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

[Benjamin Tietz]

Hello Vikas, hello Simon,

sleeping a night over this issue, I've came along with the following
concept:

The peripheral clocks are grouped by peripheral bus, that they are
connected to. Each bus is driven by one or more set of registers,
allowing up to 32 clocks to be selected. Having more than 8 registers
would require massive modifications anyway. So it can be expected to
have at most 256 clocks.

As these domains partly have special clock-domains, partly rely on their
bus-clock, I would like to interprete the id as a bitfield. At least the
least significant byte represents a simple counter over the clocks -
with all other bits set to zero representing real clocks.

Setting the LSB of the third byte (using the mask 1<<16) might represent
the "master clocks" - starting with the individual port clocks continued
by the specialized clock domains.

Using 1<<17 than could represent the individual PLLs directly.

regards
Benjamin

On Thu, Jul 28, 2016 at 09:28:09PM +0200, 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.
> 
> 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.
> 
> b) moving the sysclock and PLL-stuff in a seperate driver. That driver
> should be found in the device-tree, too.
> The device-tree should represent the hardware. Because of that, the
> source-clock of the STM32 RCC device (the clocking subsystem), should
> be either the external quartz or one of the internal sources, not a
> pll-device. Apart from that, the kernel in its current configuration
> probably is using this information to compute is current clock-speed.
> 
> c) extending the struct clk, which looks clumsy, too.
> 
> Any ideas?
> 
> regards
> Benjamin