Messages in this thread | | | Subject | Re: POSTing of video cards (WAS: Solo Xgl..) | From | Benjamin Herrenschmidt <> | Date | Tue, 22 Feb 2005 16:09:20 +1100 |
| |
On Mon, 2005-02-21 at 23:42 -0500, Jon Smirl wrote: > On Tue, 22 Feb 2005 14:12:48 +1100, Benjamin Herrenschmidt > <benh@kernel.crashing.org> wrote: > > It's up to each driver to detect wether it's card need to be POSTed or > > not. Anything else would mean infinite breakage. > > Your approach is that it is a per driver problem. I was taking a > different tack and looking at it as a BIOS deficiency that should be > compensated for. There is already code in the kernel for identifying > the boot video device.
Your assumption is rather specific to a given platform... what if you have a card with no ROM (embedded system) but your kernel has a copy of what should be the ROM at hand ? (flash is expensive, heh :)
> I was working on the assumption that all PCI based, VGA class hardware > that is not the boot device needs to be posted.
That isn't the case on all platforms. Also, I like the flexibility of having a userland helper since that doesn't "tie" us to the semantics of an x86 platform & BIOS (we could have an OF emulator too, or whatever binary program provided by the vendor in userspace to reinit the card without having to link that with the kernel).
I think my approach is the most flexible in the long run.
> And that the posting should occur before the drivers are > loaded. In order words the BIOS should have provided initialized > hardware but since it didn't we can apply a fixup in the PCI driver. I > also suspect there may be SCSI disk controller cards that need the > same procedure.
I don't think we have to do these assumptions. It should really be under driver control.
> I have no strong opinions on how to fix the post problem, I just want > to make sure the problem is fully discussed by the relevant people and > a consensus solution is achieved. I'm not sure that all of the core > kernel developers that might be impacted by this have considered all > of the options. I would like to try and get a consensus design and > avoid reimplementing everything ten times.
Agreed.
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/
| |