qemu-devel
[Top][All Lists]
Advanced

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

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


From: li guang
Subject: Re: [Qemu-devel] [PATCH][RFC 0/14] implement power chip
Date: Thu, 21 Mar 2013 08:36:14 +0800

在 2013-03-20三的 10:50 +0000,Peter Maydell写道:
> On 20 March 2013 00:56, li guang <address@hidden> 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





reply via email to

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