Re: [IIO] Proposal for sysfs attributes

[Alan Cox]

> > Do we want to resemble the 'milli' units or should we stick to
> > standard SI units (radians, kelvin, etc.) as floating point math is
> > necessary anyway.
> I've cc'd a few people who have contributed to previous abi discussions
> for IIO in ways that make me think they may have opinions on this.

FP isn't needed you can let the drivers do fixed point quite happily -
the Intel compass driver intentionally does this.

Using milli is asking for problems. There are lots of units where "milli"
is actually quite big (millifarad, millihenry) and others where its
stupendously small (eV for example). It works for hwmon because hwmon
covers such a narrow range of devices and units.

So I'd favour FP because I think there are three choices

1.	Encode the value, define the scaling factor in the ABI (not
	future proof)

2.	Encode the value and scaling factor as two fields in the ABI
	(more future proof)

3.	As 2 but use the normal encoding for this which involves
	putting a "." in the right place and using one field (ie FP)

Drivers are simply going to end up doing this with sysfs values

	snprintf(buf, sizeof(buf), "%d.%02d", v/100, v%100);

or similar - or in many cases

	snprintf(buf, sizeof(buf), "%d0000000000", v);

neither of which is a big cost.

For a ring buffer you probably need to encode the scaling factor and
field width in some sort of interface description query and the values in
the bitstream.

Which raises an interesting question. The natural way to deal with sysfs
is decimal fixed point internally. If drivers are going to do both
sysfs and rings then really you want to be able to encode powers of 10
shifts not just bitshifts.

Alan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/