All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mark Kettenis <mark.kettenis@xs4all.nl>
To: Alexander Graf <agraf@csgraf.de>
Cc: xypron.glpk@gmx.de, agust@denx.de, sjg@chromium.org,
	mbrugger@suse.com, da@libre.computer, u-boot@lists.denx.de
Subject: Re: [PATCH 0/6] Add video damage tracking
Date: Thu, 9 Jun 2022 21:26:20 +0200 (CEST)	[thread overview]
Message-ID: <d3cdb8afaa2777a5@bloch.sibelius.xs4all.nl> (raw)
In-Reply-To: <dda133e2-d0db-a634-367c-9cfbd510099e@csgraf.de> (message from Alexander Graf on Thu, 9 Jun 2022 21:04:37 +0200)

> Date: Thu, 9 Jun 2022 21:04:37 +0200
> From: Alexander Graf <agraf@csgraf.de>
> 
> On 07.06.22 10:28, Heinrich Schuchardt wrote:
> > On 6/7/22 01:43, Alexander Graf wrote:
> >> This patch set speeds up graphics output on ARM by a factor of 60x.
> >>
> >> On most ARM SBCs, we keep the frame buffer in DRAM and map it as cached,
> >> but need it accessible by the display controller which reads directly
> >> from a later point of consistency. Hence, we flush the frame buffer to
> >> DRAM on every change. The full frame buffer.
> >
> > Isn't a similar problem already solved by CONFIG_VIDEO_COPY?
> >
> > Leaving the frame buffer uncached would convert the ARM problem into the
> > X86 case?
> 
> 
> It solves a similar problem, yes. However, it requires us to allocate 
> the frame buffer size twice, and we would need to dynamically toggle the 
> MMU mappings of the frame buffer to WC instead of cached. That's code we 
> don't have today.

For the Apple M1 the framebuffer is covered by the "memory map" and
maps it as Normal-NC, but that is because the framebuffer is already
set up at the point where u-boot takes control.

  reply	other threads:[~2022-06-09 19:26 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-06-06 23:43 [PATCH 0/6] Add video damage tracking Alexander Graf
2022-06-06 23:43 ` [PATCH 1/6] dm: video: Add damage tracking API Alexander Graf
2022-06-06 23:43 ` [PATCH 2/6] dm: video: Add damage notification on display clear Alexander Graf
2022-06-06 23:43 ` [PATCH 3/6] vidconsole: Add damage notifications to all vidconsole drivers Alexander Graf
2022-06-06 23:43 ` [PATCH 4/6] video: Add damage notification on bmp display Alexander Graf
2022-06-06 23:43 ` [PATCH 5/6] efi_loader: GOP: Add damage notification on BLT Alexander Graf
2022-06-07  7:12   ` Heinrich Schuchardt
2022-06-09 14:55     ` Alexander Graf
2022-06-06 23:43 ` [PATCH 6/6] video: Only dcache flush damaged lines Alexander Graf
2022-06-07  8:00   ` Heinrich Schuchardt
2022-06-09 14:56     ` Alexander Graf
2022-06-07  8:28 ` [PATCH 0/6] Add video damage tracking Heinrich Schuchardt
2022-06-09 19:04   ` Alexander Graf
2022-06-09 19:26     ` Mark Kettenis [this message]
2022-06-09 20:32     ` Heinrich Schuchardt
2022-06-09 21:09       ` Alexander Graf

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=d3cdb8afaa2777a5@bloch.sibelius.xs4all.nl \
    --to=mark.kettenis@xs4all.nl \
    --cc=agraf@csgraf.de \
    --cc=agust@denx.de \
    --cc=da@libre.computer \
    --cc=mbrugger@suse.com \
    --cc=sjg@chromium.org \
    --cc=u-boot@lists.denx.de \
    --cc=xypron.glpk@gmx.de \
    /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.