On 21/01/15 16:36, Hartley Sweeten wrote:
On Wednesday, January 21, 2015 4:00 AM, Ian Abbott wrote:
On 20/01/15 19:00, H Hartley Sweeten wrote:
Modify the sample data returned by the async command to include the current
state of the digital inputs. Otherwise the command needs to be canceled in
order for the user to do an (*insn_bits) operation to check the digital
inputs.
Signed-off-by: H Hartley Sweeten <hsweeten@xxxxxxxxxxxxxxxxxxx>
Cc: Ian Abbott <abbotti@xxxxxxxxx>
Cc: Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx>
---
drivers/staging/comedi/drivers/aio_iiro_16.c | 33 ++++++++++++++++++++--------
1 file changed, 24 insertions(+), 9 deletions(-)
diff --git a/drivers/staging/comedi/drivers/aio_iiro_16.c b/drivers/staging/comedi/drivers/aio_iiro_16.c
index d8884a3..1c7b325 100644
--- a/drivers/staging/comedi/drivers/aio_iiro_16.c
+++ b/drivers/staging/comedi/drivers/aio_iiro_16.c
@@ -27,11 +27,14 @@
*
* The board supports interrupts on change of state of the digital inputs.
* The sample data returned by the async command indicates which inputs
- * changed state:
+ * changed state and the current state of the inputs:
*
- * Bit 7 - IRQ Enable (1) / Disable (0)
- * Bit 1 - Input 8-15 Changed State (1 = Changed, 0 = No Change)
- * Bit 0 - Input 0-7 Changed State (1 = Changed, 0 = No Change)
+ * Bit 23 - IRQ Enable (1) / Disable (0)
+ * Bit 17 - Input 8-15 Changed State (1 = Changed, 0 = No Change)
+ * Bit 16 - Input 0-7 Changed State (1 = Changed, 0 = No Change)
+ * Bit 15 - Digital input 15
+ * ...
+ * Bit 0 - Digital input 0
I'm wondering whether it should just indicate the state of the digital
inputs and not bother with the other stuff. Any thoughts?
If just the state of the inputs is returned is would get the sample size back
down to 16-bits.
But, I can see use cases where the user would want to know which 8-bit
"port" had the change of input. One port might be connected to inputs
that have low-priority handling and the other port has higher priority.
Knowing which port changed state would allow the users app to handle
them appropriately without needing to keep the previous state.
Regardless, I'm good either way as long as the input states are returned
so that the command does not need to be canceled in order to get them.
I suppose the extra bits can be useful for detecting short pulses where
the state of the digital inputs recorded by the interrupt handler call
is unchanged since the previous call. Having only two "changed state"
bits is kind of limited for that purpose, but better than nothing I
suppose! I don't really care either way, so:
Reviewed-by: Ian Abbott <abbotti@xxxxxxxxx>
--
-=( Ian Abbott @ MEV Ltd. E-mail: <abbotti@xxxxxxxxx> )=-
-=( Web: http://www.mev.co.uk/ )=-
_______________________________________________
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxx
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
