[PATCH 0/4] Fix omap-iommu bitrot

[PATCH 0/4] Fix omap-iommu bitrot

[Robin Murphy]

Hi all,

It seems omap-iommu hasn't had enough mainline users to avoid bitrotting
through the more recent evolution of the IOMMU API internals. These
patches attempt to bring it and its consumers sufficiently up-to-date
to work again, in a manner that's hopefully backportable. This is
largely all written by inspection, but I have managed to lightly boot
test patch #3 on an OMAP4 Pandaboard to confirm iommu_probe_device()
working again.

This supersedes my previous patch[1]. Patches #1 and #2 are functionally
independent, and can be applied directly to their respective trees if
preferred.

Thanks,
Robin.

[1] https://lore.kernel.org/linux-iommu/c44545c6d07c65d89daa297298c27bb0f15c8b84.1728393458.git.robin.murphy@arm.com/


Robin Murphy (4):
  remoteproc/omap: Handle ARM dma_iommu_mapping
  media: omap3isp: Handle ARM dma_iommu_mapping
  iommu/omap: Add minimal fwnode support
  iommu: Make bus_iommu_probe() static

 drivers/iommu/iommu.c                    |  3 ++-
 drivers/iommu/omap-iommu.c               | 26 +++++++++++++++---------
 drivers/media/platform/ti/omap3isp/isp.c |  7 +++++++
 drivers/remoteproc/omap_remoteproc.c     | 17 ++++++++++++++++
 include/linux/iommu.h                    |  1 -
 5 files changed, 42 insertions(+), 12 deletions(-)

-- 
2.39.2.101.g768bb238c484.dirty

[PATCH 1/4] remoteproc/omap: Handle ARM dma_iommu_mapping

[Robin Murphy]

It's no longer practical for the OMAP IOMMU driver to trick
arm_setup_iommu_dma_ops() into ignoring its presence, so let's use the
same tactic as other IOMMU API users on 32-bit ARM and explicitly kick
the arch code's dma_iommu_mapping out of the way to avoid problems.

Fixes: 4720287c7bf7 ("iommu: Remove struct iommu_ops *iommu from arch_setup_dma_ops()")
Signed-off-by: Robin Murphy <robin.murphy@arm.com>
---
 drivers/remoteproc/omap_remoteproc.c | 17 +++++++++++++++++
 1 file changed, 17 insertions(+)

diff --git a/drivers/remoteproc/omap_remoteproc.c b/drivers/remoteproc/omap_remoteproc.c
index 9ae2e831456d..3260dd512491 100644
--- a/drivers/remoteproc/omap_remoteproc.c
+++ b/drivers/remoteproc/omap_remoteproc.c
@@ -37,6 +37,10 @@
 
 #include <linux/platform_data/dmtimer-omap.h>
 
+#ifdef CONFIG_ARM_DMA_USE_IOMMU
+#include <asm/dma-iommu.h>
+#endif
+
 #include "omap_remoteproc.h"
 #include "remoteproc_internal.h"
 
@@ -1323,6 +1327,19 @@ static int omap_rproc_probe(struct platform_device *pdev)
 	/* All existing OMAP IPU and DSP processors have an MMU */
 	rproc->has_iommu = true;
 
+#ifdef CONFIG_ARM_DMA_USE_IOMMU
+	/*
+	 * Throw away the ARM DMA mapping that we'll never use, so it doesn't
+	 * interfere with the core rproc->domain and we get the right DMA ops.
+	 */
+	if (pdev->dev.archdata.mapping) {
+		struct dma_iommu_mapping *mapping = to_dma_iommu_mapping(&pdev->dev);
+
+		arm_iommu_detach_device(&pdev->dev);
+		arm_iommu_release_mapping(mapping);
+	}
+#endif
+
 	ret = omap_rproc_of_get_internal_memories(pdev, rproc);
 	if (ret)
 		return ret;
-- 
2.39.2.101.g768bb238c484.dirty

Re: [PATCH 1/4] remoteproc/omap: Handle ARM dma_iommu_mapping

[Mathieu Poirier]

On Mon, Oct 28, 2024 at 05:58:35PM +0000, Robin Murphy wrote:
> It's no longer practical for the OMAP IOMMU driver to trick
> arm_setup_iommu_dma_ops() into ignoring its presence, so let's use the
> same tactic as other IOMMU API users on 32-bit ARM and explicitly kick
> the arch code's dma_iommu_mapping out of the way to avoid problems.
> 
> Fixes: 4720287c7bf7 ("iommu: Remove struct iommu_ops *iommu from arch_setup_dma_ops()")
> Signed-off-by: Robin Murphy <robin.murphy@arm.com>
> ---
>  drivers/remoteproc/omap_remoteproc.c | 17 +++++++++++++++++
>  1 file changed, 17 insertions(+)
> 
> diff --git a/drivers/remoteproc/omap_remoteproc.c b/drivers/remoteproc/omap_remoteproc.c
> index 9ae2e831456d..3260dd512491 100644
> --- a/drivers/remoteproc/omap_remoteproc.c
> +++ b/drivers/remoteproc/omap_remoteproc.c
> @@ -37,6 +37,10 @@
>  
>  #include <linux/platform_data/dmtimer-omap.h>
>  
> +#ifdef CONFIG_ARM_DMA_USE_IOMMU
> +#include <asm/dma-iommu.h>
> +#endif
> +
>  #include "omap_remoteproc.h"
>  #include "remoteproc_internal.h"
>  
> @@ -1323,6 +1327,19 @@ static int omap_rproc_probe(struct platform_device *pdev)
>  	/* All existing OMAP IPU and DSP processors have an MMU */
>  	rproc->has_iommu = true;
>  
> +#ifdef CONFIG_ARM_DMA_USE_IOMMU
> +	/*
> +	 * Throw away the ARM DMA mapping that we'll never use, so it doesn't
> +	 * interfere with the core rproc->domain and we get the right DMA ops.
> +	 */
> +	if (pdev->dev.archdata.mapping) {
> +		struct dma_iommu_mapping *mapping = to_dma_iommu_mapping(&pdev->dev);
> +
> +		arm_iommu_detach_device(&pdev->dev);
> +		arm_iommu_release_mapping(mapping);
> +	}
> +#endif
> +

