From: Michael Schmitz <schmitzmic@gmail.com>
To: linux-m68k@vger.kernel.org
Cc: geert@linux-m68k.org, debian-68k@lists.debian.org
Subject: [PATCH 0/2] m68k/atari - make atafb work with kernel loaded to FastRAM
Date: Sat, 22 Mar 2014 21:47:06 +1300 [thread overview]
Message-ID: <1395478028-17274-1-git-send-email-schmitz@debian.org> (raw)
In-Reply-To: <1395213784-3249-1-git-send-email-schmitz@debian.org>
Geert,
cleaned up version of my earlier patches to make allocation of ST-RAM work
even when the kernel resides in FastRAM, and ST-RAM is not normally usable
by Linux because it violates the memory chunk order required for the
discontig memory model.
The code relies on a mapping that has been set up for the first 16 MB of
address space in head.S - this may not be ideal, because the mapping is
set up as non-cacheable and serialized (for reasons of hardware registers
mapped in the upper end of that segment).
I've taken care not to disturb the cache mode for the framebuffer if the
framebuffer resides in the first 4 MB of ST-RAM, for now. This is easily
disabled by reverting the relevant piece of code back to its old state
(preserving the changes to the virt/phys translation).
So far, I've only tested this on a patched version of ARAnyM, using Andreas'
SkipSTRAM or LoadToFastRAM options.
Code path for external framebuffer has not been changed - this code relies on
the user passing the address of an external VGA framebuffer to the kernel,
and should continue to work as normal.
The use of special ST-RAM virt/phys translation helpers somewhat complicates
the addition of code to deal with Videl-compatible hardware that uses a
dedicated video RAM chunk distinct from ST-RAM. Not sure how to work around
that.
Cheers,
Michael
next prev parent reply other threads:[~2014-03-22 8:47 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-03-19 7:23 [PATCH 1/2] m68k/atari - stram: alloc ST-RAM pool even if kernel not in ST-RAM Michael Schmitz
2014-03-19 7:23 ` [PATCH 2/2] m68k/atari - atafb: convert allocation of fb ram to new interface Michael Schmitz
2014-03-19 8:01 ` Geert Uytterhoeven
2014-03-20 8:17 ` schmitz
2014-03-20 8:33 ` Geert Uytterhoeven
2014-03-22 1:28 ` schmitz
2014-03-22 7:36 ` schmitz
2014-03-19 7:51 ` [PATCH 1/2] m68k/atari - stram: alloc ST-RAM pool even if kernel not in ST-RAM Geert Uytterhoeven
2014-03-20 8:23 ` schmitz
2014-03-20 8:35 ` Geert Uytterhoeven
2014-03-22 1:32 ` schmitz
2014-03-23 20:02 ` Geert Uytterhoeven
2014-03-19 8:18 ` Andreas Schwab
2014-03-20 6:35 ` Patrice Mandin
2014-03-22 8:47 ` Michael Schmitz [this message]
2014-03-23 0:28 ` [PATCH 0/2] m68k/atari - make atafb work with kernel loaded to FastRAM schmitz
2014-03-22 8:47 ` [PATCH 1/2] m68k/atari - stram: alloc ST-RAM pool even if kernel not in ST-RAM Michael Schmitz
2014-03-22 8:47 ` [PATCH 2/2] m68k/atari - atafb: convert allocation of fb ram to new interface Michael Schmitz
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=1395478028-17274-1-git-send-email-schmitz@debian.org \
--to=schmitzmic@gmail.com \
--cc=debian-68k@lists.debian.org \
--cc=geert@linux-m68k.org \
--cc=linux-m68k@vger.kernel.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