Arch arm mpu regions index number in DTS

[ioannisg]

We can describe even ARM Cortex-M core peripherals in DTS; we do it with NVIC and SysTick already; the MPU could be the next. We create an mpu node, and use DTS to describe the number of HW regions, which is implementation-defined.

We use the DTS-generated macro directly in _get_num_regions(), so we do not need to evaluate the MPU_TYPE register at run-time, all the time.

[codecov-io]

Codecov Report

Merging #12173 into master will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master   #12173   +/-   ##
=======================================
  Coverage   48.06%   48.06%           
=======================================
  Files         284      284           
  Lines       43383    43383           
  Branches    10397    10397           
=======================================
  Hits        20853    20853           
  Misses      18389    18389           
  Partials     4141     4141

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 0b9cfe7...236fdbe. Read the comment docs.

[ioannisg]

@agross-linaro could you provide comments on this PR?

[pizi-nordic]

Why we need that? In all modified architectures you can read the number of MPU regions in runtime.
Do we need this value during compilation?

[galak]

does this really make sense here, since not all arm soc's have MPUs.

[ioannisg]

The MPU registers can always be accessed (some of them will be RAZ/WI, of course, if the MPU is not present). So this does not harm, IMHO, as we don't really define the "regions" property, here. The "regions" property and the corresponding DT_ macro are, anyway, defined in SOC/Board DTS fixup.

I don't see a better place to define the MPU node, actually. We do the same for NVIC. And the actual "prio-bits" property is defined in the SOC level.

[galak]

But I feel like all the SoCs have NVIC which is why we do it, and if one doesn't it should delete the node.

I'd rather see we add MPU nodes to the SoCs that have them instead of at this level.

[galak]

Rather than adding mpu nodes to armv{6,7,8}-m.dtsi I'd like to see we add them to the SoCs dtsi files that have mpus.

[ioannisg]

Rather than adding mpu nodes to armv{6,7,8}-m.dtsi I'd like to see we add them to the SoCs dtsi files that have mpus.

@galak, I see your point, but in my opinion this is, mostly, a matter of style :)

True, all SoCs have NVIC, and that's, perhaps, why the nvic node is defined in the arm_.dtsi headers. But the actual number of priority bits of NVIC is implementation defined. And that's why we have the following definitions in the SOC .dtsi headers:

&nvic {
	arm,num-irq-priority-bits = <3>;
};

Note that this is the actual and only property we need regarding NVIC - the priority bits; no other NVIC information is passed from DTS to C code! And that one is supplied at SOC level.

So, I'd like to see MPU following the same style: i.e. seen as a "general" feature of Cortex-M CPUs, defined in the ARCH level. But the actual and only property we need regarding MPU - the number of regions - is defined at SOC level if applicable and if required, and passed to C code.

Note that this is also the case with the systick DTS node: it is defined in the arm_.dtsi while it is clearly, an optional peripheral for M0, M0+ and M23.

[galak]

And we should delete systick from any SoC that doesn't have it.

So we should either add the node per SoC, or delete it from the SoC's that dont have MPUs (if we add it at the arm*.dtsi level).

[ioannisg]

And we should delete systick from any SoC that doesn't have it.

So we should either add the node per SoC, or delete it from the SoC's that dont have MPUs (if we add it at the arm*.dtsi level).

Alright. Makes more sense to add the node per SoC, since it is all optional, anyways. The node is meant for Cortex-M23,33,7 where the number of regions is impl-defined (Cortex-M0+, M3, and M4 have 8 regions, fixed).

Will delete the SysTick from v6-M SoCs that don't have it.