[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