PCI/BIOS/int10 handling in X.org

[Thomas Winischhofer]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Jon Smirl wrote:
> On the x86 the kernel is recording the boot device for you and it
> supports shadow ROMs. There may need to be a parallel implementation
> for other archs.
> 
> There is also a kernel API for accessing the video ROM that knows
> about the rom being shadowed, see drivers/pci/rom.c. This API is used
> by the radeonfb driver, all fbdev drivers should be converted to it if
> they are going to access the ROM.

My current sisfb already does this.

(OT: Besides, there is a bug in that code. The size of the ROM which is
used to map the area is not checked against the byte from the ROM which
is returned to the called as romsize. I have a case here where this byte
is wrong: It says the BIOS is 64k, but in fact the BIOS is only 32k - as
correctly shown by the pci resource length. You should at least check
that the size info from the BIOS isn't bigger than the size of the area
you mapped. If the caller uses the returned romsize to copy the BIOS
image, this will lead to an Ooops.)


> BenH is working on a very low level system that will reset all of the
> secondary video cards as part of the boot process. This is complex
> since the VROM often use the VGA ports. The PC architecture only
> allows a single active VGA device so this has to be managed by
> changing bus routing and enabling/disabling other cards.


As X.org does when enabling/disabling access...


> /*
>   * Fixup to mark boot BIOS video selected by BIOS before it changes
>  *
>   * From information provided by "Jon Smirl" <jonsmirl at gmail.com>
>  *
>  * The standard boot ROM sequence for an x86 machine uses the BIOS
>  * to select an initial video card for boot display. This boot video 
>  * card will have it's BIOS copied to C0000 in system RAM. 
>  * IORESOURCE_ROM_SHADOW is used to associate the boot video
>  * card with this copy. On laptops this copy has to be used since
>  * the main ROM may be compressed or combined with another image.
>  * See pci_map_rom() for use of this flag. IORESOURCE_ROM_SHADOW
>  * is marked here since the boot video device will be the only enabled
>  * video device at this point.
>  */
> 
> static void __devinit pci_fixup_video(struct pci_dev *pdev)
> {
> 	struct pci_dev *bridge;
> 	struct pci_bus *bus;
> 	u16 config;
> 
> 	if ((pdev->class >> 8) != PCI_CLASS_DISPLAY_VGA)
> 		return;
> 
> 	/* Is VGA routed to us? */
> 	bus = pdev->bus;
> 	while (bus) {
> 		bridge = bus->self;
> 		if (bridge) {
> 			pci_read_config_word(bridge, PCI_BRIDGE_CONTROL,
> 						&config);
> 			if (!(config & PCI_BRIDGE_CTL_VGA))
> 				return;
> 		}
> 		bus = bus->parent;
> 	}
> 	pci_read_config_word(pdev, PCI_COMMAND, &config);
> 	if (config & (PCI_COMMAND_IO | PCI_COMMAND_MEMORY)) {
> 		pdev->resource[PCI_ROM_RESOURCE].flags |= IORESOURCE_ROM_SHADOW;
> 		printk(KERN_DEBUG "Boot video device is %s\n", pci_name(pdev));
> 	}
> }
> DECLARE_PCI_FIXUP_HEADER(PCI_ANY_ID, PCI_ANY_ID, pci_fixup_video);


I know that code. It works nicely (as of 2.6.12; the version in 2.6.11
was bad because it didn't check the io/mem-enabled-bits).

My concern, however, was X.org, not the Linux kernel.

Thomas

- --
Thomas Winischhofer
Vienna/Austria
thomas AT winischhofer DOT net          http://www.winischhofer.net/

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFC2Aa9zydIRAktyUcRAu1UAJ0eWSJb2VcQRwr7tXy2f6AExD+6ngCeLSHn
j2XhkgzCsfpZmVKDUFZAdt0=
=xLRB
-----END PGP SIGNATURE-----