15:47 <f_> Getting closer!!! https://bin.vitali64.duckdns.org/645d0e16

15:48 <f_> Might add a trailing newline after initialising the console, for formatting purposes.

15:53 <f_> (TF-A experiments!)

17:33 <narmstrong> Nice

18:29 <minute> narmstrong: how to best reach you about issues with the a311d mipi-dsi patch?

18:30 <narmstrong> minute: hi here, note I’m about to post a new version of the patchset with a much cleaner clock management

18:32 <narmstrong> minute: do you have any probe errors on dmesg ?

18:34 <narmstrong> minute: i never tested a bridge chain with a bridge but it should work like with a panel from the dsi controller pov

18:34 <minute> narmstrong: hi! so my issue is integrating it with the sn65dsi86 bridge that we have on the motherboard

18:36 <narmstrong> minute: if you can share the boot dmesg it would help ! The dt you shared on twitter looks fine so far

18:36 <minute> narmstrong: i've put in a million printks. from what i have understood (maybe wrong): sn65dsi86 wants to attach to the dsi host, but at that point the host is gone again, because it is removed in meson_dw_mipi_dsi_bind

18:37 <minute> narmstrong: the mipi_dsi->dsi_device that is referenced there is supposed to be set by meson_dw_mipi_dsi_host_attach, right? which is called when a panel or bridge attaches to this host?

18:39 <minute> narmstrong: but afaik it doesn't happen because meson_dw_mipi_dsi_bind is called before sn65dsi86 can attach (is finished probing). so sn65dsi86 also defers, and there is a loop a few times until it gives up

18:40 <minute> i can restore the code to how it was and make a dmesg

18:42 <narmstrong> Hmm yes attach should be called when the bridge tries to attach to the host, then in the next call to bind the bridge should be attached to the host and it should go well

18:43 <narmstrong> If bind is called before the bridge attaches the bind will defer

18:43 <narmstrong> Why does the bridge defers ? It shouldn’t

18:45 <minute> ok, let me reset the code to how it was and make a fresh log

18:45 <narmstrong> Dsi probe is tricky, the way I did it may not work with a bridge

18:45 <narmstrong> I know some probe issue we’re fixed on rockchip and rpi and I should probably have a closer look

18:48 <minute> hmm > [ 14.304811] auxiliary ti_sn65dsi86.bridge.0: deferred probe pending

18:51 <minute> ah, sorry

18:53 <minute> (forgot to reapply the patchset after cleanup)

18:53 <narmstrong> Hmm looking at the bridge code, it’s the same as a panel so it must be something missing in the auxiliary bridge probe

18:54 <minute> narmstrong: http://dump.mntmn.com/dmesg-a311d-1.txt

18:56 <narmstrong> Is the panel probing correctly ?

18:57 <minute> i think so, but can look into it

18:57 <minute> when i had a lot of print statements, i could see that of_find_mipi_dsi_host_by_node in ti_sn_attach_host fails, which then returns -EPROBE_DEFER

18:58 <narmstrong> Ok so indeed of_find_mipi_dsi_host_by_node() will always fail because no device is attached

18:58 <minute> yes!

18:58 <narmstrong> I need to have a look how it should be fixed

18:58 <minute> awesome, thanks

18:59 <minute> narmstrong: then i will put this project aside until i hear from you?

19:01 <narmstrong> minute: yep, but it seems to be a simple fix, rockchip and STM32 moved out of components to fix this

19:01 <narmstrong> minute: i planned to look at this tomorrow anyway

19:02 <narmstrong> Thx for your report!

19:05 <minute> narmstrong: great, looking very much forward!

23:52 <lvrp16> narmstrong: does the VPU support any refresh rates over 60Hz?

23:52 <lvrp16> Have people with 1080P and QHD 144Hz displays which should be supported reporting no display. I'm wondering if our res restriction should include framerate restriction as well so it doesn't pick a mode beyond what the VPU can support