-
Notifications
You must be signed in to change notification settings - Fork 340
Enable re-reading the channel data format #1368
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Conversation
The problem: The scan-element format (e.g. le:S24/32>>0 vs le:S20/32>>0) can change at runtime when users modify oversampling / resolution attributes. Libiio caches the original type string at context creation time with no means of changing it. This could affect downstream size calculations and conversion logic. The fix: - Add public API: iio_channel_refresh_data_format() - explicit manual refresh - A refresh on all relevant channels is done right before buffer enable. This guarantees format correctness at the moment streaming starts. Note: this implementation targets only the local backend. The rest of the backends need to be updated as well. Signed-off-by: Dan Nechita <[email protected]>
|
rather than forcing this logic into all the applications - (refreshing things) - why not just do this inside libiio? (ie. - for this one special one - don't cache it). |
|
When I was looking into it I was trying to make scan_type an attribute, so it would be read like the others (e.g., _raw) Per ABI, it contains a general
iio_infoThe paths (e.g., I see in the source code hardcoded I believe this way would be easier to set rules of which should or should not be cached. |
Agree. I guess we could read it (cache it) before enabling buffering. A driver changing oversampling while buffering is most likely a bug in driver code itself. Or we just read it from the device "on demand".
Yes, that's not good...
Also note that the above directory together with buffer/ is legacy (I guess we still need to be aware of them for older kernels) but if buffer0/ exists, that should be the one we look at. |
Yes, that is exactly what is happening with the current changes, the format type is refreshed exactly before enabling the buffer. This step would be enough for most use cases. However, I wanted to provide users the ability to choose the moment when the caching is done as there might be scenarios where users modify the oversampling and know format might change and can call I thought about making iio_channel_get_data_format() always perform a fresh read instead of caching, but this would create significant performance overhead for already existing applications that call this function on every buffer element. |
|
Is this just a break in the social contract between the kernel and libiio then? kernel if it wants to have things be dynamic - should be suffixing with Maybe @pcercuei or @larsclausen or @mhennerich knows the vision better... |
PR Description
The problem:
The scan-element format (e.g. le:S24/32>>0 vs le:S20/32>>0) can change at runtime when users modify oversampling / resolution attributes. Libiio caches the original type string at context creation time with no means of changing it afterwards.
This could affect downstream size calculations and conversion logic.
The fix:
Note: this implementation targets only the local backend. The rest of the backends need to be updated as well.
PR Type
PR Checklist