18:27 <minute> investigating 8822cs issues, i'm wondering: why, in amlogic vendor linux, they use a PWM on aml_wifi?

18:27 <minute> ah, it's used to make a 32khz clock

18:30 <minute> the bpi vendor dts says: pwms = <&pwm_ef MESON_PWM_0 30541 0>; and: duty_cycle = <15270>;

18:30 <minute> but mainline says: pwms = <&pwm_ef 0 30518 0>; /* PWM_E at 32.768KHz */

18:30 <minute> why is there this small difference?

18:31 <minute> as this is likely the RTC clock used for wifi power-save, could this be the reason why powersave is semi broken on rtw88_8822cs?

19:23 <xdarklight> minute: rtw88's SDIO code is fairly simple and does not support card waking up the host. also Jernej and myself had our focus on making it work, I don't think that we spent much/any time testing powersave

19:23 <minute> xdarklight: ah, then i misunderstood this feature

19:24 <minute> xdarklight: currently, rtw8822cs's connection often gets "stuck", and disabling power saving on the interface helps somewhat

19:25 <minute> this coincides with > rtw_8822cs mmc2:0001:1: firmware failed to leave lps state

19:27 <xdarklight> that message may require support from Ping-Ke, he has been investigating this on PCIe chips: https://bugzilla.kernel.org/show_bug.cgi?id=215496

19:28 <xdarklight> jbrunet: DT backwards compatibility is tricky, indeed. I don't see it as must-have - I was just curios

19:29 <xdarklight> jbrunet: I put "test dropping CLK_SET_RATE_PARENT on some video clocks" on my TODO-list. it's an interesting thought and I haven't tried it yet. unfortunately it will take a while until I'm able to try it out

19:30 <minute> xdarklight: also, is 20-30mbit RX the max that should be possible on rtw8822cs on mesong12b?

19:33 <xdarklight> minute: I assume not, there's also some very fresh patches for USB that may help us as well (when adapting the SDIO code accordingly): https://patchwork.kernel.org/project/linux-wireless/patch/b4c0d54c-6755-4b0f-9dd7-f9196fd74b68@gmail.com/ (especially the second sentence in the patch description is interesting as it matches the speeds that we're seeing)

19:33 <minute> ohh

19:35 <xdarklight> it's also possible that Bitterblue found a more (CPU) efficient way of reading data with RX aggregation (compared to the basic approach that we have in the SDIO driver)

19:36 <xdarklight> (SDIO code memcpy's the left-over data for the next packet(s) while Bitterblue re-uses the data buffer and just creates new skb wrappers)

19:36 <minute> mhmm

19:42 <minute> yeah, theoretically we have 50MHz x 4bit = 200mbit max bandwidth, right?

19:47 <xdarklight> that's the theoretical maximum bus speed. however we also have to discount for performance loss since DMA is not working with the SDIO controller and we need to memcpy from/to a bounce buffer

19:48 <minute> i wonder how much bandwidth is lost there

19:55 <jbrunet> xdarklight: no worries. when you try, you can start by cutting propagation after your source PLLs (hdmi, vid ? gp maybe) That way should not have the TDMS, DAC and friends tripping on each other

19:59 <jbrunet> Unfortunately that's the kind of choice you have make early on considering it may impact the interface you need for proper control. Again difficult to change later on with a stable DT ABI if you realize you made a mistake.

21:09 <minute> now giving hdmi audio a try on g12b

21:27 <minute> oh, got it to work

22:00 <minute> hmmm, having audio dropouts on hdmi unfortunately