From: Jonathan Cameron <jic23@kernel.org>
To: "Sa, Nuno" <Nuno.Sa@analog.com>
Cc: "linux-iio@vger.kernel.org" <linux-iio@vger.kernel.org>,
"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
"mark.rutland@arm.com" <mark.rutland@arm.com>,
"pmeerw@pmeerw.net" <pmeerw@pmeerw.net>,
"lars@metafoo.de" <lars@metafoo.de>,
"Ardelean, Alexandru" <alexandru.Ardelean@analog.com>,
"Hennerich, Michael" <Michael.Hennerich@analog.com>,
"knaack.h@gmx.de" <knaack.h@gmx.de>,
"robh+dt@kernel.org" <robh+dt@kernel.org>
Subject: Re: [PATCH 4/5] iio: imu: Add support for adis16475
Date: Sat, 7 Mar 2020 11:27:17 +0000 [thread overview]
Message-ID: <20200307112717.64245cf7@archlinux> (raw)
In-Reply-To: <f1f14ed4f13c41be728cee976b969192af95e61c.camel@analog.com>
...
> > > > +static irqreturn_t adis16475_trigger_handler(int irq, void *p)
> > > > +{
> > > > + struct iio_poll_func *pf = p;
> > > > + struct iio_dev *indio_dev = pf->indio_dev;
> > > > + struct adis16475 *st = iio_priv(indio_dev);
> > > > + struct adis *adis = &st->adis;
> > > > + int ret, bit, i = 0;
> > > > + u16 crc, data[ADIS16475_MAX_SCAN_DATA], *buffer, crc_res;
> > > > + /* offset until the first element after gyro and accel */
> > > > + const u8 offset = st->burst32 ? 13 : 7;
> > > > +
> > > > + ret = spi_sync(adis->spi, &adis->msg);
> > > > + if (ret)
> > > > + return ret;
> > > > +
> > > > + buffer = (u16 *)adis->buffer;
> > > > +
> > > > + if (!(adis->burst && adis->burst->en))
> > > > + goto push_to_buffers;
> > > > +
> > > > + /* We always validate the crc to at least print a message */
> > > > + crc = get_unaligned_be16(&buffer[offset + 2]);
> > > > + crc_res = adis16475_validate_crc((u8 *)adis->buffer, crc,
> > > > + st->burst32);
> > > > + if (crc_res)
> > > > + dev_err(&adis->spi->dev, "Invalid crc\n");
> > > > +
> > > > + for_each_set_bit(bit, indio_dev->active_scan_mask,
> > > > + indio_dev->masklength) {
> > > > + /*
> > > > + * When burst mode is used, system flags is the first
> > > > data
> > > > + * channel in the sequence, but the scan index is 7.
> > > > + */
> > > > + switch (bit) {
> > > > + case ADIS16475_SCAN_TEMP:
> > > > + data[i++] = get_unaligned(&buffer[offset]);
> > > > + break;
> > > > + case ADIS16475_SCAN_GYRO_X ... ADIS16475_SCAN_ACCEL_Z:
> > > > + /*
> > > > + * The first 2 bytes on the received data are
> > > > the
> > > > + * DIAG_STAT reg, hence the +1 offset here...
> > > > + */
> > > > + if (st->burst32) {
> > > > + /* upper 16 */
> > > > + data[i++] = get_unaligned(&buffer[bit *
> > > > 2 + 2]);
> > > > + /* lower 16 */
> > > > + data[i++] = get_unaligned(&buffer[bit *
> > > > 2 + 1]);
> > > > + } else {
> > > > + data[i++] = get_unaligned(&buffer[bit +
> > > > 1]);
> > > > + /* lower not used */
> > > > + data[i++] = 0;
> > > > + }
> > > > + break;
> > > > + }
> > > > + }
> > > > +
> > > > + buffer = data;
> > > > +
> > > > +push_to_buffers:
> > > > + iio_push_to_buffers_with_timestamp(indio_dev, buffer, pf-
> > > > > timestamp);
> > >
> > > I'm not sure data is the right size. It needs to have space to
> > > have
> > > an aligned
> > > timestamp at the end.
> >
> > Will double check this... Honestly I did not had the timestamp into
> > account so the size is probably wrong.
>
> I guess you are right. With all the channels enabled I think we need a
> 40 bytes buffer in order to have the aligned timestamp...
>
Sounds right.
> > > > +static const struct spi_device_id adis16475_ids[] = {
> > >
> > > Is it actually possible to instantiate this except by
> > > using the dt table below? If not, then move the 'data'
> > > part into that table and don't provide an spi_device_id
> > > table at all. It's not relevant to the possible ways
> > > of causing the driver to probe.
> >
> > I guess we could use the id table with devicetree even without the dt
> > table (even though it makes no sense).
> >
> > So, I can remove it but I was using the id->name to set the the
> > iio_dev
> > name which I guess is not the right way?
> >
> > What Im thinking is having a name/part number string in chip info
> > that
> > I can use to set the iio dev name. For parts that have the *-[1|2|3]
> > variations I could use the devicetree iio label property. Is this the
> > correct way of handling this?
>
> I was misunderstanding some stuff here. So, the *-[1|2|3] are valid
> part numbers so they can be in the `name`, right? So, labels come into
> play, for example, when we have multiple instances of the same part,
> right?
Absolutely fine to have the -1 etc. They are odd part numbers, but they
are the ones on the datasheet etc.
>
> > - Nuno Sá
> > > > + { "adis16470", ADIS16470 },
> > > > + { "adis16475-1", ADIS16475_1 },
> > > > + { "adis16475-2", ADIS16475_2 },
> > > > + { "adis16475-3", ADIS16475_3 },
> > > > + { "adis16477-1", ADIS16477_1 },
> > > > + { "adis16477-2", ADIS16477_2 },
> > > > + { "adis16477-3", ADIS16477_3 },
> > > > + { "adis16465-1", ADIS16465_1 },
> > > > + { "adis16465-2", ADIS16465_2 },
> > > > + { "adis16465-3", ADIS16465_3 },
> > > > + { "adis16467-1", ADIS16467_1 },
> > > > + { "adis16467-2", ADIS16467_2 },
> > > > + { "adis16467-3", ADIS16467_3 },
> > > > + { "adis16500", ADIS16500 },
> > > > + { "adis16505-1", ADIS16505_1 },
> > > > + { "adis16505-2", ADIS16505_2 },
> > > > + { "adis16505-3", ADIS16505_3 },
> > > > + { "adis16507-1", ADIS16507_1 },
> > > > + { "adis16507-2", ADIS16507_2 },
> > > > + { "adis16507-3", ADIS16507_3 },
> > > > + { }
> > > > +};
> > > > +MODULE_DEVICE_TABLE(spi, adis16475_ids);
> > > > +
> > > > +static const struct of_device_id adis16475_of_match[] = {
> > > > + { .compatible = "adi,adis16470" },
> > > > + { .compatible = "adi,adis16475-1" },
> > > > + { .compatible = "adi,adis16475-2" },
> > > > + { .compatible = "adi,adis16475-3" },
> > > > + { .compatible = "adi,adis16477-1" },
> > > > + { .compatible = "adi,adis16477-2" },
> > > > + { .compatible = "adi,adis16477-3" },
> > > > + { .compatible = "adi,adis16465-1" },
> > > > + { .compatible = "adi,adis16465-2" },
> > > > + { .compatible = "adi,adis16465-3" },
> > > > + { .compatible = "adi,adis16467-1" },
> > > > + { .compatible = "adi,adis16467-2" },
> > > > + { .compatible = "adi,adis16467-3" },
> > > > + { .compatible = "adi,adis16500" },
> > > > + { .compatible = "adi,adis16505-1" },
> > > > + { .compatible = "adi,adis16505-2" },
> > > > + { .compatible = "adi,adis16505-3" },
> > > > + { .compatible = "adi,adis16507-1" },
> > > > + { .compatible = "adi,adis16507-2" },
> > > > + { .compatible = "adi,adis16507-3" },
> > > > + { },
> > > > +};
> > > > +MODULE_DEVICE_TABLE(of, adis16475_of_match);
> > > > +
> > > > +static struct spi_driver adis16475_driver = {
> > > > + .driver = {
> > > > + .name = "adis16475",
> > > > + .of_match_table = adis16475_of_match,
> > > > + },
> > > > + .id_table = adis16475_ids,
> > > > + .probe = adis16475_probe,
> > > > +};
> > > > +module_spi_driver(adis16475_driver);
> > > > +
> > > > +MODULE_AUTHOR("Nuno Sa <nuno.sa@analog.com>");
> > > > +MODULE_DESCRIPTION("Analog Devices ADIS16475 IMU driver");
> > > > +MODULE_LICENSE("GPL");
>
next prev parent reply other threads:[~2020-03-07 11:27 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-02-25 12:41 [PATCH 0/5] Support ADIS16475 and similar IMUs Nuno Sá
2020-02-25 12:41 ` [PATCH 1/5] iio: imu: adis: Add Managed device functions Nuno Sá
2020-03-03 20:38 ` Jonathan Cameron
2020-03-04 17:28 ` Sa, Nuno
2020-02-25 12:41 ` [PATCH 2/5] iio: imu: adis: Add irq mask variable Nuno Sá
2020-03-03 20:40 ` Jonathan Cameron
2020-03-04 17:29 ` Sa, Nuno
2020-02-25 12:41 ` [PATCH 3/5] iio: adis: Add adis_update_bits() APIs Nuno Sá
2020-03-03 20:48 ` Jonathan Cameron
2020-03-04 17:32 ` Sa, Nuno
2020-02-25 12:41 ` [PATCH 4/5] iio: imu: Add support for adis16475 Nuno Sá
2020-03-03 21:08 ` Jonathan Cameron
2020-03-04 17:59 ` Sa, Nuno
2020-03-05 9:58 ` Sa, Nuno
2020-03-05 10:39 ` Lars-Peter Clausen
2020-03-07 11:25 ` Jonathan Cameron
2020-03-07 11:27 ` Jonathan Cameron [this message]
2020-02-25 12:41 ` [PATCH 5/5] dt-bindings: iio: Add adis16475 documentation Nuno Sá
2020-03-02 22:22 ` Rob Herring
2020-03-03 9:43 ` Sa, Nuno
2020-03-03 9:59 ` Sa, Nuno
2020-03-03 16:34 ` Rob Herring
2020-03-04 17:25 ` Sa, Nuno
2020-03-03 21:10 ` Jonathan Cameron
2020-03-04 18:00 ` Sa, Nuno
2020-03-05 10:34 ` Lars-Peter Clausen
2020-03-05 12:27 ` Sa, Nuno
2020-03-05 12:43 ` Lars-Peter Clausen
2020-03-05 13:04 ` Sa, Nuno
2020-03-07 11:33 ` Jonathan Cameron
2020-03-07 20:47 ` nunojsa
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=20200307112717.64245cf7@archlinux \
--to=jic23@kernel.org \
--cc=Michael.Hennerich@analog.com \
--cc=Nuno.Sa@analog.com \
--cc=alexandru.Ardelean@analog.com \
--cc=devicetree@vger.kernel.org \
--cc=knaack.h@gmx.de \
--cc=lars@metafoo.de \
--cc=linux-iio@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=pmeerw@pmeerw.net \
--cc=robh+dt@kernel.org \
/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