All of lore.kernel.org
 help / color / mirror / Atom feed
From: Oleksij Rempel <o.rempel@pengutronix.de>
To: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Cc: devicetree@vger.kernel.org, Lars-Peter Clausen <lars@metafoo.de>,
	Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
	linux-iio@vger.kernel.org, linux-kernel@vger.kernel.org,
	Andy Shevchenko <andy.shevchenko@gmail.com>,
	Rob Herring <robh+dt@kernel.org>,
	kernel@pengutronix.de, Jonathan Cameron <jic23@kernel.org>
Subject: Re: [PATCH v3 2/3] iio: adc: tsc2046: add vref support
Date: Thu, 1 Sep 2022 13:53:20 +0200	[thread overview]
Message-ID: <20220901115320.GD2479@pengutronix.de> (raw)
In-Reply-To: <20220901124549.00002287@huawei.com>

On Thu, Sep 01, 2022 at 12:45:49PM +0100, Jonathan Cameron wrote:
> On Thu, 1 Sep 2022 06:11:45 +0200
> Oleksij Rempel <o.rempel@pengutronix.de> wrote:
> 
> > If VREF pin is attached, we should use external VREF source instead of
> > the internal. Otherwise we will get wrong measurements on some of channel
> > types.
> > 
> > Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de>
> Hi Oleksij,
> 
> I'm not sure why I didn't review this patch in v1...
> 
> Anyhow, some comments below.
> 
> Jonathan
> 
> > ---
> >  drivers/iio/adc/ti-tsc2046.c | 64 +++++++++++++++++++++++++++++++-----
> >  1 file changed, 55 insertions(+), 9 deletions(-)
> > 
> > diff --git a/drivers/iio/adc/ti-tsc2046.c b/drivers/iio/adc/ti-tsc2046.c
> > index 0d9436a69cbfb..bbc8b4137b0b1 100644
> > --- a/drivers/iio/adc/ti-tsc2046.c
> > +++ b/drivers/iio/adc/ti-tsc2046.c
> > @@ -8,6 +8,7 @@
> >  #include <linux/bitfield.h>
> >  #include <linux/delay.h>
> >  #include <linux/module.h>
> > +#include <linux/regulator/consumer.h>
> >  #include <linux/spi/spi.h>
> >  
> >  #include <asm/unaligned.h>
> > @@ -175,6 +176,9 @@ struct tsc2046_adc_priv {
> >  	u32 time_per_bit_ns;
> >  
> >  	struct tsc2046_adc_ch_cfg ch_cfg[TI_TSC2046_MAX_CHAN];
> > +	bool use_internal_vref;
> > +	unsigned int vref_mv;
> > +	struct regulator *vref_reg;
> >  };
> >  
> >  #define TI_TSC2046_V_CHAN(index, bits, name)			\
> > @@ -252,7 +256,9 @@ static u8 tsc2046_adc_get_cmd(struct tsc2046_adc_priv *priv, int ch_idx,
> >  	case TI_TSC2046_ADDR_AUX:
> >  	case TI_TSC2046_ADDR_VBAT:
> >  	case TI_TSC2046_ADDR_TEMP0:
> > -		pd |= TI_TSC2046_SER | TI_TSC2046_PD1_VREF_ON;
> > +		pd |= TI_TSC2046_SER;
> > +		if (priv->use_internal_vref)
> > +			pd |= TI_TSC2046_PD1_VREF_ON;
> >  	}
> >  
> >  	return TI_TSC2046_START | FIELD_PREP(TI_TSC2046_ADDR, ch_idx) | pd;
> > @@ -468,7 +474,7 @@ static int tsc2046_adc_read_raw(struct iio_dev *indio_dev,
> >  		 * So, it is better to use external voltage-divider driver
> >  		 * instead, which is calculating complete chain.
> >  		 */
> > -		*val = TI_TSC2046_INT_VREF;
> > +		*val = priv->vref_mv;
> >  		*val2 = chan->scan_type.realbits;
> >  		return IIO_VAL_FRACTIONAL_LOG2;
> >  	}
> > @@ -781,22 +787,42 @@ static int tsc2046_adc_probe(struct spi_device *spi)
> >  	indio_dev->num_channels = dcfg->num_channels;
> >  	indio_dev->info = &tsc2046_adc_info;
> >  
> > +	priv->vref_reg = devm_regulator_get_optional(&spi->dev, "vref");
> > +	if (!IS_ERR(priv->vref_reg)) {
> > +		ret = regulator_enable(priv->vref_reg);
> > +		if (ret)
> > +			return ret;
> > +
> > +		ret = regulator_get_voltage(priv->vref_reg);
> > +		if (ret < 0)
> > +			goto err_regulator_disable;
> 
> Whilst regulators voltages of references rarely change at runtime
> they are allowed to, so it is logically better to query the
> voltage at the point of use. Requests for scale should be
> rare (unless there is a consumer that keeps querying this?)
> so the slightly overhead there
> shouldn't matter.

The voltage scale is related to actual adc measurements. If it variates,
we will have different scale of challenges.

> > +
> > +		priv->vref_mv = ret / 1000;
> > +		priv->use_internal_vref = false;
> > +	} else {
> > +		/* Use internal reference */
> > +		priv->vref_mv = TI_TSC2046_INT_VREF;
> > +		priv->use_internal_vref = true;
> > +	}
> > +
> >  	tsc2046_adc_parse_fwnode(priv);
> >  
> >  	ret = tsc2046_adc_setup_spi_msg(priv);
> >  	if (ret)
> > -		return ret;
> > +		goto err_regulator_disable;
> >  
> >  	mutex_init(&priv->slock);
> >  
> >  	ret = devm_request_irq(dev, spi->irq, &tsc2046_adc_irq,
> >  			       IRQF_NO_AUTOEN, indio_dev->name, indio_dev);
> >  	if (ret)
> > -		return ret;
> > +		goto err_regulator_disable;
> >  
> >  	trig = devm_iio_trigger_alloc(dev, "touchscreen-%s", indio_dev->name);
> > -	if (!trig)
> > -		return -ENOMEM;
> > +	if (!trig) {
> > +		ret = -ENOMEM;
> > +		goto err_regulator_disable;
> > +	}
> >  
> >  	priv->trig = trig;
> >  	iio_trigger_set_drvdata(trig, indio_dev);
> > @@ -811,20 +837,39 @@ static int tsc2046_adc_probe(struct spi_device *spi)
> >  	ret = devm_iio_trigger_register(dev, trig);
> >  	if (ret) {
> >  		dev_err(dev, "failed to register trigger\n");
> > -		return ret;
> > +		goto err_regulator_disable;
> 
> Please don't mix devm and non devm calls. It makes it much harder to reason about
> the correctness of ordering.
> Use devm_add_action_or_reset() to register a callback to disable the
> vref regulator.
> 
> Alternative is back out the devm_ based registration of everything after
> the regulator enable.

ok.

Regards,
Oleksij
-- 
Pengutronix e.K.                           |                             |
Steuerwalder Str. 21                       | http://www.pengutronix.de/  |
31137 Hildesheim, Germany                  | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

  reply	other threads:[~2022-09-01 11:53 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-09-01  4:11 [PATCH v3 1/3] dt-bindings: iio: adc: ti,tsc2046: add vref-supply property Oleksij Rempel
2022-09-01  4:11 ` [PATCH v3 2/3] iio: adc: tsc2046: add vref support Oleksij Rempel
2022-09-01  8:24   ` Marco Felsch
2022-09-01 11:35     ` Oleksij Rempel
2022-09-01 11:45   ` Jonathan Cameron
2022-09-01 11:53     ` Oleksij Rempel [this message]
2022-09-01  4:11 ` [PATCH v3 3/3] iio: adc: tsc2046: silent spi_device_id warning Oleksij Rempel
2022-09-01 14:20   ` Andy Shevchenko

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=20220901115320.GD2479@pengutronix.de \
    --to=o.rempel@pengutronix.de \
    --cc=Jonathan.Cameron@huawei.com \
    --cc=andy.shevchenko@gmail.com \
    --cc=devicetree@vger.kernel.org \
    --cc=jic23@kernel.org \
    --cc=kernel@pengutronix.de \
    --cc=krzysztof.kozlowski+dt@linaro.org \
    --cc=lars@metafoo.de \
    --cc=linux-iio@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=robh+dt@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.