From: Andy Shevchenko <andriy.shevchenko@intel.com>
To: "Torreno, Alexis Czezar" <AlexisCzezar.Torreno@analog.com>
Cc: Lars-Peter Clausen <lars@metafoo.de>,
"Hennerich, Michael" <Michael.Hennerich@analog.com>,
Jonathan Cameron <jic23@kernel.org>,
David Lechner <dlechner@baylibre.com>,
"Sa, Nuno" <Nuno.Sa@analog.com>,
Andy Shevchenko <andy@kernel.org>, Rob Herring <robh@kernel.org>,
Krzysztof Kozlowski <krzk+dt@kernel.org>,
Conor Dooley <conor+dt@kernel.org>,
"linux-iio@vger.kernel.org" <linux-iio@vger.kernel.org>,
"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v3 2/2] iio: dac: ad5706r: Add support for AD5706R DAC
Date: Wed, 25 Mar 2026 14:12:59 +0200 [thread overview]
Message-ID: <acPRSzrHUtSEx-J3@ashevche-desk.local> (raw)
In-Reply-To: <PH0PR03MB63519301C13837DBD94535E2F149A@PH0PR03MB6351.namprd03.prod.outlook.com>
On Wed, Mar 25, 2026 at 01:07:44AM +0000, Torreno, Alexis Czezar wrote:
> > > > > Changes since v1:
> > > > > - Removed PWM, GPIO, clock generator, debugfs, regmap,
> > > > > IIO_BUFFER
> > > >
> > > > Why was regmap removed?! Was it not used?
> > >
> > > As far as I understand it, regmap also gives access to debugfs. When I
> > > removed debugfs I also added regmap as removed.
> >
> > Not only debugfs, and it's unrelated to the any custom debugfs interfaces in
> > the driver, it's just a feature out-of-the-box of regmap.
> >
> > > For the spi write/read I am not using regmap as the device has some
> > > features that I think regmap_read/write couldn't support. Namely the
> > > variable data width, as the device only accepts exact amount of clock
> > > cycles. Future patches will also add variable SPI speed.
> >
> > We have a lot of flexibility in regmap core. Do you think it can be improved /
> > extended to cover the cases like yours?
>
> To neatly summarize, my needs are: (in future patches)
> 1. SPI read/write can have different frequencies and runtime changeable
How does it related to regmap? Is it dependent on the register?
> 2. SPI data bits needs to be exactly 8bits or 16bits depending on register width
This is solved very easily with regmap, no problem at all (two regmaps with
configuration for 8-bit and 16-bit registers), I believe we have even driver
in kernel that does exactly this.
> 3. DAC Device reads SPI command bits [14:12] for communication, not just chip select
Okay, but I'm not sure how this is a limitation...
> For regmap to be used
> 1. regmap_config would need new read_speed and write_speed entries.
> 2. val_bits must now be changeable depending on the need.
> 3. I think the read/write_flag_mask can do this.
>
> 1) is relatively easy I think, but am not sure with 2) as it might break other regmap core code
> that already assumes it to be fixed.
> Feels like a lot of work for a niche amount of devices, I may still lean on the opinion of
> keeping regmap as is.
Okay, I leave it to others, for the simplicity we can leave driver as is, but
make sure you put the summary of this into the cover letter, so we will be
crystal clear why regmap hasn't been chosen.
--
With Best Regards,
Andy Shevchenko
next prev parent reply other threads:[~2026-03-25 12:13 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-18 5:13 [PATCH v3 0/2] Add support for AD5706R DAC Alexis Czezar Torreno
2026-03-18 5:13 ` [PATCH v3 1/2] dt-bindings: iio: dac: Add ADI AD5706R Alexis Czezar Torreno
2026-03-18 6:59 ` Krzysztof Kozlowski
2026-03-19 5:23 ` Torreno, Alexis Czezar
2026-03-18 5:13 ` [PATCH v3 2/2] iio: dac: ad5706r: Add support for AD5706R DAC Alexis Czezar Torreno
2026-03-18 8:16 ` Andy Shevchenko
2026-03-19 5:23 ` Torreno, Alexis Czezar
2026-03-19 7:07 ` Andy Shevchenko
2026-03-25 1:07 ` Torreno, Alexis Czezar
2026-03-25 10:13 ` Nuno Sá
2026-03-25 12:12 ` Andy Shevchenko [this message]
2026-03-27 9:01 ` Torreno, Alexis Czezar
2026-03-21 18:39 ` Jonathan Cameron
2026-03-25 1:22 ` Torreno, Alexis Czezar
2026-03-25 3:13 ` Torreno, Alexis Czezar
2026-03-25 10:14 ` Nuno Sá
2026-03-25 11:02 ` Nuno Sá
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=acPRSzrHUtSEx-J3@ashevche-desk.local \
--to=andriy.shevchenko@intel.com \
--cc=AlexisCzezar.Torreno@analog.com \
--cc=Michael.Hennerich@analog.com \
--cc=Nuno.Sa@analog.com \
--cc=andy@kernel.org \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=dlechner@baylibre.com \
--cc=jic23@kernel.org \
--cc=krzk+dt@kernel.org \
--cc=lars@metafoo.de \
--cc=linux-iio@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox