Hi, Am Mittwoch, dem 11.05.2022 um 16:58 +0200 schrieb Marek Szyprowski: > Hi Dave, > > On 05.04.2022 13:43, Dave Stevenson wrote: > > On Fri, 18 Mar 2022 at 12:25, Dave Stevenson > > <dave.stevenson@xxxxxxxxxxxxxxx> wrote: > > > On Fri, 4 Mar 2022 at 15:18, Dave Stevenson > > > <dave.stevenson@xxxxxxxxxxxxxxx> wrote: > > > > Hi All > > > A gentle ping on this series. Any comments on the approach? > > > Thanks. > > I realise the merge window has just closed and therefore folks have > > been busy, but no responses on this after a month? > > > > Do I give up and submit a patch to document that DSI is broken and no one cares? > > Thanks for pointing this patchset in the 'drm: bridge: Add Samsung MIPI > DSIM bridge' thread, otherwise I would miss it since I'm not involved > much in the DRM development. > > This resolves most of the issues in the Exynos DSI and its recent > conversion to the drm bridge framework. I've added the needed > prepare_upstream_first flags to the panels and everything works fine > without the bridge chain order hacks. > > Feel free to add: > > Tested-by: Marek Szyprowski <m.szyprowski@xxxxxxxxxxx> > > > The only remaining thing to resolve is the moment of enabling DSI host. > The proper sequence is: > > 1. host power on, 2. device power on, 3. host init, 4. device init, 5. > video enable. > > #1 is done in dsi's pre_enable, #2 is done in panel's prepare. #3 was so > far done in the first host transfer call, which usually happens in > panel's prepare, then the #4 happens. Then video enable is done in the > enable callbacks. > > Jagan wants to move it to the dsi host pre_enable() to let it work with > DSI bridges controlled over different interfaces > (https://lore.kernel.org/all/20220504114021.33265-6-jagan@xxxxxxxxxxxxxxxxxxxx/ > ). This however fails on Exynos with DSI panels, because when dsi's > pre_enable is called, the dsi device is not yet powered. I've discussed > this with Andrzej Hajda and we came to the conclusion that this can be > resolved by adding the init() callback to the struct mipi_dsi_host_ops. > Then DSI client (next bridge or panel) would call it after powering self > on, but before sending any DSI commands in its pre_enable/prepare functions. > > I've prepared a prototype of such solution. This approach finally > resolved all the initialization issues! The bridge chain finally matches > the hardware, no hack are needed, and everything is controlled by the > DRM core. This prototype also includes the Jagan's patches, which add > IMX support to Samsung DSIM. If one is interested, here is my git repo > with all the PoC patches: > > https://github.com/mszyprow/linux/tree/v5.18-next-20220511-dsi-rework While this needs rework on the bridge chip side, I fear that we need something like that to allow the bridge to control the sequencing of the DSI host init. While most bridges that aren't controlled via the DSI channel might be fine with just initializing the host right before a video signal is driven, there are some that need a different sequencing. The chip I'm currently looking at is a TC368767, where the datasheet states that the DSI lanes must be in LP-11 before the reset is released. While the datasheet doesn't specify what happens if that sequence is violated, Marek Vasut found that the chip enters a test mode if the lanes are not in LP-11 at that point and I can confirm this observation. Now with the TC358767 being a DSI to (e)DP converter, we need to release the chip from reset pretty early to establish the DP AUX connection to communicate with the display, in order to find out which video modes we can drive. As the chip is controlled via i2c in my case, initializing the DSI host on first DSI command transaction is out and doing so before the bridge pre_enable is way too late. What I would need for this chip to work properly is an explicit call, like the mipi_dsi_host_init() added in the PoC above, to allow the bridge driver to kick the DSI host initialization before releasing the chip from reset state. Regards, Lucas
