Re: DV Flasher

[Ivan Tonchev]

Hi Philip,

> Executing:
>
> mono DVFlasher_1_10.exe
>
> causes the xterm to blink and the prompt to return with no visible
> messages remaining. I think it is trying to display a message, but the
> screen is erased before I can see the message.
>

1. Try running this in text console (CTRL + ALT + F1), not in xterm. For
some unknown to me reason, xterm doesn't like mono console output.

2. Download latest DVFlasher code from my.ti.com (latest downloadable
version is 1.12)

3. Read carefully README file. "mono DVFlasher_1_12.exe" has insufficient
command line arguments. Try something like "mono
/exe/DVFlasher_1_12.exe -fnandbin
/exe/u-boot-nand_s3_4_fix.bin"

4. Are you trying to flash something on an EVM or you're testing with a
custom board? In case of the latter, read this thread:
http://www.mail-archive.com/davinci-linux-open-source@linux.davincidsp.com/msg02411.html

Good luck,
Ivan
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source

Re: Using NAND flash bad block management

[Meher]

Hi Kenric,

On 5/11/07, Kenric Smith <[EMAIL PROTECTED]> wrote:

Not much help, but I know the kernel (and ramdisk) images are working
around blocks marked bad at the factory.  I have programmed many boards,
and some of them print out extra messages when I write to NAND under
linux about skipping a bad blocks.   The do boot fine, but if I cat the
entire memory region with a bad block, it is exactly one block smaller
than it should be.



Thanks for the information but I am still looking at what is the
format of the bad block table that si created by the MTD NAND layer
when the nand_scan_bbt is called. If I select something like 2 bits
per block then will the table be something like

|   block num  |  block type  ||   block num  |  block type  |
| 16-bits |   2 bits|| 16-bits |   2 bits|
|-

where first 2 bytes represetnt block num and 2 bits of next 1/2 bytes
will be block type(good, bad, factory bad)?? I am not able to
visualize this structure from the nand_scan_bbt code.. If I can know
how this structure looks like then I can search for this and load it
so that my bootloader is in sync with the bad blocks developed during
updating process..




-Original Message-
From:
[EMAIL PROTECTED]
sp.com
[mailto:[EMAIL PROTECTED]
davincidsp.com] On Behalf Of Meher
Sent: Thursday, May 10, 2007 12:15 PM
To: davinci-linux-open-source
Subject: Using NAND flash bad block management

Hi,
I would like to know if the current U-boot code on davinci has
support for Bad block management? I think davinci boot code expects
U-boot to be present at some aprticular location in NAND flash and say
if that block becomes bad, what does the ROM code do?
  Also how does U-boot manage the location of kernel image in flash
moving around because of bad blocks?

--
Regards,
Meher
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source




--
Regards,
Meher
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source

RE: DV Flasher

[Allred, Daniel]

Philip,

Make sure that you have the latest mono version.  Also you can try
modifying the code to remove the clear screen call at the beginning of
main.  This app was tested on a Fedora/Red Hat system with Mono 1.1.3,
so anything later should work.

Regards,

Daniel J. Allred
Software Applications
Catalog DSP / Emerging End Equipment

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On
Behalf Of Philip Balister
Sent: Friday, May 11, 2007 2:04 PM
To: davinci-linux-open-source@linux.davincidsp.com
Subject: Re: DV Flasher

Andrew Armstrong wrote:
> Philip,
> 
> If you read the readme file included with DV flasher it describes
using 
> mono under a linux machine to enable you to execute it.

Moving past my skipping the readme and reading the source 

OK, I have built the DVFlasher and am attempting to run it using mono.

Executing:

mono DVFlasher_1_10.exe

causes the xterm to blink and the prompt to return with no visible 
messages remaining. I think it is trying to display a message, but the 
screen is erased before I can see the message.

Philip
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source

Re: DV Flasher

[Philip Balister]

Andrew Armstrong wrote:

Philip,

If you read the readme file included with DV flasher it describes using 
mono under a linux machine to enable you to execute it.


Moving past my skipping the readme and reading the source 

