On 10/14/2012 05:05 PM, Denis Ciocca wrote: > Hi guys, > > according to your requests I have modified my driver. Only one things > about this function: > > static int acc_get_buffer_element(struct iio_dev *indio_dev, u8 *buf) > > You tell to me: > >> In buffered mode the samples should not be postprocessed. Userspace expects the >> samples in the format as described by the scan_type. The buffer demuxing should >> be handled by the IIO core. If you set up available_scan_masks correctly it >> will automatically do the right thing. > > I agree with you for the postprocessed samples part, but I don't understand very > well the second one. > I saw the other drivers, if I check only the available_scan_masks variable > I don't know which channels are actives and which not. > I will read every time all data channels, but I choose which channel > put in the buffer. You can tell the IIO core that you can only handle certain combinations of channels which can be sampled at the same time. E.g. in you case there is only one possible combination, which is that all channels are always sampled. If in userspace only a subset of that list is selected the IIO core will take of only passing those samples on to userspace which it actually requested. Right now you do this by hand in your driver. But if you setup scan_masks_available for you IIO device with only one scan mask which has all channels set you can skip that step and just pass the buffer containing all samples on to the IIO core and it will take care of picking those out which are actually needed. There are a few examples of this, grep for available_scan_masks to find them. I now there are also some examples of IIO drivers which do what you did in your driver, but these are older drivers which were written when the demuxing infrastructure in the core was not in place. But the plan is to switch this over as we continue to improve the existing drivers. Will try take a look at the new patch tomorrow. - Lars -- To unsubscribe from this list: send the line "unsubscribe linux-iio" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
