Around 11 o'clock on Feb 28, Vladimir Dergachev wrote:
> I agree. For example, on my Dell notebook the graphics card is not
> reinitialized properly on return from resume. At some point I'll get
> bothered enough to write code that does it.
# vbetool post
Run from your suspend script while on
On Mon, 28 Feb 2005, Pavel Machek wrote:
Hi!
I think that the driver is the "chief" here and the one to know what to
do with the cards it drives. It can detect a non-POSTed card and deal
with it.
What about the x86 case of VGA devices that run without a driver being
loaded? Do we force people to l
Hi!
> > I think that the driver is the "chief" here and the one to know what to
> > do with the cards it drives. It can detect a non-POSTed card and deal
> > with it.
>
> What about the x86 case of VGA devices that run without a driver being
> loaded? Do we force people to load an fbdev driver to
On Tue, 22 Feb 2005, Dmitry Torokhov wrote:
>
> This sounds awfully like firmware loader that seems to be working just
> fine for a range of network cards and other devices.
Yes. HOWEVER - and note how firmware loading for this case is not validly
done at device discovery, but at "ifconfig" tim
On Tue, 22 Feb 2005 11:19:10 -0800 (PST), Linus Torvalds
<[EMAIL PROTECTED]> wrote:
>
>
> On Mon, 21 Feb 2005, Jon Smirl wrote:
> >
> > I was working on the assumption that all PCI based, VGA class hardware
> > that is not the boot device needs to be posted.
>
> I don't think that's true. We cer
On Mon, 21 Feb 2005, Jon Smirl wrote:
>
> I was working on the assumption that all PCI based, VGA class hardware
> that is not the boot device needs to be posted.
I don't think that's true. We certainly don't _want_ it to be true in the
long run - and even now there are cards that we can initia
On Tue, 2005-02-22 at 01:52 -0500, Jon Smirl wrote:
> Does the kernel need to keep a bit that says the device has been
> posted, don't do it again?
No. The kernel have no idea about what POSTing means in fact. That is
also driver specific.
> Should removing/inserting a driver cause a repost?
The
Does the kernel need to keep a bit that says the device has been
posted, don't do it again? Should removing/inserting a driver cause a
repost? I was going to add bit in pci_dev that tracks the reset status
so that it will persist across unloads. Do we have code to tell if
hardware needs a reset wit
On Tue, 22 Feb 2005 17:32:40 +1100, Benjamin Herrenschmidt
<[EMAIL PROTECTED]> wrote:
> And even if we did, then we could have the vga "legacy" driver use the
> firmware loader to "boot" them. And again, you seem to dismiss all my
> other arguments...
I'm not dismissing them, I'm in agreement with
On Tue, 2005-02-22 at 01:05 -0500, Jon Smirl wrote:
> On Tue, 22 Feb 2005 16:13:36 +1100, Benjamin Herrenschmidt
> <[EMAIL PROTECTED]> wrote:
> > What we can/should provide, is a ncie helper to do the job once the
> > driver decides to have a go at it. I think userspace is the right
> > solution, s
On Tue, 2005-02-22 at 01:03 -0500, Jon Smirl wrote:
> On Tue, 22 Feb 2005 16:13:36 +1100, Benjamin Herrenschmidt
> <[EMAIL PROTECTED]> wrote:
> > On Mon, 2005-02-21 at 23:56 -0500, Alex Deucher wrote:
> > I think that the driver is the "chief" here and the one to know what to
> > do with the cards
On Tue, 22 Feb 2005 16:13:36 +1100, Benjamin Herrenschmidt
<[EMAIL PROTECTED]> wrote:
> What we can/should provide, is a ncie helper to do the job once the
> driver decides to have a go at it. I think userspace is the right
> solution, similar to the firmware loader helpers, as I wrote earlier.
> T
On Tue, 22 Feb 2005 16:13:36 +1100, Benjamin Herrenschmidt
<[EMAIL PROTECTED]> wrote:
> On Mon, 2005-02-21 at 23:56 -0500, Alex Deucher wrote:
> I think that the driver is the "chief" here and the one to know what to
> do with the cards it drives. It can detect a non-POSTed card and deal
> with it.
On Mon, 2005-02-21 at 23:56 -0500, Alex Deucher wrote:
> 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...
That's implied indeed... though Jon approach would require the common
code to "know" that we are o
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
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 pr
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 look
> 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 cal
18 matches
Mail list logo
