From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1M6SWy-0001QH-1s for qemu-devel@nongnu.org; Tue, 19 May 2009 12:51:08 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1M6SWt-0001C9-6i for qemu-devel@nongnu.org; Tue, 19 May 2009 12:51:07 -0400 Received: from [199.232.76.173] (port=52869 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1M6SWs-0001Bz-R5 for qemu-devel@nongnu.org; Tue, 19 May 2009 12:51:02 -0400 Received: from mail-fx0-f219.google.com ([209.85.220.219]:64128) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1M6SWs-0002k6-8v for qemu-devel@nongnu.org; Tue, 19 May 2009 12:51:02 -0400 Received: by fxm19 with SMTP id 19so3763999fxm.34 for ; Tue, 19 May 2009 09:51:01 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <87pre5twbh.fsf@pike.pond.sub.org> References: <87zldtotvx.fsf@pike.pond.sub.org> <87pre5twbh.fsf@pike.pond.sub.org> Date: Tue, 19 May 2009 19:51:01 +0300 Message-ID: Subject: Re: [Qemu-devel] [PATCH 1/4] Confine use of global rtc_state to PC CMOS functions From: Blue Swirl Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Markus Armbruster Cc: qemu-devel@nongnu.org On 5/19/09, Markus Armbruster wrote: > Sorry for the sloooow respons, I was on vacation. > > > Blue Swirl writes: > > > On 5/4/09, Markus Armbruster wrote: > >> Blue Swirl writes: > >> > >> > On 4/30/09, Markus Armbruster wrote: > >> >> Pass the state as argument to cmos_init() and cmos_init_hd(). > >> >> cmos_init() still needs to save it in rtc_state for use by > >> >> cmos_set_s3_resume(). > >> > > >> > pc.c could pass acpi an opaque handle (former rtc_state) at init or > >> > acpi could export a function to set the handle, called by pc.c. Then > >> > cmos_set_s3_resume could take a state parameter. > >> > >> > >> We'd just move a global variable from pc.c to acpi.c, wouldn't we? > >> Could you explain why that's a better place? > > > > No, acpi would only have an opaque pointer to the variable stored in > > PIIX4PMState, the "owner" would still be pc.c. > > > Okay, so we'd just move a global variable from pc.c into only instance > of struct PIIX4PMState, referenced from a global variable in acpi.c. > The fact that it becomes opaque in the process isn't much of an > improvement, isn't it? Yes it is, acpi.c does not need to know about rtc_state internals. > >> Passing rtc_state to piix4_pm_init() doesn't work well for pcdt.c, > >> because we'd have to pass it from RTC device to PIIX3 ACPI device > >> somehow, creating one of those ugly "non-tree" device dependencies, > >> i.e. one that doesn't follow device tree or interrupt tree edges. Your > >> other idea (a function to set the handle) allows me to keep the two > >> devices decoupled, provided I can set the handle even before > >> piix4_pm_init(). > > > > Still one idea: a signal (qemu_irq) could be used to convey the s3 > > resume condition. That may be another tree. > > > Hmm. > > How does the hardware do it? Does it update CMOS all by itself? Just guessing: there could be a signal wire from the power management chip to CMOS GPIO pin and this would be visible in a CMOS register. > > Setting the handle before piix4_pm_init will fail if the handle is > > going to be stored in PIIX4PMState, > > > Correct. > > > > but the setup can be reversed: > > piix4_pm_init can call a function to get the handle. > > > Where from? > > A global variable in pc.c? But then we create global state in acpi.c > without reducing it in pc.c. pc.c is the "owner" of most devices, so that's OK. acpi.c only has a handle. > In the context of pcdt.c: creates the same non-tree device dependency, > only in the opposite direction. I don't see how you can avoid it. Maybe power management wants a tree of its own.