| Message ID | 20191104013932.22505-2-afaerber@suse.de |
|---|---|
| State | Accepted, archived |
| Headers | show |
| Series | ARM: dts: Mali for Realtek RTD1195/RTD1295 | expand |
| Context | Check | Description |
|---|---|---|
| robh/checkpatch | success |
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
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
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
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
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 --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
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(-)