Using GPMI-NAND driver on iMX28 using 3.4-rc1?
Sam Gandhi
samgandhi9 at gmail.com
Fri Apr 6 10:06:41 EDT 2012
On Fri, Apr 6, 2012 at 6:59 AM, Shawn Guo <shawn.guo at linaro.org> wrote:
> On Fri, Apr 06, 2012 at 06:49:05AM -0700, Sam Gandhi wrote:
>> >
>> >
>> > It's maybe too late to assign the DMA cookie after mxs_dma_enable_chan() in
>> > mxs_dma_tx_submit().
>> > The interrupt may arise before the dma_cookie_assign() finishes.
>> >
>> > Why mmc/audio do not have this bug? their interrupt arise too slow.
>> >
>> > I tested the following code :
>> > ==============================================================
>> >
>> > diff --git a/drivers/dma/mxs-dma.c b/drivers/dma/mxs-dma.c
>> > index 5978113..0f5b09a 100644
>> > --- a/drivers/dma/mxs-dma.c
>> > +++ b/drivers/dma/mxs-dma.c
>> > @@ -202,10 +202,12 @@ static struct mxs_dma_chan *to_mxs_dma_chan(struct
>> > dma_cha
>> > static dma_cookie_t mxs_dma_tx_submit(struct dma_async_tx_descriptor *tx)
>> > {
>> > struct mxs_dma_chan *mxs_chan = to_mxs_dma_chan(tx->chan);
>> > + dma_cookie_t c;
>> >
>> > + c = dma_cookie_assign(tx);
>> > mxs_dma_enable_chan(mxs_chan);
>> >
>> > - return dma_cookie_assign(tx);
>> > + return c;
>> > }
>> >
>> If this is the issue, then why not have mxs_dma_enable_chan itself
>> call dma_cookie_assign() and return that cookie.
>>
> As the function name tells, mxs_dma_enable_chan is to only operate dma
> hardware to enable the channel but nothing else.
>
Well then change the name of the function
mxs_assign_cookie_enable_chan(), my point still stands.
As the case illustrates cookie needs to assigned before enabling the
channel then why not do it in that function itself. At worst please
put a comment in mxs_assign_cookie_enable() that says cookie must be
assigned prior to calling enable channel.
-Sam
More information about the linux-arm-kernel
mailing list