From: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
To: Jan Kiszka <jan.kiszka@siemens.com>, Jonathan Cameron <jic23@kernel.org>
Cc: linux-iio@vger.kernel.org,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Sascha Weisenberger <sascha.weisenberger@siemens.com>
Subject: Re: [PATCH] iio: adc: Add support for TI ADC1x8s102
Date: Mon, 24 Apr 2017 23:05:30 +0300 [thread overview]
Message-ID: <1493064330.24567.180.camel@linux.intel.com> (raw)
In-Reply-To: <6e0f0b52-27a1-0ce5-c217-3aa941babe63@siemens.com>
On Mon, 2017-04-24 at 21:28 +0200, Jan Kiszka wrote:
> This is an upstream port of an IIO driver for the TI ADC108S102 and
> ADC128S102. The former can be found on the Intel Galileo Gen2 and the
> Siemens SIMATIC IOT2000. For those boards, ACPI-based enumeration is
> included.
>
> Original author: Bogdan Pricop <bogdan.pricop@emutex.com>
> Ported from Intel Galileo Gen2 BSP to Intel Yocto kernel:
> Todor Minchev <todor@minchev.co.uk>.
> +#include <linux/interrupt.h>
> +#include <linux/module.h>
> +#include <linux/spi/spi.h>
> +
> +#include <linux/platform_data/adc1x8s102.h>
> +#include <linux/regulator/consumer.h>
> +
> +#include <linux/delay.h>
> +#include <linux/acpi.h>
> +#include <linux/property.h>
> +#include <linux/gpio.h>
> +
> +#include <linux/spi/pxa2xx_spi.h>
Perhaps alphabetical order?
> +
> +/* 16-bit SPI command format:
> + * [15:14] Ignored
> + * [13:11] 3-bit channel address
> + * [10:0] Ignored
> + */
> +#define ADC1x8S102_CMD(ch) (((ch) << (8)) << (3))
I guess ((u16)(ch) << 11) would be slightly better.
> +
> +/*
> + * 16-bit SPI response format:
> + * [15:12] Zeros
> + * [11:0] 12-bit ADC sample (for ADC108S102, [1:0] will always be
> 0).
> + */
> +#define ADC1x8S102_RES_DATA(res) (res & ((1 <<
> ADC1x8S102_BITS) - 1))
GENMASK() and to align with above
((u16)(res) & GENMASK(11, 0))
> + /* SPI message buffers:
> + * tx_buf: |C0|C1|C2|C3|C4|C5|C6|C7|XX|
> + * rx_buf: |XX|R0|R1|R2|R3|R4|R5|R6|R7|tt|tt|tt|tt|
> + *
> + * tx_buf: 8 channel read commands, plus 1 dummy command
> + * rx_buf: 1 dummy response, 8 channel responses, plus 64-
> bit timestamp
> + */
> + __be16 rx_buf[13]
> ____cacheline_aligned;
> + __be16 tx_buf[9];
Would it be better to have tx_buf with ____cache_aligned? (IIUC it's
already by fact of above, though...)
> +};
> tatic int adc1x8s102_update_scan_mode(struct iio_dev *indio_dev,
> + unsigned long const *active_scan_mask)
> +{
> + struct adc1x8s102_state *st;
> + int i, j;
> +
> + st = iio_priv(indio_dev);
> +
> + /* Fill in the first x shorts of tx_buf with the number of
> channels
> + * enabled for sampling by the triggered buffer
> + */
/*
* Is it okay style for
* multi-line comments?
*/
> + for (i = 0, j = 0; i < ADC1x8S102_MAX_CHANNELS; i++) {
> + if (test_bit(i, active_scan_mask)) {
for_each_set_bit()
> + st->tx_buf[j] =
> cpu_to_be16(ADC1x8S102_CMD(i));
> + j++;
> + }
> + }
> + /* One dummy command added, to clock in the last response */
> + st->tx_buf[j] = 0x00;
> +}
> +
> +static int adc1x8s102_read_raw(struct iio_dev *indio_dev,
> + struct iio_chan_spec const *chan,
> + int *val,
> + int *val2,
> + long m)
One line?
> +{
> + int ret;
> + struct adc1x8s102_state *st;
> +
> + st = iio_priv(indio_dev);
> +
> + switch (m) {
> + case IIO_CHAN_INFO_RAW:
> + mutex_lock(&indio_dev->mlock);
> + if (indio_dev->currentmode == INDIO_BUFFER_TRIGGERED)
> {
> + ret = -EBUSY;
> + dev_warn(&st->spi->dev,
> + "indio_dev->currentmode is
> INDIO_BUFFER_TRIGGERED\n");
Indentation?
> + } else {
> + ret = adc1x8s102_scan_direct(st, chan-
> >address);
> + }
> + mutex_unlock(&indio_dev->mlock);
> +
> + if (ret < 0)
> + return ret;
> + *val = ADC1x8S102_RES_DATA(ret);
> +
> + return IIO_VAL_INT;
> + case IIO_CHAN_INFO_SCALE:
> + switch (chan->type) {
> + case IIO_VOLTAGE:
> + if (st->reg)
> + *val = regulator_get_voltage(st->reg)
> / 1000;
> + else
> + *val = st->ext_vin;
> +
> + *val2 = chan->scan_type.realbits;
> + return IIO_VAL_FRACTIONAL_LOG2;
> + default:
> + dev_warn(&st->spi->dev,
> + "Invalid channel type %u for channel
> %d\n",
> + chan->type, chan->channel);
> + return -EINVAL;
> + }
> + default:
> + dev_warn(&st->spi->dev, "Invalid IIO_CHAN_INFO:
> %lu\n", m);
> + return -EINVAL;
> + }
> +}
> +#ifdef CONFIG_ACPI
> +typedef int (*acpi_setup_handler)(struct spi_device *,
> + const struct
> adc1x8s102_platform_data **);
> +
> +static const struct adc1x8s102_platform_data int3495_platform_data =
> {
> + .ext_vin = 5000, /* 5 V */
> +};
> +
> +/* Galileo Gen 2 SPI setup */
> +static int
> +adc1x8s102_setup_int3495(struct spi_device *spi,
> + const struct adc1x8s102_platform_data
> **pdata)
> +{
> + struct pxa2xx_spi_chip *chip_data;
This one is too big to waste memory on one member.
> +
> + chip_data = devm_kzalloc(&spi->dev, sizeof(*chip_data),
> GFP_KERNEL);
> + if (!chip_data)
> + return -ENOMEM;
> +
> + chip_data->gpio_cs = ADC1x8S102_GALILEO2_CS;
> + spi->controller_data = chip_data;
> + dev_info(&spi->dev, "setting GPIO CS value to %d\n",
> + chip_data->gpio_cs);
> + spi_setup(spi);
> +
> + *pdata = &int3495_platform_data;
> +
> + return 0;
> +}
This is weird approach.
Moreover, please do not use platform data at all.
> +
> +static const struct acpi_device_id adc1x8s102_acpi_ids[] = {
> + { "INT3495", (kernel_ulong_t)&adc1x8s102_setup_int3495 },
> + { }
> +};
> +MODULE_DEVICE_TABLE(acpi, adc1x8s102_acpi_ids);
> +#endif
> +
> +static int adc1x8s102_probe(struct spi_device *spi)
> +{
> + const struct adc1x8s102_platform_data *pdata = spi-
> >dev.platform_data;
> + struct adc1x8s102_state *st;
> + struct iio_dev *indio_dev;
> + int ret;
> +
> +#ifdef CONFIG_ACPI
No.
> + if (ACPI_COMPANION(&spi->dev)) {
> + acpi_setup_handler setup_handler;
> + const struct acpi_device_id *id;
> +
> + id = acpi_match_device(adc1x8s102_acpi_ids, &spi-
> >dev);
> + if (!id)
> + return -ENODEV;
> +
> + setup_handler = (acpi_setup_handler)id->driver_data;
> + if (setup_handler) {
> + ret = setup_handler(spi, &pdata);
> + if (ret)
> + return ret;
> + }
No way.
> + }
> +#endif
> +
> + if (!pdata) {
> + dev_err(&spi->dev, "Cannot get adc1x8s102 platform
> data\n");
> + return -ENODEV;
> + }
> +
> +error_cleanup_ring:
> + iio_triggered_buffer_cleanup(indio_dev);
> +error_disable_reg:
> + regulator_disable(st->reg);
Does devm_() help to get rid of these?
> +
> + return ret;
> +}
> +
> +static int adc1x8s102_remove(struct spi_device *spi)
> +{
> + struct iio_dev *indio_dev = spi_get_drvdata(spi);
> + struct adc1x8s102_state *st = iio_priv(indio_dev);
> +
> + iio_device_unregister(indio_dev);
> + iio_triggered_buffer_cleanup(indio_dev);
> +
> + regulator_disable(st->reg);
Ditto.
> +
> + return 0;
> +}
> +
> +++ b/include/linux/platform_data/adc1x8s102.h
It must be no such file at all!
Please, remove it completely.
--
Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Intel Finland Oy
next prev parent reply other threads:[~2017-04-24 20:05 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-04-24 19:28 [PATCH] iio: adc: Add support for TI ADC1x8s102 Jan Kiszka
2017-04-24 20:05 ` Andy Shevchenko [this message]
2017-04-24 20:10 ` Andy Shevchenko
2017-04-24 20:37 ` Jan Kiszka
2017-04-24 20:32 ` Jan Kiszka
2017-04-24 21:25 ` Andy Shevchenko
2017-04-25 5:44 ` Jan Kiszka
2017-04-25 9:42 ` Andy Shevchenko
2017-04-25 10:53 ` Jan Kiszka
2017-04-25 11:27 ` Andy Shevchenko
2017-04-25 11:35 ` Mika Westerberg
2017-04-25 12:17 ` Jan Kiszka
2017-04-25 12:30 ` Mika Westerberg
2017-04-25 13:47 ` Jan Kiszka
2017-04-25 16:12 ` Jan Kiszka
2017-04-26 9:01 ` Mika Westerberg
2017-04-27 6:01 ` Jonathan Cameron
2017-04-27 6:04 ` Jonathan Cameron
2017-05-19 16:01 ` Mark Brown
2017-05-20 16:26 ` Jonathan Cameron
2017-05-22 10:06 ` Mark Brown
2017-04-25 6:06 ` Jan Kiszka
2017-04-25 7:31 ` Peter Meerwald-Stadler
2017-04-25 9:20 ` Andy Shevchenko
2017-04-25 9:32 ` Jan Kiszka
2017-04-25 11:23 ` Andy Shevchenko
2017-04-25 12:20 ` Mika Westerberg
2017-04-26 5:37 ` Jan Kiszka
2017-04-26 10:21 ` Andy Shevchenko
2017-04-27 6:14 ` Jonathan Cameron
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1493064330.24567.180.camel@linux.intel.com \
--to=andriy.shevchenko@linux.intel.com \
--cc=jan.kiszka@siemens.com \
--cc=jic23@kernel.org \
--cc=linux-iio@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=sascha.weisenberger@siemens.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).