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@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
