Thread (9 messages) 9 messages, 3 authors, 2003-09-12

Re: Re: New radeonfb 0.2.0 (take 2)

flat view

From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Date: 2003-09-09 07:58:55

On Tue, 2003-09-09 at 05:19, Jon Smirl wrote:
Just a thought, but what do you think about splitting radeonfb into two peices?
Sort of like the way this Rage128 driver is split, http://www.saftware.de/.

First piece does PCI IDs, EDID, mode setting, command parsing, maybe hardware
cursor.
Second does fbcon support such as mapping fb to kernel space, fb accels, etc.

My idea is that this model could evolve over time into having a base driver for
each card, and then the FB or DRI drivers would plug into the base. This would
provide a common place to put locking and state saving code.
Currently, I have split it in:

 - radeon_base : basic PCI registration, CRTC setting (CRTC1 only for now,
if/when I implement CRTC2, I'll move it to a spearate file), and all other
normal driver operations

 - radeon_i2c : the i2c interface low level & EDID DDC2 code

 - radeon_monitor : monitor probing logic & modedb building. This code probes
both heads, eventually uses the i2c code and/or BIOS/OF provided informations

 - radeon_pm : the power management code (mostly used on PowerBooks for now)

I suppose radeon_base could be further split, though you may now that there
is no longer any dependency on fbcon in the fbdev driver per se, most of this
have been removed from 2.6 drivers, so there isn't much point in splitting
the fbcon related part outside of the driver...

What I want to do though is, if/when I add accel back, a separate radeon_accel
file with the accelerated primitives.

Ben.



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help