linux-gpio.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Cosmin Tanislav <demonsingur@gmail.com>
To: Jonathan Cameron <jic23@kernel.org>
Cc: 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: Mon, 17 Oct 2022 10:08:10 +0300	[thread overview]
Message-ID: <3c4c9d0d-a542-bd54-a8d0-589bb4e6ea49@gmail.com> (raw)
In-Reply-To: <20221009183122.0de740e0@jic23-huawei>



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?

> 
>> +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;
?

>> +	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.

> 
>> +
>> +	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-17  7:08 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 [this message]
2022-10-20 17:07       ` Jonathan Cameron

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=3c4c9d0d-a542-bd54-a8d0-589bb4e6ea49@gmail.com \
    --to=demonsingur@gmail.com \
    --cc=andy.shevchenko@gmail.com \
    --cc=cosmin.tanislav@analog.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).