Hi Philip,
> -Original Message-
> From: Philip Rakity [mailto:prak...@marvell.com]
> Sent: Friday, March 04, 2011 4:20 AM
> To: Nath, Arindam; anath@gmail.com
> Cc: Chris Ball; linux-mmc@vger.kernel.org; Su, Henry; Lu, Aaron;
> subha...@codeaurora.org>
> Subject: Re: [PATCH 02/12] mmc
Hi..
I agreed Chris's opinion..If use CONFIG_MMC_UNSAFE_RESUME, you can know to
occur some problem..so mentions to "DANGEROUS"
If card can be removed during suspend, i think we have too many cases.
So this configuration...i think good that use only non-removable card.
If you considered every case,
On Thu, 2011-03-03 at 21:28 -0500, Chris Ball wrote:
> Hi,
>
> On Thu, Mar 03 2011, Maxim Levitsky wrote:
> > This patch breaks the CONFIG_MMC_UNSAFE_RESUME, because it sets fake
> > non-removeable flag, but the intended use of this option is to assume
> > that card is not removed _during_ suspend
Hi,
On Thu, Mar 03 2011, Maxim Levitsky wrote:
> This patch breaks the CONFIG_MMC_UNSAFE_RESUME, because it sets fake
> non-removeable flag, but the intended use of this option is to assume
> that card is not removed _during_ suspend, and it can still be removed
> during normal use.
> With this c
On Mon, 2010-12-20 at 00:11 +0200, Ohad Ben-Cohen wrote:
> Hi Chris,
>
> On Fri, Dec 17, 2010 at 2:51 AM, Chris Ball wrote:
> ...
> > Thanks, pushed to mmc-next with trivial cleanup as below:
>
> Looks good, thanks.
>
> I just briefly tested mmc-next and it looks fine.
This patch breaks the CO
Anath,
Is it sufficient to check the CAPS for voltage etc ? Now that we have a
regulator framework do we need to also look at that ?
Philip
On Mar 3, 2011, at 1:08 PM,
wrote:
>
>> -Original Message-
>> From: Nath, Arindam [mailto:arindam.n...@amd.com]
>> Sent: Thursday, March 0
Hi Dmitry,
On Fri, Feb 11 2011, Dmitry Shmidt wrote:
> commit 9cb71a1eb86a2acf0762d31af633984cf9e24d32
> Author: Dmitry Shmidt
> Date: Fri Feb 11 16:10:33 2011 -0800
>
> mmc: core: Allow sdio operations in other thread during sdio_add_func()
>
> Signed-off-by: Dmitry Shmidt
>
> diff --
> -Original Message-
> From: Nath, Arindam [mailto:arindam.n...@amd.com]
> Sent: Thursday, March 03, 2011 7:05 PM
> To: subha...@codeaurora.org; c...@laptop.org
> Cc: linux-mmc@vger.kernel.org; Su, Henry; Lu, Aaron;
> anath@gmail.com
> Subject: RE: [PATCH 02/12] mmc: sd: add support fo
Hi Subhash,
> -Original Message-
> From: subha...@codeaurora.org [mailto:subha...@codeaurora.org]
> Sent: Thursday, March 03, 2011 6:46 PM
> To: Nath, Arindam; c...@laptop.org
> Cc: linux-mmc@vger.kernel.org; Su, Henry; Lu, Aaron;
> anath@gmail.com
> Subject: RE: [PATCH 02/12] mmc: sd:
The i.MX architecture provides IMX_HAVE_PLATFORM_* macros to signal
that a selected SoC supports a certain hardware. Use them instead of
depending on ARCH_* directly.
Signed-off-by: Sascha Hauer
Acked-by: Uwe Kleine-König
Cc: Chris Ball
Cc: linux-mmc@vger.kernel.org
---
drivers/mmc/host/Kconfi
> -Original Message-
> From: linux-mmc-ow...@vger.kernel.org [mailto:linux-mmc-
> ow...@vger.kernel.org] On Behalf Of Nath, Arindam
> Sent: Wednesday, March 02, 2011 1:36 PM
> To: subha...@codeaurora.org; c...@laptop.org
> Cc: linux-mmc@vger.kernel.org; Su, Henry; Lu, Aaron;
> anath@g
> > > > > +/* Abort type definition in the command register */
> > > > > +#define SDHCI_CMD_ABORTCMD0xC0
> > > >
> > > > Won't that belong into sd.h (unless I misunderstood your last mail)?
> > > This is the bit definitions of the ABORTCMD CMD-TYPE on the bit6~7 of
> > CMD register.
> >
12 matches
Mail list logo
