Re: Fwd: [RFC] MMC: error handling improvements

Re: Fwd: [RFC] MMC: error handling improvements

[Murali Krishna Palnati]

> ---------- Forwarded message ----------
> From: Linus Walleij <linus.walleij@linaro.org>
> Date: Tue, Feb 22, 2011 at 2:19 AM
> Subject: Re: [RFC] MMC: error handling improvements
> To: Brian Swetland <swetland@google.com>, David Brown
> <davidb@codeaurora.org
>>
> Cc: Russell King - ARM Linux <linux@arm.linux.org.uk>, Chris Ball <
> cjb@laptop.org>, linux-mmc@vger.kernel.org,
> linux-arm-kernel@lists.infradead.org
>
>
> 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.
>

Linus,

These Prime cell ID registers are removed in the newer versions of the MSM
SDCC controller and are replaced with a different register that indicates
the controller version number. So, using these prime cell ID registers may
not be an option for us. Nevertheless, as you pointed out we can hard code
the AMBA ID in the platform device data and use that in the mmci driver to
handle stuff specific to this controller similar to what is done for ST
variant in mmci driver.

Though the bulk of the MSM SDCC controller is designed around PL180, there
are still some modifications to include flow control, SDIO support, Data
Mover interface (DMA engine on Qualcomm MSMs) etc. Support/ability to talk
to the Data Mover is one of the main differences when compared to original
PL180 prime cell.

Our main concern in moving to mmci is support for DMA that needs to be
added to this driver. I believe PL180 controller does have the ability to
talk to DMA engines, but i dont see any relevant support for that in mmci
driver, unless i grossly missed something.

Regards

P Murali Krishna



Sent by a consultant of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora
Forum.

Re: Fwd: [RFC] MMC: error handling improvements

[Russell King - ARM Linux]

On Tue, Mar 01, 2011 at 10:39:59AM -0800, Murali Krishna Palnati wrote:
> Our main concern in moving to mmci is support for DMA that needs to be
> added to this driver. I believe PL180 controller does have the ability to
> talk to DMA engines, but i dont see any relevant support for that in mmci
> driver, unless i grossly missed something.

DMA engine support will be added at the next merge window.  It's already
in linux-next.

Note that as ARM evaluation boards all have entirely broken DMA, it's
something I can't test here, so I'm entirely reliant on other people
using the driver with working DMA engines, testing it, and reporting
back.  This is why the ARM primecell drivers traditionally have had no
DMA support - I just don't have any working hardware to develop such
facilities.

Re: Fwd: [RFC] MMC: error handling improvements

[Linus Walleij]

Thanks for writing back Murali!

2011/3/1 Murali Krishna Palnati <palnatim@codeaurora.org>:

> Though the bulk of the MSM SDCC controller is designed around PL180, there
> are still some modifications to include flow control, SDIO support,

We have these fixes in the U300/Ux500 version of MMCI as well, I suspect
it's nothing more than altering which bits are to be poked into which
registers.

> Data
> Mover interface (DMA engine on Qualcomm MSMs) etc. Support/ability to talk
> to the Data Mover is one of the main differences when compared to original
> PL180 prime cell.

The main work would be to switch the DMA engine in MSM to using
the DMA engine in drivers/dma. This is one thing we do to avoid the
proliferation of DMA engine code in arch/arm/*, and we very early
started to use that framework for U300 and Ux500 and I must say that
it has payed off well for us, now we have much nicer interfaces and more
review than any of the custom engines under arch/arm/*.

It's some upfront work but I think it would benefit you if you could
do this.

Yours,
Linus Walleij