Common clock: function clock and bus clock

[Grygorii Strashko]

On 03/20/2014 10:25 AM, Ulf Hansson wrote:
> On 19 March 2014 22:04, Mike Turquette <mturquette at linaro.org> wrote:
>> Quoting Grygorii Strashko (2014-03-13 04:30:43)
>>> On 03/13/2014 05:16 AM, Emilio López wrote:
>>>> Hi,
>>>>
>>>> El mié 12 mar 2014 23:15:20 ART, Chao Xie escribió:
>>>>> On Wed, Mar 12, 2014 at 6:14 PM, Grygorii Strashko
>>>>> <grygorii.strashko at ti.com> wrote:
>>>>>> On 03/12/2014 04:30 AM, Chao Xie wrote:
>>>>>>>
>>>>>>> On Tue, Mar 11, 2014 at 10:48 AM, Haojian Zhuang
>>>>>>> <haojian.zhuang at gmail.com> wrote:
>>>>>>>>
>>>>>>>> On Tue, Mar 11, 2014 at 10:06 AM, Chao Xie <xiechao.mail at 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.
>>>>
>>>> You can define two normal clocks and use them like this
>>>>
>>>> * If a device has both bus and module
>>>>
>>>> clocks = <&abc ...>, <&xyz ...>;
>>>> clock-names = "bus", "module";
>>>>
>>>> * If a device only has module clock
>>>>
>>>> clocks = <&xyz ...>;
>>>> clock-names = "module";
>>>>
>>>> Then on the driver to control this specific hardware you can do
>>>> something like
>>>>
>>>> /* mandatory module clock */
>>>> mod = devm_clk_get(dev, "module");
>>>> if (!IS_ERR(mod))
>>>>       clk_prepare_enable(mod)
>>>> else
>>>>       goto fail;
>>>>
>>>> /* optional bus clock */
>>>> bus = devm_clk_get(dev, "bus");
>>>> if (!IS_ERR(bus))
>>>>       clk_prepare_enable(bus)
>>>>
> 
> This won't work for a cross SOC driver, since in one cases it should
> be optional, but in the other mandatory.
> 
> I suggest you point the "bus" clock to the same clock clock as the
> "module" for those SOCs that don't have them as separate clocks. Thus
> the driver can keep both of them mandatory. Wouldn't that work?
> 
> Like this:
> clocks = <&xyz ...>, <&xyz ...>;
> clock-names = "bus", "module";
> 
>>>
>>> That what exactly Clock PM domain is doing :)
>>
>> I agree with Grygorii. Emilio's solution is correct as well, but using
>> runtime pm is the best way forward, especially for examples like the
>> OP's, where the goal is to do whatever is necessary to make the hardware
>> ready for doing work.
>>
>> Ulf is doing some work towards creating a "best practices" example of pm
>> runtime adaptation and I've Cc'd him in case he has any comments.
>>
>> Regards,
>> Mike
>>
>>>
>>> In Davinci it is defined as:
>>> static struct pm_clk_notifier_block platform_bus_notifier = {
>>>          .pm_domain = &davinci_pm_domain,
>>>          .con_ids = { "fck", "master", "slave", NULL },
>>> };
>>>
>>> When device is created the Clk PM domain core (clock_ops.c) recollects all clocks
>>> specified for device (in DT or in clkdev tables) by their names (DT) or con_id (clkdev).
>>> One device can specify clocks: "master", "slave"
>>> and another only "fck".
>>>
>>> Then in driver you need only do:
>>>   pm_runtime_enable(dev);
>>>   error = pm_runtime_get_sync(dev);
>>>   ^ all clocks assigned to the device will be enabled
>>>
>>> ...
>>>   error = pm_runtime_put_sync(dev);
>>>   ^ all clocks assigned to the device will be disabled
> 
> I would not recommend using the clk PM domain to solve this issue.
> Especially not through a power domain. Simply because we must not
> force each an every SOC to implement a pm_domain just to be sure
> clocks are handled properly for a device.

It depends on SoC :). PM on Keystone 2 is very simple, and It's
just based on clocks. HW block is on if its clocks are on.
So, Clk PM domain (clock_ops.c) fits such kind of SoCs the best.
Also, it allows to simplify reusing of HW block between different SoCs
- a lot of HW blocks in Keystone 2 are compatible to Davinci, but
used different set of clocks per HW block.

As for me, There are no need to force anyone to use anything :)
There are set of frameworks and Libs in Kernel which declared
as generic and the platform developer can select what is
the best for his Platform (another question is lack of documentation
for some of them).
Exception: some generic code is declared as deprecated.

So, please, treat all my previous comments as "recommendation" only :)

> 
> Still, of course runtime PM should be implemented, since it give you
> the option to gate your clocks at "request inactivity" and thus saving
> power.

Regards,
 - grygorii