Message-ID: <CAOCk7Nog30WTqOPwd0HaP3NjTLv-5E3g1ekcp6dBJi3GLqrtrw@mail.gmail.com>
Date:   Sat, 9 Nov 2019 16:55:53 -0700
From:   Jeffrey Hugo <jeffrey.l.hugo@...il.com>
To:     Stephan Gerhold <stephan@...hold.net>
Cc:     Jasper Korten <jja2000@...il.com>, Hai Li <hali@...eaurora.org>,
        David Airlie <airlied@...ux.ie>,
        MSM <linux-arm-msm@...r.kernel.org>,
        lkml <linux-kernel@...r.kernel.org>,
        "open list:DRM PANEL DRIVERS" <dri-devel@...ts.freedesktop.org>,
        Rob Clark <robdclark@...il.com>,
        Daniel Vetter <daniel@...ll.ch>,
        freedreno <freedreno@...ts.freedesktop.org>,
        Sean Paul <sean@...rly.run>
Subject: Re: [Freedreno] [PATCH] drm/msm/dsi: Delay drm_panel_enable() until dsi_mgr_bridge_enable()

On Sat, Nov 9, 2019 at 5:02 AM Stephan Gerhold <stephan@...hold.net> wrote:
>
> On Fri, Nov 08, 2019 at 08:47:08PM -0700, Jeffrey Hugo wrote:
> > On Fri, Nov 8, 2019 at 4:47 PM Stephan Gerhold <stephan@...hold.net> wrote:
> > >
> > > On Fri, Nov 08, 2019 at 03:12:28PM -0700, Jeffrey Hugo wrote:
> > > > On Fri, Nov 8, 2019 at 2:29 PM Stephan Gerhold <stephan@...hold.net> wrote:
> > > > >
> > > > > At the moment, the MSM DSI driver calls drm_panel_enable() rather early
> > > > > from the DSI bridge pre_enable() function. At this point, the encoder
> > > > > (e.g. MDP5) is not enabled, so we have not started transmitting
> > > > > video data.
> > > > >
> > > > > However, the drm_panel_funcs documentation states that enable()
> > > > > should be called on the panel *after* video data is being transmitted:
> > > > >
> > > > >   The .prepare() function is typically called before the display controller
> > > > >   starts to transmit video data. [...] After the display controller has
> > > > >   started transmitting video data, it's safe to call the .enable() function.
> > > > >   This will typically enable the backlight to make the image on screen visible.
> > > > >
> > > > > Calling drm_panel_enable() too early causes problems for some panels:
> > > > > The TFT LCD panel used in the Samsung Galaxy Tab A 9.7 (2015) (APQ8016)
> > > > > uses the MIPI_DCS_SET_DISPLAY_BRIGHTNESS command to control
> > > > > backlight/brightness of the screen. The enable sequence is therefore:
> > > > >
> > > > >   drm_panel_enable()
> > > > >     drm_panel_funcs.enable():
> > > > >       backlight_enable()
> > > > >         backlight_ops.update_status():
> > > > >           mipi_dsi_dcs_set_display_brightness(dsi, bl->props.brightness);
> > > > >
> > > > > The panel seems to silently ignore the MIPI_DCS_SET_DISPLAY_BRIGHTNESS
> > > > > command if it is sent too early. This prevents setting the initial brightness,
> > > > > causing the display to be enabled with minimum brightness instead.
> > > > > Adding various delays in the panel initialization code does not result
> > > > > in any difference.
> > > > >
> > > > > On the other hand, moving drm_panel_enable() to dsi_mgr_bridge_enable()
> > > > > fixes the problem, indicating that the panel requires the video stream
> > > > > to be active before the brightness command is accepted.
> > > > >
> > > > > Therefore: Move drm_panel_enable() to dsi_mgr_bridge_enable() to
> > > > > delay calling it until video data is being transmitted.
> > > > >
> > > > > Move drm_panel_disable() to dsi_mgr_bridge_disable() for similar reasons.
> > > > > (This is not strictly required for the panel affected above...)
> > > > >
> > > > > Tested-by: Jasper Korten <jja2000@...il.com>
> > > > > Signed-off-by: Stephan Gerhold <stephan@...hold.net>
> > > > > ---
> > > > > Since this is a core change I thought it would be better to send this
> > > > > early. I believe Jasper still wants to finish some other changes before
> > > > > submitting the initial device tree for the Samsung Galaxy Tab A 9.7 (2015). ;)
> > > > >
> > > > > I also tested it on msm8916-samsung-a5u-eur, its display is working fine
> > > > > with or without this patch.
> > > >
> > > > Nack, please.  I was curious so I threw this on the Lenovo Miix 630
> > > > laptop.  I don't get a display back with this patch.  I'll try to
> > > > figure out why, but currently I can't get into the machine.
> > >
> > > Thanks for testing the patch! Let's try to figure that out...
> > >
> > > I'm a bit confused, but this might be because I'm not very familiar with
> > > the MSM8998 laptops. It does not seem to have display in mainline yet,
> > > so do you have a link to all the patches you are using at the moment?
> >
> > The mdp5 support is there.  Some of the dependencies have dragged out.
> > I'd have to make sense of my development tree as to what is relevant.
>
> A dump of all the patches (whether still relevant or not) would be
> helpful too. Actually I was mostly looking for the device tree part to
> see which components are involved.

