qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Peter Maydell <peter.maydell@linaro.org>
To: li guang <lig.fnst@cn.fujitsu.com>
Cc: qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [PATCH][RFC 0/14] implement power chip
Date: Tue, 19 Mar 2013 10:15:14 +0000	[thread overview]
Message-ID: <CAFEAcA_QdNxobgUTQokA3ZXEAUt1sVxJbgYtx2qxgKDXsWpfxg@mail.gmail.com> (raw)
In-Reply-To: <1363685481.21129.198.camel@liguang.fnst.cn.fujitsu.com>

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

  reply	other threads:[~2013-03-19 10:15 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-03-13  8:01 [Qemu-devel] [PATCH][RFC 0/14] implement power chip liguang
2013-03-13  8:01 ` [Qemu-devel] [PATCH][RFC 01/14] gitignore: ignore more files liguang
2013-03-21  6:24   ` li guang
2013-03-21 10:43     ` Peter Maydell
2013-03-13  8:01 ` [Qemu-devel] [PATCH][RFC 02/14] qdev: add power management method liguang
2013-03-18  8:25   ` Andreas Färber
2013-03-18  8:29     ` li guang
2013-03-13  8:01 ` [Qemu-devel] [PATCH][RFC 03/14] qdev: remove redundant abort() liguang
2013-03-18  8:26   ` Andreas Färber
2013-03-21  6:24     ` li guang
2013-03-13  8:01 ` [Qemu-devel] [PATCH][RFC 04/14] qdev: add power on/off/suspend/wakeup handler liguang
2013-03-18  8:31   ` Andreas Färber
2013-03-18  8:34     ` li guang
2013-03-13  8:01 ` liguang
2013-03-13  8:01 ` [Qemu-devel] [PATCH][RFC 06/14] sysemu: remove PowerReason in sysemu.h liguang
2013-03-13  8:01 ` [Qemu-devel] [PATCH][RFC 07/14] acpi: refactor acpi wakeup function liguang
2013-03-13  8:01 ` [Qemu-devel] [PATCH][RFC 08/14] ich9: make lpc's reset also do pm_reset liguang
2013-03-13  8:01 ` [Qemu-devel] [PATCH][RFC 09/14] ich9: do lpc's power on by reset function liguang
2013-03-13  8:01 ` [Qemu-devel] [PATCH][RFC 10/14] piix4: refactor piix4's power callbacks liguang
2013-03-13  8:01 ` [Qemu-devel] [PATCH][RFC 11/14] pckbd: refactor pckbd's " liguang
2013-03-13  8:01 ` [Qemu-devel] [PATCH][RFC 12/14] ps2: call ps2_{kbd, mouse}_reset in kbd_reset liguang
2013-03-13  8:01 ` [Qemu-devel] [PATCH][RFC 13/14] parallel: refactor parallel_reset function liguang
2013-03-13  8:01 ` [Qemu-devel] [PATCH][RFC 14/14] uhci: refactor uhci's power callbacks liguang
2013-03-15  0:59 ` [Qemu-devel] [PATCH][RFC 0/14] implement power chip li guang
2013-03-18  6:12   ` li guang
2013-03-18  8:34 ` Andreas Färber
2013-03-18  8:41   ` li guang
2013-03-18 11:07 ` Peter Maydell
2013-03-19  0:55   ` li guang
2013-03-19  9:05     ` Peter Maydell
2013-03-19  9:31       ` li guang
2013-03-19 10:15         ` Peter Maydell [this message]
2013-03-20  0:56           ` li guang
2013-03-20 10:50             ` Peter Maydell
2013-03-21  0:36               ` li guang
2013-03-21 10:41                 ` Peter Maydell
2013-03-22  0:31                   ` li guang

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAFEAcA_QdNxobgUTQokA3ZXEAUt1sVxJbgYtx2qxgKDXsWpfxg@mail.gmail.com \
    --to=peter.maydell@linaro.org \
    --cc=lig.fnst@cn.fujitsu.com \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).