Message-ID: <4F969FE8.7040500@stericsson.com>
Date:	Tue, 24 Apr 2012 14:43:20 +0200
From:	Ulf Hansson <ulf.hansson@...ricsson.com>
To:	Mark Brown <broonie@...nsource.wolfsonmicro.com>
Cc:	Liam Girdwood <lrg@...mlogic.co.uk>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Mattias WALLIN <mattias.wallin@...ricsson.com>,
	Jonas ABERG <jonas.aberg@...ricsson.com>,
	Lee Jones <lee.jones@...aro.org>
Subject: Re: [PATCH] regulator: core: Keep boot_on regulators powered during
 init

On 04/24/2012 12:56 PM, Mark Brown wrote:
> On Tue, Apr 24, 2012 at 10:09:40AM +0200, Ulf Hansson wrote:
>> On 04/23/2012 08:01 PM, Mark Brown wrote:
>
>>> 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.
>
> No, that's not what I'm suggesting - all I'm suggesting is that the
> driver uses is_enabled() in probe() to check if the regulator is on, if
> it is then it grabs a reference to it.  Then, when it's figured out
> what's going on, it can drop the reference again if it's not needed.

The problem is how it should "figure out what is going on", all that 
stuff is handled from the protocol layer.

So if grabbing a reference, there is no good point in the code were I 
can drop it. Moreover _every_ host driver needs to handle this. It will 
likely become a "hack" is my first impression.

>> 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?
>
> This just seems awfully fragile and very much dependant on things like
> having the driver actually enabled to clean up later.

Setting this constraint is not done be "default", it could be clearly be 
stated that the consumer must handle the enable/disable, otherwise the 
regulator will be left in the state it was when the kernel booted.

>
>>> 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...
>
> Right, but I'm talking about uncontrolled enables not disables - worst
> case is you'll have to do an ordered shutdown you wouldn't otherwise
> have to do but that doesn't seem like the end of the world.


Kind regards
Ulf Hansson
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists