Add support for proximity sensors into soletta iio node

[lblim]

Task Description

Proximity sensor IIO node is not yet supported, can this be included for the upcoming Soletta release?

Dependencies

[barbieri]

Coincidence or not, we just noticed that today. Bruno submitted a stop gap user space sensor at #1970

But we will work with ostro team to support IIO asap. So you have some specific sensor? Please share the part number.

[lblim]

We are looking for SX9500, and APDS9930. The kernel driver for SX9500 is already available in Linux mainline, but the IIO driver for APDS9930 has not been upstreamed yet.

[barbieri]

@yongli3 can you work with @lblim to introduce soletta node types to use that family? Also work in Ostro to backport such modules if possible.

[yongli3]

@lblim please check the apds9960 and apds9300, are they similar with apds9930 ? I tested the apds9300 and apds9960 as below, could you share your apds9930 or sx9500 information(these files list in sysfs as below)? I think you want to read data from in_proximity_raw?

root@intel-quark:/sys/bus/i2c/devices/0-0039/iio:device1# ls -l
-r--r--r-- 1 root root 4096 Apr 29 23:30 dev
drwxr-xr-x 2 root root 0 Apr 29 23:30 events
-rw-r--r-- 1 root root 4096 Apr 29 23:30 in_illuminance0_input
-rw-r--r-- 1 root root 4096 Apr 29 23:30 in_intensity0_raw
-rw-r--r-- 1 root root 4096 Apr 29 23:30 in_intensity1_raw
-r--r--r-- 1 root root 4096 Apr 29 23:30 name
drwxr-xr-x 2 root root 0 Apr 29 23:30 power
lrwxrwxrwx 1 root root 0 Apr 29 23:30 subsystem -> ../../../../../../../bus/iio
-rw-r--r-- 1 root root 4096 Apr 29 23:30 uevent
root@intel-quark:/sys/bus/i2c/devices/0-0039/iio:device1# cat name
apds9300

cat /sys/bus/iio/devices/iio:device1/name
apds9960
root@intel-quark:~# cd /sys/bus/iio/devices/iio:device1/
root@intel-quark:/sys/bus/iio/devices/iio:device1# ls -l
drwxr-xr-x 2 root root 0 Apr 28 06:44 buffer
-r--r--r-- 1 root root 4096 Apr 28 06:44 dev
drwxr-xr-x 2 root root 0 Apr 28 06:44 events
-rw-r--r-- 1 root root 4096 Apr 28 06:44 in_intensity_blue_raw
-rw-r--r-- 1 root root 4096 Apr 28 06:44 in_intensity_clear_raw
-rw-r--r-- 1 root root 4096 Apr 28 06:44 in_intensity_green_raw
-rw-r--r-- 1 root root 4096 Apr 28 06:44 in_intensity_integration_time
-rw-r--r-- 1 root root 4096 Apr 28 06:44 in_intensity_red_raw
-rw-r--r-- 1 root root 4096 Apr 28 06:44 in_intensity_scale
-rw-r--r-- 1 root root 4096 Apr 28 06:44 in_proximity_raw
-rw-r--r-- 1 root root 4096 Apr 28 06:44 in_proximity_scale
-r--r--r-- 1 root root 4096 Apr 28 06:44 integration_time_available
-r--r--r-- 1 root root 4096 Apr 28 06:44 intensity_scale_available
-r--r--r-- 1 root root 4096 Apr 28 06:44 name
drwxr-xr-x 2 root root 0 Apr 28 06:44 power
-r--r--r-- 1 root root 4096 Apr 28 06:44 proximity_scale_available
drwxr-xr-x 2 root root 0 Apr 28 06:44 scan_elements
lrwxrwxrwx 1 root root 0 Apr 28 06:44 subsystem -> ../../bus/iio
-rw-r--r-- 1 root root 4096 Apr 28 06:44 uevent

[lblim]

Hi @yongli3

APDS9960, APDS9300 and APDS9930 are all ALS sensor but APDS9960 and 9930 are combo sensors that has more features. A separate kernel driver is needed for all three since they all have different features and export different IIO entries.

And Yes, in_proximity_raw is used.

Here is the IIO entries for APDS9930
root@sofia-3gr:/sys/bus/iio/devices/iio:device4# cat in_illuminance_input
200

root@sofia-3gr:/sys/bus/iio/devices/iio:device4# cat in_intensity_ir_raw
408

