On Thu, 2 Mar 2023 at 19:26, Doug Anderson <dianders@xxxxxxxxxxxx> wrote:
>
> Hi,
>
> On Mon, Feb 27, 2023 at 5:24 PM Dmitry Baryshkov
> <dmitry.baryshkov@xxxxxxxxxx> wrote:
> >
> > On 28/02/2023 02:26, Doug Anderson wrote:
> > > Hi,
> > >
> > > On Wed, Feb 1, 2023 at 1:51 AM Dave Stevenson
> > > <dave.stevenson@xxxxxxxxxxxxxxx> wrote:
> > >>
> > >> On Tue, 31 Jan 2023 at 22:22, Douglas Anderson <dianders@xxxxxxxxxxxx> wrote:
> > >>>
> > >>> Set the "pre_enable_prev_first" as provided by commit 4fb912e5e190
> > >>> ("drm/bridge: Introduce pre_enable_prev_first to alter bridge init
> > >>> order"). This should allow us to revert commit ec7981e6c614
> > >>> ("drm/msm/dsi: don't powerup at modeset time for parade-ps8640") and
> > >>> commit 7d8e9a90509f ("drm/msm/dsi: move DSI host powerup to modeset
> > >>> time").
> > >>
> > >> I see no reference in the TC358762 datasheet to requiring the DSI
> > >> interface to be in any particular state.
> > >> However, setting this flag does mean that the DSI host doesn't need to
> > >> power up and down for each host_transfer request from
> > >> tc358762_pre_enable/tc358762_init, so on that basis I'm good with it.
> > >>
> > >> Reviewed-by: Dave Stevenson <dave.stevenson@xxxxxxxxxxxxxxx>
> > >>
> > >>> Cc: Dave Stevenson <dave.stevenson@xxxxxxxxxxxxxxx>
> > >>> Cc: Dmitry Baryshkov <dmitry.baryshkov@xxxxxxxxxx>
> > >>> Cc: Abhinav Kumar <quic_abhinavk@xxxxxxxxxxx>
> > >>> Signed-off-by: Douglas Anderson <dianders@xxxxxxxxxxxx>
> > >>> ---
> > >>>
> > >>> (no changes since v1)
> > >>>
> > >>> drivers/gpu/drm/bridge/tc358762.c | 1 +
> > >>> 1 file changed, 1 insertion(+)
> > >>>
> > >>> diff --git a/drivers/gpu/drm/bridge/tc358762.c b/drivers/gpu/drm/bridge/tc358762.c
> > >>> index 0b6a28436885..77f7f7f54757 100644
> > >>> --- a/drivers/gpu/drm/bridge/tc358762.c
> > >>> +++ b/drivers/gpu/drm/bridge/tc358762.c
> > >>> @@ -229,6 +229,7 @@ static int tc358762_probe(struct mipi_dsi_device *dsi)
> > >>> ctx->bridge.funcs = &tc358762_bridge_funcs;
> > >>> ctx->bridge.type = DRM_MODE_CONNECTOR_DPI;
> > >>> ctx->bridge.of_node = dev->of_node;
> > >>> + ctx->bridge.pre_enable_prev_first = true;
> > >>>
> > >>> drm_bridge_add(&ctx->bridge);
> > >
> > > Abhinav asked what the plan was for landing this [1]. Since this isn't
> > > urgent, I guess the plan is to land patch #1 in drm-misc-next. Then we
> > > sit and wait until it percolates into mainline and, once it does, then
> > > patch #2 and #3 can land.
> > >
> > > Since I have Dave's review I can commit this to drm-misc-next myself.
> > > My plan will be to wait until Thursday or Friday of this week (to give
> > > people a bit of time to object) and then land patch #1. Then I'll
> > > snooze things for a while and poke Abhinav and Dmitry to land patch #2
> > > / #3 when I notice it in mainline. If, at any point, someone comes out
> > > of the woodwork and yells that this is breaking them then, worst case,
> > > we can revert.
> >
> > This plan sounds good to me.
>
> Pushed to drm-misc-next:
>
> 55cac10739d5 drm/bridge: tc358762: Set pre_enable_prev_first
>
> If my math is right then I'd expect that to get into mainline for
> 6.4-rc1. I guess that means it'll be in Linus's tree mid-May. I'll
> schedule a reminder to suggest landing at patches #2 and #3 again in
> late May.
It might be earlier, if msm-next merges drm-misc earlier (e.g. for the
PSR patches).
--
With best wishes
Dmitry
