From mboxrd@z Thu Jan 1 00:00:00 1970 From: Fabio Estevam Subject: Re: [RFC PATCH] CLK: Allow parent clock and rate to be configured in DT. Date: Sun, 7 Apr 2013 13:00:41 -0300 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: Matt Sealey Cc: Martin Fuzzey , Sascha Hauer , Tomasz Figa , "devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org" , Linux ARM Kernel ML , Mike Turquette List-Id: devicetree@vger.kernel.org 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? From mboxrd@z Thu Jan 1 00:00:00 1970 From: festevam@gmail.com (Fabio Estevam) Date: Sun, 7 Apr 2013 13:00:41 -0300 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 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?