Hi; this patchset proposes a couple of new APIs for Clock, which I found I needed/wanted for a work-in-progress patchset.
In this v2, the only change from the RFC series is that as Luc suggested I have made the clock-callback registration mechanisms all take a new parameter specifying the mask of events which the callback should be invoked for. (This is instead of calling all callbacks on all events and requiring them to look at their 'events' argument to see if they should ignore the call.) If people prefer I can keep hold of these patches until I have the board-support series that makes use of them ready to post; but I think if we're happy with the new APIs we could reasonably put them in to the tree sooner (especially since patch 1 means updates to all input Clock users). The problem the first two patches are trying to solve is that I found that I wanted the old value of the Clock's period when my device got a notification about a frequency/period change. The current ClockCallback API calls you after the period has changed, so the Clock is already using the new period. I wanted this because my timer device has a register that's basically a free-running up-counter; the value of that counter can be calculated with: s->ticks_then + clock_ns_to_ticks(s->clk, now - s->ns_then); where (ns_then, ticks_then) are a tuple of a QEMU_CLOCK_VIRTUAL time and the tick count at that point. Whenever the clock frequency changes we calculate a new (ns_then, ticks_then) to use as the baseline for future counter value reads, but in order to do that we must calculate ticks_then using the *old* clock period. My solution to this is to add a ClockEvent argument to the callback function, which is an enum: ClockPreUpdate : callback called before period change ClockUpdate : callback called after period change When a callback function is registered a mask of event values tells the framework which events the callback should be called for. The problem the third patch addresses is that we don't have a function for "tell me how many times this clock would tick in this length of time". clock_ns_to_ticks() does the inverse of the clock_ticks_to_ns() that we already have. Two points in particular where comment would be useful: * I chose to make the overflow case (where a clock has a very short period and the specified length of time is very long, so the clock would tick more than UINT64_MAX times) just let the value wrap around, on the basis that usually this is being used to calculate a guest register value that's in a 64 bit or 32 bit register, and so wrap-around is the right behaviour. But I'm not 100% set on this if somebody has a better idea. * The calculation needs to do a 96-bit / 64 bit => 64 bit division, for which the best thing we have is divu128(). This is particularly painful on 32-bit hosts. I don't suppose there's anything clever we can do to make this better ? Patch 4 just uses clock_ns_to_ticks() in the one place in the current codebase where we're currently using clock_ticks_to_ns() and manual calculation. thanks -- PMM Peter Maydell (4): clock: Add ClockEvent parameter to callbacks clock: Add ClockPreUpdate callback event type clock: Add clock_ns_to_ticks() function hw/timer/npcm7xx_timer: Use new clock_ns_to_ticks() docs/devel/clocks.rst | 71 ++++++++++++++++++++++++++++---- include/hw/clock.h | 63 +++++++++++++++++++++++++++- include/hw/qdev-clock.h | 17 +++++--- hw/adc/npcm7xx_adc.c | 2 +- hw/arm/armsse.c | 9 ++-- hw/char/cadence_uart.c | 4 +- hw/char/ibex_uart.c | 4 +- hw/char/pl011.c | 5 ++- hw/core/clock.c | 23 +++++++++-- hw/core/qdev-clock.c | 8 ++-- hw/mips/cps.c | 2 +- hw/misc/bcm2835_cprman.c | 23 +++++++---- hw/misc/npcm7xx_clk.c | 26 ++++++++++-- hw/misc/npcm7xx_pwm.c | 2 +- hw/misc/zynq_slcr.c | 5 ++- hw/timer/cmsdk-apb-dualtimer.c | 5 ++- hw/timer/cmsdk-apb-timer.c | 4 +- hw/timer/npcm7xx_timer.c | 6 +-- hw/watchdog/cmsdk-apb-watchdog.c | 5 ++- target/mips/cpu.c | 2 +- 20 files changed, 226 insertions(+), 60 deletions(-) -- 2.20.1