Despite acknowledging this patch I never applied it, something I have corrected
now.

Thanks for Beleswar for bringing this to my attention.

Regards,
Mathieu

>  	ret = omap_rproc_of_get_internal_memories(pdev, rproc);
>  	if (ret)
>  		return ret;
> -- 
> 2.39.2.101.g768bb238c484.dirty
> 

[PATCH 2/4] media: omap3isp: Handle ARM dma_iommu_mapping

[Robin Murphy]

It's no longer practical for the OMAP IOMMU driver to trick
arm_setup_iommu_dma_ops() into ignoring its presence, so let's use the
same tactic as other IOMMU API users on 32-bit ARM and explicitly kick
the arch code's dma_iommu_mapping out of the way to avoid problems.

Fixes: 4720287c7bf7 ("iommu: Remove struct iommu_ops *iommu from arch_setup_dma_ops()")
Signed-off-by: Robin Murphy <robin.murphy@arm.com>
---
 drivers/media/platform/ti/omap3isp/isp.c | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/drivers/media/platform/ti/omap3isp/isp.c b/drivers/media/platform/ti/omap3isp/isp.c
index 91101ba88ef0..b2210841a320 100644
--- a/drivers/media/platform/ti/omap3isp/isp.c
+++ b/drivers/media/platform/ti/omap3isp/isp.c
@@ -1961,6 +1961,13 @@ static int isp_attach_iommu(struct isp_device *isp)
 	struct dma_iommu_mapping *mapping;
 	int ret;
 
