Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1426556 > unrolled thread

[RFC PATCH] drm/nouveau/fb/nv50: set DMA mask before mapping scratch page

Back to article view | Back to linux.kernel

Contents

  [RFC PATCH] drm/nouveau/fb/nv50: set DMA mask before mapping scratch page Ard Biesheuvel <ard.biesheuvel@linaro.org> - 2016-06-20 14:40 +0200
    Re: [RFC PATCH] drm/nouveau/fb/nv50: set DMA mask before mapping scratch page Punit Agrawal <punit.agrawal@arm.com> - 2016-06-23 12:00 +0200
      Re: [RFC PATCH] drm/nouveau/fb/nv50: set DMA mask before mapping  scratch page Ard Biesheuvel <ard.biesheuvel@linaro.org> - 2016-06-23 12:10 +0200
        Re: [RFC PATCH] drm/nouveau/fb/nv50: set DMA mask before mapping scratch page Punit Agrawal <punit.agrawal@arm.com> - 2016-06-23 15:00 +0200

#1426556 — [RFC PATCH] drm/nouveau/fb/nv50: set DMA mask before mapping scratch page

The 100c08 scratch page is mapped using dma_map_page() before the TTM
layer has had a chance to set the DMA mask. This means we are still
running with the default of 32 when this code executes, and this causes
problems for platforms with no memory below 4 GB (such as AMD Seattle)

So move the dma_map_page() to the .init hook, and set the streaming DMA
mask based on the MMU subdev parameters before performing the call.

Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
---

I am sure there is a much better way to address this, but this fixes the
problem I get on AMD Seattle with a GeForce 210 PCIe card:

   nouveau 0000:02:00.0: enabling device (0000 -> 0003)
   nouveau 0000:02:00.0: NVIDIA GT218 (0a8280b1)
   nouveau 0000:02:00.0: bios: version 70.18.a6.00.00
   nouveau 0000:02:00.0: fb ctor failed, -14
   nouveau: probe of 0000:02:00.0 failed with error -14

 drivers/gpu/drm/nouveau/nvkm/subdev/fb/nv50.c | 37 ++++++++++++++------
 1 file changed, 26 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/fb/nv50.c b/drivers/gpu/drm/nouveau/nvkm/subdev/fb/nv50.c
index 1b5fb02eab2a..b2f05f733a53 100644
--- a/drivers/gpu/drm/nouveau/nvkm/subdev/fb/nv50.c
+++ b/drivers/gpu/drm/nouveau/nvkm/subdev/fb/nv50.c
@@ -216,11 +216,30 @@ nv50_fb_init(struct nvkm_fb *base)
 	struct nv50_fb *fb = nv50_fb(base);
 	struct nvkm_device *device = fb->base.subdev.device;
 
+	if (!fb->r100c08) {
+		/*
+		 * We are calling the DMA api way before the TTM layer sets the
+		 * DMA mask based on the MMU subdev parameters. This means we
+		 * are using the default DMA mask of 32, which may cause
+		 * problems on systems with no RAM below the 4 GB mark. So set
+		 * the streaming DMA mask here as well.
+		 */
+		dma_set_mask(device->dev, DMA_BIT_MASK(device->mmu->dma_bits));
+
+		fb->r100c08 = dma_map_page(device->dev, fb->r100c08_page, 0,
+					   PAGE_SIZE, DMA_BIDIRECTIONAL);
+		if (dma_mapping_error(device->dev, fb->r100c08)) {
+			nvkm_warn(&fb->base.subdev,
+				  "dma_map_page() failed on 100c08 page\n");
+		}
+	}
+
 	/* Not a clue what this is exactly.  Without pointing it at a
 	 * scratch page, VRAM->GART blits with M2MF (as in DDX DFS)
 	 * cause IOMMU "read from address 0" errors (rh#561267)
 	 */
-	nvkm_wr32(device, 0x100c08, fb->r100c08 >> 8);
+	if (fb->r100c08 != DMA_ERROR_CODE)
+		nvkm_wr32(device, 0x100c08, fb->r100c08 >> 8);
 
 	/* This is needed to get meaningful information from 100c90
 	 * on traps. No idea what these values mean exactly. */
@@ -233,11 +252,11 @@ nv50_fb_dtor(struct nvkm_fb *base)
 	struct nv50_fb *fb = nv50_fb(base);
 	struct nvkm_device *device = fb->base.subdev.device;
 
