drivers: misc: Add driver for Silicon Labs Packet Trace Interface

[asmellby]

The Packet Trace Interface is a debug interface within the radio subsystem that emits TX and RX packet data over a serial connection in real time.

Add bindings and DTS nodes for the Packet Trace Interface of the radio, and a misc driver to initialize it. Add pinctrl configuration to boards that have PTI pins wired to the on-board debugger. Add a snippet that can be used to enable packet trace output from Silicon Labs Series 2 devices for any application.

[nordicjm]

New driver classes need architecture review, will add label

[carlescufi]

Without wanting to block this directly, is this a driver that could be generalized in any way or placed under an existing category? Should we have a quick discussion in the Arch WG?

[asmellby]

I'd be happy to present for the Arch WG.

I didn't find any existing driver category that made sense, hence the choice of a misc driver. However, this is technically also something that could be done through a SoC or board init hook.

When it comes to generalization, it would be useful to discuss the general concept of "trace init". There are several instances of this on Silicon Labs SoCs (and ARM in general), where "something" needs to be done to initialize a stream of data from the device:

• ARM ETM -- instruction trace, needs pinctrl config ++
• ARM SWO -- PC sampling and exception trace (in addition to general-purpose ITM-as-a-serial-pipe usage), needs pinctrl config ++
• Silicon Labs PTI -- packet trace, needs pinctrl config ++

[carlescufi]

I'd be happy to present for the Arch WG.

Could you do next Tuesday, April 8th?

[carlescufi]

Architecture WG:

• @asmellby presents the potential sharing of infrastructure among existing and future drivers that deal with loggin/tracing/debugging
• An open question, perhaps higher-level is whether you actually need something in drivers/ when there is no API at all, because this could just technically be in soc.c, given hat it only initializes the hardware
  • @nashif and @carlescufi agree that this should be in drivers/, no objections
  • memc and power_domain are already such drivers
• @carlescufi suggests moving this and the coresight driver (cc @nordic-krch) to drivers/debug so we have those drivers grouped and we can find common parts
• @nashif suggests also looking through the tree to find additional debug-related code to this folder

[asmellby]

Created a new drivers/debug class, guarded by the DEBUG_DRIVER Kconfig option (since DEBUG is already taken).
Moved the PTI driver into drivers/debug.
Added a MAINTAINERS entry for the new driver class. Tentatively added @nordic-krch as collaborator, are you OK with that? There is also the option to reuse the existing Debug entry (currently used for subsys/debug), input on this would be appreciated.

[asmellby]

@carlescufi What are the next steps to progress this PR?

[asmellby]

Resolved merge conflicts after #89946

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud