From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752828AbdBGBEf (ORCPT ); Mon, 6 Feb 2017 20:04:35 -0500 Received: from smtp.codeaurora.org ([198.145.29.96]:42026 "EHLO smtp.codeaurora.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751967AbdBGBEb (ORCPT ); Mon, 6 Feb 2017 20:04:31 -0500 DMARC-Filter: OpenDMARC Filter v1.3.2 smtp.codeaurora.org B545960A7C 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: Mon, 6 Feb 2017 17:04:26 -0800 From: Stephen Boyd To: Florian Fainelli Cc: Florian Fainelli , Markus Mayer , Markus Mayer , Michael Turquette , Rob Herring , Mark Rutland , Viresh Kumar , "Rafael J . Wysocki" , Arnd Bergmann , Broadcom Kernel List , Linux Clock List , Power Management List , Device Tree List , ARM Kernel List , Linux Kernel Mailing List Subject: Re: [PATCH v5 1/2] dt-bindings: brcm: clocks: add binding for brcmstb-cpu-clk-div Message-ID: <20170207010426.GO25384@codeaurora.org> References: <20170119002933.7529-1-code@mmayer.net> <20170119002933.7529-2-code@mmayer.net> <20170121005202.GB8801@codeaurora.org> <20170203200652.GD25384@codeaurora.org> <20170206225914.GJ25384@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 On 02/06, Florian Fainelli wrote: > On 02/06/2017 02:59 PM, Stephen Boyd wrote: > > On 02/03, Florian Fainelli wrote: > >> > >> We already have another piece of drive code that manipulates registers > >> in the Bus Interface Unit located in drivers/soc/bcm/brcmstb/biuctrl.c > >> and which has little to nothing to do with the CPU's clock ratio. And > >> actually another one being submitted that deals with the CPU's > >> read-ahead cache. I would very much prefer we keep all of them separate > >> and dealing with just the register offset they need to do, but that does > >> not mean the Device Tree binding has to look that way though. > >> > >> The binding for the BIUCTRL register made it here: > >> > >> Documentation/devicetree/bindings/arm/bcm/brcm,brcmstb.txt > >> > >> so we should re-use that, and have a small piece of clock provided that > >> just uses the relevant register range within that larger register space > >> and provide the CLOCK_RATIO. Does that work? > >> > > > > Ok. That's fine. The existing binding will be updated to include > > this new subnode then for the clock component? > > Humm, I suppose we could do that yes, my original thought was to just > have this CPU clock provider remap the entire BIUCTRL register range > (of_iomap() etc.) and manipulate just the relevant register range of > interest (CPU_CLOCK_CONFIG_REG), but if you want a sub-node to appear, > we could probably do that as well. One node is fine as well. I thought the plan was many subnodes based on the binding document you mentioned earlier. -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project