diff mbox series

[1/7] dt-bindings: gpu: mali-midgard: Tidy up conversion to YAML

Message ID 20191104013932.22505-2-afaerber@suse.de (mailing list archive)
State New, archived
Headers show
Series ARM: dts: Mali for Realtek RTD1195/RTD1295 | expand

Commit Message

Andreas Färber Nov. 4, 2019, 1:39 a.m. UTC
Instead of grouping alphabetically by third-party vendor, leading to
one-element enums, sort by Mali model number, as done for Utgard.

This already allows us to de-duplicate two "arm,mali-t760" sections and
will make it easier to add new vendor compatibles.

Fixes: 553cedf60056 ("dt-bindings: Convert Arm Mali Midgard GPU to DT schema")
Fixes: 1be5b54d26ae ("dt-bindings: gpu: mali-midgard: Add samsung exynos5250 compatible")
Cc: Rob Herring <robh@kernel.org>
Signed-off-by: Andreas Färber <afaerber@suse.de>
---
 .../devicetree/bindings/gpu/arm,mali-midgard.yaml  | 32 ++++++++++------------
 1 file changed, 14 insertions(+), 18 deletions(-)

Comments

Rob Herring (Arm) Nov. 6, 2019, 2:24 p.m. UTC | #1
On Sun, Nov 3, 2019 at 7:40 PM Andreas Färber <afaerber@suse.de> wrote:
>
> Instead of grouping alphabetically by third-party vendor, leading to
> one-element enums, sort by Mali model number, as done for Utgard.
>
> This already allows us to de-duplicate two "arm,mali-t760" sections and
> will make it easier to add new vendor compatibles.

That was the intent. Not sure how I messed that up...

