On the Ux500 we have different regulators to different card slots
and eMMCs, and some have no regulator. Move the hardcoded vmmc
regulator name to platform data and supply it that way for the
platforms that use it. Remove the ugly and unneeded #ifdef around
the regulator fetch code at the same
On Thu, Dec 02, 2010 at 12:35:07PM +0100, Linus Walleij wrote:
On the Ux500 we have different regulators to different card slots
and eMMCs, and some have no regulator. Move the hardcoded vmmc
regulator name to platform data and supply it that way for the
platforms that use it. Remove the ugly
On Thu, Dec 02, 2010 at 12:35:07PM +0100, Linus Walleij wrote:
On the Ux500 we have different regulators to different card slots
and eMMCs, and some have no regulator. Move the hardcoded vmmc
regulator name to platform data and supply it that way for the
You should never be passing regulator
On Thu, Dec 02, 2010 at 11:57:00AM +, Russell King - ARM Linux wrote:
It seems that the regulator code is making all the same mistakes that
historically were made with the clk API code.
It's not...
Rather than using the struct device, it's trying to use the regulator
...it does exactly
On Thu, Dec 02, 2010 at 12:03:18PM +, Mark Brown wrote:
On Thu, Dec 02, 2010 at 12:35:07PM +0100, Linus Walleij wrote:
On the Ux500 we have different regulators to different card slots
and eMMCs, and some have no regulator. Move the hardcoded vmmc
regulator name to platform data and
On Thu, Dec 02, 2010 at 12:28:27PM +, Russell King - ARM Linux wrote:
The way the MMCI code is, it only requests one regulator per AMBA
device, and therefore only one regulator per struct device. So I
don't think the current code needs changing in any way provided the
struct device is
2010/12/2 Mark Brown broo...@opensource.wolfsonmicro.com:
On Thu, Dec 02, 2010 at 12:28:27PM +, Russell King - ARM Linux wrote:
The way the MMCI code is, it only requests one regulator per AMBA
device, and therefore only one regulator per struct device. So I
don't think the current code