Received: by 2002:a05:6a10:a0d1:0:0:0:0 with SMTP id j17csp394348pxa; Wed, 19 Aug 2020 04:34:44 -0700 (PDT) X-Google-Smtp-Source: ABdhPJx7Us+yFgE2JVbye0bkCEX8Z36yX31hEuMi9Qbhdg/XpAF7sHOwTW22qI9o/f/7w2uTf6xp X-Received: by 2002:aa7:c1ca:: with SMTP id d10mr25043052edp.261.1597836884593; Wed, 19 Aug 2020 04:34:44 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1597836884; cv=none; d=google.com; s=arc-20160816; b=0WougP7yikA6wFAUPGJ8QYrjtOUCB8q+Vd9nmlr2NKozQU6ZhWt6oHDQKXA8a/q0vU JArcPHi+mFw6+u1rTA7wZcV5zb/Oo2MIPB4cevjbGYni8PzA1almVe9QOiwNwnwTXzeK Uvi1BrG9+XBKqE/gb+feJO9KinGBKVWzOJZa1m5PP1FlD9N28L4DYseTe0XPhUVy/oRY QQRyxpFAKfzxF/mxNtmeaUJQ7ggK6iTFMda2TNChqOAOvqvKeJEmYZyiiZgHI1OJuNnJ 6fe8iQYdtkncdEIOGQqmZ8TXGAMrCqXUhRWZq+pbUgSNIbipznzqiBaRGnyzq4XPvhwm 34Jg== 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 :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject; bh=IfuAu+iv0tnsHn6XYFNDLE8WYjvLhgTJxluU6nWWbIA=; b=P7iUGtvjMOGt1ZZORWF2gcCCO7zRk1//o/Lk5vfkzUg5kZJR+57De5Kf6pr6Zm4LWh 4kO9E8AosDcSZkBpzk3dWoFucyfDyURhjURUZMP/ZZze54harlkUxdmKQpmBDvfADrEt 8r1h1tsV9EtluVEEBmFsoYb2u+OcGSiYRzK+uiMTFeBL36DSF74i8f6sctRKUFKLoe+8 RsIQZb22XiaHoBX60HItloN9J8ibIYPruq71ZayIdRitBGwlo8DwUMv+TEJNEBSzgekR 2KRpOiw4TqgvaPzHpw8fXLmgsVA5DZQu92HiOESNoco/EMXpVUEvqAEfv3wGmrlj5aV+ fLcw== 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id c19si15790462ejz.484.2020.08.19.04.34.20; Wed, 19 Aug 2020 04:34:44 -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; 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727856AbgHSLdU (ORCPT + 99 others); Wed, 19 Aug 2020 07:33:20 -0400 Received: from foss.arm.com ([217.140.110.172]:33414 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726820AbgHSLdT (ORCPT ); Wed, 19 Aug 2020 07:33:19 -0400 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 270F11045; Wed, 19 Aug 2020 04:33:18 -0700 (PDT) Received: from [10.57.40.122] (unknown [10.57.40.122]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 39FBA3F6CF; Wed, 19 Aug 2020 04:33:15 -0700 (PDT) Subject: Re: [PATCH 00/16] IOMMU driver for Kirin 960/970 To: Mauro Carvalho Chehab , John Stultz Cc: Greg Kroah-Hartman , driverdevel , "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" , Joerg Roedel , Manivannan Sadhasivam , Chenfeng , linuxarm@huawei.com, Wei Xu , lkml , iommu@lists.linux-foundation.org, Rob Herring , mauro.chehab@huawei.com, Suzhuangluan , linux-arm-kernel References: <5c7918b6-c506-680b-cb0f-9e5f6a7038d9@arm.com> <20200818172909.71f5243a@coco.lan> <79f40595-7769-aa6a-fbba-53adcffca327@arm.com> <20200819122832.3cd5f834@coco.lan> From: Robin Murphy Message-ID: Date: Wed, 19 Aug 2020 12:33:06 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; rv:68.0) Gecko/20100101 Thunderbird/68.11.0 MIME-Version: 1.0 In-Reply-To: <20200819122832.3cd5f834@coco.lan> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2020-08-19 11:28, Mauro Carvalho Chehab wrote: > Em Tue, 18 Aug 2020 15:02:54 -0700 > John Stultz escreveu: > >> On Tue, Aug 18, 2020 at 9:26 AM Robin Murphy wrote: >>> On 2020-08-18 16:29, Mauro Carvalho Chehab wrote: >>>> Em Tue, 18 Aug 2020 15:47:55 +0100 >>>> Basically, the DT binding has this, for IOMMU: >>>> >>>> >>>> smmu_lpae { >>>> compatible = "hisilicon,smmu-lpae"; >>>> }; >>>> >>>> ... >>>> dpe: dpe@e8600000 { >>>> compatible = "hisilicon,kirin970-dpe"; >>>> memory-region = <&drm_dma_reserved>; >>>> ... >>>> iommu_info { >>>> start-addr = <0x8000>; >>>> size = <0xbfff8000>; >>>> }; >>>> } >>>> >>>> This is used by kirin9xx_drm_dss.c in order to enable and use >>>> the iommu: >>>> >>>> >>>> static int dss_enable_iommu(struct platform_device *pdev, struct dss_hw_ctx *ctx) >>>> { >>>> struct device *dev = NULL; >>>> >>>> dev = &pdev->dev; >>>> >>>> /* create iommu domain */ >>>> ctx->mmu_domain = iommu_domain_alloc(dev->bus); >>>> if (!ctx->mmu_domain) { >>>> pr_err("iommu_domain_alloc failed!\n"); >>>> return -EINVAL; >>>> } >>>> >>>> iommu_attach_device(ctx->mmu_domain, dev); >>>> >>>> return 0; >>>> } >>>> >>>> The only place where the IOMMU domain is used is on this part of the >>>> code(error part simplified here) [1]: >>>> >>>> void hisi_dss_smmu_on(struct dss_hw_ctx *ctx) >>>> { >>>> uint64_t fama_phy_pgd_base; >>>> uint32_t phy_pgd_base; >>>> ... >>>> fama_phy_pgd_base = iommu_iova_to_phys(ctx->mmu_domain, 0); >>>> phy_pgd_base = (uint32_t)fama_phy_pgd_base; >>>> if (WARN_ON(!phy_pgd_base)) >>>> return; >>>> >>>> set_reg(smmu_base + SMMU_CB_TTBR0, phy_pgd_base, 32, 0); >>>> } >>>> >>>> [1] https://github.com/mchehab/linux/commit/36da105e719b47bbe9d6cb7e5619b30c7f3eb1bd >>>> >>>> In other words, the driver needs to get the physical address of the frame >>>> buffer (mapped via iommu) in order to set some DRM-specific register. >>>> >>>> Yeah, the above code is somewhat hackish. I would love to replace >>>> this part by a more standard approach. >>> >>> OK, so from a quick look at that, my impression is that your display >>> controller has its own MMU and you don't need to pretend to use the >>> IOMMU API at all. Just have the DRM driver use io-pgtable directly to >>> run its own set of ARM_32_LPAE_S1 pagetables - see Panfrost for an >>> example (but try to ignore the wacky "Mali LPAE" format). >> >> Yea. For the HiKey960, there was originally a similar patch series but >> it was refactored out and the (still out of tree) DRM driver I'm >> carrying doesn't seem to need it (though looking we still have the >> iommu_info subnode in the dts that maybe needs to be cleaned up). > > Funny... while the Hikey 970 DRM driver has such IOMMU code, it > doesn't actually use it! > > The driver has a function called hisi_dss_smmu_config() with > sets the registers on a different way in order to use IOMMU > or not, at the hisi_fb_pan_display() function. It can also > use a mode called "afbcd". > > Well, this function sets both to false: > > bool afbcd = false; > bool mmu_enable = false; > > I ended commenting out the code which depends at the iommu > driver and everything is working as before. > > So, I'll just forget about this iommu driver, as we can live > without that. > > For now, I'll keep the mmu code there commented out, as > it could be useful on a future port for it to use io-pgtable. > > - > > Robin, > > Can the Panfrost driver use io-pgtable while the KMS driver > won't be using it? Or this would cause it to not work? > > My end goal here is to be able to test the Panfrost driver ;-) Yup, the GPU has its own independent MMU, so Panfrost can import display buffers regardless of whether they're physically contiguous or not. Since Mesa master has recently landed AFBC support, there's probably more immediate benefit in getting that AFBC decoder working before the display MMU (although ultimately things are likely to work better under memory pressure if you don't have to rely on CMA, so it should still be worth coming back to at some point). Robin.