All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jonathan Cameron <Jonathan.Cameron@huawei.com>
To: Cosmin Tanislav <demonsingur@gmail.com>
Cc: Jonathan Cameron <jic23@kernel.org>,
	Rob Herring <robh+dt@kernel.org>,
	Linus Walleij <linus.walleij@linaro.org>,
	<linux-iio@vger.kernel.org>, <linux-gpio@vger.kernel.org>,
	<linux-kernel@vger.kernel.org>, <devicetree@vger.kernel.org>,
	Cosmin Tanislav <cosmin.tanislav@analog.com>,
	Andy Shevchenko <andy.shevchenko@gmail.com>
Subject: Re: [PATCH v9 2/2] iio: adc: ad4130: add AD4130 driver
Date: Thu, 20 Oct 2022 18:07:43 +0100	[thread overview]
Message-ID: <20221020180743.00000416@huawei.com> (raw)
In-Reply-To: <3c4c9d0d-a542-bd54-a8d0-589bb4e6ea49@gmail.com>

On Mon, 17 Oct 2022 10:08:10 +0300
Cosmin Tanislav <demonsingur@gmail.com> wrote:

> On 10/9/22 20:31, Jonathan Cameron wrote:
> > On Thu,  6 Oct 2022 17:07:37 +0300
> > Cosmin Tanislav <demonsingur@gmail.com> wrote:
> >   
> >> AD4130-8 is an ultra-low power, high precision, measurement solution for
> >> low bandwidth battery operated applications.
> >>
> >> The fully integrated AFE (Analog Front-End) includes a multiplexer for up
> >> to 16 single-ended or 8 differential inputs, PGA (Programmable Gain
> >> Amplifier), 24-bit Sigma-Delta ADC, on-chip reference and oscillator,
> >> selectable filter options, smart sequencer, sensor biasing and excitation
> >> options, diagnostics, and a FIFO buffer.
> >>
> >> Signed-off-by: Cosmin Tanislav <cosmin.tanislav@analog.com>
> >> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>  
> > Hi Cosmin,
> > 
> > I've cropped down (mostly) to the clock changes.
> > A few minor things in there + this looks like it would suffer from the issue
> > with IIO_CONST_ATTR() not being handled correctly for buffer attributes.
> > 
> > Jonathan
> > 
> > 
> >   
> >> +static IIO_CONST_ATTR(hwfifo_watermark_min, "1");
> >> +static IIO_CONST_ATTR(hwfifo_watermark_max, __stringify(AD4130_FIFO_SIZE));  
> > 
> > These look like they'd suffer from same problem
> > https://lore.kernel.org/all/cover.1664782676.git.mazziesaccount@gmail.com/
> > tackles.  Short term fix is don't use IIO_CONST_ATTR for buffer attributes.
> >   
> 
> Right, this only works downstream.
> 
> Should I switch to IIO_STATIC_CONST_DEVICE_ATTR?

Depends a bit on timing. For now I'd just put a hand coded equivalent here similar
to the patches I've queue in fixes-togreg.  Then we can roll this over
to IIO_STATIC_CONST_DEVICE_ATTR once that code lands.

