Received: by 2002:a05:6a10:eb17:0:0:0:0 with SMTP id hx23csp4003711pxb; Tue, 7 Sep 2021 12:21:53 -0700 (PDT) X-Google-Smtp-Source: ABdhPJx8x/RY4DN0XfKpB9j6e6F2Y1mJ5tOcsBbKITwLRT9ntndcCji8CLnFzupFy8Ue9K8/8iLe X-Received: by 2002:a17:906:a0c:: with SMTP id w12mr19731217ejf.376.1631042512942; Tue, 07 Sep 2021 12:21:52 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1631042512; cv=none; d=google.com; s=arc-20160816; b=EOazxWpvK5Q4WabkkkagQieLB3t7vTzhmB94TFEXHHaPQx0hPc73mczgLhRsaxWHDl K5lptfMzJJlSkgiiRzR7FMxSfEtzA8dmen48IKg8Rhhm6tKxLNnG3SX1JrsezTpybMP6 BiMregxTSs79kJCbfIt4fkZROEChPSe6aZ6iIrrj/OOILQjO5SqL9T/VlzgyFMsNnQyx UKcoRm4BqZsndV74pASl4ixhCtzbACzqtupS/KmmKb/alLLqWw+Lgi0vcAkd9EHUiulf no8dm84P8pup9oFm636Hfo9VgqYy26r2jXNGdQ21eGHew0P0nQYtcS8IAw5JokRCn6He aVfQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version; bh=HybJMlAw2y2ijeDg8NtpVEMi7UblwoRmrxRA4Rveu7I=; b=uzfm4+Piyx76TK6/l3mN+zyIIoDArheJnUGjvev3gBNQhpMjDLvbDHnf4UaQaObX8e Yd8TD7JEIzyqwrKqJLvyzZBKsr3F6hZTD+bZyIHp+aHjhTooD5RLOk7grZx/y3I3Ov/Y GNQ/9nxVCbM3djCSVADudKEbolkLpTuDT9v+kQYlrCG8R6CgBwEUHrDlQqotmUsCgwMw C+XyL+RqIRT9D7xS47Y7MU2aVmrTRoUqQnxGI3jvtuLuSN17bKf2xIRLBxmRZouwGkTH KnFPcZNjptJss4HUnR2elA0soqaniGGM4AcTSgokTrbNFZWMcfOWD7hQ+jT4SCJE+gFk QxdA== ARC-Authentication-Results: i=1; mx.google.com; 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id y8si11816836edc.536.2021.09.07.12.21.19; Tue, 07 Sep 2021 12:21:52 -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; 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1345993AbhIGTSv (ORCPT + 99 others); Tue, 7 Sep 2021 15:18:51 -0400 Received: from mail-vk1-f182.google.com ([209.85.221.182]:34334 "EHLO mail-vk1-f182.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230203AbhIGTSu (ORCPT ); Tue, 7 Sep 2021 15:18:50 -0400 Received: by mail-vk1-f182.google.com with SMTP id 13so125412vkl.1; Tue, 07 Sep 2021 12:17:43 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=HybJMlAw2y2ijeDg8NtpVEMi7UblwoRmrxRA4Rveu7I=; b=UHQlzCoWdaEna9A0ew1ImNuxeEQXt7cnuN+uUAfq1k/1N8EENveH1MpbrH04GYO819 yRTUv8E8jnUdrIEd4oiGs7Jxk2Kd96Km+7fC02GaIWUx2bp5wbRfRHRHHD2jQ6pIUTjj PNd209fkEOu3zTdsqBfwkAT8BwMmzzEar5Hdk21Yy1UcAcsCTAHpjBNc2j1VE9ETtQht n7AGtxXUQE9me8wGXUxcY/Ox3kqLN3/mckcy59//7xzYns+AKEokjej81OFt1LXhs02l jqU1R5f+ftyaUAIr2qzVQPDrioo6U4Em4bqYlp0gGb7T2ElzH1KJ9tvkckcgTU/Ll8Pz 8VVg== X-Gm-Message-State: AOAM5334MXtLEVt+22rH5mgk2N/mTN0hXjo3OZFtFopz7g0enQhbFC+O ziCfcGdSxnpuYsAetdeJzWgQaywsRjbLWWuJeF7wHn8z X-Received: by 2002:a1f:d247:: with SMTP id j68mr9449607vkg.7.1631042263032; Tue, 07 Sep 2021 12:17:43 -0700 (PDT) MIME-Version: 1.0 References: <20210901233655.1602308-1-kieran.bingham@ideasonboard.com> In-Reply-To: From: Geert Uytterhoeven Date: Tue, 7 Sep 2021 21:17:31 +0200 Message-ID: Subject: Re: [PATCH v2] dt-bindings: display: renesas,du: Provide bindings for r8a779a0 To: Rob Herring Cc: Kieran Bingham , Linux-Renesas , Laurent Pinchart , Kieran Bingham , David Airlie , Daniel Vetter , "open list:DRM DRIVERS FOR RENESAS" , "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" , open list Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Rob, On Tue, Sep 7, 2021 at 8:45 PM Rob Herring wrote: > On Mon, Sep 06, 2021 at 10:13:07AM +0200, Geert Uytterhoeven wrote: > > On Thu, Sep 2, 2021 at 1:39 AM Kieran Bingham > > wrote: > > > From: Kieran Bingham > > > > > > Extend the Renesas DU display bindings to support the r8a779a0 V3U. > > > > > > Reviewed-by: Laurent Pinchart > > > Signed-off-by: Kieran Bingham > > > --- > > > v2: > > > - Collected Laurent's tag > > > - Remove clock-names requirement > > > - Specify only a single clock > > > > Thanks for the update! > > > > > --- a/Documentation/devicetree/bindings/display/renesas,du.yaml > > > +++ b/Documentation/devicetree/bindings/display/renesas,du.yaml > > > @@ -39,6 +39,7 @@ properties: > > > - renesas,du-r8a77980 # for R-Car V3H compatible DU > > > - renesas,du-r8a77990 # for R-Car E3 compatible DU > > > - renesas,du-r8a77995 # for R-Car D3 compatible DU > > > + - renesas,du-r8a779a0 # for R-Car V3U compatible DU > > > > > > reg: > > > maxItems: 1 > > > @@ -773,6 +774,55 @@ allOf: > > > - reset-names > > > - renesas,vsps > > > > > > + - if: > > > + properties: > > > + compatible: > > > + contains: > > > + enum: > > > + - renesas,du-r8a779a0 > > > + then: > > > + properties: > > > + clocks: > > > + items: > > > + - description: Functional clock > > > + > > > + clock-names: > > > + maxItems: 1 > > > + items: > > > + - const: du > > > + > > > + interrupts: > > > + maxItems: 2 > > > + > > > + resets: > > > + maxItems: 1 > > > + > > > + reset-names: > > > + items: > > > + - const: du.0 > > > > This is now inconsistent with clock-names, which doesn't use a suffix. > > But it is consistent with all the other cases of 'reset-names'. The > problem is 'clock-names' is not consistent and should be 'du.0'. True. > Ideally, the if/them schemas should not be defining the names. That > should be at the top level and the if/them schema just limits the number > of entries. That's not always possible, but I think is for clocks and > resets in this case. It's a bit tricky. For clocks, there's usually one clock per channel, but not always. Plus clocks for external inputs, if present. For resets, there's one reset for a group of channels, with the number of channels in a group depending on the SoC family. And then there's the special casing for SoCs where there's a gap in the channel numbering... Still wondering if it would be better to have one device node per channel, and companion links... Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds