Re: [PATCH 1/2] drm/i915: take a power domain ref only when needed during HDMI detect

[Imre Deak <imre.deak@intel.com>]

On Thu, 2015-11-19 at 23:50 +0200, Imre Deak wrote:
> On Thu, 2015-11-19 at 21:38 +0000, Chris Wilson wrote:
> > On Thu, Nov 19, 2015 at 11:01:49PM +0200, Imre Deak wrote:
> > > On Thu, 2015-11-19 at 20:51 +0000, Chris Wilson wrote:
> > > > On Thu, Nov 19, 2015 at 08:55:00PM +0200, Imre Deak wrote:
> > > > > Suggested by Ville.
> > > > 
> > > > Do you mind explaining why this is done at the hdmi level and
> > > > not the
> > > > gmbus level?
> > > 
> > > To reduce the on/off toggling, since we don't have delayed power-
> > > off
> > > implemented for power wells. gmbus_xfer also takes a ref to
> > > account for
> > > accesses from the i2c device node. The solution would be to
> > > implement
> > > delayed power-off I guess.
> > 
> > As we chase ever finer grained wakelocks, yeah.
> 
> Ok, the delayed-off stuff shouldn't be difficult, since in case of
> power wells we hold an RPM ref. So AFAICS we would only need to
> synchronize during system suspend and driver unload. And then find a
> good timeout value..
> 
> > Looking at the other users of gmbus, they are the old platforms
> > (dvo,
> > sdvo, crt, lvds) so not worth generalising the optimisation of
> > holding the wakelock across the entire i2c operation, I guess?
> 
> If you mean to take an extra ref around the higher level op in those
> places too: well in case of CRT it's also in new HW where it matters,
> so that's inconsistent and I think we should do it there too. For
> others it doesn't matter I think.

Err, we do take a ref in the CRT detect code, but it's the port power
domain.

--Imre
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx