DRM and pci_driver conversion

DRM and pci_driver conversion

[Eric Anholt]

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                                eta@lclark.edu          
http://people.freebsd.org/~anholt/         anholt@FreeBSD.org

Re: [Linux-fbdev-devel] DRM and pci_driver conversion

[Kronos]

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: kronos@kronoz.cjb.net
Home: http://kronoz.cjb.net
"Sei l'unica donna della mia vita".
(Adamo)

Re: [Linux-fbdev-devel] DRM and pci_driver conversion

[Eric Anholt]

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                                eta@lclark.edu          
http://people.freebsd.org/~anholt/         anholt@FreeBSD.org

Re: [Linux-fbdev-devel] DRM and pci_driver conversion

[Jon Smirl]

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 <eta@lclark.edu> 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                                eta@lclark.edu          
> http://people.freebsd.org/~anholt/         anholt@FreeBSD.org
> 
> 

=====
Jon Smirl
jonsmirl@yahoo.com

__________________________________
Do you Yahoo!?
The New Yahoo! Shopping - with improved product search
http://shopping.yahoo.com

Re: [Dri-devel] Re: [Linux-fbdev-devel] DRM and pci_driver conversion

[Linus Torvalds]

[ 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

Re: [Dri-devel] Re: [Linux-fbdev-devel] DRM and pci_driver conversion

[Eric Anholt]

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                                eta@lclark.edu          
http://people.freebsd.org/~anholt/         anholt@FreeBSD.org

Re: [Dri-devel] Re: [Linux-fbdev-devel] DRM and pci_driver conversion

[Jeff Garzik]

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

Re: [Dri-devel] Re: [Linux-fbdev-devel] DRM and pci_driver conversion

[Jon Smirl]

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 <jgarzik@pobox.com> 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
jonsmirl@yahoo.com

__________________________________
Do you Yahoo!?
The New Yahoo! Shopping - with improved product search
http://shopping.yahoo.com

Multiple drivers for same hardware:, was: DRM and pci_driver conversion

[Jon Smirl]

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
jonsmirl@yahoo.com

__________________________________
Do you Yahoo!?
The New Yahoo! Shopping - with improved product search
http://shopping.yahoo.com

Re: Multiple drivers for same hardware:, was: DRM and pci_driver conversion

[Linus Torvalds]

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

Re: Multiple drivers for same hardware:, was: DRM and pci_driver conversion

[James Simmons]

> 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. 

Re: [Dri-devel] Re: [Linux-fbdev-devel] DRM and pci_driver conversion

[Linus Torvalds]

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

Re: [Dri-devel] Re: [Linux-fbdev-devel] DRM and pci_driver conversion

[Petr Vandrovec]

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
						vandrove@vc.cvut.cz

Re: [Dri-devel] Re: [Linux-fbdev-devel] DRM and pci_driver conversion

[Linus Torvalds]

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

Re: [Dri-devel] Re: [Linux-fbdev-devel] DRM and pci_driver conversion

[Jon Smirl]

PCI ROM enabale/disable has come up before on LKML. Russell made this comment
about making the code more portable.

--- Russell King <rmk@arm.linux.org.uk> 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
jonsmirl@yahoo.com

__________________________________
Do you Yahoo!?
The New Yahoo! Shopping - with improved product search
http://shopping.yahoo.com

Re: [Dri-devel] Re: [Linux-fbdev-devel] DRM and pci_driver conversion

[Ivan Kokshaysky]

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 <rmk@arm.linux.org.uk> 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.

Re: [Dri-devel] Re: [Linux-fbdev-devel] DRM and pci_driver conversion

[Ivan Kokshaysky]

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.

Re: [Dri-devel] Re: [Linux-fbdev-devel] DRM and pci_driver conversion

[Jeff Garzik]

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

Re: [Dri-devel] Re: [Linux-fbdev-devel] DRM and pci_driver conversion

[Jon Smirl]

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 <torvalds@osdl.org> 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
jonsmirl@yahoo.com

__________________________________
Do you Yahoo!?
The New Yahoo! Shopping - with improved product search
http://shopping.yahoo.com

Re: [Dri-devel] Re: [Linux-fbdev-devel] DRM and pci_driver conversion

[Egbert Eich]

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.

Re: [Dri-devel] Re: [Linux-fbdev-devel] DRM and pci_driver conversion

[Linus Torvalds]

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

Re: [Dri-devel] Re: [Linux-fbdev-devel] DRM and pci_driver conversion

[Jeff Garzik]

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

Re: [Dri-devel] Re: [Linux-fbdev-devel] DRM and pci_driver conversion

[Ingo Oeser]

On Saturday 25 October 2003 21:17, Jeff Garzik wrote:
> 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.

These "JIT" is needed also for another reason: 

	There are contraints for GPU commands and the pipelines need to
	be modelled, like CPU piplines are modelled in a compiler. But
	more like the pipelines of some early long instruction word
	processors, where issuing to a used pipeline will cause random
	behavior and crashes. So the JIT doesn't should also emit
	synchronization points. 

With this JIT in place, there need to be just some hardware description
files (backends) and some API (GL, DirectX, X) description files
(frontends).

Now we just need some funding for that and the datasheets. Then it's
doable.

I see just one showstopper: Cheating in benchmarks isn't possible anymore.

PS: That's basically the GGI approach taken further.

Regards

Ingo Oeser

Re: [Dri-devel] Re: [Linux-fbdev-devel] DRM and pci_driver conversion

[Jeff Garzik]

On Mon, Oct 27, 2003 at 04:37:30PM +0200, Ingo Oeser wrote:
> On Saturday 25 October 2003 21:17, Jeff Garzik wrote:
> > 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.
> 
> These "JIT" is needed also for another reason: 
> 
> 	There are contraints for GPU commands and the pipelines need to
> 	be modelled, like CPU piplines are modelled in a compiler. But
> 	more like the pipelines of some early long instruction word
> 	processors, where issuing to a used pipeline will cause random
> 	behavior and crashes. So the JIT doesn't should also emit
> 	synchronization points. 
> 
> With this JIT in place, there need to be just some hardware description
> files (backends) and some API (GL, DirectX, X) description files
> (frontends).

I agree 60%  ;-)   This JIT emits GPU-specific microcode, so it should
lean towards being hardware-dependent.  Speed and efficiency IMO demand
that.

Looking at existing, open-source CPU JITs, there are certainly general
pieces and CPU-specific pieces.  But for GPUs, I think the best method
is to start at the more-GPU-specific end of the spectrum, and _evolve_
towards a more general solution, as hardware needs dictate.

In other terms, let the hardware drive the JIT design and evolution, and
don't over-design for a future that may never come.  That was part of
GGI's problem, IMO.


> Now we just need some funding for that and the datasheets. Then it's
> doable.

Yep ;-)


> I see just one showstopper: Cheating in benchmarks isn't possible anymore.
> 
> PS: That's basically the GGI approach taken further.

I followed GGI for a while.  Trying to be all things to all people was
their principle mistake.  As Pat Morita said in Karate Kid,
"Focus, Daniel-san!"  Be specific before general.

	Jeff

Re: [Dri-devel] Re: [Linux-fbdev-devel] DRM and pci_driver conversion

[Ingo Oeser]

On Monday 27 October 2003 16:43, Jeff Garzik wrote:
> On Mon, Oct 27, 2003 at 04:37:30PM +0200, Ingo Oeser wrote:
> > On Saturday 25 October 2003 21:17, Jeff Garzik wrote:
> > > 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.
> >
> > These "JIT" is needed also for another reason:
> >
> > 	There are contraints for GPU commands and the pipelines need to
> > 	be modelled, like CPU piplines are modelled in a compiler. But
> > 	more like the pipelines of some early long instruction word
> > 	processors, where issuing to a used pipeline will cause random
> > 	behavior and crashes. So the JIT doesn't should also emit
> > 	synchronization points.
> >
> > With this JIT in place, there need to be just some hardware description
> > files (backends) and some API (GL, DirectX, X) description files
> > (frontends).
>
> I agree 60%  ;-)   This JIT emits GPU-specific microcode, so it should
> lean towards being hardware-dependent.  Speed and efficiency IMO demand
> that.
>
> Looking at existing, open-source CPU JITs, there are certainly general
> pieces and CPU-specific pieces.  But for GPUs, I think the best method
> is to start at the more-GPU-specific end of the spectrum, and _evolve_
> towards a more general solution, as hardware needs dictate.

Yes, you are partially right. The GCC project had already the problem
that they startet too simple with their pipeline management and had to
redesign it. 

If the kernel framework will not suffice the vendor needs (e.g. they
don't win in the benchmark, just because we cannot model their
hardware), it will be simply not used and we'll get just another nvidia
like driver.

But maybe I've read to much GCC internals recently, so I favor machine
descriptions and stateful pipeline descriptions for this ;-)

Your key argument still holds: This is just taking a instruction/data stream
from multiple sources and mapping it to another one with multiple
data/instruction sinks -> JIT.

> I followed GGI for a while.  Trying to be all things to all people was
> their principle mistake.  As Pat Morita said in Karate Kid,
> "Focus, Daniel-san!"  Be specific before general.

