Re: Add a "enable" sysfs attribute to the pci devices to allow userspace (Xorg) to enable devices without doing foul direct access

[Benjamin Herrenschmidt <benh@kernel.crashing.org>]

> By allowing tools to read the rom from the pci device itself, instead of
> whichever device's rom happens to be at 0xC0000.  libx86emul allows you
> to define routines that it uses for memory access, so you can copy the
> ROM out to normal memory, and map that memory to the appropriate address
> that way.  X and vbetool both already have to do this, but without
> copying the firmware image, to do DDC probing on x86_64.
> 
> > I agree with Arjan that the attribute could be useful for some special
> > tools, but using it in X is likely to be utterly wrong.
> 
> I'm actually talking about vbetool here, though X could use these
> methods.  Indeed, libx86emul comes from X itself.

There are reasons why you may have to read the image at c0000... There's
a bunch of laptops where it's in fact the only way to get to the video
BIOS as it doesn't have a ROM attached to the video chip (it's burried
in the main BIOS which thankfully copied it to c0000 when running it).
In some cases, the BISO ROM self-modifies it's c0000 and it's that
modified copy that the X (or fbdev) driver should get. Remeber that
drivers needs access to the ROM for more than just POSTing the chip...

In addition, we need to centralize VGA routing mecanism in the kernel
for other reasons. For example, because it might imply disabling MMIO or
IO access to other cards (currently, we have to disable _all_ other
cards on the same bus segment that claim to be VGA since we have no way
to know which ones might be able to simply be configured not to decode
legacy VGA accesses, though an appropriate arbiter ABI would allow to
handle that too). Thus am fbdev or X server currently running on another
card would explode in flames while something like vbetool is re-routing
VGA access to a card for POST'ing or other things vbetool can do.

It's a shitty problem, it's complicated, but there is no easy way out
thanks to PC manufacturers and Intel keeping absolutely disgusting VGA
"legacy" crap part of the PCI standard for so long.

Note that I posted various prototypes of what a VGA abiter could look
like a while ago. I have no time to resume work on that and my
prototypes weren't perfect, but that's something one interested party
could probably use as a starting point to a more complete solution.
 
Ben.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/