From: Ralf Baechle <ralf@linux-mips.org>
To: Mile Davidovic <Mile.Davidovic@micronasnit.com>
Cc: linux-mips@linux-mips.org
Subject: Re: Uncached mmap
Date: Mon, 13 Nov 2006 12:32:33 +0000 [thread overview]
Message-ID: <20061113123233.GA20337@linux-mips.org> (raw)
In-Reply-To: <001201c70704$bc731230$5c00a8c0@niit.micronasnit.com>
On Mon, Nov 13, 2006 at 10:18:52AM +0100, Mile Davidovic wrote:
> Hello to all,
> I am working on fb device and I have general questions regarding cache/uncache
> access to MIPS memory.
>
> User space application use mmap access for r/w access to fb device. If fb use
> cached memory, user space application has to call cacheflush to flush contents
> instruction and/or data cache. In this case there are no limitations regarding
> byte access to this memory. Is this correct statement?
Yes.
With caching bus transfers from and to the device happen at the full width
of the bus, so a device won't see byte accesses ever.
> If fb use uncached memory, there is no need for cacheflush call in user space
> application but limitation is access to mmap uncached memory.
Correct.
> There is no byte access to uncached mmaped memory. Is this correct statement?
Definately wrong. For example alot of mmapped I/O devices use uncached
byte accesses.
This stament if of course limited to the CPU's part of the system. Devices
may have their specific restrictions on access size and its not uncommon to
have such restrictions though that would seem unlikely for framebuffer
memory.
If your particular CPU support it you may want to use cache mode "uncached
accellerated" for a framebuffer. It should deliver significtn performance
gains yet avoid the need for cache flushes.
Ralf
next prev parent reply other threads:[~2006-11-13 12:32 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-11-13 9:18 Uncached mmap Mile Davidovic
2006-11-13 9:18 ` Mile Davidovic
2006-11-13 12:32 ` Ralf Baechle [this message]
2006-11-13 15:30 ` Mile Davidovic
2006-11-13 15:30 ` Mile Davidovic
2006-11-13 16:40 ` Ralf Baechle
2006-11-14 10:58 ` Mile Davidovic
2006-11-14 10:58 ` Mile Davidovic
2006-11-14 11:07 ` Mile Davidovic
2006-11-14 11:07 ` Mile Davidovic
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20061113123233.GA20337@linux-mips.org \
--to=ralf@linux-mips.org \
--cc=Mile.Davidovic@micronasnit.com \
--cc=linux-mips@linux-mips.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.