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