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 <address@hidden> 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?