On Fri, 8 Aug 2008, Catalin Marinas wrote:
There are already CPUs with weaker memory ordering model than ARM (e.g.
Alpha) and they are supported by Linux. Of course, there may be problems
with drivers since most of them are developed in x86.
For the OMAP SoC, most of the drivers are specific
On Thu, Aug 07, 2008 at 06:07:50PM -0500, Woodruff, Richard wrote:
If I write a series of control register commands to device A, then
write a go operation to device B, I would hope all of A's writes
had completed before B gets the go. SO gives you this. DEVICE may
not with out barriers.
On Thu, 7 Aug 2008, Catalin Marinas wrote:
Many of the architecture people in ARM seem to be on holiday, I'll try
to get clarification in about a week time.
That would be really great. For reference, here is the assembly code in
question:
On Thu, 2008-08-07 at 22:20 +0100, Russell King - ARM Linux wrote:
On Thu, Aug 07, 2008 at 03:38:55PM -0500, Woodruff, Richard wrote:
From: Russell King - ARM Linux [mailto:[EMAIL PROTECTED]
Is DEVICE really safe for things other than FIFOs with out the use of
barriers?
As far
On Fri, Aug 08, 2008 at 12:44:49PM +0100, Catalin Marinas wrote:
There are already CPUs with weaker memory ordering model than ARM (e.g.
Alpha) and they are supported by Linux. Of course, there may be problems
with drivers since most of them are developed in x86.
There are, and they are
Hello Catalin,
On Wed, 6 Aug 2008, Catalin Marinas wrote:
On Tue, 2008-08-05 at 07:15 -0500, Woodruff, Richard wrote:
Is the controller allowed to write dirty cache lines out at any time
it
likes? Surely a better fix is to drain the cache of the changes before
changing the clock for
On Wed, Aug 06, 2008 at 07:21:14AM -0500, Woodruff, Richard wrote:
Most of the weak memory attributes in newer ARMs are not exploited
today in tree. I'll guess this was more a correctness and capability
judgment from Russell.
Not entirely true. We do as much as is safe to do - which is
On Thu, 2008-08-07 at 08:30 +0100, Russell King - ARM Linux wrote:
What we don't do is mark DMA memory ask being normal uncached memory,
thereby allowing that to be reordered with device accesses - we make
it strongly ordered. The reason being that the kernel doesn't have
barriers necessary
From: Russell King - ARM Linux [mailto:[EMAIL PROTECTED]
Most of the weak memory attributes in newer ARMs are not exploited
today in tree. I'll guess this was more a correctness and
capability
judgment from Russell.
Not entirely true. We do as much as is safe to do - which is
On Thu, Aug 07, 2008 at 01:56:40PM -0500, Woodruff, Richard wrote:
From: Russell King - ARM Linux [mailto:[EMAIL PROTECTED]
Most of the weak memory attributes in newer ARMs are not exploited
today in tree. I'll guess this was more a correctness and capability
judgment from Russell.
From: Russell King - ARM Linux [mailto:[EMAIL PROTECTED]
Is DEVICE really safe for things other than FIFOs with out the use of
barriers?
As far as I'm aware, yes - and that comment is based solely upon the
fact that no one has reported any problems with the kernel which have
been tracked
On Thu, Aug 07, 2008 at 03:38:55PM -0500, Woodruff, Richard wrote:
From: Russell King - ARM Linux [mailto:[EMAIL PROTECTED]
Is DEVICE really safe for things other than FIFOs with out the use of
barriers?
As far as I'm aware, yes - and that comment is based solely upon the
fact that
On Thu, Aug 07, 2008 at 10:20:33PM +0100, Russell King - ARM Linux wrote:
In the case of arch/arm/mach-omap2/irq.c, reading the INTC_REVISION
reg after masking should be a sufficient solution.
And here's a patch to do exactly that.
diff --git a/arch/arm/mach-omap2/irq.c
On Mon, 2008-08-04 at 17:40 -0600, Paul Walmsley wrote:
Add the MT_MEMORY_STRONGLY_ORDERED memory type for ARM strongly ordered
memory.
This is used on OMAP3 for on-board SRAM. On OMAP, SRAM is used for code
that changes the SDRAM controller's clock, temporarily blocking access to
SDRAM.
On Tue, 2008-08-05 at 07:15 -0500, Woodruff, Richard wrote:
Is the controller allowed to write dirty cache lines out at any time
it
likes? Surely a better fix is to drain the cache of the changes before
changing the clock for the SDRAM?
- Previously the SRAM was marked as cached.
Why not use normal uncached memory? Strongly ordered is pretty
inefficient as it cannot do any reordering or write buffer merging
(it's
like having a memory barrier before and after each instruction).
Speculative accesses are not allowed either. Strongly ordered memory
is
not really meant
On Mon, Aug 04, 2008 at 05:40:57PM -0600, Paul Walmsley wrote:
Add the MT_MEMORY_STRONGLY_ORDERED memory type for ARM strongly ordered
memory.
This is used on OMAP3 for on-board SRAM. On OMAP, SRAM is used for code
that changes the SDRAM controller's clock, temporarily blocking access to
17 matches
Mail list logo
