All of lore.kernel.org
 help / color / mirror / Atom feed
From: Egbert Eich <eich@xfree86.org>
To: Linus Torvalds <torvalds@osdl.org>
Cc: Jon Smirl <jonsmirl@yahoo.com>, Eric Anholt <eta@lclark.edu>,
	<kronos@kronoz.cjb.net>,
	Kernel Mailing List <linux-kernel@vger.kernel.org>,
	<linux-fbdev-devel@lists.sourceforge.net>,
	dri-devel <dri-devel@lists.sourceforge.net>,
	Jeff Garzik <jgarzik@pobox.com>
Subject: Re: [Dri-devel] Re: [Linux-fbdev-devel] DRM and pci_driver conversion
Date: Sat, 25 Oct 2003 19:29:18 +0200	[thread overview]
Message-ID: <16282.45806.428547.279213@zeus.local> (raw)
In-Reply-To: torvalds@osdl.org wrote on Thursday, 23 October 2003 at 16:23:44 -0700

Linus Torvalds writes:
 > > could lead to problems with hotplug.  XFree is also mapping PCI ROMs in without
 > > informing the kernel and that can definitely cause problems.
 > 
 > Absolutely. Changing PCI configurations without telling the kernel _will_ 
 > cause problems. Especially for hotplug systems, but it's also very iffy to 
 > do if the card is behind a PCI bridge, since you have to take bridge 
 > resources into account (and know which bridges are transparent, which are 
 > not, etc etc). 

Speaking of XFree86: when I developed the PCI resource stuff in 
XFree86 I was trying to get support from kernel folks to get the 
appropriate user space interfaces into the kernel. When I got 
nowhere I decided to do everything myself. 
XFree86 does PCI bridge tracking and one reason it does this is PCI
ROM mapping. 
 > 
 > The kernel spends a lot of effort on getting this right, and even so it 
 > fails every once in a while (devices that use IO or memory regions without 
 > announcing them in the standard BAR's are quite common, and the kernel has 
 > to have special quirk entries for things like that).

Right. One reason why the PCI code in XFree86 looks so difficult is
that old ATi Mach?? cards had their 8514 registers (and their mirror
images) scattered all over the PIO space.

 > 
 > Few enough drivers actually want to enable the roms, but the code should 
 > look something like
 > 
 > 	/* Assign space for ROM resource if not already assigned. Ugly. */
 > 	if (!pci_resource_start(dev, PCI_ROM_RESOURCE))
 > 		if (pci_assign_resource(dev, PCI_ROM_RESOURCE) < 0)
 > 			return -ENOMEM;

[Stuff deleted] .....

Is there any API that allows one to do this from user space?
There are plenty of XFree86 drivers around that don't have a
DRM kernel module and it should  be possible to run those which
do without DRI support, therefore it would be a good if the
XFree86 driver could do this registration itself.

Cheers,
	Egbert.

WARNING: multiple messages have this Message-ID (diff)
From: Egbert Eich <eich@xfree86.org>
To: Linus Torvalds <torvalds@osdl.org>
Cc: Jon Smirl <jonsmirl@yahoo.com>, Eric Anholt <eta@lclark.edu>,
	kronos@kronoz.cjb.net,
	Kernel Mailing List <linux-kernel@vger.kernel.org>,
	linux-fbdev-devel@lists.sourceforge.net,
	dri-devel <dri-devel@lists.sourceforge.net>,
	Jeff Garzik <jgarzik@pobox.com>
Subject: Re: [Dri-devel] Re: DRM and pci_driver conversion
Date: Sat, 25 Oct 2003 19:29:18 +0200	[thread overview]
Message-ID: <16282.45806.428547.279213@zeus.local> (raw)
In-Reply-To: torvalds@osdl.org wrote on Thursday, 23 October 2003 at 16:23:44 -0700

