Re: [PATCH v4] dt-bindings: gpu: add bindings for the ARM Mali Bifrost GPU

[Neil Armstrong <narmstrong@baylibre.com>]

On 01/04/2019 12:00, Steven Price wrote:
> On 01/04/2019 09:09, Neil Armstrong wrote:
>> Add the bindings for the Bifrost family of ARM Mali GPUs.
>>
>> The Bifrost GPU architecture is similar to the Midgard family,
>> but with a different Shader Core & Execution Engine structures.
>>
>> Bindings are based on the Midgard family bindings, but the inner
>> architectural changes makes it a separate family needing separate
>> bindings.
>>
>> The Bifrost GPUs are present in a number of recent SoCs, like the
>> Amlogic G12A Family, and many other vendors.
>> The Amlogic vendor specific compatible is added to handle the
>> specific IP integration differences and dependencies.
>>
>> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
>> ---
>>  .../bindings/gpu/arm,mali-bifrost.txt         | 92 +++++++++++++++++++
>>  1 file changed, 92 insertions(+)
>>  create mode 100644 Documentation/devicetree/bindings/gpu/arm,mali-bifrost.txt
>>
>> Changes since v3:
>> - Added note about discoverable model/revision
>> - Enforced fixed defined irq order
>> - Fixed typo in accommodate
>>
>> Changes since v2:
>> - moved to a single compatible since HW is fully discoverable
>>
>> diff --git a/Documentation/devicetree/bindings/gpu/arm,mali-bifrost.txt b/Documentation/devicetree/bindings/gpu/arm,mali-bifrost.txt
>> new file mode 100644
>> index 000000000000..711c9ead17a2
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/gpu/arm,mali-bifrost.txt
>> @@ -0,0 +1,92 @@
>> +ARM Mali Bifrost GPU
>> +====================
>> +
>> +Required properties:
>> +
>> +- compatible :
>> +  * Since Mali Bifrost GPU model/revision if fully discoverable by reading
>                                              ^^
> s/if/is/

Thanks for pointing this.

> 
>> +    some determined registers, must contain the following:
>> +    + "arm,mali-bifrost"
>> +  * which must be preceded by one of the following vendor specifics:
>> +    + "amlogic,meson-g12a-mali"
>> +
>> +- reg : Physical base address of the device and length of the register area.
>> +
>> +- interrupts : Contains the three IRQ lines required by Mali Bifrost devices,
>> +  in the following defined order.
>> +
>> +- interrupt-names : Contains the names of IRQ resources in this exact defined
>> +  order: "job", "mmu", "gpu".
> 
> Is there any point in having "interrupt-names" if we're fixing the
> order? Although I guess it helps match the Midgard bindings.

Exact.

Neil

> 
> Steve
> 
>> +
>> +Optional properties:
>> +
>> +- clocks : Phandle to clock for the Mali Bifrost device.
>> +
>> +- mali-supply : Phandle to regulator for the Mali device. Refer to
>> +  Documentation/devicetree/bindings/regulator/regulator.txt for details.
>> +
>> +- operating-points-v2 : Refer to Documentation/devicetree/bindings/opp/opp.txt
>> +  for details.
>> +
>> +- resets : Phandle of the GPU reset line.
>> +
>> +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:
>> +
>> +- "amlogic,meson-g12a-mali"
>> +  Required properties:
>> +  - resets : Should contain phandles of :
>> +    + GPU reset line
>> +    + GPU APB glue reset line
>> +
>> +Example for a Mali-G31:
>> +
>> +gpu@ffa30000 {
>> +	compatible = "amlogic,meson-g12a-mali", "arm,mali-bifrost";
>> +	reg = <0xffe40000 0x10000>;
>> +	interrupts = <GIC_SPI 160 IRQ_TYPE_LEVEL_HIGH>,
>> +		     <GIC_SPI 161 IRQ_TYPE_LEVEL_HIGH>,
>> +		     <GIC_SPI 162 IRQ_TYPE_LEVEL_HIGH>;
>> +	interrupt-names = "job", "mmu", "gpu";
>> +	clocks = <&clk CLKID_MALI>;
>> +	mali-supply = <&vdd_gpu>;
>> +	operating-points-v2 = <&gpu_opp_table>;
>> +	resets = <&reset RESET_DVALIN_CAPB3>, <&reset RESET_DVALIN>;
>> +};
>> +
>> +gpu_opp_table: opp_table0 {
>> +	compatible = "operating-points-v2";
>> +
>> +	opp@533000000 {
>> +		opp-hz = /bits/ 64 <533000000>;
>> +		opp-microvolt = <1250000>;
>> +	};
>> +	opp@450000000 {
>> +		opp-hz = /bits/ 64 <450000000>;
>> +		opp-microvolt = <1150000>;
>> +	};
>> +	opp@400000000 {
>> +		opp-hz = /bits/ 64 <400000000>;
>> +		opp-microvolt = <1125000>;
>> +	};
>> +	opp@350000000 {
>> +		opp-hz = /bits/ 64 <350000000>;
>> +		opp-microvolt = <1075000>;
>> +	};
>> +	opp@266000000 {
>> +		opp-hz = /bits/ 64 <266000000>;
>> +		opp-microvolt = <1025000>;
>> +	};
>> +	opp@160000000 {
>> +		opp-hz = /bits/ 64 <160000000>;
>> +		opp-microvolt = <925000>;
>> +	};
>> +	opp@100000000 {
>> +		opp-hz = /bits/ 64 <100000000>;
>> +		opp-microvolt = <912500>;
>> +	};
>> +};
>>
>