drivers: Peripheral to peripheral interconnect API

[carlescufi]

Is your enhancement proposal related to a problem? Please describe.

This issue describes the (far-fetched at this point) possibility of having a common driver API for peripheral to peripheral interconnect functionality.

Today there are many microcontrollers that offer some kind of mechanism to achieve the following:

• Direct peripheral to peripheral connection
• No CPU intervention
• Ability to trigger actions on one peripheral based on the output of another one

Describe the solution you'd like

Ideally we would need a new driver API class that encapsulates this functionality in a vendor-agnostic fashion. Whether this is actually possible at all remains to be seen, given the ample differences between vendors.

Describe alternatives you've considered

The simplest alternative is to have vendor-specific APIs for each vendor individually. This may end up being the case if we do not manage to find enough commonality among the different hardware.

List of hardware features that fall into this category

• Renesas Event Link Controller (ELC)

  • Description
  • Pull Request

• Nordic (Distributed) Programmable Peripheral Interconnect ((D)PPI)

  • Description

• STM Peripheral Interconnection

  • Description

• Silicon Labs Peripheral Reflex System (PRS)

  • Description

• Espressif Event Task Matrix

  • Description, Section 3.8

[aescolar]

My 2 cents:
Apart from something like this being probably difficult to abstract without lots of complexity,
I wonder what would be the benefit: By definition connecting HW peripherals together is going to be really HW specific and be done either in drivers for some very specific set of HW IPs, or in an APP that is relying on very specific HW. So what would the benefit be of providing an abstraction over a HAL/vendor driver for this?

[carlescufi]

My 2 cents: Apart from something like this being probably difficult to abstract without lots of complexity, I wonder what would be the benefit: By definition connecting HW peripherals together is going to be really HW specific and be done either in drivers for some very specific set of HW IPs, or in an APP that is relying on very specific HW. So what would the benefit be of providing an abstraction over a HAL/vendor driver for this?

It's a very good point @aescolar. In fact the purpose of this issue is to try and find out whether it makes sense at all to abstract this type of functionality (à la pinctrl) or not at all. So your input is valuable because it gives us one point of view already. At the very least though, we should define a driver "folder" (i.e. not driver class but folder) where to place all of these driver implementations.

[henrikbrixandersen]

This is sort of like DMA, but even less generic across platforms. Giving the complexity of the DMA API and considering that this will likely be even more complex giving that we're not just talking data transfers, but also potentially signal routing and events, I too think this is too broad to benefit from a generic API.

I agree, however, that such implementations could live in the same folder, but this folder could also just be drivers/misc/ for now?

[teburd]

Right, there's just not a huge benefit to building an abstract API like this.

That said, upleveling functionality to say something like spi/dma/i2c/adc/dac/sensors kind of makes sense maybe? I had it in mind when creating rtio.

E.g.

rtio_prep_await_trigger(...) /* implied XBAR type triggering setup here */
rtio_prep_write(...) /* implied DMA programming... */
rtio_prep_read(...) /* implied DMA programming... */
rtio_submit(...) /* go program the hardware please */

Now if you were to do some scan of this chain of operations you could setup the hardware to say... await a timer event to trigger bus actions using DMA to read a sensor or adc or whatever perhaps this sort of upleveled API makes sense. But it can't do everything the hardware can, and would require some hardware specific interpretation of the commands. It would likely also require software shims whenever the hardware doesn't support the requested sequence of operations. But at least that's what the API is trying to do.

Adding an API at the hardware level afor cross peripheral triggering/signaling in some abstract manner? Yeah I agree with @henrikbrixandersen in that regard, DMA does this and the API has more or less become a union of all functionality while not really providing a great hardware abstraction. The only time its abstract across hardware today is whenever SOF is involved because SOF wants all DMAs to operate in a particular manner so you even get pseudo DMA drivers like https://github.com/zephyrproject-rtos/zephyr/blob/main/drivers/dma/dma_nxp_sof_host_dma.c

And trying to add in software shims for what might be a union of DMA features doesn't probably make much sense at this sort of device scale imho.

[decsny]

I think there is value in a generic hardware abstraction to control the wide varieties of muxing hardware. I don't think that it needs to be expected to solve complex system and software use cases on it's own. That's for other abstraction layers and components to handle, which can make use of a generic mux API.

[teburd]

Related issues/PRs recently coming up

#90285 - In this case a software interrupt for a timer is triggering an external ADC sample start event via gpio, would be better served by hardware. Subsequently a GPIO edge/level event triggers a bus read, ideally also doable entirely in hardware.
#71777 - Noted a common theme in sensor drivers of doing a bus read driven by a gpio interrupt, this requires a lot of software in between which adds cost that could be removed in theory for some parts where the gpio pin connects to peripheral cross triggering to trigger a pre-programmed DMA sequence. NXP's XBAR allows for this afaik, as does Silicon Labs according to comments there by a silabs engineer.

In the above scenarios we need an API that allows for connecting, abstractly, events to actions. Any sort of API that requires an understanding of a massive #define set of headers with events/peripherals doesn't work here... instead you need a way of (as noted) describing the action to take given an event. In a way that is software shimmable but allowing for the hardware to take advantage when it can.