From: Jon Smirl <hidden> Date: 2003-09-09 03:19:14
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.
=====
Jon Smirl
jonsmirl@yahoo.com
__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
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
From: Jon Smirl <hidden> Date: 2003-09-09 14:52:03
I meant make it into two separate device drivers, not just split the files.
Then the user could load base+DRI, base+FB or base+FB+DRI. This would minimize
the RAM footprint and let the DRI people avoid the problem of mapping the
framebuffer into kernel space.
=====
Jon Smirl
jonsmirl@yahoo.com
__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
From: Benjamin Herrenschmidt <benh@kernel.crashing.org> Date: 2003-09-09 15:22:50
On Tue, 2003-09-09 at 16:52, Jon Smirl wrote:
I meant make it into two separate device drivers, not just split the files.
Then the user could load base+DRI, base+FB or base+FB+DRI. This would minimize
the RAM footprint and let the DRI people avoid the problem of mapping the
framebuffer into kernel space.
Well, what would base do then ? You can only set modes etc... by beeing
an fbdev, and if you are an fbdev you have to map something for fbcon...
What would 'base' be without all of this ? just the PCI probing ?
Ben.
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
From: Jon Smirl <hidden> Date: 2003-09-09 15:58:27
--- Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
On Tue, 2003-09-09 at 16:52, Jon Smirl wrote:
What would 'base' be without all of this ? just the PCI probing ?
Base does PCI IDs, EDID, mode setting, command parsing, maybe hardware cursor,
VT switching and state saving.
Second piece does fbcon support such as mapping fb to kernel space, fb accels,
etc.
Base is not meant to be used as a standalone driver. It will always be used in
conjunction with FB or DRI driver.
=====
Jon Smirl
jonsmirl@yahoo.com
__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
From: Benjamin Herrenschmidt <benh@kernel.crashing.org> Date: 2003-09-09 16:17:57
On Tue, 2003-09-09 at 17:58, Jon Smirl wrote:
quoted hunk
--- Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
quoted
On Tue, 2003-09-09 at 16:52, Jon Smirl wrote:
What would 'base' be without all of this ? just the PCI probing ?
Base does PCI IDs, EDID, mode setting, command parsing, maybe hardware cursor,
VT switching and state saving.
Second piece does fbcon support such as mapping fb to kernel space, fb accels,
etc.
The current fbdev layer, afaik, impose vt switching, mode setting,
cursor support etc... to imply fbcon. The mapping of fb is just a
2 liner remaining that isn't worth a separate module.
Also, the accel API in 2.6 is meant to be used by more than just
fbcon afaik.
James, can you comment on this ?
Ben.
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
From: James Simmons <hidden> Date: 2003-09-12 17:51:17
quoted
Base does PCI IDs, EDID, mode setting, command parsing, maybe hardware cursor,
VT switching and state saving.
Second piece does fbcon support such as mapping fb to kernel space, fb accels,
etc.
The current fbdev layer, afaik, impose vt switching, mode setting,
cursor support etc... to imply fbcon. The mapping of fb is just a
2 liner remaining that isn't worth a separate module.
Correct.
Also, the accel API in 2.6 is meant to be used by more than just
fbcon afaik.
James, can you comment on this ?
Originally I had ioctl for the accel stuff for testing purposes. Ites
expensive tho. I wonder if using sysfs for this would be worth it?
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
From: James Simmons <hidden> Date: 2003-09-12 17:52:27
I meant make it into two separate device drivers, not just split the files.
Then the user could load base+DRI, base+FB or base+FB+DRI. This would minimize
the RAM footprint and let the DRI people avoid the problem of mapping the
framebuffer into kernel space.
Nice. That is what struct xxx_par was for. The idea was that in the future
a core could be implemented xxx_par that could be shared by both DRI and
fbdev.
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
From: James Simmons <hidden> Date: 2003-09-12 17:53:51
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.
Nice :-) The Mach64 driver has a simliar structure.
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf