On Mon, 2016-06-06 at 15:01 +0100, Peter Maydell wrote: > On 27 May 2016 at 06:08, Andrew Jeffery <and...@aj.id.au> wrote: > > > > Value matching allows Linux to boot with CONFIG_NO_HZ_IDLE=y on the > > palmetto-bmc machine. Two match registers are provided for each timer. > > > > Signed-off-by: Andrew Jeffery <and...@aj.id.au> > > --- > > > > The change pulls out ptimer in favour of the regular timer infrastructure. > > As a > > consequence it implements the conversions between ticks and time which > > feels a > > little tedious. Any comments there would be appreciated. > So what would you need from ptimer to be able to implement value > matching with it; or is ptimer just too far away from what this > timer device needs to make that worthwhile ?
I gave expanding the ptimer API some (quick) consideration. It feels
like it might be a departure from "simple" and depending on your view a
departure from "periodic"; though an interrupt for a given match value
is at least periodic with respect to itself. In this case the hardware
supports two match values, so if we add something to the ptimer API it
would need to support an arbitrary number of values
(ptimer_{add,del}_match(...)?). In this case the hardware counts down,
but just as we're doing currently we can fix the values to give the
right behaviour.
I guess the final thought was that you queried me on the #include
"qemu/main-loop.h" in the original patch, and that moving away from
ptimer would eliminate it.
If we come up with an acceptable match value API for ptimer I can
implement it and resend.
Cheers,
Andrew
signature.asc
Description: This is a digitally signed message part
