From mboxrd@z Thu Jan 1 00:00:00 1970 From: Maxime Ripard Subject: Re: [PATCH 05/11] mmc: sunxi: Support controllers that can use both old and new timings Date: Mon, 17 Jul 2017 11:20:45 +0200 Message-ID: <20170717092045.3hidokuo6w7cgorw@flea> References: <20170714064302.20383-1-wens@csie.org> <20170714064302.20383-6-wens@csie.org> Reply-To: maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="4ehpzjnyhte6weth" Return-path: Sender: linux-sunxi-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org Content-Disposition: inline In-Reply-To: List-Post: , List-Help: , List-Archive: , List-Unsubscribe: , To: Ulf Hansson Cc: Chen-Yu Tsai , Michael Turquette , Stephen Boyd , Rob Herring , Mark Rutland , "linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org" , "linux-mmc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" , linux-clk , "devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" , "linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" , linux-sunxi List-Id: linux-mmc@vger.kernel.org --4ehpzjnyhte6weth Content-Type: text/plain; charset="UTF-8" Content-Disposition: inline On Fri, Jul 14, 2017 at 11:57:35AM +0200, Ulf Hansson wrote: > >>> + if (host->use_new_timings) { > >>> + ret = sunxi_ccu_set_mmc_timing_mode(host->clk_mmc, true); > >> > >> Can't this be solved through some other generic API/interface? > > > > The old discussion is here: https://lkml.org/lkml/2017/5/5/77 > > > > It is possible to piggy back on existing API, but as Maxime mentioned > > back in the discussion, it is confusing. > > > > IIRC Mike said (via Maxime) an SoC specific call was the easy way > > to handle this. I don't think there's anything generic about this. > > Even if you could have a _set_mode callback for the clks, the modes > > would be SoC specific anyway. > > Right. But it would benefit that we can keep drivers generic, as they > are using generic APIs/interfaces. I prefer that. > > Anyway, let me try to dig up the earlier discussion. There's really not any generic way to support that. Even if we reuse some other function (clk_set_phase/clk_get_phase was suggested), and use error codes and / or values to differentiate between two modes, this will be very much implementation-specific as well, and any other SoC that in theory would be using that will very likely to not implement the same behaviour for its clocks. And this driver is only used on one SoC family, so it's not really a big deal anyway. Maxime -- Maxime Ripard, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com --4ehpzjnyhte6weth--