* [PATCH 0/2] blue part 6: IIO abi rework
@ 2011-07-25 13:23 Jonathan Cameron
2011-07-25 13:23 ` [PATCH 1/2] staging:iio: ABI rework - add in_ or out_ prefix to channnels Jonathan Cameron
` (2 more replies)
0 siblings, 3 replies; 20+ messages in thread
From: Jonathan Cameron @ 2011-07-25 13:23 UTC (permalink / raw)
To: linux-iio; +Cc: Jonathan Cameron
Michael pointed out the issues that not having an explicit
direction for channels was causing and the inconsistency
of the inX and outX channel naming we got from hmwon.
They are stuck with it, but we aren't, so lets fix this now.
Interesting question is whether we reset the base units to be
volts whilst we are at it? (for voltage channels obviously!)
Given there will be a lot of auditing and datasheet reading
to do that, I suggest that if we decide to do it, we leave
that for when we are moving drivers out of staging.
We could roll the doc patch in with the one in the previous
series to reduce churn. If they go together I'll probably
do that.
Thanks,
Jonathan
Jonathan Cameron (2):
staging:iio: ABI rework - add in_ or out_ prefix to channnels
staging:iio:Documentation sysfs-bus-iio add in and out prefixes
drivers/staging/iio/Documentation/sysfs-bus-iio | 536 +++++++++++-----------
drivers/staging/iio/dac/ad5686.c | 24 +-
drivers/staging/iio/iio.h | 31 ++-
drivers/staging/iio/industrialio-core.c | 28 +-
4 files changed, 324 insertions(+), 295 deletions(-)
--
1.7.3.4
^ permalink raw reply [flat|nested] 20+ messages in thread* [PATCH 1/2] staging:iio: ABI rework - add in_ or out_ prefix to channnels 2011-07-25 13:23 [PATCH 0/2] blue part 6: IIO abi rework Jonathan Cameron @ 2011-07-25 13:23 ` Jonathan Cameron 2011-07-25 15:19 ` Jonathan Cameron 2011-07-25 13:23 ` [PATCH 2/2] staging:iio:Documentation sysfs-bus-iio add in and out prefixes Jonathan Cameron 2011-07-26 9:01 ` [PATCH 0/2] blue part 6: IIO abi rework Hennerich, Michael 2 siblings, 1 reply; 20+ messages in thread From: Jonathan Cameron @ 2011-07-25 13:23 UTC (permalink / raw) To: linux-iio; +Cc: Jonathan Cameron Also involves changing current inX outX to in_voltageX and out_voltageX Signed-off-by: Jonathan Cameron <jic23@cam.ac.uk> --- drivers/staging/iio/dac/ad5686.c | 24 ++++++++++++------------ drivers/staging/iio/iio.h | 31 +++++++++++++++++++++++++++---- drivers/staging/iio/industrialio-core.c | 28 +++++++++++++++++----------- 3 files changed, 56 insertions(+), 27 deletions(-) diff --git a/drivers/staging/iio/dac/ad5686.c b/drivers/staging/iio/dac/ad5686.c index fd67cfa..b7f62d1 100644 --- a/drivers/staging/iio/dac/ad5686.c +++ b/drivers/staging/iio/dac/ad5686.c @@ -99,57 +99,57 @@ enum ad5686_supported_device_ids { static const struct ad5686_chip_info ad5686_chip_info_tbl[] = { [ID_AD5684] = { - .channel[0] = IIO_CHAN(IIO_OUT, 0, 1, 0, NULL, 0, 0, + .channel[0] = IIO_CHAN_OUT(IIO_OUT, 0, 1, 0, NULL, 0, 0, (1 << IIO_CHAN_INFO_SCALE_SHARED), AD5686_ADDR_DAC0, 0, IIO_ST('u', 12, 16, 4), 0), - .channel[1] = IIO_CHAN(IIO_OUT, 0, 1, 0, NULL, 1, 0, + .channel[1] = IIO_CHAN_OUT(IIO_OUT, 0, 1, 0, NULL, 1, 0, (1 << IIO_CHAN_INFO_SCALE_SHARED), AD5686_ADDR_DAC1, 1, IIO_ST('u', 12, 16, 4), 0), - .channel[2] = IIO_CHAN(IIO_OUT, 0, 1, 0, NULL, 2, 0, + .channel[2] = IIO_CHAN_OUT(IIO_OUT, 0, 1, 0, NULL, 2, 0, (1 << IIO_CHAN_INFO_SCALE_SHARED), AD5686_ADDR_DAC2, 2, IIO_ST('u', 12, 16, 4), 0), - .channel[3] = IIO_CHAN(IIO_OUT, 0, 1, 0, NULL, 3, 0, + .channel[3] = IIO_CHAN_OUT(IIO_OUT, 0, 1, 0, NULL, 3, 0, (1 << IIO_CHAN_INFO_SCALE_SHARED), AD5686_ADDR_DAC3, 3, IIO_ST('u', 12, 16, 4), 0), .int_vref_mv = 2500, }, [ID_AD5685] = { - .channel[0] = IIO_CHAN(IIO_OUT, 0, 1, 0, NULL, 0, 0, + .channel[0] = IIO_CHAN_OUT(IIO_OUT, 0, 1, 0, NULL, 0, 0, (1 << IIO_CHAN_INFO_SCALE_SHARED), AD5686_ADDR_DAC0, 0, IIO_ST('u', 14, 16, 2), 0), - .channel[1] = IIO_CHAN(IIO_OUT, 0, 1, 0, NULL, 1, 0, + .channel[1] = IIO_CHAN_OUT(IIO_OUT, 0, 1, 0, NULL, 1, 0, (1 << IIO_CHAN_INFO_SCALE_SHARED), AD5686_ADDR_DAC1, 1, IIO_ST('u', 14, 16, 2), 0), - .channel[2] = IIO_CHAN(IIO_OUT, 0, 1, 0, NULL, 2, 0, + .channel[2] = IIO_CHAN_OUT(IIO_OUT, 0, 1, 0, NULL, 2, 0, (1 << IIO_CHAN_INFO_SCALE_SHARED), AD5686_ADDR_DAC2, 2, IIO_ST('u', 14, 16, 2), 0), - .channel[3] = IIO_CHAN(IIO_OUT, 0, 1, 0, NULL, 3, 0, + .channel[3] = IIO_CHAN_OUT(IIO_OUT, 0, 1, 0, NULL, 3, 0, (1 << IIO_CHAN_INFO_SCALE_SHARED), AD5686_ADDR_DAC3, 3, IIO_ST('u', 14, 16, 2), 0), .int_vref_mv = 2500, }, [ID_AD5686] = { - .channel[0] = IIO_CHAN(IIO_OUT, 0, 1, 0, NULL, 0, 0, + .channel[0] = IIO_CHAN_OUT(IIO_OUT, 0, 1, 0, NULL, 0, 0, (1 << IIO_CHAN_INFO_SCALE_SHARED), AD5686_ADDR_DAC0, 0, IIO_ST('u', 16, 16, 0), 0), - .channel[1] = IIO_CHAN(IIO_OUT, 0, 1, 0, NULL, 1, 0, + .channel[1] = IIO_CHAN_OUT(IIO_OUT, 0, 1, 0, NULL, 1, 0, (1 << IIO_CHAN_INFO_SCALE_SHARED), AD5686_ADDR_DAC1, 1, IIO_ST('u', 16, 16, 0), 0), - .channel[2] = IIO_CHAN(IIO_OUT, 0, 1, 0, NULL, 2, 0, + .channel[2] = IIO_CHAN_OUT(IIO_OUT, 0, 1, 0, NULL, 2, 0, (1 << IIO_CHAN_INFO_SCALE_SHARED), AD5686_ADDR_DAC2, 2, IIO_ST('u', 16, 16, 0), 0), - .channel[3] = IIO_CHAN(IIO_OUT, 0, 1, 0, NULL, 3, 0, + .channel[3] = IIO_CHAN_OUT(IIO_OUT, 0, 1, 0, NULL, 3, 0, (1 << IIO_CHAN_INFO_SCALE_SHARED), AD5686_ADDR_DAC3, 3, IIO_ST('u', 16, 16, 0), 0), diff --git a/drivers/staging/iio/iio.h b/drivers/staging/iio/iio.h index 74d427a..4311a36 100644 --- a/drivers/staging/iio/iio.h +++ b/drivers/staging/iio/iio.h @@ -24,12 +24,11 @@ enum iio_chan_type { /* real channel types */ - IIO_IN, - IIO_OUT, + IIO_VOLTAGE, IIO_CURRENT, IIO_POWER, IIO_ACCEL, - IIO_IN_DIFF, + IIO_VOLTAGE_DIFF, IIO_GYRO, IIO_MAGN, IIO_LIGHT, @@ -42,6 +41,11 @@ enum iio_chan_type { IIO_TIMESTAMP, }; +/* Nasty hack to avoid massive churn */ +#define IIO_IN IIO_VOLTAGE +#define IIO_OUT IIO_VOLTAGE +#define IIO_IN_DIFF IIO_VOLTAGE_DIFF + #define IIO_MOD_X 0 #define IIO_MOD_LIGHT_BOTH 0 #define IIO_MOD_Y 1 @@ -124,14 +128,33 @@ struct iio_chan_spec { unsigned processed_val:1; unsigned modified:1; unsigned indexed:1; + unsigned output:1; }; #define IIO_ST(si, rb, sb, sh) \ { .sign = si, .realbits = rb, .storagebits = sb, .shift = sh } -#define IIO_CHAN(_type, _mod, _indexed, _proc, _name, _chan, _chan2, \ +/* Macro assumes input channels */ +#define IIO_CHAN(_type, _mod, _indexed, _proc, _name, _chan, _chan2, \ + _inf_mask, _address, _si, _stype, _event_mask) \ + { .type = _type, \ + .output = 0, \ + .modified = _mod, \ + .indexed = _indexed, \ + .processed_val = _proc, \ + .extend_name = _name, \ + .channel = _chan, \ + .channel2 = _chan2, \ + .info_mask = _inf_mask, \ + .address = _address, \ + .scan_index = _si, \ + .scan_type = _stype, \ + .event_mask = _event_mask } +/* Output channels */ +#define IIO_CHAN_OUT(_type, _mod, _indexed, _proc, _name, _chan, _chan2, \ _inf_mask, _address, _si, _stype, _event_mask) \ { .type = _type, \ + .output = 1, \ .modified = _mod, \ .indexed = _indexed, \ .processed_val = _proc, \ diff --git a/drivers/staging/iio/industrialio-core.c b/drivers/staging/iio/industrialio-core.c index 195808c..06ffc48 100644 --- a/drivers/staging/iio/industrialio-core.c +++ b/drivers/staging/iio/industrialio-core.c @@ -42,13 +42,17 @@ struct bus_type iio_bus_type = { }; EXPORT_SYMBOL(iio_bus_type); +static const char * const iio_direction[] = { + [0] = "in", + [1] = "out", +}; + static const char * const iio_chan_type_name_spec_shared[] = { - [IIO_IN] = "in", - [IIO_OUT] = "out", + [IIO_VOLTAGE] = "voltage", [IIO_CURRENT] = "current", [IIO_POWER] = "power", [IIO_ACCEL] = "accel", - [IIO_IN_DIFF] = "in-in", + [IIO_VOLTAGE_DIFF] = "voltage-voltage", [IIO_GYRO] = "gyro", [IIO_MAGN] = "magn", [IIO_LIGHT] = "illuminance", @@ -62,7 +66,7 @@ static const char * const iio_chan_type_name_spec_shared[] = { }; static const char * const iio_chan_type_name_spec_complex[] = { - [IIO_IN_DIFF] = "in%d-in%d", + [IIO_VOLTAGE_DIFF] = "voltage%d-voltage%d", }; static const char * const iio_modifier_names_light[] = { @@ -518,19 +522,22 @@ int __iio_device_attr_init(struct device_attribute *dev_attr, goto error_ret; /* Special case for types that uses both channel numbers in naming */ - if (chan->type == IIO_IN_DIFF && !generic) + if (chan->type == IIO_VOLTAGE_DIFF && !generic) name_format - = kasprintf(GFP_KERNEL, "%s_%s", + = kasprintf(GFP_KERNEL, "%s_%s_%s", + iio_direction[chan->output], iio_chan_type_name_spec_complex[chan->type], full_postfix); else if (generic || !chan->indexed) name_format - = kasprintf(GFP_KERNEL, "%s_%s", + = kasprintf(GFP_KERNEL, "%s_%s_%s", + iio_direction[chan->output], iio_chan_type_name_spec_shared[chan->type], full_postfix); else name_format - = kasprintf(GFP_KERNEL, "%s%d_%s", + = kasprintf(GFP_KERNEL, "%s_%s%d_%s", + iio_direction[chan->output], iio_chan_type_name_spec_shared[chan->type], chan->channel, full_postfix); @@ -637,7 +644,6 @@ static int iio_device_add_channel_sysfs(struct iio_dev *dev_info, { int ret, i; - if (chan->channel < 0) return 0; if (chan->processed_val) @@ -870,7 +876,7 @@ static int iio_device_add_event_sysfs(struct iio_dev *dev_info, } switch (chan->type) { /* Switch this to a table at some point */ - case IIO_IN: + case IIO_VOLTAGE: mask = IIO_UNMOD_EVENT_CODE(chan->type, chan->channel, i/IIO_EV_TYPE_MAX, i%IIO_EV_TYPE_MAX); @@ -880,7 +886,7 @@ static int iio_device_add_event_sysfs(struct iio_dev *dev_info, i/IIO_EV_TYPE_MAX, i%IIO_EV_TYPE_MAX); break; - case IIO_IN_DIFF: + case IIO_VOLTAGE_DIFF: mask = IIO_MOD_EVENT_CODE(chan->type, chan->channel, chan->channel2, i/IIO_EV_TYPE_MAX, -- 1.7.3.4 ^ permalink raw reply related [flat|nested] 20+ messages in thread
* Re: [PATCH 1/2] staging:iio: ABI rework - add in_ or out_ prefix to channnels 2011-07-25 13:23 ` [PATCH 1/2] staging:iio: ABI rework - add in_ or out_ prefix to channnels Jonathan Cameron @ 2011-07-25 15:19 ` Jonathan Cameron 0 siblings, 0 replies; 20+ messages in thread From: Jonathan Cameron @ 2011-07-25 15:19 UTC (permalink / raw) To: Jonathan Cameron; +Cc: linux-iio On 07/25/11 14:23, Jonathan Cameron wrote: > Also involves changing current inX outX to in_voltageX and out_voltageX oops. Didn't handle the read / write selection of attributes. Fix is obvious so I'll roll it into next version. (just check chan->output instead of matching on IIO_OUT). > > Signed-off-by: Jonathan Cameron <jic23@cam.ac.uk> > --- > drivers/staging/iio/dac/ad5686.c | 24 ++++++++++++------------ > drivers/staging/iio/iio.h | 31 +++++++++++++++++++++++++++---- > drivers/staging/iio/industrialio-core.c | 28 +++++++++++++++++----------- > 3 files changed, 56 insertions(+), 27 deletions(-) > > diff --git a/drivers/staging/iio/dac/ad5686.c b/drivers/staging/iio/dac/ad5686.c > index fd67cfa..b7f62d1 100644 > --- a/drivers/staging/iio/dac/ad5686.c > +++ b/drivers/staging/iio/dac/ad5686.c > @@ -99,57 +99,57 @@ enum ad5686_supported_device_ids { > > static const struct ad5686_chip_info ad5686_chip_info_tbl[] = { > [ID_AD5684] = { > - .channel[0] = IIO_CHAN(IIO_OUT, 0, 1, 0, NULL, 0, 0, > + .channel[0] = IIO_CHAN_OUT(IIO_OUT, 0, 1, 0, NULL, 0, 0, > (1 << IIO_CHAN_INFO_SCALE_SHARED), > AD5686_ADDR_DAC0, > 0, IIO_ST('u', 12, 16, 4), 0), > - .channel[1] = IIO_CHAN(IIO_OUT, 0, 1, 0, NULL, 1, 0, > + .channel[1] = IIO_CHAN_OUT(IIO_OUT, 0, 1, 0, NULL, 1, 0, > (1 << IIO_CHAN_INFO_SCALE_SHARED), > AD5686_ADDR_DAC1, > 1, IIO_ST('u', 12, 16, 4), 0), > - .channel[2] = IIO_CHAN(IIO_OUT, 0, 1, 0, NULL, 2, 0, > + .channel[2] = IIO_CHAN_OUT(IIO_OUT, 0, 1, 0, NULL, 2, 0, > (1 << IIO_CHAN_INFO_SCALE_SHARED), > AD5686_ADDR_DAC2, > 2, IIO_ST('u', 12, 16, 4), 0), > - .channel[3] = IIO_CHAN(IIO_OUT, 0, 1, 0, NULL, 3, 0, > + .channel[3] = IIO_CHAN_OUT(IIO_OUT, 0, 1, 0, NULL, 3, 0, > (1 << IIO_CHAN_INFO_SCALE_SHARED), > AD5686_ADDR_DAC3, > 3, IIO_ST('u', 12, 16, 4), 0), > .int_vref_mv = 2500, > }, > [ID_AD5685] = { > - .channel[0] = IIO_CHAN(IIO_OUT, 0, 1, 0, NULL, 0, 0, > + .channel[0] = IIO_CHAN_OUT(IIO_OUT, 0, 1, 0, NULL, 0, 0, > (1 << IIO_CHAN_INFO_SCALE_SHARED), > AD5686_ADDR_DAC0, > 0, IIO_ST('u', 14, 16, 2), 0), > - .channel[1] = IIO_CHAN(IIO_OUT, 0, 1, 0, NULL, 1, 0, > + .channel[1] = IIO_CHAN_OUT(IIO_OUT, 0, 1, 0, NULL, 1, 0, > (1 << IIO_CHAN_INFO_SCALE_SHARED), > AD5686_ADDR_DAC1, > 1, IIO_ST('u', 14, 16, 2), 0), > - .channel[2] = IIO_CHAN(IIO_OUT, 0, 1, 0, NULL, 2, 0, > + .channel[2] = IIO_CHAN_OUT(IIO_OUT, 0, 1, 0, NULL, 2, 0, > (1 << IIO_CHAN_INFO_SCALE_SHARED), > AD5686_ADDR_DAC2, > 2, IIO_ST('u', 14, 16, 2), 0), > - .channel[3] = IIO_CHAN(IIO_OUT, 0, 1, 0, NULL, 3, 0, > + .channel[3] = IIO_CHAN_OUT(IIO_OUT, 0, 1, 0, NULL, 3, 0, > (1 << IIO_CHAN_INFO_SCALE_SHARED), > AD5686_ADDR_DAC3, > 3, IIO_ST('u', 14, 16, 2), 0), > .int_vref_mv = 2500, > }, > [ID_AD5686] = { > - .channel[0] = IIO_CHAN(IIO_OUT, 0, 1, 0, NULL, 0, 0, > + .channel[0] = IIO_CHAN_OUT(IIO_OUT, 0, 1, 0, NULL, 0, 0, > (1 << IIO_CHAN_INFO_SCALE_SHARED), > AD5686_ADDR_DAC0, > 0, IIO_ST('u', 16, 16, 0), 0), > - .channel[1] = IIO_CHAN(IIO_OUT, 0, 1, 0, NULL, 1, 0, > + .channel[1] = IIO_CHAN_OUT(IIO_OUT, 0, 1, 0, NULL, 1, 0, > (1 << IIO_CHAN_INFO_SCALE_SHARED), > AD5686_ADDR_DAC1, > 1, IIO_ST('u', 16, 16, 0), 0), > - .channel[2] = IIO_CHAN(IIO_OUT, 0, 1, 0, NULL, 2, 0, > + .channel[2] = IIO_CHAN_OUT(IIO_OUT, 0, 1, 0, NULL, 2, 0, > (1 << IIO_CHAN_INFO_SCALE_SHARED), > AD5686_ADDR_DAC2, > 2, IIO_ST('u', 16, 16, 0), 0), > - .channel[3] = IIO_CHAN(IIO_OUT, 0, 1, 0, NULL, 3, 0, > + .channel[3] = IIO_CHAN_OUT(IIO_OUT, 0, 1, 0, NULL, 3, 0, > (1 << IIO_CHAN_INFO_SCALE_SHARED), > AD5686_ADDR_DAC3, > 3, IIO_ST('u', 16, 16, 0), 0), > diff --git a/drivers/staging/iio/iio.h b/drivers/staging/iio/iio.h > index 74d427a..4311a36 100644 > --- a/drivers/staging/iio/iio.h > +++ b/drivers/staging/iio/iio.h > @@ -24,12 +24,11 @@ > > enum iio_chan_type { > /* real channel types */ > - IIO_IN, > - IIO_OUT, > + IIO_VOLTAGE, > IIO_CURRENT, > IIO_POWER, > IIO_ACCEL, > - IIO_IN_DIFF, > + IIO_VOLTAGE_DIFF, > IIO_GYRO, > IIO_MAGN, > IIO_LIGHT, > @@ -42,6 +41,11 @@ enum iio_chan_type { > IIO_TIMESTAMP, > }; > > +/* Nasty hack to avoid massive churn */ > +#define IIO_IN IIO_VOLTAGE > +#define IIO_OUT IIO_VOLTAGE > +#define IIO_IN_DIFF IIO_VOLTAGE_DIFF > + > #define IIO_MOD_X 0 > #define IIO_MOD_LIGHT_BOTH 0 > #define IIO_MOD_Y 1 > @@ -124,14 +128,33 @@ struct iio_chan_spec { > unsigned processed_val:1; > unsigned modified:1; > unsigned indexed:1; > + unsigned output:1; > }; > > #define IIO_ST(si, rb, sb, sh) \ > { .sign = si, .realbits = rb, .storagebits = sb, .shift = sh } > > -#define IIO_CHAN(_type, _mod, _indexed, _proc, _name, _chan, _chan2, \ > +/* Macro assumes input channels */ > +#define IIO_CHAN(_type, _mod, _indexed, _proc, _name, _chan, _chan2, \ > + _inf_mask, _address, _si, _stype, _event_mask) \ > + { .type = _type, \ > + .output = 0, \ > + .modified = _mod, \ > + .indexed = _indexed, \ > + .processed_val = _proc, \ > + .extend_name = _name, \ > + .channel = _chan, \ > + .channel2 = _chan2, \ > + .info_mask = _inf_mask, \ > + .address = _address, \ > + .scan_index = _si, \ > + .scan_type = _stype, \ > + .event_mask = _event_mask } > +/* Output channels */ > +#define IIO_CHAN_OUT(_type, _mod, _indexed, _proc, _name, _chan, _chan2, \ > _inf_mask, _address, _si, _stype, _event_mask) \ > { .type = _type, \ > + .output = 1, \ > .modified = _mod, \ > .indexed = _indexed, \ > .processed_val = _proc, \ > diff --git a/drivers/staging/iio/industrialio-core.c b/drivers/staging/iio/industrialio-core.c > index 195808c..06ffc48 100644 > --- a/drivers/staging/iio/industrialio-core.c > +++ b/drivers/staging/iio/industrialio-core.c > @@ -42,13 +42,17 @@ struct bus_type iio_bus_type = { > }; > EXPORT_SYMBOL(iio_bus_type); > > +static const char * const iio_direction[] = { > + [0] = "in", > + [1] = "out", > +}; > + > static const char * const iio_chan_type_name_spec_shared[] = { > - [IIO_IN] = "in", > - [IIO_OUT] = "out", > + [IIO_VOLTAGE] = "voltage", > [IIO_CURRENT] = "current", > [IIO_POWER] = "power", > [IIO_ACCEL] = "accel", > - [IIO_IN_DIFF] = "in-in", > + [IIO_VOLTAGE_DIFF] = "voltage-voltage", > [IIO_GYRO] = "gyro", > [IIO_MAGN] = "magn", > [IIO_LIGHT] = "illuminance", > @@ -62,7 +66,7 @@ static const char * const iio_chan_type_name_spec_shared[] = { > }; > > static const char * const iio_chan_type_name_spec_complex[] = { > - [IIO_IN_DIFF] = "in%d-in%d", > + [IIO_VOLTAGE_DIFF] = "voltage%d-voltage%d", > }; > > static const char * const iio_modifier_names_light[] = { > @@ -518,19 +522,22 @@ int __iio_device_attr_init(struct device_attribute *dev_attr, > goto error_ret; > > /* Special case for types that uses both channel numbers in naming */ > - if (chan->type == IIO_IN_DIFF && !generic) > + if (chan->type == IIO_VOLTAGE_DIFF && !generic) > name_format > - = kasprintf(GFP_KERNEL, "%s_%s", > + = kasprintf(GFP_KERNEL, "%s_%s_%s", > + iio_direction[chan->output], > iio_chan_type_name_spec_complex[chan->type], > full_postfix); > else if (generic || !chan->indexed) > name_format > - = kasprintf(GFP_KERNEL, "%s_%s", > + = kasprintf(GFP_KERNEL, "%s_%s_%s", > + iio_direction[chan->output], > iio_chan_type_name_spec_shared[chan->type], > full_postfix); > else > name_format > - = kasprintf(GFP_KERNEL, "%s%d_%s", > + = kasprintf(GFP_KERNEL, "%s_%s%d_%s", > + iio_direction[chan->output], > iio_chan_type_name_spec_shared[chan->type], > chan->channel, > full_postfix); > @@ -637,7 +644,6 @@ static int iio_device_add_channel_sysfs(struct iio_dev *dev_info, > { > int ret, i; > > - > if (chan->channel < 0) > return 0; > if (chan->processed_val) > @@ -870,7 +876,7 @@ static int iio_device_add_event_sysfs(struct iio_dev *dev_info, > } > switch (chan->type) { > /* Switch this to a table at some point */ > - case IIO_IN: > + case IIO_VOLTAGE: > mask = IIO_UNMOD_EVENT_CODE(chan->type, chan->channel, > i/IIO_EV_TYPE_MAX, > i%IIO_EV_TYPE_MAX); > @@ -880,7 +886,7 @@ static int iio_device_add_event_sysfs(struct iio_dev *dev_info, > i/IIO_EV_TYPE_MAX, > i%IIO_EV_TYPE_MAX); > break; > - case IIO_IN_DIFF: > + case IIO_VOLTAGE_DIFF: > mask = IIO_MOD_EVENT_CODE(chan->type, chan->channel, > chan->channel2, > i/IIO_EV_TYPE_MAX, ^ permalink raw reply [flat|nested] 20+ messages in thread
* [PATCH 2/2] staging:iio:Documentation sysfs-bus-iio add in and out prefixes 2011-07-25 13:23 [PATCH 0/2] blue part 6: IIO abi rework Jonathan Cameron 2011-07-25 13:23 ` [PATCH 1/2] staging:iio: ABI rework - add in_ or out_ prefix to channnels Jonathan Cameron @ 2011-07-25 13:23 ` Jonathan Cameron 2011-07-26 9:01 ` [PATCH 0/2] blue part 6: IIO abi rework Hennerich, Michael 2 siblings, 0 replies; 20+ messages in thread From: Jonathan Cameron @ 2011-07-25 13:23 UTC (permalink / raw) To: linux-iio; +Cc: Jonathan Cameron Also includes the inX -> in_voltageX and outX -> out_voltageX conversions. To keep lines short quite a lot of supressing of directories was needed. Signed-off-by: Jonathan Cameron <jic23@cam.ac.uk> --- drivers/staging/iio/Documentation/sysfs-bus-iio | 536 +++++++++++----------- 1 files changed, 268 insertions(+), 268 deletions(-) diff --git a/drivers/staging/iio/Documentation/sysfs-bus-iio b/drivers/staging/iio/Documentation/sysfs-bus-iio index dfc12a9..1e49529 100644 --- a/drivers/staging/iio/Documentation/sysfs-bus-iio +++ b/drivers/staging/iio/Documentation/sysfs-bus-iio @@ -83,8 +83,8 @@ Contact: linux-iio@vger.kernel.org Description: Hardware dependent values supported by the oversampling filter. -What: /sys/bus/iio/devices/iio:deviceX/inY_raw -What: /sys/bus/iio/devices/iio:deviceX/inY_supply_raw +What: /sys/bus/iio/devices/iio:deviceX/in_voltageY_raw +What: /sys/bus/iio/devices/iio:deviceX/in_voltageY_supply_raw KernelVersion: 2.6.35 Contact: linux-iio@vger.kernel.org Description: @@ -94,7 +94,7 @@ Description: versions may be used. The number must always be specified and unique to allow association with event codes. -What: /sys/bus/iio/devices/iio:deviceX/inY-inZ_raw +What: /sys/bus/iio/devices/iio:deviceX/in_voltageY-voltageZ_raw KernelVersion: 2.6.35 Contact: linux-iio@vger.kernel.org Description: @@ -104,10 +104,10 @@ Description: separately available. In differential only parts, then all that is required is a consistent labeling. -What: /sys/bus/iio/devices/iio:deviceX/temp_raw -What: /sys/bus/iio/devices/iio:deviceX/temp_x_raw -What: /sys/bus/iio/devices/iio:deviceX/temp_y_raw -What: /sys/bus/iio/devices/iio:deviceX/temp_z_raw +What: /sys/bus/iio/devices/iio:deviceX/in_temp_raw +What: /sys/bus/iio/devices/iio:deviceX/in_temp_x_raw +What: /sys/bus/iio/devices/iio:deviceX/in_temp_y_raw +What: /sys/bus/iio/devices/iio:deviceX/in_temp_z_raw KernelVersion: 2.6.35 Contact: linux-iio@vger.kernel.org Description: @@ -116,15 +116,15 @@ Description: sensor is associated with one part of a compound device (e.g. a gyroscope axis). -What: /sys/bus/iio/devices/iio:deviceX/tempX_input +What: /sys/bus/iio/devices/iio:deviceX/in_tempX_input KernelVersion: 2.6.38 Contact: linux-iio@vger.kernel.org Description: Scaled temperature measurement in milli degrees Celsius. -What: /sys/bus/iio/devices/iio:deviceX/accel_x_raw -What: /sys/bus/iio/devices/iio:deviceX/accel_y_raw -What: /sys/bus/iio/devices/iio:deviceX/accel_z_raw +What: /sys/bus/iio/devices/iio:deviceX/in_accel_x_raw +What: /sys/bus/iio/devices/iio:deviceX/in_accel_y_raw +What: /sys/bus/iio/devices/iio:deviceX/in_accel_z_raw KernelVersion: 2.6.35 Contact: linux-iio@vger.kernel.org Description: @@ -132,22 +132,22 @@ Description: but should match other such assignments on device) channel m (not present if only one accelerometer channel at this orientation). Has all of the equivalent parameters as per - inY. Units after application of scale and offset are m/s^2. + voltageY. Units after application of scale and offset are m/s^2. -What: /sys/bus/iio/devices/iio:deviceX/gyro_x_raw -What: /sys/bus/iio/devices/iio:deviceX/gyro_y_raw -What: /sys/bus/iio/devices/iio:deviceX/gyro_z_raw +What: /sys/bus/iio/devices/iio:deviceX/in_gyro_x_raw +What: /sys/bus/iio/devices/iio:deviceX/in_gyro_y_raw +What: /sys/bus/iio/devices/iio:deviceX/in_gyro_z_raw KernelVersion: 2.6.35 Contact: linux-iio@vger.kernel.org Description: Angular velocity about axis x, y or z (may be arbitrarily assigned) Data converted by application of offset then scale to radians per second. Has all the equivalent parameters as - per inY. + per voltageY. -What: /sys/bus/iio/devices/iio:deviceX/incli_x_raw -What: /sys/bus/iio/devices/iio:deviceX/incli_y_raw -What: /sys/bus/iio/devices/iio:deviceX/incli_z_raw +What: /sys/bus/iio/devices/iio:deviceX/in_incli_x_raw +What: /sys/bus/iio/devices/iio:deviceX/in_incli_y_raw +What: /sys/bus/iio/devices/iio:deviceX/in_incli_z_raw KernelVersion: 2.6.35 Contact: linux-iio@vger.kernel.org Description: @@ -155,9 +155,9 @@ Description: arbitrarily assigned). Data converted by application of offset and scale to Degrees. -What: /sys/bus/iio/devices/iio:deviceX/magn_x_raw -What: /sys/bus/iio/devices/iio:deviceX/magn_y_raw -What: /sys/bus/iio/devices/iio:deviceX/magn_z_raw +What: /sys/bus/iio/devices/iio:deviceX/in_magn_x_raw +What: /sys/bus/iio/devices/iio:deviceX/in_magn_y_raw +What: /sys/bus/iio/devices/iio:deviceX/in_magn_z_raw KernelVersion: 2.6.35 Contact: linux-iio@vger.kernel.org Description: @@ -165,11 +165,11 @@ Description: assigned) channel m (not present if only one magnetometer at this orientation). Data converted by application of offset then scale to Gauss. Has all the equivalent modifiers - as per inY. + as per voltageY. -What: /sys/bus/iio/devices/iio:deviceX/accel_x_peak_raw -What: /sys/bus/iio/devices/iio:deviceX/accel_y_peak_raw -What: /sys/bus/iio/devices/iio:deviceX/accel_z_peak_raw +What: /sys/bus/iio/devices/iio:deviceX/in_accel_x_peak_raw +What: /sys/bus/iio/devices/iio:deviceX/in_accel_y_peak_raw +What: /sys/bus/iio/devices/iio:deviceX/in_accel_z_peak_raw KernelVersion: 2.6.36 Contact: linux-iio@vger.kernel.org Description: @@ -178,15 +178,15 @@ Description: and are otherwise the direct equivalent of the <type>Y[_name]_raw attributes. -What: /sys/bus/iio/devices/iio:deviceX/accel_xyz_squared_peak_raw +What: /sys/bus/iio/devices/iio:deviceX/in_accel_xyz_squared_peak_raw KernelVersion: 2.6.36 Contact: linux-iio@vger.kernel.org Description: A computed peak value based on the sum squared magnitude of the underlying value in the specified directions. -What: /sys/bus/iio/devices/iio:deviceX/accel_offset -What: /sys/bus/iio/devices/iio:deviceX/temp_offset +What: /sys/bus/iio/devices/iio:deviceX/in_accel_offset +What: /sys/bus/iio/devices/iio:deviceX/in_temp_offset KernelVersion: 2.6.35 Contact: linux-iio@vger.kernel.org Description: @@ -201,17 +201,17 @@ Description: for variation between different instances of the part, typically adjusted by using some hardware supported calibration procedure. -What: /sys/bus/iio/devices/iio:deviceX/inY_scale -What: /sys/bus/iio/devices/iio:deviceX/inY_supply_scale -What: /sys/bus/iio/devices/iio:deviceX/in_scale -What: /sys/bus/iio/devices/iio:deviceX/outY_scale -What: /sys/bus/iio/devices/iio:deviceX/accel_scale -What: /sys/bus/iio/devices/iio:deviceX/accel_peak_scale -What: /sys/bus/iio/devices/iio:deviceX/gyro_scale -What: /sys/bus/iio/devices/iio:deviceX/magn_scale -What: /sys/bus/iio/devices/iio:deviceX/magn_x_scale -What: /sys/bus/iio/devices/iio:deviceX/magn_y_scale -What: /sys/bus/iio/devices/iio:deviceX/magn_z_scale +What: /sys/bus/iio/devices/iio:deviceX/in_voltageY_scale +What: /sys/bus/iio/devices/iio:deviceX/in_voltageY_supply_scale +What: /sys/bus/iio/devices/iio:deviceX/in_voltage_scale +What: /sys/bus/iio/devices/iio:deviceX/out_voltageY_scale +What: /sys/bus/iio/devices/iio:deviceX/in_accel_scale +What: /sys/bus/iio/devices/iio:deviceX/in_accel_peak_scale +What: /sys/bus/iio/devices/iio:deviceX/in_gyro_scale +What: /sys/bus/iio/devices/iio:deviceX/in_magn_scale +What: /sys/bus/iio/devices/iio:deviceX/in_magn_x_scale +What: /sys/bus/iio/devices/iio:deviceX/in_magn_y_scale +What: /sys/bus/iio/devices/iio:deviceX/in_magn_z_scale KernelVersion: 2.6.35 Contact: linux-iio@vger.kernel.org Description: @@ -223,12 +223,12 @@ Description: <type>[Y][_name]_scale. The peak modifier means this value is applied to <type>Y[_name]_peak_raw values. -What: /sys/bus/iio/devices/iio:deviceX/accel_x_calibbias -What: /sys/bus/iio/devices/iio:deviceX/accel_y_calibbias -What: /sys/bus/iio/devices/iio:deviceX/accel_z_calibbias -What: /sys/bus/iio/devices/iio:deviceX/gyro_x_calibbias -What: /sys/bus/iio/devices/iio:deviceX/gyro_y_calibbias -What: /sys/bus/iio/devices/iio:deviceX/gyro_z_calibbias +What: /sys/bus/iio/devices/iio:deviceX/in_accel_x_calibbias +What: /sys/bus/iio/devices/iio:deviceX/in_accel_y_calibbias +What: /sys/bus/iio/devices/iio:deviceX/in_accel_z_calibbias +What: /sys/bus/iio/devices/iio:deviceX/in_gyro_x_calibbias +What: /sys/bus/iio/devices/iio:deviceX/in_gyro_y_calibbias +What: /sys/bus/iio/devices/iio:deviceX/in_gyro_z_calibbias KernelVersion: 2.6.35 Contact: linux-iio@vger.kernel.org Description: @@ -236,15 +236,15 @@ Description: inaccuracies). If shared across all channels, <type>_calibbias is used. -What /sys/bus/iio/devices/iio:deviceX/inY_calibscale -What /sys/bus/iio/devices/iio:deviceX/inY_supply_calibscale -What /sys/bus/iio/devices/iio:deviceX/in_calibscale -What /sys/bus/iio/devices/iio:deviceX/accel_x_calibscale -What /sys/bus/iio/devices/iio:deviceX/accel_y_calibscale -What /sys/bus/iio/devices/iio:deviceX/accel_z_calibscale -What /sys/bus/iio/devices/iio:deviceX/gyro_x_calibscale -What /sys/bus/iio/devices/iio:deviceX/gyro_y_calibscale -What /sys/bus/iio/devices/iio:deviceX/gyro_z_calibscale +What /sys/bus/iio/devices/iio:deviceX/in_voltageY_calibscale +What /sys/bus/iio/devices/iio:deviceX/in_voltageY_supply_calibscale +What /sys/bus/iio/devices/iio:deviceX/in_voltage_calibscale +What /sys/bus/iio/devices/iio:deviceX/in_accel_x_calibscale +What /sys/bus/iio/devices/iio:deviceX/in_accel_y_calibscale +What /sys/bus/iio/devices/iio:deviceX/in_accel_z_calibscale +What /sys/bus/iio/devices/iio:deviceX/in_gyro_x_calibscale +What /sys/bus/iio/devices/iio:deviceX/in_gyro_y_calibscale +What /sys/bus/iio/devices/iio:deviceX/in_gyro_z_calibscale KernelVersion: 2.6.35 Contact: linux-iio@vger.kernel.org Description: @@ -252,14 +252,14 @@ Description: production inaccuracies). If shared across all channels, <type>_calibscale is used. -What: /sys/bus/iio/devices/iio:deviceX/accel_scale_available +What: /sys/bus/iio/devices/iio:deviceX/in_accel_scale_available KernelVersion: 2.635 Contact: linux-iio@vger.kernel.org Description: If a discrete set of scale values are available, they are listed in this attribute. -What: /sys/bus/iio/devices/iio:deviceX/outY_raw +What: /sys/bus/iio/devices/iio:deviceX/out_votlageY_raw KernelVersion: 2.6.37 Contact: linux-iio@vger.kernel.org Description: @@ -267,7 +267,7 @@ Description: channel Y. The number must always be specified and unique if the output corresponds to a single channel. -What: /sys/bus/iio/devices/iio:deviceX/outY&Z_raw +What: /sys/bus/iio/devices/iio:deviceX/out_voltageY&Z_raw KernelVersion: 2.6.37 Contact: linux-iio@vger.kernel.org Description: @@ -276,8 +276,8 @@ Description: where a single output sets the value for multiple channels simultaneously. -What: /sys/bus/iio/devices/iio:deviceX/outY_powerdown_mode -What: /sys/bus/iio/devices/iio:deviceX/out_powerdown_mode +What: /sys/bus/iio/devices/iio:deviceX/out_voltageY_powerdown_mode +What: /sys/bus/iio/devices/iio:deviceX/out_voltage_powerdown_mode KernelVersion: 2.6.38 Contact: linux-iio@vger.kernel.org Description: @@ -290,16 +290,16 @@ Description: outX_powerdown_mode_available. If Y is not present the mode is shared across all outputs. -What: /sys/bus/iio/devices/iio:deviceX/outY_powerdown_mode_available -What: /sys/bus/iio/devices/iio:deviceX/out_powerdown_mode_available +What: /sys/.../iio:deviceX/out_votlageY_powerdown_mode_available +What: /sys/.../iio:deviceX/out_voltage_powerdown_mode_available KernelVersion: 2.6.38 Contact: linux-iio@vger.kernel.org Description: Lists all available output power down modes. If Y is not present the mode is shared across all outputs. -What: /sys/bus/iio/devices/iio:deviceX/outY_powerdown -What: /sys/bus/iio/devices/iio:deviceX/out_powerdown +What: /sys/bus/iio/devices/iio:deviceX/out_voltageY_powerdown +What: /sys/bus/iio/devices/iio:deviceX/out_voltage_powerdown KernelVersion: 2.6.38 Contact: linux-iio@vger.kernel.org Description: @@ -315,30 +315,30 @@ Description: Configuration of which hardware generated events are passed up to user-space. -What: /sys/.../iio:deviceX/events/accel_x_thresh_rising_en -What: /sys/.../iio:deviceX/events/accel_x_thresh_falling_en -What: /sys/.../iio:deviceX/events/accel_y_thresh_rising_en -What: /sys/.../iio:deviceX/events/accel_y_thresh_falling_en -What: /sys/.../iio:deviceX/events/accel_z_thresh_rising_en -What: /sys/.../iio:deviceX/events/accel_z_thresh_falling_en -What: /sys/.../iio:deviceX/events/gyro_x_thresh_rising_en -What: /sys/.../iio:deviceX/events/gyro_x_thresh_falling_en -What: /sys/.../iio:deviceX/events/gyro_y_thresh_rising_en -What: /sys/.../iio:deviceX/events/gyro_y_thresh_falling_en -What: /sys/.../iio:deviceX/events/gyro_z_thresh_rising_en -What: /sys/.../iio:deviceX/events/gyro_z_thresh_falling_en -What: /sys/.../iio:deviceX/events/magn_x_thresh_rising_en -What: /sys/.../iio:deviceX/events/magn_x_thresh_falling_en -What: /sys/.../iio:deviceX/events/magn_y_thresh_rising_en -What: /sys/.../iio:deviceX/events/magn_y_thresh_falling_en -What: /sys/.../iio:deviceX/events/magn_z_thresh_rising_en -What: /sys/.../iio:deviceX/events/magn_z_thresh_falling_en -What: /sys/.../iio:deviceX/events/inZ_supply_thresh_rising_en -What: /sys/.../iio:deviceX/events/inZ_supply_thresh_falling_en -What: /sys/.../iio:deviceX/events/inZ_thresh_rising_en -What: /sys/.../iio:deviceX/events/inZ_thresh_falling_en -What: /sys/.../iio:deviceX/events/temp_thresh_rising_en -What: /sys/.../iio:deviceX/events/temp_thresh_falling_en +What: /sys/.../iio:deviceX/events/in_accel_x_thresh_rising_en +What: /sys/.../iio:deviceX/events/in_accel_x_thresh_falling_en +What: /sys/.../iio:deviceX/events/in_accel_y_thresh_rising_en +What: /sys/.../iio:deviceX/events/in_accel_y_thresh_falling_en +What: /sys/.../iio:deviceX/events/in_accel_z_thresh_rising_en +What: /sys/.../iio:deviceX/events/in_accel_z_thresh_falling_en +What: /sys/.../iio:deviceX/events/in_gyro_x_thresh_rising_en +What: /sys/.../iio:deviceX/events/in_gyro_x_thresh_falling_en +What: /sys/.../iio:deviceX/events/in_gyro_y_thresh_rising_en +What: /sys/.../iio:deviceX/events/in_gyro_y_thresh_falling_en +What: /sys/.../iio:deviceX/events/in_gyro_z_thresh_rising_en +What: /sys/.../iio:deviceX/events/in_gyro_z_thresh_falling_en +What: /sys/.../iio:deviceX/events/in_magn_x_thresh_rising_en +What: /sys/.../iio:deviceX/events/in_magn_x_thresh_falling_en +What: /sys/.../iio:deviceX/events/in_magn_y_thresh_rising_en +What: /sys/.../iio:deviceX/events/in_magn_y_thresh_falling_en +What: /sys/.../iio:deviceX/events/in_magn_z_thresh_rising_en +What: /sys/.../iio:deviceX/events/in_magn_z_thresh_falling_en +What: /sys/.../iio:deviceX/events/in_voltageZ_supply_thresh_rising_en +What: /sys/.../iio:deviceX/events/in_voltageZ_supply_thresh_falling_en +What: /sys/.../iio:deviceX/events/in_voltageZ_thresh_rising_en +What: /sys/.../iio:deviceX/events/in_voltageZ_thresh_falling_en +What: /sys/.../iio:deviceX/events/in_temp_thresh_rising_en +What: /sys/.../iio:deviceX/events/in_temp_thresh_falling_en KernelVersion: 2.6.37 Contact: linux-iio@vger.kernel.org Description: @@ -360,30 +360,30 @@ Description: a given event type is enabled a future point (and not those for whatever event was previously enabled). -What: /sys/.../iio:deviceX/events/accel_x_roc_rising_en -What: /sys/.../iio:deviceX/events/accel_x_roc_falling_en -What: /sys/.../iio:deviceX/events/accel_y_roc_rising_en -What: /sys/.../iio:deviceX/events/accel_y_roc_falling_en -What: /sys/.../iio:deviceX/events/accel_z_roc_rising_en -What: /sys/.../iio:deviceX/events/accel_z_roc_falling_en -What: /sys/.../iio:deviceX/events/gyro_x_roc_rising_en -What: /sys/.../iio:deviceX/events/gyro_x_roc_falling_en -What: /sys/.../iio:deviceX/events/gyro_y_roc_rising_en -What: /sys/.../iio:deviceX/events/gyro_y_roc_falling_en -What: /sys/.../iio:deviceX/events/gyro_z_roc_rising_en -What: /sys/.../iio:deviceX/events/gyro_z_roc_falling_en -What: /sys/.../iio:deviceX/events/magn_x_roc_rising_en -What: /sys/.../iio:deviceX/events/magn_x_roc_falling_en -What: /sys/.../iio:deviceX/events/magn_y_roc_rising_en -What: /sys/.../iio:deviceX/events/magn_y_roc_falling_en -What: /sys/.../iio:deviceX/events/magn_z_roc_rising_en -What: /sys/.../iio:deviceX/events/magn_z_roc_falling_en -What: /sys/.../iio:deviceX/events/inZ_supply_roc_rising_en -What: /sys/.../iio:deviceX/events/inZ_supply_roc_falling_en -What: /sys/.../iio:deviceX/events/inZ_roc_rising_en -What: /sys/.../iio:deviceX/events/inZ_roc_falling_en -What: /sys/.../iio:deviceX/events/temp_roc_rising_en -What: /sys/.../iio:deviceX/events/temp_roc_falling_en +What: /sys/.../iio:deviceX/events/in_accel_x_roc_rising_en +What: /sys/.../iio:deviceX/events/in_accel_x_roc_falling_en +What: /sys/.../iio:deviceX/events/in_accel_y_roc_rising_en +What: /sys/.../iio:deviceX/events/in_accel_y_roc_falling_en +What: /sys/.../iio:deviceX/events/in_accel_z_roc_rising_en +What: /sys/.../iio:deviceX/events/in_accel_z_roc_falling_en +What: /sys/.../iio:deviceX/events/in_gyro_x_roc_rising_en +What: /sys/.../iio:deviceX/events/in_gyro_x_roc_falling_en +What: /sys/.../iio:deviceX/events/in_gyro_y_roc_rising_en +What: /sys/.../iio:deviceX/events/in_gyro_y_roc_falling_en +What: /sys/.../iio:deviceX/events/in_gyro_z_roc_rising_en +What: /sys/.../iio:deviceX/events/in_gyro_z_roc_falling_en +What: /sys/.../iio:deviceX/events/in_magn_x_roc_rising_en +What: /sys/.../iio:deviceX/events/in_magn_x_roc_falling_en +What: /sys/.../iio:deviceX/events/in_magn_y_roc_rising_en +What: /sys/.../iio:deviceX/events/in_magn_y_roc_falling_en +What: /sys/.../iio:deviceX/events/in_magn_z_roc_rising_en +What: /sys/.../iio:deviceX/events/in_magn_z_roc_falling_en +What: /sys/.../iio:deviceX/events/in_voltageZ_supply_roc_rising_en +What: /sys/.../iio:deviceX/events/in_voltageZ_supply_roc_falling_en +What: /sys/.../iio:deviceX/events/in_voltageZ_roc_rising_en +What: /sys/.../iio:deviceX/events/in_voltageZ_roc_falling_en +What: /sys/.../iio:deviceX/events/in_temp_roc_rising_en +What: /sys/.../iio:deviceX/events/in_temp_roc_falling_en KernelVersion: 2.6.37 Contact: linux-iio@vger.kernel.org Description: @@ -406,30 +406,30 @@ Description: a given event type is enabled a future point (and not those for whatever event was previously enabled). -What: /sys/.../iio:deviceX/events/accel_x_raw_thresh_rising_value -What: /sys/.../iio:deviceX/events/accel_x_raw_thresh_falling_value -What: /sys/.../iio:deviceX/events/accel_y_raw_thresh_rising_value -What: /sys/.../iio:deviceX/events/accel_y_raw_thresh_falling_value -What: /sys/.../iio:deviceX/events/accel_z_raw_thresh_rising_value -What: /sys/.../iio:deviceX/events/accel_z_raw_thresh_falling_value -What: /sys/.../iio:deviceX/events/gyro_x_raw_thresh_rising_value -What: /sys/.../iio:deviceX/events/gyro_x_raw_thresh_falling_value -What: /sys/.../iio:deviceX/events/gyro_y_raw_thresh_rising_value -What: /sys/.../iio:deviceX/events/gyro_y_raw_thresh_falling_value -What: /sys/.../iio:deviceX/events/gyro_z_raw_thresh_rising_value -What: /sys/.../iio:deviceX/events/gyro_z_raw_thresh_falling_value -What: /sys/.../iio:deviceX/events/magn_x_raw_thresh_rising_value -What: /sys/.../iio:deviceX/events/magn_x_raw_thresh_falling_value -What: /sys/.../iio:deviceX/events/magn_y_raw_thresh_rising_value -What: /sys/.../iio:deviceX/events/magn_y_raw_thresh_falling_value -What: /sys/.../iio:deviceX/events/magn_z_raw_thresh_rising_value -What: /sys/.../iio:deviceX/events/magn_z_raw_thresh_falling_value -What: /sys/.../iio:deviceX/events/inZ_supply_raw_thresh_rising_value -What: /sys/.../iio:deviceX/events/inZ_supply_raw_thresh_falling_value -What: /sys/.../iio:deviceX/events/inZ_raw_thresh_falling_value -What: /sys/.../iio:deviceX/events/inZ_raw_thresh_falling_value -What: /sys/.../iio:deviceX/events/temp_raw_thresh_falling_value -What: /sys/.../iio:deviceX/events/temp_raw_thresh_falling_value +What: /sys/.../events/in_accel_x_raw_thresh_rising_value +What: /sys/.../events/in_accel_x_raw_thresh_falling_value +What: /sys/.../events/in_accel_y_raw_thresh_rising_value +What: /sys/.../events/in_accel_y_raw_thresh_falling_value +What: /sys/.../events/in_accel_z_raw_thresh_rising_value +What: /sys/.../events/in_accel_z_raw_thresh_falling_value +What: /sys/.../events/in_gyro_x_raw_thresh_rising_value +What: /sys/.../events/in_gyro_x_raw_thresh_falling_value +What: /sys/.../events/in_gyro_y_raw_thresh_rising_value +What: /sys/.../events/in_gyro_y_raw_thresh_falling_value +What: /sys/.../events/in_gyro_z_raw_thresh_rising_value +What: /sys/.../events/in_gyro_z_raw_thresh_falling_value +What: /sys/.../events/in_magn_x_raw_thresh_rising_value +What: /sys/.../events/in_magn_x_raw_thresh_falling_value +What: /sys/.../events/in_magn_y_raw_thresh_rising_value +What: /sys/.../events/in_magn_y_raw_thresh_falling_value +What: /sys/.../events/in_magn_z_raw_thresh_rising_value +What: /sys/.../events/in_magn_z_raw_thresh_falling_value +What: /sys/.../events/in_voltageZ_supply_raw_thresh_rising_value +What: /sys/.../events/in_voltageZ_supply_raw_thresh_falling_value +What: /sys/.../events/in_voltageZ_raw_thresh_falling_value +What: /sys/.../events/in_voltageZ_raw_thresh_falling_value +What: /sys/.../events/in_temp_raw_thresh_falling_value +What: /sys/.../events/in_temp_raw_thresh_falling_value KernelVersion: 2.6.37 Contact: linux-iio@vger.kernel.org Description: @@ -443,30 +443,30 @@ Description: value is in raw device units or in processed units (as _raw and _input do on sysfs direct channel read attributes). -What: /sys/.../iio:deviceX/events/accel_x_raw_roc_rising_value -What: /sys/.../iio:deviceX/events/accel_x_raw_roc_falling_value -What: /sys/.../iio:deviceX/events/accel_y_raw_roc_rising_value -What: /sys/.../iio:deviceX/events/accel_y_raw_roc_falling_value -What: /sys/.../iio:deviceX/events/accel_z_raw_roc_rising_value -What: /sys/.../iio:deviceX/events/accel_z_raw_roc_falling_value -What: /sys/.../iio:deviceX/events/gyro_x_raw_roc_rising_value -What: /sys/.../iio:deviceX/events/gyro_x_raw_roc_falling_value -What: /sys/.../iio:deviceX/events/gyro_y_raw_roc_rising_value -What: /sys/.../iio:deviceX/events/gyro_y_raw_roc_falling_value -What: /sys/.../iio:deviceX/events/gyro_z_raw_roc_rising_value -What: /sys/.../iio:deviceX/events/gyro_z_raw_roc_falling_value -What: /sys/.../iio:deviceX/events/magn_x_raw_roc_rising_value -What: /sys/.../iio:deviceX/events/magn_x_raw_roc_falling_value -What: /sys/.../iio:deviceX/events/magn_y_raw_roc_rising_value -What: /sys/.../iio:deviceX/events/magn_y_raw_roc_falling_value -What: /sys/.../iio:deviceX/events/magn_z_raw_roc_rising_value -What: /sys/.../iio:deviceX/events/magn_z_raw_roc_falling_value -What: /sys/.../iio:deviceX/events/inZ_supply_raw_roc_rising_value -What: /sys/.../iio:deviceX/events/inZ_supply_raw_roc_falling_value -What: /sys/.../iio:deviceX/events/inZ_raw_roc_falling_value -What: /sys/.../iio:deviceX/events/inZ_raw_roc_falling_value -What: /sys/.../iio:deviceX/events/temp_raw_roc_falling_value -What: /sys/.../iio:deviceX/events/temp_raw_roc_falling_value +What: /sys/.../events/in_accel_x_raw_roc_rising_value +What: /sys/.../events/in_accel_x_raw_roc_falling_value +What: /sys/.../events/in_accel_y_raw_roc_rising_value +What: /sys/.../events/in_accel_y_raw_roc_falling_value +What: /sys/.../events/in_accel_z_raw_roc_rising_value +What: /sys/.../events/in_accel_z_raw_roc_falling_value +What: /sys/.../events/in_gyro_x_raw_roc_rising_value +What: /sys/.../events/in_gyro_x_raw_roc_falling_value +What: /sys/.../events/in_gyro_y_raw_roc_rising_value +What: /sys/.../events/in_gyro_y_raw_roc_falling_value +What: /sys/.../events/in_gyro_z_raw_roc_rising_value +What: /sys/.../events/in_gyro_z_raw_roc_falling_value +What: /sys/.../events/in_magn_x_raw_roc_rising_value +What: /sys/.../events/in_magn_x_raw_roc_falling_value +What: /sys/.../events/in_magn_y_raw_roc_rising_value +What: /sys/.../events/in_magn_y_raw_roc_falling_value +What: /sys/.../events/in_magn_z_raw_roc_rising_value +What: /sys/.../events/in_magn_z_raw_roc_falling_value +What: /sys/.../events/in_voltageZ_supply_raw_roc_rising_value +What: /sys/.../events/in_voltageZ_supply_raw_roc_falling_value +What: /sys/.../events/in_voltageZ_raw_roc_falling_value +What: /sys/.../events/in_voltageZ_raw_roc_falling_value +What: /sys/.../events/in_temp_raw_roc_falling_value +What: /sys/.../events/in_temp_raw_roc_falling_value KernelVersion: 2.6.37 Contact: linux-iio@vger.kernel.org Description: @@ -480,55 +480,55 @@ Description: value is in raw device units or in processed units (as _raw and _input do on sysfs direct channel read attributes). -What: /sys/.../iio:deviceX/events/accel_x_thresh_rising_period -What: /sys/.../iio:deviceX/events/accel_x_thresh_falling_period -hat: /sys/.../iio:deviceX/events/accel_x_roc_rising_period -What: /sys/.../iio:deviceX/events/accel_x_roc_falling_period -What: /sys/.../iio:deviceX/events/accel_y_thresh_rising_period -What: /sys/.../iio:deviceX/events/accel_y_thresh_falling_period -What: /sys/.../iio:deviceX/events/accel_y_roc_rising_period -What: /sys/.../iio:deviceX/events/accel_y_roc_falling_period -What: /sys/.../iio:deviceX/events/accel_z_thresh_rising_period -What: /sys/.../iio:deviceX/events/accel_z_thresh_falling_period -What: /sys/.../iio:deviceX/events/accel_z_roc_rising_period -What: /sys/.../iio:deviceX/events/accel_z_roc_falling_period -What: /sys/.../iio:deviceX/events/gyro_x_thresh_rising_period -What: /sys/.../iio:deviceX/events/gyro_x_thresh_falling_period -What: /sys/.../iio:deviceX/events/gyro_x_roc_rising_period -What: /sys/.../iio:deviceX/events/gyro_x_roc_falling_period -What: /sys/.../iio:deviceX/events/gyro_y_thresh_rising_period -What: /sys/.../iio:deviceX/events/gyro_y_thresh_falling_period -What: /sys/.../iio:deviceX/events/gyro_y_roc_rising_period -What: /sys/.../iio:deviceX/events/gyro_y_roc_falling_period -What: /sys/.../iio:deviceX/events/gyro_z_thresh_rising_period -What: /sys/.../iio:deviceX/events/gyro_z_thresh_falling_period -What: /sys/.../iio:deviceX/events/gyro_z_roc_rising_period -What: /sys/.../iio:deviceX/events/gyro_z_roc_falling_period -What: /sys/.../iio:deviceX/events/magn_x_thresh_rising_period -What: /sys/.../iio:deviceX/events/magn_x_thresh_falling_period -What: /sys/.../iio:deviceX/events/magn_x_roc_rising_period -What: /sys/.../iio:deviceX/events/magn_x_roc_falling_period -What: /sys/.../iio:deviceX/events/magn_y_thresh_rising_period -What: /sys/.../iio:deviceX/events/magn_y_thresh_falling_period -What: /sys/.../iio:deviceX/events/magn_y_roc_rising_period -What: /sys/.../iio:deviceX/events/magn_y_roc_falling_period -What: /sys/.../iio:deviceX/events/magn_z_thresh_rising_period -What: /sys/.../iio:deviceX/events/magn_z_thresh_falling_period -What: /sys/.../iio:deviceX/events/magn_z_roc_rising_period -What: /sys/.../iio:deviceX/events/magn_z_roc_falling_period -What: /sys/.../iio:deviceX/events/inZ_supply_thresh_rising_period -What: /sys/.../iio:deviceX/events/inZ_supply_thresh_falling_period -What: /sys/.../iio:deviceX/events/inz_supply_roc_rising_period -What: /sys/.../iio:deviceX/events/inZ_supply_roc_falling_period -What: /sys/.../iio:deviceX/events/inZ_thresh_rising_period -What: /sys/.../iio:deviceX/events/inZ_thresh_falling_period -What: /sys/.../iio:deviceX/events/inZ_roc_rising_period -What: /sys/.../iio:deviceX/events/inZ_roc_falling_period -What: /sys/.../iio:deviceX/events/temp_thresh_rising_period -What: /sys/.../iio:deviceX/events/temp_thresh_falling_period -What: /sys/.../iio:deviceX/events/temp_roc_rising_period -What: /sys/.../iio:deviceX/events/temp_roc_falling_period -What: /sys/.../iio:deviceX/events/accel_x&y&z_mag_falling_period +What: /sys/.../events/in_accel_x_thresh_rising_period +What: /sys/.../events/in_accel_x_thresh_falling_period +hat: /sys/.../events/in_accel_x_roc_rising_period +What: /sys/.../events/in_accel_x_roc_falling_period +What: /sys/.../events/in_accel_y_thresh_rising_period +What: /sys/.../events/in_accel_y_thresh_falling_period +What: /sys/.../events/in_accel_y_roc_rising_period +What: /sys/.../events/in_accel_y_roc_falling_period +What: /sys/.../events/in_accel_z_thresh_rising_period +What: /sys/.../events/in_accel_z_thresh_falling_period +What: /sys/.../events/in_accel_z_roc_rising_period +What: /sys/.../events/in_accel_z_roc_falling_period +What: /sys/.../events/in_gyro_x_thresh_rising_period +What: /sys/.../events/in_gyro_x_thresh_falling_period +What: /sys/.../events/in_gyro_x_roc_rising_period +What: /sys/.../events/in_gyro_x_roc_falling_period +What: /sys/.../events/in_gyro_y_thresh_rising_period +What: /sys/.../events/in_gyro_y_thresh_falling_period +What: /sys/.../events/in_gyro_y_roc_rising_period +What: /sys/.../events/in_gyro_y_roc_falling_period +What: /sys/.../events/in_gyro_z_thresh_rising_period +What: /sys/.../events/in_gyro_z_thresh_falling_period +What: /sys/.../events/in_gyro_z_roc_rising_period +What: /sys/.../events/in_gyro_z_roc_falling_period +What: /sys/.../events/in_magn_x_thresh_rising_period +What: /sys/.../events/in_magn_x_thresh_falling_period +What: /sys/.../events/in_magn_x_roc_rising_period +What: /sys/.../events/in_magn_x_roc_falling_period +What: /sys/.../events/in_magn_y_thresh_rising_period +What: /sys/.../events/in_magn_y_thresh_falling_period +What: /sys/.../events/in_magn_y_roc_rising_period +What: /sys/.../events/in_magn_y_roc_falling_period +What: /sys/.../events/in_magn_z_thresh_rising_period +What: /sys/.../events/in_magn_z_thresh_falling_period +What: /sys/.../events/in_magn_z_roc_rising_period +What: /sys/.../events/in_magn_z_roc_falling_period +What: /sys/.../events/in_voltageZ_supply_thresh_rising_period +What: /sys/.../events/in_voltageZ_supply_thresh_falling_period +What: /sys/.../events/in_voltagez_supply_roc_rising_period +What: /sys/.../events/in_voltageZ_supply_roc_falling_period +What: /sys/.../events/in_voltageZ_thresh_rising_period +What: /sys/.../events/in_voltageZ_thresh_falling_period +What: /sys/.../events/in_voltageZ_roc_rising_period +What: /sys/.../events/in_voltageZ_roc_falling_period +What: /sys/.../events/in_temp_thresh_rising_period +What: /sys/.../events/in_temp_thresh_falling_period +What: /sys/.../events/in_temp_roc_rising_period +What: /sys/.../events/in_temp_roc_falling_period +What: /sys/.../events/in_accel_x&y&z_mag_falling_period KernelVersion: 2.6.37 Contact: linux-iio@vger.kernel.org Description: @@ -536,31 +536,31 @@ Description: met before an event is generated. If direction is not specified then this period applies to both directions. -What: /sys/.../iio:deviceX/events/accel_mag_en -What: /sys/.../iio:deviceX/events/accel_mag_rising_en -What: /sys/.../iio:deviceX/events/accel_mag_falling_en -What: /sys/.../iio:deviceX/events/accel_x_mag_en -What: /sys/.../iio:deviceX/events/accel_x_mag_rising_en -What: /sys/.../iio:deviceX/events/accel_x_mag_falling_en -What: /sys/.../iio:deviceX/events/accel_y_mag_en -What: /sys/.../iio:deviceX/events/accel_y_mag_rising_en -What: /sys/.../iio:deviceX/events/accel_y_mag_falling_en -What: /sys/.../iio:deviceX/events/accel_z_mag_en -What: /sys/.../iio:deviceX/events/accel_z_mag_rising_en -What: /sys/.../iio:deviceX/events/accel_z_mag_falling_en -What: /sys/.../iio:deviceX/events/accel_x&y&z_mag_rising_en -What: /sys/.../iio:deviceX/events/accel_x&y&z_mag_falling_en +What: /sys/.../iio:deviceX/events/in_accel_mag_en +What: /sys/.../iio:deviceX/events/in_accel_mag_rising_en +What: /sys/.../iio:deviceX/events/in_accel_mag_falling_en +What: /sys/.../iio:deviceX/events/in_accel_x_mag_en +What: /sys/.../iio:deviceX/events/in_accel_x_mag_rising_en +What: /sys/.../iio:deviceX/events/in_accel_x_mag_falling_en +What: /sys/.../iio:deviceX/events/in_accel_y_mag_en +What: /sys/.../iio:deviceX/events/in_accel_y_mag_rising_en +What: /sys/.../iio:deviceX/events/in_accel_y_mag_falling_en +What: /sys/.../iio:deviceX/events/in_accel_z_mag_en +What: /sys/.../iio:deviceX/events/in_accel_z_mag_rising_en +What: /sys/.../iio:deviceX/events/in_accel_z_mag_falling_en +What: /sys/.../iio:deviceX/events/in_accel_x&y&z_mag_rising_en +What: /sys/.../iio:deviceX/events/in_accel_x&y&z_mag_falling_en KernelVersion: 2.6.37 Contact: linux-iio@vger.kernel.org Description: - Similar to accel_x_thresh[_rising|_falling]_en, but here the + Similar to in_accel_x_thresh[_rising|_falling]_en, but here the magnitude of the channel is compared to the threshold, not its signed value. -What: /sys/.../accel_raw_mag_value -What: /sys/.../accel_x_raw_mag_rising_value -What: /sys/.../accel_y_raw_mag_rising_value -What: /sys/.../accel_z_raw_mag_rising_value +What: /sys/.../events/in_accel_raw_mag_value +What: /sys/.../events/in_accel_x_raw_mag_rising_value +What: /sys/.../events/in_accel_y_raw_mag_rising_value +What: /sys/.../events/in_accel_z_raw_mag_rising_value KernelVersion: 2.6.37 Contact: linux-iio@vger.kernel.org Description: @@ -602,34 +602,34 @@ Description: Directory containing interfaces for elements that will be captured for a single triggered sample set in the buffer. -What: /sys/.../iio:deviceX/buffer/scan_elements/accel_x_en -What: /sys/.../iio:deviceX/buffer/scan_elements/accel_y_en -What: /sys/.../iio:deviceX/buffer/scan_elements/accel_z_en -What: /sys/.../iio:deviceX/buffer/scan_elements/gyro_x_en -What: /sys/.../iio:deviceX/buffer/scan_elements/gyro_y_en -What: /sys/.../iio:deviceX/buffer/scan_elements/gyro_z_en -What: /sys/.../iio:deviceX/buffer/scan_elements/magn_x_en -What: /sys/.../iio:deviceX/buffer/scan_elements/magn_y_en -What: /sys/.../iio:deviceX/buffer/scan_elements/magn_z_en -What: /sys/.../iio:deviceX/buffer/scan_elements/timestamp_en -What: /sys/.../iio:deviceX/buffer/scan_elements/inY_supply_en -What: /sys/.../iio:deviceX/buffer/scan_elements/inY_en -What: /sys/.../iio:deviceX/buffer/scan_elements/inY-inZ_en -What: /sys/.../iio:deviceX/buffer/scan_elements/incli_x_en -What: /sys/.../iio:deviceX/buffer/scan_elements/incli_y_en +What: /sys/.../buffer/scan_elements/in_accel_x_en +What: /sys/.../buffer/scan_elements/in_accel_y_en +What: /sys/.../buffer/scan_elements/in_accel_z_en +What: /sys/.../buffer/scan_elements/in_gyro_x_en +What: /sys/.../buffer/scan_elements/in_gyro_y_en +What: /sys/.../buffer/scan_elements/in_gyro_z_en +What: /sys/.../buffer/scan_elements/in_magn_x_en +What: /sys/.../buffer/scan_elements/in_magn_y_en +What: /sys/.../buffer/scan_elements/in_magn_z_en +What: /sys/.../buffer/scan_elements/in_timestamp_en +What: /sys/.../buffer/scan_elements/in_voltageY_supply_en +What: /sys/.../buffer/scan_elements/in_voltageY_en +What: /sys/.../buffer/scan_elements/in_voltageY-voltageZ_en +What: /sys/.../buffer/scan_elements/in_incli_x_en +What: /sys/.../buffer/scan_elements/in_incli_y_en KernelVersion: 2.6.37 Contact: linux-iio@vger.kernel.org Description: Scan element control for triggered data capture. -What: /sys/.../iio:deviceX/buffer/scan_elements/accel_type -What: /sys/.../iio:deviceX/buffer/scan_elements/gyro_type -What: /sys/.../iio:deviceX/buffer/scan_elements/magn_type -What: /sys/.../iio:deviceX/buffer/scan_elements/incli_type -What: /sys/.../iio:deviceX/buffer/scan_elements/inY_type -What: /sys/.../iio:deviceX/buffer/scan_elements/in-in_type -What: /sys/.../iio:deviceX/buffer/scan_elements/inY_supply_type -What: /sys/.../iio:deviceX/buffer/scan_elements/timestamp_type +What: /sys/.../buffer/scan_elements/in_accel_type +What: /sys/.../buffer/scan_elements/in_gyro_type +What: /sys/.../buffer/scan_elements/in_magn_type +What: /sys/.../buffer/scan_elements/in_incli_type +What: /sys/.../buffer/scan_elements/in_voltageY_type +What: /sys/.../buffer/scan_elements/in_voltage-in_type +What: /sys/.../buffer/scan_elements/in_voltageY_supply_type +What: /sys/.../buffer/scan_elements/in_timestamp_type KernelVersion: 2.6.37 Contact: linux-iio@vger.kernel.org Description: @@ -652,27 +652,27 @@ Description: For other storage combinations this attribute will be extended appropriately. -What: /sys/.../iio:deviceX/buffer/scan_elements/accel_type_available +What: /sys/.../buffer/scan_elements/in_accel_type_available KernelVersion: 2.6.37 Contact: linux-iio@vger.kernel.org Description: If the type parameter can take one of a small set of values, this attribute lists them. -What: /sys/.../iio:deviceX/buffer/scan_elements/inY_index -What: /sys/.../iio:deviceX/buffer/scan_elements/inY_supply_index -What: /sys/.../iio:deviceX/buffer/scan_elements/accel_x_index -What: /sys/.../iio:deviceX/buffer/scan_elements/accel_y_index -What: /sys/.../iio:deviceX/buffer/scan_elements/accel_z_index -What: /sys/.../iio:deviceX/buffer/scan_elements/gyro_x_index -What: /sys/.../iio:deviceX/buffer/scan_elements/gyro_y_index -What: /sys/.../iio:deviceX/buffer/scan_elements/gyro_z_index -What: /sys/.../iio:deviceX/buffer/scan_elements/magn_x_index -What: /sys/.../iio:deviceX/buffer/scan_elements/magn_y_index -What: /sys/.../iio:deviceX/buffer/scan_elements/magn_z_index -What: /sys/.../iio:deviceX/buffer/scan_elements/incli_x_index -What: /sys/.../iio:deviceX/buffer/scan_elements/incli_y_index -What: /sys/.../iio:deviceX/buffer/scan_elements/in_timestamp_index +What: /sys/.../buffer/scan_elements/in_voltageY_index +What: /sys/.../buffer/scan_elements/in_voltageY_supply_index +What: /sys/.../buffer/scan_elements/in_accel_x_index +What: /sys/.../buffer/scan_elements/in_accel_y_index +What: /sys/.../buffer/scan_elements/in_accel_z_index +What: /sys/.../buffer/scan_elements/in_gyro_x_index +What: /sys/.../buffer/scan_elements/in_gyro_y_index +What: /sys/.../buffer/scan_elements/in_gyro_z_index +What: /sys/.../buffer/scan_elements/in_magn_x_index +What: /sys/.../buffer/scan_elements/in_magn_y_index +What: /sys/.../buffer/scan_elements/in_magn_z_index +What: /sys/.../buffer/scan_elements/in_incli_x_index +What: /sys/.../buffer/scan_elements/in_incli_y_index +What: /sys/.../buffer/scan_elements/in_voltage_timestamp_index KernelVersion: 2.6.37 Contact: linux-iio@vger.kernel.org Description: @@ -684,9 +684,9 @@ Description: and the relevant _type attributes to establish the data storage format. -What: /sys/.../iio:deviceX/gyro_z_quadrature_correction_raw +What: /sys/.../iio:deviceX/in_gyro_z_quadrature_correction_raw KernelVersion: 2.6.38 -Contact: linux-iio@xxxxxxxxxxxxxxx +Contact: linux-iio@vger.kernel.org Description: This attribute is used to read the amount of quadrature error present in the device at a given time. -- 1.7.3.4 ^ permalink raw reply related [flat|nested] 20+ messages in thread
* RE: [PATCH 0/2] blue part 6: IIO abi rework 2011-07-25 13:23 [PATCH 0/2] blue part 6: IIO abi rework Jonathan Cameron 2011-07-25 13:23 ` [PATCH 1/2] staging:iio: ABI rework - add in_ or out_ prefix to channnels Jonathan Cameron 2011-07-25 13:23 ` [PATCH 2/2] staging:iio:Documentation sysfs-bus-iio add in and out prefixes Jonathan Cameron @ 2011-07-26 9:01 ` Hennerich, Michael 2011-07-26 9:17 ` Jonathan Cameron 2 siblings, 1 reply; 20+ messages in thread From: Hennerich, Michael @ 2011-07-26 9:01 UTC (permalink / raw) To: Jonathan Cameron, linux-iio; +Cc: device-drivers-devel Jonathan Cameron wrote on 2011-07-25: > Michael pointed out the issues that not having an explicit direction > for channels was causing and the inconsistency of the inX and outX > channel naming we got from hmwon. > > They are stuck with it, but we aren't, so lets fix this now. > > Interesting question is whether we reset the base units to be volts > whilst we are at it? (for voltage channels obviously!) What do you mean exactly volts versus milli volts? Or given the fact that we have some current converter currently as inX and = outX - So we need to audit the datasheet to make sure we the (in|out)_(voltage|cur= rent)Y_raw right? > Given there will be a lot of auditing and datasheet reading to do > that, I suggest that if we decide to do it, we leave that for when we > are moving drivers out of staging. > > We could roll the doc patch in with the one in the previous series to > reduce churn. If they go together I'll probably do that. > > Thanks, > > Jonathan > > Jonathan Cameron (2): > staging:iio: ABI rework - add in_ or out_ prefix to channnels > staging:iio:Documentation sysfs-bus-iio add in and out prefixes > drivers/staging/iio/Documentation/sysfs-bus-iio | 536 > +++++++++++---- > ------- > drivers/staging/iio/dac/ad5686.c | 24 +- > drivers/staging/iio/iio.h | 31 ++- > drivers/staging/iio/industrialio-core.c | 28 +- > 4 files changed, 324 insertions(+), 295 deletions(-) Greetings, Michael -- Analog Devices GmbH Wilhelm-Wagenfeld-Str. 6 80807 Muenchen Sitz der Gesellschaft: Muenchen; Registergericht: Muenchen HRB 40368; Gesch= aeftsfuehrer:Dr.Carsten Suckrow, Thomas Wessel, William A. Martin, Margaret= Seif ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PATCH 0/2] blue part 6: IIO abi rework 2011-07-26 9:01 ` [PATCH 0/2] blue part 6: IIO abi rework Hennerich, Michael @ 2011-07-26 9:17 ` Jonathan Cameron 2011-07-26 10:52 ` Michael Hennerich 0 siblings, 1 reply; 20+ messages in thread From: Jonathan Cameron @ 2011-07-26 9:17 UTC (permalink / raw) To: Hennerich, Michael; +Cc: linux-iio, device-drivers-devel On 07/26/11 10:01, Hennerich, Michael wrote: > Jonathan Cameron wrote on 2011-07-25: >> Michael pointed out the issues that not having an explicit direction >> for channels was causing and the inconsistency of the inX and outX >> channel naming we got from hmwon. >> >> They are stuck with it, but we aren't, so lets fix this now. >> >> Interesting question is whether we reset the base units to be volts >> whilst we are at it? (for voltage channels obviously!) > > What do you mean exactly volts versus milli volts? Make the in_voltage_scale correspond to conversion to volts instead of millivolts as now (I think). Err. Looking at it that isn't actually documented... oops. I wonder which drivers actually do that and which don't. > Or given the fact that we have some current converter currently as inX and outX - We do? Ouch. In the 'interesting' drivers or in the clean ones? > So we need to audit the datasheet to make sure we the (in|out)_(voltage|current)Y_raw > right? Probably need to audit everything during the move out of staging anyway. It would be far from unusual if we found an off by 1000 error somewhere in he drivers. > > >> Given there will be a lot of auditing and datasheet reading to do >> that, I suggest that if we decide to do it, we leave that for when we >> are moving drivers out of staging. >> >> We could roll the doc patch in with the one in the previous series to >> reduce churn. If they go together I'll probably do that. >> >> Thanks, >> >> Jonathan >> >> Jonathan Cameron (2): >> staging:iio: ABI rework - add in_ or out_ prefix to channnels >> staging:iio:Documentation sysfs-bus-iio add in and out prefixes >> drivers/staging/iio/Documentation/sysfs-bus-iio | 536 >> +++++++++++---- >> ------- >> drivers/staging/iio/dac/ad5686.c | 24 +- >> drivers/staging/iio/iio.h | 31 ++- >> drivers/staging/iio/industrialio-core.c | 28 +- >> 4 files changed, 324 insertions(+), 295 deletions(-) > > Greetings, > Michael > > -- > Analog Devices GmbH Wilhelm-Wagenfeld-Str. 6 80807 Muenchen > Sitz der Gesellschaft: Muenchen; Registergericht: Muenchen HRB 40368; Geschaeftsfuehrer:Dr.Carsten Suckrow, Thomas Wessel, William A. Martin, Margaret Seif > > > > ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PATCH 0/2] blue part 6: IIO abi rework 2011-07-26 9:17 ` Jonathan Cameron @ 2011-07-26 10:52 ` Michael Hennerich 2011-07-26 11:06 ` Jonathan Cameron 0 siblings, 1 reply; 20+ messages in thread From: Michael Hennerich @ 2011-07-26 10:52 UTC (permalink / raw) To: Jonathan Cameron; +Cc: linux-iio, device-drivers-devel On 07/26/2011 11:17 AM, Jonathan Cameron wrote: > On 07/26/11 10:01, Hennerich, Michael wrote: >> Jonathan Cameron wrote on 2011-07-25: >>> Michael pointed out the issues that not having an explicit direction >>> for channels was causing and the inconsistency of the inX and outX >>> channel naming we got from hmwon. >>> >>> They are stuck with it, but we aren't, so lets fix this now. >>> >>> Interesting question is whether we reset the base units to be volts >>> whilst we are at it? (for voltage channels obviously!) >> What do you mean exactly volts versus milli volts? > Make the in_voltage_scale correspond to conversion to volts instead of > millivolts as now (I think). Err. Looking at it that isn't actually documented... > oops. I wonder which drivers actually do that and which don't. The ones I wrote provide the scale for millivolts. With the recent introduction of IIO_VAL_INT_PLUS_NANO we got the scale accurate enough for the precession 24-bit converters. If we move to the SI base unit volt, we lose this accuracy again. Move to IIO_VAL_INT_PLUS_PICO? >> Or given the fact that we have some current converter currently as inX and outX - > We do? Ouch. In the 'interesting' drivers or in the clean ones? From top of my head I know the AD5446/AD5444 are current output DACs. But the same driver also handles various other voltage output DACs. I can make sure once we move this driver to channel spec and iio_info:write_raw we get the units right. >> So we need to audit the datasheet to make sure we the (in|out)_(voltage|current)Y_raw >> right? > Probably need to audit everything during the move out of staging anyway. It would be far > from unusual if we found an off by 1000 error somewhere in he drivers. >> >>> Given there will be a lot of auditing and datasheet reading to do >>> that, I suggest that if we decide to do it, we leave that for when we >>> are moving drivers out of staging. >>> >>> We could roll the doc patch in with the one in the previous series to >>> reduce churn. If they go together I'll probably do that. >>> >>> Thanks, >>> >>> Jonathan >>> >>> Jonathan Cameron (2): >>> staging:iio: ABI rework - add in_ or out_ prefix to channnels >>> staging:iio:Documentation sysfs-bus-iio add in and out prefixes >>> drivers/staging/iio/Documentation/sysfs-bus-iio | 536 >>> +++++++++++---- >>> ------- >>> drivers/staging/iio/dac/ad5686.c | 24 +- >>> drivers/staging/iio/iio.h | 31 ++- >>> drivers/staging/iio/industrialio-core.c | 28 +- >>> 4 files changed, 324 insertions(+), 295 deletions(-) >> Greetings, >> Michael >> >> -- >> Analog Devices GmbH Wilhelm-Wagenfeld-Str. 6 80807 Muenchen >> Sitz der Gesellschaft: Muenchen; Registergericht: Muenchen HRB 40368; Geschaeftsfuehrer:Dr.Carsten Suckrow, Thomas Wessel, William A. Martin, Margaret Seif >> >> >> >> > -- Greetings, Michael -- Analog Devices GmbH Wilhelm-Wagenfeld-Str. 6 80807 Muenchen Sitz der Gesellschaft: Muenchen; Registergericht: Muenchen HRB 40368; Geschaeftsfuehrer:Dr.Carsten Suckrow, Thomas Wessel, William A. Martin, Margaret Seif ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PATCH 0/2] blue part 6: IIO abi rework 2011-07-26 10:52 ` Michael Hennerich @ 2011-07-26 11:06 ` Jonathan Cameron 2011-07-27 14:41 ` Michael Hennerich 0 siblings, 1 reply; 20+ messages in thread From: Jonathan Cameron @ 2011-07-26 11:06 UTC (permalink / raw) To: michael.hennerich; +Cc: linux-iio, device-drivers-devel On 07/26/11 11:52, Michael Hennerich wrote: > On 07/26/2011 11:17 AM, Jonathan Cameron wrote: >> On 07/26/11 10:01, Hennerich, Michael wrote: >>> Jonathan Cameron wrote on 2011-07-25: >>>> Michael pointed out the issues that not having an explicit direction >>>> for channels was causing and the inconsistency of the inX and outX >>>> channel naming we got from hmwon. >>>> >>>> They are stuck with it, but we aren't, so lets fix this now. >>>> >>>> Interesting question is whether we reset the base units to be volts >>>> whilst we are at it? (for voltage channels obviously!) >>> What do you mean exactly volts versus milli volts? >> Make the in_voltage_scale correspond to conversion to volts instead of >> millivolts as now (I think). Err. Looking at it that isn't actually documented... >> oops. I wonder which drivers actually do that and which don't. > The ones I wrote provide the scale for millivolts. > With the recent introduction of IIO_VAL_INT_PLUS_NANO we got > the scale accurate enough for the precession 24-bit converters. > If we move to the SI base unit volt, we lose this accuracy again. Yup, that's the principal counter argument to the change. > > Move to IIO_VAL_INT_PLUS_PICO? Tricky as then we have holes (size of int on 32 bit machines isn't large enough...). That's probably not a problem, but would mean keeping a close eye on new drivers to make sure any computed values don't fall foul of the hole. When constants are used it will give a compile warning so that would be fine. >>> Or given the fact that we have some current converter currently as inX and outX - >> We do? Ouch. In the 'interesting' drivers or in the clean ones? > From top of my head I know the AD5446/AD5444 are current output DACs. > But the same driver also handles various other voltage output DACs. > I can make sure once we move this driver to channel spec and iio_info:write_raw > we get the units right. Good to know where this is happening. Clearly no driver is going out of staging until it uses chan_spec anyway so we'll get them sorted at the conversion stage as you suggest. Jonathan ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PATCH 0/2] blue part 6: IIO abi rework 2011-07-26 11:06 ` Jonathan Cameron @ 2011-07-27 14:41 ` Michael Hennerich 2011-07-28 8:03 ` Jonathan Cameron 0 siblings, 1 reply; 20+ messages in thread From: Michael Hennerich @ 2011-07-27 14:41 UTC (permalink / raw) To: Jonathan Cameron; +Cc: linux-iio, device-drivers-devel On 07/26/2011 01:06 PM, Jonathan Cameron wrote: > On 07/26/11 11:52, Michael Hennerich wrote: >> On 07/26/2011 11:17 AM, Jonathan Cameron wrote: >>> On 07/26/11 10:01, Hennerich, Michael wrote: >>>> Jonathan Cameron wrote on 2011-07-25: >>>>> Michael pointed out the issues that not having an explicit direction >>>>> for channels was causing and the inconsistency of the inX and outX >>>>> channel naming we got from hmwon. >>>>> >>>>> They are stuck with it, but we aren't, so lets fix this now. >>>>> >>>>> Interesting question is whether we reset the base units to be volts >>>>> whilst we are at it? (for voltage channels obviously!) >>>> What do you mean exactly volts versus milli volts? >>> Make the in_voltage_scale correspond to conversion to volts instead of >>> millivolts as now (I think). Err. Looking at it that isn't actually documented... >>> oops. I wonder which drivers actually do that and which don't. >> The ones I wrote provide the scale for millivolts. >> With the recent introduction of IIO_VAL_INT_PLUS_NANO we got >> the scale accurate enough for the precession 24-bit converters. >> If we move to the SI base unit volt, we lose this accuracy again. > Yup, that's the principal counter argument to the change. If we decide to leave the milli scale for volts... Do we also want to stay with milli degrees Celsius, etc.? One other thing we should also address is the byte-ordering/endianess of the scan elements stored in the ring buffers. Right now the scan_element type details signs, bits, storage bits and shifts. However it lacks to tell the endianess within the storage bits. How about le:s16/32>>0 or be:s16/32>>0 for example? -- Greetings, Michael -- Analog Devices GmbH Wilhelm-Wagenfeld-Str. 6 80807 Muenchen Sitz der Gesellschaft: Muenchen; Registergericht: Muenchen HRB 40368; Geschaeftsfuehrer:Dr.Carsten Suckrow, Thomas Wessel, William A. Martin, Margaret Seif ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PATCH 0/2] blue part 6: IIO abi rework 2011-07-27 14:41 ` Michael Hennerich @ 2011-07-28 8:03 ` Jonathan Cameron 2011-07-28 8:08 ` Hennerich, Michael 0 siblings, 1 reply; 20+ messages in thread From: Jonathan Cameron @ 2011-07-28 8:03 UTC (permalink / raw) To: michael.hennerich; +Cc: linux-iio, device-drivers-devel On 07/27/11 15:41, Michael Hennerich wrote: > On 07/26/2011 01:06 PM, Jonathan Cameron wrote: >> On 07/26/11 11:52, Michael Hennerich wrote: >>> On 07/26/2011 11:17 AM, Jonathan Cameron wrote: >>>> On 07/26/11 10:01, Hennerich, Michael wrote: >>>>> Jonathan Cameron wrote on 2011-07-25: >>>>>> Michael pointed out the issues that not having an explicit direction >>>>>> for channels was causing and the inconsistency of the inX and outX >>>>>> channel naming we got from hmwon. >>>>>> >>>>>> They are stuck with it, but we aren't, so lets fix this now. >>>>>> >>>>>> Interesting question is whether we reset the base units to be volts >>>>>> whilst we are at it? (for voltage channels obviously!) >>>>> What do you mean exactly volts versus milli volts? >>>> Make the in_voltage_scale correspond to conversion to volts instead of >>>> millivolts as now (I think). Err. Looking at it that isn't actually documented... >>>> oops. I wonder which drivers actually do that and which don't. >>> The ones I wrote provide the scale for millivolts. >>> With the recent introduction of IIO_VAL_INT_PLUS_NANO we got >>> the scale accurate enough for the precession 24-bit converters. >>> If we move to the SI base unit volt, we lose this accuracy again. >> Yup, that's the principal counter argument to the change. > If we decide to leave the milli scale for volts... > Do we also want to stay with milli degrees Celsius, etc.? If we do it for one, probably best to do it for them all.. > > One other thing we should also address is the byte-ordering/endianess of > the scan elements stored in the ring buffers. > > Right now the scan_element type details signs, bits, storage bits and shifts. > However it lacks to tell the endianess within the storage bits. Good point. I'd completely forgotten about that. > > How about le:s16/32>>0 or be:s16/32>>0 for example? Yup, that works for me. In cases where it doesn't matter they driver can pick one at random. Jonathan ^ permalink raw reply [flat|nested] 20+ messages in thread
* RE: [PATCH 0/2] blue part 6: IIO abi rework 2011-07-28 8:03 ` Jonathan Cameron @ 2011-07-28 8:08 ` Hennerich, Michael 2011-07-28 8:33 ` Manuel Stahl 2011-07-28 8:36 ` Jonathan Cameron 0 siblings, 2 replies; 20+ messages in thread From: Hennerich, Michael @ 2011-07-28 8:08 UTC (permalink / raw) To: Jonathan Cameron; +Cc: linux-iio, device-drivers-devel Jonathan Cameron wrote on 2011-07-28: > On 07/27/11 15:41, Michael Hennerich wrote: >> On 07/26/2011 01:06 PM, Jonathan Cameron wrote: >>> On 07/26/11 11:52, Michael Hennerich wrote: >>>> On 07/26/2011 11:17 AM, Jonathan Cameron wrote: >>>>> On 07/26/11 10:01, Hennerich, Michael wrote: >>>>>> Jonathan Cameron wrote on 2011-07-25: >>>>>>> Michael pointed out the issues that not having an explicit >>>>>>> direction for channels was causing and the inconsistency of the >>>>>>> inX and outX channel naming we got from hmwon. >>>>>>> >>>>>>> They are stuck with it, but we aren't, so lets fix this now. >>>>>>> >>>>>>> Interesting question is whether we reset the base units to be >>>>>>> volts whilst we are at it? (for voltage channels obviously!) >>>>>> What do you mean exactly volts versus milli volts? >>>>> Make the in_voltage_scale correspond to conversion to volts instead >>>>> of millivolts as now (I think). Err. Looking at it that isn't >>>>> actually documented... oops. I wonder which drivers actually do >>>>> that and which don't. >>>> The ones I wrote provide the scale for millivolts. >>>> With the recent introduction of IIO_VAL_INT_PLUS_NANO we got the >>>> scale accurate enough for the precession 24-bit converters. >>>> If we move to the SI base unit volt, we lose this accuracy again. >>> Yup, that's the principal counter argument to the change. >> If we decide to leave the milli scale for volts... Do we also want to >> stay with milli degrees Celsius, etc.? If we do it for one, probably >> best to do it for them all.. Hi Jonathan, So stick with the milli scale for all? >> >> One other thing we should also address is the >> byte-ordering/endianess of the scan elements stored in the ring buffers. >> >> Right now the scan_element type details signs, bits, storage bits and >> shifts. However it lacks to tell the endianess within the storage bits. >> Good point. I'd completely forgotten about that. >> >> How about le:s16/32>>0 or be:s16/32>>0 for example? > Yup, that works for me. In cases where it doesn't matter they driver > can pick one at random. We need another case - Some drivers use the (be|le)(x)_to_cpu() helpers, So in case these are used the endianess can be either or, depending on the = host. So maybe have le|be|cpu? Greetings, Michael -- Analog Devices GmbH Wilhelm-Wagenfeld-Str. 6 80807 Muenchen Sitz der Gesellschaft: Muenchen; Registergericht: Muenchen HRB 40368; Gesch= aeftsfuehrer:Dr.Carsten Suckrow, Thomas Wessel, William A. Martin, Margaret= Seif ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PATCH 0/2] blue part 6: IIO abi rework 2011-07-28 8:08 ` Hennerich, Michael @ 2011-07-28 8:33 ` Manuel Stahl 2011-07-28 9:52 ` Jonathan Cameron 2011-07-28 8:36 ` Jonathan Cameron 1 sibling, 1 reply; 20+ messages in thread From: Manuel Stahl @ 2011-07-28 8:33 UTC (permalink / raw) To: Hennerich, Michael; +Cc: Jonathan Cameron, linux-iio, device-drivers-devel Hi, I had the time to read through the discussion recently, so just a few=20 comments: Am 28.07.2011 10:08, schrieb Hennerich, Michael: > Jonathan Cameron wrote on 2011-07-28: >> On 07/27/11 15:41, Michael Hennerich wrote: >>> On 07/26/2011 01:06 PM, Jonathan Cameron wrote: >>>> On 07/26/11 11:52, Michael Hennerich wrote: >>>>> On 07/26/2011 11:17 AM, Jonathan Cameron wrote: >>>>>> On 07/26/11 10:01, Hennerich, Michael wrote: >>>>>>> Jonathan Cameron wrote on 2011-07-25: >>>>>>>> Michael pointed out the issues that not having an explicit >>>>>>>> direction for channels was causing and the inconsistency of the >>>>>>>> inX and outX channel naming we got from hmwon. >>>>>>>> >>>>>>>> They are stuck with it, but we aren't, so lets fix this now. >>>>>>>> >>>>>>>> Interesting question is whether we reset the base units to be >>>>>>>> volts whilst we are at it? (for voltage channels obviously!) >>>>>>> What do you mean exactly volts versus milli volts? >>>>>> Make the in_voltage_scale correspond to conversion to volts instea= d >>>>>> of millivolts as now (I think). Err. Looking at it that isn't >>>>>> actually documented... oops. I wonder which drivers actually do >>>>>> that and which don't. >>>>> The ones I wrote provide the scale for millivolts. >>>>> With the recent introduction of IIO_VAL_INT_PLUS_NANO we got the >>>>> scale accurate enough for the precession 24-bit converters. >>>>> If we move to the SI base unit volt, we lose this accuracy again. >>>> Yup, that's the principal counter argument to the change. >>> If we decide to leave the milli scale for volts... Do we also want to= >>> stay with milli degrees Celsius, etc.? If we do it for one, probably >>> best to do it for them all.. > Hi Jonathan, > > So stick with the milli scale for all? If it's possible, I would like to have pure units. I didn't read the API = with IIO_VAL_INT_PLUS_NANO completely so I don't understand the problem=20 yet, but using milli just because the drivers we have in place can=20 measure relatively low voltages make no sense for me. > >>> One other thing we should also address is the >>> byte-ordering/endianess of the scan elements stored in the ring buffe= rs. >>> >>> Right now the scan_element type details signs, bits, storage bits and= >>> shifts. However it lacks to tell the endianess within the storage bit= s. >>> Good point. I'd completely forgotten about that. >>> >>> How about le:s16/32>>0 or be:s16/32>>0 for example? >> Yup, that works for me. In cases where it doesn't matter they driver >> can pick one at random. > > We need another case - Some drivers use the (be|le)(x)_to_cpu() helpers= , > So in case these are used the endianess can be either or, depending on = the host. > So maybe have le|be|cpu? I think we can drop the usage of the (be|le)(x)_to_cpu() helpers. It's=20 easy to find out the current CPU endianess so we can always provide a=20 correct term here. Especially important when we use the iiod, as the=20 data might be processed on a different CPU. > > > Greetings, > Michael > > -- > Analog Devices GmbH Wilhelm-Wagenfeld-Str. 6 80807 Muenchen > Sitz der Gesellschaft: Muenchen; Registergericht: Muenchen HRB 40368; G= eschaeftsfuehrer:Dr.Carsten Suckrow, Thomas Wessel, William A. Martin, Ma= rgaret Seif > > > -- > To unsubscribe from this list: send the line "unsubscribe linux-iio" in= > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html --=20 Manuel Stahl Fraunhofer-Institut IIS Leistungsoptimierte Systeme Nordostpark 93 D90411 N=FCrnberg Telefon +49 (0)911/58061-6419 Fax +49 (0)911/58061-6398 E-Mail manuel.stahl@iis.fraunhofer.de http://www.iis.fraunhofer.de http://www.smart-power.fraunhofer.de ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PATCH 0/2] blue part 6: IIO abi rework 2011-07-28 8:33 ` Manuel Stahl @ 2011-07-28 9:52 ` Jonathan Cameron 2011-07-28 12:47 ` Manuel Stahl 0 siblings, 1 reply; 20+ messages in thread From: Jonathan Cameron @ 2011-07-28 9:52 UTC (permalink / raw) To: Manuel Stahl; +Cc: Hennerich, Michael, linux-iio, device-drivers-devel On 07/28/11 09:33, Manuel Stahl wrote: > Hi, > > I had the time to read through the discussion recently, so just a few comments: > > Am 28.07.2011 10:08, schrieb Hennerich, Michael: >> Jonathan Cameron wrote on 2011-07-28: >>> On 07/27/11 15:41, Michael Hennerich wrote: >>>> On 07/26/2011 01:06 PM, Jonathan Cameron wrote: >>>>> On 07/26/11 11:52, Michael Hennerich wrote: >>>>>> On 07/26/2011 11:17 AM, Jonathan Cameron wrote: >>>>>>> On 07/26/11 10:01, Hennerich, Michael wrote: >>>>>>>> Jonathan Cameron wrote on 2011-07-25: >>>>>>>>> Michael pointed out the issues that not having an explicit >>>>>>>>> direction for channels was causing and the inconsistency of the >>>>>>>>> inX and outX channel naming we got from hmwon. >>>>>>>>> >>>>>>>>> They are stuck with it, but we aren't, so lets fix this now. >>>>>>>>> >>>>>>>>> Interesting question is whether we reset the base units to be >>>>>>>>> volts whilst we are at it? (for voltage channels obviously!) >>>>>>>> What do you mean exactly volts versus milli volts? >>>>>>> Make the in_voltage_scale correspond to conversion to volts instead >>>>>>> of millivolts as now (I think). Err. Looking at it that isn't >>>>>>> actually documented... oops. I wonder which drivers actually do >>>>>>> that and which don't. >>>>>> The ones I wrote provide the scale for millivolts. >>>>>> With the recent introduction of IIO_VAL_INT_PLUS_NANO we got the >>>>>> scale accurate enough for the precession 24-bit converters. >>>>>> If we move to the SI base unit volt, we lose this accuracy again. >>>>> Yup, that's the principal counter argument to the change. >>>> If we decide to leave the milli scale for volts... Do we also want to >>>> stay with milli degrees Celsius, etc.? If we do it for one, probably >>>> best to do it for them all.. >> Hi Jonathan, >> >> So stick with the milli scale for all? > If it's possible, I would like to have pure units. I didn't read the > API with IIO_VAL_INT_PLUS_NANO completely so I don't understand the > problem yet, but using milli just because the drivers we have in > place can measure relatively low voltages make no sense for me. The issue is we have two integers to play with. The first is used for the integer part. The second is divided by either 10^6 or 10^9 and added on. If we go to 10^12, then max value for the decimal bit should be: 999,999,999,999. Unfortunately we only have a 32 bit int (to avoid use of div64 in drivers). It's signed as well to allow us to set the integer bit to 0. Hence max value is 2^31 = 2 147 483 648. Hence not enough and the hole. Next question is whether this is an issue. I doubt it with _scale, _offset _calibbias, but just possibly with _calibscale where very small adjustments may occur (hence 0.999999999999 is possible.) Looking at our actual users, lis3l02dq outputs a raw register read, adis16260 outputs garbage and the other two are _input outputing only devices and hence the calibscale value can be in whatever units we like (no concept of raw units for those devices). Ooops, on the adis16260 one, I'll fix that up. Should obviously be *val = val16 & ((1 << bits) -1); not *val = (1 << bits) -1; >> >>>> One other thing we should also address is the >>>> byte-ordering/endianess of the scan elements stored in the ring >>>> buffers. >>>> >>>> Right now the scan_element type details signs, bits, storage >>>> bits and shifts. However it lacks to tell the endianess within >>>> the storage bits. Good point. I'd completely forgotten about >>>> that. >>>> >>>> How about le:s16/32>>0 or be:s16/32>>0 for example? >>> Yup, that works for me. In cases where it doesn't matter they >>> driver can pick one at random. >> >> We need another case - Some drivers use the (be|le)(x)_to_cpu() >> helpers, So in case these are used the endianess can be either or, >> depending on the host. So maybe have le|be|cpu? > I think we can drop the usage of the (be|le)(x)_to_cpu() helpers. > It's easy to find out the current CPU endianess so we can always > provide a correct term here. Especially important when we use the > iiod, as the data might be processed on a different CPU. Agreed. ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PATCH 0/2] blue part 6: IIO abi rework 2011-07-28 9:52 ` Jonathan Cameron @ 2011-07-28 12:47 ` Manuel Stahl 2011-07-28 13:38 ` Jonathan Cameron 0 siblings, 1 reply; 20+ messages in thread From: Manuel Stahl @ 2011-07-28 12:47 UTC (permalink / raw) To: Jonathan Cameron; +Cc: Hennerich, Michael, linux-iio, device-drivers-devel Am 28.07.2011 11:52, schrieb Jonathan Cameron: > On 07/28/11 09:33, Manuel Stahl wrote: >> Hi, >> >> I had the time to read through the discussion recently, so just a few = comments: >> >> Am 28.07.2011 10:08, schrieb Hennerich, Michael: >>> Jonathan Cameron wrote on 2011-07-28: >>>> On 07/27/11 15:41, Michael Hennerich wrote: >>>>> On 07/26/2011 01:06 PM, Jonathan Cameron wrote: >>>>>> On 07/26/11 11:52, Michael Hennerich wrote: >>>>>>> On 07/26/2011 11:17 AM, Jonathan Cameron wrote: >>>>>>>> On 07/26/11 10:01, Hennerich, Michael wrote: >>>>>>>>> Jonathan Cameron wrote on 2011-07-25: >>>>>>>>>> Michael pointed out the issues that not having an explicit >>>>>>>>>> direction for channels was causing and the inconsistency of th= e >>>>>>>>>> inX and outX channel naming we got from hmwon. >>>>>>>>>> >>>>>>>>>> They are stuck with it, but we aren't, so lets fix this now. >>>>>>>>>> >>>>>>>>>> Interesting question is whether we reset the base units to be >>>>>>>>>> volts whilst we are at it? (for voltage channels obviously!) >>>>>>>>> What do you mean exactly volts versus milli volts? >>>>>>>> Make the in_voltage_scale correspond to conversion to volts inst= ead >>>>>>>> of millivolts as now (I think). Err. Looking at it that isn't >>>>>>>> actually documented... oops. I wonder which drivers actually do= >>>>>>>> that and which don't. >>>>>>> The ones I wrote provide the scale for millivolts. >>>>>>> With the recent introduction of IIO_VAL_INT_PLUS_NANO we got the >>>>>>> scale accurate enough for the precession 24-bit converters. >>>>>>> If we move to the SI base unit volt, we lose this accuracy again.= >>>>>> Yup, that's the principal counter argument to the change. >>>>> If we decide to leave the milli scale for volts... Do we also want = to >>>>> stay with milli degrees Celsius, etc.? If we do it for one, probabl= y >>>>> best to do it for them all.. >>> Hi Jonathan, >>> >>> So stick with the milli scale for all? >> If it's possible, I would like to have pure units. I didn't read the >> API with IIO_VAL_INT_PLUS_NANO completely so I don't understand the >> problem yet, but using milli just because the drivers we have in >> place can measure relatively low voltages make no sense for me. > The issue is we have two integers to play with. The first is > used for the integer part. The second is divided by either 10^6 or 10^= 9 > and added on. > > If we go to 10^12, then max value for the decimal bit should be: > 999,999,999,999. > > Unfortunately we only have a 32 bit int (to avoid use of div64 in drive= rs). > It's signed as well to allow us to set the integer bit to 0. Hence max= > value is 2^31 =3D 2 147 483 648. > > Hence not enough and the hole. > > Next question is whether this is an issue. I doubt it with _scale, _of= fset > _calibbias, but just possibly with _calibscale where very small adjustm= ents > may occur (hence 0.999999999999 is possible.) Does it help to support exponential formats like 999999.9999999e-10? --=20 Manuel Stahl Fraunhofer-Institut IIS Leistungsoptimierte Systeme Nordostpark 93 D90411 N=FCrnberg Telefon +49 (0)911/58061-6419 Fax +49 (0)911/58061-6398 E-Mail manuel.stahl@iis.fraunhofer.de http://www.iis.fraunhofer.de http://www.smart-power.fraunhofer.de ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PATCH 0/2] blue part 6: IIO abi rework 2011-07-28 12:47 ` Manuel Stahl @ 2011-07-28 13:38 ` Jonathan Cameron 0 siblings, 0 replies; 20+ messages in thread From: Jonathan Cameron @ 2011-07-28 13:38 UTC (permalink / raw) To: Manuel Stahl; +Cc: Hennerich, Michael, linux-iio, device-drivers-devel On 07/28/11 13:47, Manuel Stahl wrote: > Am 28.07.2011 11:52, schrieb Jonathan Cameron: >> On 07/28/11 09:33, Manuel Stahl wrote: >>> Hi, >>> >>> I had the time to read through the discussion recently, so just a few comments: >>> >>> Am 28.07.2011 10:08, schrieb Hennerich, Michael: >>>> Jonathan Cameron wrote on 2011-07-28: >>>>> On 07/27/11 15:41, Michael Hennerich wrote: >>>>>> On 07/26/2011 01:06 PM, Jonathan Cameron wrote: >>>>>>> On 07/26/11 11:52, Michael Hennerich wrote: >>>>>>>> On 07/26/2011 11:17 AM, Jonathan Cameron wrote: >>>>>>>>> On 07/26/11 10:01, Hennerich, Michael wrote: >>>>>>>>>> Jonathan Cameron wrote on 2011-07-25: >>>>>>>>>>> Michael pointed out the issues that not having an explicit >>>>>>>>>>> direction for channels was causing and the inconsistency of the >>>>>>>>>>> inX and outX channel naming we got from hmwon. >>>>>>>>>>> >>>>>>>>>>> They are stuck with it, but we aren't, so lets fix this now. >>>>>>>>>>> >>>>>>>>>>> Interesting question is whether we reset the base units to be >>>>>>>>>>> volts whilst we are at it? (for voltage channels obviously!) >>>>>>>>>> What do you mean exactly volts versus milli volts? >>>>>>>>> Make the in_voltage_scale correspond to conversion to volts instead >>>>>>>>> of millivolts as now (I think). Err. Looking at it that isn't >>>>>>>>> actually documented... oops. I wonder which drivers actually do >>>>>>>>> that and which don't. >>>>>>>> The ones I wrote provide the scale for millivolts. >>>>>>>> With the recent introduction of IIO_VAL_INT_PLUS_NANO we got the >>>>>>>> scale accurate enough for the precession 24-bit converters. >>>>>>>> If we move to the SI base unit volt, we lose this accuracy again. >>>>>>> Yup, that's the principal counter argument to the change. >>>>>> If we decide to leave the milli scale for volts... Do we also want to >>>>>> stay with milli degrees Celsius, etc.? If we do it for one, probably >>>>>> best to do it for them all.. >>>> Hi Jonathan, >>>> >>>> So stick with the milli scale for all? >>> If it's possible, I would like to have pure units. I didn't read the >>> API with IIO_VAL_INT_PLUS_NANO completely so I don't understand the >>> problem yet, but using milli just because the drivers we have in >>> place can measure relatively low voltages make no sense for me. >> The issue is we have two integers to play with. The first is >> used for the integer part. The second is divided by either 10^6 or 10^9 >> and added on. >> >> If we go to 10^12, then max value for the decimal bit should be: >> 999,999,999,999. >> >> Unfortunately we only have a 32 bit int (to avoid use of div64 in drivers). >> It's signed as well to allow us to set the integer bit to 0. Hence max >> value is 2^31 = 2 147 483 648. >> >> Hence not enough and the hole. >> >> Next question is whether this is an issue. I doubt it with _scale, _offset >> _calibbias, but just possibly with _calibscale where very small adjustments >> may occur (hence 0.999999999999 is possible.) > Does it help to support exponential formats like 999999.9999999e-10? Nasty... I'd rather just put more bits the two values if we need to. ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PATCH 0/2] blue part 6: IIO abi rework 2011-07-28 8:08 ` Hennerich, Michael 2011-07-28 8:33 ` Manuel Stahl @ 2011-07-28 8:36 ` Jonathan Cameron 2011-07-28 8:36 ` Michael Hennerich 1 sibling, 1 reply; 20+ messages in thread From: Jonathan Cameron @ 2011-07-28 8:36 UTC (permalink / raw) To: Hennerich, Michael; +Cc: linux-iio, device-drivers-devel On 07/28/11 09:08, Hennerich, Michael wrote: > Jonathan Cameron wrote on 2011-07-28: >> On 07/27/11 15:41, Michael Hennerich wrote: >>> On 07/26/2011 01:06 PM, Jonathan Cameron wrote: >>>> On 07/26/11 11:52, Michael Hennerich wrote: >>>>> On 07/26/2011 11:17 AM, Jonathan Cameron wrote: >>>>>> On 07/26/11 10:01, Hennerich, Michael wrote: >>>>>>> Jonathan Cameron wrote on 2011-07-25: >>>>>>>> Michael pointed out the issues that not having an explicit >>>>>>>> direction for channels was causing and the inconsistency of the >>>>>>>> inX and outX channel naming we got from hmwon. >>>>>>>> >>>>>>>> They are stuck with it, but we aren't, so lets fix this now. >>>>>>>> >>>>>>>> Interesting question is whether we reset the base units to be >>>>>>>> volts whilst we are at it? (for voltage channels obviously!) >>>>>>> What do you mean exactly volts versus milli volts? >>>>>> Make the in_voltage_scale correspond to conversion to volts instead >>>>>> of millivolts as now (I think). Err. Looking at it that isn't >>>>>> actually documented... oops. I wonder which drivers actually do >>>>>> that and which don't. >>>>> The ones I wrote provide the scale for millivolts. >>>>> With the recent introduction of IIO_VAL_INT_PLUS_NANO we got the >>>>> scale accurate enough for the precession 24-bit converters. >>>>> If we move to the SI base unit volt, we lose this accuracy again. >>>> Yup, that's the principal counter argument to the change. >>> If we decide to leave the milli scale for volts... Do we also want to >>> stay with milli degrees Celsius, etc.? If we do it for one, probably >>> best to do it for them all.. > > Hi Jonathan, > > So stick with the milli scale for all? Yes. > >>> >>> One other thing we should also address is the >>> byte-ordering/endianess of the scan elements stored in the ring buffers. >>> >>> Right now the scan_element type details signs, bits, storage bits and >>> shifts. However it lacks to tell the endianess within the storage bits. >>> Good point. I'd completely forgotten about that. >>> >>> How about le:s16/32>>0 or be:s16/32>>0 for example? >> Yup, that works for me. In cases where it doesn't matter they driver >> can pick one at random. > > > We need another case - Some drivers use the (be|le)(x)_to_cpu() helpers, > So in case these are used the endianess can be either or, depending on the host. > So maybe have le|be|cpu? I thought about that, but am inclined to say we just stop drivers doing the conversion. Better to leave it up to userspace? > > > Greetings, > Michael > > -- > Analog Devices GmbH Wilhelm-Wagenfeld-Str. 6 80807 Muenchen > Sitz der Gesellschaft: Muenchen; Registergericht: Muenchen HRB 40368; Geschaeftsfuehrer:Dr.Carsten Suckrow, Thomas Wessel, William A. Martin, Margaret Seif > > > ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PATCH 0/2] blue part 6: IIO abi rework 2011-07-28 8:36 ` Jonathan Cameron @ 2011-07-28 8:36 ` Michael Hennerich 2011-07-28 9:40 ` Jonathan Cameron 0 siblings, 1 reply; 20+ messages in thread From: Michael Hennerich @ 2011-07-28 8:36 UTC (permalink / raw) To: Jonathan Cameron; +Cc: linux-iio, device-drivers-devel On 07/28/2011 10:36 AM, Jonathan Cameron wrote: > On 07/28/11 09:08, Hennerich, Michael wrote: >> Jonathan Cameron wrote on 2011-07-28: >>> On 07/27/11 15:41, Michael Hennerich wrote: >>>> On 07/26/2011 01:06 PM, Jonathan Cameron wrote: >>>>> On 07/26/11 11:52, Michael Hennerich wrote: >>>>>> On 07/26/2011 11:17 AM, Jonathan Cameron wrote: >>>>>>> On 07/26/11 10:01, Hennerich, Michael wrote: >>>>>>>> Jonathan Cameron wrote on 2011-07-25: >>>>>>>>> Michael pointed out the issues that not having an explicit >>>>>>>>> direction for channels was causing and the inconsistency of the >>>>>>>>> inX and outX channel naming we got from hmwon. >>>>>>>>> >>>>>>>>> They are stuck with it, but we aren't, so lets fix this now. >>>>>>>>> >>>>>>>>> Interesting question is whether we reset the base units to be >>>>>>>>> volts whilst we are at it? (for voltage channels obviously!) >>>>>>>> What do you mean exactly volts versus milli volts? >>>>>>> Make the in_voltage_scale correspond to conversion to volts instead >>>>>>> of millivolts as now (I think). Err. Looking at it that isn't >>>>>>> actually documented... oops. I wonder which drivers actually do >>>>>>> that and which don't. >>>>>> The ones I wrote provide the scale for millivolts. >>>>>> With the recent introduction of IIO_VAL_INT_PLUS_NANO we got the >>>>>> scale accurate enough for the precession 24-bit converters. >>>>>> If we move to the SI base unit volt, we lose this accuracy again. >>>>> Yup, that's the principal counter argument to the change. >>>> If we decide to leave the milli scale for volts... Do we also want to >>>> stay with milli degrees Celsius, etc.? If we do it for one, probably >>>> best to do it for them all.. >> Hi Jonathan, >> >> So stick with the milli scale for all? > Yes. >>>> One other thing we should also address is the >>>> byte-ordering/endianess of the scan elements stored in the ring buffers. >>>> >>>> Right now the scan_element type details signs, bits, storage bits and >>>> shifts. However it lacks to tell the endianess within the storage bits. >>>> Good point. I'd completely forgotten about that. >>>> >>>> How about le:s16/32>>0 or be:s16/32>>0 for example? >>> Yup, that works for me. In cases where it doesn't matter they driver >>> can pick one at random. >> >> We need another case - Some drivers use the (be|le)(x)_to_cpu() helpers, >> So in case these are used the endianess can be either or, depending on the host. >> So maybe have le|be|cpu? > I thought about that, but am inclined to say we just stop drivers doing the conversion. > Better to leave it up to userspace? Well - we have and definitely will have more drivers where the conversion may be to time consuming to do in kernel space. I really don't have a strong preference here - but the important thing is that we need to tell user space what format is placed into the buffers. >> >> Greetings, >> Michael >> >> -- >> Analog Devices GmbH Wilhelm-Wagenfeld-Str. 6 80807 Muenchen >> Sitz der Gesellschaft: Muenchen; Registergericht: Muenchen HRB 40368; Geschaeftsfuehrer:Dr.Carsten Suckrow, Thomas Wessel, William A. Martin, Margaret Seif >> >> >> > -- Greetings, Michael -- Analog Devices GmbH Wilhelm-Wagenfeld-Str. 6 80807 Muenchen Sitz der Gesellschaft: Muenchen; Registergericht: Muenchen HRB 40368; Geschaeftsfuehrer:Dr.Carsten Suckrow, Thomas Wessel, William A. Martin, Margaret Seif ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PATCH 0/2] blue part 6: IIO abi rework 2011-07-28 8:36 ` Michael Hennerich @ 2011-07-28 9:40 ` Jonathan Cameron 2011-07-28 9:53 ` Michael Hennerich 0 siblings, 1 reply; 20+ messages in thread From: Jonathan Cameron @ 2011-07-28 9:40 UTC (permalink / raw) To: michael.hennerich; +Cc: linux-iio, device-drivers-devel On 07/28/11 09:36, Michael Hennerich wrote: > On 07/28/2011 10:36 AM, Jonathan Cameron wrote: >> On 07/28/11 09:08, Hennerich, Michael wrote: >>> Jonathan Cameron wrote on 2011-07-28: >>>> On 07/27/11 15:41, Michael Hennerich wrote: >>>>> On 07/26/2011 01:06 PM, Jonathan Cameron wrote: >>>>>> On 07/26/11 11:52, Michael Hennerich wrote: >>>>>>> On 07/26/2011 11:17 AM, Jonathan Cameron wrote: >>>>>>>> On 07/26/11 10:01, Hennerich, Michael wrote: >>>>>>>>> Jonathan Cameron wrote on 2011-07-25: >>>>>>>>>> Michael pointed out the issues that not having an explicit >>>>>>>>>> direction for channels was causing and the inconsistency of the >>>>>>>>>> inX and outX channel naming we got from hmwon. >>>>>>>>>> >>>>>>>>>> They are stuck with it, but we aren't, so lets fix this now. >>>>>>>>>> >>>>>>>>>> Interesting question is whether we reset the base units to be >>>>>>>>>> volts whilst we are at it? (for voltage channels obviously!) >>>>>>>>> What do you mean exactly volts versus milli volts? >>>>>>>> Make the in_voltage_scale correspond to conversion to volts instead >>>>>>>> of millivolts as now (I think). Err. Looking at it that isn't >>>>>>>> actually documented... oops. I wonder which drivers actually do >>>>>>>> that and which don't. >>>>>>> The ones I wrote provide the scale for millivolts. >>>>>>> With the recent introduction of IIO_VAL_INT_PLUS_NANO we got the >>>>>>> scale accurate enough for the precession 24-bit converters. >>>>>>> If we move to the SI base unit volt, we lose this accuracy again. >>>>>> Yup, that's the principal counter argument to the change. >>>>> If we decide to leave the milli scale for volts... Do we also want to >>>>> stay with milli degrees Celsius, etc.? If we do it for one, probably >>>>> best to do it for them all.. >>> Hi Jonathan, >>> >>> So stick with the milli scale for all? >> Yes. >>>>> One other thing we should also address is the >>>>> byte-ordering/endianess of the scan elements stored in the ring buffers. >>>>> >>>>> Right now the scan_element type details signs, bits, storage bits and >>>>> shifts. However it lacks to tell the endianess within the storage bits. >>>>> Good point. I'd completely forgotten about that. >>>>> >>>>> How about le:s16/32>>0 or be:s16/32>>0 for example? >>>> Yup, that works for me. In cases where it doesn't matter they driver >>>> can pick one at random. >>> >>> We need another case - Some drivers use the (be|le)(x)_to_cpu() helpers, >>> So in case these are used the endianess can be either or, depending on the host. >>> So maybe have le|be|cpu? >> I thought about that, but am inclined to say we just stop drivers doing the conversion. >> Better to leave it up to userspace? > Well - we have and definitely will have more drivers where the conversion may be > to time consuming to do in kernel space. > I really don't have a strong preference here - but the important thing is that we need > to tell user space what format is placed into the buffers. Agreed. Do it during move out of staging or do a mass push to the drivers now? ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PATCH 0/2] blue part 6: IIO abi rework 2011-07-28 9:40 ` Jonathan Cameron @ 2011-07-28 9:53 ` Michael Hennerich 2011-07-28 11:58 ` Jonathan Cameron 0 siblings, 1 reply; 20+ messages in thread From: Michael Hennerich @ 2011-07-28 9:53 UTC (permalink / raw) To: Jonathan Cameron; +Cc: linux-iio, device-drivers-devel On 07/28/2011 11:40 AM, Jonathan Cameron wrote: > On 07/28/11 09:36, Michael Hennerich wrote: >> On 07/28/2011 10:36 AM, Jonathan Cameron wrote: >>> On 07/28/11 09:08, Hennerich, Michael wrote: >>>> Jonathan Cameron wrote on 2011-07-28: >>>>> On 07/27/11 15:41, Michael Hennerich wrote: >>>>>> On 07/26/2011 01:06 PM, Jonathan Cameron wrote: >>>>>>> On 07/26/11 11:52, Michael Hennerich wrote: >>>>>>>> On 07/26/2011 11:17 AM, Jonathan Cameron wrote: >>>>>>>>> On 07/26/11 10:01, Hennerich, Michael wrote: >>>>>>>>>> Jonathan Cameron wrote on 2011-07-25: >>>>>>>>>>> Michael pointed out the issues that not having an explicit >>>>>>>>>>> direction for channels was causing and the inconsistency of the >>>>>>>>>>> inX and outX channel naming we got from hmwon. >>>>>>>>>>> >>>>>>>>>>> They are stuck with it, but we aren't, so lets fix this now. >>>>>>>>>>> >>>>>>>>>>> Interesting question is whether we reset the base units to be >>>>>>>>>>> volts whilst we are at it? (for voltage channels obviously!) >>>>>>>>>> What do you mean exactly volts versus milli volts? >>>>>>>>> Make the in_voltage_scale correspond to conversion to volts instead >>>>>>>>> of millivolts as now (I think). Err. Looking at it that isn't >>>>>>>>> actually documented... oops. I wonder which drivers actually do >>>>>>>>> that and which don't. >>>>>>>> The ones I wrote provide the scale for millivolts. >>>>>>>> With the recent introduction of IIO_VAL_INT_PLUS_NANO we got the >>>>>>>> scale accurate enough for the precession 24-bit converters. >>>>>>>> If we move to the SI base unit volt, we lose this accuracy again. >>>>>>> Yup, that's the principal counter argument to the change. >>>>>> If we decide to leave the milli scale for volts... Do we also want to >>>>>> stay with milli degrees Celsius, etc.? If we do it for one, probably >>>>>> best to do it for them all.. >>>> Hi Jonathan, >>>> >>>> So stick with the milli scale for all? >>> Yes. >>>>>> One other thing we should also address is the >>>>>> byte-ordering/endianess of the scan elements stored in the ring buffers. >>>>>> >>>>>> Right now the scan_element type details signs, bits, storage bits and >>>>>> shifts. However it lacks to tell the endianess within the storage bits. >>>>>> Good point. I'd completely forgotten about that. >>>>>> >>>>>> How about le:s16/32>>0 or be:s16/32>>0 for example? >>>>> Yup, that works for me. In cases where it doesn't matter they driver >>>>> can pick one at random. >>>> We need another case - Some drivers use the (be|le)(x)_to_cpu() helpers, >>>> So in case these are used the endianess can be either or, depending on the host. >>>> So maybe have le|be|cpu? >>> I thought about that, but am inclined to say we just stop drivers doing the conversion. >>> Better to leave it up to userspace? >> Well - we have and definitely will have more drivers where the conversion may be >> to time consuming to do in kernel space. >> I really don't have a strong preference here - but the important thing is that we need >> to tell user space what format is placed into the buffers. > Agreed. Do it during move out of staging or do a mass push to the drivers now? > removing the endianess conversion on the buffers needs to come along with the scan_element type update. On one hand side its important information that we currently missing, and should be fixed sooner than later. On the other side it may require also some datasheet research. But it shouldn't be to much, since all SPI devices typically use MSB first, so for multiple bytes read sequentially we end up with BE. -- Greetings, Michael -- Analog Devices GmbH Wilhelm-Wagenfeld-Str. 6 80807 Muenchen Sitz der Gesellschaft: Muenchen; Registergericht: Muenchen HRB 40368; Geschaeftsfuehrer:Dr.Carsten Suckrow, Thomas Wessel, William A. Martin, Margaret Seif ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PATCH 0/2] blue part 6: IIO abi rework 2011-07-28 9:53 ` Michael Hennerich @ 2011-07-28 11:58 ` Jonathan Cameron 0 siblings, 0 replies; 20+ messages in thread From: Jonathan Cameron @ 2011-07-28 11:58 UTC (permalink / raw) To: michael.hennerich; +Cc: linux-iio, device-drivers-devel On 07/28/11 10:53, Michael Hennerich wrote: > On 07/28/2011 11:40 AM, Jonathan Cameron wrote: >> On 07/28/11 09:36, Michael Hennerich wrote: >>> On 07/28/2011 10:36 AM, Jonathan Cameron wrote: >>>> On 07/28/11 09:08, Hennerich, Michael wrote: >>>>> Jonathan Cameron wrote on 2011-07-28: >>>>>> On 07/27/11 15:41, Michael Hennerich wrote: >>>>>>> On 07/26/2011 01:06 PM, Jonathan Cameron wrote: >>>>>>>> On 07/26/11 11:52, Michael Hennerich wrote: >>>>>>>>> On 07/26/2011 11:17 AM, Jonathan Cameron wrote: >>>>>>>>>> On 07/26/11 10:01, Hennerich, Michael wrote: >>>>>>>>>>> Jonathan Cameron wrote on 2011-07-25: >>>>>>>>>>>> Michael pointed out the issues that not having an explicit >>>>>>>>>>>> direction for channels was causing and the inconsistency of the >>>>>>>>>>>> inX and outX channel naming we got from hmwon. >>>>>>>>>>>> >>>>>>>>>>>> They are stuck with it, but we aren't, so lets fix this now. >>>>>>>>>>>> >>>>>>>>>>>> Interesting question is whether we reset the base units to be >>>>>>>>>>>> volts whilst we are at it? (for voltage channels obviously!) >>>>>>>>>>> What do you mean exactly volts versus milli volts? >>>>>>>>>> Make the in_voltage_scale correspond to conversion to volts instead >>>>>>>>>> of millivolts as now (I think). Err. Looking at it that isn't >>>>>>>>>> actually documented... oops. I wonder which drivers actually do >>>>>>>>>> that and which don't. >>>>>>>>> The ones I wrote provide the scale for millivolts. >>>>>>>>> With the recent introduction of IIO_VAL_INT_PLUS_NANO we got the >>>>>>>>> scale accurate enough for the precession 24-bit converters. >>>>>>>>> If we move to the SI base unit volt, we lose this accuracy again. >>>>>>>> Yup, that's the principal counter argument to the change. >>>>>>> If we decide to leave the milli scale for volts... Do we also want to >>>>>>> stay with milli degrees Celsius, etc.? If we do it for one, probably >>>>>>> best to do it for them all.. >>>>> Hi Jonathan, >>>>> >>>>> So stick with the milli scale for all? >>>> Yes. >>>>>>> One other thing we should also address is the >>>>>>> byte-ordering/endianess of the scan elements stored in the ring buffers. >>>>>>> >>>>>>> Right now the scan_element type details signs, bits, storage bits and >>>>>>> shifts. However it lacks to tell the endianess within the storage bits. >>>>>>> Good point. I'd completely forgotten about that. >>>>>>> >>>>>>> How about le:s16/32>>0 or be:s16/32>>0 for example? >>>>>> Yup, that works for me. In cases where it doesn't matter they driver >>>>>> can pick one at random. >>>>> We need another case - Some drivers use the (be|le)(x)_to_cpu() helpers, >>>>> So in case these are used the endianess can be either or, depending on the host. >>>>> So maybe have le|be|cpu? >>>> I thought about that, but am inclined to say we just stop drivers doing the conversion. >>>> Better to leave it up to userspace? >>> Well - we have and definitely will have more drivers where the conversion may be >>> to time consuming to do in kernel space. >>> I really don't have a strong preference here - but the important thing is that we need >>> to tell user space what format is placed into the buffers. >> Agreed. Do it during move out of staging or do a mass push to the drivers now? >> > > removing the endianess conversion on the buffers needs to come along with the > scan_element type update. Not actually true. We can assume all current drivers are converting to cpu endianness so if it isn't specified output the local cpu endianess. Then we can move drivers over whenever we like. We'll squash the cpu option on move out of staging though as don't want that hanging around for ever more. > On one hand side its important information that > we currently missing, and should be fixed sooner than later. > On the other side it may require also some datasheet research. > But it shouldn't be to much, since all SPI devices typically use MSB first, so for > multiple bytes read sequentially we end up with BE. ^ permalink raw reply [flat|nested] 20+ messages in thread
end of thread, other threads:[~2011-07-28 13:30 UTC | newest] Thread overview: 20+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2011-07-25 13:23 [PATCH 0/2] blue part 6: IIO abi rework Jonathan Cameron 2011-07-25 13:23 ` [PATCH 1/2] staging:iio: ABI rework - add in_ or out_ prefix to channnels Jonathan Cameron 2011-07-25 15:19 ` Jonathan Cameron 2011-07-25 13:23 ` [PATCH 2/2] staging:iio:Documentation sysfs-bus-iio add in and out prefixes Jonathan Cameron 2011-07-26 9:01 ` [PATCH 0/2] blue part 6: IIO abi rework Hennerich, Michael 2011-07-26 9:17 ` Jonathan Cameron 2011-07-26 10:52 ` Michael Hennerich 2011-07-26 11:06 ` Jonathan Cameron 2011-07-27 14:41 ` Michael Hennerich 2011-07-28 8:03 ` Jonathan Cameron 2011-07-28 8:08 ` Hennerich, Michael 2011-07-28 8:33 ` Manuel Stahl 2011-07-28 9:52 ` Jonathan Cameron 2011-07-28 12:47 ` Manuel Stahl 2011-07-28 13:38 ` Jonathan Cameron 2011-07-28 8:36 ` Jonathan Cameron 2011-07-28 8:36 ` Michael Hennerich 2011-07-28 9:40 ` Jonathan Cameron 2011-07-28 9:53 ` Michael Hennerich 2011-07-28 11:58 ` Jonathan Cameron
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.