public inbox for devicetree@vger.kernel.org
 help / color / mirror / Atom feed
From: <Ariana.Lazar@microchip.com>
To: <jic23@kernel.org>
Cc: <dlechner@baylibre.com>, <nuno.sa@analog.com>,
	<linux-iio@vger.kernel.org>, <devicetree@vger.kernel.org>,
	<robh@kernel.org>, <linux-kernel@vger.kernel.org>,
	<andy@kernel.org>, <krzk+dt@kernel.org>, <conor+dt@kernel.org>
Subject: Re: [PATCH 2/2] iio: dac: add support for Microchip MCP48FEB02
Date: Fri, 24 Apr 2026 08:01:17 +0000	[thread overview]
Message-ID: <f7f45b4327c9ce5c806cd878bd9b53e8fcbf7785.camel@microchip.com> (raw)
In-Reply-To: <20260215175857.4085bc2c@jic23-huawei>

Hi Jonathan,

> > +
> > +static int mcp48feb02_init_ctrl_regs(struct mcp48feb02_data *data)
> > +{
> > +     unsigned int i, vref_ch, gain_ch, pd_ch;
> > +     int ret;
> > +
> > +     ret = regmap_read(data->regmap, MCP48FEB02_VREF_REG_ADDR,
> > &vref_ch);
> > +     if (ret)
> > +             return ret;
> > +
> > +     ret = regmap_read(data->regmap,
> > MCP48FEB02_GAIN_CTRL_STATUS_REG_ADDR, &gain_ch);
> > +     if (ret)
> > +             return ret;
> > +
> > +     ret = regmap_read(data->regmap,
> > MCP48FEB02_POWER_DOWN_REG_ADDR, &pd_ch);
> > +     if (ret)
> > +             return ret;
> > +
> > +     gain_ch = gain_ch & MCP48FEB02_GAIN_BITS_MASK;
> > +     for_each_set_bit(i, &data->active_channels_mask, data-
> > >phys_channels) {
> > +             struct device *dev = regmap_get_device(data->regmap);
> > +             unsigned int pd_tmp;
> > +
> > +             data->chdata[i].ref_mode = (vref_ch >> (2 * i)) &
> > MCP48FEB02_DAC_CTRL_MASK;
> > +             data->chdata[i].use_2x_gain = (gain_ch >> i)  &
> > MCP48FEB02_GAIN_BIT_MASK;
> > +
> > +             /*
> > +              * Inform the user that the current voltage reference
> > read from the volatile
> > +              * register of the chip is different from the one
> > specified in the device tree.
> > +              * Considering that the user cannot have an external
> > voltage reference connected
> > +              * to the pin and select the internal Band Gap at the
> > same time, in order to avoid
> > +              * miscofiguring the reference voltage, the volatile
> > register will not be written.
> 
> Spell check comments.  misconfiguring
> 
> > +              * In order to overwrite the setting from volatile
> > register with the one from the
> > +              * device tree, the user needs to write the chosen
> > scale.
> 
> I'm a little unsure of why we need this extra gate on updating things
> to match
> the device tree provided config.  Why should the volatile register at
> this point
> match what DT says?  If it does seems to me we should be noisier
> about it than dev_dbg()
> 
> 
> > +              */
> > +             switch (data->chdata[i].ref_mode) {
> > +             case MCP48FEB02_INTERNAL_BAND_GAP:
> > +                     if (data->phys_channels >= 4 && (i % 2) &&
> > data->use_vref1) {
> > +                             dev_dbg(dev, "ch[%u]: was configured
> > to use internal band gap", i);
> > +                             dev_dbg(dev, "ch[%u]: reference
> > voltage set to VREF1", i);
> > +                             break;
> > +                     }
> > +                     if ((data->phys_channels < 4 || (data-
> > >phys_channels >= 4 && !(i % 2))) &&
> > +                         data->use_vref) {
> > +                             dev_dbg(dev, "ch[%u]: was configured
> > to use internal band gap", i);
> > +                             dev_dbg(dev, "ch[%u]: reference
> > voltage set to VREF", i);
> > +                             break;
> > +                     }
> 


The device restores its EEPROM configuration (or writes default values
for the part numbers without EEPROM) into the volatile registers at
startup, so during probe we may have a valid Vref/gain state that does
not match current DT. The driver should report any mismatch to the user
because the Vref/gain selection is changed only through the scale
attribute of each channel. The DT only describes available resources on
the board for determining the available scales.

I can update the messages to describe the behavior better and use
dev_info() instead of dev_dbg().

Best regards,
Ariana



  reply	other threads:[~2026-04-24  8:01 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-02-12 12:48 [PATCH 0/2] Add support for Microchip MCP48FxBy1/2/4/8 DAC with an SPI Interface Ariana Lazar
2026-02-12 12:48 ` [PATCH 1/2] dt-bindings: iio: dac: add support for Microchip MCP48FEB02 Ariana Lazar
2026-02-12 17:31   ` Rob Herring (Arm)
2026-02-12 18:00   ` Conor Dooley
2026-02-12 20:04     ` Andy Shevchenko
2026-02-16 13:31       ` Ariana.Lazar
2026-02-16 15:37         ` David Lechner
2026-02-16 17:34           ` Conor Dooley
2026-02-16 18:38             ` David Lechner
2026-02-12 12:48 ` [PATCH 2/2] " Ariana Lazar
2026-02-12 14:42   ` Andy Shevchenko
2026-02-16 14:29     ` Ariana.Lazar
2026-02-17  7:54       ` Andy Shevchenko
2026-02-17 11:38         ` Ariana.Lazar
2026-02-17 12:12           ` Andy Shevchenko
2026-02-15 17:58   ` Jonathan Cameron
2026-04-24  8:01     ` Ariana.Lazar [this message]
2026-04-24 10:19       ` Jonathan Cameron
2026-04-24 13:30         ` Ariana.Lazar
2026-04-24 16:48           ` Jonathan Cameron
2026-02-12 13:39 ` [PATCH 0/2] Add support for Microchip MCP48FxBy1/2/4/8 DAC with an SPI Interface Andy Shevchenko
2026-02-12 17:58   ` Conor Dooley

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=f7f45b4327c9ce5c806cd878bd9b53e8fcbf7785.camel@microchip.com \
    --to=ariana.lazar@microchip.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=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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox