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