[Linux-fbdev-devel] Resource management.

[Jon Smirl]

On Tue, 22 Feb 2005 15:46:03 +1100, Dave Airlie <airlied at gmail.com> wrote:
> >
> > 1. Lots of work that would take lots of time. To my knowledge all fbdev
> >    developers work in there spare free time. No one does this for a
> >    living.
> 
> So do most of the drm developers, I know I do and Jon Smirl does, and
> Eric Anholt does and I think us three have been the largest
> contributers apart from new driver submissions...

As far as I know none of the significant contributors on either fbdev
or DRM are being paid to work on the project.

> > 2. Sharing of headers. The dri headers are isolated in the drm directory.
> >    I totally understand why :-) It makes merging easier for them. The
> >    disadvantage is no one in the fbdev can use them easily :-(
> 
> I plan to move them in 2.6.12 maybe .. it might be 2.6.13 by the time
> I get around to it, just some minor issues.. Arjan asked me for this
> ages ago as well...

I'd like to take this further and move the stuff in drivers/video to
drivers/video/fb and then
move drm from drivers/char/drm to drivers/video/drm. I'd also like to
consolidate drm and fbdev Kconfig menus.

> > 3. DRM has way to much functionality for most embedded devices. I have
> >    talked to embedded guys before and they want a simple api to work with.
> >    By default DRM builds in everything. A simple api mean alot to those
> >    guys. Plus the extra built in code bloat takes up to much space which
> >    is precious on embedded devices. If a devices doesn't support dma then
> >    the dma code doesn't need to be built in.
> 
> Well crap on that, the old DRM didn't build everything in people
> complained aw this code is too messy, build everything in, now you
> want to revert? damn you all!!! :-), I understand I'm just saying we
> can't have it both ways.. and too be honest I'm an embedded person and
> I just want it to work, with a Linux kernel you rarely get to an every
> byte counts embedded env, of if you are you aren't using the stock
> Linus kernel....

If you removed the EXPORT_SYMBOLs and compiled everything in, won't
the compiler just eliminate the dead code for you?

PCI Express is a big reason for the new core/personality split. There
are Nforce4 motherboards now with 16 16x sockets. That means you can
plug 16 different video cards in if you want. The days of a single AGP
slot are over. If someone will send me one (with the four Opteron
chips) I'll write drivers for it.


> > 4. Which comes to the next point. The code is not modular enough. Take
> >    drm_bufs.c. Everything is a ioctl function. This has a few disadvantages.
> >    One is the fbdev layer couldn't just link into it so fbcon could use
> >    it. The second is it's not easy to take advantage of things like sysfs.
> >    If you could untangle the code somewhat it would make life so much
> >    easier. That would include making life easier for OS ports.
> 
> the reason we can't take advantage of sysfs or anything like it is
> that we can't bind to the PCI device as we break things.. this is the
> root of a lot of our problems...

This not binding to the PCI device has to be fixed. DRM can not
support hotplug or suspend/resume without a device to bind to.

> Jon's last plan - was like to have a radeon basic module, with fb and
> drm personalities and in fact any number of personalities..taking
> radeon as example:
> base module : hotplug, reset, monitor probing, memory management, CP
> programming and locking.
> fb: adds accelerated fb functions using CP locking.
> drm: adds drm functionality on top of base module, drm ioctl interfaces etc..

I have already coded most of this up and it works for me.
Unfortunately I derived it from the DRM codebase instead of the fbdev
one. fbdev has changed too much in the last six months to allow a
simple merge. Now I'm regenerating patches against fbdev using my
prior code.

A smaller step is to just treat radeonfb as the base module. This will
eat up extra memory for x86 users and they will complain, but we can
split it into three pieces later.

I think good first step would simply be to get DRM and fbdev both into
drivers/video and get the DRM h files into include/linux.


> I've looked at Alans ideas on a vga_class driver and have decided they
> are unworkable due to the massive initial changes they involve in
> *every* fb/drm driver in the kernel, I cannot undertake a work of that
> magnitude without fb people being involved and the chances of breaking
> a lot of stuff.. maybe a 2.7 thing but I don't think we'll ever have a
> 2.7 for this stuff...

My head hurts thinking about how much editing this would involve.

> What I do think though is that ideas of a the vga class driver could
> be made into a helper module that the base graphics driver uses to do
> some standard things, like reset and stuff..
> 
> I'm hoping to get a better handle on these ideas and write something
> up.. but they are mostly Jons ideas better presented :-)
> 
> Dave.
> 


-- 
Jon Smirl
jonsmirl at gmail.com