Direct Rendering Infrastructure

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

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

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

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

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

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

[ 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

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

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

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

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

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

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

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

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

--- Russell King <rmk@...> 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@...

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

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.

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

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.

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

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

--- Linus Torvalds <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.
> 
> 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@...

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

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

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

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

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

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

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

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

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

On Sat, Oct 25, 2003 at 11:37:05AM -0700, Linus Torvalds wrote:

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

XFree86 cares more about being a useable X server on a wide range of
platforms than on playing well with a few Linux-specific hacks.

The real problem is that you have a mix of ideologies in the Linux
kernel, each struggling for supremacy.  Come back to us when you know
who the winner is.  At that time I'm sure you'll feel free to re-write
history and claim that we should have been doing things that way all
along.

David
-- 
David Dawes
Founder/committer/developer                     The XFree86 Project
 http://www.XFree86.org/~dawes

On Mon, 2003-10-27 at 16:40, David Dawes wrote:
> On Sat, Oct 25, 2003 at 11:37:05AM -0700, Linus Torvalds wrote:
> 
> >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.
> 
> XFree86 cares more about being a useable X server on a wide range of
> platforms than on playing well with a few Linux-specific hacks.
> 
> The real problem is that you have a mix of ideologies in the Linux
> kernel, each struggling for supremacy. 

Interesting. Could you care to elaborate?

-- 
Torgeir Veimo <torgeir@...>

On Thu, Oct 23, 2003 at 02:31:44PM -0700, 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. I'm looking at
>adding the resource marking code right now.

Can't the kernel figure out which resources are mapped by user-land by
monitoring mmaps of /dev/mem or the /proc/bus/pci/... nodes?

David
-- 
David Dawes
Founder/committer/developer                     The XFree86 Project
 http://www.XFree86.org/~dawes

David Dawes wrote:
> On Sat, Oct 25, 2003 at 11:37:05AM -0700, Linus Torvalds wrote:
> 
>>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.
> 
> XFree86 cares more about being a useable X server on a wide range of
> platforms than on playing well with a few Linux-specific hacks.
> 
> The real problem is that you have a mix of ideologies in the Linux
> kernel, each struggling for supremacy.  Come back to us when you know
> who the winner is.  At that time I'm sure you'll feel free to re-write
> history and claim that we should have been doing things that way all
> along.

I'm really baffled here.  Why would you even say such a thing?  In 
relation to Linus' *whole* message, your first paragraph and second 
paragraph are incongruous.  Linus (or anyone else) did not suggest that 
XFree86 be shoe-horned into any of the existing Linux video driver 
architectures.  In fact, he said quite the opposite.  He said that 
XFree86 is trying to do things that really do need kernel support, and 
all the existing methods for doing that suck.

Part of the problem is that, with the exception of DRI, the existing 
video specific interfaces in Linux were, as far as I know, created 
without input from XFree86.  You're suggesting that same mistake be 
repeated.

I'm also baffled by the general animosty shown towards Linux.  Judging 
by the traffic on the various lists, it seems to me that Linux and *BSD 
represent the lion's share of the XFree86 user base.  Making a consious 
choice to not support those platforms better is making a consious choice 
to not support our users.  I simply don't understand the rationalle 
behind such a decision.

Not only that, there is no requirement that the drivers use any given 
kernel interface.  Just because the drivers use a kernel interface on 
Linux or *BSD does not mean that they have to use a kernel interface on 
Solaris or HPUX.  There will be growing pains involved in having a 
kernel path and a non-kernel path.  I think that several of the DRI 
drivers (Radeon and Rage128) have shown that it *is* doable.

The next step is to create a kernel interface that is both generic 
enough and specific enough to acomplish the task at hand.  After 
watching the development of fbdev / fbcon, DRI, and XFree86 for a long 
time, I can say that there is no point in squabling over whether or not 
a kernel interface is useful for performance or necessary for proper 
device configuration.  Both of those questions have been sufficiently 
answered.  The question of where we go from here has not been answered.

On Mon, 27 Oct 2003, Ian Romanick wrote:
> 
> I'm also baffled by the general animosty shown towards Linux.

I don't think it is animosity vs Linux per se, but I do think that XFree86 
tends to have a very strong bias against infrastructure change. 

Which is somewhat understandable: I'm a kernel person, so infrastructure 
change is what I'm all about, but most other projects really hate having 
any kind of rug pulled out from under them. 

And kernel modules are _nasty_. From past experience, I can just say that
external kernel modules (ones not integrated into the standard kernel
tree) just generate a lot of pain on all sides. Users, project developers, 
and kernel developers universally _hate_ having to try to keep external 
modules working and debugging the problems that inevitably happen when 
they don't work.

So animosity toward them is certainly understandable - they just don't
work very well, and are a total maintenance nightmare.

This is the reason why I decided I had to follow the DRI CVS tree: just to
try to make the DRI kernel modules basically irrelevant to most people. My
theory is that peopel are more likely to happily upgrade the whole kernel
than to try to fight the version skew that inevitable happens with
external kernel modules.

This is, btw, also the reason why I have been an asshole about backwards
compatibility wrt the DRI project, and was less-than-perfectly-polite to
some people when DRI upgrades caused older setups to fail. That's simply
because my belief is that version skew is simply unacceptable, which means
that the only _acceptable_ situation is to try to make it ok to always
have the most recent kernel.

So otherwise we'd have to go back to the "use external modules" thing,
which I just don't believe works.

This is also the reason I believe that the only really workable way to
handle this is to have a very version-neutral (and thus _stupid_)  
minimal driver for handling the low-level needs of all the projects
involved (DRI/XFree86/fbcon). Exactly to avoid the possibility of version
skew.

In other words, I'd keep it so simple that versions don't really matter,
because the low-level driver doesn't do enough complex things that you'd
be forced to upgrade it all the time. I don't think fbdev is at all the 
proper interface - I think the proper interface is something that is so 
close to the hardware that the hardware _forces_ all issues, and there are 
never any questions of what the low-level driver should be.

And since people still want to run X on old setups too, clearly X will 
have to have the ability to have its own user-space module. That's needed 
for other operating systems _anyway_, so this wouldn't obviate that. 

			Linus

> In other words, I'd keep it so simple that versions don't really matter,
> because the low-level driver doesn't do enough complex things that you'd
> be forced to upgrade it all the time. I don't think fbdev is at all the 
> proper interface - I think the proper interface is something that is so 
> close to the hardware that the hardware _forces_ all issues, and there are 
> never any questions of what the low-level driver should be.
> 
> And since people still want to run X on old setups too, clearly X will 
> have to have the ability to have its own user-space module. That's needed 
> for other operating systems _anyway_, so this wouldn't obviate that. 

I see your point about fbdev not beeing the proper interface here.

But then, what would be the relationchip between that low level stuff
and fbdev ? (fbdev beeing a driver providing basically mode setting &
basic framebuffer support for client applications, fbcon beeing just
one of them here, with possibly later on some accel modules as well)

Same question goes for XFree.

Do they still just map register space and blast registers ? Or do you
expect all register accesses to go through some kind of "command pipe" ?

There are lots of tricky things to do especially at board init time
that basically require direct register access (and if possible beeing
in the kernel with irq off for subtle things like "measuring" the
board PLL, unfortunately necessary on some cards).

So the main service the "low level" module would provide would be
just basic card identification (list of PCI IDs), mapping facilities
for fb & registers, arbitration so that things like fbdev can get full
ownership (prevent ring commands) when mode switching & such, and the
actual DMA/IRQ command blasting engine (equivalent of current DRI module).

This looks like just an extension of the current DRI modules, and having
things like fbdev stack on top of them...

Ben.

On Tue, 28 Oct 2003, Benjamin Herrenschmidt wrote:
> 
> I see your point about fbdev not beeing the proper interface here.
> 
> But then, what would be the relationchip between that low level stuff
> and fbdev ?

My suggestion, as a starting point, is to really think very rudimentary at
first. A truly _minimal_ thing. Minimal partly because that just avoids
all the interface design issues ("there are none" ;), but partly because
everybody involved will have rather different goals. In particular, the
XFree86 people would have as a goal to keep the differences to a
user-space implementation minimal, so in that sense you really want to
have an abstraction that doesn't hide the hardware AT ALL.

NOTE! I'm not saying this is necessarily the best interface or a truly 
great idea. This is just throwing out my thought of the day. I'm nothing 
if not flexible - some people think I change my mind _too_ often ;)

So the thing should really just have 
 - discovery and attach/detach
 - interrupt event notification (and it can't just be "an interrupt 
   happened" - the interrupt driver actually has to know enough to ACK the
   interrupt, so that we can tell user space that an interrupt happened 
   without having to disable the interrupt until the event goes away)
 - serialization (ie a lock) and waiting for events ("engine idle" or 
   "command queue less than half full")
 - DMA arbitration and setup.

Most of the rest (actual IO accesses etc) can be done outside the lowlevel
crud, once you have the lock. This is also why DMA really _is_ special,
since it's asynchronous: so it can and does happen independently of the
lock. But normal synchronous programmed IO doesn't need any real help, and 
there's no point in forcing that into the low-level driver. All the users 
might as well do any direct IO directly.

So the low-level driver wouldn't know about palettes or cursors or any 
"high-level" concepts like that. It would have a few locks to make sure 
that the users that try to access the things don't stop on each other, 
nothing more (maybe the locks themselves would be grouped into "palette 
lock" vs "cursor lock" vs "DMA engine lock" since hardware may be threaded 
enough to allow it, but the point is that the low-level driver wouldn't 
actually _do_ anything, it only allows others to do what they want without 
stomping on each others toes).

Is this wonderful and solves all problems? Hell no. The interfaces would 
be pretty ugly and specialized.

That doesn't mean that there aren't any issues at all. For example for
locking, you probably don't want just "lock" and "unlock": you'd likely 
want the low-level driver to implement the "expensive lock", but do your 
own cheap locks in low-level drivers. That in turn means that the 
lowlevel lock needs to have a "please release the lock" callback thing. 
Something that works for everybody. Which might not be all that east at 
all.

> There are lots of tricky things to do especially at board init time
> that basically require direct register access (and if possible beeing
> in the kernel with irq off for subtle things like "measuring" the
> board PLL, unfortunately necessary on some cards).

This is exactly the kinds of things I would advice against very strongly. 
You do _not_ want to have a common driver that knows that much about the 
hardware. Because if the common driver has to know all the esoteric 
details, there's no way it will get them all right. And once it gets 
something wrong, people start trying to work around it and have driver 
quirks and version dependencies etc.

> This looks like just an extension of the current DRI modules, and having
> things like fbdev stack on top of them...

Quite the reverse, I think. It would be a _shrink_ of the DRI modules.

		Linus

On Mon, Oct 27, 2003 at 06:13:32PM -0800, Linus Torvalds wrote:
>..
> So the thing should really just have 
>  - discovery and attach/detach
>  - interrupt event notification (and it can't just be "an interrupt 
>    happened" - the interrupt driver actually has to know enough to ACK the
>    interrupt, so that we can tell user space that an interrupt happened 
>    without having to disable the interrupt until the event goes away)
>  - serialization (ie a lock) and waiting for events ("engine idle" or 
>    "command queue less than half full")
>  - DMA arbitration and setup.
>[....]
> So the low-level driver wouldn't know about palettes or cursors or any 
> "high-level" concepts like that. It would have a few locks to make sure 
> that the users that try to access the things don't stop on each other, 
> nothing more (maybe the locks themselves would be grouped into "palette 
> lock" vs "cursor lock" vs "DMA engine lock" since hardware may be threaded 
> enough to allow it, but the point is that the low-level driver wouldn't 
> actually _do_ anything, it only allows others to do what they want without 
> stomping on each others toes).

Sounds like a good idea. Simple Is Better.

Now, would that "DMA arbitration" include
"submit a chunk o dma memory for GPU processing",

or would it just allow [whatever] to map the registers, and basically say,
"I'll tell you when something completes (aka sends an interrupt)
 but it's up to you to START it"

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

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

> > I see your point about fbdev not beeing the proper interface here.
> > 
> > But then, what would be the relationchip between that low level stuff
> > and fbdev ?
> 
> My suggestion, as a starting point, is to really think very rudimentary at
> first. A truly _minimal_ thing. Minimal partly because that just avoids
> all the interface design issues ("there are none" ;), but partly because
> everybody involved will have rather different goals. In particular, the
> XFree86 people would have as a goal to keep the differences to a
> user-space implementation minimal, so in that sense you really want to
> have an abstraction that doesn't hide the hardware AT ALL.
> 
> NOTE! I'm not saying this is necessarily the best interface or a truly 
> great idea. This is just throwing out my thought of the day. I'm nothing 
> if not flexible - some people think I change my mind _too_ often ;)
> 
> So the thing should really just have 
>  - discovery and attach/detach
>  - interrupt event notification (and it can't just be "an interrupt 
>    happened" - the interrupt driver actually has to know enough to ACK the
>    interrupt, so that we can tell user space that an interrupt happened 
>    without having to disable the interrupt until the event goes away)
>  - serialization (ie a lock) and waiting for events ("engine idle" or 
>    "command queue less than half full")
>  - DMA arbitration and setup.

   This is good design for DMA based graphics cards. Unfortunely at present 
maybe one fbdev driver actaully uses DMA (i810fb). Almost all fbdev drivers 
use IO access :-( Sure we could convert as many as possible to DMA, which I was 
planning to do anyways :-)
 
