[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID:
<SN6PR03MB432071701D6A19C3B4C0C33FF3F22@SN6PR03MB4320.namprd03.prod.outlook.com>
Date: Wed, 29 May 2024 15:01:06 +0000
From: "Nechita, Ramona" <Ramona.Nechita@...log.com>
To: Andy Shevchenko <andriy.shevchenko@...ux.intel.com>
CC: "linux-iio@...r.kernel.org" <linux-iio@...r.kernel.org>,
Jonathan Cameron
<jic23@...nel.org>,
Lars-Peter Clausen <lars@...afoo.de>,
"Hennerich,
Michael" <Michael.Hennerich@...log.com>,
Liam Girdwood <lgirdwood@...il.com>, Mark Brown <broonie@...nel.org>,
"Sa, Nuno" <Nuno.Sa@...log.com>,
Marius
Cristea <marius.cristea@...rochip.com>,
"Schmitt, Marcelo"
<Marcelo.Schmitt@...log.com>,
Maksim Kiselev <bigunclemax@...il.com>,
Ivan
Mikhaylov <fr0st61te@...il.com>,
Marcus Folkesson
<marcus.folkesson@...il.com>,
Liam Beguin <liambeguin@...il.com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: RE: [PATCH] drivers: iio: adc: add support for ad777x family
Hello,
Thank you for the review. I implemented most of your comments, excepting some things that were slightly unclear to me or I had a different explanation I left a couple of comments below, and I will send a new patch in a separate email.
>On Wed, May 22, 2024 at 02:59:53PM +0300, ranechita wrote:
>> Added support for ad7770,ad7771,ad7779 ADCs. The data is streamed only
>> on the spi-mode, without using the data lines.
>
>> ---
>
>Please, explain here, in the comment area, why any existing driver can not be reused (extended) for these ADCs.
>
>...
>
>> +#include <linux/gpio.h>
>
>This header must not be in the new code.
>
>...
>
>> +#define AD777X_SINC3_MAXFREQ 16000
>> +#define AD777X_SINC5_MAXFREQ 128000
>
>HZ_PER_KHZ ? You will need units.h.
>
>...
>
>> +#define DEC3 1000
>> +#define DEC6 1000000
>
>NIH some of units.h constants. Use them.
>
>...
>
>
>> + /*
>> + * DMA (thus cache coherency maintenance) requires the
>> + * transfer buffers to live in their own cache lines.
>> + */
>> + u8 reg_rx_buf[3] ____cacheline_aligned;
>> + u8 reg_tx_buf[3];
>
>> + u8 spidata_rx[32];
>> + u8 spidata_tx[32];
>
>These will not be cache aligned. Is it a problem?
No, it should be fine without the alignment.
> ------
>
>> +{
>> + int ret;
>> + u8 regval, data;
>> +
>> + ret = ad777x_spi_read(st, reg, &data);
>> + if (ret)
>> + return ret;
>> +
>> + regval = data;
>> + regval &= ~mask;
>> + regval |= val;
>> +
>> + if (regval != data) {
>> + ret = ad777x_spi_write(st, reg, regval);
>> + if (ret)
>> + return ret;
>> + }
>> +
>> + return 0;
>
>This all can be written as
>
> if (regval != data)
> return ad777x_spi_write(st, reg, regval);
>
> return 0;
>
>...or...
>
> if (regval == data)
> return 0;
>
> return ad777x_spi_write(st, reg, regval);
>
>(I prefer the latter as it shows better the flow)
>
>> +}
>
>No mutex no nothing for RMW op like this?
>
>Btw, can't you use regmap for IO?
Unfortunately, I don't think regmap could be used, because of the crc and the fact that data is shifted out on the SPI SDO line in the interrupt. I consider perhaps adding regmap to the mix might complicate things a bit.
>
>...
>
>> + if (st->filter_enabled == AD777X_SINC3 &&
>> + sampling_freq > AD777X_SINC3_MAXFREQ) {
>> + return -EINVAL;
>> + } else if (st->filter_enabled == AD777X_SINC5 &&
>
>Redundant 'else'
>
>> + sampling_freq > AD777X_SINC5_MAXFREQ) {
>
>Broken indentation.
>
>> + return -EINVAL;
>> + }
>
>Unneeded {}.
>
>...
>
>> + ret = ad777x_spi_write(st, AD777X_REG_SRC_N_LSB, lsb);
>> + if (ret)
>> + return ret;
>> + ret = ad777x_spi_write(st, AD777X_REG_SRC_N_MSB, msb);
>> + if (ret)
>> + return ret;
>
>Can you use 16-bit writes?
>Same Q to all similar LSB/MSB write groups.
I cannot do 16-bit writes due to how the spi functions on the chip and because the registers for MSB/LSB are at different addresses.
>--------
>> +static void ad777x_clk_disable(void *data) {
>> + clk_disable_unprepare(data);
>> +}
>
>See below.
>
>...
>
>> + st->mclk = devm_clk_get(&spi->dev, "mclk");
>> + if (IS_ERR(st->mclk))
>> + return PTR_ERR(st->mclk);
>> +
>> + ret = clk_prepare_enable(st->mclk);
>> + if (ret < 0)
>> + return ret;
>
>> + ret = devm_add_action_or_reset(&spi->dev,
>> + ad777x_clk_disable,
>> + st->mclk);
>> + if (ret)
>> + return ret;
>
>So, what's wrong with the _enabled() API?
Sorry, I am not sure what you mean here by _enabled() API, is there a different mechanism that can be used for this type of operations?
Best Regards,
Ramona
Powered by blists - more mailing lists