From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 5B08EC433F5 for ; Tue, 28 Sep 2021 09:18:13 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 39165610E5 for ; Tue, 28 Sep 2021 09:18:13 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S239765AbhI1JTv (ORCPT ); Tue, 28 Sep 2021 05:19:51 -0400 Received: from new1-smtp.messagingengine.com ([66.111.4.221]:34513 "EHLO new1-smtp.messagingengine.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S239043AbhI1JTv (ORCPT ); Tue, 28 Sep 2021 05:19:51 -0400 Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailnew.nyi.internal (Postfix) with ESMTP id 952F65805DD; Tue, 28 Sep 2021 05:18:11 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute3.internal (MEProxy); Tue, 28 Sep 2021 05:18:11 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cerno.tech; h= date:from:to:cc:subject:message-id:references:mime-version :content-type:content-transfer-encoding:in-reply-to; s=fm1; bh=a z58RAATejJOnuwYVDi925Y5L5Fz8v8ETOF1VVXfBFo=; b=mkFIkhnTkD262P8Bg f1tIlQZrFdVw1cP7H9BBmWxTQF6b5mjae2413trvlP/CZ2NBr5+ZwX0UJ9OFzvBd nLRBxRbHVwuH6MBwubzC7aMfSxToIM9Kc2hzDNrlKY83hA7OZ0FR3QOr7pD8HEOD lbQbUfHn5qilrvRgkLn7zaEyAEBLeI+1goh90CzhK6ZzwT5OFQgDVoive+sovI0R 9jmNRcML0RqkfnQLc+igmQwPNQS8T6x6JD/jp0dndMvxtTL4F1NC1Ff5gKpIw+UV fOsVHZrlSrCvqW7OKlnXCrtpJH+tLqqqSfK9hRdTrSKJbBSpMbNGtZ418RujdLA2 OLYNQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm3; bh=az58RAATejJOnuwYVDi925Y5L5Fz8v8ETOF1VVXfB Fo=; b=rfG7exEEIVLxzpRwK3TohfxlxFmByaAfXcABxwKjk67aN6Jwi188Ev45+ SNpsmsXpMlJaw4vOsIFn13seohtIiYdkYzCfjg3DHlGiNXMZpqWmKw33BfZeB6nX o+JroOJd6jAdNjFFsUs6MgpnaVuyWrjAtz5If9JNu/3hDXCKsOWE/B+Qa2F2qh4x kgcF/DDodk8eYLm7B6ChCa4NmpTBBVB0wPZIh6yLD/0/tHKHOr3xaZ+KV8tjv0fL m6aXxOj5IRW78jf2a9JTNwGTy/PNhW2Fx2++OTjVfjJ3QyxDvpv5LJ8Wc1oYKJEu vlGNno8kgehwScDbf/DZZQoBnAEdg== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvtddrudektddguddtucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepfffhvffukfhfgggtugfgjgesthhqredttddtvdenucfhrhhomhepofgrgihi mhgvucftihhprghrugcuoehmrgigihhmvgestggvrhhnohdrthgvtghhqeenucggtffrrg htthgvrhhnpefgjeettdejgffgffdvteeutdehtdehgeehueetkeefgefhtdetjeekledu gedvudenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpe hmrgigihhmvgestggvrhhnohdrthgvtghh X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA; Tue, 28 Sep 2021 05:18:08 -0400 (EDT) Date: Tue, 28 Sep 2021 11:18:07 +0200 From: Maxime Ripard To: "H. Nikolaus Schaller" Cc: Sam Ravnborg , Laurent Pinchart , Paul Cercueil , Rob Herring , Mark Rutland , Thomas Bogendoerfer , Geert Uytterhoeven , Kees Cook , "Eric W. Biederman" , Miquel Raynal , David Airlie , Daniel Vetter , Andrzej Hajda , Neil Armstrong , Robert Foss , Jernej Skrabec , Ezequiel Garcia , Harry Wentland , Hans Verkuil , Liam Girdwood , Mark Brown , Paul Boddie , "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" , linux-mips , linux-kernel , Discussions about the Letux Kernel , Jonas Karlman , dri-devel , Rob Herring Subject: Re: [PATCH v4 03/10] dt-bindings: display: Add ingenic,jz4780-dw-hdmi DT Schema Message-ID: <20210928091807.xgqxemjizlobpcxy@gilmour> References: <6c8b72a03703de54fa02b29c1a53c84ca0889e50.1632761067.git.hns@goldelico.com> <20210927170702.on243lp24fcfdhbj@gilmour> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-mips@vger.kernel.org On Tue, Sep 28, 2021 at 10:59:45AM +0200, H. Nikolaus Schaller wrote: > >> +properties: > >> + compatible: > >> + items: > >> + - const: ingenic,jz4780-dw-hdmi > >=20 > > This can just be a const, there's no need for the items >=20 > Maybe starting with an enum is better if more compatible strings are to b= e added. it's still fairly easy to change if needed, there's no need to confuse anyone. > >=20 > >> + reg-io-width: > >> + const: 4 > >=20 > > If it's fixed, why do you need it in the first place? >=20 > There is a fixed default of 1 if not specified. My point was more about why do you need to have that property at all? Can't you just drop it and assume that the register width is 32 bits if it's all you will ever run on? > >> + clocks: > >> + maxItems: 2 > >> + description: Clock specifiers for isrf and iahb clocks > >=20 > > This can be defined as > >=20 > > clocks: > > items: > > - description: isrf > > - description: iahb > >=20 > > A better description about what these clocks are would be nice as well >=20 > Generally I see that this all is nowadays not independent of >=20 > Documentation/devicetree/bindings/display/bridge/synopsys,dw-hdmi.yaml >=20 > where there is already a description. Ok, good then > On the other hand every SoC specialization runs its own copy. e.g. >=20 > Documentation/devicetree/bindings/display/imx/fsl,imx6-hdmi.yaml > Documentation/devicetree/bindings/display/rockchip/rockchip,dw-hdmi.yam >=20 > >=20 > >> + clock-names: > >> + items: > >> + - const: isfr > >=20 > > Is it isfr or isrf? >=20 > isfr. Seems to be a typo in the description. See > bridge/synopsys,dw-hdmi.yaml# >=20 > One question to the yaml specialists: >=20 > since ../bridge/synopsys,dw-hdmi.yaml# already defines this, do we > have to repeat? Or can we reduce to just the changes? If you add the ref you mentionned above, you don't have to repeat yourself indeed. You can just put clock-names: true > [I am still not familiar enough with the yaml stuff to understand if > it has sort of inheritance like device tree include files, so that you > just have to change relevant properties] Kind of, but not entirely. schemas are all applied separately, unlike DT includes that will just expand to one big DT. In practice, it means that your device must validate against all the schemas, not just the sum of them. For example, if you have a generic schema that has: properties: compatible: const: vendor,my-generic-compatible and your schema that extends the generic binding, with a ref to the generic one that has: properties: compatible: items: - const: other-vendor,my-device-compatible - const: vendor,my-generic-compatible It will still fail since the generic schema expects only a single compatible, whereas your device would have two. > >=20 > >> + - const: iahb >=20 > would it make sense to add additionalItems: false here? >=20 > In the jz4780 case there are just two clocks while other specializations > use more and synopsys,dw-hdmi.yaml# defines additionalItems: true. If you want to refine the generic one, and it's all the clocks you ever expect then there's no need for additionalItems > >=20 > >> + description: An I2C interface if the internal DDC I2C driver is n= ot to be used > >> + ports: true > >=20 > > If there's a single port, you don't need ports >=20 > There can be two ports - one for input from LCDC and one > for output (HDMI connector). But explicitly defining an output > port is optional to some extent (depending on driver structure). This needs to be defined then (and port@0 made mandatory) Maxime