This patch is problematic because there's changes in arm-soc juno/dt
branch and there's now a patch for exynos5420 (t628). I'd propose I
apply this such that we don't get a merge conflict with juno/dt and we
finish resorting after rc1 (or when both branches are in Linus' tree).

Rob
Krzysztof Kozlowski Nov. 6, 2019, 2:36 p.m. UTC | #2
On Wed, 6 Nov 2019 at 15:25, Rob Herring <robh@kernel.org> wrote:
>
> On Sun, Nov 3, 2019 at 7:40 PM Andreas Färber <afaerber@suse.de> wrote:
> >
> > Instead of grouping alphabetically by third-party vendor, leading to
> > one-element enums, sort by Mali model number, as done for Utgard.
> >
> > This already allows us to de-duplicate two "arm,mali-t760" sections and
> > will make it easier to add new vendor compatibles.
>
> That was the intent. Not sure how I messed that up...
>
> This patch is problematic because there's changes in arm-soc juno/dt
> branch and there's now a patch for exynos5420 (t628). I'd propose I
> apply this such that we don't get a merge conflict with juno/dt and we
> finish resorting after rc1 (or when both branches are in Linus' tree).

After resubmit, you could take the exynos5420 bindings one (and I'll
take the DTS). However the submitter should base then on latest next,
assuming you'll apply this one.

Best regards,
Krzysztof
Andreas Färber Nov. 6, 2019, 3:07 p.m. UTC | #3
Am Mittwoch, den 06.11.2019, 08:24 -0600 schrieb Rob Herring:
> On Sun, Nov 3, 2019 at 7:40 PM Andreas Färber <afaerber@suse.de>
> wrote:
> > Instead of grouping alphabetically by third-party vendor, leading
> > to
> > one-element enums, sort by Mali model number, as done for Utgard.
> > 
> > This already allows us to de-duplicate two "arm,mali-t760" sections
> > and
> > will make it easier to add new vendor compatibles.
> 
> That was the intent. Not sure how I messed that up...
> 
> This patch is problematic because there's changes in arm-soc juno/dt
> branch and there's now a patch for exynos5420 (t628). I'd propose I
> apply this such that we don't get a merge conflict with juno/dt and
> we
> finish resorting after rc1 (or when both branches are in Linus'
> tree).

This series has dependencies for the Realtek-side RFC patches and is
not yet ready to merge, so you can take this prep PATCH through your
tree for v5.6 probably, or feel free to rebase/rework as you see fit -
I'd just appreciate being credited at least via Reported-by. :)

Thanks,
Andreas
Rob Herring (Arm) Nov. 6, 2019, 3:34 p.m. UTC | #4
On Wed, Nov 6, 2019 at 9:07 AM Andreas Färber <afaerber@suse.de> wrote:
>
> Am Mittwoch, den 06.11.2019, 08:24 -0600 schrieb Rob Herring:
> > On Sun, Nov 3, 2019 at 7:40 PM Andreas Färber <afaerber@suse.de>
> > wrote:
> > > Instead of grouping alphabetically by third-party vendor, leading
> > > to
> > > one-element enums, sort by Mali model number, as done for Utgard.
> > >
> > > This already allows us to de-duplicate two "arm,mali-t760" sections
> > > and
> > > will make it easier to add new vendor compatibles.
> >
> > That was the intent. Not sure how I messed that up...
> >
> > This patch is problematic because there's changes in arm-soc juno/dt
> > branch and there's now a patch for exynos5420 (t628). I'd propose I
> > apply this such that we don't get a merge conflict with juno/dt and
> > we
> > finish resorting after rc1 (or when both branches are in Linus'
> > tree).
>
> This series has dependencies for the Realtek-side RFC patches and is
> not yet ready to merge, so you can take this prep PATCH through your
> tree for v5.6 probably, or feel free to rebase/rework as you see fit -
> I'd just appreciate being credited at least via Reported-by. :)

I was assuming the non-RFC patches are good to go, so I was going to
pick up 1, 2, and 7.

Rob
Andreas Färber Nov. 7, 2019, 10:03 a.m. UTC | #5
Am 06.11.19 um 16:34 schrieb Rob Herring:
> On Wed, Nov 6, 2019 at 9:07 AM Andreas Färber <afaerber@suse.de> wrote:
>> Am Mittwoch, den 06.11.2019, 08:24 -0600 schrieb Rob Herring:
>>> This patch is problematic because there's changes in arm-soc juno/dt
>>> branch and there's now a patch for exynos5420 (t628). I'd propose I
>>> apply this such that we don't get a merge conflict with juno/dt and
>>> we
>>> finish resorting after rc1 (or when both branches are in Linus'
>>> tree).
>>
>> This series has dependencies for the Realtek-side RFC patches and is
>> not yet ready to merge, so you can take this prep PATCH through your
>> tree for v5.6 probably, or feel free to rebase/rework as you see fit -
>> I'd just appreciate being credited at least via Reported-by. :)
> 
> I was assuming the non-RFC patches are good to go, so I was going to
> pick up 1, 2, and 7.

Actually 1, 2 and 4 should be good to go; 7 if you fix the subject or if
I respin. Also 6 if you can have someone check that no new properties
will be needed for 470 (no Linux driver support yet).

All but 1 assuming you'll be okay to add SoC-specific restrictions on
clocks/resets/domains later, once we've fully figured it out (cf. cover
letter for current errors - looking into power domains next).

Regards,
Andreas
diff mbox series

Patch

diff --git a/Documentation/devicetree/bindings/gpu/arm,mali-midgard.yaml b/Documentation/devicetree/bindings/gpu/arm,mali-midgard.yaml
index 8e00a21b36f5..ffdb24c4ab6a 100644
--- a/Documentation/devicetree/bindings/gpu/arm,mali-midgard.yaml
+++ b/Documentation/devicetree/bindings/gpu/arm,mali-midgard.yaml
@@ -16,36 +16,32 @@  properties:
     oneOf:
       - items:
           - enum:
-             - allwinner,sun50i-h6-mali
-          - const: arm,mali-t720
-      - items:
-          - enum:
-             - amlogic,meson-gxm-mali
-          - const: arm,mali-t820
+             - samsung,exynos5250-mali
+          - const: arm,mali-t604
       - items:
           - enum:
              - arm,juno-mali
           - const: arm,mali-t624
+      # "arm,mali-t628"
       - items:
           - enum:
-             - rockchip,rk3288-mali
-          - const: arm,mali-t760
+             - allwinner,sun50i-h6-mali
+          - const: arm,mali-t720
       - items:
           - enum:
-             - rockchip,rk3399-mali
-          - const: arm,mali-t860
+             - rockchip,rk3288-mali
+             - samsung,exynos5433-mali
+          - const: arm,mali-t760
       - items:
           - enum:
-             - samsung,exynos5250-mali
-          - const: arm,mali-t604
+             - amlogic,meson-gxm-mali
+          - const: arm,mali-t820
+      # "arm,mali-t830"
       - items:
           - enum:
-             - samsung,exynos5433-mali
-          - const: arm,mali-t760
-
-          # "arm,mali-t628"
-          # "arm,mali-t830"
-          # "arm,mali-t880"
+             - rockchip,rk3399-mali
+          - const: arm,mali-t860
+      # "arm,mali-t880"
 
   reg:
     maxItems: 1