[PATCH 0/22] Make SVGA oriented FBs work on multi-domain PCI

[PATCH 0/22] Make SVGA oriented FBs work on multi-domain PCI

[David Miller]

This patch set makes sure that FB drivers for PCI devices utilizing
the svgalib interfaces work on multi-domain PCI architectures.

Basically this amounts to making sure that the vgastate->vgabase
__iomem pointer makes it way into every interfaces and gets used
by all of the I/O access calls.

All of arkfb, s3fb, and vt8623fb have been converted.

Signed-off-by: David S. Miller <davem@davemloft.net>

Re: [PATCH 0/22] Make SVGA oriented FBs work on multi-domain PCI

[Alex Buell]

On Tue, 2011-01-11 at 15:48 -0800, David Miller wrote:

> This patch set makes sure that FB drivers for PCI devices utilizing
> the svgalib interfaces work on multi-domain PCI architectures.
> 
> Basically this amounts to making sure that the vgastate->vgabase
> __iomem pointer makes it way into every interfaces and gets used
> by all of the I/O access calls.

jeez, that was fast work! I'd already done the changes in s3fb.c but
didn't get as far as you did with this. 

I'm now testing your patches right now.
-- 
Tactical Nuclear Kittens

Re: [PATCH 0/22] Make SVGA oriented FBs work on multi-domain PCI

[David Miller]

From: Alex Buell <alex.buell@munted.org.uk>
Date: Wed, 12 Jan 2011 00:20:50 +0000

> On Tue, 2011-01-11 at 15:48 -0800, David Miller wrote:
> 
>> This patch set makes sure that FB drivers for PCI devices utilizing
>> the svgalib interfaces work on multi-domain PCI architectures.
>> 
>> Basically this amounts to making sure that the vgastate->vgabase
>> __iomem pointer makes it way into every interfaces and gets used
>> by all of the I/O access calls.
> 
> jeez, that was fast work! I'd already done the changes in s3fb.c but
> didn't get as far as you did with this. 
> 
> I'm now testing your patches right now.

Thanks a lot in advance for testing Alex.

Re: [PATCH 0/22] Make SVGA oriented FBs work on multi-domain PCI

[Alex Buell]

On Tue, 2011-01-11 at 16:22 -0800, David Miller wrote:
> From: Alex Buell <alex.buell@munted.org.uk>
> Date: Wed, 12 Jan 2011 00:20:50 +0000
> 
> > On Tue, 2011-01-11 at 15:48 -0800, David Miller wrote:
> > 
> >> This patch set makes sure that FB drivers for PCI devices utilizing
> >> the svgalib interfaces work on multi-domain PCI architectures.
> >> 
> >> Basically this amounts to making sure that the vgastate->vgabase
> >> __iomem pointer makes it way into every interfaces and gets used
> >> by all of the I/O access calls.
> > 
> > jeez, that was fast work! I'd already done the changes in s3fb.c but
> > didn't get as far as you did with this. 
> > 
> > I'm now testing your patches right now.
> 
> Thanks a lot in advance for testing Alex.

With your patches, this happens:

Jan 12 01:24:20 sodium kernel: fb1: S3 Virge/GX on 0000:00:03.0, 6 MB RAM, 14 MHz MCLK
Jan 12 01:24:24 sodium kernel: eth0: Link down, cable problem?
Jan 12 01:24:36 sodium kernel: eth0: Auto-Negotiation unsuccessful, trying force link mode
Jan 12 01:24:45 sodium kernel: eth0: Link down, cable problem?
Jan 12 01:24:47 sodium kernel: ERROR(1): Cheetah error trap taken afsr[0010100000000000] afar[00000000000a0000] TL1(0)
Jan 12 01:24:47 sodium kernel: ERROR(1): TPC[1057490c] TNPC[10574910] O7[80] TSTATE[9911001600]
Jan 12 01:24:47 sodium kernel: ERROR(1): TPC<restore_vga+0x8c0/0x1068 [vgastate]>
Jan 12 01:24:47 sodium kernel: ERROR(1): M_SYND(0),  E_SYND(0), Privileged
Jan 12 01:24:47 sodium kernel: ERROR(1): Highest priority error (0000100000000000) "Unmapped error from system bus"
Jan 12 01:24:47 sodium kernel: ERROR(1): D-cache idx[0] tag[0000000000000000] utag[0000000000000000] stag[0000000000000000]
Jan 12 01:24:47 sodium kernel: ERROR(1): D-cache data0[0000000000000000] data1[0000000000000000] data2[0000000000000000] data3[0000000000000000]
Jan 12 01:24:47 sodium kernel: ERROR(1): I-cache idx[0] tag[0000000000000000] utag[0000000000000000] stag[0000000000000000] u[0000000000000000] l[0000000000000000]
Jan 12 01:24:47 sodium kernel: ERROR(1): I-cache INSN0[0000000000000000] INSN1[0000000000000000] INSN2[0000000000000000] INSN3[0000000000000000]
Jan 12 01:24:47 sodium kernel: ERROR(1): I-cache INSN4[0000000000000000] INSN5[0000000000000000] INSN6[0000000000000000] INSN7[0000000000000000]
Jan 12 01:24:47 sodium kernel: ERROR(1): E-cache idx[a0000] tag[0000000001000049]
Jan 12 01:24:47 sodium kernel: ERROR(1): E-cache data0[82006c3080a08001] data1[1268001b03001c87] data2[25002050f05c24d0] data3[230021f8e65861e0]
Jan 12 01:24:47 sodium kernel: Kernel panic - not syncing: Irrecoverable deferred error trap.
Jan 12 01:24:47 sodium kernel: 
Jan 12 01:24:47 sodium kernel: sym0: SCSI BUS reset detected.
Jan 12 01:24:47 sodium kernel: sym0: SCSI BUS has been reset.
Jan 12 01:24:47 sodium kernel: Call Trace:
Jan 12 01:24:47 sodium kernel: [00000000004292d0] cheetah_deferred_handler+0x494/0x4cc
Jan 12 01:24:47 sodium kernel: [0000000000405e70] c_deferred+0x18/0x24
Jan 12 01:24:47 sodium kernel: [000000001057490c] restore_vga+0x8c0/0x1068 [vgastate]
Jan 12 01:24:47 sodium kernel: [00000000105b0840] s3fb_release+0x40/0x6c [s3fb]
Jan 12 01:24:47 sodium kernel: [00000000005ca0fc] fb_release+0x24/0x4c
Jan 12 01:24:47 sodium kernel: [00000000004bb8a0] fput+0x118/0x1e0
Jan 12 01:24:47 sodium kernel: [00000000004b9100] filp_close+0x64/0x78
Jan 12 01:24:47 sodium kernel: [00000000004b91a0] SyS_close+0x8c/0xe4
Jan 12 01:24:47 sodium kernel: [0000000000406154] linux_sparc_syscall32+0x34/0x40


