[RFC] MMC: error handling improvements

[linus.walleij@linaro.org (Linus Walleij)]

2011/2/17 Brian Swetland <swetland@google.com>:
> On Wed, Feb 16, 2011 at 1:01 PM, Linus Walleij <linus.walleij@linaro.org> wrote:
>> 2011/2/16 David Brown <davidb@codeaurora.org>:

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