dts: ti: cc13xx_cc26xx: devicetree sysclk alignment

[ghost]

This change introduces the "_rtc_timer" suffix for the system tick timer driver "compatible" property and aligns naming conventions with the actual CC13/26xx SoC series product policy.

This frees up the "_rtc" namespace to introduce additional APIs based on the same peripheral in the future:

rtc: rtc@... {
  compatible = "ti,cc13xx-cc26xx-rtc";
  ...

  timer {
    compatible = "ti,cc13xx-cc26xx-rtc-timer";
    ...
  };

  counter {
    compatible = "ti,cc13xx-cc26xx-rtc-counter";
    ...
  };

  pps {
    compatible = "ti,cc13xx-cc26xx-rtc-pps";
    ...
  };
};

Or alternatively an MFD pattern with similar requirements.

To enable this change, some duplicate devicetree nodes were removed and inconsistencies in the naming and include hierarchy of the cc13xx_cc26xx devicetree and RTC system clock driver fixed.

[ghost]

@cfriedt @niflostancu You'll probably also want to review this.

[cfriedt]

It's possible that this may be usable as a RTC in spite of the fact that it's missing separate year, month, day of month, etc registers.

In particular, the fact that it has support for compensation indicates to me that it might actually work.

I wouldn't mind hearing @vaishnavachath's thoughts here.

[ghost]

It's possible that this may be usable as a RTC in spite of the fact that it's missing separate year, month, day of month, etc registers.

@cfriedt True, the hardware peripheral has the capability for system_timer.h, rtc.h, counter.h and PPS for clock synchronization.

Got some help from Brix on Discord, I guess the correct solution would then be rtc: rtc@... following the "peripheral-name-from-datasheet: generic-function@address" pattern? The same is probably true for the compat-String which was fine as it represents hardware, not the driver software. Will update the PR accordingly.

[ghost]

@cfriedt Update: As only one driver can be attached per dt node using the _rtc_timer suffix for the compatible property is correct as we'd clutter the namespace otherwise. Do you agree?

Just updated the PR accordingly.

[vaishnavachath]

@fgrandel can we split the changes to two separate commits? one for the binding/DT update and another for the rename/include fixes?

[ghost]

an we split the changes to two separate commits? one for the binding/DT update and another for the rename/include fixes?

@vaishnavachath Yes, of course. Makes sense. Done.

[ghost]

Echo client/server regression test result on real hardware to verify that nothing fundamental broke:

IPv6 recv      78248    sent    78327   drop    6       forwarded       0
IPv6 ND recv   992      sent    1001    drop    0
IPv6 MLD recv  0        sent    3       drop    0
IP vhlerr      0        hblener 0       lblener 0
IP fragerr     0        chkerr  0       protoer 0
UDP recv       77250    sent    77322   drop    0
UDP chkerr     0
Bytes received 10916465
Bytes sent     10920976
Processing err 6

[ghost]

@cfriedt I think this one is ready for re-reviewing now.

[kartben]

I'm obviously late here, but shouldn't these changes be added to the release notes? Renaming the compatible and Kconfig options may break things for people.
Also, it would probably make sense to rename ti,cc13xx-cc26xx-rtc.yaml to ti,cc13xx-cc26xx-rtc-timer.yaml?

[ghost]

I'm obviously late here,

@kartben It is never too late. :-) See #60177

Thanks for catching these obvious issues!