Received: by 2002:a05:6a10:22f:0:0:0:0 with SMTP id 15csp3598523pxk; Tue, 29 Sep 2020 00:49:32 -0700 (PDT) X-Google-Smtp-Source: ABdhPJz/ijVYLSh3NMvpaaZjG8OoOSmi6OCmbDppfXwnenYeqRWZaMjTLXun1XyE6OFu6dTBzsAx X-Received: by 2002:a17:906:8690:: with SMTP id g16mr2494721ejx.187.1601365772514; Tue, 29 Sep 2020 00:49:32 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1601365772; cv=none; d=google.com; s=arc-20160816; b=pK/xemxoMfcp3eUJ9PMOpN0Jz0etmaNIgf88h7AChCdPKE1zjgRSycWHAUl8WodeIY o/YUSh1Sh7mLbMcKyUG0Gm44W+6XhZaMnbI7qiGGxeV6MGTiv67JNtATcYNP+CbaR4WD s3c8Tsx59gQy1ZSeOoGPULFszLzBTVtcF2kmqLY1OWvjBiS22NO+2EsDohBt+kZwxyrB gdqLo1E8WFv6zW8Xxa5lhysdYotb2thoTvFdTK3ksFwTASPyS32aCEeEISaYKDMV3Acf s1No2dP6w+u7wso+33uGUd63mBTdZGnjHLLqTsBMys0tox0ewGtX3IH3eQ2YYJ9RgSM8 CKWQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:cc:to:subject :message-id:date:from:in-reply-to:references:mime-version :dkim-signature; bh=gTw8+Yfq2M+lgL6uz8tiJpeY2ZADAkzaEJEhPKyRCFI=; b=UUdRUkPcjRBxV7TSh840lEPkhsHV12U9OIZDnuFHck2+LLDm/AGFCYgwjT80y/1Vcz CFz+3FTvACZlOCCCa7xoztF3WNGkcAqt7rWWKOztKKyvh+zQClW9fQsXbdumtrkd9PKT fT77utCFmQ5sJa1w7+BRg9bvlp6TQzzzKnmzHrmw8mc6MLgHWoEcw2aBWWLfBWh/zqUX 1v6LpJqBUtFUdJtk5Wic5vPzmXOw4v5MIA1pX5fZj1L/laKRTUnvdMwLd/tXi9C5lIY2 Jh6vNS+XFFABIIaSWRR6+zHL9DcC1sUFFyuzVcdtU+BIPtsQBzHTdUtfaHozGSJaDS6h o5lQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=IkT8QLC8; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id u7si2103585edo.567.2020.09.29.00.49.08; Tue, 29 Sep 2020 00:49:32 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=IkT8QLC8; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727533AbgI2Hru (ORCPT + 99 others); Tue, 29 Sep 2020 03:47:50 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:58856 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725535AbgI2Hrt (ORCPT ); Tue, 29 Sep 2020 03:47:49 -0400 Received: from mail-wm1-x344.google.com (mail-wm1-x344.google.com [IPv6:2a00:1450:4864:20::344]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 79625C061755 for ; Tue, 29 Sep 2020 00:47:49 -0700 (PDT) Received: by mail-wm1-x344.google.com with SMTP id a9so3740451wmm.2 for ; Tue, 29 Sep 2020 00:47:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=gTw8+Yfq2M+lgL6uz8tiJpeY2ZADAkzaEJEhPKyRCFI=; b=IkT8QLC85j8yoqCUXeesrjQjdwYyMXKI+9pHr+gD194jy/JPlP7IULJjQBms6RfAcn ngOpiL8YKxttlae/eW+ZSYsuN6fw22wjzPlxYz4CDVZQDW6jOe/fUpkTpZ06RqkrezNR tZkf3oRsdTOWnYGJBVtyhGGF97Yrg4fEfY5ZIcZb811ljQIAJX1+o0YjTeWIaW1PBXE+ VLRgbDqUx1NexRNOfcMr8YML02icMyBzioqMZjt4FsQUuZccI2vjISzfstZ8Ll3CZL0X uw2lFh1dlc98GFEzdezIO+4ogmKGDBjmkzMVNoNFeVIQxDwrMa1bVwb3S3R4Q7QIhlWk BKJQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=gTw8+Yfq2M+lgL6uz8tiJpeY2ZADAkzaEJEhPKyRCFI=; b=KXlJqeZx8y2kb/prHAtl7tWmeYF9rihUNllVseSnSkTXnBt8a+R7g4KSMoAyT9gNYO ga66OJFAVOEDtQ+bUfvNvo9pN2/XdO/j2bU+8dwXZiI55mPR5x55EPNCNyv5sMV9F3gC AkWK8JmBTUk/ASX9KFregRJhGuFIOrPDVBjzcqu6tczJJ3Q2tN6ObZaOIF6j9MCpTwhv 6IlECIsi6qm28hpNl7eu8KtqHHAWlkLRHk51Rm5Ma3Mg+FQ0DRq9ywtvYFDjA4rjFbKt F7B3axz2UY2VogJd++FMCyXwRuJra++5Qez1ahg/Al1/fRoJIFO0wo3xs5wLaItg8Hbq 3jgQ== X-Gm-Message-State: AOAM533LYjylMdcpmNKo4QUJTsYCVbOwtNPsZNiZ6jHH8Lsi+rkwwGMO rCWfEtdbyh3sjHKmRWJDqbbN9g+klxJy8GzWsgRVo+ksgHFdyg== X-Received: by 2002:a7b:cc17:: with SMTP id f23mr2888405wmh.166.1601365668191; Tue, 29 Sep 2020 00:47:48 -0700 (PDT) MIME-Version: 1.0 References: <1601274460-7866-1-git-send-email-kevin3.tang@gmail.com> <1601274460-7866-2-git-send-email-kevin3.tang@gmail.com> <20200928081726.hkh3rzbfr6m7jszt@gilmour.lan> In-Reply-To: From: Chunyan Zhang Date: Tue, 29 Sep 2020 15:47:12 +0800 Message-ID: Subject: Re: [PATCH RFC v7 1/6] dt-bindings: display: add Unisoc's drm master bindings To: Kevin Tang Cc: Rob Herring , Maxime Ripard , Maarten Lankhorst , Sean Paul , David Airlie , Daniel Vetter , Mark Rutland , Orson Zhai , "linux-kernel@vger.kernel.org" , dri-devel Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 29 Sep 2020 at 14:35, Kevin Tang wrote: > > Hi Rob, > Component framework include master and component, here is master subnode. > It seems that everyone else does it, why not me? > > Your comments on v6: > "We generally try to avoid this virtual node as it doesn't represent > any h/w. Can't you bind the driver to the DPU directly?" > > I'm sorry, maybe is my careless, I still don't understand why and how to = do it Devicetree is used to describe hardware rather than virtual things like "sprd,display-subsystem" which is not a real device. That's what I understand for Rob's comments here. Chunyan > > Rob Herring =E4=BA=8E2020=E5=B9=B49=E6=9C=8829=E6=97= =A5=E5=91=A8=E4=BA=8C =E4=B8=8A=E5=8D=8812:28=E5=86=99=E9=81=93=EF=BC=9A > > > > > On Mon, Sep 28, 2020 at 3:17 AM Maxime Ripard wrote= : > > > > > > Hi! > > > > > > On Mon, Sep 28, 2020 at 02:27:35PM +0800, Kevin Tang wrote: > > > > From: Kevin Tang > > > > > > > > The Unisoc DRM master device is a virtual device needed to list all > > > > DPU devices or other display interface nodes that comprise the > > > > graphics subsystem > > > > > > > > RFC v7: > > > > - Fix DTC unit name warnings > > > > - Fix the problem of maintainers > > > > > > > > Cc: Orson Zhai > > > > Cc: Chunyan Zhang > > > > Signed-off-by: Kevin Tang > > > > --- > > > > .../display/sprd/sprd,display-subsystem.yaml | 39 ++++++++++= ++++++++++++ > > > > 1 file changed, 39 insertions(+) > > > > create mode 100644 Documentation/devicetree/bindings/display/sprd/= sprd,display-subsystem.yaml > > > > > > > > diff --git a/Documentation/devicetree/bindings/display/sprd/sprd,di= splay-subsystem.yaml b/Documentation/devicetree/bindings/display/sprd/sprd,= display-subsystem.yaml > > > > new file mode 100644 > > > > index 0000000..9487a39 > > > > --- /dev/null > > > > +++ b/Documentation/devicetree/bindings/display/sprd/sprd,display-s= ubsystem.yaml > > > > @@ -0,0 +1,39 @@ > > > > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) > > > > +%YAML 1.2 > > > > +--- > > > > +$id: http://devicetree.org/schemas/display/sprd/sprd,display-subsy= stem.yaml# > > > > +$schema: http://devicetree.org/meta-schemas/core.yaml# > > > > + > > > > +title: Unisoc DRM master device > > > > + > > > > +maintainers: > > > > + - Kevin Tang > > > > + > > > > +description: | > > > > + The Unisoc DRM master device is a virtual device needed to list = all > > > > + DPU devices or other display interface nodes that comprise the > > > > + graphics subsystem. > > > > + > > > > +properties: > > > > + compatible: > > > > + const: sprd,display-subsystem > > > > + > > > > + ports: > > > > + $ref: /schemas/types.yaml#/definitions/phandle-array > > > > + description: > > > > + Should contain a list of phandles pointing to display interf= ace port > > > > + of DPU devices. > > > > > > Generally speaking, driver-specific properties should be prefixed by = the > > > vendor name to avoid any conflict with generic properties (like the > > > OF-Graph ports subnode in this case) > > > > We try to avoid this virtual node altogether which I commented about > > on v6 which was ignored. > > > > Rob