From: Finn Thain <fthain@telegraphics.com.au>
To: <linux-kernel@vger.kernel.org>, <linux-m68k@vger.kernel.org>,
<linuxppc-dev@lists.ozlabs.org>,
Jean-Christophe Plagniol-Villard <plagnioj@jcrosoft.com>,
Tomi Valkeinen <tomi.valkeinen@ti.com>,
linux-fbdev@vger.kernel.org
Subject: [RFC v5 17/26] powerpc, fbdev: Use NV_CMODE and NV_VMODE only when CONFIG_PPC32 and CONFIG_PPC_PMAC and CONFIG_NVRAM
Date: Sat, 25 Jul 2015 17:46:16 +1000 [thread overview]
Message-ID: <20150725074603.673303850@telegraphics.com.au> (raw)
In-Reply-To: 20150725074559.543547894@telegraphics.com.au
[-- Attachment #1: ppc32-fbdev-NV_CMODE-and-NV_VMODE --]
[-- Type: text/plain, Size: 6526 bytes --]
This patch addresses inconsistencies in Mac framebuffer drivers and their
use of Kconfig symbols relating to NVRAM, so PPC64 can use CONFIG_NVRAM.
Macintosh framebuffer drivers use default settings for color mode and
video mode that are found in NVRAM. On PCI Macs, MacOS stores display
settings in the Name Registry (NR) partition in NVRAM*. On NuBus Macs,
there is no NR partition and MacOS stores display mode settings in PRAM**.
Early model Macs are the ones most likely to benefit from these settings,
since they are more likely to have one display: a fixed-frequency monitor
connected to the built-in framebuffer device. Moreover, a single NV_CMODE
value and a single NV_VMODE value provide for only one display.
The NV_CMODE and NV_VMODE constants are apparently offsets into the NR
partition for Old World machines and not New World, which also suggests
that these defaults are not useful on later models.
All this argues for limiting NVRAM support in PowerMac fbdev drivers to
PPC32 and indeed this is already the case, since CONFIG_NVRAM cannot be
enabled on PPC64 at present.
For matroxfb, make the CONFIG_PPC32 condition explicit. That way the
driver won't crash on PPC64 when CONFIG_NVRAM becomes available there.
In imsttfb, add the missing CONFIG_NVRAM test to prevent a build failure,
since PPC64 does not implement nvram_read_byte(). Also add a missing
machine_is(powermac) check. Change the inconsistent CONFIG_PPC dependency
and the matching #ifdef tests to CONFIG_PPC_PMAC. Drop unused #includes.
In valkyriefb, for clarity and consistency with the other PowerMac fbdev
drivers, test for CONFIG_PPC_PMAC instead of !CONFIG_MAC. Remove a
bogus comment regarding PRAM.
* See GetPreferredConfiguration and SavePreferredConfiguration in
"Designing PCI Cards and Drivers for Power Macintosh Computers".
** See SetDefaultMode and GetDefaultMode in "Designing Cards and Drivers
for the Macintosh Family".
Signed-off-by: Finn Thain <fthain@telegraphics.com.au>
---
drivers/video/fbdev/Kconfig | 2 +-
drivers/video/fbdev/imsttfb.c | 13 +++++--------
drivers/video/fbdev/matrox/matroxfb_base.c | 2 +-
drivers/video/fbdev/valkyriefb.c | 14 ++++++--------
4 files changed, 13 insertions(+), 18 deletions(-)
Index: linux/drivers/video/fbdev/Kconfig
===================================================================
--- linux.orig/drivers/video/fbdev/Kconfig 2015-07-25 17:42:34.000000000 +1000
+++ linux/drivers/video/fbdev/Kconfig 2015-07-25 17:45:44.000000000 +1000
@@ -544,7 +544,7 @@ config FB_IMSTT
bool "IMS Twin Turbo display support"
depends on (FB = y) && PCI
select FB_CFB_IMAGEBLIT
- select FB_MACMODES if PPC
+ select FB_MACMODES if PPC_PMAC
help
The IMS Twin Turbo is a PCI-based frame buffer card bundled with
many Macintosh and compatible computers.
Index: linux/drivers/video/fbdev/imsttfb.c
===================================================================
--- linux.orig/drivers/video/fbdev/imsttfb.c 2015-07-25 17:42:34.000000000 +1000
+++ linux/drivers/video/fbdev/imsttfb.c 2015-07-25 17:45:44.000000000 +1000
@@ -30,10 +30,8 @@
#include <asm/io.h>
#include <linux/uaccess.h>
-#if defined(CONFIG_PPC)
+#if defined(CONFIG_PPC_PMAC)
#include <linux/nvram.h>
-#include <asm/prom.h>
-#include <asm/pci-bridge.h>
#include "macmodes.h"
#endif
@@ -328,14 +326,13 @@ enum {
TVP = 1
};
-#define USE_NV_MODES 1
#define INIT_BPP 8
#define INIT_XRES 640
#define INIT_YRES 480
static int inverse = 0;
static char fontname[40] __initdata = { 0 };
-#if defined(CONFIG_PPC)
+#if defined(CONFIG_PPC_PMAC)
static signed char init_vmode = -1, init_cmode = -1;
#endif
@@ -1391,8 +1388,8 @@ static void init_imstt(struct fb_info *i
}
}
-#if USE_NV_MODES && defined(CONFIG_PPC32)
- {
+#if defined(CONFIG_PPC_PMAC) && defined(CONFIG_PPC32) && defined(CONFIG_NVRAM)
+ if (machine_is(powermac)) {
int vmode = init_vmode, cmode = init_cmode;
if (vmode == -1) {
@@ -1566,7 +1563,7 @@ imsttfb_setup(char *options)
inverse = 1;
fb_invert_cmaps();
}
-#if defined(CONFIG_PPC)
+#if defined(CONFIG_PPC_PMAC)
else if (!strncmp(this_opt, "vmode:", 6)) {
int vmode = simple_strtoul(this_opt+6, NULL, 0);
if (vmode > 0 && vmode <= VMODE_MAX)
Index: linux/drivers/video/fbdev/matrox/matroxfb_base.c
===================================================================
--- linux.orig/drivers/video/fbdev/matrox/matroxfb_base.c 2015-07-25 17:45:38.000000000 +1000
+++ linux/drivers/video/fbdev/matrox/matroxfb_base.c 2015-07-25 17:45:44.000000000 +1000
@@ -1876,7 +1876,7 @@ static int initMatrox2(struct matrox_fb_
struct fb_var_screeninfo var;
if (default_vmode <= 0 || default_vmode > VMODE_MAX)
default_vmode = VMODE_640_480_60;
-#ifdef CONFIG_NVRAM
+#if defined(CONFIG_PPC32) && defined(CONFIG_NVRAM)
if (default_cmode == CMODE_NVRAM)
default_cmode = nvram_read_byte(NV_CMODE);
#endif
Index: linux/drivers/video/fbdev/valkyriefb.c
===================================================================
--- linux.orig/drivers/video/fbdev/valkyriefb.c 2015-07-25 17:42:34.000000000 +1000
+++ linux/drivers/video/fbdev/valkyriefb.c 2015-07-25 17:45:44.000000000 +1000
@@ -65,14 +65,12 @@
#include "macmodes.h"
#include "valkyriefb.h"
-#ifdef CONFIG_MAC
-/* We don't yet have functions to read the PRAM... perhaps we can
- adapt them from the PPC code? */
-static int default_vmode = VMODE_CHOOSE;
-static int default_cmode = CMODE_8;
-#else
+#ifdef CONFIG_PPC_PMAC
static int default_vmode = VMODE_NVRAM;
static int default_cmode = CMODE_NVRAM;
+#else
+static int default_vmode = VMODE_CHOOSE;
+static int default_cmode = CMODE_8;
#endif
struct fb_par_valkyrie {
@@ -285,7 +283,7 @@ static void __init valkyrie_choose_mode(
printk(KERN_INFO "Monitor sense value = 0x%x\n", p->sense);
/* Try to pick a video mode out of NVRAM if we have one. */
-#if !defined(CONFIG_MAC) && defined(CONFIG_NVRAM)
+#if defined(CONFIG_PPC_PMAC) && defined(CONFIG_NVRAM)
if (default_vmode == VMODE_NVRAM) {
default_vmode = nvram_read_byte(NV_VMODE);
if (default_vmode <= 0
@@ -298,7 +296,7 @@ static void __init valkyrie_choose_mode(
default_vmode = mac_map_monitor_sense(p->sense);
if (!valkyrie_reg_init[default_vmode - 1])
default_vmode = VMODE_640_480_67;
-#if !defined(CONFIG_MAC) && defined(CONFIG_NVRAM)
+#if defined(CONFIG_PPC_PMAC) && defined(CONFIG_NVRAM)
if (default_cmode == CMODE_NVRAM)
default_cmode = nvram_read_byte(NV_CMODE);
#endif
next prev parent reply other threads:[~2015-07-25 7:57 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-07-25 7:45 [RFC v5 00/26] Re-use nvram module Finn Thain
2015-07-25 7:46 ` [RFC v5 01/26] scsi/atari_scsi: Dont select CONFIG_NVRAM Finn Thain
2015-07-25 7:46 ` [RFC v5 02/26] char/nvram: Use bitwise OR to obtain Atari video mode data Finn Thain
2015-07-25 7:46 ` [RFC v5 03/26] m68k/atari: Move Atari-specific code out of drivers/char/nvram.c Finn Thain
2015-07-25 7:46 ` [RFC v5 04/26] m68k/atari: Replace nvram_{read,write}_byte with arch_nvram_ops Finn Thain
2015-07-25 7:46 ` [RFC v5 05/26] char/nvram: Re-order functions to remove forward declarations and #ifdefs Finn Thain
2015-07-25 7:46 ` [RFC v5 06/26] char/nvram: Adopt arch_nvram_ops Finn Thain
2015-07-25 7:46 ` [RFC v5 07/26] x86/thinkpad_acpi: Use arch_nvram_ops methods instead of nvram_read_byte() and nvram_write_byte() Finn Thain
2015-07-25 7:46 ` [RFC v5 08/26] char/nvram: Allow the set_checksum and initialize ioctls to be omitted Finn Thain
2015-07-25 7:46 ` [RFC v5 09/26] char/nvram: Implement NVRAM read/write methods Finn Thain
2015-07-25 7:46 ` [RFC v5 10/26] char/nvram: Use generic fixed_size_llseek() Finn Thain
2015-07-25 7:46 ` [RFC v5 11/26] m68k/atari: Implement arch_nvram_ops methods and enable CONFIG_HAVE_ARCH_NVRAM_OPS Finn Thain
2015-07-25 7:46 ` [RFC v5 12/26] char/nvram: Add "devname:nvram" module alias Finn Thain
2015-07-25 7:46 ` [RFC v5 13/26] powerpc: Cleanup nvram includes Finn Thain
2015-07-25 7:46 ` [RFC v5 14/26] powerpc: Add missing ppc_md.nvram_size for CHRP and PowerMac Finn Thain
2015-07-25 7:46 ` [RFC v5 15/26] powerpc: Implement arch_nvram_ops.get_size() and remove old nvram_* exports Finn Thain
2015-07-25 7:46 ` [RFC v5 16/26] powerpc: Implement nvram sync ioctl Finn Thain
2015-07-25 7:46 ` Finn Thain [this message]
2015-07-25 7:46 ` [RFC v5 18/26] powerpc, fbdev: Use arch_nvram_ops methods instead of nvram_read_byte() and nvram_write_byte() Finn Thain
2015-07-25 7:46 ` [RFC v5 19/26] nvram: Drop nvram_* symbol exports and prototypes Finn Thain
2015-07-25 7:46 ` [RFC v5 20/26] powerpc: Remove CONFIG_GENERIC_NVRAM and adopt CONFIG_HAVE_ARCH_NVRAM_OPS Finn Thain
2015-07-25 7:46 ` [RFC v5 21/26] char/generic_nvram: Remove as unused Finn Thain
2015-07-25 7:46 ` [RFC v5 22/26] powerpc: Adopt nvram module for PPC64 Finn Thain
2015-07-25 7:46 ` [RFC v5 23/26] m68k/mac: Adopt naming and calling conventions for PRAM routines Finn Thain
2015-07-25 7:46 ` [RFC v5 24/26] m68k/mac: Use macros for RTC accesses not magic numbers Finn Thain
2015-07-25 7:46 ` [RFC v5 25/26] m68k/mac: Fix PRAM accessors Finn Thain
2015-07-25 7:46 ` [RFC v5 26/26] m68k: Dispatch nvram_ops calls to Atari or Mac functions Finn Thain
2015-08-16 9:15 ` [RFC v5 00/26] Re-use nvram module Geert Uytterhoeven
2015-08-17 8:04 ` Finn Thain
2015-08-17 8:20 ` Geert Uytterhoeven
2015-08-17 8:48 ` Finn Thain
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=20150725074603.673303850@telegraphics.com.au \
--to=fthain@telegraphics.com.au \
--cc=linux-fbdev@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-m68k@vger.kernel.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=plagnioj@jcrosoft.com \
--cc=tomi.valkeinen@ti.com \
/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