Message-ID: <1275646048.26010.22.camel@maxim-laptop>
Date:	Fri, 04 Jun 2010 13:07:28 +0300
From:	Maxim Levitsky <maximlevitsky@...il.com>
To:	Philip Langdale <philipl@...rt.org>
Cc:	linux-kernel <linux-kernel@...r.kernel.org>, adq_dvb@...skialf.net,
	"linux-mmc@...r.kernel.org" <linux-mmc@...r.kernel.org>
Subject: Re: [PATCH] mmc: make sdhci work with ricoh mmc controller

On Thu, 2010-06-03 at 21:42 -0700, Philip Langdale wrote: 
> On Thu, 03 Jun 2010 20:35:31 +0300
> Maxim Levitsky <maximlevitsky@...il.com> wrote:
> 
> > On Thu, 2010-06-03 at 10:05 -0700, Philip Langdale wrote: 
> > > On Thu, 3 Jun 2010 09:39:14 -0700
> > > Philip Langdale <philipl@...rt.org> wrote:
> > > 
> > > > > > 
> > > > > > Have you been able to establish if 4bit and high-speed
> > > > > > operations work correctly through the MMC controller? I note
> > > > > > that you didn't set SDHCI_CAN_DO_HISPD.
> > > > > Didn't test that yet, will do.
> > > > > I hope my MMCPlus card can do high-speed.
> > > > 
> > > > I should get a chance today to test this as well; I'll let you
> > > > know what I see.
> > > > 
> > > 
> > > Ok, I was able to try it out and setting HISPD works and 4bit seems
> > > to work too. My MMCplus cards run at the same speed with either
> > > controller.
> > I too confirm that.
> 
> On this subject:
> 
> 1) Would it make sense to have the hard-coded caps reflect the full
> set of caps you see on the sdhci side?
This would be ugly cause two driver instances would have to talk one
with another. A global variable will be necessary.


> 
> 2) We ought to be able to set the MMC high-speed flag for this
> controller; I've tried it out and it works fine. The default sdhci
> code will never set this flag. I think it would need to an additional
> quirk. Pierre argued against setting it on the basis that SD high speed
> has slightly different timings; I haven't seen hardware where this
> has been an issue.
> 
> > However that suspend/resume race is tough one.
> > The problem seems that controller doesn't like both devices to be
> > poked at same time, and normally they won't, but here on resume both
> > are tested for a card, and this is done asynchronously by mmc core.
> > 
> > I will get to bottom of this sooner or later (I hope).
> 
> Hmm. So, if the issue is the test, then you should be able to serialize
> in mmc core instead of forcing sync resume in general. An ugly way would
> be a quirk that says to serialize all card tests if the controller is
> present in the system. In practice it would be fine as systems won't
> have arbitrary other sdhci controllers if they have this ricoh mmc
> thing. But yes, it isn't clean. :-P
This seems to be worse that I thought.
The problem is that mmc controller tells that card is removed on resume
(after a while it reappears)

This brings a question though, are MMC and SD cards electrically
different?
If not them its interesting how the controller distinguishes between
them.


This isn't a show stopper though, cause the cards are removed/reinserted
anyway unless CONFIG_MMC_UNSAFE_RESUME is set.
The fact that this triggers system hang is another story, and sooner or
later will be fixed ether by some hack in mmc code or by making
del_gendisk not hang when userspace is frozen.


It not due to interleaving, because I tried binding sdhci-pci to only
mmc interface, and yet same problem happens.

Magically, if async suspend is disabled everything works, and it well
tested. and that despite me disabling async suspend on all 4 functions.
(And I know that this works, and makes pm core suspend them in order
from 0 to 4 and synchronously.
I tried adding large delays to simulate delays caused by waiting for
other devices, but it didn't help.

I''l get to bottom of this.



> 
> --phil


--
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