All of lore.kernel.org
 help / color / mirror / Atom feed
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

  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.