boards: nrf54l15dk: disable Peripheral Resource Sharing (PRS) boxes

[eivindj-nordic]

Disable all Peripheral Resource Sharing (PRS) boxes for nRF54l15DK.

[github-actions]

You can find the documentation preview for this PR here.

[lemrey]

What's the reason for this change?
And also, why don't we disable all drivers by default?

[eivindj-nordic]

What's the reason for this change?

Reason is to align with #621. The PRS boxes are for advanced use.

And also, why don't we disable all drivers by default?

The reason to have the drivers enabled by default is to reduce the complexity for the user, and for the applications. We could remove it, though then we would need to enable it in all samples using the peripherals. Also, we might need to add board specific configuration files to some of the samples as not all SoCs have the same peripherals.

[lemrey]

What's the reason for this change?

Reason is to align with #621. The PRS boxes are for advanced use.

But a peripheral being for "advanced use" is not a clear and well defined characteristic. How do you define that? Is it really something we want to use to selectively enable/disable a peripheral at the board level?

And also, why don't we disable all drivers by default?

The reason to have the drivers enabled by default is to reduce the complexity for the user, and for the applications. We could remove it, though then we would need to enable it in all samples using the peripherals. Also, we might need to add board specific configuration files to some of the samples as not all SoCs have the same peripherals.

Perhaps we could think of peripherals that all samples want to use, like GPIO and UART and enable those, leaving the rest disabled.

[bjorn-tore-taraldsen]

What's the reason for this change?

Reason is to align with #621. The PRS boxes are for advanced use.

But a peripheral being for "advanced use" is not a clear and well defined characteristic. How do you define that? Is it really something we want to use to selectively enable/disable a peripheral at the board level?

And also, why don't we disable all drivers by default?

The reason to have the drivers enabled by default is to reduce the complexity for the user, and for the applications. We could remove it, though then we would need to enable it in all samples using the peripherals. Also, we might need to add board specific configuration files to some of the samples as not all SoCs have the same peripherals.

Perhaps we could think of peripherals that all samples want to use, like GPIO and UART and enable those, leaving the rest disabled.

Statement that "PRS boxes are for advanced use":
PRS boxes is only used when you, at runtime, want to switch and use to peripherals that share the same interrupt vector. These two peripherals can not be enabled at the same time but you could alter between them, but you need a way of handling the common resources. And you will only need to enable the PRS box that is handling that specific Serial box.

This is a very special use-case and is the reason why I think these boxes should be disabled by default

[eivindj-nordic]

PRS boxes is only used when you, at runtime, want to switch and use to peripherals that share the same interrupt vector. These two peripherals can not be enabled at the same time but you could alter between them, but you need a way of handling the common resources. And you will only need to enable the PRS box that is handling that specific Serial box.

This is a very special use-case and is the reason why I think these boxes should be disabled by default

I've been thinking a bit more about this and I am leaning towards keeping the PRS boxes and LPCOMP enabled in the boards by default. If we are starting to disable some of the features in nrfx because it is "too advanced" it opens the question of what should be enabled and what should not be. If some users might want to use the enhanced features, I think we should support that as long as it does not "cause harm" to other users. If we leave everything enabled then it is up to the user to decide what to use in their application in the end, with one less step to configure for using a nrfx driver, which I think is good.