OK, I have built the DVFlasher and am attempting to run it using mono.

Executing:

mono DVFlasher_1_10.exe

causes the xterm to blink and the prompt to return with no visible 
messages remaining. I think it is trying to display a message, but the 
screen is erased before I can see the message.


Philip


smime.p7s
Description: S/MIME Cryptographic Signature
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source

Re: mmap issue

[Andy Ngo]

Hi,

Thanks to everyone for your responses and suggestions.  I still have a 
questions about reads.  When I do a read from the mmaped region, how do I know 
if they values are valid (not stale data)?  For example, if the FPGA microblaze 
processor on the other side writes, let's say 32 bytes, to the shared RAM, then 
interrupts the Davinci to read them, are those 32 bytes valid when my user 
application accesses those bytes via the mmaped pointer?  Does the /dev/mem 
driver access the real shared RAM on every read access or do I have to call 
msync every time I do a read to guarantee the data are valid?  Thanks!

Regards,
Andy

- Original Message 
From: Roberto Waltman <[EMAIL PROTECTED]>
To: "davinci-linux-open-source @linux.davincidsp.com" 

Sent: Friday, May 11, 2007 6:54:39 AM
Subject: Re: mmap issue


Sorry, I misread the original post.  We had a similar, but not identical 
problem.
In our case, CPU writes to control registers in an external FPGA were 
not being propagated correctly.
Still, the same solution may work (dummy writes followed by reads?)

Also:
Andy Ngo wrote:
 > 1) If I need the writes to be real-time (immediately flushed out to 
the shared RAM), do I have to call msync every single time I do a 
write?  If this is the case, isn't this very inefficient? Does msync 
have to check the whole 0x2 range to check what bytes need to be 
flushed?

You can tell msync() to synchronize only the same area modified in the 
write. If this is "inefficient" or not, only you can tell.  msync() may 
not be necessary for memory access, as opposed to access to memory 
mapped files.

 > 3) I tried using MAP_PRIVATE and it doesn't seem to map to the shared 
RAM space at all (mmap doesn't return an error but I can't write or read 
from it).  Is there anyway to force the mechanism behind mmap (driver 
for /dev/mem ?) to force a flush everytime the ARM writes to shared RAM 
without having to call msync?

I thought about writing a special driver similar to /dev/mem, but with 
that property as well as only using the right word size (16 bits in our 
case)


Roberto Waltman wrote:
> R. Simning wrote:
>> Andy Ngo wrote:
>>> . the FPGA Microblaze write values to the shared RAM, and when 
>>> our ARM processor on the Davinci reads them during the interrupt 
>>> processing, the data looks staled (as though from previous reads).
> ...
>>  I thought the declaration of a variable as "volatile" would force 
>> the value to always be read directly from RAM, never cache. I'm not 
>> clear whether declaring a variable "volatile" forces the write to 
>> RAM, but that case doesn't seem to be an issue here.
>>
>> I would believe that just declaring those data structures as 
>> "volatile" should resolve your cache issues of reading "stale" data.
>
> No, that only tells the compiler not to optimize-out references to a 
> variable, always fetching a new value from "memory" when necessary.  
> The compiler has no knowledge if the value is fetched from actual 
> memory, from an internal or external cache, or if it is out of sync 
> with a second CPU's view, etc.
>
> We went through the same problem recently, one of my colleagues found 
> the answer:
>
> (a) Declare all variables in the mapped area as volatile, and
> (b) Do a readback immediately after writing to mapped memory, to force 
> flushing the cache.
>
> See  http://www.arm.com/pdfs/DDI0198D_926_TRM.pdf,  chapter 4, in 
> particular section 4.2, for the rationale behind this.
>
>
> Roberto Waltman
>
>
> ___
> Davinci-linux-open-source mailing list
> Davinci-linux-open-source@linux.davincidsp.com
> http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
>


___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source




___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source

Re: mmap issue

[Roberto Waltman]

Sorry, I misread the original post.  We had a similar, but not identical 
problem.
In our case, CPU writes to control registers in an external FPGA were 
not being propagated correctly.

