From: grygorii.strashko@ti•com (Grygorii Strashko)
To: linux-arm-kernel@lists•infradead.org
Subject: Common clock: function clock and bus clock
Date: Wed, 12 Mar 2014 12:14:03 +0200 [thread overview]
Message-ID: <5320336B.3020107@ti.com> (raw)
In-Reply-To: <CADApbegGTm=REJbukdyEY9ZVK9hXax+Hodp7MFx3SUb=CV1TbA@mail.gmail.com>
On 03/12/2014 04:30 AM, Chao Xie wrote:
> On Tue, Mar 11, 2014 at 10:48 AM, Haojian Zhuang
> <haojian.zhuang@gmail•com> wrote:
>> On Tue, Mar 11, 2014 at 10:06 AM, Chao Xie <xiechao.mail@gmail•com> wrote:
>>> hi
>>>
>>> I can not find any examples for handling function clock and bus clock
>>> in drivers/clk/.
>>>
>>> For a device, it will have a function clock and bus clock. function
>>> clock will control the fucntionality of this device, while bus clock
>>> will control the communication part to the bus.
>>>
>>> For some SOCes, they do not export bus clock, so from the hardware it
>>> seems that function clock is combined with bus clock, while for some
>>> SOCes, they are not.
>>>
>>> For most of the device driver, they will enable/disable function clock
>>> and bus clock both. While for some devices, they may share bus clock,
>>> and have different function clocks.
>>>
>>> In fact, i want to define the APIs as below:
>>>
>>> struct clk* soc_register_bus_clock(struct device *dev, char **parent_name, ...);
>>> This function will create and register bus clock
>>>
>>> struct clk* soc_register_fucntion_clock(struct device *dev, char
>>> **parent_name, ...);
>>> This function will create and register function clock
>>>
>>> struct clk* soc_register_clk(struct device *dev, char **parent_name);
>>> This function will create and register a device clock. Then this clock
>>> is enable, it will enable bus clock and function clock both, and it is
>>> similar for disabling.
>>>
>>> struct clk* soc_register_composite_clk(struct device *dev, char
>>> *bus_clk_name, char *function_clk_name);
>>> This function will create and register a composite device clock. When
>>> enable this clock, it will invoke clk_enable(bus_clk) and
>>> clk_enable(function_clk) both. It is similar for disabling.
>>>
>>> So for the device which has its own control register and bits for
>>> function clock and bus clock. We can call soc_register_clk.
>>> For the device share bus clock with other devices, we create the clock
>>> for the device by calling soc_register_composite_clk.
>>>
>>> 1. Now clk_enable can be preempted by same caller.
>>> 2. For above devices, the bus clock only have enable/disable ops.
>>>
>>> Based on above conditions, I think soc_register_composite_clk is fine.
>>>
>>> Does anyone have same problems? Will above proposal break common clock rules.
>>
>> I think it's too complex.
>>
>> If the bus clock and function clock is only used for gating, maybe you
>> can set the bus clock as parent of function clock.
>>
> You can not do it. Because the function clock may have mux and div, it
> can not depends on bus clock's rate.
>
>> If both of them are complex, why not define two clocks in your device driver?
>>
> It is the problem. In fact for different SOCes, we can not know which
> device will have such limitation.
> Even for same device, for SOC-a, it has the limitation, for SOC-b, it does not.
> So the choice is make all the device drivers to grap two clocks. There
> are too many of them, and for
> the devices does not have such limitation, it is redundant.
> So the point is we donot want to change the device driver, and we want
> to make the device driver interfaces
> maintain unchanged. .
Clk pm domain - Is it what you want?
drivers/base/power/clock_ops.c
Usage example:
arch/arm/mach-davinci/pm_domain.c
arch/arm/mach-keystone/pm_domain.c
Then you can simply use Runtime PM API to control clocks.
Regrads,
-grygorii
next prev parent reply other threads:[~2014-03-12 10:14 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-03-11 2:06 Common clock: function clock and bus clock Chao Xie
2014-03-11 2:48 ` Haojian Zhuang
2014-03-12 2:30 ` Chao Xie
2014-03-12 10:14 ` Grygorii Strashko [this message]
2014-03-13 2:15 ` Chao Xie
2014-03-13 3:16 ` Emilio López
2014-03-13 11:30 ` Grygorii Strashko
[not found] ` <20140319210428.31449.19420@quantum>
[not found] ` <CAPDyKFqg230Ob5Wxu0tvXqia+B3WG5+YdKTdxTQ0ySbZokb+7Q@mail.gmail.com>
2014-03-20 10:30 ` Grygorii Strashko
2014-03-20 11:42 ` Russell King - ARM Linux
2014-03-20 9:45 ` Ben Dooks
2014-03-20 11:35 ` Russell King - ARM Linux
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=5320336B.3020107@ti.com \
--to=grygorii.strashko@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