> Most of the rest (actual IO accesses etc) can be done outside the lowlevel
> crud, once you have the lock. This is also why DMA really _is_ special,
> since it's asynchronous: so it can and does happen independently of the
> lock. But normal synchronous programmed IO doesn't need any real help, and 
> there's no point in forcing that into the low-level driver. All the users 
> might as well do any direct IO directly.
> 
> So the low-level driver wouldn't know about palettes or cursors or any 
> "high-level" concepts like that. It would have a few locks to make sure 
> that the users that try to access the things don't stop on each other, 
> nothing more (maybe the locks themselves would be grouped into "palette 
> lock" vs "cursor lock" vs "DMA engine lock" since hardware may be threaded 
> enough to allow it, but the point is that the low-level driver wouldn't 
> actually _do_ anything, it only allows others to do what they want without 
> stomping on each others toes).

   Unfortunely most fbdev drivers set the hardware in IO access mode. Plus 
some of the devices lack any kind of DMA support. In this case seperating 
out the parts of the driver that program the "high level" stuff leaves 
almost nothing left. Would it still be wise to seperate it out as you 
suggest? Would we really gain that much doing this for the case of IO 
access only graphics hardware?  	

> > This looks like just an extension of the current DRI modules, and having
> > things like fbdev stack on top of them...
> 
> Quite the reverse, I think. It would be a _shrink_ of the DRI modules.

:-)

>    Unfortunely most fbdev drivers set the hardware in IO access mode. Plus 
> some of the devices lack any kind of DMA support. In this case seperating 
> out the parts of the driver that program the "high level" stuff leaves 
> almost nothing left. Would it still be wise to seperate it out as you 
> suggest? Would we really gain that much doing this for the case of IO 
> access only graphics hardware?  	

The problem is the same. DMA or not DMA, what we want is arbitration.

When fbdev sets up a mode, the X server mustn't blast 2D engine (either
using PIO or sending DMA commands) etc... So that "arbitration" module
will have to provide the necessary arbitration so that the 2D/3D DMA
command flow can be interrupted (if any), and/or the hw access "lock"
passed between things like fbdev/fbcon and userland clients.

Right now, even plain fbdev as it exist is racy in this regard. Nothing
prevent an accelerated printk or cursor operation to happen in the middle
of a userland initiated mode switch, potentially locking up the card. My
latest radeonfb has minimal spinlock so at least the indirect register
accesses (like PLL) are safe, but it's still broken in some way.

Unfortunately, the way fbcon currently works, the only way to deal with
those issues is by taking the console semaphore on every fbdev operations.
(Thanks to printk & blanking coming from irq). If fbcon can completely
separate update of the text/attr buffer from actual refresh of the
framebuffer, it may be possible to do something smarter.

This problem isn't really an issue we need to deal with in that proposed
"low level" driver though. It's entirely an fbdev/fbcon issue that is
caused by having fbcon active on a VT, that is by having a KDTEXT VT.

I expect that when such a console is frontmost, the HW lock will be solely
owned by fbdev/fbcon. Only a KDGRAPHICS vt shall release that HW lock,
letting userland grab it for drawing operations, fbdev taking it only when
requested to do things like mode changes or palette changes.

Ben.

--- Benjamin Herrenschmidt <benh@...> wrote:
> The problem is the same. DMA or not DMA, what we want is arbitration.
> 
> When fbdev sets up a mode, the X server mustn't blast 2D engine (either
> using PIO or sending DMA commands) etc... So that "arbitration" module
> will have to provide the necessary arbitration so that the 2D/3D DMA
> command flow can be interrupted (if any), and/or the hw access "lock"
> passed between things like fbdev/fbcon and userland clients.

Do we really want arbitration between multiple things (FB, X, DRI, etc) all
trying to control the video hardware at a register level? This is like writing
a multitaking system for device drivers.

Or do we want a single device driver with multiple clients?

A major complaint from the framebuffer console people is that we have to do
mode setting/EDID in the device driver so that there is a console to look at
from the first second the kernel boots. This also means we have to map the
framebuffer into kernel space (sucking up to 256MB of kernel address space).

In the 2.7 time frame is it possible to write a low level driver like Linus
proposed plus a small DSO for mode setting/EDID. Then write fbconsole as a user
space app that is loaded much eariler in the boot process than user-mode
currently starts? In other words is there a solution to having a boot time
console that doesn't involve running it in a device driver?

Another possible solution to the boot time problem would be to write a
disposable device driver. The disposable driver would set the mode/EDID and run
the console until user mode started; then self destruct. 

=====
Jon Smirl
jonsmirl@...

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

On Tue, Oct 28, 2003 at 02:09:40PM -0800, Jon Smirl wrote:
> Another possible solution to the boot time problem would be to write a
> disposable device driver. The disposable driver would set the mode/EDID and run
> the console until user mode started; then self destruct. 

