From: santosh.shilimkar@ti•com (Santosh Shilimkar)
To: linux-arm-kernel@lists•infradead.org
Subject: [PATCH 2/8] clk: keystone: Add gate control clock driver
Date: Thu, 22 Aug 2013 10:10:14 -0400 [thread overview]
Message-ID: <52161BC6.1050905@ti.com> (raw)
In-Reply-To: <20130822081256.8231.50781@quantum>
On Thursday 22 August 2013 04:12 AM, Mike Turquette wrote:
> 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).
>
Thanks Mike.
Regards,
Santosh
next prev parent reply other threads:[~2013-08-22 14:10 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
2013-08-22 14:10 ` Santosh Shilimkar [this message]
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=52161BC6.1050905@ti.com \
--to=santosh.shilimkar@ti$(echo .)com \
--cc=linux-arm-kernel@lists$(echo .)infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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