On 20/01/17 04:44 PM, Nils Holland wrote: > On Fri, Jan 20, 2017 at 11:47:53AM +0900, Michel Dänzer wrote: >> On 20/01/17 04:35 AM, Nils Holland wrote: >>> >>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c 2016-12-11 20:17:54.000000000 +0100 >>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c 2017-01-19 15:38:56.972034489 +0100 >>> @@ -372,6 +372,10 @@ >>> if (!drm_arch_can_wc_memory()) >>> bo->flags &= ~AMDGPU_GEM_CREATE_CPU_GTT_USWC; >>> >>> + #ifdef CONFIG_X86_32 >>> + bo->flags &= ~AMDGPU_GEM_CREATE_CPU_GTT_USWC; >>> + #endif >>> + >>> amdgpu_fill_placement_to_bo(bo, placement); >>> /* Kernel allocation are uninterruptible */ >>> r = ttm_bo_init(&adev->mman.bdev, &bo->tbo, size, type, >> >> The corresponding code in the radeon driver has changed quite a bit >> since this original fix. It would be better to bring the amdgpu code in >> line with the current radeon code. >> >> >>> With this patch, the amdgpu driver works fine for me on my 32 bit >>> kernel: All graphics output looks the way it's supposed to, even with >>> full acceleration enabled - great! >>> >>> I'd suggest that it might be a good idea to put to apply the above >>> patch or something similar to the official sources. >> >> Indeed. Do you want to create a proper patch and submit it to the >> amd-gfx mailing list for review? See Documentation/SubmittingPatches for >> more information. > > Sounds like a good idea! I was a bit heasitant because, to be honest, > I'm not at all an expert about the code in question and basically only > saw how you fixed the issue in radeon and thought: "Well, let's see if > I can do the same thing in amdgpu and if so, if it helps there, too". > ;-) > > However, since you've said that a 32 bit fix in amdgpu generally seems > like a good idea, Actually, unless your CPU can't run 64-bit code, I'd say running a 64-bit kernel would be an overall even better idea for you, even with 32-bit userspace. :) Anyway, this problem clearly needs to be fixed. > I would indeed use a little time on the weekend to get a proper patch > ready and submit it for review. Even if the "no wc for x86_32" part is > probably the only thing it'll contain I wouldn't bother with that. There is no real reason against bringing it all over in one go. > - more of "bringing the amdgpu code in line with the current radeon > code" might, for the time being, be beyond my capabilities, at least > if we assume that the code should stay in a sane and working > condition. ;-) Don't worry, it's mostly a matter of copy'n'paste, testing on your end, review and more testing by others. :) -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Mesa and X developer
