Re: [Qemu-devel] [PATCH 3/5] hw/arm/pxa2xx: Add reset method for pxa2xx_ssp

[Peter Crosthwaite]

On Fri, Jun 5, 2015 at 4:18 PM, Peter Maydell <address@hidden> wrote:
> On 6 June 2015 at 00:06, Peter Crosthwaite <address@hidden> wrote:
>> But I have some follow up design questions, mainly in that I have
>> started using individual device resets that back onto the ->reset hook
>> to implement reset controllers. This means an IRQ source should reset
>> its IRQ pin to notify its sinks of the state change as those sinks
>> will not get a reset callback.
>>
>> I know its not supported by the current reset semantic but can we
>> start doing this going forward?
>
> Device reset is a sink and a quagmire. Note incidentally that what
> we call "reset" in QEMU is actually "we hard powercycled the simulation",
> not an emulated reset. If you can propose some coherent and workable
> semantics I think it would be nice if we could clean things up.
> (You may find you need two-phase reset by analogy with two-phase init...)
>

So I don't really like the predetermined finite number of init phases
as the number of phases seems to just grow over time. We already have
about 4 phases of init if you count all of init() post_init(),
realize() and machine_init_done-notifiers. Resets will probably go the
same way. Can we instead have a dependency management system where
reset handlers can register deps? If you rely on another device for
your reset (e.g. a boot-loader must wait out a CPU reset) then it
makes sense you have awareness of that dep and can use a QOM link
navigation to register a reset dep. Devs can register multiple resets
if deps demand but I would expect that to be super rare.

The resetter functionality then ensures a topological ordering of the
resets for the reset.

IRQs and GPIOs can form loops though, so I think it is a case of
machines that support partial reset need to update their GPIOs on
reset to remove a large number of reset ordering deps.

So my semantics are:

* The reset function must reset the device to POR state.
* Resets may depend on any number of other resets to occur first. No
loops in the deps.
* If a device is reset concurrently with one of its deps, the dep is
guaranteed to go first
* a dev with externally provided state that doesn't register reset dep
may need to preserve that state through reset (e.g. state of a GPIO
input).
* Systems can register reset domains, with reset operations respecting
deps within
* It is an error to define a reset domain that doesn't include all deps.
* By extension a trivial one-device domain can implement an individual
core reset (if the platform/dev supports that)

FWIW, I already have reset GPIOs for ARM CPUs that back onto
device::reset. These in turn connect to the reset controller to
support run time CPU reset via hardware peripheral.

Regards,
Peter

> -- PMM
>