public inbox for devicetree@vger.kernel.org
 help / color / mirror / Atom feed
From: Jonathan Cameron <jic23@kernel.org>
To: David Lechner <dlechner@baylibre.com>
Cc: "Michael Hennerich" <Michael.Hennerich@analog.com>,
	"Nuno Sá" <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, devicetree@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH 4/4] iio: adc: ad7124: add clock output support
Date: Sun, 27 Jul 2025 13:29:16 +0100	[thread overview]
Message-ID: <20250727132916.609755f4@jic23-huawei> (raw)
In-Reply-To: <20250724-iio-adc-ad7124-proper-clock-support-v1-4-88f35db2fcaf@baylibre.com>

On Thu, 24 Jul 2025 18:25:25 -0500
David Lechner <dlechner@baylibre.com> wrote:

> Add support for the AD7124's internal clock output. If the #clock-cells
> property is present, turn on the internal clock output during probe.
> 
> If both the clocks and #clock-names properties are present (not allowed
> by devicetree bindings), assume that an external clock is being used so
> that we don't accidentally have two outputs fighting each other.
> 
> Signed-off-by: David Lechner <dlechner@baylibre.com>
> ---
> 
> We could make this fancier and only turn on the output on demand of a
> clock consumer, but then we have to deal with locking of the SPI bus
> to be able to write to the register. So I opted for the simpler
> solution of always turning it on during probe. This would only be used
> for synchronizing with other similar ADCs, so implementing the functions
> for a more general-purpose clock seems a bit overkill.
Seems reasonable.  One comment inline.
> ---
>  drivers/iio/adc/ad7124.c | 35 ++++++++++++++++++++++++++++++++---
>  1 file changed, 32 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/iio/adc/ad7124.c b/drivers/iio/adc/ad7124.c
> index b0b03f838eed730347a3afcd759be7c1a8ab201e..b18229ff037596c6e98e12dc22b1552bf13fdc4e 100644
> --- a/drivers/iio/adc/ad7124.c
> +++ b/drivers/iio/adc/ad7124.c
> @@ -7,6 +7,7 @@
>  #include <linux/bitfield.h>
>  #include <linux/bitops.h>
>  #include <linux/clk.h>
> +#include <linux/clk-provider.h>
>  #include <linux/delay.h>
>  #include <linux/device.h>
>  #include <linux/err.h>
> @@ -125,10 +126,12 @@ static const unsigned int ad7124_reg_size[] = {
>  	3, 3, 3, 3, 3
>  };
>  
> +#define AD7124_INT_CLK_HZ 614400
> +
>  static const int ad7124_master_clk_freq_hz[3] = {
> -	[AD7124_LOW_POWER] = 76800,
> -	[AD7124_MID_POWER] = 153600,
> -	[AD7124_FULL_POWER] = 614400,
> +	[AD7124_LOW_POWER] = AD7124_INT_CLK_HZ / 8,
> +	[AD7124_MID_POWER] = AD7124_INT_CLK_HZ / 4,
> +	[AD7124_FULL_POWER] = AD7124_INT_CLK_HZ,
>  };
>  
>  static const char * const ad7124_ref_names[] = {
> @@ -1163,6 +1166,32 @@ static int ad7124_setup(struct ad7124_state *st)
>  		}
>  
>  		clk_sel = AD7124_ADC_CONTROL_CLK_SEL_INT;
> +	} else if (!device_property_present(dev, "clocks") &&
> +		   device_property_present(dev, "clock-names")) {
> +		struct clk_hw *clk_hw;
> +		char *name;
> +
> +		name = devm_kasprintf(dev, GFP_KERNEL, "%s-clk",
> +				      fwnode_get_name(dev_fwnode(dev)));

I think for anything that isn't const the clock core will copy the name
during registration.  Ultimately __clk_register()
https://elixir.bootlin.com/linux/v6.15.8/source/drivers/clk/clk.c#L4342

As such tying this to devm lifespans is excessive.  Should be fine
using a __free(kfree) to clean it up at the end of this scope.

> +		if (!name)
> +			return -ENOMEM;
> +
> +		clk_hw = devm_clk_hw_register_fixed_rate(dev, name, NULL, 0,
> +							 AD7124_INT_CLK_HZ);
> +		if (IS_ERR(clk_hw))
> +			return dev_err_probe(dev, PTR_ERR(clk_hw), "Failed to register clock provider\n");
> +
> +		ret = devm_of_clk_add_hw_provider(dev, of_clk_hw_simple_get,
> +						  clk_hw);
> +		if (ret)
> +			return dev_err_probe(dev, ret, "Failed to add clock provider\n");
> +
> +		/*
> +		 * Treat the clock as always on. This way we don't have to deal
> +		 * with someone trying to enable/disable the clock while we are
> +		 * reading samples.
> +		 */
> +		clk_sel = AD7124_ADC_CONTROL_CLK_SEL_INT_OUT;
>  	} else {
>  		struct clk *clk;
>  
> 


      reply	other threads:[~2025-07-27 12:29 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-07-24 23:25 [PATCH 0/4] iio: adc: ad7124: proper clock support David Lechner
2025-07-24 23:25 ` [PATCH 1/4] dt-bindings: iio: adc: adi,ad7124: fix clocks properties David Lechner
2025-07-25 23:27   ` Rob Herring (Arm)
2025-07-24 23:25 ` [PATCH 2/4] iio: adc: ad7124: do not require mclk David Lechner
2025-07-27 12:21   ` Jonathan Cameron
2025-07-29 16:08     ` David Lechner
2025-07-29 18:42       ` Jonathan Cameron
2025-07-24 23:25 ` [PATCH 3/4] iio: adc: ad7124: add external clock support David Lechner
2025-07-27 12:24   ` Jonathan Cameron
2025-07-24 23:25 ` [PATCH 4/4] iio: adc: ad7124: add clock output support David Lechner
2025-07-27 12:29   ` 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=20250727132916.609755f4@jic23-huawei \
    --to=jic23@kernel.org \
    --cc=Michael.Hennerich@analog.com \
    --cc=andy@kernel.org \
    --cc=conor+dt@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=dlechner@baylibre.com \
    --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