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 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 smtp.lore.kernel.org (Postfix) with ESMTPS id 5F42AC433FE for ; Thu, 20 Jan 2022 16:57:25 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id DE50B10E8DB; Thu, 20 Jan 2022 16:57:19 +0000 (UTC) Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) by gabe.freedesktop.org (Postfix) with ESMTPS id C951310E8D4; Thu, 20 Jan 2022 16:57:18 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1642697838; x=1674233838; h=date:from:to:subject:message-id:references:mime-version: content-transfer-encoding:in-reply-to; bh=pCcwTYYesBJwbUxzk/FlPOIcKf6xw2HINpD6RNQi8Ug=; b=kKAQyiDghXfU/NDu4Gbmm4TnGO8w017GPjhajy/b1cLf8Pe8bjC4QeVk 49sNWg6NNPWlfkz7iWUhl9/tMGyKuYEejU9kDm3cs8TUH///vgrsGUynx +7Z49gUeJqr3z9TTDMpHSdge++w91P/3iNXcBCgq8a9dfObjmmETj2mFf SEp7pDQM6GVg9DxWVMq8vJmW9psMUeBllbnjDR6E8iXvfoyPqBuOqzv/b NkPWnNgMh83CTfqt0oJsYFNIdkqPpamuOKENIk/52Gbw6/U0iq+n9V8kK O2OPUt/JJZgA+682oz3r3Oj+jPMvvzjwshh2ZsVeYtV14iWUAWYM3InZy A==; X-IronPort-AV: E=McAfee;i="6200,9189,10233"; a="245189912" X-IronPort-AV: E=Sophos;i="5.88,302,1635231600"; d="scan'208";a="245189912" Received: from orsmga008.jf.intel.com ([10.7.209.65]) by orsmga102.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 20 Jan 2022 08:57:18 -0800 X-IronPort-AV: E=Sophos;i="5.88,302,1635231600"; d="scan'208";a="532859202" Received: from iweiny-desk2.sc.intel.com (HELO localhost) ([10.3.52.147]) by orsmga008-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 20 Jan 2022 08:57:18 -0800 Date: Thu, 20 Jan 2022 08:57:17 -0800 From: Ira Weiny To: Christian =?iso-8859-1?Q?K=F6nig?= , David Airlie , Patrik Jakobsson , Rob Clark , Sean Paul , amd-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org, intel-gfx@lists.freedesktop.org, linux-arm-msm@vger.kernel.org Message-ID: <20220120165717.GG209936@iweiny-DESK2.sc.intel.com> References: <20211210232404.4098157-1-ira.weiny@intel.com> <20220119165356.GD209936@iweiny-DESK2.sc.intel.com> <20220119235542.GF209936@iweiny-DESK2.sc.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.11.1 (2018-12-01) Subject: Re: [Intel-gfx] [PATCH 0/7] DRM kmap() fixes and kmap_local_page() conversions X-BeenThere: intel-gfx@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Intel graphics driver community testing & development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: intel-gfx-bounces@lists.freedesktop.org Sender: "Intel-gfx" On Thu, Jan 20, 2022 at 04:48:50PM +0100, Daniel Vetter wrote: > On Thu, Jan 20, 2022 at 09:16:35AM +0100, Christian König wrote: > > Am 20.01.22 um 00:55 schrieb Ira Weiny: > > > On Wed, Jan 19, 2022 at 06:24:22PM +0100, Daniel Vetter wrote: > > > > On Wed, Jan 19, 2022 at 08:53:56AM -0800, Ira Weiny wrote: > > > > > On Fri, Dec 10, 2021 at 03:23:57PM -0800, 'Ira Weiny' wrote: > > > > > > From: Ira Weiny > > > > > > > > > > > > This series starts by converting the last easy kmap() uses to > > > > > > kmap_local_page(). > > > > > > > > > > > > There is one more call to kmap() wrapped in ttm_bo_kmap_ttm(). Unfortunately, > > > > > > ttm_bo_kmap_ttm() is called in a number of different ways including some which > > > > > > are not thread local. I have a patch to convert that call. However, it is not > > > > > > straight forward so it is not included in this series. > > > > > > > > > > > > The final 2 patches fix bugs found while working on the ttm_bo_kmap_ttm() > > > > > > conversion. > > > > > Gentile ping on this series? Will it make this merge window? > > > > I think this fell through the cracks and so no. Note that generally we > > > > feature-freeze drm tree around -rc6 anyway for the upcoming merge window, > > > > so you were cutting this all a bit close anyway. > > > Ok, No problem. I just had not heard if this was picked up or not. > > > > > > > Also looks like the ttm > > > > kmap caching question didn't get resolved? > > > I'm sorry I thought it was resolve for this series. Christian said the patches > > > in this series were "a good bug fix" even if not strictly necessary.[1] Beyond > > > this series I was discussing where to go from here, and is it possible to go > > > further with more changes.[2] At the moment I don't think I will. > > > > > > Christian did I misunderstand? I can drop patch 6 and 7 if they are not proper > > > bug fixes or at least clarifications to the code. > > > > Yeah, it is indeed a correct cleanup. I would just *not* put a CC stable on > > it because it doesn't really fix anything. > > Ok can you pls get the amd/radeon ones stuffed into alex' tree? Or do we > want to put all the ttm ones into drm-misc instead? I just updated to the latest master and there is a minor conflict. Since this is not going in this window. Let me rebase and resend. Ira > -Daniel >