From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751380AbdGQJVA (ORCPT ); Mon, 17 Jul 2017 05:21:00 -0400 Received: from mail.free-electrons.com ([62.4.15.54]:44648 "EHLO mail.free-electrons.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751278AbdGQJU5 (ORCPT ); Mon, 17 Jul 2017 05:20:57 -0400 Date: Mon, 17 Jul 2017 11:20:45 +0200 From: Maxime Ripard To: Ulf Hansson Cc: Chen-Yu Tsai , Michael Turquette , Stephen Boyd , Rob Herring , Mark Rutland , "linux-arm-kernel@lists.infradead.org" , "linux-mmc@vger.kernel.org" , linux-clk , "devicetree@vger.kernel.org" , "linux-kernel@vger.kernel.org" , linux-sunxi Subject: Re: [PATCH 05/11] mmc: sunxi: Support controllers that can use both old and new timings Message-ID: <20170717092045.3hidokuo6w7cgorw@flea> References: <20170714064302.20383-1-wens@csie.org> <20170714064302.20383-6-wens@csie.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="4ehpzjnyhte6weth" Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20170609 (1.8.3) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org --4ehpzjnyhte6weth Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Jul 14, 2017 at 11:57:35AM +0200, Ulf Hansson wrote: > >>> + if (host->use_new_timings) { > >>> + ret =3D 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. >=20 > Right. But it would benefit that we can keep drivers generic, as they > are using generic APIs/interfaces. I prefer that. >=20 > 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 --=20 Maxime Ripard, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com --4ehpzjnyhte6weth Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAEBAgAGBQJZbIFtAAoJEBx+YmzsjxAg4DoP/3A2zAdfpPwRKRni8/xIZXeT rxKBN8LAPCm2gW85Ufk3mY54BiAUFu+8FhR6eYtlo4LVr8fTNIFGN0fYHYVfQtW+ sP8LVKDXeDpvs5v5oRduaQQclgziR8+4FwhrRe4C6mHim1s3U0HMwlxQOCw9azWk /Kq3q+Tc0LJqVChvJmuTqcdD+VgNAkJRkjWO3kmRnnatLTYoao1VJxa01iIoqU7j 3j4GGYUCfrIouecm/2UDOMi0hLjnD/IWKKCRmSUcN2tMWzdd6N2vsrrLviIXQ4td 4YSUUBzp8wcIMD4up3/wTQCUwci/S2X8uJQqDa3GO22ItrDCV6//MkqNm5xllFSK Q32qRmfNyEJ3T+M1PHUKgufmipIvXCI2Q1RYVpGc6BpODygqOkvXSFagHBitaif6 vjeJAPjkteHSQ6Y2Z2U66f9PHwgPxryFQA2lHe3pFg3uBEfVER7gsLx4O2lZf0OU k3sQ5HWZUxGk/tUcXV67Z4YVDWtHSXpjWpYSja4uqWjVf2fg/IWGeUTi8lhEfUXt GPro/dRlGwm/imCN1cPtahlzeR0iqnLBPbvq8+7em1v31JT26S7YODHFxP0T5SiV CR/q/pMe20dqqOhsz4KGAEjKo+g3hR4WdAoXtjUdzhHK27ztTS0020XIJGNWS+tO qYMLM/JqKj2kbluwuAZ3 =MAT0 -----END PGP SIGNATURE----- --4ehpzjnyhte6weth--