+	/* We always want to replace any default mapping from the arch code */
+	mapping = to_dma_iommu_mapping(isp->dev);
+	if (mapping) {
+		arm_iommu_detach_device(isp->dev);
+		arm_iommu_release_mapping(mapping);
+	}
+
 	/*
 	 * Create the ARM mapping, used by the ARM DMA mapping core to allocate
 	 * VAs. This will allocate a corresponding IOMMU domain.
-- 
2.39.2.101.g768bb238c484.dirty

Re: [PATCH 2/4] media: omap3isp: Handle ARM dma_iommu_mapping

[Sicelo]

Hi

On Mon, Oct 28, 2024 at 05:58:36PM +0000, Robin Murphy wrote:
> It's no longer practical for the OMAP IOMMU driver to trick
> arm_setup_iommu_dma_ops() into ignoring its presence, so let's use the
> same tactic as other IOMMU API users on 32-bit ARM and explicitly kick
> the arch code's dma_iommu_mapping out of the way to avoid problems.
> 
> Fixes: 4720287c7bf7 ("iommu: Remove struct iommu_ops *iommu from arch_setup_dma_ops()")
> Signed-off-by: Robin Murphy <robin.murphy@arm.com>
> ---
>  drivers/media/platform/ti/omap3isp/isp.c | 7 +++++++
>  1 file changed, 7 insertions(+)
> 
> diff --git a/drivers/media/platform/ti/omap3isp/isp.c b/drivers/media/platform/ti/omap3isp/isp.c
> index 91101ba88ef0..b2210841a320 100644
> --- a/drivers/media/platform/ti/omap3isp/isp.c
> +++ b/drivers/media/platform/ti/omap3isp/isp.c
> @@ -1961,6 +1961,13 @@ static int isp_attach_iommu(struct isp_device *isp)
>  	struct dma_iommu_mapping *mapping;
>  	int ret;
>  
> +	/* We always want to replace any default mapping from the arch code */
> +	mapping = to_dma_iommu_mapping(isp->dev);
> +	if (mapping) {
> +		arm_iommu_detach_device(isp->dev);
> +		arm_iommu_release_mapping(mapping);
> +	}
> +
>  	/*
>  	 * Create the ARM mapping, used by the ARM DMA mapping core to allocate
>  	 * VAs. This will allocate a corresponding IOMMU domain.
> -- 
> 2.39.2.101.g768bb238c484.dirty
> 

I have finally found time to test this patch on the Nokia N900 and can
confirm it is working fine.

I was wondering - is there a reason that it is not merged yet? I tested
on 6.14-rc2, which did not have it, and notice it is also not in
linux-next.

If it helps:

Tested-by: Sicelo A. Mhlongo <absicsz@gmail.com>

Re: [PATCH 2/4] media: omap3isp: Handle ARM dma_iommu_mapping

[Laurent Pinchart]

CC'ing Sakari.

Sakari, would you pick this patch ?

On Sat, Feb 15, 2025 at 08:57:24AM +0200, Sicelo wrote:
> On Mon, Oct 28, 2024 at 05:58:36PM +0000, Robin Murphy wrote:
> > It's no longer practical for the OMAP IOMMU driver to trick
> > arm_setup_iommu_dma_ops() into ignoring its presence, so let's use the
> > same tactic as other IOMMU API users on 32-bit ARM and explicitly kick
> > the arch code's dma_iommu_mapping out of the way to avoid problems.
> > 
> > Fixes: 4720287c7bf7 ("iommu: Remove struct iommu_ops *iommu from arch_setup_dma_ops()")
> > Signed-off-by: Robin Murphy <robin.murphy@arm.com>
> > ---
> >  drivers/media/platform/ti/omap3isp/isp.c | 7 +++++++
> >  1 file changed, 7 insertions(+)
> > 
> > diff --git a/drivers/media/platform/ti/omap3isp/isp.c b/drivers/media/platform/ti/omap3isp/isp.c
> > index 91101ba88ef0..b2210841a320 100644
> > --- a/drivers/media/platform/ti/omap3isp/isp.c
> > +++ b/drivers/media/platform/ti/omap3isp/isp.c
> > @@ -1961,6 +1961,13 @@ static int isp_attach_iommu(struct isp_device *isp)
> >  	struct dma_iommu_mapping *mapping;
> >  	int ret;
> >  
> > +	/* We always want to replace any default mapping from the arch code */
> > +	mapping = to_dma_iommu_mapping(isp->dev);
> > +	if (mapping) {
> > +		arm_iommu_detach_device(isp->dev);
> > +		arm_iommu_release_mapping(mapping);
> > +	}
> > +
> >  	/*
> >  	 * Create the ARM mapping, used by the ARM DMA mapping core to allocate
> >  	 * VAs. This will allocate a corresponding IOMMU domain.
> > -- 
> > 2.39.2.101.g768bb238c484.dirty
> > 
> 
> I have finally found time to test this patch on the Nokia N900 and can
> confirm it is working fine.
> 
> I was wondering - is there a reason that it is not merged yet? I tested
> on 6.14-rc2, which did not have it, and notice it is also not in
> linux-next.
> 
> If it helps:
> 
> Tested-by: Sicelo A. Mhlongo <absicsz@gmail.com>

-- 
Regards,

Laurent Pinchart

Re: [PATCH 2/4] media: omap3isp: Handle ARM dma_iommu_mapping

[Sakari Ailus]

Hi Laurent, others,

On Sat, Feb 15, 2025 at 09:43:28PM +0200, Laurent Pinchart wrote:
> CC'ing Sakari.
> 
> Sakari, would you pick this patch ?

Thanks! I wonder what happened -- it wasn't visible in Linuxtv.org
Patchwork but could be found via the message id.

It's in my tree now.

> 
> On Sat, Feb 15, 2025 at 08:57:24AM +0200, Sicelo wrote:
> > On Mon, Oct 28, 2024 at 05:58:36PM +0000, Robin Murphy wrote:
> > > It's no longer practical for the OMAP IOMMU driver to trick
> > > arm_setup_iommu_dma_ops() into ignoring its presence, so let's use the
> > > same tactic as other IOMMU API users on 32-bit ARM and explicitly kick
> > > the arch code's dma_iommu_mapping out of the way to avoid problems.
> > > 
> > > Fixes: 4720287c7bf7 ("iommu: Remove struct iommu_ops *iommu from arch_setup_dma_ops()")
> > > Signed-off-by: Robin Murphy <robin.murphy@arm.com>
> > > ---
> > >  drivers/media/platform/ti/omap3isp/isp.c | 7 +++++++
> > >  1 file changed, 7 insertions(+)
> > > 
> > > diff --git a/drivers/media/platform/ti/omap3isp/isp.c b/drivers/media/platform/ti/omap3isp/isp.c
> > > index 91101ba88ef0..b2210841a320 100644
> > > --- a/drivers/media/platform/ti/omap3isp/isp.c
> > > +++ b/drivers/media/platform/ti/omap3isp/isp.c
> > > @@ -1961,6 +1961,13 @@ static int isp_attach_iommu(struct isp_device *isp)
> > >  	struct dma_iommu_mapping *mapping;
> > >  	int ret;
> > >  
> > > +	/* We always want to replace any default mapping from the arch code */
> > > +	mapping = to_dma_iommu_mapping(isp->dev);
> > > +	if (mapping) {
> > > +		arm_iommu_detach_device(isp->dev);
> > > +		arm_iommu_release_mapping(mapping);
> > > +	}
> > > +
> > >  	/*
> > >  	 * Create the ARM mapping, used by the ARM DMA mapping core to allocate
> > >  	 * VAs. This will allocate a corresponding IOMMU domain.
> > > -- 
> > > 2.39.2.101.g768bb238c484.dirty
> > > 
> > 
> > I have finally found time to test this patch on the Nokia N900 and can
> > confirm it is working fine.
> > 
> > I was wondering - is there a reason that it is not merged yet? I tested
> > on 6.14-rc2, which did not have it, and notice it is also not in
> > linux-next.
> > 
> > If it helps:
> > 
> > Tested-by: Sicelo A. Mhlongo <absicsz@gmail.com>
> 

-- 
Regards,

Sakari Ailus

[PATCH 3/4] iommu/omap: Add minimal fwnode support

[Robin Murphy]

The OMAP driver uses the generic "iommus" DT binding but is the final
holdout not implementing a corresponding .of_xlate method. Unfortunately
this now results in __iommu_probe_device() failing to find ops due to
client devices missing the expected IOMMU fwnode association. The legacy
DT parsing in omap_iommu_probe_device() could probably all be delegated
to generic code now, but for the sake of an immediate fix, just add a
minimal .of_xlate implementation to allow client fwspecs to be created
appropriately, and so the ops lookup to work again.

This means we also need to register the additional instances on DRA7 so
that of_iommu_xlate() doesn't defer indefinitely waiting for their ops
either, but we'll continue to hide them from sysfs just in case. This
also renders the bus_iommu_probe() call entirely redundant.

Reported-by: Beleswar Padhi <b-padhi@ti.com>
Link: https://lore.kernel.org/linux-iommu/0dbde87b-593f-4b14-8929-b78e189549ad@ti.com/
Reported-by: H. Nikolaus Schaller <hns@goldelico.com>
Link: https://lore.kernel.org/linux-media/A7C284A9-33A5-4E21-9B57-9C4C213CC13F@goldelico.com/
Fixes: 17de3f5fdd35 ("iommu: Retire bus ops")
Signed-off-by: Robin Murphy <robin.murphy@arm.com>
---
 drivers/iommu/omap-iommu.c | 26 ++++++++++++++++----------
 1 file changed, 16 insertions(+), 10 deletions(-)

diff --git a/drivers/iommu/omap-iommu.c b/drivers/iommu/omap-iommu.c
index c9528065a59a..3f72aef8bd5b 100644
--- a/drivers/iommu/omap-iommu.c
+++ b/drivers/iommu/omap-iommu.c
@@ -1230,25 +1230,24 @@ static int omap_iommu_probe(struct platform_device *pdev)
 		if (err)
 			return err;
 
-		err = iommu_device_register(&obj->iommu, &omap_iommu_ops, &pdev->dev);
-		if (err)
-			goto out_sysfs;
 		obj->has_iommu_driver = true;
 	}
 
+	err = iommu_device_register(&obj->iommu, &omap_iommu_ops, &pdev->dev);
+	if (err)
+		goto out_sysfs;
+
 	pm_runtime_enable(obj->dev);
 
 	omap_iommu_debugfs_add(obj);
 
 	dev_info(&pdev->dev, "%s registered\n", obj->name);
 
-	/* Re-probe bus to probe device attached to this IOMMU */
-	bus_iommu_probe(&platform_bus_type);
-
 	return 0;
 
 out_sysfs:
