On Wed, 01 Jul 2015, Pavel Machek <pavel@xxxxxx> wrote: > On Wed 2015-07-01 13:53:31, Ville Syrjälä wrote: >> On Wed, Jul 01, 2015 at 11:51:27AM +0200, Pavel Machek wrote: >> > > > > - Embedded panels have a well defined shutdown sequence. We >> > don't >> > >> > > > > have >> > > > > any good reason to not follow this, in fact for some panels the >> > > > > subsequent reinitialization could be problematic in case of a hard >> > > > > power-off. (Thanks to Jani for this info) >> > > > >> > > > Please cite concrete example. I have yet to see machine that would not >> > > > power up on forced power down. In fact, I argue that such machine >> > > > would be very broken, and that such machine does not exist. While we >> > > > have these real machines broken: >> > > > >> > > > > + * Lenovo Thinkpad X301, X61s, X60, T60, X41 >> > > > > + * Fujitsu FSC S7110 >> > > > > + * Acer Aspire 1830T >> > > > >> > > > What makes you think that BIOS writers will do something different for >> > > > Gen6+ hardware? X301 is not that old. >> > > >> > > Thinkpad X1 Carbon (IVB) is perfectly happy with the D3, so clearly >> > > something changed for Lenovo at least. And most machines (old and new) >> > > have no problems whatsoever with the D3. >> > >> > Well, one machine being happy does not matter that much... >> >> I said most machines, not one. >> >> > as going to >> > D3 has no real benefits. >> >> Sure it does. Eventually we'll want to avoid resuming runtime suspended >> devices when entering system suspend. For broken machines we'd need to >> resume the GPU at that point. > > You want to optimize transition between suspend-to-RAM and > hibernation? No? I thought so. > > So no benefits, 7 real, broken machines. runtime suspended != suspend-to-RAM > Pavel > > -- > (english) http://www.livejournal.com/~pavelmachek > (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- Jani Nikula, Intel Open Source Technology Center -- To unsubscribe from this list: send the line "unsubscribe stable" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html