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

Benjamin Tietz benjamin at micronet24.de
Thu Jul 28 21:28:09 CEST 2016


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


More information about the U-Boot mailing list