-- 
Tactical Nuclear Kittens

Re: [PATCH 0/22] Make SVGA oriented FBs work on multi-domain PCI

[Alex Buell]

On Wed, 2011-01-12 at 01:30 +0000, Alex Buell wrote:
> On Tue, 2011-01-11 at 16:22 -0800, David Miller wrote:
> > From: Alex Buell <alex.buell@munted.org.uk>
> > Date: Wed, 12 Jan 2011 00:20:50 +0000
> > 
> > > On Tue, 2011-01-11 at 15:48 -0800, David Miller wrote:
> > > 
> > >> This patch set makes sure that FB drivers for PCI devices utilizing
> > >> the svgalib interfaces work on multi-domain PCI architectures.
> > >> 
> > >> Basically this amounts to making sure that the vgastate->vgabase
> > >> __iomem pointer makes it way into every interfaces and gets used
> > >> by all of the I/O access calls.
> > > 
> > > jeez, that was fast work! I'd already done the changes in s3fb.c but
> > > didn't get as far as you did with this. 
> > > 
> > > I'm now testing your patches right now.
> > 
> > Thanks a lot in advance for testing Alex.
> 
> With your patches, this happens:
> 
> Jan 12 01:24:20 sodium kernel: fb1: S3 Virge/GX on 0000:00:03.0, 6 MB RAM, 14 MHz MCLK
> Jan 12 01:24:24 sodium kernel: eth0: Link down, cable problem?
> Jan 12 01:24:36 sodium kernel: eth0: Auto-Negotiation unsuccessful, trying force link mode
> Jan 12 01:24:45 sodium kernel: eth0: Link down, cable problem?
> Jan 12 01:24:47 sodium kernel: ERROR(1): Cheetah error trap taken afsr[0010100000000000] afar[00000000000a0000] TL1(0)
> Jan 12 01:24:47 sodium kernel: ERROR(1): TPC[1057490c] TNPC[10574910] O7[80] TSTATE[9911001600]
> Jan 12 01:24:47 sodium kernel: ERROR(1): TPC<restore_vga+0x8c0/0x1068 [vgastate]>
> Jan 12 01:24:47 sodium kernel: ERROR(1): M_SYND(0),  E_SYND(0), Privileged
> Jan 12 01:24:47 sodium kernel: ERROR(1): Highest priority error (0000100000000000) "Unmapped error from system bus"
> Jan 12 01:24:47 sodium kernel: ERROR(1): D-cache idx[0] tag[0000000000000000] utag[0000000000000000] stag[0000000000000000]
> Jan 12 01:24:47 sodium kernel: ERROR(1): D-cache data0[0000000000000000] data1[0000000000000000] data2[0000000000000000] data3[0000000000000000]
> Jan 12 01:24:47 sodium kernel: ERROR(1): I-cache idx[0] tag[0000000000000000] utag[0000000000000000] stag[0000000000000000] u[0000000000000000] l[0000000000000000]
> Jan 12 01:24:47 sodium kernel: ERROR(1): I-cache INSN0[0000000000000000] INSN1[0000000000000000] INSN2[0000000000000000] INSN3[0000000000000000]
> Jan 12 01:24:47 sodium kernel: ERROR(1): I-cache INSN4[0000000000000000] INSN5[0000000000000000] INSN6[0000000000000000] INSN7[0000000000000000]
> Jan 12 01:24:47 sodium kernel: ERROR(1): E-cache idx[a0000] tag[0000000001000049]
> Jan 12 01:24:47 sodium kernel: ERROR(1): E-cache data0[82006c3080a08001] data1[1268001b03001c87] data2[25002050f05c24d0] data3[230021f8e65861e0]
> Jan 12 01:24:47 sodium kernel: Kernel panic - not syncing: Irrecoverable deferred error trap.
> Jan 12 01:24:47 sodium kernel: 
> Jan 12 01:24:47 sodium kernel: sym0: SCSI BUS reset detected.
> Jan 12 01:24:47 sodium kernel: sym0: SCSI BUS has been reset.
> Jan 12 01:24:47 sodium kernel: Call Trace:
> Jan 12 01:24:47 sodium kernel: [00000000004292d0] cheetah_deferred_handler+0x494/0x4cc
> Jan 12 01:24:47 sodium kernel: [0000000000405e70] c_deferred+0x18/0x24
> Jan 12 01:24:47 sodium kernel: [000000001057490c] restore_vga+0x8c0/0x1068 [vgastate]
> Jan 12 01:24:47 sodium kernel: [00000000105b0840] s3fb_release+0x40/0x6c [s3fb]
> Jan 12 01:24:47 sodium kernel: [00000000005ca0fc] fb_release+0x24/0x4c
> Jan 12 01:24:47 sodium kernel: [00000000004bb8a0] fput+0x118/0x1e0
> Jan 12 01:24:47 sodium kernel: [00000000004b9100] filp_close+0x64/0x78
> Jan 12 01:24:47 sodium kernel: [00000000004b91a0] SyS_close+0x8c/0xe4
> Jan 12 01:24:47 sodium kernel: [0000000000406154] linux_sparc_syscall32+0x34/0x40
> 
> 

