On Sat, 2009-06-13 at 18:45 +0200, Albrecht Dreß wrote:
Am 11.06.09 19:28 schrieb(en) Grant Likely:
So; the solution to me seems to be on an MPC5200 platform replace the
offending hooks with MPC5200 specific variants at runtime.
Will re-work the patch that way! BTW, a dumb question:
Am 11.06.09 18:27 schrieb(en) Grant Likely:
+ *(u16 *)buf = *((volatile u16 *)(vdest - 1));
+ buf[1] = *((u8 *)src);
+ *((volatile u16 *)(vdest - 1)) = *(u16 *)buf;
what is the purpose of volatile here? If you need io barriers, then
use the
On Sat, Jun 13, 2009 at 10:45 AM, Albrecht Dreßalbrecht.dr...@arcor.de wrote:
Am 11.06.09 18:27 schrieb(en) Grant Likely:
+ *(u16 *)buf = *((volatile u16 *)(vdest - 1));
+ buf[1] = *((u8 *)src);
+ *((volatile u16 *)(vdest - 1)) = *(u16 *)buf;
what
On Tue, Jun 9, 2009 at 1:46 PM, Albrecht Dreßalbrecht.dr...@arcor.de wrote:
Hi all,
this patch adds support for RAM chips connected to the Local Plus Bus of a
MPC5200B in 16-bit mode. As no single byte write accesses are allowed by
the bus in this mode, a byte write has to be split into a
Blech. ugly #ifdef and not really multiplatform safe (yeah, I know it
shouldn't break non-5200 platforms, but it does have an undesirable
impact). There's got to be a better way.
What about putting the special memcpy in asm/io.h (like it is done for eeh)?
Will this cause too much overhead
Hi all,
this patch adds support for RAM chips connected to the Local Plus Bus
of a MPC5200B in 16-bit mode. As no single byte write accesses are
allowed by the bus in this mode, a byte write has to be split into a
word read - modify - write sequence (mpc52xx_memcpy2lpb16, as
