On Fri, 04 Jun 2010 13:07:28 +0300 Maxim Levitsky <maximlevitsky@xxxxxxxxx> wrote: > > > > 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. Instead of doing it at runtime, we could read them offline and then write them in. Of course, I suspect there's some variation in capabilities of Ricoh parts - I know there's at least two generations of MMC controllers with the same PCI IDs. :-/ > > > > > 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. They are not. I suspect the controller pokes the card using SPI mode just enough to tell them apart. > > 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. I'm not familiar with what pm core allows but can you tell it to serialise the functions but still handle the device asynchronously? That would still allow the maximum possible asynchrony. > > > > > > --phil > > > --phil -- To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
