Steve 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.
As Dave said in May of 2008[1], the map driver is advertising xip acc
On Fri, 9 Jul 2010 14:59:09 +0200
Segher Boessenkool 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 drivers
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
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.
Wouldn't y
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 Thu, 8 Jul 2010 21:30:33 +0200
Segher Boessenkool 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 drivers never sho
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
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
loca
iters; linuxppc-dev@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
>> wrote:
>> > On Tue, 2010-06-29 at 11:04 -0500, Steve Deiters
> -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/power
On Wed, Jul 7, 2010 at 11:10 PM, Benjamin Herrenschmidt
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
>> the
>> local bus
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 solve
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
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
---
arch/powerpc/lib/copy_32.S | 56
14 matches
Mail list logo
