PMU node location
Hi Rob, Mark, Grant and others,
I want to check with you the location of ARM pmu node I see that
1) highbank and dbx5x0 have it in soc node
2) vexpress and tegra have no main bus and pmu is in root like all others devices. (Any reason no to have main bus? Does it mean that there is no bus or that all devices are accessible?)
3) omap2/omap3 have added pmu node to root node(mailing list)
4) Just for completeness no platform has it in the bus.
That's why I have obvious question what it is proper location for pmu node?
Thanks,
Michal
Signature · 4 lines
Michal Simek, Ing. (M.Eng) w: www.monstr.eu p: +42-0-721842854 Maintainer of Linux kernel 2.6 Microblaze Linux - http://www.monstr.eu/fdt/ Microblaze U-BOOT custodian
A message that is not in the archive (sent off-list or not yet received): [email protected]
Quoted 11 lines · Michal Simek
Hi Rob, Mark, Grant and others,
I want to check with you the location of ARM pmu node I see that
1) highbank and dbx5x0 have it in soc node2) vexpress and tegra have no main bus and pmu is in root like all others devices.
(Any reason no to have main bus? Does it mean that there is no bus or that all
devices are accessible?)
That seems really wrong in general. Any memory mapped device is on a bus of some kind. I'm not sure the reasoning. Perhaps Stephen can explain.
Quoted 6 lines
3) omap2/omap3 have added pmu node to root node(mailing list)
4) Just for completeness no platform has it in the bus.
That's why I have obvious question what it is proper location for pmu node?
Obviously, highbank is the true and correct way. ;)
The pmu is part of the cpu, so it could be part of /cpus. That may cause problems having non-cpu nodes and it would not get probed (although technically that is a Linux problem and should not influence the DT). Since it is not on a bus, then putting it at the top level probably makes more sense than on a bus.
Rob
Quoted 4 lines
Thanks,
Michal
A message that is not in the archive (sent off-list or not yet received): [email protected]
Quoted 7 lines · Rob Herring
Quoted 6 lines · Michal Simek
Hi Rob, Mark, Grant and others,
I want to check with you the location of ARM pmu node I see that
1) highbank and dbx5x0 have it in soc node
Quoted 8 lines
Quoted 5 lines
2) vexpress and tegra have no main bus and pmu is in root like all others devices.
(Any reason no to have main bus? Does it mean that there is no bus or that all
devices are accessible?)That seems really wrong in general. Any memory mapped device is on a bus of some kind. I'm not sure the reasoning. Perhaps Stephen can explain.
I saw no need to have add a bus node (there wasn't one before I started touching DT on Tegra); the top-level of the DT represents the CPU's entire view of the address space and has #address-cells/#size-cells, so devices get probed there just fine, whether they're addressed MMIO devices or not.
A message that is not in the archive (sent off-list or not yet received): [email protected]
Quoted 14 lines · Stephen Warren
Quoted 13 lines · Rob Herring
Quoted 11 lines · Michal Simek
Hi Rob, Mark, Grant and others,
I want to check with you the location of ARM pmu node I see that
1) highbank and dbx5x0 have it in soc node2) vexpress and tegra have no main bus and pmu is in root like all others devices.
(Any reason no to have main bus? Does it mean that there is no bus or that all
devices are accessible?)
Quoted 8 lines
Quoted 2 lines
That seems really wrong in general. Any memory mapped device is on a bus of some kind. I'm not sure the reasoning. Perhaps Stephen can explain.
I saw no need to have add a bus node (there wasn't one before I started touching DT on Tegra); the top-level of the DT represents the CPU's entire view of the address space and has #address-cells/#size-cells, so devices get probed there just fine, whether they're addressed MMIO devices or not.
The top level doesn't really represent a bus. It is basically all the things that have no hierarchical relationship (cpu, memory, chosen, peripheral buses). The reason to have a bus node is to define "simple-bus"
While I would do it differently, I don't recommend changing it at this point. Although, this could be changed without compatibility issues.
Rob
Quoted 21 lines · Rob Herring
Quoted 11 lines · Michal Simek
Hi Rob, Mark, Grant and others,
I want to check with you the location of ARM pmu node I see that
1) highbank and dbx5x0 have it in soc node2) vexpress and tegra have no main bus and pmu is in root like all others devices.
(Any reason no to have main bus? Does it mean that there is no bus or that all
devices are accessible?)That seems really wrong in general. Any memory mapped device is on a bus of some kind. I'm not sure the reasoning. Perhaps Stephen can explain.
Quoted 5 lines
3) omap2/omap3 have added pmu node to root node(mailing list)
4) Just for completeness no platform has it in the bus.
Quoted 7 lines
Quoted 1 line
That's why I have obvious question what it is proper location for pmu node?
Obviously, highbank is the true and correct way. ;)
The pmu is part of the cpu, so it could be part of /cpus. That may cause problems having non-cpu nodes and it would not get probed (although technically that is a Linux problem and should not influence the DT).
If we were going to allow cpu nodes in /cpus, I'd rather we supported a pmu node in each /cpus/cpuN node. That way the description of heterogeneous clusters would be intuitive (each pmu node representing a single cpu-affine unit rather than the collection of all cpu-affine units). That way describing heterogeneous clusters would become intuitive (cpu affinity would be implicit, and wouldn't have to be described separately as with my proposed binding [1]).
and I'm not sure how you'd handle PMUs which used the same PPI
Quoted 2 lines
Since it is not on a bus, then putting it at the top level probably makes more sense than on a bus.
Agreed. I think this makes the most sense.
Quoted 8 lines
Rob
Quoted 4 lines
Thanks,
Michal
Thanks,
Mark.
[1] http://lists.infradead.org/pipermail/linux-arm-kernel/2012-December/137290.html
A message that is not in the archive (sent off-list or not yet received): 20130114091834.GK19765-NuALmloUBlrZROr8t4l/[email protected]
2013/1/14 Mark Rutland <[email protected]>:
Quoted 30 lines · Rob Herring
Quoted 21 lines · Michal Simek
Quoted 11 lines
Hi Rob, Mark, Grant and others,
I want to check with you the location of ARM pmu node I see that
1) highbank and dbx5x0 have it in soc node2) vexpress and tegra have no main bus and pmu is in root like all others devices.
(Any reason no to have main bus? Does it mean that there is no bus or that all
devices are accessible?)That seems really wrong in general. Any memory mapped device is on a bus of some kind. I'm not sure the reasoning. Perhaps Stephen can explain.
Quoted 5 lines
3) omap2/omap3 have added pmu node to root node(mailing list)
4) Just for completeness no platform has it in the bus.
Quoted 7 lines
Quoted 1 line
That's why I have obvious question what it is proper location for pmu node?
Obviously, highbank is the true and correct way. ;)
The pmu is part of the cpu, so it could be part of /cpus. That may cause problems having non-cpu nodes and it would not get probed (although technically that is a Linux problem and should not influence the DT).
Quoted 8 lines
If we were going to allow cpu nodes in /cpus, I'd rather we supported a pmu node in each /cpus/cpuN node. That way the description of heterogeneous clusters would be intuitive (each pmu node representing a single cpu-affine unit rather than the collection of all cpu-affine units). That way describing heterogeneous clusters would become intuitive (cpu affinity would be implicit, and wouldn't have to be described separately as with my proposed binding [1]).
and I'm not sure how you'd handle PMUs which used the same PPI
This is the same as is done with mpcore private timers which uses the same PPI. Based on gic binding it is solved by 3rd cell (flags) "bits[15:8] PPI interrupt cpu mask"
This also open one more question for me because we have mpcore timers on the bus but they are in mpcore. They should be also moved to /cpu/cpuN node.
ps7_scutimer_0: ps7-scutimer@f8f00600 {
compatible = "xlnx,ps7-scutimer-1.00.a", "arm,cortex-a9-twd-timer";
interrupt-parent = <&ps7_scugic_0>;
interrupts = <1 13 0x0301>;
reg = < 0xf8f00600 0x20 >;
} ;btw: what is the main reason for Soc node name? Because of highbank.dts includes ecx-common.dtsi
where soc is used as bus.
Thanks,
Michal
Signature · 5 lines
Michal Simek, Ing. (M.Eng) w: www.monstr.eu p: +42-0-721842854 Maintainer of Linux kernel - Microblaze cpu - http://www.monstr.eu/fdt/ Maintainer of Linux kernel - Xilinx Zynq ARM architecture Microblaze U-BOOT custodian
A message that is not in the archive (sent off-list or not yet received): CAHTX3dLm-LQzPfbRvaPMbOeTg72pBCy2+KqsnftLJKpgFskW9A-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org
Quoted 38 lines · Michal Simek
2013/1/14 Mark Rutland <[email protected]>:
Quoted 37 lines · Rob Herring
Quoted 21 lines · Michal Simek
Quoted 11 lines
Hi Rob, Mark, Grant and others,
I want to check with you the location of ARM pmu node I see that
1) highbank and dbx5x0 have it in soc node2) vexpress and tegra have no main bus and pmu is in root like all others devices.
(Any reason no to have main bus? Does it mean that there is no bus or that all
devices are accessible?)That seems really wrong in general. Any memory mapped device is on a bus of some kind. I'm not sure the reasoning. Perhaps Stephen can explain.
Quoted 5 lines
3) omap2/omap3 have added pmu node to root node(mailing list)
4) Just for completeness no platform has it in the bus.
Quoted 7 lines
Quoted 1 line
That's why I have obvious question what it is proper location for pmu node?
Obviously, highbank is the true and correct way. ;)
The pmu is part of the cpu, so it could be part of /cpus. That may cause problems having non-cpu nodes and it would not get probed (although technically that is a Linux problem and should not influence the DT).
If we were going to allow cpu nodes in /cpus, I'd rather we supported a pmu node in each /cpus/cpuN node. That way the description of heterogeneous clusters would be intuitive (each pmu node representing a single cpu-affine unit rather than the collection of all cpu-affine units). That way describing heterogeneous clusters would become intuitive (cpu affinity would be implicit, and wouldn't have to be described separately as with my proposed binding [1]).
Quoted 5 lines
Quoted 1 line
and I'm not sure how you'd handle PMUs which used the same PPI
This is the same as is done with mpcore private timers which uses the same PPI. Based on gic binding it is solved by 3rd cell (flags) "bits[15:8] PPI interrupt cpu mask"
What I meant was that for PPIs, you have to use the percpu_irq functions, requesting each PPI irq once globally, then enabling it on a subset of all cores. You have to be very careful to ensure you don't attempt to request the same PPI twice. For example you might have different PPIs in different clusters, and you have no guarantee that the nodes sharing the same PPI are grouped together in any consistent order. Ensuring that you've dealt with all nodes and not double-requested an irq is going to get messy.
Quoted 2 lines
This also open one more question for me because we have mpcore timers on the bus but they are in mpcore. They should be also moved to /cpu/cpuN node.
If we're doing this it'd probably be good to have some common framework with the PMU code for handling both cpu-affine description and global description in the root of the tree. We have to be careful to ensure we don't break current device trees.
Quoted 9 lines
ps7_scutimer_0: ps7-scutimer@f8f00600 {
compatible = "xlnx,ps7-scutimer-1.00.a", "arm,cortex-a9-twd-timer";
interrupt-parent = <&ps7_scugic_0>;
interrupts = <1 13 0x0301>;
reg = < 0xf8f00600 0x20 >;
} ;Quoted 15 lines
btw: what is the main reason for Soc node name? Because of
highbank.dtsincludesecx-common.dtsi
where soc is used as bus.Thanks,
MichalSignature · 5 lines
Michal Simek, Ing. (M.Eng) w: www.monstr.eu p: +42-0-721842854 Maintainer of Linux kernel - Microblaze cpu - http://www.monstr.eu/fdt/ Maintainer of Linux kernel - Xilinx Zynq ARM architecture Microblaze U-BOOT custodian
Thanks,
Mark.