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/