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. Regards, Hartley _______________________________________________ devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxx http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
