Re: Merging DRM and fbdev

[Jon Smirl]

Resource reservations are not the central problem with merging fbdev
and drm. The central problem is that both card specific drivers
initialize the hardware, program it in conflicting ways, allocate the
video memory differently, etc. Moving to a single card specific driver
lets me fix that.

In the final form both the VGA scheme and my code provide shared
resource reservation code. The main difference between the schemes is
that the VGA scheme allows multiple independent card drivers while
mine only allow a single merged one.

Multiple card drivers in the past has resulted in conflicting
programming of the hardware. I suppose we could write a bunch of rules
about how to share the hardware but that seems like a lot of
complicated work. The radeon has over 200 registers that would need
rules for what settings are allowed. It's a lot easier to simply merge
20K of radeonfb  driver into the radeondrm and eliminate this error
prone process.

If we could all just concentrate on fixing the radeondrm driver we
could build a complete driver for the radeon cards instead of the ten
half finished ones we have today. Once we get a complete driver the
incentive for people to write new ones will be gone.

The two models look like this:

vga - attached to hardware
   radeon-drm
      drm - library
   radeon-fb
      fb - library
         fbcon - library

My model....

radeon - attached to hardware
   drm - library
   fb - library
      fbcon - library

vga - independent driver, there is only one VGA device even if
multiple radeons. This driver is responsible for secondary card
resets.

In the first model radeon-drm and radeon-fb can run independently.
This requires duplication of the initialization code. Since the are
separate drivers they can and do have completely different models for
programming the hardware. At VT switch time the drivers have to
save/restore state.

In the second model it is not required that a driver support both fb
and drm. Something like cyber2000 does have to link in drm since it
has no use for it.

A complaint in the second model might be that the radeon driver is
120K. If some embedded system is really, really tight on RAM and they
are embedding a radeon but don't want to use its advanced abilities,
there is nothing stopping someone from splitting the radeon driver up
into pieces. I will happily take the patch. Doing this is probably a
week's worth of coding and testing to get maybe 50K memory savings.
Simplest way to do this is to add IFDEFs to remove drm support from
the merged radeon driver.

-- 
Jon Smirl
jonsmirl@xxxxxxxxx
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/