From: Eric A. <et...@lc...> - 2003-10-21 05:15:03
|
I recently committed a change to the DRM for Linux in DRI CVS that converted it to use pci_driver and that probe system. Unfortunately, we've found that there is a conflict between the DRM now and at least the radeon framebuffer. Both want to attach to the same device, and with pci_driver, the second one to come along doesn't get probe called for that device. Is there any way to mark things shared, or in some other way get the DRM to attach to a device that's already attached to, in the new model? Please CC me on replies as I'm not subscribed to these lists. -- Eric Anholt et...@lc... http://people.freebsd.org/~anholt/ anholt@FreeBSD.org |
From: Kronos <kr...@kr...> - 2003-10-23 19:04:30
|
Il Mon, Oct 20, 2003 at 07:31:56PM -0700, Eric Anholt ha scritto: > I recently committed a change to the DRM for Linux in DRI CVS that > converted it to use pci_driver and that probe system. Unfortunately, > we've found that there is a conflict between the DRM now and at least > the radeon framebuffer. Both want to attach to the same device, and > with pci_driver, the second one to come along doesn't get probe called > for that device. Is there any way to mark things shared, or in some > other way get the DRM to attach to a device that's already attached to, > in the new model? AFAIK no, pci_dev only stores one pointer to the driver. Two drivers fiddling with the same hw can be dangerous. What will happen if radeonfb starts using hw accel, touching registers without DRM knowing it? What is (IMHO) needed is a common layer that works with hardware and exposes an interface to both radeonfb and DRM. I think that Jon Smirl is working on something like this. Luca -- Reply-To: kr...@kr... Home: http://kronoz.cjb.net "Sei l'unica donna della mia vita". (Adamo) |
From: Eric A. <et...@lc...> - 2003-10-23 21:14:21
|
On Thu, 2003-10-23 at 12:04, Kronos wrote: > Il Mon, Oct 20, 2003 at 07:31:56PM -0700, Eric Anholt ha scritto: > > I recently committed a change to the DRM for Linux in DRI CVS that > > converted it to use pci_driver and that probe system. Unfortunately, > > we've found that there is a conflict between the DRM now and at least > > the radeon framebuffer. Both want to attach to the same device, and > > with pci_driver, the second one to come along doesn't get probe called > > for that device. Is there any way to mark things shared, or in some > > other way get the DRM to attach to a device that's already attached to, > > in the new model? > > AFAIK no, pci_dev only stores one pointer to the driver. Two drivers > fiddling with the same hw can be dangerous. What will happen if radeonfb > starts using hw accel, touching registers without DRM knowing it? What > is (IMHO) needed is a common layer that works with hardware and exposes > an interface to both radeonfb and DRM. I think that Jon Smirl is working > on something like this. Apparently loading DRM after radeonfb is okay. Loading radeonfb after DRM is okay as long as the DRM is not in use. For some cards, the fb after the DRM would still be okay (sis, tdfx at the moment, for example), but it isn't the case on radeon, apparently. Other than that there aren't any issues I know of. I've moved the Linux DRM to old-style probing as pci.txt described, which hopefully restores the ability of fb and drm to coexist as well as they have in the past. I hope some linux developers can get this all done right so that the two can coexist better. -- Eric Anholt et...@lc... http://people.freebsd.org/~anholt/ anholt@FreeBSD.org |
From: Jon S. <jon...@ya...> - 2003-10-23 21:40:43
|
I don't think DRM drivers are doing things correctly yet. DRM is missing the code for marking PCI resources as being in use while DRM is using them. This could lead to problems with hotplug. XFree is also mapping PCI ROMs in without informing the kernel and that can definitely cause problems. I'm looking at adding the resource marking code right now. I am not a fan of having two device drivers (DRM and FB) trying to control the same piece of hardware, but if we are going to insist on doing it we need to do it in a way where both drivers work and mark the resources in use independent of the order in which they are loaded. So I think we need to implement both the old and new PCI ID schemes and fallback to the old one if the other driver is present. DRM also needs to add code marking resources in use which will also conflict with framebuffer. It would flow something like this: new style probe if (new probe has device) mark resources in use else do old style probe (make sure card is really there) assume other driver has marked resources in use The framebuffer drivers that have DRM parallels would need to implement the same code. That way it won't matter what order things get loaded. A second possibility would be to implement a tiny stub for just attaching to the PCI ID and resources. Then framebuffer and DRM could both share the stub. A third scheme would disallow mixing DRM and FB. A DRM-console module would be written to replace FB console. Accelerated console could be written using DRM since it already knows about the 3D hardware. This would fix the problem with radeonfb mapping upto 256K of memory into the 1GB kernel space and pushing all the page tables high. Everything would be coordinated in a single drive so there is no state saving on VT switch problem either. --- Eric Anholt <et...@lc...> wrote: > On Thu, 2003-10-23 at 12:04, Kronos wrote: > > Il Mon, Oct 20, 2003 at 07:31:56PM -0700, Eric Anholt ha scritto: > > > I recently committed a change to the DRM for Linux in DRI CVS that > > > converted it to use pci_driver and that probe system. Unfortunately, > > > we've found that there is a conflict between the DRM now and at least > > > the radeon framebuffer. Both want to attach to the same device, and > > > with pci_driver, the second one to come along doesn't get probe called > > > for that device. Is there any way to mark things shared, or in some > > > other way get the DRM to attach to a device that's already attached to, > > > in the new model? > > > > AFAIK no, pci_dev only stores one pointer to the driver. Two drivers > > fiddling with the same hw can be dangerous. What will happen if radeonfb > > starts using hw accel, touching registers without DRM knowing it? What > > is (IMHO) needed is a common layer that works with hardware and exposes > > an interface to both radeonfb and DRM. I think that Jon Smirl is working > > on something like this. > > Apparently loading DRM after radeonfb is okay. Loading radeonfb after > DRM is okay as long as the DRM is not in use. For some cards, the fb > after the DRM would still be okay (sis, tdfx at the moment, for > example), but it isn't the case on radeon, apparently. Other than that > there aren't any issues I know of. > > I've moved the Linux DRM to old-style probing as pci.txt described, > which hopefully restores the ability of fb and drm to coexist as well as > they have in the past. I hope some linux developers can get this all > done right so that the two can coexist better. > > -- > Eric Anholt et...@lc... > http://people.freebsd.org/~anholt/ anholt@FreeBSD.org > > ===== Jon Smirl jon...@ya... __________________________________ Do you Yahoo!? The New Yahoo! Shopping - with improved product search http://shopping.yahoo.com |
From: Linus T. <tor...@os...> - 2003-10-24 13:15:33
|
[ Jeff: is that PCI ROM enable _really_ that complicated? Ouch. Or is there some helper function I missed? ] On Thu, 23 Oct 2003, Jon Smirl wrote: > > I don't think DRM drivers are doing things correctly yet. DRM is missing the > code for marking PCI resources as being in use while DRM is using them. This > 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). 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). 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; /* Enable it. This is too ugly */ if (!(pci_resource_flags(dev, PCI_ROM_RESOURCE) & PCI_ROM_ADDRESS_ENABLE)) { u32 val; pci_read_config_dword(dev, PCI_ROM_ADDRESS, &val); val |= PCI_ROM_ADDRESS_ENABLE; pci_write_config_dword(dev, PCI_ROM_ADDRESS, val); pci_resource_flags(dev, PCI_ROM_RESOURCE) |= PCI_ROM_ADDRESS_ENABLE; } /* Enable the device, and regular resources */ if (pci_enable_device(dev)) return -ENODEV; pci_set_master(dev); /* If we want to */ pci_set_mwi(dev); /* If we want to */ (Yeah, that is more complex than it really should need to be. That's just a sign of exactly how few device drivers tend to want to do this: the usual helper stuff is all geared for the normal case). > new style probe > if (new probe has device) > mark resources in use You shouldn't need to mark the resources in use. Just registering the driver should do everything for you, including making sure that no other driver will register that device. Of course, if you are worried about mixing with drivers that use the old "find device and just use it", then yes, you'll need to mark the resources in use. That can be as trivial as just doing a if (pci_request_regions(dev, "drivername") < 0) return -EAIIEEEE!; in the probe function (but then you need to remember to release them in the drop function). Linus |
From: Jeff G. <jg...@po...> - 2003-10-24 01:21:32
|
Linus Torvalds wrote: > [ Jeff: is that PCI ROM enable _really_ that complicated? Ouch. Or is > there some helper function I missed? ] The mechanics aren't complicated, but I seem to recall there being a Real Good Reason why you want to leave it disabled 99% of the time. No, I don't recall that reason :( But my fuzzy memory seems to think that "enable, grab a slice o 'rom, disable" was viable. Jeff |
From: Jon S. <jon...@ya...> - 2003-10-24 03:48:56
|
What about the fundamental question? We have several pairs of device drivers that want to control the same hardware. One example would be radeon DRM and radeon Framebuffer. How should these drivers coordinate probing and claiming resources? What should be the policy for multiple drivers? 1) try new probe first and fall back to old scheme. First driver that loads gets the new probe, second gets the old. First driver reserves resources. 2) Require a mini driver that handles probing. Then both drivers attach to the mini driver. 3) Declare it illegal and make the drivers merge. 4) Declare it illegal and only allow first one loaded to run. Right now radeonfb handles probing and resource reservation. DRM works in stealth mode. DRM uses all of the resources and never tells the kernel, that's how it avoids conflicting with framebuffer. DRM and framebuffer trade off control at VT switch. 2D state is save and restored. There is an assumption that framebuffer won't mess with the 3D state. I'm not sure that suspend/resume are coordinated in any way. ===== Jon Smirl jon...@ya... __________________________________ Do you Yahoo!? The New Yahoo! Shopping - with improved product search http://shopping.yahoo.com |
From: Linus T. <tor...@os...> - 2003-10-24 04:45:41
|
On Thu, 23 Oct 2003, Jon Smirl wrote: > > What about the fundamental question? We have several pairs of device drivers > that want to control the same hardware. One example would be radeon DRM and > radeon Framebuffer. How should these drivers coordinate probing and claiming > resources? Since they have to co-operate some way on the resources _anyway_, they'll just need to work it out amongst themselves. One common case is to have a "arbitration driver" that tends to do the actual low-level accesses and is one level of abstraction over the hardware (papers over trivial differences in hardware). An example of this would be the old-style ISA DMA infrastructure (now happily pretty much dead), where the "DMA driver" was just a trivial layer that had some basic allocation/deallocation and had somewhat nicer access routines than the raw IO accesses, but didn't do much more. Another case is the PS/2 keyboard driver, where the mouse and the keyboard actually share the controller, and they shared a spinlock and some helper routines to guarantee some basic serialization (that eventually got replaced with the current i8042 driver, but the old setup was trivial). > 1) try new probe first and fall back to old scheme. First driver that loads > gets the new probe, second gets the old. First driver reserves resources. > 2) Require a mini driver that handles probing. Then both drivers attach to the > mini driver. > 3) Declare it illegal and make the drivers merge. > 4) Declare it illegal and only allow first one loaded to run. I'd suggest the minidriver case. You _will_ find common issues anyway (locking and certain access patterns etc), and the minidriver ends up being a place to put the trivial shared code too. Linus |
From: James S. <jsi...@in...> - 2003-10-28 18:03:49
|
> Since they have to co-operate some way on the resources _anyway_, they'll > just need to work it out amongst themselves. > > One common case is to have a "arbitration driver" that tends to do the > actual low-level accesses and is one level of abstraction over the > hardware (papers over trivial differences in hardware). An example of this > would be the old-style ISA DMA infrastructure (now happily pretty much > dead), where the "DMA driver" was just a trivial layer that had some basic > allocation/deallocation and had somewhat nicer access routines than the > raw IO accesses, but didn't do much more. I already have thought ahead about this issue. That is why one of the major changes to the framebuffer layer was to seperate the driver data into struct fb_info and a struct xxx_par. The idea was the data in struct fb_info was for the framebuffer layer and the data in struct xxx_par could be shared with other interfaces like DRI. The par idea can be extended further and we could use a common structure between a low level text mode console driver and a graphics driver. For example mdacon and hgafb. |
From: Jon S. <jon...@ya...> - 2003-10-24 06:19:48
|
Video drivers only enable the ROM long enough to get some values out it and then disable it. You don't want to leave ROMs enabled because there is some hardware that uses the same address decoder for ROM and RAM and you can't use them both at the same time. --- Jeff Garzik <jg...@po...> wrote: > Linus Torvalds wrote: > > [ Jeff: is that PCI ROM enable _really_ that complicated? Ouch. Or is > > there some helper function I missed? ] > > > The mechanics aren't complicated, but I seem to recall there being a > Real Good Reason why you want to leave it disabled 99% of the time. No, > I don't recall that reason :( But my fuzzy memory seems to think that > "enable, grab a slice o 'rom, disable" was viable. > > Jeff > > > ===== Jon Smirl jon...@ya... __________________________________ Do you Yahoo!? The New Yahoo! Shopping - with improved product search http://shopping.yahoo.com |
From: Linus T. <tor...@os...> - 2003-10-24 16:46:34
|
On Thu, 23 Oct 2003, Jeff Garzik wrote: > > The mechanics aren't complicated, but I seem to recall there being a > Real Good Reason why you want to leave it disabled 99% of the time. No, > I don't recall that reason :( But my fuzzy memory seems to think that > "enable, grab a slice o 'rom, disable" was viable. That's not what I'm worried about: yes, it's doable, and it's only ten lines of code, but my point is that having drivers do something like this: > /* 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; > > /* Enable it. This is too ugly */ > if (!(pci_resource_flags(dev, PCI_ROM_RESOURCE) & PCI_ROM_ADDRESS_ENABLE)) { > u32 val; > pci_read_config_dword(dev, PCI_ROM_ADDRESS, &val); > val |= PCI_ROM_ADDRESS_ENABLE; > pci_write_config_dword(dev, PCI_ROM_ADDRESS, val); > pci_resource_flags(dev, PCI_ROM_RESOURCE) |= PCI_ROM_ADDRESS_ENABLE; > } over and over again _is_ going to cause us problems later. Either we'll change some interface slightly (and have to fix up the drivers), or a couple of the drivers are going to do things _slightly_ wrong (forget to assign the resource, or forget to mark it enabled, or whatever), and then we'll have a subtle bug that only shows up on certain hardware and firmware combinations, depending on how the BIOS sets up regions etc. So wouldn't it be nice if we just had those ten lines as a generic function like int pci_enable_rom(struct pci_device *dev) { ... int pci_disable_rom(..); that does all of this properly for the (few) drivers that need this in order to fetch resource information from the ROM's? That way people could just do if (pci_enable_device(dev)) return -ENODEV; if (pci_enable_rom(dev)) return -Exxx; and we wouldn't have to have drivers that have _waay_ too much knowledge about things like assigning bus resources and the PCI_ROM_ADDRESS_ENABLE bit. Drivers really shouldn't need to know or care. A driver writer should just know that his card has a ROM attached to it, and that he will need to enable it explicitly because for most chips we just don't want to waste IO mapping space by enabling it by default. (Yeah, the driver still needs to know about doing the ioremap() etc and only accessing it with read/write[bwl(), but those are common to any memory-mapped thing, so that's not "new" knowledge per se). Case in point: I had to dig around a bit to write those ten lines of code. And I consider myself above-average-knowledgeable about PCI device issues. So I don't think driver writers should have to write those ten lines, the same way I think they should just do "pci_enable_device()" to get the interrupt line and regular BAR things up, and the chip powered on.. And no, most drivers really don't care about their roms. Most devices don't even have any roms. But grepping for "PCI_ROM_" shows that there clearly are more than one or two that do (and I'm afraid to think about the ones that use hardcoded values rather than the symbolic ones, just because the driver writer didn't find a helper function and just did it by hand by reading the PCI spec). Linus |
From: Jeff G. <jg...@po...> - 2003-10-24 17:08:50
|
On Fri, Oct 24, 2003 at 09:44:38AM -0700, Linus Torvalds wrote: > So wouldn't it be nice if we just had those ten lines as a generic > function like > > int pci_enable_rom(struct pci_device *dev) > { > ... > > int pci_disable_rom(..); Yes. Agreed, Jeff |
From: Petr V. <van...@vc...> - 2003-10-24 18:17:22
|
On Fri, Oct 24, 2003 at 09:44:38AM -0700, Linus Torvalds wrote: > > On Thu, 23 Oct 2003, Jeff Garzik wrote: > > > /* 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; > > > > /* Enable it. This is too ugly */ > > if (!(pci_resource_flags(dev, PCI_ROM_RESOURCE) & PCI_ROM_ADDRESS_ENABLE)) { > > u32 val; > > pci_read_config_dword(dev, PCI_ROM_ADDRESS, &val); > > val |= PCI_ROM_ADDRESS_ENABLE; > > pci_write_config_dword(dev, PCI_ROM_ADDRESS, val); > > pci_resource_flags(dev, PCI_ROM_RESOURCE) |= PCI_ROM_ADDRESS_ENABLE; > > } > > over and over again _is_ going to cause us problems later. Either we'll > change some interface slightly (and have to fix up the drivers), or a We need something more sophisticated. Matrox's hardware has bits 31-16 readable/writable only if bit 0 is set to 1 (ROM enabled; you can (obviously) set bits 31-16 & 0 in one write). When ROM is disabled, bits 31-1 are always read as 0. > So wouldn't it be nice if we just had those ten lines as a generic > function like > > int pci_enable_rom(struct pci_device *dev) > { > ... > > int pci_disable_rom(..); It would be nice if it works... For matrox hardware I have to map ROM over framebuffer (it is solution recommended by datasheet), as there is no way to get memory range allocated for ROM unless ROM was left enabled all the time. Best regards, Petr Vandrovec van...@vc... |
From: Linus T. <tor...@os...> - 2003-10-24 18:18:29
|
On Fri, 24 Oct 2003, Petr Vandrovec wrote: > > It would be nice if it works... For matrox hardware I have to map ROM > over framebuffer (it is solution recommended by datasheet), as there is > no way to get memory range allocated for ROM unless ROM was left enabled > all the time. That's fine - it sounds like Matrox hardware is just buggy, and then you will never be able to use the generic "enable ROM" routines. That shouldn't detract from other drivers doing it, though. On the other hand, we might well be able to work around the matrox behaviour if we really want to: writing all-ones to the register should work, and that is the way we figure out the size of the allocation anyway. So this is one of those things where having a generic routine and knowing a bit about some implementation oddities migth well work out. Maybe some other cards have the same odd behaviour. But since Matrox has a separate recommended solution in their datasheets, I suspect the right thing is just to ignore Matrox when talking about the generic thing. Linus |
From: Jon S. <jon...@ya...> - 2003-10-24 18:34:06
|
PCI ROM enabale/disable has come up before on LKML. Russell made this comment about making the code more portable. --- Russell King <rm...@ar...> wrote: > You should use pcibios_resource_to_bus() to convert a resource to a > representation suitable for a BAR. http://lkml.org/lkml/2003/8/19/279 ===== Jon Smirl jon...@ya... __________________________________ Do you Yahoo!? The New Yahoo! Shopping - with improved product search http://shopping.yahoo.com |
From: Ivan K. <in...@ju...> - 2003-10-24 19:48:34
|
On Fri, Oct 24, 2003 at 11:34:04AM -0700, Jon Smirl wrote: > PCI ROM enabale/disable has come up before on LKML. Russell made this comment > about making the code more portable. > > --- Russell King <rm...@ar...> wrote: > > You should use pcibios_resource_to_bus() to convert a resource to a > > representation suitable for a BAR. pci_assign_resource() does call pcibios_resource_to_bus(), so Linus' proposal will work correctly as it is. Ivan. |
From: Ivan K. <in...@ju...> - 2003-10-24 19:12:45
|
On Fri, Oct 24, 2003 at 06:57:18PM +0200, Petr Vandrovec wrote: > We need something more sophisticated. Matrox's hardware has bits > 31-16 readable/writable only if bit 0 is set to 1 (ROM enabled; you can > (obviously) set bits 31-16 & 0 in one write). When ROM is disabled, > bits 31-1 are always read as 0. Hmm, I believe it's not true at least for Mystique, Millennium II and G400. Otherwise we wouldn't be able to determine ROM size/alignment as we do probe with ROM disabled (probe.c, line 125): pci_write_config_dword(dev, rom, ~PCI_ROM_ADDRESS_ENABLE); pci_read_config_dword(dev, rom, &sz); Ivan. |
From: Jon S. <jon...@ya...> - 2003-10-24 01:54:17
|
Wouldn't it be better to add ROM enable/disable functions to the PCI driver than to scatter it out into every driver? All of the framebuffer and DRM drivers need to do this. I also seem to remember that there are more steps needed if this is going to work on an ARM chip. --- Linus Torvalds <tor...@os...> wrote: > > [ Jeff: is that PCI ROM enable _really_ that complicated? Ouch. Or is > there some helper function I missed? ] > > On Thu, 23 Oct 2003, Jon Smirl wrote: > > > > I don't think DRM drivers are doing things correctly yet. DRM is missing > the > > code for marking PCI resources as being in use while DRM is using them. > This > > 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). > > 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). > > 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; > > /* Enable it. This is too ugly */ > if (!(pci_resource_flags(dev, PCI_ROM_RESOURCE) & PCI_ROM_ADDRESS_ENABLE)) { > u32 val; > pci_read_config_dword(dev, PCI_ROM_ADDRESS, &val); > val |= PCI_ROM_ADDRESS_ENABLE; > pci_write_config_dword(dev, PCI_ROM_ADDRESS, val); > pci_resource_flags(dev, PCI_ROM_RESOURCE) |= PCI_ROM_ADDRESS_ENABLE; > } > > > /* Enable the device, and regular resources */ > if (pci_enable_device(dev)) > return -ENODEV; > > pci_set_master(dev); /* If we want to */ > pci_set_mwi(dev); /* If we want to */ > > (Yeah, that is more complex than it really should need to be. That's just > a sign of exactly how few device drivers tend to want to do this: the > usual helper stuff is all geared for the normal case). > > > new style probe > > if (new probe has device) > > mark resources in use > > You shouldn't need to mark the resources in use. Just registering the > driver should do everything for you, including making sure that no other > driver will register that device. > > Of course, if you are worried about mixing with drivers that use the old > "find device and just use it", then yes, you'll need to mark the resources > in use. That can be as trivial as just doing a > > if (pci_request_regions(dev, "drivername") < 0) > return -EAIIEEEE!; > > in the probe function (but then you need to remember to release them in > the drop function). > > Linus > The framebuffer drivers are doing it like this. Should they be replaced with pci_request_regions? /* request the mem regions */ if (!request_mem_region (rinfo->fb_base_phys, pci_resource_len(pdev, 0), "radeonfb")) { printk (KERN_ERR "radeonfb: cannot reserve FB region\n"); goto free_rinfo; } if (!request_mem_region (rinfo->mmio_base_phys, pci_resource_len(pdev, 2), "radeonfb")) { printk (KERN_ERR "radeonfb: cannot reserve MMIO region\n"); goto release_fb; } ===== Jon Smirl jon...@ya... __________________________________ Do you Yahoo!? The New Yahoo! Shopping - with improved product search http://shopping.yahoo.com |
From: Eric A. <et...@lc...> - 2003-10-24 16:24:09
|
On Thu, 2003-10-23 at 16:23, Linus Torvalds wrote: > [ Jeff: is that PCI ROM enable _really_ that complicated? Ouch. Or is > there some helper function I missed? ] > > On Thu, 23 Oct 2003, Jon Smirl wrote: > > > > I don't think DRM drivers are doing things correctly yet. DRM is missing the > > code for marking PCI resources as being in use while DRM is using them. This > > 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). > > 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). > > 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; > > /* Enable it. This is too ugly */ > if (!(pci_resource_flags(dev, PCI_ROM_RESOURCE) & PCI_ROM_ADDRESS_ENABLE)) { > u32 val; > pci_read_config_dword(dev, PCI_ROM_ADDRESS, &val); > val |= PCI_ROM_ADDRESS_ENABLE; > pci_write_config_dword(dev, PCI_ROM_ADDRESS, val); > pci_resource_flags(dev, PCI_ROM_RESOURCE) |= PCI_ROM_ADDRESS_ENABLE; > } > > > /* Enable the device, and regular resources */ > if (pci_enable_device(dev)) > return -ENODEV; > > pci_set_master(dev); /* If we want to */ > pci_set_mwi(dev); /* If we want to */ > > (Yeah, that is more complex than it really should need to be. That's just > a sign of exactly how few device drivers tend to want to do this: the > usual helper stuff is all geared for the normal case). > > > new style probe > > if (new probe has device) > > mark resources in use > > You shouldn't need to mark the resources in use. Just registering the > driver should do everything for you, including making sure that no other > driver will register that device. > > Of course, if you are worried about mixing with drivers that use the old > "find device and just use it", then yes, you'll need to mark the resources > in use. That can be as trivial as just doing a > > if (pci_request_regions(dev, "drivername") < 0) > return -EAIIEEEE!; > > in the probe function (but then you need to remember to release them in > the drop function). However, the DRM is now using the old-style probing instead, because of the radeonfb conflict. In the case of the DRM, we want drivers to coexist, at least when loaded in the FB then DRM order. What should the DRM be doing exactly in this case? Is it exactly what Jon Smirl said, or something else? -- Eric Anholt et...@lc... http://people.freebsd.org/~anholt/ anholt@FreeBSD.org |
From: Egbert E. <ei...@xf...> - 2003-10-25 17:58:28
|
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. |
From: Linus T. <tor...@os...> - 2003-10-25 18:42:28
|
On Sat, 25 Oct 2003, Egbert Eich wrote: > > 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. There won't be any "user space interfaces". There are perfectly good in-kernel interfaces, and anybody who needs them needs to be in kernel space. Ie the kernel interfaces are for kernel modules, not for user space accesses. The kernel module can be a simple interface layer like DRI, but the thing is, it needs to be specific to some kind of hardware. I refuse to have some kind of crap "user space driver" interface - drivers in user space are a mistake. > Is there any API that allows one to do this from user space? No. And I don't really see any huge reason for it. > 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. If you do this, do it _right_. Look at what X really needs, and make a driver for it. A _real_ driver. Not just a half-hearted "we want to do things in user space, but we can't". Face it, a good graphics driver needs more than just "set up the ROM". It needs DMA access, and the ability to use interrupts. It needs a real driver. It basically needs something like what the DRI modules tend to do. I'd be really happy to have real graphics drivers in the kernel, but quite frankly, so far the abstractions I've seen have sucked dead donkeys through a straw. "fbcon" does way too much (it's not a driver, it's more a text delivery system and a mode switcher). And DRI is too complex and fluid to be a good low-level driver. Quite frankly, I'd much rather see a low-level graphics driver that does _two_ things, and those things only: - basic hardware enumeration and setup (and no, "basic setup" does not mean "mode switching": it literally means things like doing the pci_enable_device() stuff. - serialization and arbitrary command queuing from a _trusted_ party (ie it could take command lists from the X server, but not from untrusted clients). This part basically boils down to "DMA and interrupts". This is the part that allows others to wait for command completion, "enough space in the ring buffers" etc. But it does _not_ know or care what the commands are. Then, fbcon and DRI and X could all three use these basics - and they'd be _so_ basic that the hardware layer could be really stable (unlike the DRI code that tends to have to upgrade for each new type of command that DRI adds - since it has to take care of untrusted clients. So DRI would basically use the low-level driver as a separate module, the way it already uses AGP). But I'm _not_ interested in some interfaces to let user mode just bypass the kernel. Because they will not solve any of the other problems that clearly _do_ need solving, and if the X server continues to believe that it can just access the hardware directly, it will never play well together with projects like fbcon/dri. Linus |
From: Jeff G. <jg...@po...> - 2003-10-25 19:18:29
|
Linus Torvalds wrote: > Quite frankly, I'd much rather see a low-level graphics driver that does > _two_ things, and those things only: > > - basic hardware enumeration and setup (and no, "basic setup" does not > mean "mode switching": it literally means things like doing the > pci_enable_device() stuff. > > - serialization and arbitrary command queuing from a _trusted_ party (ie > it could take command lists from the X server, but not from untrusted > clients). This part basically boils down to "DMA and interrupts". This > is the part that allows others to wait for command completion, "enough > space in the ring buffers" etc. But it does _not_ know or care what the > commands are. Thank you for saying it. This is what I have been preaching (quietly) for years -- command submission and synchronization (and thus, DMA/irq handling) needs to be in the kernel. Everything else can be in userspace (excluding hardware enable/enumerate, of course). Graphics processors are growing more general, too -- moving towards generic vector/data processing engines. I bet you'll see an optimal model emerge where you have some sort of "JIT" for GPU microcode in userspace. Multiple apps pipeline X/GL/hardware commands into the JIT, which in turn pipelines data and microcode commands to the GPU kernel driver. Jeff |
From: Keith W. <ke...@tu...> - 2003-10-27 15:18:25
|
Jeff Garzik wrote: > Linus Torvalds wrote: > >> Quite frankly, I'd much rather see a low-level graphics driver that does >> _two_ things, and those things only: >> >> - basic hardware enumeration and setup (and no, "basic setup" does not >> mean "mode switching": it literally means things like doing the >> pci_enable_device() stuff. >> >> - serialization and arbitrary command queuing from a _trusted_ party (ie >> it could take command lists from the X server, but not from untrusted >> clients). This part basically boils down to "DMA and interrupts". >> This is the part that allows others to wait for command completion, >> "enough space in the ring buffers" etc. But it does _not_ know or >> care what the commands are. > > > Thank you for saying it. This is what I have been preaching (quietly) > for years -- command submission and synchronization (and thus, DMA/irq > handling) needs to be in the kernel. Everything else can be in > userspace (excluding hardware enable/enumerate, of course). To enable secure direct rendering on current hardware (ie without secure command submission mechanisms), you need command valididation somewhere. This could be a layer on top of the minimal dma engine Linus describes. > Graphics processors are growing more general, too -- moving towards > generic vector/data processing engines. I bet you'll see an optimal > model emerge where you have some sort of "JIT" for GPU microcode in > userspace. You mean like the programmable fragment and vertex hardware that has been in use for a couple of years now? Keith |
From: Jeff G. <jg...@po...> - 2003-10-27 15:46:53
|
On Mon, Oct 27, 2003 at 03:14:11PM +0000, Keith Whitwell wrote: > Jeff Garzik wrote: > >Thank you for saying it. This is what I have been preaching (quietly) > >for years -- command submission and synchronization (and thus, DMA/irq > >handling) needs to be in the kernel. Everything else can be in > >userspace (excluding hardware enable/enumerate, of course). > > To enable secure direct rendering on current hardware (ie without secure > command submission mechanisms), you need command valididation somewhere. > This could be a layer on top of the minimal dma engine Linus describes. Certainly. > >Graphics processors are growing more general, too -- moving towards > >generic vector/data processing engines. I bet you'll see an optimal > >model emerge where you have some sort of "JIT" for GPU microcode in > >userspace. > > You mean like the programmable fragment and vertex hardware that has been > in use for a couple of years now? I mean, taking current fragment and vertex processing and making it even _more_ general. Which has already happened, on one particular chip maker's chip... Jeff |
From: Keith W. <ke...@tu...> - 2003-10-27 15:55:01
|
Jeff Garzik wrote: > On Mon, Oct 27, 2003 at 03:14:11PM +0000, Keith Whitwell wrote: > >>Jeff Garzik wrote: >> >>>Thank you for saying it. This is what I have been preaching (quietly) >>>for years -- command submission and synchronization (and thus, DMA/irq >>>handling) needs to be in the kernel. Everything else can be in >>>userspace (excluding hardware enable/enumerate, of course). >> >>To enable secure direct rendering on current hardware (ie without secure >>command submission mechanisms), you need command valididation somewhere. >>This could be a layer on top of the minimal dma engine Linus describes. > > > Certainly. > > > >>>Graphics processors are growing more general, too -- moving towards >>>generic vector/data processing engines. I bet you'll see an optimal >>>model emerge where you have some sort of "JIT" for GPU microcode in >>>userspace. >> >>You mean like the programmable fragment and vertex hardware that has been >>in use for a couple of years now? > > > I mean, taking current fragment and vertex processing and making it > even _more_ general. Which has already happened, on one particular chip > maker's chip... I think that generally you can view all the current generation of hardware as arbitary programmable devices, and most of the graphics drivers are doing code-generation for that hardware on the fly. This isn't exactly new ground for graphics drivers as graphics hardware has alternated (I'm told) between fixed function and programmable cores multiple times now. In addition, graphics drivers have been doing on-the-fly codegen for the host cpu since year dot. The orignal software-rasterization SGI opengl drivers for windows were supposed to be pretty much state of the art in this respect. Now that the barriers for codegen have lowered so dramatically (see, eg. http://fabrice.bellard.free.fr/tcc/), it is now feasible to talk of building a code-generating software rasterizer for mesa. Keith Keith |