Re: radeon-pre-2

[Alan Cox]

On Sad, 2004-09-11 at 01:50, Dave Airlie wrote:
> So the IDE-CD driver and IDE-disk drivers both program registers on the
> IDE controller directly.. oh no the ide driver seems to do that.. this is
> FUD,

Its a shame the DRI people having nothing better to do than tell folks
to shut up or mutter FUD about things they don't grasp. You've almost
got the point by now at least.

The IDE CD and IDE disk drivers do both write to registers on the IDE
controller directly - often the same registers. The reason it doesn't
end up in a nasty heap is because the core IDE code does co-ordination. 
Two drivers, independant drivers, an access protocol an the ability for
some entity to co-ordinate them and lo - it all works.

>  a graphics card is a device, singular one device, it requires one
> device driver,

That appears to be the pet religion but repeating bullshit doesn't make
it true.

> I can't write a user space IDE driver and still expect the kernel one to
> be happy, I can't write a second IDE driver for a chipset for formatting
> disks and expect the normal kernel driver to stay working with it, why do
> people think graphics driver are meant to be different..

Because they are not different, and you can write such a formatting
driver providing it follows the IDE access protocols in the core code.
You won't have to modify existing IDE drivers either. It works because
the co-ordination layer is there.

> Alan, I agree with how you want to proceed with this, and keep things
> stable, but anything short of a single card-specific driver looking after
> the registers and DMA queueing and locking is going to have deficiencies
> and the DRM has a better basis than the fb drivers,

"I want to own it, mine mine". Pathetic really isn't it. The FB writers
I've no doubt think they should own it and their code is better too.
They also support a lot more hardware than you do of course, and on
platforms that DRI doesn't support.

What is actually so hard about driver code that instead looks like


my_fb_attach_notify(struct vga_dev *dev, int type)
{
	if(type == TYPE_DRI)
	{
		me->fb_ops = &dri_ops;
		my_fb_dri_init(dev);
		return 0;
	}
	if(type == TYPE_OVERLAY && dev->rev < 0xC4) /* Errata */
		return -EINVAL; /* Refuse overlays in fb mode */
}

or

	down(&dev->lock);
	vga_quiesce_all_drivers(dev);
	do nasty non parallel stuff
	up(&dev->lock);

This is essentially what the IDE layer does, although its closer to

	queue_this_function_and_args_to_list(dev, callback, args);
	if(!doing_stuff);
		begin_queue_run(dev);

Either model works

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