Re: [PATCH v8 20/24] iommu: Require a default_domain for all iommu drivers
On Tue, 3 Oct 2023 at 02:00, Jason Gunthorpe wrote: > > On Tue, Oct 03, 2023 at 12:21:59AM +0300, Dmitry Baryshkov wrote: > > On Wed, 13 Sept 2023 at 16:45, Jason Gunthorpe wrote: > > > > > > At this point every iommu driver will cause a default_domain to be > > > selected, so we can finally remove this gap from the core code. > > > > > > The following table explains what each driver supports and what the > > > resulting default_domain will be: > > > > > > ops->defaut_domain > > > IDENTITY DMA PLATFORMv ARM32 > > > dma-iommu ARCH > > > amd/iommu.c Y Y N/A > > > either > > > apple-dart.cY Y N/A > > > either > > > arm-smmu.c Y Y IDENTITY > > > either > > > qcom_iommu.cG Y IDENTITY > > > either > > > arm-smmu-v3.c Y Y N/A > > > either > > > exynos-iommu.c G Y IDENTITY > > > either > > > fsl_pamu_domain.c Y Y N/A > > > N/A PLATFORM > > > intel/iommu.c Y Y N/A > > > either > > > ipmmu-vmsa.cG Y IDENTITY > > > either > > > msm_iommu.c G IDENTITY > > > N/A > > > > Unfortunately this patch breaks msm_iommu platforms. This driver > > doesn't select ARM_DMA_USE_IOMMU, so iommu_get_default_domain_type() > > returns 0, bus_iommu_probe() fails with -ENODEV. > > If I make MSM_IOMMU select ARM_DMA_USE_IOMMU, then GPU probing fails > > with -EBUSY. > > Oh, OK. > > Does this fix it? It indeed fixes the issue, so could you please post it, adding: Tested-by: Dmitry Baryshkov > diff --git a/drivers/iommu/msm_iommu.c b/drivers/iommu/msm_iommu.c > index cdc7b730192a35..f7ef081c33dcb2 100644 > --- a/drivers/iommu/msm_iommu.c > +++ b/drivers/iommu/msm_iommu.c > @@ -685,10 +685,16 @@ irqreturn_t msm_iommu_fault_handler(int irq, void > *dev_id) > return 0; > } > > +static int msm_iommu_def_domain_type(struct device *dev) > +{ > + return IOMMU_DOMAIN_IDENTITY; > +} > + > static struct iommu_ops msm_iommu_ops = { > .identity_domain = &msm_iommu_identity_domain, > .domain_alloc_paging = msm_iommu_domain_alloc_paging, > .probe_device = msm_iommu_probe_device, > + .def_domain_type = msm_iommu_def_domain_type, > .device_group = generic_device_group, > .pgsize_bitmap = MSM_IOMMU_PGSIZES, > .of_xlate = qcom_iommu_of_xlate, -- With best wishes Dmitry
Re: [PATCH v8 20/24] iommu: Require a default_domain for all iommu drivers
On Wed, 13 Sept 2023 at 16:45, Jason Gunthorpe wrote: > > At this point every iommu driver will cause a default_domain to be > selected, so we can finally remove this gap from the core code. > > The following table explains what each driver supports and what the > resulting default_domain will be: > > ops->defaut_domain > IDENTITY DMA PLATFORMv ARM32 > dma-iommu ARCH > amd/iommu.c Y Y N/A either > apple-dart.cY Y N/A either > arm-smmu.c Y Y IDENTITYeither > qcom_iommu.cG Y IDENTITYeither > arm-smmu-v3.c Y Y N/A either > exynos-iommu.c G Y IDENTITYeither > fsl_pamu_domain.c Y Y N/A N/A > PLATFORM > intel/iommu.c Y Y N/A either > ipmmu-vmsa.cG Y IDENTITYeither > msm_iommu.c G IDENTITYN/A Unfortunately this patch breaks msm_iommu platforms. This driver doesn't select ARM_DMA_USE_IOMMU, so iommu_get_default_domain_type() returns 0, bus_iommu_probe() fails with -ENODEV. If I make MSM_IOMMU select ARM_DMA_USE_IOMMU, then GPU probing fails with -EBUSY. > mtk_iommu.c G Y IDENTITYeither > mtk_iommu_v1.c G IDENTITYN/A > omap-iommu.cG IDENTITYN/A > rockchip-iommu.cG Y IDENTITYeither > s390-iommu.cY Y N/A N/A > PLATFORM > sprd-iommu.cY N/A DMA > sun50i-iommu.c G Y IDENTITYeither > tegra-smmu.cG Y IDENTITY > IDENTITY > virtio-iommu.c Y Y N/A either > spapr Y Y N/A N/A > PLATFORM > * G means ops->identity_domain is used > * N/A means the driver will not compile in this configuration > > ARM32 drivers select an IDENTITY default domain through either the > ops->identity_domain or directly requesting an IDENTIY domain through > alloc_domain(). > > In ARM64 mode tegra-smmu will still block the use of dma-iommu.c and > forces an IDENTITY domain. > > S390 uses a PLATFORM domain to represent when the dma_ops are set to the > s390 iommu code. > > fsl_pamu uses an PLATFORM domain. > > POWER SPAPR uses PLATFORM and blocking to enable its weird VFIO mode. > > The x86 drivers continue unchanged. > > After this patch group->default_domain is only NULL for a short period > during bus iommu probing while all the groups are constituted. Otherwise > it is always !NULL. > > This completes changing the iommu subsystem driver contract to a system > where the current iommu_domain always represents some form of translation > and the driver is continuously asserting a definable translation mode. > > It resolves the confusion that the original ops->detach_dev() caused > around what translation, exactly, is the IOMMU performing after > detach. There were at least three different answers to that question in > the tree, they are all now clearly named with domain types. > > Tested-by: Heiko Stuebner > Tested-by: Niklas Schnelle > Tested-by: Steven Price > Tested-by: Marek Szyprowski > Tested-by: Nicolin Chen > Reviewed-by: Lu Baolu > Reviewed-by: Jerry Snitselaar > Signed-off-by: Jason Gunthorpe > --- > drivers/iommu/iommu.c | 22 +++--- > 1 file changed, 7 insertions(+), 15 deletions(-) > > diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c > index 42a4585dd76da6..cfb597751f5bad 100644 > --- a/drivers/iommu/iommu.c > +++ b/drivers/iommu/iommu.c > @@ -1865,7 +1865,6 @@ static int iommu_get_def_domain_type(struct iommu_group > *group, > static int iommu_get_default_domain_type(struct iommu_group *group, > int target_type) > { > - const struct iommu_ops *ops = group_iommu_ops(group); > struct device *untrusted = NULL; > struct group_device *gdev; > int driver_type = 0; > @@ -1876,11 +1875,13 @@ static int iommu_get_default_domain_type(struct > iommu_group *group, > * ARM32 drivers supporting CONFIG_ARM_DMA_USE_IOMMU can declare an > * identity_domain and it will automatically become their default > * domain. Later on ARM_DMA_USE_IOMMU will install its UNMANAGED > domain. > -* Override the selection to IDENTITY if we are sure the driver > su
Re: [PATCH v5 14/25] iommu/msm: Implement an IDENTITY domain
On 24/07/2023 20:22, Jason Gunthorpe wrote: What msm does during omap_iommu_set_platform_dma() is actually putting the typo: msm driver doesn't use/provide omap_iommu_set_platform_dma(). iommu into identity mode. Move to the new core support for ARM_DMA_USE_IOMMU by defining ops->identity_domain. This driver does not support IOMMU_DOMAIN_DMA, however it cannot be compiled on ARM64 either. Most likely it is fine to support dma-iommu.c Signed-off-by: Jason Gunthorpe --- drivers/iommu/msm_iommu.c | 23 +++ 1 file changed, 19 insertions(+), 4 deletions(-) diff --git a/drivers/iommu/msm_iommu.c b/drivers/iommu/msm_iommu.c index 79d89bad5132b7..26ed81cfeee897 100644 --- a/drivers/iommu/msm_iommu.c +++ b/drivers/iommu/msm_iommu.c @@ -443,15 +443,20 @@ static int msm_iommu_attach_dev(struct iommu_domain *domain, struct device *dev) return ret; } -static void msm_iommu_set_platform_dma(struct device *dev) +static int msm_iommu_identity_attach(struct iommu_domain *identity_domain, +struct device *dev) { struct iommu_domain *domain = iommu_get_domain_for_dev(dev); - struct msm_priv *priv = to_msm_priv(domain); + struct msm_priv *priv; unsigned long flags; struct msm_iommu_dev *iommu; struct msm_iommu_ctx_dev *master; - int ret; + int ret = 0; + if (domain == identity_domain || !domain) + return 0; + + priv = to_msm_priv(domain); free_io_pgtable_ops(priv->iop); spin_lock_irqsave(&msm_iommu_lock, flags); @@ -468,8 +473,18 @@ static void msm_iommu_set_platform_dma(struct device *dev) } fail: spin_unlock_irqrestore(&msm_iommu_lock, flags); + return ret; } +static struct iommu_domain_ops msm_iommu_identity_ops = { + .attach_dev = msm_iommu_identity_attach, +}; + +static struct iommu_domain msm_iommu_identity_domain = { + .type = IOMMU_DOMAIN_IDENTITY, + .ops = &msm_iommu_identity_ops, +}; + static int msm_iommu_map(struct iommu_domain *domain, unsigned long iova, phys_addr_t pa, size_t pgsize, size_t pgcount, int prot, gfp_t gfp, size_t *mapped) @@ -675,10 +690,10 @@ irqreturn_t msm_iommu_fault_handler(int irq, void *dev_id) } static struct iommu_ops msm_iommu_ops = { + .identity_domain = &msm_iommu_identity_domain, .domain_alloc = msm_iommu_domain_alloc, .probe_device = msm_iommu_probe_device, .device_group = generic_device_group, - .set_platform_dma_ops = msm_iommu_set_platform_dma, .pgsize_bitmap = MSM_IOMMU_PGSIZES, .of_xlate = qcom_iommu_of_xlate, .default_domain_ops = &(const struct iommu_domain_ops) { -- With best wishes Dmitry
Re: [PATCH v2 01/16] of: device: make of_device_uevent_modalias() take a const device *
On 11/01/2023 17:26, Greg Kroah-Hartman wrote: On Wed, Jan 11, 2023 at 08:54:04AM -0600, Rob Herring wrote: On Wed, Jan 11, 2023 at 5:30 AM Greg Kroah-Hartman wrote: of_device_uevent_modalias() does not modify the device pointer passed to it, so mark it constant. In order to properly do this, a number of busses need to have a modalias function added as they were attempting to just point to of_device_uevent_modalias instead of their bus-specific modalias function. This is fine except if the prototype for a bus and device type modalias function diverges and then problems could happen. To prevent all of that, just wrap the call to of_device_uevent_modalias() directly for each bus and device type individually. Why not just put the wrapper function in the DT code instead of making 4 copies of it? I could, if you think that it would be better there instead of in each individual bus (like all of the other bus callbacks). This way each bus "owns" their implementation :) I'd vote for the generic wrapper instead of 4 similar wrapper. In the end, if of_device_uevent_modalias (or the bus callback) interface changes again for whatever reasons, there will be just a single place to fix rather than fixing 4 (or more) bus drivers. -- With best wishes Dmitry
Re: [PATCH] Add new framebuffer driver for Fujitsu MB862xx GDCs
Anatolij Gustschin wrote: > This patch adds framebuffer driver for Fujitsu Carmine/Coral-P(A)/Lime > graphics controllers. Lime GDC support is known to work on PPC440EPx > based lwmon5 and MPC8544E based socrates embedded boards, both equipped > with Lime GDC. Carmine/Coral-P PCI GDC support is known to work on > PPC440EPx based Sequoia board and also on x86 platform. > > Signed-off-by: Anatolij Gustschin <[EMAIL PROTECTED]> --- > There are some PPC OF bits, so I'm cc'ing linuxppc-dev list. I though there is already carminefb driver. Probably you should either merge them or state that carminefb should be dropped. -- With best wishes Dmitry ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Maple D info
Hi, Sorry to bother you. I'm searching for the information/guides related to the Maple D board (XSC-100). I've downloaded all the info I could get from the IBM, but I'm still missing the docs about board jumpers/settings/etc. All official sources for info are dead since long ago. So, if one has any technical docs regarding XSC-100 board, could you please contact me. Thanks in advance. -- With best wishes Dmitry ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev