From: David Brown <hidden> Date: 2011-02-16 19:28:15
On Wed, Feb 16 2011, Linus Walleij wrote:
2011/2/16 David Brown [off-list ref]:
quoted
It's also possible this is finding problems in our SDCC driver.
The SDCC is obviously an MMCI derivate, VHDL hacking
on top of ARMs source code for PL180/PL181.
Why do you insist on maintaining a forked driver?
Well, it's not me insisting on it. I'll let the maintainers of the
driver chime in.
The changes we made to the block are significant, but even beyond that
we changed how the block is even accessed. The driver doesn't directly
access the registers of the controller, but all accesses go through a
custom DMA engine.
Please consider switching to using mmci.c like everyone else.
The quirks we have in place for U300, Nomadik and Ux500
should show you the way for how to do this (yes we did the
same thing, hacking the ARM VHDL).
I suspect the changes to mmci would be fairly drastic.
If I remember correctly I could even see that some early
Android sources were using Russells mmci.c driver before this
fork was created.
These old drivers are also not usable. 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.
David
--
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
It's also possible this is finding problems in our SDCC driver.
The SDCC is obviously an MMCI derivate, VHDL hacking
on top of ARMs source code for PL180/PL181.
Why do you insist on maintaining a forked driver?
Well, it's not me insisting on it. ?I'll let the maintainers of the
driver chime in.
Yeah OK. I tried writing them last week on linux-arm-kernel
with more or less the same question.
?The driver doesn't directly
access the registers of the controller, but all accesses go through a
custom DMA engine.
(...)
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.
That's significant, I agree. That the DMA engine is custom
instead of using the <linux/dmaengine.h> interface is not
making things easier, but it's another issue. If it did, I think it
could quite easily use mmci.c.
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 DMA code path doesn't look one bit different from
what we currently do for the generic DMA engine in
mmci.c, it sets up a DMA job from the sglist in the datapath,
but maybe I'm not looking close enough?
I suspect the changes to mmci would be fairly drastic.
I don't think so, but the changes to the DMA engine
(I guess mach-msm/dma.c) would potentially be pretty drastic,
apart from just moving the thing to drivers/dma.
Actually when I look at the code in msm_sdcc.c it looks
like some of the code we usually centralize into the
DMA engine (like the thing iterating over a sglist and
packing it into some custom struct called "box") is instead
spread out in the client drivers.
I just wanted to raise the issue because I see that the
msm_sdcc driver is trying to e.g. synchronize against
dataend signals and such stuff that we've worked with
recently in mmci.c, and I really think it would be in the
MSM platforms best interest to use this driver rather than
its own.
Yours,
Linus Walleij
From: Brian Swetland <hidden> Date: 2011-02-16 23:06:06
On Wed, Feb 16, 2011 at 1:01 PM, Linus Walleij [off-list ref] wrote:
2011/2/16 David Brown [off-list ref]:
quoted
?The driver doesn't directly
access the registers of the controller, but all accesses go through a
custom DMA engine.
(...)
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.
That's significant, I agree. That the DMA engine is custom
instead of using the <linux/dmaengine.h> interface is not
making things easier, but it's another issue. If it did, I think it
could quite easily use mmci.c.
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?
On MSM7x01,7x2x,8x50,8x55,7x30 the overall design involves both the
baseband cpu (running AMSS) and the apps cpu (running Linux) sharing a
single SDCC to read/write different partitions on NAND.
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.
Later Qualcomm chipsets move away from this model (yay) and that
should simplify things quite a bit.
Brian
The DMA code path doesn't look one bit different from
what we currently do for the generic DMA engine in
mmci.c, it sets up a DMA job from the sglist in the datapath,
but maybe I'm not looking close enough?
quoted
I suspect the changes to mmci would be fairly drastic.
I don't think so, but the changes to the DMA engine
(I guess mach-msm/dma.c) would potentially be pretty drastic,
apart from just moving the thing to drivers/dma.
Actually when I look at the code in msm_sdcc.c it looks
like some of the code we usually centralize into the
DMA engine (like the thing iterating over a sglist and
packing it into some custom struct called "box") is instead
spread out in the client drivers.
I just wanted to raise the issue because I see that the
msm_sdcc driver is trying to e.g. synchronize against
dataend signals and such stuff that we've worked with
recently in mmci.c, and I really think it would be in the
MSM platforms best interest to use this driver rather than
its own.
Yours,
Linus Walleij
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel at lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
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
From: Brian Swetland <hidden> Date: 2011-02-18 16:04:34
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
Out of sheer curiosity, Qualcomm/CodeAurora guys:
if you dump out the registers at offset 0xfe0-0xfff on the
SDCC, does it contain a valid PrimeCell ID? Anyone who
can make a hexdump of it?
It is possible to hardcode an AMBA ID to use this driver
even if this area is just 0x0000... but I'm just curious
about how different silicon vendors treat these registers,
e.g. if they contain something sensible.
Yours,
Linus Walleij