Received: by 2002:a05:6a10:16a7:0:0:0:0 with SMTP id gp39csp382715pxb; Tue, 3 Nov 2020 02:02:14 -0800 (PST) X-Google-Smtp-Source: ABdhPJzG975X7Ur5WUuejK2YYXLAinRGbRIaGRbA9FffOJD+jF812lzk4tRrAuI30BIgtsHXDQqT X-Received: by 2002:a17:906:ad8c:: with SMTP id la12mr18622569ejb.521.1604397734447; Tue, 03 Nov 2020 02:02:14 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1604397734; cv=none; d=google.com; s=arc-20160816; b=yl//FKET2zRkTQ6tmpEAtxVRzwEMhzy1zyjZCQyrn16Z7iz1cJhy0ZdnFWyevbEN7j MOtVlcg5ieVEkoerlJSgOmaOdWpNyfclV3aUFohqS+i4xGNxAVZhmhZwdK6CVzsxB3u8 79CsajuoPSO2bViVDxLBJTUOsu/cnKbis6PDPtaE2cf51bQZUGwLEY7H9B96PeqiDr0U LSwfQuDObDvJkXMakM76ZwTBe3h5cjYNZcorIsa8KCRwg6/5zYb3cf7HuXKlPUpdF9JU UChnHpfjh12gEUqjcggWIx+v8zHPiGFUqJf6Wu1n2TouuzkiSiQDuBI0Pqn1jMqwLoY7 vY2g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:date:user-agent:message-id:organization:from :subject:to:cc:references:in-reply-to:content-transfer-encoding :mime-version:ironport-sdr:ironport-sdr; bh=WxZosOWtDUza7V2pGRW2LJR3lnnpTIIbaAGZjBT7H4c=; b=FE+5xsOMB/wbWRBpGm1C5aga1WmGZLiF6RoZReoHeqVE5S+Ab1Sqo693C20epMKtBK QUV2RqGKJrHI3l1zrW0uNE+a3GGdiRjncNVjX/RokV/ln63s0sMb2028Bw1Ydrx55xAt oYWIZqe8e+W97z6GX+gZmOe7xvwd/4Ap8GHE3gvYuMeAVcSedufdn9/4XBIW68Ktc5M1 oxJolpA+h+dIEuZ2QWi+xHugt27nu2YRYo50KAOJyFW5wjUbumhbT43CmW+YvV8IMNpZ UXaZ1AZidWMSRSm5vH0z+6OmITbIx4qlFVRFjASSwYypmglii6uOGvPuPyplO2+YxvwZ llTg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id bu15si12204253ejb.175.2020.11.03.02.01.51; Tue, 03 Nov 2020 02:02:14 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727385AbgKCJ6d convert rfc822-to-8bit (ORCPT + 99 others); Tue, 3 Nov 2020 04:58:33 -0500 Received: from mga12.intel.com ([192.55.52.136]:62748 "EHLO mga12.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725988AbgKCJ6c (ORCPT ); Tue, 3 Nov 2020 04:58:32 -0500 IronPort-SDR: RewzBUIiezlD+TwUtNOOOs9lkZ7SUQqhY+gDPnH4GrttGQw2MRogGEFTPgVl7oT8aIvjHf1Zp5 wpj6zEaCkdVg== X-IronPort-AV: E=McAfee;i="6000,8403,9793"; a="148308737" X-IronPort-AV: E=Sophos;i="5.77,447,1596524400"; d="scan'208";a="148308737" X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga005.fm.intel.com ([10.253.24.32]) by fmsmga106.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 03 Nov 2020 01:58:31 -0800 IronPort-SDR: qXZ3CdVSYmts5JPldn4hVxPQrAnAqM0Gp50/FrVIsGpM55HmGd9I+qH+0dA28fc+ZNECT9313p hjOw5WMKj6fQ== X-IronPort-AV: E=Sophos;i="5.77,447,1596524400"; d="scan'208";a="528363463" Received: from stevenro-mobl.ger.corp.intel.com (HELO localhost) ([10.252.23.13]) by fmsmga005-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 03 Nov 2020 01:58:28 -0800 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8BIT In-Reply-To: <99a0d1eb-7fde-dff4-225f-92b68fbf7620@linux.intel.com> References: <20200927063437.13988-1-baolu.lu@linux.intel.com> <8bac9e91-36a0-c1d6-a887-4d60567ac75a@linux.intel.com> <3f5694f3-62f9-cc2b-1c2b-f9e99a4788c1@linux.intel.com> <1ce5b94a-38b3-548e-3b1a-a68390b93953@linux.intel.com> <82dab98e-0761-8946-c31c-92f19a0615b4@linux.intel.com> <99a0d1eb-7fde-dff4-225f-92b68fbf7620@linux.intel.com> Cc: Ashok Raj , Intel-gfx@lists.freedesktop.org, iommu@lists.linux-foundation.org, linux-kernel@vger.kernel.org To: Christoph Hellwig , David Woodhouse , Joerg Roedel , Lu Baolu , Tom Murphy , Tvrtko Ursulin Subject: Re: [PATCH v4 0/7] Convert the intel iommu driver to the dma-iommu api From: Joonas Lahtinen Organization: Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo Message-ID: <160439750572.8460.14782978404889004150@jlahtine-mobl.ger.corp.intel.com> User-Agent: alot/0.8.1 Date: Tue, 03 Nov 2020 11:58:26 +0200 Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Quoting Tvrtko Ursulin (2020-11-03 11:14:32) > > > On 03/11/2020 02:53, Lu Baolu wrote: > > On 11/2/20 7:52 PM, Tvrtko Ursulin wrote: > >> > >> On 02/11/2020 02:00, Lu Baolu wrote: > >>> Hi Tvrtko, > >>> On 10/12/20 4:44 PM, Tvrtko Ursulin wrote: > >>>> > >>>> On 29/09/2020 01:11, Lu Baolu wrote: > >>>> FYI we have merged the required i915 patches to out tree last week > >>>> or so. I *think* this means they will go into 5.11. So the i915 > >>>> specific workaround patch will not be needed in Intel IOMMU. > >>> > >>> Do you mind telling me what's the status of this fix patch? I tried this > >>> series on v5.10-rc1 with the graphic quirk patch dropped. I am still > >>> seeing dma faults from graphic device. > >> > >> Hmm back then I thought i915 fixes for this would land in 5.11 so I > >> will stick with that. :) (See my quoted text a paragraph above yours.) > > > > What size are those fixes? I am considering pushing this series for > > v5.11. Is it possible to get some acks for those patches and let them > > go to Linus through iommu tree? > > For 5.10 you mean? They feel a bit too large for comfort to go via a > non-i915/drm tree. These are the two patches required: > > https://cgit.freedesktop.org/drm-intel/commit/?h=drm-intel-gt-next&id=8a473dbadccfc6206150de3db3223c40785da348 > https://cgit.freedesktop.org/drm-intel/commit/?h=drm-intel-gt-next&id=934941ed5a3070a7833c688c9b1d71484fc01a68 > > I'll copy Joonas as our maintainer - how does the idea of taking the > above two patches through the iommu tree sound to you? Hi Lu, The patches have already been merged into our tree and are heading towards 5.11, so I don't think we should merge them elsewhere. DRM subsystem had the feature freeze for 5.10 at the time of 5.9-rc5 and only drm-intel-fixes pull requests are sent after that. The patches seem to target to eliminate need for a previously used workaround. To me it seems more appropriate for the patches to follow the regular process as new feature for 5.11 to make sure the changes get validated as part of linux-next. Would that work for you? We intend to send the feature pull requests to DRM for 5.11 in the upcoming weeks. Regards, Joonas