* [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
* [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 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
* 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: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: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 ` 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 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: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
* 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
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.