Scott Wood wrote:
> If you were to immediately follow it with out_8 as currently defined,
> yes. But setbits_8 should be OK.
I don't want my flash_writeX functions to make any assumptions about what
set_mux_to_diu() does. Can I just replace the __raw_readb() with an in_8()?
--
Timur Tabi
Linux
On Wed, 01 Dec 2010 17:28:28 -0600
Timur Tabi wrote:
> Scott Wood wrote:
> >> You told me that since I'm doing a read following a write to uncached
> >> memory,
> >> > that I don't need a sync.
> > No, I was talking about a write followed by a read, to the same location.
>
> That's what I said.
Scott Wood wrote:
>> You told me that since I'm doing a read following a write to uncached memory,
>> > that I don't need a sync.
> No, I was talking about a write followed by a read, to the same location.
That's what I said. Read following write == write followed by read.
> out_8 should be fixed
On Wed, 01 Dec 2010 16:45:57 -0600
Timur Tabi wrote:
> Wood Scott-B07421 wrote:
> >
> > Careful with the barriers.
> >
> > You've got a raw readback, which means it's not going to wait for
> > completion with the twi/isync hack.
>
> You told me that since I'm doing a read following a write to
Wood Scott-B07421 wrote:
>
> Careful with the barriers.
>
> You've got a raw readback, which means it's not going to wait for
> completion with the twi/isync hack.
You told me that since I'm doing a read following a write to uncached memory,
that I don't need a sync.
And what twi/isync hack are
> > Timur,
> > Any reason not to use in_be8?
> > The first version code is finished by me some months ago. at that
time I used
> the in_be8.
>
> What first version code? Did you implement this feature, too?
http://git.ap.freescale.net/gitweb/?p=u-boot-p1022.git;a=commitdiff;h=45
ddca32e5f288e81a
On Dec 1, 2010, at 7:51 AM, "Liu Dave-R63238" wrote
>
> Timur,
> Any reason not to use in_be8?
> The first version code is finished by me some months ago. at that time I used
> the in_be8.
What first version code? Did you implement this feature, too?
>
__
>> /* There is no __raw_writeq(), so do the write manually */
>> *(volatile u64 *)addr = value;
>> -if (sw)
>> +if (sw) {
>> +/*
>> + * To ensure the post-write is completed to eLBC, software must
>> + * perform a dummy read from one valid addre
On Nov 30, 2010, at 7:50 PM, Scott Wood wrote:
> On Tue, 30 Nov 2010 18:36:25 -0600
> Timur Tabi wrote:
>
>> @@ -244,8 +266,15 @@ void flash_write64(u64 value, void *addr)
>>
>> /* There is no __raw_writeq(), so do the write manually */
>> *(volatile u64 *)addr = value;
>> -if (s
On Tue, 30 Nov 2010 18:36:25 -0600
Timur Tabi wrote:
> @@ -244,8 +266,15 @@ void flash_write64(u64 value, void *addr)
>
> /* There is no __raw_writeq(), so do the write manually */
> *(volatile u64 *)addr = value;
> - if (sw)
> + if (sw) {
> + /*
> +
On the P1022, the pins which drive the video display (DIU) are muxed with the
local bus controller (LBC), so if the DIU is active, the pins need to be
temporarily muxed to LBC whenever accessing NOR flash.
The code which handled this transition is checking and changing the wrong
bits in PMUXCR.
A
11 matches
Mail list logo
