linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: mturquette@linaro.org (Mike Turquette)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 2/8] clk: keystone: Add gate control clock driver
Date: Tue, 20 Aug 2013 19:22:25 -0700	[thread overview]
Message-ID: <20130821022225.4443.97467@quantum> (raw)
In-Reply-To: <5213F397.6020708@ti.com>

Quoting Santosh Shilimkar (2013-08-20 15:54:15)
> On Tuesday 20 August 2013 06:41 PM, Mike Turquette wrote:
> > Quoting Santosh Shilimkar (2013-08-20 14:55:56)
> >> On Tuesday 20 August 2013 05:30 PM, Mike Turquette wrote:
> 
> [...]
> 
> >>>> They are bit different w.r.t OMAP. LPSC itself is the clock control of the
> >>>> IP. The LPSC number in the bindings is actually the specific number which
> >>>> is used to reach to the address space of the clock control. One can view
> >>>> that one as clock control register index.
> >>>
> >>> Thanks for the information. I have a further question about then: are
> >>> the LPSC clocks really module clocks that belong to the IP that they are
> >>> gating?
> >>>
> >> LPSC controls the clock enable/disable to the IP/module so answer is yes.
> >> In certain cases LPSC controls clock to more than one IP as well.
> >>
> >>> If so then they could be defined within the node defining their parent
> >>> IP. That might be enough to get rid of the LPSC index value. Again I
> >>> might be over-engineering it. Just trying to get an understanding.
> >>>
> >> Am not sure I follow you here on not having the LPSC index. Sorry. 
> > 
> > How are the 'reg' property and the 'lpsc' property related? Does the
> > lpsc property modify the register address used to access the clock
> > control bits?
> > 
> Yes it does. Currently all nodes use fix address and then lpsc is
> used as an index.

Ok cool. Well the reason I brought that up was because I even had the
idea to define these module clocks within the module nodes that own them
in DT. I am way outside of my DT knowledge at this point but I wonder
if the following type of binding is possible:

module: module at 4a308200 {
	#address-cells = <1>;
	#size-cells = <1>;
	reg = <0x4a308200 0x1000>;

	clock {
		#clock-cells = <0>;
		compatible = "keystone,psc-clk";
		clocks = <&chipclk3>;
		clock-output-names = "debugss_trc";
		reg = <0x0256>;
		pd = <1>;
	};
};

Again, my DT knowledge is pretty limited, but could the reg property of
the clock be directly affected by the parent node? That seems like it
could nicely model what the hardware is really doing.

> But I think we can do better by just using the
> right(offset) address in the reg property. Will have a look at it
> and see what I can do here.

This also solves the problem nicely.  Thanks for putting up with my
silly questions ;-)

Regards,
Mike

> 
> Thanks for asking this questions Mike 
> 
> regards,
> Santosh

  reply	other threads:[~2013-08-21  2:22 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-08-05 16:12 [PATCH 0/8] clk: keystone: Add common clock drivers and PM bus Santosh Shilimkar
2013-08-05 16:12 ` [PATCH 1/8] clk: keystone: add Keystone PLL clock driver Santosh Shilimkar
2013-08-13 15:48   ` Mark Rutland
2013-08-13 16:01     ` Santosh Shilimkar
2013-08-13 16:47       ` Mark Rutland
2013-08-13 16:58         ` Santosh Shilimkar
2013-08-19 17:42           ` Santosh Shilimkar
2013-08-19 20:33             ` Mike Turquette
2013-08-20 13:41               ` Santosh Shilimkar
2013-08-20 21:23                 ` Mike Turquette
2013-08-20 21:46                   ` Santosh Shilimkar
2013-08-05 16:12 ` [PATCH 2/8] clk: keystone: Add gate control " Santosh Shilimkar
2013-08-13 16:13   ` Mark Rutland
2013-08-13 16:36     ` Santosh Shilimkar
2013-08-13 16:53       ` Mark Rutland
2013-08-19 20:43         ` Mike Turquette
2013-08-20 13:55           ` Santosh Shilimkar
2013-08-20 21:30             ` Mike Turquette
2013-08-20 21:55               ` Santosh Shilimkar
2013-08-20 22:41                 ` Mike Turquette
2013-08-20 22:54                   ` Santosh Shilimkar
2013-08-21  2:22                     ` Mike Turquette [this message]
2013-08-21 13:16                       ` Santosh Shilimkar
2013-08-22  8:12                         ` Mike Turquette
2013-08-22 14:10                           ` Santosh Shilimkar
2013-08-05 16:12 ` [PATCH 3/8] clk: keystone: common clk driver initialization Santosh Shilimkar
2013-08-05 18:54   ` Nishanth Menon
2013-08-05 19:27     ` Santosh Shilimkar
2013-08-05 16:12 ` [PATCH 4/8] clk: keystone: Build Keystone clock drivers Santosh Shilimkar
2013-08-05 16:12 ` [PATCH 5/8] ARM: dts: keystone: Add clock tree data to devicetree Santosh Shilimkar
2013-08-05 16:12 ` [PATCH 6/8] ARM: dts: keystone: Add clock phandle to UART nodes Santosh Shilimkar
2013-08-05 16:12 ` [PATCH 7/8] ARM: keystone: Enable and initialise clock drivers Santosh Shilimkar
2013-08-05 16:12 ` [PATCH 8/8] ARM: keystone: add PM bus support for clock management Santosh Shilimkar

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=20130821022225.4443.97467@quantum \
    --to=mturquette@linaro.org \
    --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).