[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
Re: [Qemu-devel] [PATCH 1/4] Confine use of global rtc_state to PC CMOS functions
Tue, 5 May 2009 19:22:33 +0300
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.
> 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
Still one idea: a signal (qemu_irq) could be used to convey the s3
resume condition. That may be another tree.
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.