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

David Dawes wrote:

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

quoted

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.




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

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



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

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.



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

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



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

quoted

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?  	

quoted

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.

:-)




-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive?  Does it
help you create better code?   SHARE THE LOVE, and help us help
YOU!  Click Here: http://sourceforge.net/donate/

   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.
 



-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive?  Does it
help you create better code?   SHARE THE LOVE, and help us help
YOU!  Click Here: http://sourceforge.net/donate/

--- Benjamin Herrenschmidt <benh@kernel.crashing.org> 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@yahoo.com

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


-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive?  Does it
help you create better code?   SHARE THE LOVE, and help us help
YOU!  Click Here: http://sourceforge.net/donate/

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.




-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive?  Does it
help you create better code?   SHARE THE LOVE, and help us help
YOU!  Click Here: http://sourceforge.net/donate/

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



-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive?  Does it
help you create better code?   SHARE THE LOVE, and help us help
YOU!  Click Here: http://sourceforge.net/donate/