[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <YXpYUIUIQe+oxwXK@shinobu>
Date: Thu, 28 Oct 2021 16:59:12 +0900
From: William Breathitt Gray <vilhelm.gray@...il.com>
To: David Lechner <david@...hnology.com>
Cc: linux-iio@...r.kernel.org, Robert Nelson <robertcnelson@...il.com>,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH 4/8] docs: counter: add unit timer sysfs attributes
On Wed, Oct 27, 2021 at 10:30:36AM -0500, David Lechner wrote:
> On 10/27/21 1:46 AM, William Breathitt Gray wrote:
> > On Sat, Oct 16, 2021 at 08:33:39PM -0500, David Lechner wrote:
> >> This documents new unit timer sysfs attributes for the counter
> >> subsystem.
> >>
> >> Signed-off-by: David Lechner <david@...hnology.com>
> >
> > Hello David,
> >
> > The unit timer is effectively a Count in its own right, so instead of
> > introducing new sysfs attributes you can just implement it as another
> > Count in the driver. Count 0 is "QPOSCNT", so set the name of this new
> > Count 1 as "Unit Timer" (or the datasheet naming if more apt) to
> > differentiate the Counts. You can then provide the "unit_timer_enable",
> > "unit_timer_period", and "unit_timer_time" functionalities as respective
> > Count 1 extensions ("enable" and "period") and Count 1 "count".
Actually if the counter function here is COUNTER_FUNCTION_DECREASE, then
instead of introducing a new "period" extension, define this as a
"ceiling" extension; that's what ceiling represents in the Counter
interface: "the upper limit for the respective counter", which is the
period of a timer counting down to a timeout.
William Breathitt Gray
> >
> > If you believe it appropriate, you can provide the raw timer ticks via
> > the Count 1 "count" while a nanoseconds interface is provided via a
> > Count 1 extension "timeout" (or something similar).
> >
>
> Sounds reasonable.
>
Download attachment "signature.asc" of type "application/pgp-signature" (834 bytes)
Powered by blists - more mailing lists