Re: [PATCH] DRM: core mode setting support
On Monday, November 3, 2008 8:26 am Jesse Barnes wrote: > On Friday, October 31, 2008 2:18 pm Dave Airlie wrote: > > On Sat, Nov 1, 2008 at 4:02 AM, Jesse Barnes <[EMAIL PROTECTED]> > > wrote: > > > On Friday, October 31, 2008 4:01 am Thomas Hellström wrote: > > >> Jesse Barnes wrote: > > >> > This commit adds the core mode setting routines for use by DRM > > >> > drivers to manage outputs and displays. Originally based on the > > >> > X.Org Randr 1.2 implementation, the code has since been heavily > > >> > changed by Dave Airlie with contributions by Jesse Barnes, Jakob > > >> > Bornecrantz and others. > > >> > > > >> > This one should probably be split up a bit; I think the TTM stuff in > > >> > particular could be factored out fairly easily. > > >> > > >> Jesse, > > >> We must split out TTM from anything that goes into DRM next for now, > > >> as we're about to re-add it in a device dependant > > >> form with a well defined kernel only API. (This is probably going to > > >> happen within a couple of weeks). > > >> > > >> A minimal user-space API will be added when there are drivers > > >> supporting it. I guess the first one will be a reworked via driver > > >> following up with other work. > > >> > > >> So for now, I guess the best thing is to strip the TTM parts > > >> completely and not consider the drivers that rely on it. > > >> > > >> I have a patch lying around that strips TTM from modesetting-gem and > > >> disables the build of radeon, radeon-ms and nouvea, if that would > > >> help... > > > > > > Yeah that would help a bit. I'm not in a position to push those bits > > > anyway, so it would be good if my next set of patches didn't have any > > > TTM or radeon bits... > > > > My tree in drm-rawhide shouldn't have many TTM + modeset commits. > > > > My plan was to take the core modesetting additions patch > > 75432e26f0a14a30da437018938d4c04a8faa00e > > db392921b6e5d051b6651c1f8d47875da789fb44 > > > > get a tree with just those in it, copy over the latest version of the > > modesetting files from > > the head of the branch and make that the base patch. > > > > Then get the multi-master bits (can go before or after modesetting in > > theory). > > > > Then drop the Intel driver on top. > > Sounds reasonable; I was mainly looking at the radeon stuff to get a feel > for how it impacts the core. So do you have a tree with the changes above? > If so I can get the intel driver working with it and ignore all the > radeon/TTM stuff... Now that I've looked at it a little it seems like the mods are a bit more interrelated than I'd hoped. It might be easier to just drop the TTM bits from the core mode setting patch I posted, though those are pretty tangled up too. Jesse - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ -- ___ Dri-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] DRM: core mode setting support
On Friday, October 31, 2008 2:18 pm Dave Airlie wrote: > On Sat, Nov 1, 2008 at 4:02 AM, Jesse Barnes <[EMAIL PROTECTED]> wrote: > > On Friday, October 31, 2008 4:01 am Thomas Hellström wrote: > >> Jesse Barnes wrote: > >> > This commit adds the core mode setting routines for use by DRM drivers > >> > to manage outputs and displays. Originally based on the X.Org Randr > >> > 1.2 implementation, the code has since been heavily changed by Dave > >> > Airlie with contributions by Jesse Barnes, Jakob Bornecrantz and > >> > others. > >> > > >> > This one should probably be split up a bit; I think the TTM stuff in > >> > particular could be factored out fairly easily. > >> > >> Jesse, > >> We must split out TTM from anything that goes into DRM next for now, as > >> we're about to re-add it in a device dependant > >> form with a well defined kernel only API. (This is probably going to > >> happen within a couple of weeks). > >> > >> A minimal user-space API will be added when there are drivers supporting > >> it. I guess the first one will be a reworked via driver following up > >> with other work. > >> > >> So for now, I guess the best thing is to strip the TTM parts completely > >> and not consider the drivers that rely on it. > >> > >> I have a patch lying around that strips TTM from modesetting-gem and > >> disables the build of radeon, radeon-ms and nouvea, if that would > >> help... > > > > Yeah that would help a bit. I'm not in a position to push those bits > > anyway, so it would be good if my next set of patches didn't have any TTM > > or radeon bits... > > My tree in drm-rawhide shouldn't have many TTM + modeset commits. > > My plan was to take the core modesetting additions patch > 75432e26f0a14a30da437018938d4c04a8faa00e > db392921b6e5d051b6651c1f8d47875da789fb44 > > get a tree with just those in it, copy over the latest version of the > modesetting files from > the head of the branch and make that the base patch. > > Then get the multi-master bits (can go before or after modesetting in > theory). > > Then drop the Intel driver on top. Sounds reasonable; I was mainly looking at the radeon stuff to get a feel for how it impacts the core. So do you have a tree with the changes above? If so I can get the intel driver working with it and ignore all the radeon/TTM stuff... Thanks, Jesse - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ -- ___ Dri-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] DRM: core mode setting support
> We must split out TTM from anything that goes into DRM next for now, as > we're about to re-add it in a device dependant > form with a well defined kernel only API. (This is probably going to > happen within a couple of weeks). > > A minimal user-space API will be added when there are drivers supporting > it. I guess the first one will be a reworked via driver following up > with other work. > > So for now, I guess the best thing is to strip the TTM parts completely > and not consider the drivers that rely on it. > > I have a patch lying around that strips TTM from modesetting-gem and > disables the build of radeon, radeon-ms and nouvea, if that would help... No don't do that, I have a working radeon driver in there and would like to keep working on it. I think we can prepare core/intel patches without touching this stuff. When you can publish the new TTM changes I can look at rebasing radeon on top of them. Dave. > > /Thomas > > > > > > - > This SF.Net email is sponsored by the Moblin Your Move Developer's challenge > Build the coolest Linux based applications with Moblin SDK & win great prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > -- > ___ > Dri-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/dri-devel > > - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ -- ___ Dri-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] DRM: core mode setting support
On Sat, Nov 1, 2008 at 4:02 AM, Jesse Barnes <[EMAIL PROTECTED]> wrote: > On Friday, October 31, 2008 4:01 am Thomas Hellström wrote: >> Jesse Barnes wrote: >> > This commit adds the core mode setting routines for use by DRM drivers to >> > manage outputs and displays. Originally based on the X.Org Randr 1.2 >> > implementation, the code has since been heavily changed by Dave Airlie >> > with contributions by Jesse Barnes, Jakob Bornecrantz and others. >> > >> > This one should probably be split up a bit; I think the TTM stuff in >> > particular could be factored out fairly easily. >> >> Jesse, >> We must split out TTM from anything that goes into DRM next for now, as >> we're about to re-add it in a device dependant >> form with a well defined kernel only API. (This is probably going to >> happen within a couple of weeks). >> >> A minimal user-space API will be added when there are drivers supporting >> it. I guess the first one will be a reworked via driver following up >> with other work. >> >> So for now, I guess the best thing is to strip the TTM parts completely >> and not consider the drivers that rely on it. >> >> I have a patch lying around that strips TTM from modesetting-gem and >> disables the build of radeon, radeon-ms and nouvea, if that would help... > > Yeah that would help a bit. I'm not in a position to push those bits anyway, > so it would be good if my next set of patches didn't have any TTM or radeon > bits... > My tree in drm-rawhide shouldn't have many TTM + modeset commits. My plan was to take the core modesetting additions patch 75432e26f0a14a30da437018938d4c04a8faa00e db392921b6e5d051b6651c1f8d47875da789fb44 get a tree with just those in it, copy over the latest version of the modesetting files from the head of the branch and make that the base patch. Then get the multi-master bits (can go before or after modesetting in theory). Then drop the Intel driver on top. Nearly all the work on drm-rawhide has been on radeon mm and kms so the core kms code hasn't see major amount of changes. We should ignore radeon from an upstream perspective for the moment as the TTM interfacing needs to happen first. Dave. - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ -- ___ Dri-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] DRM: core mode setting support
On Friday, October 31, 2008 4:01 am Thomas Hellström wrote: > Jesse Barnes wrote: > > This commit adds the core mode setting routines for use by DRM drivers to > > manage outputs and displays. Originally based on the X.Org Randr 1.2 > > implementation, the code has since been heavily changed by Dave Airlie > > with contributions by Jesse Barnes, Jakob Bornecrantz and others. > > > > This one should probably be split up a bit; I think the TTM stuff in > > particular could be factored out fairly easily. > > Jesse, > We must split out TTM from anything that goes into DRM next for now, as > we're about to re-add it in a device dependant > form with a well defined kernel only API. (This is probably going to > happen within a couple of weeks). > > A minimal user-space API will be added when there are drivers supporting > it. I guess the first one will be a reworked via driver following up > with other work. > > So for now, I guess the best thing is to strip the TTM parts completely > and not consider the drivers that rely on it. > > I have a patch lying around that strips TTM from modesetting-gem and > disables the build of radeon, radeon-ms and nouvea, if that would help... Yeah that would help a bit. I'm not in a position to push those bits anyway, so it would be good if my next set of patches didn't have any TTM or radeon bits... Thanks, Jesse - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ -- ___ Dri-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] DRM: core mode setting support
Jesse Barnes wrote: > This commit adds the core mode setting routines for use by DRM drivers to > manage outputs and displays. Originally based on the X.Org Randr 1.2 > implementation, the code has since been heavily changed by Dave Airlie > with contributions by Jesse Barnes, Jakob Bornecrantz and others. > > This one should probably be split up a bit; I think the TTM stuff in > particular could be factored out fairly easily. > > Jesse, We must split out TTM from anything that goes into DRM next for now, as we're about to re-add it in a device dependant form with a well defined kernel only API. (This is probably going to happen within a couple of weeks). A minimal user-space API will be added when there are drivers supporting it. I guess the first one will be a reworked via driver following up with other work. So for now, I guess the best thing is to strip the TTM parts completely and not consider the drivers that rely on it. I have a patch lying around that strips TTM from modesetting-gem and disables the build of radeon, radeon-ms and nouvea, if that would help... /Thomas - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ -- ___ Dri-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/dri-devel
