2010/8/31 Mark Brown :
> On Sun, Aug 29, 2010 at 05:30:48PM +0200, Linus Walleij wrote:
>> 2010/8/29 Mark Brown :
>
>> > This seems like the wrong approach; if there's a problem it'd seem much
>> > better to fix the core code that everything is sharing rather than
>> > factor it out - the location
On Sun, Aug 29, 2010 at 05:30:48PM +0200, Linus Walleij wrote:
> 2010/8/29 Mark Brown :
> > This seems like the wrong approach; if there's a problem it'd seem much
> > better to fix the core code that everything is sharing rather than
> > factor it out - the location of the code is orthogonal to i
2010/8/29 Mark Brown :
> On Sat, Aug 28, 2010 at 04:48:58PM +0200, Linus Walleij wrote:
>> 2010/8/27 Chris Ball :
>
>> > Looks like this patch got dropped because of the missing modifications
>> > to arch/arm/mach-omap2/mmc-twl4030.c. Are we still interested in the
>> > patch otherwise, and can an
On Sat, Aug 28, 2010 at 04:48:58PM +0200, Linus Walleij wrote:
> 2010/8/27 Chris Ball :
> > Looks like this patch got dropped because of the missing modifications
> > to arch/arm/mach-omap2/mmc-twl4030.c. Are we still interested in the
> > patch otherwise, and can anyone help with that?
> Actual
2010/8/27 Chris Ball :
> Looks like this patch got dropped because of the missing modifications
> to arch/arm/mach-omap2/mmc-twl4030.c. Are we still interested in the
> patch otherwise, and can anyone help with that?
Actually just before the summer I submitted something not quite similar:
I move
Hi Daniel,
On Thu, Dec 03, 2009 at 01:46:30PM +0100, Daniel Mack wrote:
> At the moment, regulator operations are done from individual mmc host
> drivers. This is a problem because the regulators are not claimed
> exclusively but the mmc core enables and disables them according to the
> return val
On Friday 04 December 2009, Daniel Mack wrote:
> On Thu, Dec 03, 2009 at 10:12:36PM +0200, Adrian Hunter wrote:
> > Daniel Mack wrote:
> > >On Thu, Dec 03, 2009 at 04:27:39PM +0200, Adrian Hunter wrote:
>
> > >>What about arch/arm/mach-omap2/mmc-twl4030.c ?
> > >
> > >Argh, missed that one. And th
.org; linux-
> ker...@vger.kernel.org; madhu...@ti.com >> Madhusudhan Chikkature; Cliff
> Brake; Russell King; Pierre Ossman; Robert Jarzmik; Andrew Morton; linux-
> arm-ker...@lists.infradead.org; Liam Girdwood
> Subject: Re: [PATCH] mmc: move regulator handling to core
>
> On Fri
On Fri, Dec 04, 2009 at 12:58:05PM +0100, Daniel Mack wrote:
> > >On Thu, Dec 03, 2009 at 04:27:39PM +0200, Adrian Hunter wrote:
>
> > >>What about arch/arm/mach-omap2/mmc-twl4030.c ?
> > >
> > >Argh, missed that one. And this particular case doesn't fit to my
> > >modifications. I don't know the
On Thu, Dec 03, 2009 at 10:12:36PM +0200, Adrian Hunter wrote:
> Daniel Mack wrote:
> >On Thu, Dec 03, 2009 at 04:27:39PM +0200, Adrian Hunter wrote:
> >>What about arch/arm/mach-omap2/mmc-twl4030.c ?
> >
> >Argh, missed that one. And this particular case doesn't fit to my
> >modifications. I don'
Daniel Mack wrote:
On Thu, Dec 03, 2009 at 04:27:39PM +0200, Adrian Hunter wrote:
gDaniel Mack wrote:
[...]
drivers/mmc/core/core.c | 36
drivers/mmc/core/host.c |3 +++
drivers/mmc/host/mmci.c | 28
drivers/mmc/hos
On Thu, Dec 03, 2009 at 04:27:39PM +0200, Adrian Hunter wrote:
> gDaniel Mack wrote:
[...]
> > drivers/mmc/core/core.c | 36
> > drivers/mmc/core/host.c |3 +++
> > drivers/mmc/host/mmci.c | 28
> > drivers/mmc/host/mmci
On Thu, Dec 03, 2009 at 02:58:25PM +, Russell King - ARM Linux wrote:
> On Thu, Dec 03, 2009 at 01:22:41PM +, Mark Brown wrote:
> > without power control). This goes back to the thing about using
> > regulator_get_exclusive(), the message given was that the MMC drivers
> > really needed t
On Thu, Dec 03, 2009 at 01:22:41PM +, Mark Brown wrote:
> On Thu, Dec 03, 2009 at 02:14:23PM +0100, Daniel Mack wrote:
> > I would expect the power to be killed when the last user stops using it.
> > Which should result in the same effect if you only have one host, one
> > regulator, and one us
gDaniel Mack wrote:
At the moment, regulator operations are done from individual mmc host
drivers. This is a problem because the regulators are not claimed
exclusively but the mmc core enables and disables them according to the
return value of regulator_is_enabled(). That can lead to a number of
On Thu, Dec 03, 2009 at 01:40:32PM +, Mark Brown wrote:
> On Thu, Dec 03, 2009 at 02:32:00PM +0100, Daniel Mack wrote:
[...]
> > The mmci people would need to answer that. To me, the code just looked
> > like a power saving feature.
>
> > If this driver needs it, the only tweak to my patch t
On Thu, Dec 03, 2009 at 02:32:00PM +0100, Daniel Mack wrote:
> On Thu, Dec 03, 2009 at 01:22:41PM +, Mark Brown wrote:
> > On Thu, Dec 03, 2009 at 02:14:23PM +0100, Daniel Mack wrote:
> > > I would expect the power to be killed when the last user stops using it.
> > > Which should result in th
On Thu, Dec 03, 2009 at 01:22:41PM +, Mark Brown wrote:
> On Thu, Dec 03, 2009 at 02:14:23PM +0100, Daniel Mack wrote:
[...]
> > I would expect the power to be killed when the last user stops using it.
> > Which should result in the same effect if you only have one host, one
> > regulator, an
On Thu, Dec 03, 2009 at 02:14:23PM +0100, Daniel Mack wrote:
> On Thu, Dec 03, 2009 at 01:06:27PM +, Mark Brown wrote:
> > This is historical, they can all be converted to regulator_get_exclusive()
> > so the move to the core (while good) isn't required for this reason.
> Is it? What if you s
On Thu, Dec 03, 2009 at 01:06:27PM +, Mark Brown wrote:
> On Thu, Dec 03, 2009 at 01:46:30PM +0100, Daniel Mack wrote:
> > At the moment, regulator operations are done from individual mmc host
> > drivers. This is a problem because the regulators are not claimed
> > exclusively but the mmc core
On Thu, Dec 03, 2009 at 01:46:30PM +0100, Daniel Mack wrote:
> At the moment, regulator operations are done from individual mmc host
> drivers. This is a problem because the regulators are not claimed
> exclusively but the mmc core enables and disables them according to the
This is historical, the
21 matches
Mail list logo
