On Thu, Aug 20, 2015 at 04:04:47PM +0300, Heikki Krogerus wrote: > Hi, > > On Thu, Aug 20, 2015 at 03:38:05PM +0300, Mika Westerberg wrote: > > +Heikki > > > > On Thu, Aug 20, 2015 at 10:46:07PM +0530, Srinidhi Kasagar wrote: > > > LPSS devices in Braswell and Baytrail does not need the default > > > 10ms d3_delay imposed by PCI specification. Removing this > > > unnecessary delay significantly reduces the resume time > > > (~200ms on Braswell/Cherrytrail) on these platforms. > > > > > > Signed-off-by: Srinidhi Kasagar <srinidhi.kasagar@xxxxxxxxx> > > > Signed-off-by: Kumar P Mahesh <mahesh.kumar.p@xxxxxxxxx> > > > > Have you tested this on Asus T100? The delay was actually needed in > > order to restore the context IIRC. > > We need to make sure the write operation succeeded when restoring the > register values. That was the problem we had with T100, which btw. is > Baytrail. > > Instead of using the delay conditionally, why not just read the value > back in a loop (with timeout of course) until we see the write > succeed? That should speedup the resume like you want, but still > guarantee the ctx has really been restored. I would love to do that. But these are PCI devices and the delay is imposed by PCI spec and in many other places these conditional delays have been used. I do not think there exist any mechanism to verify write succeeds. Srinidhi -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
