Message ID | 20230414125913.851920-1-broonie@kernel.org |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:b0ea:0:b0:3b6:4342:cba0 with SMTP id b10csp360291vqo; Fri, 14 Apr 2023 06:00:47 -0700 (PDT) X-Google-Smtp-Source: AKy350ZKeSdWyHsIIgIHKADwkERpv0paSC1/o6GbboEMID7WSKl0x7NGhdM7q+hJsVQ/kQ1+gDRh X-Received: by 2002:a17:90a:290d:b0:247:2152:6391 with SMTP id g13-20020a17090a290d00b0024721526391mr4636997pjd.17.1681477246624; Fri, 14 Apr 2023 06:00:46 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1681477246; cv=none; d=google.com; s=arc-20160816; b=CjSrU+xf+kgof5HqDlbQrtixh00bp+4BfIugOHP1/pJaIaGIWoladvwSv0g2r00X1s sZPoyKlde94qJ3DLguvxkC2mKpRd3tV4Ii/F/GKEfmB3YI88lYV0mpDzPSZfNRZHXwod s3EvvNetG/zBvNTRm3bPPd7uFHz9EdGlgzRZ/WsBEUEnQp5oPFimzvXpZwPbJ5ga2O5b 1XiSJ6PZKkhiPoKtEm/HYmtzSXO0OP0F7JOIPW9EonxVlNxBkjnwz3RCXFH/kxScE/nz u+c8tX/49PE7u+w2daA+qJ3RURFp4Sy3/bQ6IlGr20Deb7r9W8m6e42cCz+tqAZH0Fum FDbw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from:dkim-signature; bh=XzqkzZC23E5goZMJDCFCBngD4R2he5f0WAr0QLxWdfI=; b=PHNdZw288IQKQDs9shrzBUPXvf7+RRUrqkxX/RumWq79i/JNme8y0fLghYv3xDkxBs odT3WzQZRcUGHX3ns1A2mD+goGfq2QMfTE184apOlPMYjavQBn4wIQa/73hni/rryvD2 XkLy7PThje0/qyklWcuT5sp+apMl04VvSa2wbLfAmnPbjCKwuPO8kP7EzT8QH7VxeZfb 6Ws+ppBElasm7Arkfau7gaLF7Mlkw07qfjxOGZESgkPWwn2lJ6W6kwSzu3OPPwZbCWVA HLEq+E3x5laV6qEE50iCpxLDA9hq3R8VVxPQx6mZgBfiMuXUCNWe1GNIFqVHQAAXpH2c +MlQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b="Eq/W4LJP"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id mp10-20020a17090b190a00b002372f2c4d9dsi6980065pjb.44.2023.04.14.06.00.26; Fri, 14 Apr 2023 06:00:46 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b="Eq/W4LJP"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230061AbjDNM76 (ORCPT <rfc822;leviz.kernel.dev@gmail.com> + 99 others); Fri, 14 Apr 2023 08:59:58 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:44512 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229752AbjDNM7y (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Fri, 14 Apr 2023 08:59:54 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 87C97B470; Fri, 14 Apr 2023 05:59:21 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 9C36E637DB; Fri, 14 Apr 2023 12:59:19 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 3FCE8C433D2; Fri, 14 Apr 2023 12:59:17 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1681477159; bh=BaN8i5TpFQuSHnQB44TUL3cxmY9lLmJo2EoDj/fQwSE=; h=From:To:Cc:Subject:Date:From; b=Eq/W4LJPPzfaEzWEHTg4TSccaMQdALsmfcK1HXCq/iuCFTsaOVxUFZMMlBB1fGxNT J5HyWmj1v+169ian2toHXF5acIcX/fa9FLOjUuI5Kw++vHqXe4JGabJeOi+WzHWeFW V7IQWentx/iEPehmjiJljw+UwVPexVHuYMhfePz8VlrZ7ePJT/+lzx+3cOYN63vw2Y PyMh2V5j0a3kHh3j5QHN+R91kEdnAPhe7mxQC5HVqLImWxkHk/Ixl+W2DEV12U+lXg oTY0rWCap2wi2DKCsdSF4IrbsgMifBTi7TOOmNJNCVbUhz/rcmDF68kL7P3+4Kpdkl LiJYE4GP7x10w== From: broonie@kernel.org To: Daniel Vetter <daniel.vetter@ffwll.ch>, Intel Graphics <intel-gfx@lists.freedesktop.org>, DRI <dri-devel@lists.freedesktop.org> Cc: Andrew Morton <akpm@linux-foundation.org>, =?utf-8?q?Christian_K=C3=B6ni?= =?utf-8?q?g?= <christian.koenig@amd.com>, "Kirill A . Shutemov" <kirill.shutemov@linux.intel.com>, Linux Kernel Mailing List <linux-kernel@vger.kernel.org>, Linux Next Mailing List <linux-next@vger.kernel.org> Subject: linux-next: manual merge of the drm-misc tree with the mm-stable tree Date: Fri, 14 Apr 2023 13:59:12 +0100 Message-Id: <20230414125913.851920-1-broonie@kernel.org> X-Mailer: git-send-email 2.30.2 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-4.4 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_MED, SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1763156685658981628?= X-GMAIL-MSGID: =?utf-8?q?1763156685658981628?= |
Series |
linux-next: manual merge of the drm-misc tree with the mm-stable tree
|
|
Commit Message
Mark Brown
April 14, 2023, 12:59 p.m. UTC
Hi all, Today's linux-next merge of the drm-misc tree got a conflict in: drivers/gpu/drm/ttm/ttm_pool.c between commit: 23baf831a32c0 ("mm, treewide: redefine MAX_ORDER sanely") from the mm-stable tree and commit: 56e51681246e5 ("drm/ttm: revert "Reduce the number of used allocation orders for TTM pages"") from the drm-misc tree. I fixed it up (see below) and can carry the fix as necessary. This is now fixed as far as linux-next is concerned, but any non trivial conflicts should be mentioned to your upstream maintainer when your tree is submitted for merging. You may also want to consider cooperating with the maintainer of the conflicting tree to minimise any particularly complex conflicts. +++ b/drivers/gpu/drm/ttm/ttm_pool.c [Just the version in mm]
Comments
On Fri, Apr 14, 2023 at 01:59:12PM +0100, broonie@kernel.org wrote: > Hi all, > > Today's linux-next merge of the drm-misc tree got a conflict in: > > drivers/gpu/drm/ttm/ttm_pool.c > > between commit: > > 23baf831a32c0 ("mm, treewide: redefine MAX_ORDER sanely") > > from the mm-stable tree and commit: > > 56e51681246e5 ("drm/ttm: revert "Reduce the number of used allocation orders for TTM pages"") > > from the drm-misc tree. > > I fixed it up (see below) and can carry the fix as necessary. This > is now fixed as far as linux-next is concerned, but any non trivial > conflicts should be mentioned to your upstream maintainer when your tree > is submitted for merging. You may also want to consider cooperating > with the maintainer of the conflicting tree to minimise any particularly > complex conflicts. > > > diff --cc drivers/gpu/drm/ttm/ttm_pool.c > index 4db3982057be8,dfce896c4baeb..0000000000000 > --- a/drivers/gpu/drm/ttm/ttm_pool.c > +++ b/drivers/gpu/drm/ttm/ttm_pool.c > > [Just the version in mm] Note there was a ppc compile fail, which is why we pushed the ttm revert. That /should/ be fixed now, but would be good if you can confirm? Thanks, Daniel
On Sun, Apr 16, 2023 at 09:58:50AM +0200, Daniel Vetter wrote: > Note there was a ppc compile fail, which is why we pushed the ttm revert. > That /should/ be fixed now, but would be good if you can confirm? I don't have any PowerPC toolchains set up - I guess one of the community builders might have checked?
On Sun, Apr 16, 2023 at 09:58:50AM +0200, Daniel Vetter wrote: > Note there was a ppc compile fail, which is why we pushed the ttm revert. > That /should/ be fixed now, but would be good if you can confirm? According to Nathan (CCed) there's still issues with the interaction with the PowerPC tree.
On Tue, Apr 18, 2023 at 07:34:44PM +0100, Mark Brown wrote: > On Sun, Apr 16, 2023 at 09:58:50AM +0200, Daniel Vetter wrote: > > > Note there was a ppc compile fail, which is why we pushed the ttm revert. > > That /should/ be fixed now, but would be good if you can confirm? > > According to Nathan (CCed) there's still issues with the interaction > with the PowerPC tree. So this revert was supposed to fix this: 56e51681246e ("drm/ttm: revert "Reduce the number of used allocation orders for TTM pages"") If there's anything left then I need to chase that asap since the merge window will open soon. -Daniel
On Wed, Apr 19, 2023 at 06:24:37PM +0200, Daniel Vetter wrote: > On Tue, Apr 18, 2023 at 07:34:44PM +0100, Mark Brown wrote: > > On Sun, Apr 16, 2023 at 09:58:50AM +0200, Daniel Vetter wrote: > > > > > Note there was a ppc compile fail, which is why we pushed the ttm revert. > > > That /should/ be fixed now, but would be good if you can confirm? > > > > According to Nathan (CCed) there's still issues with the interaction > > with the PowerPC tree. > > So this revert was supposed to fix this: 56e51681246e ("drm/ttm: revert > "Reduce the number of used allocation orders for TTM pages"") > > If there's anything left then I need to chase that asap since the merge > window will open soon. I think we are talking about two different issues here. My issue is not a compilation failure, it is an incorrect merge resolution that is happening in -next because of two independent changes in the drm and powerpc tree, the thread below should have more information. https://lore.kernel.org/20230413184725.GA3183133@dev-arch.thelio-3990X/ I do not think this is something that either tree can solve independently of each other, -next has to resolve the conflict correctly (which is what I point out in the message above) and a note of it should be passed along to Linus so it can be resolved correctly in mainline when the time comes. Cheers, Nathan
On Wed, Apr 19, 2023 at 09:30:11AM -0700, Nathan Chancellor wrote: > On Wed, Apr 19, 2023 at 06:24:37PM +0200, Daniel Vetter wrote: > > On Tue, Apr 18, 2023 at 07:34:44PM +0100, Mark Brown wrote: > > > On Sun, Apr 16, 2023 at 09:58:50AM +0200, Daniel Vetter wrote: > > > > > > > Note there was a ppc compile fail, which is why we pushed the ttm revert. > > > > That /should/ be fixed now, but would be good if you can confirm? > > > > > > According to Nathan (CCed) there's still issues with the interaction > > > with the PowerPC tree. > > > > So this revert was supposed to fix this: 56e51681246e ("drm/ttm: revert > > "Reduce the number of used allocation orders for TTM pages"") > > > > If there's anything left then I need to chase that asap since the merge > > window will open soon. > > I think we are talking about two different issues here. My issue is not > a compilation failure, it is an incorrect merge resolution that is > happening in -next because of two independent changes in the drm and > powerpc tree, the thread below should have more information. > > https://lore.kernel.org/20230413184725.GA3183133@dev-arch.thelio-3990X/ > > I do not think this is something that either tree can solve > independently of each other, -next has to resolve the conflict correctly > (which is what I point out in the message above) and a note of it should > be passed along to Linus so it can be resolved correctly in mainline > when the time comes. Ah yes that's a different one. I think we have a note about this one already, but I'll double-check with Dave Airlie. -Daniel
diff --cc drivers/gpu/drm/ttm/ttm_pool.c index 4db3982057be8,dfce896c4baeb..0000000000000 --- a/drivers/gpu/drm/ttm/ttm_pool.c