[PATCH V2 0/3] DSI host and peripheral initialisation ordering

[Dave Stevenson]

Hi Lucas

On Fri, 10 Jun 2022 at 08:52, Lucas Stach <l.stach at pengutronix.de> wrote:
>
> 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 at raspberrypi.com>  wrote:
> > > > On Fri, 4 Mar 2022 at 15:18, Dave Stevenson
> > > > <dave.stevenson at raspberrypi.com>  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 at samsung.com>
> >
> >
> > 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@amarulasolutions.com/
> > ). 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.

This is going off on a slight tangent from the original patch set, but
a thought has just come to mind for this use case.

For this sort of bridge device where you want to power up early
(either just for LP-11 state, or for HS on the clock lane), is power
up at mipi_dsi_attach, and power down at mipi_dsi_detach sufficient?
We have mode_flags in struct mipi_dsi_device passed in
mipi_dsi_attach, so an extra flag in there (eg
MIPI_DSI_EARLY_POWER_ON) would be very easy and be a simple way to
signal an alternate DSI host behaviour.

It still leaves the configuration of link frequency as an open
question, but potentially solves the sequencing issue. Just a thought.
Perhaps dsi_attach() is still too late in the process.

  Dave