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