Received: by 2002:a05:6a10:a0d1:0:0:0:0 with SMTP id j17csp2161783pxa; Mon, 17 Aug 2020 02:31:09 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwbf/WACZdTKHzgrYSKUafUDVTEAcXtLe4ub5wE2w3lXekdWIRS33XmgEayylXOlQ+i7JNm X-Received: by 2002:a17:907:9e7:: with SMTP id ce7mr14020200ejc.12.1597656669287; Mon, 17 Aug 2020 02:31:09 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1597656669; cv=none; d=google.com; s=arc-20160816; b=FNRpJGavWxIFSqe4qcBc8jZIYxJ5cO9vgOZFyrh5LpR8+NwQQI/5JQpxaOYVBqYcN3 LvAS7ZfKQyuXfkAnkd3pM9C3rBQg0TiTChsjJnS2WEzYhe1kEY62uMOrG2OG6wfgAZG/ nldtrcWhMpsurJsBSH7LVfppZTjW2ORlrkIw7AwwdQw2AtbB0uW51cZPCcUTmKuKwY2o UysVeTAZSu5wiW0N/p6TFb11tnSuNK+ahSJTWXMUiL3DtdNwATvLmgduJP/U0RvtfCrW 3V+JkCy3mSCrNEdrhlaH6D0n3DCS1X/RJvxnbroSdV8Y+cV5zI+YEgKNz/tT9OTl8Kv5 dbIA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :references:in-reply-to:message-id:subject:cc:to:from:date :dkim-signature; bh=cmkmhZjwAZDWA8P9OvtZ4cTH/xwBY2G2jOEuruNB3+E=; b=oO1CIAax9RCNa1+KMigVTsUk56hAN2nLVY+LYcUPa4VX/s2+LwRj2u+Ahn9sfHknoi MCZ+HJ0xCVX8/os1MhHt9QGq6H/BTvw9rGdUKyvmMQwoReIAFA3vjyIGmb7gt+Mhs4v+ rFFOyIzkQk44SlrtN4ARcTm2Jv6c0nKQgsGexj74saMcjc4OKMdOr8FQbf3DdQWNhE5g yjx6lSDa7ihI8yk0S1MOlXo7Je9sSER5U8EzvNeBFitEI8443Hvrg3+s5U0AdrxpGAnJ 3hjMJKczRDX04LHz1/HiC27SFDGXm3aylhmBKUKGiW4RUdneGiv63p1MNuhLLz8X0Iep 6wVQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=vqk5sYZZ; 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=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id r29si10745656edx.264.2020.08.17.02.30.45; Mon, 17 Aug 2020 02:31:09 -0700 (PDT) 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; dkim=pass header.i=@kernel.org header.s=default header.b=vqk5sYZZ; 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=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727001AbgHQJ1c (ORCPT + 99 others); Mon, 17 Aug 2020 05:27:32 -0400 Received: from mail.kernel.org ([198.145.29.99]:36802 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726422AbgHQJ1b (ORCPT ); Mon, 17 Aug 2020 05:27:31 -0400 Received: from coco.lan (ip5f5ad5a3.dynamic.kabel-deutschland.de [95.90.213.163]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 0E6CF2072D; Mon, 17 Aug 2020 09:27:27 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1597656451; bh=J/kOpSEU8RbORM5aCdkVXUkRjQk8bFOWgJybhAWbpJU=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=vqk5sYZZ5vFZvh+OqPDYux84g9ZoKEUfl5z4tXlktjbc5mbcZQo9e27w5hlB9T2ZO hUtwy0hXhHzgSFFRkZjOfcnrDWyr8IUSf4FplhzqtGDtOHOLFXvmhtO/K4kBNzavLa F3lePsGgArFX+LDzGfPRsQr7vKYAV3zzh8B8ZqAs= Date: Mon, 17 Aug 2020 11:27:25 +0200 From: Mauro Carvalho Chehab To: Christoph Hellwig Cc: Greg Kroah-Hartman , linuxarm@huawei.com, mauro.chehab@huawei.com, John Stultz , Manivannan Sadhasivam , Rob Herring , linux-arm-kernel@lists.infradead.org, Wei Xu , devicetree@vger.kernel.org, Joerg Roedel , Joerg Roedel , iommu@lists.linux-foundation.org, Chenfeng , devel@driverdev.osuosl.org, Suzhuangluan , linux-kernel@vger.kernel.org Subject: Re: [PATCH 00/16] IOMMU driver for Kirin 960/970 Message-ID: <20200817112725.26f1b7d6@coco.lan> In-Reply-To: <20200817082106.GA16296@infradead.org> References: <20200817082106.GA16296@infradead.org> X-Mailer: Claws Mail 3.17.5 (GTK+ 2.24.32; x86_64-redhat-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Christoph, Em Mon, 17 Aug 2020 09:21:06 +0100 Christoph Hellwig escreveu: > On Mon, Aug 17, 2020 at 09:49:59AM +0200, Mauro Carvalho Chehab wrote: > > Add a driver for the Kirin 960/970 iommu. > > > > As on the past series, this starts from the original 4.9 driver from > > the 96boards tree: > > > > https://github.com/96boards-hikey/linux/tree/hikey970-v4.9 > > > > The remaining patches add SPDX headers and make it build and run with > > the upstream Kernel. > > Please don't add iommu drivers to staging, and just work with the > maintainers to properly clean it up. I need to start from the original patch in order to preserve its authorship. My plan is to work with the iommu subsystem maintainers after have this (and another pending patch series for DRM) merged. > I also don't think adding a totally out of date not compiling version > is a good idea. Please do a proper rollup, and if required (probably > not in this case), split it into useful chunks. This series make this driver working as expected. I mean, while patch 01/16 is against Kernel 4.9, the other patches on this series ports it to upstream, cleans up the driver and address several issues on it. This specific IOMMU seems to be an specific part of the SoC dedicated for the display engine and by the encoding/decoding images via the ISP. With this series, this driver builds and runs as expected, providing IOMMU support needed by the upcoming KMS/DRM driver. The only issue on it (as far as I can tell) is that the DT bindings require some work, as, instead of using dma-ranges, the DRM driver binds into it with: smmu_lpae { compatible = "hisilicon,smmu-lpae"; }; dpe: dpe@e8600000 { compatible = "hisilicon,kirin970-dpe"; ... iommu_info { start-addr = <0x8000>; size = <0xbfff8000>; }; }; In order to properly address it, the best would be to also have the DRM driver merged upstream, as it relies on it. So, a change in DT will also mean a change at the way the DRM uses it. The DRM itself should go via staging, as it has some bugs that I'd like to fix before moving it to drivers/gpu/drm. Those are more tricky to solve, as they seem to require using different settings for some hardware registers, and the downstream driver also have the same issues. Fixing them will likely require some time. Thanks, Mauro