The radeon_buffer.c addition that gets pulled into the DRM driver as part of Kernel Mode Setting (even if you disable KMS for the Radeon driver) was assuming that it was safe to use symbols from the AGP code, but that isn't safe on platforms where __OS_HAS_AGP is 0. Such as sparc64. :)
This patch gets the code building again. It probably should go into the actual kms patch, but if you would prefer this go as a separate patch, I can apply it. With this, we can get rawhide building for sparc64, so I'm eager to see it applied in one way or another.
Signed-off-by: Tom "spot" Callaway tcallawa@redhat.com
On Wed, Mar 11, 2009 at 10:27:51AM -0400, Tom spot Callaway wrote:
The radeon_buffer.c addition that gets pulled into the DRM driver as part of Kernel Mode Setting (even if you disable KMS for the Radeon driver) was assuming that it was safe to use symbols from the AGP code, but that isn't safe on platforms where __OS_HAS_AGP is 0. Such as sparc64. :)
This patch gets the code building again. It probably should go into the actual kms patch, but if you would prefer this go as a separate patch, I can apply it. With this, we can get rawhide building for sparc64, so I'm eager to see it applied in one way or another.
Signed-off-by: Tom "spot" Callaway tcallawa@redhat.com
diff -up linux-2.6.28.sparc64/drivers/gpu/drm/radeon/radeon_buffer.c.BAD linux-2.6.28.sparc64/drivers/gpu/drm/radeon/radeon_buffer.c --- linux-2.6.28.sparc64/drivers/gpu/drm/radeon/radeon_buffer.c.BAD 2009-03-11 09:11:01.000000000 -0500 +++ linux-2.6.28.sparc64/drivers/gpu/drm/radeon/radeon_buffer.c 2009-03-11 09:11:27.000000000 -0500 @@ -37,9 +37,11 @@ struct drm_ttm_backend *radeon_create_tt { drm_radeon_private_t *dev_priv = dev->dev_private;
+#if __OS_HAS_AGP
Not that this is your fault, but shouldn't this be something like __ARCH_HAS_AGP?
josh
On Wed, Mar 11, 2009 at 11:33:25AM -0400, Josh Boyer wrote:
+#if __OS_HAS_AGP
Not that this is your fault, but shouldn't this be something like __ARCH_HAS_AGP?
Keep in mind the DRM for better or for worse supposedly supports more OSes than just Linux.
I suspect the 'ideal' fix for upstream is to stub out drm_agp_init_ttm on !CONFIG_AGP arches.
regards, Kyle
On Wed, Mar 11, 2009 at 11:55:53AM -0400, Kyle McMartin wrote:
On Wed, Mar 11, 2009 at 11:33:25AM -0400, Josh Boyer wrote:
+#if __OS_HAS_AGP
Not that this is your fault, but shouldn't this be something like __ARCH_HAS_AGP?
Keep in mind the DRM for better or for worse supposedly supports more OSes than just Linux.
I had blissfully forgotten that.
I suspect the 'ideal' fix for upstream is to stub out drm_agp_init_ttm on !CONFIG_AGP arches.
Yeah, something like that.
josh
On Wed, 2009-03-11 at 11:55 -0400, Kyle McMartin wrote:
On Wed, Mar 11, 2009 at 11:33:25AM -0400, Josh Boyer wrote:
+#if __OS_HAS_AGP
Not that this is your fault, but shouldn't this be something like __ARCH_HAS_AGP?
Keep in mind the DRM for better or for worse supposedly supports more OSes than just Linux.
I suspect the 'ideal' fix for upstream is to stub out drm_agp_init_ttm on !CONFIG_AGP arches.
OS_HAS_AGP is just a wrapper around convoluted CONFIG_AGP, CONFIG_AGP_MODULE.
Its perfectly acceptable to build a kernel with no AGP and DRM enabled on x86.
Dave.
regards, Kyle
On 03/11/2009 11:33 AM, Josh Boyer wrote:
+#if __OS_HAS_AGP
Not that this is your fault, but shouldn't this be something like __ARCH_HAS_AGP?
Maybe, but I'm not about to redefine existing kernel defines for the purposes of logic. ;)
~spot
kernel@lists.fedoraproject.org
-
David Airlie -
Josh Boyer -
Kyle McMartin -
Tom Callaway