On 05/22/2013 04:00 PM, Guillaume Ballet wrote: > On Wed, May 22, 2013 at 3:39 PM, Lars-Peter Clausen <lars@xxxxxxxxxx> wrote: >> On 05/22/2013 03:29 PM, Guillaume Ballet wrote: >>> On Wed, May 22, 2013 at 1:43 PM, Lars-Peter Clausen <lars@xxxxxxxxxx> wrote: >>>> On 05/22/2013 11:37 AM, Guillaume Ballet wrote: >>>>>>> >>>>>>>> >>>>>>>>> functions' signature only has one integer >>>>>>>>> in/out parameter. That makes sense in the context of _raw because the >>>>>>>>> value isn't yet processed. >>>>>>>>> >>>>>>>>> However, as the scale is a number encoded over two ints, the >>>>>>>>> _processed value should also span two ints. Is there a reason why it's >>>>>>>>> still only one int? >>>>>>>> >>>>>>>> No it certainly should not be one int for exactly the reasons you have >>>>>>>> stated. >>>>>>>>> >>>>>>>>> >>>>>>> >>>>>>> I'm not to sure about that. I'd rather add a scale parameter to the >>>>>>> iio_read_channel_processed, just in the same way the >>>>>>> convert_raw_to_processed function takes a scale parameter. >>>>>> >>>>>> That may be tricky to do given we often have nasty non linear functions >>>>>> that are the reason we are using processed in the first place. Hmm. >>>>>> Not sure which way works better. >>>>> >>>>> I agree, this is the whole point of using processed. Lars, is there a >>>>> specific reason why you want to keep reading the value and the scale >>>>> in different function calls? >>>> >>>> I don't want to keep reading scale and value in different function calls. >>>> >>>> What's you use case and how do you want to split the data between the two >>>> integers? >>> >>> Since the scale's format can be IIO_VAL_INT_PLUS_MICRO and >>> IIO_VAL_INT_PLUS_NANO, etc... and since iio_read_channel_processed >>> returns a value that is homogeneous to (value * scale), it seems to me >>> the same format should be used as when calling iio_read_channel_raw >>> with IIO_CHAN_INFO_SCALE. My use case is not more complicated than >>> making sure I keep the same precision when getting processed values. >> >> That doesn't really help me understand what you are trying to do. What is >> your application, where do you call iio_read_channel_processed and how do >> you process the returned value. > > I have a driver for an ADC block that measures miscellaneous values in > various units (temperature, voltage, current...) to be read from > drivers in other kernel subsystems (the power supply class, for > instance). This already works today with the current implementation of iio_read_channel_processed. Unit conversion has to be done by the IIO device itself as > it's done using tables that are provided by various vendors who don't > want them published. So how do you include the tables in the IIO driver if they can't be published? > Hence my need to call iio_read_channel_processed > and not entrust anyone else with the conversion. Ah, ok, so your driver implements IIO_CHAN_INFO_PROCESSED instead of IIO_CHAN_INFO_RAW. And you want to be able to specify your value with sub-decimal precession, is this correct? > > Could _you_ please explain what your concern with using the same format is? Because the definition of IIO_CHAN_INFO_PROCESSED is that the value has already the proper unit and no unit conversion is necessary. - 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
