Hi
Am 12/15/2011 05:07 PM, schrieb Lars-Peter Clausen:
On 12/15/2011 02:51 PM, Duss Pirmin wrote:
Hi,
It looks like your driver is based on a rather old version of IIO. Please
try to always submit IIO patches against Gregs staging-next[1] tree.
I wrote it against 3.0.4, as this is the Kernel of the target we us it
for. I will adapt it to staging-next.
Also it looks like your mail program messed up the patch. (Replaced tabs
with space, inserted line breaks).
I will check the settings of my Thunderbird.
+
+struct ads1110_conversion_mode {
+ char *name;
+ u8 reg_cfg;
+};
+
+static struct ads1110_conversion_mode
+ads1110_conv_mode_table[ADS1110_MAX_CONV_MODE] = {
+ { "continuous-conversion", 0 },
+ { "single-conversion", 1 },
+};
This should probably not user controllable. You probably want to do a single
conversion when reading from sysfs and use continuous conversion when using
a triggered buffer.
+static int ads1110_i2c_read_config(struct ads1110_chip_info *chip, u8 *data)
+{
+ struct i2c_client *client = chip->client;
+ int ret = 0;
+ u8 tmp[3]; // read three bytes ; first two are data third is the
config
Please use C style comments.
Ok.
+
+static IIO_DEV_ATTR_START_CONVERSION(S_IWUSR,
+ NULL,
+ ads1110_store_start_conversion);
This should probably not be a sysfs attribute, but be set on demand.
+
+/*
+ * attributes for ysfs
+ */
+
+static struct attribute *ads1110_attributes[] = {
+&iio_dev_attr_available_conversion_modes.dev_attr.attr,
+&iio_dev_attr_available_data_rates.dev_attr.attr,
+&iio_dev_attr_available_gains.dev_attr.attr,
+&iio_dev_attr_value.dev_attr.attr,
+&iio_dev_attr_conversion_mode.dev_attr.attr,
+&iio_dev_attr_data_rate.dev_attr.attr,
+&iio_dev_attr_gain.dev_attr.attr,
+&iio_dev_attr_start_conversion.dev_attr.attr,
+ NULL,
+};
Please use channel_spec. Most of the attributes can probably be expresses
through it. For those which can not please take a look at
Documentation/sysfs-bus-iio and see which already existing attribute names
match your use case. E.g. your "data_rate" should probably be
"sampling_frequency".
Ok.
+
+static const struct iio_info ads1110_info = {
+ .attrs =&ads1110_attribute_group,
+ .num_interrupt_lines = 1,
+ .event_attrs =&ads1110_event_attribute_group,
+ .driver_module = THIS_MODULE,
+};
+
+/*
+ * device probe and remove
+ */
+
+static int __devinit ads1110_probe(struct i2c_client *client,
+ const struct i2c_device_id *id)
+{
+ int ret = 0, regdone = 0;
+ struct ads1110_chip_info *chip = kzalloc(sizeof(*chip), GFP_KERNEL);
+ if (chip == NULL) {
+ ret = -ENOMEM;
+ goto error_ret;
+ }
+
+ // this is only used for device removal purposes
+ i2c_set_clientdata(client, chip);
+
+ chip->client = client;
+
+ chip->indio_dev = iio_allocate_device(0);
+ if (chip->indio_dev == NULL) {
+ ret = -ENOMEM;
+ goto error_free_chip;
+ }
+
Make your ads1110_chip_info the private part of the iio_device.
indio_dev = iio_allocate_device(sizeof(*chip));
chip = iio_priv(indio_dev);
Copied and adapted this code from ad7150.c in 3.0.4, will change this.
+error_free_dev:
+ if (regdone)
+ iio_device_unregister(chip->indio_dev);
+ else
+ iio_free_device(chip->indio_dev);
You have to call both device_unregister and free_device with the current
version of IIO.
OK.
+static const struct i2c_device_id ads1110_id[] = {
+ { "ads1110-ed0", 0x48 },
+ { "ads1110-ed1", 0x49 },
+ { "ads1110-ed2", 0x50 },
+ { "ads1110-ed3", 0x51 },
+ { "ads1110-ed4", 0x52 },
+ { "ads1110-ed5", 0x53 },
+ { "ads1110-ed6", 0x54 },
+ { "ads1110-ed7", 0x55 },
Are these really different parts, or is it just the same part with a
different I2C address controlled by some external pins?
Each is an different part. no pins to control the I2C address.
--
To unsubscribe from this list: send the line "unsubscribe linux-iio" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