Linus Torvalds writes:
 > > could lead to problems with hotplug.  XFree is also mapping PCI ROMs in without
 > > informing the kernel and that can definitely cause problems.
 > 
 > Absolutely. Changing PCI configurations without telling the kernel _will_ 
 > cause problems. Especially for hotplug systems, but it's also very iffy to 
 > do if the card is behind a PCI bridge, since you have to take bridge 
 > resources into account (and know which bridges are transparent, which are 
 > not, etc etc). 

Speaking of XFree86: when I developed the PCI resource stuff in 
XFree86 I was trying to get support from kernel folks to get the 
appropriate user space interfaces into the kernel. When I got 
nowhere I decided to do everything myself. 
XFree86 does PCI bridge tracking and one reason it does this is PCI
ROM mapping. 
 > 
 > The kernel spends a lot of effort on getting this right, and even so it 
 > fails every once in a while (devices that use IO or memory regions without 
 > announcing them in the standard BAR's are quite common, and the kernel has 
 > to have special quirk entries for things like that).

Right. One reason why the PCI code in XFree86 looks so difficult is
that old ATi Mach?? cards had their 8514 registers (and their mirror
images) scattered all over the PIO space.

 > 
 > Few enough drivers actually want to enable the roms, but the code should 
 > look something like
 > 
 > 	/* Assign space for ROM resource if not already assigned. Ugly. */
 > 	if (!pci_resource_start(dev, PCI_ROM_RESOURCE))
 > 		if (pci_assign_resource(dev, PCI_ROM_RESOURCE) < 0)
 > 			return -ENOMEM;

[Stuff deleted] .....

Is there any API that allows one to do this from user space?
There are plenty of XFree86 drivers around that don't have a
DRM kernel module and it should  be possible to run those which
do without DRI support, therefore it would be a good if the
XFree86 driver could do this registration itself.

Cheers,
	Egbert.


-------------------------------------------------------
This SF.net email is sponsored by: The SF.net Donation Program.
Do you like what SourceForge.net is doing for the Open
Source Community?  Make a contribution, and help us add new
features and functionality. Click here: http://sourceforge.net/donate/

  parent reply	other threads:[~2003-10-25 17:53 UTC|newest]

