| Message ID | cover.1730136799.git.robin.murphy@arm.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | Fix omap-iommu bitrot | expand |
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:~#
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:~# > > >
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
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(-) >
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
> 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
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
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
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 >