On Fri, Jun 5, 2015 at 4:18 PM, Peter Maydell <peter.mayd...@linaro.org> wrote: > On 6 June 2015 at 00:06, Peter Crosthwaite <peter.crosthwa...@xilinx.com> > 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 >
