<apritzel>
I mean the PMICs of choice (AXP806,805,305) don't even have battery support
<apritzel>
I mean AW seems to become more consequent in their peripheral choice: no more Ethernet & HDMI in Axx SoCs (A63), no panel and camera support in H class (H616)
<smaeul>
apritzel: the purpose of two DRAM PLLs is so you only modify the factors of the inactive PLL, then swap once it locks
<smaeul>
which is explicitly supported now for CPUX as well, with a PLL_PERIPH0 bypass of PLL_CPUX
<apritzel>
smaeul: but isn't PLL_CPUX supposed to be able to switch frequency without glitches, and without switching?
<apritzel>
or does that not really work reliably?
<smaeul>
apritzel: it doesn't work reliably, which is why we have a rate notifier that reparents to OSC24M
<apritzel>
right, I was scratching my head about that I found that somewhere in the code
<smaeul>
and in the newest (H616 I believe) manual, PLL_CPUX is actually described as DVFS = NO in the PLL table
<apritzel>
but AW seemed to go to great lengths in the manual to claim that the PLL_CPUX (and only that one) could do "live" changes?
<smaeul>
they used to, yes
<apritzel>
so they messed up, have some glitches now and then, and gave up?
<smaeul>
sure, something like that
<smaeul>
not that bypassing the PLL during rate changes really breaks anything
<apritzel>
smaeul: so PERIPH0(1x) can now drive the cores?
<apritzel>
which is typically at 600 MHz?
<smaeul>
apritzel: yes, read 3.3.3.1. Frequency Adjustment of PLL_CPUX in H616 manual
<smaeul>
(1) Before you configure PLL_CPU, switch the clock source of CPU to PLL_PERI0(1X)
popolon has quit [Quit: WeeChat 3.0]
<apritzel>
smaeul: ah, thanks for the pointer, I was already rummaging around in that area
<apritzel>
and that explicitly mentions the DRAM switch there, thanks
<apritzel>
smaeul: do you use frequency scaling for DRAM in crust yet, or do you have any plans for that?
<smaeul>
apritzel: not currently, I only touch the DRAM PLL when I turn it off during suspend
<smaeul>
but that is something that I want to do eventually
<smaeul>
doing it in crust has the nice property that I can temporarily stop the world to reprogram the DRAM controller
<smaeul>
and if we ever want to turn off VDD_SYS, either ATF or crust needs to be able to program the DRAM controller from scratch anyway
<apritzel>
ah, so you turn the PLL off, but need to keep it powered up, to not lose the DRAM controller setup?
<smaeul>
I can reset the AHB/AXI/MBUS domain, but I can't reset the APB domain. all of those are powered by VDD_SYS, which can't be turned off in suspend for a multitude of reasons
<smaeul>
(APB domain == MCTL registers)
<apritzel>
with "suspend" you mean suspend-to-RAM or suspend-to-disk?
<smaeul>
suspend to ram
<smaeul>
for suspend to disk (== poweroff), I can kill DRAM entirely, since that is followed by normal boot
<apritzel>
but then you need to DRAM controller to stay alive to perform the refresh? Or do the chips do that autonomously in some self-refresh state?
<smaeul>
correct, the chips are in self-refresh, and the DRAM pads are all tristated
<apritzel>
ah, I see
<apritzel>
was confused how you could tinker with the DRAM controller when you care about the content ...
<smaeul>
very carefully
<apritzel>
can imagine ...
<apritzel>
sounds like open heart surgery
apritzel has quit [Ping timeout: 246 seconds]
ChriChri_ has joined #linux-sunxi
ChriChri has quit [Ping timeout: 260 seconds]
ChriChri_ is now known as ChriChri
Net147 has joined #linux-sunxi
Net147 has quit [Read error: Connection reset by peer]
Net147 has joined #linux-sunxi
Net147 has quit [Read error: Connection reset by peer]
Net147 has joined #linux-sunxi
netlynx has quit [Quit: Ex-Chat]
victhor has quit [Ping timeout: 265 seconds]
vagrantc has quit [Ping timeout: 272 seconds]
night199uk has quit [Quit: ZNC 1.6.6+deb1ubuntu0.2 - http://znc.in]
sunshavi has quit [Read error: Connection reset by peer]
night199uk has joined #linux-sunxi
gaston1980 has quit [Quit: Konversation terminated!]
night199uk has quit [Quit: ZNC 1.6.6+deb1ubuntu0.2 - http://znc.in]
<apritzel>
jernej: how hard was it to get a UART on your TV box?
<jernej>
simple, it is nicely marked
<apritzel>
no pins to bridge or transistors to solder?
<jernej>
I just soldered 3 pins on it
<jernej>
I mean on header
<jernej>
nope
<jernej>
first box was also easy, header was already properly marked and worked first time already
pion333 has quit [Remote host closed the connection]
<apritzel>
jernej: do you also have one of those T95 boxes? Or know if they are similar?
<jernej>
yes, second one is T95 and it's pretty decent build quality
<jernej>
easy to open - screws
<jernej>
FEL button is behind analog audio port, but at this stage you won't need it
<jernej>
one of the reasons for TV box was 4 GiB RAM
<apritzel>
did you boot mainline on it? Does eMMC work without the shift-by-2 fix?
<apritzel>
the manual suggests that this is only for MMC0 and MMC1
<jernej>
not yet
<apritzel>
which would make MMC2 compatible to the a64_emmc_cfg
pion3k has joined #linux-sunxi
<pion3k>
Hi guys, I have a question concerning setting internal pull-up/down for PA10 gpio in BananaPi M2+ v1.2 (allwinner H3), kernel 5.4.69. I added new node to sun8i-h3-bananapi-m2-plus.dts, in the pinctrl@1c20800 node, with the following properties: pins = "PA10"; function = "gpio_in"; drive-strength = <0x1e>; bias-pull-down; I believe that there is something fundamental missing here since I observer floating values on the PA10 by usin
<pion3k>
g libgpiod. How can I configure this internal pull-up/down prop?
<apritzel>
pion3k: that's not how you typically configure GPIOs
ChanServ has quit [shutting down]
<apritzel>
I think on 5.4 you can use the new ioctl based GPIO interface, which allow to configure pull-ups, IIRC
ChanServ has joined #linux-sunxi
lynxis has quit [Ping timeout: 260 seconds]
lynxis has joined #linux-sunxi
<apritzel>
pion3k: dammit, pull up/down control seems to be a 5.5 feature ...
<pion3k>
Hmm, what should be the proper way for 5.4 then? Is it possible to configure this through dts? I just want to achieve not-floating gpio input pin to test its value in the userspace
<apritzel>
pion3k: yeah, looks like you need to configure the pull down this way in the DT in this case
<apritzel>
but I am not sure if the pinctrl entry is used this way for GPIOs, because typically those pinctrl child nodes need to be referenced by some other DT node to be active
<jernej>
apritzel: any luck with USB?
<apritzel>
not yet
<jernej>
in worst case, you can boot BSP image and dump register values
<pion3k>
apritzel: This is what I concluded as well, but unfortunately I could not find any working example for that. For example for a similar description of pinctrl for mmc0-pins I can see that it has a property phandle=<0x08>, which in turn is referenced in the mmc@1c0f000 node by: pinctrl-0=<0x08>. Does it mean that I should add new node with some specific GPIO driver selected (through the compatible string)?
dddddd has quit [Quit: dddddd]
<apritzel>
pion3k: that sounds like not the right way. So far personally I got away without pull-up/downs for my GPIOs, and just saw that it's now possible to configure from userland
<apritzel>
pion3k: for MMC for instance, the MMC driver uses the in-kernel GPIO interface to configure the pin, which takes care of the pull-up/down settings
<apritzel>
maybe some other people more familiar with GPIOs know the proper way?
dddddd has joined #linux-sunxi
<pion3k>
If only I had known them :) Anyway, thanks for helping. I will ask more general question tomorrow, maybe there will be more people here.
merbanan has quit [Ping timeout: 256 seconds]
merbanan has joined #linux-sunxi
<apritzel>
clementp[m]: you were right: on closer inspection there are many more subtle differences between H6 and H616, especially in the whole video area (which I only skimmed over before)
<apritzel>
I still think it warrants a joint driver
<clementp[m]>
Yes if it was only some slightly clock différences but the fact that H6 PLL enable / disable whereas H616 toggle the PLL output means that all PLLs will have different structures
pion3k has quit [Quit: Leaving.]
<clementp[m]>
And H6 is sun50iw6, h616 sun50iw9, a100 sun50iw10. Maybe h616 and a100 are close than h6 and h616
<apritzel>
ah, good point, the A100 clocks are in there already
<apritzel>
clementp[m]: well, the enable it only additional, and default on, so for now it shouldn't hurt
<clementp[m]>
Haha I think they are no logic to choose one or the other
<apritzel>
clementp[m]: well, if the A100 is closer, I might need less additional clocks
<apritzel>
and A100 is probably more again more a true tablet-only chip (like the A63), so it removes everything non-tablet-y, like Ethernet and HDMI
<apritzel>
let met check that ccu file ...
<clementp[m]>
Yes I agree I think h616 clocks are close to h6
<clementp[m]>
Than a100
<apritzel>
yeah, indeed no sign of GMACs or HDMI or TVout
<clementp[m]>
Except for this output switch Vs enable disable.
<apritzel>
indeed
<apritzel>
I am not sure this the right way of modelling it
<clementp[m]>
What do you mean ?
<apritzel>
I mean we now just gate the PLL output if we turn it off, but it keeps running
<apritzel>
wasting power
<apritzel>
I think the reason we turn PLLs off is to save power, maybe even reduce electrical noise
<apritzel>
AFAIK PLLs are nasty analogue circuitry
<clementp[m]>
Ok
<apritzel>
and also that means that we rely on all PLLs already being enabled, since we lose the possibility to turn them on?
<clementp[m]>
It's done at CCU probe
<apritzel>
ah, I see
<apritzel>
I wonder if "Due to the current design..." means "has always caused trouble, we just decided to work around it with an extra gate"
<apritzel>
clementp[m]: do you know of any available A100 documentation?
<clementp[m]>
No never see one, Just code source and Yang Tao upstream
<clementp[m]>
But I think you're right this a bit a hack we use the .enable to gate the output
<clementp[m]>
I think we should add a .gate with this bit and add a flag to say USE_GATE_NOT_ENABLE
<apritzel>
yeah, I was thinking about this as well
<clementp[m]>
And i also agree is this due to new design or we just recently observed some trouble... so we fix it for new SoC
<apritzel>
.gate and a flag sounds like a good idea!
<clementp[m]>
I have some instability with GPU PLL when I enable GPU devfreq
<apritzel>
not sure what causes trouble, exactly, maybe it's just switching off? So we could leave them off in probe, and turn them on *once* we need them (but never turn them off again)
<smaeul>
the manual mentions that switching on/off one PLL could affect other PLLs
<apritzel>
and only use the .gate from that point on
<smaeul>
speaking of PLL bugs... the newest A64 ARISC blob has code to repeatedly power cycle the entire VCC-PLL power domain if it can't lock PLL_DDR1 during resume :/
<apritzel>
smaeul: oh dear, some code should never be looked at ...
<apritzel>
smaeul: do those reverse engineer tools support OpenRISC? Or do you work on pure objdumps?
<jernej>
apritzel: megi wrote openrisc plugin for ghidra
<apritzel>
I spent two weeks of debugging back in uni because I didn't want to hear to my prof saying: "just put a NOP in there"
<smaeul>
:)
<smaeul>
clementp[m]: yes, I need to update that page some. though ideally I could get the processor plugin merged upstream as well
<bauen1>
apritzel: because some instructions won't work properly unless the next instruction is a "nop" or how should that be understood ?
<smaeul>
bauen1: the CPU executes the instruction after a branch before branching. you can pretend that doesn't happen by putting a nop after every branch
<apritzel>
bauen1: because as a young lad you try to put some *previous* instruction in there, to not waste that slot
<bauen1>
aren't the side effects of that _supposed_ to be invisible
<apritzel>
bauen1: yeah, *theoretically* that should work, it's just mind-boggling and error prone
<bauen1>
apritzel: so you were trying to "optimise" by putting the first instruction of a loop after the branch that goes back up to save a word of code ?
<apritzel>
bauen1: something like that, yeah
<apritzel>
for unconditional branches that works quite well, but for conditional ones you quickly get into trouble
<bauen1>
tbh that sounds like a nice idea to fuck with the one correcting your homework
<smaeul>
the reason why switch statements are fun is they usually get compiled to a binary search => chained conditional branches
<smaeul>
on or1k a conditional branch takes 2 instructions: 1) set-flag-if-cond 2) branch-if-flag
<smaeul>
so gcc puts the second set-flag-if-cond inside the first branch-if-flag's delay slot, and when you disassemble it, you just see branch-if-flag -> branch-if-flag -> branch-if-flag and you have to figure out where the instruction actually setting the flag is
<clementp[m]>
apritzel: found some A100 docs
<clementp[m]>
maybe gediz0x539 could you download them ?
<apritzel>
smaeul: lol, but indeed a compiler is the only sane "person" to be able to pull those things off
<apritzel>
I wonder if this is a side effect of generic peephole delay-slot optimisation, or something put deliberately into the code generator for switch/case constructs
<smaeul>
I don't believe it's switch/case-specific
<smaeul>
one downside of ghidra is that sharing the databases is nontrivial - collaboration requires an application-specific server
<smaeul>
though if anyone is interested, I'm happy to share what I have
<jernej>
apritzel: I just checked PortA oddities
<jernej>
this particular die is used in several packages
<jernej>
and on some, port A seems to be connected to pins
<jernej>
this can be deduced from comment in sun50iw9p1-pinctrl.dtsi
lynxis has quit [Read error: Connection reset by peer]
<apritzel>
jernej: you mean that affects the functions *other* than gmac1? And gmac1 is there in every case, and we also need to switch to that function for the internal PHY to work?