public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: Jon Smirl <jonsmirl@gmail.com>
Cc: Alex Deucher <alexdeucher@gmail.com>,
	Dave Airlie <airlied@linux.ie>,
	dri-devel@lists.sourceforge.net,
	Linux Kernel list <linux-kernel@vger.kernel.org>,
	xorg@lists.freedesktop.org
Subject: Re: POSTing of video cards (WAS: Solo Xgl..)
Date: Tue, 22 Feb 2005 17:57:46 +1100	[thread overview]
Message-ID: <1109055466.5326.99.camel@gaston> (raw)
In-Reply-To: <9e47339105022122526338b2c9@mail.gmail.com>

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 driver should be able to determine that looking at the state of the
device. Things like vgacon may need some massaging, but that is not
something we need to care too much about :)

> 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 without the tracking bit?

That doesn't have room in pci_dev, that only concerns a minority of HW
and I don't think we need to track it accross load/unload.

> On the x86 DRM will run without fbdev loaded. So DRM needs to also be
> able to do the post and well as fbdev. Or we can just leave the old
> drivers alone and only implement this in a merged fbdev/drm driver?

I think we need _at_least_ to make a common "stub" driver for fbdev/drm,
and if possible, only implement that in the merged driver when that
happens. We are talking about the future here. Existing users already
have X happily POST'ing their cards.

> When current X loads it's going to reset the cards again, that may
> stomp anything the driver has set up.

Yes, and X need to be fixed for that, this is _WRONG_, one of the
numerous x86-centric assumptions in X. Note that the fbdev driver is
currently aware that anything can happen to the card when in KD_GRAPHICS
mode (and thus, the driver loses ownership). I restore as much as I need
hopefully when coming back. So we may end up having a non-issue there.
Once we have an Xgl on top of mesa solo, the problem will not happen.

Ben.





  reply	other threads:[~2005-02-22  6:58 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <Pine.LNX.4.58.0502201049480.18753@skynet>
     [not found] ` <4218BAF0.3010603@tungstengraphics.com>
     [not found]   ` <21d7e997050220150030ea5a68@mail.gmail.com>
     [not found]     ` <9e4733910502201542afb35f7@mail.gmail.com>
     [not found]       ` <1108973275.5326.8.camel@gaston>
     [not found]         ` <9e47339105022111082b2023c2@mail.gmail.com>
     [not found]           ` <1109019855.5327.28.camel@gaston>
     [not found]             ` <9e4733910502211717116a4df3@mail.gmail.com>
2005-02-22  3:12               ` POSTing of video cards (WAS: Solo Xgl..) Benjamin Herrenschmidt
2005-02-22  4:42                 ` Jon Smirl
2005-02-22  5:09                   ` Benjamin Herrenschmidt
2005-02-22 19:19                   ` Linus Torvalds
2005-02-22 19:38                     ` Dmitry Torokhov
2005-02-22 20:46                       ` Linus Torvalds
2005-02-22  4:56                 ` Alex Deucher
2005-02-22  5:13                   ` Benjamin Herrenschmidt
2005-02-22  6:03                     ` Jon Smirl
2005-02-22  6:32                       ` Benjamin Herrenschmidt
2005-02-22  6:42                         ` Jon Smirl
2005-02-22  6:52                         ` Jon Smirl
2005-02-22  6:57                           ` Benjamin Herrenschmidt [this message]
2005-02-28 14:36                       ` Pavel Machek
2005-02-28 16:06                         ` Vladimir Dergachev
2005-02-28 16:47                           ` Keith Packard
2005-02-22  6:05                     ` Jon Smirl
2005-02-22  6:34                       ` Benjamin Herrenschmidt

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1109055466.5326.99.camel@gaston \
    --to=benh@kernel.crashing.org \
    --cc=airlied@linux.ie \
    --cc=alexdeucher@gmail.com \
    --cc=dri-devel@lists.sourceforge.net \
    --cc=jonsmirl@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=xorg@lists.freedesktop.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox