diff mbox

am3517: geting MMC working

Message ID 50091045.7060102@visionsystems.de (mailing list archive)
State New, archived
Headers show

Commit Message

Yegor Yefremov July 20, 2012, 8:01 a.m. UTC
Am 20.07.2012 09:39, schrieb Yegor Yefremov:
> Am 20.07.2012 09:28, schrieb T Krishnamoorthy, Balaji:
>> On Fri, Jul 20, 2012 at 3:08 AM, Paul Walmsley <paul@pwsan.com> wrote:
>>> On Thu, 19 Jul 2012, S, Venkatraman wrote:
>>>
>>>> >From this, one can only infer that the card is not responding at all,
>>>> and all attempts
>>>> are returning with a timeout (CTO=Command Time Out).
>>> Looks to me like the card is responding to CMD8, CMD55, ACMD41, and CMD0.
>>> It's only CMD52 and CMD5 that are timing out.  Aren't those timeouts
>>> expected with a SD memory card?
>> yes, those timeouts are expected for SD card.
>> The failure is due to irq not received/missing for last CMD0.
>> Hi Yegor, Can you provide details for the SD card being used.
> 
> This is Apacer 2GB. In 3.3-rc7 I have no problems with it. Should I enable debugging in 3.3-rc7 and post the output?

I found the solution:


I've seen this hack for some on the mailing list. I think Mark A. Greer introduced it, but I don't remember for sure. Can this patch be applied as it is or there are some infrastructure changes required?

Best regards,
Yegor
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Comments

Mark Greer July 26, 2012, 11:31 p.m. UTC | #1
On Fri, Jul 20, 2012 at 10:01:09AM +0200, Yegor Yefremov wrote:
> Am 20.07.2012 09:39, schrieb Yegor Yefremov:
> > Am 20.07.2012 09:28, schrieb T Krishnamoorthy, Balaji:
> >> On Fri, Jul 20, 2012 at 3:08 AM, Paul Walmsley <paul@pwsan.com> wrote:
> >>> On Thu, 19 Jul 2012, S, Venkatraman wrote:
> >>>
> >>>> >From this, one can only infer that the card is not responding at all,
> >>>> and all attempts
> >>>> are returning with a timeout (CTO=Command Time Out).
> >>> Looks to me like the card is responding to CMD8, CMD55, ACMD41, and CMD0.
> >>> It's only CMD52 and CMD5 that are timing out.  Aren't those timeouts
> >>> expected with a SD memory card?
> >> yes, those timeouts are expected for SD card.
> >> The failure is due to irq not received/missing for last CMD0.
> >> Hi Yegor, Can you provide details for the SD card being used.
> > 
> > This is Apacer 2GB. In 3.3-rc7 I have no problems with it. Should I enable debugging in 3.3-rc7 and post the output?
> 
> I found the solution:
> 
> diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
> index e4fc88c..0ab26ab 100644
> --- a/arch/arm/mach-omap2/pm34xx.c
> +++ b/arch/arm/mach-omap2/pm34xx.c
> @@ -359,7 +359,7 @@ static void omap3_pm_idle(void)
>  {
>  	local_fiq_disable();
>  
> -	if (omap_irq_pending())
> +	if (omap_irq_pending() || !omap3_has_io_wakeup())
>  		goto out;
>  
>  	trace_power_start(POWER_CSTATE, 1, smp_processor_id());
> 
> I've seen this hack for some on the mailing list. I think
> Mark A. Greer introduced it, but I don't remember for sure.
> Can this patch be applied as it is or there are some infrastructure
> changes required?

[Oops, I thought I sent this days ago.]

Hi Yegor.

Yep, it was me.  That change is unacceptable though, see:

	http://www.spinics.net/lists/arm-kernel/msg168865.html

You were testing on linux-omap/master?  If so, hmmm, I thought
that branch would work.  For now, you can try adding 'nohlt'
to the cmdline but that's a bit of a sledgehammer...

Mark
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
diff mbox

Patch

diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index e4fc88c..0ab26ab 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -359,7 +359,7 @@  static void omap3_pm_idle(void)
 {
 	local_fiq_disable();
 
-	if (omap_irq_pending())
+	if (omap_irq_pending() || !omap3_has_io_wakeup())
 		goto out;
 
 	trace_power_start(POWER_CSTATE, 1, smp_processor_id());