Skip to contentSkip to conversation

FAILED: patch "[PATCH] drm/radeon: insist on 32-bit DMA for Cedar on PPC64/PPC64LE" failed to apply to 4.16-stable tree

PATCH [email protected] 3 participants 4 messages Apr 22, 2018 – Apr 25, 2018

Subsystems (3)
lore
Share & tools
lore

[email protected]

author maintainer
#0 lore raw

The patch below does not apply to the 4.16-stable tree.
If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <[email protected]>.

thanks,

greg k-h

------------------ original commit in Linus's tree ------------------

Quoted 1 line

From bcb0b981c5571744ac446a6c906aa05a28d21446 Mon Sep 17 00:00:00 2001

From: Ben Crocker <[email protected]>
Date: Thu, 22 Feb 2018 17:52:19 -0500
Subject: [PATCH] drm/radeon: insist on 32-bit DMA for Cedar on PPC64/PPC64LE

In radeon_device_init, set the need_dma32 flag for Cedar chips (e.g. FirePro 2270). This fixes, or at least works around, a bug on PowerPC exposed by last year's commits

8e3f1b1d8255105f31556aacf8aeb6071b00d469 (Russell Currey)

and

253fd51e2f533552ae35a0c661705da6c4842c1b (Alistair Popple)

which enabled the 64-bit DMA iommu bypass.

This caused the device to freeze, in some cases unrecoverably, and is the subject of several bug reports internal to Red Hat.

