Re: [Intel-gfx] [PATCH 05/21] drm/i915: Check eDP power when doing aux channel communications

2011-10-03 Thread Jesse Barnes
On Thu, 29 Sep 2011 18:09:37 -0700 Keith Packard wrote: > Verify that the eDP VDD is on, either with the panel being on or with > the VDD force-on bit being set. > > This demonstrates that in many instances, VDD is not on when needed, > which leads to failed EDID communications. > > Signed-off-

[Intel-gfx] [PATCH 05/21] drm/i915: Check eDP power when doing aux channel communications

2011-10-03 Thread Jesse Barnes
On Thu, 29 Sep 2011 18:09:37 -0700 Keith Packard wrote: > Verify that the eDP VDD is on, either with the panel being on or with > the VDD force-on bit being set. > > This demonstrates that in many instances, VDD is not on when needed, > which leads to failed EDID communications. > > Signed-off-

[Intel-gfx] [PATCH 05/21] drm/i915: Check eDP power when doing aux channel communications

2011-09-30 Thread Daniel Vetter
On Fri, Sep 30, 2011 at 11:01:06AM -0700, Keith Packard wrote: > Should I bother to include this patch in the series at all? It's purely > for diagnostics to make sure the panel is powered during all aux channel > transactions. I'd say yes, imo paranoia in modesetting code is justified ;-) -Daniel

[Intel-gfx] [PATCH 05/21] drm/i915: Check eDP power when doing aux channel communications

2011-09-30 Thread Chris Wilson
On Fri, 30 Sep 2011 11:01:06 -0700, Keith Packard wrote: Non-text part: multipart/signed > On Fri, 30 Sep 2011 19:02:42 +0200, Daniel Vetter wrote: > > > Use pp_control instead of re-reading? > > Could, but you'll note a later patch eliminates both pp_status and > pp_control local variables, so

[Intel-gfx] [PATCH 05/21] drm/i915: Check eDP power when doing aux channel communications

2011-09-30 Thread Daniel Vetter
On Thu, Sep 29, 2011 at 06:09:37PM -0700, Keith Packard wrote: > Verify that the eDP VDD is on, either with the panel being on or with > the VDD force-on bit being set. > > This demonstrates that in many instances, VDD is not on when needed, > which leads to failed EDID communications. > > Signed

Re: [Intel-gfx] [PATCH 05/21] drm/i915: Check eDP power when doing aux channel communications

2011-09-30 Thread Chris Wilson
On Fri, 30 Sep 2011 11:01:06 -0700, Keith Packard wrote: Non-text part: multipart/signed > On Fri, 30 Sep 2011 19:02:42 +0200, Daniel Vetter wrote: > > > Use pp_control instead of re-reading? > > Could, but you'll note a later patch eliminates both pp_status and > pp_control local variables, so

Re: [Intel-gfx] [PATCH 05/21] drm/i915: Check eDP power when doing aux channel communications

2011-09-30 Thread Daniel Vetter
On Fri, Sep 30, 2011 at 11:01:06AM -0700, Keith Packard wrote: > Should I bother to include this patch in the series at all? It's purely > for diagnostics to make sure the panel is powered during all aux channel > transactions. I'd say yes, imo paranoia in modesetting code is justified ;-) -Daniel

Re: [Intel-gfx] [PATCH 05/21] drm/i915: Check eDP power when doing aux channel communications

2011-09-30 Thread Keith Packard
On Fri, 30 Sep 2011 19:02:42 +0200, Daniel Vetter wrote: > Use pp_control instead of re-reading? Could, but you'll note a later patch eliminates both pp_status and pp_control local variables, so I didn't bother to clean this up when refactoring. > dp_aux_ch does the low-level io for the below,

[Intel-gfx] [PATCH 05/21] drm/i915: Check eDP power when doing aux channel communications

2011-09-30 Thread Keith Packard
On Fri, 30 Sep 2011 19:02:42 +0200, Daniel Vetter wrote: > Use pp_control instead of re-reading? Could, but you'll note a later patch eliminates both pp_status and pp_control local variables, so I didn't bother to clean this up when refactoring. > dp_aux_ch does the low-level io for the below,

Re: [Intel-gfx] [PATCH 05/21] drm/i915: Check eDP power when doing aux channel communications

2011-09-30 Thread Daniel Vetter
On Thu, Sep 29, 2011 at 06:09:37PM -0700, Keith Packard wrote: > Verify that the eDP VDD is on, either with the panel being on or with > the VDD force-on bit being set. > > This demonstrates that in many instances, VDD is not on when needed, > which leads to failed EDID communications. > > Signed