[Qemu-devel] [PATCH][RFC 0/14] implement power chip

[Qemu-devel] [PATCH][RFC 0/14] implement power chip

[liguang]

By now, all devices of QEMU do not have much more
power management consideration, for example, if
system do suspend, it will call all registered notifiers,
this was loosely required, and the code to do power management
state transition seems just do 'ugly emulation', rather than be
conscious with whole system devices, same condition with reset(it
has been embedded in DeviceClass, good!),
shutdown, in real world, commonly all devices' power are controlled
by a power chip, then all power sequence can be done just
issue commands to this chip.
so, I come across an idea to implement qdev'ed power device, and
make all qdev struct of devices aware of self power management(add
on/off/wakeup/suspend ... filed for DeviceClass), this will
bring tidy power management, and the emulation will more like what
happened in real world.

Of course, it's only a patch-set for RFC, I'd like to ask all 
developers to help correct this idea, if it's worth to implement, 
I'll go head to refactor more.

Li Guang (14)
	 gitignore: ignore more files
	 qdev: add power management method
	 qdev: remove redundant abort()
	 qdev: add power on/off/suspend/wakeup handler
	 power: add power chip emulation
	 sysemu: remove PowerReason in sysemu.h
	 acpi: refactor acpi wakeup function
	 ich9: make lpc's reset also do pm_reset
	 ich9: do lpc's power on by reset function
	 piix4: refactor piix4's power callbacks
	 pckbd: refactor pckbd's power callbacks
	 ps2: call ps2_{kbd,mouse}_reset in kbd_reset
	 parallel: refactor parallel_reset function
	 uhci: refactor uhci's power callbacks

.gitignore              |   3 +++
Makefile.objs           |   1 +
hw/acpi.c               |  20 +++++++++-----------
hw/acpi.h               |   3 ++-
hw/acpi_ich9.c          |   4 ++--
hw/ich9.h               |   1 +
hw/lpc_ich9.c           |  12 ++++++++++-
hw/parallel.c           |  10 ++++++----
hw/pckbd.c              |  25 ++++++++++++----------
hw/piix4.c              |  14 ++++++++++++--
hw/ps2.c                |   8 ++++----
hw/ps2.h                |   2 ++
hw/qdev-core.h          |  15 ++++++
hw/qdev.c               |  99 +--
hw/usb/hcd-uhci.c       |  10 ++++++++++
include/sysemu/sysemu.h |   7 +------
power.c                 | 133 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++
power.h                 |  41 +++++++++++++++++
18 files changed, 365 insertions(+), 43 deletions(-)
 create mode 100644 power.c
 create mode 100644 power.h

[Qemu-devel] [PATCH][RFC 01/14] gitignore: ignore more files

[liguang]

ignore *.patch, *.gcda, *.gcno

Signed-off-by: liguang <lig.fnst@cn.fujitsu.com>
---
 .gitignore |    3 +++
 1 files changed, 3 insertions(+), 0 deletions(-)

diff --git a/.gitignore b/.gitignore
index 27ad002..9c234a3 100644
--- a/.gitignore
+++ b/.gitignore
@@ -80,6 +80,9 @@ fsdev/virtfs-proxy-helper.pod
 *.swp
 *.orig
 .pc
+*.patch
+*.gcda
+*.gcno
 patches
 pc-bios/bios-pq/status
 pc-bios/vgabios-pq/status
-- 
1.7.2.5

Re: [Qemu-devel] [PATCH][RFC 01/14] gitignore: ignore more files

[li guang]

ping ...
can this change be accepted?

在 2013-03-13三的 16:01 +0800，liguang写道：
> ignore *.patch, *.gcda, *.gcno
> 
> Signed-off-by: liguang <lig.fnst@cn.fujitsu.com>
> ---
>  .gitignore |    3 +++
>  1 files changed, 3 insertions(+), 0 deletions(-)
> 
> diff --git a/.gitignore b/.gitignore
> index 27ad002..9c234a3 100644
> --- a/.gitignore
> +++ b/.gitignore
> @@ -80,6 +80,9 @@ fsdev/virtfs-proxy-helper.pod
>  *.swp
>  *.orig
>  .pc
> +*.patch
> +*.gcda
> +*.gcno
>  patches
>  pc-bios/bios-pq/status
>  pc-bios/vgabios-pq/status

Re: [Qemu-devel] [PATCH][RFC 01/14] gitignore: ignore more files

[Peter Maydell]

On 21 March 2013 06:24, li guang <lig.fnst@cn.fujitsu.com> wrote:
> ping ...
> can this change be accepted?
>
> 在 2013-03-13三的 16:01 +0800，liguang写道：
>> ignore *.patch, *.gcda, *.gcno
>>
>> Signed-off-by: liguang <lig.fnst@cn.fujitsu.com>

If you want a change to be considered for acceptance
on its own, it's better not to include it in a 14 patch
RFC series. "RFC" specifically means "I'm asking for
comments and don't expect/want this to be applied".
Since this is a standalone patch I suggest you send it
out as a single patch email (you could probably cc
qemu-trivial too).

thanks
-- PMM

[Qemu-devel] [PATCH][RFC 02/14] qdev: add power management method

[liguang]

In fact, every devices have to be aware of
it's power management, so it can decide what
to do when platform board switch it's power
state between on/off/suspend/wakeup.

Signed-off-by: liguang <lig.fnst@cn.fujitsu.com>
---
 hw/qdev-core.h |    6 ++++++
 1 files changed, 6 insertions(+), 0 deletions(-)

