linux-toradex.git/drivers/staging, branch v3.14.39

vt6655: RFbSetPower fix missing rate RATE_12M

2015-04-13T12:03:02+00:00

commit 40c8790bcb7ac74f3038153cd09310e220c6a1df upstream.

When the driver sets this rate a power of zero value is set causing
data flow stoppage until another rate is tried.

Signed-off-by: Malcolm Priestley 
Signed-off-by: Greg Kroah-Hartman

staging: vt6656: vnt_rf_setpower: fix missing rate RATE_12M

2015-04-13T12:03:01+00:00

commit 163fe301b9f78b6de57d0014eafe504fd20c0cd4 upstream.

When the driver sets this rate a power of zero value is set causing
data flow stoppage until another rate is tried.

Signed-off-by: Malcolm Priestley 
Signed-off-by: Greg Kroah-Hartman

iio: mxs-lradc: fix merge error

2015-03-26T14:06:49+00:00

Commit e7f3db14eacaf1993a70b1517582603dfdf34988 (89bb35e200bee745c539a96666e0792301ca40f1 upstream) was backported incorrectly by me, so fix it up, as the driver is now broken.

Sorry about that.

Reported-by: Kristina Martšenko 
Cc: Marek Vasut 
Cc: Jonathan Cameron 
Signed-off-by: Greg Kroah-Hartman

staging: comedi: cb_pcidas64: fix incorrect AI range code handling

2015-03-18T12:31:33+00:00

commit be8e89087ec2d2c8a1ad1e3db64bf4efdfc3c298 upstream.

The hardware range code values and list of valid ranges for the AI
subdevice is incorrect for several supported boards.  The hardware range
code values for all boards except PCI-DAS4020/12 is determined by
calling `ai_range_bits_6xxx()` based on the maximum voltage of the range
and whether it is bipolar or unipolar, however it only returns the
correct hardware range code for the PCI-DAS60xx boards.  For
PCI-DAS6402/16 (and /12) it returns the wrong code for the unipolar
ranges.  For PCI-DAS64/Mx/16 it returns the wrong code for all the
ranges and the comedi range table is incorrect.

Change `ai_range_bits_6xxx()` to use a look-up table pointed to by new
member `ai_range_codes` of `struct pcidas64_board` to map the comedi
range table indices to the hardware range codes.  Use a new comedi range
table for the PCI-DAS64/Mx/16 boards (and the commented out variants).

Signed-off-by: Ian Abbott 
Signed-off-by: Greg Kroah-Hartman

staging: comedi: comedi_compat32.c: fix COMEDI_CMD copy back

2015-03-18T12:31:32+00:00

commit 42b8ce6f55facfa101462e694d33fc6bca471138 upstream.

`do_cmd_ioctl()` in "comedi_fops.c" handles the `COMEDI_CMD` ioctl.
This returns `-EAGAIN` if it has copied a modified `struct comedi_cmd`
back to user-space.  (This occurs when the low-level Comedi driver's
`do_cmdtest()` handler returns non-zero to indicate a problem with the
contents of the `struct comedi_cmd`, or when the `struct comedi_cmd` has
the `CMDF_BOGUS` flag set.)

`compat_cmd()` in "comedi_compat32.c" handles the 32-bit compatible
version of the `COMEDI_CMD` ioctl.  Currently, it never copies a 32-bit
compatible version of `struct comedi_cmd` back to user-space, which is
at odds with the way the regular `COMEDI_CMD` ioctl is handled.  To fix
it, change `compat_cmd()` to copy a 32-bit compatible version of the
`struct comedi_cmd` back to user-space when the main ioctl handler
returns `-EAGAIN`.

Signed-off-by: Ian Abbott 
Reviewed-by: H Hartley Sweeten 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Greg Kroah-Hartman

iio: mxs-lradc: only update the buffer when its conversions have finished

2015-03-18T12:31:26+00:00

commit 89bb35e200bee745c539a96666e0792301ca40f1 upstream.

Using the touchscreen while running buffered capture results in the
buffer reporting lots of wrong values, often just zeros. This is because
we push readings to the buffer every time a touchscreen interrupt
arrives, including when the buffer's own conversions have not yet
finished. So let's only push to the buffer when its conversions are
ready.

Signed-off-by: Kristina Martšenko 
Reviewed-by: Marek Vasut 
Signed-off-by: Jonathan Cameron 
Signed-off-by: Greg Kroah-Hartman