> 
> >   
> >> +static IIO_DEVICE_ATTR_RO(hwfifo_watermark, 0);
> >> +static IIO_DEVICE_ATTR_RO(hwfifo_enabled, 0);
> >> +
> >> +static const struct attribute *ad4130_fifo_attributes[] = {
> >> +	&iio_const_attr_hwfifo_watermark_min.dev_attr.attr,
> >> +	&iio_const_attr_hwfifo_watermark_max.dev_attr.attr,
> >> +	&iio_dev_attr_hwfifo_watermark.dev_attr.attr,
> >> +	&iio_dev_attr_hwfifo_enabled.dev_attr.attr,
> >> +	NULL
> >> +};  
> > 
> >   
> >> +static void ad4130_clk_disable_unprepare(void *clk)
> >> +{
> >> +	clk_disable_unprepare(clk);
> >> +}
> >> +
> >> +static int ad4130_set_mclk_sel(struct ad4130_state *st,
> >> +			       enum ad4130_mclk_sel mclk_sel)
> >> +{
> >> +	return regmap_update_bits(st->regmap, AD4130_ADC_CONTROL_REG,
> >> +				 AD4130_ADC_CONTROL_MCLK_SEL_MASK,
> >> +				 FIELD_PREP(AD4130_ADC_CONTROL_MCLK_SEL_MASK,
> >> +					    mclk_sel));
> >> +}
> >> +
> >> +static unsigned long ad4130_int_clk_recalc_rate(struct clk_hw *hw,
> >> +						unsigned long parent_rate)
> >> +{
> >> +	return AD4130_MCLK_FREQ_76_8KHZ;
> >> +}
> >> +
> >> +static int ad4130_int_clk_is_enabled(struct clk_hw *hw)
> >> +{
> >> +	struct ad4130_state *st = container_of(hw, struct ad4130_state, int_clk_hw);
> >> +
> >> +	return st->mclk_sel == AD4130_MCLK_76_8KHZ_OUT;
> >> +}
> >> +
> >> +static int ad4130_int_clk_prepare(struct clk_hw *hw)
> >> +{
> >> +	struct ad4130_state *st = container_of(hw, struct ad4130_state, int_clk_hw);
> >> +	int ret;
> >> +
> >> +	ret = ad4130_set_mclk_sel(st, AD4130_MCLK_76_8KHZ_OUT);
> >> +	if (ret)
> >> +		return ret;
> >> +
> >> +	st->mclk_sel = AD4130_MCLK_76_8KHZ_OUT;
> >> +
> >> +	return 0;
> >> +}
> >> +
> >> +static void ad4130_int_clk_unprepare(struct clk_hw *hw)
> >> +{
> >> +	struct ad4130_state *st = container_of(hw, struct ad4130_state, int_clk_hw);
> >> +	int ret;
> >> +
> >> +	ret = ad4130_set_mclk_sel(st, AD4130_MCLK_76_8KHZ);
> >> +	if (ret)
> >> +		return;
> >> +
> >> +	st->mclk_sel = AD4130_MCLK_76_8KHZ;
> >> +}
> >> +
> >> +static const struct clk_ops ad4130_int_clk_ops = {
> >> +	.recalc_rate = ad4130_int_clk_recalc_rate,
> >> +	.is_enabled = ad4130_int_clk_is_enabled,
> >> +	.prepare = ad4130_int_clk_prepare,
> >> +	.unprepare = ad4130_int_clk_unprepare,
> >> +};
> >> +
> >> +static int ad4130_setup_int_clk(struct ad4130_state *st)
> >> +{
> >> +	struct device *dev = &st->spi->dev;
> >> +	struct device_node *of_node = dev->of_node;  
> > 
> > Hmm. There goes our careful use of generic firmware properties.
> > I guess there still isn't much we can do about that for clks
> > so at least it's contained to this one function.
> > 
> > Also is this code safe to of_node == NULL?
> >   
> 
> No, I guess it is not. I'll fix it.
> Should I just
> if (!of_node) return 0;
> ?

Good question.  I guess we are fine just not having the output clock
on ACPI platforms.  Maybe this is worth a dev_info message
to say we are carrying on without them?

> 
> >> +	struct clk_init_data init;
> >> +	const char *clk_name;
> >> +	struct clk *clk;
> >> +
> >> +	if (st->int_pin_sel == AD4130_INT_PIN_CLK ||
> >> +	    st->mclk_sel != AD4130_MCLK_76_8KHZ)
> >> +		return 0;
> >> +
> >> +	clk_name = of_node->name;
> >> +	of_property_read_string(of_node, "clock-output-names", &clk_name);  
> > 
> > Probably want to check success of that read before using it.
> > I'd also expect that these to be optional + doesn't he dt binding need
> > updating to add this stuff?
> >   
> 
> It does need updating, sorry.
> of_node->name is the default clk_name, if clock-output-names is present
> then the of_property_read_string() result will be used instead. If not,
> there's no trouble, and we don't care about the return value since we
> have the default clk_name assigned just above.
> I can also switch to device_property_read_string() here to minimize the
> damage from using OF.

Sounds good to me.

Jonathan

> 
> >   
> >> +
> >> +	init.name = clk_name;
> >> +	init.ops = &ad4130_int_clk_ops;
> >> +
> >> +	st->int_clk_hw.init = &init;
> >> +	clk = devm_clk_register(dev, &st->int_clk_hw);
> >> +	if (IS_ERR(clk))
> >> +		return PTR_ERR(clk);
> >> +
> >> +	return of_clk_add_provider(of_node, of_clk_src_simple_get, clk);
> >> +}
> >> +  


      reply	other threads:[~2022-10-20 17:07 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-10-06 14:07 [PATCH v9 0/2] AD4130 Cosmin Tanislav
2022-10-06 14:07 ` [PATCH v9 1/2] dt-bindings: iio: adc: add AD4130 Cosmin Tanislav
2022-10-06 14:07 ` [PATCH v9 2/2] iio: adc: ad4130: add AD4130 driver Cosmin Tanislav
2022-10-07  2:45   ` kernel test robot
2022-10-08 13:01   ` kernel test robot
2022-10-09 17:31   ` Jonathan Cameron
2022-10-17  7:08     ` Cosmin Tanislav
2022-10-20 17:07       ` Jonathan Cameron [this message]

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=20221020180743.00000416@huawei.com \
    --to=jonathan.cameron@huawei.com \
    --cc=andy.shevchenko@gmail.com \
    --cc=cosmin.tanislav@analog.com \
    --cc=demonsingur@gmail.com \
    --cc=devicetree@vger.kernel.org \
    --cc=jic23@kernel.org \
    --cc=linus.walleij@linaro.org \
    --cc=linux-gpio@vger.kernel.org \
    --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.