On 10 November 2018 at 15:20, Mark Cave-Ayland <mark.cave-ayl...@ilande.co.uk> wrote: > On 09/11/2018 10:31, Peter Maydell wrote: >> I think the code I saw that looked like a non-QOMified >> device was cpu_timer_create().
> Ah okay. The above timers are certainly internal CPU timers rather than > external, so > should they still be QOMified? How are timers modelled for other CPUs? So, a couple of caveats first: * I haven't really looked at the sparc code * as I mentioned elsewhere in this thread, I'm not sure this is necessarily our most-important cleanup/refactoring There are a couple of "QOM-style" ways I know of to do cpu timers: (1) the Arm Cortex-A9/A15 have some timers that are part of the cpu in the sense that they're always there in hardware, but they're just memory-mapped devices at a known address. We model these as the usual sort of standalone QOM device, with a convenience container object in hw/cpu/ that instantiates the various devices and wires things up. (2) the newer Arm "generic timers" are more closely coupled to the CPU, because they're programmed via system registers. These we actually model as part of the CPU object itself, with the code all in target/arm. The CPU object then exposes outbound GPIO lines which are the interrupt signals for the timers, and which the board or SoC code wires up to the interrupt controller. So it depends on how closely coupled the sparc cpu timers are to the cpu, I think. thanks -- PMM
