From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-3.7 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id AF44BC4727E for ; Thu, 1 Oct 2020 15:08:29 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 678C9207F7 for ; Thu, 1 Oct 2020 15:08:29 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1732339AbgJAPI2 (ORCPT ); Thu, 1 Oct 2020 11:08:28 -0400 Received: from mga07.intel.com ([134.134.136.100]:3056 "EHLO mga07.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1732213AbgJAPI2 (ORCPT ); Thu, 1 Oct 2020 11:08:28 -0400 IronPort-SDR: 2/bjamm5NXgcRVfi6LE3LpT/AjcVtk3DftdkGBPv7i39vEr3OHaSeuQzPOBr/XGQ5hFjL1QCrA UqymGpyqRRUA== X-IronPort-AV: E=McAfee;i="6000,8403,9760"; a="226872520" X-IronPort-AV: E=Sophos;i="5.77,323,1596524400"; d="scan'208";a="226872520" X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga005.jf.intel.com ([10.7.209.41]) by orsmga105.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 01 Oct 2020 08:08:21 -0700 IronPort-SDR: O74dZO2eJgRDJLthE9jBgpEVhqwkllD59i4GnCHCxutJccngda6LcTYLp6JKVj8dIEg/+jV4fu l6hOT1x/4JaQ== X-IronPort-AV: E=Sophos;i="5.77,323,1596524400"; d="scan'208";a="504034506" Received: from lraichel-mobl.ger.corp.intel.com (HELO localhost) ([10.249.36.225]) by orsmga005-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 01 Oct 2020 08:08:17 -0700 From: Jani Nikula To: Daniel Vetter , Christoph Hellwig Cc: Stephen Rothwell , Andrew Morton , Joonas Lahtinen , Rodrigo Vivi , Intel Graphics , DRI , Dave Airlie , Chris Wilson , Linux Kernel Mailing List , Linux Next Mailing List Subject: Re: linux-next: manual merge of the akpm tree with the drm-intel tree In-Reply-To: Organization: Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo References: <20201001203917.43d46a3d@canb.auug.org.au> <20201001135350.GA14869@lst.de> Date: Thu, 01 Oct 2020 18:08:36 +0300 Message-ID: <87h7rem1aj.fsf@intel.com> MIME-Version: 1.0 Content-Type: text/plain Precedence: bulk List-ID: X-Mailing-List: linux-next@vger.kernel.org On Thu, 01 Oct 2020, Daniel Vetter wrote: > On Thu, Oct 1, 2020 at 3:53 PM Christoph Hellwig wrote: >> >> On Thu, Oct 01, 2020 at 08:39:17PM +1000, Stephen Rothwell wrote: >> > Hi all, >> > >> > Today's linux-next merge of the akpm tree got a conflict in: >> > >> > drivers/gpu/drm/i915/gem/i915_gem_pages.c >> > >> > between commit: >> > >> > 4caf017ee937 ("drm/i915/gem: Avoid implicit vmap for highmem on x86-32") >> > ba2ebf605d5f ("drm/i915/gem: Prevent using pgprot_writecombine() if PAT is not supported") > > Uh these patches shouldn't be in linux-next because they're for 5.11, > not the 5.10 merge window that will open soon. Joonas? I don't know anything else, but both are tagged Cc: stable. BR, Jani. > >> > from the drm-intel tree and patch: >> > >> > "drm/i915: use vmap in i915_gem_object_map" >> > >> > from the akpm tree. >> > >> > I fixed it up (I just dropped the changes in the former commits) and >> >> Sigh. The solution is a bit more complicated, but I just redid my >> patches to not depend on the above ones. I can revert back to the old >> version, though. Andrew, let me know what works for you. > > Imo ignore, rebasing onto linux-next without those intel patches was > the right thing for the 5.10 merge window. > -Daniel -- Jani Nikula, Intel Open Source Graphics Center