I just found the problem. Here's a patch that makes the s3fb  driver
work. Haven't seen any output on the device yet that's to come later.
Here's a quick patch:

--- s3fb.c.orig 2011-01-12 02:09:47.339553002 +0000
+++ s3fb.c      2011-01-12 02:10:01.411553002 +0000
@@ -383,7 +383,7 @@
 
                memset(&(par->state), 0, sizeof(struct vgastate));
                par->state.vgabase = vgabase;
-               par->state.flags = VGA_SAVE_MODE | VGA_SAVE_FONTS |
VGA_SAVE_CMAP;
+               par->state.flags = VGA_SAVE_MODE | VGA_SAVE_CMAP;
                par->state.num_crtc = 0x70;
                par->state.num_seq = 0x20;
                save_vga(&(par->state));

# fbset -i -fb /dev/fb1

mode "640x480-60"
    # D: 25.176 MHz, H: 31.469 kHz, V: 59.942 Hz
    geometry 640 480 640 480 8
    timings 39721 40 24 32 11 96 2
    rgba 8/0,8/0,8/0,0/0
endmode

Frame buffer device information:
    Name        : S3 Virge/GX
    Address     : 0x14000000
    Size        : 6291456
    Type        : PACKED PIXELS
    Visual      : PSEUDOCOLOR
    XPanStep    : 0
    YPanStep    : 0
    YWrapStep   : 0
    LineLength  : 0
    Accelerator : No

To get the driver to use /dev/fb1, I had to comment out some code as
well:

/*
        if (! svga_primary_device(dev)) {
                dev_info(&(dev->dev), "ignoring secondary device\n");
                return -ENODEV;
        }
*/

-- 
Tactical Nuclear Kittens

Re: [PATCH 0/22] Make SVGA oriented FBs work on multi-domain PCI

[David Miller]

From: Alex Buell <alex.buell@munted.org.uk>
Date: Wed, 12 Jan 2011 02:14:59 +0000

> I just found the problem. Here's a patch that makes the s3fb  driver
> work. Haven't seen any output on the device yet that's to come later.
> Here's a quick patch:
> 
> --- s3fb.c.orig 2011-01-12 02:09:47.339553002 +0000
> +++ s3fb.c      2011-01-12 02:10:01.411553002 +0000
> @@ -383,7 +383,7 @@
>  
>                 memset(&(par->state), 0, sizeof(struct vgastate));
>                 par->state.vgabase = vgabase;
> -               par->state.flags = VGA_SAVE_MODE | VGA_SAVE_FONTS |
> VGA_SAVE_CMAP;
> +               par->state.flags = VGA_SAVE_MODE | VGA_SAVE_CMAP;
>                 par->state.num_crtc = 0x70;
>                 par->state.num_seq = 0x20;
>                 save_vga(&(par->state));

Hmmm, while this change is correct, restore_vga() should skip VGA_SAVE_FONTS
if state->membase is zero, which it ought ot be here.  If state->membase
is zero, then ioremap() will return NULL.  If ioremap() returns NULL then
restore_vga() should cleanup and return 1.

