On Fri, Feb 18, 2011 at 5:03 AM, Linus Walleij [off-list ref] wrote:

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

quoted

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

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

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