Still, the same solution may work (dummy writes followed by reads?)

Also:
Andy Ngo wrote:
> 1) If I need the writes to be real-time (immediately flushed out to 
the shared RAM), do I have to call msync every single time I do a 
write?  If this is the case, isn't this very inefficient? Does msync 
have to check the whole 0x2 range to check what bytes need to be 
flushed?


You can tell msync() to synchronize only the same area modified in the 
write. If this is "inefficient" or not, only you can tell.  msync() may 
not be necessary for memory access, as opposed to access to memory 
mapped files.


> 3) I tried using MAP_PRIVATE and it doesn't seem to map to the shared 
RAM space at all (mmap doesn't return an error but I can't write or read 
from it).  Is there anyway to force the mechanism behind mmap (driver 
for /dev/mem ?) to force a flush everytime the ARM writes to shared RAM 
without having to call msync?


I thought about writing a special driver similar to /dev/mem, but with 
that property as well as only using the right word size (16 bits in our 
case)



Roberto Waltman wrote:

R. Simning wrote:

Andy Ngo wrote:
. the FPGA Microblaze write values to the shared RAM, and when 
our ARM processor on the Davinci reads them during the interrupt 
processing, the data looks staled (as though from previous reads).

...
 I thought the declaration of a variable as "volatile" would force 
the value to always be read directly from RAM, never cache. I'm not 
clear whether declaring a variable "volatile" forces the write to 
RAM, but that case doesn't seem to be an issue here.


I would believe that just declaring those data structures as 
"volatile" should resolve your cache issues of reading "stale" data.


No, that only tells the compiler not to optimize-out references to a 
variable, always fetching a new value from "memory" when necessary.  
The compiler has no knowledge if the value is fetched from actual 
memory, from an internal or external cache, or if it is out of sync 
with a second CPU's view, etc.


We went through the same problem recently, one of my colleagues found 
the answer:


(a) Declare all variables in the mapped area as volatile, and
(b) Do a readback immediately after writing to mapped memory, to force 
flushing the cache.


See  http://www.arm.com/pdfs/DDI0198D_926_TRM.pdf,  chapter 4, in 
particular section 4.2, for the rationale behind this.



Roberto Waltman


___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source




___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source

Re: mmap issue

[Roberto Waltman]

R. Simning wrote:

Andy Ngo wrote:
. the FPGA Microblaze write values to the shared RAM, and when 
our ARM processor on the Davinci reads them during the interrupt 
processing, the data looks staled (as though from previous reads).

...
 I thought the declaration of a variable as "volatile" would force the 
value to always be read directly from RAM, never cache. I'm not clear 
whether declaring a variable "volatile" forces the write to RAM, but 
that case doesn't seem to be an issue here.


I would believe that just declaring those data structures as 
"volatile" should resolve your cache issues of reading "stale" data.


No, that only tells the compiler not to optimize-out references to a 
variable, always fetching a new value from "memory" when necessary.  The 
compiler has no knowledge if the value is fetched from actual memory, 
from an internal or external cache, or if it is out of sync with a 
second CPU's view, etc.


We went through the same problem recently, one of my colleagues found 
the answer:


(a) Declare all variables in the mapped area as volatile, and
(b) Do a readback immediately after writing to mapped memory, to force 
flushing the cache.


See  http://www.arm.com/pdfs/DDI0198D_926_TRM.pdf,  chapter 4, in 
particular section 4.2, for the rationale behind this.



Roberto Waltman


___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source

Re: MMC Performance Issue

[Andrew Armstrong]

I have some more information regarding this issue, I have been testing
out the driver and discovered that in fact varying of the internal
settings, dma, 4 bit access etc does not make any difference.

A scope revealed that the card is only being accessed only for a
fraction of the time. So the key to getting this upto any reasonable
speed is increase the rate at which the kernel services this device.

Any ideas?

Andrew


