PROBLEM: loading viafb module turns screen to black on VN896

PROBLEM: loading viafb module turns screen to black on VN896

[Julian Wollrath]

[-- Attachment #1: Type: text/plain, Size: 8426 bytes --]

Hi,

since I switched from 2.6.31.8 to 2.6.32.2 loading the viafb module
turns the screen to black, there is no graphic output on the screen anymore.


Kernel version:
Linux version 2.6.32.2

Kernel .config is attached.

The bug didn't appear in the 2.6.31 series.

Output of ver_linux:
Linux Aldoreel 2.6.32.2 #1 SMP PREEMPT Sat Dec 19 17:14:29 CET 2009 i686
GNU/Linux

Gnu C                  4.4.2
Gnu make               3.81
binutils               2.20
util-linux             2.16.2
mount                  support
module-init-tools      3.11
e2fsprogs              1.41.9
pcmciautils            014
Linux C Library        2.10.2
Dynamic linker (ldd)   2.10.2
Procps                 3.2.8
Net-tools              1.60
Kbd                    1.15.1
Sh-utils               8.1
wireless-tools         30
Modules Loaded         viafb i2c_algo_bit ipv6 via drm af_packet
nls_iso8859_1 nls_cp437 fuse snd_hda_codec_conexant snd_hda_intel
snd_hda_codec snd_hwdep snd_pcm_oss snd_mixer_oss snd_pcm snd_seq_dummy
snd_seq_oss snd_seq_midi snd_rawmidi snd_seq_midi_event snd_seq ath5k
snd_timer snd_seq_device snd soundcore mac80211 snd_page_alloc shpchp
ath evdev battery psmouse ac pci_hotplug button processor i2c_viapro
ide_cd_mod cdrom sd_mod ata_generic usbhid pata_via sata_via uhci_hcd
via82cxxx libata ehci_hcd via_agp ide_pci_generic ide_core usbcore
via_rhine agpgart thermal fan unix fbcon font bitblit softcursor

/proc/cpuinfo:processor       : 0
vendor_id       : GenuineIntel
cpu family      : 6
model           : 14
model name      : Intel(R) Celeron(R) M CPU        440  @ 1.86GHz
stepping        : 12
cpu MHz         : 1861.982
cache size      : 1024 KB
fdiv_bug        : no
hlt_bug         : no
f00f_bug        : no
coma_bug        : no
fpu             : yes
fpu_exception   : yes
cpuid level     : 10
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge
mca cmov clflush dts acpi mmx fxsr sse sse2 ss tm pbe nx constant_tsc up
arch_perfmon bts aperfmperf pni monitor tm2 xtpr pdcm
bogomips        : 3723.96
clflush size    : 64
cache_alignment : 64
address sizes   : 32 bits physical, 32 bits virtual
power management:

/proc/modules:
viafb 73153 1 - Live 0xdcafa000
i2c_algo_bit 4203 1 viafb, Live 0xdc6d9000
ipv6 221661 8 - Live 0xdca52000
via 35660 0 - Live 0xdcaad000
drm 120248 1 via, Live 0xdcb17000
af_packet 14998 4 - Live 0xdd197000
nls_iso8859_1 2965 1 - Live 0xdcfb0000
nls_cp437 4497 1 - Live 0xdcfa5000
fuse 50108 2 - Live 0xdcf8b000
snd_hda_codec_conexant 18398 1 - Live 0xdcef1000
snd_hda_intel 17702 1 - Live 0xdced4000
snd_hda_codec 47063 2 snd_hda_codec_conexant,snd_hda_intel, Live 0xdceb1000
snd_hwdep 4638 1 snd_hda_codec, Live 0xdce94000
snd_pcm_oss 31869 0 - Live 0xdce80000
snd_mixer_oss 11840 1 snd_pcm_oss, Live 0xdce6a000
snd_pcm 55689 3 snd_hda_intel,snd_hda_codec,snd_pcm_oss, Live 0xdce4a000
snd_seq_dummy 987 0 - Live 0xdce2b000
snd_seq_oss 23246 0 - Live 0xdce1b000
snd_seq_midi 3656 0 - Live 0xdcddd000
snd_rawmidi 14504 1 snd_seq_midi, Live 0xdcdfc000
snd_seq_midi_event 4308 2 snd_seq_oss,snd_seq_midi, Live 0xdcdd6000
snd_seq 39428 6
snd_seq_dummy,snd_seq_oss,snd_seq_midi,snd_seq_midi_event, Live 0xdcdbf000
ath5k 114540 0 - Live 0xdcd89000
snd_timer 14917 2 snd_pcm,snd_seq, Live 0xdcd5a000
snd_seq_device 4137 5
snd_seq_dummy,snd_seq_oss,snd_seq_midi,snd_rawmidi,snd_seq, Live 0xdcd49000
snd 39348 14
snd_hda_codec_conexant,snd_hda_intel,snd_hda_codec,snd_hwdep,snd_pcm_oss,snd_mixer_oss,snd_pcm,snd_seq_oss,snd_rawmidi,snd_seq,snd_timer,snd_seq_device,
Live 0xdcd30000
soundcore 4527 1 snd, Live 0xdcd14000
mac80211 118871 1 ath5k, Live 0xdcce5000
snd_page_alloc 5505 2 snd_hda_intel,snd_pcm, Live 0xdccb3000
ac 2175 0 - Live 0xdcca7000
shpchp 25808 0 - Live 0xdcc89000
battery 7280 0 - Live 0xdcc08000
processor 25534 1 - Live 0xdcc3f000
evdev 6618 10 - Live 0xdcbfa000
ath 6502 1 ath5k, Live 0xdcbed000
button 3585 0 - Live 0xdcbc1000
psmouse 35960 0 - Live 0xdcba6000
pci_hotplug 11098 1 shpchp, Live 0xdcb67000
i2c_viapro 4893 0 - Live 0xdcb58000
sd_mod 23381 6 - Live 0xdcb43000
usbhid 31531 0 - Live 0xdcb0d000
ide_cd_mod 22780 0 - Live 0xdcaf2000
cdrom 29385 1 ide_cd_mod, Live 0xdca40000
ata_generic 2187 0 - Live 0xdca3a000
pata_via 6135 0 - Live 0xdca26000
sata_via 6057 5 - Live 0xdca16000
uhci_hcd 26515 0 - Live 0xdc6c8000
libata 133261 3 ata_generic,pata_via,sata_via, Live 0xdcabf000
ide_pci_generic 1960 0 - Live 0xdcc39000
ehci_hcd 43432 0 - Live 0xdcc24000
via_agp 4892 1 - Live 0xdcc0b000
via82cxxx 4742 0 - Live 0xdcbfe000
ide_core 74443 3 ide_cd_mod,ide_pci_generic,via82cxxx, Live 0xdcb81000
usbcore 127465 4 usbhid,uhci_hcd,ehci_hcd, Live 0xdca8b000
via_rhine 17300 0 - Live 0xdca4b000
agpgart 22363 2 drm,via_agp, Live 0xdca32000
thermal 9246 0 - Live 0xdca1b000
fan 2582 0 - Live 0xdca0d000
unix 19630 210 - Live 0xdca02000
fbcon 33350 72 - Live 0xdc6e3000
font 7004 1 fbcon, Live 0xdc6d0000
bitblit 4238 1 fbcon, Live 0xdc6c4000
softcursor 989 1 bitblit, Live 0xdc6ba000

/proc/ioports:
0000-001f : dma1
0020-0021 : pic1
0022-0022 : ACPI PM2_CNT_BLK
0040-0043 : timer0
0050-0053 : timer1
0060-0060 : keyboard
0064-0064 : keyboard
0070-0075 : rtc0
0080-008f : dma page reg
00a0-00a1 : pic2
00c0-00df : dma2
00f0-00ff : fpu
0170-0177 : 0000:00:0f.1
  0170-0177 : via82cxxx
01f0-01f7 : 0000:00:0f.1
  01f0-01f7 : via82cxxx
0376-0376 : 0000:00:0f.1
  0376-0376 : via82cxxx
03c0-03df : vesafb
03f6-03f6 : 0000:00:0f.1
  03f6-03f6 : via82cxxx
04d0-04d1 : pnp 00:07
0cf8-0cff : PCI conf1
1000-1fff : PCI Bus 0000:02
4000-407f : pnp 00:07
  4000-4003 : ACPI PM1a_EVT_BLK
  4008-400b : ACPI PM_TMR
  4010-4015 : ACPI CPU throttle
  4020-4023 : ACPI GPE0_BLK
  4050-4053 : ACPI GPE1_BLK
4100-411f : pnp 00:07
  4100-4107 : vt596_smbus
6000-6001 : ACPI PM1a_CNT_BLK
6004-6007 : 0000:00:0f.0
  6004-6007 : sata_via
6008-600f : 0000:00:0f.0
  6008-600f : sata_via
6010-601f : 0000:00:0f.0
  6010-601f : sata_via
6020-603f : 0000:00:10.0
  6020-603f : uhci_hcd
6040-605f : 0000:00:10.1
  6040-605f : uhci_hcd
6060-607f : 0000:00:10.2
  6060-607f : uhci_hcd
6080-609f : 0000:00:10.3
  6080-609f : uhci_hcd
60a0-60af : 0000:00:0f.1
  60a0-60af : via82cxxx
60b0-60b3 : 0000:00:0f.0
  60b0-60b3 : sata_via
60b8-60bf : 0000:00:0f.0
  60b8-60bf : sata_via
6400-64ff : 0000:00:0f.0
  6400-64ff : sata_via
6800-68ff : 0000:00:12.0
  6800-68ff : via-rhine
7000-7fff : PCI Bus 0000:03
fe00-fe00 : pnp 00:07
fe10-fe11 : pnp 00:07

/proc/iomem:
00000000-00001fff : System RAM
00002000-00005fff : reserved
00006000-0009dbff : System RAM
0009dc00-0009ffff : reserved
000a0000-000bffff : Video RAM area
000c0000-000cffff : Video ROM
000e0000-000fffff : reserved
  000f0000-000fffff : System ROM
00100000-1be8ffff : System RAM
  01000000-012ea543 : Kernel code
  012ea544-01405897 : Kernel data
  0145f000-014cbbbf : Kernel bss
1be90000-1be9efff : ACPI Tables
1be9f000-1befffff : ACPI Non-volatile Storage
1bf00000-1fffffff : reserved
20000000-201fffff : PCI Bus 0000:02
20200000-203fffff : PCI Bus 0000:02
20400000-205fffff : PCI Bus 0000:03
20600000-206fffff : PCI Bus 0000:05
  20600000-2060ffff : 0000:05:01.0
    20600000-2060ffff : ath5k
a0000000-bfffffff : PCI Bus 0000:01
  a0000000-bfffffff : 0000:01:00.0
    a0000000-a3ffffff : vesafb
c0000000-c7ffffff : 0000:00:00.0
c8000000-c8ffffff : PCI Bus 0000:01
  c8000000-c8ffffff : 0000:01:00.0
c9000000-c90fffff : PCI Bus 0000:03
c9100000-c91fffff : PCI Bus 0000:04
  c9100000-c9103fff : 0000:04:01.0
    c9100000-c9103fff : ICH HD audio
c9400000-c94000ff : 0000:00:10.4
  c9400000-c94000ff : ehci_hcd
c9400400-c94004ff : 0000:00:12.0
  c9400400-c94004ff : via-rhine
e0000000-efffffff : PCI MMCONFIG 0 [00-ff]
  e0000000-efffffff : pnp 00:01
    e0000000-e01010ff : pnp 00:06
      e00100ff-e00190fe : pnp 00:06
      e00700ff-e007a0fe : pnp 00:06
      e00800ff-e00a00fe : pnp 00:06
f0012000-f0012fff : pnp 00:01
f0013000-f0013fff : pnp 00:01
fec00000-fec0ffff : reserved
  fec00000-fec00fff : IOAPIC 0
fecc0000-fecc0fff : IOAPIC 1
fee00000-fee00fff : Local APIC
  fee00000-fee00fff : reserved
ffb80000-ffc7ffff : pnp 00:06
ffee0000-ffefffff : pnp 00:06
fff00000-ffffffff : reserved
  fff00000-ffffffff : pnp 00:06

Output of lspci -vvv is attached.

/proc/scsi/scsi:
Attached devices:
Host: scsi0 Channel: 00 Id: 00 Lun: 00
  Vendor: ATA      Model: ST980811AS       Rev: 3.AL
  Type:   Direct-Access                    ANSI  SCSI revision: 05



With kind regards
Julian Wollrath

[-- Attachment #2: config.bz2 --]
[-- Type: application/octet-stream, Size: 13665 bytes --]

[-- Attachment #3: lspci-vvv.bz2 --]
[-- Type: application/octet-stream, Size: 3909 bytes --]

Re: PROBLEM: loading viafb module turns screen to black on VN896

[Florian Tobias Schandinat]

Hi Julian,

thanks for your feedback.

Julian Wollrath schrieb:
> Hi,
> 
> since I switched from 2.6.31.8 to 2.6.32.2 loading the viafb module
> turns the screen to black, there is no graphic output on the screen anymore.

Did you really use viafb before and if that's the case, how did you load 
the module? (including module parameters)
One change that even confused me is that after exposing the PCI stuff 
the module gets auto loaded and as viafb needs an insane amount of 
parameters to work correctly this lead to the effect you described as it 
didn't get its parameters. So is this problem caused by auto-loading?
If the above does not fit your situation, are you willing to do 
regression testing to figure out which patch to viafb exactly caused the 
behaviour you described?


Thanks,

Florian Tobias Schandinat

Re: PROBLEM: loading viafb module turns screen to black on VN896

[Erik-Jan]

[-- Attachment #1: Type: text/plain, Size: 980 bytes --]

Julian Wollrath wrote:
 > Hi,
 >
 > since I switched from 2.6.31.8 to 2.6.32.2 loading the viafb module
 > turns the screen to black, there is no graphic output on the screen 
anymore.

I had the same sort of problem with CLE266. Only I didn't get a black 
screen, but a scrambled-up screen, as if the timings were wrong.
Not surprisingly, it all has to do with the 2D engine rewrite (around 
commit c3e25673843153ea75fda79a47cf12f10a25ca37) that has been done in 
2.6.32.

I found a few small things in the initialization of the framebuffer, 
that were present in 2.6.31 but removed in 2.6.32.
Attached a patch that puts these changes back in. I don't know if I've 
done some bad things (never done any kernel coding before) nor if it is 
OK for all the different VIA hardware out there, but on my CLE266 it now 
works as before.

The changes to accel.c are needed for a correct boot; the other changes 
are needed for changing the framebuffer mode with fbset.

Bye,
Erik-Jan




[-- Attachment #2: linux-2.6.32.2-viafb.patch --]
[-- Type: text/plain, Size: 2360 bytes --]

diff -Naur linux-2.6.32.2-orig/drivers/video/via/accel.c linux-2.6.32.2/drivers/video/via/accel.c
--- linux-2.6.32.2-orig/drivers/video/via/accel.c	2009-12-31 00:38:03.000000000 +0100
+++ linux-2.6.32.2/drivers/video/via/accel.c	2009-12-31 00:38:23.000000000 +0100
@@ -137,7 +137,7 @@
 			tmp, dst_pitch);
 		return -EINVAL;
 	}
-	tmp = (tmp >> 3) | (dst_pitch << (16 - 3));
+	tmp = VIA_PITCH_ENABLE | (tmp >> 3) | (dst_pitch << (16 - 3));
 	writel(tmp, engine + 0x38);
 
 	if (op == VIA_BITBLT_FILL)
@@ -352,6 +352,9 @@
 	viapar->shared->vq_vram_addr = viapar->fbmem_free;
 	viapar->fbmem_used += VQ_SIZE;
 
+	/* Init 2D engine reg to reset 2D engine */
+	writel(0x0, engine + VIA_REG_KEYCONTROL);
+
 	/* Init AGP and VQ regs */
 	switch (chip_name) {
 	case UNICHROME_K8M890:
diff -Naur linux-2.6.32.2-orig/drivers/video/via/hw.c linux-2.6.32.2/drivers/video/via/hw.c
--- linux-2.6.32.2-orig/drivers/video/via/hw.c	2009-12-18 23:27:07.000000000 +0100
+++ linux-2.6.32.2/drivers/video/via/hw.c	2010-01-01 19:04:30.000000000 +0100
@@ -2348,6 +2348,7 @@
 		}
 	}
 
+	viafb_update_fix(viafbinfo);
 	viafb_set_primary_pitch(viafbinfo->fix.line_length);
 	viafb_set_secondary_pitch(viafb_dual_fb ? viafbinfo1->fix.line_length
 		: viafbinfo->fix.line_length);
diff -Naur linux-2.6.32.2-orig/drivers/video/via/viafbdev.c linux-2.6.32.2/drivers/video/via/viafbdev.c
--- linux-2.6.32.2-orig/drivers/video/via/viafbdev.c	2009-12-18 23:27:07.000000000 +0100
+++ linux-2.6.32.2/drivers/video/via/viafbdev.c	2010-01-01 19:03:21.000000000 +0100
@@ -54,7 +54,7 @@
 static struct fb_ops viafb_ops;
 
 
-static void viafb_update_fix(struct fb_info *info)
+void viafb_update_fix(struct fb_info *info)
 {
 	u32 bpp = info->var.bits_per_pixel;
 
diff -Naur linux-2.6.32.2-orig/drivers/video/via/viafbdev.h linux-2.6.32.2/drivers/video/via/viafbdev.h
--- linux-2.6.32.2-orig/drivers/video/via/viafbdev.h	2009-12-18 23:27:07.000000000 +0100
+++ linux-2.6.32.2/drivers/video/via/viafbdev.h	2010-01-01 19:03:42.000000000 +0100
@@ -99,6 +99,7 @@
 void viafb_fill_var_timing_info(struct fb_var_screeninfo *var, int refresh,
 			  int mode_index);
 int viafb_get_mode_index(int hres, int vres);
+void viafb_update_fix(struct fb_info *info);
 u8 viafb_gpio_i2c_read_lvds(struct lvds_setting_information
 	*plvds_setting_info, struct lvds_chip_information
 	*plvds_chip_info, u8 index);

Re: PROBLEM: loading viafb module turns screen to black on VN896

[Florian Tobias Schandinat]

[-- Attachment #1: Type: text/plain, Size: 1943 bytes --]

Hi,

Erik-Jan schrieb:
> Julian Wollrath wrote:
>  > Hi,
>  >
>  > since I switched from 2.6.31.8 to 2.6.32.2 loading the viafb module
>  > turns the screen to black, there is no graphic output on the screen 
> anymore.
> 
> I had the same sort of problem with CLE266. Only I didn't get a black 
> screen, but a scrambled-up screen, as if the timings were wrong.

Well not exactly the same (initially) as the former one was mainly a new 
supported chip started without the correct parameters.

> Not surprisingly, it all has to do with the 2D engine rewrite (around 
> commit c3e25673843153ea75fda79a47cf12f10a25ca37) that has been done in 
> 2.6.32.
> 
> I found a few small things in the initialization of the framebuffer, 
> that were present in 2.6.31 but removed in 2.6.32.
> Attached a patch that puts these changes back in. I don't know if I've 
> done some bad things (never done any kernel coding before) nor if it is 
> OK for all the different VIA hardware out there, but on my CLE266 it now 
> works as before.

Excellent work!

> The changes to accel.c are needed for a correct boot; the other changes 
> are needed for changing the framebuffer mode with fbset.

Ooh, I really must have been blind to let the later one slip in. But I 
prefer a bit different solution as in 0001-*.patch to not duplicate that 
call (and using info instead of viafbinfo as this is more compatible on 
the way to dual head support). For the first one, well, I do not own 
every VIA hardware especially not all configurations and for the oldest 
ones there isn't even documentation available so I have sometimes rely 
on people testing (ideally -mm so that bugs are caught before they go 
mainline).
The attached patches apply to current -mm
http://userweb.kernel.org/~akpm/mmotm/
If you are okay with them please give them your sign-off as you are the 
original author so that I can forward them to Andrew.


Thanks a lot,

Florian Tobias Schandinat

[-- Attachment #2: 0001-viafb-do-modesetting-after-updating-variables.patch --]
[-- Type: text/x-patch, Size: 1287 bytes --]

From a4d146a3b73da61d026308bef7effc47b71b433b Mon Sep 17 00:00:00 2001
From: Florian Tobias Schandinat <FlorianSchandinat@gmx.de>
Date: Sun, 3 Jan 2010 00:25:15 +0000
Subject: [PATCH 1/2] viafb: do modesetting after updating variables

viafb: do modesetting after updating variables

Reorder viafb_set_par to allow using the updated variables in
viafb_setmode. This fixes a regression that prevented proper
runtime mode changes.

Signed-off-by: Florian Tobias Schandinat <FlorianSchandinat@gmx.de>
---
 drivers/video/via/viafbdev.c |    6 +++---
 1 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/video/via/viafbdev.c b/drivers/video/via/viafbdev.c
index e16df84..f7ff4ea 100644
--- a/drivers/video/via/viafbdev.c
+++ b/drivers/video/via/viafbdev.c
@@ -174,15 +174,15 @@ static int viafb_set_par(struct fb_info *info)
 	}
 
 	if (vmode_entry) {
-		viafb_setmode(vmode_entry, info->var.bits_per_pixel,
-			vmode_entry1, viafb_bpp1);
-
 		viafb_update_fix(info);
 		viafb_bpp = info->var.bits_per_pixel;
 		if (info->var.accel_flags & FB_ACCELF_TEXT)
 			info->flags &= ~FBINFO_HWACCEL_DISABLED;
 		else
 			info->flags |= FBINFO_HWACCEL_DISABLED;
+
+		viafb_setmode(vmode_entry, info->var.bits_per_pixel,
+			vmode_entry1, viafb_bpp1);
 	}
 
 	return 0;
-- 
1.6.3.2


[-- Attachment #3: 0002-viafb-fix-acceleration-for-some-chips.patch --]
[-- Type: text/x-patch, Size: 1460 bytes --]

From 7ad1f2249e7d0d176f3a962d0bae27374f984822 Mon Sep 17 00:00:00 2001
From: Florian Tobias Schandinat <FlorianSchandinat@gmx.de>
Date: Mon, 4 Jan 2010 19:03:48 +0000
Subject: [PATCH 2/2] viafb: fix acceleration for some chips

viafb: fix acceleration for some chips

This patch fixes a regression in hardware acceleration which made the
accelerated framebuffer unusable on some chips. These need extra
initialization and an extra flag which is no longer needed/available
on current chips.

Signed-off-by: Florian Tobias Schandinat <FlorianSchandinat@gmx.de>
---
 drivers/video/via/accel.c |    5 ++++-
 1 files changed, 4 insertions(+), 1 deletions(-)

diff --git a/drivers/video/via/accel.c b/drivers/video/via/accel.c
index 9d4f3a4..d5077df 100644
--- a/drivers/video/via/accel.c
+++ b/drivers/video/via/accel.c
@@ -137,7 +137,7 @@ static int hw_bitblt_1(void __iomem *engine, u8 op, u32 width, u32 height,
 			tmp, dst_pitch);
 		return -EINVAL;
 	}
-	tmp = (tmp >> 3) | (dst_pitch << (16 - 3));
+	tmp = VIA_PITCH_ENABLE | (tmp >> 3) | (dst_pitch << (16 - 3));
 	writel(tmp, engine + 0x38);
 
 	if (op == VIA_BITBLT_FILL)
@@ -352,6 +352,9 @@ int viafb_init_engine(struct fb_info *info)
 	viapar->shared->vq_vram_addr = viapar->fbmem_free;
 	viapar->fbmem_used += VQ_SIZE;
 
+	/* Init 2D engine reg to reset 2D engine */
+	writel(0x0, engine + VIA_REG_KEYCONTROL);
+
 	/* Init AGP and VQ regs */
 	switch (chip_name) {
 	case UNICHROME_K8M890:
-- 
1.6.3.2

Re: PROBLEM: loading viafb module turns screen to black on VN896

[Erik-Jan]

[-- Attachment #1: Type: text/plain, Size: 2297 bytes --]



Florian Tobias Schandinat wrote:
> Hi,
> 
> Erik-Jan schrieb:
>> Julian Wollrath wrote:
>>  > Hi,
>>  >
>>  > since I switched from 2.6.31.8 to 2.6.32.2 loading the viafb module
>>  > turns the screen to black, there is no graphic output on the screen 
>> anymore.
>>
>> I had the same sort of problem with CLE266. Only I didn't get a black 
>> screen, but a scrambled-up screen, as if the timings were wrong.
> 
> Well not exactly the same (initially) as the former one was mainly a new 
> supported chip started without the correct parameters.
> 
>> Not surprisingly, it all has to do with the 2D engine rewrite (around 
>> commit c3e25673843153ea75fda79a47cf12f10a25ca37) that has been done in 
>> 2.6.32.
>>
>> I found a few small things in the initialization of the framebuffer, 
>> that were present in 2.6.31 but removed in 2.6.32.
>> Attached a patch that puts these changes back in. I don't know if I've 
>> done some bad things (never done any kernel coding before) nor if it 
>> is OK for all the different VIA hardware out there, but on my CLE266 
>> it now works as before.
> 
> Excellent work!

Thanks.

> 
>> The changes to accel.c are needed for a correct boot; the other 
>> changes are needed for changing the framebuffer mode with fbset.
> 
> Ooh, I really must have been blind to let the later one slip in. But I 
> prefer a bit different solution as in 0001-*.patch to not duplicate that 
> call (and using info instead of viafbinfo as this is more compatible on 
> the way to dual head support). For the first one, well, I do not own 
> every VIA hardware especially not all configurations and for the oldest 
> ones there isn't even documentation available so I have sometimes rely 
> on people testing (ideally -mm so that bugs are caught before they go 
> mainline).
> The attached patches apply to current -mm
> http://userweb.kernel.org/~akpm/mmotm/

The 0001 didn't apply to -mm or to 2.6.32.2, so I've created a 
0001b-version that does. See attachment.

> If you are okay with them please give them your sign-off as you are the 
> original author so that I can forward them to Andrew.
> 

Tested with both 2.6.32.2 and mmotm (DATE=2009-12-10-17-19) and it works.
Signed-off-by: Erik-Jan Post <ej.lfs@xs4all.nl>

> 
> Thanks a lot,
> 
> Florian Tobias Schandinat
> 

[-- Attachment #2: 0001b-viafb-do-modesetting-after-updating-variables.patch --]
[-- Type: text/plain, Size: 1502 bytes --]

From a4d146a3b73da61d026308bef7effc47b71b433b Mon Sep 17 00:00:00 2001
From: Florian Tobias Schandinat <FlorianSchandinat@gmx.de>
Date: Sun, 3 Jan 2010 00:25:15 +0000
Subject: [PATCH 1/2] viafb: do modesetting after updating variables

viafb: do modesetting after updating variables

Reorder viafb_set_par to allow using the updated variables in
viafb_setmode. This fixes a regression that prevented proper
runtime mode changes.

Signed-off-by: Erik-Jan Post <ej.lfs@xs4all.nl>
Signed-off-by: Florian Tobias Schandinat <FlorianSchandinat@gmx.de>
---
 drivers/video/via/viafbdev.c |    6 +++---
 1 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/video/via/viafbdev.c b/drivers/video/via/viafbdev.c
index e16df84..f7ff4ea 100644
--- a/drivers/video/via/viafbdev.c
+++ b/drivers/video/via/viafbdev.c
@@ -177,16 +177,16 @@ static int viafb_set_par(struct fb_info *info)
 	}
 
 	if (vmode_index != VIA_RES_INVALID) {
-		viafb_setmode(vmode_index, info->var.xres, info->var.yres,
-			info->var.bits_per_pixel, vmode_index1,
-			viafb_second_xres, viafb_second_yres, viafb_bpp1);
-
 		viafb_update_fix(info);
 		viafb_bpp = info->var.bits_per_pixel;
 		if (info->var.accel_flags & FB_ACCELF_TEXT)
 			info->flags &= ~FBINFO_HWACCEL_DISABLED;
 		else
 			info->flags |= FBINFO_HWACCEL_DISABLED;
+
+		viafb_setmode(vmode_index, info->var.xres, info->var.yres,
+			info->var.bits_per_pixel, vmode_index1,
+			viafb_second_xres, viafb_second_yres, viafb_bpp1);
 	}
 
 	return 0;
-- 
1.6.3.2