Re: Issue with Clock Parent Assignment on AM335x SoC (Watchdog Timer)

["Mathieu Dubois-Briand" <mathieu.dubois-briand@bootlin.com>]

On Thu Apr 30, 2026 at 5:40 AM CEST, Tony Lindgren wrote:
> * Stephen Boyd <sboyd@kernel.org> [260429 03:46]:
>> +Tony (author of commit)
>> 
>> Quoting Mathieu Dubois-Briand (2026-04-28 05:03:16)
>> > Hi,
>> > 
>> > I believe I’ve identified an issue with clock management on the AM335x
>> > SoC and possibly other TI SoC. It can be seen while using the SoC
>> > watchdog timer, but I suspect other clocks or modules might be impacted.
>> > 
>> > While I partially understand the issue, I struggle to find a correct
>> > solution. I will describe my findings below.
>> > 
>> > First, here is a quick way to reproduce it.
>> > - Hardware: Beagle Bone Black.
>> > - Linux kernel version: v7.1-rc1 (or anything after 5.19).
>> > - Configuration: omap2plus_defconfig + CONFIG_OMAP_WATCHDOG=y
>> > - In the bootloader, I select the 32KHz clock derived from the 24MHz one
>> >   as the watchdog clock source. This is controlled by bit 1 of
>> >   CLKSEL_WDT1_CLK.
>> >   This is probably the point that differs from most use cases, and why
>> >   it hasn't been observed before. On my final setup, I do not control
>> >   the bootloader and so cannot change this value.
>> >   In u-boot, this is: mw.l 0x44e00538 1
>> > - Once the kernel is booted, I open the watchdog device node. I'm using
>> >   busybox "watchdog" command, but a simple "cat" will trigger the same
>> >   error.
>> >   watchdog /dev/watchdog0
>> > - This will result in the bus clock failing to be enabled and a failure
>> >   to access the watchdog module:
>> >   [   11.677752] l4-wkup-clkctrl:00d4:0: failed to enable
>> >   [   11.686079] Unhandled fault: external abort on non-linefetch (0x1028) at 0xf9e35034
>> >   I'm attaching the full trace at the very end of my email.
>> > 
>> > So, I tried to dig a bit into this issue and the reason why the
>> > l4-wkup-clkctrl:00d4:0 clock can't be enabled.

Hi Tony,

Thanks for your reply.

> Just a quick guess.. You can use assigned-clocks in the dts file to
> configure how your board is wired up.

Just to be clear: I believe this is entirely independent from how the
board is wired up. On both my custom board and the Beagle Bone Black, I
can successfully use any of the two muxing possibilities, if I manually
write the correct data into the registers. My only issue is the kernel
does not handle the clocks correctly when one these muxing possibilities
is enabled.

Yet I tried to add an assigned-clocks property to the clock-wdt1-fck@538
node. Is that what you had in mind? This had no visible effect.

> Please check the system timers configuration too, sounds like timers may
> not be configured properly either. Some timer examples can be seen with:
>
> $ git grep -A10 "Preferred " arch/arm/boot/dts/

So I had a look at existing preferred timer configurations, but they are
all applied to the "timer.*_target" [1][2] nodes, that do correspond to
SoC timers (DMTIMER.*) and I fail to see how this is linked with the
peripheral clocks involved here (in CM_PER module) and my current clock
issues.

Nevertheless, I can see these being defined in
arch/arm/boot/dts/ti/omap/am33xx.dtsi [3][4], so they are indeed applied
in my situation.

So, I believe timers configuration are correct. Should I add something
else?

Thanks again,
Mathieu

[1]: https://elixir.bootlin.com/linux/v7.0.1/source/arch/arm/boot/dts/ti/omap/am33xx-l4.dtsi#L357
[2]: https://elixir.bootlin.com/linux/v7.0.1/source/arch/arm/boot/dts/ti/omap/am33xx-l4.dtsi#L1280
[3]: https://elixir.bootlin.com/linux/v7.0.1/source/arch/arm/boot/dts/ti/omap/am33xx.dtsi#L702
[4]: https://elixir.bootlin.com/linux/v7.0.1/source/arch/arm/boot/dts/ti/omap/am33xx.dtsi#L715

-- 
Mathieu Dubois-Briand, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com