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 <[email protected]>
Signed-off-by: Andreas Färber <[email protected]>
---
.../devicetree/bindings/gpu/arm,mali-midgard.yaml | 32 ++++++++++------------
1 file changed, 14 insertions(+), 18 deletions(-)
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
--
2.16.4
On Sun, Nov 3, 2019 at 7:40 PM Andreas Färber <[email protected]> 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
On Wed, 6 Nov 2019 at 15:25, Rob Herring <[email protected]> wrote:
>
> On Sun, Nov 3, 2019 at 7:40 PM Andreas Färber <[email protected]> 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
Am Mittwoch, den 06.11.2019, 08:24 -0600 schrieb Rob Herring:
> On Sun, Nov 3, 2019 at 7:40 PM Andreas Färber <[email protected]>
> 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
--
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer
HRB 36809 (AG Nürnberg)
On Wed, Nov 6, 2019 at 9:07 AM Andreas Färber <[email protected]> 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 <[email protected]>
> > 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
Am 06.11.19 um 16:34 schrieb Rob Herring:
> On Wed, Nov 6, 2019 at 9:07 AM Andreas Färber <[email protected]> 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
--
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer
HRB 36809 (AG Nürnberg)