Re: [PATCH v6 1/8] drm/msm/dp: Add eDP support via aux_bus

[Abhinav Kumar]

Hi Doug and Dmitry

On 4/8/2022 7:58 AM, Dmitry Baryshkov wrote:
> On Fri, 8 Apr 2022 at 16:43, Doug Anderson <dianders@xxxxxxxxxxxx> wrote:
> > Hi,
> >
> > On Fri, Apr 8, 2022 at 5:20 AM Dmitry Baryshkov
> > <dmitry.baryshkov@xxxxxxxxxx> wrote:
> > > > I guess my thought was that in DP you could still create the AUX bus
> > > > at probe time. Then for DP you just return an instant "transfer
> > > > failed" from the AUX bus if HPD isn't asserted. For eDP (as discussed
> > > > elsewhere) when we try to do an AUX transfer then we delay until HPD
> > > > is there.
> > >
> > > I think panel-edp would already handle the delay, so we do not need to
> > > have this logic in the DP driver.
> >
> > There's a whole discussion about this between Stephen and me in patch
> > #5 ("drm/msm/dp: wait for hpd high before any sink interaction").
> > Basically:
> >
> > * If panel HPD is hooked up to the dedicated HPD pin on the eDP
> > controller then the panel driver doesn't have a way to read it.
>
> I refreshed that dialog. I must admit, I have missed the fact that the
> HPD pin might not be visible as the GPIO pin.
>
> > * We can't leverage the existing "HPD" query functions in DRM because
> > those indicate whether a panel is _physically_ connected. For eDP, it
> > always is.
>
> Yes, I was thinking about (mis)using the
> drm_bridge_connector_hpd_notify() for generic HPD-related
> notifications (to tell eDP that it should check the current state). I
> have abandoned that idea.
>
> > For now the rule is that the AUX transfer function is in charge of
> > waiting for HPD for eDP if the dedicated HPD pin is used. If we want
> > to re-invent this we could, but that system works, isn't _too_ ugly,
> > and we're already making big enough changes in this series.
>
> The is_hpd_asserted() looks like a good callback for the aux bus.
> It will allow the panel driver to check if the panel is powered up (in
> the absence of the GPIO pin).
>
> > > > So we can still acquire resources (clocks, PHY, io maps, etc) at probe
> > > > time for DP and create the AUX bus, right? It will just return
> > > > "-ENODEV" if HPD isn't asserted and you're DP?
> > >
> > > Yes, please. I still suppose that we'd need a separate case to
> > > power_on eDP's PHY during the probe time. Maybe I'm mistaken here.
> >
> > I think the ideal way is to do it like Kieran's proposal for sn65dsi86:
> >
> > https://lore.kernel.org/r/20220317131250.1481275-4-kieran.bingham+renesas@xxxxxxxxxxxxxxxx/
> >
> > * When enabling HPD (physical hot plug detect) in the hpd_enable()
> > callback you do a pm_runtime_get(). You do the
> > pm_runtime_put_autosuspend() when disabling. This is only used for DP
> > since we only provide DRM_BRIDGE_OP_HPD for DP, not for eDP.
> >
> > * We do a pm_runtime_get() / pm_runtime_put_autosuspend() in the AUX
> > transfer routine. While holding the pm_runtime reference we check HPD.
> > For DP we return immediately if HPD isn't asserted. For eDP, we delay.
> >
> > * We do the pm_runtime_get() in pre_enable and the pm_runtime_put() in
> > post_disable. For DP this will add a 2nd refcount (since we probably
> > were holding the reference for HPD). For eDP this will cause us to
> > power on.
> >
> > * If there's any other time we need to read HW registers, and we
> > aren't guaranteed to already have a pm_runtime reference (like during
> > probe), we can do a temporary pm_runtime_get() /
> > pm_runtime_put_autosuspend().
>
> This looks good. I'd be more than welcome to review such series.
>
> Note: I think this would require using
> drm_bridge_connector_enable_hpd() in the DP code.
> Hopefully at some point we would be able to move all
> drm_bridge_connector calls to the core msm layer.
> --
> With best wishes
> Dmitry


Thanks for the proposals.

In general I would break up this task as follows:

1) Re-factoring dp/edp parsing code to move it to probe ( its currently
done in bind ). So not sure what dependencies we will uncover there.
Nonetheless, lets assume for now it can be done.

2) Then bind all the power resources needed for AUX in pm_runtime_ops

3) Handle EPROBE_DEFER cases of the panel-eDP aux device

4) Probably the biggest from our point of view --- makes sure none of 
this breaks DP/eDP

Since QC will be taking ownership of all of this, I would still suggest 
land this series first so that basic display functionality on sc7280
chromebooks works, unblocks more developers and this program and we can
internally evaluate all of this and post the changes as-and-when ready
for review.

So, I suggest/request acking this current one after
fixing the other comments (unrelated to this re-factor) which have been 
given so far ofcourse, as we all agree this is not breaking and seems 
pretty reasonable short term.

Doug, you can track this re-factor with a different bug so that all this 
discussion remains intact.

Thanks

Abhinav