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 _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
