From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([140.186.70.92]:43563)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <kraxel@redhat.com>) id 1RvU4J-0004kX-Hv
	for qemu-devel@nongnu.org; Thu, 09 Feb 2012 08:29:53 -0500
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <kraxel@redhat.com>) id 1RvU4B-0005wc-Fe
	for qemu-devel@nongnu.org; Thu, 09 Feb 2012 08:29:47 -0500
Received: from mx1.redhat.com ([209.132.183.28]:39018)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <kraxel@redhat.com>) id 1RvU4B-0005w7-4c
	for qemu-devel@nongnu.org; Thu, 09 Feb 2012 08:29:39 -0500
Message-ID: <4F33CA3C.50903@redhat.com>
Date: Thu, 09 Feb 2012 14:29:32 +0100
From: Gerd Hoffmann <kraxel@redhat.com>
MIME-Version: 1.0
References: <1328698819-31269-1-git-send-email-kraxel@redhat.com>
	<1328698819-31269-2-git-send-email-kraxel@redhat.com>
	<20120209084816.GB18866@redhat.com> <4F33A3C1.1080108@redhat.com>
	<20120209111928.GH18866@redhat.com> <4F33B5E7.7070502@redhat.com>
	<20120209123725.GK18866@redhat.com> <4F33C00F.7040408@redhat.com>
	<20120209131714.GM18866@redhat.com>
In-Reply-To: <20120209131714.GM18866@redhat.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: Re: [Qemu-devel] [PATCH v3 1/6] suspend: add infrastructure
List-Id: <qemu-devel.nongnu.org>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Gleb Natapov <gleb@redhat.com>
Cc: xen-devel@lists.xensource.com, qemu-devel@nongnu.org

  Hi,

>>> We need to give ACPI ability to prevent wakeup. So, for instance, if RTC
>>> alarm calls wakeup but ACPI detects that RTC_EN is cleared it can
>>> prevent it.
>>
>> Yea, already figured that after reading your rtc reply ...
>>
>> One more incremental attached for review.
>>
> We can start from that. But other devices can use STS/EN registers
> from different GPEs, so they will have same "reason" bit, but in
> different registers.

Yes, we'll need more reason bits then, basically one per device.

> Also I'd rather hide this logic in ACPI code
> instead of having it in vl.c.

The acpi bits will be in acpi of course.

I'll try to get a complete v4 out of the door later today, that should
the direction I'm heading to more clear than these incremental bits.

cheers,
  Gerd