[ELDK] Non cacheable memory request

[Fariya]

Hi,

Thanks for ur reply. I wud be using a debugger to make sure if the memory
that I've requested is cacheable/not. I wud be thankful if any1 cud help me
out with the cause of the delay that Iam facing while doing subsequent EBC
reads/writes. As I already stated, btwn subsequent EBC read/write if I
introduce a delay, I cud see the wite/read actually take place & cud see the
chip select trigger else the chip select wsn;t getting triggered. Can any1
help me out with sme pointers to correct this prblm?

Thanks & Regards,
Fariya


On 2/29/08, Douglas, Jim (Jim) <jdouglas at avaya.com> wrote:
>
> > From: eldk-bounces at lists.denx.de [mailto:eldk-bounces at lists.denx.de]
> On
> > Behalf Of Fariya
> >
> > I am working on the PPC 405EX processor with a peripheral attached to
> the
> > EBC. I've requested for I/O memory. How do I ensure that the memory
> range
> > that I requested is non-cacheable? I've to work with non-cacheable
> memory.
> >  I've requested for memory using request_mem_region( ) & mapped it
> using
> > ioremap( ) . Which functions should I use to ensure the
> non-cacheability
> > of
> > the requested memory region?
> [Jim Douglas]
> I do not know about 405EX, but try kmalloc(..., GFP_DMA | GFP_KERNEL)
> or
> dma_alloc_coherent(...)
>
> >
> > Between any consecutive writes or any consecutive reads, if I
> introduce a
> > delay of 500msec, the read/write is completing.  Does this have to do
> > anything with caching? What could be the  reason for this?
> [Jim Douglas]
> Maybe compiler or CPU reordering/optimisation.  This is what memory
> barriers are for.
>
> Conventional kernel practise is to avoid directly writing to IO memory,
> but to use macros like ioread8() etc, instead.  Watch out, though,
> because some of them are little-endian.  For ppc, 'volatile' is also
> used a lot.
>
> See Documentation/memory-barriers.txt
> See also Documentation/volatile-considered-harmful.txt
>
> --jim
>



-- 
-Fariya Fatima