On Fri, Nov 1, 2019 at 2:31 PM Stefano Stabellini via System-dt system-dt@lists.openampproject.org wrote:
On Thu, 31 Oct 2019, Nathalie Chan King Choy via System-dt wrote:
Hi all,
Welcome to the OpenAMP system-dt mailing list. You're subscribed because you are either (1) in the OpenAMP TSC list, (2) on the DTE Wednesday call invitation that I received, (3) were on the System DT meeting invitation from Linaro Connect SAN19. Info is at the end of this email on how others can subscribe, or how you can unsubscribe yourself. If you are not sure if your colleague is subscribed & want to make sure they are, as a member of the list, you are able to log in & see who else is a member, from the list info page (use the password reminder in the edit options section to find out your auto-generated password).
The notes from today's call can be found on the OpenAMP wiki at this link: https://github.com/OpenAMP/open-amp/wiki/System-DT-Meeting-Notes-2019#201910...
Hi Nathalie,
Thank you for the notes. I'll take this opportunity to test the new mailing list as well ;-)
In today's call, Stefano presented from the example System DTS file that is attached. It is an early draft based on discussions between Stefano & Grant after Linaro Connect SAN19, related to getting a system DT to work in the default case, without requiring pruning. (I wasn't sure how to allow .dts files in the mailing list content filter, so I changed the extension to .txt)
Action items:
- All: if you can think of simple solution to interrupt-map info duplication, let Stefano know & he will try to add to the example.
- Stefano: Remove ranges from amba_rpu
- Stefano: In next couple weeks, look at GPIO controller extensions & write in detail & send to list so we can discuss.
I am trying to look for the interrupt-related GPIO extensions, and the only one I could find is: socionext,interrupt-ranges from Documentation/devicetree/bindings/gpio/gpio-uniphier.txt:
- socionext,interrupt-ranges: Specifies an interrupt number mapping between this GPIO controller and its interrupt parent, in the form of arbitrary number of <child-interrupt-base parent-interrupt-base length> triplets.
No, there's numerous examples that *should* have used interrupt-map, but invented their own thing.
which is very similar to what we need here, but it looks like a socionext specific property while I seem to recall that Rob said that it was made "standard".
Rob, is this the property you had in mind? Or is there another one?
No. It's '*-map-pass-thru' and in the DT spec. Here's the commit adding it[1]. The motivation for this was GPIO, but the spec was written generically.
Rob
[1] https://github.com/devicetree-org/devicetree-specification/commit/32c96cd64d...
On Fri, 1 Nov 2019, Rob Herring wrote:
Action items:
- All: if you can think of simple solution to interrupt-map info duplication, let Stefano know & he will try to add to the example.
- Stefano: Remove ranges from amba_rpu
- Stefano: In next couple weeks, look at GPIO controller extensions & write in detail & send to list so we can discuss.
I am trying to look for the interrupt-related GPIO extensions, and the only one I could find is: socionext,interrupt-ranges from Documentation/devicetree/bindings/gpio/gpio-uniphier.txt:
- socionext,interrupt-ranges: Specifies an interrupt number mapping between this GPIO controller and its interrupt parent, in the form of arbitrary number of <child-interrupt-base parent-interrupt-base length> triplets.
No, there's numerous examples that *should* have used interrupt-map, but invented their own thing.
which is very similar to what we need here, but it looks like a socionext specific property while I seem to recall that Rob said that it was made "standard".
Rob, is this the property you had in mind? Or is there another one?
No. It's '*-map-pass-thru' and in the DT spec. Here's the commit adding it[1]. The motivation for this was GPIO, but the spec was written generically.
Rob
[1] https://github.com/devicetree-org/devicetree-specification/commit/32c96cd64d...
Thank you, that was very helpful! So if I read it right, it would turn it into this at the interrupt-multiplexer node:
#interrupt-cells = <3>;
/* copy all attributes from children to parents */ interrupt-map-pass-thru = <0xffffffff 0xffffffff 0xffffffff>;
/* mask all childres bits to always match the first 0x0 entries */ interrupt-map-mask = <0x0 0x0 0x0>;
/* child address cells, child interrupt cells, parent, parent interrupt cells */ interrupt-map = <0x0 0x0 0x0 &gic_a72 0x0 0x0 0x0>, <0x0 0x0 0x0 &gic_r5 0x0 0x0 0x0>;
The zero interrupt-map-mask would make sure that any children interrupts would match the two zero interrupt-map entries. The fully set interrupt-map-pass-thru would make sure that any children interrupts numbers and flags would be copied over to the parents.
On Fri, Nov 1, 2019 at 3:30 PM Stefano Stabellini stefano.stabellini@xilinx.com wrote:
On Fri, 1 Nov 2019, Rob Herring wrote:
Action items:
- All: if you can think of simple solution to interrupt-map info duplication, let Stefano know & he will try to add to the example.
- Stefano: Remove ranges from amba_rpu
- Stefano: In next couple weeks, look at GPIO controller extensions & write in detail & send to list so we can discuss.
I am trying to look for the interrupt-related GPIO extensions, and the only one I could find is: socionext,interrupt-ranges from Documentation/devicetree/bindings/gpio/gpio-uniphier.txt:
- socionext,interrupt-ranges: Specifies an interrupt number mapping between this GPIO controller and its interrupt parent, in the form of arbitrary number of <child-interrupt-base parent-interrupt-base length> triplets.
No, there's numerous examples that *should* have used interrupt-map, but invented their own thing.
which is very similar to what we need here, but it looks like a socionext specific property while I seem to recall that Rob said that it was made "standard".
Rob, is this the property you had in mind? Or is there another one?
No. It's '*-map-pass-thru' and in the DT spec. Here's the commit adding it[1]. The motivation for this was GPIO, but the spec was written generically.
Rob
[1] https://github.com/devicetree-org/devicetree-specification/commit/32c96cd64d...
Thank you, that was very helpful! So if I read it right, it would turn it into this at the interrupt-multiplexer node:
#interrupt-cells = <3>; /* copy all attributes from children to parents */ interrupt-map-pass-thru = <0xffffffff 0xffffffff 0xffffffff>; /* mask all childres bits to always match the first 0x0 entries */ interrupt-map-mask = <0x0 0x0 0x0>; /* child address cells, child interrupt cells, parent, parent interrupt cells */ interrupt-map = <0x0 0x0 0x0 &gic_a72 0x0 0x0 0x0>, <0x0 0x0 0x0 &gic_r5 0x0 0x0 0x0>;The zero interrupt-map-mask would make sure that any children interrupts would match the two zero interrupt-map entries. The fully set interrupt-map-pass-thru would make sure that any children interrupts numbers and flags would be copied over to the parents.
I believe that's right. Of course, there's no kernel support for interrupt-map-pass-thru (there is for GPIO), and it in no way solves the problem of which entry to select. A simple way to solve this is to look for 'interrupt-parent' in the /cpus node when not found in the root node. The OS would just have to know which /cpus node to look in. That wouldn't work for existing OSs, but it's not major changes to dts files or OSs. For your case, interrupt-map is not even needed. For the complex case, you'd split interrupt-map for each GIC into each /cpus node.
Rob
system-dt@lists.openampproject.org
-
Rob Herring -
Stefano Stabellini