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
