- 19 Aug, 2022 16 commits
-
-
Krzysztof Kozlowski authored
Instead of listing directly properties typical for SPI peripherals, reference the spi-peripheral-props.yaml schema. This allows using all properties typical for SPI-connected devices, even these which device bindings author did not tried yet. Remove the spi-* properties which now come via spi-peripheral-props.yaml schema, except for the cases when device schema adds some constraints like maximum frequency. While changing additionalProperties->unevaluatedProperties, put it in typical place, just before example DTS. Signed-off-by:
Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Reviewed-by:
Rob Herring <robh@kernel.org> Link: https://lore.kernel.org/r/20220816124321.67817-10-krzysztof.kozlowski@linaro.orgSigned-off-by:
Jonathan Cameron <Jonathan.Cameron@huawei.com>
-
Krzysztof Kozlowski authored
Instead of listing directly properties typical for SPI peripherals, reference the spi-peripheral-props.yaml schema. This allows using all properties typical for SPI-connected devices, even these which device bindings author did not tried yet. Remove the spi-* properties which now come via spi-peripheral-props.yaml schema, except for the cases when device schema adds some constraints like maximum frequency. While changing additionalProperties->unevaluatedProperties, put it in typical place, just before example DTS. Signed-off-by:
-
Krzysztof Kozlowski authored
Instead of listing directly properties typical for SPI peripherals, reference the spi-peripheral-props.yaml schema. This allows using all properties typical for SPI-connected devices, even these which device bindings author did not tried yet. Remove the spi-* properties which now come via spi-peripheral-props.yaml schema, except for the cases when device schema adds some constraints like maximum frequency. While changing additionalProperties->unevaluatedProperties, put it in typical place, just before example DTS. Signed-off-by:
-
Krzysztof Kozlowski authored
Instead of listing directly properties typical for SPI peripherals, reference the spi-peripheral-props.yaml schema. This allows using all properties typical for SPI-connected devices, even these which device bindings author did not tried yet. Remove the spi-* properties which now come via spi-peripheral-props.yaml schema, except for the cases when device schema adds some constraints like maximum frequency. While changing additionalProperties->unevaluatedProperties, put it in typical place, just before example DTS. Signed-off-by:
-
Krzysztof Kozlowski authored
Instead of listing directly properties typical for SPI peripherals, reference the spi-peripheral-props.yaml schema. This allows using all properties typical for SPI-connected devices, even these which device bindings author did not tried yet. Remove the spi-* properties which now come via spi-peripheral-props.yaml schema, except for the cases when device schema adds some constraints like maximum frequency. While changing additionalProperties->unevaluatedProperties, put it in typical place, just before example DTS. Signed-off-by:
-
Krzysztof Kozlowski authored
Instead of listing directly properties typical for SPI peripherals, reference the spi-peripheral-props.yaml schema. This allows using all properties typical for SPI-connected devices, even these which device bindings author did not tried yet. Remove the spi-* properties which now come via spi-peripheral-props.yaml schema, except for the cases when device schema adds some constraints like maximum frequency. While changing additionalProperties->unevaluatedProperties, put it in typical place, just before example DTS. Signed-off-by:
-
Krzysztof Kozlowski authored
Instead of listing directly properties typical for SPI peripherals, reference the spi-peripheral-props.yaml schema. This allows using all properties typical for SPI-connected devices, even these which device bindings author did not tried yet. Remove the spi-* properties which now come via spi-peripheral-props.yaml schema, except for the cases when device schema adds some constraints like maximum frequency. While changing additionalProperties->unevaluatedProperties, put it in typical place, just before example DTS. Signed-off-by:
-
Krzysztof Kozlowski authored
Instead of listing directly properties typical for SPI peripherals, reference the spi-peripheral-props.yaml schema. This allows using all properties typical for SPI-connected devices, even these which device bindings author did not tried yet. Remove the spi-* properties which now come via spi-peripheral-props.yaml schema, except for the cases when device schema adds some constraints like maximum frequency. While changing additionalProperties->unevaluatedProperties, put it in typical place, just before example DTS. Signed-off-by:
-
Krzysztof Kozlowski authored
Instead of listing directly properties typical for SPI peripherals, reference the spi-peripheral-props.yaml schema. This allows using all properties typical for SPI-connected devices, even these which device bindings author did not tried yet. Remove the spi-* properties which now come via spi-peripheral-props.yaml schema, except for the cases when device schema adds some constraints like maximum frequency. While changing additionalProperties->unevaluatedProperties, put it in typical place, just before example DTS. Signed-off-by:
Marcus Folkesson <marcus.folkesson@gmail.com> Reviewed-by:
-
Krzysztof Kozlowski authored
Emails to Patrick Vasseur bounce ("Unknown To address"). Signed-off-by: -
Krzysztof Kozlowski authored
Emails to Tomislav Denis bounce ("550 5.1.1 User Unknown"). Signed-off-by: -
Krzysztof Kozlowski authored
Emails to Tomislav Denis bounce ("550 5.1.1 User Unknown"). Signed-off-by: -
Robert Marko authored
Add support for ADC5_VREF_VADC channel to rev2 ADC5 channel list. This channel measures the VADC reference LDO output. Signed-off-by:
Robert Marko <robimarko@gmail.com> Link: https://lore.kernel.org/r/20220818221815.346233-3-robimarko@gmail.comSigned-off-by:
-
Wolfram Sang authored
Follow the advice of the below link and prefer 'strscpy' in this subsystem. Conversion is 1:1 because the return value is not used. Generated by a coccinelle script. Link: https://lore.kernel.org/r/CAHk-=wgfRnXz0W3D37d01q3JFkr_i_uTL=V6A6G1oUZcprmknw@mail.gmail.com/Signed-off-by:
Wolfram Sang <wsa+renesas@sang-engineering.com> Signed-off-by:
-
Wolfram Sang authored
Follow the advice of the below link and prefer 'strscpy' in this subsystem. Conversion is 1:1 because the return value is not used. Generated by a coccinelle script. Link: https://lore.kernel.org/r/CAHk-=wgfRnXz0W3D37d01q3JFkr_i_uTL=V6A6G1oUZcprmknw@mail.gmail.com/Signed-off-by:
-
Antoniu Miclaus authored
Remove extra step where the error code is assigned to the `ret` variable. Return instead error code directly. Signed-off-by:
Antoniu Miclaus <antoniu.miclaus@analog.com> Link: https://lore.kernel.org/r/20220819104117.4600-1-antoniu.miclaus@analog.comSigned-off-by:
-
- 15 Aug, 2022 24 commits
-
-
Andy Shevchenko authored
Both pressure and temperature are 24-bit long. Use proper accessors instead of overlapping readings. Signed-off-by:
Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://lore.kernel.org/r/20220726142048.4494-1-andriy.shevchenko@linux.intel.comSigned-off-by:
-
Jakob Hauser authored
Add support for the magnetometer Yamaha YAS537. The additions are based on comparison of Yamaha Android kernel drivers for YAS532 [1] and YAS537 [2]. In the Yamaha YAS537 Android driver, there is an overflow/underflow control implemented. For regular usage, this seems not necessary. A similar overflow/ underflow control of Yamaha YAS530/532 Android driver isn't integrated in the mainline driver. It is therefore skipped for YAS537 in the mainline too. Also in the Yamaha YAS537 Android driver, at the end of the reset_yas537() function, a measurement is saved in "last_after_rcoil". Later on, this is compared to current measurements. If the difference gets too big, a new reset is initialized. The difference in measurements needs to be quite big, it's hard to say if this is necessary for regular operation. Therefore this isn't integrated in the mainline driver either. [1] https://github.com/msm8916-mainline/android_kernel_qcom_msm8916/blob/GT-I9195I/drivers/iio/magnetometer/yas_mag_drv-yas532.c [2] https://github.com/msm8916-mainline/android_kernel_qcom_msm8916/blob/GT-I9195I/drivers/iio/magnetometer/yas_mag_drv-yas537.cSigned-off-by:
Jakob Hauser <jahau@rocketmail.com> Reviewed-by:
Linus Walleij <linus.walleij@linaro.org> Link: https://lore.kernel.org/r/264c6488733a5c32089c9ab406a5bcb808c48fef.1660337264.git.jahau@rocketmail.comSigned-off-by:
-
Jakob Hauser authored
Add function pointers to the "chip_info" structure to ease the handling of different YAS variants. In the function yas5xx_probe(), the function call for "measure_offsets" was added as a conditional "if (ci->measure_offsets)". This is a preparatory step for YAS537, as this variant doesn't need an offset measurement. Signed-off-by:
Andy Shevchenko <andy.shevchenko@gmail.com> Reviewed-by:
-
Jakob Hauser authored
Add temperature calculation to the "chip_info" structure to ease the handling of different YAS variants. Signed-off-by:
-
Jakob Hauser authored
Add IIO scaling to the "chip_info" structure to ease the handling to different YAS variants. Signed-off-by:
-
Jakob Hauser authored
Add volatile registers to the "chip_info" structure to ease the handling of different YAS variants. Signed-off-by:
-
Jakob Hauser authored
Introduce the "chip_info" structure approach for better variant handling. The variant to be used is now chosen by the Device Tree (enum "chip_ids"), not by the chip ID in the register. However, there is a check to make sure they match (using integer "id_check"). Signed-off-by:
-
Jakob Hauser authored
This commit gathers several minor changes. In the device examples, "Xiaomi" is too generic, specific devices should be listed here. E.g. Xiaomi Redmi 2 seems to have YAS537 but it's not fully clear if this applies to all its variants. Samsung Galaxy S7 is often quoted in conjunction with YAS537. Removed defines for device IDs of YAS537 and YAS539, they are not needed so far. Signed-off-by:
-
Jakob Hauser authored
Use less stack by modifying %*ph parameters. While at it, in the function yas530_get_calibration_data(), the debug dump was extended to 16 elements as this is the size of the calibration data array of YAS530. Suggested-by:
-
Jakob Hauser authored
This is a preparation for adding the YAS537 variant. Functions that are used only by YAS530, YAS532 and YAS533 are renamed from yas5xx to yas530. Same for the registers. To avoid part listing in function and registers names, the name of the first variant is used. Where appropriate, comments were added that these functions are used by more than one variant. Functions that will be used by all variants including YAS537 remain in the naming scheme yas5xx. Or YAS5XX for registers, respectively. Signed-off-by:
-
Jakob Hauser authored
This is a preparation for adding YAS537 variant. YAS537 uses other data types on the calibration coefficients [1] than YAS530 [2] and YAS532 [3]. On YAS537, at least for a4 and a7 this could matter because 8-bit unsigned data from the register gets stored into a signed data type, therefore this should be 8-bit as well. For YAS530/532, on the other hand, it doesn't seem to matter. The size of a2-a9 and k is smaller than 8-bit at extraction, also the applied math is low. And Cx/Cy1/Cy2, now being defined as signed 16-bit, are extracted as unsigned 8-bit and undergo only minor math. [1] https://github.com/msm8916-mainline/android_kernel_qcom_msm8916/blob/GT-I9195I/drivers/iio/magnetometer/yas_mag_drv-yas537.c#L76-L78 [2] https://github.com/NovaFusion/android_kernel_samsung_golden/blob/cm-12.1/drivers/sensor/compass/yas_mag_driver-yas530.c#L526-L527 [3] https://github.com/msm8916-mainline/android_kernel_qcom_msm8916/blob/GT-I9195I/drivers/iio/magnetometer/yas_mag_drv-yas532.c#L76-L77Signed-off-by:
-
Jakob Hauser authored
The raw temperature value is a number of counts from a certain starting point. The resolution of the temperature counts is different for the YAS variants. Temperature compensation for YAS532 version AC seems to be handled differently. It uses the deviation from 20 degree Celsius [1] whereas YAS530 and older versions of YAS532 apply solely the t value as a multiplier [2][3]. In funtion yas5xx_read_raw(), add case IIO_CHAN_INFO_PROCESSED. Remove scale of temperature as this isn't applied. Additionally correct sign of temperature channel in iio_chan_spec. It's already defined that way in the yas5xx_get_measure() function. [1] https://github.com/msm8916-mainline/android_kernel_qcom_msm8916/blob/GT-I9195I/drivers/iio/magnetometer/yas_mag_drv-yas532.c#L442 [2] https://github.com/NovaFusion/android_kernel_samsung_golden/blob/cm-12.1/drivers/sensor/compass/yas_mag_driver-yas530.c#L881-L883 [3] https://github.com/LineageOS/android_kernel_samsung_msm8930-common/blob/lineage-18.1/drivers/sensors/geomagnetic/yas_mag_driver-yas53x.c#L856-L858Signed-off-by:
-
Jakob Hauser authored
Looks like YAS530 raw values return picotesla and YAS532 nanotesla. Adapt comments and scaling. Signed-off-by:
-
Jakob Hauser authored
In function yas5xx_volatile_reg(), register "YAS5XX_MEASURE_DATA + 8" shouldn't be volatile as we count from 0 to 7 here. Instead of lowering the number from 8 to 7, the operator "<=" is replaced by "<". The size of the measure data array is 8, therefore it's more natural to use 8 as a constant. This change is of low importance as the "+ 8" register isn't called. Signed-off-by:
-
Jakob Hauser authored
The "hard_offsets" are currently unsigned u8 but they should be signed as they can get negative. They are signed in function yas5xx_meaure_offsets() and in the Yamaha drivers [1][2]. [1] https://github.com/NovaFusion/android_kernel_samsung_golden/blob/cm-12.1/drivers/sensor/compass/yas.h#L156 [2] https://github.com/msm8916-mainline/android_kernel_qcom_msm8916/blob/GT-I9195I/drivers/iio/magnetometer/yas_mag_drv-yas532.c#L91 Fixes: de8860b1 ("iio: magnetometer: Add driver for Yamaha YAS530") Signed-off-by:
-
Crt Mori authored
Document the newly added vdd supply option. Signed-off-by:
Crt Mori <cmo@melexis.com> Acked-by:
-
Crt Mori authored
Provide possibility to toggle power supply to the sensor so that user can optimize their setup and not have the sensor constantly powered. Signed-off-by:
-
Uwe Kleine-König authored
Make use of devm_clk_get_enabled() to replace some code that effectively open codes this new function. Reviewed-by:
Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Link: https://lore.kernel.org/r/20220808204740.307667-13-u.kleine-koenig@pengutronix.deSigned-off-by:
-
Uwe Kleine-König authored
Make use of devm_clk_get_enabled() to replace some code that effectively open codes this new function. Reviewed-by:
-
Uwe Kleine-König authored
Make use of devm_clk_get_enabled() to replace some code that effectively open codes this new function. Reviewed-by:
-
Uwe Kleine-König authored
Make use of devm_clk_get_enabled() to replace some code that effectively open codes this new function. Reviewed-by:
-
Uwe Kleine-König authored
Make use of devm_clk_get_enabled() to replace some code that effectively open codes this new function. Reviewed-by:
-
Uwe Kleine-König authored
Make use of devm_clk_get_enabled() to replace some code that effectively open codes this new function. Reviewed-by:
-
Uwe Kleine-König authored
Make use of devm_clk_get_enabled() to replace some code that effectively open codes this new function. Reviewed-by:
-
