Re: radeon-pre-2

[Alan Cox <alan@lxorguk.ukuu.org.uk>]

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