root@sofia-3gr:/sys/bus/iio/devices/iio:device4# cat in_intensity_both_raw
5924

root@sofia-3gr:/sys/bus/iio/devices/iio:device4# cat in_proximity_raw
1023

root@sofia-3gr:/sys/bus/iio/devices/iio:device4# cat uevent
MAJOR=252
MINOR=4
DEVNAME=iio:device4
DEVTYPE=iio_device
OF_NAME=proxsensor
OF_FULLNAME=/xgold/noc/l2_noc/ahb_per@1/i2c_3/proxsensor
OF_COMPATIBLE_0=avago,apds9930
OF_COMPATIBLE_N=1

root@sofia-3gr:/sys/bus/iio/devices/iio:device4# ls
dev in_illuminance_input in_intensity_ir_raw name subsystem
events in_intensity_both_raw in_proximity_raw power uevent

[yongli3]

@lblim Thanks for your update. The illuminance is supported now, let me add the in_proximity_raw support

[lblim]

SX9500

root@s3gr10m6s:/sys/bus/iio/devices/iio:device6 # ls buffer dev events in_proximity0_raw in_proximity1_raw in_proximity2_raw in_proximity3_raw name power sampling_frequency sampling_frequency_available scan_elements subsystem trigger uevent

root@s3gr10m6s:/sys/bus/iio/devices/iio:device6 # ls buffer/ enable length

root@s3gr10m6s:/sys/bus/iio/devices/iio:device6 # cat dev
252:6

root@s3gr10m6s:/sys/bus/iio/devices/iio:device6 # ls events/ in_proximity0_thresh_either_en in_proximity1_thresh_either_en in_proximity2_thresh_either_en in_proximity3_thresh_either_en

root@s3gr10m6s:/sys/bus/iio/devices/iio:device6 # cat in_proximity0_raw
31727
root@s3gr10m6s:/sys/bus/iio/devices/iio:device6 # cat in_proximity1_raw
31367
root@s3gr10m6s:/sys/bus/iio/devices/iio:device6 # cat in_proximity2_raw
32711
root@s3gr10m6s:/sys/bus/iio/devices/iio:device6 # cat in_proximity3_raw
31495

*** 3GR use CS2 only. And only use iio event.
**0 mean direct touch the casing
root@s3gr10m6s:/sys/bus/iio/devices/iio:device6 # cat in_proximity2_raw
0
*__~2cm from the casing
root@s3gr10m6s:/sys/bus/iio/devices/iio:device6 # cat in_proximity2_raw
25399
**~0.5cm from the casing
root@s3gr10m6s:/sys/bus/iio/devices/iio:device6 # cat in_proximity2_raw
8919

root@s3gr10m6s:/sys/bus/iio/devices/iio:device6 # cat sampling_frequency
33.333333
root@s3gr10m6s:/sys/bus/iio/devices/iio:device6 # cat sampling_frequency_available <
2.500000 3.333333 5 6.666666 8.333333 11.111111 16.666666 33.333333

root@s3gr10m6s:/sys/bus/iio/devices/iio:device6 # ls scan_elements/ in_proximity0_en in_proximity0_index in_proximity0_type in_proximity1_en in_proximity1_index in_proximity1_type in_proximity2_en in_proximity2_index in_proximity2_type in_proximity3_en in_proximity3_index in_proximity3_type in_timestamp_en in_timestamp_index in_timestamp_type

root@s3gr10m6s:/sys/bus/iio/devices/iio:device6 # ls power/ async autosuspend_delay_ms control runtime_active_kids runtime_active_time runtime_enabled runtime_status runtime_suspended_time runtime_usage

root@s3gr10m6s:/sys/bus/iio/devices/iio:device6 # ls subsystem/ devices drivers drivers_autoprobe drivers_probe uevent

root@s3gr10m6s:/sys/bus/iio/devices/iio:device6 # ls trigger/ current_trigger

root@s3gr10m6s:/sys/bus/iio/devices/iio:device6 # cat uevent
MAJOR=252
MINOR=6
DEVNAME=iio:device6
DEVTYPE=iio_device
OF_NAME=sarsensor
OF_FULLNAME=/xgold/noc/l2_noc/ahb_per@1/i2c_3/sarsensor
OF_COMPATIBLE_0=semtech,sx9500
OF_COMPATIBLE_N=1

