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 bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id DBDB9C531DC for ; Fri, 23 Aug 2024 18:22:32 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:Cc:List-Subscribe: List-Help:List-Post:List-Archive:List-Unsubscribe:List-Id:In-Reply-To: Content-Type:MIME-Version:References:Message-ID:Subject:To:Date:From:Reply-To :Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=FICRI5lzPDPrWMcBNEaOg3XU9oTCEC3UNpnHrqnVnWY=; b=VNUQ1dzu3rM7MbgL4n04NP1F/O 2K+tbUYX2C4OxI85ID9a5djR9hWW5xL1/sUgD9dHKsFYPaCWC5FEvi1wu5lSkYobCrUUo7kWAHdj3 YICnJioSdcs8LVLnyMPNJ00xxHFXyP/vYvLGh7obvY3ZQnIHMT53FQWt2dd/OngCGwCTdvmc2cqpc c8TU3UAhMstffDGdJ/8jktorZRWqOSgZJKId43CZsBwQZMKE6B8lmnNKiYfLpFW7GYmyu+MYMADGX 4UCRVowd8iDzFh0gH+NrW/9XEMDO6sb8YZy2W32WIGAG1q+HpGwJrwVpAmuaZcq3dW4yE56bUX4l8 NHomPbQA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1shYvT-00000000I5S-2ojq; Fri, 23 Aug 2024 18:22:19 +0000 Received: from mail-lf1-x136.google.com ([2a00:1450:4864:20::136]) by bombadil.infradead.org with esmtps (Exim 4.97.1 #2 (Red Hat Linux)) id 1shYuh-00000000HxZ-29bU for linux-arm-kernel@lists.infradead.org; Fri, 23 Aug 2024 18:21:32 +0000 Received: by mail-lf1-x136.google.com with SMTP id 2adb3069b0e04-53349d3071eso2837169e87.2 for ; Fri, 23 Aug 2024 11:21:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1724437289; x=1725042089; darn=lists.infradead.org; h=in-reply-to:content-disposition:mime-version:references :mail-followup-to:message-id:subject:cc:to:date:from:from:to:cc :subject:date:message-id:reply-to; bh=FICRI5lzPDPrWMcBNEaOg3XU9oTCEC3UNpnHrqnVnWY=; b=O8/rdSJL63Zlrrv9a2Dj1+Coa3gB9/IWvQjWXm4OgJAUCUpGoIvRQXykazoxvTuypN Jm3mg868pYavJx8f4RMp7CqOHVqoJ7OprjcMwKZQ3JkMTmCtYJE8nme+xiHjXGAouJbe dECrnVI9liH20+51fUKeIzviEKpQ6lwcEhL+d4LtCgfblfSTL+IEyFOrXCrPOgz5vMSv 5Tp0fBQ1moKQt/A8cgZvTYE437uNUJ0lutm8GbQ5dcxpmxciS50QSQICzSCvbYfALGQB UHFdXC71zSHCxGs8LqGKRWnS0pN6IpnBaBjglTBt77Yxlupiv7KkEcLpSSqPd02fU+ze MQfA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1724437289; x=1725042089; h=in-reply-to:content-disposition:mime-version:references :mail-followup-to:message-id:subject:cc:to:date:from :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=FICRI5lzPDPrWMcBNEaOg3XU9oTCEC3UNpnHrqnVnWY=; b=h7bfqcupJ9UNCtFCt8U74KeeEkSIqrlEz16QcZ0FRejTIR5LyOV9EbsS95PW8rbmUA K/qiOzWbiw4yNloLKObIKyD/626WfviQrkbNXRAuAaIGvTfTnr5KsW5dp+sK07VJn1o1 VhtuXzZ5rpjExc+G6VnuBtFYB5Ph+DigUlq9fYq8sPykd1ASgKkqT5hxIBFLIkOgdKJR 8SYkT4ifBXeTyTMuw3N2UQcmdBXhn/Y4828V5kDzMFTA223FO+Kc3Dugd7JhY3aFiMrd dz1pH/tK+I0Ab8HeeStORmPsNJpwKxQCwcUgUWq23eGsFvIveII+OEdhP8JIpQu4vMOa Z0MA== X-Forwarded-Encrypted: i=1; AJvYcCWOHKEiFW9ylOHNyCfolabugIOVzy/QOPsjOBFM1g4xGKt05+sFm6T7DD1qOm8MY7/F+gdUt1AGUVqykDRV3njE@lists.infradead.org X-Gm-Message-State: AOJu0Yw9LTSjM8jryJdWTqi1iI4tYqMhobI5qayDzK361EX9sOw3Duo9 PYmupOwytKsZWYc8MpRGyig8q4ikj2sHH6AenFRi/4bN8GOevKxuzhOfZQLO3sY= X-Google-Smtp-Source: AGHT+IHGMmpORef4vYjLxEDkG4MSJEX/JfR9cTLIAj6QepyUfSPuFPKAHVyeeB5MysQZc4aa4suv7g== X-Received: by 2002:a05:6512:3e1b:b0:533:d3e:16e6 with SMTP id 2adb3069b0e04-53438784950mr2355588e87.25.1724437288497; Fri, 23 Aug 2024 11:21:28 -0700 (PDT) Received: from localhost ([87.13.33.30]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-a868f299d9asm292716766b.60.2024.08.23.11.21.27 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 23 Aug 2024 11:21:28 -0700 (PDT) From: Andrea della Porta X-Google-Original-From: Andrea della Porta Date: Fri, 23 Aug 2024 20:21:34 +0200 To: Conor Dooley Subject: Re: [PATCH 01/11] dt-bindings: clock: Add RaspberryPi RP1 clock bindings Message-ID: Mail-Followup-To: Conor Dooley , Krzysztof Kozlowski , Andrea della Porta , Michael Turquette , Stephen Boyd , Rob Herring , Krzysztof Kozlowski , Conor Dooley , Florian Fainelli , Broadcom internal kernel review list , Linus Walleij , Catalin Marinas , Will Deacon , Derek Kiernan , Dragan Cvetic , Arnd Bergmann , Greg Kroah-Hartman , Nicolas Ferre , Claudiu Beznea , "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Saravana Kannan , Bjorn Helgaas , linux-clk@vger.kernel.org, devicetree@vger.kernel.org, linux-rpi-kernel@lists.infradead.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, linux-gpio@vger.kernel.org, netdev@vger.kernel.org, linux-pci@vger.kernel.org, linux-arch@vger.kernel.org, Lee Jones , Andrew Lunn , Stefan Wahren References: <8d7dd7ca5da41f2a96e3ef4e2e3f29fd0d71906a.1724159867.git.andrea.porta@suse.com> <20240820-baritone-delegate-5711f7a0bc76@spud> <20240821-exception-nearby-5adeaaf0178b@spud> <399ff156-ffc9-4d50-8e5f-a86dc82da2fa@kernel.org> <20240822-refutable-railroad-a3f111ab1e3f@spud> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20240822-refutable-railroad-a3f111ab1e3f@spud> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20240823_112131_674494_B9F6716E X-CRM114-Status: GOOD ( 48.48 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Andrew Lunn , Catalin Marinas , Michael Turquette , Claudiu Beznea , Eric Dumazet , Dragan Cvetic , Will Deacon , linux-clk@vger.kernel.org, linux-arch@vger.kernel.org, Rob Herring , Florian Fainelli , Lee Jones , Krzysztof Kozlowski , Saravana Kannan , Broadcom internal kernel review list , linux-pci@vger.kernel.org, Jakub Kicinski , Paolo Abeni , Linus Walleij , devicetree@vger.kernel.org, Conor Dooley , Arnd Bergmann , linux-gpio@vger.kernel.org, linux-rpi-kernel@lists.infradead.org, Bjorn Helgaas , Andrea della Porta , linux-arm-kernel@lists.infradead.org, Derek Kiernan , Stephen Boyd , Greg Kroah-Hartman , linux-kernel@vger.kernel.org, Stefan Wahren , netdev@vger.kernel.org, Krzysztof Kozlowski , "David S. Miller" Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org Hi Conor and Krzysztof, On 17:23 Thu 22 Aug , Conor Dooley wrote: > On Thu, Aug 22, 2024 at 11:52:27AM +0200, Krzysztof Kozlowski wrote: > > > >>>>> +examples: > > >>>>> + - | > > >>>>> + #include > > >>>>> + > > >>>>> + rp1 { > > >>>>> + #address-cells = <2>; > > >>>>> + #size-cells = <2>; > > >>>>> + > > >>>>> + rp1_clocks: clocks@18000 { > > >>>> > > >>>> The unit address does not match the reg property. I'm surprised that > > >>>> dtc doesn't complain about that. > > >>> > > >>> Agreed. I'll update the address with the reg value in the next release > > >>> > > >>>> > > >>>>> + compatible = "raspberrypi,rp1-clocks"; > > >>>>> + reg = <0xc0 0x40018000 0x0 0x10038>; > > >>>> > > >>>> This is a rather oddly specific size. It leads me to wonder if this > > >>>> region is inside some sort of syscon area? > > >>> > > >>> >From downstream source code and RP1 datasheet it seems that the last addressable > > >>> register is at 0xc040028014 while the range exposed through teh devicetree ends > > >>> up at 0xc040028038, so it seems more of a little safe margin. I wouldn't say it > > >>> is a syscon area since those register are quite specific for video clock > > >>> generation and not to be intended to be shared among different peripherals. > > >>> Anyway, the next register aperture is at 0xc040030000 so I would say we can > > >>> extend the clock mapped register like the following: > > >>> > > >>> reg = <0xc0 0x40018000 0x0 0x18000>; > > >>> > > >>> if you think it is more readable. > > >> > > >> I don't care > > > > > > Ack. > > > > > >>>>> + #clock-cells = <1>; > > >>>>> + clocks = <&clk_xosc>; > > >>>>> + > > >>>>> + assigned-clocks = <&rp1_clocks RP1_PLL_SYS_CORE>, > > >>> > > >>>> FWIW, I don't think any of these assigned clocks are helpful for the > > >>>> example. That said, why do you need to configure all of these assigned > > >>>> clocks via devicetree when this node is the provider of them? > > >>> > > >>> Not sure to understand what you mean here, the example is there just to > > >>> show how to compile the dt node, maybe you're referring to the fact that > > >>> the consumer should setup the clock freq? > > >> > > >> I suppose, yeah. I don't think a particular configuration is relevant > > >> for the example binding, but simultaneously don't get why you are > > >> assigning the rate for clocks used by audio devices or ethernet in the > > >> clock provider node. > > >> > > > > > > Honestly I don't have a strong preference here, I can manage to do some tests > > > moving the clock rate settings inside the consumer nodes but I kinda like > > > the curernt idea of a centralized node where clocks are setup beforehand. > > > In RP1 the clock generator and peripherals such as ethernet are all on-board > > > and cannot be rewired in any other way so the devices are not standalone > > > consumer in their own right (such it would be an ethernet chip wired to an > > > external CPU). But of course this is debatable, on the other hand the current > > > approach of provider/consumer is of course very clean. I'm just wondering > > > wthether you think I should take action on this or we can leave it as it is. > > > Please see also below. > > > > > >>> Consider that the rp1-clocks > > >>> is coupled to the peripherals contained in the same RP1 chip so there is > > >>> not much point in letting the peripherals set the clock to their leisure. > > >> > > >> How is that any different to the many other SoCs in the kernel? > > > > > > In fact, it isn't. Please take a look at: > > > > > > arch/arm/boot/dts/st/stm32mp15xx-dhcom-som.dtsi > > > arch/arm/boot/dts/ti/omap/omap44xx-clocks.dtsi > > > arch/arm/boot/dts/ti/omap/dra7xx-clocks.dtsi > > > arch/arm/boot/dts/nxp/imx/imx7d-zii-rpu2.dts > > > > > > and probably many others... they use the same approach, so I assumed it is at > > > least reasonable to assign the clock rate this way. > > > > Please do not bring some ancient DTS, not really worked on, as example. > > stm32 could is moderately recent but dra and omap are not. > > Right, there may be some examples like this, but there are many many > other SoCs where clocks are also not re-wireable, that do not. To me > this line of argument is akin to the clock driver calling enable on all > of the clocks because "all of the peripherals are always on the SoC". > The peripheral is the actual consumer of the clock that quote-unquote > wants the particular rate, not the clock provider, so having the rate > assignments in the consumers is the only thing that makes sense to me. > > I'll try to cook something that move the rate definition to the consumer side, then. Many thanks, Andrea