am33xx: ignore SYSBOOT 15:14 if board OSC is known
diff mbox

Message ID CAEXMXLT9EJ33Yu-fQbL77YHaL_ftGSroOTxmRzyDPR6fb7x-yA@mail.gmail.com
State New
Headers show

Commit Message

Nuno Gonçalves May 21, 2015, 4:26 p.m. UTC
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

[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


        bone_capemgr {
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Comments

Tero Kristo July 13, 2015, 12:17 p.m. UTC | #1
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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Patch
diff mbox

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 */
 / {