On Thu, 2007-05-10 at 10:04 +0100, Andrew Armstrong wrote:
> Hi Guys,
> 
> I have been experimenting with the MMC/SD interface. I am finding that
> transfers are really slow, with figures like 3.96 mbit/s (async) and
> 2.94 mbit/s (sync).
> 
> Does anyone know anything about the MMC driver and where the bottleneck
> is? I am considering modifying it accordingly, but I do not yet have
> enough understanding of driver and hardware involved.
> 
> Is there any way to gauge what the theoretical through-puts to this
> device should be?
> 
> Regards,
> 
> Andrew
> 
> ___
> Davinci-linux-open-source mailing list
> Davinci-linux-open-source@linux.davincidsp.com
> http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source

___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source

Re: mmap issue

[Matthias Welwarsky]

I just checked drivers/char/mem.c:

static int mmap_mem(struct file * file, struct vm_area_struct * vma)
{
#ifdef pgprot_noncached
unsigned long offset = vma->vm_pgoff << PAGE_SHIFT;
int uncached;

uncached = uncached_access(file, offset);
if (uncached)
vma->vm_page_prot = pgprot_noncached(vma->vm_page_prot);
#endif

/* Remap-pfn-range will mark the range VM_IO and VM_RESERVED */
if (remap_pfn_range(vma,
vma->vm_start,
vma->vm_pgoff,
vma->vm_end-vma->vm_start,
vma->vm_page_prot))
return -EAGAIN;
return 0;
}

have a look at the function "uncached_access" in the same file. You'll
see that it returns 1 for O_SYNC, so it should work as is suggested.

regards,
matthias

Matthias Welwarsky wrote:
> Andy Ngo wrote:
>> Thanks, but how do I set the range uncacheable?  I don't see such an
>> option for mmap.  Please advise.  Thanks!
> does it help to open /dev/mem with O_SYNC?
>>
>> Regards,
>> Andy
>>
>> - Original Message 
>> From: YunChuan Qin <[EMAIL PROTECTED]>
>> To: Andy Ngo <[EMAIL PROTECTED]>
>> Sent: Thursday, May 10, 2007 9:38:46 PM
>> Subject: Re: mmap issue
>>
>> set this memory range uncacheable may solve your problem.
>>
>> 2007/5/11, Andy Ngo <[EMAIL PROTECTED]
>> >:
>>
>> Hi,
>>
>> This is more of a Linux question than anything.  Hopefully
>> someone can help me.  Our custom board has the Davinci exchanging
>> data with a Xilinx Virtex 5 Pro FPGA Microblaze processor via a
>> shared (Dual-Port) RAM interface.  The shared RAM is 128Kb and is
>> hooked us to CS4 on the AEMIF.  In order to access this shared
>> RAM memory space (physical address is 0x0600), our
>> application is using mmap to map it to a virtual address space. 
>> Here's a snippet of the mmap initialization:
>>
>> int fd;
>> unsigned char *shareRamPtr;
>>
>> fd = open("/dev/mem", O_RDWR);
>> sharedRamPtr = (unsigned char *)mmap(0, 0x2 /* 128 Kb */,
>> PROT_READ | PROT_WRITE,
>> MAP_SHARED, fd, 0x0600);
>>
>> It seems to work but not quite.  We have a interrupt processing
>> handler that needs access (writes as well as reads) this space in
>> real-time every 2ms.  Sometimes, when the FPGA Microblaze write
>> values to the shared RAM, and when our ARM processor on the
>> Davinci reads them during the interrupt processing, the data
>> looks staled (as though from previous reads).  I googled and
>> found that writes require a call to msync to flush writes to the
>> actual shared RAM interface.  So here are my questions:
>>
>> 1) If I need the writes to be real-time (immediately flushed out
>> to the shared RAM), do I have to call msync every single time I
>> do a write?  If this is the case, isn't this very inefficient?
>> Does msync have to check the whole 0x2 range to check what
>> bytes need to be flushed?
>> 2) How about for reads?  As mentioned above, I seem to get stale
>> data sometimes during reads.  Since the Microblaze is constantly
>> writing to shared RAM, what needs to be done so that when the ARM
>> reads the data at those locations, they are what the Microblaze
>> wrote?
>> 3) I tried using MAP_PRIVATE and it doesn't seem to map to the
>> shared RAM space at all (mmap doesn't return an error but I can't
>> write or read from it).  Is there anyway to force the mechanism
>> behind mmap (driver for /dev/mem ?) to force a flush everytime
>> the ARM writes to shared RAM without having to call msync?
>>
>> Please advise.  Thanks.
>>
>> Regards,
>> Andy
>>
>>
>> ___
>> Davinci-linux-open-source mailing list
>> Davinci-linux-open-source@linux.davincidsp.com
>> 
>> http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
>> 
>>
>>
>>
>>
>> -- 
>> blog site:blog.csdn.net/freasy 
>>
>>
>> 
>>
>> ___
>> Davinci-linux-open-source mailing list
>> Davinci-linux-open-source@linux.davincidsp.com
>> http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
>>   
>
> -- 
> * Matthias Welwarsky
> Project Manager Software
> Germany
>
> *

