public inbox for devicetree@vger.kernel.org
 help / color / mirror / Atom feed
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");  
> 


  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