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=-5.9 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,NICE_REPLY_A,SPF_HELO_NONE, SPF_PASS,USER_AGENT_SANE_1 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 E8A33C47082 for ; Thu, 3 Jun 2021 06:50:53 +0000 (UTC) Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 9C7CC613DA for ; Thu, 3 Jun 2021 06:50:53 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 9C7CC613DA Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=linux.intel.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=dri-devel-bounces@lists.freedesktop.org Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id BBFFC6F3F1; Thu, 3 Jun 2021 06:50:52 +0000 (UTC) Received: from mga12.intel.com (mga12.intel.com [192.55.52.136]) by gabe.freedesktop.org (Postfix) with ESMTPS id 07B576E0C1; Thu, 3 Jun 2021 06:50:50 +0000 (UTC) IronPort-SDR: Mfdty32Ug2ZzyOkkprZHKsYkM1MRWh4yWBv/v1DwTFH9WaYJtXU37jxr6AyRK1lMX3k9QoEd3A 9LalA4OS6K3A== X-IronPort-AV: E=McAfee;i="6200,9189,10003"; a="183659089" X-IronPort-AV: E=Sophos;i="5.83,244,1616482800"; d="scan'208";a="183659089" Received: from fmsmga004.fm.intel.com ([10.253.24.48]) by fmsmga106.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 02 Jun 2021 23:50:50 -0700 IronPort-SDR: vR8nVvCel3CvOx4zZtYEHj/v6cbbeM9EdnU1GVv0oLakefu8f7LhZZDyq0L71B6E7bSmTLwPEW rBlZ2fyk7+Dw== X-IronPort-AV: E=Sophos;i="5.83,244,1616482800"; d="scan'208";a="467852375" Received: from slindbla-mobl1.ger.corp.intel.com (HELO [10.249.254.57]) ([10.249.254.57]) by fmsmga004-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 02 Jun 2021 23:50:46 -0700 Subject: Re: [Intel-gfx] Merging TTM branches through the Intel tree? To: Daniel Vetter , =?UTF-8?Q?Christian_K=c3=b6nig?= References: From: =?UTF-8?Q?Thomas_Hellstr=c3=b6m?= Message-ID: Date: Thu, 3 Jun 2021 08:50:44 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.10.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-BeenThere: dri-devel@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Direct Rendering Infrastructure - Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: =?UTF-8?Q?Thomas_Hellstr=c3=b6m_=28Intel=29?= , Intel Graphics Development , DRI Development , Matthew Auld Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" On 6/2/21 8:40 PM, Daniel Vetter wrote: > On Wed, Jun 02, 2021 at 11:48:41AM +0200, Christian König wrote: >> Am 02.06.21 um 11:16 schrieb Thomas Hellström (Intel): >>> On 6/2/21 10:32 AM, Christian König wrote: >>>> Uff I'm just waiting for feedback from Philip to merge a large patch >>>> set for TTM through drm-misc-next. >>>> >>>> I'm pretty sure we will run into merge conflicts if you try to push >>>> your changes through the Intel tree. >>>> >>>> Christian. >>> OK, so what would be the best approach here?, Adding the TTM patches to >>> drm-misc-next when your set has landed? >> I think I will send out out my set to Matthew once more for review, then >> push the common TTM stuff to drm-misc-next as much as possible. >> >> Then you should be able to land your stuff to drm-misc-next and rebase on >> the end result. >> >> Just need to note to David that drm-misc-next should be merged to drm-next >> before the Intel patches depending on that stuff land as well. > Other option (because the backmerges tend to be slow) is a topic branch, > and we just eat/resolve the conflicts in both drm-misc-next and > drm-intel-gt-next in the merge commit. If it's not too bad (I haven't > looked at what exactly we need for the i915 side from ttm in detail). > > But also often figuring out the topic branch logistics takes longer than > just merging to drm-misc-next as the patches get ready. > -Daniel Daniel: So the thing we need to get into TTM is the iterator-based move_memcpy which is more adaptable than the current one and needed to support non-linear lmem buffers, some bug-fixes and minor changes to be able to keep our short-term-pinning while on the LRU. A necessary evil. Christian: it looks like you have landed some TTM changes already, in particular the &bo->mem -> bo->resource change which is the main conflict I think. Is the 10 patches self-allocation series the main remaining part? That will probably cause some conflicts with already pushed i915 TTM setup code, but otherwise will not conflict with the rest of the TTM code I think, which should make it possible to bring in our TTM changes after conflict resolution with what you've already pushed. The memcpy code is pretty self-contained. /Thomas