Re: [Qemu-devel] [RFC PATCH] Distinguish between reset types

[Peter Maydell]

On 20 February 2013 12:47, Peter Crosthwaite
<address@hidden> wrote:
> On Wed, Feb 20, 2013 at 10:29 PM, Peter Maydell
> <address@hidden> wrote:
>> On 20 February 2013 12:21, Peter Crosthwaite
>> <address@hidden> wrote:
>>> Could we be more general and implement this on the TYPE_DEVICE level
>>> (rather than X86_CPU)? I want this GPIO-as-reset feature for all Zynq
>>> devices cpus and preihperals alike. The Zynq power controller has
>>> software controllable individual reset for every device in the system
>>> and my plan-A was to do it as GPIOs. To implement the reset gpio-ins
>>> however I was thinking do it in one swift stroke by adding the single
>>> GPIO on the TYPE_DEVICE layer that backs onto DeviceClass-.>reset.
>>
>> The trouble is that:
>>  * some devices have no reset GPIO line
>
> Is there any harm in just not connecting the default reset GPIO? Or if
> you are pedantic allow the class definition to opt-out and inhibit
> generation of the GPIO.
>
>>  * some devices have more than one (eg a Cortex-A9MPx4 has 18 different
>>    reset input lines)
>
> Yeh you are lost in this case. But my intended semantics for the
> TYPE_DEVICE reset GPIO is it is a power on reset (PoR) with equivalent
> function to DeviceClass->reset

I don't think this is a useful thing to model. What is actually
useful to model is "what does the device do when its hardware
reset line is asserted" (which might be the same as power on reset
but isn't required to be so). We can have a default convenience
implementation which is "reset like a power cycle", but that doesn't
mean the semantics of the reset GPIO line are *defined* to be "reset
like a power cycle". It just means that if your reset line's semantics
are different you can't use the convenience implementation. (Also
that you can't rely on every device having a 'reset' GPIO line,
if the hardware doesn't either. But that's not a problem I think.)

If you're trying to model the case of "my power controller actually
forcibly powers down subsets of the board" you should already be
able to do that by calling the relevant object reset methods
[possibly via some indirection through suitably constructed containers].
Powering down a section of the board isn't done by asserting input
lines to each affected device; the mechanism is different and the
modelling should be too.

> It just strikes me as a workable solution for the 90% case then we can
> go you full custom GPIO solution for the harder ones.

Mmm, as long as there's a way to turn it off and/or to override
the implementation it should be ok as a default/convenience
method.

-- PMM