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

[Peter Maydell]

On 6 June 2015 at 02:37, Peter Crosthwaite <address@hidden> wrote:
> On Fri, Jun 5, 2015 at 4:18 PM, Peter Maydell <address@hidden> wrote:
>> 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.

I don't think this will work, because as a device you don't know
what you're connected to. The idea I had was something like:
 * phase 1, all devices reset their internal state and reset
   outbound signal lines accordingly
   They also set a flag to say "being held in reset"; calls
   inbound for "your gpio line changed" are only handled to
   note the new state of the line, not to trigger device state change
 * phase 2, devices go out of reset: they do whatever the device
   does when it leaves reset and samples the state of its inbound
   signals (which might result in changing state, outbound signal
   levels, etc)

These basically correspond to "leading edge of reset" and
"trailing edge of reset". If you're modelling them with QEMU
IRQs then they'd be "things done when level goes 0->1" and
"things done when level goes 1->0".

There is an obvious problem here, though, which is that this
is (a) an enormous upheaval in every device and (b) breaking
migration, because of all the new state.

Anthony Liguori had a vaguely similar idea at one point IIRC,
but done by making the QEMU IRQ lines maintain internal state
(at the moment they don't at all) rather than having the device
do it. It's probably worth trawling the list archives for earlier
discussions and ideas...

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

How many cases really need this dependency-driven reset rather
than just being "I have an external signal that tells me when
to reset" ? There are oddities like the boot loader, but is there
anything else?

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

Right, this is what I would think of as the "normal case".

-- PMM