<minute>
narmstrong: it is the same/similar problem as before, ti_sn65dsi86 defers because of_find_mipi_dsi_host_by_node() always fails
<narmstrong>
minute: yes I’m afraid it’s not solved :-/
<narmstrong>
The problem is the components stuff which makes everything bad
<narmstrong>
on the meson dw mipi dsi driver, moving all the code from bind to probe, but keeping the component_add/del and empty bind function would probably work
<minute>
narmstrong: ah, will try
Danct12 has quit [Quit: How would you be so reckless with someone's heart!?]
<minute>
narmstrong: component_add at the end of probe i presume?
<narmstrong>
minute: yep otherwise it won’t bind the master driver
<minute>
ok
<narmstrong>
minute: you can drop the unbind op but keep the bind op but empty
<minute>
ok
Danct12 has joined #linux-amlogic
<minute>
interesting, this now oopses in of_find_mipi_dsi_host_by_node+0x54/0xa4
<minute>
(null pointer dereference)
leohoo_sdu[m] has quit [K-Lined]
<f_>
I have no idea how or why, but ...
<f_>
The WeTek Hub and NanoPi K2 ACS work..
<f_>
Work, as in, linux boots.
<f_>
Hmm
<f_>
The P201 ACS doesn't work however.
<f_>
* This board have not been autorized or product keys are not valid. *
<f_>
* Please contact with Hardkernel or your distributor *
<f_>
Heh
<f_>
Does HardKernel implement DRM now?
<f_>
I was wondering why the timings seemed different from the ones in my eMMC dump
<minute>
narmstrong: ah, i think the bridge probes now
<narmstrong>
f_: yes do not use the odroid c2 fip, they added a check for their HW
<narmstrong>
minute: Nice!
<f_>
narmstrong: Heh. That was for testing purposes. I wasn't actually going to use it.
<f_>
But this looks like BL2..
jacobk has quit [Ping timeout: 240 seconds]
<f_>
Pretty funny though.
<minute>
narmstrong: the display pipeline is not starting though... some puzzle piece is missing
<minute>
narmstrong: so no /dev/dri/card* is created for the display/vpu (only for gpu)
<narmstrong>
minute: hmm it would mean the bridge isn’t properly detected, is there an error printed somehow ?
<minute>
narmstrong: no, strangely no output from vpu this time except[ 3.869938] meson-drm ff900000.vpu: Queued 1 outputs on vpu
<narmstrong>
Hmm this should be 2, are you sure you kept the component_add ?
<narmstrong>
Or you disabled HDMI ?
<minute>
narmstrong: disabled hdmi yep
<minute>
narmstrong: meson_encoder_dsi_init() is not called now
<minute>
narmstrong: ah i'm silly
<minute>
narmstrong: i did a return before component_add, so it's not reached
<narmstrong>
Ok this explains everything, if you get a -22 probe error on the drm driver, you could you try to add « if (!mipi_dsi->dsi_device) return -EPROBE_DEFER; » in the dsi bind function so it defers until the dsi bridge has attached to the dsi host
<minute>
yeah, i get an oops again now
<minute>
in (of_find_mipi_dsi_host_by_node+0x54/0xa4)
<narmstrong>
Weird, can you share the call stack ?
<minute>
narmstrong: it's possible that your DEFER suggestion could fix it
<minute>
narmstrong: i think it is because of the removed unbind
<minute>
narmstrong: IIRC the oops happens if mipi_dsi->dmd is dangling
<narmstrong>
minute: you should not remove dmd in unbind anymore so the dsi host remains
<minute>
narmstrong: i don't, i commented out unbind as you suggested
<narmstrong>
Wait, perhaps the component unbind frees all the devm allocated stuff
<minute>
narmstrong: yes
<minute>
narmstrong: or i think a DEFER does
<minute>
but not sure... in any case when i was debugging in the last days, the problem was that you can't keep the host around during a DEFER because something gets deallocated but still referenced
<narmstrong>
Yep I confirm it does in component_unbind :-/
<minute>
but i didn't have enough experience to fix this
jacobk has joined #linux-amlogic
<minute>
narmstrong: is there a workaround?
<narmstrong>
Yeah stop using components… I maybe have an idea
<narmstrong>
minute: if screen flicked it means something is on the dsi lanes, which is a good news
<minute>
narmstrong: thanks!
<narmstrong>
I’m not sure at all about the mode timings settings, I have only 2 screens to test and I never managed to get them working with the timings used for rockchip :-/
<minute>
oh ok
<minute>
narmstrong: btw my version says max 250 instead of 255 like in the file you linked... this was updated later?
<narmstrong>
Probably, updating the max won’t help achieving 972 anyway
<minute>
oh, color bars test works (generated by sn65dsi86)
<minute>
narmstrong: ok
<minute>
ah, with 120 min and setting 972mhz in dts, i get > gp0_pll 2 2 1 972000000
<minute>
but if i disable test pattern in sn65dsi86, still flicker on the display. so maybe something with the actual mipi frames
<narmstrong>
Ok so the dsi bit clock is right so it can generate the right dp link, so yeah the pixel timings generation is completely off
<narmstrong>
I think you can enable test color bars from the dw mipi dsi driver
<narmstrong>
But I never understood how it worked…
<narmstrong>
It’s vpg in debugfs
<minute>
ah, pixel timing is unfinished?
<narmstrong>
It is but based on the amlogic vendor code, but their base timings are completely different from other vendors
<minute>
oh strange
<minute>
hmm there's a lot of "TODO dw drv improvements" in dw-mipi-dsi.c
<narmstrong>
Yeah well you know they did a complete implementation of dsi for no reason, typical vendor code
<narmstrong>
I think the dsi part is ok
<narmstrong>
You could check if you have the correct frame rate with modetest -s -v
<narmstrong>
Anyway, it’s already a good result! Good night !
<minute>
thanks so far!! good night
<minute>
(getting 70.04hz, i think that's about right)