I noticed that it's ok to keep the design in mind, even in the comments,
but it never proved good to me to keep the design in dead code and
useless layers.

So I guess, we agree here ;-)

Re: [Dri-devel] Re: [Linux-fbdev-devel] DRM and pci_driver conversion

[Keith Whitwell]

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

Re: [Dri-devel] Re: [Linux-fbdev-devel] DRM and pci_driver conversion

[Jeff Garzik]

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

Re: [Dri-devel] Re: [Linux-fbdev-devel] DRM and pci_driver conversion

[Keith Whitwell]

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

Re: [Dri-devel] Re: [Linux-fbdev-devel] DRM and pci_driver conversion

[Jon Smirl]

--- Linus Torvalds <torvalds@osdl.org> 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.
> 
> 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).
> 

Linus, why don't you refuse updates from these projects until this is sorted
out? Your proposal is exactly what it needed. For a year now I have been poking
at these issues and making very little progress. I do know that all of the
pieces needed already exist; but without some incentive there is very little
reason to rearchitect the existing code. 

Personally I'm working on a standalone version of Mesa (OpenGL). This would
allow us to write a 3D hardware based windowing system in response to the ones
on the Mac and MS Longhorn. But instead of working on a windowing system I've
spent all of my time trying to help sort out the video device drivers.


=====
Jon Smirl
jonsmirl@yahoo.com

__________________________________
Do you Yahoo!?
Exclusive Video Premiere - Britney Spears
http://launch.yahoo.com/promos/britneyspears/

Re: [Dri-devel] Re: [Linux-fbdev-devel] DRM and pci_driver conversion

[Benjamin Herrenschmidt]

> 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.

Well... While I tend to agree, note that in 2.6 fbcon and the fbdev
itself _do_ have been separated. The fbdevs are moving toward that
low level driver thing.

> 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.

IMHO, that low level driver should be ... the fbdev. The main reason for
that is the necessary locking & synchronisation between the command flow
and mode switching, palette control and cursor control (which aren't
things doable via the normal command path on moth cases).

> 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).

I agree that fbcon itself should (and is now in 2.6) be a separate
module. The interface is still scary, the locking is almost absent,
which is a real problem even with current mode switching beeing racy
with printk & blanking, but at least we have something that works and
can evolve in the right direction.

Look how the fbdev interface was simplified in the 2.4 -> 2.6
transition, it's really a lot saner now, and I hope it will continue
to improve.

> 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.

Fully agreed. My point is that this low-level driver and the fbdev should
be one thing.

Ben.

Re: [Dri-devel] Re: [Linux-fbdev-devel] DRM and pci_driver conversion

[jlnance]

On Sat, Oct 25, 2003 at 11:37:05AM -0700, Linus Torvalds wrote:
> 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.

On Tue, 16 Jan 1996, Linus Torvalds wrote:
> X goes to hardware directly, but that's just because it should do it. 
> And exactly _because_ it's an application, it can be just about as
> complex as it wants (and needs) to be.  So you have a user-level device
> driver: is that not a good idea? The microkernel people are jumping up
> and down and wetting themselves in excitement over things like that. 

Its not that I dont think you are entitled to change your mind.  Its just
that the second version is so quotable that it has stuck in my mind oh
these many years.

Jim

Re: [Dri-devel] Re: [Linux-fbdev-devel] DRM and pci_driver conversion

[Eric W. Biederman]

Linus Torvalds <torvalds@osdl.org> writes:

> 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.

Well almost.    There is still one significant flaw in the kernel space stuff.

The BIOS can specify arbitrary regions as reserved in the E820 map and then
a kernel driver can't use that region itself.  This shows up in corner
cases where the resource on the PCI device is a boolean rather than
a general purpose thing.  Particularly for mtd map drivers to allow
flashing your ROM from linux this is a problem.

This is not required for 2.6.0 but it would be nice to actually be able
to reliably reserve resources in kernel drivers.

Eric

Re: [Dri-devel] Re: [Linux-fbdev-devel] DRM and pci_driver conversion

[Keith Whitwell]

Linus Torvalds wrote:
> 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).

That makes sense - the abstraction of dma engine away from the 
security-providing gumpf that is so much of the DRM modules, to form a single 
kernel-level "owner" of the graphics hardware.

This would also answer various questions that float around regarding who is 
the ultimate "owner" of the graphics hardware - in particular, who is 
responsible for virtualization of the graphics memory.

Of course, that's a trickier task because it is one which doesn't just rip 
existing code out of various poorly-conceived modules.

Keith