2011/2/17 Brian Swetland [off-list ref]:

On Wed, Feb 16, 2011 at 1:01 PM, Linus Walleij [off-list ref] wrote:

quoted

2011/2/16 David Brown [off-list ref]:

quoted

quoted

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

This magic macro does the trick?

static inline void
msmsdcc_writel(struct msmsdcc_host *host, u32 data, unsigned int reg)
{
        writel(data, host->base + reg);
        /* 3 clk delay required! */
        udelay(1 + ((3 * USEC_PER_SEC) /
               (host->clk_rate ? host->clk_rate : msmsdcc_fmin)));
}

What is so hard about renaming this mmci_writel() and putting
the udelay() weirdness inside #ifdef ARCH_MSM? Wrapping
all the writes in the mmci driver inside an inline function is hardly
a big problem.

Yours,
Linus Walleij