-- 
* Matthias Welwarsky
Project Manager Software
Germany

*



This  email  and any  files  transmitted  with it are  confidential  and are
intended solely  for the use of the individual  or entity to which  they are
addressed.  Access to this e-mail by anyone else is unauthorised. If you are
not the  intended recipient,  any disclosure,  c

Re: mmap issue

[R. Simning]

Andy Ngo wrote:

  
  
  Hi,
  
This is more of a Linux question than anything.  Hopefully someone can
help me.  Our custom board has the Davinci exchanging data with a
Xilinx Virtex 5 Pro FPGA Microblaze processor via a shared (Dual-Port)
RAM interface.  The shared RAM is 128Kb and is hooked us to CS4 on the
AEMIF.  In order to access this shared RAM memory space (physical
address is 0x0600), our application is using mmap to map it to a
virtual address space.  Here's a snippet of the mmap initialization:
  
int fd;
unsigned char *shareRamPtr;
  
fd = open("/dev/mem", O_RDWR);
sharedRamPtr = (unsigned char *)mmap(0, 0x2 /* 128 Kb */, PROT_READ
| PROT_WRITE, 
    MAP_SHARED, fd, 0x0600);
  
It seems to work but not quite.  We have a interrupt processing handler
that needs access (writes as well as reads) this space in real-time
every 2ms.  Sometimes, when the FPGA Microblaze write values to the
shared RAM, and when our ARM processor on the Davinci reads them during
the interrupt processing, the data looks staled (as though from
previous reads).  I googled and found that writes require a call to
msync to flush writes to the actual shared RAM interface.  So here are
my questions:
  
1) If I need the writes to be real-time (immediately flushed out to the
shared RAM), do I have to call msync every single time I do a write? 
If this is the case, isn't this very inefficient? Does msync have to
check the whole 0x2 range to check what bytes need to be flushed?
2) How about for reads?  As mentioned above, I seem to get stale data
sometimes during reads.  Since the Microblaze is constantly writing to
shared RAM, what needs to be done so that when the ARM reads the data
at those locations, they are what the Microblaze wrote?
3) I tried using MAP_PRIVATE and it doesn't seem to map to the shared
RAM space at all (mmap doesn't return an error but I can't write or
read from it).  Is there anyway to force the mechanism behind mmap
(driver for /dev/mem ?) to force a flush everytime the ARM writes to
shared RAM without having to call msync?
  
Please advise.  Thanks.
  
Regards,
Andy
  
  
  
  

___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
  

The FPGA is writing directly to shared RAM. There should be no cache
issues from the perspective of the FPGA. 

The issue would seem to be concerning the ARM only. I thought the
declaration of a variable as "volatile" would force the value to always
be read directly from RAM, never cache. I'm not clear whether declaring
a variable "volatile" forces the write to RAM, but that case doesn't
seem to be an issue here.

I would believe that just declaring those data structures as "volatile"
should resolve your cache issues of reading "stale" data.

Bob




___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source

Re: mmap issue

[Matthias Welwarsky]

