From: Nishanth Menon <nm@ti.com>
To: Peter Ujfalusi <peter.ujfalusi@nokia.com>
Cc: Tony Lindgren <tony@atomide.com>,
"linux-omap@vger.kernel.org" <linux-omap@vger.kernel.org>,
Jarkko Nikula <jhnikula@gmail.com>,
Liam Girdwood <lrg@slimlogic.co.uk>
Subject: Re: [PATCH 2/2] OMAP3: DMA: Errata: sDMA FIFO draining does not finish
Date: Fri, 1 Oct 2010 04:23:26 -0500 [thread overview]
Message-ID: <4CA5A88E.1080908@ti.com> (raw)
In-Reply-To: <201010011151.52547.peter.ujfalusi@nokia.com>
Peter Ujfalusi had written, on 10/01/2010 03:51 AM, the following:
> On Friday 01 October 2010 10:45:12 ext Nishanth Menon wrote:
> ...
>>> - l &= ~OMAP_DMA_CCR_EN;
>>> - dma_write(l, CCR(lch));
>>> + /* OMAP3 Errata: sDMA FIFO draining does not finish */
>> would be informative to give the iXYZ id as well for some of these
>> erratas might scale across processors.
>
> In TI's site I was only able to find this public ERRATA:
> OMAP3530/25/15/03 Applications Processor Silicon Errata-Revs 3.1, 3.0, 2.1,&2.0
> (Rev. E)
> In that document it is under: Advisory 3.1.1.192, but no iXYZ is associated with
> it. However I have another ERRATA document, which has the iXYZ associated with
> this advisory, but the first page tells that it is confidential, and under NDA
> restriction. I'm not really sure, if I should refere to that number...
> But if you have the iXYZ number, which I can use, than I'm more than happy to
> add that.
I do. It is i541.
>
>>> + if (cpu_is_omap34xx() && (l & OMAP_DMA_CCR_SEL_SRC_DST_SYNC)) {
>> does it make sense to use an dma_errata variable and populate it?
>
> Hmmm, the errata handling via dma_errata shall be done separately IMHO,
> since if we do that, than we need to revisit other parts of the code as well,
> and replace the existing errata handling.
>
> But yes, it would make the code much more readable, and we can easily track,
> which errata has been already addressed.
>
I suppose that is fair..
--
Regards,
Nishanth Menon
next prev parent reply other threads:[~2010-10-01 9:23 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-10-01 6:39 [PATCH 0/2] OMAP2/3: DMA: FIFO drain errata fixes Peter Ujfalusi
2010-10-01 6:39 ` [PATCH 1/2] omap: dma: Fix buffering disable bit setting for omap24xx Peter Ujfalusi
2010-10-01 7:47 ` Nishanth Menon
2010-10-01 9:20 ` Jarkko Nikula
2010-10-01 6:39 ` [PATCH 2/2] OMAP3: DMA: Errata: sDMA FIFO draining does not finish Peter Ujfalusi
2010-10-01 7:00 ` Jarkko Nikula
2010-10-01 7:45 ` Nishanth Menon
2010-10-01 8:51 ` Peter Ujfalusi
2010-10-01 9:23 ` Nishanth Menon [this message]
2010-10-01 10:40 ` Peter Ujfalusi
2010-10-01 9:29 ` G, Manjunath Kondaiah
2010-10-01 9:43 ` Nishanth Menon
2010-10-01 9:45 ` G, Manjunath Kondaiah
2010-10-01 10:43 ` Peter Ujfalusi
2010-10-01 10:41 ` Peter Ujfalusi
2010-10-01 11:09 ` G, Manjunath Kondaiah
2010-10-01 11:43 ` Jarkko Nikula
2010-10-01 11:48 ` Jarkko Nikula
2010-10-01 17:02 ` Tony Lindgren
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=4CA5A88E.1080908@ti.com \
--to=nm@ti.com \
--cc=jhnikula@gmail.com \
--cc=linux-omap@vger.kernel.org \
--cc=lrg@slimlogic.co.uk \
--cc=peter.ujfalusi@nokia.com \
--cc=tony@atomide.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.