Merging DRM and fbdev

Merging DRM and fbdev

[Jon Smirl]

I've started on a merged fbdev and DRM driver model. 
It doesn't work yet but here's what the modules look like:

Module                  Size  Used by
fbcon                  38080  0
radeon                123598  1
fb                     34344  2 fbcon,radeon
drm                    59044  1 radeon

fbcon and fb modules are almost unmodified from the kernel source.
radeonfb and radeondrm have been merged into a single driver. The
merged driver uses both the drm and fb modules as libraries. It wasn't
possible to build this model until drm supported drm-core.

The radeon and fb modules will get smaller, I'm just beginning to use
the delete key on them. There is still a lot of duplicated code inside
the radeon driver.

In this model a non-drm, fb only driver like cyber2000 could load only
the fb and fbcon modules. I need to do some work rearranging generic
library support functions to allow this.

This is the next phase in the work described in this email:
http://lkml.org/lkml/2004/8/2/111

-- 
Jon Smirl
jonsmirl@gmail.com

Re: Merging DRM and fbdev

[Dave Airlie]

> In this model a non-drm, fb only driver like cyber2000 could load only
> the fb and fbcon modules. I need to do some work rearranging generic
> library support functions to allow this.
>

I think the stated issue with this is, how big the fb driver now becomes
because all the DRM stuff is in it... I think a radeon common, with
radeonfb/radeondrm is probably going to be needed,

Hopefully tomorrow (I've a day off, but the weather is getting nice as
well :-), I'll get some time to port some stuff to the vga class stuff,

I also want to prepare some patches for the kernel for the previous work
you've done ...

Dave.

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@gmail.com

Re: Merging DRM and fbdev

[Vladimir Dergachev]

On Sun, 3 Oct 2004, Jon Smirl wrote:

> 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.



> My model....
>
> radeon - attached to hardware
>   drm - library
>   fb - library
>      fbcon - library

Can we add to this "km" library ? (That's the GATOS v4l module)

In particular, I can contribute the code that does Framebuffer->System Ram
transfers over PCI/AGP. It is currently GPL licensed, but there is no 
problem if BSD folks want it too.

This is also potentially useful for any Mesa functions that want to 
transfer data back from video RAM - using plain reads for this is really slow.

                           best

                              Vladimir Dergachev

Re: Merging DRM and fbdev

[Jon Smirl]

On Sun, 3 Oct 2004 11:50:50 -0400 (EDT), Vladimir Dergachev
<volodya@mindspring.com> wrote:
> On Sun, 3 Oct 2004, Jon Smirl wrote:
> 
> > 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.
> 
> > My model....
> >
> > radeon - attached to hardware
> >   drm - library
> >   fb - library
> >      fbcon - library
> 
> Can we add to this "km" library ? (That's the GATOS v4l module)
> 
> In particular, I can contribute the code that does Framebuffer->System Ram
> transfers over PCI/AGP. It is currently GPL licensed, but there is no
> problem if BSD folks want it too.
> 
> This is also potentially useful for any Mesa functions that want to
> transfer data back from video RAM - using plain reads for this is really slow.

Drivers are free to call as many libraries as they want....

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

Libraries are kernel modules that don't attach to any specific
hardware, they just supply routines for other drivers to call. We
might want to change the name of these to libdrm, libfb, libkm.

I haven't looked into Gatos yet but I'd like to see the radeon
converted to follow the model of all of the other vl4 cards instead of
having it's own system. In the X on GL world the 2D XAA radeon driver
is gone. Gatos support will need to live somewhere else.

-- 
Jon Smirl
jonsmirl@gmail.com

Re: Merging DRM and fbdev

[Vladimir Dergachev]

>   km - library
>
> Libraries are kernel modules that don't attach to any specific
> hardware, they just supply routines for other drivers to call. We
> might want to change the name of these to libdrm, libfb, libkm.
>
> I haven't looked into Gatos yet but I'd like to see the radeon
> converted to follow the model of all of the other vl4 cards instead of
> having it's own system. In the X on GL world the 2D XAA radeon driver
> is gone. Gatos support will need to live somewhere else.

Jon, this is a common misconception - GATOS km module *does* provide a v4l 
interface.

What is different is that the device configuration (like setting the tuner 
or encoding) is done by Xserver.

All km does is check whether the card can supply a v4l stream and, if so, 
it provides it. This is little different from a webcam driver, especially
if a webcam has its own on/off switch.

The misconception arises from the fact that many v4l programs were only 
made to work with bt848 cards - they would *not* work with webcams any
more than they would work with km.

                               best

                                 Vladimir Dergachev

>
> -- 
> Jon Smirl
> jonsmirl@gmail.com
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
> Use IT products in your business? Tell us what you think of them. Give us
> Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
> http://productguide.itmanagersjournal.com/guidepromo.tmpl
> --
> _______________________________________________
> Dri-devel mailing list
> Dri-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/dri-devel
>

Re: Merging DRM and fbdev

[Jon Smirl]

How is the tuner controlled? Is it a V4L insterface?


On Sun, 3 Oct 2004 12:59:38 -0400 (EDT), Vladimir Dergachev
<volodya@mindspring.com> wrote:
> Jon, this is a common misconception - GATOS km module *does* provide a v4l
> interface.
> 
> What is different is that the device configuration (like setting the tuner
> or encoding) is done by Xserver.
> 
> All km does is check whether the card can supply a v4l stream and, if so,
> it provides it. This is little different from a webcam driver, especially
> if a webcam has its own on/off switch.
> 
> The misconception arises from the fact that many v4l programs were only
> made to work with bt848 cards - they would *not* work with webcams any
> more than they would work with km.
> 
>                                best
> 
>                                  Vladimir Dergachev
> 
> >
> > --
> > Jon Smirl
> > jonsmirl@gmail.com
> >
> >
> > -------------------------------------------------------
> > This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
> > Use IT products in your business? Tell us what you think of them. Give us
> > Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
> > http://productguide.itmanagersjournal.com/guidepromo.tmpl
> > --
> > _______________________________________________
> > Dri-devel mailing list
> > Dri-devel@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/dri-devel
> >
> 



-- 
Jon Smirl
jonsmirl@gmail.com

Re: Merging DRM and fbdev

[Vladimir Dergachev]

On Sun, 3 Oct 2004, Jon Smirl wrote:

> How is the tuner controlled? Is it a V4L insterface?

No, the tuner is controlled via Xserver Xv extension. No V4L interface is 
provided for tuner control.

                       best

                          Vladimir Dergachev

>
>
> On Sun, 3 Oct 2004 12:59:38 -0400 (EDT), Vladimir Dergachev
> <volodya@mindspring.com> wrote:
>> Jon, this is a common misconception - GATOS km module *does* provide a v4l
>> interface.
>>
>> What is different is that the device configuration (like setting the tuner
>> or encoding) is done by Xserver.
>>
>> All km does is check whether the card can supply a v4l stream and, if so,
>> it provides it. This is little different from a webcam driver, especially
>> if a webcam has its own on/off switch.
>>
>> The misconception arises from the fact that many v4l programs were only
>> made to work with bt848 cards - they would *not* work with webcams any
>> more than they would work with km.
>>
>>                                best
>>
>>                                  Vladimir Dergachev
>>
>>>
>>> --
>>> Jon Smirl
>>> jonsmirl@gmail.com
>>>
>>>
>>> -------------------------------------------------------
>>> This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
>>> Use IT products in your business? Tell us what you think of them. Give us
>>> Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
>>> http://productguide.itmanagersjournal.com/guidepromo.tmpl
>>> --
>>> _______________________________________________
>>> Dri-devel mailing list
>>> Dri-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/dri-devel
>>>
>>
>
>
>
> -- 
> Jon Smirl
> jonsmirl@gmail.com
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
> Use IT products in your business? Tell us what you think of them. Give us
> Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
> http://productguide.itmanagersjournal.com/guidepromo.tmpl
> --
> _______________________________________________
> Dri-devel mailing list
> Dri-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/dri-devel
>

Re: Merging DRM and fbdev

[Jon Smirl]

Is there are device driver level interface defined for controlling
tuners? Or is this something that even needs to be done in a device
driver? With X on GL Xv will have to change form too.

On Sun, 3 Oct 2004 16:37:03 -0400 (EDT), Vladimir Dergachev
<volodya@mindspring.com> wrote:
> 
> 
> On Sun, 3 Oct 2004, Jon Smirl wrote:
> 
> > How is the tuner controlled? Is it a V4L insterface?
> 
> No, the tuner is controlled via Xserver Xv extension. No V4L interface is
> provided for tuner control.
> 
>                        best
> 
>                           Vladimir Dergachev
> 
> 
> 
> >
> >
> > On Sun, 3 Oct 2004 12:59:38 -0400 (EDT), Vladimir Dergachev
> > <volodya@mindspring.com> wrote:
> >> Jon, this is a common misconception - GATOS km module *does* provide a v4l
> >> interface.
> >>
> >> What is different is that the device configuration (like setting the tuner
> >> or encoding) is done by Xserver.
> >>
> >> All km does is check whether the card can supply a v4l stream and, if so,
> >> it provides it. This is little different from a webcam driver, especially
> >> if a webcam has its own on/off switch.
> >>
> >> The misconception arises from the fact that many v4l programs were only
> >> made to work with bt848 cards - they would *not* work with webcams any
> >> more than they would work with km.
> >>
> >>                                best
> >>
> >>                                  Vladimir Dergachev
> >>
> >>>
> >>> --
> >>> Jon Smirl
> >>> jonsmirl@gmail.com
> >>>
> >>>
> >>> -------------------------------------------------------
> >>> This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
> >>> Use IT products in your business? Tell us what you think of them. Give us
> >>> Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
> >>> http://productguide.itmanagersjournal.com/guidepromo.tmpl
> >>> --
> >>> _______________________________________________
> >>> Dri-devel mailing list
> >>> Dri-devel@lists.sourceforge.net
> >>> https://lists.sourceforge.net/lists/listinfo/dri-devel
> >>>
> >>
> >
> >
> >
> > --
> > Jon Smirl
> > jonsmirl@gmail.com
> >
> >
> > -------------------------------------------------------
> 
> 
> > This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
> > Use IT products in your business? Tell us what you think of them. Give us
> > Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
> > http://productguide.itmanagersjournal.com/guidepromo.tmpl
> > --
> > _______________________________________________
> > Dri-devel mailing list
> > Dri-devel@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/dri-devel
> >
> 



-- 
Jon Smirl
jonsmirl@gmail.com

Re: Merging DRM and fbdev

[Alan Cox]

On Sul, 2004-10-03 at 23:42, Jon Smirl wrote:
> Is there are device driver level interface defined for controlling
> tuners?

Both at the Xv and the kernel level yes.

Re: Merging DRM and fbdev

[Alan Cox]

On Sul, 2004-10-03 at 16:50, Vladimir Dergachev wrote:
> In particular, I can contribute the code that does Framebuffer->System Ram
> transfers over PCI/AGP. It is currently GPL licensed, but there is no 
> problem if BSD folks want it too.

This will do *wonders* to X render performance if used properly on those
cards we can't do render in hardware.

> This is also potentially useful for any Mesa functions that want to 
> transfer data back from video RAM - using plain reads for this is really slow.

Agreed - and Mesa tends to skip even tricks like SSE2 that can quadruple
read performance.

Re: Merging DRM and fbdev

[Vladimir Dergachev]

On Sun, 3 Oct 2004, Alan Cox wrote:

> On Sul, 2004-10-03 at 16:50, Vladimir Dergachev wrote:
>> In particular, I can contribute the code that does Framebuffer->System Ram
>> transfers over PCI/AGP. It is currently GPL licensed, but there is no
>> problem if BSD folks want it too.
>
> This will do *wonders* to X render performance if used properly on those
> cards we can't do render in hardware.
>
>> This is also potentially useful for any Mesa functions that want to
>> transfer data back from video RAM - using plain reads for this is really slow.
>
> Agreed - and Mesa tends to skip even tricks like SSE2 that can quadruple
> read performance.

I am glad to see such enthusiasm :)

The code I have only does it on ATI cards (all radeons, all rage128, some 
mach64). The radeon code is the one that is known to work well.

My personal interest is that Framebuffer -> System Ram transfer is needed
if one wants to use Radeon GPUs for numerical computation. Thus, if there 
is an agreement on what needs to be done and what modifications are 
acceptable I can make this a priority.

What kind of interface would different projects want ? Should I wait for 
Jon's modifications to complete ? What people should we include on CC list ?

Also here is a short description of current km design:

     * km.[c,h] - this provides module registration and DMA queue
       virtualization (note: this is GUI_DMA queue, different from what
       DRM uses)

     * radeon.c, rage128.c, mach64.c - these are hardware specific
       functions

     * km_memory.[c,h] - this is v4l code for reverse mapping, I guess
       it is obsolete in 2.6.x kernels

     * km_api.[c,h] km_api_data.[c,h] - this is a new interface for
       video (and similar devices), an experiment to implement features
       not present in v4l or v4l2.
       ** I am not suggesting this be included. **

     * km_v4l.c - this is a client of km_api that provides v4l
       interface.

The first two pieces can be ported with ease - there are few modifications 
to be made, just cut the code that registers the driver.

The km_api piece will need to be replaced with interface everyone agrees 
on.

Please let me know your comments !

                         best

                            Vladimir Dergachev



>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
> Use IT products in your business? Tell us what you think of them. Give us
> Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
> http://productguide.itmanagersjournal.com/guidepromo.tmpl
> --
> _______________________________________________
> Dri-devel mailing list
> Dri-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/dri-devel
>

Re: Merging DRM and fbdev

[Mike Mestnik]

What about moving the DRM and FB specific code into there own per card
libs?

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

Keeping in mind that any/all external symbols to/from radeon-drm and
radeon-fb can/should be weak.



	
		
__________________________________
Do you Yahoo!?
New and Improved Yahoo! Mail - 100MB free storage!
http://promotions.yahoo.com/new_mail 

Re: Merging DRM and fbdev

[Jon Smirl]

On Sun, 3 Oct 2004 11:38:39 -0700 (PDT), Mike Mestnik
<cheako911@yahoo.com> wrote:
> What about moving the DRM and FB specific code into there own per card
> libs?
> 
> radeon - attached to hardware
>    radeon-drm
>       drm - library
>    radeon-fb
>       fb - library
>          fbcon - library

Fell free to convert the merged radeon driver in to a driver plus two
libs if you want. I'll accept the patch back. You'll need to wait
until I get the merged driver working.

What I don't want is two independent implementations of the hardware
initialization code like we currently have. The point of merging is to
make sure that a single logical driver programs the hardware is a
consistent way.

We spend so much time talking about splitting the radeon driver into
pieces. But I don't hear anyone saying I can't ship my product because
the radeon driver is 120K and all I can handle is 60K. I'm not going
to spend a week's work breaking things up and testing them just
because of some theoretical need for a non-existant embedded system.
When this hypothetical embedded system shows up the people making the
money off from the system can do the work.

If an embedded system is really that memory constrained they should
just use the existing fbdev radeon driver. There is no way a system
with that little of memory needs to worry about VT switching to X with
DRM.

-- 
Jon Smirl
jonsmirl@gmail.com

Re: Merging DRM and fbdev

[Bill Davidsen]

Jon Smirl wrote:
> On Sun, 3 Oct 2004 11:38:39 -0700 (PDT), Mike Mestnik
> <cheako911@yahoo.com> wrote:
> 
>>What about moving the DRM and FB specific code into there own per card
>>libs?
>>
>>radeon - attached to hardware
>>   radeon-drm
>>      drm - library
>>   radeon-fb
>>      fb - library
>>         fbcon - library
> 
> 
> Fell free to convert the merged radeon driver in to a driver plus two
> libs if you want. I'll accept the patch back. You'll need to wait
> until I get the merged driver working.
> 
> What I don't want is two independent implementations of the hardware
> initialization code like we currently have. The point of merging is to
> make sure that a single logical driver programs the hardware is a
> consistent way.
> 
> We spend so much time talking about splitting the radeon driver into
> pieces. But I don't hear anyone saying I can't ship my product because
> the radeon driver is 120K and all I can handle is 60K. I'm not going
> to spend a week's work breaking things up and testing them just
> because of some theoretical need for a non-existant embedded system.
> When this hypothetical embedded system shows up the people making the
> money off from the system can do the work.

Perhaps there might be some feedback from the embedded folks and/or 
those who decide if these changes are what they want to go in the 
kernel. If you're going to do something like this, one of the embedded 
vendors might want to contribute to development. Clearly smaller 
software parts have advantages, if resources were available to do it 
split as part of the modification.

That would probably reduce the maintenence effort in the future as well.

-- 
    -bill davidsen (davidsen@tmr.com)
"The secret to procrastination is to put things off until the
  last possible moment - but no longer"  -me

Re: Merging DRM and fbdev

[Jon Smirl]

On Sun, 3 Oct 2004 08:26:54 +0100 (IST), Dave Airlie <airlied@linux.ie> wrote:
> I also want to prepare some patches for the kernel for the previous work
> you've done ...

Did you get around to making ffb compile?
Have all of the drivers been given minimal testing? I've done radeon and r128. 
Is the general consensus that the core model is the way to go for 2.6?

Once drm-core makes it into the kernel I can do another patch to
remove the inter_module_get calls between drm and agp. With those gone
inter_module can be removed from the kernel.

But there does appear to be one other user of inter_module_...
MTD driver for "M-Systems Disk-On-Chip Millennium Plus"
mtd/devices/doc2001plus.c
mtd/chips/cfi_cmdset_0001.c

> 
> Dave.
> 



-- 
Jon Smirl
jonsmirl@gmail.com

Re: Merging DRM and fbdev

[Tonnerre]

[-- Attachment #1: Type: text/plain, Size: 403 bytes --]

Salut,

On Sun, Oct 03, 2004 at 12:46:51PM -0400, Jon Smirl wrote:
> But there does appear to be one other user of inter_module_...
> MTD driver for "M-Systems Disk-On-Chip Millennium Plus"
> mtd/devices/doc2001plus.c
> mtd/chips/cfi_cmdset_0001.c

nvidia and  ati use them  as well, it  seems. Not that I'd  care about
them, though. They can roll their own fixes as they decided to.

			     Tonnerre


[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: Merging DRM and fbdev

[Jon Smirl]

On Mon, 4 Oct 2004 19:47:00 +0200, Tonnerre <tonnerre@thundrix.ch> wrote:
> On Sun, Oct 03, 2004 at 12:46:51PM -0400, Jon Smirl wrote:
> > But there does appear to be one other user of inter_module_...
> > MTD driver for "M-Systems Disk-On-Chip Millennium Plus"
> > mtd/devices/doc2001plus.c
> > mtd/chips/cfi_cmdset_0001.c
> 
> nvidia and  ati use them  as well, it  seems. Not that I'd  care about
> them, though. They can roll their own fixes as they decided to.

Nvidia and ATI probably use it because they are derived from Linux
DRM/AGP code. When I remove it from the Linux drivers it may disappear
from theirs too.

I CC'd a few of the email addresses in the MTD driver's source. 

-- 
Jon Smirl
jonsmirl@gmail.com