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

[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.

> 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."

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.