clk: bcm2835: what is the best way to limit the selection of parent clocks in the device-tree

clk: bcm2835: what is the best way to limit the selection of parent clocks in the device-tree

[Martin Sperl]

Hi!

On the raspberry pi the pcm (and other) clock has multiple parent
clocks that the driver may select from to get the "best fit" clock.

This list of parents of valid for each clock is hard-coded in the driver.

But this "standard" list of parents includes some clocks that are
independently controlled by the firmware with - unfortunately for
now - no notification of changes going back to the linux kernel.
This is mostly needed for powermanagement and ARM clock
modifications as well as to avoid overheating.

So how is the best way to define those parent clocks one wants to
use for an individual clock?

As far as I can tell none of the default dt-properties really fit.

So I wonder if something like the following would be acceptable:
cprman: cprman at 7e101000 {
     compatible = "brcm,bcm2835-cprman";
     #clock-cells = <1>;
     reg = <0x7e101000 0x2000>;
     clocks = <&clk_osc>;
     /* limit parent clock selection for the PCM clock */
     pcm_clk at BCM2835_CLOCK_PCM {
         reg = <BCM2835_CLOCK_PCM>;
         clock-parent-names = "gnd", "xosc", "plla_per", "plld_per";
     };
};

As an alternative it could also be defined on the consumer side:
i2s: i2s at 7e203000 {
     compatible = "brcm,bcm2835-i2s";
     reg = <0x7e203000 0x24>;
     clocks = <&cprman BCM2835_CLOCK_PCM>;
     clock-parent-names = "gnd", "xosc", "plla_per", "plld_per";
};
This variant might need to be made "clock-parent-names-0",
"clock-parent-names-1", ... (analogous to "pinctrl-0") to allow
distinct parents for distinct clocks.

Is something like this acceptable?

If not, what approach could be taken to achieve the required
(except for hard-coding the selection it in the driver)?

If it is the second, then I guess the implementation would need
to go into the core framework while for the first the logic could
also stay within the driver.

Thanks,
                 Martin

clk: bcm2835: what is the best way to limit the selection of parent clocks in the device-tree

[Stefan Wahren]

Hi Martin,

Am 25.04.2016 um 10:01 schrieb Martin Sperl:
> Hi!
>
> On the raspberry pi the pcm (and other) clock has multiple parent
> clocks that the driver may select from to get the "best fit" clock.
>
> This list of parents of valid for each clock is hard-coded in the driver.
>
> But this "standard" list of parents includes some clocks that are
> independently controlled by the firmware with - unfortunately for
> now - no notification of changes going back to the linux kernel.
> This is mostly needed for powermanagement and ARM clock
> modifications as well as to avoid overheating.
>
> So how is the best way to define those parent clocks one wants to
> use for an individual clock?

since the device tree should describe the hardware this should be kept
in the driver. So we can't get into trouble if the firmware change it's
behavior.

Regards
Stefan

clk: bcm2835: what is the best way to limit the selection of parent clocks in the device-tree

[Martin Sperl]

> On 26.04.2016, at 13:22, Stefan Wahren <stefan.wahren@i2se.com> wrote:
> 
> Hi Martin,
> 
> Am 25.04.2016 um 10:01 schrieb Martin Sperl:
>> Hi!
>> 
>> On the raspberry pi the pcm (and other) clock has multiple parent
>> clocks that the driver may select from to get the "best fit" clock.
>> 
>> This list of parents of valid for each clock is hard-coded in the driver.
>> 
>> But this "standard" list of parents includes some clocks that are
>> independently controlled by the firmware with - unfortunately for
>> now - no notification of changes going back to the linux kernel.
>> This is mostly needed for powermanagement and ARM clock
>> modifications as well as to avoid overheating.
>> 
>> So how is the best way to define those parent clocks one wants to
>> use for an individual clock?
> 
> since the device tree should describe the hardware this should be kept
> in the driver. So we can't get into trouble if the firmware change it's
> behavior.

I am just thinking about the way that different groups want to use
for example i2s may want to use different parents than pwm.

My concern is that people will have to compile the kernel separately
to reach their personal preference. And to some extend this
is also describing the device connected: different DAC may have
different preferences (with regards to noise) - and that then 
describes the hardware (or at least the intent of the HW designer).

So I wonder how we can achive this?

Along a similar line is the configuration of the higher order mash
clock options (fractional divider with noise spreading).

Making all these policies go inside the driver may not be intended,
as it would not apply to all DAC equally...

Martin