<tokyovigilante>
thanks, no the clock driver comment made sense and I have split that out already, and I have made the change to an enum in the bus driver as Conor suggested, although I don't understand why, and I don't understand the rationale for (or against) a fallback for the mixer binding.
<tokyovigilante>
Thanks have just seen your message on the list too
flyback has joined #linux-sunxi
hentai has joined #linux-sunxi
<apritzel>
tokyovigilante: is that about the meaning of a fallback or about the JSON notation?
<tokyovigilante>
yeah about the meaning of a fallback
<apritzel>
<tokyovigilante>
I have seen the notation in a few other places, but don't understand why you would or wouldn't use it
<apritzel>
Using a fallback means something is fully compatible, and any driver would only need to match against the fallback string
<apritzel>
so what the existing binding means is:
<apritzel>
the is the A64 DE2 clock device, and there is the same (or at least compatible) IP in the H6
<apritzel>
we would theoretically ignore the H6 name and just use the A64 one, but it's good practice to not do so
<apritzel>
for once we document that it's actually a different implementation
<apritzel>
but more importantly this is insurance for any quirks we might need, because of bugs in the new IP
<apritzel>
so then we can later match on that specific string in the driver, and catch that special case
<apritzel>
but the separate clock driver actually suggests it's not compatible (the new one has less clocks?)
<tokyovigilante>
Yeah I suspect it is not, and actually only has 1 mixer for example compared to the H6 with two, but the docs are a bit unclear. I'm taking the T5 series datasheet as closest
<apritzel>
so the possible strings would be: just "a64", for the A64; "h6, a64", for the H6; and just "h616" for the H616
<tokyovigilante>
ok, thanks. I get the concept, will need to poke through a few of the other bindings to see how it works in practice a bit more.
<tokyovigilante>
The suggestion to split out the driver a bit more makes sense too, thanks.
<apritzel>
actually it looks like the H616 just misses the "rot" clocks
<apritzel>
the rest looks close, so I think you can reuse the existing driver file, and just reference fewer clocks, like the H3 does
<apritzel>
and speaking of which, the H3 seems to also miss the ROT clock, so maybe it's the same?
<apritzel>
so the compatible would be "h616, h3"?
<apritzel>
dammit, looks like mixer1 shares the reset line with mixer0 on the H3, but they are separate on the H616
<apritzel>
the rest looks the same
<apritzel>
but at least you can use the same driver file, just adding a separate compatible entry and the required boilerplate (just copy everything from the H3)
<tokyovigilante>
ok, will work on that. Think V2 will also need to be an RFC ;)
Daanct12 has joined #linux-sunxi
apritzel has quit [Ping timeout: 480 seconds]
<Jookia>
yay!
<Jookia>
speaking on sunxi stuff
<Jookia>
now that i'm done with u-boot for a while i'll be getting back to my kernel clocking+audio patches
<Jookia>
they've been tested on prototype hardware and confirmed to work well enough
flyback has quit [Remote host closed the connection]
hexdump0815 has joined #linux-sunxi
hexdump01 has quit [Ping timeout: 480 seconds]
hexdump01 has joined #linux-sunxi
hexdump0815 has quit [Ping timeout: 480 seconds]
aggi_ has joined #linux-sunxi
aggi has quit [Ping timeout: 480 seconds]
hexdump0815 has joined #linux-sunxi
hexdump01 has quit [Ping timeout: 480 seconds]
gsz has joined #linux-sunxi
jkm has quit [Ping timeout: 480 seconds]
JohnDoe_71Rus has joined #linux-sunxi
aggi_ has quit [Remote host closed the connection]
aggi has joined #linux-sunxi
gsz has quit [Ping timeout: 480 seconds]
Schimsalabim has quit [Ping timeout: 480 seconds]
Schimsalabim has joined #linux-sunxi
sunshavi_ has quit [Ping timeout: 480 seconds]
Schimsalabim has quit [Read error: Connection reset by peer]
Schimsalabim has joined #linux-sunxi
apritzel has joined #linux-sunxi
apritzel has quit [Ping timeout: 480 seconds]
Schimsalabim has quit [Read error: Connection reset by peer]
Schimsalabim has joined #linux-sunxi
Schimsalabim has quit [Read error: Connection reset by peer]
Schimsalabim has joined #linux-sunxi
Schimsalabim has quit [Ping timeout: 480 seconds]
Schimsalabim has joined #linux-sunxi
Schimsalabim has quit [Read error: Connection reset by peer]
Schimsalabim has joined #linux-sunxi
tnovotny has joined #linux-sunxi
colinsane has quit []
colinsane has joined #linux-sunxi
montjoie has joined #linux-sunxi
montjoie_ has quit [Ping timeout: 480 seconds]
apritzel has joined #linux-sunxi
colinsane has quit []
colinsane has joined #linux-sunxi
ity has quit [Remote host closed the connection]
ity has joined #linux-sunxi
warpme has joined #linux-sunxi
colinsane has quit []
Daanct12 has quit [Quit: WeeChat 4.3.2]
colinsane has joined #linux-sunxi
Daanct12 has joined #linux-sunxi
Daanct12 has quit []
bauen1_ has quit [Ping timeout: 480 seconds]
colinsane has quit []
colinsane has joined #linux-sunxi
<tokyovigilante>
apritzel: thanks for the clock driver tips, turns out the H3 clock and H5 reset structs match perfectly to use the existing DE2 driver, only issue is what looks suspiciously like magic register values in jernej's DE33 driver
<tokyovigilante>
writel(0x0000A980, reg + 0x28);
<tokyovigilante>
writel(0, reg + 0x24);
<tokyovigilante>
which are required to get a display working on the H700
aggi_ has joined #linux-sunxi
aggi has quit [Ping timeout: 480 seconds]
dsimic is now known as Guest10041
dsimic has joined #linux-sunxi
Guest10041 has quit [Ping timeout: 480 seconds]
warpme has quit []
bauen1 has joined #linux-sunxi
<apritzel>
tokyovigilante: do you have the DE3 manual?
<macromorgan>
are there upstreamed fixes yet for the RAM code in U-Boot for the H700/T507 series? Just curious. Also didn't know if anyone was currently working in U-Boot or not for the Anbernic devices.
Schimsalabim has quit [Ping timeout: 480 seconds]
Schimsalabim has joined #linux-sunxi
tnovotny has quit [Remote host closed the connection]
bauen1 has quit [Ping timeout: 480 seconds]
<apritzel>
macromorgan: I was hoping you or tokyovigilante would ;-)
<apritzel>
and no, jernej has patches in his github, but nothing has been sent or proposed yet
<macromorgan>
I was planning on working on it, I just didn't want to step on anyone's toes. But I've been heads down with the power stuff the last few weeks so I haven't been paying attention to the status of the RAM init stuff.
<macromorgan>
I assumed I was using the latest and greatest, but on rare occasions still boot with 2048MB detected
<apritzel>
that looks more fleshed out than the bits I have seen so far
<apritzel>
macromorgan: as it seems like jernej is busy, feel free to pick those patches, slam your S-o-B on them and send them to the list. The U-Boot merge windows opens in two weeks.
<macromorgan>
okay, I'll start testing the RAM patches soon. The main thing I was wanting to do here aside from what you'd consider a "standard" integration would be to make the U-Boot device work for 5 different boards (selecting the correct devicetree at runtime).
<macromorgan>
That shouldn't be a problem if I do it after RAM init right? Meaning the tiny SRAM shouldn't be a factor?
<macromorgan>
also probably opening a whole can of worms with this question, but any thoughts on how to support suspend on a device with no ARISC core?
<Jookia>
there's different levels of suspend on devices usually
<apritzel>
macromorgan: I sketched some ideas in here a while ago, should be in the logs
<macromorgan>
okay I'll dig for it
<Jookia>
i know on the stm32mp1 series they support putting the RAM in auto refresh mode and turning everything off, then at boot setting up the hardware enough to get back to linux
<apritzel>
Jookia: yeah, that's roughly the plan
<Jookia>
ah.
<Jookia>
i don't think the datasheets say much about how to hit that power mode. i guess you'd be looking at the BSP?
<apritzel>
but the implementation is tedious, because we don't have a framework ready, so you have to do everything manually and slam it in somewhere, for instance in TF-A
<Jookia>
as a heads up, i do have an interest in suspend to RAM on the T113
<Jookia>
one device i'm working with is battery powered and the best i can offer as suspend is linux idle
<apritzel>
I think the technical details are not that much of a problem, it's just quite some work to pull all of this together and put it somewhere where it's halfway clean and integrates with the PSCI flow
<Jookia>
luckily for this case it's an actual embedded system so rebooting might actually be fine
<Jookia>
i *think*, and i might be 100% wrong, but i think ST does power management in op-tee
<Jookia>
mainline has rejected this approach i think
<apritzel>
well, we don't need to make it more complicated than it already is
<apritzel>
I think it should be part of TF-A, since that gets the idle request from the OS
<Jookia>
i was under the impression TF-A doesn't have a runtime. or am i thinking of 32-bit TF-,A
<apritzel>
but TF-A runs in DRAM, so we have to copy (and relocate?) this code to SRAM
<apritzel>
TF-A hosts the PSCI services, that's the main reason we have it, actually
<Jookia>
interesting
<apritzel>
and for a while U-Boot didn't really support runtime services, conceptually
<Jookia>
how much would be in SRAM? wouldn't you just put some data in DRAM, put it to sleep, then on a boot check for it? or am i misunderstanding?
<apritzel>
you could have some code in DRAM still, but would need the final (and first) bits in SRAM
<Jookia>
ah
<Jookia>
the botoloader puts the first bits in SRAM i think, so it would just be the final that would save registers and clock out i suppose
<apritzel>
so you would turn off as much as you can, go to SRAM, turn DRAM to self-refresh, then go to WFI and wait for a wakeup event
<apritzel>
then on the way back re-enable the DRAM, turn things back on and return to Linux
<Jookia>
oh!
<Jookia>
so you wouldn't fully shut down and reset the CPU cores?
<Jookia>
that would make life easier
<Jookia>
i was imagining you would go through the startup sequence and branch based on RAM contents
<apritzel>
the secondaries could be completely off, but you would need something to run the wakeup code, right?
<Jookia>
yeah
<Jookia>
i might completely misunderstand how the STM32MP1 series does it, i figured the system actually did an entire reset aside from the RAM
<apritzel>
mmh, that's another approach, but what would be the wakeup event, then?
<Jookia>
not sure
<Jookia>
that might be something you'd need a block for
<Jookia>
uh, IP core
<apritzel>
I mean if that somehow turns on the cores: why not? But I would think it's an interrupt, from a GPIO, or the IR, or a timer, or what not
<Jookia>
yeah
<apritzel>
and that IRQ must be taken by something that's still alive
<apritzel>
I mean this could then do a core reset and trigger the normal boot process, if that's easier
<Jookia>
I have no idea what's easier, but I imagine you wouldn't need to worry about things in SRAM then
<apritzel>
well, as usual: suspend is easy, but resume is the tricky part ;-)
<Jookia>
ah, in stm32 you can only wake up from the wakeup pin, rtc, watchdog, or reset pin. not arbitrary irqs
<Jookia>
i think the pmic is intended to handle some power logic like this
<apritzel>
you mean through the power key?
<Jookia>
yeah
<Jookia>
ST produces their own PMIC that goes along with their soc
<Jookia>
i'm not sure if it's a good assumption to assume the pmic would be helpful on random sunxi boards
<Jookia>
or if there's even a pmic there...
<apritzel>
well, the AXP PMICs support some kind of suspend mode, but I don't know if that keeps the DRAM rails alive
<macromorgan>
that's configurable I think, isn't it?
<apritzel>
I think it's supposed to just supply VCC_RTC, to just power the ARISC
<Jookia>
adding nice power management to a design of chips is a lot easier than retrofitting suspend i suppose
<apritzel>
are we talking about Allwinner? ;-)
<Jookia>
i guess comparing the ST approach here
<Jookia>
to ... whatever this is
<apritzel>
to be fair, the whole suspend story is somewhat sound with an ARISC
<Jookia>
oh, how does that work? the ARISC core stays alive?
<apritzel>
yes, it's supplied by VCC-RTC, or at least a separate supply
<apritzel>
so you can turn VCC_CPU off completely
<Jookia>
oh, that's pretty cool
<apritzel>
I think that's the whole point of the ARISC: to provide some logic in super low power states
<apritzel>
I think it can even run on a 32KHz oscillator, so you can turn the 24 MHz osc off
<apritzel>
but smaeul is the real expert here
<Jookia>
i'm still fairly new to low level stuff like that
<apritzel>
but the DRAM supply problem is still there, so I guess it's indeed configurable in the PMIC
<apritzel>
but may the PMIC doesn't go to sleep, it has just many rails turned off, and delivers a power button event via an interrupt to the ARISC
<Jookia>
so linux wouldn't need to change, it would turn off the things it owns then call ATF, then ATF would turn off the things it owns and does suspend/resume
<apritzel>
yes, it would work already, provided the PSCI firmware does its job
<Jookia>
interesting
<Jookia>
unfortunately i live in t113 land without ATF :(
<apritzel>
well, you still have a PSCI runtime, it just ships with U-Boot proper, getting copied into some SRAM
<Jookia>
interesting
bauen1 has joined #linux-sunxi
apritzel has quit [Ping timeout: 480 seconds]
Schimsalabim has quit [Ping timeout: 480 seconds]
Schimsalabim has joined #linux-sunxi
Schimsalabim has quit [Read error: Connection reset by peer]
Schimsalabim has joined #linux-sunxi
warpme has quit []
ftg has joined #linux-sunxi
<tokyovigilante>
apritzel: I have the DE3 but not DE33 manual, and those registers only need to be set for DE33 it seems, they don’t quite line up with what I can find in the DE3 manual. thanks for the tips about quirks. I think V2 will be much cleaner.
<tokyovigilante>
macromorgan: I have my current DRAM patches and other u-boot stuff including defconfigs with the relevant timings in my tree, but no great further insights other than what jernej had provided recently, very happy for you to take that and run. After I do the display engine for the kernel, I still have the subsequent LCD/TCON work (which is mostly device tree thankfully) then GPU and
<tokyovigilante>
sound, and I wanted to come back to the SD2 voltage switch as well, so great if you could do the DRAM patches.
<tokyovigilante>
I also want to get the LCD working with u-boot for an early splash based on Jookia’s driver
<tokyovigilante>
regarding suspend, it would be ideal if the PMIC could just keep RAM powered and switch off the CPU entirely, my cursory reading of the datasheet suggested that might be possible? power consumption seems very
<tokyovigilante>
high when suspended with the stock firmware
<macromorgan>
You probably need at least 1 CPU core left on too along with the RAM I'm betting
<macromorgan>
I'm ignorant and haven't read apritzel's musings on the topic yet, but I'm betting we need to either keep 1 CPU core active and then if we can't fit the necessary code in sram we need to also keep the RAM active. Meaning there probably won't be much power savings to speak of even if we do get the monstrosity to work.
<macromorgan>
that said if we shut down the wifi and backlight and downclock the CPU to oblivion I'm betting we save some power
<tokyovigilante>
yeah I think that was the gist of it, I had always assumed suspend to ram meant the CPU could be off entirely, but maybe that’s an x86 thing
apritzel has joined #linux-sunxi
<apritzel>
tokyovigilante: btw: if you send a "v2", please don't make it an RFC again. Arguably your first post shouldn't have been an RFC already
<apritzel>
RFC usually comes with an explicit set of questions, regarding some approaches, like: Is this the right driver subsystem? The DT binding looks awkward, any ideas how to improve it? Should this live in a separate driver?
<apritzel>
so just send a v1 now, of course without explicitly saying v1, it's just "[PATCH x/y]"
<apritzel>
tokyovigilante: oh, also: jernej's email address in the from field is no longer valid, please use his gmail address (git commit --amend --author "...")
gsz has quit [Ping timeout: 480 seconds]
ftg has quit [Read error: Connection reset by peer]
jason123santaonirc is now known as jason123onirc
<tokyovigilante>
thanks apritzel, will do, and yes had noted Jernej’s old address,
<tokyovigilante>
will correct all those.
<apritzel>
do all the Anbernic devices have a power button?
<tokyovigilante>
All the RG35XX/H700 ones do, not sure about the others macromorgan had worked on previously
<apritzel>
ah, thanks, I am just interested in the Allwinner ones
<apritzel>
from briefly looking at the AXP717 data sheet, I don't think we can use the PMIC for suspend
<apritzel>
in "power off" mode, only VCC-RTC is supplied, so DRAM would lose power
<apritzel>
you can set rails to whatever state you like in the AXP717's sleep mode, but wakeup from there is only possible via either a register write or the IRQ pin, but apparently not via the power button
<apritzel>
so I think we have to keep the AXP running, plus one CPU core, in WFI, and wait for the PowerKey interrupt
<apritzel>
we power off most devices, including system busses and clocks as far as possible, also PMIC rails, then jump to some SRAM code, which puts the DRAM controller into self refresh, then goes to WFI
<apritzel>
on the PowerKey interrupt, we bring back the DRAM controller, and continue in TF-A DRAM code, which reverses the suspend actions (PMIC, buses, clocks, devices), then returns to Linux
<apritzel>
so the SRAM code would be quite small, ideally just a few hundred bytes, which should fit easily at the end of SRAM A1