On Thu, Sep 15, 2016 at 12:48:08PM +0100, Bryan O'Donoghue wrote: > On Thu, 2016-09-15 at 12:20 +0100, Mark Rutland wrote: > > For example, you have absolutely no guarantee as to what backs > > get_cycles(). Despite this, the code assumes that get_cycles() is > > backed by something running at the frequency described in a > > "google,greybus-frame-time-counter" node. > > > > Even if this *happens* to match what some piece of arch code provides > > today on some platform, it is in no way *guaranteed*. > > That's the point though, if you declare "google,greybus-frame-time- > counter" in your platform code - then you can use 'get_cycles()' in > this manner
To be clear, *some* properties (and perhaps additional nodes) may need to be in the DT, in order to capture the hardware property or relationship that you are reliant upon. However, the DT cannot possibly know anything about get_cycles(), as get_cycles() is a kernel implementation details that's subject to arbitrary change at any point in time, independent of the DT. The "google,greybus-frame-time-counter" node, as it stands, does not capture any relevant hardware detail, and does not belong in the DT. > > Without a higher-level view of what you're trying to achieve, it's > > not clear to me whether get_cycles() is the right interface. > > I appreciate that. Until that's clarified, we won't make any progress here. Thanks, Mark.