<jernej>
Probably I could re-write it to be more clear, but anyway
<KotCzarny>
and probably move out of private page
<jernej>
that too
<wens>
I did the calculations by hand once, and the values they use are slightly off, though it it doesn't show audibly
<wens>
but based the manuals it seems only the audio PLL supports SDM
<wens>
so I'm not sure if we gain anything by generalizing the SDM clock code to support arbitrary clock rates
warpme_ has quit [Quit: warpme_]
<jernej>
which SoC? looking at H6 PLL registers, it seems that most have SDM enable bit
<jernej>
but yes, it's probably useful only for audio
<jernej>
btw, I checked A64 pattern for 24576000Hz and it's off only for 810Hz
<jernej>
I don't think you can get any closer
<wens>
wonder if it's possible to get closer by using a higher rate for pll-base, and then dividing it down
<wens>
anyway, for the H5 and all before, only PLL AUDIO has a note saying "if SDM is enabled, only lowest 4 bits of N work"
<wens>
that signals something special about the audio PLL, or at least is a big red flag
<wens>
H6 pll clocks seem to have a slightly different structure, and there are three extra control bits: FRAC_IN, FRAC_EN, DITHER_EN
<jernej>
ok, I'll try to fit H6 audio SDM in current framework
<jernej>
but then I'll have to rework pll-audio to have adjustable divider
<wens>
you can just rework the "fixed" dividers to whatever you need. I already did this for the other SoCs
<jernej>
hm... I checked clk driver of H3, A64 and R40 and all have pll-audio with fixed divider
<jernej>
which one has adjustable?
return0e has joined #linux-sunxi
<wens>
no, you just adjust the fixed factors so they match what you want for the base pll, i.e. D2=2
<wens>
jernej: so for the h3 (and all the others), pll-audio(-1x) = pll-audio-4x = pll-audio-base, and pll-audio-2x = pll-audio-base / 2, while pll-audio-8x = pll-audio-base * 2
<jernej>
not sure how to do that, H6 audio PLL SD patterns in BSP clk driver are only for 541900800 and 589824000 base rate, e.g. 24x higher
<wens>
that's probably because N needs to be above 11? so they divide it down using P and output div?
<jernej>
yes
<wens>
doesn't that make the 2x and 4x outputs unusable?
<jernej>
probably
<jernej>
if I make pll-audio with adjustable P and fixed post-divider (D2 = 2), then dividers will be same as in BSP
<wens>
doesn't seem you need adjustable P either?
<wens>
the BSP has four sets of values, either 22.5792/24.576, or 90.3168/98.304
<wens>
and within the two sets, only N and the SDM value change
<jernej>
sure, but P is currently fixed to 8 in mainline
<jernej>
but BSP sets it either to 3 or 12
<jernej>
so, why not make pll-audio flexible with adjustable P?
<wens>
you could just change it to 12, and only support 22.5792/24.576
<wens>
making it adjustable is possible as well, I just don't see the benefit
<wens>
maybe useful for hi-res audio?
<jernej>
probably, yes
<jernej>
so it wouldn't need to be changed once hi-res audio is supported
<jernej>
there is ongoing effort to improve HDMI audio support
<wens>
ok. I'm just not currently seeing how it would be exercised
<wens>
speaking of HDMI audio, I think there was a recent patch that programs the audio sample rate properly in the HDMI block.
<jernej>
I know, I reviewed it
<wens>
does that help with the auto cts part that had issues?
<jernej>
maybe you're right and we don't need support for higher rates yet, only use I could find it for AHUB, which we don't support
<wens>
AHUB is interesting. previous chips had something like it but it wasn't documented.
<wens>
We'd have to switch to DPCM to support it though
<wens>
it looks more or less like a digital stream mixer?
<jernej>
I don't know audio infrastructure so well...
<wens>
I meant the hardware. AHUB looks like a mixer
<avph>
So on my A20 in FEL mode my SPI flash is not detected with sunxi-fel, but reading and writing seems fine. Booting does not work from SPI however.
<avph>
any clues?
marekbelisko has joined #linux-sunxi
<hellsenberg>
avph: which board is it?
<avph>
bananapi with a SPI flash hooked up
<hellsenberg>
can the OS "see" the flash chip? (e.g. flashrom)
<hellsenberg>
i wonder if the on-chip bootloader could have problems with the specific SPI flash chip model for some reason
<avph>
yes
gaston1980 has quit [Quit: Konversation terminated!]
<hellsenberg>
how's the flash chip wired up? when you say "reading and writing seems fine", do you mean using flashrom or sunxi-fel?
<avph>
so both reading and writing seems fine with both flashrom and sunxi-fel, but booting from it does not work (falls back to FEL)
<hellsenberg>
i recall something about sunxi checking some magic value to determine it can boot from there
<avph>
hmm so I was wrong about sunxi-fel being able to do something useful... flashrom+spidev does work fine however
<hellsenberg>
then fel mode probably doesn't know how to use the chip i guess, kind of like intel hardware has the ME VSCC table
<hellsenberg>
*i guess*
<avph>
reading is quite universal on SPI flash, so I think it's weird that the BROM does not use it...
<smaeul>
avph: which pins / which SPI controller do you have it hooked up to? the BROM only works with a specific pin/CS combo
<avph>
smaeul: SPI0,CS0 I think
<smaeul>
– Support system boot from NAND Flash, SPI Nor Flash (SPI0), SD Card/TF card (SDC0/2)
<smaeul>
ok so that's right
megi has joined #linux-sunxi
<smaeul>
and it's the pinmux on port C: PC0-PC2 and PC23