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

[Peter Maydell]

On 20 February 2013 12:21, Peter Crosthwaite
<address@hidden> wrote:
> On Wed, Feb 20, 2013 at 8:50 AM, Peter Maydell <address@hidden> wrote:
>> If we're just solving a PC problem here and it really is just
>> "only reset the CPU, nothing else", why don't we give the
>> x86 CPU a qemu_irq input for "reset this CPU core" and wire it
>> up to the relevant bit of hardware on the PC board? I don't
>> see the need for a specific 'qemu_system_cpu_reset()' here
>> (and not having one avoids the swamp of trying to define its
>> semantics...)

> 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
 * some devices have more than one (eg a Cortex-A9MPx4 has 18 different
   reset input lines)
 * the reset line doesn't always match up with the DeviceClass::reset
   semantics

I guess maybe if there was a way to say 'this device suppresses
the default reset input implementation'.

(Plus as you note we'd have to actually support named GPIO inputs
to have the base class provide an input pin that didn't get
tangled up with the device's own inputs.)

-- PMM