On 05/21/2015 07:26 PM, Nuno Gonçalves wrote:
Currently the processor PLLs and Dividers are configured according to SYSBOOT levels during boot [1][2]. In the case of boards with expansion capabitliy, like the Beaglebone, the expansion board might touch this SYSBOOT pins a provide a wrong clock information. If we know the OSC on board as a fact (for example 24MHz for the Beaglebone), the SYSBOOT information can be safely ignored and the correct value hardcoded on the DT. The patch following works for am33xx. Anyway I have some reservations about this. Maybe overriding "sys_clkin_ck" with "virt_24000000_ck" is a better solution? Regards, Nuno
Sorry, seems this patch was buried in my mailbox, thanks for the offline ping.
Anyway, the approach taken here is a horrible hack IMO, both for software and hardware.
- Why would a cape want to reconfigure SYSBOOT pins in the first place? If this happens, it is bad hardware design. If you really need to re-use SYSBOOT pins for something, you should make sure their value is proper during reset, and only after reset is released set-up their alternative use.
- Reconfiguring SYSBOOT pins will cause other problems in addition to kernel configuration being wrong; namely, SYSBOOT pins are also read by ROM code and certain initializations are done based on this. If you provide wrong value on SYSBOOT, the initial PLL config is going to be wrong also, which can cause various problems for the device.
The status for this patch is NAK. -Tero
[1] https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/arch/arm/boot/dts/am33xx-clocks.dtsi#n11 [2] http://www.ti.com/lit/ug/spruh73l/spruh73l.pdf diff --git a/src/arm/am335x-bone-common.dtsi b/src/arm/am335x-bone-common.dtsi index 77067d6..1ddaa58 100644 --- a/src/arm/am335x-bone-common.dtsi +++ b/src/arm/am335x-bone-common.dtsi @@ -356,6 +356,10 @@ status = "okay"; }; +&sys_clkin_ck { + clocks = <&virt_24000000_ck>, <&virt_24000000_ck>, <&virt_24000000_ck>, <&virt_24000000_ck>; +}; + /* the cape manager */ / { bone_capemgr {
-- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
