From mboxrd@z Thu Jan 1 00:00:00 1970 From: Matt Sealey Subject: Re: [RFC PATCH] CLK: Allow parent clock and rate to be configured in DT. Date: Sun, 7 Apr 2013 11:34:14 -0500 Message-ID: References: <20130319170933.28337.50448.stgit@localhost> <6581638.FPkNsv6peb@flatron> <20130407132623.GP1906@pengutronix.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: devicetree-discuss-bounces+gldd-devicetree-discuss=m.gmane.org-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org Sender: "devicetree-discuss" To: Fabio Estevam Cc: Martin Fuzzey , Mike Turquette , Sascha Hauer , Tomasz Figa , "devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org" , Linux ARM Kernel ML List-Id: devicetree@vger.kernel.org Or actually, let me rephrase that; sure, when we decide that the actual clock tree is described IN the device tree and not in Linux - the only thing I have to test this on is i.MX and OMAP and it's all a huge table in the Linux kernel which the DT uses to reference arbitrary indices into a provider array... I could add desired parents to the provider array but that wouldn't really fix the configuration problem. Can we get an agreement that actually, no matter how "unwieldy" or "unreadable" some people think it might be, that the entire clock tree for a board should end up in it's device tree (muxes, selects, gates and all) with suitable bindings? This is the only way you'll get clock "hacks" out of the source. I do have a kernel tree for some 3.8-rc (which you know of already) which started work on this and I had some success with it. I'll need a little while to move it forward after Shawn moved some things around, rebase all the work.. there are more problems to fix with how everything "works" right now than just a need for configuration data, which is why I am so opposed to adding that configuration data. It supposes that we are giving complete descriptions already anyway, and my proposal relies on having complete descriptions anyway, when we are not in either case. Give me a couple weeks and I'll probably have it done, if nothing moves under my feet again.. At the point where we have two proposals here; implement 100 clocks as device tree nodes, or implement multiple ways of providing clock reparenting and frequency setting information as a configuration clock, I would rather implement those 100 clocks as nodes.. Matt Sealey Product Development Analyst, Genesi USA, Inc. On Sun, Apr 7, 2013 at 11:23 AM, Matt Sealey wrote: > On Sun, Apr 7, 2013 at 11:00 AM, Fabio Estevam wrote: >> On Sun, Apr 7, 2013 at 12:50 PM, Matt Sealey wrote: >> >>> If we're dealing with audio codecs, fix the audio codec to accept a >>> *table* of possible clock values and if that hardware operates >>> differently per clock value, then add that data in there too (like the >>> cs42l52 audio codec). Where the software and hardware is a little more >>> dynamic, the same binding works here - and the usual trick is just >>> force one configuration possible out of many. The board designer can >>> look at all the possibilities and choose the one or two or all that >>> will work with the design, and it can go into the device tree. >> >> Sorry, but I have a hard time following a so long response. >> >> Can't you just send patches to the list with your proposal so that we >> can move forward with the idea? > > Sure. > > -- > Matt Sealey > Product Development Analyst, Genesi USA, Inc. From mboxrd@z Thu Jan 1 00:00:00 1970 From: matt@genesi-usa.com (Matt Sealey) Date: Sun, 7 Apr 2013 11:34:14 -0500 Subject: [RFC PATCH] CLK: Allow parent clock and rate to be configured in DT. In-Reply-To: References: <20130319170933.28337.50448.stgit@localhost> <6581638.FPkNsv6peb@flatron> <20130407132623.GP1906@pengutronix.de> Message-ID: To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org Or actually, let me rephrase that; sure, when we decide that the actual clock tree is described IN the device tree and not in Linux - the only thing I have to test this on is i.MX and OMAP and it's all a huge table in the Linux kernel which the DT uses to reference arbitrary indices into a provider array... I could add desired parents to the provider array but that wouldn't really fix the configuration problem. Can we get an agreement that actually, no matter how "unwieldy" or "unreadable" some people think it might be, that the entire clock tree for a board should end up in it's device tree (muxes, selects, gates and all) with suitable bindings? This is the only way you'll get clock "hacks" out of the source. I do have a kernel tree for some 3.8-rc (which you know of already) which started work on this and I had some success with it. I'll need a little while to move it forward after Shawn moved some things around, rebase all the work.. there are more problems to fix with how everything "works" right now than just a need for configuration data, which is why I am so opposed to adding that configuration data. It supposes that we are giving complete descriptions already anyway, and my proposal relies on having complete descriptions anyway, when we are not in either case. Give me a couple weeks and I'll probably have it done, if nothing moves under my feet again.. At the point where we have two proposals here; implement 100 clocks as device tree nodes, or implement multiple ways of providing clock reparenting and frequency setting information as a configuration clock, I would rather implement those 100 clocks as nodes.. Matt Sealey Product Development Analyst, Genesi USA, Inc. On Sun, Apr 7, 2013 at 11:23 AM, Matt Sealey wrote: > On Sun, Apr 7, 2013 at 11:00 AM, Fabio Estevam wrote: >> On Sun, Apr 7, 2013 at 12:50 PM, Matt Sealey wrote: >> >>> If we're dealing with audio codecs, fix the audio codec to accept a >>> *table* of possible clock values and if that hardware operates >>> differently per clock value, then add that data in there too (like the >>> cs42l52 audio codec). Where the software and hardware is a little more >>> dynamic, the same binding works here - and the usual trick is just >>> force one configuration possible out of many. The board designer can >>> look at all the possibilities and choose the one or two or all that >>> will work with the design, and it can go into the device tree. >> >> Sorry, but I have a hard time following a so long response. >> >> Can't you just send patches to the list with your proposal so that we >> can move forward with the idea? > > Sure. > > -- > Matt Sealey > Product Development Analyst, Genesi USA, Inc.