Thread overview: 67+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-10-21  2:31 DRM and pci_driver conversion Eric Anholt
2003-10-23 19:04 ` [Linux-fbdev-devel] " Kronos
2003-10-23 19:04   ` Kronos
2003-10-23 21:10   ` [Linux-fbdev-devel] " Eric Anholt
2003-10-23 21:31     ` Jon Smirl
2003-10-23 23:23       ` [Dri-devel] " Linus Torvalds
2003-10-23 23:23         ` Linus Torvalds
2003-10-23 23:46         ` Eric Anholt
2003-10-24  1:19         ` Jeff Garzik
2003-10-24  1:19           ` [Dri-devel] " Jeff Garzik
2003-10-24  1:52           ` [Dri-devel] Re: [Linux-fbdev-devel] " Jon Smirl
2003-10-24  3:47           ` Multiple drivers for same hardware:, was: " Jon Smirl
2003-10-24  3:47             ` Jon Smirl
2003-10-24  4:40             ` Linus Torvalds
2003-10-24  4:40               ` Linus Torvalds
2003-10-28 18:00               ` James Simmons
2003-10-28 18:00                 ` James Simmons
2003-10-24 16:44           ` [Dri-devel] Re: [Linux-fbdev-devel] " Linus Torvalds
2003-10-24 16:44             ` [Dri-devel] " Linus Torvalds
2003-10-24 16:57             ` [Dri-devel] Re: [Linux-fbdev-devel] " Petr Vandrovec
2003-10-24 17:59               ` Linus Torvalds
2003-10-24 17:59                 ` Linus Torvalds
2003-10-24 18:34                 ` Jon Smirl
2003-10-24 19:45                   ` Ivan Kokshaysky
2003-10-24 19:45                     ` [Dri-devel] " Ivan Kokshaysky
2003-10-24 19:08               ` [Dri-devel] Re: [Linux-fbdev-devel] " Ivan Kokshaysky
2003-10-24 19:08                 ` [Dri-devel] " Ivan Kokshaysky
2003-10-24 17:06             ` [Dri-devel] Re: [Linux-fbdev-devel] " Jeff Garzik
2003-10-24 17:06               ` [Dri-devel] " Jeff Garzik
2003-10-24  1:50         ` [Dri-devel] Re: [Linux-fbdev-devel] " Jon Smirl
2003-10-24  1:50           ` [Dri-devel] " Jon Smirl
2003-10-25 17:29         ` Egbert Eich [this message]
2003-10-25 17:29           ` Egbert Eich
2003-10-25 18:37           ` [Dri-devel] Re: [Linux-fbdev-devel] " Linus Torvalds
2003-10-25 18:37             ` Linus Torvalds
2003-10-25 19:17             ` Jeff Garzik
2003-10-25 19:17               ` [Dri-devel] " Jeff Garzik
2003-10-27 14:37               ` Ingo Oeser
2003-10-27 14:37               ` [Dri-devel] Re: [Linux-fbdev-devel] " Ingo Oeser
2003-10-27 15:43                 ` Jeff Garzik
2003-10-27 15:43                   ` [Dri-devel] " Jeff Garzik
2003-10-28 10:53                   ` [Dri-devel] Re: [Linux-fbdev-devel] " Ingo Oeser
2003-10-27 15:14               ` Keith Whitwell
2003-10-27 15:14                 ` [Dri-devel] " Keith Whitwell
2003-10-27 15:38                 ` Jeff Garzik
2003-10-27 15:38                 ` [Dri-devel] Re: [Linux-fbdev-devel] " Jeff Garzik
2003-10-27 15:50                   ` [Dri-devel] " Keith Whitwell
2003-10-27 15:50                   ` [Dri-devel] Re: [Linux-fbdev-devel] " Keith Whitwell
2003-10-25 21:02             ` Jon Smirl
2003-10-25 21:02               ` [Dri-devel] " Jon Smirl
2003-10-25 22:07             ` [Dri-devel] Re: [Linux-fbdev-devel] " Benjamin Herrenschmidt
2003-10-25 22:07               ` [Dri-devel] " Benjamin Herrenschmidt
2003-10-27 14:01             ` [Dri-devel] Re: [Linux-fbdev-devel] " jlnance
2003-10-27 15:10             ` Eric W. Biederman
2003-10-27 15:10               ` [Dri-devel] " Eric W. Biederman
2003-10-27 15:10             ` [Dri-devel] Re: [Linux-fbdev-devel] " Keith Whitwell
2003-10-27 15:10               ` [Dri-devel] " Keith Whitwell
     [not found]             ` <20031027114006.A66611@xfree86.org>
2003-10-27 19:38               ` Ian Romanick
2003-10-27 21:32                 ` Linus Torvalds
2003-10-27 23:55                   ` Benjamin Herrenschmidt
2003-10-28  2:13                     ` Linus Torvalds
2003-10-28  3:27                       ` Philip Brown
2003-10-28 19:40                       ` James Simmons
2003-10-28 21:35                         ` Benjamin Herrenschmidt
2003-10-28 22:09                           ` Jon Smirl
2003-10-28 22:26                             ` Benjamin Herrenschmidt
2003-10-28 22:54                         ` Linus Torvalds

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=16282.45806.428547.279213@zeus.local \
    --to=eich@xfree86.org \
    --cc=dri-devel@lists.sourceforge.net \
    --cc=eta@lclark.edu \
    --cc=jgarzik@pobox.com \
    --cc=jonsmirl@yahoo.com \
    --cc=kronos@kronoz.cjb.net \
    --cc=linux-fbdev-devel@lists.sourceforge.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=torvalds@osdl.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.