public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Ulf Hansson <ulf.hansson@stericsson.com>
To: Mark Brown <broonie@opensource.wolfsonmicro.com>
Cc: Liam Girdwood <lrg@slimlogic.co.uk>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Mattias WALLIN <mattias.wallin@stericsson.com>,
	Jonas ABERG <jonas.aberg@stericsson.com>,
	Lee Jones <lee.jones@linaro.org>
Subject: Re: [PATCH] regulator: core: Keep boot_on regulators powered during init
Date: Tue, 24 Apr 2012 10:09:40 +0200	[thread overview]
Message-ID: <4F965FC4.7010502@stericsson.com> (raw)
In-Reply-To: <20120423180140.GR8318@opensource.wolfsonmicro.com>

On 04/23/2012 08:01 PM, Mark Brown wrote:
> On Mon, Apr 23, 2012 at 02:45:10PM +0200, Ulf Hansson wrote:
>
>> A typical mmc host driver is when finished it's probe routine,
>> trigger of a so called mmc_rescan work which is taking care of
>> detecting and initializing the eMMC card. It is a quite complicated
>> procedure which preferably not to be handled from the host driver's
>> probe function.
>
>> If the platform already have booted from the eMMC card, the card is
>> already powered an initialized from a bootloader. Cutting the power
>> without first notifying the card by sending commands to it, must be
>> prevented and also violates the eMMC specification. In the end, it
>> will mean that the detect and initialization procedure fails.
>
> Can the driver use is_enabled() in the probe routine to check the
> current status during probe and hand off appropriately?  The issue here
> seems like it's the fact that the driver isn't managing to bootstrapping
> of its state well.

Well, it is not as simple as that. An mmc host driver is just a driver 
for handling a certain mmc IP. Uper layers handles the (e)MMC/SD/SDIO 
protocol including controlling power the card. Moreover the complicated 
detect procedure is handled in a work.

In principle what you are proposing will mean that each mmc host driver 
will have to "flush" the rescan work from probe. This will have horrid 
impact on boot time since rescan can take several hundred of 
milliseconds for each eMMC/SD/SDIO card. Is is far better to handle the 
rescan in parallel works.

I really think it would be much beneficial to be able to tell the late 
init call (regulator_init_completet) to back off from disabling this 
regulator. If not using boot_on, we can invent another regulator 
constraint for this. What do you think of this?

>
> Worst case seems to be that the card will be briefly powered during boot
> then turned off again after enumeration which doesn't seem like the end
> of the world to me.

It is really crucial that the regulator is not switched off in an 
uncontrolled manner. It will mean viloating eMMC spec and in many cases 
the hw is not able to reset the eMMC and thus the detect procedure will 
fail. Likely the eMMC holds root file system then the platform wont boot...

Kind regards
Ulf Hansson

  reply	other threads:[~2012-04-24  8:10 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-04-23  9:37 [PATCH] regulator: core: Keep boot_on regulators powered during init Ulf Hansson
2012-04-23 10:18 ` Mark Brown
2012-04-23 10:52   ` Ulf Hansson
2012-04-23 11:05     ` Mark Brown
2012-04-23 12:21       ` Ulf Hansson
2012-04-23 12:25         ` Mark Brown
2012-04-23 12:45           ` Ulf Hansson
2012-04-23 18:01             ` Mark Brown
2012-04-24  8:09               ` Ulf Hansson [this message]
2012-04-24 10:56                 ` Mark Brown
2012-04-24 12:43                   ` Ulf Hansson
2012-04-25  8:02                     ` Mark Brown
2012-04-25  9:37                       ` Ulf Hansson
2012-04-25  9:58                         ` Mark Brown
2012-04-25 16:45                           ` Jassi Brar
2012-04-25 15:34               ` Jassi Brar
2012-04-25 15:44                 ` Ulf Hansson
2012-04-25 16:31                   ` Jassi Brar
2012-04-26  8:35                 ` Mark Brown
2012-04-26  9:10                   ` Jassi Brar

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4F965FC4.7010502@stericsson.com \
    --to=ulf.hansson@stericsson.com \
    --cc=broonie@opensource.wolfsonmicro.com \
    --cc=jonas.aberg@stericsson.com \
    --cc=lee.jones@linaro.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lrg@slimlogic.co.uk \
    --cc=mattias.wallin@stericsson.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox