All of lore.kernel.org
 help / color / mirror / Atom feed
From: Rob Herring <robh@kernel.org>
To: Tony Lindgren <tony@atomide.com>
Cc: Michael Turquette <mturquette@baylibre.com>,
	Stephen Boyd <sboyd@codeaurora.org>,
	Tero Kristo <t-kristo@ti.com>,
	devicetree@vger.kernel.org, linux-clk@vger.kernel.org,
	linux-omap@vger.kernel.org, Paul Walmsley <paul@pwsan.com>
Subject: Re: [PATCHv2] Documentation: dt-bindings: Add binding documentation for TI clkctrl clocks
Date: Thu, 19 Jan 2017 13:28:13 -0600	[thread overview]
Message-ID: <20170119192813.xdt5jahffcdzmucu@rob-hp-laptop> (raw)
In-Reply-To: <20170117225302.10844-1-tony@atomide.com>

On Tue, Jan 17, 2017 at 02:53:02PM -0800, Tony Lindgren wrote:
> Texas Instruments omap variant SoCs starting with omap4 have a clkctrl
> clock controller instance for each interconnect target module. The clkctrl
> controls functional and interface clocks for the module.
> 
> The clkctrl clocks are currently handled by arch/arm/mach-omap2 hwmod code.
> With this binding and a related clock device driver we can start moving the
> clkctrl clock handling to live in drivers/clk/ti.
> 
> Note that this binding allows keeping the clockdomain related parts out of
> drivers/clock. The CLKCTCTRL and DYNAMICDEP registers can be handled by
> a separate driver in drivers/soc/ti and genpd. If the clockdomain driver
> needs to know it's clocks, we can just set the the clkctrl device
> instances to be children of the related clockdomain device.
> 
> Each clkctrl clock can have multiple optional gate clocks, and multiple
> optional mux clocks. To represent this in device tree, it seems that
> it is best done using four clock cells #clock-cells = <4> property.
> 
> The reasons for using #clock-cells = <4> are:
> 
> 1. We need to specify the clkctrl offset from the instance base. Otherwise
>    we end up with a large number of device tree nodes that need to be
>    patched when new clocks are discovered in a clkctrl clock with minor
>    hardware revision changes for example
> 
> 2. On omap5 CM_L3INIT_USB_HOST_HS_CLKCTRL has ten OPTFCLKEN bits. So we
>    need to use a separate cell for optional gate clocks to avoid address
>    space conflicts
> 
> 3. Some clkctrl instances can also also optional mux clocks. To address
>    them properly we need also a separate cell for the optional mux
>    clock index
> 
> 4. The modulemode clock needs a flag passed to it for hardware or
>    software controlled mode
> 
> There is probably no need to list input clocks for each clkctrl clock
> instance in the binding. If we want to add them, the standard clocks
> binding can be used for that.
> 
> For hardware reference, see omap4430 TRM "Table 3-1312. L4PER_CM2 Registers
> Mapping Summary" for example. It shows one instance of a clkctrl clock
> controller with multiple clkctrl registers.
> 
> Cc: Paul Walmsley <paul@pwsan.com>
> Cc: Rob Herring <robh@kernel.org>
> Signed-off-by: Tony Lindgren <tony@atomide.com>
> ---
> 
> Changes from v1:
> 
> - Use #clock-cells to avoid address space conflicts
> 
> - Consider also optional mux clocks as pointed out by Tero
> 
> ---
>  .../devicetree/bindings/clock/ti-clkctrl.txt       | 57 ++++++++++++++++++++++
>  1 file changed, 57 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/clock/ti-clkctrl.txt

Acked-by: Rob Herring <robh@kernel.org>


  reply	other threads:[~2017-01-19 19:28 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-01-17 22:53 [PATCHv2] Documentation: dt-bindings: Add binding documentation for TI clkctrl clocks Tony Lindgren
2017-01-19 19:28 ` Rob Herring [this message]
     [not found] ` <20170117225302.10844-1-tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org>
2017-01-23 14:43   ` Tero Kristo
2017-01-23 14:43     ` Tero Kristo
2017-01-23 16:28     ` Tony Lindgren
     [not found]       ` <20170123162828.GR7403-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org>
2017-01-23 18:29         ` Tero Kristo
2017-01-23 18:29           ` Tero Kristo
     [not found]           ` <f3c4154d-09d0-3930-4452-1f7d61622f3d-l0cyMroinI0@public.gmane.org>
2017-01-23 18:38             ` Tony Lindgren
2017-01-23 18:38               ` Tony Lindgren

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=20170119192813.xdt5jahffcdzmucu@rob-hp-laptop \
    --to=robh@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=linux-clk@vger.kernel.org \
    --cc=linux-omap@vger.kernel.org \
    --cc=mturquette@baylibre.com \
    --cc=paul@pwsan.com \
    --cc=sboyd@codeaurora.org \
    --cc=t-kristo@ti.com \
    --cc=tony@atomide.com \
    /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.