On Tue, 22 Feb 2005 14:12:48 +1100, Benjamin Herrenschmidt <[EMAIL PROTECTED]> wrote: > > > Ben, since I'm not getting any help on LKML maybe you can answer this. > > Secondary cards needs reset. After looking at a bunch of fbdev drivers > > their code assumes the card has been reset when their probe() function > > runs. So this means that we have to run the VBIOS reset before probe > > is called. > > I'm putting back LKML on CC since I intended to reply to your post there > once I got a bit of time. > > No, we can't really do that _before_ probe is called. It's the > responsibility of the driver to do what it needs at probe time or later. > Some drivers need that reset (and not that many in fact), some don't. > > We may provide a "helper" to use from the probe() for that purpose, to > make things easier. > > Wether the reset code is kernel based or userland based, I would avoid > have it run synchronously anyway. If a driver detects that it's card > hasn't been properly initialized by the firmware (and the driver should > be able to detect that), I suggest it's probe routine calls the > appropriate helper, providing it with ways to get to the ROM (in some > case, the same helper will be needed for resume from sleep, and the ROM > may not be the PCI BAR one, but the memory shadow, though that will not > always work afaik). > > Look at the firmware download helper, that's very similar. I want an > asynchronous interface though (that is you get a callback when the reset > is complete or timed out) rather than synchronous since it's wrong to > synchronously rely on userland beeing available (power management, > pre-root mount, etc...) > > > So where can I hook up the call to run the VBIOS up in the kernel? You > > can't trigger it on module load since the module may support multiple > > identical adapters. One adapter may already have the module loaded and > > then a second shows up via hotplug. In this case the module won't get > > loaded again and the second card doesn't get reset. > > > > If using a user space reset program what do you do if the user space > > program is missing or does not complete running? Somehow you have to > > stop the probe function from being called. > > That's ok. We deal with that in the firmware loader code already. Just > timeout or check for errors from call_usermodehelper. You basically run > the user program and wait for it to write a "reply" via sysfs. In fact, > the existing firmware loading facility could be re-used. > > > Another case, you have a card and load the module for it, this causes > > reset. Now unload the module and load it again. This probably should > > not reset the card a second time. You also have to make sure you don't > > reset the primary card. > > It's up to each driver to detect wether it's card need to be POSTed or > not. Anything else would mean infinite breakage. > > > One solution is to track in pci_dev if the card has been reset. This > > preserves the state across module load/unload. I'm then tempted to put > > an in-kernel emu86 (I have a 40K one) into the pci driver. PCI would > > use this to reset the card before calling probe(). If the VBIOS/emu86 > > has an error it simply wouldn't call the probe function. Doing this > > in-kernel makes everything synchronous but GregKH would probably have > > some choice words about the emulator in the PCI driver. > > No, again, it's up to the driver to decide wether it needs to POST or > not (I prefer that to "reset"). I have no preference for the emulator to > be in-kernel or userland. I suppose it's easier in userland, just > re-using the existing infrastructure for firmware loading. >
another advantage of the emulator would be that "PC" vga cards could be used in non-x86 platforms, which I'm sure would be quite popular... Alex - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
