Re: [Q] Frequency & duty cycle measurement?

[William Breathitt Gray <wbg@kernel.org>]

[-- Attachment #1: Type: text/plain, Size: 3751 bytes --]

On Thu, Jan 30, 2025 at 02:59:20PM +0100, Csókás Bence wrote:
> Hi William,
> 
> On 2025. 01. 27. 16:00, William Breathitt Gray wrote:
> > If RA and RB are provided as a memory buffer on your device, you can
> > instead expose them via DEFINE_COUNTER_ARRAY_CAPTURE() such as the
> > ti-ecap-capture driver does, then perform your userspace computations
> > by utilizing those respective "capture" array attribute values (via
> > chrdev like the example above or alternatively via sysfs).
> 
> Thanks for your extensive explanation! With DEFINE_COUNTER_ARRAY_CAPTURE() I
> was able to expose RA and RB as
> `/sys/bus/counter/devices/counter0/count0/capture{0,1}`, and could verify
> that by replacing `devmem` calls with read()-reopen(), our PoC code still
> works. Now I want to use the chardev interface, but I couldn't find how to
> set up the watches appropriately. So far I have:
> 
> 	{
> 		.component.type = COUNTER_COMPONENT_EXTENSION,
> 		// also tried COUNTER_COMPONENT_COUNT
> 		.component.scope = COUNTER_SCOPE_COUNT,
> 		.component.parent = 0,
> 		.component.id = X, // also tried this instead:
> 		// .channel = X,
> 		.event = COUNTER_EVENT_CAPTURE,
> 	},
> 
> However, with this, the first read() never comes back.
> 
> Bence

Hi Bence,

Are you still having trouble with this? Is "X" the
capture{0,1}_component_id value?

I apologize, the Generic Counter character device interface is
underdocumented so it can be a bit confusing at first; I'll submit a
patch improving the documentation later this cycle when I get a chance.
For now, let's walk through how to create an appropriate Counter watch
for the capture extension components you have.

The first step is to decide which event we'll monitor and on which
channel: we want to monitor Capture events so that's
COUNTER_EVENT_CAPTURE, and we want event channel 0 (n.b. 0 because
that's the channel parameter value passed to counter_push_event() in the
driver).

The next step is to choose the components you wish to watch: Count 0's
capture0 and capture1 extensions. So type is COUNTER_COMPONENT_EXTENSION
because we want to watch extensions, scope is COUNTER_SCOPE_COUNT
because we want Count extensions, and parent is 0 because we want
Count 0's Count extensions.

Finally, we need to set the component id for each extension. You get a
particular component's id by reading the respective *_component_id sysfs
attribute: so for capture{0,1} you would read capture{0,1}_component_id
respectively. These component id values potentially can change with
future driver updates, so for robustness your userspace application
should read the respective *_component_id sysfs attribute itself rather
than hardcoding the component id in the Counter watch.

However, for the sake of simplicity in this example, I'll assume the
component ids are 42 and 43 respectively for capture0 and capture1. That
gives us the following two watches:

        {
                .component.type = COUNTER_COMPONENT_EXTENSION,
                .component.scope = COUNTER_SCOPE_COUNT,
                .component.parent = 0,
                .component.id = 42,
                .event = COUNTER_EVENT_CAPTURE,
                .channel = 0,
        },
        {
                .component.type = COUNTER_COMPONENT_EXTENSION,
                .component.scope = COUNTER_SCOPE_COUNT,
                .component.parent = 0,
                .component.id = 43,
                .event = COUNTER_EVENT_CAPTURE,
                .channel = 0,
        },

Does this resolve your chardev read issue? If you're still having
troubling, just let me know and we can troubleshoot further to figure
out what's going on.

William Breathitt Gray

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]