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

[Peter Crosthwaite]

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:
>> 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

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

>  * the reset line doesn't always match up with the DeviceClass::reset
>    semantics
>

Then its not a PoR equivalent (and thus from QEMUs perspective not a
"reset" at all). Its a device specific GPIO. The same applies to 18
lines of A9MPx4, althought that is a container object so im guessing
some of those 18 resets will pass through as PoR equivalents to the
subdevices?

So working on that case, suppose GIC (a subcomponent of Cortex-A9MPx4)
has a PoR equivalent wired directly as one of the 18 resets. The
container will have to explicitly define all 18 resets, however, it
can pass GICs through to the TYPE_DEVICE reset for the GIC instance,
saving on having to hack up GIC to explicitly have a reset GPIO.

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.

Regards,
Peter


> 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
>