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/
next prev 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: linkBe 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.