Re: [PATCH] drm/dp: Clarify that wait_hpd_asserted() is not optional for panels

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi,

On Tue, Mar 19, 2024 at 1:55 PM Dmitry Baryshkov
<dmitry.baryshkov@xxxxxxxxxx> wrote:
>
> > >>>> -        * panel to finish powering on. This is an optional function.
> > >>>> +        * panel to finish powering on. It is optional for DP AUX controllers
> > >>>> +        * to implement this function but required for DP AUX endpoints (panel
> > >>>> +        * drivers) to call it after powering up but before doing AUX transfers.
> > >>>> +        * If a DP AUX controller does not implement this function then it
> > >>>> +        * may still support eDP panels that use the AUX controller's built-in
> > >>>> +        * HPD signal by implementing a long wait for HPD in the transfer()
> > >>>> +        * callback, though this is deprecated.
> > >>>
> > >>> It doesn't cover a valid case when the panel driver handles HPD signal
> > >>> on its own.
> > >>>
> > >>
> > >> This doc is only for wait_for_hpd_asserted(). If panel driver handles
> > >> HPD signal on its own, this will not be called. Do we need a doc for that?
> > >
> > > This comment declares that this callback must be called by the panel
> > > driver: '...but required for DP AUX endpoints [...] to call it after
> > > powering up but before doing AUX transfers.'
> > >
> > > If we were to follow documentation changes from this patch, we'd have
> > > to patch panel-edp to always call wait_for_hpd_asserted, even if HPD
> > > GPIO is used. However this is not correct from my POV.
> > >
> >
> > hmmm I dont mind explicitly saying "unless the panel can independently
> > check the HPD state" but not required in my opinion because if panel was
> > capable of checking the HPD gpio (its self-capable) why would it even
> > call wait_for_hpd_asserted?
>
> I'm fine with the proposed change. Doug?
>
> >
> > I will let you and Doug discuss this but fwiw, I am fine without this
> > additional clarification. So the R-b stands with or without this
> > additional clause.

Adjusted wording in v2. Kept Abhniav's R-b. PTAL.

https://lore.kernel.org/r/20240319135836.v2.1.I521dad0693cc24fe4dd14cba0c7048d94f5b6b41@changeid




[Index of Archives]     [Linux DRI Users]     [Linux Intel Graphics]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux