From: Tony Lindgren <tony@atomide.com>
To: "Woodruff, Richard" <r-woodruff2@ti.com>
Cc: "linux-omap@vger.kernel.org" <linux-omap@vger.kernel.org>
Subject: Re: [PATCH 4/4] DSPBRIDGE: Ensure write posting when acking mailbox irq
Date: Sun, 2 Nov 2008 14:10:50 -0800 [thread overview]
Message-ID: <20081102221050.GQ28924@atomide.com> (raw)
In-Reply-To: <13B9B4C6EF24D648824FF11BE89671620369885CBD@dlee02.ent.ti.com>
* Woodruff, Richard <r-woodruff2@ti.com> [081031 20:44]:
> > owner@vger.kernel.org] On Behalf Of Tony Lindgren
> > Sent: Friday, October 31, 2008 2:21 PM
>
> > The only way to ensure write posting to L4 bus is to do a read back
> > of the same register right after the write.
> >
> > This seems to be mostly needed in interrupt handlers to avoid
> > causing spurious interrupts.
> >
> > The earlier fix has been to mark the L4 bus as strongly ordered
> > memory, which solves the problem, but causes performance penalties.
>
> What penalties have you observed? Can you quantify?
Not yet, I guess we can run some benchmarks though.
> From the L4 perspectives DEVICE and SO are similar. Long back I was told one difference is DEVICE is allowed to do burst transactions of element size where SO was not. This behavior is only really wanted to a FIFO.
>
> Really performance sensitive devices will be using DMA to FIFOs. SO/DEVICE only applies to the ARM's view of things. DMA is not affected by ARM memory types.
You may be right, and if that's the only difference, then SO might be
even faster as it avoids the extra readbacks.
> Some kind of barrier or read back is needed for sure when dealing with the main interrupt controller.
Yeah. I'm worried that these issues could happen with SO too..
Regards,
Tony
next prev parent reply other threads:[~2008-11-02 22:10 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-10-31 19:21 [PATCH 0/4] 34xx spurious interrupts unravelling Tony Lindgren
2008-10-31 19:21 ` [PATCH 1/4] Revert "Add MT_MEMORY_SO, mark L3 and L4 to use it" Tony Lindgren
2008-10-31 19:21 ` [PATCH 2/4] ARM: OMAP3: Print debug info on spurious interrupts Tony Lindgren
2008-10-31 19:21 ` [PATCH 3/4] I2C: Ensure write posting for critical i2c-omap writes Tony Lindgren
2008-10-31 19:21 ` [PATCH 4/4] DSPBRIDGE: Ensure write posting when acking mailbox irq Tony Lindgren
2008-10-31 21:06 ` Tony Lindgren
2008-11-01 3:43 ` Woodruff, Richard
2008-11-02 22:10 ` Tony Lindgren [this message]
2008-11-03 18:54 ` Tony Lindgren
2008-10-31 21:03 ` [PATCH 3/4] I2C: Ensure write posting for critical i2c-omap writes Tony Lindgren
2008-10-31 20:55 ` [PATCH 2/4] ARM: OMAP3: Print debug info on spurious interrupts Tony Lindgren
2008-10-31 20:07 ` [PATCH 0/4] 34xx spurious interrupts unravelling David Brownell
2008-10-31 20:35 ` Tony Lindgren
2008-10-31 21:59 ` David Brownell
2008-11-01 4:01 ` Woodruff, Richard
2008-11-01 6:08 ` David Brownell
2008-11-01 12:57 ` Woodruff, Richard
2008-11-01 21:14 ` Felipe Contreras
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=20081102221050.GQ28924@atomide.com \
--to=tony@atomide.com \
--cc=linux-omap@vger.kernel.org \
--cc=r-woodruff2@ti.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox