From mboxrd@z Thu Jan 1 00:00:00 1970 From: Benjamin Tietz Date: Thu, 28 Jul 2016 21:28:09 +0200 Subject: [U-Boot] [PATCH v2 07/22] clock-uclass: allow disabling a peripheral clock In-Reply-To: References: <20160620182505.21075.54136.stgit@obelix.dresden.micronet24.de> <20160620182636.21075.97627.stgit@obelix.dresden.micronet24.de> Message-ID: <20160728192809.GC2991@micronet24.de> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de 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