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: Thu, 22 Aug 2013 01:12:56 -0700	[thread overview]
Message-ID: <20130822081256.8231.50781@quantum> (raw)
In-Reply-To: <5214BDB1.9080503@ti.com>

Quoting Santosh Shilimkar (2013-08-21 06:16:33)
> On Tuesday 20 August 2013 10:22 PM, Mike Turquette wrote:
> > 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.
> > 
> The module(I assume you mean IP here) reg address space is separate than
> that used for clock control so that doesn't fit as such. Traditionally
> clock controls even though targeted for specific modules sits in different
> control as at least seen on OMAP and Keystone. OCP wrappers on OMAP
> were bit of exceptions but they were little bit of glue logic without
> much control within the address space.

Great, you perfectly answered my questions. I think that assigning the
"final" address to the 'reg' property is the right way to go (fixed
address + LPSC index).

Regards,
Mike

> 
> >> 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 ;-)
> > 
> You asked right and good questions.
> 
> Regards,
> Santosh

  reply	other threads:[~2013-08-22  8:12 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
2013-08-21 13:16                       ` Santosh Shilimkar
2013-08-22  8:12                         ` Mike Turquette [this message]
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=20130822081256.8231.50781@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).