08:18 <wens> that's right

08:18 <wens> the bind() function is only run when all the components have appeared and the component master does a bind_all call

08:19 <wens> (off the top of my head, I might be wrong)

11:28 <junari> wens: Does npu require support from mesa to work?

11:28 <junari> apritzel: are you going to send patches for cpu ccu to upstream?

11:30 <junari> I had a cleaned-up version somewhere, but with all my recent moves, it would take a lot of effort to find it

11:31 <junari> walnutpi npu seems to be working, which is not the case with x96qproplus

12:18 <apritzel> junari: yes, I am closing in on the CPU CCU code, the patches are in good shape - only problem is it hangs the system - I guess either something accidentally turned off, or the PLLs crashing or something

12:19 <apritzel> the symptom is the serial output stopping mid-sentence when I have debug messages in

12:21 <wens> junari: yes you need the teflon driver enabled

14:54 <junari> apritzel: I encountered this problem, but I can't remember what caused it

15:04 <junari> tokyovigilante: can you tell me which patches are currently missing in 6.17 for LCD and HDMI to work in h700?

15:05 <junari> I didn't really keep track of their progress

15:17 <junari> apritzel: did you forget about the need to forcefully enable polyphase mode on pmic?

15:17 <junari> https://gitlab.manjaro.org/iuncuim/linux/-/blob/master/1204-regulator-axp20x-force-polyphase-setup-for-axp323.patch?ref_type=heads

15:22 <apritzel> junari: so you reckon the power supply is insufficient for those high frequencies? I can try this ..

15:25 <junari> apritzel: If you don't have anything like that, and your driver doesn't have any other problems, then it's definitely necessary

15:26 <junari> I spent a lot of time trying to debug it

15:29 <junari> I noticed this when the freezes occurred during a cold start, but did not occur after soft rebooting from the vendor system

15:37 <apritzel> good point, thanks junari, will try it later

16:32 <electricworry> wens: Thanks!

16:57 <electricworry> Is anyone able to explain the sunxi pipeline for graphics, please? display-engine has "allwinner,pipelines = <&mixer0>. Said mixer (DE33) has "mixer0_out_tcon_top_mixer0", then off to HDMI, etc. Is this kind of like a muxer?

16:59 <apritzel> electricworry: isn't there some ASCII art in some of the drivers? I found this quite enlightening ...

17:00 <apritzel> (though I needed to draw my own more elaborate version, on a piece of paper, maybe I can find that later)

17:01 <apritzel> electricworry: also there was a least some talk about this, I think at some ELCE or FOSDEM?

17:04 <electricworry> apritzel, yes there's some ascii art in the dtbindings. The reason I ask is, am I visualising a switch where in one state the HDMI IP will be connected to the right wires (and EDID will be readable over DDC, etc.) and in another state it will be switched somewhere else (i.e. EDID I2C queries will come back all zeroes)?

17:07 <apritzel> IIUC EDID I2C is somewhat separate from the video signals, so is not handled by the mixer mux?

17:08 <apritzel> (maybe the I2C pins are always routed to the HDMI port, even?)

17:09 <electricworry> Could be. I'm just having trouble understanding then what the mixer is for then. :)

17:09 <electricworry> I'll try and find that talk.

17:22 <apritzel> electricworry: IIUC the mixer just handles the video signals, not the I2C pins

17:23 <electricworry> Thanks. It might make more sense in time :)

17:23 <apritzel> (since LVDS or MIPI DSI don't have or need this kind of communication)

21:56 <apritzel> junari: many thanks for the tip, I just typed "pmic dev pmic@36; pmic write 0x22 2" in U-Boot instead, and that seems to indeed fix my issues!

21:57 <apritzel> I mean at least enough to be able to send out the driver, now of course we need to find a good upstream solution for that problem

22:23 <apritzel> wens: I have now this: $ cat /sys/devices/soc0/machine => Allwinner A527 M000000H purely with a TF-A patch, for all 64-bit SoCs (plus a kernel bug fix)