On Mon, 2005-02-21 at 23:42 -0500, Jon Smirl wrote: > On Tue, 22 Feb 2005 14:12:48 +1100, Benjamin Herrenschmidt > <[EMAIL PROTECTED]> 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. ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click -- _______________________________________________ Dri-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/dri-devel
