Skip to content

cloud-kernel
cloud-kernel

openanolis / cloud-kernel
1 年多 前同步成功

通知 161
Star 36
Fork 7
cloud-kernel
cloud-kernel
切换分支/标签
  1. 19 4月, 2015 1 次提交
  3. 10 4月, 2015 1 次提交
    • J
      iio/axp288_adc: add missing channel info mask · d0716b0e
      由 Jacob Pan 提交于 
      Commit 65de7654 ("iio: iio: Fix iio_channel_read return if
channel havn't info") added a check for valid info masks.

This patch adds missing channel info masks for all ADC channels.
Otherwise, iio_read_channel_raw() would return -EINVAL when called
by consumer drivers.

Note that the change of _processed to _raw actually fixes an ABI abuse
in the original driver where it was used to avoid some special handling
rather than because it was correct.
Signed-off-by: NJacob Pan <jacob.jun.pan@linux.intel.com>
Cc: <Stable@vger.kernel.org>
Signed-off-by: NJonathan Cameron <jic23@kernel.org>
      d0716b0e
  5. 09 4月, 2015 1 次提交
  7. 02 4月, 2015 1 次提交
  9. 01 4月, 2015 1 次提交
  11. 29 3月, 2015 5 次提交
    • V
      iio: mlx90614: Support devices with dual IR sensor · bad4d1a0
      由 Vianney le Clément de Saint-Marcq 提交于 
      The model is detected by reading the EEPROM configuration during
probing.
Signed-off-by: NVianney le Clément de Saint-Marcq <vianney.leclement@essensium.com>
Cc: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Signed-off-by: NJonathan Cameron <jic23@kernel.org>
      bad4d1a0
    • V
      iio: mlx90614: Add symbols for accessible registers · 209c0069
      由 Vianney le Clément de Saint-Marcq 提交于 
      Add symbols for all accessible RAM and EEPROM registers, as well as the
sleep command and timings defined in the datasheet.
Signed-off-by: NVianney le Clément de Saint-Marcq <vianney.leclement@essensium.com>
Cc: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Signed-off-by: NJonathan Cameron <jic23@kernel.org>
      209c0069
    • O
      iio: bmc150_accel: add support for hardware fifo · 3bbec977
      由 Octavian Purdila 提交于 
      We only advertise hardware fifo support if the I2C bus supports full
I2C or smbus I2C block data reads since it is mandatory to read the
full frame in one read (otherwise the rest of the frame is discarded).

The hardware fifo is enabled only when triggers are not active because:

(a) when using the any-motion trigger the user expects to see samples
based on ROC events, but the fifo stores samples based on the sample
frequency

(b) the data-ready trigger is waking the CPU for for every sample, so
using the hardware fifo does not have any benefit
Signed-off-by: NOctavian Purdila <octavian.purdila@intel.com>
Reviewed-by: NLars-Peter Clausen <lars@metafoo.de>
Signed-off-by: NJonathan Cameron <jic23@kernel.org>
      3bbec977
    • O
      iio: add support for hardware fifo · f4f4673b
      由 Octavian Purdila 提交于 
      Some devices have hardware buffers that can store a number of samples
for later consumption. Hardware usually provides interrupts to notify
the processor when the FIFO is full or when it has reached a certain
watermark level. This helps with reducing the number of interrupts to
the host processor and thus it helps decreasing the power consumption.

This patch enables usage of hardware FIFOs for IIO devices in
conjunction with software device buffers. When the hardware FIFO is
enabled the samples are stored in the hardware FIFO. The samples are
later flushed to the device software buffer when the number of entries
in the hardware FIFO reaches the hardware watermark or when a flush
operation is triggered by the user when doing a non-blocking read
on an empty software device buffer.

In order to implement hardware FIFO support the device drivers must
implement the following new operations: setting and getting the
hardware FIFO watermark level, flushing the hardware FIFO to the
software device buffer. The device must also expose information about
the hardware FIFO such it's minimum and maximum watermark and if
necessary a list of supported watermark values. Finally, the device
driver must activate the hardware FIFO when the device buffer is
enabled, if the current device settings allows it.

The software device buffer watermark is passed by the IIO core to the
device driver as a hint for the hardware FIFO watermark. The device
driver can adjust this value to allow for hardware limitations (such
as capping it to the maximum hardware watermark or adjust it to a
value that is supported by the hardware). It can also disable the
hardware watermark (and implicitly the hardware FIFO) it this value is
below the minimum hardware watermark.

Since a driver may support hardware FIFO only when not in triggered
buffer mode (due to different semantics of hardware FIFO sampling and
triggered sampling) this patch changes the IIO core code to allow
falling back to non-triggered buffered mode if no trigger is enabled.
Signed-off-by: NOctavian Purdila <octavian.purdila@intel.com>
Reviewed-by: NLars-Peter Clausen <lars@metafoo.de>
Signed-off-by: NJonathan Cameron <jic23@kernel.org>
      f4f4673b
    • J
      iio: add watermark logic to iio read and poll · 37d34556
      由 Josselin Costanzi 提交于 
      Currently the IIO buffer blocking read only wait until at least one
data element is available.
This patch makes the reader sleep until enough data is collected before
returning to userspace. This should limit the read() calls count when
trying to get data in batches.

Co-author: Yannick Bedhomme <yannick.bedhomme@mobile-devices.fr>
Signed-off-by: NJosselin Costanzi <josselin.costanzi@mobile-devices.fr>
[rebased and remove buffer timeout]
Signed-off-by: NOctavian Purdila <octavian.purdila@intel.com>
Reviewed-by: NLars-Peter Clausen <lars@metafoo.de>
Signed-off-by: NJonathan Cameron <jic23@kernel.org>
      37d34556
  13. 28 3月, 2015 7 次提交
  15. 15 3月, 2015 8 次提交
  17. 12 3月, 2015 1 次提交
  19. 09 3月, 2015 3 次提交
  21. 08 3月, 2015 3 次提交
  23. 28 2月, 2015 1 次提交
    • A
      iio: ak8975: fix AK09911 dependencies · 36086889
      由 Arnd Bergmann 提交于 
      ak8975 depends on I2C and GPIOLIB, so any symbols that selects
ak8975 must have the same dependency, or we get build errors:

drivers/iio/magnetometer/ak8975.c: In function 'ak8975_who_i_am':
drivers/iio/magnetometer/ak8975.c:393:2: error: implicit declaration of function 'i2c_smbus_read_i2c_block_data' [-Werror=implicit-function-declaration]
  ret = i2c_smbus_read_i2c_block_data(client, AK09912_REG_WIA1,
  ^
drivers/iio/magnetometer/ak8975.c: In function 'ak8975_set_mode':
drivers/iio/magnetometer/ak8975.c:431:2: error: implicit declaration of function 'i2c_smbus_write_byte_data' [-Werror=implicit-function-declaration]
  ret = i2c_smbus_write_byte_data(data->client,
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
Fixes: 57e73a42 ("iio: ak8975: add ak09911 and ak09912 support")
Signed-off-by: NJonathan Cameron <jic23@kernel.org>
      36086889
  25. 25 2月, 2015 2 次提交
    • S
      iio: imu: inv_mpu6050: Create mux clients for ACPI · a35c5d1a
      由 Srinivas Pandruvada 提交于 
      This is a follow up patches after adding i2c mux adapter for bypass
mode. Potentially many different types of sensor can be attached to
INVMPU6XXX device, which can be connected to main cpu i2c bus in
bypass mode.
Why do we need this?
The system ACPI table entry will consist of only one device for
INV6XXX, assuming that this driver will handle all connected sensors.
That is not true for the Linux driver. There are bunch of IIO drivers
for each sensors, hence we created a mux on this device. So to load
these additional drivers, we need to create i2c devices for them
in this driver using this mux adapter.

There are multiple options:
1. Use the auto detect feature, this needs a new i2c class for the
adapter as the existing HWMON class is not acceptable. Also the
autodetect has overhead of executing detect method for each
matching class of adapters.
This is a simple implementation. This option was previously submitted
with not a happy feedback.

2. Option is use ACPI magic and parse the configuration data. What
we need to create a i2c device at a minimum is address and a name.
Address can be obtained for secondary device in more or less in a
standard way from using _CRS element. But there is no name. To get
name we need to process proprietary vendor data. Not having name is
not fun, as you have to create device using the device name of
INVN6XXXX, respecting driver duplicate name space restriction.
Also each client driver needs to have this name in the id table.
Since multiple driver can be loaded, the driver should be able to
detect its presence and gracefully exit for the other client driver
to take it over.
So we use two step process:
- Use DMI to id platform and parse propritery data. This is not uncommon
for many x86 platform specific driver. We will get both name and address.
The change created necessary infrastructure to add more properitery vendor
data parsing.
- If DMI match fails, then create device on INV6XXX-client (we can't
create with same name as INV6XXX as it will cause duplicate name and driver
model will reject.) With this each client sensor driver which needs to get
attached via INV6XXXX, need this name in the id table and detect the
physical presence of sensor in probe and exit if not found.
Signed-off-by: NSrinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: NJonathan Cameron <jic23@kernel.org>
      a35c5d1a
    • K
      iio: jsa1212: Constify struct regmap_config · 9820d883
      由 Krzysztof Kozlowski 提交于 
      The regmap_config struct may be const because it is not modified by the
driver and regmap_init() accepts pointer to const.
Signed-off-by: NKrzysztof Kozlowski <k.kozlowski@samsung.com>
Signed-off-by: NJonathan Cameron <jic23@kernel.org>
      9820d883
  27. 22 2月, 2015 2 次提交
  29. 15 2月, 2015 1 次提交
  31. 14 2月, 2015 2 次提交
    • A
      IIO: si7020: Allocate correct amount of memory in devm_iio_device_alloc · e01becba
      由 Andrey Smirnov 提交于 
      Since only a pointer to struct i2c_client is stored in a private area
of IIO device created by the driver there's no need to allocate
sizeof(struct i2c_client) worth of storage.

Pushed to stable as this is linked to the revert patch previously.
Without this followup the original patch looks sensible.
Signed-off-by: NAndrey Smirnov <andrew.smirnov@gmail.com>
Cc: Stable@vger.kernel.org
Signed-off-by: NJonathan Cameron <jic23@kernel.org>
      e01becba
    • J
      Revert "iio:humidity:si7020: fix pointer to i2c client" · e765537a
      由 Jonathan Cameron 提交于 
      This reverts commit e0922e5e.
Requested by Andrey Smirnov.

It incorrectly assumes that the level of indirection is not needed
which is not true(probably because the driver incorrectly allocates
sizeof(*client) instead of sizeof(*data) via devm_iio_device_alloc).
If you look at the code of the probe function(see below) it is easy to
see that what is being stored in the private memory of the IIO device
instance is not a copy of a 'struct i2c_client' but a pointer to an
instance passed as an argument to the probe function.

struct i2c_client **data;
int ret;

< Some code skipped >

indio_dev = devm_iio_device_alloc(&client->dev, sizeof(*client));
if (!indio_dev)
return -ENOMEM;

data = iio_priv(indio_dev);
*data = client;

Without reverting this change any read of a raw value of this sensor
leads to a kernel oops due to a NULL pointer de-reference on my
hardware setup.
Signed-off-by: NJonathan Cameron <jic23@kernel.org>
Cc: Stable@vger.kernel.org
      e765537a