On 07/28/11 09:36, Michael Hennerich wrote: > On 07/28/2011 10:36 AM, Jonathan Cameron wrote: >> On 07/28/11 09:08, Hennerich, Michael wrote: >>> Jonathan Cameron wrote on 2011-07-28: >>>> On 07/27/11 15:41, Michael Hennerich wrote: >>>>> On 07/26/2011 01:06 PM, Jonathan Cameron wrote: >>>>>> On 07/26/11 11:52, Michael Hennerich wrote: >>>>>>> On 07/26/2011 11:17 AM, Jonathan Cameron wrote: >>>>>>>> On 07/26/11 10:01, Hennerich, Michael wrote: >>>>>>>>> Jonathan Cameron wrote on 2011-07-25: >>>>>>>>>> Michael pointed out the issues that not having an explicit >>>>>>>>>> direction for channels was causing and the inconsistency of the >>>>>>>>>> inX and outX channel naming we got from hmwon. >>>>>>>>>> >>>>>>>>>> They are stuck with it, but we aren't, so lets fix this now. >>>>>>>>>> >>>>>>>>>> Interesting question is whether we reset the base units to be >>>>>>>>>> volts whilst we are at it? (for voltage channels obviously!) >>>>>>>>> What do you mean exactly volts versus milli volts? >>>>>>>> Make the in_voltage_scale correspond to conversion to volts instead >>>>>>>> of millivolts as now (I think). Err. Looking at it that isn't >>>>>>>> actually documented... oops. I wonder which drivers actually do >>>>>>>> that and which don't. >>>>>>> The ones I wrote provide the scale for millivolts. >>>>>>> With the recent introduction of IIO_VAL_INT_PLUS_NANO we got the >>>>>>> scale accurate enough for the precession 24-bit converters. >>>>>>> If we move to the SI base unit volt, we lose this accuracy again. >>>>>> Yup, that's the principal counter argument to the change. >>>>> If we decide to leave the milli scale for volts... Do we also want to >>>>> stay with milli degrees Celsius, etc.? If we do it for one, probably >>>>> best to do it for them all.. >>> Hi Jonathan, >>> >>> So stick with the milli scale for all? >> Yes. >>>>> One other thing we should also address is the >>>>> byte-ordering/endianess of the scan elements stored in the ring buffers. >>>>> >>>>> Right now the scan_element type details signs, bits, storage bits and >>>>> shifts. However it lacks to tell the endianess within the storage bits. >>>>> Good point. I'd completely forgotten about that. >>>>> >>>>> How about le:s16/32>>0 or be:s16/32>>0 for example? >>>> Yup, that works for me. In cases where it doesn't matter they driver >>>> can pick one at random. >>> >>> We need another case - Some drivers use the (be|le)(x)_to_cpu() helpers, >>> So in case these are used the endianess can be either or, depending on the host. >>> So maybe have le|be|cpu? >> I thought about that, but am inclined to say we just stop drivers doing the conversion. >> Better to leave it up to userspace? > Well - we have and definitely will have more drivers where the conversion may be > to time consuming to do in kernel space. > I really don't have a strong preference here - but the important thing is that we need > to tell user space what format is placed into the buffers. Agreed. Do it during move out of staging or do a mass push to the drivers now? -- 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
