All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ramona Gradinariu <ramona.bolboaca13@gmail.com>
To: Jonathan Cameron <jic23@kernel.org>
Cc: linux-kernel@vger.kernel.org, linux-iio@vger.kernel.org,
	devicetree@vger.kernel.org, conor+dt@kernel.org,
	krzysztof.kozlowski+dt@linaro.org, robh@kernel.org,
	nuno.sa@analog.com
Subject: Re: [PATCH 7/7] drivers: iio: imu: Add support for adis1657x family
Date: Wed, 8 May 2024 17:32:34 +0300	[thread overview]
Message-ID: <9f0a8fdb-dd34-4a53-948d-d4ed0410de6f@gmail.com> (raw)
In-Reply-To: <20240428154523.17b27fa8@jic23-huawei>

Hello Jonathan,

Some explanations from my side.

>> @@ -437,6 +467,130 @@ static int adis16475_set_filter(struct adis16475 *st, const u32 filter)
>>  	return 0;
>>  }
>>  
>> +static ssize_t adis16475_get_fifo_enabled(struct device *dev,
>> +					  struct device_attribute *attr,
>> +					  char *buf)
>> +{
>> +	struct iio_dev *indio_dev = dev_to_iio_dev(dev);
>> +	struct adis16475 *st = iio_priv(indio_dev);
>> +	int ret;
>> +	u16 val;
>> +
>> +	ret = adis_read_reg_16(&st->adis, ADIS16475_REG_FIFO_CTRL, &val);
>> +	if (ret)
>> +		return ret;
>> +	val = FIELD_GET(ADIS16475_FIFO_EN_MASK, val);
>> +
>> +	return sysfs_emit(buf, "%d\n", val);
> As below, might as well put the FIELD_GET() in the sysfs_emit rather than
> writing the local parameter.

In all instances where I did, I did it to avoid casting. v2 inlines the values and
the cast is needed to avoid compilation errors.

> 	
>> +	if (adis->data->burst_max_len)
>> +		burst_max_length = adis->data->burst_max_len;
>> +	else
>> +		burst_max_length = burst_length;
>> +
>> +	tx = adis->buffer + burst_max_length;
>> +	tx[0] = ADIS_READ_REG(burst_req);
>> +
>> +	if (burst_req)
> If !burst_req does the rest of this do anything at all?
> If so flip the logic as
> 	if (!burst_req)
> 		return adis16475_push_single_sample(pf);
>
> 	the rest...
> 	return spi_sync(adis->spi, &adis->msg);

The update is needed even if burst_req is false. The adis message has to be updated
based on the burst request value, which is then used either in 
adis16475_push_single_sample or in spi_sync call.

> 		
>
>> +		return spi_sync(adis->spi, &adis->msg);
>> +
>> +	return adis16475_push_single_sample(pf);
>> +}
>> +
>> +/*
>> + * This handler is meant to be used for devices which support burst readings
>> + * from FIFO (namely devices from adis1657x family).
>> + * In order to pop the FIFO the 0x68 0x00 FIFO pop burst request has to be sent.
>> + * If the previous device command was not a FIFO pop burst request, the FIFO pop
>> + * burst request will simply pop the FIFO without returning valid data.
>> + * For the nth consecutive burst request, the
>> + * device will send the data popped with the (n-1)th consecutive burst request.
>> + * In order to read the data which was popped previously, without popping the FIFO,
>> + * the 0x00 0x00 burst request has to be sent.
>> + * If after a 0x68 0x00 FIFO pop burst request, there is any other device access
>> + * different from a 0x68 0x00 or a 0x00 0x00 burst request, the FIFO data popped
>> + * previously will be lost.
>> + */
>> +static irqreturn_t adis16475_trigger_handler_with_fifo(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;
>> +	u16 fifo_cnt, i;
>>  
>> -	adis16475_push_single_sample(pf);
>> +	adis_dev_lock(&st->adis);
>> +
>> +	ret = __adis_read_reg_16(adis, ADIS16475_REG_FIFO_CNT, &fifo_cnt);
>> +	if (ret || fifo_cnt < 2)
>> +		goto unlock;
> I would break these conditions and add a comment on why fifo_cnt < 2 is
> a reason to just return 0;

Updated this in v2, and actually fifo_cnt can also be 1 so the code simply
verifies if !fifo_cnt.

>
>> +
>> +	if (fifo_cnt > st->fifo_watermark)
>> +		fifo_cnt = st->fifo_watermark;
> fifo_cnt = min(fifo_cnt, st->fifo_watermark);
>
> This confuses me though as normally overreading after a fifo watermark is
> both safe and the right thing to do (as reduces chance of overflow etc).
> If we need to clamp to the watermark for some reason, add a comment.

Removed this in v2.

>>  
>>  			ret = __adis_write_reg_16(&st->adis,
>>  						  ADIS16475_REG_UP_SCALE,
>> @@ -1467,7 +1888,23 @@ static int adis16475_config_irq_pin(struct adis16475 *st)
>>  	 */
>>  	usleep_range(250, 260);
>>  
>> -	return 0;
>> +	/*
>> +	 * If the device has FIFO support, configure the watermark polarity
>> +	 * pin as well.
> The pin is for polarity or the polarity is for the watermark signalling on that
> pin?  I'm not seeing a datasheet yet for these parts so I couldn't check.

The device has a watermark pin, which can be used as a trigger source.
In this case we set the polarity for the watermark pin.

>
>> +	 */
>> +	if (st->info->flags & ADIS16475_HAS_FIFO) {
>> +		val = ADIS16475_WM_POL(polarity);
>> +		ret = adis_update_bits(&st->adis, ADIS16475_REG_FIFO_CTRL,
>> +				       ADIS16475_WM_POL_MASK, val);
>> +		if (ret)
>> +			return ret;
>> +
>> +		/* Enable watermark interrupt pin. */
>> +		val = ADIS16475_WM_EN(1);
>> +		ret = adis_update_bits(&st->adis, ADIS16475_REG_FIFO_CTRL, ADIS16475_WM_EN_MASK, val);

Best Regards,
Ramona


  reply	other threads:[~2024-05-08 14:32 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-04-26 13:53 [PATCH 0/7] adis16501 and adis1657x support Ramona Gradinariu
2024-04-26 13:53 ` [PATCH 1/7] dt-bindings: iio: imu: Add ADIS16501 compatibles Ramona Gradinariu
2024-04-26 16:36   ` Conor Dooley
2024-04-26 13:53 ` [PATCH 2/7] drivers: iio: imu: Add support for ADIS16501 Ramona Gradinariu
2024-04-26 13:53 ` [PATCH 3/7] iio: imu: adis16475: Re-define ADIS16475_DATA Ramona Gradinariu
2024-04-27  2:00   ` kernel test robot
2024-04-28 13:49     ` Jonathan Cameron
2024-04-27  2:43   ` kernel test robot
2024-04-26 13:53 ` [PATCH 4/7] iio: imu: adis_buffer: Add buffer setup API with buffer attributes Ramona Gradinariu
2024-04-27  3:05   ` kernel test robot
2024-04-26 13:53 ` [PATCH 5/7] iio: imu: adis16475: Create push single sample API Ramona Gradinariu
2024-04-26 13:53 ` [PATCH 6/7] dt-bindings: iio: imu: Add ADIS1657X family devices compatibles Ramona Gradinariu
2024-04-26 16:38   ` Conor Dooley
2024-04-26 13:53 ` [PATCH 7/7] drivers: iio: imu: Add support for adis1657x family Ramona Gradinariu
2024-04-28 14:45   ` Jonathan Cameron
2024-05-08 14:32     ` Ramona Gradinariu [this message]
2024-05-11 11:27       ` 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=9f0a8fdb-dd34-4a53-948d-d4ed0410de6f@gmail.com \
    --to=ramona.bolboaca13@gmail.com \
    --cc=conor+dt@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=jic23@kernel.org \
    --cc=krzysztof.kozlowski+dt@linaro.org \
    --cc=linux-iio@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=nuno.sa@analog.com \
    --cc=robh@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.