linux-stable.git/drivers/staging/comedi, branch linux-3.19.y

staging: comedi: adv_pci1710: fix AI INSN_READ for non-zero channel

2015-04-29T08:23:46+00:00

commit abe46b8932dd9a6dfc3698e3eb121809b7b9ed28 upstream.

Reading of analog input channels by the `INSN_READ` comedi instruction
is broken for all except channel 0.  `pci171x_ai_insn_read()` calls
`pci171x_ai_read_sample()` with the wrong value for the third parameter.
It is supposed to be the current index in a channel list (which is
always of length 1 in this case, so the index should be 0), but instead
it is passing the actual channel number.  `pci171x_ai_read_sample()`
checks the channel number encoded in the raw sample value read from the
hardware matches the channel number stored in the specified index of the
previously set up channel list and returns `-ENODATA` if it doesn't
match.  Since the index should always be 0 in this case, the match will
fail unless the channel number is also 0.  Fix it by passing 0 as the
channel index.

Note that when the bug first appeared, it was `pci171x_ai_dropout()`
that was called with the wrong parameter value.  `pci171x_ai_dropout()`
got replaced with `pci171x_ai_read_sample()` in commit 7fd2dae2500d
("staging: comedi: adv_pci1710: introduce pci171x_ai_read_sample()").

Fixes: 16c7eb6047bb ("staging: comedi: adv_pci1710: always enable PCI171x_PARANOIDCHECK code")
Signed-off-by: Ian Abbott 
Signed-off-by: Greg Kroah-Hartman

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

2015-03-18T13:11:08+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-18T13:11:07+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

staging: comedi: change some printk calls to pr_err

2014-12-03T00:54:43+00:00

There are a handful of calls to printk in ni_stc.h without specified log
levels, as well as one in ni_mio_common.c.  This patch converts these
calls to pr_err() instead, so that they are now explicitly log level
ERR.

Signed-off-by: Chase Southwood 
Reviewed-by: Ian Abbott 
Signed-off-by: Greg Kroah-Hartman

staging: comedi: adl_pci9118: eliminate DMA buffer defragmentation step

2014-12-03T00:31:20+00:00

The DMA operations used by the driver may have been set up to acquire
data from unwanted channels in addition to the wanted channels.
Currently, `interrupt_pci9118_ai_dma()` calls `defragment_dma_buffer()`
to move all the wanted data to the start of the DMA buffer and then
calls `comedi_buf_write_samples()` to copy it all to the comedi async
buffer.  Those two functions used to be called from
`move_block_from_dma()` which was absorbed into
`interrupt_pci9118_ai_dma()`.

Reinstate `move_block_from_dma()` but rewrite it to copy data directly
from the wanted fragments of the DMA buffer to the comedi async buffer
without defragmenting the buffer first.

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

staging: comedi: adl_pci9118: try and avoid unnecessary DMA restart

2014-12-03T00:31:20+00:00

`interrupt_pci9118_ai_dma()` is called on interrupt to transfer data
from DMA buffers into the comedi async data buffer.  Currently it always
restarts DMA.  If double buffering, it restarts DMA on the next DMA
buffer before processing the current DMA buffer, otherwise it restarts
DMA on the same DMA buffer after it has been processed.

For single buffering we can avoid restarting the DMA transfer by
checking the async event flags after the current buffer has been
processed, which is easy.

For double buffering, we need to know how many valid samples there are
in the current buffer before it has been processed and determine whether
there is enough to complete the acquisition.  Call new function
`valid_samples_in_act_dma_buf()` to determine the number of valid
samples in the current DMA buffer, and compare that with the result of
`comedi_nsamples_left()` to determine if DMA needs to be restarted.
(`comedi_nsamples_left()` needs an upper bound to clamp to, so use the
number of valid samples in the DMA buffer plus one for our test.)

It is still possible for DMA to be restarted unnecessarily in the double
buffer case if a `COMEDI_CB_OVERFLOW` event occurs while copying to the
comedi async buffer, but it doesn't really matter.  The ongoing DMA
operation will get disabled when the subdevice's `cancel()` handler is
called when the events are handled later in the interrupt service
routine (as it does currently).

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

staging: comedi: adl_pci9118: simplify interrupt_pci9118_ai_dma() a bit

2014-12-03T00:31:20+00:00

Eliminate the `next_dma_buf` variable in `interrupt_pci9118_ai_dma()`.
It holds the next value of `devpriv->dma_actbuf` when double buffering
is used, but we can just set that to the next value directly at the
point where the buffers are switched as the old value is not used
anywhere else.

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

staging: comedi: adv_pci1723: remove comedi_device 'write_subdev' init

2014-11-26T23:40:00+00:00

The comedi_device 'write_subdev' should only be initialized if the subdevice
supports async commands.

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

staging: comedi: adv_pci1723: tidy up multi-line comments

2014-11-26T23:40:00+00:00

Tidy up the multi-line comments to follow the CodingStyle.

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

staging: comedi: adv_pci1723: update the MODULE_DESCRIPTION

2014-11-26T23:40:00+00:00

Update the MODULE_DESCRIPTION to something more useful than the
generic "Comedi low-level driver".

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