On 07/28/11 10:53, Michael Hennerich wrote: > On 07/28/2011 11:40 AM, Jonathan Cameron wrote: >> 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? >> > > removing the endianess conversion on the buffers needs to come along with the > scan_element type update. Not actually true. We can assume all current drivers are converting to cpu endianness so if it isn't specified output the local cpu endianess. Then we can move drivers over whenever we like. We'll squash the cpu option on move out of staging though as don't want that hanging around for ever more. > On one hand side its important information that > we currently missing, and should be fixed sooner than later. > On the other side it may require also some datasheet research. > But it shouldn't be to much, since all SPI devices typically use MSB first, so for > multiple bytes read sequentially we end up with BE. -- 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
