PCI/BIOS/int10 handling in X.org

[Jon Smirl]

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.

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.

/*
  * 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);

-- 
Jon Smirl
jonsmirl at gmail.com



On 7/15/05, Thomas Winischhofer <thomas at winischhofer.net> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> 
> Since adding XGI support not only to the X driver but also to the Linux
> kernel framebuffer driver, I experimented a little with having two video
> cards in one box.
> 
> The Linux kernel framebuffer driver is capable of POSTing all XGI cards,
> should that be needed (which is judged by D[1:0] of PCI_COMMAND, ie if
> its memory and io resources are enabled or not).
> 
> As soon as two cards have their mem/io enabled, X.org fails to determine
> which of the cards is "primary". All cards are "secondary". This is
> basically understandable... how should it.
> 
> However, this leads to unpleasant side effects:
> 
> 1) Drivers that POST "secondary" cards via int10 during their preinit
> phase, now POST all video cards in the system. That is undesireable for
> the "primary" card as it makes mode restoring impossible.
> 
> 2) On SiS machines, the integrated VGA has no BIOS ROM. The BIOS is
> compressed in the system BIOS and only available as a shadow copy.
> 
> The int10 code, when trying to read the BIOS image, handles cards
> differently depending on whether they are "primary" or "secondary".
> 
> If a card is "primary", the BIOS is assumed at c0000. When secondary,
> the int10 code calls mapPciRom - which fails for such hardware without a
> real ROM; leaving the driver without int10 and, as a consequence,
> without VBE.
> 
> While I have no idea what to do about issue 1), I think the BIOS reading
> code could try a little harder for secondary cards. Especially if the
> entity is PCI, it could check the "PCIR" BIOS data block of apparent
> BIOS images in the c0000-f0000 area and compare the PCI IDs to the ones
> stored in the BIOS... or not?
> 
> What do the experts say?
> 
> 
> 
> - --
> 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
> 
> iD8DBQFC199zzydIRAktyUcRAouEAJ9F08GWoiyMx4D4eSdwGqghgVZPVACcClgY
> vjXXz/rEK4g1FUcYxVsrp5Y=
> =Ll4N
> -----END PGP SIGNATURE-----
> _______________________________________________
> xorg mailing list
> xorg at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/xorg
> 


-- 
Jon Smirl
jonsmirl at gmail.com