| Message ID | 20200820010331.2911-3-s-anna@ti.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | Add C66x & C71x DSP nodes on J721E SoCs | expand |
On 20:03-20200819, Suman Anna wrote: > Add the required 'mboxes' property to both the C66x DSP processors on the > TI J721E common processor board. The mailboxes and some shared memory I am not sure I understand the logic here. The carveout is added to p0 SOM - and the mbox is added to common_proc_board. I am not sure I get the difference. The C66x processors are on the SoC, stack is as follows: - SoC - SoM - Common Proc board I am just wondering if the carveouts and mbox linkage should be in the common processor board? if that makes sense at all? I know we already have other definitions.. Trying to see if we are making it harder to understand the definition than that is necessary.. > are required for running the Remote Processor Messaging (RPMsg) stack > between the host processor and each of the R5Fs. The chosen sub-mailboxes > match the values used in the current firmware images. This can be changed, > if needed, as per the system integration needs after making appropriate > changes on the firmware side as well. > > Signed-off-by: Suman Anna <s-anna@ti.com> > --- > arch/arm64/boot/dts/ti/k3-j721e-common-proc-board.dts | 8 ++++++++ > 1 file changed, 8 insertions(+) > > diff --git a/arch/arm64/boot/dts/ti/k3-j721e-common-proc-board.dts b/arch/arm64/boot/dts/ti/k3-j721e-common-proc-board.dts > index e8fc01d97ada..ff541dc09eca 100644 > --- a/arch/arm64/boot/dts/ti/k3-j721e-common-proc-board.dts > +++ b/arch/arm64/boot/dts/ti/k3-j721e-common-proc-board.dts > @@ -379,6 +379,14 @@ &mailbox0_cluster11 { > status = "disabled"; > }; > > +&c66_0 { > + mboxes = <&mailbox0_cluster3 &mbox_c66_0>; > +}; > + > +&c66_1 { > + mboxes = <&mailbox0_cluster3 &mbox_c66_1>; > +}; > + > &main_sdhci0 { > /* eMMC */ > non-removable; > -- > 2.28.0 >
Hi Nishanth, On 8/20/20 6:42 AM, Nishanth Menon wrote: > On 20:03-20200819, Suman Anna wrote: >> Add the required 'mboxes' property to both the C66x DSP processors on the >> TI J721E common processor board. The mailboxes and some shared memory > > I am not sure I understand the logic here. The carveout is added to > p0 SOM - and the mbox is added to common_proc_board. I am not sure I > get the difference. The C66x processors are on the SoC, stack is as > follows: - SoC - SoM - Common Proc board > > I am just wondering if the carveouts and mbox linkage should be in the > common processor board? if that makes sense at all? I know we already > have other definitions.. Trying to see if we are making it harder to > understand the definition than that is necessary.. In general, I consider these as stuff that needs to be added to the board dts files. You will see that this is what I have followed on all the TI AM57xx/DRA7xx boards. For J721E, we have a weird organization as the memory node, typically a board property, is defined in the som dtsi file, so the reserved memory nodes are also added in the som dtsi file. The convention I followed in general is to have the reserved-memory and memory nodes together. If you think the mailbox nodes should be moved into the SoM dts file, I could do it as a follow-on cleanup series, but would wait for the ABI 3.0 changes to be merged first. regards Suman > >> are required for running the Remote Processor Messaging (RPMsg) stack >> between the host processor and each of the R5Fs. The chosen sub-mailboxes >> match the values used in the current firmware images. This can be changed, >> if needed, as per the system integration needs after making appropriate >> changes on the firmware side as well. >> >> Signed-off-by: Suman Anna <s-anna@ti.com> >> --- >> arch/arm64/boot/dts/ti/k3-j721e-common-proc-board.dts | 8 ++++++++ >> 1 file changed, 8 insertions(+) >> >> diff --git a/arch/arm64/boot/dts/ti/k3-j721e-common-proc-board.dts b/arch/arm64/boot/dts/ti/k3-j721e-common-proc-board.dts >> index e8fc01d97ada..ff541dc09eca 100644 >> --- a/arch/arm64/boot/dts/ti/k3-j721e-common-proc-board.dts >> +++ b/arch/arm64/boot/dts/ti/k3-j721e-common-proc-board.dts >> @@ -379,6 +379,14 @@ &mailbox0_cluster11 { >> status = "disabled"; >> }; >> >> +&c66_0 { >> + mboxes = <&mailbox0_cluster3 &mbox_c66_0>; >> +}; >> + >> +&c66_1 { >> + mboxes = <&mailbox0_cluster3 &mbox_c66_1>; >> +}; >> + >> &main_sdhci0 { >> /* eMMC */ >> non-removable; >> -- >> 2.28.0 >> >
On 08:25-20200820, Suman Anna wrote: [...] > > I am just wondering if the carveouts and mbox linkage should be in the > > common processor board? if that makes sense at all? I know we already > > have other definitions.. Trying to see if we are making it harder to > > understand the definition than that is necessary.. > > In general, I consider these as stuff that needs to be added to the board dts > files. You will see that this is what I have followed on all the TI > AM57xx/DRA7xx boards. For J721E, we have a weird organization as the memory > node, typically a board property, is defined in the som dtsi file, so the > reserved memory nodes are also added in the som dtsi file. The convention I > followed in general is to have the reserved-memory and memory nodes together. > > If you think the mailbox nodes should be moved into the SoM dts file, I could do I think that might make more sense and less confusing. I'd rather leave the processor board dts for more signal and interface hookup related topics as it is done right now. if we do endup with too many SoM duplication, then we should consider it's own dtsi > it as a follow-on cleanup series, but would wait for the ABI 3.0 changes to be > merged first. Of course. We are expecting this to be part of rc2, please rebase and post once the tag is out. next-20200820 has it already, if you want a pre-look.
Hi Nishanth, On 8/20/20 2:03 PM, Nishanth Menon wrote: > On 08:25-20200820, Suman Anna wrote: > [...] >>> I am just wondering if the carveouts and mbox linkage should be in the >>> common processor board? if that makes sense at all? I know we already >>> have other definitions.. Trying to see if we are making it harder to >>> understand the definition than that is necessary.. >> >> In general, I consider these as stuff that needs to be added to the board dts >> files. You will see that this is what I have followed on all the TI >> AM57xx/DRA7xx boards. For J721E, we have a weird organization as the memory >> node, typically a board property, is defined in the som dtsi file, so the >> reserved memory nodes are also added in the som dtsi file. The convention I >> followed in general is to have the reserved-memory and memory nodes together. >> >> If you think the mailbox nodes should be moved into the SoM dts file, I could do > > I think that might make more sense and less confusing. I'd rather > leave the processor board dts for more signal and interface hookup > related topics as it is done right now. if we do endup with too many > SoM duplication, then we should consider it's own dtsi > >> it as a follow-on cleanup series, but would wait for the ABI 3.0 changes to be >> merged first. > > Of course. We are expecting this to be part of rc2, please rebase and > post once the tag is out. next-20200820 has it already, if you want a > pre-look. > So, the ABI 3.0 changes are not part of -rc2, so, I cannot move the unrelated mailbox nodes/cleanup without conflicting with that series. Are you ok if I just move these nodes into the SoM dtsi file? regards Suman
On 17:00-20200824, Suman Anna wrote: > Hi Nishanth, > > On 8/20/20 2:03 PM, Nishanth Menon wrote: > > On 08:25-20200820, Suman Anna wrote: > > [...] > >>> I am just wondering if the carveouts and mbox linkage should be in the > >>> common processor board? if that makes sense at all? I know we already > >>> have other definitions.. Trying to see if we are making it harder to > >>> understand the definition than that is necessary.. > >> > >> In general, I consider these as stuff that needs to be added to the board dts > >> files. You will see that this is what I have followed on all the TI > >> AM57xx/DRA7xx boards. For J721E, we have a weird organization as the memory > >> node, typically a board property, is defined in the som dtsi file, so the > >> reserved memory nodes are also added in the som dtsi file. The convention I > >> followed in general is to have the reserved-memory and memory nodes together. > >> > >> If you think the mailbox nodes should be moved into the SoM dts file, I could do > > > > I think that might make more sense and less confusing. I'd rather > > leave the processor board dts for more signal and interface hookup > > related topics as it is done right now. if we do endup with too many > > SoM duplication, then we should consider it's own dtsi > > > >> it as a follow-on cleanup series, but would wait for the ABI 3.0 changes to be > >> merged first. > > > > Of course. We are expecting this to be part of rc2, please rebase and > > post once the tag is out. next-20200820 has it already, if you want a > > pre-look. > > > > So, the ABI 3.0 changes are not part of -rc2, so, I cannot move the unrelated > mailbox nodes/cleanup without conflicting with that series. Are you ok if I just > move these nodes into the SoM dtsi file? Lets introduce things properly: First cleanup rather creating a kludgy intermediate state (half of r5 mbox nodes in proc, half of c6x node in SoM etc).
On 8/25/20 5:42 AM, Nishanth Menon wrote: > On 17:00-20200824, Suman Anna wrote: >> Hi Nishanth, >> >> On 8/20/20 2:03 PM, Nishanth Menon wrote: >>> On 08:25-20200820, Suman Anna wrote: >>> [...] >>>>> I am just wondering if the carveouts and mbox linkage should be in the >>>>> common processor board? if that makes sense at all? I know we already >>>>> have other definitions.. Trying to see if we are making it harder to >>>>> understand the definition than that is necessary.. >>>> >>>> In general, I consider these as stuff that needs to be added to the board dts >>>> files. You will see that this is what I have followed on all the TI >>>> AM57xx/DRA7xx boards. For J721E, we have a weird organization as the memory >>>> node, typically a board property, is defined in the som dtsi file, so the >>>> reserved memory nodes are also added in the som dtsi file. The convention I >>>> followed in general is to have the reserved-memory and memory nodes together. >>>> >>>> If you think the mailbox nodes should be moved into the SoM dts file, I could do >>> >>> I think that might make more sense and less confusing. I'd rather >>> leave the processor board dts for more signal and interface hookup >>> related topics as it is done right now. if we do endup with too many >>> SoM duplication, then we should consider it's own dtsi >>> >>>> it as a follow-on cleanup series, but would wait for the ABI 3.0 changes to be >>>> merged first. >>> >>> Of course. We are expecting this to be part of rc2, please rebase and >>> post once the tag is out. next-20200820 has it already, if you want a >>> pre-look. >>> >> >> So, the ABI 3.0 changes are not part of -rc2, so, I cannot move the unrelated >> mailbox nodes/cleanup without conflicting with that series. Are you ok if I just >> move these nodes into the SoM dtsi file? > > Lets introduce things properly: First cleanup rather creating a > kludgy intermediate state (half of r5 mbox nodes in proc, half of c6x > node in SoM etc). OK, posted a v2 [1] with the cleanup first. It does create a dependency on the pending ABI 3.0 PR. regards Suman [1] https://patchwork.kernel.org/cover/11736095/
diff --git a/arch/arm64/boot/dts/ti/k3-j721e-common-proc-board.dts b/arch/arm64/boot/dts/ti/k3-j721e-common-proc-board.dts index e8fc01d97ada..ff541dc09eca 100644 --- a/arch/arm64/boot/dts/ti/k3-j721e-common-proc-board.dts +++ b/arch/arm64/boot/dts/ti/k3-j721e-common-proc-board.dts @@ -379,6 +379,14 @@ &mailbox0_cluster11 { status = "disabled"; }; +&c66_0 { + mboxes = <&mailbox0_cluster3 &mbox_c66_0>; +}; + +&c66_1 { + mboxes = <&mailbox0_cluster3 &mbox_c66_1>; +}; + &main_sdhci0 { /* eMMC */ non-removable;
Add the required 'mboxes' property to both the C66x DSP processors on the TI J721E common processor board. The mailboxes and some shared memory are required for running the Remote Processor Messaging (RPMsg) stack between the host processor and each of the R5Fs. The chosen sub-mailboxes match the values used in the current firmware images. This can be changed, if needed, as per the system integration needs after making appropriate changes on the firmware side as well. Signed-off-by: Suman Anna <s-anna@ti.com> --- arch/arm64/boot/dts/ti/k3-j721e-common-proc-board.dts | 8 ++++++++ 1 file changed, 8 insertions(+)