Add the 2nd core(core 1) of MT8195 dual-core SCP to devicetree file.
Reserve some SRAM spaces for the core 1 image.
Signed-off-by: Tinghan Shen <tinghan.shen@mediatek.com>
---
arch/arm64/boot/dts/mediatek/mt8195.dtsi | 14 +++++++++++++-
1 file changed, 13 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/mediatek/mt8195.dtsi b/arch/arm64/boot/dts/mediatek/mt8195.dtsi
index 905d1a90b406..48d457bd39b8 100644
--- a/arch/arm64/boot/dts/mediatek/mt8195.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8195.dtsi
@@ -760,12 +760,24 @@
scp: scp@10500000 {
compatible = "mediatek,mt8195-scp";
- reg = <0 0x10500000 0 0x100000>,
+ reg = <0 0x10500000 0 0xa0000>,
<0 0x10720000 0 0xe0000>,
<0 0x10700000 0 0x8000>;
reg-names = "sram", "cfg", "l1tcm";
interrupts = <GIC_SPI 462 IRQ_TYPE_LEVEL_HIGH 0>;
status = "disabled";
+
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges = <0x105a0000 0 0x105a0000 0x20000>;
+
+ scp_c1: scp-c1@105a0000 {
+ compatible = "mediatek,mt8195-scp-core";
+ reg = <0x105a0000 0x20000>;
+ reg-names = "sram";
+ interrupts = <GIC_SPI 463 IRQ_TYPE_LEVEL_HIGH 0>;
+ status = "disabled";
+ };
};
scp_adsp: clock-controller@10720000 {
--
2.18.0
Il 27/09/22 04:55, Tinghan Shen ha scritto:
> Add the 2nd core(core 1) of MT8195 dual-core SCP to devicetree file.
> Reserve some SRAM spaces for the core 1 image.
>
> Signed-off-by: Tinghan Shen <tinghan.shen@mediatek.com>
> ---
> arch/arm64/boot/dts/mediatek/mt8195.dtsi | 14 +++++++++++++-
> 1 file changed, 13 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm64/boot/dts/mediatek/mt8195.dtsi b/arch/arm64/boot/dts/mediatek/mt8195.dtsi
> index 905d1a90b406..48d457bd39b8 100644
> --- a/arch/arm64/boot/dts/mediatek/mt8195.dtsi
> +++ b/arch/arm64/boot/dts/mediatek/mt8195.dtsi
> @@ -760,12 +760,24 @@
>
> scp: scp@10500000 {
> compatible = "mediatek,mt8195-scp";
> - reg = <0 0x10500000 0 0x100000>,
> + reg = <0 0x10500000 0 0xa0000>,
> <0 0x10720000 0 0xe0000>,
> <0 0x10700000 0 0x8000>;
> reg-names = "sram", "cfg", "l1tcm";
> interrupts = <GIC_SPI 462 IRQ_TYPE_LEVEL_HIGH 0>;
> status = "disabled";
> +
> + #address-cells = <1>;
> + #size-cells = <1>;
> + ranges = <0x105a0000 0 0x105a0000 0x20000>;
> +
> + scp_c1: scp-c1@105a0000 {
> + compatible = "mediatek,mt8195-scp-core";
> + reg = <0x105a0000 0x20000>;
> + reg-names = "sram";
> + interrupts = <GIC_SPI 463 IRQ_TYPE_LEVEL_HIGH 0>;
> + status = "disabled";
> + };
I think that the best way of describing a dual-core SCP in devicetree would
be either something like:
scp: scp@10500000 {
compatible = "mediatek,mt8195-scp";
reg = <0 0x10500000 0 0xa0000>, <0 0x105a0000 0 0x20000>,
<0 0x10720000 0 0xe0000>, <0 0x10700000 0 0x8000>;
reg-names = "sram", "sram-c1", "cfg", "l1tcm";
interrupts = <GIC_SPI 462 IRQ_TYPE_LEVEL_HIGH 0>,
<GIC_SPI 463 IRQ_TYPE_LEVEL_HIGH 0>;
status = "disabled";
};
...but that may pose an issue when trying to assign different (or more instances
of the same) subnode(s) to each core... for which, I'd be more for something like:
scp: scp@10500000 {
compatible = "mediatek,mt8195-scp";
reg = <0 0x10720000 0 0xe0000>, <0 0x10700000 0 0x8000>;
reg-names = "cfg", "l1tcm";
#address-cells = <1>;
#size-cells = <1>;
ranges = <0 0 0x10500000 0x100000>;
status = "disabled";
scp_c0: scp-core@0 {
compatible = "mediatek,mt8195-scp-core";
reg = <0x0 0xa0000>;
reg-names = "sram";
interrupts = <GIC_SPI 462 IRQ_TYPE_LEVEL_HIGH 0>;
};
scp_c1: scp-core@a0000 {
compatible = "mediatek,mt8195-scp-core";
reg = <0xa0000 0x20000>;
reg-names = "sram";
interrupts = <GIC_SPI 463 IRQ_TYPE_LEVEL_HIGH 0>;
};
};
Regards,
Angelo
On Tue, 2022-09-27 at 13:01 +0200, AngeloGioacchino Del Regno wrote:
> Il 27/09/22 04:55, Tinghan Shen ha scritto:
> > Add the 2nd core(core 1) of MT8195 dual-core SCP to devicetree file.
> > Reserve some SRAM spaces for the core 1 image.
> >
> > Signed-off-by: Tinghan Shen <tinghan.shen@mediatek.com>
> > ---
> > arch/arm64/boot/dts/mediatek/mt8195.dtsi | 14 +++++++++++++-
> > 1 file changed, 13 insertions(+), 1 deletion(-)
> >
> > diff --git a/arch/arm64/boot/dts/mediatek/mt8195.dtsi b/arch/arm64/boot/dts/mediatek/mt8195.dtsi
> > index 905d1a90b406..48d457bd39b8 100644
> > --- a/arch/arm64/boot/dts/mediatek/mt8195.dtsi
> > +++ b/arch/arm64/boot/dts/mediatek/mt8195.dtsi
> > @@ -760,12 +760,24 @@
> >
> > scp: scp@10500000 {
> > compatible = "mediatek,mt8195-scp";
> > - reg = <0 0x10500000 0 0x100000>,
> > + reg = <0 0x10500000 0 0xa0000>,
> > <0 0x10720000 0 0xe0000>,
> > <0 0x10700000 0 0x8000>;
> > reg-names = "sram", "cfg", "l1tcm";
> > interrupts = <GIC_SPI 462 IRQ_TYPE_LEVEL_HIGH 0>;
> > status = "disabled";
> > +
> > + #address-cells = <1>;
> > + #size-cells = <1>;
> > + ranges = <0x105a0000 0 0x105a0000 0x20000>;
> > +
> > + scp_c1: scp-c1@105a0000 {
> > + compatible = "mediatek,mt8195-scp-core";
> > + reg = <0x105a0000 0x20000>;
> > + reg-names = "sram";
> > + interrupts = <GIC_SPI 463 IRQ_TYPE_LEVEL_HIGH 0>;
> > + status = "disabled";
> > + };
>
> I think that the best way of describing a dual-core SCP in devicetree would
> be either something like:
>
> scp: scp@10500000 {
> compatible = "mediatek,mt8195-scp";
> reg = <0 0x10500000 0 0xa0000>, <0 0x105a0000 0 0x20000>,
> <0 0x10720000 0 0xe0000>, <0 0x10700000 0 0x8000>;
> reg-names = "sram", "sram-c1", "cfg", "l1tcm";
> interrupts = <GIC_SPI 462 IRQ_TYPE_LEVEL_HIGH 0>,
> <GIC_SPI 463 IRQ_TYPE_LEVEL_HIGH 0>;
> status = "disabled";
> };
>
> ...but that may pose an issue when trying to assign different (or more instances
> of the same) subnode(s) to each core... for which, I'd be more for something like:
>
> scp: scp@10500000 {
> compatible = "mediatek,mt8195-scp";
> reg = <0 0x10720000 0 0xe0000>, <0 0x10700000 0 0x8000>;
> reg-names = "cfg", "l1tcm";
> #address-cells = <1>;
> #size-cells = <1>;
> ranges = <0 0 0x10500000 0x100000>;
> status = "disabled";
>
> scp_c0: scp-core@0 {
> compatible = "mediatek,mt8195-scp-core";
> reg = <0x0 0xa0000>;
> reg-names = "sram";
> interrupts = <GIC_SPI 462 IRQ_TYPE_LEVEL_HIGH 0>;
> };
>
> scp_c1: scp-core@a0000 {
> compatible = "mediatek,mt8195-scp-core";
> reg = <0xa0000 0x20000>;
> reg-names = "sram";
> interrupts = <GIC_SPI 463 IRQ_TYPE_LEVEL_HIGH 0>;
> };
> };
>
> Regards,
> Angelo
>
>
Hi Angelo,
I'm thinking about identifying the cores by the order of the sub nodes,
i.e. core 0 must be the first sub node and core 1 must be the second sub node,
because the scp cores in the example have the same compatible name.
I'm hesitant to make the sub nodes appear in a certain order. Is it appropriate?
Or, would it be more readable to create a new core id property? Or utilizing
different compatble strings for cores? I would appreciat it if you could share your opinion.
--
Best regards,
TingHan
Il 17/01/23 09:19, TingHan Shen (沈廷翰) ha scritto:
> On Tue, 2022-09-27 at 13:01 +0200, AngeloGioacchino Del Regno wrote:
>> Il 27/09/22 04:55, Tinghan Shen ha scritto:
>>> Add the 2nd core(core 1) of MT8195 dual-core SCP to devicetree file.
>>> Reserve some SRAM spaces for the core 1 image.
>>>
>>> Signed-off-by: Tinghan Shen <tinghan.shen@mediatek.com>
>>> ---
>>> arch/arm64/boot/dts/mediatek/mt8195.dtsi | 14 +++++++++++++-
>>> 1 file changed, 13 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/arch/arm64/boot/dts/mediatek/mt8195.dtsi b/arch/arm64/boot/dts/mediatek/mt8195.dtsi
>>> index 905d1a90b406..48d457bd39b8 100644
>>> --- a/arch/arm64/boot/dts/mediatek/mt8195.dtsi
>>> +++ b/arch/arm64/boot/dts/mediatek/mt8195.dtsi
>>> @@ -760,12 +760,24 @@
>>>
>>> scp: scp@10500000 {
>>> compatible = "mediatek,mt8195-scp";
>>> - reg = <0 0x10500000 0 0x100000>,
>>> + reg = <0 0x10500000 0 0xa0000>,
>>> <0 0x10720000 0 0xe0000>,
>>> <0 0x10700000 0 0x8000>;
>>> reg-names = "sram", "cfg", "l1tcm";
>>> interrupts = <GIC_SPI 462 IRQ_TYPE_LEVEL_HIGH 0>;
>>> status = "disabled";
>>> +
>>> + #address-cells = <1>;
>>> + #size-cells = <1>;
>>> + ranges = <0x105a0000 0 0x105a0000 0x20000>;
>>> +
>>> + scp_c1: scp-c1@105a0000 {
>>> + compatible = "mediatek,mt8195-scp-core";
>>> + reg = <0x105a0000 0x20000>;
>>> + reg-names = "sram";
>>> + interrupts = <GIC_SPI 463 IRQ_TYPE_LEVEL_HIGH 0>;
>>> + status = "disabled";
>>> + };
>>
>> I think that the best way of describing a dual-core SCP in devicetree would
>> be either something like:
>>
>> scp: scp@10500000 {
>> compatible = "mediatek,mt8195-scp";
>> reg = <0 0x10500000 0 0xa0000>, <0 0x105a0000 0 0x20000>,
>> <0 0x10720000 0 0xe0000>, <0 0x10700000 0 0x8000>;
>> reg-names = "sram", "sram-c1", "cfg", "l1tcm";
>> interrupts = <GIC_SPI 462 IRQ_TYPE_LEVEL_HIGH 0>,
>> <GIC_SPI 463 IRQ_TYPE_LEVEL_HIGH 0>;
>> status = "disabled";
>> };
>>
>> ...but that may pose an issue when trying to assign different (or more instances
>> of the same) subnode(s) to each core... for which, I'd be more for something like:
>>
>> scp: scp@10500000 {
>> compatible = "mediatek,mt8195-scp";
>> reg = <0 0x10720000 0 0xe0000>, <0 0x10700000 0 0x8000>;
>> reg-names = "cfg", "l1tcm";
>> #address-cells = <1>;
>> #size-cells = <1>;
>> ranges = <0 0 0x10500000 0x100000>;
>> status = "disabled";
>>
>> scp_c0: scp-core@0 {
>> compatible = "mediatek,mt8195-scp-core";
>> reg = <0x0 0xa0000>;
>> reg-names = "sram";
>> interrupts = <GIC_SPI 462 IRQ_TYPE_LEVEL_HIGH 0>;
>> };
>>
>> scp_c1: scp-core@a0000 {
>> compatible = "mediatek,mt8195-scp-core";
>> reg = <0xa0000 0x20000>;
>> reg-names = "sram";
>> interrupts = <GIC_SPI 463 IRQ_TYPE_LEVEL_HIGH 0>;
>> };
>> };
>>
>> Regards,
>> Angelo
>>
>>
> Hi Angelo,
>
> I'm thinking about identifying the cores by the order of the sub nodes,
> i.e. core 0 must be the first sub node and core 1 must be the second sub node,
> because the scp cores in the example have the same compatible name.
>
> I'm hesitant to make the sub nodes appear in a certain order. Is it appropriate?
> Or, would it be more readable to create a new core id property? Or utilizing
> different compatble strings for cores? I would appreciat it if you could share your opinion.
>
>
Assuming that in a future >2 cores architecture only the first core, which I will
call "core 0" for commodity, will have "special treatment" and core 1, 2, 3...N
will always be "interchangeable", I think that something like `mediatek,scp-leader`
would work to identify the first core.
Cheers!
Angelo
© 2016 - 2026 Red Hat, Inc.