From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ulf Hansson Subject: Re: [PATCH 4/5 v3] mmc: add a function to get a regulator, supplying card's Vdd Date: Mon, 11 Jun 2012 16:43:54 +0200 Message-ID: <4FD6042A.10102@stericsson.com> References: <1925406B-D680-40BB-890A-78447EEB4583@marvell.com> <4FC33362.4010806@intel.com> <20120528144317.GF4032@opensource.wolfsonmicro.com> <20120611142332.GR11439@opensource.wolfsonmicro.com> <15DF5528-1451-4121-A572-C293B5DCA8B4@marvell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit Return-path: Received: from eu1sys200aog108.obsmtp.com ([207.126.144.125]:48599 "EHLO eu1sys200aog108.obsmtp.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755289Ab2FKOo0 (ORCPT ); Mon, 11 Jun 2012 10:44:26 -0400 In-Reply-To: <15DF5528-1451-4121-A572-C293B5DCA8B4@marvell.com> Sender: linux-mmc-owner@vger.kernel.org List-Id: linux-mmc@vger.kernel.org To: Philip Rakity Cc: Mark Brown , Guennadi Liakhovetski , Adrian Hunter , Ulf Hansson , "linux-mmc@vger.kernel.org" , Chris Ball , Magnus Damm On 06/11/2012 04:36 PM, Philip Rakity wrote: > > On Jun 11, 2012, at 7:23 AM, Mark Brown wrote: > >> On Mon, Jun 11, 2012 at 02:39:29PM +0200, Guennadi Liakhovetski wrote: >>> On Mon, 28 May 2012, Mark Brown wrote: >> >>>> Even if the supply is always on you can easily provide an always on >>>> regulator. From the point of view of the consumer if there are two >>>> physical supplies needed it's much clearer and easier to just code that >>>> and deal with the fact that we might have no control over them >>>> externally, there's nothing device specific about that process. >> >>> Mark, I'm not sure I understand your above comment correctly. The >>> function, that I add in this patch doesn't do much now, that we removed >> >>> IIUC, to satisfy Philip's requirement for a second regulator it would >>> suffice to just issue one more devm_regulator_get() and let the caller >>> deal with any errors. Is this what you're suggesting or are you against >>> adding the second regulator? We could of course also add it later, but >>> that would change the function prototype (unless we add regulator pointers >>> to struct mmc_host itself). Whith existing users such changes are a bit >>> messy... >> >> Yes, that's what I'm suggesting. I guess you could wrap the two >> regulators up in a small struct without it being too invasive? > > > Some background notes: > Historically SD cards operated with the same vccq (signaling for dat and clk pins) > and vcc (core) voltage. > usually 3.3v --> we would use one regulator to supply both. The power (regulator) > was always on and as far as the SD code was concerned never exposed > (eg regulator_get (vmmc) returned an error). > > Now enter UHS cards. They allow (require) the vccq voltage change from > 3.3v to 1.8v when operating in UHS mode (DDR50, SDR50, SDR104). > They also note that when a voltage switch is done to move the card > into UHS mode (3.3V to 1.8V) the switch may fail. In this case vcc > needs to turned off and then back on to cause the card to reinitialize. > > This led me to the conclusion two regulators are required. > vccq must be switchable between 3.3 and 1.8 > vcc must be able to be turned off/on and may be switchable to a lower voltage. > > Note: embedded MMC is different (eMMC). Since it is embedded it is > assumed by the spec that the board designed knows that they are doing > and the correct voltages are supplied. > Just some additional input; In eMMC scenario you have two regulators as well. One called vcc (power to the card) and one called vccq (io-voltage). Very much depending on the hw board design, you may use one, two or no regulator at all for these power(s). Kind regards Ulf Hansson