[U-Boot] [PATCH v2 07/22] clock-uclass: allow disabling a peripheral clock

[Stephen Warren]

On 07/28/2016 01:28 PM, Benjamin Tietz wrote:
> Hello Vikas, hello Simon,
>
> the new clk-API leaves me with a problem. Previously there was a
> seperate way to access the clock-device itself (using clk_[gs]et_rate) and
> the peripherals connected (clk_[gs]et_periph_rate). The former case now isn't
> available no more. But the system clock in STM32 doesn't have a separate ID.
> According to the device-tree the kernel doesn't care about that - or
> uses special logic.

I don't understand the issue here. The device tree model is that every 
clock has some provider (a node/phandle) and some ID (a sequence of 
integer values). There's no such thing as "the clock-device itself".

The kernel is consistent with that model; each client executes 
clk_get(), which for a DT-based system parses the 
phandle+clock_specifier and returns a clock handle, and then the client 
just uses that handle. That's exactly how U-Boot works too.

Perhaps you can show the portion of DT that's causing the issue?

Is the issue that there are clocks that your code needs to use that 
haven't yet been assigned a clock ID (clock specifier value) for use in 
DT (i.e. you have SoC-specific code that's calling clk_get() and the 
mapping isn't via DT)? If so, you simply need to assign one and 
everything will work fine. High numbers work fine for this.

> Possible solutions:
>
> a) Using a magic ID. Unfortunately, the peripheral used in the current
> device-tree are 0-based (and 0 is already in use), so this number isn't
> available. Moving the IDs around would break compatibility to the linux
> kernel.
>
> Negative numbers look like errors.
>
> Using a special high number looks unintuitive. And often result in
> additional work-arounds in the future.

What specific issues are you thinking of? I haven't experienced any when 
assigning IDs on Tegra, and I haven't observed anyone having issues 
doing this on any platform within the Linux kernel, where the exact same 
thing would be required.