iio: mxs-lradc: make ADC reads not unschedule touchscreen conversions

2015-03-18T12:31:26+00:00

commit 6abe0300a1d5242f4ff89257197f284679af1a06 upstream.

Reading a channel through sysfs, or starting a buffered capture, can
occasionally turn off the touchscreen.

This is because the read_raw() and buffer preenable()/postdisable()
callbacks unschedule current conversions on all channels. If a delay
channel happens to schedule a touchscreen conversion at the same time,
the conversion gets cancelled and the touchscreen sequence stops.

This is probably related to this note from the reference manual:

	"If a delay group schedules channels to be sampled and a manual
	write to the schedule field in CTRL0 occurs while the block is
	discarding samples, the LRADC will switch to the new schedule
	and will not sample the channels that were previously scheduled.
	The time window for this to happen is very small and lasts only
	while the LRADC is discarding samples."

So make the callbacks only unschedule conversions for the channels they
use. This means channel 0 for read_raw() and channels 0-5 for the buffer
(if the touchscreen is enabled). Since the touchscreen uses different
channels (6 and 7), it no longer gets turned off.

This is tested and fixes the issue on i.MX28, but hasn't been tested on
i.MX23.

Signed-off-by: Kristina Martšenko 
Reviewed-by: Marek Vasut 
Signed-off-by: Jonathan Cameron 
Signed-off-by: Greg Kroah-Hartman

iio: mxs-lradc: make ADC reads not disable touchscreen interrupts

2015-03-18T12:31:26+00:00

commit 86bf7f3ef7e961e91e16dceb31ae0f583483b204 upstream.

Reading a channel through sysfs, or starting a buffered capture, will
currently turn off the touchscreen. This is because the read_raw() and
buffer preenable()/postdisable() callbacks disable interrupts for all
LRADC channels, including those the touchscreen uses.

So make the callbacks only disable interrupts for the channels they use.
This means channel 0 for read_raw() and channels 0-5 for the buffer (if
the touchscreen is enabled). Since the touchscreen uses different
channels (6 and 7), it no longer gets turned off.

Note that only i.MX28 is affected by this issue, i.MX23 should be fine.

Signed-off-by: Kristina Martšenko 
Reviewed-by: Marek Vasut 
Signed-off-by: Jonathan Cameron 
Signed-off-by: Greg Kroah-Hartman

iio: mxs-lradc: separate touchscreen and buffer virtual channels

2015-03-18T12:31:25+00:00

commit f81197b8a31b8fb287ae57f597b5b6841e1ece92 upstream.

The touchscreen was initially designed [1] to map all of its physical
channels to one virtual channel, leaving buffered capture to use the
remaining 7 virtual channels. When the touchscreen was reimplemented
[2], it was made to use four virtual channels, which overlap and
conflict with the channels the buffer uses.

As a result, when the buffer is enabled, the touchscreen's virtual
channels are remapped to whichever physical channels the buffer was
configured with, causing the touchscreen to read those instead of the
touch measurement channels. Effectively the touchscreen stops working.

So here we separate the channels again, giving the touchscreen 2 virtual
channels and the buffer 6. We can't give the touchscreen just 1 channel
as before, as the current pressure calculation requires 2 channels to be
read at the same time.

This makes the touchscreen continue to work during buffered capture. It
has been tested on i.MX28, but not on i.MX23.

[1] 06ddd353f5c8 ("iio: mxs: Implement support for touchscreen")
[2] dee05308f602 ("Staging/iio/adc/touchscreen/MXS: add interrupt driven
touch detection")

Signed-off-by: Kristina Martšenko 
Reviewed-by: Marek Vasut 
Signed-off-by: Jonathan Cameron 
Signed-off-by: Greg Kroah-Hartman

iio: mxs-lradc: fix iio channel map regression

2015-03-18T12:31:25+00:00

commit 03305e535cd5cdc1079b32909bf4b2dd67d46f7f upstream.

Since commit c8231a9af8147f8a ("iio: mxs-lradc: compute temperature
from channel 8 and 9") with the removal of adc channel 9 there is
no 1-1 mapping in the channel spec.

All hwmon channel values above 9 are accessible via there index minus
one. So add a hidden iio channel 9 to fix this issue.

Signed-off-by: Stefan Wahren 
Acked-by: Alexandre Belloni 
Reviewed-by: Marek Vasut 
Signed-off-by: Jonathan Cameron 
Signed-off-by: Greg Kroah-Hartman