On 2020-08-19 11:28, Mauro Carvalho Chehab wrote:
Em Tue, 18 Aug 2020 15:02:54 -0700
John Stultz <john.stultz@xxxxxxxxxx> escreveu:
On Tue, Aug 18, 2020 at 9:26 AM Robin Murphy <robin.murphy@xxxxxxx> 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.
_______________________________________________
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxx
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
