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
