[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <2c36496c-68bb-4c06-8580-3efc694429ea@gmail.com>
Date: Fri, 5 Sep 2025 10:10:55 +0300
From: Matti Vaittinen <mazziesaccount@...il.com>
To: Andy Shevchenko <andy.shevchenko@...il.com>
Cc: Matti Vaittinen <matti.vaittinen@...rohmeurope.com>,
Jonathan Cameron <jic23@...nel.org>, David Lechner <dlechner@...libre.com>,
Nuno Sá <nuno.sa@...log.com>,
Andy Shevchenko <andy@...nel.org>, Rob Herring <robh@...nel.org>,
Krzysztof Kozlowski <krzk+dt@...nel.org>, Conor Dooley
<conor+dt@...nel.org>, Linus Walleij <linus.walleij@...aro.org>,
Bartosz Golaszewski <brgl@...ev.pl>,
Marcelo Schmitt <marcelo.schmitt@...log.com>,
Javier Carrasco <javier.carrasco.cruz@...il.com>,
Tobias Sperling <tobias.sperling@...ting.com>,
Antoniu Miclaus <antoniu.miclaus@...log.com>,
Trevor Gamblin <tgamblin@...libre.com>, Esteban Blanc <eblanc@...libre.com>,
Ramona Alexandra Nechita <ramona.nechita@...log.com>,
Hans de Goede <hansg@...nel.org>, Herve Codina <herve.codina@...tlin.com>,
Alisa-Dariana Roman <alisadariana@...il.com>, linux-iio@...r.kernel.org,
devicetree@...r.kernel.org, linux-kernel@...r.kernel.org,
linux-gpio@...r.kernel.org
Subject: Re: [PATCH v3 2/3] iio: adc: Support ROHM BD79112 ADC/GPIO
On 05/09/2025 09:54, Andy Shevchenko wrote:
> On Fri, Sep 5, 2025 at 9:42 AM Matti Vaittinen <mazziesaccount@...il.com> wrote:
>>
>> The ROHM BD79112 is an ADC/GPIO with 32 channels. The channel inputs can
>> be used as ADC or GPIO. Using the GPIOs as IRQ sources isn't supported.
>>
>> The ADC is 12-bit, supporting input voltages up to 5.7V, and separate I/O
>> voltage supply. Maximum SPI clock rate is 20 MHz (10 MHz with
>> daisy-chain configuration) and maximum sampling rate is 1MSPS.
>>
>> The IC does also support CRC but it is not implemented in the driver.
>
> ...
>
>> +config ROHM_BD79112
>> + tristate "Rohm BD79112 ADC driver"
>> + depends on I2C && GPIOLIB
>
> Still I2C?
Thanks :) I didn't spot this @_@. I just switched the REGMAP_I2C to
REGMAP_SPI. Will fix.
>
>> + select REGMAP_SPI
>> + select IIO_ADC_HELPER
>> + help
>> + Say yes here to build support for the ROHM BD79112 ADC. The
>> + ROHM BD79112 is a 12-bit, 32-channel, SAR ADC, which analog
>
> which --> where
I thought which (as a genetive case) would work here just fine?
>
>> + inputs can also be used for GPIO.
>
> ...
>
>> +/*
>> + * The data-sheet explains register I/O communication as follows:
>> + *
>> + * Read, two 16-bit sequences separated by CSB:
>> + * MOSI:
>> + * SCK: | 1 | 2 | 3 | 4 | 5 .. 8 | 9 .. 16 |
>> + * data:| 0 | 0 |IOSET| RW (1) | ADDR | 8'b0 |
>> + *
>> + * MISO:
>> + * SCK: | 1 .. 8 | 9 .. 16 |
>> + * data:| 8'b0 | data |
>> + *
>> + * Note, CSB is shown to be released between writing the address (MOSI) and
>> + * reading the register data (MISO).
>> + *
>> + * Write, single 16-bit sequence:
>> + * MOSI:
>> + * SCK: | 1 | 2 | 3 | 4 | 5 .. 8 |
>> + * data:| 0 | 0 |IOSET| RW(0) | ADDR |
>> + *
>> + * MISO:
>> + * SCK: | 1 .. 8 |
>> + * data:| data |
>> + */
>
> What I meant in previous reviews is that the | are not aligned (in the
> same columns). Is it on purpose? If so, I can't read that as I don't
> understand the meaning of | in each case. For example, the data starts
> with 0, followed by 0, and the latter one is when SCL is #1? Okay, but
> how to read IOSET that overlaps 2 SCK cycles and is unaligned with
> times... I'm really quite confused by these charts.
Ah. I think I now know what you mean. Whitespaces are hard :)
I see I have '\t' between the SCK: and first |.
>> + * SCK: /* '\t' here */ | 1 | 2 | 3 | 4 | 5 .. 8 |
It works perfectly on my editor, which has tab width 8. Thus, all the
'|' on SCK and data rows are perfectly aligned for me. My original
thought has been to align the first '|' on all rows by tab, but since
the " * data:" is already 8 chars I didn't add a tab for this row...
I now realize this will not work if tabs behave different from my setup.
I will do replacing the '\t' with ' '. Does this make it better for your
editor or do you see some other problem besides that?
Thanks for the patience explaining it.
> ...
>
>> + * Ouch. Seems the pin is ADC input - shouldn't happen as changing mux
>> + * at runtime is not supported and non GPIO pins should be invalidated
>> + * by the valid_mask at probe. Maybe someone wrote register bypassing
>
> wrote a
>
>> + * the driver?
>
Yours,
-- Matti
Powered by blists - more mailing lists