Add a basic GPU node and opp table for mt8183.
The binding we use with out-of-tree Mali drivers includes more
clocks, I assume this would be required eventually if we have an
in-tree driver:
clocks =
<&topckgen CLK_TOP_MFGPLL_CK>,
<&topckgen CLK_TOP_MUX_MFG>,
<&clk26m>,
<&mfgcfg CLK_MFG_BG3D>;
clock-names =
"clk_main_parent",
"clk_mux",
"clk_sub_parent",
"subsys_mfg_cg";
Signed-off-by: Nicolas Boichat <[email protected]>
---
Upstreaming what matches existing bindings from our Chromium OS tree:
https://chromium.googlesource.com/chromiumos/third_party/kernel/+/chromeos-4.19/arch/arm64/boot/dts/mediatek/mt8183.dtsi#1348
The evb part of this change depends on this patch to add PMIC dtsi:
https://patchwork.kernel.org/patch/10928161/
arch/arm64/boot/dts/mediatek/mt8183-evb.dts | 7 ++
arch/arm64/boot/dts/mediatek/mt8183.dtsi | 103 ++++++++++++++++++++
2 files changed, 110 insertions(+)
diff --git a/arch/arm64/boot/dts/mediatek/mt8183-evb.dts b/arch/arm64/boot/dts/mediatek/mt8183-evb.dts
index 1fb195c683c3d01..200d8e65a6368a1 100644
--- a/arch/arm64/boot/dts/mediatek/mt8183-evb.dts
+++ b/arch/arm64/boot/dts/mediatek/mt8183-evb.dts
@@ -7,6 +7,7 @@
/dts-v1/;
#include "mt8183.dtsi"
+#include "mt6358.dtsi"
/ {
model = "MediaTek MT8183 evaluation board";
@@ -30,6 +31,12 @@
status = "okay";
};
+&gpu {
+ supply-names = "mali", "mali_sram";
+ mali-supply = <&mt6358_vgpu_reg>;
+ mali_sram-supply = <&mt6358_vsram_gpu_reg>;
+};
+
&i2c0 {
pinctrl-names = "default";
pinctrl-0 = <&i2c_pins_0>;
diff --git a/arch/arm64/boot/dts/mediatek/mt8183.dtsi b/arch/arm64/boot/dts/mediatek/mt8183.dtsi
index 97f84aa9fc6e1c1..8ea548a762ea252 100644
--- a/arch/arm64/boot/dts/mediatek/mt8183.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8183.dtsi
@@ -579,6 +579,109 @@
#clock-cells = <1>;
};
+ gpu: mali@13040000 {
+ compatible = "mediatek,mt8183-mali", "arm,mali-bifrost";
+ reg = <0 0x13040000 0 0x4000>;
+ interrupts =
+ <GIC_SPI 280 IRQ_TYPE_LEVEL_LOW>,
+ <GIC_SPI 279 IRQ_TYPE_LEVEL_LOW>,
+ <GIC_SPI 278 IRQ_TYPE_LEVEL_LOW>;
+ interrupt-names = "job", "mmu", "gpu";
+
+ clocks = <&topckgen CLK_TOP_MFGPLL_CK>;
+ power-domains =
+ <&scpsys MT8183_POWER_DOMAIN_MFG_CORE0>,
+ <&scpsys MT8183_POWER_DOMAIN_MFG_CORE1>,
+ <&scpsys MT8183_POWER_DOMAIN_MFG_2D>;
+
+ operating-points-v2 = <&gpu_opp_table>;
+ };
+
+ gpu_opp_table: opp_table0 {
+ compatible = "operating-points-v2";
+ opp-shared;
+
+ opp-300000000 {
+ opp-hz = /bits/ 64 <300000000>;
+ opp-microvolt = <625000>, <850000>;
+ };
+
+ opp-320000000 {
+ opp-hz = /bits/ 64 <320000000>;
+ opp-microvolt = <631250>, <850000>;
+ };
+
+ opp-340000000 {
+ opp-hz = /bits/ 64 <340000000>;
+ opp-microvolt = <637500>, <850000>;
+ };
+
+ opp-360000000 {
+ opp-hz = /bits/ 64 <360000000>;
+ opp-microvolt = <643750>, <850000>;
+ };
+
+ opp-380000000 {
+ opp-hz = /bits/ 64 <380000000>;
+ opp-microvolt = <650000>, <850000>;
+ };
+
+ opp-400000000 {
+ opp-hz = /bits/ 64 <400000000>;
+ opp-microvolt = <656250>, <850000>;
+ };
+
+ opp-420000000 {
+ opp-hz = /bits/ 64 <420000000>;
+ opp-microvolt = <662500>, <850000>;
+ };
+
+ opp-460000000 {
+ opp-hz = /bits/ 64 <460000000>;
+ opp-microvolt = <675000>, <850000>;
+ };
+
+ opp-500000000 {
+ opp-hz = /bits/ 64 <500000000>;
+ opp-microvolt = <687500>, <850000>;
+ };
+
+ opp-540000000 {
+ opp-hz = /bits/ 64 <540000000>;
+ opp-microvolt = <700000>, <850000>;
+ };
+
+ opp-580000000 {
+ opp-hz = /bits/ 64 <580000000>;
+ opp-microvolt = <712500>, <850000>;
+ };
+
+ opp-620000000 {
+ opp-hz = /bits/ 64 <620000000>;
+ opp-microvolt = <725000>, <850000>;
+ };
+
+ opp-653000000 {
+ opp-hz = /bits/ 64 <653000000>;
+ opp-microvolt = <743750>, <850000>;
+ };
+
+ opp-698000000 {
+ opp-hz = /bits/ 64 <698000000>;
+ opp-microvolt = <768750>, <868750>;
+ };
+
+ opp-743000000 {
+ opp-hz = /bits/ 64 <743000000>;
+ opp-microvolt = <793750>, <893750>;
+ };
+
+ opp-800000000 {
+ opp-hz = /bits/ 64 <800000000>;
+ opp-microvolt = <825000>, <925000>;
+ };
+ };
+
mmsys: syscon@14000000 {
compatible = "mediatek,mt8183-mmsys", "syscon";
reg = <0 0x14000000 0 0x1000>;
--
2.23.0.187.g17f5b7556c-goog
On Thu, Sep 5, 2019 at 9:16 AM Nicolas Boichat <[email protected]> wrote:
>
> Add a basic GPU node and opp table for mt8183.
>
> The binding we use with out-of-tree Mali drivers includes more
> clocks, I assume this would be required eventually if we have an
> in-tree driver:
We have an in-tree driver...
> clocks =
> <&topckgen CLK_TOP_MFGPLL_CK>,
> <&topckgen CLK_TOP_MUX_MFG>,
> <&clk26m>,
> <&mfgcfg CLK_MFG_BG3D>;
> clock-names =
> "clk_main_parent",
> "clk_mux",
> "clk_sub_parent",
> "subsys_mfg_cg";
>
> Signed-off-by: Nicolas Boichat <[email protected]>
>
> ---
> Upstreaming what matches existing bindings from our Chromium OS tree:
> https://chromium.googlesource.com/chromiumos/third_party/kernel/+/chromeos-4.19/arch/arm64/boot/dts/mediatek/mt8183.dtsi#1348
>
> The evb part of this change depends on this patch to add PMIC dtsi:
> https://patchwork.kernel.org/patch/10928161/
>
> arch/arm64/boot/dts/mediatek/mt8183-evb.dts | 7 ++
> arch/arm64/boot/dts/mediatek/mt8183.dtsi | 103 ++++++++++++++++++++
> 2 files changed, 110 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/mediatek/mt8183-evb.dts b/arch/arm64/boot/dts/mediatek/mt8183-evb.dts
> index 1fb195c683c3d01..200d8e65a6368a1 100644
> --- a/arch/arm64/boot/dts/mediatek/mt8183-evb.dts
> +++ b/arch/arm64/boot/dts/mediatek/mt8183-evb.dts
> @@ -7,6 +7,7 @@
>
> /dts-v1/;
> #include "mt8183.dtsi"
> +#include "mt6358.dtsi"
>
> / {
> model = "MediaTek MT8183 evaluation board";
> @@ -30,6 +31,12 @@
> status = "okay";
> };
>
> +&gpu {
> + supply-names = "mali", "mali_sram";
> + mali-supply = <&mt6358_vgpu_reg>;
> + mali_sram-supply = <&mt6358_vsram_gpu_reg>;
Not documented. Just 'sram-supply' is enough.
Note that the binding doc queued up for 5.4 has been converted to DT schema.
> +};
> +
> &i2c0 {
> pinctrl-names = "default";
> pinctrl-0 = <&i2c_pins_0>;
> diff --git a/arch/arm64/boot/dts/mediatek/mt8183.dtsi b/arch/arm64/boot/dts/mediatek/mt8183.dtsi
> index 97f84aa9fc6e1c1..8ea548a762ea252 100644
> --- a/arch/arm64/boot/dts/mediatek/mt8183.dtsi
> +++ b/arch/arm64/boot/dts/mediatek/mt8183.dtsi
> @@ -579,6 +579,109 @@
> #clock-cells = <1>;
> };
>
> + gpu: mali@13040000 {
gpu@...
> + compatible = "mediatek,mt8183-mali", "arm,mali-bifrost";
You need to add this compatible string too.
> + reg = <0 0x13040000 0 0x4000>;
> + interrupts =
> + <GIC_SPI 280 IRQ_TYPE_LEVEL_LOW>,
> + <GIC_SPI 279 IRQ_TYPE_LEVEL_LOW>,
> + <GIC_SPI 278 IRQ_TYPE_LEVEL_LOW>;
> + interrupt-names = "job", "mmu", "gpu";
> +
> + clocks = <&topckgen CLK_TOP_MFGPLL_CK>;
> + power-domains =
> + <&scpsys MT8183_POWER_DOMAIN_MFG_CORE0>,
> + <&scpsys MT8183_POWER_DOMAIN_MFG_CORE1>,
> + <&scpsys MT8183_POWER_DOMAIN_MFG_2D>;
This needs to be documented too.
> +
> + operating-points-v2 = <&gpu_opp_table>;
> + };
> +
> + gpu_opp_table: opp_table0 {
> + compatible = "operating-points-v2";
> + opp-shared;
> +
> + opp-300000000 {
> + opp-hz = /bits/ 64 <300000000>;
> + opp-microvolt = <625000>, <850000>;
> + };
> +
> + opp-320000000 {
> + opp-hz = /bits/ 64 <320000000>;
> + opp-microvolt = <631250>, <850000>;
> + };
> +
> + opp-340000000 {
> + opp-hz = /bits/ 64 <340000000>;
> + opp-microvolt = <637500>, <850000>;
> + };
> +
> + opp-360000000 {
> + opp-hz = /bits/ 64 <360000000>;
> + opp-microvolt = <643750>, <850000>;
> + };
> +
> + opp-380000000 {
> + opp-hz = /bits/ 64 <380000000>;
> + opp-microvolt = <650000>, <850000>;
> + };
> +
> + opp-400000000 {
> + opp-hz = /bits/ 64 <400000000>;
> + opp-microvolt = <656250>, <850000>;
> + };
> +
> + opp-420000000 {
> + opp-hz = /bits/ 64 <420000000>;
> + opp-microvolt = <662500>, <850000>;
> + };
> +
> + opp-460000000 {
> + opp-hz = /bits/ 64 <460000000>;
> + opp-microvolt = <675000>, <850000>;
> + };
> +
> + opp-500000000 {
> + opp-hz = /bits/ 64 <500000000>;
> + opp-microvolt = <687500>, <850000>;
> + };
> +
> + opp-540000000 {
> + opp-hz = /bits/ 64 <540000000>;
> + opp-microvolt = <700000>, <850000>;
> + };
> +
> + opp-580000000 {
> + opp-hz = /bits/ 64 <580000000>;
> + opp-microvolt = <712500>, <850000>;
> + };
> +
> + opp-620000000 {
> + opp-hz = /bits/ 64 <620000000>;
> + opp-microvolt = <725000>, <850000>;
> + };
> +
> + opp-653000000 {
> + opp-hz = /bits/ 64 <653000000>;
> + opp-microvolt = <743750>, <850000>;
> + };
> +
> + opp-698000000 {
> + opp-hz = /bits/ 64 <698000000>;
> + opp-microvolt = <768750>, <868750>;
> + };
> +
> + opp-743000000 {
> + opp-hz = /bits/ 64 <743000000>;
> + opp-microvolt = <793750>, <893750>;
> + };
> +
> + opp-800000000 {
> + opp-hz = /bits/ 64 <800000000>;
> + opp-microvolt = <825000>, <925000>;
> + };
Okay, but I seriously doubt the OPP selection logic is sophisticated
enough or will ever be to use all these levels...
> + };
> +
> mmsys: syscon@14000000 {
> compatible = "mediatek,mt8183-mmsys", "syscon";
> reg = <0 0x14000000 0 0x1000>;
> --
> 2.23.0.187.g17f5b7556c-goog
>
Thanks for the quick review!
On Thu, Sep 5, 2019 at 5:09 PM Rob Herring <[email protected]> wrote:
>
> On Thu, Sep 5, 2019 at 9:16 AM Nicolas Boichat <[email protected]> wrote:
> >
> > Add a basic GPU node and opp table for mt8183.
> >
> > The binding we use with out-of-tree Mali drivers includes more
> > clocks, I assume this would be required eventually if we have an
> > in-tree driver:
>
> We have an in-tree driver...
Right but AFAICT it does not support Bifrost GPU (yet?).
>
> > clocks =
> > <&topckgen CLK_TOP_MFGPLL_CK>,
> > <&topckgen CLK_TOP_MUX_MFG>,
> > <&clk26m>,
> > <&mfgcfg CLK_MFG_BG3D>;
> > clock-names =
> > "clk_main_parent",
> > "clk_mux",
> > "clk_sub_parent",
> > "subsys_mfg_cg";
Do you think we should add those to the binding document? May not be
easy to match what the amlogic binding does (I'm not sure to
understand the details of this device, but I can dig further/ask).
> >
> > Signed-off-by: Nicolas Boichat <[email protected]>
> >
> > ---
> > Upstreaming what matches existing bindings from our Chromium OS tree:
> > https://chromium.googlesource.com/chromiumos/third_party/kernel/+/chromeos-4.19/arch/arm64/boot/dts/mediatek/mt8183.dtsi#1348
> >
> > The evb part of this change depends on this patch to add PMIC dtsi:
> > https://patchwork.kernel.org/patch/10928161/
> >
> > arch/arm64/boot/dts/mediatek/mt8183-evb.dts | 7 ++
> > arch/arm64/boot/dts/mediatek/mt8183.dtsi | 103 ++++++++++++++++++++
> > 2 files changed, 110 insertions(+)
> >
> > diff --git a/arch/arm64/boot/dts/mediatek/mt8183-evb.dts b/arch/arm64/boot/dts/mediatek/mt8183-evb.dts
> > index 1fb195c683c3d01..200d8e65a6368a1 100644
> > --- a/arch/arm64/boot/dts/mediatek/mt8183-evb.dts
> > +++ b/arch/arm64/boot/dts/mediatek/mt8183-evb.dts
> > @@ -7,6 +7,7 @@
> >
> > /dts-v1/;
> > #include "mt8183.dtsi"
> > +#include "mt6358.dtsi"
> >
> > / {
> > model = "MediaTek MT8183 evaluation board";
> > @@ -30,6 +31,12 @@
> > status = "okay";
> > };
> >
> > +&gpu {
> > + supply-names = "mali", "mali_sram";
> > + mali-supply = <&mt6358_vgpu_reg>;
> > + mali_sram-supply = <&mt6358_vsram_gpu_reg>;
>
> Not documented. Just 'sram-supply' is enough.
Will fix.
> Note that the binding doc queued up for 5.4 has been converted to DT schema.
Yep I see that in linux-next.
>
> > +};
> > +
> > &i2c0 {
> > pinctrl-names = "default";
> > pinctrl-0 = <&i2c_pins_0>;
> > diff --git a/arch/arm64/boot/dts/mediatek/mt8183.dtsi b/arch/arm64/boot/dts/mediatek/mt8183.dtsi
> > index 97f84aa9fc6e1c1..8ea548a762ea252 100644
> > --- a/arch/arm64/boot/dts/mediatek/mt8183.dtsi
> > +++ b/arch/arm64/boot/dts/mediatek/mt8183.dtsi
> > @@ -579,6 +579,109 @@
> > #clock-cells = <1>;
> > };
> >
> > + gpu: mali@13040000 {
>
> gpu@...
>
> > + compatible = "mediatek,mt8183-mali", "arm,mali-bifrost";
>
> You need to add this compatible string too.
Will do.
>
> > + reg = <0 0x13040000 0 0x4000>;
> > + interrupts =
> > + <GIC_SPI 280 IRQ_TYPE_LEVEL_LOW>,
> > + <GIC_SPI 279 IRQ_TYPE_LEVEL_LOW>,
> > + <GIC_SPI 278 IRQ_TYPE_LEVEL_LOW>;
> > + interrupt-names = "job", "mmu", "gpu";
> > +
> > + clocks = <&topckgen CLK_TOP_MFGPLL_CK>;
> > + power-domains =
> > + <&scpsys MT8183_POWER_DOMAIN_MFG_CORE0>,
> > + <&scpsys MT8183_POWER_DOMAIN_MFG_CORE1>,
> > + <&scpsys MT8183_POWER_DOMAIN_MFG_2D>;
>
> This needs to be documented too.
I see that Documentation/devicetree/bindings/gpu/arm,mali-midgard.yaml
has power-domains in the example both not in the yaml, is that
expected?
>
> > +
> > + operating-points-v2 = <&gpu_opp_table>;
> > + };
> > +
> > + gpu_opp_table: opp_table0 {
> > + compatible = "operating-points-v2";
> > + opp-shared;
> > +
> > + opp-300000000 {
> > + opp-hz = /bits/ 64 <300000000>;
> > + opp-microvolt = <625000>, <850000>;
> > + };
> > +
> > + opp-320000000 {
> > + opp-hz = /bits/ 64 <320000000>;
> > + opp-microvolt = <631250>, <850000>;
> > + };
> > +
> > + opp-340000000 {
> > + opp-hz = /bits/ 64 <340000000>;
> > + opp-microvolt = <637500>, <850000>;
> > + };
> > +
> > + opp-360000000 {
> > + opp-hz = /bits/ 64 <360000000>;
> > + opp-microvolt = <643750>, <850000>;
> > + };
> > +
> > + opp-380000000 {
> > + opp-hz = /bits/ 64 <380000000>;
> > + opp-microvolt = <650000>, <850000>;
> > + };
> > +
> > + opp-400000000 {
> > + opp-hz = /bits/ 64 <400000000>;
> > + opp-microvolt = <656250>, <850000>;
> > + };
> > +
> > + opp-420000000 {
> > + opp-hz = /bits/ 64 <420000000>;
> > + opp-microvolt = <662500>, <850000>;
> > + };
> > +
> > + opp-460000000 {
> > + opp-hz = /bits/ 64 <460000000>;
> > + opp-microvolt = <675000>, <850000>;
> > + };
> > +
> > + opp-500000000 {
> > + opp-hz = /bits/ 64 <500000000>;
> > + opp-microvolt = <687500>, <850000>;
> > + };
> > +
> > + opp-540000000 {
> > + opp-hz = /bits/ 64 <540000000>;
> > + opp-microvolt = <700000>, <850000>;
> > + };
> > +
> > + opp-580000000 {
> > + opp-hz = /bits/ 64 <580000000>;
> > + opp-microvolt = <712500>, <850000>;
> > + };
> > +
> > + opp-620000000 {
> > + opp-hz = /bits/ 64 <620000000>;
> > + opp-microvolt = <725000>, <850000>;
> > + };
> > +
> > + opp-653000000 {
> > + opp-hz = /bits/ 64 <653000000>;
> > + opp-microvolt = <743750>, <850000>;
> > + };
> > +
> > + opp-698000000 {
> > + opp-hz = /bits/ 64 <698000000>;
> > + opp-microvolt = <768750>, <868750>;
> > + };
> > +
> > + opp-743000000 {
> > + opp-hz = /bits/ 64 <743000000>;
> > + opp-microvolt = <793750>, <893750>;
> > + };
> > +
> > + opp-800000000 {
> > + opp-hz = /bits/ 64 <800000000>;
> > + opp-microvolt = <825000>, <925000>;
> > + };
>
> Okay, but I seriously doubt the OPP selection logic is sophisticated
> enough or will ever be to use all these levels...
>
> > + };
> > +
> > mmsys: syscon@14000000 {
> > compatible = "mediatek,mt8183-mmsys", "syscon";
> > reg = <0 0x14000000 0 0x1000>;
> > --
> > 2.23.0.187.g17f5b7556c-goog
> >
On Thu, Sep 5, 2019 at 10:49 AM Nicolas Boichat <[email protected]> wrote:
>
> Thanks for the quick review!
>
> On Thu, Sep 5, 2019 at 5:09 PM Rob Herring <[email protected]> wrote:
> >
> > On Thu, Sep 5, 2019 at 9:16 AM Nicolas Boichat <[email protected]> wrote:
> > >
> > > Add a basic GPU node and opp table for mt8183.
> > >
> > > The binding we use with out-of-tree Mali drivers includes more
> > > clocks, I assume this would be required eventually if we have an
> > > in-tree driver:
> >
> > We have an in-tree driver...
>
> Right but AFAICT it does not support Bifrost GPU (yet?).
It's mostly the mesa userspace side that's missing. The kernel driver
needs the compatible string and page table support[1]. The former
should be enough to access the registers which is typically enough to
sort out an platform specific clock, reset, power issues.
> > > clocks =
> > > <&topckgen CLK_TOP_MFGPLL_CK>,
> > > <&topckgen CLK_TOP_MUX_MFG>,
> > > <&clk26m>,
> > > <&mfgcfg CLK_MFG_BG3D>;
> > > clock-names =
> > > "clk_main_parent",
> > > "clk_mux",
> > > "clk_sub_parent",
> > > "subsys_mfg_cg";
>
> Do you think we should add those to the binding document? May not be
> easy to match what the amlogic binding does (I'm not sure to
> understand the details of this device, but I can dig further/ask).
I somewhat expect this needs more investigation. I'm doubtful that
there's a 26MHz clock going to Mali. Ideally, the clocks are what are
actually connected to the h/w, not just a list of all the clocks
needed on some platform because we fail to manage them elsewhere (like
an interconnect driver). Otherwise we end up with a different list for
every platform.
> > > Signed-off-by: Nicolas Boichat <[email protected]>
> > >
> > > ---
> > > Upstreaming what matches existing bindings from our Chromium OS tree:
> > > https://chromium.googlesource.com/chromiumos/third_party/kernel/+/chromeos-4.19/arch/arm64/boot/dts/mediatek/mt8183.dtsi#1348
> > >
> > > The evb part of this change depends on this patch to add PMIC dtsi:
> > > https://patchwork.kernel.org/patch/10928161/
> > >
> > > arch/arm64/boot/dts/mediatek/mt8183-evb.dts | 7 ++
> > > arch/arm64/boot/dts/mediatek/mt8183.dtsi | 103 ++++++++++++++++++++
> > > 2 files changed, 110 insertions(+)
> > >
> > > diff --git a/arch/arm64/boot/dts/mediatek/mt8183-evb.dts b/arch/arm64/boot/dts/mediatek/mt8183-evb.dts
> > > index 1fb195c683c3d01..200d8e65a6368a1 100644
> > > --- a/arch/arm64/boot/dts/mediatek/mt8183-evb.dts
> > > +++ b/arch/arm64/boot/dts/mediatek/mt8183-evb.dts
> > > @@ -7,6 +7,7 @@
> > >
> > > /dts-v1/;
> > > #include "mt8183.dtsi"
> > > +#include "mt6358.dtsi"
> > >
> > > / {
> > > model = "MediaTek MT8183 evaluation board";
> > > @@ -30,6 +31,12 @@
> > > status = "okay";
> > > };
> > >
> > > +&gpu {
> > > + supply-names = "mali", "mali_sram";
> > > + mali-supply = <&mt6358_vgpu_reg>;
> > > + mali_sram-supply = <&mt6358_vsram_gpu_reg>;
> >
> > Not documented. Just 'sram-supply' is enough.
>
> Will fix.
>
> > Note that the binding doc queued up for 5.4 has been converted to DT schema.
>
> Yep I see that in linux-next.
>
> >
> > > +};
> > > +
> > > &i2c0 {
> > > pinctrl-names = "default";
> > > pinctrl-0 = <&i2c_pins_0>;
> > > diff --git a/arch/arm64/boot/dts/mediatek/mt8183.dtsi b/arch/arm64/boot/dts/mediatek/mt8183.dtsi
> > > index 97f84aa9fc6e1c1..8ea548a762ea252 100644
> > > --- a/arch/arm64/boot/dts/mediatek/mt8183.dtsi
> > > +++ b/arch/arm64/boot/dts/mediatek/mt8183.dtsi
> > > @@ -579,6 +579,109 @@
> > > #clock-cells = <1>;
> > > };
> > >
> > > + gpu: mali@13040000 {
> >
> > gpu@...
> >
> > > + compatible = "mediatek,mt8183-mali", "arm,mali-bifrost";
> >
> > You need to add this compatible string too.
>
> Will do.
>
> >
> > > + reg = <0 0x13040000 0 0x4000>;
> > > + interrupts =
> > > + <GIC_SPI 280 IRQ_TYPE_LEVEL_LOW>,
> > > + <GIC_SPI 279 IRQ_TYPE_LEVEL_LOW>,
> > > + <GIC_SPI 278 IRQ_TYPE_LEVEL_LOW>;
> > > + interrupt-names = "job", "mmu", "gpu";
> > > +
> > > + clocks = <&topckgen CLK_TOP_MFGPLL_CK>;
> > > + power-domains =
> > > + <&scpsys MT8183_POWER_DOMAIN_MFG_CORE0>,
> > > + <&scpsys MT8183_POWER_DOMAIN_MFG_CORE1>,
> > > + <&scpsys MT8183_POWER_DOMAIN_MFG_2D>;
> >
> > This needs to be documented too.
>
> I see that Documentation/devicetree/bindings/gpu/arm,mali-midgard.yaml
> has power-domains in the example both not in the yaml, is that
> expected?
Err, no. Probably some copy-n-paste from utgard.
Rob
[1] https://patchwork.freedesktop.org/patch/304731/
> > > The binding we use with out-of-tree Mali drivers includes more
> > > clocks, I assume this would be required eventually if we have an
> > > in-tree driver:
> >
> > We have an in-tree driver...
>
> Right but AFAICT it does not support Bifrost GPU (yet?).
By the time MT8183 shows up in more concrete devices, it will, certainly
in kernel-space and likely in userspace as well. At present, the DDK can
be modified to run on top of the in-tree Mali drivers, i.e. "Bifrost on
mainline linux-next (+ page table/compatible patches), with blob
userspace".
While the open userspace isn't ready here quite yet, I would definitely
encourage upstream kernel for ChromeOS, since then there's no need to
maintain the out-of-tree GPU driver.
---
More immediately, per Rob's review, it's important that the bindings
accepted upstream work with the in-tree Bifrost driver. Conceptually,
once Mesa supports Bifrost, if I install Debian on a MT8183 board,
everything should just work. I shouldn't need MT-specific changes / need
to change names for the DT. Regardless of which kernel driver you end up
using, minimally sharing the DT is good for everyone :-)
-Alyssa
Thanks Rob and Alyssa.
+Douglas Anderson +Dominik Behr who may be interested (if not already aware)
On Sat, Sep 14, 2019 at 2:17 AM Alyssa Rosenzweig
<[email protected]> wrote:
>
> > > > The binding we use with out-of-tree Mali drivers includes more
> > > > clocks, I assume this would be required eventually if we have an
> > > > in-tree driver:
> > >
> > > We have an in-tree driver...
> >
> > Right but AFAICT it does not support Bifrost GPU (yet?).
>
> By the time MT8183 shows up in more concrete devices, it will, certainly
> in kernel-space and likely in userspace as well. At present, the DDK can
> be modified to run on top of the in-tree Mali drivers, i.e. "Bifrost on
> mainline linux-next (+ page table/compatible patches), with blob
> userspace".
>
> While the open userspace isn't ready here quite yet, I would definitely
> encourage upstream kernel for ChromeOS, since then there's no need to
> maintain the out-of-tree GPU driver.
That's an interesting idea, I had no idea, thanks for the info!
Would that work with midgard as well? We have released hardware with
RK3288/3399, so it might be nice to experiment with these first.
>
> ---
>
> More immediately, per Rob's review, it's important that the bindings
> accepted upstream work with the in-tree Bifrost driver. Conceptually,
> once Mesa supports Bifrost, if I install Debian on a MT8183 board,
> everything should just work. I shouldn't need MT-specific changes / need
> to change names for the DT. Regardless of which kernel driver you end up
> using, minimally sharing the DT is good for everyone :-)
Yes. I'll try to dig further with MTK, but this may take some time.
>
> -Alyssa
> > By the time MT8183 shows up in more concrete devices, it will, certainly
> > in kernel-space and likely in userspace as well. At present, the DDK can
> > be modified to run on top of the in-tree Mali drivers, i.e. "Bifrost on
> > mainline linux-next (+ page table/compatible patches), with blob
> > userspace".
> >
> > While the open userspace isn't ready here quite yet, I would definitely
> > encourage upstream kernel for ChromeOS, since then there's no need to
> > maintain the out-of-tree GPU driver.
>
> That's an interesting idea, I had no idea, thanks for the info!
>
> Would that work with midgard as well? We have released hardware with
> RK3288/3399, so it might be nice to experiment with these first.
Yes, the above would work with Midgard as well with no changes needed.
Ping Steven about thtat (CC'd).
> > More immediately, per Rob's review, it's important that the bindings
> > accepted upstream work with the in-tree Bifrost driver. Conceptually,
> > once Mesa supports Bifrost, if I install Debian on a MT8183 board,
> > everything should just work. I shouldn't need MT-specific changes / need
> > to change names for the DT. Regardless of which kernel driver you end up
> > using, minimally sharing the DT is good for everyone :-)
>
> Yes. I'll try to dig further with MTK, but this may take some time.
Thank you!
On 19/09/2019 13:32, Alyssa Rosenzweig wrote:
>>> By the time MT8183 shows up in more concrete devices, it will, certainly
>>> in kernel-space and likely in userspace as well. At present, the DDK can
>>> be modified to run on top of the in-tree Mali drivers, i.e. "Bifrost on
>>> mainline linux-next (+ page table/compatible patches), with blob
>>> userspace".
Actually most(?) Bifrost GPUs support the "legacy" 'LPAE-ish' page table
format. So the only kernel change *required* is adding the compatible
string (and any SoC-specific quirks).
The support for "blob-on-Panfrost" is currently an experimental internal
investigation. So I can't make any promises about it ever being released
publicly.
>>> While the open userspace isn't ready here quite yet, I would definitely
>>> encourage upstream kernel for ChromeOS, since then there's no need to
>>> maintain the out-of-tree GPU driver.
>>
>> That's an interesting idea, I had no idea, thanks for the info!
>>
>> Would that work with midgard as well? We have released hardware with
>> RK3288/3399, so it might be nice to experiment with these first.
>
> Yes, the above would work with Midgard as well with no changes needed.
> Ping Steven about thtat (CC'd).
Indeed since it's the same kernel driver the same compatibility layer
can be used to run Midgard DDK blob on Panfrost. Although given the
progress that has already occurred with the Mesa Panfrost user space you
might be able to simply switch to a completely open stack (available now).
Again I'm afraid I'm not in a position to give any guarantees that my
prototype blob-on-Panfrost work will actually be released or timescales
of when. However since the current focus internally is on newer GPUs I'm
less confident that there will be interest for Midgard DDK on Panfrost.
Steve
>>> More immediately, per Rob's review, it's important that the bindings
>>> accepted upstream work with the in-tree Bifrost driver. Conceptually,
>>> once Mesa supports Bifrost, if I install Debian on a MT8183 board,
>>> everything should just work. I shouldn't need MT-specific changes / need
>>> to change names for the DT. Regardless of which kernel driver you end up
>>> using, minimally sharing the DT is good for everyone :-)
>>
>> Yes. I'll try to dig further with MTK, but this may take some time.
>
> Thank you!
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> [email protected]
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>