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 _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
