<mntmn>
hmm. upgraded from 5.7 to 5.10-rc5. esdhci controller is broken for me now on imx8mq (for sd cards). mmc0: Timeout waiting for hardware interrupt
<mntmn>
already reverted sdhci-esdhc-imx.c and it's not the culprit
<mntmn>
some interrupt, power or clocktree changes maybe?
<mntmn>
or even dma...
<mntmn>
ah no, it's the internal emmc that's not working
<lynxeye>
mntmn: assigned-clocks for the esdhc controller moved from the SoC dtsi to the board dts files.
<mntmn>
lynxeye: thanks, that's a very good hint!
<mntmn>
i should re-compare the evk dts with my dts
<mntmn>
currently trying to get the finally upstreamed dcss to work...
<lynxeye>
mntmn: are you using DCSS with the HDP or the MIPI DSI bridge?
<mntmn>
lynxeye: mainly with MIPI DSI
<mntmn>
lynxeye: but i've tried both in the past
<mntmn>
lynxeye: i made an experimental modification a while ago that would let me switch between hdmi and dsi with a module parameter, it mostly worked. but now i'm trying to use the vanilla dcss code in the kernel.
<mntmn>
ugh what > [ 4.149430] [drm:ti_sn_bridge_attach] *ERROR* Fix bridge driver to make connector optional!
<lynxeye>
Yep, another shiny new kernel feature, where you pass in the connector from the start of the pipeline instead of each bridge needing to look if there is another bridge behind or it needs to construct the connector
<marex>
lynxeye: did you recently test qtwebengine >= 5.14 with etnaviv ?
<marex>
I noticed some weird rendering issues start with 5.14, so I wonder whether you saw that already
<lynxeye>
marex: nope, I don't have any system running up-to-date Qt at the moment. And most of our web needs shifted to WPE.
<austriancoder>
marex: can you provide an api trace of the problem?
<marex>
austriancoder: yeah, I was trying to record that two days ago already, but then apitrace couldn't record the qtwebengine, so I still need to look into it
<austriancoder>
marex: ok
<marex>
I think it was failing on missing eglQueryString implementation or something
<mntmn>
lynxeye: ok so the same bridge chain works fine with lcdif/mxsfb, but not with dcss.
<mntmn>
just lcdif is unusable together with PCIe... (crazy image distortion whenever there's SSD traffic)
<marex>
mntmn: need more DRAM bandwidth ?
<lynxeye>
mntmn: yea, lcdif doesn't have a prefetch buffer like the DCSS, so it totally messes up when its bus request don't get serviced in time due to high bus load.
<mntmn>
marex: no, it works with DCSS
<mntmn>
lynxeye: sounds reasonable... is there any priority tuning knob for this? (i guess not)
<lynxeye>
dcss has a lot more slack in the bus latency requirements due to the large prefetch SRAM
<lynxeye>
I remember there being *some* knobs in the NOC interface for the lcdif, but the commits in downstream didn't look like they were able to solve it fully
<marex>
lynxeye: cant you use ACP somehow for the mxsfb ?
<mntmn>
hmm
<lynxeye>
no such thing as ACP on i.MX8
<mntmn>
if that were solved, i could use 2 displays + nvme, but it sounds not possible.
<lynxeye>
also wouldn't help as the elcdif just requests too late, as the requests are coupled to the FIFO levels
<mntmn>
anyway, back to understanding why dcss -> nwl -> sn65dsi86 -> edp doesn't work, but the same chain with lcdif does
<mntmn>
nwl-dsi that is
<lynxeye>
marex: while you are around: do you have any idea why we need to fake the double PHY refclk for the i.MX8MM MIPI DSI to work?
<mntmn>
hmm yeah dcss does > ret = drm_bridge_attach(encoder, bridge, NULL, DRM_BRIDGE_ATTACH_NO_CONNECTOR);
<mntmn>
i wonder if lcdif could do 8 or 16 bit or something to reduce bandwidth :3
<mntmn>
hmm i patched dcss to use the same way mxsfb does the attach, and the whole chain links up, but sigh > [ 4.352800] [CRTC:37:crtc-0] vblank wait timed out
<marex>
lynxeye: double phy refclock ?
<lynxeye>
marex: We set the PHY refclk to 27MHz via assigned-clocks, but specify the refclk as 54MHz with the "samsung,pll-clock-frequency" property.
<lynxeye>
Only this combination works. If it were the other way around, I would say there's just a /2 divider in the clock path somewhere, but this way around makes no sense to me.
<marex>
lynxeye: maybe there is one in the samsung hardware ?
<lynxeye>
marex: The register descriptions match up with with the code and that is calculating a predivider for the PLL for a rate of 54MHz...
<mntmn>
hmm why would this freeze the system > dcss_update(0, LINE0_IRQ | LINE1_IRQ, dtg->base_reg + DCSS_DTG_INT_MASK);