![]() | |||||||||||||
Messages in this thread |
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/ | ||||||||||||
| Last update: 2005-03-22 14:10 [from the cache] ©2003-2008 | |||||||||||||