On Thu, 2014-10-30 at 23:39 +0000, One Thousand Gnomes wrote: > > > You'd have to solve it in the firmware. > > > > Not if the kernel can tell us that the event occurred and when. > > Which it can only do if the firmware told the kernel meaningfully ! > > > And I think I have one of those devices, an Intel Baytrail tablet. > > > > > - Suspend/Resume on such machines are a Linux fake to keep legacy code > > > happy > > > > Do you have a link to how this is implemented currently? > > You ask for suspend and we put all the devices into lowest power state if > they are not already there then sit on our backsides issuing mwaits > asking for C7 state on BYT (C10 I think on HSW). > > If you box is ever passive enough you can even randomly enter this state > in the idle loop. You generally won't do this on current devices because > you won't have suitable panels and most desktop OS's are far too noisy on > wakeups. There's nothing preventing you having half your processors in > deep idle. > > That's where it is all heading though. Suspend will eventually go away. > > > [1]: Reason for wake-up for each wake-up-able device, along with a > > timestamp. > > We may not know and the answer in many cases will be extremely device > specific.
Which is why I'm interested in the device drivers providing that information. > It's a reasonable ask but answers even if available are likely > to be things like "because GPE36" and GPE36 will just be some connection > to something that could be anything from a lid switch to a light sensor > or even a smart wifi chip deciding it wants the CPU to help out because > you are out of range of the base station. We may not even know what it > relates to. But the device or platform driver would know that, presumably. > A non suspend system will exit deep idle type status because they got > an IRQ or perhaps some DMA needed the cache coherency. That doesn't mean > they've got the foggiest which IRQ kicked them out if idle, just that hey > I'm awake and there are four pending interrupts. That of course is > assuming it even noticed it entered a deep idle state - you don't want to > wake an idle CPU to tell it that its more idle than it was before. Sure, the CPU might not be the best example of a device for which we need to track the wakeup reason. The device drivers however... -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