-	if (fb->r100c08_page) {
+	if (fb->r100c08 != NULL && fb->r100c08 != DMA_ERROR_CODE)
 		dma_unmap_page(device->dev, fb->r100c08, PAGE_SIZE,
 			       DMA_BIDIRECTIONAL);
-		__free_page(fb->r100c08_page);
-	}
+
+	__free_page(fb->r100c08_page);
 
 	return fb;
 }
@@ -264,13 +283,9 @@ nv50_fb_new_(const struct nv50_fb_func *func, struct nvkm_device *device,
 	*pfb = &fb->base;
 
 	fb->r100c08_page = alloc_page(GFP_KERNEL | __GFP_ZERO);
-	if (fb->r100c08_page) {
-		fb->r100c08 = dma_map_page(device->dev, fb->r100c08_page, 0,
-					   PAGE_SIZE, DMA_BIDIRECTIONAL);
-		if (dma_mapping_error(device->dev, fb->r100c08))
-			return -EFAULT;
-	} else {
-		nvkm_warn(&fb->base.subdev, "failed 100c08 page alloc\n");
+	if (!fb->r100c08_page) {
+		nvkm_error(&fb->base.subdev, "failed 100c08 page alloc\n");
+		return -ENOMEM;
 	}
 
 	return 0;
-- 
2.7.4

[toc] | [next] | [standalone]

#1429641

Ard Biesheuvel <ard.biesheuvel@linaro.org> writes:

> The 100c08 scratch page is mapped using dma_map_page() before the TTM
> layer has had a chance to set the DMA mask. This means we are still
> running with the default of 32 when this code executes, and this causes
> problems for platforms with no memory below 4 GB (such as AMD Seattle)
>
> So move the dma_map_page() to the .init hook, and set the streaming DMA
> mask based on the MMU subdev parameters before performing the call.
>
> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>

Hi Ard,

Thanks for posting this patch.

With the patch, I am able to see console output on a screen attached to
the NVS 300 PCIe card in an AMD Seattle system. It was failing with
a message similar to what you've posted below.

For some reason, X refuses to start up but that, I think, is a problem
with my userspace setup.

Cheers,
Punit


[...]

[toc] | [prev] | [next] | [standalone]

#1429650 — Re: [RFC PATCH] drm/nouveau/fb/nv50: set DMA mask before mapping scratch page

On 23 June 2016 at 11:55, Punit Agrawal <punit.agrawal@arm.com> wrote:
> Ard Biesheuvel <ard.biesheuvel@linaro.org> writes:
>
>> The 100c08 scratch page is mapped using dma_map_page() before the TTM
>> layer has had a chance to set the DMA mask. This means we are still
>> running with the default of 32 when this code executes, and this causes
>> problems for platforms with no memory below 4 GB (such as AMD Seattle)
>>
>> So move the dma_map_page() to the .init hook, and set the streaming DMA
>> mask based on the MMU subdev parameters before performing the call.
>>
>> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
>
> Hi Ard,
>
> Thanks for posting this patch.
>
> With the patch, I am able to see console output on a screen attached to
> the NVS 300 PCIe card in an AMD Seattle system. It was failing with
> a message similar to what you've posted below.
>

Thanks for the report. May I take it as a tested-by?

> For some reason, X refuses to start up but that, I think, is a problem
> with my userspace setup.
>

Good to know that you are attempting the same thing. We should take
this offline, but I'd like to compare notes regarding the Xorg
problems that you are experiencing.

Regards,
Ard.

[toc] | [prev] | [next] | [standalone]

#1429792

Ard Biesheuvel <ard.biesheuvel@linaro.org> writes:

> On 23 June 2016 at 11:55, Punit Agrawal <punit.agrawal@arm.com> wrote:
>> Ard Biesheuvel <ard.biesheuvel@linaro.org> writes:
>>
>>> The 100c08 scratch page is mapped using dma_map_page() before the TTM
>>> layer has had a chance to set the DMA mask. This means we are still
>>> running with the default of 32 when this code executes, and this causes
>>> problems for platforms with no memory below 4 GB (such as AMD Seattle)
>>>
>>> So move the dma_map_page() to the .init hook, and set the streaming DMA
>>> mask based on the MMU subdev parameters before performing the call.
>>>
>>> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
>>
>> Hi Ard,
>>
>> Thanks for posting this patch.
>>
>> With the patch, I am able to see console output on a screen attached to
>> the NVS 300 PCIe card in an AMD Seattle system. It was failing with
>> a message similar to what you've posted below.
>>
>
> Thanks for the report. May I take it as a tested-by?

Sure.

Punit


[...]

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web