flow:iio: Add Proximity sensor Category support into iio node #1986
Conversation
|
@lblim @barbieri @edersondisouza @neofang please help to review, this PR is used for issue #1971. It will read the sysfs entity in_proximity_raw(APDS9960/APDS9930), to get the raw data. |
| @@ -803,6 +803,95 @@ | |||
| } | |||
| ], | |||
| "private_data_type": "light_data" | |||
| }, | |||
| { | |||
There was a problem hiding this comment.
This { looks mis-indented
|
About the in_proximityX... how are they used? What does mean the data they read? A simple answer would be adding another option to node type, but I'd like to understand more about meaning of this data. Are they complementary? Do they measure different ranges? |
|
Thanks @edersondisouza for the review. About the in_proximity data reading, for common sensors such as APDS9960/APDS9930, users will use "cat in_proximity_raw" to get the data, this PR can support such kind of sensors. But if there are more than one raw data, such as SX9500 in issue #1971, we need to get data from in_proximity2_raw. @lblim could you share some information about how to use these in_proximityX? do we need to read all of them, or just in_proximity2_raw? |
Signed-off-by: Yong Li <[email protected]>
|
@lblim @laykuanloon I modified this PR, it can support the default in_proximity_raw and in_proximity2_raw. If you want to support both these 4 channels, I think we can use another PR to implement it. @edersondisouza how do you think about it? |
| channel_config.offset = mdata->offset; \ | ||
| mdata->channel_ ## _val = sol_iio_add_channel(mdata->device, "in_proximity", &channel_config); \ | ||
| if (!mdata->channel_ ## _val) \ | ||
| mdata->channel_ ## _val = sol_iio_add_channel(mdata->device, "in_proximity2", &channel_config); \ |
There was a problem hiding this comment.
You are adding two channels, but only saves one. So, you only read in_proximity2 in fact, as it's the last one you saved. If a device happens to not have in_proximity2, you'll get NULL here and no readings after.
Nevertheless, I still would like to understand the differences between these channels. I suspect that we could model all channels on only one final information.
There was a problem hiding this comment.
Oh... disregard first comment, only now I've seen the if (!mdata->channel_ ## _val)... sorry.
But I'm kinda puzzled by the in_proximity2... AFAICU from sx9500 datasheet, there's no differentiation among channels...
There was a problem hiding this comment.
@edersondisouza As discussed in issue #1971, only channel 2 in sx9500 is needed.
APDS9960/APDS9930 only have the in_proximity_raw, and the SX9500 has in_proximity0_raw to in_proximity3_raw, if we only use in_proximity2_raw, this PR can support all these three sensors. But if we want to add multi-channel support, we need a new implement
There was a problem hiding this comment.
Ok. I'll merge this PR, but we need to change nodes to address this multiple channel case.
|
Integrated. Tks! |
|
No problem |
Signed-off-by: Yong Li [email protected]