From: Tony Lindgren <tony@atomide.com>
To: "Woodruff, Richard" <r-woodruff2@ti.com>
Cc: linux-omap-open-source@linux.omap.com
Subject: Re: [PATCH] To add OMAP 2430 Support
Date: Fri, 10 Nov 2006 02:46:06 +0200 [thread overview]
Message-ID: <20061110004606.GY16172@atomide.com> (raw)
In-Reply-To: <EA12F909C0431D458B9D18A176BEE4A50884C5B8@dlee02.ent.ti.com>
Hi,
* Woodruff, Richard <r-woodruff2@ti.com> [061109 17:02]:
> Yes this in theory it is needed. It is ARM implementation dependent on
> whether it is needed or not.
>
> I've included a small graphics (hope it makes it) to help clarify. The
> TRM also had a section on this.
>
> - The ARM-CPU has 4 ports of interest here. An instruction read (IR), a
> data read (DR), a data write (DW), and the peripheral port (PP).
>
> - There is a write-buffer between the ARM and the peripheral port (there
> is also a familiar write buffer between the ARM and its data port). A
> write to the port does not necessarily happen immediately.
>
> - The ARM internal pipeline is NOT synchronized with the peripheral port
> but it is with the others. This means dependencies are tracked with
> register and CPSR accesses. This means a write to the DR can cause the
> pipeline to stall. When you write to the PP the pipeline will never
> stall.
>
> ** This means you can write to acknowledge an interrupt then enable
> interrupts at the CPSR and the write to the CPSR can overtake the ACK to
> the PP. You now have a spurious interrupt. There are a few some
> combinations.
OK, thanks for explaining. So this means that wmb() would not be enough
because it only blocks memory access instructions, and not other access
like draining writebuffer does?
> Interestingly, the L3 bus on the other side of the AHB2OCP bridge also
> has multiple hardware threads and you can have times where accesses to
> one port can overtake others. This is all ok with ARM11 as it is
> specified to have out of order operations as long as it can tell any
> dependencies/hazards have been taken care of. How much this happens in
> practice depends on the memory system of the implementer. There a lot
> of ARM11 memory system optimizations which the standard ARM kernel does
> not take advantage of today. It takes the simple road with marking
> things as strongly ordered.
Well maybe someday somebody will do a patch for that :)
Tony
next prev parent reply other threads:[~2006-11-10 0:46 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-11-09 15:01 [PATCH] To add OMAP 2430 Support Woodruff, Richard
2006-11-10 0:46 ` Tony Lindgren [this message]
2006-11-13 16:01 ` porting linux rajesh B
-- strict thread matches above, loose matches on Subject: below --
2006-11-03 18:44 [PATCH] To add OMAP 2430 Support Syed Mohammed, Khasim
2006-11-03 19:03 ` Dirk Behme
2006-11-03 19:28 ` Dirk Behme
2006-11-03 22:00 ` David Brownell
2006-11-03 22:49 ` Syed Mohammed, Khasim
2006-11-09 2:23 ` Tony Lindgren
2006-11-09 2:22 ` 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=20061110004606.GY16172@atomide.com \
--to=tony@atomide.com \
--cc=linux-omap-open-source@linux.omap.com \
--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 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.