On Mon, Feb 24, 2014 at 01:56:20PM +0200, Imre Deak wrote: > On Thu, 2014-02-20 at 11:33 -0800, Jesse Barnes wrote: > > On Wed, 19 Feb 2014 14:39:58 +0200 > > Imre Deak <imre.deak@xxxxxxxxx> wrote: > > > > > On Wed, 2014-02-19 at 14:35 +0200, Ville Syrjälä wrote: > > > > On Tue, Feb 18, 2014 at 12:02:09AM +0200, Imre Deak wrote: > > > > > The connector detect and get_mode handlers need to access the port > > > > > specific HW blocks to read the EDID etc. Get/put the port power domains > > > > > around these handlers. > > > > > > > > > > Signed-off-by: Imre Deak <imre.deak@xxxxxxxxx> > > > > > --- > > > > > drivers/gpu/drm/i915/intel_crt.c | 42 ++++++++++++++++++++++++++++++++-------- > > > > > drivers/gpu/drm/i915/intel_dp.c | 16 ++++++++++++--- > > > > > drivers/gpu/drm/i915/intel_dsi.c | 13 ++++++++++++- > > > > > > > > And what about HDMI? > > > > > > Good catch, I missed that one. > > > > I wonder if we can catch bits like that using our display reg base > > bits. We could have a platform specific power check for each block to > > do some basic sanity checking on whether the appropriate well was > > enabled and squak if not. > > > > I just know we'll miss this more than once, and I'm not sure if the > > unclaimed reg stuff will save us on all platforms. > > Yea, good idea. The register->power well mapping could be part of the > platform specific power well struct and we could assert on the SW state > of the well being 'enabled'. We could add a (start, length) register range (or an array of such ranges) to the power well struct and use that in our reg I/O functions for the display range. If we don't do this for any of the registers in the forcewake range the impact should be fairly minimal I hope ... -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
