From: Guillaume Tucker <email@example.com>
To: Rob Herring <firstname.lastname@example.org>
Cc: "Mark Rutland" <email@example.com>,
"Heiko Stübner" <firstname.lastname@example.org>,
"Neil Armstrong" <email@example.com>,
"Sjoerd Simons" <firstname.lastname@example.org>,
"Enric Balletbo i Serra" <email@example.com>,
"John Reitan" <firstname.lastname@example.org>, Wookey <email@example.com>,
"open list:ARM/Rockchip SoC..."
Subject: Re: [PATCH v4 1/5] dt-bindings: gpu: add bindings for the ARM Mali Midgard GPU
Date: Tue, 2 May 2017 15:49:29 +0100 [thread overview]
Message-ID: <firstname.lastname@example.org> (raw)
On 02/05/17 15:13, Rob Herring wrote:
> On Tue, May 2, 2017 at 6:23 AM, Guillaume Tucker
> <email@example.com> wrote:
>> Hi Rob,
>> On 28/04/17 20:27, Rob Herring wrote:
>>> On Tue, Apr 25, 2017 at 02:16:16PM +0100, Guillaume Tucker wrote:
>>>> diff --git a/Documentation/devicetree/bindings/gpu/arm,mali-midgard.txt
>>>> new file mode 100644
>>>> index 000000000000..547ddeceb498
>>>> --- /dev/null
>>>> +++ b/Documentation/devicetree/bindings/gpu/arm,mali-midgard.txt
>>>> @@ -0,0 +1,82 @@
>>>> +ARM Mali Midgard GPU
>>>> +Required properties:
>>>> +- compatible :
>>>> + * Must be one of the following:
>>>> + + "arm,mali-t60x"
>>>> + + "arm,mali-t62x"
>>> Don't use wildcards.
>> Sure, old habits die hard... I'll fix it in patch v5.
>>>> + + "arm,mali-t720"
>>>> + + "arm,mali-t760"
>>>> + + "arm,mali-t820"
>>>> + + "arm,mali-t830"
>>>> + + "arm,mali-t860"
>>>> + + "arm,mali-t880"
>>>> + * And, optionally, one of the vendor specific compatible:
>>> IMO, these should not be optional.
>> Well, vendor compatible strings are clearly optional for the
>> Utgard GPU series for which the bindings docs were recently
>> merged. It seems that whether these should be optional or not,
>> the documentation should be consistent between at least all
>> similar types of devices like Midgard and Utgard GPUs. They have
>> different architectures but from a device tree point of view,
>> they both have the same kind of SoC-specific integration (clocks,
>> irqs, regulators...).
> Clocks should not vary by SoC. There is often variation because clocks
> get driven by same source or are not s/w controlled, but really there
> should not be that variation. I noticed Utgard has 2 clocks. So is
> Midgard really just 1 clock? The DT should have all the clocks listed
> in the TRMs.
I meant to say that the clock sources are different in each SoC,
but yes the same clock input is always needed by the GPU.
The TRM is confidential but to the best of my knowledge and based
on existing device trees and the out-of-tree kernel driver, the
Midgard GPU has only one clock input.
>> So was this was overlooked in the Utgard case and should it
>> ideally be fixed there as well as non-optional? Or, is it OK to
>> keep these optional on a second thought?
> Probably should be required in the Utgard case as well.
OK, so I'll make the vendor compatible strings required (for
Midgard) in patch v5.
next prev parent reply other threads:[~2017-05-02 14:49 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-04-25 13:16 [PATCH v4 0/5] Add ARM Mali Midgard device tree bindings and gpu node for rk3288 Guillaume Tucker
2017-04-25 13:16 ` [PATCH v4 1/5] dt-bindings: gpu: add bindings for the ARM Mali Midgard GPU Guillaume Tucker
2017-04-28 19:27 ` Rob Herring
2017-05-02 11:23 ` Guillaume Tucker
2017-05-02 14:13 ` Rob Herring
2017-05-02 14:49 ` Guillaume Tucker [this message]
2017-04-25 13:16 ` [PATCH v4 2/5] ARM: dts: rockchip: add ARM Mali GPU node for rk3288 Guillaume Tucker
2017-04-25 13:16 ` [PATCH v4 3/5] ARM: dts: rockchip: enable ARM Mali GPU on rk3288-rock2-som Guillaume Tucker
2017-04-25 13:16 ` [PATCH v4 4/5] ARM: dts: rockchip: enable ARM Mali GPU on rk3288-firefly Guillaume Tucker
2017-04-25 13:16 ` [PATCH v4 5/5] ARM: dts: rockchip: enable ARM Mali GPU on rk3288-veyron Guillaume Tucker
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).