<apritzel>
Jookia: have you looked at what it would take to have proper DM clock support, not those old-style clock hacks?
<Jookia>
apritzel: i'm not familiar with the clock DM stuff ... can i specify parents and ask it for specific clock rates/etc?
<tokyovigilante>
apritzel: can I ask about the usb regulators? I assume they come from the AXP boost, but I'm struggling to get two defined, one for each of the -H's ports
<apritzel>
in the display code it should be easier, almost Linux like, since you just tell it to use the clocks provided by the DT
<apritzel>
tokyovigilante: are they actually both using the same regulator?
<Jookia>
apritzel: does it support finding rates/based on the parent? some of the clocking code in the display is very much 'find a solution for multiple clocks then set a PLL and set a peripheral clock divisor' which makes it complicated
<apritzel>
Jookia: the downside is that we don't have set_rate() support at all in the U-Boot DM clock code, just gates and resets (so those should be easy)
<Jookia>
yeah, that's where i'm not too sure how to integrate
<apritzel>
Jookia: we were always shying away from the problem, since there was no real killer need for it
<Jookia>
hmm.
<apritzel>
but the MMC code might benefit as well, since it has the same problem
<tokyovigilante>
apritzel: not sure, I've just taken macromorgan's defines so may just be one
<Jookia>
this is kind of an exact situation where you'd need it. but i'm not sure how the code would model it
<apritzel>
Jookia: but MMC is needed for non-DM as well, so we have the old-style clock there in any case
<Jookia>
but the amount of clock creep here is concerning
<apritzel>
Jookia: theoretically it's not complicated, someone(TM) would just need to sit down and implement that in sunxi clock driver
<apritzel>
yeah, that's why I don't want to go this way for new code
<apritzel>
I guess it's time to bite the bullet
<Jookia>
copy paste linux code?
<apritzel>
let me find you a pointer ....
<apritzel>
for the actual rate selection: maybe, or you copy the existing code. But it needs to live in the clock driver, not the display driver
<Jookia>
i do have some knowledge of how clocking subsystem in linux works as i have implemented fractional clocking (shameful sounds of not upstreaming it yet)
<apritzel>
I think the U-Boot DM clock is somewhat similar, though a bit simpler, I think
<Jookia>
so unfortuantely it seems like something i COULD do
<apritzel>
the breadcrumbs start at drivers/clk/sunxi/clk_sunxi.c: struct clk_ops sunxi_clk_ops { ...
<apritzel>
you see we have just .enable and .disable here, but there are more
<Jookia>
does u-boot have the code for trying multiple parents/finding a rate?
<apritzel>
I haven't looked, but possibly
<apritzel>
I mean multiple other platforms use the clock framework fully
<Jookia>
interesting
<Jookia>
yes that would work
<apritzel>
I guess we need at least .set_rate, maybe .set_parent
<apritzel>
and some way to express the details in our (or a new?) struct
<Jookia>
yes, linux does this. so i could probably copy some of that
<apritzel>
the first clock would take a bit of work, but then the rest would be quite easy, I guess: just encode the bits and offsets
<Jookia>
i'm going to circle back around to clocking probably next month sometime
<apritzel>
sounds good! I will see if I find time earlier
<Jookia>
i'd imagine doing this would be just specifically for these clocks for now :)
<Jookia>
ie the DE clocks
<apritzel>
well, but it sets the stage for other clocks
<Jookia>
yep!
<Jookia>
the 'it'll only support this subset' is more for me
<apritzel>
though we don't need many, the MMC clock is one that comes to mind, but we have the code separate for the SPL already, so there is not too much to win
<apritzel>
Jookia: many thanks for digging out the details anyway, I will try to give it a run later
<Jookia>
no problem. any feedback is good :)
<Jookia>
at least having a series up means someone can use it
<apritzel>
tokyovigilante: on the -H model, if you supply the console via a USB-C power supply, does the USB port work with just the GPIO controlled fixed regulator
<apritzel>
since I would assume we need the boost regulator only when running off the battery
<apritzel>
I mean the second, host-only USB port, connected to EHCI/OHCI1
<tokyovigilante>
makes sense. I will grab a USB device and grab it a try presently, also having some wee trouble with a panic after boot, getting a message
<tokyovigilante>
vcc-1v8: disabling
<tokyovigilante>
and then the console becomes unresponsive
<tokyovigilante>
maybe needs to be always-on?
<apritzel>
ah, yes
<apritzel>
the SoC requires 1.8V on some pins, I think for instance VCC-PLL on the H616
<Jookia>
btw i'm putting the spl cleanup in my queue of things to review
<apritzel>
Jookia: thanks!
<tokyovigilante>
apritzel: thanks, also a bunch of sun50i-h616-pinctrl 300b000.pinctrl: supply vcc-pf not found, using dummy regulator
<apritzel>
Jookia: I will check how far I come with reviewing the SPI series
<tokyovigilante>
is it worth defining some of these? I see some of the other DTs have them
<apritzel>
tokyovigilante: well, yes, but mostly to avoid this message, and to be complete, so it's not the highest priority
<apritzel>
tricky part it's not easy to figure out without schematics, although we can have some guesses
<apritzel>
I think macromorgan mentioned he started looking at that
<apritzel>
so just leave them out for now, we can add them later, to squash those messages
<Jookia>
apritzel: no rush :)
<tokyovigilante>
thanks, yeah never seemed to cause an actual problem with them undefined
<tokyovigilante>
but wifi/bt working 100% now with the extra regulator work
<Jookia>
whoa, that's some good progress there
<apritzel>
tokyovigilante: what it vcc-1v8? From the AXP or a fixed regulator? I guess AXP?
<apritzel>
BLDO2, maybe?
<apritzel>
if you look at the T5 series datasheet (not user manual), section 5.2 lists a bunch of power domains and their required voltages
<tokyovigilante>
yup BLDO2
<apritzel>
there is VCC_PLL and VCC_DCXO with 1.8V, they sound essential
<tokyovigilante>
ta, will do
<apritzel>
set the regulator name to vcc-pll-dcxo or something, that should serve as documentation why this clock is always-on
<apritzel>
DCXO is the circuitry for supporting the 24 MHz crystal, so there is basically not much happening without that, same for the PLLs
<tokyovigilante>
make sense, sorry the AXP regulator node or the SOC node?
<apritzel>
the "regulator-name" property should be vcc-something-something, roughly listing the consumers
<apritzel>
if they are something obviously essential, like PLL, which has no consumer DT node, then you use always-on, and in this case don't even need a comment
<apritzel>
look at sun50i-h64-remix-mini-pc.dts, as the AXP313 boards are not good examples, since they have only so few rails
<apritzel>
if USB host is unclear, leave it out for now
<apritzel>
we need to have something correct and working by next Friday, I guess, to get into 6.10
<tokyovigilante>
Thanks
<apritzel>
it doesn't need to be complete, though
<tokyovigilante>
feel like I'm getting close, it's pretty stable and wifi/bt working well
<apritzel>
that sounds great. If you feel like it's good, send it
<tokyovigilante>
Just want to look at the cpufreq opp again for 1.5ghz but that can be a followup
<tokyovigilante>
thanks, will just sort these regulators, have addressed the rest of the feedback I think
<apritzel>
I dropped support for the H700 from the cpufreq series, so will get the fallback 1.4 GHz
<apritzel>
so don't waste your time on this now
<apritzel>
and don't worry: there will still be comments, probably, but much less, and then the version after that is probably ready
<tokyovigilante>
yeah that's fine
<apritzel>
so if you send something before Monday, there should still be time for another revision. I will try to review that quickly
<Jookia>
apritzel: can you cc me when you do your axp717 patch refresh so i can review it? or is that just auto done if you're pulling in trailers
apritzel has quit [Ping timeout: 480 seconds]
montjoie_ has joined #linux-sunxi
<tokyovigilante>
out now so will try and finish this up and post this evening
montjoie has quit [Ping timeout: 480 seconds]
Schimsalabim has quit [Read error: Connection reset by peer]
Schimsalabim has joined #linux-sunxi
KREYREN_oftc has quit [Remote host closed the connection]
KREYREN_oftc has joined #linux-sunxi
JohnDoe_71Rus has joined #linux-sunxi
KREYREN_oftc has quit [Remote host closed the connection]
KREYREN_oftc has joined #linux-sunxi
KREYREN_oftc has quit [Remote host closed the connection]
KREYREN_oftc has joined #linux-sunxi
KREYREN_oftc has quit [Remote host closed the connection]
KREYREN_oftc has joined #linux-sunxi
KREYREN_oftc has quit [Remote host closed the connection]
KREYREN_oftc has joined #linux-sunxi
hexdump0815 has joined #linux-sunxi
KREYREN_oftc has quit [Remote host closed the connection]
hexdump01 has quit [Ping timeout: 480 seconds]
KREYREN_oftc has joined #linux-sunxi
KREYREN_oftc has quit [Write error: connection closed]
KREYREN_oftc has joined #linux-sunxi
Schimsalabim has quit [Read error: Connection reset by peer]
Schimsalabim has joined #linux-sunxi
KREYREN_oftc has quit [Remote host closed the connection]
KREYREN_oftc has joined #linux-sunxi
KREYREN_oftc has quit [Remote host closed the connection]
KREYREN_oftc has joined #linux-sunxi
KREYREN_oftc has quit [Remote host closed the connection]
apritzel has joined #linux-sunxi
Net147 has quit [Quit: Quit]
Net147 has joined #linux-sunxi
Schimsalabim has quit [Ping timeout: 480 seconds]
Schimsalabim has joined #linux-sunxi
apritzel has quit [Ping timeout: 480 seconds]
warpme has joined #linux-sunxi
<dok>
i am bit late to the party, but i've (partially) ported the sunxi-clk driver from linux to barebox. not sure if this is of interest for u-boot.
<Jookia>
dok: oh cool!
<Jookia>
dok: how much allwinner barebox support do you have working? :)
<dok>
uart and emmc on A64 (pine64)
apritzel has joined #linux-sunxi
<apritzel>
dok: we deliberately decided against porting the whole Linux clk driver to U-Boot, since that would be total overkill, just blowing up the code base
<apritzel>
clocks and pinctrl are particularly bad, since they is little information in the DT itself, so it requires vast tables in the code
<apritzel>
which is somewhat acceptable in Linux, but a bit over the top for bootloaders
<tokyovigilante>
macromorgan: have you been able to get SD2 working? the card detect GPIO is, but I'm getting a power error with a card in
<apritzel>
Jookia: I posted a v2 of the AXP717 already on Thursday, and I thought I CCed: you?
<apritzel>
tokyovigilante: the regulator must be able to provide 3.3V
<tokyovigilante>
I've got this for SD2 currently
<tokyovigilante>
vmmc-supply = <®_vcc_sd2>;
<tokyovigilante>
vmmc-supply = <®_vcc_sd2>;
<tokyovigilante>
vqmmc-supply = <®_aldo1>;
<tokyovigilante>
which is a 3.3v supply (also used for SD1 so probably needs renaming)
<Jookia>
apritzel: will review, thanks :)
<tokyovigilante>
Although looks like I have ALDO1 supplying it, which doesn't seem rigth
<apritzel>
to be able to boot from SD1, the regulators must be already correct at reset, so an AXP rail supplying it sounds unlikely
<apritzel>
in general it is a bit poor design to use the same vqmmc regulator for both slots
<tokyovigilante>
I don't actually have a vqmmc for slot 1, so this does seem quite wrong
<apritzel>
that's quite common, in this case it's assumed to be the same as vmmc
<apritzel>
just saying that the first SD slot typically has hard wired supplies, to be ready when the BROM wants to load (the BROM cannot know about any PMICs)
<tokyovigilante>
right, makes sense
<apritzel>
vmmc could be shared, that's a constant 3.3V anyway
<apritzel>
but vqmmc can be negotiated between the card and the controller, so it should be individual per slot
<apritzel>
not necessarily saying that Anbernic did it that way, but that would be a clever choice ;-)
<apritzel>
you could try to quickly benchmark the SD card performances in the BSP image, to see it any of them exceeds 25 MB/s
<tokyovigilante>
macromorgan had SD1 powered from CLDO3 which didn't boot for me, this might be why
<apritzel>
then you would know that this slot supports a switchable vqmmc. MMC0 supports this within the SoC already, but for MMC2 that would mean that PortC is powered by an AXP rail, and can be switched
<tokyovigilante>
also this is a surprise -
<tokyovigilante>
[ 1.662978] boost: failed to apply 5000000-5000000uV constraint: -EINVAL
<tokyovigilante>
just adding in a boost regulator
<apritzel>
try 5.062 volts
<apritzel>
the boost regulator has both an odd range and an odd stepping, so exactly 5.000V cannot be programmed
<tokyovigilante>
nice
<tokyovigilante>
[ 1.641646] boost: Bringing 5126000uV into 5062000-5062000uV
<tokyovigilante>
should I just pick 5.126v in that case?
<Jookia>
if you can use 5.1 it might make devices a little happier
apritzel has quit [Ping timeout: 480 seconds]
<tokyovigilante>
ok, no problems with 5.126, interestingly locks up when plugging a USB device in the second slot however
<tokyovigilante>
and still no joy with MMC2.
<tokyovigilante>
I've also had to enable ALDO3/4 and CPUSLDO always-on to keep it up after boot now, otherwise those regulators get disabled with a lockup.
<tokyovigilante>
certainly would be ideal to have a schematic
<Jookia>
maybe you could ask anbernic for a schematic? say you're mainlining the board FOR FREE :)
<tokyovigilante>
IKR
<tokyovigilante>
macromorgan has already tried that, he gets the devices for free but absolutely no help or docs
<Jookia>
the precious schematics. a list of things that connect together
<tokyovigilante>
surely regulator-always-on and regulator-boot-on are redundant together?
<Jookia>
i think regulator-boot-on signals the bootloader turned it on
<tokyovigilante>
hmm, so that is probably the case for DCDC1 and DCDC3 for CPU and DRAM
<tokyovigilante>
Ah well, I will chuck it in then get told off on list I'm sure ;)
<Jookia>
the LCD patches require the panel to be supported in u-boot unless it uses simple-pane
<Jookia>
panel*
<Jookia>
unless there's like ... a bridge
<Jookia>
i'm not sure how it works
<tokyovigilante>
heh, ah right, I thought this was for linux not u-boot
<Jookia>
nope, sorry :) though shouldn't LCD work on your board?
<Jookia>
what's blocking it?
<tokyovigilante>
jernej has an HDMI patch for linux which is not upstreamed but works a treat on the H616
<tokyovigilante>
probably just my incompetence
<tokyovigilante>
it may be as simple as some DT enablement
<Jookia>
it likely is simple like that yeah
<Jookia>
i'd say wait until you have the rest of the board figured out
<Jookia>
you've made really good progress so far though :D
<tokyovigilante>
the main pieces left are the GPU (should be supported by panfrost but crashing on startup so probably a regulator as well), then the backlight, RGB for the LCD, and audio
<tokyovigilante>
yeah it is going well
<tokyovigilante>
I can take no credit, I just do what I'm told ;)
<tokyovigilante>
right, out for the night, thanks!
<Jookia>
o/
<Jookia>
90% of porting is clocking and regulators :(
<Jookia>
apritzel: kind of off topic but i'm going to add a panel to u-boot for my board and it requires 9-bit spi. in linux there's a 'does spi driver support bitlen' command, but in u-boot there's not. is adding this a bad idea?
<Jookia>
right now i think it's safe to say all drivers support 0 and multiples of 8