DSI0 to "ti,sn65dsi86" (bridge) to "sharp,ld-d5116z01b" (panel).

>
> > >
> > > Judging from the patches I was able to find, the Lenovo Miix 630 is
> > > using a DSI to eDP bridge.
> > > Isn't the panel managed by the bridge driver in that case?
> >
> > It uses the TI SN65 bridge.
> >
>
> It is covered by the ti-sn65dsi86 driver I assume?

Yes

>
> > >
> > > struct msm_dsi contains:
> > >         /*
> > >          * panel/external_bridge connected to dsi bridge output, only one of the
> > >          * two can be valid at a time
> > >          */
> > >         struct drm_panel *panel;
> > >         struct drm_bridge *external_bridge;
> > >
> > > So if you have "external_bridge" set in your case, "panel" should be NULL.
> > > I have only moved code that uses msm_dsi->panel, so my patch really
> > > shouldn't make any difference for you.
> > >
> > > Am I confusing something here?
> >
> > I don't think panel is null in my case.  I need to trace a few things
> > through to be sure.
> >
>
> ti-sn65dsi86.c contains:
>
> static void ti_sn_bridge_enable(struct drm_bridge *bridge)
> {
>         /* ... */
>         drm_panel_enable(pdata->panel);
> }
>
> static void ti_sn_bridge_pre_enable(struct drm_bridge *bridge)
> {
>         /* ... */
>         drm_panel_prepare(pdata->panel);
> }
>
> So it does indeed manage the panel for you. If msm_dsi->panel is not
> NULL for you it would mean that your panel is managed by two drivers
> at the same time.
>
> (Also note how it calls drm_panel_enable() in enable() instead of
> pre_enable(). This is exactly the change my patch does for the case
> when the panel is managed by the MSM driver...)
>
> > Taking a quick look at the datasheet for the bridge, I suspect that
> > operations are occurring in the enable() phase of the bridge, that
> > need to occur before video data is transmitted.  Based on your
> > analysis in the commit message, I suspect these operations need to be
> > moved to pre_enable().
> >
>
> I'm still confused how my patch makes any difference for you.
> The enable sequence should be exactly the same as before.
>
> > I'm hoping to gather more data this weekend, which will hopefully
> > identify what we need to do to move this forward without causing
> > regressions.
>
> Looking forward to it, thanks!

Panel was infact NULL for me, and the DSI panel operations are not
translating into direct bridge calls.  I re-applied your change, and
I'm not reproing the original failure.  I tried a couple of times to
be sure.  I have no idea what happened during the initial testing to
break things.

Therefore, I remove my nack.

Tested-by: Jeffrey Hugo <jeffrey.l.hugo@...il.com>
Reviewed-by: Jeffrey Hugo <jeffrey.l.hugo@...il.com>

Powered by blists - more mailing lists