Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751940AbZG2Uze (ORCPT ); Wed, 29 Jul 2009 16:55:34 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1751658AbZG2Uzd (ORCPT ); Wed, 29 Jul 2009 16:55:33 -0400 Received: from mail-bw0-f219.google.com ([209.85.218.219]:34927 "EHLO mail-bw0-f219.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751120AbZG2Uzc convert rfc822-to-8bit (ORCPT ); Wed, 29 Jul 2009 16:55:32 -0400 DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=sUm6qpHk1u+AOcZ2ODkyq+Qkz66f0GwScUvUypbJqMgtrAhktcCjRhpD7ESg8mrMOa vR96s5SLk/mGlbqm47z+gt6QKHH0yfELmGdLxP2UnM/hwx2la7Mijc7smglpO18ZYRpW zmMyEoINjPbLl2d+nu9KteiB15llUSqxWTnmQ= MIME-Version: 1.0 In-Reply-To: <20090729201702.GA28202@linux-sh.org> References: <20090729115817.GA12223@rakim.wolfsonmicro.main> <20090729124233.GA12802@rakim.wolfsonmicro.main> <4A704777.70001@mnementh.co.uk> <4A7053E8.8050303@mnementh.co.uk> <20090729201702.GA28202@linux-sh.org> Date: Wed, 29 Jul 2009 22:55:31 +0200 Message-ID: <74d0deb30907291355n39df7db0v1d7afc93917adc14@mail.gmail.com> Subject: Re: MMC: Make the configuration memory resource optional From: pHilipp Zabel To: Paul Mundt , Ian Molton , Magnus Damm , Mark Brown , Guennadi Liakhovetski , linux-kernel@vger.kernel.org, Pierre Ossman , Magnus Damm Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2644 Lines: 62 On Wed, Jul 29, 2009 at 10:17 PM, Paul Mundt wrote: > On Wed, Jul 29, 2009 at 02:51:36PM +0100, Ian Molton wrote: >> Magnus Damm wrote: >> >Note that I don't need clocklib to get the tmio_mmc driver working for >> >my platform. It's something _you_ need for the MFD chips. But you seem >> >to want me to fix it for you even though I don't have any particular >> >need for it. >> >> Actually, the tmio-mmc driver works perfectly on the MFD chips right >> now. These are the chips it was written to handle. >> > And these patches are fixing up the mmc driver to support the non-MFD > case. If you want to fix up the MFD driver to expose a similar interface > to the mmc one as what we are doing with the clock framework, that is > fine, but is likewise an unrelated change. > > Lets evaluate the clock options we have today: > > ? ? ? ?1) clock framework > ? ? ? ?2) clkdev 2) is nothing more than an implementation detail of 1). How clk_get looks up the struct clk internally should not be of any concern to the consumer. > ? ? ? ?3) clocklib > > #1 is what these patches are written for, and the only standard in-tree > interface that we have cross platform today. #2 could be generalized, but > that needs discussion by itself, as it was never proposed as a standard > interface and never submitted to l-k for review. #3 is not in the kernel > today and it's not clear that it ever will be. Yes, 3) is unlikely to happen in the near future. [...] > If you can show what is wrong with how the clock framework is being used > in the patch that Guennadi posted, we will certainly rework it as > necessary. However, I will not at this point be merging clkdev in to my > architecture tree, and clocklib I have never supported. These are things > that can be done and supported incrementally, but making these > prerequisites is simply blocking progress, especially when there is no > consensus on the clkdev/clocklib parts. Providing the clock consumer ID via platform data is wrong. As I understand it, that ID should be either NULL if the clock can be determined from the struct device pointer (i.e. if it's the only clock provided to that device), or it should be used to distinguish the device's clock input pins (in the tmio-mmc case that would be 'hclk' or 'clk32' if I remember the datasheet correctly). >> Can we keep it technical now, please? [...] regards Philipp -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/