[PATCH 01/18] drm/etnaviv: reset GPU when coming back from suspend

[Lucas Stach]

Am Montag, den 22.08.2016, 13:27 +0100 schrieb Russell King - ARM Linux:
> On Mon, Aug 22, 2016 at 02:15:25PM +0200, Lucas Stach wrote:
> > Am Montag, den 22.08.2016, 12:20 +0100 schrieb Russell King - ARM Linux:
> > > On Mon, Aug 22, 2016 at 01:00:55PM +0200, Lucas Stach wrote:
> > > > The GPU may still keep its state when in suspend, which breaks the
> > > > assumption that the hardware is in a clean state before the init
> > > > routine runs. Make sure to reset the GPU when coming back from
> > > > suspend, so this assumption is validated.
> > > 
> > > This doesn't mean very much to me - could you explain exactly what the
> > > problem you're trying to solve here is?
> > > 
> > On the i.MX6 both the 2D and 3D GPU are in the same power domain. As
> > long as the 2D core is in use the 3D core will not loose power during
> > suspend and the other way around.
> 
> ... which is already fine.
> 
> > So the GPU is keeping it's state during suspend. What I've seen is that
> > we definitely fall over when trying to configure an already enabled MMU,
> > as this is causing faults. But I can well imagine that we the GPU might
> > behave slightly different in a number of places.
> 
> I've not seen this on iMX6, and since my setup exercises the 2D and 3D
> GPUs quite independently, I'm surprised that you've found a problem here.
> Again... more details please.  Bearing in mind that the iMX6 GPUs (with
> v1 MMUs) are incapable of generating any kind of fault, I'm not really
> sure what you're talking about here.
> 
I'm looking at i.MX6QP with MMUv2.

> > Also currently the i.MX6 platform resets the GPU after powering up the
> > power domain, but there is no guarantee that the platform does this and
> > the driver should work correctly regardless. In fact im.MX6QP has an
> > erratum, which disallows to power down the GPU power domain, as long as
> > the PRE unit is active, so there will be no power-up reset when coming
> > back from suspend.
> 
> There is no requirement to actually power down the GPU when placing it
> into low power state, and we don't make the assumption that it will be
> powered down - but we do expect that it may power down, so we do enough
> to bring it back up.
> 
> In any case, if hardware has been powered down, it has _got_ to be reset
> by hardware when re-applying power otherwise it is in a completely
> indeterminant state.  That is very dangerous as it would mean that the
> MMUs can contain random data, as well as the command processor, and the
> rest of the GPU.  The GPU could well think that it's supposed to be
> drawing stuff to random places in memory.  You can't say "ah yes, but
> this is why we need to software reset it" because that's _way_ too late,
> there's a time window between applying power and the GPU starting to
> scribble, and the CPU getting around to applying the software reset.
> 
> So, software resetting the GPU doesn't achieve very much in this
> situation IMHO.
> 
> > > This looks like it makes resuming the GPU quite expensive.
> > > 
> > Possibly, yes. But the timeouts for runtime PM are really long right
> > now, so we should not power down the GPU when it's in active use. So
> > taking a little longer to resume the GPU shouldn't matter. Even more so
> > when taking into account that the resume path is already quite
> > expensive, involving a regulator the be enabled and waited on to become
> > stable.
> 
> Not all platforms are that expensive.  For Dove, it's writing three
> registers and you're done, with no wait required.  So I don't buy
> the argument that "it's already expensive, so we can make it more
> expensive."
> 
Okay, I see your argument. I'll drop this patch and add a check to the
MMUv2 code to not restore anything if the state is retained during
suspend.

Regards,
Lucas