linux-fbdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Siarhei Siamashka <siarhei.siamashka@gmail.com>
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 0/2] OMAPDSS: write-through caching support for omapfb
Date: Tue, 22 May 2012 19:54:02 +0000	[thread overview]
Message-ID: <1337716444-30139-1-git-send-email-siarhei.siamashka@gmail.com> (raw)

This is a very simple few-liner patchset, which allows to optionally
enable write-through caching for OMAP DSS framebuffer. The problem with
the current writecombine cacheability attribute is that it only speeds
up writes. Uncached reads are slow, even though the use of NEON mitigates
this problem a bit.

Traditionally, xf86-video-fbdev DDX is using shadow framebuffer in the
system memory. Which contains a copy of the framebuffer data for the
purpose of providing fast read access to it when needed. Framebuffer
read access is required not so often, but it still gets used for
scrolling and moving windows around in Xorg server. And the users
perceive their linux desktop as rather sluggish when these operations
are not fast enough.

In the case of ARM hardware, framebuffer is typically physically
located in the main memory. And the processors still support
write-through cacheability attribute. According to ARM ARM, the writes
done to write-through cached memory inside the level of cache are
visible to all observers outside the level of cache without the need
of explicit cache maintenance (same rule as for non-cached memory).
So write-through cache is a perfect choice when only CPU is allowed
to modify the data in the framebuffer and everyone else (screen
refresh DMA) is only reading it. That is, assuming that write-through
cached memory provides good performance and there are no quirks.
As the framebuffer reads become fast, the need for shadow framebuffer
disappears.

And at least for ARM11 and Cortex-A8 processors, the performance of
write-through cache is really good. Cortex-A9 is another story, because
all pages marked as Write-Through are supposedly treated as Non-Cacheable:
    http://infocenter.arm.com/help/topic/com.arm.doc.ddi0388h/CBBFDIJD.html
So OMAP4 is out of luck. But OMAP3 based hardware can have a nice
graphics performance boost. And OMAP3 actually needs it a lot more.

PS. The xf86-video-omapfb-0.1.1 driver does not even use shadow
    framebuffer (ouch!). So its users, if any, should see an immediate
    speedup.

Siarhei Siamashka (2):
  ARM: pgtable: add pgprot_writethrough() macro
  OMAPDSS: Optionally enable write-through cache for the framebuffer

 Documentation/arm/OMAP/DSS               |   10 ++++++++++
 arch/arm/include/asm/pgtable.h           |    3 +++
 drivers/video/omap2/omapfb/omapfb-main.c |    7 ++++++-
 3 files changed, 19 insertions(+), 1 deletions(-)

-- 
1.7.3.4


             reply	other threads:[~2012-05-22 19:54 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-05-22 19:54 Siarhei Siamashka [this message]
2012-05-22 19:54 ` [PATCH 1/2] ARM: pgtable: add pgprot_writethrough() macro Siarhei Siamashka
2012-08-08 11:07   ` Grazvydas Ignotas
2012-05-22 19:54 ` [PATCH 2/2] OMAPDSS: Optionally enable write-through cache for the framebuffer Siarhei Siamashka
2012-05-22 20:25 ` [PATCH 0/2] OMAPDSS: write-through caching support for omapfb Siarhei Siamashka
2012-05-24  7:43 ` Tomi Valkeinen
2012-05-25  9:00   ` Siarhei Siamashka

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=1337716444-30139-1-git-send-email-siarhei.siamashka@gmail.com \
    --to=siarhei.siamashka@gmail.com \
    --cc=linux-arm-kernel@lists.infradead.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).