[Qemu-devel] [RFC] Generic Clock and Reset Control

[Peter Crosthwaite]

Hi All,

Im looking into how to do clock control in QEMU. For 95% of devices
this is irrelevant and timing is not worth modelling, however it holds
some relevance for a few things for us, mainly timers. But we also
want to model individual clock gating for a large number of devices.
That is, if a device has a clock frequency of 0 it stops functioning
regardless of whether the device models timing or not.

Whats a good way to propagate clocks from one device to the next? I
know the idea of using GPIOs has been floated before - a clock is just
a GPIO where the int value of the GPIO is the frequency. A value of 0
can be used to gate the clock. GPIOs is however a slippery slope, at
least until we get named GPIOs up and running.

A TYPE_CLOCKABLE interface is an another idea, but falls over quickly
when you have multiple clock domains for the one device.

Building clock support into TYPE_DEVICE is the last idea. I think this
is reasonable. If a device truly has no clock it can opt out of this
feature. It can work much the same way as GPIOs, just a little more
tailored and robust.

Yet a further complication is I want to be able to define clock
domains on different levels of the QOM heirachy. The main one is I
want a clock domain for just the bus attachment of a device on the
SysBus level. If the bus input clock is 0 then the bus clock is gated
and the device ignores MMIO transactions. I want to derive a type from
TYPE_SYS_BUS_DEVICE that defines this clock behaviour. I then make my
suite of devices derive from this new type to pickup my gateable bus
clock with 0 boilerplate code. My specific devices then define their
own sperate clock domains that add to or piggy back off the already
existing sysbus clock.

Now the same thing question all over again for resets. The argument
seems analogous to the clock one I have put forward here. All of the
above options are valid for creating multiple reset options. PMM
developed some ideas on this in an earlier thread but id like to add
clocks into the discussion for completeness as I am seeing some
overlap in the underlying problems.

Regards,
Peter