On Wed, Feb 20, 2013 at 10:29 PM, Peter Maydell <peter.mayd...@linaro.org> wrote: > On 20 February 2013 12:21, Peter Crosthwaite > <peter.crosthwa...@xilinx.com> wrote: >> On Wed, Feb 20, 2013 at 8:50 AM, Peter Maydell <peter.mayd...@linaro.org> >> 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 >
