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

From: Imre Deak <imre.deak@intel.com>
To: Chris Wilson <chris@chris-wilson.co.uk>
Cc: intel-gfx@lists.freedesktop.org
Subject: Re: [PATCH 1/2] drm/i915: take a power domain ref only when needed during HDMI detect
Date: Thu, 19 Nov 2015 23:50:42 +0200	[thread overview]
Message-ID: <1447969842.7864.19.camel@intel.com> (raw)
In-Reply-To: <20151119213828.GE24442@nuc-i3427.alporthouse.com>

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.

--Imre

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