On Wed, Feb 16 2011, Linus Walleij wrote: > 2011/2/16 David Brown <davidb@xxxxxxxxxxxxxx>: >> It's also possible this is finding problems in our SDCC driver. > > The SDCC is obviously an MMCI derivate, VHDL hacking > on top of ARMs source code for PL180/PL181. > > Why do you insist on maintaining a forked driver? Well, it's not me insisting on it. I'll let the maintainers of the driver chime in. The changes we made to the block are significant, but even beyond that we changed how the block is even accessed. The driver doesn't directly access the registers of the controller, but all accesses go through a custom DMA engine. > Please consider switching to using mmci.c like everyone else. > The quirks we have in place for U300, Nomadik and Ux500 > should show you the way for how to do this (yes we did the > same thing, hacking the ARM VHDL). I suspect the changes to mmci would be fairly drastic. > If I remember correctly I could even see that some early > Android sources were using Russells mmci.c driver before this > fork was created. These old drivers are also not usable. The SDCC block is shared between the modem processor and the processor running Linux. If the driver doesn't go through the DMA engine, which coordinates this, the registers will be stomped on by the other CPU whenever it decides to access it's parts of the flash device. David -- Sent by an employee of the Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum. -- 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
