Re: POSTing of video cards (WAS: Solo Xgl..)

• Previous message: Dave Airlie: "Re: [Linux-fbdev-devel] Resource management."
• In reply to: Benjamin Herrenschmidt: "POSTing of video cards (WAS: Solo Xgl..)"
• Next in thread: Benjamin Herrenschmidt: "Re: POSTing of video cards (WAS: Solo Xgl..)"
• Reply: Benjamin Herrenschmidt: "Re: POSTing of video cards (WAS: Solo Xgl..)"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

Date:	Mon, 21 Feb 2005 23:56:12 -0500
To: Benjamin Herrenschmidt <benh@kernel.crashing.org>

On Tue, 22 Feb 2005 14:12:48 +1100, Benjamin Herrenschmidt
<benh@kernel.crashing.org> 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 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/

• Previous message: Dave Airlie: "Re: [Linux-fbdev-devel] Resource management."
• In reply to: Benjamin Herrenschmidt: "POSTing of video cards (WAS: Solo Xgl..)"
• Next in thread: Benjamin Herrenschmidt: "Re: POSTing of video cards (WAS: Solo Xgl..)"
• Reply: Benjamin Herrenschmidt: "Re: POSTing of video cards (WAS: Solo Xgl..)"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]