- 19 Oct, 2021 40 commits
-
-
Colin Ian King authored
There is a spelling mistake in a dev_warn message. Fix it. Signed-off-by:
Colin Ian King <colin.king@canonical.com> Link: https://lore.kernel.org/r/20211001120018.17570-1-colin.king@canonical.comSigned-off-by:
Jonathan Cameron <Jonathan.Cameron@huawei.com>
-
Alexandru Ardelean authored
This is a simple conversion for to device-managed with using devm_request_threaded_irq(), disabling the regulator via a devm_add_action_or_reset() hook and finally using devm_iio_device_register(). The i2c_set_clientdata() call is removed as it becomes redundant after this change. Signed-off-by:
Alexandru Ardelean <aardelean@deviqon.com> Link: https://lore.kernel.org/r/20210926194315.7742-1-aardelean@deviqon.comSigned-off-by:
-
Alexandru Ardelean authored
Otherwise most build checks will omit this driver from a compile-test due to it's dependency only on the BERLIN_ARCH symbol. Signed-off-by:
-
Alexandru Ardelean authored
This driver requires only a devm_add_action_or_reset() hook for the power-down of the device, and then devm_iio_device_register() can be used directly. Signed-off-by:
-
Alexandru Ardelean authored
This driver already hooks a similar unwind callback via devm_add_action_or_reset(). They pretty much do the same thing, so this change converts it to the devm_iio_map_array_register(). Signed-off-by:
Andreas Kemnade <andreas@kemnade.info> Link: https://lore.kernel.org/r/20210926162859.3567685-1-aardelean@deviqon.comSigned-off-by:
-
Alexandru Ardelean authored
For this conversion, the 2 regulators (being enabled) require each a devm_add_action_or_reset() hook registration. For the other functions, there are device-managed variants. Signed-off-by:
-
Alexandru Ardelean authored
This is a trivial conversion to device-managed functions. The mutex_destroy() calls are redundant, as the data will be free'd anyway. And the IRQ and IIO register functions both have device-managed equivalents. Signed-off-by:
Alexandre Belloni <alexandre.belloni@bootlin.com> Link: https://lore.kernel.org/r/20210926154932.3287590-1-aardelean@deviqon.comSigned-off-by:
-
Nuno Sá authored
The library can now handle enabling/disabling IRQs for devices that cannot unmask the data ready pin. Hence there's no need to provide an 'enable_irq' callback anymore. The library will also automatically request the IRQ with 'IRQF_NO_AUTOEN' so that we can also remove that from the driver. Signed-off-by:
Nuno Sá <nuno.sa@analog.com> Link: https://lore.kernel.org/r/20210903141423.517028-5-nuno.sa@analog.comSigned-off-by:
-
Nuno Sá authored
The library can now handle enabling/disabling IRQs for devices that cannot unmask the data ready pin. Hence there's no need to provide an 'enable_irq' callback anymore. The library will also automatically request the IRQ with 'IRQF_NO_AUTOEN' so that we can also remove that from the driver. Signed-off-by:
-
Nuno Sá authored
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á authored
With commit ecb010d4 ("iio: imu: adis: Refactor adis_initial_startup") we are doing a HW or SW reset to the device which means that we'll get the default state of the data ready pin (which is enabled). Hence there's no point in disabling the IRQ in the init function. Moreover, this function is intended to initialize internal data structures and not really do anything on the device. As a result of this, some devices were left with the data ready pin enabled after probe which was not the desired behavior. Thus, we move the call to 'adis_enable_irq()' to the initial startup function where it makes more sense for it to be. Note that for devices that cannot mask/unmask the pin, it makes no sense to call the function at this point since the IRQ should not have been yet requested. This will be improved in a follow up change. Fixes: ecb010d4 ("iio: imu: adis: Refactor adis_initial_startup") Signed-off-by:
-
Alexandru Ardelean authored
This change converts the probe of this driver to use device-managed functions only, which means that the remove hook can be removed. The remove hook has only 2 calls to iio_device_unregister() and iio_map_array_unregister(). Both these can now be done via devm register functions, now that there's also a devm_iio_map_array_register() function. The platform_set_drvdata() can also be removed now. This change also removes the error print for when the iio_device_register() call fails. This isn't required now. Signed-off-by:
-
Alexandru Ardelean authored
This change converts the probe of this driver to use device-managed functions only, which means that the remove hook can be removed. The remove hook has only 2 calls to iio_device_unregister() and iio_map_array_unregister(). Both these can now be done via devm register functions, now that there's also a devm_iio_map_array_register() function. The platform_set_drvdata() can also be removed now. This change also removes the error print for when the iio_device_register() call fails. This isn't required now. Signed-off-by:
-
Alexandru Ardelean authored
This change converts the probe of this driver to use device-managed functions only, which means that the remove hook can be removed. The remove hook has only 2 calls to iio_device_unregister() and iio_map_array_unregister(). Both these can now be done via devm register functions, now that there's also a devm_iio_map_array_register() function. The platform_set_drvdata() can also be removed now. This change also removes the error print for when the iio_device_register() call fails. This isn't required now. Signed-off-by:
Hans de Goede <hdegoede@redhat.com> Link: https://lore.kernel.org/r/20210903072917.45769-4-aardelean@deviqon.comSigned-off-by:
-
Alexandru Ardelean authored
The only call in the remove hook is the iio_map_array_unregister() call. Since we have a devm_iio_map_array_register() function now, we can use that and remove the remove hook entirely. The IIO device was registered with the devm_iio_device_register() prior to this change. Also, the platform_set_drvdata() can be removed now, since it was used only in the remove hook. Signed-off-by:
Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://lore.kernel.org/r/20210903072917.45769-3-aardelean@deviqon.comSigned-off-by:
-
Alexandru Ardelean authored
This change introduces a device-managed variant to the iio_map_array_register() function. It's a simple implementation of calling iio_map_array_register() and registering a callback to iio_map_array_unregister() with the devm_add_action_or_reset(). The function uses an explicit 'dev' parameter to bind the unwinding to. It could have been implemented to implicitly use the parent of the IIO device, however it shouldn't be too expensive to callers to just specify to which device object to bind this unwind call. It would make the API a bit more flexible. Signed-off-by:
-
Alexandru Ardelean authored
The driver tries to initialize all possible regulators from the DT, then match the external regulators with each channel and then release all unused regulators. We can change the logic a bit to initialize regulators only when at least one channel needs them. This change creates a mx25_gcq_ext_regulator_setup() function that is called only for the external regulators. If there's already a reference to an external regulator, the function will just exit early with no error. This way, the driver doesn't need to keep any track of these regulators during init. Signed-off-by:
-
Lorenzo Bianconi authored
Move max_fifo_size in st_lsm6dsx_fifo_ops in order to have all FIFO configuration parameters in st_lsm6dsx_fifo_ops structure. This patch does not introduce any logic change, just small code rearrangement. Signed-off-by:
Lorenzo Bianconi <lorenzo@kernel.org> Link: https://lore.kernel.org/r/3262ad9d9d1497e19ea1bab208c495c2b9a98994.1632664866.git.lorenzo@kernel.orgSigned-off-by:
-
Miquel Raynal authored
External triggers do not necessarily need the EOC interrupt to be populated to work properly. The end of conversion status may either come from an interrupt or from a sufficient enough extra delay. IRQs are not mandatory so move the triggered buffer setup out of the IRQ condition and add the logic to wait enough time for all the requested conversions to be in the device's FIFO. Signed-off-by:
Miquel Raynal <miquel.raynal@bootlin.com> Link: https://lore.kernel.org/r/20210921115408.66711-17-miquel.raynal@bootlin.comSigned-off-by:
-
Miquel Raynal authored
There is no reason to limit this driver to its internal trigger. The only difference being, when using an external trigger, the sample conversion must be manually started. Drop the ->validate_trigger() hook in order to allow other triggers to be bound. Signed-off-by:
-
Miquel Raynal authored
So far the End-Of-Conversion interrupt was only used in conjunction with the internal trigger to process the data. Let's extend the use of this interrupt handler to support regular single-shot conversions as well. Doing so requires writing our own hard IRQ handler. This handler has to check if buffers are enabled or not: *** Buffers disabled condition *** This means the user requested a single conversion and the sample is ready to be retrieved. -> This implies adding the relevant completion boilerplate. *** Buffers enabled condition *** Triggers are used. So far there is only support for the internal trigger but this trigger might soon be attached to another device as well so it is the core duty to decide which handler to call in order to process the data. The core will decide to either: * Call the internal trigger handler which will extract the data that is already present in the ADC FIFOs or * Call the trigger handler of another driver when using this trigger with another device, even though this call will be slightly delayed by the fact that the max1027 IRQ is a data-ready interrupt rather than a real trigger: -> The new handler will manually inform the core about the trigger having transitioned by directly calling iio_trigger_poll() (which iio_trigger_generic_data_rdy_poll() initially did). In order for the handler to be "source" agnostic, we also need to change the private pointer and provide the IIO device instead of the trigger object. Signed-off-by: -
Miquel Raynal authored
The threaded handler is not populated, this means there is nothing running in process context so let's switch to the regular devm_request_irq() call instead. Signed-off-by:
-
Miquel Raynal authored
For now this helper only waits for the maximum duration of a single conversion. In practice, a "temperature measurement" will take twice this time because it will also carry another analog conversion but as here we will only care about the temperature conversion which happens first, we can still only wait for a single sample and get the right data. This helper will soon be improved to properly handle the end of conversion interrupt as well as a higher number of samples. Signed-off-by:
-
Miquel Raynal authored
Create a max1027_read_scan() helper which will make clearer the future IRQ handler updates (no functional change). Signed-off-by:
-
Miquel Raynal authored
When hardware buffers are enabled (the cnvst pin being the trigger), one should not mess with the device state by requesting a single channel read. There is already a iio_buffer_enabled() check in *_read_single_value() to merely prevent this situation but the check is inconsistent since buffers can be enabled after the if clause anyway. Instead, use the core mutex by calling iio_device_claim/release_direct_mode(). Signed-off-by:
-
Miquel Raynal authored
These bits are meant to be reused for triggered buffers setup. Signed-off-by:
-
Miquel Raynal authored
We don't expect the (hardware) cnvst trigger to be enabled at boot time, this is a user choice made in sysfs and there is a dedicated callback to enable/disable this trigger. Hence, we can just ensure it is disabled in the probe at initialization time and then assume that whenever a ->read_raw() call happens, the trigger has been disabled and conversions will start on register write. Signed-off-by:
-
Miquel Raynal authored
The call to max1027_enable_trigger() is the same in both cases thanks to the 'state' variable, so factorize a little bit to simplify the code and explain why we call this helper. Signed-off-by:
-
Miquel Raynal authored
There are two ways to physically trigger a conversion: - A falling edge on the cnvst pin - A write operation on the conversion register Let's create a helper for this. Signed-off-by:
-
Miquel Raynal authored
Make it clear that the *_set_trigger_state() hook is responsible for cnvst based conversions by renaming the helper. This may avoid confusions with software trigger support that is going to be introduced. Signed-off-by:
-
Miquel Raynal authored
Provide a list of ->available_scan_masks which match the device's capabilities. Basically, these devices are able to scan from 0 to N, N being the highest voltage channel requested by the user. The temperature can be included or not, but cannot be retrieved alone. The consequence is, instead of reading and pushing to the IIO buffers all channels each time, the "minimum" number of channels will be scanned and pushed based on the ->active_scan_mask. For example, if the user wants channels 1, 4 and 5, all channels from 0 to 5 will be scanned and pushed to the IIO buffers. The core will then filter out the unneeded samples based on the ->active_scan_mask that has been selected and only channels 1, 4 and 5 will be available to the user in the shared buffer. Provide a comment in the code explaining this logic. Signed-off-by:
-
Miquel Raynal authored
These two debug messages bring absolutely no value, let's drop them. Signed-off-by:
-
Miquel Raynal authored
Memory allocation errors automatically trigger the right logs, no need to have our own. Signed-off-by:
-
Miquel Raynal authored
Follow checkpatch.pl's main advices before hacking into the driver, mainly: WARNING: Prefer 'unsigned int' to bare use of 'unsigned' WARNING: Prefer 'unsigned int *' to bare use of 'unsigned *' CHECK: Comparison to NULL could be written "!foo" CHECK: Alignment should match open parenthesis Signed-off-by:
-
Cai Huoqing authored
The NXP i.MX 8QuadXPlus SOC has a new ADC IP. After adding the driver support for it, I add the driver info of the NXP IMX8QXP ADC to MAINTAINERS file. Signed-off-by:
Cai Huoqing <caihuoqing@baidu.com> Link: https://lore.kernel.org/r/20210925020555.129-4-caihuoqing@baidu.comSigned-off-by:
-
Cai Huoqing authored
The NXP i.MX 8QuadXPlus SOC a new ADC IP, so add binding documentation for NXP IMX8QXP ADC. Reviewed-by:
Rob Herring <robh@kernel.org> Signed-off-by:
-
Cai Huoqing authored
The NXP i.MX 8QuadXPlus SOC has a new ADC IP, so add driver support for this ADC. Signed-off-by:
Fabio Estevam <festevam@gmail.com> Link: https://lore.kernel.org/r/20210925020555.129-2-caihuoqing@baidu.comSigned-off-by:
-
Sean Nyekjaer authored
This adds ways for the SoC to wake from accelerometer wake events. In the suspend function we skip disabling the sensor if wakeup-source and events are activated. If buffered reads are enabled they will be deactivated before suspend. As the onboard buffer is only holding up to 32 12-bit X/Y/Z data triplets. Signed-off-by:
Sean Nyekjaer <sean@geanix.com> Reviewed-by:
Andy Shevchenko <andy.shevchenko@gmail.com> Link: https://lore.kernel.org/r/20210920114221.1595543-2-sean@geanix.comSigned-off-by:
-
Sean Nyekjaer authored
Add event channels that control the creation of motion events. Signed-off-by:
-
Billy Tsai authored
The ADC controller has a trimming register for fine-tune the reference voltage. The trimming value comes from the OTP register which will be written during chip production. This patch will read this OTP value and configure it to the ADC register when the ADC controller probes and using dts property "aspeed,trim-data-valid" to determine whether to execute this flow. Signed-off-by:
Billy Tsai <billy_tsai@aspeedtech.com> Link: https://lore.kernel.org/r/20210922081520.30580-12-billy_tsai@aspeedtech.comSigned-off-by:
-
