From: robh@kernel.org (Rob Herring)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 1/2] dt-bindings: gpu: Add Mali Utgard bindings
Date: Thu, 19 Jan 2017 10:16:48 -0600 [thread overview]
Message-ID: <20170119161648.u6tta5mogadli7ih@rob-hp-laptop> (raw)
In-Reply-To: <20170116132424.7038-1-maxime.ripard@free-electrons.com>
On Mon, Jan 16, 2017 at 02:24:23PM +0100, Maxime Ripard wrote:
> The ARM Mali Utgard GPU family is embedded into a number of SoCs from
> Allwinner, Amlogic, Mediatek or Rockchip.
>
> Add a binding for the GPU of that family.
>
> Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
> ---
> .../devicetree/bindings/gpu/arm,mali-utgard.txt | 76 ++++++++++++++++++++++
> 1 file changed, 76 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/gpu/arm,mali-utgard.txt
>
> diff --git a/Documentation/devicetree/bindings/gpu/arm,mali-utgard.txt b/Documentation/devicetree/bindings/gpu/arm,mali-utgard.txt
> new file mode 100644
> index 000000000000..df05ba0ec357
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/gpu/arm,mali-utgard.txt
> @@ -0,0 +1,76 @@
> +ARM Mali Utgard GPU
> +===================
> +
> +Required properties:
> + - compatible:
> + * "arm,mali-utgard" and one of the following:
Drop this. It's meaningless and 3 compatibles to match is the kernel is
not a big deal.
> + + "arm,mali-300"
> + + "arm,mali-400"
> + + "arm,mali-450"
> +
> + - reg: Physical base address and length of the GPU registers
> +
> + - interrupts: an entry for each entry in interrupt-names.
> + See ../interrupt-controller/interrupts.txt for details.
> +
> + - interrupt-names:
> + * ppX: Pixel Processor X interrupt (X from 0 to 7)
> + * ppmmuX: Pixel Processor X MMU interrupt (X from 0 to 7)
Is the number of pixel processors probe-able? If not, then it needs to
be implied by the vendor compatible string or a property.
> + * pp: Pixel Processor broadcast interrupt (mali-450 only)
> + * gp: Geometry Processor interrupt
> + * gpmmu: Geometry Processor MMU interrupt
That's a lot of interrupts. Was going to ask about combining, but
I see Linus raised that.
> +
> +
> +Optional properties:
> + - interrupt-names:
> + * pmu: Power Management Unit interrupt, if implemented in hardware
> +
> +Vendor-specific bindings
> +------------------------
> +
> +The Mali GPU is integrated very differently from one SoC to
> +another. In order to accommodate those differences, you have the option
> +to specify one more vendor-specific compatible, among:
> +
> + - allwinner,sun4i-a10-mali
List this with the compatible strings. I assume one of the arm,mali-???
strings applies too.
> + Required properties:
> + * clocks: an entry for each entry in clock-names
> + * clock-names:
> + + bus: bus clock for the GPU
> + + core: clock driving the GPU itself
This should be in the core binding. The number of clocks should not
vary. We often get this wrong because the IP blocks get integrated and
connected to the same clock source. But this should be equal to the
number of clock inputs.
> + * resets: phandle to the reset line for the GPU
> +
> + - allwinner,sun7i-a20-mali
> + Required properties:
> + * clocks: an entry for each entry in clock-names
> + * clock-names:
> + + bus: bus clock for the GPU
> + + core: clock driving the GPU itself
> + * resets: phandle to the reset line for the GPU
> +
> +Example:
> +
> +mali: gpu at 01c40000 {
> + compatible = "allwinner,sun7i-a20-mali", "arm,mali-400",
> + "arm,mali-utgard";
> + reg = <0x01c40000 0x10000>;
> + interrupts = <GIC_SPI 97 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 98 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 99 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 100 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 102 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 103 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 101 IRQ_TYPE_LEVEL_HIGH>;
> + interrupt-names = "gp",
> + "gpmmu",
> + "pp0",
> + "ppmmu0",
> + "pp1",
> + "ppmmu1",
> + "pmu";
> + clocks = <&ccu CLK_BUS_GPU>, <&ccu CLK_GPU>;
> + clock-names = "bus", "core";
> + resets = <&ccu RST_BUS_GPU>;
> +};
> +
> +
> --
> 2.11.0
>
next prev parent reply other threads:[~2017-01-19 16:16 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-01-16 13:24 [PATCH 1/2] dt-bindings: gpu: Add Mali Utgard bindings Maxime Ripard
2017-01-16 13:24 ` [PATCH 2/2] ARM: sun8i: dt: Add mali node Maxime Ripard
2017-01-16 18:49 ` [PATCH 1/2] dt-bindings: gpu: Add Mali Utgard bindings Krzysztof Kozlowski
2017-01-17 9:38 ` Maxime Ripard
2017-01-17 10:22 ` Neil Armstrong
2017-01-17 11:33 ` Krzysztof Kozlowski
2017-01-17 20:50 ` Maxime Ripard
2017-01-19 15:51 ` Maxime Ripard
2017-01-19 16:02 ` Neil Armstrong
2017-01-17 11:31 ` Krzysztof Kozlowski
2017-01-17 20:51 ` Maxime Ripard
2017-01-19 16:08 ` Rob Herring
2017-01-18 23:09 ` Linus Walleij
2017-01-19 15:49 ` Maxime Ripard
2017-01-20 9:16 ` Linus Walleij
2017-01-19 16:16 ` Rob Herring [this message]
2017-01-20 8:59 ` Maxime Ripard
2017-01-19 19:24 ` John Stultz
2017-01-20 9:16 ` Maxime Ripard
2017-01-20 14:15 ` Rob Herring
2017-01-23 12:34 ` Maxime Ripard
2017-01-20 14:10 ` Rob Herring
2017-01-26 17:15 ` Mason
Reply instructions:
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:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20170119161648.u6tta5mogadli7ih@rob-hp-laptop \
--to=robh@kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* 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