devicetree.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Tony Lindgren <tony@atomide.com>
To: Stephen Boyd <sboyd@codeaurora.org>
Cc: Tero Kristo <t-kristo@ti.com>,
	Michael Turquette <mturquette@baylibre.com>,
	devicetree@vger.kernel.org, linux-clk@vger.kernel.org,
	linux-omap@vger.kernel.org, Paul Walmsley <paul@pwsan.com>
Subject: Re: [PATCHv3] Documentation: dt-bindings: Add binding documentation for TI clkctrl clocks
Date: Wed, 19 Apr 2017 10:02:48 -0700	[thread overview]
Message-ID: <20170419170246.GA19537@atomide.com> (raw)
In-Reply-To: <20170419165522.GL7065@codeaurora.org>

* Stephen Boyd <sboyd@codeaurora.org> [170419 09:58]:
> On 02/13, Tero Kristo wrote:
> > On 24/01/17 00:17, 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 = <2> property.
> > >
> > >The reasons for using #clock-cells = <2> 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
> > >
> > >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>
> > >Acked-by: Rob Herring <robh@kernel.org>
> > >Signed-off-by: Tony Lindgren <tony@atomide.com>
> > 
> > This binding works for me, so:
> > 
> > Acked-by: Tero Kristo <t-kristo@ti.com>
> > 
> 
> This wasn't in the TI clk PR. Shall I merge this to clk-next?

Tero has this included in his clkctrl series and there's one typo
fix needed where the doc still says #clock-cells = <4> instead of <2>.

I suggest let's wait a bit on this and let's try to get the clkctrl
driver parts into next early after v4.12-rc1 if no issues.

It seems the clkctrl series clock driver part is pretty much
ready to go, the remaining issues seem to be in the hwmod code.

Regards,

Tony

  reply	other threads:[~2017-04-19 17:02 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-01-23 22:17 [PATCHv3] Documentation: dt-bindings: Add binding documentation for TI clkctrl clocks Tony Lindgren
2017-02-13 15:19 ` Tero Kristo
2017-04-19 16:55   ` Stephen Boyd
2017-04-19 17:02     ` Tony Lindgren [this message]
     [not found]       ` <20170419170246.GA19537-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org>
2017-04-19 17:16         ` Stephen Boyd

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=20170419170246.GA19537@atomide.com \
    --to=tony@atomide.com \
    --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 \
    /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).