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 questio
On Sat, Jun 13, 2009 at 10:45 AM, Albrecht Dreß 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 is the p
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 in_/out_b
On Thu, Jun 11, 2009 at 10:55 AM, Wolfram Sang wrote:
>> 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 (
> 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
On Tue, Jun 9, 2009 at 1:46 PM, Albrecht Dreß 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 word read - modify
>
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
fix/extensio