11:50 <Jookia> I think fractional clocking is broken for the D1, at least for I2S. It won't change the parent clock to an acceptable rate, but if I tell it it's okay to do that it will arrive at the correct clock on paper but in reality it's divided down by something

11:53 <apritzel> Jookia: "fractional clocking is broken for the D1": in hardware, or in the Linux CCU driver?

11:53 <Jookia> The linux driver I think

11:54 <Jookia> I disabled fractional clocking it seems like re-parenting is causing the issue

12:00 <Jookia> Output rate is divided by 1.6

12:12 <Jookia> AUDIO0 and I2S2 clock registers are set correctly to make a 24576000 clock. for my chosen rate and channels it divides by 2 correctly in the I2S clock divider. Hmm

12:50 <Jookia> Yeah I just can't get fractional clocking working, it seems to just ignore SDM tables and setting CLK_SET_RATE_PARENT just makes the output weirder

12:51 <Jookia> The fractions included in the ccu aren't even applied

12:52 <Jookia> If anyone can figure out how to enable fractional clocking for audio0, please tell me

12:55 <Jookia> The two issues I see is clk_set_rate for the i2s2 bus does not try to set audio0 or anything, only pick the closest parent, there is no way to set audio0 at all, and trying to propagate changes up sets it but it never chooses SDM frequencies and puts out odd frequencies on my scope

13:02 <Jookia> Unless there's like a hidden 8 / 5 divisor somewhere

13:23 <apritzel> Jookia: that's on the D1 only? Do you know if that affects other SoCs as well?

13:23 <Jookia> i'm not sure, this is the T113

13:38 <Jookia> i'm really confused about what conditions cause a rate to be set and why, and why i got a weird clock despite the registers looking fine

13:41 <Jookia> I used ftrace to try and figure out if any ccu_sdm code was running and it wasn't

13:43 <Jookia> I added a rate of 98304000 and calling clk_set_rate with it just seems to do nothing except try to set the i2s divider

13:44 <Jookia> It's very confusing, so I might be misinterpreting something important. I'm just shook that somehow I managed to get a clock that is 1.6x slower than my target one

13:45 <Jookia> I read the registers manually to calculate them and they seemed correct

13:47 <apritzel> could it be that Linux uses a different rate for the SDM table lookup? Something already doubled or halved or so?

13:48 <Jookia> Not sure, I'll check that. I kind of have a suspicion that the datasheet may be lying and the clock it's trying to get (245.76MHz) is too high for the audio0 PLL

13:49 <apritzel> Jookia: can you put some debug in ccu_sdm_helper_has_rate(), to see if that it even called?

13:49 <Jookia> Yeah, shall do when I get to it next. I'll start debugging the clock code a bit more

13:50 <Jookia> I'm just not entirely sure if this is a Linux issue or hardware issue, as the registers all seemed to be set correctly to get the clock Linux wanted, the clock on the output was just wrong

13:52 <Jookia> I am somewhat hoping if I can figure this out I can implement calculating SDM parameters at runtime

13:55 <apritzel> do you have any idea of the algorithm? I tried to research that the other day, and that didn't seem easy at all

16:18 <Jookia> apritzel: yes, it's fairly simple. at least if i can test it :)

23:24 <macromorgan> anyone have a datasheet handy for the AXP2202? Or even better some BSP sources?

23:58 <apritzel> macromorgan: I couldn't find anything back a few weeks ago. It's in the Teclast P85T tablet, judging by the BSP debug output, check https://linux-sunxi.org/Teclast_P85T#BSP_Boot_log

23:58 <apritzel> and then there is this: https://github.com/DeciHD/allwinner_docs/tree/main/pmu_xpowers

23:59 <apritzel> there is a commit that mentions two PMICs for the A523. The AXP323 looks very close to the already supported AXP313