that doesnt sound very appealing.

On Wed, 2003-10-29 at 09:09, Jon Smirl wrote:

> Do we really want arbitration between multiple things (FB, X, DRI, etc) all
> trying to control the video hardware at a register level? This is like writing
> a multitaking system for device drivers.
> 
> Or do we want a single device driver with multiple clients?

Here, you are going away from Linus suggestion. While it makes sense
too, it would be a real pain to keep that single driver in sync between
the different parties, to keep backward compatibility, etc... re-read
Linus emails on this topic. I tend to agree with him here, what we want
is a small low level layer that does the strict minimum to provide
DMA/irq and arbitration.

> A major complaint from the framebuffer console people is that we have to do
> mode setting/EDID in the device driver so that there is a console to look at
> from the first second the kernel boots. This also means we have to map the
> framebuffer into kernel space (sucking up to 256MB of kernel address space).

That mode setting / EDID is done in drivers on other platforms as well,
I don't see the problem here. It's the basic "feature" provided by the
framebuffer driver, it doesn't only make sense for fbcon but also for
other framebuffer apps.

Mapping the framebuffer into kernel space isn't necessary. It's how
today's fbcon works, but it's not mandatory. In fact, if fbcon was
fully accelerated, mapping the fb would be useless.

> In the 2.7 time frame is it possible to write a low level driver like Linus
> proposed plus a small DSO for mode setting/EDID. 

DSO ? Can you translate ?

> Then write fbconsole as a user
> space app that is loaded much eariler in the boot process than user-mode
> currently starts? In other words is there a solution to having a boot time
> console that doesn't involve running it in a device driver?

So we lose the ability to get early boot messages and printk at
interrupt time ? no thanks ! Looks you aren't regulary faced with the
need to debug kernel code ;)

> Another possible solution to the boot time problem would be to write a
> disposable device driver. The disposable driver would set the mode/EDID and run
> the console until user mode started; then self destruct. 

fbcon can still be in the kernel. I see no point in your push to move it
down to userland, provided that it stays a clearly separate entity from the
fbdev itself, just another client.

Ben.

On Tue, 28 Oct 2003, James Simmons wrote:
> 
>    This is good design for DMA based graphics cards. Unfortunely at present 
> maybe one fbdev driver actaully uses DMA (i810fb). Almost all fbdev drivers 
> use IO access :-( Sure we could convert as many as possible to DMA, which I was 
> planning to do anyways :-)

Even if you don't use DMA, you still want the discovery/enumeration and
serialization parts, which you want in the kernel.

And if the driver ends up being really small - all the better. If the card 
literally doesn't even have a command buffer (ie a truly stupid entirely 
synchronous IO programming model like classic VGA) then the driver won't 
even need the "wait for command ring empty" kind of thing.

Now, your reaction might be that "oh, but what a wasteful thing to have a
driver for just a simple serialization and discovery". True. But on the
other hand, it's not like it would be actually wasting that much, and the
nice thing is that this kind of truly minimal driver that doesn't have to
worry about DMA etc can quite likely be shared with pretty much _all_ of
the stupid cards. So we could have just _one_ driver that covers all of
the "this card doesn't do DMA or even retrace interrupts".

So don't worry about the fact that for some hardware the driver might be 
really simple. Even a simple driver is worth it if it means that we can 
have a unified model for synchronizing between the different agents that 
want to touch the video hardware. I think.

>    Unfortunely most fbdev drivers set the hardware in IO access mode. Plus 
> some of the devices lack any kind of DMA support.

I don't think this is "unfortunately" at all. Quite the reverse. If the
card doesn't use/need DMA, that just makes for a simple low-level driver.

The reason I mentioned DMA arbitration as a major thing the driver would
do is not because I think that every driver _has_ to have DMA. I mentioned
it specially because DMA is kind of special in that it is done
asynchronously and thus needs an abitration model that is above-and-beyond
just a normal "lock this card" thing.

			Linus

--- Philip Brown <phil@...> wrote:
> On Tue, Oct 28, 2003 at 02:09:40PM -0800, Jon Smirl wrote:
> > Another possible solution to the boot time problem would be to write a
> > disposable device driver. The disposable driver would set the mode/EDID and
> run
> > the console until user mode started; then self destruct. 
> 
> that doesnt sound very appealing.

This is not needed except on the very few systems that have no display support
in their boot ROMs. For example all PC class machines have VGA/VESA support at
boot time so they don't need it. I have been told that such machines exist but
no one have given me an example of one.

=====
Jon Smirl
jonsmirl@...

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