From: Sekhar Nori <nsekhar@ti.com>
To: Vinod Koul <vinod.koul@intel.com>
Cc: Dan Williams <dan.j.williams@intel.com>,
DMA Engine Mailing List <dmaengine@vger.kernel.org>,
Linux DaVinci Mailing List
<davinci-linux-open-source@linux.davincidsp.com>,
Jon Ringle <jringle@gridpoint.com>,
Alexander Holler <holler@ahsoftware.de>,
Linux OMAP Mailing List <linux-omap@vger.kernel.org>,
Joel Fernandes <joelf@ti.com>
Subject: Re: [PATCH 1/1] dma: edma: fix incorrect SG list handling
Date: Mon, 14 Apr 2014 14:39:00 +0530 [thread overview]
Message-ID: <534BA5AC.7060903@ti.com> (raw)
In-Reply-To: <20140414085746.GG32284@intel.com>
On Monday 14 April 2014 02:27 PM, Vinod Koul wrote:
> On Mon, Apr 14, 2014 at 02:01:11PM +0530, Sekhar Nori wrote:
>> Vinod,
>>
>> On Wednesday 19 March 2014 11:25 AM, Sekhar Nori wrote:
>>> The code to handle any length SG lists calls edma_resume()
>>> even before edma_start() is called. This is incorrect
>>> because edma_resume() enables edma events on the channel
>>> after which CPU (in edma_start) cannot clear posted
>>> events by writing to ECR (per the EDMA user's guide).
>>>
>>> Because of this EDMA transfers fail to start if due
>>> to some reason there is a pending EDMA event registered
>>> even before EDMA transfers are started. This can happen if
>>> an EDMA event is a byproduct of device initialization.
>>>
>>> Fix this by calling edma_resume() only if it is not the
>>> first batch of MAX_NR_SG elements.
>>>
>>> Without this patch, MMC/SD fails to function on DA850 EVM
>>> with DMA. The behaviour is triggered by specific IP and
>>> this can explain why the issue was not reported before
>>> (example with MMC/SD on AM335x).
>>>
>>> Tested on DA850 EVM and AM335x EVM-SK using MMC/SD card.
>>>
>>> Cc: stable@vger.kernel.org # v3.12.x+
>>> Cc: Joel Fernandes <joelf@ti.com>
>>> Acked-by: Joel Fernandes <joelf@ti.com>
>>> Tested-by: Jon Ringle <jringle@gridpoint.com>
>>> Tested-by: Alexander Holler <holler@ahsoftware.de>
>>> Reported-by: Jon Ringle <jringle@gridpoint.com>
>>> Signed-off-by: Sekhar Nori <nsekhar@ti.com>
>>
>> Looks like this patch is not in mainline still?
>
> Sorry looks like I have missed sending the email. I had applied it last week and
> today rebased after rc1. It would be part of rc2...
Thank you!
Regards,
Sekhar
prev parent reply other threads:[~2014-04-14 9:09 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-03-19 5:55 [PATCH 1/1] dma: edma: fix incorrect SG list handling Sekhar Nori
2014-04-14 8:31 ` Sekhar Nori
2014-04-14 8:57 ` Vinod Koul
2014-04-14 9:09 ` Sekhar Nori [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=534BA5AC.7060903@ti.com \
--to=nsekhar@ti.com \
--cc=dan.j.williams@intel.com \
--cc=davinci-linux-open-source@linux.davincidsp.com \
--cc=dmaengine@vger.kernel.org \
--cc=holler@ahsoftware.de \
--cc=joelf@ti.com \
--cc=jringle@gridpoint.com \
--cc=linux-omap@vger.kernel.org \
--cc=vinod.koul@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.