Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Message-ID: <d47c842b-579d-b119-73f9-e8c95984b30b@baylibre.com>
Date:   Mon, 8 Aug 2022 10:58:22 +0200
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.1.0
Subject: Re: [PATCH v3 2/2] iio: time: capture-tiecap: capture driver support
 for ECAP
To:     William Breathitt Gray <william.gray@linaro.org>
Cc:     Jonathan Cameron <jic23@kernel.org>, robh+dt@kernel.org,
        krzysztof.kozlowski+dt@linaro.org, lars@metafoo.de,
        linux-iio@vger.kernel.org, devicetree@vger.kernel.org,
        linux-kernel@vger.kernel.org, mranostay@ti.com
References: <20220728175124.468461-1-jpanis@baylibre.com>
 <20220728175124.468461-3-jpanis@baylibre.com>
 <20220731164116.30e91f34@jic23-huawei>
 <11b7436b-5c31-671e-ba77-435fe8e3b767@baylibre.com>
 <98d17617-72b5-6330-d4f5-1bece928ceab@baylibre.com> <YvBZQsiAm6f3yxME@fedora>
Content-Language: en-US
From:   Julien Panis <jpanis@baylibre.com>
In-Reply-To: <YvBZQsiAm6f3yxME@fedora>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: bulk


On 08/08/2022 02:30, William Breathitt Gray wrote:
> Hi Julien,
>
> I've taken a cursory look over the TI ECAP reference guide and your
> descriptions in this thread. I think a device driver for this would fit
> better in the Counter subsystem than IIO.
>
> First I want to correct a minor misunderstanding: the "timestamp"
> member of struct counter_event is simply a way to identify Counter
> events on the system as a way of grouping multiple Counter watches. In
> other words, the "timestamp" member here represents when a Counter event
> was detected by the system, not when an event was logged on the counter
> device hardware. Instead, hardware timestamps such as the CAPx registers
> would be provided by the "value" member of struct counter_event.
>
> Now, I have a few ideas for how we could expose the timestamps using a
> Counter device driver, but first I want to make sure I understand
> correctly what's happening in this device. If I understand correctly, we
> have the following device components:
>
> * CTR: 32-bit counter timer
> * Mod4: 2-bit counter
> * CAP1-CAP4: four 32-bit registers, each indepedently store a timestamp
> * ECAP: input signal providing event trigger edges
>
> Four edge polarities are configured corresponding to each CAPx register,
> yet the input signal is still the same single ECAP pin. The event that
> is fired is instead determined by the Mod4 counter: when Mod4 is 0 and
> the edge of ECAP matches the polarity configured for CAP1 then an event
> is triggered which saves the current CTR value to CAP1 and increments
> Mod4 to 1, etc.
>
> Is my understanding of how this device behaves correct?

Hi William. Thank you for your help.
Yes, your understanding of how this device behaves is correct.

>
> If so, then one possible way to represent this device in the Counter
> sysfs tree is something like this:
>
> * CTR: /sys/bus/counter/devices/counterX/count0/count
> * Mod4: /sys/bus/counter/devices/counterX/count1/count
> * CAP1: /sys/bus/counter/devices/counterX/count1/cap1
> * CAP2: /sys/bus/counter/devices/counterX/count1/cap2
> * CAP3: /sys/bus/counter/devices/counterX/count1/cap3
> * CAP4: /sys/bus/counter/devices/counterX/count1/cap4
> * ECAP: /sys/bus/counter/devices/counterX/signal0/signal
> * polarity1: /sys/bus/counter/devices/counterX/signal0/cap1_polarity
> * polarity2: /sys/bus/counter/devices/counterX/signal0/cap2_polarity
> * polarity3: /sys/bus/counter/devices/counterX/signal0/cap3_polarity
> * polarity4: /sys/bus/counter/devices/counterX/signal0/cap4_polarity
>
> This is just a tentative arrangement (you could also include "enable"
> attributes as well), but it should give you an idea of how it could be
> organized.
>
> In your driver, you could then use counter_push_event() whenever you get
> an event triggered. In userspace, your application will add Counter
> watches for the CAPx registers they want. When an event triggers,
> userspace can then received all four CAP register values at the same
> time via the respective /dev/counterX character device node.
>
> Would this design work for your needs?

Yes, that would work for my needs.
The "how" is not fully clear to me yet, since I never used counter 
subsystem. But the
best way to understand better how it works is probably to start working 
with it. :-)
So, next patch version will be based on counter subsystem.

>
> William Breathitt Gray