| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
The Exynos7-specific code bits in ADC driver do not play with PHY:
the field exynos_adc_data.needs_adc_phy is not set in exynos7_adc_data
instance. Therefore the initialization code does not have to check if
it is true.
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
Reviewed-by: Alim Akhtar <alim.akhtar@samsung.com>
Tested-by: Alim Akhtar <alim.akhtar@samsung.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
|
|
Currently the driver only exposes the raw counts. As we
have the regulator voltage and the maximum value (stored in
the data mask), we can trivially produce a scaling fraction
of voltage / max value.
This assumes that the regulator voltage is in fact the max
voltage, which appears to be the case for all mainline dts
and cross referenced with the public Exynos4412 and S5PV210
datasheets.
Signed-off-by: Jonathan Bakker <xc-racer2@live.ca>
Reviewed-by: Krzysztof Kozlowski <krzk@kernel.org>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
|
|
It is clear that we transition to INDIO_DIRECT_MODE when disabling the
buffer(s) and it is also clear that we transition from INDIO_DIRECT_MODE
when enabling the buffer(s). So leaving the currentmode field
INDIO_DIRECT_MODE until after the preenable() callback and updating it to
INDIO_DIRECT_MODE before the postdisable() callback doesn't add additional
value. On the other hand some drivers will need to perform different
actions depending on which mode the device is going to operate in/was
operating in.
Moving the update of currentmode before preenable() and after postdisable()
enables us to have drivers which perform mode dependent actions in those
callbacks.
Note, was originally not intended as such, but fixes an issue introduced
in the at91-sama5d2 adc driver.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
Fixes: 065056cb0d0a ("iio: at91-sama5d2_adc: split at91_adc_current_chan_is_touch() helper")
Tested-by: Eugen Hristev <eugen.hristev@microchip.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
|
|
As part of the general cleanup of indio_dev->mlock, this change replaces
it with a local lock on the device's state structure.
Signed-off-by: Sergiu Cuciurean <sergiu.cuciurean@analog.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
|
|
As part of the general cleanup of indio_dev->mlock, this change replaces
it with a local lock on the device's state structure.
Signed-off-by: Sergiu Cuciurean <sergiu.cuciurean@analog.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
|
|
As part of the general cleanup of indio_dev->mlock, this change replaces
it with a local lock on the device's state structure.
Signed-off-by: Sergiu Cuciurean <sergiu.cuciurean@analog.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
|
|
As part of the general cleanup of indio_dev->mlock, this change replaces
it with a local lock on the device's state structure.
Signed-off-by: Sergiu Cuciurean <sergiu.cuciurean@analog.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
|
|
As part of the general cleanup of indio_dev->mlock, this change replaces
it with a local lock on the device's state structure.
Signed-off-by: Sergiu Cuciurean <sergiu.cuciurean@analog.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
|
|
As part of the general cleanup of indio_dev->mlock, this change replaces
it with a local lock on the device's state structure.
Signed-off-by: Sergiu Cuciurean <sergiu.cuciurean@analog.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
|
|
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 also changes some internal functions to pass the pointer to the
state-struct vs a ref to indio_dev just to access the state-struct again.
Signed-off-by: Sergiu Cuciurean <sergiu.cuciurean@analog.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
|
|
As part of the general cleanup of indio_dev->mlock, this change replaces
it with a local lock on the device's state structure.
Signed-off-by: Sergiu Cuciurean <sergiu.cuciurean@analog.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
|
|
As part of the general cleanup of indio_dev->mlock, this change replaces
it with a local lock on the device's state structure.
Signed-off-by: Sergiu Cuciurean <sergiu.cuciurean@analog.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
|
|
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 also changes some internal functions to pass the pointer to the
state-struct vs a ref to indio_dev just to access the state-struct again.
Signed-off-by: Sergiu Cuciurean <sergiu.cuciurean@analog.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
|
|
The bma150/smb380 are very similar to the bma023 but have a temperature
channel as well.
Signed-off-by: Jonathan Bakker <xc-racer2@live.ca>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
|
|
The bma180 driver is being extended to support the bma150.
Its temperature channel is unsigned so the center_temp naming
no longer makes.
Signed-off-by: Jonathan Bakker <xc-racer2@live.ca>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
|
|
The bma023 chip is similar enough to the bma180 and bma25x that the
same driver can support all of them. The biggest differences are
the lack of a temperature channel and no low power but still working
mode.
The bma150 is a close relative of the bma023, but it does have a
temperature channel so support is not added for it.
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Jonathan Bakker <xc-racer2@live.ca>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
|
|
The bma180 IIO driver is being extended for support for the chips
support by input's bma150 driver (bma023, bma150, smb380). Don't
allow both drivers to be enabled simultaneously as they're for the
same hardware.
Signed-off-by: Jonathan Bakker <xc-racer2@live.ca>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
|
|
Some variants of the bma180 (eg bma023) have different reset
values. In preparation for adding support for them, factor
out the reset value into the chip specific data.
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Jonathan Bakker <xc-racer2@live.ca>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio into staging-next
Jonathan writes:
Second set of new device support, cleanups and features for IIO in the 5.8 cycle
Usual mixed back but with a few subsystem wide or device type
wide cleanups.
New device support
* adis16475
- New driver supporting adis16470, adis16475, adis16477, adis16465,
adis16467, adis16500, adis16505 and adis16507.
Includes some rework of the adis library to simplify using it
for this new driver.
* ak8974
- Add support for Alps hscdt008a. ID only. Related patches add support
for scale.
* atlas-sensor
- Add support for RTD-SM OEM temperature sensor.
* cm32181
- Add support for CM3218 including support for SMBUS alert via
ACPI resources.
* ltc2632
- Add support for ltc2634-12/10/8 DACS including handling per
device type numbers of channels.
Major Features
* cm32181
- ACPI bindings including parsing CPM0 and CPM1 custom ACPI tables.
Includes minor tidy ups and fixes.
* vcnl4000
- Add event support
- Add buffered data capture support
- Add control of sampling frequency
Cleanups and minor fixes.
* core
- Trivial rework of iio_device_alloc to use an early return and
improve readability.
- Precursors to addition of multiple buffer support. So far
minor refactoring.
* subsystem wide
- Use get_unaligned_be24 slightly improve readability over open
coding it.
* adis drivers
- Use iio_get_debugfs_dentry access function.
* bh1780, cm32181, cm3232, gp2ap02a00f, opt3001, st_uvis25, vl6180,
dmard06, kxsd9
- Drop use of of_match_ptr to allow ACPI based probing via PRP0001.
Part of clear out of this to avoid cut and paste into new drivers.
* ad5592r, ad5593r
- Fix typos
* ad5933
- Use managed interfaces to automate error handling and remove.
* ak8974
- Fix wrong number of 'real bits' for buffered data.
- Refactor to pull measurement code out as separate function.
bmp280
- Fix lack of clamp on range during data capture.
* at91-sama5d2_adc
- Handle unfinished conversions correctly.
- Allow use of triggers other than it's own.
- Reorganize buffer setup and tear down as part of long running
subsystem wide rework.
* ccs811
- Add DT binding docs and match table.
- Support external reset and wakeup pins.
* hid-sensors
- Reorganize buffer setup and tear down as part of long running
subsystem wide rework.
* ltr501
- Constify some structs.
* vcnl4000
- Fix an endian issue by using explicit byte swapped i2c accessors.
* tag 'iio-for-5.8b' of git://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio: (74 commits)
iio: light: ltr501: Constify structs
staging: iio: ad5933: attach life-cycle of kfifo buffer to parent device and use managed calls throughout
iio: bmp280: fix compensation of humidity
iio: light: cm32181: Fix integartion time typo
iio: light: cm32181: Add support for parsing CPM0 and CPM1 ACPI tables
iio: light: cm32181: Make lux_per_bit and lux_per_bit_base_it runtime settings
iio: light: cm32181: Use units of 1/100000th for calibscale and lux_per_bit
iio: light: cm32181: Change reg_init to use a bitmap of which registers to init
iio: light: cm32181: Handle CM3218 ACPI devices with 2 I2C resources
iio: light: cm32181: Clean up the probe function a bit
iio: light: cm32181: Add support for the CM3218
iio: light: cm32181: Add some extra register defines
iio: light: cm32181: Add support for ACPI enumeration
iio: light: cm32181: Switch to new style i2c-driver probe function
iio: hid-sensors: move triggered buffer setup into hid_sensor_setup_trigger
iio: vcnl4000: Add buffer support for VCNL4010/20.
iio: vcnl4000: Add sampling frequency support for VCNL4010/20.
iio: vcnl4000: Add event support for VCNL4010/20.
iio: vcnl4000: Factorize data reading and writing.
iio: vcnl4000: Fix i2c swapped word reading.
...
|
|
Constify some data structs that are never changed. In order to do so,
also update a couple of functions that now need to accept pointers to
const struct instead of struct. While at it, update a few more functions
to accept pointers to const struct instead of pointers.
This allows the compiler to put more data in the code segment instead of
the data segment, as seen by the output of the file command:
Before:
text data bss dec hex filename
27080 8144 192 35416 8a58 drivers/iio/light/ltr501.o
After:
text data bss dec hex filename
27688 7536 192 35416 8a58 drivers/iio/light/ltr501.o
Signed-off-by: Rikard Falkeborn <rikard.falkeborn@gmail.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
|
|
Limit the output of humidity compensation to the range between 0 and 100
percent.
Depending on the calibration parameters of the individual sensor it
happens, that a humidity above 100 percent or below 0 percent is
calculated, which don't make sense in terms of relative humidity.
Add a clamp to the compensation formula as described in the datasheet of
the sensor in chapter 4.2.3.
Although this clamp is documented, it was never in the driver of the
kernel.
It depends on the circumstances (calibration parameters, temperature,
humidity) if one can see a value above 100 percent without the clamp.
The writer of this patch was working with this type of sensor without
noting this error. So it seems to be a rare event when this bug occures.
Signed-off-by: Andreas Klinger <ak@it-klinger.de>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
|
|
Fix integartion time typo and while at it improve the comment with
the typo a bit in general.
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
|
|
On ACPI based systems the CPLM3218 ACPI device node describing the
CM3218[1] sensor typically will have some extra tables with register
init values for initializing the sensor and calibration info.
This is based on a newer version of cm32181.c, with a copyright of:
* Copyright (C) 2014 Capella Microsystems Inc.
* Author: Kevin Tsai <ktsai@capellamicro.com>
*
* This program is free software; you can redistribute it and/or modify it
* under the terms of the GNU General Public License version 2, as published
* by the Free Software Foundation.
Which is floating around on the net in various places, but the changes
from this newer version never made it upstream.
This was tested on the following models: Acer Switch 10 SW5-012 (CM32181)
Asus T100TA (CM3218), Asus T100CHI (CM3218) and HP X2 10-n000nd (CM32181).
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
|
|
This looks really unusual to have a 'get_device()' hidden in a 'dev_err()'
call.
Remove it.
While at it add a missing \n at the end of the message.
Fixes: 574fb258d636 ("Staging: IIO: VTI sca3000 series accelerometer driver (spi)")
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Cc: <Stable@vger.kernel.org>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
|
|
Make lux_per_bit and lux_per_bit_base_it settings stored in struct
cm32181_chip instead of a hardcoded (defined) values.
This is a preparation patch for reading some ACPI tables which specify
a device specific lux_per_bit value.
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
|
|
Use units of 1/100000th for calibscale and lux_per_bit. The similar
cm3232 driver already uses 1/100000th as unit for calibscale.
This allows for higher-accuracy and makes it easier to add support
for getting device-specific calibscale and lux_per_bit values from
a device's ACPI tables, as the values in the ACPI tables also use
1/100000th units.
This units change means that our intermediate values in cm32181_get_lux()
may get quite big, change the type of the lux variable to a u64 to
deal with this.
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
|
|
This is a preparation patch for reading some ACPI tables which give
init values for multiple registers.
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
|
|
Some ACPI systems list 2 I2C resources for the CM3218 sensor. On these
systems the first I2cSerialBus ACPI-resource points to the SMBus Alert
Response Address (ARA, 0x0c) and the second I2cSerialBus ACPI-resource
points to the actual CM3218 sensor address:
Method (_CRS, 0, NotSerialized) // _CRS: Current Resource Settings
{
Name (SBUF, ResourceTemplate ()
{
I2cSerialBusV2 (0x000C, ControllerInitiated, 0x00061A80,
AddressingMode7Bit, "\\_SB.I2C3",
0x00, ResourceConsumer, , Exclusive,
)
I2cSerialBusV2 (0x0048, ControllerInitiated, 0x00061A80,
AddressingMode7Bit, "\\_SB.I2C3",
0x00, ResourceConsumer, , Exclusive,
)
Interrupt (ResourceConsumer, Level, ActiveHigh, Exclusive, ,, )
{
0x00000033,
}
})
Return (SBUF) /* \_SB_.I2C3.ALSD._CRS.SBUF */
}
Detect this and take the following step to deal with it:
1. When a SMBus Alert capable sensor has an Alert asserted, it will
not respond on its actual I2C address. Read a byte from the ARA
to clear any pending Alerts.
2. Create a "dummy" client for the actual I2C address and
use that client to communicate with the sensor.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
|
|
3 small cleanups to cm32181_probe():
1. Do not log an error when we fail to allocate memory (as a general
rule drivers do not log errors for this as the kernel will already
have complained loudly that it could not alloc the mem).
2. Remove the i2c_set_clientdata() call, we never use i2c_get_clientdata()
or dev_get_drvdata() anywhere.
3. Add a dev helper variable and use it in various places instead of
&client->dev.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
|
|
Add support for the CM3218 which is an older version of the
CM32181.
This is based on a newer version of cm32181.c, with a copyright of:
* Copyright (C) 2014 Capella Microsystems Inc.
* Author: Kevin Tsai <ktsai@capellamicro.com>
*
* This program is free software; you can redistribute it and/or modify it
* under the terms of the GNU General Public License version 2, as published
* by the Free Software Foundation.
Which is floating around on the net in various places, but the changes
from this newer version never made it upstream.
This was tested on an Asus T100TA and an Asus T100CHI, which both come
with the CM3218 variant of the light sensor.
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
|
|
These come from a newer version of cm32181.c, which is floating around
the net, with a copyright of:
* Copyright (C) 2014 Capella Microsystems Inc.
* Author: Kevin Tsai <ktsai@capellamicro.com>
*
* This program is free software; you can redistribute it and/or modify it
* under the terms of the GNU General Public License version 2, as published
* by the Free Software Foundation.
Note that this removes the bogus CM32181_CMD_ALS_ENABLE define, there
is no enable bit, only a disable bit and enabled is the absence of
being disabled.
This is a preparation patch for adding support for the older
CM3218 model of the light sensor.
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
|
|
Add support for ACPI enumeration, this has been tested on a HP
HP Pavilion x2 Detachable 10 (Bay Trail model).
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
|
|
Switch to the new style i2c-driver probe_new probe function and drop the
unnecessary i2c_device_id table (we do not have any old style board files
using this).
This is a preparation patch for adding ACPI binding support.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
|
|
The main intent here is to get rid of the iio_buffer_set_attrs() helper, or
at least rework it's usage a bit.
The problem with that helper is that it needs a pointer to the buffer,
which makes supporting multiple buffers per IIO device a bit more
cumbersome.
The hid_sensor_setup_trigger() is pretty much used in the same way:
- iio_triggered_buffer_setup() gets called before
- then hid_sensor_setup_trigger() and hid_sensor_setup_batch_mode() gets
called which may attach some fifo attributes
This change merges the 2 together under the hid_sensor_setup_trigger()
function. Only the &iio_pollfunc_store_time is passed to all devices, so
it's not even required to pass it explicitly outside of the common
hid_sensor_setup_trigger() function.
Moving the devm_iio_triggered_buffer_setup/cleanup() calls into the common
place code can help the rework of the buffer code, since it is in one
place.
One detail of the change is that there are 2 drivers that use
devm_iio_triggered_buffer_setup(). That function gets implicitly
replaced with iio_triggered_buffer_setup()/cleanup(), but since all drivers
call both hid_sensor_setup_trigger9) & hid_sensor_remove_trigger() trigger,
the iio_triggered_buffer_cleanup() piggy backs on the
hid_sensor_remove_trigger() call, which should cover the cleanup.
Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
Acked-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
|
|
The VCNL4010 and VCNL4020 chips are able to raise interrupts on data ready.
Use it to provide triggered buffer support for proximity data.
Those two chips also provide ambient light data. However, they are sampled
at different rate than proximity data. As this is not handled by the IIO
framework for now, and the sample frequencies of ambient light data are
very low, do add buffer support for them.
Signed-off-by: Mathieu Othacehe <m.othacehe@gmail.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
|
|
Add sampling frequency support for proximity data on VCNL4010 and VCNL4020
chips.
Signed-off-by: Mathieu Othacehe <m.othacehe@gmail.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
|
|
The VCNL4010 and VCNL4020 chips are able to raise interrupts on proximity
threshold events. Add support for threshold rising and falling events for
those two chips.
Signed-off-by: Mathieu Othacehe <m.othacehe@gmail.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
|
|
Factorize data reading in vcnl4000_measure into a vcnl4000_read_data
function. Also add a vcnl4000_write_data function.
Signed-off-by: Mathieu Othacehe <m.othacehe@gmail.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
|
|
The bytes returned by the i2c reading need to be swapped
unconditionally. Otherwise, on be16 platforms, an incorrect value will be
returned.
Taking the slow path via next merge window as its been around a while
and we have a patch set dependent on this which would be held up.
Fixes: 62a1efb9f868 ("iio: add vcnl4000 combined ALS and proximity sensor")
Signed-off-by: Mathieu Othacehe <m.othacehe@gmail.com>
Cc: <Stable@vger.kernel.org>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
|
|
The IIO core provides a iio_get_debugfs_dentry() helper.
It seems that the ADIS IMU drivers access that field directly.
This change converts them to use iio_get_debugfs_dentry() instead.
Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
Acked-by: Nuno Sá <nuno.sa@analog.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
|
|
DMA channel request should use device struct from platform device struct.
Currently it's using iio device struct. But at this stage when probing,
device struct isn't yet registered (e.g. device_register is done in
iio_device_register). Since commit 71723a96b8b1 ("dmaengine: Create
symlinks between DMA channels and slaves"), a warning message is printed
as the links in sysfs can't be created, due to device isn't yet registered:
- Cannot create DMA slave symlink
- Cannot create DMA dma:rx symlink
Fix this by using device struct from platform device to request dma chan.
Fixes: eca949800d2d ("IIO: ADC: add stm32 DFSDM support for PDM microphone")
Signed-off-by: Fabrice Gasnier <fabrice.gasnier@st.com>
Cc: <Stable@vger.kernel.org>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
|
|
DMA channel request should use device struct from platform device struct.
Currently it's using iio device struct. But at this stage when probing,
device struct isn't yet registered (e.g. device_register is done in
iio_device_register). Since commit 71723a96b8b1 ("dmaengine: Create
symlinks between DMA channels and slaves"), a warning message is printed
as the links in sysfs can't be created, due to device isn't yet registered:
- Cannot create DMA slave symlink
- Cannot create DMA dma:rx symlink
Fix this by using device struct from platform device to request dma chan.
Fixes: 2763ea0585c99 ("iio: adc: stm32: add optional dma support")
Signed-off-by: Fabrice Gasnier <fabrice.gasnier@st.com>
Cc: <Stable@vger.kernel.org>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
|
|
During initial submission the selection of the channel was done using
the scan_index member of the iio_chan_spec structure. It was an abuse
because this member is supposed to be used with a buffer so it was
removed.
However there was still the need to be able to known how to select a
channel, the correct member to store this information is address.
Thanks to this it is possible to select any other channel than the
channel 0.
Fixes: 8dd2d7c0fed7 ("iio: adc: Add driver for the TI ADS8344 A/DC chips")
Signed-off-by: Gregory CLEMENT <gregory.clement@bootlin.com>
Cc: <Stable@vger.kernel.org>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
|
|
This patch add support for Analog Devices (Linear Technology)
LTC2634 Quad 12-/10-/8-Bit Rail-to-Rail DAC.
The SPI functionality based on them from LTC2632 therefor
add the definitions only and update the Kconfig.
Signed-off-by: Chris Ruehl <chris.ruehl@gtsys.com.hk>
Acked-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
|
|
The documentation for ltc_2632_chip_info missed the desciption for the
num_channels. This trivial patch adds it.
Signed-off-by: Chris Ruehl <chris.ruehl@gtsys.com.hk>
Fixes: 9f15a4a0adc9 ("iio: dac: ltc2632: add support for LTC2636 family")
Acked-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
|
|
The manual for the HSCDTD008A gives us a scaling for the
three axis as +/- 2.4mT (24 Gauss) per axis.
The manual for the AMI305 and AMI306 gives us a scaling
for the three axis as +/- 12 Gauss per axis.
Tests with the HSCDTD008A sensor, cat the raw values:
$ cat in_magn_*_raw
raw
45
189
-19
The scaling factor in in_magn_*_scale is 0.001464843,
which gives:
0.065 Gauss
0.277 Gauss
-0.027 Gauss
The earths magnetic field is in the range of 0.25 to 0.65
Gauss on the surface according to Wikipedia, so these
seem like reasonable values.
Again we are guessing that the AK8974 has a 12 bit ADC,
based on the similarity with AMI305 and AMI306.
Cc: Nick Reitemeyer <nick.reitemeyer@web.de>
Cc: Stephan Gerhold <stephan@gerhold.net>
Cc: Michał Mirosław <mirq-linux@rere.qmqm.pl>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
|
|
This breaks out the measurement code to its own function
so we can handle this without swirling it up with the
big switch() statement inside ak8974_read_raw().
Keep a local s16 helper variable for the signed value
coming out of the measurement before assigning it to the
integer *val. The local variable makes the code easier
to read and the compiler will optimize it if possible.
Cc: Nick Reitemeyer <nick.reitemeyer@web.de>
Cc: Stephan Gerhold <stephan@gerhold.net>
Reviewed-by: Michał Mirosław <mirq-linux@rere.qmqm.pl>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
|
|
The HSCDTD008A has 15 bits of actual ADC valie, and the
AMI305 and AMI306 has 12 bits.
Correct this by providing an extra parameter to the channel
macro and define a separate set of channels for each variant
of the chip. The resolution is the actual resolution of the
internal ADC of the chip.
The values are stored in a S16 in 2's complement so all 16
bits are used for storing (no shifting needed).
The AMI305, AMI306 and HSCDTD008A valid bits are picked from
respective datasheet.
My best educated guess is that AK8974 is also 12 bits. The
AK8973 is an 8 bit and earlier version, and the sibling
drivers AMI305 and AMI306 are 12 bits, so it makes sense
to assume that the AK8974 is also 12 bits.
Cc: Nick Reitemeyer <nick.reitemeyer@web.de>
Cc: Stephan Gerhold <stephan@gerhold.net>
Cc: Michał Mirosław <mirq-linux@rere.qmqm.pl>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
|
|
The hscdtd008a is similar to the AK8974:
Only the whoami value and some registers are different.
Signed-off-by: Nick Reitemeyer <nick.reitemeyer@web.de>
Reviewed-by: Stephan Gerhold <stephan@gerhold.net>
Tested-by: Stephan Gerhold <stephan@gerhold.net>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Tested-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
|
|
Enable 833Hz ODR for sensors that supports tagged hw FIFO:
- LSM6DSO/LSM6DSOX
- LSM6DSR/LSM6DSRX
- ASM330LHH
Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
|
