On Fri, Feb 18, 2011 at 5:03 AM, Linus Walleij <linus.walleij@xxxxxxxxxx> wrote: > 2011/2/17 Brian Swetland <swetland@xxxxxxxxxx>: >> On Wed, Feb 16, 2011 at 1:01 PM, Linus Walleij <linus.walleij@xxxxxxxxxx> wrote: >>> 2011/2/16 David Brown <davidb@xxxxxxxxxxxxxx>: > >>>> 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. >>> (...) >>> >>> At the same time what you're saying sounds very weird: >>> the ios handler in mmc_sdcc does not request any DMA >>> channel before messing with the hardware, it simply just write >>> into registers very much in the style of mmci.c. Wouldn't that >>> disturb any simultaneous access to the MMC from another >>> CPU? >> >> (...) >> The way register access for the SDCC is synchronized between these two >> cores is by using a locking primitive built into the MSM DMA >> controller. ÂIf you don't use this indirect access model (via DMA >> transactions to the registers), you end up tripping over the baseband >> or the other way 'round. ÂIt's not fun. > > Wherever is that synchronized in the DMA controller? > I don't get it because the code is so very similar. > > When the ios does this: > msmsdcc_writel(host, clk, MMCICLOCK); Sorry, I'm wrong. I was thinking of the MSM NAND driver which does have a funky DMA interlock access control scheme where the DMA engine is use to arbitrate register access between the apps and modem cores. You are correct -- there's no special magic in the SDCC driver. If this can be handled by a common driver with a quirks flag for msm-specific oddities, that sounds quite sane to me. Brian -- 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
