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 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.