... > > Hi Jonathan, > > > root:/sys/devices/platform/bfin-spi.0/spi0.18/device0> ls > device0:buffer0 power > in-in_scale range > in0-in0_raw range_available > in1-in1_raw sampling_frequency > in2-in2_raw sampling_frequency_available > in3_raw subsystem > in4_supply_raw temp0_raw > in4_supply_scale temp_scale > in_scale trigger > name uevent > > root:/sys/devices/platform/bfin-spi.0/spi0.18/device0> cat in_scale > 0.000140 > > root:/sys/devices/platform/bfin-spi.0/spi0.18/device0> cat range_available > 2500 1250 625 312 156 78 39 19 > > root:/sys/devices/platform/bfin-spi.0/spi0.18/device0> echo 312 > range > root:/sys/devices/platform/bfin-spi.0/spi0.18/device0> cat in_scale > 0.000010 > > root:/sys/devices/platform/bfin-spi.0/spi0.18/device0> echo 78 > range > root:/sys/devices/platform/bfin-spi.0/spi0.18/device0> cat in_scale > 0.000000 > root:/sys/devices/platform/bfin-spi.0/spi0.18/device0> > > with these 24-bit converters and input AMPs we are already exhausted > the number of available digits we have for scale. Time for a new return type and extra logic in the core. IIO_VAL_INT_PLUS_NANO should still fit in a 32 bit long. Perhaps it's better to make a bigger jump - or this will just bite us again sometime soon. After nano we will have to start having padding zeros which is going to be a little strange - or I guess we don't have to keep val as being int... IIO_VAL_MICRO_PLUS_PICO maybe? The maximum option of IIO_VAL_NANO_PLUS_ATTO seems a little 'odd'. The more complex question is going to be writing values that are this small. I think we will have to add another callback into the drivers where they can query what format a value should be in so the core can provide it. Make this optional so it doesn't effect the majority of drivers where int + micro does the job. > > What shall we do? > > Also how would you name AIN1(-) - AIN1(-)? > > #define AD7793_CH_AIN1P_AIN1M 0 /* AIN1(+) - AIN1(-) */ > #define AD7793_CH_AIN2P_AIN2M 1 /* AIN2(+) - AIN2(-) */ > #define AD7793_CH_AIN3P_AIN3M 2 /* AIN3(+) - AIN3(-) */ > #define AD7793_CH_AIN1M_AIN1M 3 /* AIN1(-) - AIN1(-) */ > > in0-in0_zerooffset_raw ? Hmm.. That is awkward. Given only the channel numbers exist in event codes it will also possibly cause us issues at some later date. How about having in0-in0_raw then in0-in0_offset + in0-in0_offset_available. (actually this would be shared I guess so in-in_offset_available). A little clunky, but does fit better within the api. Is there a real use case for buffering where one grabs both offsets in the same scan? 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
