Process to merge Openchrome work

Process to merge Openchrome work

[James Simmons]

Hello!!

	This last year the Openchrome support for the VIA chipsets has 
come along way from being in a state of decay. The plan is to release
a Xorg driver June 1 that will have support for the KMS as well as UMS.
The goal is to have this xorg driver out in the wild before the kernel
side is ready so that the migration to the new kernel drivers will be
as painless as possible. My hope is to merge the kernel tree for public 
use for Christmas.
	This brings up the question I had with the other project leader.
How does one go about merging the tree? What makes this more complex is
that a old via drm kernel driver already exist. Do we just drop in the 
code into the staging area? Does it have to be piece meal? Does a rename 
of the driver need to happen? What would you recommend ?

Re: Process to merge Openchrome work

[Dave Airlie]

>
>        This last year the Openchrome support for the VIA chipsets has
> come along way from being in a state of decay. The plan is to release
> a Xorg driver June 1 that will have support for the KMS as well as UMS.
> The goal is to have this xorg driver out in the wild before the kernel
> side is ready so that the migration to the new kernel drivers will be
> as painless as possible. My hope is to merge the kernel tree for public
> use for Christmas.
>        This brings up the question I had with the other project leader.
> How does one go about merging the tree? What makes this more complex is
> that a old via drm kernel driver already exist. Do we just drop in the
> code into the staging area? Does it have to be piece meal? Does a rename
> of the driver need to happen? What would you recommend ?

So what we've done before to avoid regression is

a) add a new CONFIG_ option that is default n, so users don't get a regression,

b) enable the KMS bits and PCI binding depending on the new option.

Now the easiest way may be to make a new driver with a new name, make
it bind to PCI devices etc,
and just have CONFIG to turn it on/off. It depends on how much code
the new driver shares with the old etc.
So older distros can share the older code.

Then you'd have to generate decent reviewable patches of the codebase
and send them to dri-devel,
where others could review them. The main thing review looks out for is
that the userspace interfaces are
sane and secure.

I don't generally take git merges until people have built up a bit of
trust sending decent patches, and making sure reviews are done.

The other question is what to people lose if they switch to VIA KMS in
terms of acceleration, is the 2D/3D Xorg/Mesa driver work
at the same level as the old driver? does anyone care?

Dave.

Re: Process to merge Openchrome work

[Daniel Vetter]

On Mon, Apr 02, 2012 at 04:23:57PM +0100, James Simmons wrote:
> 
> Hello!!
> 
> 	This last year the Openchrome support for the VIA chipsets has 
> come along way from being in a state of decay. The plan is to release
> a Xorg driver June 1 that will have support for the KMS as well as UMS.
> The goal is to have this xorg driver out in the wild before the kernel
> side is ready so that the migration to the new kernel drivers will be
> as painless as possible. My hope is to merge the kernel tree for public 
> use for Christmas.
> 	This brings up the question I had with the other project leader.
> How does one go about merging the tree? What makes this more complex is
> that a old via drm kernel driver already exist. Do we just drop in the 
> code into the staging area? Does it have to be piece meal? Does a rename 
> of the driver need to happen? What would you recommend ?

Suggestion from a drm/i915 hacker: Make a clean split between the old ums
driver and the new kms/gem/ttm thing. Not being able to quickly switch
between the 2 drivers makes debugging a bit more involved until the kms
stuff all works well, but with a everything-smashed-into-one driver you'll
sign up for a decent long-term burden. After all, you're never allowed to
ditch the old ums/dri1 stuff.

For merging I suggest to go through staging - practically no work required
for that than to send a big patch to greg kh.

Yours, Daniel
-- 
Daniel Vetter
Mail: daniel@ffwll.ch
Mobile: +41 (0)79 365 57 48