[Q] Frequency & duty cycle measurement?
Csókás Bence
csokas.bence at prolan.hu
Wed Feb 5 01:30:26 PST 2025
Hi,
On 2025. 02. 05. 0:37, William Breathitt Gray wrote:
> Are you still having trouble with this? Is "X" the
> capture{0,1}_component_id value?
X is 0/1 from `/sys/bus/counter/devices/counter0/count0/capture{0,1}`,
which is also equal to the respective `capture{0,1}_component_id`, since
I don't have any other counters. I checked that beforehand.
> 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.
After much tinkering and reading of the `counter-chrdev.c` code, I now
see *something*, although it's much slower to make a measurement than
the sysfs `reopen()` hack.
> 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.
I had no success using `channel = 0`, only data from `capture0` comes
back. If I set both `channel` AND `component.id` to X, then I start to
see similar values than what I get from reading sysfs. (For now I
hard-coded all values; I agree that the correct way would be to read
component IDs from sysfs, but this is still a PoC...)
Did I do something wrong in implementing the driver maybe? (See the
submitted patches.) And any idea as to why I might be seeing the slowdown?
Bence
More information about the linux-arm-kernel
mailing list