-	iommu_device_sysfs_remove(&obj->iommu);
+	if (obj->has_iommu_driver)
+		iommu_device_sysfs_remove(&obj->iommu);
 	return err;
 }
 
@@ -1256,10 +1255,10 @@ static void omap_iommu_remove(struct platform_device *pdev)
 {
 	struct omap_iommu *obj = platform_get_drvdata(pdev);
 
-	if (obj->has_iommu_driver) {
+	if (obj->has_iommu_driver)
 		iommu_device_sysfs_remove(&obj->iommu);
-		iommu_device_unregister(&obj->iommu);
-	}
+
+	iommu_device_unregister(&obj->iommu);
 
 	omap_iommu_debugfs_remove(obj);
 
@@ -1723,12 +1722,19 @@ static void omap_iommu_release_device(struct device *dev)
 
 }
 
+static int omap_iommu_of_xlate(struct device *dev, const struct of_phandle_args *args)
+{
+	/* TODO: collect args->np to save re-parsing in probe above */
+	return 0;
+}
+
 static const struct iommu_ops omap_iommu_ops = {
 	.identity_domain = &omap_iommu_identity_domain,
 	.domain_alloc_paging = omap_iommu_domain_alloc_paging,
 	.probe_device	= omap_iommu_probe_device,
 	.release_device	= omap_iommu_release_device,
 	.device_group	= generic_single_device_group,
+	.of_xlate	= omap_iommu_of_xlate,
 	.pgsize_bitmap	= OMAP_IOMMU_PGSIZES,
 	.default_domain_ops = &(const struct iommu_domain_ops) {
 		.attach_dev	= omap_iommu_attach_dev,
-- 
2.39.2.101.g768bb238c484.dirty

[PATCH 4/4] iommu: Make bus_iommu_probe() static

[Robin Murphy]

With the last external caller of bus_iommu_probe() now gone, make it
internal as it really should be.

Signed-off-by: Robin Murphy <robin.murphy@arm.com>
---
 drivers/iommu/iommu.c | 3 ++-
 include/linux/iommu.h | 1 -
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
index 83c8e617a2c5..35291b02aab1 100644
--- a/drivers/iommu/iommu.c
+++ b/drivers/iommu/iommu.c
@@ -90,6 +90,7 @@ static const char * const iommu_group_resv_type_string[] = {
 #define IOMMU_CMD_LINE_DMA_API		BIT(0)
 #define IOMMU_CMD_LINE_STRICT		BIT(1)
 
+static int bus_iommu_probe(const struct bus_type *bus);
 static int iommu_bus_notifier(struct notifier_block *nb,
 			      unsigned long action, void *data);
 static void iommu_release_device(struct device *dev);
@@ -1795,7 +1796,7 @@ static void iommu_group_do_probe_finalize(struct device *dev)
 		ops->probe_finalize(dev);
 }
 
-int bus_iommu_probe(const struct bus_type *bus)
+static int bus_iommu_probe(const struct bus_type *bus)
 {
 	struct iommu_group *group, *next;
 	LIST_HEAD(group_list);
diff --git a/include/linux/iommu.h b/include/linux/iommu.h
index bd722f473635..84a6ed5e803a 100644
--- a/include/linux/iommu.h
+++ b/include/linux/iommu.h
@@ -784,7 +784,6 @@ static inline void iommu_iotlb_gather_init(struct iommu_iotlb_gather *gather)
 	};
 }
 
-extern int bus_iommu_probe(const struct bus_type *bus);
 extern bool iommu_present(const struct bus_type *bus);
 extern bool device_iommu_capable(struct device *dev, enum iommu_cap cap);
 extern bool iommu_group_has_isolated_msi(struct iommu_group *group);
-- 
2.39.2.101.g768bb238c484.dirty

Re: [PATCH 0/4] Fix omap-iommu bitrot

[H. Nikolaus Schaller]

Hi Robin,

> Am 28.10.2024 um 18:58 schrieb Robin Murphy <robin.murphy@arm.com>:
> 
> Hi all,
> 
> It seems omap-iommu hasn't had enough mainline users to avoid bitrotting
> through the more recent evolution of the IOMMU API internals. These
> patches attempt to bring it and its consumers sufficiently up-to-date
> to work again, in a manner that's hopefully backportable. This is
> largely all written by inspection, but I have managed to lightly boot
> test patch #3 on an OMAP4 Pandaboard to confirm iommu_probe_device()
> working again.
> 
> This supersedes my previous patch[1]. Patches #1 and #2 are functionally
> independent, and can be applied directly to their respective trees if
> preferred.

I can confirm that this series works on omap3 with v6.12-rc5 and
Camera is back to the GTA04.

So you can add:
Tested-by: H. Nikolaus Schaller <hns@goldelico.com>

BR and thanks,
Nikolaus

root@letux:~# dmesg|fgrep iommu
[    0.522613] iommu: Default domain type: Translated
[    0.522644] iommu: DMA domain TLB invalidation policy: strict mode
[    0.525177] omap-iommu 480bd400.mmu: 480bd400.mmu registered
[   10.752563] omap3isp 480bc000.isp: Adding to iommu group 0
[   10.811218] omap-iommu 480bd400.mmu: 480bd400.mmu: version 1.1
[   11.039489] omap-iommu 480bd400.mmu: 480bd400.mmu: version 1.1
root@letux:~# dmesg|fgrep .isp
[   10.752563] omap3isp 480bc000.isp: Adding to iommu group 0
[   10.841522] omap3isp 480bc000.isp: supply vdd-csiphy1 not found, using dummy regulator
[   10.948577] omap3isp 480bc000.isp: supply vdd-csiphy2 not found, using dummy regulator
[   10.990814] omap3isp 480bc000.isp: Revision 15.0 found
[   11.089324] omap3isp 480bc000.isp: hist: using DMA channel dma0chan15
[   11.115905] omap3isp 480bc000.isp: Entity type for entity OMAP3 ISP CCP2 was not initialized!
[   11.168792] omap3isp 480bc000.isp: isp_xclk_set_rate: cam_xclka set to 24685714 Hz (div 7)
[   11.220062] omap3isp 480bc000.isp: Entity type for entity OMAP3 ISP CSI2a was not initialized!
[   11.291748] omap3isp 480bc000.isp: Entity type for entity OMAP3 ISP CCDC was not initialized!
[   11.362152] omap3isp 480bc000.isp: Entity type for entity OMAP3 ISP preview was not initialized!
[   11.404266] omap3isp 480bc000.isp: Entity type for entity OMAP3 ISP resizer was not initialized!
[   11.485687] omap3isp 480bc000.isp: Entity type for entity OMAP3 ISP AEWB was not initialized!
[   11.520874] omap3isp 480bc000.isp: Entity type for entity OMAP3 ISP AF was not initialized!
[   11.574981] omap3isp 480bc000.isp: Entity type for entity OMAP3 ISP histogram was not initialized!
[   11.594268] omap3isp 480bc000.isp: parsing parallel interface
[  106.102905] omap3isp 480bc000.isp: -------------CCDC Register dump-------------
[  106.110595] omap3isp 480bc000.isp: ###CCDC PCR=0x00000000
[  106.116973] omap3isp 480bc000.isp: ###CCDC SYN_MODE=0x00031704
[  106.123657] omap3isp 480bc000.isp: ###CCDC HD_VD_WID=0x00000000
[  106.129974] omap3isp 480bc000.isp: ###CCDC PIX_LINES=0x00000000
[  106.136810] omap3isp 480bc000.isp: ###CCDC HORZ_INFO=0x000004ff
[  106.143615] omap3isp 480bc000.isp: ###CCDC VERT_START=0x00000000
[  106.149932] omap3isp 480bc000.isp: ###CCDC VERT_LINES=0x000003ff
[  106.156799] omap3isp 480bc000.isp: ###CCDC CULLING=0xffff00ff
[  106.163299] omap3isp 480bc000.isp: ###CCDC HSIZE_OFF=0x00000a00
[  106.169616] omap3isp 480bc000.isp: ###CCDC SDOFST=0x00000000
[  106.176086] omap3isp 480bc000.isp: ###CCDC SDR_ADDR=0x40000000
[  106.182708] omap3isp 480bc000.isp: ###CCDC CLAMP=0x00000010
[  106.188598] omap3isp 480bc000.isp: ###CCDC DCSUB=0x00000000
[  106.195068] omap3isp 480bc000.isp: ###CCDC COLPTN=0xbb11bb11
[  106.201507] omap3isp 480bc000.isp: ###CCDC BLKCMP=0x00000000
[  106.207550] omap3isp 480bc000.isp: ###CCDC FPC=0x00000000
[  106.213684] omap3isp 480bc000.isp: ###CCDC FPC_ADDR=0x00000000
[  106.219909] omap3isp 480bc000.isp: ###CCDC VDINT=0x03fe02aa
[  106.226409] omap3isp 480bc000.isp: ###CCDC ALAW=0x00000006
[  106.232696] omap3isp 480bc000.isp: ###CCDC REC656IF=0x00000000
[  106.238830] omap3isp 480bc000.isp: ###CCDC CFG=0x00008800
[  106.244964] omap3isp 480bc000.isp: ###CCDC FMTCFG=0x00000000
[  106.251434] omap3isp 480bc000.isp: ###CCDC FMT_HORZ=0x00000000
[  106.257568] omap3isp 480bc000.isp: ###CCDC FMT_VERT=0x00000000
[  106.264251] omap3isp 480bc000.isp: ###CCDC PRGEVEN0=0x00000000
[  106.271606] omap3isp 480bc000.isp: ###CCDC PRGEVEN1=0x00000000
[  106.285400] omap3isp 480bc000.isp: ###CCDC PRGODD0=0x00000000
[  106.301147] omap3isp 480bc000.isp: ###CCDC PRGODD1=0x00000000
[  106.307220] omap3isp 480bc000.isp: ###CCDC VP_OUT=0x00000000
[  106.326019] omap3isp 480bc000.isp: ###CCDC LSC_CONFIG=0x00006600
[  106.340087] omap3isp 480bc000.isp: ###CCDC LSC_INITIAL=0x00000000
[  106.358001] omap3isp 480bc000.isp: ###CCDC LSC_TABLE_BASE=0x00000000
[  106.372985] omap3isp 480bc000.isp: ###CCDC LSC_TABLE_OFFSET=0x00000000
[  106.379882] omap3isp 480bc000.isp: --------------------------------------------
[  118.617980] omap3isp 480bc000.isp: OMAP3 ISP AEWB: user wants to disable module.
[  118.626068] omap3isp 480bc000.isp: OMAP3 ISP AEWB: module is being disabled
[  118.633392] omap3isp 480bc000.isp: OMAP3 ISP AF: user wants to disable module.
[  118.641937] omap3isp 480bc000.isp: OMAP3 ISP AF: module is being disabled
[  118.649627] omap3isp 480bc000.isp: OMAP3 ISP histogram: user wants to disable module.
[  118.658508] omap3isp 480bc000.isp: OMAP3 ISP histogram: module is being disabled
root@letux:~# 

Re: [PATCH 0/4] Fix omap-iommu bitrot

[Mathieu Poirier]

On Mon, 28 Oct 2024 at 14:46, H. Nikolaus Schaller <hns@goldelico.com> wrote:
>
> Hi Robin,
>
> > Am 28.10.2024 um 18:58 schrieb Robin Murphy <robin.murphy@arm.com>:
> >
> > Hi all,
> >
> > It seems omap-iommu hasn't had enough mainline users to avoid bitrotting
> > through the more recent evolution of the IOMMU API internals. These
> > patches attempt to bring it and its consumers sufficiently up-to-date
> > to work again, in a manner that's hopefully backportable. This is
> > largely all written by inspection, but I have managed to lightly boot
> > test patch #3 on an OMAP4 Pandaboard to confirm iommu_probe_device()
> > working again.
> >
> > This supersedes my previous patch[1]. Patches #1 and #2 are functionally
> > independent, and can be applied directly to their respective trees if
> > preferred.
>
> I can confirm that this series works on omap3 with v6.12-rc5 and
> Camera is back to the GTA04.
>
> So you can add:
> Tested-by: H. Nikolaus Schaller <hns@goldelico.com>
>

Many thanks for taking the time to test this, it is really appreciated.

> BR and thanks,
> Nikolaus
>
> root@letux:~# dmesg|fgrep iommu
> [    0.522613] iommu: Default domain type: Translated
> [    0.522644] iommu: DMA domain TLB invalidation policy: strict mode
> [    0.525177] omap-iommu 480bd400.mmu: 480bd400.mmu registered
> [   10.752563] omap3isp 480bc000.isp: Adding to iommu group 0
> [   10.811218] omap-iommu 480bd400.mmu: 480bd400.mmu: version 1.1
> [   11.039489] omap-iommu 480bd400.mmu: 480bd400.mmu: version 1.1
> root@letux:~# dmesg|fgrep .isp
> [   10.752563] omap3isp 480bc000.isp: Adding to iommu group 0
> [   10.841522] omap3isp 480bc000.isp: supply vdd-csiphy1 not found, using dummy regulator
> [   10.948577] omap3isp 480bc000.isp: supply vdd-csiphy2 not found, using dummy regulator
> [   10.990814] omap3isp 480bc000.isp: Revision 15.0 found
> [   11.089324] omap3isp 480bc000.isp: hist: using DMA channel dma0chan15
> [   11.115905] omap3isp 480bc000.isp: Entity type for entity OMAP3 ISP CCP2 was not initialized!
> [   11.168792] omap3isp 480bc000.isp: isp_xclk_set_rate: cam_xclka set to 24685714 Hz (div 7)
> [   11.220062] omap3isp 480bc000.isp: Entity type for entity OMAP3 ISP CSI2a was not initialized!
> [   11.291748] omap3isp 480bc000.isp: Entity type for entity OMAP3 ISP CCDC was not initialized!
> [   11.362152] omap3isp 480bc000.isp: Entity type for entity OMAP3 ISP preview was not initialized!
> [   11.404266] omap3isp 480bc000.isp: Entity type for entity OMAP3 ISP resizer was not initialized!
> [   11.485687] omap3isp 480bc000.isp: Entity type for entity OMAP3 ISP AEWB was not initialized!
> [   11.520874] omap3isp 480bc000.isp: Entity type for entity OMAP3 ISP AF was not initialized!
> [   11.574981] omap3isp 480bc000.isp: Entity type for entity OMAP3 ISP histogram was not initialized!
> [   11.594268] omap3isp 480bc000.isp: parsing parallel interface
> [  106.102905] omap3isp 480bc000.isp: -------------CCDC Register dump-------------
> [  106.110595] omap3isp 480bc000.isp: ###CCDC PCR=0x00000000
> [  106.116973] omap3isp 480bc000.isp: ###CCDC SYN_MODE=0x00031704
> [  106.123657] omap3isp 480bc000.isp: ###CCDC HD_VD_WID=0x00000000
> [  106.129974] omap3isp 480bc000.isp: ###CCDC PIX_LINES=0x00000000
> [  106.136810] omap3isp 480bc000.isp: ###CCDC HORZ_INFO=0x000004ff
> [  106.143615] omap3isp 480bc000.isp: ###CCDC VERT_START=0x00000000
> [  106.149932] omap3isp 480bc000.isp: ###CCDC VERT_LINES=0x000003ff
> [  106.156799] omap3isp 480bc000.isp: ###CCDC CULLING=0xffff00ff
> [  106.163299] omap3isp 480bc000.isp: ###CCDC HSIZE_OFF=0x00000a00
> [  106.169616] omap3isp 480bc000.isp: ###CCDC SDOFST=0x00000000
> [  106.176086] omap3isp 480bc000.isp: ###CCDC SDR_ADDR=0x40000000
> [  106.182708] omap3isp 480bc000.isp: ###CCDC CLAMP=0x00000010
> [  106.188598] omap3isp 480bc000.isp: ###CCDC DCSUB=0x00000000
> [  106.195068] omap3isp 480bc000.isp: ###CCDC COLPTN=0xbb11bb11
> [  106.201507] omap3isp 480bc000.isp: ###CCDC BLKCMP=0x00000000
> [  106.207550] omap3isp 480bc000.isp: ###CCDC FPC=0x00000000
> [  106.213684] omap3isp 480bc000.isp: ###CCDC FPC_ADDR=0x00000000
> [  106.219909] omap3isp 480bc000.isp: ###CCDC VDINT=0x03fe02aa
> [  106.226409] omap3isp 480bc000.isp: ###CCDC ALAW=0x00000006
> [  106.232696] omap3isp 480bc000.isp: ###CCDC REC656IF=0x00000000
> [  106.238830] omap3isp 480bc000.isp: ###CCDC CFG=0x00008800
> [  106.244964] omap3isp 480bc000.isp: ###CCDC FMTCFG=0x00000000
> [  106.251434] omap3isp 480bc000.isp: ###CCDC FMT_HORZ=0x00000000
> [  106.257568] omap3isp 480bc000.isp: ###CCDC FMT_VERT=0x00000000
> [  106.264251] omap3isp 480bc000.isp: ###CCDC PRGEVEN0=0x00000000
> [  106.271606] omap3isp 480bc000.isp: ###CCDC PRGEVEN1=0x00000000
> [  106.285400] omap3isp 480bc000.isp: ###CCDC PRGODD0=0x00000000
> [  106.301147] omap3isp 480bc000.isp: ###CCDC PRGODD1=0x00000000
> [  106.307220] omap3isp 480bc000.isp: ###CCDC VP_OUT=0x00000000
> [  106.326019] omap3isp 480bc000.isp: ###CCDC LSC_CONFIG=0x00006600
> [  106.340087] omap3isp 480bc000.isp: ###CCDC LSC_INITIAL=0x00000000
> [  106.358001] omap3isp 480bc000.isp: ###CCDC LSC_TABLE_BASE=0x00000000
> [  106.372985] omap3isp 480bc000.isp: ###CCDC LSC_TABLE_OFFSET=0x00000000
> [  106.379882] omap3isp 480bc000.isp: --------------------------------------------
> [  118.617980] omap3isp 480bc000.isp: OMAP3 ISP AEWB: user wants to disable module.
> [  118.626068] omap3isp 480bc000.isp: OMAP3 ISP AEWB: module is being disabled
> [  118.633392] omap3isp 480bc000.isp: OMAP3 ISP AF: user wants to disable module.
> [  118.641937] omap3isp 480bc000.isp: OMAP3 ISP AF: module is being disabled
> [  118.649627] omap3isp 480bc000.isp: OMAP3 ISP histogram: user wants to disable module.
> [  118.658508] omap3isp 480bc000.isp: OMAP3 ISP histogram: module is being disabled
> root@letux:~#
>
>
>

Re: [PATCH 0/4] Fix omap-iommu bitrot

[Kevin Hilman]

Robin Murphy <robin.murphy@arm.com> writes:

> It seems omap-iommu hasn't had enough mainline users to avoid bitrotting
> through the more recent evolution of the IOMMU API internals. These
> patches attempt to bring it and its consumers sufficiently up-to-date
> to work again, in a manner that's hopefully backportable. This is
> largely all written by inspection, but I have managed to lightly boot
> test patch #3 on an OMAP4 Pandaboard to confirm iommu_probe_device()
> working again.
>
> This supersedes my previous patch[1]. Patches #1 and #2 are functionally
> independent, and can be applied directly to their respective trees if
> preferred.

Reviewed-by: Kevin Hilman <khilman@baylibre.com>
Tested-by: Kevin Hilman <khilman@baylibre.com>

I tested this on am57xx-beagle-x15 where before this series, I was
seeing various remoteproc drivers fail with

       remoteproc remoteproc0: can't enable iommu: -12

and now with this the remoteproc drivers are successfully loading again.

Thanks Robin for working on bringing this back into modern times!

Kevin

Re: [PATCH 0/4] Fix omap-iommu bitrot

[Beleswar Prasad Padhi]

Hi Robin,

On 28/10/24 23:28, Robin Murphy wrote:
> Hi all,
>
> It seems omap-iommu hasn't had enough mainline users to avoid bitrotting
> through the more recent evolution of the IOMMU API internals. These
> patches attempt to bring it and its consumers sufficiently up-to-date
> to work again, in a manner that's hopefully backportable. This is
> largely all written by inspection, but I have managed to lightly boot
> test patch #3 on an OMAP4 Pandaboard to confirm iommu_probe_device()
> working again.
>
> This supersedes my previous patch[1]. Patches #1 and #2 are functionally
> independent, and can be applied directly to their respective trees if
> preferred.
>
> Thanks,
> Robin.
>
> [1] https://lore.kernel.org/linux-iommu/c44545c6d07c65d89daa297298c27bb0f15c8b84.1728393458.git.robin.murphy@arm.com/
>
>
> Robin Murphy (4):
>    remoteproc/omap: Handle ARM dma_iommu_mapping
>    media: omap3isp: Handle ARM dma_iommu_mapping
>    iommu/omap: Add minimal fwnode support
>    iommu: Make bus_iommu_probe() static


Tested this series on omap4 w.r.t. remoteproc subsystem on v6.12-rc5, it 
works fine; attached logs[2]. Therefore, for series please use:

Tested-by: Beleswar Padhi <b-padhi@ti.com>

Many thanks for working on the fix.

Best,
Beleswar

[2]: https://gist.github.com/3V3RYONE/f9244a0aa0e3514b7c62f7965cbb0bae

>
>   drivers/iommu/iommu.c                    |  3 ++-
>   drivers/iommu/omap-iommu.c               | 26 +++++++++++++++---------
>   drivers/media/platform/ti/omap3isp/isp.c |  7 +++++++
>   drivers/remoteproc/omap_remoteproc.c     | 17 ++++++++++++++++
>   include/linux/iommu.h                    |  1 -
>   5 files changed, 42 insertions(+), 12 deletions(-)
>

Re: [PATCH 0/4] Fix omap-iommu bitrot

[Joerg Roedel]

On Mon, Oct 28, 2024 at 05:58:34PM +0000, Robin Murphy wrote:
> It seems omap-iommu hasn't had enough mainline users to avoid bitrotting
> through the more recent evolution of the IOMMU API internals. These
> patches attempt to bring it and its consumers sufficiently up-to-date
> to work again, in a manner that's hopefully backportable. This is
> largely all written by inspection, but I have managed to lightly boot
> test patch #3 on an OMAP4 Pandaboard to confirm iommu_probe_device()
> working again.

My initial reflex would have been to just wipe the omap drivers,
hardware is 10+ years out of production, no? So who is still using this
hardware with recent kernels for other purposes than kernel testing?

> This supersedes my previous patch[1]. Patches #1 and #2 are functionally
> independent, and can be applied directly to their respective trees if
> preferred.

I applied patches 3 and 4 to the ti/omap branch.

Regards,

	Joerg

Re: [PATCH 0/4] Fix omap-iommu bitrot

[H. Nikolaus Schaller]

> Am 30.10.2024 um 10:55 schrieb Joerg Roedel <joro@8bytes.org>:
> 
> On Mon, Oct 28, 2024 at 05:58:34PM +0000, Robin Murphy wrote:
>> It seems omap-iommu hasn't had enough mainline users to avoid bitrotting
>> through the more recent evolution of the IOMMU API internals. These
>> patches attempt to bring it and its consumers sufficiently up-to-date
>> to work again, in a manner that's hopefully backportable. This is
>> largely all written by inspection, but I have managed to lightly boot
>> test patch #3 on an OMAP4 Pandaboard to confirm iommu_probe_device()
>> working again.
> 
> My initial reflex would have been to just wipe the omap drivers,

Why that? There was a discussion and everyone agreed to remove omap2,
but not omap3 and later.

> hardware is 10+ years out of production, no? So who is still using this
> hardware with recent kernels for other purposes than kernel testing?

There are some devices besides the PandaBoard. I am aware of these where
this is relevant: Epson BT200, Samsung Galaxy Tab 2, Pyra Handheld
(in production) and we are currently thinking about producing a tiny series
of the DM3730 based GTA04A5 with spare parts.

And of course we want to participate from the latest and greatest upstream changes.

> 
>> This supersedes my previous patch[1]. Patches #1 and #2 are functionally
>> independent, and can be applied directly to their respective trees if
>> preferred.
> 
> I applied patches 3 and 4 to the ti/omap branch.

Thanks,
Nikolaus

Re: [PATCH 0/4] Fix omap-iommu bitrot

[Joerg Roedel]

On Wed, Oct 30, 2024 at 12:20:31PM +0100, H. Nikolaus Schaller wrote:
> Why that? There was a discussion and everyone agreed to remove omap2,
> but not omap3 and later.

I raised this question to make sure the things we maintain are still
relevant. Developer and maintainers time is limited and we should not
spend it on stuff that nobody uses.

> There are some devices besides the PandaBoard. I am aware of these where
> this is relevant: Epson BT200, Samsung Galaxy Tab 2, Pyra Handheld
> (in production) and we are currently thinking about producing a tiny series
> of the DM3730 based GTA04A5 with spare parts.
> 
> And of course we want to participate from the latest and greatest upstream changes.

Okay, if there are still real users for latest mainline kernels on this
hardware, then the effort is justified.

Regards,

	Joerg

Re: [PATCH 0/4] Fix omap-iommu bitrot

[Sicelo]

Hi

On Wed, Oct 30, 2024 at 01:38:11PM +0100, Joerg Roedel wrote:
> On Wed, Oct 30, 2024 at 12:20:31PM +0100, H. Nikolaus Schaller wrote:
> > Why that? There was a discussion and everyone agreed to remove omap2,
> > but not omap3 and later.
> 
> I raised this question to make sure the things we maintain are still
> relevant. Developer and maintainers time is limited and we should not
> spend it on stuff that nobody uses.
> 
> > There are some devices besides the PandaBoard. I am aware of these where
> > this is relevant: Epson BT200, Samsung Galaxy Tab 2, Pyra Handheld
> > (in production) and we are currently thinking about producing a tiny series
> > of the DM3730 based GTA04A5 with spare parts.
> > 
> > And of course we want to participate from the latest and greatest upstream changes.
> 
> Okay, if there are still real users for latest mainline kernels on this
> hardware, then the effort is justified.
> 
> Regards,
> 
> 	Joerg

There is also the Nokia N900 phone (OMAP3) still seeing mainline
activity, as well as the Motorola Droid 4 (OMAP4), to name a few. I will
also be testing on the N900 around the weekend.

Thanks to everyone for the amazing work.

Sincerely
Sicelo

Re: [PATCH 0/4] Fix omap-iommu bitrot

[Adam Ford]

On Wed, Oct 30, 2024 at 8:28 AM Sicelo <absicsz@gmail.com> wrote:
>
> Hi
>
> On Wed, Oct 30, 2024 at 01:38:11PM +0100, Joerg Roedel wrote:
> > On Wed, Oct 30, 2024 at 12:20:31PM +0100, H. Nikolaus Schaller wrote:
> > > Why that? There was a discussion and everyone agreed to remove omap2,
> > > but not omap3 and later.
> >
> > I raised this question to make sure the things we maintain are still
> > relevant. Developer and maintainers time is limited and we should not
> > spend it on stuff that nobody uses.
> >
> > > There are some devices besides the PandaBoard. I am aware of these where
> > > this is relevant: Epson BT200, Samsung Galaxy Tab 2, Pyra Handheld
> > > (in production) and we are currently thinking about producing a tiny series
> > > of the DM3730 based GTA04A5 with spare parts.
> > >
> > > And of course we want to participate from the latest and greatest upstream changes.
> >
> > Okay, if there are still real users for latest mainline kernels on this
> > hardware, then the effort is justified.
> >
> > Regards,
> >
> >       Joerg
>
> There is also the Nokia N900 phone (OMAP3) still seeing mainline
> activity, as well as the Motorola Droid 4 (OMAP4), to name a few. I will
> also be testing on the N900 around the weekend.

The Beacon Embedded / LogicPD Torpedo and SOM-LV families (OMA35 and
DM37) are still being sold and I still run various tests on them
periodically. There is also an AM3517 that I still periodically test.

Once Micron kills off the RAM and they run out of supply and Beacon
cannot sell them anymore, I'll submit a patch to remove the
unsupported / EOL boards.

>
> Thanks to everyone for the amazing work.

Thank you for all this.  I haven't been as active lately, but I have
been following this.

adam
>
> Sincerely
> Sicelo
>