Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp905777imu; Tue, 11 Dec 2018 09:20:53 -0800 (PST) X-Google-Smtp-Source: AFSGD/U3a7OEhfcTnKEx43dojH/qP3BU3I/+MBdzHQ5DI91EUyqLz1EZ9MYzJEFzeC7FWoufMTKk X-Received: by 2002:a63:5d55:: with SMTP id o21mr15041247pgm.92.1544548853007; Tue, 11 Dec 2018 09:20:53 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1544548852; cv=none; d=google.com; s=arc-20160816; b=hzGSKXEUvYAacDrollN6oOVMGvyB9lqjurPZG0AewOQvk7fUs2V8da0eYXS+ErdRfn CEyAamzT1kcl7M40AQl6+YuzgsXyyFeJRPCDq/4IDclipR25imqTbs0TrjPtSzy+sAGN YvQVvVE/lIS+/of1Pzr7RU64WAhPIrFmRvSYyR2dXxuyDy0JIc12fc8k/TTnxY8yPc2Z NQOySxu+uoEG/S9Q/3b9rlTqC8U31pl414eMbBv5KSi1bImjbh3heL6aRqLj96G33ccl PEAmPXnr9eymt2tnHpH9Drxi3bNEYF6nhdtAYDulQy+mVcCZxOJUovrVcp1CssRCMtiX JD3g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=Y87KSNLOtxTkyZ8U/lPyPfpWY+u5uQcSZ4xHNpLYDmE=; b=NX/4vZARV+fvEgJ1jFaFLivG3/Y4pxYfEUrdV8+YYYc9bgeLitgbCWyDngciplK5GX k+mYePx4XVPYlDplxT8iXMYkB2kKKU0y36OwTaOlhKVt5qPgHaPmPAQ1++3EgXhk3Q/D JnWxsQJ6NgqGTdH9s78+EOZHfkXt0rlnZTyV7BW1SnXNqqQmK1O6vFTQmpnwISuTx4DX Emiw9fEIByn+gszzNCO9PrsTZIynGso6ELr9BHG0xNCFvrGaugD1AY3S80DQKDXiB5aH mlKHkdWbc0hUAEJeHvOK0pwOIoSWI4PWuHUfWfSiG0uSeLhsDHsln3sJXFfoWbB3kruL vFPQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=CpPo0r4W; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id o184si11765701pgo.591.2018.12.11.09.20.38; Tue, 11 Dec 2018 09:20:52 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=CpPo0r4W; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727517AbeLKRFN (ORCPT + 99 others); Tue, 11 Dec 2018 12:05:13 -0500 Received: from mail.kernel.org ([198.145.29.99]:50152 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727216AbeLKRFM (ORCPT ); Tue, 11 Dec 2018 12:05:12 -0500 Received: from mail-qt1-f172.google.com (mail-qt1-f172.google.com [209.85.160.172]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id E3C8720989; Tue, 11 Dec 2018 17:05:10 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1544547911; bh=avd+dtzQl41dld8XFGWOC3fNEzUjx2h5h/WpLXi8A2s=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=CpPo0r4WLehhLcU3qIbpQP35e/HVrdBcPiW+zjR0y9a+Xk3/VFOcFavybYbV7F78m aJfLDxZfLAcAak7+a0TGiySqf/Ygvyy7vw6XBAOONehZNa357gq0t1girs0/0X4Ud/ q9NRJeg+YsudwcWi2NxNbZnERB8auc2bIrP2SqJc= Received: by mail-qt1-f172.google.com with SMTP id n21so17209187qtl.6; Tue, 11 Dec 2018 09:05:10 -0800 (PST) X-Gm-Message-State: AA+aEWYdLkq+7vCdg72CDCYWKb1rYGUNODEflbIAREGNstgWeSabb/tC Fo33zGRSB3dK5nOjBIm13UPhmQvBlQklr0Vcng== X-Received: by 2002:ac8:6b18:: with SMTP id w24mr17102010qts.144.1544547910109; Tue, 11 Dec 2018 09:05:10 -0800 (PST) MIME-Version: 1.0 References: <20181127074249.15204-1-icenowy@aosc.io> <20181127074249.15204-2-icenowy@aosc.io> <11894938.HOUtrQJeEF@phil> In-Reply-To: <11894938.HOUtrQJeEF@phil> From: Rob Herring Date: Tue, 11 Dec 2018 11:04:59 -0600 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH 2/2] dt-bindings: gpu: add Allwinner H6 Mali Midgard binding To: "heiko@sntech.de" , Neil Armstrong Cc: dri-devel , Mark Rutland , devicetree@vger.kernel.org, Jernej Skrabec , Maxime Ripard , linux-sunxi , "linux-kernel@vger.kernel.org" , David Airlie , Chen-Yu Tsai , Icenowy Zheng Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Dec 3, 2018 at 6:25 AM Heiko Stuebner wrote: > > Am Dienstag, 27. November 2018, 08:42:49 CET schrieb Icenowy Zheng: > > Allwinner H6 SoC uses a Mali T720 GPU, which is one of the GPUs in the > > Midgard GPU product line. > > > > Add binding for the H6 Mali Midgard GPU. > > > > Signed-off-by: Icenowy Zheng > > --- > > .../devicetree/bindings/gpu/arm,mali-midgard.txt | 13 +++++++++++++ > > 1 file changed, 13 insertions(+) > > > > diff --git a/Documentation/devicetree/bindings/gpu/arm,mali-midgard.txt b/Documentation/devicetree/bindings/gpu/arm,mali-midgard.txt > > index 02f870cd60e6..c897dd7be48f 100644 > > --- a/Documentation/devicetree/bindings/gpu/arm,mali-midgard.txt > > +++ b/Documentation/devicetree/bindings/gpu/arm,mali-midgard.txt > > @@ -18,6 +18,7 @@ Required properties: > > + "amlogic,meson-gxm-mali" > > + "rockchip,rk3288-mali" > > + "rockchip,rk3399-mali" > > + + "allwinner,sun50i-h6-mali" > > I'd think you might want to keep an alphabetical sorting here, aka > above amlogic, otherwise the list will probably become hard to read > at some later point. > > > > - reg : Physical base address of the device and length of the register area. > > > > @@ -44,6 +45,18 @@ Optional properties: > > for details. > > > > > > +Vendor-specific bindings > > +------------------------ > > + > > +The Mali GPU is integrated very differently from one SoC to > > +another. In order to accomodate those differences, you have the option > > +to specify one more vendor-specific compatible, among: > > + > > + - allwinner,sun50i-h6-mali > > + Required properties: > > + * resets: phandle to the reset line for the GPU > > While this paragraph is similar to how it is done in Utgard, I'm > wondering why we cannot just describe the "resets" as regular > optional property above that. Optional is fine, but I don't want to see every vendor doing their own definition (there's a similar patch for meson[1]). Please first figure out how many resets the IP block has. ARM should help as they were eager for me to accept this binding in the first place. Then we can see if vendors have extra resets. Rob [1] https://patchwork.ozlabs.org/patch/1010406/