From: Sakari Ailus <sakari.ailus@iki.fi>
To: Robin Murphy <robin.murphy@arm.com>
Cc: hch@lst.de, joro@8bytes.org, linux@armlinux.org.uk,
will@kernel.org, inki.dae@samsung.com, sw0312.kim@samsung.com,
kyungmin.park@samsung.com, m.szyprowski@samsung.com,
agross@kernel.org, bjorn.andersson@linaro.org,
thierry.reding@gmail.com, jonathanh@nvidia.com,
vdumpa@nvidia.com, digetx@gmail.com, matthias.bgg@gmail.com,
yong.wu@mediatek.com, geert+renesas@glider.be,
magnus.damm@gmail.com, t-kristo@ti.com, s-anna@ti.com,
laurent.pinchart@ideasonboard.com,
linux-arm-kernel@lists.infradead.org,
iommu@lists.linux-foundation.org,
linux-samsung-soc@vger.kernel.org, linux-tegra@vger.kernel.org,
linux-arm-msm@vger.kernel.org,
linux-mediatek@lists.infradead.org,
dri-devel@lists.freedesktop.org, linux-media@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH 17/18] media/omap3isp: Clean up IOMMU workaround
Date: Thu, 20 Aug 2020 22:55:36 +0300 [thread overview]
Message-ID: <20200820195536.GL7145@valkosipuli.retiisi.org.uk> (raw)
In-Reply-To: <be010209-4abc-ba48-4e31-185427776a13@arm.com>
On Thu, Aug 20, 2020 at 06:25:19PM +0100, Robin Murphy wrote:
> On 2020-08-20 17:53, Sakari Ailus wrote:
> > Hi Robin,
> >
> > On Thu, Aug 20, 2020 at 04:08:36PM +0100, Robin Murphy wrote:
> > > Now that arch/arm is wired up for default domains and iommu-dma, devices
> > > behind IOMMUs will get mappings set up automatically as appropriate, so
> > > there is no need for drivers to do so manually.
> > >
> > > Signed-off-by: Robin Murphy <robin.murphy@arm.com>
> >
> > Thanks for the patch.
>
> Many thanks for testing so quickly!
>
> > I haven't looked at the details but it seems that this causes the buffer
> > memory allocation to be physically contiguous, which causes a failure to
> > allocate video buffers of entirely normal size. I guess that was not
> > intentional?
>
> Hmm, it looks like the device ends up with the wrong DMA ops, which implies
> something didn't go as expected with the earlier IOMMU setup and default
> domain creation. Chances are that either I missed some subtlety in the
> omap_iommu change, or I've fundamentally misjudged how the ISP probing works
> and it never actually goes down the of_iommu_configure() path in the first
> place. Do you get any messages from the IOMMU layer earlier on during boot?
I do get these:
[ 2.934936] iommu: Default domain type: Translated
[ 2.940917] omap-iommu 480bd400.mmu: 480bd400.mmu registered
[ 2.946899] platform 480bc000.isp: Adding to iommu group 0
--
Sakari Ailus
WARNING: multiple messages have this Message-ID (diff)
From: Sakari Ailus <sakari.ailus@iki.fi>
To: Robin Murphy <robin.murphy@arm.com>
Cc: geert+renesas@glider.be, dri-devel@lists.freedesktop.org,
linux-tegra@vger.kernel.org, thierry.reding@gmail.com,
laurent.pinchart@ideasonboard.com, digetx@gmail.com,
will@kernel.org, hch@lst.de, linux-samsung-soc@vger.kernel.org,
magnus.damm@gmail.com, linux@armlinux.org.uk,
jonathanh@nvidia.com, agross@kernel.org,
linux-media@vger.kernel.org, linux-arm-msm@vger.kernel.org,
inki.dae@samsung.com, linux-mediatek@lists.infradead.org,
matthias.bgg@gmail.com, linux-arm-kernel@lists.infradead.org,
sw0312.kim@samsung.com, iommu@lists.linux-foundation.org,
linux-kernel@vger.kernel.org, t-kristo@ti.com,
kyungmin.park@samsung.com
Subject: Re: [PATCH 17/18] media/omap3isp: Clean up IOMMU workaround
Date: Thu, 20 Aug 2020 22:55:36 +0300 [thread overview]
Message-ID: <20200820195536.GL7145@valkosipuli.retiisi.org.uk> (raw)
In-Reply-To: <be010209-4abc-ba48-4e31-185427776a13@arm.com>
On Thu, Aug 20, 2020 at 06:25:19PM +0100, Robin Murphy wrote:
> On 2020-08-20 17:53, Sakari Ailus wrote:
> > Hi Robin,
> >
> > On Thu, Aug 20, 2020 at 04:08:36PM +0100, Robin Murphy wrote:
> > > Now that arch/arm is wired up for default domains and iommu-dma, devices
> > > behind IOMMUs will get mappings set up automatically as appropriate, so
> > > there is no need for drivers to do so manually.
> > >
> > > Signed-off-by: Robin Murphy <robin.murphy@arm.com>
> >
> > Thanks for the patch.
>
> Many thanks for testing so quickly!
>
> > I haven't looked at the details but it seems that this causes the buffer
> > memory allocation to be physically contiguous, which causes a failure to
> > allocate video buffers of entirely normal size. I guess that was not
> > intentional?
>
> Hmm, it looks like the device ends up with the wrong DMA ops, which implies
> something didn't go as expected with the earlier IOMMU setup and default
> domain creation. Chances are that either I missed some subtlety in the
> omap_iommu change, or I've fundamentally misjudged how the ISP probing works
> and it never actually goes down the of_iommu_configure() path in the first
> place. Do you get any messages from the IOMMU layer earlier on during boot?
I do get these:
[ 2.934936] iommu: Default domain type: Translated
[ 2.940917] omap-iommu 480bd400.mmu: 480bd400.mmu registered
[ 2.946899] platform 480bc000.isp: Adding to iommu group 0
--
Sakari Ailus
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
WARNING: multiple messages have this Message-ID (diff)
From: Sakari Ailus <sakari.ailus@iki.fi>
To: Robin Murphy <robin.murphy@arm.com>
Cc: geert+renesas@glider.be, dri-devel@lists.freedesktop.org,
bjorn.andersson@linaro.org, linux-tegra@vger.kernel.org,
thierry.reding@gmail.com, laurent.pinchart@ideasonboard.com,
digetx@gmail.com, s-anna@ti.com, will@kernel.org, hch@lst.de,
m.szyprowski@samsung.com, linux-samsung-soc@vger.kernel.org,
joro@8bytes.org, magnus.damm@gmail.com, linux@armlinux.org.uk,
jonathanh@nvidia.com, agross@kernel.org, yong.wu@mediatek.com,
linux-media@vger.kernel.org, linux-arm-msm@vger.kernel.org,
inki.dae@samsung.com, vdumpa@nvidia.com,
linux-mediatek@lists.infradead.org, matthias.bgg@gmail.com,
linux-arm-kernel@lists.infradead.org, sw0312.kim@samsung.com,
iommu@lists.linux-foundation.org, linux-kernel@vger.kernel.org,
t-kristo@ti.com, kyungmin.park@samsung.com
Subject: Re: [PATCH 17/18] media/omap3isp: Clean up IOMMU workaround
Date: Thu, 20 Aug 2020 22:55:36 +0300 [thread overview]
Message-ID: <20200820195536.GL7145@valkosipuli.retiisi.org.uk> (raw)
In-Reply-To: <be010209-4abc-ba48-4e31-185427776a13@arm.com>
On Thu, Aug 20, 2020 at 06:25:19PM +0100, Robin Murphy wrote:
> On 2020-08-20 17:53, Sakari Ailus wrote:
> > Hi Robin,
> >
> > On Thu, Aug 20, 2020 at 04:08:36PM +0100, Robin Murphy wrote:
> > > Now that arch/arm is wired up for default domains and iommu-dma, devices
> > > behind IOMMUs will get mappings set up automatically as appropriate, so
> > > there is no need for drivers to do so manually.
> > >
> > > Signed-off-by: Robin Murphy <robin.murphy@arm.com>
> >
> > Thanks for the patch.
>
> Many thanks for testing so quickly!
>
> > I haven't looked at the details but it seems that this causes the buffer
> > memory allocation to be physically contiguous, which causes a failure to
> > allocate video buffers of entirely normal size. I guess that was not
> > intentional?
>
> Hmm, it looks like the device ends up with the wrong DMA ops, which implies
> something didn't go as expected with the earlier IOMMU setup and default
> domain creation. Chances are that either I missed some subtlety in the
> omap_iommu change, or I've fundamentally misjudged how the ISP probing works
> and it never actually goes down the of_iommu_configure() path in the first
> place. Do you get any messages from the IOMMU layer earlier on during boot?
I do get these:
[ 2.934936] iommu: Default domain type: Translated
[ 2.940917] omap-iommu 480bd400.mmu: 480bd400.mmu registered
[ 2.946899] platform 480bc000.isp: Adding to iommu group 0
--
Sakari Ailus
_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek
WARNING: multiple messages have this Message-ID (diff)
From: Sakari Ailus <sakari.ailus@iki.fi>
To: Robin Murphy <robin.murphy@arm.com>
Cc: geert+renesas@glider.be, dri-devel@lists.freedesktop.org,
bjorn.andersson@linaro.org, linux-tegra@vger.kernel.org,
thierry.reding@gmail.com, laurent.pinchart@ideasonboard.com,
digetx@gmail.com, will@kernel.org, hch@lst.de,
m.szyprowski@samsung.com, linux-samsung-soc@vger.kernel.org,
joro@8bytes.org, magnus.damm@gmail.com, linux@armlinux.org.uk,
jonathanh@nvidia.com, agross@kernel.org, yong.wu@mediatek.com,
linux-media@vger.kernel.org, linux-arm-msm@vger.kernel.org,
inki.dae@samsung.com, linux-mediatek@lists.infradead.org,
matthias.bgg@gmail.com, linux-arm-kernel@lists.infradead.org,
sw0312.kim@samsung.com, iommu@lists.linux-foundation.org,
linux-kernel@vger.kernel.org, t-kristo@ti.com,
kyungmin.park@samsung.com
Subject: Re: [PATCH 17/18] media/omap3isp: Clean up IOMMU workaround
Date: Thu, 20 Aug 2020 22:55:36 +0300 [thread overview]
Message-ID: <20200820195536.GL7145@valkosipuli.retiisi.org.uk> (raw)
In-Reply-To: <be010209-4abc-ba48-4e31-185427776a13@arm.com>
On Thu, Aug 20, 2020 at 06:25:19PM +0100, Robin Murphy wrote:
> On 2020-08-20 17:53, Sakari Ailus wrote:
> > Hi Robin,
> >
> > On Thu, Aug 20, 2020 at 04:08:36PM +0100, Robin Murphy wrote:
> > > Now that arch/arm is wired up for default domains and iommu-dma, devices
> > > behind IOMMUs will get mappings set up automatically as appropriate, so
> > > there is no need for drivers to do so manually.
> > >
> > > Signed-off-by: Robin Murphy <robin.murphy@arm.com>
> >
> > Thanks for the patch.
>
> Many thanks for testing so quickly!
>
> > I haven't looked at the details but it seems that this causes the buffer
> > memory allocation to be physically contiguous, which causes a failure to
> > allocate video buffers of entirely normal size. I guess that was not
> > intentional?
>
> Hmm, it looks like the device ends up with the wrong DMA ops, which implies
> something didn't go as expected with the earlier IOMMU setup and default
> domain creation. Chances are that either I missed some subtlety in the
> omap_iommu change, or I've fundamentally misjudged how the ISP probing works
> and it never actually goes down the of_iommu_configure() path in the first
> place. Do you get any messages from the IOMMU layer earlier on during boot?
I do get these:
[ 2.934936] iommu: Default domain type: Translated
[ 2.940917] omap-iommu 480bd400.mmu: 480bd400.mmu registered
[ 2.946899] platform 480bc000.isp: Adding to iommu group 0
--
Sakari Ailus
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
WARNING: multiple messages have this Message-ID (diff)
From: Sakari Ailus <sakari.ailus@iki.fi>
To: Robin Murphy <robin.murphy@arm.com>
Cc: geert+renesas@glider.be, dri-devel@lists.freedesktop.org,
bjorn.andersson@linaro.org, linux-tegra@vger.kernel.org,
thierry.reding@gmail.com, laurent.pinchart@ideasonboard.com,
digetx@gmail.com, s-anna@ti.com, will@kernel.org, hch@lst.de,
m.szyprowski@samsung.com, linux-samsung-soc@vger.kernel.org,
joro@8bytes.org, magnus.damm@gmail.com, linux@armlinux.org.uk,
jonathanh@nvidia.com, agross@kernel.org, yong.wu@mediatek.com,
linux-media@vger.kernel.org, linux-arm-msm@vger.kernel.org,
vdumpa@nvidia.com, linux-mediatek@lists.infradead.org,
matthias.bgg@gmail.com, linux-arm-kernel@lists.infradead.org,
sw0312.kim@samsung.com, iommu@lists.linux-foundation.org,
linux-kernel@vger.kernel.org, t-kristo@ti.com,
kyungmin.park@samsung.com
Subject: Re: [PATCH 17/18] media/omap3isp: Clean up IOMMU workaround
Date: Thu, 20 Aug 2020 22:55:36 +0300 [thread overview]
Message-ID: <20200820195536.GL7145@valkosipuli.retiisi.org.uk> (raw)
In-Reply-To: <be010209-4abc-ba48-4e31-185427776a13@arm.com>
On Thu, Aug 20, 2020 at 06:25:19PM +0100, Robin Murphy wrote:
> On 2020-08-20 17:53, Sakari Ailus wrote:
> > Hi Robin,
> >
> > On Thu, Aug 20, 2020 at 04:08:36PM +0100, Robin Murphy wrote:
> > > Now that arch/arm is wired up for default domains and iommu-dma, devices
> > > behind IOMMUs will get mappings set up automatically as appropriate, so
> > > there is no need for drivers to do so manually.
> > >
> > > Signed-off-by: Robin Murphy <robin.murphy@arm.com>
> >
> > Thanks for the patch.
>
> Many thanks for testing so quickly!
>
> > I haven't looked at the details but it seems that this causes the buffer
> > memory allocation to be physically contiguous, which causes a failure to
> > allocate video buffers of entirely normal size. I guess that was not
> > intentional?
>
> Hmm, it looks like the device ends up with the wrong DMA ops, which implies
> something didn't go as expected with the earlier IOMMU setup and default
> domain creation. Chances are that either I missed some subtlety in the
> omap_iommu change, or I've fundamentally misjudged how the ISP probing works
> and it never actually goes down the of_iommu_configure() path in the first
> place. Do you get any messages from the IOMMU layer earlier on during boot?
I do get these:
[ 2.934936] iommu: Default domain type: Translated
[ 2.940917] omap-iommu 480bd400.mmu: 480bd400.mmu registered
[ 2.946899] platform 480bc000.isp: Adding to iommu group 0
--
Sakari Ailus
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
next prev parent reply other threads:[~2020-08-20 19:56 UTC|newest]
Thread overview: 250+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <CGME20200820150857eucas1p18f5f2ad87703a68b6ed20a090f7c1c57@eucas1p1.samsung.com>
2020-08-20 15:08 ` [PATCH 00/18] Convert arch/arm to use iommu-dma Robin Murphy
2020-08-20 15:08 ` Robin Murphy
2020-08-20 15:08 ` Robin Murphy
2020-08-20 15:08 ` Robin Murphy
2020-08-20 15:08 ` Robin Murphy
2020-08-20 15:08 ` [PATCH 01/18] ARM/dma-mapping: Drop .dma_supported for IOMMU ops Robin Murphy
2020-08-20 15:08 ` Robin Murphy
2020-08-20 15:08 ` Robin Murphy
2020-08-20 15:08 ` Robin Murphy
2020-08-20 15:08 ` Robin Murphy
2020-08-20 15:08 ` [PATCH 02/18] ARM/dma-mapping: Consolidate IOMMU ops callbacks Robin Murphy
2020-08-20 15:08 ` Robin Murphy
2020-08-20 15:08 ` Robin Murphy
2020-08-20 15:08 ` Robin Murphy
2020-08-20 15:08 ` Robin Murphy
2020-08-20 15:08 ` [PATCH 03/18] ARM/dma-mapping: Merge IOMMU ops Robin Murphy
2020-08-20 15:08 ` Robin Murphy
2020-08-20 15:08 ` Robin Murphy
2020-08-20 15:08 ` Robin Murphy
2020-08-20 15:08 ` Robin Murphy
2020-08-20 15:08 ` [PATCH 04/18] iommu/dma: Add temporary hacks for arch/arm Robin Murphy
2020-08-20 15:08 ` Robin Murphy
2020-08-20 15:08 ` Robin Murphy
2020-08-20 15:08 ` Robin Murphy
2020-08-20 15:08 ` Robin Murphy
2020-08-20 15:08 ` [PATCH 05/18] ARM/dma-mapping: Switch to iommu_dma_ops Robin Murphy
2020-08-20 15:08 ` Robin Murphy
2020-08-20 15:08 ` Robin Murphy
2020-08-20 15:08 ` Robin Murphy
2020-08-20 15:08 ` Robin Murphy
2020-09-28 11:32 ` Marek Szyprowski
2020-09-28 11:32 ` Marek Szyprowski
2020-09-28 11:32 ` Marek Szyprowski
2020-09-28 11:32 ` Marek Szyprowski
2020-09-28 11:32 ` Marek Szyprowski
2020-08-20 15:08 ` [PATCH 06/18] ARM/dma-mapping: Support IOMMU default domains Robin Murphy
2020-08-20 15:08 ` Robin Murphy
2020-08-20 15:08 ` Robin Murphy
2020-08-20 15:08 ` Robin Murphy
2020-08-20 15:08 ` Robin Murphy
2020-08-20 15:08 ` [PATCH 07/18] iommu/arm-smmu: Remove arch/arm workaround Robin Murphy
2020-08-20 15:08 ` Robin Murphy
2020-08-20 15:08 ` Robin Murphy
2020-08-20 15:08 ` Robin Murphy
2020-08-20 15:08 ` Robin Murphy
2020-08-21 8:07 ` Will Deacon
2020-08-21 8:07 ` Will Deacon
2020-08-21 8:07 ` Will Deacon
2020-08-21 8:07 ` Will Deacon
2020-08-21 8:07 ` Will Deacon
2020-08-20 15:08 ` [PATCH 08/18] iommu/renesas: " Robin Murphy
2020-08-20 15:08 ` Robin Murphy
2020-08-20 15:08 ` Robin Murphy
2020-08-20 15:08 ` Robin Murphy
2020-08-20 15:08 ` Robin Murphy
2020-08-20 15:08 ` [PATCH 09/18] iommu/mediatek-v1: Add IOMMU_DOMAIN_DMA support Robin Murphy
2020-08-20 15:08 ` Robin Murphy
2020-08-20 15:08 ` Robin Murphy
2020-08-20 15:08 ` Robin Murphy
2020-08-20 15:08 ` Robin Murphy
2020-08-29 9:54 ` Yong Wu
2020-08-29 9:54 ` Yong Wu
2020-08-29 9:54 ` Yong Wu
2020-08-29 9:54 ` Yong Wu
2020-08-29 9:54 ` Yong Wu
2020-08-20 15:08 ` [PATCH 10/18] iommu/msm: " Robin Murphy
2020-08-20 15:08 ` Robin Murphy
2020-08-20 15:08 ` Robin Murphy
2020-08-20 15:08 ` Robin Murphy
2020-08-20 15:08 ` Robin Murphy
2020-08-20 15:55 ` Rob Clark
2020-08-20 15:55 ` Rob Clark
2020-08-20 15:55 ` Rob Clark
2020-08-20 15:55 ` Rob Clark
2020-08-20 15:55 ` Rob Clark
2020-08-20 16:58 ` Robin Murphy
2020-08-20 16:58 ` Robin Murphy
2020-08-20 16:58 ` Robin Murphy
2020-08-20 16:58 ` Robin Murphy
2020-08-20 16:58 ` Robin Murphy
2020-08-20 17:05 ` Rob Clark
2020-08-20 17:05 ` Rob Clark
2020-08-20 17:05 ` Rob Clark
2020-08-20 17:05 ` Rob Clark
2020-08-20 17:05 ` Rob Clark
2020-08-20 15:08 ` [PATCH 11/18] iommu/omap: " Robin Murphy
2020-08-20 15:08 ` Robin Murphy
2020-08-20 15:08 ` Robin Murphy
2020-08-20 15:08 ` Robin Murphy
2020-08-20 15:08 ` Robin Murphy
2020-08-24 21:39 ` Suman Anna
2020-08-24 21:39 ` Suman Anna
2020-08-24 21:39 ` Suman Anna
2020-08-24 21:39 ` Suman Anna
2020-08-24 21:39 ` Suman Anna via iommu
2020-08-20 15:08 ` [PATCH 12/18] iommu/tegra-gart: " Robin Murphy
2020-08-20 15:08 ` Robin Murphy
2020-08-20 15:08 ` Robin Murphy
2020-08-20 15:08 ` Robin Murphy
2020-08-20 15:08 ` Robin Murphy
2020-08-20 20:16 ` Dmitry Osipenko
2020-08-20 20:16 ` Dmitry Osipenko
2020-08-20 20:16 ` Dmitry Osipenko
2020-08-20 20:16 ` Dmitry Osipenko
2020-08-20 20:16 ` Dmitry Osipenko
2020-08-21 0:28 ` Robin Murphy
2020-08-21 0:28 ` Robin Murphy
2020-08-21 0:28 ` Robin Murphy
2020-08-21 0:28 ` Robin Murphy
2020-08-21 0:28 ` Robin Murphy
2020-08-23 21:42 ` Dmitry Osipenko
2020-08-23 21:42 ` Dmitry Osipenko
2020-08-23 21:42 ` Dmitry Osipenko
2020-08-23 21:42 ` Dmitry Osipenko
2020-08-23 21:42 ` Dmitry Osipenko
2020-08-20 15:08 ` [PATCH 13/18] iommu/tegra: " Robin Murphy
2020-08-20 15:08 ` Robin Murphy
2020-08-20 15:08 ` Robin Murphy
2020-08-20 15:08 ` Robin Murphy
2020-08-20 15:08 ` Robin Murphy
2020-08-27 15:45 ` Thierry Reding
2020-08-27 15:45 ` Thierry Reding
2020-08-27 15:45 ` Thierry Reding
2020-08-27 15:45 ` Thierry Reding
2020-08-27 15:45 ` Thierry Reding
2020-08-27 18:18 ` Robin Murphy
2020-08-27 18:18 ` Robin Murphy
2020-08-27 18:18 ` Robin Murphy
2020-08-27 18:18 ` Robin Murphy
2020-08-27 18:18 ` Robin Murphy
2020-08-20 15:08 ` [PATCH 14/18] drm/exynos: Consolidate IOMMU mapping code Robin Murphy
2020-08-20 15:08 ` Robin Murphy
2020-08-20 15:08 ` Robin Murphy
2020-08-20 15:08 ` Robin Murphy
2020-08-20 15:08 ` Robin Murphy
2020-09-18 14:30 ` Marek Szyprowski
2020-09-18 14:30 ` Marek Szyprowski
2020-09-18 14:30 ` Marek Szyprowski
2020-09-18 14:30 ` Marek Szyprowski
2020-09-18 14:30 ` Marek Szyprowski
2020-09-21 2:09 ` Inki Dae
2020-09-21 2:09 ` Inki Dae
2020-09-21 2:09 ` Inki Dae
2020-09-21 2:09 ` Inki Dae
2020-09-21 2:09 ` Inki Dae
2020-08-20 15:08 ` [PATCH 15/18] drm/nouveau/tegra: Clean up IOMMU workaround Robin Murphy
2020-08-20 15:08 ` Robin Murphy
2020-08-20 15:08 ` Robin Murphy
2020-08-20 15:08 ` Robin Murphy
2020-08-20 15:08 ` Robin Murphy
2020-08-20 15:08 ` [PATCH 16/18] staging/media/tegra-vde: " Robin Murphy
2020-08-20 15:08 ` Robin Murphy
2020-08-20 15:08 ` Robin Murphy
2020-08-20 15:08 ` Robin Murphy
2020-08-20 15:08 ` Robin Murphy
2020-08-20 19:51 ` Dmitry Osipenko
2020-08-20 19:51 ` Dmitry Osipenko
2020-08-20 19:51 ` Dmitry Osipenko
2020-08-20 19:51 ` Dmitry Osipenko
2020-08-20 19:51 ` Dmitry Osipenko
2020-08-20 20:10 ` Dmitry Osipenko
2020-08-20 20:10 ` Dmitry Osipenko
2020-08-20 20:10 ` Dmitry Osipenko
2020-08-20 20:10 ` Dmitry Osipenko
2020-08-20 20:10 ` Dmitry Osipenko
2020-08-21 0:11 ` Robin Murphy
2020-08-21 0:11 ` Robin Murphy
2020-08-21 0:11 ` Robin Murphy
2020-08-21 0:11 ` Robin Murphy
2020-08-21 0:11 ` Robin Murphy
2020-08-23 21:34 ` Dmitry Osipenko
2020-08-23 21:34 ` Dmitry Osipenko
2020-08-23 21:34 ` Dmitry Osipenko
2020-08-23 21:34 ` Dmitry Osipenko
2020-08-23 21:34 ` Dmitry Osipenko
2020-08-24 14:01 ` Robin Murphy
2020-08-24 14:01 ` Robin Murphy
2020-08-24 14:01 ` Robin Murphy
2020-08-24 14:01 ` Robin Murphy
2020-08-24 14:01 ` Robin Murphy
2020-08-27 7:05 ` Dmitry Osipenko
2020-08-27 7:05 ` Dmitry Osipenko
2020-08-27 7:05 ` Dmitry Osipenko
2020-08-27 7:05 ` Dmitry Osipenko
2020-08-27 7:05 ` Dmitry Osipenko
2020-08-27 15:54 ` Thierry Reding
2020-08-27 15:54 ` Thierry Reding
2020-08-27 15:54 ` Thierry Reding
2020-08-27 15:54 ` Thierry Reding
2020-08-27 15:54 ` Thierry Reding
2020-08-30 19:44 ` Dmitry Osipenko
2020-08-30 19:44 ` Dmitry Osipenko
2020-08-30 19:44 ` Dmitry Osipenko
2020-08-30 19:44 ` Dmitry Osipenko
2020-08-30 19:44 ` Dmitry Osipenko
2020-08-20 15:08 ` [PATCH 17/18] media/omap3isp: " Robin Murphy
2020-08-20 15:08 ` Robin Murphy
2020-08-20 15:08 ` Robin Murphy
2020-08-20 15:08 ` Robin Murphy
2020-08-20 15:08 ` Robin Murphy
2020-08-20 16:53 ` Sakari Ailus
2020-08-20 16:53 ` Sakari Ailus
2020-08-20 16:53 ` Sakari Ailus
2020-08-20 16:53 ` Sakari Ailus
2020-08-20 16:53 ` Sakari Ailus
2020-08-20 17:25 ` Robin Murphy
2020-08-20 17:25 ` Robin Murphy
2020-08-20 17:25 ` Robin Murphy
2020-08-20 17:25 ` Robin Murphy
2020-08-20 17:25 ` Robin Murphy
2020-08-20 19:55 ` Sakari Ailus [this message]
2020-08-20 19:55 ` Sakari Ailus
2020-08-20 19:55 ` Sakari Ailus
2020-08-20 19:55 ` Sakari Ailus
2020-08-20 19:55 ` Sakari Ailus
2020-08-20 23:01 ` Robin Murphy
2020-08-20 23:01 ` Robin Murphy
2020-08-20 23:01 ` Robin Murphy
2020-08-20 23:01 ` Robin Murphy
2020-08-20 23:01 ` Robin Murphy
2020-08-24 21:55 ` Suman Anna
2020-08-24 21:55 ` Suman Anna
2020-08-24 21:55 ` Suman Anna
2020-08-24 21:55 ` Suman Anna
2020-08-24 21:55 ` Suman Anna via iommu
2020-08-20 15:08 ` [PATCH 18/18] ARM/dma-mapping: Remove legacy dma-iommu API Robin Murphy
2020-08-20 15:08 ` Robin Murphy
2020-08-20 15:08 ` Robin Murphy
2020-08-20 15:08 ` Robin Murphy
2020-08-20 15:08 ` Robin Murphy
2020-08-24 11:40 ` [PATCH 00/18] Convert arch/arm to use iommu-dma Marek Szyprowski
2020-08-24 11:40 ` Marek Szyprowski
2020-08-24 11:40 ` Marek Szyprowski
2020-08-24 11:40 ` Marek Szyprowski
2020-08-24 11:40 ` Marek Szyprowski
2020-09-18 15:13 ` Marek Szyprowski
2020-09-18 15:13 ` Marek Szyprowski
2020-09-18 15:13 ` Marek Szyprowski
2020-09-18 15:13 ` Marek Szyprowski
2020-09-18 15:13 ` Marek Szyprowski
2020-08-27 12:31 ` Aw: " Frank Wunderlich
2020-08-27 12:31 ` Frank Wunderlich
2020-08-27 12:31 ` Frank Wunderlich
2020-08-27 12:31 ` Frank Wunderlich
2020-08-27 12:31 ` Frank Wunderlich
2020-08-27 12:54 ` Matthias Brugger
2020-08-27 12:54 ` Matthias Brugger
2020-08-27 12:54 ` Matthias Brugger
2020-08-27 12:54 ` Matthias Brugger
2020-08-27 12:54 ` Matthias Brugger
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20200820195536.GL7145@valkosipuli.retiisi.org.uk \
--to=sakari.ailus@iki.fi \
--cc=agross@kernel.org \
--cc=bjorn.andersson@linaro.org \
--cc=digetx@gmail.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=geert+renesas@glider.be \
--cc=hch@lst.de \
--cc=inki.dae@samsung.com \
--cc=iommu@lists.linux-foundation.org \
--cc=jonathanh@nvidia.com \
--cc=joro@8bytes.org \
--cc=kyungmin.park@samsung.com \
--cc=laurent.pinchart@ideasonboard.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-media@vger.kernel.org \
--cc=linux-mediatek@lists.infradead.org \
--cc=linux-samsung-soc@vger.kernel.org \
--cc=linux-tegra@vger.kernel.org \
--cc=linux@armlinux.org.uk \
--cc=m.szyprowski@samsung.com \
--cc=magnus.damm@gmail.com \
--cc=matthias.bgg@gmail.com \
--cc=robin.murphy@arm.com \
--cc=s-anna@ti.com \
--cc=sw0312.kim@samsung.com \
--cc=t-kristo@ti.com \
--cc=thierry.reding@gmail.com \
--cc=vdumpa@nvidia.com \
--cc=will@kernel.org \
--cc=yong.wu@mediatek.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.