linux-kernel - Re: [PATCH 5/8] counter/ti-eqep: add support for latched position

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <YXpbc61WAKgN0DgU@shinobu>
Date:   Thu, 28 Oct 2021 17:12:35 +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 5/8] counter/ti-eqep: add support for latched position

On Wed, Oct 27, 2021 at 10:40:15AM -0500, David Lechner wrote:
> On 10/27/21 2:44 AM, William Breathitt Gray wrote:
> > On Sat, Oct 16, 2021 at 08:33:40PM -0500, David Lechner wrote:
> >> This adds support to the TI eQEP counter driver for a latched position.
> >> This is a new extension that gets the counter count that was recorded
> >> when an event was triggered. A new device-level latch_mode attribute is
> >> added to select the trigger. Edge capture unit support will be needed
> >> to make full use of this, but "Unit timeout" mode can already be used
> >> to calculate high speeds.
> >>
> >> The unit timer could also have attributes for latched_time and
> >> latched_period that use the same trigger. However this is not a use
> >> case at this time, so they can be added later if needed.
> > 
> > I see that "latched_count" holds the captured counter count; would this
> > "latched_time" hold the captured unit timer time? If so, does that mean
> > setting the latch mode to "Unit timeout" always results in a
> > "latched_time" equal to 0 (assuming that's when the timeout event
> > triggers)?
> > 
> 
> Some `latched_*` attributes will only be useful for one `latched_mode`
> selection but not the other.
> 
> These latched registers are used to measure speed. There are two ways
> to do this. A) measuring the change in position over a fixed time and
> B) measuring the change in time for a fixed change in position. So for
> A) latched_mode would be set to trigger on timeout and we would use
> the latched_position for the measurement. For B) we would set the
> latched_mode to trigger on reading the count register and use the
> latched_time as the measurement.
> 
> ...
> 
> >>   static struct counter_comp ti_eqep_device_ext[] = {
> >> +	COUNTER_COMP_DEVICE_ENUM("latch_mode", ti_eqep_latch_mode_read,
> >> +				ti_eqep_latch_mode_write, ti_eqep_latch_modes),
> > 
> > It seems more appropriate to move this alongside "latched_count" as
> > Count extension because this is setting the trigger mode to latch the
> > respective Count's count. Or does this particular extension also affect
> > the "latched_time" capture for the unit timer?
> > 
> 
> In hardware, there are at least 3 registers that get latched that I
> recall. They are in different subsystems (main count, unit timer,
> edge capture). So as you have guessed, that is the reason for having
> the trigger selection at the device level.

Ah, I see what's going on now. I think supporting these latch registers
will involve some further considerations. I'll continue my reply in the
respective docs patch where you've gone more in depth about the
hardware.

William Breathitt Gray

Download attachment "signature.asc" of type "application/pgp-signature" (834 bytes)