Re: radeon-pre-2

Alan Cox
2004-09-11T15:37:34Z

On Sad, 2004-09-11 at 06:19, Dave Airlie wrote:
> 1. It doesn't matter where the code lives, fbdev/DRM need to start talking
> about things

It matters immensely what the divison is because people talking doesn't
scale ..

> I'm interested in seeing what Alan comes up with, even in a non-working
> form .. I much prefer the evolution of these things than complete new
> solutions... but I also think linking the fb and drm code together will
> remove alot of the headaches and result in a more maintainable system
> longterm, even if shortterm there are some ugly hacks..

What I'm trying to end up with is this

drv.type = TYPE_FB0; /* Head 0 */
/* Rest much like PCI */
vga_register_driver(&drv)

drv.type = TYPE_DRI;
vga_register_driver(&drv)

all working like the PCI API, so you get add/remove notifications, you
also don't need to modify the video and DRI drivers much. Unlike the
pci_register it allows multiple claims for each device (one memory
manager, one dri driver, up to four "heads" for now - multihead needs
more pondering perhaps)

Each of these gets notified when the others are added/removed and can
veto such an add or remove. They can also provide whatever methods it
turns out are appropriate to each other for co-ordination.

For example I can see the radeon DRM driver providing

->queue_commands()
->quiesce()

to the 2D driver. And the 2D driver providing

->define_fb_layout() for DRI to provide to X

That way it is only these calls between drivers you and the fb authors
have to argue about the functionality and interfaces between. (eg who
saves registers, which registers)

Alan