Reviewed-by: Bernd Porr
Ian Abbott wrote:
The return value of the `cmdtest` handler for a subdevice checks the
prospective new command in various steps and returns the step number at
which any problem was detected, or 0 if no problem was detected. It is
allowed to modify the command
Reviewed-by: Bernd Porr
Ian Abbott wrote:
The return value of the `cmdtest` handler for a subdevice checks the
prospective new command in various steps and returns the step number at
which any problem was detected, or 0 if no problem was detected. It is
allowed to modify the command
Reviewed-by: Bernd Porr
Ian Abbott wrote:
The AI subdevice `cmdtest` handler `usbduxsigma_ai_cmdtest()` ensures
that `cmd->scan_begin_src == TRIG_TIMER` by the end of step 2 of the
command checking code, so assume that this is the case for step 3
onwards and remove the redundant code.
Sig
Reviewed-by: Bernd Porr
Ian Abbott wrote:
`devpriv->ao_timer` is used while an asynchronous command is running on
the AO subdevice. It also gets modified by the subdevice's `cmdtest`
handler for checking new asynchronous commands,
`usbduxsigma_ao_cmdtest()`, which is not correct as i
Reviewed-by: Bernd Porr
Ian Abbott wrote:
The `cmdtest` and `cmd` handlers for the AO subdevice
(`usbduxsigma_ao_cmdtest()` and `usbduxsigma_ao_cmd()`) support "scan"
timing of commands with all channels updated every "scan" period. There
is some disabled code to use &quo
Reviewed-by: Bernd Porr
Ian Abbott wrote:
`devpriv->ai_timer` is used while an asynchronous command is running on
the AI subdevice. It also gets modified by the subdevice's `cmdtest`
handler for checking new asynchronous commands
(`usbduxsigma_ai_cmdtest()`), which is not correct as i
Reviewed-by: Bernd Porr m...@berndporr.me.uk
Ian Abbott wrote:
The return value of the `cmdtest` handler for a subdevice checks the
prospective new command in various steps and returns the step number at
which any problem was detected, or 0 if no problem was detected. It is
allowed to modify
Reviewed-by: Bernd Porr m...@berndporr.me.uk
Ian Abbott wrote:
The AI subdevice `cmdtest` handler `usbduxsigma_ai_cmdtest()` ensures
that `cmd-scan_begin_src == TRIG_TIMER` by the end of step 2 of the
command checking code, so assume that this is the case for step 3
onwards and remove
Reviewed-by: Bernd Porr m...@berndporr.me.uk
Ian Abbott wrote:
`devpriv-ai_timer` is used while an asynchronous command is running on
the AI subdevice. It also gets modified by the subdevice's `cmdtest`
handler for checking new asynchronous commands
(`usbduxsigma_ai_cmdtest()`), which
Reviewed-by: Bernd Porr m...@berndporr.me.uk
Ian Abbott wrote:
The `cmdtest` and `cmd` handlers for the AO subdevice
(`usbduxsigma_ao_cmdtest()` and `usbduxsigma_ao_cmd()`) support scan
timing of commands with all channels updated every scan period. There
is some disabled code to use convert
Reviewed-by: Bernd Porr m...@berndporr.me.uk
Ian Abbott wrote:
`devpriv-ao_timer` is used while an asynchronous command is running on
the AO subdevice. It also gets modified by the subdevice's `cmdtest`
handler for checking new asynchronous commands,
`usbduxsigma_ao_cmdtest()`, which
Reviewed-by: Bernd Porr m...@berndporr.me.uk
Ian Abbott wrote:
The return value of the `cmdtest` handler for a subdevice checks the
prospective new command in various steps and returns the step number at
which any problem was detected, or 0 if no problem was detected. It is
allowed to modify
-dio_state = be32_to_cpu(devpriv->in_buf[0]);
-
/* get the data from the USB bus and hand it over to comedi */
for (i = 0; i < cmd->chanlist_len; i++) {
/* transfer data, note first byte is the DIO state */
Reviewed-by: Ian Abbott
...@mev.co.uk
Reviewed-by: Bernd Porr m...@berndporr.me.uk
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Indeed. It can be completely removed. I was intending to speed up DIO
reads during async acquisition but I decided against it because it would
create unpredictable latencies.
Thanks Ian for flagging it!
/Bernd
Ian Abbott wrote:
On 28/01/15 22:39, Rickard Strandqvist wrote:
Variable ar
Indeed. It can be completely removed. I was intending to speed up DIO
reads during async acquisition but I decided against it because it would
create unpredictable latencies.
Thanks Ian for flagging it!
/Bernd
Ian Abbott wrote:
On 28/01/15 22:39, Rickard Strandqvist wrote:
Variable ar
I've updated my contact details and removed obsolete comments.
Signed-off-by: Bernd Porr
---
drivers/staging/comedi/drivers/usbdux.c | 59 -
1 file changed, 28 insertions(+), 31 deletions(-)
diff --git a/drivers/staging/comedi/drivers/usbdux.c
b/drivers
Updated the range of years, e-mail and added driver desription as
usually done in comedi.
Signed-off-by: Bernd Porr
---
drivers/staging/comedi/drivers/usbduxfast.c | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/drivers/staging/comedi/drivers/usbduxfast.c
b
I've updated my contact details of the driver. I've also tested it
thoroughly and it works perfectly. I've changed the status to stable.
Signed-off-by: Bernd Porr
---
drivers/staging/comedi/drivers/usbduxsigma.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git
I've updated my contact details of the driver. I've also tested it
thoroughly and it works perfectly. I've changed the status to stable.
Signed-off-by: Bernd Porr m...@berndporr.me.uk
---
drivers/staging/comedi/drivers/usbduxsigma.c | 8
1 file changed, 4 insertions(+), 4 deletions
Updated the range of years, e-mail and added driver desription as
usually done in comedi.
Signed-off-by: Bernd Porr m...@berndporr.me.uk
---
drivers/staging/comedi/drivers/usbduxfast.c | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/drivers/staging/comedi/drivers
I've updated my contact details and removed obsolete comments.
Signed-off-by: Bernd Porr m...@berndporr.me.uk
---
drivers/staging/comedi/drivers/usbdux.c | 59 -
1 file changed, 28 insertions(+), 31 deletions(-)
diff --git a/drivers/staging/comedi/drivers
Looks quite promising. I would like to run comedi on a blackfin stamp.
Please keep me in the loop.
/Bernd
www:http://www.berndporr.me.uk/
http://www.linux-usb-daq.co.uk/
Mobile: +44 (0)7840 340069
Work: +44 (0)141 330 5237
University of Glasgow
Department of
Looks quite promising. I would like to run comedi on a blackfin stamp.
Please keep me in the loop.
/Bernd
www:http://www.berndporr.me.uk/
http://www.linux-usb-daq.co.uk/
Mobile: +44 (0)7840 340069
Work: +44 (0)141 330 5237
University of Glasgow
Department of
Hi There!
1.: SCSI lock-up when scanning with SNAPSCAN1236
2.:
I have an AGFA SNAP-scan 1236S and used it with the kernel
2.2.16 and with the new beta-test-kernel 2.4.0-test9.
The SCSI-Controller is a aha152x and is working fine with
the 2.2.16 kernel except that there is an error message from
Hi There!
1.: SCSI lock-up when scanning with SNAPSCAN1236
2.:
I have an AGFA SNAP-scan 1236S and used it with the kernel
2.2.16 and with the new beta-test-kernel 2.4.0-test9.
The SCSI-Controller is a aha152x and is working fine with
the 2.2.16 kernel except that there is an error message from
26 matches
Mail list logo