Oh... I see what is happening.  save_vga() sets this value using it's
own heuristics, when VGA_SAVE_FONTS is set, but in a way that won't
work in multi-domain PCI situations.

So we need to set this up in the drivers just like we do for the
'vgabase' member.

I'll work on some patches to fix this.

Thanks.

Re: [PATCH 0/22] Make SVGA oriented FBs work on multi-domain PCI

[David Miller]

From: David Miller <davem@davemloft.net>
Date: Tue, 11 Jan 2011 18:29:45 -0800 (PST)

> Oh... I see what is happening.  save_vga() sets this value using it's
> own heuristics, when VGA_SAVE_FONTS is set, but in a way that won't
> work in multi-domain PCI situations.
> 
> So we need to set this up in the drivers just like we do for the
> 'vgabase' member.
> 
> I'll work on some patches to fix this.

Alex, give this a try.

Re: [PATCH 0/22] Make SVGA oriented FBs work on multi-domain PCI

[David Miller]

From: David Miller <davem@davemloft.net>
Date: Tue, 11 Jan 2011 20:27:19 -0800 (PST)

> From: David Miller <davem@davemloft.net>
> Date: Tue, 11 Jan 2011 18:29:45 -0800 (PST)
> 
>> Oh... I see what is happening.  save_vga() sets this value using it's
>> own heuristics, when VGA_SAVE_FONTS is set, but in a way that won't
>> work in multi-domain PCI situations.
>> 
>> So we need to set this up in the drivers just like we do for the
>> 'vgabase' member.
>> 
>> I'll work on some patches to fix this.
> 
> Alex, give this a try.

Sorry, forgot the patch, here it is :-)

diff --git a/drivers/video/arkfb.c b/drivers/video/arkfb.c
index f63fdf7..3b2f6f5 100644
--- a/drivers/video/arkfb.c
+++ b/drivers/video/arkfb.c
@@ -535,13 +535,13 @@ static int arkfb_open(struct fb_info *info, int user)
 
 	mutex_lock(&(par->open_lock));
 	if (par->ref_count = 0) {
-		void __iomem *vgabase = par->state.vgabase;
-
-		memset(&(par->state), 0, sizeof(struct vgastate));
-		par->state.vgabase = vgabase;
 		par->state.flags = VGA_SAVE_MODE | VGA_SAVE_FONTS | VGA_SAVE_CMAP;
+		par->state.depth = 0;
+		par->state.num_attr = 0;
 		par->state.num_crtc = 0x60;
+		par->state.num_gfx = 0;
 		par->state.num_seq = 0x30;
+		par->state.vidstate = NULL;
 		save_vga(&(par->state));
 	}
 
