[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <1173230305.24738.529.camel@localhost.localdomain>
Date: Wed, 07 Mar 2007 02:18:24 +0100
From: Thomas Gleixner <tglx@...utronix.de>
To: Dan Hecht <dhecht@...are.com>
Cc: Jeremy Fitzhardinge <jeremy@...p.org>,
Zachary Amsden <zach@...are.com>, Ingo Molnar <mingo@...e.hu>,
akpm@...ux-foundation.org, ak@...e.de,
Virtualization Mailing List <virtualization@...ts.osdl.org>,
Rusty Russell <rusty@...tcorp.com.au>,
LKML <linux-kernel@...r.kernel.org>,
john stultz <johnstul@...ibm.com>
Subject: Re: + stupid-hack-to-make-mainline-build.patch added to -mm tree
On Tue, 2007-03-06 at 16:53 -0800, Dan Hecht wrote:
> > Ooops. I completely forgot, that you get the absolute expiry time
> > already in ktime_t format (nanoseconds) when dev->set_next_event() is
> > called.
> >
> > dev->next_event = expires;
> >
> > is done right before the call.
> >
> > So it's already there for free.
> >
> >
>
> Okay. I noticed that but didn't think it was okay to use since it
> didn't seem like it was set up for the clock_event_device code's use, so
> seemed like a conceptual interface violation to go digging around in
> there.
Yes it is.
I just wanted to point out that you can use it until I'm awake enough to
implement it proper.
> Also, wasn't one of the points of clockevents to prevent the device code
> from doing conversions between nanoseconds and clicks themselves? Don't
> we really want the clockevents generic layer to do this conversion
> between monotonic nanonseconds to absolute device clicks and then give
> the device code that value, so the device layer doesn't perform any
> conversions?
Right. But this applies only to deltas, as the conversion of absolute
time values gets ugly, i.e. 128bit math
IMO the paravirt interfaces should use nanoseconds anyway for both
readout and next event programming. That way the conversion is done in
the hypervisor once and the clocksources and clockevents are simple and
unified (except for the underlying hypervisor calls).
> On an unrelated note, can you explain what the difference between
> CLOCK_EVT_MODE_UNUSED and CLOCK_EVT_MODE_SHUTDOWN modes are and what the
> legal state transitions are? (or point me to a document describing
> this). At least on i386, all clock event devices treat them the same;
> do we really need both?
UNUSED:
The device is registered, but not used by any clockevents client
SHUTDOWN:
The device is registered, claimed by a clockevents client, but
momentarily not active.
The clock events device can treat UNUSED and SHUTDOWN basically in the
same way.
tglx
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists