On 14 November 2016 10:30:50 GMT+00:00, Lars-Peter Clausen <lars@xxxxxxxxxx> wrote: >On 11/12/2016 03:24 PM, Jonathan Cameron wrote: >> On 11/11/16 14:18, Lars-Peter Clausen wrote: >>> On 11/11/2016 07:34 AM, Eva Rachel Retuya wrote: >>>> Eliminate the non-standard attribute in_voltage_range and move its >>>> functionality under the scale attribute. read_raw() has been taken >care >>>> of previously so only write_raw() is handled here. >>>> >>>> Additionally, rename the attribute in_voltage_range_available into >>>> in_voltage_scale_available. >>>> >>>> Suggested-by: Lars-Peter Clausen <lars@xxxxxxxxxx> >>>> Signed-off-by: Eva Rachel Retuya <eraretuya@xxxxxxxxx> >>> >>> Hi, >>> >>> Thanks for the patch. Unfortunately this is not quite this straight >forward. >>> >>> The scale is what you multiply the raw with to get the value in the >standard >>> IIO unit. Range as implemented in this driver is the maximum output >voltage. >>> >>> To get the scale we need to look at the transfer function of the ADC >[1]. >>> The transfer function tells us that 1 LSB is 305uV for the 10V range >and >>> 152uV for the 5V range. >>> >>> More specifically this is $RANGE*2/2**16 (times two since the ADC is >bipolar). >>> >>> Since the default unit for IIO is mV for voltages we need to >multiply this >>> by 1000. >>> >>> The other thing we need to handle is the case where the RANGE pin is >not >>> connected to a GPIO but either hardwired to 1 or 0. Which we need to >handle >>> somehow. >> Is it just me who thought, we need a fixed GPI like a fixed >regulator? >> Would allow this sort of fixed wiring to be simply defined. >> >> Linus, worth exploring? >> >> I doubt this will be the last case of this particular problem >> (not exactly unusual to hard wire control lines like these as which >range >> makes sense is often a feature of the device). >> >> Would be a pain to have to add code to every driver to cover the >fixed >> case. > >We still have to add code to every driver to cover the fixed case since >the >mode of operation is inherently different. But it would be nice to have >a >coherent way of doing so with a standardized interface rather than >having >every device come up with its own code and bindings. Agreed. Not totally obvious how to do it but definitely don't want to work around it by custom bindings all over the place. A simple is_gpo_fixed or similar would get the driver the info it needs. Could do it with errors but that would perhaps be ugly! The other flags related to type of input/output can be emulated so there doesn't seem to be anything similar... > >This could either be handled directly by the GPIO API or by a small set >of >helper functions on top of it. > >I think the most important part for now is to agree on a standard >binding to >describe hardwired GPIOs. We can still rework the kernel API later on, >but >the DT bindings will be set in stone. Agreed. Some magic gpio description or a fake gpio chip similar to fixed regs? 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 -- Sent from my Android device with K-9 Mail. Please excuse my brevity. -- 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