Andy Ngo wrote:
> Thanks, but how do I set the range uncacheable?  I don't see such an
> option for mmap.  Please advise.  Thanks!
does it help to open /dev/mem with O_SYNC?
>
> Regards,
> Andy
>
> - Original Message 
> From: YunChuan Qin <[EMAIL PROTECTED]>
> To: Andy Ngo <[EMAIL PROTECTED]>
> Sent: Thursday, May 10, 2007 9:38:46 PM
> Subject: Re: mmap issue
>
> set this memory range uncacheable may solve your problem.
>
> 2007/5/11, Andy Ngo <[EMAIL PROTECTED]
> >:
>
> Hi,
>
> This is more of a Linux question than anything.  Hopefully someone
> can help me.  Our custom board has the Davinci exchanging data
> with a Xilinx Virtex 5 Pro FPGA Microblaze processor via a shared
> (Dual-Port) RAM interface.  The shared RAM is 128Kb and is hooked
> us to CS4 on the AEMIF.  In order to access this shared RAM memory
> space (physical address is 0x0600), our application is using
> mmap to map it to a virtual address space.  Here's a snippet of
> the mmap initialization:
>
> int fd;
> unsigned char *shareRamPtr;
>
> fd = open("/dev/mem", O_RDWR);
> sharedRamPtr = (unsigned char *)mmap(0, 0x2 /* 128 Kb */,
> PROT_READ | PROT_WRITE,
> MAP_SHARED, fd, 0x0600);
>
> It seems to work but not quite.  We have a interrupt processing
> handler that needs access (writes as well as reads) this space in
> real-time every 2ms.  Sometimes, when the FPGA Microblaze write
> values to the shared RAM, and when our ARM processor on the
> Davinci reads them during the interrupt processing, the data looks
> staled (as though from previous reads).  I googled and found that
> writes require a call to msync to flush writes to the actual
> shared RAM interface.  So here are my questions:
>
> 1) If I need the writes to be real-time (immediately flushed out
> to the shared RAM), do I have to call msync every single time I do
> a write?  If this is the case, isn't this very inefficient? Does
> msync have to check the whole 0x2 range to check what bytes
> need to be flushed?
> 2) How about for reads?  As mentioned above, I seem to get stale
> data sometimes during reads.  Since the Microblaze is constantly
> writing to shared RAM, what needs to be done so that when the ARM
> reads the data at those locations, they are what the Microblaze wrote?
> 3) I tried using MAP_PRIVATE and it doesn't seem to map to the
> shared RAM space at all (mmap doesn't return an error but I can't
> write or read from it).  Is there anyway to force the mechanism
> behind mmap (driver for /dev/mem ?) to force a flush everytime the
> ARM writes to shared RAM without having to call msync?
>
> Please advise.  Thanks.
>
> Regards,
> Andy
>
>
> ___
> Davinci-linux-open-source mailing list
> Davinci-linux-open-source@linux.davincidsp.com
> 
> http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
> 
>
>
>
>
> -- 
> blog site:blog.csdn.net/freasy 
>
>
> 
>
> ___
> Davinci-linux-open-source mailing list
> Davinci-linux-open-source@linux.davincidsp.com
> http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
>   

-- 
* Matthias Welwarsky
Project Manager Software
Germany

*



This  email  and any  files  transmitted  with it are  confidential  and are
intended solely  for the use of the individual  or entity to which  they are
addressed.  Access to this e-mail by anyone else is unauthorised. If you are
not the  intended recipient,  any disclosure,  copying,  distribution or any
action taken or omitted to be taken in reliance on it, is prohibited. E-mail
messages are not necessarily secure.  Archos does not accept  responsibility
for any changes made to this message after it was sent.

___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source

Re: mmap issue

[Ivan Tonchev]

Hi Andy,

Thanks, but how do I set the range uncacheable?  I don't see such an 
option for mmap.  Please advise.  Thanks!




Have you tried with pgprot_noncached()?

I haven't used it myself, but found it in some framebuffer mmap handling 
code. For example see linux/drivers/video/sa1100fb.c


Good luck,
Ivan

___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source