@@ -947,12 +947,36 @@ static struct fb_ops arkfb_ops = {
 
 /* ------------------------------------------------------------------------- */
 
+static void __devinit ark_init_vgastate(struct pci_dev *dev, struct vgastate *state)
+{
+	struct pci_bus_region bus_reg;
+	struct resource vga_res;
+
+	bus_reg.start = 0;
+	bus_reg.end = 64 * 1024;
+
+	memset(&vga_res, 0, sizeof(vga_res));
+	vga_res.flags = IORESOURCE_IO;
+
+	pcibios_bus_to_resource(dev, &vga_res, &bus_reg);
+
+	state->vgabase = (void __iomem *) vga_res.start;
+
+	bus_reg.start = 0xa0000;
+	bus_reg.end = bus_reg.start + (8 * 8192);
+
+	memset(&vga_res, 0, sizeof(vga_res));
+	vga_res.flags = IORESOURCE_MEM;
+
+	pcibios_bus_to_resource(dev, &vga_res, &bus_reg);
+
+	state->membase = vga_res.start;
+	state->memsize = 8 * 8192;
+}
 
 /* PCI probe */
 static int __devinit ark_pci_probe(struct pci_dev *dev, const struct pci_device_id *id)
 {
-	struct pci_bus_region bus_reg;
-	struct resource vga_res;
 	struct fb_info *info;
 	struct arkfb_info *par;
 	int rc;
@@ -1008,14 +1032,7 @@ static int __devinit ark_pci_probe(struct pci_dev *dev, const struct pci_device_
 		goto err_iomap;
 	}
 
-	bus_reg.start = 0;
-	bus_reg.end = 64 * 1024;
-
-	vga_res.flags = IORESOURCE_IO;
-
-	pcibios_bus_to_resource(dev, &vga_res, &bus_reg);
-
-	par->state.vgabase = (void __iomem *) vga_res.start;
+	ark_init_vgastate(dev, &par->state);
 
 	/* FIXME get memsize */
 	regval = vga_rseq(par->state.vgabase, 0x10);
diff --git a/drivers/video/s3fb.c b/drivers/video/s3fb.c
index 64ef7b3..4b8f215 100644
--- a/drivers/video/s3fb.c
+++ b/drivers/video/s3fb.c
@@ -379,13 +379,13 @@ static int s3fb_open(struct fb_info *info, int user)
 
 	mutex_lock(&(par->open_lock));
 	if (par->ref_count = 0) {
-		void __iomem *vgabase = par->state.vgabase;
-
-		memset(&(par->state), 0, sizeof(struct vgastate));
-		par->state.vgabase = vgabase;
 		par->state.flags = VGA_SAVE_MODE | VGA_SAVE_FONTS | VGA_SAVE_CMAP;
+		par->state.depth = 0;
+		par->state.num_attr = 0;
 		par->state.num_crtc = 0x70;
+		par->state.num_gfx = 0;
 		par->state.num_seq = 0x20;
+		par->state.vidstate = NULL;
 		save_vga(&(par->state));
 	}
 
@@ -929,13 +929,37 @@ static int __devinit s3_identification(struct s3fb_info *par)
 	return CHIP_UNKNOWN;
 }
 
+static void __devinit s3fb_init_vgastate(struct pci_dev *dev, struct vgastate *state)
+{
+	struct pci_bus_region bus_reg;
+	struct resource vga_res;
+
+	bus_reg.start = 0;
+	bus_reg.end = 64 * 1024;
+
+	memset(&vga_res, 0, sizeof(vga_res));
+	vga_res.flags = IORESOURCE_IO;
+
+	pcibios_bus_to_resource(dev, &vga_res, &bus_reg);
+
+	state->vgabase = (void __iomem *) vga_res.start;
+
+	bus_reg.start = 0xa0000;
+	bus_reg.end = bus_reg.start + (8 * 8192);
+
+	memset(&vga_res, 0, sizeof(vga_res));
+	vga_res.flags = IORESOURCE_MEM;
+
+	pcibios_bus_to_resource(dev, &vga_res, &bus_reg);
+
+	state->membase = vga_res.start;
+	state->memsize = 8 * 8192;
+}
 
 /* PCI probe */
 
 static int __devinit s3_pci_probe(struct pci_dev *dev, const struct pci_device_id *id)
 {
-	struct pci_bus_region bus_reg;
-	struct resource vga_res;
 	struct fb_info *info;
 	struct s3fb_info *par;
 	int rc;
@@ -985,14 +1009,7 @@ static int __devinit s3_pci_probe(struct pci_dev *dev, const struct pci_device_i
 		goto err_iomap;
 	}
 
-	bus_reg.start = 0;
-	bus_reg.end = 64 * 1024;
-
-	vga_res.flags = IORESOURCE_IO;
-
-	pcibios_bus_to_resource(dev, &vga_res, &bus_reg);
-
-	par->state.vgabase = (void __iomem *) vga_res.start;
+	s3fb_init_vgastate(dev, &par->state);
 
 	/* Unlock regs */
 	cr38 = vga_rcrt(par->state.vgabase, 0x38);
diff --git a/drivers/video/vt8623fb.c b/drivers/video/vt8623fb.c
index 74df7a8..be70c14 100644
--- a/drivers/video/vt8623fb.c
+++ b/drivers/video/vt8623fb.c
@@ -292,13 +292,13 @@ static int vt8623fb_open(struct fb_info *info, int user)
 
 	mutex_lock(&(par->open_lock));
 	if (par->ref_count = 0) {
-		void __iomem *vgabase = par->state.vgabase;
-
-		memset(&(par->state), 0, sizeof(struct vgastate));
-		par->state.vgabase = vgabase;
 		par->state.flags = VGA_SAVE_MODE | VGA_SAVE_FONTS | VGA_SAVE_CMAP;
+		par->state.depth = 0;
+		par->state.num_attr = 0;
 		par->state.num_crtc = 0xA2;
+		par->state.num_gfx = 0;
 		par->state.num_seq = 0x50;
+		par->state.vidstate = NULL;
 		save_vga(&(par->state));
 	}
 
@@ -656,13 +656,37 @@ static struct fb_ops vt8623fb_ops = {
 	.fb_get_caps    = svga_get_caps,
 };
 
+static void __devinit vt8623_init_vgastate(struct pci_dev *dev, struct vgastate *state)
+{
+	struct pci_bus_region bus_reg;
+	struct resource vga_res;
+
+	bus_reg.start = 0;
+	bus_reg.end = 64 * 1024;
+
+	memset(&vga_res, 0, sizeof(vga_res));
+	vga_res.flags = IORESOURCE_IO;
+
+	pcibios_bus_to_resource(dev, &vga_res, &bus_reg);
+
+	state->vgabase = (void __iomem *) vga_res.start;
+
+	bus_reg.start = 0xa0000;
+	bus_reg.end = bus_reg.start + (8 * 8192);
+
+	memset(&vga_res, 0, sizeof(vga_res));
+	vga_res.flags = IORESOURCE_MEM;
+
+	pcibios_bus_to_resource(dev, &vga_res, &bus_reg);
+
+	state->membase = vga_res.start;
+	state->memsize = 8 * 8192;
+}
 
 /* PCI probe */
 
 static int __devinit vt8623_pci_probe(struct pci_dev *dev, const struct pci_device_id *id)
 {
-	struct pci_bus_region bus_reg;
-	struct resource vga_res;
 	struct fb_info *info;
 	struct vt8623fb_info *par;
 	unsigned int memsize1, memsize2;
@@ -721,14 +745,7 @@ static int __devinit vt8623_pci_probe(struct pci_dev *dev, const struct pci_devi
 		goto err_iomap_2;
 	}
 
-	bus_reg.start = 0;
-	bus_reg.end = 64 * 1024;
-
-	vga_res.flags = IORESOURCE_IO;
-
-	pcibios_bus_to_resource(dev, &vga_res, &bus_reg);
-
-	par->state.vgabase = (void __iomem *) vga_res.start;
+	vt8623_init_vgastate(dev, &par->state);
 
 	/* Find how many physical memory there is on card */
 	memsize1 = (vga_rseq(par->state.vgabase, 0x34) + 1) >> 1;

Re: [PATCH 0/22] Make SVGA oriented FBs work on multi-domain PCI

[Ondrej Zary]

On Wednesday 12 January 2011, David Miller wrote:
> This patch set makes sure that FB drivers for PCI devices utilizing
> the svgalib interfaces work on multi-domain PCI architectures.
>
> Basically this amounts to making sure that the vgastate->vgabase
> __iomem pointer makes it way into every interfaces and gets used
> by all of the I/O access calls.
>
> All of arkfb, s3fb, and vt8623fb have been converted.

Great, I was thinking about something like this when looking at s3fb code and 
wondering how it can be extended to work with secondary cards (not 
initialized by BIOS). I'll test this with arkfb and s3fb.

-- 
Ondrej Zary

Re: [PATCH 0/22] Make SVGA oriented FBs work on multi-domain PCI

[Alex Buell]

On Tue, 2011-01-11 at 20:51 -0800, David Miller wrote:
> From: David Miller <davem@davemloft.net>
> Date: Tue, 11 Jan 2011 20:27:19 -0800 (PST)
> 
> > From: David Miller <davem@davemloft.net>
> > Date: Tue, 11 Jan 2011 18:29:45 -0800 (PST)
> > 
> >> Oh... I see what is happening.  save_vga() sets this value using it's
> >> own heuristics, when VGA_SAVE_FONTS is set, but in a way that won't
> >> work in multi-domain PCI situations.
> >> 
> >> So we need to set this up in the drivers just like we do for the
> >> 'vgabase' member.
> >> 
> >> I'll work on some patches to fix this.
> > 
> > Alex, give this a try.
> 
> Sorry, forgot the patch, here it is :-)
> 
> diff --git a/drivers/video/arkfb.c b/drivers/video/arkfb.c

[ snip ]

>  	/* Find how many physical memory there is on card */
>  	memsize1 = (vga_rseq(par->state.vgabase, 0x34) + 1) >> 1;

It's a step in the right direction. With this patch added to the
svgalib/vgastate modules, it doesn't crash as bad as it used to. The
errors in the logs looks like it's accessing the PCI registers, don't
really understand what it's complaining about though:

Jan 12 21:53:10 sodium kernel: fb1: S3 Virge/GX on 0000:00:03.0, 6 MB RAM, 14 MHz MCLK
Jan 12 21:53:18 sodium kernel: eth0: Link down, cable problem?
Jan 12 21:53:27 sodium pci@8,700000: PCI Error, primary error type[Master Abort]
Jan 12 21:53:27 sodium kernel: /pci@8,700pci@8,pci@8,700000: PCter Aborpci@8,700000: PCI Error, primary error type[Master Abort]
Jan 12 21:53:27 sodium kernel: /pci@8,700000: bytemask[0080] was_block(0) space(Memory)
Jan 12 21:53:27 sodium kernel: /pci@8,700000: PCI AFAR [00000000000a00a8]
Jan 12 21:53:27 sodium kernel: /pci@8,700000: PCI Secondary errors [(Master Abort)]
Jan 12 21:53:27 sodium kernel: /pci@8,700000: PCI Error, primary error type[Master Abort]
Jan 12 21:53:27 sodium kernel: /pci@8,700000: bytemask[0040] was_block(0) space(Memory)
Jan 12 21:53:27 sodium kernel: /pci@8,700000: PCI AFAR [00000000000a00b8]
Jan 12 21:53:27 sodium kernel: /pci@8,700000: PCI Secondary errors [(Master Abort)]
Jan 12 21:53:27 sodium kernel: /pci@8,700000: PCI Error, primary error type[Master Abort]
Jan 12 21:53:27 sodium kernel: /pci@8,700000: bytemask[0008] was_block(0) space(Memory)
Jan 12 21:53:27 sodium kernel: /pci@8,700000: PCI AFAR [00000000000a00c8]
Jan 12 21:53:27 sodium kernel: /pci@8,700000: PCI Secondary errors [(Master Abort)]
Jan 12 21:53:27 sodium kernel: /pci@8,700000: PCI Error, primary error type[Master Abort]
Jan 12 21:53:27 sodium kernel: /pci@8,700000: bytemask[0004] was_block(0) space(Memory)
Jan 12 21:53:27 sodium kernel: /pci@8,700000: PCI AFAR [00000000000a00d8]
Jan 12 21:53:27 sodium kernel: /pci@8,700000: PCI Secondary errors [(Master Abort)]
Jan 12 21:53:27 sodium kernel: /pci@8,700000: PCI Error, primary error type[Master Abort]
Jan 12 21:53:27 sodium kernel: /pci@8,700000: bytemask[0002] was_block(0) space(Memory)
Jan 12 21:53:27 sodium kernel: /pci@8,700000: PCI AFAR [00000000000a00e8]
Jan 12 21:53:27 sodium kernel: /pci@8,700000: PCI Secondary errors [(Master Abort)]
Jan 12 21:53:27 sodium kernel: /pci@8,700000: PCI Error, primary error type[Master Abort]
Jan 12 21:53:27 sodium kernel: /pci@8,700000: bytemask[0080] was_block(0) space(Memory)
Jan 12 21:53:27 sodium kernel: /pci@8,700000: PCI AFAR [00000000000a00f0]
Jan 12 21:53:27 sodium kernel: /pci@8,700000: PCI Secondary errors [(Master Abort)]
Jan 12 21:53:27 sodium kernel: /pci@8,700000: PCI Error, primary error type[Master Abort]
Jan 12 21:53:27 sodium kernel: /pci@8,700000: bytemask[0010] was_block(0) space(Memory)

I simply did the following:

fbset -i -fb /dev/fb1 (which correctly printed the mode information)
fbset -fb /dev/fb1 -g 1024 768 1024 768 8

at this point it crashed, nothing in the logs, not even a
CTRL-ALT-SYSRQ-S/B could get it out of the deep hole it'd dug for
itself. 
-- 
Tactical Nuclear Kittens

Re: [PATCH 0/22] Make SVGA oriented FBs work on multi-domain PCI

[David Miller]

From: Alex Buell <alex.buell@munted.org.uk>
Date: Wed, 12 Jan 2011 23:43:02 +0000

> Jan 12 21:53:27 sodium pci@8,700000: PCI Error, primary error type[Master Abort]
> Jan 12 21:53:27 sodium kernel: /pci@8,700pci@8,pci@8,700000: PCter Aborpci@8,700000: PCI Error, primary error type[Master Abort]
> Jan 12 21:53:27 sodium kernel: /pci@8,700000: bytemask[0080] was_block(0) space(Memory)
> Jan 12 21:53:27 sodium kernel: /pci@8,700000: PCI AFAR [00000000000a00a8]
> Jan 12 21:53:27 sodium kernel: /pci@8,700000: PCI Secondary errors [(Master Abort)]
> Jan 12 21:53:27 sodium kernel: /pci@8,700000: PCI Error, primary error type[Master Abort]

The address we're using seems right, but for some reason the device
is giving a master abort when we try to access the legacy VGA memory.

I did a little bit of research, and there is a bit in the VGA I/O
register set that needs to be set otherwise the VGA card will not
respond to video memory accesses.

Can you test to see if the following patch makes a difference?

diff --git a/drivers/video/s3fb.c b/drivers/video/s3fb.c
index 4b8f215..00152f6 100644
--- a/drivers/video/s3fb.c
+++ b/drivers/video/s3fb.c
@@ -1053,6 +1053,13 @@ static int __devinit s3_pci_probe(struct pci_dev *dev, const struct pci_device_i
 	vga_wcrt(par->state.vgabase, 0x38, cr38);
 	vga_wcrt(par->state.vgabase, 0x39, cr39);
 
+	/* Ensure that the card will respond to legacy VGA memory
+	 * accesses.
+	 */
+	regval = vga_r(par->state.vgabase, VGA_MIS_R);
+	regval |= VGA_MIS_ENB_MEM_ACCESS;
+	vga_w(par->state.vgabase, VGA_MIS_W, regval);
+
 	strcpy(info->fix.id, s3_names [par->chip]);
 	info->fix.mmio_start = 0;
 	info->fix.mmio_len = 0;

Re: [PATCH 0/22] Make SVGA oriented FBs work on multi-domain PCI

[David Miller]

From: Alex Buell <alex.buell@munted.org.uk>
Date: Mon, 17 Jan 2011 13:06:48 +0000

> The module loads OK but generates the following when I run fbset -i
> -fb /dev/fb1
> 
> Jan 17 13:00:54 sodium kernel: [  369.984028] /pci@8,700000: PCI Error,
> primary error type[Master Abort]
> Jan 17 13:00:54 sodium kernel: [  369.984042] /pci@8,700000:
> bytemask[0001] was_block(0) space(Memory)
> Jan 17 13:00:54 sodium kernel: [  369.984049] /pci@8,700000: PCI AFAR
> [00000000000a0000]

Yeah, it's dying the same way as before.

I'm stumped at the moment.

Re: [PATCH 0/22] Make SVGA oriented FBs work on multi-domain PCI

[Alex Buell]

On Fri, 2011-01-21 at 20:11 -0800, David Miller wrote:

> > [00000000000a0000]
> 
> Yeah, it's dying the same way as before.
> 
> I'm stumped at the moment.

I just spotted something. Looking at the above address, it seems to be
0xA0000, same as the high address for accessing VGA memory in a PC.
Perhaps it's still trying to access that whereas on a SUN it may need
remapping to the correct location?
-- 
Tactical Nuclear Kittens

Re: [PATCH 0/22] Make SVGA oriented FBs work on multi-domain PCI

[Ondrej Zary]

On Wednesday 12 January 2011 00:48:46 David Miller wrote:
> This patch set makes sure that FB drivers for PCI devices utilizing
> the svgalib interfaces work on multi-domain PCI architectures.
>
> Basically this amounts to making sure that the vgastate->vgabase
> __iomem pointer makes it way into every interfaces and gets used
> by all of the I/O access calls.
>
> All of arkfb, s3fb, and vt8623fb have been converted.
>
> Signed-off-by: David S. Miller <davem@davemloft.net>

Just tested arkfb and s3fb and they seem to still work fine (on x86) with 
these changes.

-- 
Ondrej Zary

Re: [PATCH 0/22] Make SVGA oriented FBs work on multi-domain PCI

[Alex Buell]

On Thu, 2011-02-17 at 00:01 +0100, Ondrej Zary wrote:
> > Signed-off-by: David S. Miller <davem@davemloft.net>
> 
> Just tested arkfb and s3fb and they seem to still work fine (on x86)
> with these changes. 

Hmm, that's odd. The exact same driver with the updates crashes on sparc
hardware. So far, I've not been able to figure out why it does.
-- 
Tactical Nuclear Kittens

Re: [PATCH 0/22] Make SVGA oriented FBs work on multi-domain PCI

[David Miller]

From: Alex Buell <alex.buell@munted.org.uk>
Date: Wed, 16 Feb 2011 23:21:20 +0000

> On Thu, 2011-02-17 at 00:01 +0100, Ondrej Zary wrote:
>> > Signed-off-by: David S. Miller <davem@davemloft.net>
>> 
>> Just tested arkfb and s3fb and they seem to still work fine (on x86)
>> with these changes. 
> 
> Hmm, that's odd. The exact same driver with the updates crashes on sparc
> hardware. So far, I've not been able to figure out why it does.

We know why it does, because sparc systems do not initialize the VGA
hardware in the BIOS the way a PC will.

That's the whole gist of the most recent thread we had where we were
trying to diagnose your crashes.

We simply haven't figured out the magic that will get this to work.

So it's perfectly fine and expected that platforms where these drivers
worked before, still work fine.

Re: [PATCH 0/22] Make SVGA oriented FBs work on multi-domain PCI

[Alex Buell]

On Wed, 2011-02-16 at 15:24 -0800, David Miller wrote:
> From: Alex Buell <alex.buell@munted.org.uk>
> Date: Wed, 16 Feb 2011 23:21:20 +0000
> 
> > On Thu, 2011-02-17 at 00:01 +0100, Ondrej Zary wrote:
> >> > Signed-off-by: David S. Miller <davem@davemloft.net>
> >> 
> >> Just tested arkfb and s3fb and they seem to still work fine (on x86)
> >> with these changes. 
> > 
> > Hmm, that's odd. The exact same driver with the updates crashes on sparc
> > hardware. So far, I've not been able to figure out why it does.
> 
> We know why it does, because sparc systems do not initialize the VGA
> hardware in the BIOS the way a PC will.
> 
> That's the whole gist of the most recent thread we had where we were
> trying to diagnose your crashes.
> 
> We simply haven't figured out the magic that will get this to work.
> 
> So it's perfectly fine and expected that platforms where these drivers
> worked before, still work fine.

OK, I'd forgotten that the VGA hardware needs initialising. 
-- 
Tactical Nuclear Kittens

Re: [PATCH 0/22] Make SVGA oriented FBs work on multi-domain PCI

[Ondrej Zary]

On Thursday 17 February 2011, Alex Buell wrote:
> On Wed, 2011-02-16 at 15:24 -0800, David Miller wrote:
> > From: Alex Buell <alex.buell@munted.org.uk>
> > Date: Wed, 16 Feb 2011 23:21:20 +0000
> >
> > > On Thu, 2011-02-17 at 00:01 +0100, Ondrej Zary wrote:
> > >> > Signed-off-by: David S. Miller <davem@davemloft.net>
> > >>
> > >> Just tested arkfb and s3fb and they seem to still work fine (on x86)
> > >> with these changes.
> > >
> > > Hmm, that's odd. The exact same driver with the updates crashes on
> > > sparc hardware. So far, I've not been able to figure out why it does.
> >
> > We know why it does, because sparc systems do not initialize the VGA
> > hardware in the BIOS the way a PC will.
> >
> > That's the whole gist of the most recent thread we had where we were
> > trying to diagnose your crashes.
> >
> > We simply haven't figured out the magic that will get this to work.
> >
> > So it's perfectly fine and expected that platforms where these drivers
> > worked before, still work fine.
>
> OK, I'd forgotten that the VGA hardware needs initialising.

Playing with (at least) S3 initialization is on my todo list.

-- 
Ondrej Zary