Hi,
On Tue, Feb 15, 2022 at 4:41 PM Brian Norris wrote:
>
> On Tue, Feb 15, 2022 at 3:46 PM Doug Anderson wrote:
> > On Tue, Feb 15, 2022 at 2:52 PM Brian Norris
> > wrote:
> > > It still makes me wonder what the point
> > > of the /dev/drm_dp_aux interface is though, because it seems like
> >
On Tue, Feb 15, 2022 at 3:46 PM Doug Anderson wrote:
> On Tue, Feb 15, 2022 at 2:52 PM Brian Norris wrote:
> > It still makes me wonder what the point
> > of the /dev/drm_dp_aux interface is though, because it seems like
> > you're pretty much destined to not have reliable operation through
> > t
Hi,
On Tue, Feb 15, 2022 at 2:52 PM Brian Norris wrote:
>
> On Tue, Feb 15, 2022 at 1:31 PM Doug Anderson wrote:
> >
> > Hi,
>
> Hi!
>
> > On Fri, Oct 1, 2021 at 2:50 PM Brian Norris
> > wrote:
> > >
> > > If the display is not enable()d, then we aren't holding a runtime PM
> > > reference her
On Tue, Feb 15, 2022 at 1:31 PM Doug Anderson wrote:
>
> Hi,
Hi!
> On Fri, Oct 1, 2021 at 2:50 PM Brian Norris wrote:
> >
> > If the display is not enable()d, then we aren't holding a runtime PM
> > reference here. Thus, it's easy to accidentally cause a hang, if user
> > space is poking around
Hi,
On Fri, Oct 1, 2021 at 2:50 PM Brian Norris wrote:
>
> If the display is not enable()d, then we aren't holding a runtime PM
> reference here. Thus, it's easy to accidentally cause a hang, if user
> space is poking around at /dev/drm_dp_aux0 at the "wrong" time.
>
> Let's get the panel and PM
Hi Andrzej,
On Tue, Jan 11, 2022 at 5:26 AM Andrzej Hajda wrote:
> I am not DP specialist so CC-ed people working with DP
Thanks for the review regardless! I'll also not claim to be a DP
specialist -- although I've had to learn my fair share to debug a good
handful of issues on an SoC using this
Hi Brian,
I am not DP specialist so CC-ed people working with DP
On 01.10.2021 23:42, Brian Norris wrote:
If the display is not enable()d, then we aren't holding a runtime PM
reference here. Thus, it's easy to accidentally cause a hang, if user
space is poking around at /dev/drm_dp_aux0 at the
(updating Andrzej's email)
On Fri, Oct 1, 2021 at 2:50 PM Brian Norris wrote:
> If the display is not enable()d, then we aren't holding a runtime PM
> reference here. Thus, it's easy to accidentally cause a hang, if user
> space is poking around at /dev/drm_dp_aux0 at the "wrong" time.
>
> Let's
If the display is not enable()d, then we aren't holding a runtime PM
reference here. Thus, it's easy to accidentally cause a hang, if user
space is poking around at /dev/drm_dp_aux0 at the "wrong" time.
Let's get the panel and PM state right before trying to talk AUX.
Fixes: 0d97ad03f422 ("drm/br