• State Resolved
  • Locked Locked
  • Replies 9 replies
  • Subscribers 99 subscribers
  • Views 251 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

AM3352: ti-sysc: Failed to create device link 0x180 with supplier for timer1 and timer2

Lucas Martins Alves
Prodigy 80 points

Part Number: AM3352

Hello,

I am working with an AM3352-based platform and have observed the following messages during Linux boot:

ti-sysc 44e31000.target-module: Failed to create device link 0x180 with supplier ocp for /ocp/interconnect@44c00000/segment@200000/target-module@31000/timer@0
ti-sysc 48040000.target-module: Failed to create device link 0x180 with supplier ocp for /ocp/interconnect@48000000/segment@0/target-module@40000/timer@0

From my current understanding, these messages seem to be related to the TI SYSC interconnect driver attempting to create device links for timer modules. I suspect this may be associated with flag 0x180 (DL_FLAG_SYNC_STATE_ONLY) and possibly because the timer device has already been probed.

I also noticed that the same message appears in Texas Instruments' own CI test logs for AM335x platforms. For example:

https://software-dl.ti.com/cicd-report/linux/index.html?section=test_log&platform=am335x&snapshot=cicd.master.202605061800&board=am335x-evm&variant=Linux&test=LCPD-T826&log=dut1_1_log.txt

This suggests that the issue might be known and possibly benign, but I would appreciate clarification.

My questions are:

- Does this issue have any functional impact?
  The system appears to operate normally, but I would like to know whether this may affect power management, clock handling, or runtime PM behavior.

- Is there a recommended way to fix or avoid this message?
  For example:
  - Device Tree adjustments
  - Kernel configuration changes
  - Known upstream patches

- If this message is harmless, what would be the recommended way to suppress or reduce it in the boot logs?

Any insights or recommendations would be greatly appreciated.

Thank you!

  • 0
    TI__Mastermind 24775 points

    Hello Lucas,

    Let me look into this error and get back to you on Monday.

    Thanks,

    Anshu

  • 0 in reply to Anshu Madwesh
    TI__Mastermind 24775 points

    Hi Lucas,

    Is this timer in use for your application? If not, let look into disabling it. 


    If you do need the timer, can you see if this patch removes the error: https://github.com/beagleboard/BeagleBoard-DeviceTrees/issues/84

    https://github.com/beagleboard/BeagleBoard-DeviceTrees/commit/b413db3

    Best Regards,

    Anshu

  • 0 in reply to Anshu Madwesh
    Prodigy 80 points

    Hi Anshu,

    If I am reading this correctly, on AM335x, timer1 and timer2 seem to be foundational timers that are attached very early during boot. It appears that timer1 is usually treated as the preferred always-on clocksource timer, while timer2 is typically used as the preferred clockevent timer. If that assumption is correct, both nodes enter the early fw_devlink dependency flow, so any issue in creating an inferred device link is likely to show up very early in boot.

     Based on core.c:2173 (inside function fw_devlink_create_devlink), the error seems to come from a very specific code path:

     dev_err(con, "Failed to create device link (0x%x) with supplier %s for %pfwf\n",
            flags, dev_name(sup_dev), link->consumer);
    ret = -EINVAL;

     From this path, the message does not seem to indicate an EBUSY condition. A more likely interpretation is that fw_devlink_create_devlink() calls device_link_add() and receives NULL. In that flow, the kernel does not appear to propagate a detailed errno from lower layers; instead, it treats the inability to create the link as a structural dependency-graph failure and converts it to -EINVAL. That may explain why the log reports that the device link could not be created, while the return value is not EBUSY.

     

    Also, this possible workaround was tested and did not resolve the issue:

    https://github.com/beagleboard/BeagleBoard-DeviceTrees/issues/84
    https://github.com/beagleboard/BeagleBoard-DeviceTrees/commit/b413db3

    Best Regards,
    Lucas

  • 0 in reply to Lucas Martins Alves
    TI__Guru**** 182316 points

    Hi Lucas,

    If you see these messages are still in the TI CICD test log, it apparently exits in the latest kernel. I will look into the kernel code to see what causes them and if they need to be addressed.

    I am currently in the middle of a task, and likely I can start look into this timer issue early next week. I will keep you posted.

  • 0 in reply to Bin Liu
    Prodigy 80 points

    Hi Bin Liu,

     

    Thanks for the update.

     

    I’ll wait for your findings.

     

    Best regards, 
    Lucas
  • +1 in reply to Bin Liu
    Prodigy 85 points

    Hi Bin,

    I found the root cause and a working fix. Timer1 and Timer2 are initialized before the OCP interconnect. Later, when OCP is probed and tries to create device links to these timers, the kernel reports the device-link creation errors.

    The fix is to add the post-init-providers property to Timer1 and Timer2, so dependency resolution reflects that OCP is available after the timer initialization stage. This prevents the invalid link-creation attempt and removes the related boot log errors.

    The patch for the am33xx:

    From d16536280ef80bef39cdb4c111ef66407b8bbd24 Mon Sep 17 00:00:00 2001
From: Wagner Popov dos Santos <wagner.popov@autotrac.com.br>
Date: Wed, 24 Jun 2026 13:28:02 -0300
Subject: [PATCH] ARM: dts: am33xx: avoid invalid OCP device-link for timers

This patch fixes boot-time fw_devlink errors on AM335x/UCC3 caused
by invalid device-link creation attempts involving timer1/timer2
and supplier ocp.

Observed kernel log messages:

  ti-sysc 44e31000.target-module: Failed to create device link 0x180
  with supplier ocp for
  /ocp/interconnect@44c00000/segment@200000/target-module@31000/timer@0

  ti-sysc 48040000.target-module: Failed to create device link 0x180
  with supplier ocp for
  /ocp/interconnect@48000000/segment@0/target-module@40000/timer@0

The change updates dependency handling for timer1 and timer2 so the
kernel no longer attempts this invalid link-creation path during
initialization.

Impact:

- Removes the two ti-sysc/fw_devlink error messages at boot
- Preserves current timer and clock assignment behavior
- No functional regression observed in boot and timer operation tests

Signed-off-by: Wagner Popov dos Santos <wagner.popov@autotrac.com.br>
---
 arch/arm/boot/dts/ti/omap/am33xx.dtsi | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm/boot/dts/ti/omap/am33xx.dtsi b/arch/arm/boot/dts/ti/omap/am33xx.dtsi
index ca3e7f5d7d0d..760598d5ae1c 100644
--- a/arch/arm/boot/dts/ti/omap/am33xx.dtsi
+++ b/arch/arm/boot/dts/ti/omap/am33xx.dtsi
@@ -708,6 +708,7 @@ &timer1_target {
 	timer@0 {
 		assigned-clocks = <&timer1_fck>;
 		assigned-clock-parents = <&sys_clkin_ck>;
+		post-init-providers = <&ocp>;
 	};
 };
 
@@ -721,5 +722,6 @@ &timer2_target {
 	timer@0 {
 		assigned-clocks = <&timer2_fck>;
 		assigned-clock-parents = <&sys_clkin_ck>;
+		post-init-providers = <&ocp>;
 	};
 };
-- 
2.43.0

  • 0 in reply to Wagner Popov dos Santos
    TI__Guru**** 182316 points

    Hi Wagner,

    Glad to hear the issue is resolved. Thanks for sharing the patch. Do you plan to send it to kernel upstream?

  • 0 in reply to Bin Liu
    Prodigy 85 points

    Hi Bin,

    Yes, I sent the patch.

    Thanks,
    Wagner