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 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
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
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 get the
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
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 a
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"
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
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
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
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 certainly don't
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 time.
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?
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
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
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,
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.
>
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
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
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
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
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
> 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
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.
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
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()
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
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 on a
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.
What
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.
There
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 it drives.
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, similar to
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 with
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
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
36 matches
Mail list logo
