Re: [PATCH 00/14] drm/i915: IRQ work for chv mostly

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, Nov 04, 2014 at 06:42:16PM +0200, Ville Syrjälä wrote:
> On Tue, Nov 04, 2014 at 01:40:05PM +0100, Daniel Vetter wrote:
> > On Tue, Nov 4, 2014 at 1:21 PM, Ville Syrjälä
> > <ville.syrjala@xxxxxxxxxxxxxxx> wrote:
> > >> >   drm/i915: Refactor vlv_display_irq_uninstall()
> > >>
> > >> Except this, I think consens is that we don't need it?
> > >
> > > No, it's needed by the later patches. Trying to replace the vlv/chv
> > > uninstall() hooks with reset() is best left for another series IMO.
> > > And doing that involves more than just reviewing the the display irq
> > > install/uninstall paths. Eg. currently VLV_MASTER_IER handling is
> > > very inconsistent.
> > 
> > Well I think we should just open-code it for chv and not do this
> > extraction.
> 
> I don't see what the extraction hurts. If someone manages to unify it
> more that's fine, but in the meantime it could at least prevent random
> bugs from cropping up in one of the relevant platforms. Wouldn't be the
> first time someone forgets about chv.

Well my understanding was that chv doesn't yet have runtime pm and that
runtime pm on vlv is still broken. Hence my reluctance to copypaste code
around which might be part of the problem and not the solution.

> > All the complexity here is due to vlv runtime pm, and
> > somehow I still think that this should work more magically. At least
> > it should be possible if we start to handle power domains in the
> > system s/r code instead of just force-enabling them all.
> 
> Well the same complexity is already there during driver init. So it just
> comes from the power wells. Trying to avoid the force enable all thing
> is a bit difficult because we can't really reconstruct the required
> refcounts until we've read out the entire modeset state.
> 
> I guess one option would be to read out the current power well states
> and convert that into temporary refcounts that get dropped after the
> init is done. That would at least guarantee we don't prematurely turn
> off anything that the BIOS already lit up. And as Imre pointed out to me,
> we should then definitely add the unclaimed register check for vlv/chv
> so that we might catch more easily any missing power well references
> in the init path.

Hm yeah that might work well, both for driver load and init. We already
have the ->is_enabled hook, so we could reconstruct the current mask of
power well refcounts from the bios. At least over s/r we shouldn't have
any lingering power domain refcounts, so then we could just drop the bios
refcounts. Since usually on resume the bios hasn't turned up anything that
would get us exactly what we want, while the code can still be the same
for moduel load.
-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





[Index of Archives]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]
  Powered by Linux