On Friday, October 24, 2014 1:49 AM, Ian Abbott wrote: > On 23/10/14 17:35, Hartley Sweeten wrote: >> On Thursday, October 23, 2014 4:28 AM, Ian Abbott wrote: >>> On 22/10/14 23:37, H Hartley Sweeten wrote: >>>> Subdevices that set the SDF_PACKED flag return all the scan data in a single >>>> sample. The cmd->chanlist_len is used to pass the DIO channel information to >>>> the command and does not indicate the length (cmd->scan_end_arg) of the scan. >>> >>> In general, the scan data could be packed into more than one "sample", >>> but you can fit 8*bytes_per_sample() 1-bit samples in each "sample". In >>> practice, currently only the ni_pcidio driver sets the SDF_PACKED flag >>> (although some other drivers ought to set it) and the whole scan will >>> fit into a single "sample" in that case. >> >> Patches 47, 48, 50, and 51 add the SDF_PACKED flag to the addi_apci_2032, >> amplc_dio200_common, pcmmio, and pcmuio drivers. > > I appreciate that. It was something I was hoping to get around to, > especially as pcmmio and pcmuio had endian issues. [snip] >>> Is this patch even necessary? comedi_bytes_per_scan() assumes digital >>> samples will be packed into a whole number of "samples" and calculates >>> the scan length in bytes accordingly. >> >> I guess it's not really "necessary" but it adds clarification to what >> the SDF_PACKED flag does. Right now the only documentation >> for that flag is: >> >> #define SDF_PACKED 0x20000000 /* subdevice can do packed DIO */ >> >> But nothing in the core uses it. I don't think comedilib >> references the flag either. > > Applications could see it, though they would probably ignore it as well, > as any application using async commands for digital I/O probably needs > to be hardware specific as the order of data in the scan data doesn't > match the order of channels in the chanlist for all drivers. (Some just > return all channels in channel number order.) Should this be fixed? >> It took me a bit of head scratching to figure out why the >> ni_pcidio driver would be setting the flag. This seemed >> like the best way to make the core use the flag for >> something. >> >> As you pointed out, this will not work if a driver packs a scan >> into more than one "sample" (32-bits if the SDF_LSAMPL flag >> is set, 16-bits if not). But, it works for all the current comedi >> drivers. If necessary, a separate patch could be made to make >> it work if a driver does use more than one "sample" to pack the >> scan. > > But the original already works in that case! Fair enough. Greg, please drop this patch. Ian has signed off the rest of the series. Regards, Hartley _______________________________________________ devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxx http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
