On 08/15/11 17:47, Paul Thomas wrote: > On Mon, Aug 15, 2011 at 9:19 AM, Jonathan Cameron <jic23@xxxxxxxxx> wrote: >> On 08/15/11 16:57, Paul Thomas wrote: >>> On Mon, Aug 15, 2011 at 2:52 AM, Jonathan Cameron <jic23@xxxxxxxxx> wrote: >>>> On 08/14/11 21:18, Paul Thomas wrote: >>>>> This uses the iio sysfs interface, and inculdes gain >>>> includes >>>> >>>> Couple of left over bits from chan_spec conversion that need >>>> cleaning up and a that gain attribute wants to be done via the >>>> scale_shared chan_info element instead. >>> OK, most of that makes sense. I might have more questions latter, but >>> one question for now. You say to use the scale_shared for the gain >>> (can you point do a good example of this?) I just want to make sure >>> we're on the same page as to what the gain is doing. It's really just >>> setting the range of the voltage input I scale the result back down to >>> volts. So if the input voltage is 0.2V you get 0.2V Whether you set >>> the gain to 1 or 8 >> Ah, I missed that. In that case, given it's internal only, it should >> be IIO_CHAN_INFO_CALIBSCALE_SHARED and you should be setting processed_val >> in iio_chan_spec structures and scaling to millivolts not volts >> (we may change everything to volts but haven't done it yet). >> >> For a device like this we tend to leave things raw and use the scale attribute >> to tell userspace enough to know how to convert it to SI units. Doesn't >> matter so much with devices only being accessed over sysfs (hence fine here) >> but you don't want to waste time with conversions when pushing to a buffer. >> >> Jonathan >> > > OK, but isn't this just about what the best way to report the values? > What should the knob/hook from userspace be to set the gain/range? Two ways of doing this: 1) If reporting _raw values, the calibscale and calibbias are controls for an offset and scale applied inside the hardware. Here, control is done via scale and offset (as userspace has to apply these later anyway). There has been some debate about range and it is in the abi, but hasn't been added to chan_spec stuff yet. 2) If reporting _input (processed values) as you are here, then it looks to userspace as if hardware has already applied these values - hence conventionally we have been using calibscale and calibbias under that condition. Only place this really happened before is in the light sensors. There the transform is so hideous, it's not practical to tell userspace what it is, hence processing is done internally and calibscale is actually a software knob. So given your current situation, either use the range attribute (and add it to the chan spec core stuff) or use calibscale. Sorry for the slow reply, Jonathan -- 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
