- 25 Mar, 2021 9 commits
-
-
Gwendal Grignou authored
Allow setting frequency below 1Hz or sub 1Hz precision. Useful for slow sensors like ALS. Test frequency is set properly: modprobe iio-trig-hrtimer && \ mkdir /sys/kernel/config/iio/triggers/hrtimer/t1 && \ cd /sys/bus/iio/devices/triggerX ; for i in 1 .1 .01 .001 ; do echo $i > sampling_frequency cat sampling_frequency done Signed-off-by:
Gwendal Grignou <gwendal@chromium.org> Reviewed-by:
Andy Shevchenko <andy.shevchenko@gmail.com> Link: https://lore.kernel.org/r/20210226014733.2108544-1-gwendal@chromium.orgSigned-off-by:
Jonathan Cameron <Jonathan.Cameron@huawei.com>
-
Baruch Siach authored
The ADI device-drivers-devel list no longer exists. Cc: Mike Frysinger <vapier@gentoo.org> Signed-off-by:
Baruch Siach <baruch@tkos.co.il> Link: https://lore.kernel.org/r/69b3e45e7666a1dd74a83df0b84ef8a63bf090ea.1614082343.git.baruch@tkos.co.ilSigned-off-by:
-
Sean Nyekjaer authored
Improve readability by fixing indentation. Signed-off-by:
Sean Nyekjaer <sean@geanix.com> Link: https://lore.kernel.org/r/20210301080029.1974797-1-sean@geanix.comSigned-off-by:
-
Ivan Mikhaylov authored
Add the proximity rate optional option and handling of it for vishay vcnl3020. Signed-off-by:
Ivan Mikhaylov <i.mikhaylov@yadro.com> Link: https://lore.kernel.org/r/20210225201444.12983-2-i.mikhaylov@yadro.comSigned-off-by:
-
Sergiu Cuciurean authored
As part of the general cleanup of indio_dev->mlock, this change replaces it with a local lock on the device's state structure. This is part of a bigger cleanup. Link: https://lore.kernel.org/linux-iio/CA+U=Dsoo6YABe5ODLp+eFNPGFDjk5ZeQEceGkqjxXcVEhLWubw@mail.gmail.com/Signed-off-by:
Sergiu Cuciurean <sergiu.cuciurean@analog.com> Signed-off-by:
Mircea Caprioru <mircea.caprioru@analog.com> Link: https://lore.kernel.org/r/20200928131333.36646-3-mircea.caprioru@analog.comSigned-off-by:
-
Sergiu Cuciurean authored
As part of the general cleanup of indio_dev->mlock, this change replaces it with a local lock on the device's state structure. This is part of a bigger cleanup. Link: https://lore.kernel.org/linux-iio/CA+U=Dsoo6YABe5ODLp+eFNPGFDjk5ZeQEceGkqjxXcVEhLWubw@mail.gmail.com/Signed-off-by:
-
Sergiu Cuciurean authored
As part of the general cleanup of indio_dev->mlock, this change replaces it with a local lock on the device's state structure. This is part of a bigger cleanup. Link: https://lore.kernel.org/linux-iio/CA+U=Dsoo6YABe5ODLp+eFNPGFDjk5ZeQEceGkqjxXcVEhLWubw@mail.gmail.com/Signed-off-by:
-
Jonathan Cameron authored
This control on the gain of a measurement used for time of flight sensing is standard but the expected values for different enviroments may not be. As we cannot have the same ABI element documented in two files, add a generic version to sysfs-bus-iio-proximity and a note on the expected value vs measuring environment for the as3935. Fixes $ scripts/get_abi.pl validate Warning: /sys/bus/iio/devices/iio:deviceX/sensor_sensitivity is defined 2 times: ./Documentation/ABI/testing/sysfs-bus-iio-distance-srf08:0 ./Documentation/ABI/testing/sysfs-bus-iio-proximity-as3935:8 Cc: Matt Ranostay <matt.ranostay@konsulko.com> Reported-by:
Mauro Carvalho Chehab <mchehab+huawei@kernel.org> Signed-off-by:
Matt Ranostay <matt.ranostay@konsulko.com> Link: https://lore.kernel.org/r/20210117153816.696693-7-jic23@kernel.orgSigned-off-by:
-
Jonathan Cameron authored
These contain only one entry for out_current_heater_raw (_available). Document this in a new sysfs-bus-iio-humidity file, and make it a little more generic by allowing for non 0/1 values. Fixes $ scripts/get_abi.pl validate Warning: /sys/bus/iio/devices/iio:deviceX/out_current_heater_raw is defined 2 times: ./Documentation/ABI/testing/sysfs-bus-iio-humidity-hdc2010:0 ./Documentation/ABI/testing/sysfs-bus-iio-humidity-hdc100x:0 Warning: /sys/bus/iio/devices/iio:deviceX/out_current_heater_raw_available is defined 2 times: ./Documentation/ABI/testing/sysfs-bus-iio-humidity-hdc2010:1 ./Documentation/ABI/testing/sysfs-bus-iio-humidity-hdc100x:1 Cc: Eugene Zaikonnikov <ez@norphonic.com> Cc: Matt Ranostay <matt.ranostay@konsulko.com> Reported-by:
-
- 11 Mar, 2021 31 commits
-
-
Linus Walleij authored
To get access to the big endian byte order parsing helpers drivers need to include <asm/unaligned.h> and nothing else. Cc: Gene Chen <gene_chen@richtek.com> Suggested-by:
Harvey Harrison <harvey.harrison@gmail.com> Signed-off-by:
Linus Walleij <linus.walleij@linaro.org> Link: https://lore.kernel.org/r/20210215153447.48457-1-linus.walleij@linaro.orgSigned-off-by:
-
Nuno Sa authored
Add some helpers to lock and unlock the device. As this is such a simple change, we update all the users that were using the lock already in this patch. Signed-off-by:
Nuno Sa <nuno.sa@analog.com> Link: https://lore.kernel.org/r/20210218114039.216091-5-nuno.sa@analog.comSigned-off-by:
-
Nuno Sá authored
`adi,scaled-output-hz` is no longer used by the driver. Acked-by:
Rob Herring <robh@kernel.org> Signed-off-by:
-
Nuno Sa authored
With this patch, we don't force users to define the IMU scaled internal sampling rate once in the devicetree. Now it's dynamically calculated at runtime depending on the desired output rate given by users. Calculating the sync_scale dynamically gives us better chances of achieving a perfect/integer value for DEC_RATE (thus giving more flexibility). The math is: 1. lcm of the input clock and the desired output rate. 2. get the highest multiple of the previous result lower than the adis max rate. 3. The last result becomes the IMU sample rate. Use that to calculate SYNC_SCALE and DEC_RATE (to get the user output rate). Signed-off-by: -
Nuno Sa authored
When using PPS mode, the input clock needs to be scaled so that we have an IMU sample rate between (optimally) 4000 and 4250. After this, we can use the decimation filter to lower the sampling rate in order to get what the user wants. Optimally, the user sample rate is a multiple of both the IMU sample rate and the input clock. Hence, calculating the sync_scale dynamically gives us better chances of achieving a perfect/integer value for DEC_RATE. The math here is: 1. lcm of the input clock and the desired output rate. 2. get the highest multiple of the previous result lower than the adis max rate. 3. The last result becomes the IMU sample rate. Use that to calculate SYNC_SCALE and DEC_RATE (to get the user output rate). Fixes: 326e2357 ("iio: imu: adis16480: Add support for external clock") Signed-off-by: -
Alexandru Ardelean authored
The channels are of type iio_chan_spec, not axi_adc_chan_spec. They were in some earlier version, but forgot to rename in the doc-string. Fixes: ef040706 ("iio: adc: adi-axi-adc: add support for AXI ADC IP core") Signed-off-by:
Alexandru Ardelean <alexandru.ardelean@analog.com> Link: https://lore.kernel.org/r/20210219090134.48057-1-alexandru.ardelean@analog.comSigned-off-by:
-
Alexandru Ardelean authored
Since the new change to the IIO buffer infrastructure, the buffer/ and scan_elements/ directories have been merged into bufferY/ to have some attributes available per-buffer. This change updates the ABI docs to reflect this change. The hwfifo attributes are not updated, as for now these should be used via the legacy buffer/ directory until they are moved into core. Signed-off-by:
-
Mircea Caprioru authored
The AD5673R/AD5677R are low power, 16-channel, 12-/16-bit buffered voltage output digital-to-analog converters (DACs). They include a 2.5 V internal reference (enabled by default). These devices are very similar to AD5674R/AD5679R, except that they have an i2c interface. Signed-off-by:
-
Hans de Goede authored
Some 2-in-1 laptops / convertibles with 360° (yoga-style) hinges, have 2 accelerometers, 1 in their base and 1 in their display. In many cases the kernel can detect the location of each accelerometer based on e.g. information from the ACPI tables. It is important for userspace to know the location of the 2 accelerometers. Rather then adding a new sysfs-attribute for this we can relay this information to userspace by using standardized label strings for this. This mirrors how this is done for proximity sensors. This commit documents 2 new standardized label strings for this purpose: "accel-base" "accel-display" Note the "base" and "display" suffixes were chosen to match the values used for the systemd/udev hwdb.d/60-sensor.hwdb file's ACCEL_LOCATION property. Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com> Cc: Mark Pearson <mpearson@lenovo.com> Cc: Bastien Nocera <hadess@hadess.net> Signed-off-by:
Hans de Goede <hdegoede@redhat.com> Link: https://lore.kernel.org/r/20210215191003.698888-2-hdegoede@redhat.comSigned-off-by:
-
Hans de Goede authored
Add an entry to Documentation/ABI/testing/sysfs-bus-iio for the new device label sysfs-attribute support. And document the standardized labels which may be used with proximity sensors to hint userspace about the intended use of the sensor. Using labels to differentiate between the multiple proximity sensors which a modern laptop/tablet may have was discussed in this thread: https://lore.kernel.org/linux-iio/9f9b0ff6-3bf1-63c4-eb36-901cecd7c4d9@redhat.com/ As mentioned there the "proximity-wifi*" labels are already being used in this manner on some chromebooks, see e.g.: arch/arm64/boot/dts/qcom/sc7180-trogdor.dtsi arch/arm64/boot/dts/qcom/sc7180-trogdor-lte-sku.dtsi And the "proximity-palmrest" and "proximity-lap" labels are intended to be used with the lap and palmrest sensors found in recent Lenovo ThinkPad models. Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com> Cc: Mark Pearson <mpearson@lenovo.com> Cc: Bastien Nocera <hadess@hadess.net> Signed-off-by:
-
Ye Xiang authored
Add relative hysteresis in ABI documentation for als sensor. Signed-off-by:
Ye Xiang <xiang.ye@intel.com> Link: https://lore.kernel.org/r/20210207070048.23935-4-xiang.ye@intel.comSigned-off-by:
-
Ye Xiang authored
Hid sensor als use relative hysteresis, this patch adds the support. Signed-off-by:
-
Ye Xiang authored
Some hid sensors may use relative sensitivity such as als sensor. This patch adds relative sensitivity checking for all hid sensors. Signed-off-by:
Jiri Kosina <jkosina@suse.cz> Link: https://lore.kernel.org/r/20210207070048.23935-2-xiang.ye@intel.comSigned-off-by:
-
Ye Xiang authored
Before, when reading/writing the hysteresis of als, incli-3d, press, and rotation sensor, we will get invalid argument error. This patch add more sensitivity data fields for these sensors, so that these sensors can get sensitivity index and return correct hysteresis value. Signed-off-by:
-
Ye Xiang authored
No functional change has been made with this patch. The main intent here is to reduce code repetition of getting sensitivity attribute. In the current implementation, sensor_hub_input_get_attribute_info() is called from multiple drivers to get attribute info for sensitivity field. Moving this to common place will avoid code repetition. Signed-off-by:
Alexandre Belloni <alexandre.belloni@bootlin.com> Link: https://lore.kernel.org/r/20210201054921.18214-2-xiang.ye@intel.comSigned-off-by:
-
Luca Ceresoli authored
Show that this field is optional, just like the shift value. Signed-off-by:
Luca Ceresoli <luca@lucaceresoli.net> Link: https://lore.kernel.org/r/20210215143511.25471-6-luca@lucaceresoli.netSigned-off-by:
-
Luca Ceresoli authored
This 2nd-level bullet list is not properly ReST-formatted and thus it gets rendered as a unique paragraph quite unreadable. Fix by adding spaces as needed. While there also swap "shift" and "repeat" so they are in the correct order. Signed-off-by:
-
Luca Ceresoli authored
Two out of three attributes are documented, document the third one too. Signed-off-by:
-
Luca Ceresoli authored
This directory is a, well, directory, not a file. Signed-off-by:
-
Luca Ceresoli authored
This line is part of the code snippet, so it has to be nested in order to be rendered correctly. Signed-off-by:
-
Julia Lawall authored
Use getter and setter functions, for a variety of data types. Signed-off-by:
Julia Lawall <Julia.Lawall@inria.fr> Link: https://lore.kernel.org/r/20210209211315.1261791-1-Julia.Lawall@inria.frSigned-off-by:
-
Alexandru Ardelean authored
This change makes use of the new IIO buffer API to read data from an IIO buffer. It doesn't read the /sys/bus/iio/devices/iio:deviceX/scan_elements dir anymore, it reads /sys/bus/iio/devices/iio:deviceX/bufferY, where all the scan_elements have been merged together with the old/classical buffer attributes. And it makes use of the new IIO_BUFFER_GET_FD_IOCTL ioctl to get an FD for the IIO buffer for which to read data from. It also does a quick sanity check to see that -EBUSY is returned if reading the chardev after the ioctl() has succeeded. This was tested with the following cases: 1. Tested buffer0 works with ioctl() 2. Tested that buffer0 can't be opened via /dev/iio:deviceX after ioctl() This check should be omitted under normal operation; it's being done here to check that the driver change is sane 3. Moved valid buffer0 to be buffer1, and tested that data comes from it Signed-off-by: -
Alexandru Ardelean authored
Mostly a tidy-up. But also helps to understand the limits of scope of these functions and globals. Signed-off-by:
-
Alexandru Ardelean authored
This is a bit of a tidy-up, but also helps with extending the iioutils_get_type() function a bit, as we don't need to use it outside of the iio_utils.c file. So, we'll need to update it only in one place. With this change, the 'unsigned' types are updated to 'unsigned int' in the iioutils_get_type() function definition. Signed-off-by:
-
Alexandru Ardelean authored
The 'dev' variable name usually refers to 'struct device' types. However in iio_device_alloc() this was used for the 'struct iio_dev' type, which was sometimes causing minor confusions. This change renames the variable to 'indio_dev', which is the usual name used around IIO for 'struct iio_dev' type objects. It makes grepping a bit easier as well. Signed-off-by:
-
Alexandru Ardelean authored
With this change, an ioctl() call is added to open a character device for a buffer. The ioctl() number is 'i' 0x91, which follows the IIO_GET_EVENT_FD_IOCTL ioctl. The ioctl() will return an FD for the requested buffer index. The indexes are the same from the /sys/iio/devices/iio:deviceX/bufferY (i.e. the Y variable). Since there doesn't seem to be a sane way to return the FD for buffer0 to be the same FD for the /dev/iio:deviceX, this ioctl() will return another FD for buffer0 (or the first buffer). This duplicate FD will be able to access the same buffer object (for buffer0) as accessing directly the /dev/iio:deviceX chardev. Also, there is no IIO_BUFFER_GET_BUFFER_COUNT ioctl() implemented, as the index for each buffer (and the count) can be deduced from the '/sys/bus/iio/devices/iio:deviceX/bufferY' folders (i.e the number of bufferY folders). Used following C code to test this: ------------------------------------------------------------------- #include <stdio.h> #include <stdlib.h> #include <unistd.h> #include <sys/ioctl.h> #include <fcntl.h" #include <errno.h> #define IIO_BUFFER_GET_FD_IOCTL _IOWR('i', 0x91, int) int main(int argc, char *argv[]) { int fd; int fd1; int ret; if ((fd = open("/dev/iio:device0", O_RDWR))<0) { fprintf(stderr, "Error open() %d errno %d\n",fd, errno); return -1; } fprintf(stderr, "Using FD %d\n", fd); fd1 = atoi(argv[1]); ret = ioctl(fd, IIO_BUFFER_GET_FD_IOCTL, &fd1); if (ret < 0) { fprintf(stderr, "Error for buffer %d ioctl() %d errno %d\n", fd1, ret, errno); close(fd); return -1; } fprintf(stderr, "Got FD %d\n", fd1); close(fd1); close(fd); return 0; } ------------------------------------------------------------------- Results are: ------------------------------------------------------------------- # ./test 0 Using FD 3 Got FD 4 # ./test 1 Using FD 3 Got FD 4 # ./test 2 Using FD 3 Got FD 4 # ./test 3 Using FD 3 Got FD 4 # ls /sys/bus/iio/devices/iio\:device0 buffer buffer0 buffer1 buffer2 buffer3 dev in_voltage_sampling_frequency in_voltage_scale in_voltage_scale_available name of_node power scan_elements subsystem uevent ------------------------------------------------------------------- iio:device0 has some fake kfifo buffers attached to an IIO device. Signed-off-by: -
Alexandru Ardelean authored
With this change, calling iio_device_attach_buffer() will actually attach more buffers. Right now this doesn't do any validation of whether a buffer is attached twice; maybe that can be added later (if needed). Attaching a buffer more than once should yield noticeably bad results. The first buffer is the legacy buffer, so a reference is kept to it. At this point, accessing the data for the extra buffers (that are added after the first one) isn't possible yet. The iio_device_attach_buffer() is also changed to return an error code, which for now is -ENOMEM if the array could not be realloc-ed for more buffers. To adapt to this new change iio_device_attach_buffer() is called last in all place where it's called. The realloc failure is a bit difficult to handle during un-managed calls when unwinding, so it's better to have this as the last error in the setup_buffer calls. At this point, no driver should call iio_device_attach_buffer() directly, it should call one of the {devm_}iio_triggered_buffer_setup() or devm_iio_kfifo_buffer_setup() or devm_iio_dmaengine_buffer_setup() functions. This makes iio_device_attach_buffer() a bit easier to handle. Signed-off-by: -
Alexandru Ardelean authored
The iio_simple_dummy_configure_buffer() function is essentially a re-implementation of the iio_triggered_buffer_setup() function. This change makes use of the iio_triggered_buffer_setup() function. The reason is so that we don't have to modify the iio_device_attach_buffer() function in this driver as well. One minor drawback is that the pollfunc name may not be 100% identical with the one in the original code, but since it's an example, it should be a big problem. This change does a minor re-arranging of the included iio headers, as a minor tidy-up. Signed-off-by:
-
Alexandru Ardelean authored
The __iio_buffer_free_sysfs_and_mask() function will be used in iio_buffer_alloc_sysfs_and_mask() when multiple buffers will be attached to the IIO device. This will need to be used to cleanup resources on each buffer, when the buffers cleanup unwind will occur on the error path. The move is done in this patch to make the patch that adds multiple buffers per IIO device a bit cleaner. Signed-off-by:
-
Alexandru Ardelean authored
In order to keep backwards compatibility with the current chardev mechanism, and in order to add support for multiple buffers per IIO device, we need to pass both the IIO device & IIO buffer to the chardev. This is particularly needed for the iio_buffer_read_outer() function, where we need to pass another buffer object than 'indio_dev->buffer'. Since we'll also open some chardevs via anon inodes, we can pass extra buffers in that function by assigning another object to the iio_dev_buffer_pair object. Signed-off-by:
-
Alexandru Ardelean authored
The reference to the IIO buffer object is stored on the attribute object. So we need to unwind it to obtain it. Signed-off-by:
-
