<Jookia>
time to head back to the u-boot clock mines today :D
KREYREN_ has joined #linux-sunxi
KREYREN_oftc has quit [Remote host closed the connection]
montjoie has joined #linux-sunxi
montjoie_ has quit [Ping timeout: 480 seconds]
<tokyovigilante>
apritzel: sorry without CLDO4 referenced (for vmmc) it doesn't work. ALDO1 doesn't actually need to be referenced for vqmmc, but is defined in the vendor BSP @1.8v which is why we have it there initially I think.
<tokyovigilante>
Have read the SD spec in part, but is the inference that the VCC and IO supplies are the same rail, initially 3.3v and then switched to 1.8v for LVS, or is it two separate supplies, with the 1.8v only enabled if LVS is supported and negotiated?
<tokyovigilante>
or is it implementation-specific?
<tokyovigilante>
ALDO1@3.3v for vmmc doesn't work either - [ 2.012045] sunxi-mmc 4022000.mmc: no support for card's volts
<tokyovigilante>
I do note I've been seeing but politely ignoring this about MMC1 for the wifi - [ 2.213622] sunxi-mmc 4021000.mmc: card claims to support voltages below defined range
<tokyovigilante>
Ah here we go, ALDO1@3.3v does work with no-1-8-v set
<tokyovigilante>
can't get rid of the requirement for that extra regulator though
Schimsalabim has quit [Read error: Connection reset by peer]
<tokyovigilante>
That's a new one...
<Jookia>
card's volts!
Schimsalabim has joined #linux-sunxi
vagrantc has quit [Quit: leaving]
<tokyovigilante>
Vexing, but it seems for LVS, there must be a VCC/VDD which stays at 3.3v, and a vqmcc/VCC-IO/VDD2 which starts at 3.3v then is switched to 1.8v for LVS. But in the vendor BSP clearly ALDO1 is vqmmc, and is reported running at 1.8v, ie ALDO1 must be vqmmc, so then it can't be vmmc, but where is vmmc? Maybe I will just take the board to work and CT it to get traces ;)
hexdump01 has joined #linux-sunxi
hexdump0815 has quit [Ping timeout: 480 seconds]
JohnDoe_71Rus has joined #linux-sunxi
KREYREN_ has quit [Remote host closed the connection]
KREYREN_ has joined #linux-sunxi
<Jookia>
okay, i figured out how to bind device tree clocks correctly. the allwinner tree is sloowly happening: https://paste.xogium.me/Ig.txt
<apritzel>
so for all Allwinner boards so far we go with not specifying vqmmc explicitly, which means it's the same as vmmc, which must be 3.3V
<apritzel>
and all SD cards must work with this setting, although this limits the speed modes available
<apritzel>
so I wonder if we should just drop vqmmc, but keep aldo1 at 1.8V, as always-on?
<gnarface>
apritzel: does that sound related to why i couldn't get sd-uhs-sdr104 acknowledged by my pine64+ board?
<apritzel>
as for why the BSP runs at 1.8V: this is the *runtime* value, for when the board is up and running, right? So it could have been switched to that value before?
<apritzel>
gnarface: that was for WiFi, right?
<gnarface>
apritzel: yea, the sdio wifi module add-on
<tokyovigilante>
apritzel: yup, was hoping you might pop in. Yeah absolutely, there is obviously more to unpack with the regulators, so would be good to just drop it for now.
<tokyovigilante>
apritzel: correct, so I'm assuming it's capable of the 3.3v->1.8v switch, just not sure how
<apritzel>
gnarface: in general UHS requires 1.8V, and it requires a *switchable* supply for that, per the spec
<apritzel>
tokyovigilante: one way could be re-programming aldo1, but it might also be fixed at 1.8V, and they have a separate voltage switch (controlled by PE4?)
<gnarface>
apritzel: that was a yes, right?
<tokyovigilante>
no combination of regulators I've been able to arrive at allows the card to work with that extra vcc_3v3_sd2 regulator defined *AND* referencing it in the mmc2, ie I've had to use vmmc = &CLDO4; which of course makes no sense and doesn't look good in the commit message
<tokyovigilante>
I'll try again with just 3.3v
<apritzel>
gnarface: I think on the Pine64 PortG is already 1.8V, and SDIO and eMMC are slightly different from SD, in that you can drive them just with 1.8V signalling voltage
<gnarface>
hmm
<apritzel>
tokyovigilante: but vmmc using CLDO4 looks absolutely right, this must always be 3.3V, regardless of the speed mode
<apritzel>
gnarface: that's why we can use advanced speed modes easily for all the eMMC devices: they are just hardwired to some 1.8V rail, and that's it
<tokyovigilante>
apritzel: yup have figured that out, but just unclear why I need that extra regulator defined in that case.
<apritzel>
tokyovigilante: so does it work if you omit vqmmc? And maybe have ALDO1 as always-on?
<apritzel>
I would feel best with not specifying vqmmc at all, as we simply don't know yet what it is
<apritzel>
and it looks like aldo1 has a play in here, IIUC you said SD2 doesn't work if that is not enabled?
<gnarface>
apritzel: aah, i see, thanks
<apritzel>
gnarface: so I am not even sure those Wifi modules support the advanced speed modes, the datasheet didn't mention them, and it shouldn't really matter, as the 100 MBit/s should suffice for those WiFi speeds it supports
<tokyovigilante>
sorry no it works fine with just vmmc defined, I've disabled ALDO1 now and no problems
<apritzel>
ah, that's great!
<apritzel>
tokyovigilante: what is your SD card? Is it a UHS capable one (should have this "U" style logo then)
<tokyovigilante>
UHS-I yup
<apritzel>
I wonder if those SD cards actually tolerate being run with always 1.8V on the signal lines
<apritzel>
even though this is not what the spec says
<tokyovigilante>
It's a newish Samsung, have given it a flogging, thats for sure
<gnarface>
apritzel: i'm starting to suspect something else in the kernel build or in hostapd might be the cause of the speed issues i was having
<gnarface>
my interest in the UHC stuff is more just academic now
<apritzel>
gnarface: I agree, it sounds suspicious, and I also don't think it's interface related
<apritzel>
tokyovigilante: so give me a few minutes to check if there is something else to fix in v5 ...
<tokyovigilante>
no worries, thanks
<jernej>
I just found one node out of place :)
<apritzel>
tokyovigilante: but if you would prepare a v6, without vqmmc for mmc2, and whatever aldo1 needs to be (off, or always-on)
<apritzel>
tokyovigilante: and drop vcc_3v3_sd2 completely, if it's not referenced
<apritzel>
we have that in the mailing list archives now, so it's not lost ;-)
<tokyovigilante>
apritzel: Disabling vcc_3v3_sd2 does break SD2 unfortunately
<tokyovigilante>
that's what I can't figure out
<apritzel>
what do you mean with "disabling"? It's not referenced, so it's unused and turned off anyway, right?
<apritzel>
or does that mean PE4 needs to be low?
<apritzel>
and the kernel disabling the unused regulator does exactly that?
<tokyovigilante>
by disabling I mean commenting out of the DTS sorry, I'm assuming it is the GPIO setting as it has no other relation to the mmc node in that case
<apritzel>
tokyovigilante: that's what I mean: if PE4 is mentioned nowhere, it's not configured at all
<apritzel>
but somehow it needs to be low for that to work
<tokyovigilante>
ok, is there any other way to pull the pin low without the extra node?
<apritzel>
yeah, I was thinking, there is a gpio hog, which might be a placeholder for now, but it
<apritzel>
... feels a bit odd
<apritzel>
in general there are two things at play here: what the vqmmc voltage actually is: and your card might be tolerant to it being 1.8V constantly
<apritzel>
the other thing is what the kernel *thinks* the voltage is, which influences the MMC state machine
<apritzel>
and leads to those messages about the card voltage being not supported and such
<apritzel>
so for now I would feel best if we make the kernel think it's a constant 3.3V, at best by just dropping vqmmc altogether, so we are not really lying it in the face ;-)
<apritzel>
and just adjust the regulators (and maybe GPIO?) to make it work(TM)
<tokyovigilante>
Sure, very happy to have it running at 3.3v, I did try with o-1-8-v; as well but it didn't like that either
<apritzel>
tbh, I don't really mind those kernel warnings or messages for now, as long as it works
<apritzel>
how critical is that second SD card? If everything else fails, we could remove that node completely...
<tokyovigilante>
not critical, but most downstream users will have an OS image on the first, then legally-acquired game ROMs etc on the second
<tokyovigilante>
It does work fine with v5, just weirdly so with that GPIO piggybacked on a random regulator, and presumably hard to get away with that in mainline
<apritzel>
I see, but with the current state of the DT this would be just text adventures, right? :-D
<tokyovigilante>
quite ;) although... [ 12.459458] sun50i-h616-codec 5096000.codec: ASoC: CODEC DAI Codec not registered
<tokyovigilante>
I'm relaxed about getting a patch in the books without the second slot if that's what it takes
<apritzel>
ah, so "Guitar Band" over serial, then?
<apritzel>
I feel like jernej would like that best (no mmc2) ...
<apritzel>
to verify that "PE4 must be low" theory, you could add a GPIO hog to the pio node, and force PE4 low, check Documentation/devicetree/bindings/gpio/gpio.txt
<jernej>
yeah, cd-gpio feels weird and we are under no obligation to hurry
<jernej>
so no mmc2 would be best for now
<tokyovigilante>
No drama, sounds like a decision. Will try the gpio-hog just to confirm the theory, but will do a v6 with just mmc1 for now
<gnarface>
hmm, seems that with the new 6.1 kernel build i can push it to 3.5 MB/s!
<gnarface>
it's no 6 MB/s but it's a notable improvement, now i wonder what what that clue means...
warpme has quit []
JohnDoe_71Rus has quit [Quit: KVIrc KVIrc Quasar 5.2.2, revision: 5.2.0+git-7571-8c8adf27c, build type: debug, sources date: 20160102, built on: 2024-03-24 18:03:42 UTC 5.2.0+git-7571-]
<Jookia>
apritzel: i have the nightmare feeling that i'm going to have to implement some more device tree compatibles to find the correct clocks for the de2...
<Jookia>
long term that's probably the best solution too...
apritzel has joined #linux-sunxi
<apritzel>
Jookia: well, yes, if you follow this by the (kernel) book, then this might easily become a can of worms
<apritzel>
but I wonder if we can take some shortcuts here, after all U-Boot's clock setup is comparably easy and static
<Jookia>
apritzel: i'm currently implementing the common clock framework + some sunxi stuff for the D1, so this will allow clock logic to be separated out the de2 driver for the H6 and D1
<Jookia>
separating out the clock logic from the DE logic would be good
<Jookia>
separating out the clock logic doesn't require the common clock framework of course, but just think of how nice it will be :)
ftg^ has joined #linux-sunxi
ftg has quit [Ping timeout: 480 seconds]
<apritzel>
well, but why? To make U-Boot more complicated? I don't really see the point: it's just a boot loader
electricworry has quit [Ping timeout: 480 seconds]
<apritzel>
Jookia: who will review this complex code? Even people working in the saw mills can enumerate U-Boot reviewers on one hand ...
<apritzel>
what are the clocks that we really need? Probably two or three video mod clocks? which requires one or two video PLLs? If we can just implement them, wouldn't that be enough?
<Jookia>
apritzel: i need to model a way to get the rate of the pwm parent block for the backlight, so i'm pulling in the common clock framework for that
<Jookia>
i don't know about the de2 stuff
<Jookia>
you said you don't like the clocking code for the de2 patches i sent and want it factored out
<apritzel>
well, you *sound* like you are introducing a lot of complicated code
<apritzel>
maybe it's best to show some code
<apritzel>
it's hard to see where you are heading exactly
<apritzel>
I think we probably want a mixture of hard coding and properly modelled: like the divider clocks having proper code, but every parent just fixed to what we need
<Jookia>
there's only 3 clock-related commits at the moment
<apritzel>
Jookia: thanks!
<Jookia>
the rest is spi/panel related
<Jookia>
most of it is dummied so far
<Jookia>
looks like i accidentally broke the a64 code
<apritzel>
that's alright, I just want to see the high level for now
<Jookia>
the pwm driver (i haven't begun porting yet) lets the dt specify apb0 or hosc as the parent, so i need get_rate to calculate pwm for those
<Jookia>
i have no idea how the de2 code fits in to this
<apritzel>
so for instance apb0 is fixed, we set it in the SPL, IIRC. And hosc is fixed anyway, so we just need to return some constant value for get_rate(), right?
<Jookia>
yeah
<apritzel>
or we might even not expose those parents
<Jookia>
clk_fixed_rate can do that
<apritzel>
instead just have a switch/case in the PWM clock code, that sets a variable "parent_rate" to either 24000000 or to whatever ABP0 is
<Jookia>
on this board hosc is already modeled as a fixed rate clock
<apritzel>
actually I wonder if we can just always use HOSC, for a simple backlight?
<Jookia>
i don't know
<Jookia>
maybe?
<Jookia>
i'm writing a generic pwm driver
<Jookia>
not the backlight
<apritzel>
so this is the general idea I had in mind: don't boil the ocean for those simple and fixed use cases in U-Boot
<apritzel>
I understand and appreciate your generic approach, since you are coming from the kernel
<Jookia>
i'm not sure how else to do it here since the device tree specifies these things
<apritzel>
and it's absolutely the right thing to do there
<Jookia>
i guess i could just have a u-boot specific dt
<Jookia>
and drop kernel/mainline compatibility
<apritzel>
the PWM driver references the clocks using their (made-up) DT number, and the existing clock code calls the sunxi clock driver with that number
<apritzel>
but instead of modelling the whole complex clock tree, we stop it here and see if we can serve the limited use cases in one function
<Jookia>
most the tree needs to be modeled anyway for the de2 code
<apritzel>
for instance by avoiding calling back into U-Boot's CCF for parents, if all we need to know is the parent clock rate, which is mostly fixed
<Jookia>
if it's going to be changed
<apritzel>
I am not so sure of that, actually, I was hoping it's kind of similar
<apritzel>
for Linux we need that to coexist with the audio clocks, and maybe another video output device
<Jookia>
the de2 code requires setting multiple clocks and parents to form a final value
<Jookia>
the clocks vary chip to chip
<Jookia>
and cannot be set statically due to the pixel clock being runtime
<apritzel>
yes, and we have chip by chip clock implementations anyway, but we don't need the clock tree down to the root, and with ability to select arbitrary parents
<Jookia>
hmm. i'm not sure then
<apritzel>
so if DE2 requests setting its clock, we just program the mod clocks, and use a fixed PLL_VIDEO0 as a parent
<Jookia>
we can't use a fixed PLL_VIDEO0 as parent
<Jookia>
it varies chip to chip
<Jookia>
or do you mean per-chip set_video_clock() function?
<apritzel>
the clock implementations are per-chip anyway
<Jookia>
kind of
<Jookia>
the d1 and h6 share the same clock code
<apritzel>
we can let them share some core PLL setter code, but the actual entry point is in the per-SoC clock driver
<Jookia>
hmm
<Jookia>
i'm not sure then, i'll abandon trying to do clocking/pwm for now and just use gpio-backlight for u-boot i think
<apritzel>
I mean the goal for U-Boot clock code should be to be as simple as possible
<apritzel>
I think PWM is actually a good and probably easy example
<apritzel>
let me have a look at this ...
<Jookia>
i'm not convinced it's worth the effort for my use case
<Jookia>
the only reason i wanted to implement it was for kernel dt compatibility that's all
<apritzel>
and that's a given, of course
<apritzel>
there is only on DT
<Jookia>
i'm using two dts in my setup
<Jookia>
u-boot and kernel
<Jookia>
plus the pwm driver i'm using isn't merged mainline so it can't be used in u-boot yet
<apritzel>
U-Boot now *directly* includes the Linux DTs
<Jookia>
i mean yeah but for my use case i can just use a per-uboot dt
<Jookia>
once the kernel side figures out the pwm story i'll take another look
<Jookia>
otherwise i'm chasing a moving target
<apritzel>
this is for the T113-s3?
<Jookia>
yes
<apritzel>
I am pretty sure the DT side of the D1 PWM driver will not change
<apritzel>
and even if, it should be simple to adjust in any driver
<Jookia>
there's really no point writing it at this exact moment
<apritzel>
so you ask U-Boot's clock framework to enable the bus clock: that should already work
<Jookia>
i don't want to make more work for myself or maintainers given there's already a large patch backlog
<apritzel>
sorry, I don't understand: weren't you proposing porting parts of the Linux CCF to U-Boot?
<Jookia>
no, the ccf is already in u-boot
<Jookia>
its used by other clock drivers
<apritzel>
but we only have gate clocks implemented atm for sunxi
<apritzel>
so we would need more, and this is where it gets hairy, which I want to avoid
<Jookia>
yeah so i was going to implement more- all it requires is adding some register getter and setters
<Jookia>
with just some new getters/setters for N and NM sunxi register fields
<apritzel>
but the PWM clock is your case?
<apritzel>
as you said you don't care about DE2 clocks modelled right now?
<Jookia>
well i was going to start with the PWM clocks and use this to model DE2 clocking, but i don't know. i was hoping that i could set up the clocks then implement some basic code that reclocks parents
<Jookia>
either that or just being able to call clock_set_rate in de2 code
<Jookia>
instead of setting registers
<Jookia>
without the parent reclocking
<apritzel>
my idea was to basically move the existing (basic) clock register setting code into the clock driver instead
<Jookia>
the problem is that the de2 code is extremely leaky clock-wise and calculates N/M/X factors then sets each register for various clocks and peripherals based on this
<apritzel>
but without going crazy about all the possibly parents, when for instance PLL_VIDOE0 is all we ever need
<Jookia>
lcdc.c and sunxi_dw_hdmi.c have duplicate code for calculating clock factors
<Jookia>
that is now being special cased in 3 different setups
<Jookia>
it started as code assuming it supports an N*M/P clock, but the H6/H616/D1 only support a N*M clock