- 18 Oct, 2013 1 commit
-
-
Sachin Kamat authored
'of_match_ptr' is defined in linux/of.h. Include it explicitly to avoid build breakage in the future. Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
-
- 17 Oct, 2013 16 commits
-
-
Josh Wu authored
AT91 ADC hardware integrate touch screen support. So this patch add touch screen support for at91 adc iio driver. To enable touch screen support in adc, you need to add the dt parameters: 1. which type of touch are used? (4 or 5 wires), sample period time. 2. correct pressure detect threshold value. In the meantime, since touch screen will use a interal period trigger of adc, so it is conflict to other hardware triggers. Driver will disable the hardware trigger support if touch screen is enabled. This driver has been tested in AT91SAM9X5-EK and SAMA5D3x-EK. Signed-off-by: Josh Wu <josh.wu@atmel.com> Acked-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> CC: devicetree@vger.kernel.org Signed-off-by: Jonathan Cameron <jic23@kernel.org>
-
Peter Meerwald authored
Signed-off-by: Peter Meerwald <pmeerw@pmeerw.net> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
-
Peter Meerwald authored
Signed-off-by: Peter Meerwald <pmeerw@pmeerw.net> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
-
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 <pmeerw@pmeerw.net> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
-
Peter Meerwald authored
move locking inside _set() function Signed-off-by: Peter Meerwald <pmeerw@pmeerw.net> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
-
Peter Meerwald authored
and be consistent with other setter functions in that first argument is hmc5843_data Signed-off-by: Peter Meerwald <pmeerw@pmeerw.net> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
-
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 <pmeerw@pmeerw.net> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
-
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 <pmeerw@pmeerw.net> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
-
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 <pmeerw@pmeerw.net> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
-
Peter Meerwald authored
and drop/inline helper functions _check_int_plus_micros() and _show_int_plus_micros() Signed-off-by: Peter Meerwald <pmeerw@pmeerw.net> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
-
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: Peter Meerwald <pmeerw@pmeerw.net> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
-
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: Jonathan Cameron <jic23@kernel.org>
-
Beomho Seo authored
This patch adds a new driver for Capella CM36651 proximity and RGB sensor. Signed-off-by: Beomho Seo <beomho.seo@samsung.com> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
-
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: Jonathan Cameron <jic23@kernel.org>
-
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: Lars-Peter Clausen <lars@metafoo.de> Reported-by: kbuild test robot <fengguang.wu@intel.com> Cc: Roland Stigge <stigge@antcom.de> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
-
- 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 <lars@metafoo.de> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
-
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 <lars@metafoo.de> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
-
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 <lars@metafoo.de> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
-
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 <lars@metafoo.de> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
-
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 <lars@metafoo.de> Cc: Marek Vasut <marex@denx.de> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
-
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 <lars@metafoo.de> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
-
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 <lars@metafoo.de> Cc: Jacek Anaszewski <j.anaszewski@samsung.com> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
-
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 <lars@metafoo.de> Cc: Denis Ciocca <denis.ciocca@st.com> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
-
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 <lars@metafoo.de> Cc: Denis Ciocca <denis.ciocca@st.com> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
-
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 <lars@metafoo.de> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
-
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 <lars@metafoo.de> Cc: Denis Ciocca <denis.ciocca@st.com> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
-
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 <lars@metafoo.de> Cc: Zubair Lutfullah <zubair.lutfullah@gmail.com> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
-
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 <lars@metafoo.de> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
-
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 <lars@metafoo.de> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
-
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 <lars@metafoo.de> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
-
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 <lars@metafoo.de> Cc: Denis Ciocca <denis.ciocca@st.com> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
-
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: Lars-Peter Clausen <lars@metafoo.de> Cc: Denis Ciocca <denis.ciocca@st.com> Cc: Marek Vasut <marex@denx.de> Cc: Zubair Lutfullah <zubair.lutfullah@gmail.com> Cc: Jacek Anaszewski <j.anaszewski@samsung.com> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
-
- 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 <lars@metafoo.de> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
-
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 <lars@metafoo.de> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
-
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 <lars@metafoo.de> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
-
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: Lars-Peter Clausen <lars@metafoo.de> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
-
- 14 Oct, 2013 2 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: Lars-Peter Clausen <lars@metafoo.de> Reviewed-by: Marek Vasut <marex@denx.de> Cc: Stefan Roese <sr@denx.de> Cc: Roland Stigge <stigge@antcom.de> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
-
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 <lars@metafoo.de> Cc: Marek Vasut <marex@denx.de> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
-