diff --git a/hw/qdev-core.h b/hw/qdev-core.h
index 2486f36..e69c50b 100644
--- a/hw/qdev-core.h
+++ b/hw/qdev-core.h
@@ -85,6 +85,12 @@ typedef struct DeviceClass {
     Property *props;
     int no_user;
 
+    /* power management */
+    void (*on)(DeviceState *dev);
+    void (*off)(DeviceState *dev);
+    void (*suspend)(DeviceState *dev);
+    void (*wakeup)(DeviceState *dev);
+
     /* callbacks */
     void (*reset)(DeviceState *dev);
     DeviceRealize realize;
-- 
1.7.2.5

Re: [Qemu-devel] [PATCH][RFC 02/14] qdev: add power management method

[Andreas Färber]

Am 13.03.2013 09:01, schrieb liguang:
> In fact, every devices have to be aware of
> it's power management, so it can decide what
> to do when platform board switch it's power
> state between on/off/suspend/wakeup.
> 
> Signed-off-by: liguang <lig.fnst@cn.fujitsu.com>
> ---
>  hw/qdev-core.h |    6 ++++++
>  1 files changed, 6 insertions(+), 0 deletions(-)
> 
> diff --git a/hw/qdev-core.h b/hw/qdev-core.h
> index 2486f36..e69c50b 100644
> --- a/hw/qdev-core.h
> +++ b/hw/qdev-core.h
> @@ -85,6 +85,12 @@ typedef struct DeviceClass {
>      Property *props;
>      int no_user;
>  
> +    /* power management */
> +    void (*on)(DeviceState *dev);
> +    void (*off)(DeviceState *dev);
> +    void (*suspend)(DeviceState *dev);
> +    void (*wakeup)(DeviceState *dev);
> +
>      /* callbacks */
>      void (*reset)(DeviceState *dev);
>      DeviceRealize realize;

Whatever callbacks get added, they should be added down here and get
gtk-doc documentation above the struct. That should also include some
guidelines on how new devices should implement these (hint: we'd want to
avoid code duplication).

I have the feeling your hooks may be rather x86-specific - have you
checked against any other architecture?

Andreas

-- 
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg

Re: [Qemu-devel] [PATCH][RFC 02/14] qdev: add power management method

[li guang]

Thanks!

在 2013-03-18一的 09:25 +0100，Andreas Färber写道：
> Am 13.03.2013 09:01, schrieb liguang:
> > In fact, every devices have to be aware of
> > it's power management, so it can decide what
> > to do when platform board switch it's power
> > state between on/off/suspend/wakeup.
> > 
> > Signed-off-by: liguang <lig.fnst@cn.fujitsu.com>
> > ---
> >  hw/qdev-core.h |    6 ++++++
> >  1 files changed, 6 insertions(+), 0 deletions(-)
> > 
> > diff --git a/hw/qdev-core.h b/hw/qdev-core.h
> > index 2486f36..e69c50b 100644
> > --- a/hw/qdev-core.h
> > +++ b/hw/qdev-core.h
> > @@ -85,6 +85,12 @@ typedef struct DeviceClass {
> >      Property *props;
> >      int no_user;
> >  
> > +    /* power management */
> > +    void (*on)(DeviceState *dev);
> > +    void (*off)(DeviceState *dev);
> > +    void (*suspend)(DeviceState *dev);
> > +    void (*wakeup)(DeviceState *dev);
> > +
> >      /* callbacks */
> >      void (*reset)(DeviceState *dev);
> >      DeviceRealize realize;
> 
> Whatever callbacks get added, they should be added down here and get
> gtk-doc documentation above the struct. That should also include some
> guidelines on how new devices should implement these (hint: we'd want to
> avoid code duplication).

OK

> 
> I have the feeling your hooks may be rather x86-specific - have you
> checked against any other architecture?
> 

I'm considering to be generic

> Andreas
> 

[Qemu-devel] [PATCH][RFC 03/14] qdev: remove redundant abort()

[liguang]

Signed-off-by: liguang <lig.fnst@cn.fujitsu.com>
---
 hw/qdev.c |    3 +--
 1 files changed, 1 insertions(+), 2 deletions(-)

diff --git a/hw/qdev.c b/hw/qdev.c
index 689cd54..2bed9d8 100644
--- a/hw/qdev.c
+++ b/hw/qdev.c
@@ -116,11 +116,10 @@ DeviceState *qdev_create(BusState *bus, const char *name)
         if (bus) {
             error_report("Unknown device '%s' for bus '%s'", name,
                          object_get_typename(OBJECT(bus)));
-            abort();
         } else {
             error_report("Unknown device '%s' for default sysbus", name);
-            abort();
         }
+        abort();
     }
 
     return dev;
-- 
1.7.2.5

Re: [Qemu-devel] [PATCH][RFC 03/14] qdev: remove redundant abort()

[Andreas Färber]

Am 13.03.2013 09:01, schrieb liguang:
> Signed-off-by: liguang <lig.fnst@cn.fujitsu.com>
> ---
>  hw/qdev.c |    3 +--
>  1 files changed, 1 insertions(+), 2 deletions(-)
> 
> diff --git a/hw/qdev.c b/hw/qdev.c
> index 689cd54..2bed9d8 100644
> --- a/hw/qdev.c
> +++ b/hw/qdev.c
> @@ -116,11 +116,10 @@ DeviceState *qdev_create(BusState *bus, const char *name)
>          if (bus) {
>              error_report("Unknown device '%s' for bus '%s'", name,
>                           object_get_typename(OBJECT(bus)));
> -            abort();
>          } else {
>              error_report("Unknown device '%s' for default sysbus", name);
> -            abort();
>          }
> +        abort();
>      }
>  
>      return dev;

Reviewed-by: Andreas Färber <afaerber@suse.de>

However this being a fatal abort, it doesn't really matter too much.

Andreas

-- 
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg

Re: [Qemu-devel] [PATCH][RFC 03/14] qdev: remove redundant abort()

[li guang]

ping ...
can this change be accepted?

在 2013-03-18一的 09:26 +0100，Andreas Färber写道：
> Am 13.03.2013 09:01, schrieb liguang:
> > Signed-off-by: liguang <lig.fnst@cn.fujitsu.com>
> > ---
> >  hw/qdev.c |    3 +--
> >  1 files changed, 1 insertions(+), 2 deletions(-)
> > 
> > diff --git a/hw/qdev.c b/hw/qdev.c
> > index 689cd54..2bed9d8 100644
> > --- a/hw/qdev.c
> > +++ b/hw/qdev.c
> > @@ -116,11 +116,10 @@ DeviceState *qdev_create(BusState *bus, const char *name)
> >          if (bus) {
> >              error_report("Unknown device '%s' for bus '%s'", name,
> >                           object_get_typename(OBJECT(bus)));
> > -            abort();
> >          } else {
> >              error_report("Unknown device '%s' for default sysbus", name);
> > -            abort();
> >          }
> > +        abort();
> >      }
> >  
> >      return dev;
> 
> Reviewed-by: Andreas Färber <afaerber@suse.de>
> 
> However this being a fatal abort, it doesn't really matter too much.
> 
> Andreas
> 

[Qemu-devel] [PATCH][RFC 04/14] qdev: add power on/off/suspend/wakeup handler

[liguang]

Signed-off-by: liguang <lig.fnst@cn.fujitsu.com>
---
 hw/qdev-core.h |    9 +++++
 hw/qdev.c      |   96 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 2 files changed, 105 insertions(+), 0 deletions(-)

diff --git a/hw/qdev-core.h b/hw/qdev-core.h
index e69c50b..805ac69 100644
--- a/hw/qdev-core.h
+++ b/hw/qdev-core.h
@@ -262,6 +262,15 @@ void qdev_reset_all(DeviceState *dev);
 void qbus_reset_all(BusState *bus);
 void qbus_reset_all_fn(void *opaque);
 
+void qdev_power_on(DeviceState *dev);
+void qdev_power_off(DeviceState *dev);
+void qdev_power_wakeup(DeviceState *dev);
+void qdev_power_suspend(DeviceState *dev);
+void qbus_power_off(void *opaque);
+void qbus_power_wakeup(void *opaque);
+void qbus_power_suspend(void *opaque);
+void qbus_power_on(void *opaque);
+
 void qbus_free(BusState *bus);
 
 #define FROM_QBUS(type, dev) DO_UPCAST(type, qbus, dev)
diff --git a/hw/qdev.c b/hw/qdev.c
index 2bed9d8..dfc265d 100644
--- a/hw/qdev.c
+++ b/hw/qdev.c
@@ -237,6 +237,102 @@ void qbus_reset_all_fn(void *opaque)
     qbus_reset_all(bus);
 }
 
+static int qdev_off_one(DeviceState *dev, void *opaque)
+{
+    device_reset(dev);
+
+    return 0;
+}
+
+static int qbus_off_one(BusState *bus, void *opaque)
+{
+    return 0;
+}
+
+static int qdev_on_one(DeviceState *dev, void *opaque)
+{
+    device_reset(dev);
+
+    return 0;
+}
+
+static int qbus_on_one(BusState *bus, void *opaque)
+{
+    return 0;
+}
+
+static int qdev_wakeup_one(DeviceState *dev, void *opaque)
+{
+    device_reset(dev);
+
+    return 0;
+}
+
+static int qbus_wakeup_one(BusState *bus, void *opaque)
+{
+    return 0;
+}
+
+static int qdev_suspend_one(DeviceState *dev, void *opaque)
+{
+    device_reset(dev);
+
+    return 0;
+}
+
+static int qbus_suspend_one(BusState *bus, void *opaque)
+{
+    return 0;
+}
+
+void qdev_power_on(DeviceState *dev)
+{
+    qdev_walk_children(dev, qdev_on_one, qbus_on_one, NULL);
+}
+
+void qbus_power_on(void *opaque)
+{
+    BusState *bus = opaque;
+
+    qbus_walk_children(bus, qdev_on_one, qbus_on_one, NULL);
+}
+
+void qdev_power_off(DeviceState *dev)
+{
+    qdev_walk_children(dev, qdev_off_one, qbus_off_one, NULL);
+}
+
+void qbus_power_off(void *opaque)
+{
+    BusState *bus = opaque;
+
+    qbus_walk_children(bus, qdev_off_one, qbus_off_one, NULL);
+}
+
+void qdev_power_wakeup(DeviceState *dev)
+{
+    qdev_walk_children(dev, qdev_wakeup_one, qbus_wakeup_one, NULL);
+}
+
+void qbus_power_wakeup(void *opaque)
+{
+    BusState *bus = opaque;
+
+    qbus_walk_children(bus, qdev_wakeup_one, qbus_wakeup_one, NULL);
+}
+
+void qdev_power_suspend(DeviceState *dev)
+{
+    qdev_walk_children(dev, qdev_suspend_one, qbus_suspend_one, NULL);
+}
+
+void qbus_power_suspend(void *opaque)
+{
+    BusState *bus = opaque;
+
+    qbus_walk_children(bus, qdev_suspend_one, qbus_suspend_one, NULL);
+}
+
 /* can be used as ->unplug() callback for the simple cases */
 int qdev_simple_unplug_cb(DeviceState *dev)
 {
-- 
1.7.2.5

Re: [Qemu-devel] [PATCH][RFC 04/14] qdev: add power on/off/suspend/wakeup handler

[Andreas Färber]

Am 13.03.2013 09:01, schrieb liguang:
> Signed-off-by: liguang <lig.fnst@cn.fujitsu.com>
> ---
>  hw/qdev-core.h |    9 +++++
>  hw/qdev.c      |   96 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>  2 files changed, 105 insertions(+), 0 deletions(-)
> 
> diff --git a/hw/qdev-core.h b/hw/qdev-core.h
> index e69c50b..805ac69 100644
> --- a/hw/qdev-core.h
> +++ b/hw/qdev-core.h
> @@ -262,6 +262,15 @@ void qdev_reset_all(DeviceState *dev);
>  void qbus_reset_all(BusState *bus);
>  void qbus_reset_all_fn(void *opaque);
>  
> +void qdev_power_on(DeviceState *dev);
> +void qdev_power_off(DeviceState *dev);
> +void qdev_power_wakeup(DeviceState *dev);
> +void qdev_power_suspend(DeviceState *dev);

No new qdev_ functions please. qdev no longer exists in its original
form since the QOM introduction. Please use device_ instead.

Note that here you use power_*, so it may be worth using an identical
callback field name for at least on and off if we go with your concept.

Andreas

> +void qbus_power_off(void *opaque);
> +void qbus_power_wakeup(void *opaque);
> +void qbus_power_suspend(void *opaque);
> +void qbus_power_on(void *opaque);
> +
>  void qbus_free(BusState *bus);
>  
>  #define FROM_QBUS(type, dev) DO_UPCAST(type, qbus, dev)
[snip]

-- 
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg

Re: [Qemu-devel] [PATCH][RFC 04/14] qdev: add power on/off/suspend/wakeup handler

[li guang]

在 2013-03-18一的 09:31 +0100，Andreas Färber写道：
> Am 13.03.2013 09:01, schrieb liguang:
> > Signed-off-by: liguang <lig.fnst@cn.fujitsu.com>
> > ---
> >  hw/qdev-core.h |    9 +++++
> >  hw/qdev.c      |   96 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> >  2 files changed, 105 insertions(+), 0 deletions(-)
> > 
> > diff --git a/hw/qdev-core.h b/hw/qdev-core.h
> > index e69c50b..805ac69 100644
> > --- a/hw/qdev-core.h
> > +++ b/hw/qdev-core.h
> > @@ -262,6 +262,15 @@ void qdev_reset_all(DeviceState *dev);
> >  void qbus_reset_all(BusState *bus);
> >  void qbus_reset_all_fn(void *opaque);
> >  
> > +void qdev_power_on(DeviceState *dev);
> > +void qdev_power_off(DeviceState *dev);
> > +void qdev_power_wakeup(DeviceState *dev);
> > +void qdev_power_suspend(DeviceState *dev);
> 
> No new qdev_ functions please. qdev no longer exists in its original
> form since the QOM introduction. Please use device_ instead.
> 
> Note that here you use power_*, so it may be worth using an identical
> callback field name for at least on and off if we go with your concept.
> 
> Andreas

Good suggestion!
Thanks!

> 
> > +void qbus_power_off(void *opaque);
> > +void qbus_power_wakeup(void *opaque);
> > +void qbus_power_suspend(void *opaque);
> > +void qbus_power_on(void *opaque);
> > +
> >  void qbus_free(BusState *bus);
> >  
> >  #define FROM_QBUS(type, dev) DO_UPCAST(type, qbus, dev)
> [snip]
> 

[Qemu-devel] [PATCH][RFC 04/14] qdev: add power on/off/suspend/wakeup handler

[liguang]

Signed-off-by: liguang <lig.fnst@cn.fujitsu.com>
---
 hw/qdev-core.h |    9 +++++
 hw/qdev.c      |   96 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 2 files changed, 105 insertions(+), 0 deletions(-)

diff --git a/hw/qdev-core.h b/hw/qdev-core.h
index e69c50b..805ac69 100644
--- a/hw/qdev-core.h
+++ b/hw/qdev-core.h
@@ -262,6 +262,15 @@ void qdev_reset_all(DeviceState *dev);
 void qbus_reset_all(BusState *bus);
 void qbus_reset_all_fn(void *opaque);
 
+void qdev_power_on(DeviceState *dev);
+void qdev_power_off(DeviceState *dev);
+void qdev_power_wakeup(DeviceState *dev);
+void qdev_power_suspend(DeviceState *dev);
+void qbus_power_off(void *opaque);
+void qbus_power_wakeup(void *opaque);
+void qbus_power_suspend(void *opaque);
+void qbus_power_on(void *opaque);
+
 void qbus_free(BusState *bus);
 
 #define FROM_QBUS(type, dev) DO_UPCAST(type, qbus, dev)
diff --git a/hw/qdev.c b/hw/qdev.c
index 2bed9d8..dfc265d 100644
--- a/hw/qdev.c
+++ b/hw/qdev.c
@@ -237,6 +237,102 @@ void qbus_reset_all_fn(void *opaque)
     qbus_reset_all(bus);
 }
 
+static int qdev_off_one(DeviceState *dev, void *opaque)
+{
+    device_reset(dev);
+
+    return 0;
+}
+
+static int qbus_off_one(BusState *bus, void *opaque)
+{
+    return 0;
+}
+
+static int qdev_on_one(DeviceState *dev, void *opaque)
+{
+    device_reset(dev);
+
+    return 0;
+}
+
+static int qbus_on_one(BusState *bus, void *opaque)
+{
+    return 0;
+}
+
+static int qdev_wakeup_one(DeviceState *dev, void *opaque)
+{
+    device_reset(dev);
+
+    return 0;
+}
+
+static int qbus_wakeup_one(BusState *bus, void *opaque)
+{
+    return 0;
+}
+
+static int qdev_suspend_one(DeviceState *dev, void *opaque)
+{
+    device_reset(dev);
+
+    return 0;
+}
+
+static int qbus_suspend_one(BusState *bus, void *opaque)
+{
+    return 0;
+}
+
+void qdev_power_on(DeviceState *dev)
+{
+    qdev_walk_children(dev, qdev_on_one, qbus_on_one, NULL);
+}
+
+void qbus_power_on(void *opaque)
+{
+    BusState *bus = opaque;
+
+    qbus_walk_children(bus, qdev_on_one, qbus_on_one, NULL);
+}
+
+void qdev_power_off(DeviceState *dev)
+{
+    qdev_walk_children(dev, qdev_off_one, qbus_off_one, NULL);
+}
+
+void qbus_power_off(void *opaque)
+{
+    BusState *bus = opaque;
+
+    qbus_walk_children(bus, qdev_off_one, qbus_off_one, NULL);
+}
+
+void qdev_power_wakeup(DeviceState *dev)
+{
+    qdev_walk_children(dev, qdev_wakeup_one, qbus_wakeup_one, NULL);
+}
+
+void qbus_power_wakeup(void *opaque)
+{
+    BusState *bus = opaque;
+
+    qbus_walk_children(bus, qdev_wakeup_one, qbus_wakeup_one, NULL);
+}
+
+void qdev_power_suspend(DeviceState *dev)
+{
+    qdev_walk_children(dev, qdev_suspend_one, qbus_suspend_one, NULL);
+}
+
+void qbus_power_suspend(void *opaque)
+{
+    BusState *bus = opaque;
+
+    qbus_walk_children(bus, qdev_suspend_one, qbus_suspend_one, NULL);
+}
+
 /* can be used as ->unplug() callback for the simple cases */
 int qdev_simple_unplug_cb(DeviceState *dev)
 {
-- 
1.7.2.5

[Qemu-devel] [PATCH][RFC 06/14] sysemu: remove PowerReason in sysemu.h

[liguang]

Signed-off-by: liguang <lig.fnst@cn.fujitsu.com>
---
 include/sysemu/sysemu.h |    7 +------
 1 files changed, 1 insertions(+), 6 deletions(-)

diff --git a/include/sysemu/sysemu.h b/include/sysemu/sysemu.h
index b19ec95..bf830da 100644
--- a/include/sysemu/sysemu.h
+++ b/include/sysemu/sysemu.h
@@ -9,6 +9,7 @@
 #include "qapi-types.h"
 #include "qemu/notify.h"
 #include "qemu/main-loop.h"
+#include "power.h"
 
 /* vl.c */
 
@@ -37,12 +38,6 @@ void vm_start(void);
 void vm_stop(RunState state);
 void vm_stop_force_state(RunState state);
 
-typedef enum WakeupReason {
-    QEMU_WAKEUP_REASON_OTHER = 0,
-    QEMU_WAKEUP_REASON_RTC,
-    QEMU_WAKEUP_REASON_PMTIMER,
-} WakeupReason;
-
 void qemu_system_reset_request(void);
 void qemu_system_suspend_request(void);
 void qemu_register_suspend_notifier(Notifier *notifier);
-- 
1.7.2.5

[Qemu-devel] [PATCH][RFC 07/14] acpi: refactor acpi wakeup function

[liguang]

realize wakeup function for ICH9-LPC device

Signed-off-by: liguang <lig.fnst@cn.fujitsu.com>
---
 hw/acpi.c     |   20 +++++++++-----------
 hw/acpi.h     |    3 ++-
 hw/lpc_ich9.c |   11 ++++++++++-
 3 files changed, 21 insertions(+), 13 deletions(-)

diff --git a/hw/acpi.c b/hw/acpi.c
index 8c9dcc5..c0e07d4 100644
--- a/hw/acpi.c
+++ b/hw/acpi.c
@@ -241,12 +241,11 @@ int acpi_table_add(const char *t)
 
 }
 
-static void acpi_notify_wakeup(Notifier *notifier, void *data)
+void acpi_power_wakeup(ACPIREGS *ar)
 {
-    ACPIREGS *ar = container_of(notifier, ACPIREGS, wakeup);
-    WakeupReason *reason = data;
+    WakeupReason  reason = power_management_wakeup_reason();
 
-    switch (*reason) {
+    switch (reason) {
     case QEMU_WAKEUP_REASON_RTC:
         ar->pm1.evt.sts |=
             (ACPI_BITMASK_WAKE_STATUS | ACPI_BITMASK_RT_CLOCK_STATUS);
@@ -288,9 +287,9 @@ static void acpi_pm1_evt_write_sts(ACPIREGS *ar, uint16_t val)
 static void acpi_pm1_evt_write_en(ACPIREGS *ar, uint16_t val)
 {
     ar->pm1.evt.en = val;
-    qemu_system_wakeup_enable(QEMU_WAKEUP_REASON_RTC,
+    power_management_wakeup_capability(QEMU_WAKEUP_REASON_RTC,
                               val & ACPI_BITMASK_RT_CLOCK_ENABLE);
-    qemu_system_wakeup_enable(QEMU_WAKEUP_REASON_PMTIMER,
+    power_management_wakeup_capability(QEMU_WAKEUP_REASON_PMTIMER,
                               val & ACPI_BITMASK_TIMER_ENABLE);
 }
 
@@ -306,8 +305,8 @@ void acpi_pm1_evt_reset(ACPIREGS *ar)
 {
     ar->pm1.evt.sts = 0;
     ar->pm1.evt.en = 0;
-    qemu_system_wakeup_enable(QEMU_WAKEUP_REASON_RTC, 0);
-    qemu_system_wakeup_enable(QEMU_WAKEUP_REASON_PMTIMER, 0);
+    power_management_wakeup_capability(QEMU_WAKEUP_REASON_RTC, false);
+    power_management_wakeup_capability(QEMU_WAKEUP_REASON_PMTIMER, false);
 }
 
 static uint64_t acpi_pm_evt_read(void *opaque, hwaddr addr, unsigned width)
@@ -385,7 +384,8 @@ static uint32_t acpi_pm_tmr_get(ACPIREGS *ar)
 static void acpi_pm_tmr_timer(void *opaque)
 {
     ACPIREGS *ar = opaque;
-    qemu_system_wakeup_request(QEMU_WAKEUP_REASON_PMTIMER);
+    power_management_wakeup_reason_set(QEMU_WAKEUP_REASON_PMTIMER);
+    power_management_set(POWER_WAKEUP);
     ar->tmr.update_sci(ar);
 }
 
@@ -474,8 +474,6 @@ static const MemoryRegionOps acpi_pm_cnt_ops = {
 
 void acpi_pm1_cnt_init(ACPIREGS *ar, MemoryRegion *parent)
 {
-    ar->wakeup.notify = acpi_notify_wakeup;
-    qemu_register_wakeup_notifier(&ar->wakeup);
     memory_region_init_io(&ar->pm1.cnt.io, &acpi_pm_cnt_ops, ar, "acpi-cnt", 2);
     memory_region_add_subregion(parent, 4, &ar->pm1.cnt.io);
 }
diff --git a/hw/acpi.h b/hw/acpi.h
index c3628d0..98f7c5f 100644
--- a/hw/acpi.h
+++ b/hw/acpi.h
@@ -117,7 +117,6 @@ struct ACPIREGS {
         ACPIPM1EVT  evt;
         ACPIPM1CNT  cnt;
     } pm1;
-    Notifier wakeup;
 };
 
 /* PM_TMR */
@@ -154,4 +153,6 @@ void acpi_gpe_reset(ACPIREGS *ar);
 void acpi_gpe_ioport_writeb(ACPIREGS *ar, uint32_t addr, uint32_t val);
 uint32_t acpi_gpe_ioport_readb(ACPIREGS *ar, uint32_t addr);
 
+void acpi_power_wakeup(ACPIREGS *ar);
+
 #endif /* !QEMU_HW_ACPI_H */
diff --git a/hw/lpc_ich9.c b/hw/lpc_ich9.c
index eceb052..42f2dfa 100644
--- a/hw/lpc_ich9.c
+++ b/hw/lpc_ich9.c
@@ -467,6 +467,8 @@ static void ich9_lpc_reset(DeviceState *qdev)
 
     lpc->sci_level = 0;
     lpc->rst_cnt = 0;
+
+    pm_reset(&lpc->pm);
 }
 
 static const MemoryRegionOps rbca_mmio_ops = {
@@ -595,6 +597,13 @@ static const VMStateDescription vmstate_ich9_lpc = {
     }
 };
 
+static void ich9_lpc_power_wakeup(DeviceState *dev)
+{
+    ICH9LPCState *lpc = ICH9_LPC_DEVICE(PCI_DEVICE(dev));
+
+    acpi_power_wakeup(&lpc->pm.acpi_regs);
+}
+
 static void ich9_lpc_class_init(ObjectClass *klass, void *data)
 {
     DeviceClass *dc = DEVICE_CLASS(klass);
@@ -604,13 +613,13 @@ static void ich9_lpc_class_init(ObjectClass *klass, void *data)
     k->init = ich9_lpc_initfn;
     dc->vmsd = &vmstate_ich9_lpc;
     dc->no_user = 1;
+    dc->wakeup = ich9_lpc_power_wakeup;
     k->config_write = ich9_lpc_config_write;
     dc->desc = "ICH9 LPC bridge";
     k->vendor_id = PCI_VENDOR_ID_INTEL;
     k->device_id = PCI_DEVICE_ID_INTEL_ICH9_8;
     k->revision = ICH9_A2_LPC_REVISION;
     k->class_id = PCI_CLASS_BRIDGE_ISA;
-
 }
 
 static const TypeInfo ich9_lpc_info = {
-- 
1.7.2.5

[Qemu-devel] [PATCH][RFC 08/14] ich9: make lpc's reset also do pm_reset

[liguang]

Signed-off-by: liguang <lig.fnst@cn.fujitsu.com>
---
 hw/acpi_ich9.c |    4 ++--
 hw/ich9.h      |    1 +
 2 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/hw/acpi_ich9.c b/hw/acpi_ich9.c
index d2f9808..b78a32e 100644
--- a/hw/acpi_ich9.c
+++ b/hw/acpi_ich9.c
@@ -176,7 +176,7 @@ const VMStateDescription vmstate_ich9_pm = {
     }
 };
 
-static void pm_reset(void *opaque)
+void pm_reset(void *opaque)
 {
     ICH9LPCPMRegs *pm = opaque;
     ich9_pm_iospace_update(pm, 0);
@@ -224,7 +224,7 @@ void ich9_pm_init(PCIDevice *lpc_pci, ICH9LPCPMRegs *pm,
     memory_region_add_subregion(&pm->io, ICH9_PMIO_SMI_EN, &pm->io_smi);
 
     pm->irq = sci_irq;
-    qemu_register_reset(pm_reset, pm);
+
     pm->powerdown_notifier.notify = pm_powerdown_req;
     qemu_register_powerdown_notifier(&pm->powerdown_notifier);
 }
diff --git a/hw/ich9.h b/hw/ich9.h
index dbc4495..35a1daf 100644
--- a/hw/ich9.h
+++ b/hw/ich9.h
@@ -20,6 +20,7 @@ void ich9_lpc_set_irq(void *opaque, int irq_num, int level);
 int ich9_lpc_map_irq(PCIDevice *pci_dev, int intx);
 PCIINTxRoute ich9_route_intx_pin_to_irq(void *opaque, int pirq_pin);
 void ich9_lpc_pm_init(PCIDevice *pci_lpc, qemu_irq cmos_s3);
+void pm_reset(void *opaque);
 PCIBus *ich9_d2pbr_init(PCIBus *bus, int devfn, int sec_bus);
 i2c_bus *ich9_smb_init(PCIBus *bus, int devfn, uint32_t smb_io_base);
 
-- 
1.7.2.5

[Qemu-devel] [PATCH][RFC 09/14] ich9: do lpc's power on by reset function

[liguang]

Signed-off-by: liguang <lig.fnst@cn.fujitsu.com>
---
 hw/lpc_ich9.c |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/hw/lpc_ich9.c b/hw/lpc_ich9.c
index 42f2dfa..9be6196 100644
--- a/hw/lpc_ich9.c
+++ b/hw/lpc_ich9.c
@@ -614,6 +614,7 @@ static void ich9_lpc_class_init(ObjectClass *klass, void *data)
     dc->vmsd = &vmstate_ich9_lpc;
     dc->no_user = 1;
     dc->wakeup = ich9_lpc_power_wakeup;
+    dc->on = ich9_lpc_reset;
     k->config_write = ich9_lpc_config_write;
     dc->desc = "ICH9 LPC bridge";
     k->vendor_id = PCI_VENDOR_ID_INTEL;
-- 
1.7.2.5

[Qemu-devel] [PATCH][RFC 10/14] piix4: refactor piix4's power callbacks

[liguang]

Signed-off-by: liguang <lig.fnst@cn.fujitsu.com>
---
 hw/piix4.c |   14 ++++++++++++--
 1 files changed, 12 insertions(+), 2 deletions(-)

diff --git a/hw/piix4.c b/hw/piix4.c
index c1cb94d..1066149 100644
--- a/hw/piix4.c
+++ b/hw/piix4.c
@@ -34,7 +34,7 @@ typedef struct PIIX4State {
     PCIDevice dev;
 } PIIX4State;
 
-static void piix4_reset(void *opaque)
+static void piix4_config_reset(void *opaque)
 {
     PIIX4State *d = opaque;
     uint8_t *pci_conf = d->dev.config;
@@ -72,6 +72,14 @@ static void piix4_reset(void *opaque)
     pci_conf[0xae] = 0x00;
 }
 
+static void piix4_dev_reset(DeviceState *dev)
+{
+    PCIDevice *d = PCI_DEVICE(dev);
+    PIIX4State *ps = DO_UPCAST(PIIX4State, dev, d);
+
+    piix4_config_reset(ps);
+}
+
 static const VMStateDescription vmstate_piix4 = {
     .name = "PIIX4",
     .version_id = 2,
@@ -89,7 +97,7 @@ static int piix4_initfn(PCIDevice *dev)
 
     isa_bus_new(&d->dev.qdev, pci_address_space_io(dev));
     piix4_dev = &d->dev;
-    qemu_register_reset(piix4_reset, d);
+
     return 0;
 }
 
@@ -115,6 +123,8 @@ static void piix4_class_init(ObjectClass *klass, void *data)
     dc->desc = "ISA bridge";
     dc->no_user = 1;
     dc->vmsd = &vmstate_piix4;
+    dc->reset = piix4_dev_reset;
+    dc->on = piix4_dev_reset;
 }
 
 static const TypeInfo piix4_info = {
-- 
1.7.2.5

[Qemu-devel] [PATCH][RFC 11/14] pckbd: refactor pckbd's power callbacks

[liguang]

Signed-off-by: liguang <lig.fnst@cn.fujitsu.com>
---
 hw/pckbd.c |   22 ++++++++++++----------
 1 files changed, 12 insertions(+), 10 deletions(-)

diff --git a/hw/pckbd.c b/hw/pckbd.c
index 3bad09b..1ab8ada 100644
--- a/hw/pckbd.c
+++ b/hw/pckbd.c
@@ -142,6 +142,12 @@ typedef struct KBDState {
     hwaddr mask;
 } KBDState;
 
+typedef struct ISAKBDState {
+    ISADevice dev;
+    KBDState kbd;
+    MemoryRegion io[2];
+} ISAKBDState;
+
 /* update irq and KBD_STAT_[MOUSE_]OBF */
 /* XXX: not generating the irqs if KBD_MODE_DISABLE_KBD is set may be
    incorrect, but it avoids having to simulate exact delays */
@@ -360,9 +366,10 @@ static void kbd_write_data(void *opaque, hwaddr addr,
     s->write_cmd = 0;
 }
 
-static void kbd_reset(void *opaque)
+static void kbd_reset(DeviceState *dev)
 {
-    KBDState *s = opaque;
+    ISADevice *isadev = ISA_DEVICE(dev);
+    KBDState *s = &(DO_UPCAST(ISAKBDState, dev, isadev)->kbd);
 
     s->mode = KBD_MODE_KBD_INT | KBD_MODE_MOUSE_INT;
     s->status = KBD_STAT_CMD | KBD_STAT_UNLOCKED;
@@ -428,15 +435,8 @@ void i8042_mm_init(qemu_irq kbd_irq, qemu_irq mouse_irq,
 
     s->kbd = ps2_kbd_init(kbd_update_kbd_irq, s);
     s->mouse = ps2_mouse_init(kbd_update_aux_irq, s);
-    qemu_register_reset(kbd_reset, s);
 }
 
-typedef struct ISAKBDState {
-    ISADevice dev;
-    KBDState kbd;
-    MemoryRegion io[2];
-} ISAKBDState;
-
 void i8042_isa_mouse_fake_event(void *opaque)
 {
     ISADevice *dev = opaque;
@@ -499,7 +499,7 @@ static int i8042_initfn(ISADevice *dev)
 
     s->kbd = ps2_kbd_init(kbd_update_kbd_irq, s);
     s->mouse = ps2_mouse_init(kbd_update_aux_irq, s);
-    qemu_register_reset(kbd_reset, s);
+
     return 0;
 }
 
@@ -510,6 +510,8 @@ static void i8042_class_initfn(ObjectClass *klass, void *data)
     ic->init = i8042_initfn;
     dc->no_user = 1;
     dc->vmsd = &vmstate_kbd_isa;
+    dc->reset = kbd_reset;
+    dc->on = kbd_reset;
 }
 
 static const TypeInfo i8042_info = {
-- 
1.7.2.5

[Qemu-devel] [PATCH][RFC 12/14] ps2: call ps2_{kbd, mouse}_reset in kbd_reset

[liguang]

Signed-off-by: liguang <lig.fnst@cn.fujitsu.com>
---
 hw/pckbd.c |    3 +++
 hw/ps2.c   |    8 ++++----
 hw/ps2.h   |    2 ++
 3 files changed, 9 insertions(+), 4 deletions(-)

diff --git a/hw/pckbd.c b/hw/pckbd.c
index 1ab8ada..f2570d8 100644
--- a/hw/pckbd.c
+++ b/hw/pckbd.c
@@ -374,6 +374,9 @@ static void kbd_reset(DeviceState *dev)
     s->mode = KBD_MODE_KBD_INT | KBD_MODE_MOUSE_INT;
     s->status = KBD_STAT_CMD | KBD_STAT_UNLOCKED;
     s->outport = KBD_OUT_RESET | KBD_OUT_A20;
+
+    ps2_kbd_reset(s->kbd);
+    ps2_mouse_reset(s->mouse);
 }
 
 static const VMStateDescription vmstate_kbd = {
diff --git a/hw/ps2.c b/hw/ps2.c
index 15cfd5b..36d431e 100644
--- a/hw/ps2.c
+++ b/hw/ps2.c
@@ -528,7 +528,7 @@ static void ps2_common_reset(PS2State *s)
     s->update_irq(s->update_arg, 0);
 }
 
-static void ps2_kbd_reset(void *opaque)
+void ps2_kbd_reset(void *opaque)
 {
     PS2KbdState *s = (PS2KbdState *) opaque;
 
@@ -538,7 +538,7 @@ static void ps2_kbd_reset(void *opaque)
     s->scancode_set = 0;
 }
 
-static void ps2_mouse_reset(void *opaque)
+void ps2_mouse_reset(void *opaque)
 {
     PS2MouseState *s = (PS2MouseState *) opaque;
 
@@ -659,7 +659,7 @@ void *ps2_kbd_init(void (*update_irq)(void *, int), void *update_arg)
     s->scancode_set = 2;
     vmstate_register(NULL, 0, &vmstate_ps2_keyboard, s);
     qemu_add_kbd_event_handler(ps2_put_keycode, s);
-    qemu_register_reset(ps2_kbd_reset, s);
+
     return s;
 }
 
@@ -671,6 +671,6 @@ void *ps2_mouse_init(void (*update_irq)(void *, int), void *update_arg)
     s->common.update_arg = update_arg;
     vmstate_register(NULL, 0, &vmstate_ps2_mouse, s);
     qemu_add_mouse_event_handler(ps2_mouse_event, s, 0, "QEMU PS/2 Mouse");
-    qemu_register_reset(ps2_mouse_reset, s);
+
     return s;
 }
diff --git a/hw/ps2.h b/hw/ps2.h
index 7c45ce7..3e65d47 100644
--- a/hw/ps2.h
+++ b/hw/ps2.h
@@ -34,5 +34,7 @@ uint32_t ps2_read_data(void *);
 void ps2_queue(void *, int b);
 void ps2_keyboard_set_translation(void *opaque, int mode);
 void ps2_mouse_fake_event(void *opaque);
+void ps2_kbd_reset(void *opaque);
+void ps2_mouse_reset(void *opaque);
 
 #endif /* !HW_PS2_H */
-- 
1.7.2.5

[Qemu-devel] [PATCH][RFC 13/14] parallel: refactor parallel_reset function

[liguang]

Signed-off-by: liguang <lig.fnst@cn.fujitsu.com>
---
 hw/parallel.c |   10 ++++++----
 1 files changed, 6 insertions(+), 4 deletions(-)

diff --git a/hw/parallel.c b/hw/parallel.c
index 3a4e06b..7dc53eb 100644
--- a/hw/parallel.c
+++ b/hw/parallel.c
@@ -427,9 +427,11 @@ static uint32_t parallel_ioport_ecp_read(void *opaque, uint32_t addr)
     return ret;
 }
 
-static void parallel_reset(void *opaque)
+static void parallel_reset(DeviceState *dev)
 {
-    ParallelState *s = opaque;
+    ISADevice *isadev = ISA_DEVICE(dev);
+    ISAParallelState *isaparal = DO_UPCAST(ISAParallelState, dev, isadev);
+    ParallelState *s = &isaparal->state;
 
     s->datar = ~0;
     s->dataw = ~0;
@@ -495,7 +497,6 @@ static int parallel_isa_initfn(ISADevice *dev)
 
     base = isa->iobase;
     isa_init_irq(dev, &s->irq, isa->isairq);
-    qemu_register_reset(parallel_reset, s);
 
     if (qemu_chr_fe_ioctl(s->chr, CHR_IOCTL_PP_READ_STATUS, &dummy) == 0) {
         s->hw_driver = 1;
@@ -575,7 +576,6 @@ bool parallel_mm_init(MemoryRegion *address_space,
     s->irq = irq;
     s->chr = chr;
     s->it_shift = it_shift;
-    qemu_register_reset(parallel_reset, s);
 
     memory_region_init_io(&s->iomem, &parallel_mm_ops, s,
                           "parallel", 8 << it_shift);
@@ -597,6 +597,8 @@ static void parallel_isa_class_initfn(ObjectClass *klass, void *data)
     ISADeviceClass *ic = ISA_DEVICE_CLASS(klass);
     ic->init = parallel_isa_initfn;
     dc->props = parallel_isa_properties;
+    dc->reset = parallel_reset;
+    dc->on = parallel_reset;
 }
 
 static const TypeInfo parallel_isa_info = {
-- 
1.7.2.5

[Qemu-devel] [PATCH][RFC 14/14] uhci: refactor uhci's power callbacks

[liguang]

Signed-off-by: liguang <lig.fnst@cn.fujitsu.com>
---
 hw/usb/hcd-uhci.c |   10 ++++++++++
 1 files changed, 10 insertions(+), 0 deletions(-)

diff --git a/hw/usb/hcd-uhci.c b/hw/usb/hcd-uhci.c
index f8c4286..008f567 100644
--- a/hw/usb/hcd-uhci.c
+++ b/hw/usb/hcd-uhci.c
@@ -414,6 +414,14 @@ static void uhci_reset(void *opaque)
     uhci_update_irq(s);
 }
 
+static void uhci_dev_reset(DeviceState *dev)
+{
+    PCIDevice *pdev = PCI_DEVICE(dev);
+    UHCIState *s = container_of(pdev, UHCIState, dev);
+
+    uhci_reset(s);
+}
+
 static const VMStateDescription vmstate_uhci_port = {
     .name = "uhci port",
     .version_id = 1,
@@ -1307,6 +1315,8 @@ static void uhci_class_init(ObjectClass *klass, void *data)
     k->class_id  = PCI_CLASS_SERIAL_USB;
     k->no_hotplug = 1;
     dc->vmsd = &vmstate_uhci;
+    dc->reset = uhci_dev_reset;
+    dc->on = uhci_dev_reset;
     dc->props = uhci_properties;
     u->info = *info;
 }
-- 
1.7.2.5

Re: [Qemu-devel] [PATCH][RFC 0/14] implement power chip

[li guang]

Hi, Anthony

Sorry to bother you,
can you please help to see it this work is
worth to go on, or ...

or someone else can help to see this patch-set.

Thanks All.


在 2013-03-13三的 16:01 +0800，liguang写道：
> By now, all devices of QEMU do not have much more
> power management consideration, for example, if
> system do suspend, it will call all registered notifiers,
> this was loosely required, and the code to do power management
> state transition seems just do 'ugly emulation', rather than be
> conscious with whole system devices, same condition with reset(it
> has been embedded in DeviceClass, good!),
> shutdown, in real world, commonly all devices' power are controlled
> by a power chip, then all power sequence can be done just
> issue commands to this chip.
> so, I come across an idea to implement qdev'ed power device, and
> make all qdev struct of devices aware of self power management(add
> on/off/wakeup/suspend ... filed for DeviceClass), this will
> bring tidy power management, and the emulation will more like what
> happened in real world.
> 
> Of course, it's only a patch-set for RFC, I'd like to ask all 
> developers to help correct this idea, if it's worth to implement, 
> I'll go head to refactor more.
> 
> Li Guang (14)
> 	 gitignore: ignore more files
> 	 qdev: add power management method
> 	 qdev: remove redundant abort()
> 	 qdev: add power on/off/suspend/wakeup handler
> 	 power: add power chip emulation
> 	 sysemu: remove PowerReason in sysemu.h
> 	 acpi: refactor acpi wakeup function
> 	 ich9: make lpc's reset also do pm_reset
> 	 ich9: do lpc's power on by reset function
> 	 piix4: refactor piix4's power callbacks
> 	 pckbd: refactor pckbd's power callbacks
> 	 ps2: call ps2_{kbd,mouse}_reset in kbd_reset
> 	 parallel: refactor parallel_reset function
> 	 uhci: refactor uhci's power callbacks
> 
> .gitignore              |   3 +++
> Makefile.objs           |   1 +
> hw/acpi.c               |  20 +++++++++-----------
> hw/acpi.h               |   3 ++-
> hw/acpi_ich9.c          |   4 ++--
> hw/ich9.h               |   1 +
> hw/lpc_ich9.c           |  12 ++++++++++-
> hw/parallel.c           |  10 ++++++----
> hw/pckbd.c              |  25 ++++++++++++----------
> hw/piix4.c              |  14 ++++++++++++--
> hw/ps2.c                |   8 ++++----
> hw/ps2.h                |   2 ++
> hw/qdev-core.h          |  15 ++++++
> hw/qdev.c               |  99 +--
> hw/usb/hcd-uhci.c       |  10 ++++++++++
> include/sysemu/sysemu.h |   7 +------
> power.c                 | 133 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> power.h                 |  41 +++++++++++++++++
> 18 files changed, 365 insertions(+), 43 deletions(-)
>  create mode 100644 power.c
>  create mode 100644 power.h
> 
> 
> 

Re: [Qemu-devel] [PATCH][RFC 0/14] implement power chip

[li guang]

ping ...


在 2013-03-15五的 08:59 +0800，li guang写道：
> Hi, Anthony
> 
> Sorry to bother you,
> can you please help to see it this work is
> worth to go on, or ...
> 
> or someone else can help to see this patch-set.
> 
> Thanks All.
> 
> 
> 在 2013-03-13三的 16:01 +0800，liguang写道：
> > By now, all devices of QEMU do not have much more
> > power management consideration, for example, if
> > system do suspend, it will call all registered notifiers,
> > this was loosely required, and the code to do power management
> > state transition seems just do 'ugly emulation', rather than be
> > conscious with whole system devices, same condition with reset(it
> > has been embedded in DeviceClass, good!),
> > shutdown, in real world, commonly all devices' power are controlled
> > by a power chip, then all power sequence can be done just
> > issue commands to this chip.
> > so, I come across an idea to implement qdev'ed power device, and
> > make all qdev struct of devices aware of self power management(add
> > on/off/wakeup/suspend ... filed for DeviceClass), this will
> > bring tidy power management, and the emulation will more like what
> > happened in real world.
> > 
> > Of course, it's only a patch-set for RFC, I'd like to ask all 
> > developers to help correct this idea, if it's worth to implement, 
> > I'll go head to refactor more.
> > 
> > Li Guang (14)
> > 	 gitignore: ignore more files
> > 	 qdev: add power management method
> > 	 qdev: remove redundant abort()
> > 	 qdev: add power on/off/suspend/wakeup handler
> > 	 power: add power chip emulation
> > 	 sysemu: remove PowerReason in sysemu.h
> > 	 acpi: refactor acpi wakeup function
> > 	 ich9: make lpc's reset also do pm_reset
> > 	 ich9: do lpc's power on by reset function
> > 	 piix4: refactor piix4's power callbacks
> > 	 pckbd: refactor pckbd's power callbacks
> > 	 ps2: call ps2_{kbd,mouse}_reset in kbd_reset
> > 	 parallel: refactor parallel_reset function
> > 	 uhci: refactor uhci's power callbacks
> > 
> > .gitignore              |   3 +++
> > Makefile.objs           |   1 +
> > hw/acpi.c               |  20 +++++++++-----------
> > hw/acpi.h               |   3 ++-
> > hw/acpi_ich9.c          |   4 ++--
> > hw/ich9.h               |   1 +
> > hw/lpc_ich9.c           |  12 ++++++++++-
> > hw/parallel.c           |  10 ++++++----
> > hw/pckbd.c              |  25 ++++++++++++----------
> > hw/piix4.c              |  14 ++++++++++++--
> > hw/ps2.c                |   8 ++++----
> > hw/ps2.h                |   2 ++
> > hw/qdev-core.h          |  15 ++++++
> > hw/qdev.c               |  99 +--
> > hw/usb/hcd-uhci.c       |  10 ++++++++++
> > include/sysemu/sysemu.h |   7 +------
> > power.c                 | 133 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> > power.h                 |  41 +++++++++++++++++
> > 18 files changed, 365 insertions(+), 43 deletions(-)
> >  create mode 100644 power.c
> >  create mode 100644 power.h
> > 
> > 
> > 
> 

Re: [Qemu-devel] [PATCH][RFC 0/14] implement power chip

[Andreas Färber]

Am 13.03.2013 09:01, schrieb liguang:
> Li Guang (14)
> 	 gitignore: ignore more files
> 	 qdev: add power management method
> 	 qdev: remove redundant abort()
> 	 qdev: add power on/off/suspend/wakeup handler

> 	 power: add power chip emulation

This patch seems to be missing, whereas the previous one arrived twice.

Andreas

> 	 sysemu: remove PowerReason in sysemu.h
> 	 acpi: refactor acpi wakeup function
> 	 ich9: make lpc's reset also do pm_reset
> 	 ich9: do lpc's power on by reset function
> 	 piix4: refactor piix4's power callbacks
> 	 pckbd: refactor pckbd's power callbacks
> 	 ps2: call ps2_{kbd,mouse}_reset in kbd_reset
> 	 parallel: refactor parallel_reset function
> 	 uhci: refactor uhci's power callbacks

-- 
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg

Re: [Qemu-devel] [PATCH][RFC 0/14] implement power chip

[li guang]

在 2013-03-18一的 09:34 +0100，Andreas Färber写道：
> Am 13.03.2013 09:01, schrieb liguang:
> > Li Guang (14)
> > 	 gitignore: ignore more files
> > 	 qdev: add power management method
> > 	 qdev: remove redundant abort()
> > 	 qdev: add power on/off/suspend/wakeup handler
> 
> > 	 power: add power chip emulation
> 
> This patch seems to be missing, whereas the previous one arrived twice.
> 
> Andreas

Odd things!
anyway, I'll send 5/14 to mail-list
Thanks!

> 
> > 	 sysemu: remove PowerReason in sysemu.h
> > 	 acpi: refactor acpi wakeup function
> > 	 ich9: make lpc's reset also do pm_reset
> > 	 ich9: do lpc's power on by reset function
> > 	 piix4: refactor piix4's power callbacks
> > 	 pckbd: refactor pckbd's power callbacks
> > 	 ps2: call ps2_{kbd,mouse}_reset in kbd_reset
> > 	 parallel: refactor parallel_reset function
> > 	 uhci: refactor uhci's power callbacks
> 

Re: [Qemu-devel] [PATCH][RFC 0/14] implement power chip

[Peter Maydell]

On 13 March 2013 08:01, liguang <lig.fnst@cn.fujitsu.com> wrote:
> By now, all devices of QEMU do not have much more
> power management consideration, for example, if
> system do suspend, it will call all registered notifiers,
> this was loosely required, and the code to do power management
> state transition seems just do 'ugly emulation', rather than be
> conscious with whole system devices, same condition with reset(it
> has been embedded in DeviceClass, good!),
> shutdown, in real world, commonly all devices' power are controlled
> by a power chip, then all power sequence can be done just
> issue commands to this chip.
> so, I come across an idea to implement qdev'ed power device, and
> make all qdev struct of devices aware of self power management(add
> on/off/wakeup/suspend ... filed for DeviceClass), this will
> bring tidy power management, and the emulation will more like what
> happened in real world.

I'm really dubious that this can or should be implemented by
adding methods at the device base class level. I don't think
real hardware works this way. You could probably do power on/off
like this. Reset definitely shouldn't be done this way, and
suspend probably not either.

I think more documentation/discussion of what you think the
semantics of the power down/up/etc should be might be useful.

thanks
-- PMM

Re: [Qemu-devel] [PATCH][RFC 0/14] implement power chip

[li guang]

在 2013-03-18一的 11:07 +0000，Peter Maydell写道：
> On 13 March 2013 08:01, liguang <lig.fnst@cn.fujitsu.com> wrote:
> > By now, all devices of QEMU do not have much more
> > power management consideration, for example, if
> > system do suspend, it will call all registered notifiers,
> > this was loosely required, and the code to do power management
> > state transition seems just do 'ugly emulation', rather than be
> > conscious with whole system devices, same condition with reset(it
> > has been embedded in DeviceClass, good!),
> > shutdown, in real world, commonly all devices' power are controlled
> > by a power chip, then all power sequence can be done just
> > issue commands to this chip.
> > so, I come across an idea to implement qdev'ed power device, and
> > make all qdev struct of devices aware of self power management(add
> > on/off/wakeup/suspend ... filed for DeviceClass), this will
> > bring tidy power management, and the emulation will more like what
> > happened in real world.
> 
> I'm really dubious that this can or should be implemented by
> adding methods at the device base class level. I don't think
> real hardware works this way.

and what it should be?

>  You could probably do power on/off
> like this. Reset definitely shouldn't be done this way, and
> suspend probably not either.

AFAIK, reset is mostly power off then power on,
suspend, of course is not supported by all devices, 
but, if system want to suspend, it have to let all devices
aware this, and if the device support power suspend, it
can do something specific(or just some with others, simple)

> 
> I think more documentation/discussion of what you think the
> semantics of the power down/up/etc should be might be useful.
> 

I'm eager to get more comments and discussion.
This idea simply based on system board design convention,
I'm not saying a power chip has signals directly connected
to all devices, I mean system board and its devices should 
have protocol to deal with power state changes.

Re: [Qemu-devel] [PATCH][RFC 0/14] implement power chip

[Peter Maydell]

On 19 March 2013 00:55, li guang <lig.fnst@cn.fujitsu.com> wrote:
> 在 2013-03-18一的 11:07 +0000，Peter Maydell写道：
>> I'm really dubious that this can or should be implemented by
>> adding methods at the device base class level. I don't think
>> real hardware works this way.
>
> and what it should be?
>
>>  You could probably do power on/off
>> like this. Reset definitely shouldn't be done this way, and
>> suspend probably not either.
>
> AFAIK, reset is mostly power off then power on,

The DeviceState method 'reset' simulates a power cycle.
On real hardware power-controller controlled reset is
more complicated and generally devices implement one
or more reset pins which can be asserted by the power
controller.

> suspend, of course is not supported by all devices,
> but, if system want to suspend, it have to let all devices
> aware this, and if the device support power suspend, it
> can do something specific(or just some with others, simple)

I suspect this should involve more modelling of actual
control signals between the power controller and
the devices, not methods on the base class.

> I'm eager to get more comments and discussion.
> This idea simply based on system board design convention,
> I'm not saying a power chip has signals directly connected
> to all devices, I mean system board and its devices should
> have protocol to deal with power state changes.

Hardware does it with signals, so should we.

-- PMM

Re: [Qemu-devel] [PATCH][RFC 0/14] implement power chip

[li guang]

在 2013-03-19二的 09:05 +0000，Peter Maydell写道：
> On 19 March 2013 00:55, li guang <lig.fnst@cn.fujitsu.com> wrote:
> > 在 2013-03-18一的 11:07 +0000，Peter Maydell写道：
> >> I'm really dubious that this can or should be implemented by
> >> adding methods at the device base class level. I don't think
> >> real hardware works this way.
> >
> > and what it should be?
> >
> >>  You could probably do power on/off
> >> like this. Reset definitely shouldn't be done this way, and
> >> suspend probably not either.
> >
> > AFAIK, reset is mostly power off then power on,
> 
> The DeviceState method 'reset' simulates a power cycle.
> On real hardware power-controller controlled reset is
> more complicated and generally devices implement one
> or more reset pins which can be asserted by the power
> controller.

By now, it seems 'reset' callback only implemented as
device status initialization, and I want to keep this,
because, it's mostly the result power off/on.

> 
> > suspend, of course is not supported by all devices,
> > but, if system want to suspend, it have to let all devices
> > aware this, and if the device support power suspend, it
> > can do something specific(or just some with others, simple)
> 
> I suspect this should involve more modelling of actual
> control signals between the power controller and
> the devices, not methods on the base class.
> 

do we have to realize something like signals which are actually
only some copper wires?
I think we just emulate the real work, that is when some signals
asserted, we just call corresponding method to do something
by these embedded method, I want to let devices take care
of power event(on/off/suspend/wakeup) themselves.

> > I'm eager to get more comments and discussion.
> > This idea simply based on system board design convention,
> > I'm not saying a power chip has signals directly connected
> > to all devices, I mean system board and its devices should
> > have protocol to deal with power state changes.
> 
> Hardware does it with signals, so should we.

can these signals be viewed as the calling of corresponding methods?
 

Re: [Qemu-devel] [PATCH][RFC 0/14] implement power chip

[Peter Maydell]

On 19 March 2013 09:31, li guang <lig.fnst@cn.fujitsu.com> wrote:
> 在 2013-03-19二的 09:05 +0000，Peter Maydell写道：
>> I suspect this should involve more modelling of actual
>> control signals between the power controller and
>> the devices, not methods on the base class.
>>
>
> do we have to realize something like signals which are actually
> only some copper wires?
> I think we just emulate the real work, that is when some signals
> asserted, we just call corresponding method to do something
> by these embedded method, I want to let devices take care
> of power event(on/off/suspend/wakeup) themselves.

The point is that how exactly power controllers connect
to devices, and which devices respond to reset/suspend/etc
is a property of the individual machine being modelled.
An x86 PC will be different from an ARM devboard which is
different again from the Exynos4 ARM SoC. So to allow this
flexibility, you have to let the machine model do the configuration,
which you do by having the model wire up the power controller
to the devices in the same way it's done on hardware.

>> > I'm eager to get more comments and discussion.
>> > This idea simply based on system board design convention,
>> > I'm not saying a power chip has signals directly connected
>> > to all devices, I mean system board and its devices should
>> > have protocol to deal with power state changes.
>>
>> Hardware does it with signals, so should we.
>
> can these signals be viewed as the calling of corresponding methods?

In some ways, they are -- but the wiring up of the source of
the call to the implementation is done at runtime as devices
are connected together.

-- PMM

Re: [Qemu-devel] [PATCH][RFC 0/14] implement power chip

[li guang]

在 2013-03-19二的 10:15 +0000，Peter Maydell写道：
> On 19 March 2013 09:31, li guang <lig.fnst@cn.fujitsu.com> wrote:
> > 在 2013-03-19二的 09:05 +0000，Peter Maydell写道：
> >> I suspect this should involve more modelling of actual
> >> control signals between the power controller and
> >> the devices, not methods on the base class.
> >>
> >
> > do we have to realize something like signals which are actually
> > only some copper wires?
> > I think we just emulate the real work, that is when some signals
> > asserted, we just call corresponding method to do something
> > by these embedded method, I want to let devices take care
> > of power event(on/off/suspend/wakeup) themselves.
> 
> The point is that how exactly power controllers connect
> to devices, and which devices respond to reset/suspend/etc
> is a property of the individual machine being modelled.
> An x86 PC will be different from an ARM devboard which is
> different again from the Exynos4 ARM SoC. So to allow this
> flexibility, you have to let the machine model do the configuration,
> which you do by having the model wire up the power controller
> to the devices in the same way it's done on hardware.

agree, originally, I  made all devices can realize the power 
state callbacks, e.g. if one can do suspend, then it will
realize DeviceState::suspend, so if system go to suspend,
this method will be called.
do you want some explicit way to configure for machine's 
devices if they can support power state changes?

> 
> >> > I'm eager to get more comments and discussion.
> >> > This idea simply based on system board design convention,
> >> > I'm not saying a power chip has signals directly connected
> >> > to all devices, I mean system board and its devices should
> >> > have protocol to deal with power state changes.
> >>
> >> Hardware does it with signals, so should we.
> >
> > can these signals be viewed as the calling of corresponding methods?
> 
> In some ways, they are -- but the wiring up of the source of
> the call to the implementation is done at runtime as devices
> are connected together.

So, can I go ahead to do this work?

Thanks!

Li Guang

Re: [Qemu-devel] [PATCH][RFC 0/14] implement power chip

[Peter Maydell]

On 20 March 2013 00:56, li guang <lig.fnst@cn.fujitsu.com> wrote:
> 在 2013-03-19二的 10:15 +0000，Peter Maydell写道：
>> The point is that how exactly power controllers connect
>> to devices, and which devices respond to reset/suspend/etc
>> is a property of the individual machine being modelled.
>> An x86 PC will be different from an ARM devboard which is
>> different again from the Exynos4 ARM SoC. So to allow this
>> flexibility, you have to let the machine model do the configuration,
>> which you do by having the model wire up the power controller
>> to the devices in the same way it's done on hardware.
>
> agree, originally, I  made all devices can realize the power
> state callbacks, e.g. if one can do suspend, then it will
> realize DeviceState::suspend, so if system go to suspend,
> this method will be called.
> do you want some explicit way to configure for machine's
> devices if they can support power state changes?

The devices should just implement appropriate signals/connections
if they have a means of talking to a power controller, and the
board model should wire them up. That's all.

>> >> Hardware does it with signals, so should we.
>> >
>> > can these signals be viewed as the calling of corresponding methods?
>>
>> In some ways, they are -- but the wiring up of the source of
>> the call to the implementation is done at runtime as devices
>> are connected together.
>
> So, can I go ahead to do this work?

Well, it's not for me to say what you should do, but you
still seem to be trying to do this with device methods,
which (as I've argued above) I think is the wrong approach.

-- PMM

Re: [Qemu-devel] [PATCH][RFC 0/14] implement power chip

[li guang]

在 2013-03-20三的 10:50 +0000，Peter Maydell写道：
> On 20 March 2013 00:56, li guang <lig.fnst@cn.fujitsu.com> wrote:
> > 在 2013-03-19二的 10:15 +0000，Peter Maydell写道：
> >> The point is that how exactly power controllers connect
> >> to devices, and which devices respond to reset/suspend/etc
> >> is a property of the individual machine being modelled.
> >> An x86 PC will be different from an ARM devboard which is
> >> different again from the Exynos4 ARM SoC. So to allow this
> >> flexibility, you have to let the machine model do the configuration,
> >> which you do by having the model wire up the power controller
> >> to the devices in the same way it's done on hardware.
> >
> > agree, originally, I  made all devices can realize the power
> > state callbacks, e.g. if one can do suspend, then it will
> > realize DeviceState::suspend, so if system go to suspend,
> > this method will be called.
> > do you want some explicit way to configure for machine's
> > devices if they can support power state changes?
> 
> The devices should just implement appropriate signals/connections
> if they have a means of talking to a power controller, and the
> board model should wire them up. That's all.

Hmm, can you give some demo of signals implementation?
(I'm hesitating to say do you mean signal() or sigaction()? :) )

> 
> >> >> Hardware does it with signals, so should we.
> >> >
> >> > can these signals be viewed as the calling of corresponding methods?
> >>
> >> In some ways, they are -- but the wiring up of the source of
> >> the call to the implementation is done at runtime as devices
> >> are connected together.
> >
> > So, can I go ahead to do this work?
> 
> Well, it's not for me to say what you should do, but you
> still seem to be trying to do this with device methods,
> which (as I've argued above) I think is the wrong approach.
> 
> -- PMM

Re: [Qemu-devel] [PATCH][RFC 0/14] implement power chip

[Peter Maydell]

On 21 March 2013 00:36, li guang <lig.fnst@cn.fujitsu.com> wrote:
> 在 2013-03-20三的 10:50 +0000，Peter Maydell写道：
>> The devices should just implement appropriate signals/connections
>> if they have a means of talking to a power controller, and the
>> board model should wire them up. That's all.
>
> Hmm, can you give some demo of signals implementation?
> (I'm hesitating to say do you mean signal() or sigaction()? :) )

No, I don't mean signals in the POSIX signals sense. For a
simple yes/no kind of connection, qemu_irq is what we currently
use. If you need something more complicated QOM should be able
to do that but I don't have an example to hand.

-- PMM

Re: [Qemu-devel] [PATCH][RFC 0/14] implement power chip

[li guang]

在 2013-03-21四的 10:41 +0000，Peter Maydell写道：
> On 21 March 2013 00:36, li guang <lig.fnst@cn.fujitsu.com> wrote:
> > 在 2013-03-20三的 10:50 +0000，Peter Maydell写道：
> >> The devices should just implement appropriate signals/connections
> >> if they have a means of talking to a power controller, and the
> >> board model should wire them up. That's all.
> >
> > Hmm, can you give some demo of signals implementation?
> > (I'm hesitating to say do you mean signal() or sigaction()? :) )
> 
> No, I don't mean signals in the POSIX signals sense. For a
> simple yes/no kind of connection, qemu_irq is what we currently
> use. If you need something more complicated QOM should be able
> to do that but I don't have an example to hand.
> 

OK, thanks!