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 X-Spam-Level: X-Spam-Status: No, score=-7.0 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_HELO_NONE, SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id B535EC433E5 for ; Fri, 7 Aug 2020 11:37:06 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id A027A22C9F for ; Fri, 7 Aug 2020 11:37:06 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728278AbgHGLhA convert rfc822-to-8bit (ORCPT ); Fri, 7 Aug 2020 07:37:00 -0400 Received: from mail-oo1-f65.google.com ([209.85.161.65]:43049 "EHLO mail-oo1-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726293AbgHGLg7 (ORCPT ); Fri, 7 Aug 2020 07:36:59 -0400 Received: by mail-oo1-f65.google.com with SMTP id z10so353625ooi.10; Fri, 07 Aug 2020 04:36:57 -0700 (PDT) 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=XXMM2VmPbdzScEgaWzC2c7QfQOtrLAuTY8gvz9Vc4VA=; b=i2+bmzm6DH1N21mIeZptUZA7++/9Dot11W8Go1vfnZmv6NLxFyMUQ3NYRJuC/9zZy6 JX/bJkajC04xQ0mBs4txh8Yn7UV9MSBsecOVOhqPddopu6nuxkL6IbMmaXS/xAMW5Mvd nv3umyDWILaKzFR7VW4BYeeOlryd9pgvlQ4pUTT9vXozKkZfSdocnpmAfzdm0Y0pWMOv F5tLDf8S9Bh/f0zH0WTKncPNiKabeEPgjnv0/Wen5JEKC7M+AKARxSd/pGnNoYX0BaLm sXcGmj0gCJQeZz+Z/yXvZrzWEKU6vP40BbDzJy5zcH3lwP7CZr0PjAWEfKMX45B+tbll 8TSw== X-Gm-Message-State: AOAM5321t5vfKYT5soHllJlIECFhExrcIHDvk9hNqFzsqTFdqXVR4wMV ZLSjKRnGrwCzbJxf3irZSYkIYbyhRdwti3Lbm18= X-Google-Smtp-Source: ABdhPJzvkXusENrHFbx7Z4UeU5tcAYrWmu2wMgV9PP1LU7MWabSySITzZd9SeQneUYYb9H/JEkRsCIws54cijEZ+u5w= X-Received: by 2002:a4a:4201:: with SMTP id h1mr12077660ooj.1.1596800217309; Fri, 07 Aug 2020 04:36:57 -0700 (PDT) MIME-Version: 1.0 References: <1594919915-5225-1-git-send-email-prabhakar.mahadev-lad.rj@bp.renesas.com> <1594919915-5225-21-git-send-email-prabhakar.mahadev-lad.rj@bp.renesas.com> <20200807112754.GC3387836@oden.dyn.berto.se> In-Reply-To: <20200807112754.GC3387836@oden.dyn.berto.se> From: Geert Uytterhoeven Date: Fri, 7 Aug 2020 13:36:46 +0200 Message-ID: Subject: Re: [PATCH 20/20] arm64: dts: renesas: r8a774e1: Add VIN and CSI-2 nodes To: =?UTF-8?Q?Niklas_S=C3=B6derlund?= Cc: "Lad, Prabhakar" , Lad Prabhakar , Jens Axboe , Rob Herring , Vinod Koul , Mauro Carvalho Chehab , Marek Vasut , Yoshihiro Shimoda , Mark Brown , Bjorn Helgaas , Kishon Vijay Abraham I , Liam Girdwood , Greg Kroah-Hartman , Magnus Damm , "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" , linux-ide@vger.kernel.org, dmaengine , Linux I2C , Linux Kernel Mailing List , Linux Media Mailing List , linux-pci , ALSA Development Mailing List , Linux-Renesas , USB list Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8BIT Sender: dmaengine-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: dmaengine@vger.kernel.org Hi Niklas, On Fri, Aug 7, 2020 at 1:27 PM Niklas Söderlund wrote: > On 2020-08-06 13:47:58 +0200, Geert Uytterhoeven wrote: > > On Thu, Aug 6, 2020 at 1:17 PM Lad, Prabhakar > > wrote: > > > On Wed, Aug 5, 2020 at 12:19 PM Geert Uytterhoeven wrote: > > > > On Thu, Jul 16, 2020 at 7:20 PM Lad Prabhakar > > > > wrote: > > > > > Add VIN and CSI-2 nodes to RZ/G2H (R8A774E1) SoC dtsi. > > > > > > > > > > Signed-off-by: Lad Prabhakar > > > > > Reviewed-by: Marian-Cristian Rotariu > > > > > > > > Reviewed-by: Geert Uytterhoeven > > > > > > > > However, before I queue this in renesas-devel for v5.10, I'd like to > > > > have some clarification about the issue below. > > > > > > > > > --- a/arch/arm64/boot/dts/renesas/r8a774e1.dtsi > > > > > +++ b/arch/arm64/boot/dts/renesas/r8a774e1.dtsi > > > > > > > > > + vin4: video@e6ef4000 { > > > > > + compatible = "renesas,vin-r8a774e1"; > > > > > + reg = <0 0xe6ef4000 0 0x1000>; > > > > > + interrupts = ; > > > > > + clocks = <&cpg CPG_MOD 807>; > > > > > + power-domains = <&sysc R8A774E1_PD_ALWAYS_ON>; > > > > > + resets = <&cpg 807>; > > > > > + renesas,id = <4>; > > > > > + status = "disabled"; > > > > > + > > > > > + ports { > > > > > + #address-cells = <1>; > > > > > + #size-cells = <0>; > > > > > + > > > > > + port@1 { > > > > > + #address-cells = <1>; > > > > > + #size-cells = <0>; > > > > > > > > "make dtbs W=1" says: > > > > > > > > arch/arm64/boot/dts/renesas/r8a774e1.dtsi:1562.12-1572.7: Warning > > > > (graph_child_address): /soc/video@e6ef4000/ports/port@1: graph node > > > > has single child node 'endpoint@0', #address-cells/#size-cells are not > > > > necessary > > > > > > > > (same for vin5-7 below) > > > > > > > Referring to commit 5e53dbf4edb4d ("arm64: dts: renesas: r8a77990: Fix > > > VIN endpoint numbering") we definitely need endpoint numbering. > > > Probably the driver needs to be fixed to handle such cases. > > > > > > > + > > > > > + reg = <1>; > > > > > + > > > > > + vin4csi20: endpoint@0 { > > > > > + reg = <0>; > > > > > + remote-endpoint = <&csi20vin4>; > > > > On R-Car E3, the single endpoint is at address 2, so "make dtbs W=1"doesn't > > complain. Here it is at address 0. > > > > Niklas? > > First the R-Car VIN driver makes decisions based on which endpoint is > described, each endpoint 0-3 represents a different CSI-2 block on the > other end (0: CSI20, 1: CSI21, 2: CSI40 and 3: CSI41). That's my understanding, too. > Then how to handle the warning I'm not sure. I can only really see 2 > options. > > 1. Ignore the warning. > 2. Remove #address-cells, #size-cells and reg properties from port@ if > the only endpoint described is endpoint@0. > > I would prefers option 2. that is what we do in other cases (for example > on Gen2 boards that only have a single parallel sensor in some early DTS > files we don't have the ports node and just describe a single port with > the same reasoning. > > We are not at risk at someone describing a second CSI-2 bock as an > overlay so I see no real harm in option 2. Yeah, no overlay possible for on-SoC wiring ;-) > What are your thoughts Geert? > You know more about DT then me. You have too much faith in me ;-) AFAIK we don't get this warning for e.g. SPI buses, which can have a single device at address 0, and #{address,size}-cells is mandatory there. So endpoints (or SPI?) are treated special? 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 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 X-Spam-Level: X-Spam-Status: No, score=-7.0 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SIGNED_OFF_BY, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id AC379C433DF for ; Fri, 7 Aug 2020 11:37:59 +0000 (UTC) Received: from alsa0.perex.cz (alsa0.perex.cz [77.48.224.243]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 3013A22CAE for ; Fri, 7 Aug 2020 11:37:59 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=alsa-project.org header.i=@alsa-project.org header.b="I6BTFHxO" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 3013A22CAE Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=linux-m68k.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=alsa-devel-bounces@alsa-project.org Received: from alsa1.perex.cz (alsa1.perex.cz [207.180.221.201]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by alsa0.perex.cz (Postfix) with ESMTPS id 8B4461663; Fri, 7 Aug 2020 13:37:07 +0200 (CEST) DKIM-Filter: OpenDKIM Filter v2.11.0 alsa0.perex.cz 8B4461663 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=alsa-project.org; s=default; t=1596800277; bh=2vifmn4McR9qoEJw//OiO3BiekmcKVk7Q558//RI+BM=; h=References:In-Reply-To:From:Date:Subject:To:Cc:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: From; b=I6BTFHxOeiNbxGYbP8U77hcnOI0SGapaRokgTbDvz2q3aPAX/te6T2YiSZMzvaEer S3UM6ZslewMM0kwgbbLXZmZtE/Zf5i+SPfk7r9urJWE1MqJlUJzcBRxTKOaRxnyVge E/GQmWcOqJkBbP+CuaYck9QKBJmKiiiVaFtAli2g= Received: from alsa1.perex.cz (localhost.localdomain [127.0.0.1]) by alsa1.perex.cz (Postfix) with ESMTP id 32A84F80234; Fri, 7 Aug 2020 13:37:07 +0200 (CEST) Received: by alsa1.perex.cz (Postfix, from userid 50401) id D801CF8023E; Fri, 7 Aug 2020 13:37:05 +0200 (CEST) Received: from mail-oo1-f67.google.com (mail-oo1-f67.google.com [209.85.161.67]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by alsa1.perex.cz (Postfix) with ESMTPS id 2AC5FF800B7 for ; Fri, 7 Aug 2020 13:36:58 +0200 (CEST) DKIM-Filter: OpenDKIM Filter v2.11.0 alsa1.perex.cz 2AC5FF800B7 Received: by mail-oo1-f67.google.com with SMTP id p137so356395oop.4 for ; Fri, 07 Aug 2020 04:36:58 -0700 (PDT) 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=XXMM2VmPbdzScEgaWzC2c7QfQOtrLAuTY8gvz9Vc4VA=; b=L93tKPaffMJ55Bvq1hRWOQuLykNCof3qhpAp9skqVri/7hqj1e5Duxp15sF5PGque6 Lb6gZE1WUEg+5mmojEbsKKMRHkblk5reI9iJwP0aTdhWHezGwzsLaJfGdgYzhCuUbu4u NpQy8mZr/t/JvLgL83BSvFDT7Ocp1RCZcnDUVIveMoDEk7ASCZ81iYictns3KcpUB4F8 GuiIGCA9LjUaUh7Y83FTLqK5ixFNQRXVMZxzNJ3ZDiO/qoEfxa/CDLJaqina20z1mCGB JIvFmh9hrxLv3EN0U2FeO00k3nXz6kr2EF33ZAaNfV08H6i25f68XBiFL0HiSO52zwJO 5/0g== X-Gm-Message-State: AOAM531HfZVlkObyEZvVmBncptDetx4R5zREY8jXAR2FoCGvKh1uzPJF myhYQJyBkTAHO6qznWuNp/JYgpFJRbdnaAflGfg= X-Google-Smtp-Source: ABdhPJzvkXusENrHFbx7Z4UeU5tcAYrWmu2wMgV9PP1LU7MWabSySITzZd9SeQneUYYb9H/JEkRsCIws54cijEZ+u5w= X-Received: by 2002:a4a:4201:: with SMTP id h1mr12077660ooj.1.1596800217309; Fri, 07 Aug 2020 04:36:57 -0700 (PDT) MIME-Version: 1.0 References: <1594919915-5225-1-git-send-email-prabhakar.mahadev-lad.rj@bp.renesas.com> <1594919915-5225-21-git-send-email-prabhakar.mahadev-lad.rj@bp.renesas.com> <20200807112754.GC3387836@oden.dyn.berto.se> In-Reply-To: <20200807112754.GC3387836@oden.dyn.berto.se> From: Geert Uytterhoeven Date: Fri, 7 Aug 2020 13:36:46 +0200 Message-ID: Subject: Re: [PATCH 20/20] arm64: dts: renesas: r8a774e1: Add VIN and CSI-2 nodes To: =?UTF-8?Q?Niklas_S=C3=B6derlund?= Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Cc: ALSA Development Mailing List , linux-pci , Liam Girdwood , linux-ide@vger.kernel.org, "Lad, Prabhakar" , Linux I2C , Marek Vasut , Magnus Damm , Kishon Vijay Abraham I , Linux Media Mailing List , "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" , Lad Prabhakar , Rob Herring , Bjorn Helgaas , Mauro Carvalho Chehab , Jens Axboe , Greg Kroah-Hartman , Yoshihiro Shimoda , USB list , Linux Kernel Mailing List , Linux-Renesas , Vinod Koul , Mark Brown , dmaengine X-BeenThere: alsa-devel@alsa-project.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Alsa-devel mailing list for ALSA developers - http://www.alsa-project.org" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: alsa-devel-bounces@alsa-project.org Sender: "Alsa-devel" Hi Niklas, On Fri, Aug 7, 2020 at 1:27 PM Niklas S=C3=B6derlund wrote: > On 2020-08-06 13:47:58 +0200, Geert Uytterhoeven wrote: > > On Thu, Aug 6, 2020 at 1:17 PM Lad, Prabhakar > > wrote: > > > On Wed, Aug 5, 2020 at 12:19 PM Geert Uytterhoeven wrote: > > > > On Thu, Jul 16, 2020 at 7:20 PM Lad Prabhakar > > > > wrote: > > > > > Add VIN and CSI-2 nodes to RZ/G2H (R8A774E1) SoC dtsi. > > > > > > > > > > Signed-off-by: Lad Prabhakar > > > > > Reviewed-by: Marian-Cristian Rotariu > > > > > > > > Reviewed-by: Geert Uytterhoeven > > > > > > > > However, before I queue this in renesas-devel for v5.10, I'd like t= o > > > > have some clarification about the issue below. > > > > > > > > > --- a/arch/arm64/boot/dts/renesas/r8a774e1.dtsi > > > > > +++ b/arch/arm64/boot/dts/renesas/r8a774e1.dtsi > > > > > > > > > + vin4: video@e6ef4000 { > > > > > + compatible =3D "renesas,vin-r8a774e1"; > > > > > + reg =3D <0 0xe6ef4000 0 0x1000>; > > > > > + interrupts =3D ; > > > > > + clocks =3D <&cpg CPG_MOD 807>; > > > > > + power-domains =3D <&sysc R8A774E1_PD_ALWA= YS_ON>; > > > > > + resets =3D <&cpg 807>; > > > > > + renesas,id =3D <4>; > > > > > + status =3D "disabled"; > > > > > + > > > > > + ports { > > > > > + #address-cells =3D <1>; > > > > > + #size-cells =3D <0>; > > > > > + > > > > > + port@1 { > > > > > + #address-cells =3D <1>; > > > > > + #size-cells =3D <0>; > > > > > > > > "make dtbs W=3D1" says: > > > > > > > > arch/arm64/boot/dts/renesas/r8a774e1.dtsi:1562.12-1572.7: Warni= ng > > > > (graph_child_address): /soc/video@e6ef4000/ports/port@1: graph node > > > > has single child node 'endpoint@0', #address-cells/#size-cells are = not > > > > necessary > > > > > > > > (same for vin5-7 below) > > > > > > > Referring to commit 5e53dbf4edb4d ("arm64: dts: renesas: r8a77990: Fi= x > > > VIN endpoint numbering") we definitely need endpoint numbering. > > > Probably the driver needs to be fixed to handle such cases. > > > > > > > + > > > > > + reg =3D <1>; > > > > > + > > > > > + vin4csi20: endpoint@0 { > > > > > + reg =3D <0>; > > > > > + remote-endpoint = =3D <&csi20vin4>; > > > > On R-Car E3, the single endpoint is at address 2, so "make dtbs W=3D1"d= oesn't > > complain. Here it is at address 0. > > > > Niklas? > > First the R-Car VIN driver makes decisions based on which endpoint is > described, each endpoint 0-3 represents a different CSI-2 block on the > other end (0: CSI20, 1: CSI21, 2: CSI40 and 3: CSI41). That's my understanding, too. > Then how to handle the warning I'm not sure. I can only really see 2 > options. > > 1. Ignore the warning. > 2. Remove #address-cells, #size-cells and reg properties from port@ if > the only endpoint described is endpoint@0. > > I would prefers option 2. that is what we do in other cases (for example > on Gen2 boards that only have a single parallel sensor in some early DTS > files we don't have the ports node and just describe a single port with > the same reasoning. > > We are not at risk at someone describing a second CSI-2 bock as an > overlay so I see no real harm in option 2. Yeah, no overlay possible for on-SoC wiring ;-) > What are your thoughts Geert? > You know more about DT then me. You have too much faith in me ;-) AFAIK we don't get this warning for e.g. SPI buses, which can have a single device at address 0, and #{address,size}-cells is mandatory there. So endpoints (or SPI?) are treated special? Gr{oetje,eeting}s, Geert --=20 Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k= .org In personal conversations with technical people, I call myself a hacker. Bu= t when I'm talking to journalists I just say "programmer" or something like t= hat. -- Linus Torvalds