drivers/gpu/drm/radeon/radeon_device.c +4 -0
index 7f40c6f7c4dd..e415d2c097a7 100644
@@ -1366,6 +1366,10 @@ int radeon_device_init(struct radeon_device *rdev,
 	if ((rdev->flags & RADEON_IS_PCI) &&
 	    (rdev->family <= CHIP_RS740))
 		rdev->need_dma32 = true;
+#ifdef CONFIG_PPC64
+	if (rdev->family == CHIP_CEDAR)
+		rdev->need_dma32 = true;
+#endif
 
 	dma_bits = rdev->need_dma32 ? 32 : 40;
 	r = pci_set_dma_mask(rdev->pdev, DMA_BIT_MASK(dma_bits));
#1 lore raw

(Third try, after turning on Plain Text mode in Gmail; apologies if you got this more than once)

Hi Greg,

Thanks for the note. I think this is a case of the same change having been checked in on different branches. I downloaded the linux-4.16.3 tarball, unpacked it, and examined radeon_device.c; the correct change is there in radeon_device_init (the four lines beginning "#ifdef CONFIG_PPC64").

Looking at the whole git log, I see two instances of exactly the same patch:

commit bcb0b981c5571744ac446a6c906aa05a28d21446

Author: Ben Crocker <[email protected]>
Date:   Thu Feb 22 17:52:19 2018 -0500

drm/radeon: insist on 32-bit DMA for Cedar on PPC64/PPC64LE

and

commit 2c83029cda55a5e7665c7c6326909427d6a01350

Author: Ben Crocker <[email protected]>
Date:   Thu Feb 22 17:52:19 2018 -0500

drm/radeon: insist on 32-bit DMA for Cedar on PPC64/PPC64LE

A colleague of mine here at Red Hat thinks that no further action is necessary; please let me know what you think.

Thanks,
Ben

Quoted 52 lines · On Sun, Apr 22, 2018 at 4:19 AM, <[email protected]> wrote:

The patch below does not apply to the 4.16-stable tree.
If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <[email protected]>.

thanks,

greg k-h

------------------ original commit in Linus's tree ------------------

From bcb0b981c5571744ac446a6c906aa05a28d21446 Mon Sep 17 00:00:00 2001
From: Ben Crocker <[email protected]>
Date: Thu, 22 Feb 2018 17:52:19 -0500
Subject: [PATCH] drm/radeon: insist on 32-bit DMA for Cedar on PPC64/PPC64LE

In radeon_device_init, set the need_dma32 flag for Cedar chips (e.g. FirePro 2270). This fixes, or at least works around, a bug on PowerPC exposed by last year's commits

8e3f1b1d8255105f31556aacf8aeb6071b00d469 (Russell Currey)

and

253fd51e2f533552ae35a0c661705da6c4842c1b (Alistair Popple)

which enabled the 64-bit DMA iommu bypass.

This caused the device to freeze, in some cases unrecoverably, and is the subject of several bug reports internal to Red Hat.

drivers/gpu/drm/radeon/radeon_device.c +4 -0
index 7f40c6f7c4dd..e415d2c097a7 100644
@@ -1366,6 +1366,10 @@ int radeon_device_init(struct radeon_device *rdev,
        if ((rdev->flags & RADEON_IS_PCI) &&
            (rdev->family <= CHIP_RS740))
                rdev->need_dma32 = true;
+#ifdef CONFIG_PPC64
+       if (rdev->family == CHIP_CEDAR)
+               rdev->need_dma32 = true;
+#endif
 
        dma_bits = rdev->need_dma32 ? 32 : 40;
        r = pci_set_dma_mask(rdev->pdev, DMA_BIT_MASK(dma_bits));
#2 lore raw
Quoted 30 lines

-----Original Message-----
From: Ben Crocker [mailto:[email protected]]
Sent: Tuesday, April 24, 2018 3:30 PM
To: [email protected]
Cc: Deucher, Alexander <[email protected]>; [email protected]
Subject: Re: FAILED: patch "[PATCH] drm/radeon: insist on 32-bit DMA for Cedar on PPC64/PPC64LE" failed to apply to 4.16-stable tree

(Third try, after turning on Plain Text mode in Gmail; apologies if you got this more than once)

Hi Greg,

Thanks for the note. I think this is a case of the same change having been checked in on different branches. I downloaded the linux-4.16.3 tarball, unpacked it, and examined radeon_device.c; the correct change is there in radeon_device_init (the four lines beginning "#ifdef CONFIG_PPC64").

Looking at the whole git log, I see two instances of exactly the same patch:

commit bcb0b981c5571744ac446a6c906aa05a28d21446

Author: Ben Crocker <[email protected]>
Date:   Thu Feb 22 17:52:19 2018 -0500

drm/radeon: insist on 32-bit DMA for Cedar on PPC64/PPC64LE

and

Quoted 8 lines

commit 2c83029cda55a5e7665c7c6326909427d6a01350

Author: Ben Crocker <[email protected]>
Date:   Thu Feb 22 17:52:19 2018 -0500

drm/radeon: insist on 32-bit DMA for Cedar on PPC64/PPC64LE

A colleague of mine here at Red Hat thinks that no further action is necessary; please let me know what you think.

No further action is required. The patch was committed to drm-next for the next kernel and also ended up in drm-fixes for the current one at the time.

Alex

Quoted 61 lines

Thanks,
Ben

Quoted 6 lines · On Sun, Apr 22, 2018 at 4:19 AM, <[email protected]> wrote:

The patch below does not apply to the 4.16-stable tree.
If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <[email protected]>.

Quoted 7 lines

thanks,

greg k-h

------------------ original commit in Linus's tree ------------------

From bcb0b981c5571744ac446a6c906aa05a28d21446 Mon Sep 17 00:00:00

2001

drivers/gpu/drm/radeon/radeon_device.c int radeon_device_init(struct radeon_device

Quoted 30 lines

From: Ben Crocker <[email protected]>
Date: Thu, 22 Feb 2018 17:52:19 -0500
Subject: [PATCH] drm/radeon: insist on 32-bit DMA for Cedar on PPC64/PPC64LE

In radeon_device_init, set the need_dma32 flag for Cedar chips (e.g. FirePro 2270). This fixes, or at least works around, a bug on PowerPC exposed by last year's commits

8e3f1b1d8255105f31556aacf8aeb6071b00d469 (Russell Currey)

and

253fd51e2f533552ae35a0c661705da6c4842c1b (Alistair Popple)

which enabled the 64-bit DMA iommu bypass.

This caused the device to freeze, in some cases unrecoverably, and is the subject of several bug reports internal to Red Hat.

drivers/gpu/drm/radeon/radeon_device.c +0 -0
index 7f40c6f7c4dd..e415d2c097a7 100644
@@ -1366,6 +1366,10 @@ int radeon_device_init(struct radeon_device

*rdev,

Quoted 10 lines
drivers/gpu/drm/radeon/radeon_device.c +3 -0
        if ((rdev->flags & RADEON_IS_PCI) &&
            (rdev->family <= CHIP_RS740))
                rdev->need_dma32 = true;
+#ifdef CONFIG_PPC64
+       if (rdev->family == CHIP_CEDAR)
+               rdev->need_dma32 = true; #endif
 
        dma_bits = rdev->need_dma32 ? 32 : 40;
        r = pci_set_dma_mask(rdev->pdev, DMA_BIT_MASK(dma_bits));
author maintainer
#3 lore raw
Quoted 34 lines · Alexander
Quoted 34 lines

-----Original Message-----
From: Ben Crocker [mailto:[email protected]]
Sent: Tuesday, April 24, 2018 3:30 PM
To: [email protected]
Cc: Deucher, Alexander <[email protected]>; [email protected]
Subject: Re: FAILED: patch "[PATCH] drm/radeon: insist on 32-bit DMA for Cedar on PPC64/PPC64LE" failed to apply to 4.16-stable tree

(Third try, after turning on Plain Text mode in Gmail; apologies if you got this more than once)

Hi Greg,

Thanks for the note. I think this is a case of the same change having been checked in on different branches. I downloaded the linux-4.16.3 tarball, unpacked it, and examined radeon_device.c; the correct change is there in radeon_device_init (the four lines beginning "#ifdef CONFIG_PPC64").

Looking at the whole git log, I see two instances of exactly the same patch:

commit bcb0b981c5571744ac446a6c906aa05a28d21446

Author: Ben Crocker <[email protected]>
Date:   Thu Feb 22 17:52:19 2018 -0500

drm/radeon: insist on 32-bit DMA for Cedar on PPC64/PPC64LE

and

commit 2c83029cda55a5e7665c7c6326909427d6a01350

Author: Ben Crocker <[email protected]>
Date:   Thu Feb 22 17:52:19 2018 -0500
Quoted 8 lines
Quoted 4 lines

drm/radeon: insist on 32-bit DMA for Cedar on PPC64/PPC64LE

A colleague of mine here at Red Hat thinks that no further action is necessary; please let me know what you think.

No further action is required. The patch was committed to drm-next for the next kernel and also ended up in drm-fixes for the current one at the time.

And it's annoying as hell.

I already argued a lot with the i915 maintainers about this in the past, but for them, at least they have the crazy "cherry-picked from..." tag in there showing how they are cherry picking from a _FUTURE_ commit, which gives me a hint as to the lunacy that is happening so I can properly detect it when it hits the tree for the second time.

But for these patches I have no clue.

Which is why all stable DRM driver patches are at the absolute bottom of my priority queue and I dread seeing them ever show up as I don't know what mess is going to happen whenever I try to apply them.

If you are going to do this more often in the future, at least give me a fighting chance to detect it is happening. Otherwise you will get a lot of these "FAILED" emails happening, along with me just starting to ignore radeon stable patches, like I do for i915, until they pile up and I have nothing else better to do that day.

What a mess...

greg k-h