[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH 1/4] Confine use of global rtc_state to PC CMOS

From: Markus Armbruster
Subject: Re: [Qemu-devel] [PATCH 1/4] Confine use of global rtc_state to PC CMOS functions
Date: Tue, 19 May 2009 08:56:34 +0200
User-agent: Gnus/5.11 (Gnus v5.11) Emacs/22.3 (gnu/linux)

Sorry for the sloooow respons, I was on vacation.

Blue Swirl <address@hidden> writes:

> On 5/4/09, Markus Armbruster <address@hidden> wrote:
>> Blue Swirl <address@hidden> writes:
>>  > On 4/30/09, Markus Armbruster <address@hidden> 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?

>>  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.


How does the hardware do it?  Does it update CMOS all by itself?

> Setting the handle before piix4_pm_init will fail if the handle is
> going to be stored in PIIX4PMState,


>                                     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.

In the context of pcdt.c: creates the same non-tree device dependency,
only in the opposite direction.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]