Menu
▾
▴
linux-fbdev-devel — linux-fbdev mailing list for project developers
You can subscribe to this list here.
| 2001 |
Jan
|
Feb
|
Mar
(1) |
Apr
(104) |
May
(81) |
Jun
(248) |
Jul
(133) |
Aug
(33) |
Sep
(53) |
Oct
(82) |
Nov
(166) |
Dec
(71) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2002 |
Jan
(121) |
Feb
(42) |
Mar
(39) |
Apr
(84) |
May
(87) |
Jun
(58) |
Jul
(97) |
Aug
(130) |
Sep
(32) |
Oct
(139) |
Nov
(108) |
Dec
(216) |
| 2003 |
Jan
(299) |
Feb
(136) |
Mar
(392) |
Apr
(141) |
May
(137) |
Jun
(107) |
Jul
(94) |
Aug
(262) |
Sep
(300) |
Oct
(216) |
Nov
(72) |
Dec
(94) |
| 2004 |
Jan
(174) |
Feb
(192) |
Mar
(215) |
Apr
(314) |
May
(319) |
Jun
(293) |
Jul
(205) |
Aug
(161) |
Sep
(192) |
Oct
(226) |
Nov
(308) |
Dec
(89) |
| 2005 |
Jan
(127) |
Feb
(269) |
Mar
(588) |
Apr
(106) |
May
(77) |
Jun
(77) |
Jul
(161) |
Aug
(239) |
Sep
(86) |
Oct
(112) |
Nov
(153) |
Dec
(145) |
| 2006 |
Jan
(87) |
Feb
(57) |
Mar
(129) |
Apr
(109) |
May
(102) |
Jun
(232) |
Jul
(97) |
Aug
(69) |
Sep
(67) |
Oct
(69) |
Nov
(214) |
Dec
(82) |
| 2007 |
Jan
(133) |
Feb
(307) |
Mar
(121) |
Apr
(171) |
May
(229) |
Jun
(156) |
Jul
(185) |
Aug
(160) |
Sep
(122) |
Oct
(130) |
Nov
(78) |
Dec
(27) |
| 2008 |
Jan
(105) |
Feb
(137) |
Mar
(146) |
Apr
(148) |
May
(239) |
Jun
(208) |
Jul
(157) |
Aug
(244) |
Sep
(119) |
Oct
(125) |
Nov
(189) |
Dec
(225) |
| 2009 |
Jan
(157) |
Feb
(139) |
Mar
(106) |
Apr
(130) |
May
(246) |
Jun
(189) |
Jul
(128) |
Aug
(127) |
Sep
(88) |
Oct
(86) |
Nov
(216) |
Dec
(9) |
| 2010 |
Jan
(5) |
Feb
|
Mar
(11) |
Apr
(31) |
May
(3) |
Jun
|
Jul
(7) |
Aug
|
Sep
(1) |
Oct
|
Nov
(1) |
Dec
|
| 2012 |
Jan
|
Feb
|
Mar
(3) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2013 |
Jan
(1) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Avi K. <av...@re...> - 2009-11-03 15:57:53
|
On 11/03/2009 05:14 PM, Anthony Liguori wrote: > Avi Kivity wrote: >> On 11/03/2009 10:26 AM, Alexander Graf wrote: >>> Exactly. In fact, I'm even scared to reboot mine because I might end >>> up in a 3270 terminal. The whole text only crap keeps people from >>> using this platform! And that's what I want to change here. >> >> Ok. I oppose paravirtualization for its own sake and only support it >> if there's no other way to get performance. In this case it buys us >> basic functionality which is surprisingly missing on native, that's >> arguably even more important. > > There is no "native" on s390. Everything is "paravirtual". I meant native as in "what they usually do without our stuff". -- error compiling committee.c: too many arguments to function |
|
From: Anthony L. <an...@co...> - 2009-11-03 15:45:39
|
Avi Kivity wrote: > On 11/03/2009 10:26 AM, Alexander Graf wrote: >> Exactly. In fact, I'm even scared to reboot mine because I might end >> up in a 3270 terminal. The whole text only crap keeps people from >> using this platform! And that's what I want to change here. > > Ok. I oppose paravirtualization for its own sake and only support it > if there's no other way to get performance. In this case it buys us > basic functionality which is surprisingly missing on native, that's > arguably even more important. There is no "native" on s390. Everything is "paravirtual". Regards, Anthony Liguori |
|
From: Clemens L. <cl...@la...> - 2009-11-03 15:43:08
|
Without an allocated colormap, FBIOGETCMAP fails. This would make
programs restore an all-black colormap ("links -g") or fail to work
altogether ("mplayer -vo fbdev2").
Signed-off-by: Clemens Ladisch <cl...@la...>
---
v2: implemented suggestions by James Simmons
drivers/gpu/drm/drm_fb_helper.c | 4 ++++
1 file changed, 4 insertions(+)
--- linux-2.6/drivers/gpu/drm/drm_fb_helper.c
+++ linux-2.6/drivers/gpu/drm/drm_fb_helper.c
@@ -905,6 +905,9 @@ int drm_fb_helper_single_fb_probe(struct
if (new_fb) {
info->var.pixclock = 0;
+ ret = fb_alloc_cmap(&info->cmap, crtc->gamma_size, 0);
+ if (ret)
+ return ret;
if (register_framebuffer(info) < 0)
return -EINVAL;
} else {
@@ -936,6 +939,7 @@ void drm_fb_helper_free(struct drm_fb_he
unregister_sysrq_key('v', &sysrq_drm_fb_helper_restore_op);
}
drm_fb_helper_crtc_free(helper);
+ fb_dealloc_cmap(&helper->fb->fbdev->cmap);
}
EXPORT_SYMBOL(drm_fb_helper_free);
|
|
From: Ondrej Z. <san...@cr...> - 2009-11-03 15:28:24
|
On Tue, Nov 03, 2009 at 11:38:18AM +0200, Avi Kivity wrote: > On 11/03/2009 01:25 PM, Vincent Hanquez wrote: > > not sure if i'm missing the point here, but couldn't it be hypothetically > > extended to stuff 3d (or video& more 2d accel ?) commands too ? I can't > > imagine the cirrus or stdvga driver be able to do that ever ;) > > > > cirrus has pretty good 2d acceleration. 3D is a mega-project though. Cirrus has no blending/compositing hardware support. Paravirtualized graphics can easily support full XRender-style 2D acceleration. -- Elen sila lumenn' omentielvo Ondrej 'SanTiago' Zajicek (email: san...@cr...) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) "To err is human -- to blame it on a computer is even more so." |
|
From: Finn T. <ft...@te...> - 2009-11-03 14:04:53
|
Add the missing mac video modes for the Portrait and 12" RGB displays. The
specs come from the Mac LC III developer note.
Signed-off-by: Finn Thain <ft...@te...>
---
drivers/video/macmodes.c | 52 +++++++++++++++++++++++++----------------------
1 file changed, 28 insertions(+), 24 deletions(-)
Index: linux-2.6.31/drivers/video/macmodes.c
===================================================================
--- linux-2.6.31.orig/drivers/video/macmodes.c 2009-11-03 03:23:43.000000000 +1100
+++ linux-2.6.31/drivers/video/macmodes.c 2009-11-03 03:23:44.000000000 +1100
@@ -33,6 +33,10 @@
static const struct fb_videomode mac_modedb[] = {
{
+ /* 512x384, 60Hz, Non-Interlaced (15.67 MHz dot clock) */
+ "mac2", 60, 512, 384, 63828, 80, 16, 19, 1, 32, 3,
+ 0, FB_VMODE_NONINTERLACED
+ }, {
/* 640x480, 60 Hz, Non-Interlaced (25.175 MHz dotclock) */
"mac5", 60, 640, 480, 39722, 32, 32, 33, 10, 96, 2,
0, FB_VMODE_NONINTERLACED
@@ -41,6 +45,10 @@ static const struct fb_videomode mac_mod
"mac6", 67, 640, 480, 33334, 80, 80, 39, 3, 64, 3,
0, FB_VMODE_NONINTERLACED
}, {
+ /* 640x870, 75Hz (portrait), Non-Interlaced (57.28 MHz dot clock) */
+ "mac7", 75, 640, 870, 17457, 80, 32, 42, 3, 80, 3,
+ 0, FB_VMODE_NONINTERLACED
+ }, {
/* 800x600, 56 Hz, Non-Interlaced (36.00 MHz dotclock) */
"mac9", 56, 800, 600, 27778, 112, 40, 22, 1, 72, 2,
FB_SYNC_HOR_HIGH_ACT|FB_SYNC_VERT_HIGH_ACT, FB_VMODE_NONINTERLACED
@@ -105,10 +113,6 @@ static const struct fb_videomode mac_mod
"mac1", 60, 512, 384, pixclock, left, right, upper, lower, hslen, vslen,
sync, FB_VMODE_INTERLACED
}, {
- /* VMODE_512_384_60: 512x384, 60Hz, Non-Interlaced */
- "mac2", 60, 512, 384, pixclock, left, right, upper, lower, hslen, vslen,
- sync, FB_VMODE_NONINTERLACED
- }, {
/* VMODE_640_480_50I: 640x480, 50Hz, Interlaced (PAL) */
"mac3", 50, 640, 480, pixclock, left, right, upper, lower, hslen, vslen,
sync, FB_VMODE_INTERLACED
@@ -117,10 +121,6 @@ static const struct fb_videomode mac_mod
"mac4", 60, 640, 480, pixclock, left, right, upper, lower, hslen, vslen,
sync, FB_VMODE_INTERLACED
}, {
- /* VMODE_640_870_75P: 640x870, 75Hz (portrait), Non-Interlaced */
- "mac7", 75, 640, 870, pixclock, left, right, upper, lower, hslen, vslen,
- sync, FB_VMODE_NONINTERLACED
- }, {
/* VMODE_768_576_50I: 768x576, 50Hz (PAL full frame), Interlaced */
"mac8", 50, 768, 576, pixclock, left, right, upper, lower, hslen, vslen,
sync, FB_VMODE_INTERLACED
@@ -141,31 +141,35 @@ static const struct mode_map {
int vmode;
const struct fb_videomode *mode;
} mac_modes[] = {
+ /* 512x384 */
+ { VMODE_512_384_60, &mac_modedb[0] },
/* 640x480 */
- { VMODE_640_480_60, &mac_modedb[0] },
- { VMODE_640_480_67, &mac_modedb[1] },
+ { VMODE_640_480_60, &mac_modedb[1] },
+ { VMODE_640_480_67, &mac_modedb[2] },
+ /* 640x870 */
+ { VMODE_640_870_75P, &mac_modedb[3] },
/* 800x600 */
- { VMODE_800_600_56, &mac_modedb[2] },
- { VMODE_800_600_60, &mac_modedb[3] },
- { VMODE_800_600_75, &mac_modedb[5] },
- { VMODE_800_600_72, &mac_modedb[4] },
+ { VMODE_800_600_56, &mac_modedb[4] },
+ { VMODE_800_600_60, &mac_modedb[5] },
+ { VMODE_800_600_75, &mac_modedb[7] },
+ { VMODE_800_600_72, &mac_modedb[6] },
/* 832x624 */
- { VMODE_832_624_75, &mac_modedb[6] },
+ { VMODE_832_624_75, &mac_modedb[8] },
/* 1024x768 */
- { VMODE_1024_768_60, &mac_modedb[7] },
- { VMODE_1024_768_70, &mac_modedb[8] },
- { VMODE_1024_768_75V, &mac_modedb[9] },
- { VMODE_1024_768_75, &mac_modedb[10] },
+ { VMODE_1024_768_60, &mac_modedb[9] },
+ { VMODE_1024_768_70, &mac_modedb[10] },
+ { VMODE_1024_768_75V, &mac_modedb[11] },
+ { VMODE_1024_768_75, &mac_modedb[12] },
/* 1152x768 */
- { VMODE_1152_768_60, &mac_modedb[14] },
+ { VMODE_1152_768_60, &mac_modedb[16] },
/* 1152x870 */
- { VMODE_1152_870_75, &mac_modedb[11] },
+ { VMODE_1152_870_75, &mac_modedb[13] },
/* 1280x960 */
- { VMODE_1280_960_75, &mac_modedb[12] },
+ { VMODE_1280_960_75, &mac_modedb[14] },
/* 1280x1024 */
- { VMODE_1280_1024_75, &mac_modedb[13] },
+ { VMODE_1280_1024_75, &mac_modedb[15] },
/* 1600x1024 */
- { VMODE_1600_1024_60, &mac_modedb[15] },
+ { VMODE_1600_1024_60, &mac_modedb[17] },
{ -1, NULL }
};
|
|
From: Finn T. <ft...@te...> - 2009-11-03 14:04:46
|
Cleanup whitespace and code style. Remove unused #includes and prototypes. Remove obsolete, redundant or misleading comments. Remove dead code and redundant initialisers. Signed-off-by: Finn Thain <ft...@te...> --- drivers/video/macfb.c | 586 +++++++++++++++++++++++++------------------------- 1 file changed, 300 insertions(+), 286 deletions(-) Index: linux-2.6.31/drivers/video/macfb.c =================================================================== --- linux-2.6.31.orig/drivers/video/macfb.c 2009-11-03 03:23:43.000000000 +1100 +++ linux-2.6.31/drivers/video/macfb.c 2009-11-03 03:23:44.000000000 +1100 @@ -1,29 +1,33 @@ -/* macfb.c: Generic framebuffer for Macs whose colourmaps/modes we - don't know how to set */ - -/* (c) 1999 David Huggins-Daines <dh...@de...> - - Primarily based on vesafb.c, by Gerd Knorr - (c) 1998 Gerd Knorr <kr...@cs...> - - Also uses information and code from: - - The original macfb.c from Linux/mac68k 2.0, by Alan Cox, Juergen - Mellinger, Mikael Forselius, Michael Schmitz, and others. - - valkyriefb.c, by Martin Costabel, Kevin Schoedel, Barry Nathan, Dan - Jacobowitz, Paul Mackerras, Fabio Riccardi, and Geert Uytterhoeven. - - This code is free software. You may copy, modify, and distribute - it subject to the terms and conditions of the GNU General Public - License, version 2, or any later version, at your convenience. */ +/* + * macfb.c: Generic framebuffer for Macs whose colourmaps/modes we + * don't know how to set. + * + * (c) 1999 David Huggins-Daines <dh...@de...> + * + * Primarily based on vesafb.c, by Gerd Knorr + * (c) 1998 Gerd Knorr <kr...@cs...> + * + * Also uses information and code from: + * + * The original macfb.c from Linux/mac68k 2.0, by Alan Cox, Juergen + * Mellinger, Mikael Forselius, Michael Schmitz, and others. + * + * valkyriefb.c, by Martin Costabel, Kevin Schoedel, Barry Nathan, Dan + * Jacobowitz, Paul Mackerras, Fabio Riccardi, and Geert Uytterhoeven. + * + * The VideoToolbox "Bugs" web page at + * http://rajsky.psych.nyu.edu/Tips/VideoBugs.html + * + * This code is free software. You may copy, modify, and distribute + * it subject to the terms and conditions of the GNU General Public + * License, version 2, or any later version, at your convenience. + */ #include <linux/module.h> #include <linux/kernel.h> #include <linux/errno.h> #include <linux/string.h> #include <linux/mm.h> -#include <linux/slab.h> #include <linux/delay.h> #include <linux/nubus.h> #include <linux/init.h> @@ -31,9 +35,6 @@ #include <asm/setup.h> #include <asm/bootinfo.h> -#include <asm/uaccess.h> -#include <asm/pgtable.h> -#include <asm/irq.h> #include <asm/macintosh.h> #include <asm/io.h> @@ -44,7 +45,7 @@ #define DAFB_BASE 0xf9800200 /* Address for the built-in Civic framebuffer in Quadra AVs */ -#define CIVIC_BASE 0x50f30800 /* Only tested on 660AV! */ +#define CIVIC_BASE 0x50f30800 /* GSC (Gray Scale Controller) base address */ #define GSC_BASE 0x50F20000 @@ -52,27 +53,9 @@ /* CSC (Color Screen Controller) base address */ #define CSC_BASE 0x50F20000 -static int (*macfb_setpalette) (unsigned int regno, unsigned int red, - unsigned int green, unsigned int blue, - struct fb_info *info) = NULL; -static int dafb_setpalette (unsigned int regno, unsigned int red, - unsigned int green, unsigned int blue, - struct fb_info *fb_info); -static int rbv_setpalette (unsigned int regno, unsigned int red, - unsigned int green, unsigned int blue, - struct fb_info *fb_info); -static int mdc_setpalette (unsigned int regno, unsigned int red, - unsigned int green, unsigned int blue, - struct fb_info *fb_info); -static int toby_setpalette (unsigned int regno, unsigned int red, - unsigned int green, unsigned int blue, - struct fb_info *fb_info); -static int civic_setpalette (unsigned int regno, unsigned int red, - unsigned int green, unsigned int blue, - struct fb_info *fb_info); -static int csc_setpalette (unsigned int regno, unsigned int red, - unsigned int green, unsigned int blue, - struct fb_info *fb_info); +static int (*macfb_setpalette)(unsigned int regno, unsigned int red, + unsigned int green, unsigned int blue, + struct fb_info *info); static struct { unsigned char addr; @@ -106,15 +89,15 @@ static struct { } __iomem *civic_cmap_regs; static struct { - char pad1[0x40]; - unsigned char clut_waddr; /* 0x40 */ - char pad2; - unsigned char clut_data; /* 0x42 */ - char pad3[0x3]; - unsigned char clut_raddr; /* 0x46 */ + char pad1[0x40]; + unsigned char clut_waddr; /* 0x40 */ + char pad2; + unsigned char clut_data; /* 0x42 */ + char pad3[0x3]; + unsigned char clut_raddr; /* 0x46 */ } __iomem *csc_cmap_regs; -/* We will leave these the way they are for the time being */ +/* The registers in these structs are in NuBus slot space */ struct mdc_cmap_regs { char pad1[0x200200]; unsigned char addr; @@ -135,13 +118,12 @@ struct jet_cmap_regs { unsigned char lut; }; -#define PIXEL_TO_MM(a) (((a)*10)/28) /* width in mm at 72 dpi */ +#define PIXEL_TO_MM(a) (((a)*10)/28) /* width in mm at 72 dpi */ -/* mode */ static int video_slot = 0; static struct fb_var_screeninfo macfb_defined = { - .bits_per_pixel = 8, + .bits_per_pixel = 8, .activate = FB_ACTIVATE_NOW, .width = -1, .height = -1, @@ -159,19 +141,19 @@ static struct fb_fix_screeninfo macfb_fi static struct fb_info fb_info; static u32 pseudo_palette[16]; -static int inverse = 0; -static int vidtest = 0; +static int inverse; +static int vidtest; -/* Unlike the Valkyrie, the DAFB cannot set individual colormap - registers. Therefore, we do what the MacOS driver does (no - kidding!) and simply set them one by one until we hit the one we - want. */ -static int dafb_setpalette (unsigned int regno, unsigned int red, - unsigned int green, unsigned int blue, - struct fb_info *info) +/* + * Unlike the Valkyrie, the DAFB cannot set individual colormap + * registers. Therefore, we do what the MacOS driver does (no + * kidding!) and simply set them one by one until we hit the one we + * want. + */ +static int dafb_setpalette(unsigned int regno, unsigned int red, + unsigned int green, unsigned int blue, + struct fb_info *info) { - /* FIXME: really, really need to use ioremap() here, - phys_to_virt() doesn't work anymore */ static int lastreg = -1; unsigned long flags; @@ -180,42 +162,47 @@ static int dafb_setpalette (unsigned int blue >>= 8; local_irq_save(flags); - - /* fbdev will set an entire colourmap, but X won't. Hopefully - this should accommodate both of them */ - if (regno != lastreg+1) { + + /* + * fbdev will set an entire colourmap, but X won't. Hopefully + * this should accommodate both of them + */ + if (regno != lastreg + 1) { int i; - + /* Stab in the dark trying to reset the CLUT pointer */ nubus_writel(0, &dafb_cmap_regs->reset); nop(); - + /* Loop until we get to the register we want */ for (i = 0; i < regno; i++) { - nubus_writeb(info->cmap.red[i] >> 8, &dafb_cmap_regs->lut); + nubus_writeb(info->cmap.red[i] >> 8, + &dafb_cmap_regs->lut); nop(); - nubus_writeb(info->cmap.green[i] >> 8, &dafb_cmap_regs->lut); + nubus_writeb(info->cmap.green[i] >> 8, + &dafb_cmap_regs->lut); nop(); - nubus_writeb(info->cmap.blue[i] >> 8, &dafb_cmap_regs->lut); + nubus_writeb(info->cmap.blue[i] >> 8, + &dafb_cmap_regs->lut); nop(); } } - + nubus_writeb(red, &dafb_cmap_regs->lut); nop(); nubus_writeb(green, &dafb_cmap_regs->lut); nop(); nubus_writeb(blue, &dafb_cmap_regs->lut); - + local_irq_restore(flags); lastreg = regno; return 0; } /* V8 and Brazil seem to use the same DAC. Sonora does as well. */ -static int v8_brazil_setpalette (unsigned int regno, unsigned int red, - unsigned int green, unsigned int blue, - struct fb_info *info) +static int v8_brazil_setpalette(unsigned int regno, unsigned int red, + unsigned int green, unsigned int blue, + struct fb_info *info) { unsigned int bpp = info->var.bits_per_pixel; unsigned char _red =red>>8; @@ -224,33 +211,35 @@ static int v8_brazil_setpalette (unsigne unsigned char _regno; unsigned long flags; - if (bpp > 8) return 1; /* failsafe */ + if (bpp > 8) + return 1; /* failsafe */ local_irq_save(flags); /* On these chips, the CLUT register numbers are spread out - across the register space. Thus: - - In 8bpp, all regnos are valid. - - In 4bpp, the regnos are 0x0f, 0x1f, 0x2f, etc, etc - - In 2bpp, the regnos are 0x3f, 0x7f, 0xbf, 0xff */ - _regno = (regno << (8 - bpp)) | (0xFF >> bpp); - nubus_writeb(_regno, &v8_brazil_cmap_regs->addr); nop(); + * across the register space. Thus: + * In 8bpp, all regnos are valid. + * In 4bpp, the regnos are 0x0f, 0x1f, 0x2f, etc, etc + * In 2bpp, the regnos are 0x3f, 0x7f, 0xbf, 0xff + */ + _regno = (regno << (8 - bpp)) | (0xFF >> bpp); + nubus_writeb(_regno, &v8_brazil_cmap_regs->addr); + nop(); /* send one color channel at a time */ - nubus_writeb(_red, &v8_brazil_cmap_regs->lut); nop(); - nubus_writeb(_green, &v8_brazil_cmap_regs->lut); nop(); + nubus_writeb(_red, &v8_brazil_cmap_regs->lut); + nop(); + nubus_writeb(_green, &v8_brazil_cmap_regs->lut); + nop(); nubus_writeb(_blue, &v8_brazil_cmap_regs->lut); - local_irq_restore(flags); + local_irq_restore(flags); return 0; } -static int rbv_setpalette (unsigned int regno, unsigned int red, - unsigned int green, unsigned int blue, - struct fb_info *info) +static int rbv_setpalette(unsigned int regno, unsigned int red, + unsigned int green, unsigned int blue, + struct fb_info *info) { /* use MSBs */ unsigned char _red =red>>8; @@ -259,10 +248,11 @@ static int rbv_setpalette (unsigned int unsigned char _regno; unsigned long flags; - if (info->var.bits_per_pixel > 8) return 1; /* failsafe */ + if (info->var.bits_per_pixel > 8) + return 1; /* failsafe */ local_irq_save(flags); - + /* From the VideoToolbox driver. Seems to be saying that * regno #254 and #255 are the important ones for 1-bit color, * regno #252-255 are the important ones for 2-bit color, etc. @@ -270,24 +260,28 @@ static int rbv_setpalette (unsigned int _regno = regno + (256-(1 << info->var.bits_per_pixel)); /* reset clut? (VideoToolbox sez "not necessary") */ - nubus_writeb(0xFF, &rbv_cmap_regs->cntl); nop(); - + nubus_writeb(0xFF, &rbv_cmap_regs->cntl); + nop(); + /* tell clut which address to use. */ - nubus_writeb(_regno, &rbv_cmap_regs->addr); nop(); - + nubus_writeb(_regno, &rbv_cmap_regs->addr); + nop(); + /* send one color channel at a time. */ - nubus_writeb(_red, &rbv_cmap_regs->lut); nop(); - nubus_writeb(_green, &rbv_cmap_regs->lut); nop(); - nubus_writeb(_blue, &rbv_cmap_regs->lut); - - local_irq_restore(flags); /* done. */ + nubus_writeb(_red, &rbv_cmap_regs->lut); + nop(); + nubus_writeb(_green, &rbv_cmap_regs->lut); + nop(); + nubus_writeb(_blue, &rbv_cmap_regs->lut); + + local_irq_restore(flags); return 0; } -/* Macintosh Display Card (8x24) */ +/* Macintosh Display Card (8*24) */ static int mdc_setpalette(unsigned int regno, unsigned int red, - unsigned int green, unsigned int blue, - struct fb_info *info) + unsigned int green, unsigned int blue, + struct fb_info *info) { volatile struct mdc_cmap_regs *cmap_regs = nubus_slot_addr(video_slot); @@ -299,11 +293,14 @@ static int mdc_setpalette(unsigned int r unsigned long flags; local_irq_save(flags); - + /* the nop's are there to order writes. */ - nubus_writeb(_regno, &cmap_regs->addr); nop(); - nubus_writeb(_red, &cmap_regs->lut); nop(); - nubus_writeb(_green, &cmap_regs->lut); nop(); + nubus_writeb(_regno, &cmap_regs->addr); + nop(); + nubus_writeb(_red, &cmap_regs->lut); + nop(); + nubus_writeb(_green, &cmap_regs->lut); + nop(); nubus_writeb(_blue, &cmap_regs->lut); local_irq_restore(flags); @@ -312,8 +309,8 @@ static int mdc_setpalette(unsigned int r /* Toby frame buffer */ static int toby_setpalette(unsigned int regno, unsigned int red, - unsigned int green, unsigned int blue, - struct fb_info *info) + unsigned int green, unsigned int blue, + struct fb_info *info) { volatile struct toby_cmap_regs *cmap_regs = nubus_slot_addr(video_slot); @@ -326,10 +323,13 @@ static int toby_setpalette(unsigned int unsigned long flags; local_irq_save(flags); - - nubus_writeb(_regno, &cmap_regs->addr); nop(); - nubus_writeb(_red, &cmap_regs->lut); nop(); - nubus_writeb(_green, &cmap_regs->lut); nop(); + + nubus_writeb(_regno, &cmap_regs->addr); + nop(); + nubus_writeb(_red, &cmap_regs->lut); + nop(); + nubus_writeb(_green, &cmap_regs->lut); + nop(); nubus_writeb(_blue, &cmap_regs->lut); local_irq_restore(flags); @@ -338,8 +338,8 @@ static int toby_setpalette(unsigned int /* Jet frame buffer */ static int jet_setpalette(unsigned int regno, unsigned int red, - unsigned int green, unsigned int blue, - struct fb_info *info) + unsigned int green, unsigned int blue, + struct fb_info *info) { volatile struct jet_cmap_regs *cmap_regs = nubus_slot_addr(video_slot); @@ -350,10 +350,13 @@ static int jet_setpalette(unsigned int r unsigned long flags; local_irq_save(flags); - - nubus_writeb(regno, &cmap_regs->addr); nop(); - nubus_writeb(_red, &cmap_regs->lut); nop(); - nubus_writeb(_green, &cmap_regs->lut); nop(); + + nubus_writeb(regno, &cmap_regs->addr); + nop(); + nubus_writeb(_red, &cmap_regs->lut); + nop(); + nubus_writeb(_green, &cmap_regs->lut); + nop(); nubus_writeb(_blue, &cmap_regs->lut); local_irq_restore(flags); @@ -363,53 +366,33 @@ static int jet_setpalette(unsigned int r /* * Civic framebuffer -- Quadra AV built-in video. A chip * called Sebastian holds the actual color palettes, and - * apparently, there are two different banks of 512K RAM + * apparently, there are two different banks of 512K RAM * which can act as separate framebuffers for doing video * input and viewing the screen at the same time! The 840AV - * Can add another 1MB RAM to give the two framebuffers + * Can add another 1MB RAM to give the two framebuffers * 1MB RAM apiece. * * FIXME: this doesn't seem to work anymore. */ -static int civic_setpalette (unsigned int regno, unsigned int red, - unsigned int green, unsigned int blue, - struct fb_info *info) +static int civic_setpalette(unsigned int regno, unsigned int red, + unsigned int green, unsigned int blue, + struct fb_info *info) { - static int lastreg = -1; unsigned long flags; int clut_status; - if (info->var.bits_per_pixel > 8) return 1; /* failsafe */ + if (info->var.bits_per_pixel > 8) + return 1; /* failsafe */ red >>= 8; green >>= 8; blue >>= 8; local_irq_save(flags); - - /* - * Set the register address - */ - nubus_writeb(regno, &civic_cmap_regs->addr); nop(); - /* - * Wait for VBL interrupt here; - * They're usually not enabled from Penguin, so we won't check - */ -#if 0 - { -#define CIVIC_VBL_OFFSET 0x120 - volatile unsigned long *vbl = nubus_readl(civic_cmap_regs->vbl_addr + CIVIC_VBL_OFFSET); - /* do interrupt setup stuff here? */ - *vbl = 0L; nop(); /* clear */ - *vbl = 1L; nop(); /* set */ - while (*vbl != 0L) /* wait for next vbl */ - { - usleep(10); /* needed? */ - } - /* do interrupt shutdown stuff here? */ - } -#endif + /* Set the register address */ + nubus_writeb(regno, &civic_cmap_regs->addr); + nop(); /* * Grab a status word and do some checking; @@ -422,39 +405,52 @@ static int civic_setpalette (unsigned in #if 0 if ((clut_status & 0x000D) != 0) { - nubus_writeb(0x00, &civic_cmap_regs->lut); nop(); - nubus_writeb(0x00, &civic_cmap_regs->lut); nop(); + nubus_writeb(0x00, &civic_cmap_regs->lut); + nop(); + nubus_writeb(0x00, &civic_cmap_regs->lut); + nop(); } #endif - nubus_writeb( red, &civic_cmap_regs->lut); nop(); - nubus_writeb(green, &civic_cmap_regs->lut); nop(); - nubus_writeb( blue, &civic_cmap_regs->lut); nop(); - nubus_writeb( 0x00, &civic_cmap_regs->lut); nop(); + nubus_writeb(red, &civic_cmap_regs->lut); + nop(); + nubus_writeb(green, &civic_cmap_regs->lut); + nop(); + nubus_writeb(blue, &civic_cmap_regs->lut); + nop(); + nubus_writeb(0x00, &civic_cmap_regs->lut); } else { unsigned char junk; - junk = nubus_readb(&civic_cmap_regs->lut); nop(); - junk = nubus_readb(&civic_cmap_regs->lut); nop(); - junk = nubus_readb(&civic_cmap_regs->lut); nop(); - junk = nubus_readb(&civic_cmap_regs->lut); nop(); + junk = nubus_readb(&civic_cmap_regs->lut); + nop(); + junk = nubus_readb(&civic_cmap_regs->lut); + nop(); + junk = nubus_readb(&civic_cmap_regs->lut); + nop(); + junk = nubus_readb(&civic_cmap_regs->lut); + nop(); if ((clut_status & 0x000D) != 0) { - nubus_writeb(0x00, &civic_cmap_regs->lut); nop(); - nubus_writeb(0x00, &civic_cmap_regs->lut); nop(); + nubus_writeb(0x00, &civic_cmap_regs->lut); + nop(); + nubus_writeb(0x00, &civic_cmap_regs->lut); + nop(); } - nubus_writeb( red, &civic_cmap_regs->lut); nop(); - nubus_writeb(green, &civic_cmap_regs->lut); nop(); - nubus_writeb( blue, &civic_cmap_regs->lut); nop(); - nubus_writeb( junk, &civic_cmap_regs->lut); nop(); + nubus_writeb(red, &civic_cmap_regs->lut); + nop(); + nubus_writeb(green, &civic_cmap_regs->lut); + nop(); + nubus_writeb(blue, &civic_cmap_regs->lut); + nop(); + nubus_writeb(junk, &civic_cmap_regs->lut); } local_irq_restore(flags); - lastreg = regno; return 0; } @@ -463,10 +459,9 @@ static int civic_setpalette (unsigned in * (and the 5300 too, but that's a PowerMac). This function * brought to you in part by the ECSC driver for MkLinux. */ - -static int csc_setpalette (unsigned int regno, unsigned int red, - unsigned int green, unsigned int blue, - struct fb_info *info) +static int csc_setpalette(unsigned int regno, unsigned int red, + unsigned int green, unsigned int blue, + struct fb_info *info) { mdelay(1); nubus_writeb(regno, &csc_cmap_regs->clut_waddr); @@ -477,14 +472,14 @@ static int csc_setpalette (unsigned int } static int macfb_setcolreg(unsigned regno, unsigned red, unsigned green, - unsigned blue, unsigned transp, - struct fb_info *fb_info) + unsigned blue, unsigned transp, + struct fb_info *fb_info) { /* - * Set a single color register. The values supplied are - * already rounded down to the hardware's capabilities - * (according to the entries in the `var' structure). Return - * != 0 for invalid regno. + * Set a single color register. The values supplied are + * already rounded down to the hardware's capabilities + * (according to the entries in the `var' structure). + * Return non-zero for invalid regno. */ if (regno >= fb_info->cmap.len) @@ -518,28 +513,22 @@ static int macfb_setcolreg(unsigned regn } else { /* 0:5:6:5 */ ((u32*) (fb_info->pseudo_palette))[regno] = - ((red & 0xf800) ) | + ((red & 0xf800) >> 0) | ((green & 0xfc00) >> 5) | ((blue & 0xf800) >> 11); } break; - /* I'm pretty sure that one or the other of these - doesn't exist on 68k Macs */ + /* + * 24-bit colour almost doesn't exist on 68k Macs -- + * http://support.apple.com/kb/TA28634 (Old Article: 10992) + */ case 24: - red >>= 8; - green >>= 8; - blue >>= 8; - ((u32 *)(fb_info->pseudo_palette))[regno] = - (red << fb_info->var.red.offset) | - (green << fb_info->var.green.offset) | - (blue << fb_info->var.blue.offset); - break; case 32: red >>= 8; green >>= 8; blue >>= 8; ((u32 *)(fb_info->pseudo_palette))[regno] = - (red << fb_info->var.red.offset) | + (red << fb_info->var.red.offset) | (green << fb_info->var.green.offset) | (blue << fb_info->var.blue.offset); break; @@ -560,18 +549,19 @@ static struct fb_ops macfb_ops = { static void __init macfb_setup(char *options) { char *this_opt; - + if (!options || !*options) return; - + while ((this_opt = strsep(&options, ",")) != NULL) { - if (!*this_opt) continue; - - if (! strcmp(this_opt, "inverse")) - inverse=1; - /* This means "turn on experimental CLUT code" */ - else if (!strcmp(this_opt, "vidtest")) - vidtest=1; + if (!*this_opt) + continue; + + if (!strcmp(this_opt, "inverse")) + inverse = 1; + else + if (!strcmp(this_opt, "vidtest")) + vidtest = 1; /* enable experimental CLUT code */ } } @@ -607,48 +597,52 @@ static int __init macfb_init(void) mac_bi_data.id == MAC_MODEL_P588) return -ENODEV; /* See valkyriefb.c */ - /* There can only be one internal video controller anyway so - we're not too worried about this */ macfb_defined.xres = mac_bi_data.dimensions & 0xFFFF; macfb_defined.yres = mac_bi_data.dimensions >> 16; macfb_defined.bits_per_pixel = mac_bi_data.videodepth; + macfb_fix.line_length = mac_bi_data.videorow; - macfb_fix.smem_len = macfb_fix.line_length * macfb_defined.yres; + macfb_fix.smem_len = macfb_fix.line_length * macfb_defined.yres; /* Note: physical address (since 2.1.127) */ - macfb_fix.smem_start = mac_bi_data.videoaddr; - /* This is actually redundant with the initial mappings. - However, there are some non-obvious aspects to the way - those mappings are set up, so this is in fact the safest - way to ensure that this driver will work on every possible - Mac */ + macfb_fix.smem_start = mac_bi_data.videoaddr; + + /* + * This is actually redundant with the initial mappings. + * However, there are some non-obvious aspects to the way + * those mappings are set up, so this is in fact the safest + * way to ensure that this driver will work on every possible Mac + */ fb_info.screen_base = ioremap(mac_bi_data.videoaddr, macfb_fix.smem_len); printk("macfb: framebuffer at 0x%08lx, mapped to 0x%p, size %dk\n", - macfb_fix.smem_start, fb_info.screen_base, macfb_fix.smem_len/1024); + macfb_fix.smem_start, fb_info.screen_base, + macfb_fix.smem_len / 1024); printk("macfb: mode is %dx%dx%d, linelength=%d\n", - macfb_defined.xres, macfb_defined.yres, macfb_defined.bits_per_pixel, macfb_fix.line_length); - + macfb_defined.xres, macfb_defined.yres, + macfb_defined.bits_per_pixel, macfb_fix.line_length); + /* - * Fill in the available video resolution + * Fill in the available video resolution */ - - macfb_defined.xres_virtual = macfb_defined.xres; - macfb_defined.yres_virtual = macfb_defined.yres; - macfb_defined.height = PIXEL_TO_MM(macfb_defined.yres); - macfb_defined.width = PIXEL_TO_MM(macfb_defined.xres); + macfb_defined.xres_virtual = macfb_defined.xres; + macfb_defined.yres_virtual = macfb_defined.yres; + macfb_defined.height = PIXEL_TO_MM(macfb_defined.yres); + macfb_defined.width = PIXEL_TO_MM(macfb_defined.xres); printk("macfb: scrolling: redraw\n"); - macfb_defined.yres_virtual = macfb_defined.yres; /* some dummy values for timing to make fbset happy */ - macfb_defined.pixclock = 10000000 / macfb_defined.xres * 1000 / macfb_defined.yres; + macfb_defined.pixclock = 10000000 / macfb_defined.xres * + 1000 / macfb_defined.yres; macfb_defined.left_margin = (macfb_defined.xres / 8) & 0xf8; macfb_defined.hsync_len = (macfb_defined.xres / 8) & 0xf8; switch (macfb_defined.bits_per_pixel) { case 1: - /* XXX: I think this will catch any program that tries - to do FBIO_PUTCMAP when the visual is monochrome */ + /* + * XXX: I think this will catch any program that tries + * to do FBIO_PUTCMAP when the visual is monochrome. + */ macfb_defined.red.length = macfb_defined.bits_per_pixel; macfb_defined.green.length = macfb_defined.bits_per_pixel; macfb_defined.blue.length = macfb_defined.bits_per_pixel; @@ -676,14 +670,14 @@ static int __init macfb_init(void) printk("macfb: directcolor: " "size=1:5:5:5, shift=15:10:5:0\n"); video_cmap_len = 16; - /* Should actually be FB_VISUAL_DIRECTCOLOR, but this - works too */ + /* + * Should actually be FB_VISUAL_DIRECTCOLOR, but this + * works too + */ macfb_fix.visual = FB_VISUAL_TRUECOLOR; break; case 24: case 32: - /* XXX: have to test these... can any 68k Macs - actually do this on internal video? */ macfb_defined.red.offset = 16; macfb_defined.red.length = 8; macfb_defined.green.offset = 8; @@ -697,18 +691,19 @@ static int __init macfb_init(void) default: video_cmap_len = 0; macfb_fix.visual = FB_VISUAL_MONO01; - printk("macfb: unknown or unsupported bit depth: %d\n", macfb_defined.bits_per_pixel); + printk("macfb: unknown or unsupported bit depth: %d\n", + macfb_defined.bits_per_pixel); break; } - /* Hardware dependent stuff */ - /* We take a wild guess that if the video physical address is - * in nubus slot space, that the nubus card is driving video. - * Penguin really ought to tell us whether we are using internal - * video or not. + /* + * We take a wild guess that if the video physical address is + * in nubus slot space, that the nubus card is driving video. + * Penguin really ought to tell us whether we are using internal + * video or not. + * Hopefully we only find one of them. Otherwise our NuBus + * code is really broken :-) */ - /* Hopefully we only find one of them. Otherwise our NuBus - code is really broken :-) */ while ((ndev = nubus_find_type(NUBUS_CAT_DISPLAY, NUBUS_TYPE_VIDEO, ndev)) != NULL) @@ -736,7 +731,7 @@ static int __init macfb_init(void) strcpy(macfb_fix.id, "Jet"); macfb_setpalette = jet_setpalette; macfb_defined.activate = FB_ACTIVATE_NOW; - break; + break; default: strcpy(macfb_fix.id, "Generic NuBus"); break; @@ -744,20 +739,19 @@ static int __init macfb_init(void) } /* If it's not a NuBus card, it must be internal video */ - /* FIXME: this function is getting way too big. (this driver - is too...) */ if (!video_is_nubus) - switch( mac_bi_data.id ) - { - /* DAFB Quadras */ - /* Note: these first four have the v7 DAFB, which is - known to be rather unlike the ones used in the - other models */ + switch (mac_bi_data.id) { + /* + * DAFB Quadras + * Note: these first four have the v7 DAFB, which is + * known to be rather unlike the ones used in the + * other models + */ case MAC_MODEL_P475: case MAC_MODEL_P475F: case MAC_MODEL_P575: case MAC_MODEL_Q605: - + case MAC_MODEL_Q800: case MAC_MODEL_Q650: case MAC_MODEL_Q610: @@ -772,17 +766,21 @@ static int __init macfb_init(void) dafb_cmap_regs = ioremap(DAFB_BASE, 0x1000); break; - /* LC II uses the V8 framebuffer */ + /* + * LC II uses the V8 framebuffer + */ case MAC_MODEL_LCII: strcpy(macfb_fix.id, "V8"); macfb_setpalette = v8_brazil_setpalette; macfb_defined.activate = FB_ACTIVATE_NOW; v8_brazil_cmap_regs = ioremap(DAC_BASE, 0x1000); break; - - /* IIvi, IIvx use the "Brazil" framebuffer (which is - very much like the V8, it seems, and probably uses - the same DAC) */ + + /* + * IIvi, IIvx use the "Brazil" framebuffer (which is + * very much like the V8, it seems, and probably uses + * the same DAC) + */ case MAC_MODEL_IIVI: case MAC_MODEL_IIVX: case MAC_MODEL_P600: @@ -791,12 +789,14 @@ static int __init macfb_init(void) macfb_defined.activate = FB_ACTIVATE_NOW; v8_brazil_cmap_regs = ioremap(DAC_BASE, 0x1000); break; - - /* LC III (and friends) use the Sonora framebuffer */ - /* Incidentally this is also used in the non-AV models - of the x100 PowerMacs */ - /* These do in fact seem to use the same DAC interface - as the LC II. */ + + /* + * LC III (and friends) use the Sonora framebuffer + * Incidentally this is also used in the non-AV models + * of the x100 PowerMacs + * These do in fact seem to use the same DAC interface + * as the LC II. + */ case MAC_MODEL_LCIII: case MAC_MODEL_P520: case MAC_MODEL_P550: @@ -807,9 +807,11 @@ static int __init macfb_init(void) v8_brazil_cmap_regs = ioremap(DAC_BASE, 0x1000); break; - /* IIci and IIsi use the infamous RBV chip - (the IIsi is just a rebadged and crippled - IIci in a different case, BTW) */ + /* + * IIci and IIsi use the infamous RBV chip + * (the IIsi is just a rebadged and crippled + * IIci in a different case, BTW) + */ case MAC_MODEL_IICI: case MAC_MODEL_IISI: macfb_setpalette = rbv_setpalette; @@ -818,7 +820,9 @@ static int __init macfb_init(void) rbv_cmap_regs = ioremap(DAC_BASE, 0x1000); break; - /* AVs use the Civic framebuffer */ + /* + * AVs use the Civic framebuffer + */ case MAC_MODEL_Q840: case MAC_MODEL_C660: macfb_setpalette = civic_setpalette; @@ -828,15 +832,10 @@ static int __init macfb_init(void) break; - /* Write a setpalette function for your machine, then - you can add something similar here. These are - grouped by classes of video chipsets. Some of this - information is from the VideoToolbox "Bugs" web - page at - http://rajsky.psych.nyu.edu/Tips/VideoBugs.html */ - - /* Assorted weirdos */ - /* We think this may be like the LC II */ + /* + * Assorted weirdos + * We think this may be like the LC II + */ case MAC_MODEL_LC: if (vidtest) { macfb_setpalette = v8_brazil_setpalette; @@ -846,7 +845,10 @@ static int __init macfb_init(void) } strcpy(macfb_fix.id, "LC"); break; - /* We think this may be like the LC II */ + + /* + * We think this may be like the LC II + */ case MAC_MODEL_CCL: if (vidtest) { macfb_setpalette = v8_brazil_setpalette; @@ -857,23 +859,29 @@ static int __init macfb_init(void) strcpy(macfb_fix.id, "Color Classic"); break; - /* And we *do* mean "weirdos" */ + /* + * And we *do* mean "weirdos" + */ case MAC_MODEL_TV: strcpy(macfb_fix.id, "Mac TV"); break; - /* These don't have colour, so no need to worry */ + /* + * These don't have colour, so no need to worry + */ case MAC_MODEL_SE30: case MAC_MODEL_CLII: strcpy(macfb_fix.id, "Monochrome"); break; - /* Powerbooks are particularly difficult. Many of - them have separate framebuffers for external and - internal video, which is admittedly pretty cool, - but will be a bit of a headache to support here. - Also, many of them are grayscale, and we don't - really support that. */ + /* + * Powerbooks are particularly difficult. Many of + * them have separate framebuffers for external and + * internal video, which is admittedly pretty cool, + * but will be a bit of a headache to support here. + * Also, many of them are grayscale, and we don't + * really support that. + */ case MAC_MODEL_PB140: case MAC_MODEL_PB145: @@ -881,7 +889,9 @@ static int __init macfb_init(void) strcpy(macfb_fix.id, "DDC"); break; - /* Internal is GSC, External (if present) is ViSC */ + /* + * Internal is GSC, External (if present) is ViSC + */ case MAC_MODEL_PB150: /* no external video */ case MAC_MODEL_PB160: case MAC_MODEL_PB165: @@ -891,13 +901,17 @@ static int __init macfb_init(void) strcpy(macfb_fix.id, "GSC"); break; - /* Internal is TIM, External is ViSC */ + /* + * Internal is TIM, External is ViSC + */ case MAC_MODEL_PB165C: case MAC_MODEL_PB180C: strcpy(macfb_fix.id, "TIM"); break; - /* Internal is CSC, External is Keystone+Ariel. */ + /* + * Internal is CSC, External is Keystone+Ariel. + */ case MAC_MODEL_PB190: /* external video is optional */ case MAC_MODEL_PB520: case MAC_MODEL_PB250: @@ -909,7 +923,7 @@ static int __init macfb_init(void) strcpy(macfb_fix.id, "CSC"); csc_cmap_regs = ioremap(CSC_BASE, 0x1000); break; - + default: strcpy(macfb_fix.id, "Unknown"); break; @@ -924,7 +938,7 @@ static int __init macfb_init(void) err = fb_alloc_cmap(&fb_info.cmap, video_cmap_len, 0); if (err) goto fail_unmap; - + err = register_framebuffer(&fb_info); if (err) goto fail_dealloc; |
|
From: Finn T. <ft...@te...> - 2009-11-03 13:59:52
|
The valkyriefb driver assumes that this logic holds:
mac_vmode_to_var(X, cmode, &var);
mac_var_to_vmode(&var, &vmode, &cmode);
assert(vmode == X);
But it doesn't hold because mac_var_to_vmode() can return a mode with a
slower pixel clock, even when a match is available. So we end up with this
failure:
using video mode 11 and color mode 0.
valkyriefb: vmode 12 not valid.
valkyriefb: can't set default video mode
valkyriefb: vmode 12 not valid.
Rather than have mac_var_to_mode() return the first reasonable mode it
finds, have it return the mode that is closest to the requested one (or
the mode with the closest longer pixel clock period if there is no exact
match).
Signed-off-by: Finn Thain <ft...@te...>
---
drivers/video/macmodes.c | 40 +++++++++++++++++++++++++++++++---------
1 file changed, 31 insertions(+), 9 deletions(-)
Index: linux-2.6.31/drivers/video/macmodes.c
===================================================================
--- linux-2.6.31.orig/drivers/video/macmodes.c 2009-11-03 03:23:24.000000000 +1100
+++ linux-2.6.31/drivers/video/macmodes.c 2009-11-03 03:23:43.000000000 +1100
@@ -134,7 +134,7 @@ static const struct fb_videomode mac_mod
*
* These MUST be ordered in
* - increasing resolution
- * - decreasing refresh rate
+ * - decreasing pixel clock period
*/
static const struct mode_map {
@@ -142,20 +142,20 @@ static const struct mode_map {
const struct fb_videomode *mode;
} mac_modes[] = {
/* 640x480 */
- { VMODE_640_480_67, &mac_modedb[1] },
{ VMODE_640_480_60, &mac_modedb[0] },
+ { VMODE_640_480_67, &mac_modedb[1] },
/* 800x600 */
+ { VMODE_800_600_56, &mac_modedb[2] },
+ { VMODE_800_600_60, &mac_modedb[3] },
{ VMODE_800_600_75, &mac_modedb[5] },
{ VMODE_800_600_72, &mac_modedb[4] },
- { VMODE_800_600_60, &mac_modedb[3] },
- { VMODE_800_600_56, &mac_modedb[2] },
/* 832x624 */
{ VMODE_832_624_75, &mac_modedb[6] },
/* 1024x768 */
- { VMODE_1024_768_75, &mac_modedb[10] },
- { VMODE_1024_768_75V, &mac_modedb[9] },
- { VMODE_1024_768_70, &mac_modedb[8] },
{ VMODE_1024_768_60, &mac_modedb[7] },
+ { VMODE_1024_768_70, &mac_modedb[8] },
+ { VMODE_1024_768_75V, &mac_modedb[9] },
+ { VMODE_1024_768_75, &mac_modedb[10] },
/* 1152x768 */
{ VMODE_1152_768_60, &mac_modedb[14] },
/* 1152x870 */
@@ -299,7 +299,6 @@ EXPORT_SYMBOL(mac_vmode_to_var);
int mac_var_to_vmode(const struct fb_var_screeninfo *var, int *vmode,
int *cmode)
{
- const struct fb_videomode *mode = NULL;
const struct mode_map *map;
if (var->bits_per_pixel <= 8)
@@ -311,8 +310,13 @@ int mac_var_to_vmode(const struct fb_var
else
return -EINVAL;
+ /*
+ * Find the mac_mode with a matching resolution or failing that, the
+ * closest larger resolution. Skip modes with a shorter pixel clock period.
+ */
for (map = mac_modes; map->vmode != -1; map++) {
- mode = map->mode;
+ const struct fb_videomode *mode = map->mode;
+
if (var->xres > mode->xres || var->yres > mode->yres)
continue;
if (var->xres_virtual > mode->xres || var->yres_virtual > mode->yres)
@@ -322,6 +326,24 @@ int mac_var_to_vmode(const struct fb_var
if ((var->vmode & FB_VMODE_MASK) != mode->vmode)
continue;
*vmode = map->vmode;
+
+ /*
+ * Having found a good resolution, find the matching pixel clock
+ * or failing that, the closest longer pixel clock period.
+ */
+ map++;
+ while (map->vmode != -1) {
+ const struct fb_videomode *clk_mode = map->mode;
+
+ if (mode->xres != clk_mode->xres || mode->yres != clk_mode->yres)
+ break;
+ if (var->pixclock > mode->pixclock)
+ break;
+ if (mode->vmode != clk_mode->vmode)
+ continue;
+ *vmode = map->vmode;
+ map++;
+ }
return 0;
}
return -EINVAL;
|
|
From: Finn T. <ft...@te...> - 2009-11-03 13:59:47
|
Valkyriefb and macfb will adopt the same card if they get the chance, so
remove valkyrie support from macfb. Also fix the "valkyriefb: can't do
832x624x8" problem reported by Raylynn Knight some time ago, by adding
vmode 13 support for CONFIG_MAC. Also add vmode 11 since that works too.
Make use of the monitor sense lines on 68k Macs too. Also some cleanups.
Signed-off-by: Finn Thain <ft...@te...>
---
drivers/video/macfb.c | 53 +++------------------------------------------
drivers/video/valkyriefb.c | 6 ++---
drivers/video/valkyriefb.h | 31 ++++++++------------------
3 files changed, 17 insertions(+), 73 deletions(-)
Index: linux-2.6.31/drivers/video/macfb.c
===================================================================
--- linux-2.6.31.orig/drivers/video/macfb.c 2009-11-03 03:23:24.000000000 +1100
+++ linux-2.6.31/drivers/video/macfb.c 2009-11-03 03:23:43.000000000 +1100
@@ -55,9 +55,6 @@
static int (*macfb_setpalette) (unsigned int regno, unsigned int red,
unsigned int green, unsigned int blue,
struct fb_info *info) = NULL;
-static int valkyrie_setpalette (unsigned int regno, unsigned int red,
- unsigned int green, unsigned int blue,
- struct fb_info *info);
static int dafb_setpalette (unsigned int regno, unsigned int red,
unsigned int green, unsigned int blue,
struct fb_info *fb_info);
@@ -79,13 +76,6 @@ static int csc_setpalette (unsigned int
static struct {
unsigned char addr;
- /* Note: word-aligned */
- char pad[3];
- unsigned char lut;
-} __iomem *valkyrie_cmap_regs;
-
-static struct {
- unsigned char addr;
unsigned char lut;
} __iomem *v8_brazil_cmap_regs;
@@ -172,33 +162,6 @@ static u32 pseudo_palette[16];
static int inverse = 0;
static int vidtest = 0;
-static int valkyrie_setpalette (unsigned int regno, unsigned int red,
- unsigned int green, unsigned int blue,
- struct fb_info *info)
-{
- unsigned long flags;
-
- red >>= 8;
- green >>= 8;
- blue >>= 8;
-
- local_irq_save(flags);
-
- /* tell clut which address to fill */
- nubus_writeb(regno, &valkyrie_cmap_regs->addr);
- nop();
-
- /* send one color channel at a time */
- nubus_writeb(red, &valkyrie_cmap_regs->lut);
- nop();
- nubus_writeb(green, &valkyrie_cmap_regs->lut);
- nop();
- nubus_writeb(blue, &valkyrie_cmap_regs->lut);
-
- local_irq_restore(flags);
- return 0;
-}
-
/* Unlike the Valkyrie, the DAFB cannot set individual colormap
registers. Therefore, we do what the MacOS driver does (no
kidding!) and simply set them one by one until we hit the one we
@@ -614,8 +577,6 @@ static void __init macfb_setup(char *opt
static void __init iounmap_macfb(void)
{
- if (valkyrie_cmap_regs)
- iounmap(valkyrie_cmap_regs);
if (dafb_cmap_regs)
iounmap(dafb_cmap_regs);
if (v8_brazil_cmap_regs)
@@ -642,6 +603,10 @@ static int __init macfb_init(void)
if (!MACH_IS_MAC)
return -ENODEV;
+ if (mac_bi_data.id == MAC_MODEL_Q630 ||
+ mac_bi_data.id == MAC_MODEL_P588)
+ return -ENODEV; /* See valkyriefb.c */
+
/* There can only be one internal video controller anyway so
we're not too worried about this */
macfb_defined.xres = mac_bi_data.dimensions & 0xFFFF;
@@ -784,16 +749,6 @@ static int __init macfb_init(void)
if (!video_is_nubus)
switch( mac_bi_data.id )
{
- /* Valkyrie Quadras */
- case MAC_MODEL_Q630:
- /* I'm not sure about this one */
- case MAC_MODEL_P588:
- strcpy(macfb_fix.id, "Valkyrie");
- macfb_setpalette = valkyrie_setpalette;
- macfb_defined.activate = FB_ACTIVATE_NOW;
- valkyrie_cmap_regs = ioremap(DAC_BASE, 0x1000);
- break;
-
/* DAFB Quadras */
/* Note: these first four have the v7 DAFB, which is
known to be rather unlike the ones used in the
Index: linux-2.6.31/drivers/video/valkyriefb.c
===================================================================
--- linux-2.6.31.orig/drivers/video/valkyriefb.c 2009-11-03 03:23:24.000000000 +1100
+++ linux-2.6.31/drivers/video/valkyriefb.c 2009-11-03 03:23:43.000000000 +1100
@@ -69,7 +69,7 @@
#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_640_480_67;
+static int default_vmode = VMODE_CHOOSE;
static int default_cmode = CMODE_8;
#else
static int default_vmode = VMODE_NVRAM;
@@ -326,11 +326,11 @@ int __init valkyriefb_init(void)
#ifdef CONFIG_MAC
if (!MACH_IS_MAC)
- return 0;
+ return -ENODEV;
if (!(mac_bi_data.id == MAC_MODEL_Q630
/* I'm not sure about this one */
|| mac_bi_data.id == MAC_MODEL_P588))
- return 0;
+ return -ENODEV;
/* Hardcoded addresses... welcome to 68k Macintosh country :-) */
frame_buffer_phys = 0xf9000000;
Index: linux-2.6.31/drivers/video/valkyriefb.h
===================================================================
--- linux-2.6.31.orig/drivers/video/valkyriefb.h 2009-11-03 03:23:24.000000000 +1100
+++ linux-2.6.31/drivers/video/valkyriefb.h 2009-11-03 03:23:43.000000000 +1100
@@ -134,15 +134,7 @@ static struct valkyrie_regvals valkyrie_
{ 1024, 0 },
1024, 768
};
-
-/* Register values for 800x600, 72Hz mode (11) */
-static struct valkyrie_regvals valkyrie_reg_init_11 = {
- 13,
- { 17, 27, 3 }, /* pixel clock = 49.63MHz for V=71.66Hz */
- { 800, 0 },
- 800, 600
-};
-#endif /* CONFIG_MAC */
+#endif /* !defined CONFIG_MAC */
/* Register values for 832x624, 75Hz mode (13) */
static struct valkyrie_regvals valkyrie_reg_init_13 = {
@@ -152,6 +144,14 @@ static struct valkyrie_regvals valkyrie_
832, 624
};
+/* Register values for 800x600, 72Hz mode (11) */
+static struct valkyrie_regvals valkyrie_reg_init_11 = {
+ 13,
+ { 17, 27, 3 }, /* pixel clock = 49.63MHz for V=71.66Hz */
+ { 800, 0 },
+ 800, 600
+};
+
/* Register values for 800x600, 60Hz mode (10) */
static struct valkyrie_regvals valkyrie_reg_init_10 = {
12,
@@ -188,24 +188,13 @@ static struct valkyrie_regvals *valkyrie
NULL,
NULL,
&valkyrie_reg_init_10,
-#ifdef CONFIG_MAC
- NULL,
- NULL,
- &valkyrie_reg_init_13,
- NULL,
- NULL,
- NULL,
- NULL,
-#else
&valkyrie_reg_init_11,
NULL,
&valkyrie_reg_init_13,
+#ifndef CONFIG_MAC
&valkyrie_reg_init_14,
&valkyrie_reg_init_15,
NULL,
&valkyrie_reg_init_17,
#endif
- NULL,
- NULL,
- NULL
};
|
|
From: Finn T. <ft...@te...> - 2009-11-03 13:59:47
|
Lots of changes. Remove volatile keywords. Take the advice in the comments
and change video_slot to slot_addr. Factor out fifteen or so "channel >>
8" shifts into three shifts higher up the call graph. Make
csc_setpalette() atomic, pass the correct color values. Check for
ioremap() failure. Add missing break statement, thus fixing 24 bit console
visual (blue background bug). Remove some uninformative printk() noise.
Add a description for powerbook 140/170 graphics.
Signed-off-by: Finn Thain <ft...@te...>
---
drivers/video/macfb.c | 144 ++++++++++++++++++++------------------------------
1 file changed, 60 insertions(+), 84 deletions(-)
Index: linux-2.6.31/drivers/video/macfb.c
===================================================================
--- linux-2.6.31.orig/drivers/video/macfb.c 2009-11-03 03:23:44.000000000 +1100
+++ linux-2.6.31/drivers/video/macfb.c 2009-11-03 03:23:45.000000000 +1100
@@ -120,8 +120,6 @@ struct jet_cmap_regs {
#define PIXEL_TO_MM(a) (((a)*10)/28) /* width in mm at 72 dpi */
-static int video_slot = 0;
-
static struct fb_var_screeninfo macfb_defined = {
.bits_per_pixel = 8,
.activate = FB_ACTIVATE_NOW,
@@ -139,6 +137,7 @@ static struct fb_fix_screeninfo macfb_fi
.accel = FB_ACCEL_NONE,
};
+static void *slot_addr;
static struct fb_info fb_info;
static u32 pseudo_palette[16];
static int inverse;
@@ -156,10 +155,6 @@ static int dafb_setpalette(unsigned int
{
static int lastreg = -1;
unsigned long flags;
-
- red >>= 8;
- green >>= 8;
- blue >>= 8;
local_irq_save(flags);
@@ -205,10 +200,6 @@ static int v8_brazil_setpalette(unsigned
struct fb_info *info)
{
unsigned int bpp = info->var.bits_per_pixel;
- unsigned char _red =red>>8;
- unsigned char _green=green>>8;
- unsigned char _blue =blue>>8;
- unsigned char _regno;
unsigned long flags;
if (bpp > 8)
@@ -222,16 +213,16 @@ static int v8_brazil_setpalette(unsigned
* In 4bpp, the regnos are 0x0f, 0x1f, 0x2f, etc, etc
* In 2bpp, the regnos are 0x3f, 0x7f, 0xbf, 0xff
*/
- _regno = (regno << (8 - bpp)) | (0xFF >> bpp);
- nubus_writeb(_regno, &v8_brazil_cmap_regs->addr);
+ regno = (regno << (8 - bpp)) | (0xFF >> bpp);
+ nubus_writeb(regno, &v8_brazil_cmap_regs->addr);
nop();
/* send one color channel at a time */
- nubus_writeb(_red, &v8_brazil_cmap_regs->lut);
+ nubus_writeb(red, &v8_brazil_cmap_regs->lut);
nop();
- nubus_writeb(_green, &v8_brazil_cmap_regs->lut);
+ nubus_writeb(green, &v8_brazil_cmap_regs->lut);
nop();
- nubus_writeb(_blue, &v8_brazil_cmap_regs->lut);
+ nubus_writeb(blue, &v8_brazil_cmap_regs->lut);
local_irq_restore(flags);
return 0;
@@ -241,11 +232,6 @@ static int rbv_setpalette(unsigned int r
unsigned int green, unsigned int blue,
struct fb_info *info)
{
- /* use MSBs */
- unsigned char _red =red>>8;
- unsigned char _green=green>>8;
- unsigned char _blue =blue>>8;
- unsigned char _regno;
unsigned long flags;
if (info->var.bits_per_pixel > 8)
@@ -257,22 +243,22 @@ static int rbv_setpalette(unsigned int r
* regno #254 and #255 are the important ones for 1-bit color,
* regno #252-255 are the important ones for 2-bit color, etc.
*/
- _regno = regno + (256-(1 << info->var.bits_per_pixel));
+ regno += 256 - (1 << info->var.bits_per_pixel);
/* reset clut? (VideoToolbox sez "not necessary") */
nubus_writeb(0xFF, &rbv_cmap_regs->cntl);
nop();
/* tell clut which address to use. */
- nubus_writeb(_regno, &rbv_cmap_regs->addr);
+ nubus_writeb(regno, &rbv_cmap_regs->addr);
nop();
/* send one color channel at a time. */
- nubus_writeb(_red, &rbv_cmap_regs->lut);
+ nubus_writeb(red, &rbv_cmap_regs->lut);
nop();
- nubus_writeb(_green, &rbv_cmap_regs->lut);
+ nubus_writeb(green, &rbv_cmap_regs->lut);
nop();
- nubus_writeb(_blue, &rbv_cmap_regs->lut);
+ nubus_writeb(blue, &rbv_cmap_regs->lut);
local_irq_restore(flags);
return 0;
@@ -283,25 +269,19 @@ static int mdc_setpalette(unsigned int r
unsigned int green, unsigned int blue,
struct fb_info *info)
{
- volatile struct mdc_cmap_regs *cmap_regs =
- nubus_slot_addr(video_slot);
- /* use MSBs */
- unsigned char _red =red>>8;
- unsigned char _green=green>>8;
- unsigned char _blue =blue>>8;
- unsigned char _regno=regno;
+ struct mdc_cmap_regs *cmap_regs = slot_addr;
unsigned long flags;
local_irq_save(flags);
/* the nop's are there to order writes. */
- nubus_writeb(_regno, &cmap_regs->addr);
+ nubus_writeb(regno, &cmap_regs->addr);
nop();
- nubus_writeb(_red, &cmap_regs->lut);
+ nubus_writeb(red, &cmap_regs->lut);
nop();
- nubus_writeb(_green, &cmap_regs->lut);
+ nubus_writeb(green, &cmap_regs->lut);
nop();
- nubus_writeb(_blue, &cmap_regs->lut);
+ nubus_writeb(blue, &cmap_regs->lut);
local_irq_restore(flags);
return 0;
@@ -312,25 +292,24 @@ static int toby_setpalette(unsigned int
unsigned int green, unsigned int blue,
struct fb_info *info)
{
- volatile struct toby_cmap_regs *cmap_regs =
- nubus_slot_addr(video_slot);
+ struct toby_cmap_regs *cmap_regs = slot_addr;
unsigned int bpp = info->var.bits_per_pixel;
- /* use MSBs */
- unsigned char _red =~(red>>8);
- unsigned char _green=~(green>>8);
- unsigned char _blue =~(blue>>8);
- unsigned char _regno = (regno << (8 - bpp)) | (0xFF >> bpp);
unsigned long flags;
+ red = ~red;
+ green = ~green;
+ blue = ~blue;
+ regno = (regno << (8 - bpp)) | (0xFF >> bpp);
+
local_irq_save(flags);
- nubus_writeb(_regno, &cmap_regs->addr);
+ nubus_writeb(regno, &cmap_regs->addr);
nop();
- nubus_writeb(_red, &cmap_regs->lut);
+ nubus_writeb(red, &cmap_regs->lut);
nop();
- nubus_writeb(_green, &cmap_regs->lut);
+ nubus_writeb(green, &cmap_regs->lut);
nop();
- nubus_writeb(_blue, &cmap_regs->lut);
+ nubus_writeb(blue, &cmap_regs->lut);
local_irq_restore(flags);
return 0;
@@ -341,23 +320,18 @@ static int jet_setpalette(unsigned int r
unsigned int green, unsigned int blue,
struct fb_info *info)
{
- volatile struct jet_cmap_regs *cmap_regs =
- nubus_slot_addr(video_slot);
- /* use MSBs */
- unsigned char _red = (red>>8);
- unsigned char _green = (green>>8);
- unsigned char _blue = (blue>>8);
+ struct jet_cmap_regs *cmap_regs = slot_addr;
unsigned long flags;
local_irq_save(flags);
nubus_writeb(regno, &cmap_regs->addr);
nop();
- nubus_writeb(_red, &cmap_regs->lut);
+ nubus_writeb(red, &cmap_regs->lut);
nop();
- nubus_writeb(_green, &cmap_regs->lut);
+ nubus_writeb(green, &cmap_regs->lut);
nop();
- nubus_writeb(_blue, &cmap_regs->lut);
+ nubus_writeb(blue, &cmap_regs->lut);
local_irq_restore(flags);
return 0;
@@ -384,10 +358,6 @@ static int civic_setpalette(unsigned int
if (info->var.bits_per_pixel > 8)
return 1; /* failsafe */
- red >>= 8;
- green >>= 8;
- blue >>= 8;
-
local_irq_save(flags);
/* Set the register address */
@@ -463,11 +433,17 @@ static int csc_setpalette(unsigned int r
unsigned int green, unsigned int blue,
struct fb_info *info)
{
- mdelay(1);
+ unsigned long flags;
+
+ local_irq_save(flags);
+
+ udelay(1); /* mklinux on PB 5300 waits for 260 ns */
nubus_writeb(regno, &csc_cmap_regs->clut_waddr);
- nubus_writeb(red, &csc_cmap_regs->clut_data);
+ nubus_writeb(red, &csc_cmap_regs->clut_data);
nubus_writeb(green, &csc_cmap_regs->clut_data);
- nubus_writeb(blue, &csc_cmap_regs->clut_data);
+ nubus_writeb(blue, &csc_cmap_regs->clut_data);
+
+ local_irq_restore(flags);
return 0;
}
@@ -494,8 +470,8 @@ static int macfb_setcolreg(unsigned regn
case 4:
case 8:
if (macfb_setpalette)
- macfb_setpalette(regno, red, green, blue,
- fb_info);
+ macfb_setpalette(regno, red >> 8, green >> 8,
+ blue >> 8, fb_info);
else
return 1;
break;
@@ -612,8 +588,11 @@ static int __init macfb_init(void)
* those mappings are set up, so this is in fact the safest
* way to ensure that this driver will work on every possible Mac
*/
- fb_info.screen_base = ioremap(mac_bi_data.videoaddr, macfb_fix.smem_len);
-
+ fb_info.screen_base = ioremap(mac_bi_data.videoaddr,
+ macfb_fix.smem_len);
+ if (!fb_info.screen_base)
+ return -ENODEV;
+
printk("macfb: framebuffer at 0x%08lx, mapped to 0x%p, size %dk\n",
macfb_fix.smem_start, fb_info.screen_base,
macfb_fix.smem_len / 1024);
@@ -621,17 +600,13 @@ static int __init macfb_init(void)
macfb_defined.xres, macfb_defined.yres,
macfb_defined.bits_per_pixel, macfb_fix.line_length);
- /*
- * Fill in the available video resolution
- */
+ /* Fill in the available video resolution */
macfb_defined.xres_virtual = macfb_defined.xres;
macfb_defined.yres_virtual = macfb_defined.yres;
macfb_defined.height = PIXEL_TO_MM(macfb_defined.yres);
macfb_defined.width = PIXEL_TO_MM(macfb_defined.xres);
- printk("macfb: scrolling: redraw\n");
-
- /* some dummy values for timing to make fbset happy */
+ /* Some dummy values for timing to make fbset happy */
macfb_defined.pixclock = 10000000 / macfb_defined.xres *
1000 / macfb_defined.yres;
macfb_defined.left_margin = (macfb_defined.xres / 8) & 0xf8;
@@ -667,8 +642,6 @@ static int __init macfb_init(void)
macfb_defined.green.length = 5;
macfb_defined.blue.offset = 0;
macfb_defined.blue.length = 5;
- printk("macfb: directcolor: "
- "size=1:5:5:5, shift=15:10:5:0\n");
video_cmap_len = 16;
/*
* Should actually be FB_VISUAL_DIRECTCOLOR, but this
@@ -684,10 +657,9 @@ static int __init macfb_init(void)
macfb_defined.green.length = 8;
macfb_defined.blue.offset = 0;
macfb_defined.blue.length = 8;
- printk("macfb: truecolor: "
- "size=0:8:8:8, shift=0:16:8:0\n");
video_cmap_len = 16;
macfb_fix.visual = FB_VISUAL_TRUECOLOR;
+ break;
default:
video_cmap_len = 0;
macfb_fix.visual = FB_VISUAL_MONO01;
@@ -705,16 +677,17 @@ static int __init macfb_init(void)
* code is really broken :-)
*/
- while ((ndev = nubus_find_type(NUBUS_CAT_DISPLAY, NUBUS_TYPE_VIDEO, ndev))
- != NULL)
+ while ((ndev = nubus_find_type(NUBUS_CAT_DISPLAY,
+ NUBUS_TYPE_VIDEO, ndev)))
{
- if (!(mac_bi_data.videoaddr >= ndev->board->slot_addr
- && (mac_bi_data.videoaddr <
- (unsigned long)nubus_slot_addr(ndev->board->slot+1))))
+ unsigned long base = ndev->board->slot_addr;
+
+ if (mac_bi_data.videoaddr < base ||
+ mac_bi_data.videoaddr - base > 0xFFFFFF)
continue;
+
video_is_nubus = 1;
- /* We should probably just use the slot address... */
- video_slot = ndev->board->slot;
+ slot_addr = (unsigned char *)base;
switch(ndev->dr_hw) {
case NUBUS_DRHW_APPLE_MDC:
@@ -883,6 +856,9 @@ static int __init macfb_init(void)
* really support that.
*/
+ /*
+ * Slot 0 ROM says TIM. No external video. B&W.
+ */
case MAC_MODEL_PB140:
case MAC_MODEL_PB145:
case MAC_MODEL_PB170:
|
|
From: Clemens L. <cl...@la...> - 2009-11-03 12:29:10
|
When the framebuffer driver does not publish detailed timing information for the current video mode, the correct value for the pixclock field is zero, not -1. Since pixclock is actually unsigned, the value -1 would be interpreted as 4294967295 picoseconds (i.e., about 4 milliseconds) by register_framebuffer() and userspace programs. This patch allows X.org's fbdev driver to work. Signed-off-by: Clemens Ladisch <cl...@la...> --- No changes from v1. drivers/gpu/drm/drm_fb_helper.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) --- linux-2.6/drivers/gpu/drm/drm_fb_helper.c +++ linux-2.6/drivers/gpu/drm/drm_fb_helper.c @@ -599,7 +599,7 @@ int drm_fb_helper_check_var(struct fb_va struct drm_framebuffer *fb = fb_helper->fb; int depth; - if (var->pixclock == -1 || !var->pixclock) + if (var->pixclock != 0) return -EINVAL; /* Need to resize the fb object !!! */ @@ -691,7 +691,7 @@ int drm_fb_helper_set_par(struct fb_info int ret; int i; - if (var->pixclock != -1) { + if (var->pixclock != 0) { DRM_ERROR("PIXEL CLCOK SET\n"); return -EINVAL; } @@ -904,7 +904,7 @@ int drm_fb_helper_single_fb_probe(struct fb_helper->fb = fb; if (new_fb) { - info->var.pixclock = -1; + info->var.pixclock = 0; if (register_framebuffer(info) < 0) return -EINVAL; } else { |
|
From: Clemens L. <cl...@la...> - 2009-11-03 12:25:12
|
James Simmons wrote:
>> Without an allocated colormap, FBIOGETCMAP fails. This would make
>> programs restore an all-black colormap ("links -g") or fail to work
>> altogether ("mplayer -vo fbdev2").
>>
>> --- linux-2.6/drivers/gpu/drm/i915/intel_fb.c
>> +++ linux-2.6/drivers/gpu/drm/i915/intel_fb.c
>> @@ -227,6 +227,10 @@ static int intelfb_create(struct drm_dev
>>
>> fb->fbdev = info;
>>
>> + ret = fb_alloc_cmap(&info->cmap, 256, 0);
>> + if (ret)
>> + goto out_unpin;
>> +
>> par->intel_fb = intel_fb;
>
> It would be better to place that code in drm_fb_helper_single_fb_probe.
Thanks, I wasn't quite able to untangle the indirections between the
four framebuffer structures.
New patch set follows.
|
|
From: Clemens L. <cl...@la...> - 2009-11-03 12:24:33
|
The fbdev field of the drm_framebuffer structure is always used to store
a pointer to a fb_info, so there is no reason for it to be void*.
Signed-off-by: Clemens Ladisch <cl...@la...>
---
Needed for the next patch.
include/drm/drm_crtc.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- linux-2.6/include/drm/drm_crtc.h
+++ linux-2.6/include/drm/drm_crtc.h
@@ -256,7 +256,7 @@ struct drm_framebuffer {
unsigned int depth;
int bits_per_pixel;
int flags;
- void *fbdev;
+ struct fb_info *fbdev;
u32 pseudo_palette[17];
struct list_head filp_head;
/* if you are using the helper */
|
|
From: Chaithrika U S <cha...@ti...> - 2009-11-03 11:58:24
|
Add cpufreq support for DA8xx/OMAP-L1xx frame buffer driver
Signed-off-by: Chaithrika U S <cha...@ti...>
---
This patch applies to Linus' kernel tree. In this version, a macro name
has been corrected. This patch is dependent on the 'davinci: fb:
Calculate the clock divider from pixel clock info' patch submitted earlier.
drivers/video/da8xx-fb.c | 55 ++++++++++++++++++++++++++++++++++++++++++++++
1 files changed, 55 insertions(+), 0 deletions(-)
diff --git a/drivers/video/da8xx-fb.c b/drivers/video/da8xx-fb.c
index d9ab839..93842c8 100644
--- a/drivers/video/da8xx-fb.c
+++ b/drivers/video/da8xx-fb.c
@@ -28,6 +28,7 @@
#include <linux/uaccess.h>
#include <linux/interrupt.h>
#include <linux/clk.h>
+#include <linux/cpufreq.h>
#include <video/da8xx-fb.h>
#define DRIVER_NAME "da8xx_lcdc"
@@ -114,6 +115,9 @@ struct da8xx_fb_par {
unsigned int databuf_sz;
unsigned int palette_sz;
unsigned int pxl_clk;
+#ifdef CONFIG_CPU_FREQ
+ struct notifier_block freq_transition;
+#endif
};
/* Variable Screen Information */
@@ -586,6 +590,41 @@ static int fb_check_var(struct fb_var_screeninfo *var,
return err;
}
+#ifdef CONFIG_CPU_FREQ
+static int lcd_da8xx_cpufreq_transition(struct notifier_block *nb,
+ unsigned long val, void *data)
+{
+ struct da8xx_fb_par *par;
+ unsigned int reg;
+
+ par = container_of(nb, struct da8xx_fb_par, freq_transition);
+ if (val == CPUFREQ_PRECHANGE) {
+ reg = lcdc_read(LCD_RASTER_CTRL_REG);
+ lcdc_write(reg & ~LCD_RASTER_ENABLE, LCD_RASTER_CTRL_REG);
+ } else if (val == CPUFREQ_POSTCHANGE) {
+ lcd_calc_clk_divider(par);
+ reg = lcdc_read(LCD_RASTER_CTRL_REG);
+ lcdc_write(reg | LCD_RASTER_ENABLE, LCD_RASTER_CTRL_REG);
+ }
+
+ return 0;
+}
+
+static inline int lcd_da8xx_cpufreq_register(struct da8xx_fb_par *par)
+{
+ par->freq_transition.notifier_call = lcd_da8xx_cpufreq_transition;
+
+ return cpufreq_register_notifier(&par->freq_transition,
+ CPUFREQ_TRANSITION_NOTIFIER);
+}
+
+static inline void lcd_da8xx_cpufreq_deregister(struct da8xx_fb_par *par)
+{
+ cpufreq_unregister_notifier(&par->freq_transition,
+ CPUFREQ_TRANSITION_NOTIFIER);
+}
+#endif
+
static int __devexit fb_remove(struct platform_device *dev)
{
struct fb_info *info = dev_get_drvdata(&dev->dev);
@@ -593,6 +632,9 @@ static int __devexit fb_remove(struct platform_device *dev)
if (info) {
struct da8xx_fb_par *par = info->par;
+#ifdef CONFIG_CPU_FREQ
+ lcd_da8xx_cpufreq_deregister(par);
+#endif
if (lcdc_read(LCD_RASTER_CTRL_REG) & LCD_RASTER_ENABLE)
lcd_disable_raster(par);
lcdc_write(0, LCD_RASTER_CTRL_REG);
@@ -823,12 +865,25 @@ static int __init fb_probe(struct platform_device *device)
goto err_dealloc_cmap;
}
+#ifdef CONFIG_CPU_FREQ
+ ret = lcd_da8xx_cpufreq_register(par);
+ if (ret) {
+ dev_err(&device->dev, "failed to register cpufreq\n");
+ goto err_cpu_freq;
+ }
+#endif
+
/* enable raster engine */
lcdc_write(lcdc_read(LCD_RASTER_CTRL_REG) |
LCD_RASTER_ENABLE, LCD_RASTER_CTRL_REG);
return 0;
+#ifdef CONFIG_CPU_FREQ
+err_cpu_freq:
+ unregister_framebuffer(da8xx_fb_info);
+#endif
+
err_dealloc_cmap:
fb_dealloc_cmap(&da8xx_fb_info->cmap);
--
1.5.6
|
|
From: Vincent H. <ta...@sn...> - 2009-11-03 09:51:16
|
On Tue, Nov 03, 2009 at 07:39:34AM +0100, Alexander Graf wrote: > > On 03.11.2009, at 07:34, Avi Kivity wrote: > >> On 11/03/2009 08:27 AM, Alexander Graf wrote: >>> >>>> How does it work today? >>> >>> You boot into a TERM=dumb line based emulation on 3270 (worst thing >>> haunting people's nightmares ever), trying to get out of that mode >>> as quickly as possible and off into SSH / VNC. >> >> Despite the coolness factor, IMO a few minutes during install time do >> not justify a new hardware model and a new driver. > > It's more than just coolness factor. There are use cases out there > (www.susestudio.com) that don't want to rely on the guest exporting a VNC > server to the outside just to access graphics. You also want to see boot > messages, have a console login screen, be able to debug things without > switching between virtio-console and vnc, etc. etc. > > The hardware model isn't exactly new either. It's just the next logical > step to a full PV machine using virtio. If the virtio-fb stuff turns out > to be really fast and reliable, I could even imagine it being the default > target for kvm on ppc as well, as we can't switch resolutions on the fly > there atm. not sure if i'm missing the point here, but couldn't it be hypothetically extended to stuff 3d (or video & more 2d accel ?) commands too ? I can't imagine the cirrus or stdvga driver be able to do that ever ;) -- Vincent |
|
From: Avi K. <av...@re...> - 2009-11-03 09:38:34
|
On 11/03/2009 01:25 PM, Vincent Hanquez wrote: > not sure if i'm missing the point here, but couldn't it be hypothetically > extended to stuff 3d (or video& more 2d accel ?) commands too ? I can't > imagine the cirrus or stdvga driver be able to do that ever ;) > cirrus has pretty good 2d acceleration. 3D is a mega-project though. -- error compiling committee.c: too many arguments to function |
|
From: Eric M. <eri...@gm...> - 2009-11-03 09:32:57
|
On Tue, Nov 3, 2009 at 2:45 PM, Jun Nie <nie...@gm...> wrote:
> pxa: frame buffer support both pxa168 and pxa910
>
> Signed-off-by: Jun Nie <nj...@ma...>
> ---
> drivers/video/pxa168fb.c | 6 ++++++
> 1 files changed, 6 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/video/pxa168fb.c b/drivers/video/pxa168fb.c
> index 27bdf2b..2ba1444 100644
> --- a/drivers/video/pxa168fb.c
> +++ b/drivers/video/pxa168fb.c
> @@ -875,12 +875,18 @@ failed:
> return ret;
> }
>
> + static const struct platform_device_id mmpfb_id_table[] = {
> + {"pxa168-fb", 0},
> + {"pxa910-fb", 1},
> + };
> +
Not sure '0' and '1' means anything here? Otherwise can just be '0'.
Intended usage could be some flags difference between processors,
let's say pxa910-fb supports YUV, one can have something like:
{ "pxa168-fb", FB_SUPPORT_RGB },
{ "pxa910-fb", FB_SUPPORT_RGB | FB_SUPPORT_YUV },
Just examples.
> static struct platform_driver pxa168fb_driver = {
> .driver = {
> .name = "pxa168-fb",
> .owner = THIS_MODULE,
> },
> .probe = pxa168fb_probe,
> + .id_table = mmpfb_id_table,
> };
>
> static int __devinit pxa168fb_init(void)
> --
> 1.5.4.3
>
> _______________________________________________
> linux-arm-kernel mailing list
> lin...@li...
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>
|
|
From: Avi K. <av...@re...> - 2009-11-03 08:53:20
|
On 11/03/2009 10:26 AM, Alexander Graf wrote: > Exactly. In fact, I'm even scared to reboot mine because I might end > up in a 3270 terminal. The whole text only crap keeps people from > using this platform! And that's what I want to change here. Ok. I oppose paravirtualization for its own sake and only support it if there's no other way to get performance. In this case it buys us basic functionality which is surprisingly missing on native, that's arguably even more important. -- error compiling committee.c: too many arguments to function |
|
From: Eric M. <eri...@gm...> - 2009-11-03 08:33:03
|
On Tue, Nov 3, 2009 at 2:45 PM, Jun Nie <nie...@gm...> wrote:
> pxa: support pxa168 LCD controller SPI operation
>
> Signed-off-by: Jun Nie <nj...@ma...>
> ---
> arch/arm/mach-mmp/include/mach/pxa168fb.h | 29 +++++++++
> drivers/video/pxa168fb.c | 92 +++++++++++++++++++++++++++++
> drivers/video/pxa168fb.h | 24 +-------
> include/video/pxa168fb.h | 18 ++++++
> 4 files changed, 140 insertions(+), 23 deletions(-)
> create mode 100644 arch/arm/mach-mmp/include/mach/pxa168fb.h
>
> diff --git a/arch/arm/mach-mmp/include/mach/pxa168fb.h
> b/arch/arm/mach-mmp/include/mach/pxa168fb.h
> new file mode 100644
> index 0000000..897cc3e
> --- /dev/null
> +++ b/arch/arm/mach-mmp/include/mach/pxa168fb.h
> @@ -0,0 +1,29 @@
> +#ifndef __PXA168FBSPI_H__
> +#define __PXA168FBSPI_H__
> +
> +/* SPI Control Register. */
> +#define LCD_SPU_SPI_CTRL 0x0180
> +#define CFG_SCLKCNT(div) ((div) << 24) /* 0xFF~0x2 */
> +#define CFG_SCLKCNT_MASK 0xFF000000
> +#define CFG_RXBITS(rx) ((rx - 1) << 16) /* 0x1F~0x1, 0x1:
> 2bits ... 0x1F: 32bits */
> +#define CFG_RXBITS_MASK 0x00FF0000
> +#define CFG_TXBITS(tx) ((tx - 1) << 8) /*
> 0x1F~0x1, 0x1: 2bits ... 0x1F: 32bits */
> +#define CFG_TXBITS_MASK 0x0000FF00
> +#define CFG_CLKINV(clk) ((clk) << 7)
> +#define CFG_CLKINV_MASK 0x00000080
> +#define CFG_KEEPXFER(transfer) ((transfer) << 6)
> +#define CFG_KEEPXFER_MASK 0x00000040
> +#define CFG_RXBITSTO0(rx) ((rx) << 5)
> +#define CFG_RXBITSTO0_MASK 0x00000020
> +#define CFG_TXBITSTO0(tx) ((tx) << 4)
> +#define CFG_TXBITSTO0_MASK 0x00000010
> +#define CFG_SPI_ENA(spi) ((spi) << 3)
> +#define CFG_SPI_ENA_MASK 0x00000008
> +#define CFG_SPI_SEL(spi) ((spi) << 2) /* 1: port1; 0: port0 */
> +#define CFG_SPI_SEL_MASK 0x00000004
> +#define CFG_SPI_3W4WB(wire) ((wire)<<1) /* 1:
> 3-wire; 0: 4-wire */
> +#define CFG_SPI_3W4WB_MASK 0x00000002
> +#define CFG_SPI_START(start) (start)
> +#define CFG_SPI_START_MASK 0x00000001
> +
> +#endif /* __PXA168FBSPI_H__ */
Shouldn't these be defined in drivers/video/pxa168fb.h? Or if
some of the definitions are to be used by platform code, move
them to include/video/pxa168fb.h.
> diff --git a/drivers/video/pxa168fb.c b/drivers/video/pxa168fb.c
> index 84d8327..27bdf2b 100644
> --- a/drivers/video/pxa168fb.c
> +++ b/drivers/video/pxa168fb.c
> @@ -29,10 +29,91 @@
> #include <linux/uaccess.h>
> #include <video/pxa168fb.h>
>
> +#include <mach/pxa168fb.h>
> +#include <mach/gpio.h>
> #include "pxa168fb.h"
>
> #define DEFAULT_REFRESH 60 /* Hz */
>
> +static inline void spi_gpio_assert_set(int spi_gpio_cs, int val)
> +{
> + if (gpio_is_valid(spi_gpio_cs))
> + gpio_set_value(spi_gpio_cs, val);
> +}
Mmm.... two points:
1. spi_gpio_assert() sounds enough to me, no "_set" suffix necessary
2. is it possible that in some cases that this GPIO CS signal is inverted?
> +int pxa168fb_spi_send(struct pxa168fb_info *fbi, void *value, int count,
> + unsigned int spi_gpio_cs, unsigned int interval_us)
> +{
> + u32 x, spi_byte_len;
> + u8 *cmd = (u8 *)value;
> + int i, err, isr, iopad, ret = 0;
> +
> + if (gpio_is_valid(spi_gpio_cs)) {
> + err = gpio_request(spi_gpio_cs, "LCD_SPI_CS");
> + if (err) {
> + dev_err(fbi->dev, "failed to request GPIO for LCD CS\n");
> + return -1;
> + }
> + gpio_direction_output(spi_gpio_cs, 1);
> + }
Is this possible this been done at some initialization stage and do only once?
> + spi_byte_len = readl(fbi->reg_base + LCD_SPU_SPI_CTRL);
> + spi_byte_len = (spi_byte_len >> 8) & 0xff;
> + /* Alignment should be (spi_byte_len + 7) >> 3, but
> + * spi controller request set one less than bit length */
> + spi_byte_len = (spi_byte_len + 8) >> 3;
> + /* spi command provided by platform should be 1, 2, or 4 byte aligned */
> + if(3 == spi_byte_len)
> + spi_byte_len = 4;
> +
> + iopad = readl(fbi->reg_base + SPU_IOPAD_CONTROL);
> + if ((iopad & CFG_IOPADMODE_MASK) != PIN_MODE_DUMB_18_SPI)
> + writel(PIN_MODE_DUMB_18_SPI, fbi->reg_base + SPU_IOPAD_CONTROL);
> + isr = readl(fbi->reg_base + SPU_IRQ_ISR);
> + writel((isr & ~SPI_IRQ_ENA_MASK), fbi->reg_base + SPU_IRQ_ISR);
> + for (i = 0; i < count; i++) {
> + spi_gpio_assert_set(spi_gpio_cs, 0);
> + udelay(interval_us);
> + switch (spi_byte_len){
> + case 1:
> + writel(*cmd, fbi->reg_base + LCD_SPU_SPI_TXDATA);
> + break;
> + case 2:
> + writel(*(u16*)cmd, fbi->reg_base + LCD_SPU_SPI_TXDATA);
> + break;
> + case 4:
> + writel(*(u32*)cmd, fbi->reg_base + LCD_SPU_SPI_TXDATA);
> + break;
> + default:
> + dev_err(fbi->dev, "Wrong spi bit length\n");
> + spi_gpio_assert_set(spi_gpio_cs, 1);
> + ret = -1;
> + goto spi_exit;
> + }
> + cmd += spi_byte_len;
> + x = readl(fbi->reg_base + LCD_SPU_SPI_CTRL);
> + x |= 0x1;
> + writel(x, fbi->reg_base + LCD_SPU_SPI_CTRL);
> + isr = readl(fbi->reg_base + SPU_IRQ_ISR);
> + while(!(isr & SPI_IRQ_ENA_MASK)) {
> + udelay(1);
> + isr = readl(fbi->reg_base + SPU_IRQ_ISR);
> + }
> + x = readl(fbi->reg_base + LCD_SPU_SPI_CTRL);
> + x &= ~0x1;
> + writel(x, fbi->reg_base + LCD_SPU_SPI_CTRL);
> + spi_gpio_assert_set(spi_gpio_cs, 1);
> + }
So after this loop, the 'spi_gpio_cs' is left asserted, which isn't good.
> +
> +spi_exit:
> + if (gpio_is_valid(spi_gpio_cs))
> + gpio_free(spi_gpio_cs);
> + if ((iopad & CFG_IOPADMODE_MASK) != PIN_MODE_DUMB_18_SPI)
> + writel(iopad, fbi->reg_base + SPU_IOPAD_CONTROL);
> +
> + return ret;
> +}
> +EXPORT_SYMBOL(pxa168fb_spi_send);
> +
> static int determine_best_pix_fmt(struct fb_var_screeninfo *var)
> {
> /*
> @@ -687,6 +768,7 @@ static int __init pxa168fb_probe(struct
> platform_device *pdev)
> }
>
> info->fix.smem_start = (unsigned long)fbi->fb_start_dma;
> + set_graphics_start(info, 0, 0);
This need a separate patch.
>
> /*
> * Set video mode according to platform data.
> @@ -728,6 +810,9 @@ static int __init pxa168fb_probe(struct
> platform_device *pdev)
> writel(0, fbi->reg_base + LCD_SPU_SRAM_PARA0);
> writel(CFG_CSB_256x32(0x1)|CFG_CSB_256x24(0x1)|CFG_CSB_256x8(0x1),
> fbi->reg_base + LCD_SPU_SRAM_PARA1);
> + if ((mi->spi_ctrl != -1) && (mi->spi_ctrl & CFG_SPI_ENA_MASK))
> + writel(mi->spi_ctrl, fbi->reg_base + LCD_SPU_SPI_CTRL);
> +
>
> /*
> * Allocate color map.
> @@ -764,6 +849,13 @@ static int __init pxa168fb_probe(struct
> platform_device *pdev)
> }
>
> platform_set_drvdata(pdev, fbi);
> + if (mi->pxa168fb_lcd_power){
> + if(mi->pxa168fb_lcd_power(fbi, mi->spi_gpio_cs, mi->spi_gpio_reset, 1)){
> + dev_err(&pdev->dev, "Failed to power up pxa168-fb\n");
> + goto failed_free_irq;
> + }
> + }
> + dev_info(fbi->dev, "frame buffer detected\n");
Need another patch for this as well?
> return 0;
>
> failed_free_irq:
> diff --git a/drivers/video/pxa168fb.h b/drivers/video/pxa168fb.h
> index eee0927..1e4859e 100644
> --- a/drivers/video/pxa168fb.h
> +++ b/drivers/video/pxa168fb.h
> @@ -170,29 +170,7 @@
> #define DMA_FRAME_CNT_MASK 0x00000003 /* Video */
>
> /* SPI Control Register. */
> -#define LCD_SPU_SPI_CTRL 0x0180
> -#define CFG_SCLKCNT(div) ((div) << 24) /* 0xFF~0x2 */
> -#define CFG_SCLKCNT_MASK 0xFF000000
> -#define CFG_RXBITS(rx) ((rx) << 16) /* 0x1F~0x1 */
> -#define CFG_RXBITS_MASK 0x00FF0000
> -#define CFG_TXBITS(tx) ((tx) << 8) /* 0x1F~0x1 */
> -#define CFG_TXBITS_MASK 0x0000FF00
> -#define CFG_CLKINV(clk) ((clk) << 7)
> -#define CFG_CLKINV_MASK 0x00000080
> -#define CFG_KEEPXFER(transfer) ((transfer) << 6)
> -#define CFG_KEEPXFER_MASK 0x00000040
> -#define CFG_RXBITSTO0(rx) ((rx) << 5)
> -#define CFG_RXBITSTO0_MASK 0x00000020
> -#define CFG_TXBITSTO0(tx) ((tx) << 4)
> -#define CFG_TXBITSTO0_MASK 0x00000010
> -#define CFG_SPI_ENA(spi) ((spi) << 3)
> -#define CFG_SPI_ENA_MASK 0x00000008
> -#define CFG_SPI_SEL(spi) ((spi) << 2)
> -#define CFG_SPI_SEL_MASK 0x00000004
> -#define CFG_SPI_3W4WB(wire) ((wire) << 1)
> -#define CFG_SPI_3W4WB_MASK 0x00000002
> -#define CFG_SPI_START(start) (start)
> -#define CFG_SPI_START_MASK 0x00000001
> +/* For SPI register, please refer to
> arch/arm/mach-mmp/include/mach/pxa168fb.h */
>
> /* SPI Tx Data Register */
> #define LCD_SPU_SPI_TXDATA 0x0184
> diff --git a/include/video/pxa168fb.h b/include/video/pxa168fb.h
> index b5cc72f..f0497ae 100644
> --- a/include/video/pxa168fb.h
> +++ b/include/video/pxa168fb.h
> @@ -122,6 +122,24 @@ struct pxa168fb_mach_info {
> unsigned panel_rbswap:1;
> unsigned active:1;
> unsigned enable_lcd:1;
> + /*
> + * SPI control
> + */
> + unsigned int spi_ctrl;
> + unsigned int spi_gpio_cs;
> + unsigned int spi_gpio_reset;
> + /*
> + * power on/off function.
> + */
> + int (*pxa168fb_lcd_power)(struct pxa168fb_info *, unsigned int,
> unsigned int, int);
> };
>
> +/* SPI utility for configure panel SPI command.
> + * value: command array, element should be 1, 2 or 4 byte aligned.
> + * count: command array length
> + * spi_gpio_cs: gpio number for spi chip select
> + * interval_us: time interval between two commands, us as unit */
> +int pxa168fb_spi_send(struct pxa168fb_info *fbi, void *value, int count,
> + unsigned int spi_gpio_cs, unsigned int interval_us);
> +
> #endif /* __ASM_MACH_PXA168FB_H */
> --
> 1.5.4.3
>
> _______________________________________________
> linux-arm-kernel mailing list
> lin...@li...
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>
|
|
From: Alexander G. <ag...@su...> - 2009-11-03 08:26:25
|
On 03.11.2009, at 09:20, Avi Kivity wrote: > On 11/03/2009 09:50 AM, Alexander Graf wrote: >> >> Ok, imagine this was not this unloved S390 odd architecture but >> X86. The only output choices you have are: >> >> 1) virtio-console >> 2) VNC / SSH over network >> 3) virtio-fb >> >> Now you want to configure a server, probably using yast and all >> those nice graphical utilities, but still enable a firewall so >> people outside don't intrude your machine. Well, you managed to >> configure the firewall by luck to allow VNC, but now you >> reconfigured it and something broke - but VNC was your only chance >> to access the machine. Oops... > > x86 has real framebuffers, so software and people expect it. s390 > doesn't. How do people manage now? They cope with what's there. Fortunately we're in a position to change things, so we don't have to stick with the worse. >>>> You also want to see boot messages, have a console login screen, >>> >>> virtio-console does that, except for the penguins. Better, since >>> you can scroll back. >> >> It doesn't do graphics. Ever used yast in text mode? > > Once you're in, start ssh+X or vnc. Again, what do people do now? Exactly that. Again, it works but is not ideal. If we can improve user experience why work against it? >>>> The hardware model isn't exactly new either. It's just the next >>>> logical step to a full PV machine using virtio. If the virtio-fb >>>> stuff turns out to be really fast and reliable, I could even >>>> imagine it being the default target for kvm on ppc as well, as we >>>> can't switch resolutions on the fly there atm. >>>> >>> >>> We could with vmware-vga. >> >> The vmware-port stuff is pretty much tied onto X86. I don't think >> modifying EAX is that easy on PPC ;-). > > Yes, though we can probably make it work on ppc with minimal > modifications. Is it worth it? We can also just implement a virtio mouse event dev plus fb and be good. That way we control the whole stack without risking to break vmware. >>>>> Why? the guest will typically have networking when it's set up, >>>>> so it should have network access during install. You can easily >>>>> use slirp redirection and the built-in dhcp server to set this >>>>> up with relatively few hassles. >>>> >>>> That's how I use it right now. It's no fun. >>>> >>> >>> The toolstack should hide the unfun parts. >> >> You can't hide guest configuration. We as a distribution control >> the kernel. We don't control the user's configuration as that's by >> design the user's choice. The only thing we can do is give users >> meaningful choices to choose from - and having graphics available >> is definitely one of them. > > Well, if the user chooses not to have networking then vnc or ssh+x > definitely fail. That would be a strange choice for a server machine. It's actually rather common on S390, though admittedly not that much on Linux+S390. There are more ways for inter node communication than networking. You can talk to another VM on the same machine without any network whatsoever. That way you can set up an isolated job (your bank transfer database for example) that is always protected by a proxy to the outside world. >> Seriously, try to ask someone internally to get access to an S390. >> I think you'll understand my motivations a lot better after having >> used it for a bit. > > I actually have a s390 vm (RHEL 4 IIRC). It acts just like any > other remote machine over ssh except that it's especially slow > (probably the host is overloaded). Of course I wouldn't dream of > trying to install something like that though. Exactly. In fact, I'm even scared to reboot mine because I might end up in a 3270 terminal. The whole text only crap keeps people from using this platform! And that's what I want to change here. Alex |
|
From: Avi K. <av...@re...> - 2009-11-03 08:20:58
|
On 11/03/2009 09:50 AM, Alexander Graf wrote: > > Ok, imagine this was not this unloved S390 odd architecture but X86. > The only output choices you have are: > > 1) virtio-console > 2) VNC / SSH over network > 3) virtio-fb > > Now you want to configure a server, probably using yast and all those > nice graphical utilities, but still enable a firewall so people > outside don't intrude your machine. Well, you managed to configure the > firewall by luck to allow VNC, but now you reconfigured it and > something broke - but VNC was your only chance to access the machine. > Oops... x86 has real framebuffers, so software and people expect it. s390 doesn't. How do people manage now? >>> You also want to see boot messages, have a console login screen, >> >> virtio-console does that, except for the penguins. Better, since you >> can scroll back. > > It doesn't do graphics. Ever used yast in text mode? Once you're in, start ssh+X or vnc. Again, what do people do now? > >>> The hardware model isn't exactly new either. It's just the next >>> logical step to a full PV machine using virtio. If the virtio-fb >>> stuff turns out to be really fast and reliable, I could even imagine >>> it being the default target for kvm on ppc as well, as we can't >>> switch resolutions on the fly there atm. >>> >> >> We could with vmware-vga. > > The vmware-port stuff is pretty much tied onto X86. I don't think > modifying EAX is that easy on PPC ;-). Yes, though we can probably make it work on ppc with minimal modifications. >>>> Why? the guest will typically have networking when it's set up, so >>>> it should have network access during install. You can easily use >>>> slirp redirection and the built-in dhcp server to set this up with >>>> relatively few hassles. >>> >>> That's how I use it right now. It's no fun. >>> >> >> The toolstack should hide the unfun parts. > > You can't hide guest configuration. We as a distribution control the > kernel. We don't control the user's configuration as that's by design > the user's choice. The only thing we can do is give users meaningful > choices to choose from - and having graphics available is definitely > one of them. Well, if the user chooses not to have networking then vnc or ssh+x definitely fail. That would be a strange choice for a server machine. > Seriously, try to ask someone internally to get access to an S390. I > think you'll understand my motivations a lot better after having used > it for a bit. I actually have a s390 vm (RHEL 4 IIRC). It acts just like any other remote machine over ssh except that it's especially slow (probably the host is overloaded). Of course I wouldn't dream of trying to install something like that though. -- error compiling committee.c: too many arguments to function |
|
From: Andrew M. <ak...@li...> - 2009-11-03 07:59:01
|
On Tue, 20 Oct 2009 16:29:05 +0400 Valentin Sitdikov <val...@si...> wrote:
>
> ...
>
> +/* Fill in the cmd array /GDC FIFO commands/ to draw a 1bit image.
> + * Make sure cmd has enough room! */
The comment layout is sicky-looking.
> +static void mb86290fb_imageblit(struct fb_info *info,
> + const struct fb_image *image)
> +{
> + int mdr;
> + u32 *cmd = NULL;
> + void (*cmdfn) (u32 *, u16, u16, u16, u16, u16, u32, u32,
> + const struct fb_image *, struct fb_info *) = NULL;
> + u32 cmdlen;
> + u32 fgcolor = 0, bgcolor = 0;
> + u16 step;
> +
> + u16 width = image->width, height = image->height;
> + u16 dx = image->dx, dy = image->dy;
> + int x2, y2, vxres, vyres;
> +
> + mdr = (GDC_ROP_COPY << 9);
> + x2 = image->dx + image->width;
> + y2 = image->dy + image->height;
> + dx = image->dx > 0 ? image->dx : 0;
> + dy = image->dy > 0 ? image->dy : 0;
image->dz and image->dy are unsigned, so the above two statements
have no effect.
> + vxres = info->var.xres_virtual;
> + vyres = info->var.yres_virtual;
> + x2 = x2 < vxres ? x2 : vxres;
> + y2 = y2 < vyres ? y2 : vyres;
We have nice helper macros for this - please don't open code them.
Please review:
--- a/drivers/video/mb862xx/mb862xxfb_accel.c~mb862xxfb-add-acceleration-support-for-coral-p-coral-pa-imageblt-copyarea-fillrect-fix
+++ a/drivers/video/mb862xx/mb862xxfb_accel.c
@@ -66,8 +66,10 @@ static void mb86290fb_copyarea(struct fb
mb862xxfb_write_fifo(6, cmd, info);
}
-/* Fill in the cmd array /GDC FIFO commands/ to draw a 1bit image.
- * Make sure cmd has enough room! */
+/*
+ * Fill in the cmd array /GDC FIFO commands/ to draw a 1bit image.
+ * Make sure cmd has enough room!
+ */
static void mb86290fb_imageblit1(u32 *cmd, u16 step, u16 dx, u16 dy,
u16 width, u16 height, u32 fgcolor,
u32 bgcolor, const struct fb_image *image,
@@ -113,8 +115,10 @@ static void mb86290fb_imageblit1(u32 *cm
}
}
-/* Fill in the cmd array /GDC FIFO commands/ to draw a 8bit image.
- * Make sure cmd has enough room! */
+/*
+ * Fill in the cmd array /GDC FIFO commands/ to draw a 8bit image.
+ * Make sure cmd has enough room!
+ */
static void mb86290fb_imageblit8(u32 *cmd, u16 step, u16 dx, u16 dy,
u16 width, u16 height, u32 fgcolor,
u32 bgcolor, const struct fb_image *image,
@@ -150,8 +154,10 @@ static void mb86290fb_imageblit8(u32 *cm
}
}
-/* Fill in the cmd array /GDC FIFO commands/ to draw a 16bit image.
- * Make sure cmd has enough room! */
+/*
+ * Fill in the cmd array /GDC FIFO commands/ to draw a 16bit image.
+ * Make sure cmd has enough room!
+ */
static void mb86290fb_imageblit16(u32 *cmd, u16 step, u16 dx, u16 dy,
u16 width, u16 height, u32 fgcolor,
u32 bgcolor, const struct fb_image *image,
@@ -195,12 +201,10 @@ static void mb86290fb_imageblit(struct f
mdr = (GDC_ROP_COPY << 9);
x2 = image->dx + image->width;
y2 = image->dy + image->height;
- dx = image->dx > 0 ? image->dx : 0;
- dy = image->dy > 0 ? image->dy : 0;
vxres = info->var.xres_virtual;
vyres = info->var.yres_virtual;
- x2 = x2 < vxres ? x2 : vxres;
- y2 = y2 < vyres ? y2 : vyres;
+ x2 = min(x2, vxres);
+ y2 = min(y2, vyres);
width = x2 - dx;
height = y2 - dy;
@@ -265,8 +269,8 @@ static void mb86290fb_fillrect(struct fb
* hardware clipping by writing to framebuffer directly. */
x2 = rect->dx + rect->width;
y2 = rect->dy + rect->height;
- x2 = x2 < vxres ? x2 : vxres;
- y2 = y2 < vyres ? y2 : vyres;
+ x2 = min(x2, vxres);
+ y2 = min(y2, vyres);
width = x2 - rect->dx;
height = y2 - rect->dy;
if (info->fix.visual == FB_VISUAL_TRUECOLOR ||
diff -puN drivers/video/mb862xx/mb862xxfb_accel.h~mb862xxfb-add-acceleration-support-for-coral-p-coral-pa-imageblt-copyarea-fillrect-fix drivers/video/mb862xx/mb862xxfb_accel.h
_
|
|
From: Alexander G. <ag...@su...> - 2009-11-03 07:50:29
|
On 03.11.2009, at 08:43, Avi Kivity wrote: > On 11/03/2009 08:39 AM, Alexander Graf wrote: >> >> On 03.11.2009, at 07:34, Avi Kivity wrote: >> >>> On 11/03/2009 08:27 AM, Alexander Graf wrote: >>>> >>>>> How does it work today? >>>> >>>> You boot into a TERM=dumb line based emulation on 3270 (worst >>>> thing haunting people's nightmares ever), trying to get out of >>>> that mode as quickly as possible and off into SSH / VNC. >>> >>> Despite the coolness factor, IMO a few minutes during install time >>> do not justify a new hardware model and a new driver. >> >> It's more than just coolness factor. There are use cases out there (www.susestudio.com >> ) that don't want to rely on the guest exporting a VNC server to >> the outside just to access graphics. > > Instead you rely on the guest using virtio-fb. Since we have to make > guest modifications, why not go for the simpler ones? Ok, imagine this was not this unloved S390 odd architecture but X86. The only output choices you have are: 1) virtio-console 2) VNC / SSH over network 3) virtio-fb Now you want to configure a server, probably using yast and all those nice graphical utilities, but still enable a firewall so people outside don't intrude your machine. Well, you managed to configure the firewall by luck to allow VNC, but now you reconfigured it and something broke - but VNC was your only chance to access the machine. Oops... >> You also want to see boot messages, have a console login screen, > > virtio-console does that, except for the penguins. Better, since > you can scroll back. It doesn't do graphics. Ever used yast in text mode? >> be able to debug things without switching between virtio-console >> and vnc, etc. etc. > > Render virtio-console on your vnc session. We do that already, no? > (well, the host's vnc session, not the guest's). Yes, we do that. Still doesn't buy you graphics. >> The hardware model isn't exactly new either. It's just the next >> logical step to a full PV machine using virtio. If the virtio-fb >> stuff turns out to be really fast and reliable, I could even >> imagine it being the default target for kvm on ppc as well, as we >> can't switch resolutions on the fly there atm. >> > > We could with vmware-vga. The vmware-port stuff is pretty much tied onto X86. I don't think modifying EAX is that easy on PPC ;-). >>> Why? the guest will typically have networking when it's set up, >>> so it should have network access during install. You can easily >>> use slirp redirection and the built-in dhcp server to set this up >>> with relatively few hassles. >> >> That's how I use it right now. It's no fun. >> > > The toolstack should hide the unfun parts. You can't hide guest configuration. We as a distribution control the kernel. We don't control the user's configuration as that's by design the user's choice. The only thing we can do is give users meaningful choices to choose from - and having graphics available is definitely one of them. Seriously, try to ask someone internally to get access to an S390. I think you'll understand my motivations a lot better after having used it for a bit. Alex |
|
From: Avi K. <av...@re...> - 2009-11-03 07:44:04
|
On 11/03/2009 08:39 AM, Alexander Graf wrote: > > On 03.11.2009, at 07:34, Avi Kivity wrote: > >> On 11/03/2009 08:27 AM, Alexander Graf wrote: >>> >>>> How does it work today? >>> >>> You boot into a TERM=dumb line based emulation on 3270 (worst thing >>> haunting people's nightmares ever), trying to get out of that mode >>> as quickly as possible and off into SSH / VNC. >> >> Despite the coolness factor, IMO a few minutes during install time do >> not justify a new hardware model and a new driver. > > It's more than just coolness factor. There are use cases out there > (www.susestudio.com) that don't want to rely on the guest exporting a > VNC server to the outside just to access graphics. Instead you rely on the guest using virtio-fb. Since we have to make guest modifications, why not go for the simpler ones? > You also want to see boot messages, have a console login screen, virtio-console does that, except for the penguins. Better, since you can scroll back. > be able to debug things without switching between virtio-console and > vnc, etc. etc. Render virtio-console on your vnc session. We do that already, no? (well, the host's vnc session, not the guest's). > The hardware model isn't exactly new either. It's just the next > logical step to a full PV machine using virtio. If the virtio-fb stuff > turns out to be really fast and reliable, I could even imagine it > being the default target for kvm on ppc as well, as we can't switch > resolutions on the fly there atm. > We could with vmware-vga. >> >> Why? the guest will typically have networking when it's set up, so >> it should have network access during install. You can easily use >> slirp redirection and the built-in dhcp server to set this up with >> relatively few hassles. > > That's how I use it right now. It's no fun. > The toolstack should hide the unfun parts. -- Do not meddle in the internals of kernels, for they are subtle and quick to panic. |
|
From: Jun N. <nie...@gm...> - 2009-11-03 07:31:37
|
2009/11/3 Jun Nie <nie...@gm...>:
> pxa: add frame buffer support on pxa168 aspenite platform
>
> Signed-off-by: Jun Nie <nj...@ma...>
> ---
> arch/arm/configs/pxa168_defconfig | 86 ++++++++++++++++++++-
> arch/arm/mach-mmp/aspenite.c | 132 +++++++++++++++++++++++++++++++
> arch/arm/mach-mmp/include/mach/pxa168.h | 8 ++
> arch/arm/mach-mmp/pxa168.c | 3 +
> 4 files changed, 227 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/configs/pxa168_defconfig
> b/arch/arm/configs/pxa168_defconfig
> index db5faea..b736517 100644
> --- a/arch/arm/configs/pxa168_defconfig
> +++ b/arch/arm/configs/pxa168_defconfig
> @@ -509,7 +509,49 @@ CONFIG_UNIX98_PTYS=y
> # CONFIG_R3964 is not set
> # CONFIG_RAW_DRIVER is not set
> # CONFIG_TCG_TPM is not set
> -# CONFIG_I2C is not set
> +CONFIG_I2C=y
> +CONFIG_I2C_BOARDINFO=y
> +# CONFIG_I2C_CHARDEV is not set
> +CONFIG_I2C_HELPER_AUTO=y
> +CONFIG_I2C_ALGOBIT=y
> +
> +#
> +# I2C Hardware Bus support
> +#
> +
> +#
> +# I2C system bus drivers (mostly embedded / system-on-chip)
> +#
> +# CONFIG_I2C_DESIGNWARE is not set
> +CONFIG_I2C_GPIO=y
> +# CONFIG_I2C_OCORES is not set
> +CONFIG_I2C_PXA=y
> +# CONFIG_I2C_PXA_SLAVE is not set
> +# CONFIG_I2C_SIMTEC is not set
> +
> +#
> +# External I2C/SMBus adapter drivers
> +#
> +# CONFIG_I2C_PARPORT_LIGHT is not set
> +# CONFIG_I2C_TAOS_EVM is not set
> +
> +#
> +# Other I2C/SMBus bus drivers
> +#
> +# CONFIG_I2C_PCA_PLATFORM is not set
> +# CONFIG_I2C_STUB is not set
> +
> +#
> +# Miscellaneous I2C Chip support
> +#
> +# CONFIG_DS1682 is not set
> +# CONFIG_SENSORS_PCF8574 is not set
> +# CONFIG_PCF8575 is not set
> +# CONFIG_SENSORS_TSL2550 is not set
> +# CONFIG_I2C_DEBUG_CORE is not set
> +# CONFIG_I2C_DEBUG_ALGO is not set
> +# CONFIG_I2C_DEBUG_BUS is not set
> +# CONFIG_I2C_DEBUG_CHIP is not set
> # CONFIG_SPI is not set
> CONFIG_ARCH_REQUIRE_GPIOLIB=y
> CONFIG_GPIOLIB=y
> @@ -523,6 +565,9 @@ CONFIG_GPIOLIB=y
> #
> # I2C GPIO expanders:
> #
> +# CONFIG_GPIO_MAX732X is not set
> +CONFIG_GPIO_PCA953X=y
> +# CONFIG_GPIO_PCF857X is not set
>
> #
> # PCI GPIO expanders:
> @@ -578,7 +623,34 @@ CONFIG_SSB_POSSIBLE=y
> #
> # CONFIG_VGASTATE is not set
> # CONFIG_VIDEO_OUTPUT_CONTROL is not set
> -# CONFIG_FB is not set
> +CONFIG_FB=y
> +# CONFIG_FIRMWARE_EDID is not set
> +# CONFIG_FB_DDC is not set
> +# CONFIG_FB_BOOT_VESA_SUPPORT is not set
> +# CONFIG_FB_CFB_FILLRECT is not set
> +# CONFIG_FB_CFB_COPYAREA is not set
> +# CONFIG_FB_CFB_IMAGEBLIT is not set
> +# CONFIG_FB_CFB_REV_PIXELS_IN_BYTE is not set
> +# CONFIG_FB_SYS_FILLRECT is not set
> +# CONFIG_FB_SYS_COPYAREA is not set
> +# CONFIG_FB_SYS_IMAGEBLIT is not set
> +# CONFIG_FB_FOREIGN_ENDIAN is not set
> +# CONFIG_FB_SYS_FOPS is not set
> +# CONFIG_FB_SVGALIB is not set
> +# CONFIG_FB_MACMODES is not set
> +# CONFIG_FB_BACKLIGHT is not set
> +# CONFIG_FB_MODE_HELPERS is not set
> +# CONFIG_FB_TILEBLITTING is not set
> +
> +#
> +# Frame buffer hardware drivers
> +#
> +# CONFIG_FB_S1D13XXX is not set
> +CONFIG_FB_PXA168=y
> +# CONFIG_FB_VIRTUAL is not set
> +# CONFIG_FB_METRONOME is not set
> +# CONFIG_FB_MB862XX is not set
> +# CONFIG_FB_BROADSHEET is not set
> # CONFIG_BACKLIGHT_LCD_SUPPORT is not set
>
> #
> @@ -591,6 +663,16 @@ CONFIG_SSB_POSSIBLE=y
> #
> # CONFIG_VGA_CONSOLE is not set
> CONFIG_DUMMY_CONSOLE=y
> +CONFIG_FRAMEBUFFER_CONSOLE=y
> +CONFIG_FRAMEBUFFER_CONSOLE_DETECT_PRIMARY=y
> +# CONFIG_FRAMEBUFFER_CONSOLE_ROTATION is not set
> +# CONFIG_FONTS is not set
> +CONFIG_FONT_8x8=y
> +CONFIG_FONT_8x16=y
> +CONFIG_LOGO=y
> +# CONFIG_LOGO_LINUX_MONO is not set
> +CONFIG_LOGO_LINUX_VGA16=y
> +CONFIG_LOGO_LINUX_CLUT224=y
> # CONFIG_SOUND is not set
> # CONFIG_HID_SUPPORT is not set
> # CONFIG_USB_SUPPORT is not set
> diff --git a/arch/arm/mach-mmp/aspenite.c b/arch/arm/mach-mmp/aspenite.c
> index b422bb5..76a57dc 100644
> --- a/arch/arm/mach-mmp/aspenite.c
> +++ b/arch/arm/mach-mmp/aspenite.c
> @@ -17,12 +17,14 @@
> #include <linux/mtd/partitions.h>
> #include <linux/mtd/nand.h>
> #include <linux/i2c/pca953x.h>
> +#include <linux/delay.h>
>
> #include <asm/mach-types.h>
> #include <asm/mach/arch.h>
> #include <mach/addr-map.h>
> #include <mach/mfp-pxa168.h>
> #include <mach/pxa168.h>
> +#include <mach/pxa168fb.h>
> #include <mach/gpio.h>
> #include <plat/pxa3xx_nand.h>
> #include <video/pxa168fb.h>
> @@ -66,6 +68,39 @@ static unsigned long common_pin_config[] __initdata = {
> /* UART1 */
> GPIO107_UART1_RXD,
> GPIO108_UART1_TXD,
> +
> +#ifdef CONFIG_FB_PXA168
> + /* LCD */
> + GPIO56_LCD_FCLK_RD,
> + GPIO57_LCD_LCLK_A0,
> + GPIO58_LCD_PCLK_WR,
> + GPIO59_LCD_DENA_BIAS,
> + GPIO60_LCD_DD0,
> + GPIO61_LCD_DD1,
> + GPIO62_LCD_DD2,
> + GPIO63_LCD_DD3,
> + GPIO64_LCD_DD4,
> + GPIO65_LCD_DD5,
> + GPIO66_LCD_DD6,
> + GPIO67_LCD_DD7,
> + GPIO68_LCD_DD8,
> + GPIO69_LCD_DD9,
> + GPIO70_LCD_DD10,
> + GPIO71_LCD_DD11,
> + GPIO72_LCD_DD12,
> + GPIO73_LCD_DD13,
> + GPIO74_LCD_DD14,
> + GPIO75_LCD_DD15,
> +
> + GPIO76_LCD_DD16,
> + GPIO77_LCD_DD17,
> + GPIO78_LCD_DD18,
> + GPIO79_LCD_DD19,
> + GPIO80_LCD_DD20,
> + GPIO81_LCD_DD21,
> + GPIO82_LCD_DD22,
> + GPIO83_LCD_DD23,
> +#endif
> };
>
> static struct smc91x_platdata smc91x_info = {
> @@ -95,6 +130,100 @@ static struct platform_device smc91x_device = {
> .resource = smc91x_resources,
> };
>
> +#ifdef CONFIG_FB_PXA168
> +static u16 tpo_spi_cmdon[] = {
> + 0x080F,
> + 0x0C5F,
> + 0x1017,
> + 0x1420,
> + 0x1808,
> + 0x1c20,
> + 0x2020,
> + 0x2420,
> + 0x2820,
> + 0x2c20,
> + 0x3020,
> + 0x3420,
> + 0x3810,
> + 0x3c10,
> + 0x4010,
> + 0x4415,
> + 0x48aa,
> + 0x4cff,
> + 0x5086,
> + 0x548d,
> + 0x58d4,
> + 0x5cfb,
> + 0x602e,
> + 0x645a,
> + 0x6889,
> + 0x6cfe,
> + 0x705a,
> + 0x749b,
> + 0x78c5,
> + 0x7cff,
> + 0x80f0,
> + 0x84f0,
> + 0x8808,
> +};
> +
> +static u16 tpo_spi_cmdoff[] = {
> + 0x0c5e, //standby
> +};
> +
> +static int tpo_lcd_power(struct pxa168fb_info *fbi, unsigned int
> spi_gpio_cs, unsigned int spi_gpio_reset, int on)
> +{
> + int err = 0;
> + if (on) {
> + if (spi_gpio_reset != -1) {
> + err = gpio_request(spi_gpio_reset, "TPO_LCD_SPI_RESET");
> + if (err) {
> + printk("failed to request GPIO for TPO LCD RESET\n");
> + return err;
> + }
> + gpio_direction_output(spi_gpio_reset, 0);
> + msleep(100);
> + gpio_set_value(spi_gpio_reset, 1);
> + msleep(100);
> + gpio_free(spi_gpio_reset);
> + }
> + return pxa168fb_spi_send(fbi, tpo_spi_cmdon,
> ARRAY_SIZE(tpo_spi_cmdon), spi_gpio_cs, 1);
> + } else
> + return pxa168fb_spi_send(fbi, tpo_spi_cmdoff,
> ARRAY_SIZE(tpo_spi_cmdoff), spi_gpio_cs, 1);
> +}
> +
> +static struct fb_videomode video_modes_aspen[] = {
> + [0] = {
> + .pixclock = 30120,
> + .refresh = 60,
> + .xres = 800,
> + .yres = 480,
> + .hsync_len = 1,
> + .left_margin = 215,
> + .right_margin = 40,
> + .vsync_len = 1,
> + .upper_margin = 34,
> + .lower_margin = 10,
> + .sync = 0,
> + },
> +};
> +
> +struct pxa168fb_mach_info aspenite_lcd_info __initdata = {
> + .id = "Base-aspen",
> + .modes = video_modes_aspen,
> + .num_modes = ARRAY_SIZE(video_modes_aspen),
> + .pix_fmt = PIX_FMT_RGB565,
> + .io_pin_allocation_mode = PIN_MODE_DUMB_24,
> + .dumb_mode = DUMB_MODE_RGB888,
> + .active = 1,
> + .spi_ctrl = CFG_SCLKCNT(2) | CFG_TXBITS(16) | CFG_SPI_SEL(1) |
> CFG_SPI_3W4WB(1) | CFG_SPI_ENA(1),
> + .spi_gpio_cs = GPIO_EXT1(14),
> + .spi_gpio_reset = -1,
> + .pxa168fb_lcd_power = tpo_lcd_power,
> +};
> +
> +#endif
> +
> #if defined(CONFIG_MTD_NAND) || defined(CONFIG_MTD_NAND_MODULE)
> static struct mtd_partition apn_nand_partitions[] = {
> {
> @@ -184,6 +313,9 @@ static void __init common_init(void)
>
> /* on-chip devices */
> pxa168_add_uart(1);
> +#ifdef CONFIG_FB_PXA168
> + pxa168_add_fb(&aspenite_lcd_info);
> +#endif
>
> apn_init_nand();
> pxa168_add_twsi(0, &pwri2c_info, ARRAY_AND_SIZE(aspenite_i2c_board_info));
> diff --git a/arch/arm/mach-mmp/include/mach/pxa168.h
> b/arch/arm/mach-mmp/include/mach/pxa168.h
> index d117ceb..d43fb13 100644
> --- a/arch/arm/mach-mmp/include/mach/pxa168.h
> +++ b/arch/arm/mach-mmp/include/mach/pxa168.h
> @@ -4,6 +4,7 @@
> #include <linux/i2c.h>
> #include <mach/devices.h>
> #include <plat/i2c.h>
> +#include <video/pxa168fb.h>
>
> extern struct pxa_device_desc pxa168_device_uart1;
> extern struct pxa_device_desc pxa168_device_uart2;
> @@ -14,6 +15,7 @@ extern struct pxa_device_desc pxa168_device_pwm2;
> extern struct pxa_device_desc pxa168_device_pwm3;
> extern struct pxa_device_desc pxa168_device_pwm4;
> extern struct pxa_device_desc pxa168_device_nand;
> +extern struct pxa_device_desc pxa168_device_fb;
>
> static inline int pxa168_add_uart(int id)
> {
> @@ -65,4 +67,10 @@ static inline int pxa168_add_pwm(int id)
>
> return pxa_register_device(d, NULL, 0);
> }
> +
> +static inline int pxa168_add_fb(struct pxa168fb_mach_info *mi)
> +{
> + return pxa_register_device(&pxa168_device_fb, mi, sizeof(*mi));
> +}
> +
> #endif /* __ASM_MACH_PXA168_H */
> diff --git a/arch/arm/mach-mmp/pxa168.c b/arch/arm/mach-mmp/pxa168.c
> index 59b393e..8be1e46 100644
> --- a/arch/arm/mach-mmp/pxa168.c
> +++ b/arch/arm/mach-mmp/pxa168.c
> @@ -74,6 +74,7 @@ static APBC_CLK(pwm3, PXA168_PWM3, 1, 13000000);
> static APBC_CLK(pwm4, PXA168_PWM4, 1, 13000000);
>
> static APMU_CLK(nand, NAND, 0x1db, 208000000);
> +static APMU_CLK(lcd, LCD, 0x003f, 312000000);
>
> /* device and clock bindings */
> static struct clk_lookup pxa168_clkregs[] = {
> @@ -86,6 +87,7 @@ static struct clk_lookup pxa168_clkregs[] = {
> INIT_CLKREG(&clk_pwm2, "pxa168-pwm.1", NULL),
> INIT_CLKREG(&clk_pwm3, "pxa168-pwm.2", NULL),
> INIT_CLKREG(&clk_pwm4, "pxa168-pwm.3", NULL),
> + INIT_CLKREG(&clk_lcd, "pxa168-fb", "LCDCLK"),
> };
>
> static int __init pxa168_init(void)
> @@ -132,3 +134,4 @@ PXA168_DEVICE(pwm2, "pxa168-pwm", 1, NONE,
> 0xd401a400, 0x10);
> PXA168_DEVICE(pwm3, "pxa168-pwm", 2, NONE, 0xd401a800, 0x10);
> PXA168_DEVICE(pwm4, "pxa168-pwm", 3, NONE, 0xd401ac00, 0x10);
> PXA168_DEVICE(nand, "pxa3xx-nand", -1, NAND, 0xd4283000, 0x200, 97, 99);
> +PXA168_DEVICE(fb, "pxa168-fb", -1, LCD, 0xd420b000, 0x1c8);
> --
> 1.5.4.3
>
add lin...@vg...
|
|
From: Jun N. <nie...@gm...> - 2009-11-03 07:31:05
|
2009/11/3 Jun Nie <nie...@gm...>:
> pxa: add gpio expander on pxa168 aspenite platform
>
> Signed-off-by: Jun Nie <nj...@ma...>
> ---
> arch/arm/mach-mmp/aspenite.c | 45 ++++++++++++++++++++++++++++++++++++++++++
> drivers/gpio/pca953x.c | 1 +
> 2 files changed, 46 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/mach-mmp/aspenite.c b/arch/arm/mach-mmp/aspenite.c
> index 115f728..b422bb5 100644
> --- a/arch/arm/mach-mmp/aspenite.c
> +++ b/arch/arm/mach-mmp/aspenite.c
> @@ -16,6 +16,7 @@
> #include <linux/mtd/mtd.h>
> #include <linux/mtd/partitions.h>
> #include <linux/mtd/nand.h>
> +#include <linux/i2c/pca953x.h>
>
> #include <asm/mach-types.h>
> #include <asm/mach/arch.h>
> @@ -24,9 +25,14 @@
> #include <mach/pxa168.h>
> #include <mach/gpio.h>
> #include <plat/pxa3xx_nand.h>
> +#include <video/pxa168fb.h>
>
> #include "common.h"
>
> +/*used by expander max7312, 16 pins gpio expander */
> +#define GPIO_EXT0(x) (NR_BUILTIN_GPIO + (x))
> +#define GPIO_EXT1(x) (NR_BUILTIN_GPIO + 16 + (x))
> +
> static unsigned long common_pin_config[] __initdata = {
> /* Data Flash Interface */
> GPIO0_DFI_D15,
> @@ -134,6 +140,44 @@ static void __init apn_init_nand(void)
> static void __init apn_init_nand(void) {}
> #endif
>
> +static struct i2c_pxa_platform_data pwri2c_info __initdata = {
> + .use_pio = 1,
> +};
> +
> +#if defined(CONFIG_GPIO_PCA953X)
> +/* GPIO expander max7312 could reuse PCA953X */
> +static struct pca953x_platform_data max7312_data[] = {
> + /* two max7312 in system */
> +
> + [0] = {
> + .gpio_base = GPIO_EXT0(0),
> + },
> +
> + [1] = {
> + .gpio_base = GPIO_EXT1(0),
> + },
> +};
> +#endif
> +
> +static struct i2c_board_info aspenite_i2c_board_info[] = {
> +
> +#if defined(CONFIG_GPIO_PCA953X)
> + {
> + .type = "max7312",
> + .addr = 0x10, /* 0x20/0x21 */
> + .irq = IRQ_GPIO(122),
> + .platform_data = &max7312_data[0],
> + },
> +
> + {
> + .type = "max7312",
> + .addr = 0x20, /* 0x40/0x41 */
> + .irq = IRQ_GPIO(120),
> + .platform_data = &max7312_data[1],
> + },
> +#endif
> +};
> +
> static void __init common_init(void)
> {
> mfp_config(ARRAY_AND_SIZE(common_pin_config));
> @@ -142,6 +186,7 @@ static void __init common_init(void)
> pxa168_add_uart(1);
>
> apn_init_nand();
> + pxa168_add_twsi(0, &pwri2c_info, ARRAY_AND_SIZE(aspenite_i2c_board_info));
>
> /* off-chip devices */
> platform_device_register(&smc91x_device);
> diff --git a/drivers/gpio/pca953x.c b/drivers/gpio/pca953x.c
> index 6a2fb3f..7822684 100644
> --- a/drivers/gpio/pca953x.c
> +++ b/drivers/gpio/pca953x.c
> @@ -39,6 +39,7 @@ static const struct i2c_device_id pca953x_id[] = {
> { "pca9557", 8, },
>
> { "max7310", 8, },
> + { "max7312", 16, },
> { "max7315", 8, },
> { "pca6107", 8, },
> { "tca6408", 8, },
> --
> 1.5.4.3
>
add lin...@vg...
|
754 messages has been excluded from this view by a project administrator.
