Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S934531AbdDGTwD (ORCPT ); Fri, 7 Apr 2017 15:52:03 -0400 Received: from smtp.codeaurora.org ([198.145.29.96]:42858 "EHLO smtp.codeaurora.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932813AbdDGTvy (ORCPT ); Fri, 7 Apr 2017 15:51:54 -0400 DMARC-Filter: OpenDMARC Filter v1.3.2 smtp.codeaurora.org 8FDD660D6E Authentication-Results: pdx-caf-mail.web.codeaurora.org; dmarc=none (p=none dis=none) header.from=codeaurora.org Authentication-Results: pdx-caf-mail.web.codeaurora.org; spf=none smtp.mailfrom=sboyd@codeaurora.org Date: Fri, 7 Apr 2017 12:51:52 -0700 From: Stephen Boyd To: Gabriel Fernandez Cc: Rob Herring , Mark Rutland , Russell King , Maxime Coquelin , Alexandre Torgue , Michael Turquette , Nicolas Pitre , Arnd Bergmann , daniel.thompson@linaro.org, andrea.merello@gmail.com, radoslaw.pietrzyk@gmail.com, Lee Jones , devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, linux-clk@vger.kernel.org, ludovic.barre@st.com, olivier.bideau@st.com, amelie.delaunay@st.com Subject: Re: [PATCH] clk: stm32h7: Add stm32h743 clock driver Message-ID: <20170407195152.GH7065@codeaurora.org> References: <1489569810-24350-1-git-send-email-gabriel.fernandez@st.com> <20170405223233.GJ7065@codeaurora.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1814 Lines: 50 On 04/06, Gabriel Fernandez wrote: > On 04/06/2017 12:32 AM, Stephen Boyd wrote: > >On 03/15, gabriel.fernandez@st.com wrote: > >>diff --git a/Documentation/devicetree/bindings/clock/st,stm32h7-rcc.txt b/Documentation/devicetree/bindings/clock/st,stm32h7-rcc.txt > >>new file mode 100644 > >>index 0000000..9d4b587 > >>--- /dev/null > >>+++ b/Documentation/devicetree/bindings/clock/st,stm32h7-rcc.txt > >>@@ -0,0 +1,152 @@ > >>+ > >>+ rcc: rcc@58024400 { > >>+ #reset-cells = <1>; > >>+ #clock-cells = <2> > >>+ compatible = "st,stm32h743-rcc", "st,stm32-rcc"; > >>+ reg = <0x58024400 0x400>; > >>+ clocks = <&clk_hse>, <&clk_lse>, <&clk_i2s_ckin>; > >>+ > >>+ st,syscfg = <&pwrcfg>; > >>+ > >>+ #address-cells = <1>; > >>+ #size-cells = <0>; > >>+ > >>+ vco1@58024430 { > >>+ #clock-cells = <0>; > >>+ compatible = "stm32,pll"; > >>+ reg = <0>; > >reg is super confusing and doesn't match unit address. > ok i fixed it in the v2 > > > > >>+ }; > >Why? Shouldn't we know this from the compatible string how many > >PLLs there are and where they're located? Export the PLLs through > >rcc node's clock-cells? > > > Because i need to offer the possibility to change the PLL VCO > frequencies at the start-up of this driver clock. > The VCO algorithm needs a division factor, a multiplication factor > and a fractional factor. > Lot's of solution are possible for one frequency and it's nightmare > to satisfy the 3 output dividers of the PLL. Sure, but do we need to configure that on a per-board basis or a per-SoC basis? If it's just some configuration, I wonder why we don't put that into the driver and base it off some compatible string that includes the SoC the device is for. -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project