[yongli3]

@lblim APDS9930 is using only one: in_proximity_raw, but the SX9500 is using several different files: in_proximity1_raw, in_proximity2_raw, ..,. do you only need the in_proximity2_raw?

[laykuanloon]

Yes, we are using in_proximity2_raw and iio event (events/in_proximity2_thresh_either_en) only.

sx9500 consist of 4-channel capacitive controller that can operate either as a proximity or button sensor. Customer can choose make use of all 4-channel.

flow:iio: Add Proximity sensor Category support into iio node #1986 can support all channel or channel 2 only?

[barbieri]

Please describe use cases and how they use each of the channels. This way we can model a node type that helps those. I fear that exposing ports "out[4]" for the 4 channels will just propagate the confusion to our users.

Do these ports have a relation between them?

[laykuanloon]

For my case I only use channel 2.

The 4 channel is from the sx9500 datasheet. Just want to know how soletta handle for different usage, I think Android use 3 channel for menu, home and back button.
http://www.droid-life.com/2015/06/24/on-screen-or-physicalcapacitive-navigation-buttons-which-is-better/

[edersondisouza]

On 09-05-2016 10:40, laykuanloon wrote:

For my case I only use channel 2.

The 4 channel is from the sx9500 datasheet. Just want to know how
soletta handle for different usage, I think Android use 3 channel for
menu, home and back button.
http://www.droid-life.com/2015/06/24/on-screen-or-physicalcapacitive-navigation-buttons-which-is-better/

Ah, so they are on different places? Now I've got it: one connects a
sensor to each available CSn pin. It makes sense now!
So, it appears that we have two options: adding an option to node type
or making it's output account for all of them. I'm inclined to first,
but need more thoughts on that.
Thank you!

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub
#1971 (comment)

[laykuanloon]

Yes, I only use channel 2 on phone backside to detect user is holding phone.

[barbieri]

if we can create multiple iio node instances, each for each channel, then using an channel=NUMBER option makes sense, in such case just a single OUT por is needed. The default should be the first channel, 1, and you guys would use the number 2 given what you said.

We just need to make sure our implementation allows that, multiple node instances wouldn't step on each other toes.

[edersondisouza]

Right now, it doesn't: node types would need to change to 'share' the same iio device. Even if channels are logically distinct, as in this case, they're all exposed via same /dev/iio:deviceX device.

[barbieri]

then we need to do it, @lblim already said to me about modules that provide multiple sensors in the same package and thus driver, like luminosity and presence. I believe providing a bundled-2-on-1 will not scale, then allowing these to use the same device may be a better approach.

AFAIU this is basically changing our open/close, the other parts remain the same. The shared part would go in a static global vector and have reference count.

[edersondisouza]

On 09-05-2016 14:08, Gustavo Sverzut Barbieri wrote:

then we need to do it, @lblim https://github.com/lblim already said to
me about modules that provide multiple sensors in the same package and
thus driver, like luminosity and presence. I believe providing a
bundled-2-on-1 will not scale, then allowing these to use the same
device may be a better approach.

AFAIU this is basically changing our open/close, the other parts remain
the same. The shared part would go in a static global vector and have
reference count.

Yeah, although I haven't really though of how, I think it shouldn't be
so hard; it would be an opportunity to refactor IIO node types so they
share more code, instead of being basically copy & paste.

—
You are receiving this because you commented.
Reply to this email directly or view it on GitHub
#1971 (comment)

[lblim]

Yes, allowing nodes to share the same IIO device is a better approach :)

[yongli3]

@lblim PR #1986 was merged, Soletta can support the proximity sensors now. Please test it using the APDS9930 or SX9500. FYI, below is a .fbp sample code for APDS9960 on Galileo boards:
#!/usr/bin/env sol-fbp-runner
apds(iio/proximity:iio_device="apds9960 create,i2c,pci0000:00/0000:00:15.2/i2c_designware.0,0x39,apds9960 1",buffer_size=-1)
timer(timer)
timer OUT -> TICK apds OUT -> IN _(console)

We will add the multiple channels implementation(#1998) later

[lblim]

@yongli3 @bdilly

For our proximity sensor use case we have dependency on IIO event support (#1985) and also multiple channels implementation(#1998).

I will close this issue since the iio node and follow the other two issues.
SX9500 has dependency on