kernel/linux.git/include/linux/iio/imu, branch v6.6.132

iio: imu: adis: ensure proper DMA alignment

2024-02-23T08:25:06+00:00

commit 8e98b87f515d8c4bae521048a037b2cc431c3fd5 upstream. Aligning the buffer to the L1 cache is not sufficient in some platforms as they might have larger cacheline sizes for caches after L1 and thus, we can't guarantee DMA safety. That was the whole reason to introduce IIO_DMA_MINALIGN in [1]. Do the same for the sigma_delta ADCs. [1]: https://lore.kernel.org/linux-iio/20220508175712.647246-2-jic23@kernel.org/ Fixes: ccd2b52f4ac6 ("staging:iio: Add common ADIS library") Signed-off-by: Nuno Sa Link: https://lore.kernel.org/r/20240117-adis-improv-v1-1-7f90e9fad200@analog.com Cc: Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman

iio: imu: adis: Remove adis_initial_startup function

2022-11-23T20:37:51+00:00

Remove adis_initial_startup function since it is not used anymore. Signed-off-by: Ramona Bolboaca Reviewed-by: Nuno Sá Link: https://lore.kernel.org/r/20221122082757.449452-10-ramona.bolboaca@analog.com Signed-off-by: Jonathan Cameron

iio: adis: add '__adis_enable_irq()' implementation

2022-11-23T20:37:50+00:00

Add '__adis_enable_irq()' implementation which is the unlocked version of 'adis_enable_irq()'. Call '__adis_enable_irq()' instead of 'adis_enable_irq()' from '__adis_intial_startup()' to keep the expected unlocked functionality. This fix is needed to remove a deadlock for all devices which are using 'adis_initial_startup()'. The deadlock occurs because the same mutex is acquired twice, without releasing it. The mutex is acquired once inside 'adis_initial_startup()', before calling '__adis_initial_startup()', and once inside 'adis_enable_irq()', which is called by '__adis_initial_startup()'. The deadlock is removed by calling '__adis_enable_irq()', instead of 'adis_enable_irq()' from within '__adis_initial_startup()'. Fixes: b600bd7eb3335 ("iio: adis: do not disabe IRQs in 'adis_init()'") Signed-off-by: Ramona Bolboaca Reviewed-by: Nuno Sá Link: https://lore.kernel.org/r/20221122082757.449452-2-ramona.bolboaca@analog.com Signed-off-by: Jonathan Cameron

iio: adis: stylistic changes

2022-01-23T18:03:37+00:00

Minor stylistic changes to address checkptach complains when called with '--strict'. Signed-off-by: Nuno Sá Link: https://lore.kernel.org/r/20220122130905.99-3-nuno.sa@analog.com Signed-off-by: Jonathan Cameron

adis: simplify 'adis_update_bits' macros

2022-01-23T18:03:37+00:00

There's no need to use '__builtin_choose_expr' to choose the right call to 'adis_update_bits_base()'. We can change the 'BUILD_BUG_ON()' condition so that it makes sure only the supported sizes are passed in. With that, we can just use 'sizeof(val)' as the size argument of 'adis_update_bits_base()'. Signed-off-by: Nuno Sá Link: https://lore.kernel.org/r/20220122130905.99-2-nuno.sa@analog.com Signed-off-by: Jonathan Cameron

iio: adis: handle devices that cannot unmask the drdy pin

2021-10-19T07:27:34+00:00

Some devices can't mask/unmask the data ready pin and in those cases each driver was just calling '{dis}enable_irq()' to control the trigger state. This change, moves that handling into the library by introducing a new boolean in the data structure that tells the library that the device cannot unmask the pin. On top of controlling the trigger state, we can also use this flag to automatically request the IRQ with 'IRQF_NO_AUTOEN' in case it is set. So far, all users of the library want to start operation with IRQs/DRDY pin disabled so it should be fairly safe to do this inside the library. Signed-off-by: Nuno Sá Link: https://lore.kernel.org/r/20210903141423.517028-3-nuno.sa@analog.com Signed-off-by: Jonathan Cameron

iio: adis: add burst_max_speed_hz variable

2021-05-17T12:49:09+00:00

Typically, in burst mode, the device cannot operate at it's full spi speed. Hence, the spi transfers for burst mode have to take this into account. With this change we avoid a potential race with the spi core as drivers were 'hacking' the device 'max_speed_hz' directly in the trigger handler. Reviewed-by: Alexandru Ardelean Signed-off-by: Nuno Sa Link: https://lore.kernel.org/r/20210427085454.30616-5-nuno.sa@analog.com Signed-off-by: Jonathan Cameron

iio: adis: add helpers for locking

2021-03-11T20:47:12+00:00

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 Link: https://lore.kernel.org/r/20210218114039.216091-5-nuno.sa@analog.com Signed-off-by: Jonathan Cameron

iio: adis. Drop adis_burst struct

2020-09-21T19:01:45+00:00

As there are no users anymore of this structure, it can be safely removed. Signed-off-by: Nuno Sá Signed-off-by: Jonathan Cameron Link: https://lore.kernel.org/r/20200917155223.218500-5-nuno.sa@analog.com

iio: adis: Move burst mode into adis_data

2020-09-21T19:01:45+00:00

Add burst mode variables in the per device specific data structure. As some drivers support multiple devices with different burst sizes it makes sense this data to be in `adis_data`. While moving the variables, there are two main differences: 1. The `en`variable is dropped. If a device supports burst mode, it will just use it as it will has better performance for almost all real use cases. 2. Replace `extra_len` by `burst_len`. Users should now explicitly define the length of the burst buffer as it is typically constant. This also allows to remove the following line from the library: ``` /* All but the timestamp channel */ burst_length = (indio_dev->num_channels - 1) * sizeof(u16); ``` The library should not assume that a timestamp channel is defined. Moreover, most parts also include some diagnostic data, crc, etc.. in the burst buffer that needed to be included in an `extra_len` variable which is not that nice. On top of this, some devices already start to have some 32bit size channels ... This patch is also a move to completely drop the `struct adis_burst` from the library. Signed-off-by: Nuno Sá Signed-off-by: Jonathan Cameron Link: https://lore.kernel.org/r/20200917155223.218500-2-nuno.sa@analog.com