Hmm, unfortunately, it's usage is not clearly documented in mtd-
physmap.txt,
It's pretty clear I think. Patches for making it better are welcome
of course.
so I never thought of this parameter. And IMHO the problem goes
further - basically *any* chip which is attached to the LPB can be
On Fri, 9 Jul 2010 14:59:09 +0200
Segher Boessenkool seg...@kernel.crashing.org wrote:
Actually, this is something which might need closer attention -
and maybe some support in the device tree indicating which read or
write width a device can accept?
There already is device-width; the
-Original Message-
From: glik...@secretlab.ca [mailto:glik...@secretlab.ca] On
Behalf Of Grant Likely
Sent: Thursday, July 08, 2010 12:38 AM
To: Benjamin Herrenschmidt
Cc: Steve Deiters; linuxppc-dev@lists.ozlabs.org
Subject: Re: [PATCH] arch/powerpc/lib/copy_32.S: Use
alternate
@lists.ozlabs.org
Subject: Re: [PATCH] arch/powerpc/lib/copy_32.S: Use
alternate memcpy for MPC512x and MPC52xx
On Wed, Jul 7, 2010 at 11:10 PM, Benjamin Herrenschmidt
b...@kernel.crashing.org wrote:
On Tue, 2010-06-29 at 11:04 -0500, Steve Deiters wrote:
These processors will corrupt data
Am 08.07.10 17:22 schrieb(en) Grant Likely:
Just out of curiousity, what configuration might cause a byte-wise alignment
not to work?
Can't remember the register configuration, but I worked on one project where
this was the case. In hindsight, it was probably a mis-configuration of the
Actually, this is something which might need closer attention - and
maybe some support in the device tree indicating which read or
write width a device can accept?
There already is device-width; the drivers never should use any other
access width unless they *know* that will work.
Segher
On Thu, 8 Jul 2010 21:30:33 +0200
Segher Boessenkool seg...@kernel.crashing.org wrote:
Actually, this is something which might need closer attention -
and maybe some support in the device tree indicating which read or
write width a device can accept?
There already is device-width; the
Am 08.07.10 21:30 schrieb(en) Segher Boessenkool:
Actually, this is something which might need closer attention - and maybe some
support in the device tree indicating which read or write width a device can
accept?
There already is device-width; the drivers never should use any other access
On Tue, 2010-06-29 at 11:04 -0500, Steve Deiters wrote:
These processors will corrupt data if accessing the local bus with
unaligned
addresses. This version fixes the typical case of copying from Flash on
the
local bus by keeping the source address always aligned.
Shouldn't this be solved by
On Wed, Jul 7, 2010 at 11:10 PM, Benjamin Herrenschmidt
b...@kernel.crashing.org wrote:
On Tue, 2010-06-29 at 11:04 -0500, Steve Deiters wrote:
These processors will corrupt data if accessing the local bus with
unaligned
addresses. This version fixes the typical case of copying from Flash on
These processors will corrupt data if accessing the local bus with
unaligned
addresses. This version fixes the typical case of copying from Flash on
the
local bus by keeping the source address always aligned.
Signed-off-by: Steve Deiters stevedeit...@basler.com
---
arch/powerpc/lib/copy_32.S |
These processors will corrupt data if accessing the local bus with
unaligned
addresses. This version fixes the typical case of copying from
Flash on
the
local bus by keeping the source address always aligned.
On many platforms accessing ROM as RAM simply doesn't work(*). You
shouldn't
map
12 matches
Mail list logo
