- 17 Oct, 2013 13 commits
-
-
Peter Meerwald authored
Signed-off-by:
Peter Meerwald <pmeerw@pmeerw.net> Signed-off-by:
Jonathan Cameron <jic23@kernel.org>
-
Peter Meerwald authored
move locking inside _set() function Signed-off-by:
-
Peter Meerwald authored
move locking inside _set() function Signed-off-by:
-
Peter Meerwald authored
and be consistent with other setter functions in that first argument is hmc5843_data Signed-off-by:
-
Peter Meerwald authored
only continuous mode is supported for now; the driver could/should be switched to single conversion mode operating mode should be determined by the way IIO accesses the device and not exposed explicitly Signed-off-by:
-
Peter Meerwald authored
v3: * use __be16 instead of s16 v2 (thanks to Jonathan Cameron): * drop dynamic buffer allocation, buffer is in hmc5842_data * grab timestamp near data acquisition * restrict available scan masks (only read all axis) Signed-off-by:
-
Peter Meerwald authored
v2: * use __be16 instead of s16 Split out data ready/wait for read measurement fix bug in case reading status register fails Signed-off-by:
-
Peter Meerwald authored
and drop/inline helper functions _check_int_plus_micros() and _show_int_plus_micros() Signed-off-by:
-
Peter Meerwald authored
v3: * rename _check_scale() to _get_scale_index() v2: * use SCALE instead of CALIBSCALE to control the range/gain of measurements Signed-off-by:
-
Beomho Seo authored
This patch adds device tree binding documentation for CM36651 proximity/light sensor. Signed-off-by:
Beomho Seo <beomho.seo@samsung.com> Signed-off-by:
-
Beomho Seo authored
This patch adds a new driver for Capella CM36651 proximity and RGB sensor. Signed-off-by:
-
Lars-Peter Clausen authored
The test in the spear_adc driver which checks whether the IRQ number returned by platform_get_irq() has multiple problems. It accepts 0 even though this is an invalid IRQ. It also rejects IRQ numbers that are larger or equal than NR_IRQS. First of all drivers should never need to reference NR_IRQS and secondly with CONFIG_SPARSE_IRQ NR_IRQS is not the upper limit, so the check might reject valid IRQ numbers. This patch modifies the check to only test against less or equal to 0. Signed-off-by:
Lars-Peter Clausen <lars@metafoo.de> Reported-by:
kbuild test robot <fengguang.wu@intel.com> Cc: Stefan Roese <sr@denx.de> Signed-off-by:
-
Lars-Peter Clausen authored
The test in the lpc32xx_adc driver which checks whether the IRQ number returned by platform_get_irq() has multiple problems. It accepts 0 even though this is an invalid IRQ. It also rejects IRQ numbers that are larger or equal than NR_IRQS. First of all drivers should never need to reference NR_IRQS and secondly with CONFIG_SPARSE_IRQ NR_IRQS is not the upper limit, so the check might reject valid IRQ numbers. This patch modifies the check to only test against less or equal to 0. Signed-off-by:
-
- 16 Oct, 2013 17 commits
-
-
Lars-Peter Clausen authored
The functionality implemented by iio_sw_buffer_preenable() is now done directly in the IIO core and previous users of iio_sw_buffer_preenable() have all been updated to not use it anymore. It is unused now and can be remove. Signed-off-by:
-
Lars-Peter Clausen authored
The equivalent of iio_sw_buffer_preenable() is now done in the IIO buffer core, so there is no need to do this from the driver anymore. Signed-off-by:
-
Lars-Peter Clausen authored
The equivalent of iio_sw_buffer_preenable() is now done in the IIO buffer core, so there is no need to do this from the driver anymore. Signed-off-by:
-
Lars-Peter Clausen authored
The equivalent of iio_sw_buffer_preenable() is now done in the IIO buffer core, so there is no need to do this from the driver anymore. Signed-off-by:
-
Lars-Peter Clausen authored
The equivalent of iio_sw_buffer_preenable() is now done in the IIO buffer core, so there is no need to do this from the driver anymore. Signed-off-by:
-
Lars-Peter Clausen authored
The equivalent of iio_sw_buffer_preenable() is now done in the IIO buffer core, so there is no need to do this from the driver anymore. Signed-off-by:
-
Lars-Peter Clausen authored
The equivalent of iio_sw_buffer_preenable() is now done in the IIO buffer core, so there is no need to do this from the driver anymore. Signed-off-by:
-
Lars-Peter Clausen authored
The equivalent of iio_sw_buffer_preenable() is now done in the IIO buffer core, so there is no need to do this from the driver anymore. Signed-off-by:
-
Lars-Peter Clausen authored
The equivalent of iio_sw_buffer_preenable() is now done in the IIO buffer core, so there is no need to do this from the driver anymore. Signed-off-by:
-
Lars-Peter Clausen authored
The equivalent of iio_sw_buffer_preenable() is now done in the IIO buffer core, so there is no need to do this from the driver anymore. Signed-off-by:
-
Lars-Peter Clausen authored
The equivalent of iio_sw_buffer_preenable() is now done in the IIO buffer core, so there is no need to do this from the driver anymore. Signed-off-by:
-
Lars-Peter Clausen authored
The equivalent of iio_sw_buffer_preenable() is now done in the IIO buffer core, so there is no need to do this from the driver anymore. Signed-off-by:
-
Lars-Peter Clausen authored
The equivalent of iio_sw_buffer_preenable() is now done in the IIO buffer core, so there is no need to do this from the driver anymore. Signed-off-by:
-
Lars-Peter Clausen authored
The equivalent of iio_sw_buffer_preenable() is now done in the IIO buffer core, so there is no need to do this from the driver anymore. Signed-off-by:
-
Lars-Peter Clausen authored
The equivalent of iio_sw_buffer_preenable() is now done in the IIO buffer core, so there is no need to do this from the driver anymore. Signed-off-by:
-
Lars-Peter Clausen authored
The equivalent of iio_sw_buffer_preenable() is now done in the IIO buffer core, so there is no need to do this from the driver anymore. Signed-off-by:
-
Lars-Peter Clausen authored
Currently a IIO device driver needs to make sure to update the buffer's bytes per datum after the scan mask has changed. This is usually done in the preenable callback by invoking iio_sw_buffer_preenable(). This is something that needs to be done and is done for virtually all devices which support buffers (we currently have only one exception). Also this a bit of a layering violation since we have to call the buffer setup ops from the device setup ops. This requires the device driver to know about the internal requirements of the buffer (e.g. whether we need to call the set_bytes_per_datum) callback. And especially with in-kernel buffer consumers, which allows to attach arbitrary buffers to a device, this is something that the driver can't know. Moving this to the core allows us to drop the individual calls to iio_sw_buffer_preenable() from drivers. Signed-off-by:
-
- 15 Oct, 2013 4 commits
-
-
Lars-Peter Clausen authored
update_needed is used to decide whether the kfifo buffer needs to be re-allocated. It is set to true whenever the size of the buffer is changed. It is never set to false though, causing the buffer to always be re-allocated. Setting update_needed to false after the new buffer has been allocated fixes the problem. Signed-off-by:
-
Lars-Peter Clausen authored
The kfifo's request_update callback will free the current buffer and allocate a new one if the size has changed. This will remove any samples that might still be left in the buffer. If the size has not changed the buffer content is left untouched though. This is a bit inconsistent and might cause an application to see data from a previous capture. This patch inserts a call to kfifo_reset_out() when the size did not change. This makes sure that any pending samples are removed from the buffer. Note, due to a different bug the buffer is currently always re-allocated, even if the size did not change. So this patch will not change the behavior. In the next patch the bug will be fixed and this patch makes sure that the current behavior is kept. Signed-off-by:
-
Lars-Peter Clausen authored
It is possible for userspace to concurrently access the buffer from multiple threads or processes. To avoid corruption of the internal state of the buffer we need to add proper locking. It is possible for multiple processes to try to read from the buffer concurrently and it is also possible that one process causes a buffer re-allocation while a different process still access the buffer. Both can be fixed by protecting the calls to kfifo_to_user() and kfifo_alloc() by the same mutex. In iio_read_first_n_kfifo() we also use kfifo_recsize() instead of the buffers bytes_per_datum to avoid a race that can happen if bytes_per_datum has been changed, but the buffer has not been reallocated yet. Note that all access to the buffer from within the kernel is already properly synchronized, so there is no need for extra locking in iio_store_to_kfifo(). Signed-off-by:
-
Lars-Peter Clausen authored
We need to free the kfifo when we release the buffer, otherwise the fifos memory will be leaked. Signed-off-by:
-
- 14 Oct, 2013 3 commits
-
-
Lars-Peter Clausen authored
None of the SPEAr, LPC32XX or MXS ADC drivers have a compile time dependency on their respective platform. So make it possible to build the drivers when CONFIG_COMPILE_TEST is set. This makes it easier to compile test changes. Signed-off-by:
Marek Vasut <marex@denx.de> Cc: Stefan Roese <sr@denx.de> Cc: Roland Stigge <stigge@antcom.de> Signed-off-by:
-
Lars-Peter Clausen authored
The MXS ADC driver uses the stmp_reset_block() which is only provided when the STMP_DEVICE Kconfig symbol is selected. Hence the driver should select this symbol. So far this has not been a problem since the driver depends on ARCH_MXS, which already selects STMP_DEVICE, but will become necessary once we allow the driver to be built when COMPILE_TEST is selected. Signed-off-by:
-
Lars-Peter Clausen authored
The driver is casting from one __iomem pointer to another. Make sure to include __iomem in the cast, otherwise sparse will complain with the following warning: drivers/staging/iio/adc/spear_adc.c:321:18: warning: cast removes address space of expression drivers/staging/iio/adc/spear_adc.c:320:33: warning: incorrect type in assignment (different address spaces) drivers/staging/iio/adc/spear_adc.c:320:33: expected struct adc_regs_spear3xx [noderef] <asn:2>*adc_base_spear3xx drivers/staging/iio/adc/spear_adc.c:320:33: got struct adc_regs_spear3xx *<noident> Signed-off-by:
-
- 12 Oct, 2013 3 commits
-
-
Lars-Peter Clausen authored
Remove the scale_mv variable from the read_raw() callback. Fixes the following warning: drivers/staging/iio/adc/spear_adc.c: In function 'spear_read_raw': drivers/staging/iio/adc/spear_adc.c:149:6: warning: unused variable 'scale_mv' Signed-off-by:
-
Lars-Peter Clausen authored
Since the kernel now disables all buffers when a device is unregistered it might happen that a in-kernel consumer tries to disable that buffer again. So ignore requests where the buffer already is in the desired state. Signed-off-by:
-
Lars-Peter Clausen authored
Register the event threshold hysteresis attributes by using the new IIO_EV_INFO_HYSTERESIS event spec type. This allows us to throw away a good portion of boiler-plate code. Signed-off-by:
-
