linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: mark.rutland@arm.com (Mark Rutland)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH V2] clk: palmas: add clock driver for palmas
Date: Tue, 8 Oct 2013 15:15:12 +0100	[thread overview]
Message-ID: <20131008141512.GE1412@e106331-lin.cambridge.arm.com> (raw)
In-Reply-To: <1381154751-4565-1-git-send-email-ldewangan@nvidia.com>

On Mon, Oct 07, 2013 at 03:05:51PM +0100, Laxman Dewangan wrote:
> Palmas devices has two clock output CLK32K_KG and CLK32K_KG_AUDIO
> which can be nebale/disable through software.
> 
> Add clock driver support for the Palmas 32k clocks.
> 
> Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com>
> ---
> Changes from V1:
> - Call prepare if the clk is needed for boot-enable or sleep control.
> - change is_enabled to is_prepared.
> - Added ops palmas_clks_recalc_rate.
> - Added of_clk_add_provider().
> 
>  .../devicetree/bindings/clock/clk-palmas.txt       |   45 +++
>  drivers/clk/Kconfig                                |    7 +
>  drivers/clk/Makefile                               |    2 +
>  drivers/clk/clk-palmas.c                           |  336 ++++++++++++++++++++
>  4 files changed, 390 insertions(+), 0 deletions(-)
>  create mode 100644 Documentation/devicetree/bindings/clock/clk-palmas.txt
>  create mode 100644 drivers/clk/clk-palmas.c
> 
> diff --git a/Documentation/devicetree/bindings/clock/clk-palmas.txt b/Documentation/devicetree/bindings/clock/clk-palmas.txt
> new file mode 100644
> index 0000000..c247538
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/clock/clk-palmas.txt
> @@ -0,0 +1,45 @@
> +* Palmas 32KHz clocks *
> +
> +Palmas device has two clock output pins for 32KHz, KG and KG_AUDIO.
> +
> +This binding uses the common clock binding ./clock-bindings.txt.
> +
> +Clock 32KHz KG is output 0 of the driver and clock 32KHz is output 1.
> +
> +Required properties:
> +- compatible : shall be "ti,palmas-clk".
> +- #clock-cells : from common clock binding; shall be set to 1.

It would make sense to describe the value values here, rather than
above.

> +
> +Optional subnode:
> +       The clock node has optional subnode to provide the init configuration of
> +       clocks like boot enable, sleep control.
> +
> +       The subnode name is fixed and it should be
> +               clk32k_kg for the 32KHz KG clock.
> +               clk32k_kg_audio for the 32KHz KG_AUDIO clock.
> +
> +       Optional subnode properties:
> +       ti,clock-boot-enable: Enable clock at the time of booting.

Why is this needed?

If drivers need clocks, they should request them. If they don't
currently, that's a bug in the driver.

> +       ti,external-sleep-control: The clock is enable/disabled by state
> +               of external enable input pins ENABLE, ENABLE2 and NSLEEP.
> +               The valid value for the external pins are:
> +                       1 for ENABLE1
> +                       2 for ENABLE2
> +                       3 for NSLEEP.
> +               Option 0 or missing this property means the clock is
> +               enabled/disabled via register access and these pins do
> +               not have any control.

What actually drives these pins to control the clock?

> +
> +Example:
> +       clock {
> +               compatible = "ti,palmas-clk";
> +               #clock-cells = <1>;
> +               clk32k_kg {
> +                       ti,clock-boot-enable;
> +                       ti,external-sleep-control = <3>;
> +               };
> +
> +               clk32k_kg_audio {
> +                       ti,clock-boot-enable;
> +               };
> +       };

How does the palmas-clk driver control these? No description of
registers, gpio, or any other component that could be used for control
is dfined.

Is the palmas-clk intended to be a subnode of the palmas mfd (the
palmas-rtc binding example suggests this)? It seems odd to describe
components of a device separately with no linkage between them.

I also note that the palmas MFD appears to be an I2C slave, but the
binding doesn't define that (which makes it somewhat confuding for
someone unfamiliar with the hardware).

Thanks,
Mark.

      parent reply	other threads:[~2013-10-08 14:15 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-10-07 14:05 [PATCH V2] clk: palmas: add clock driver for palmas Laxman Dewangan
2013-10-07 14:23 ` Laxman Dewangan
2013-10-08  1:02 ` Mike Turquette
2013-10-08 13:15   ` Laxman Dewangan
2013-10-08 14:15 ` Mark Rutland [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=20131008141512.GE1412@e106331-lin.cambridge.arm.com \
    --to=mark.rutland@arm.com \
    --cc=linux-arm-kernel@lists.infradead.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).