1 file changed, 1 insertion(+)
> >
> > diff --git a/arch/arm/mm/dma-mapping.c b/arch/arm/mm/dma-mapping.c
> > index ab4f745..a40f03e 100644
> > --- a/arch/arm/mm/dma-mapping.c
> > +++ b/arch/arm/mm/dma-mapping.c
> > @@ -2358,6 +2358,7 @@ static void arm_tea
gt;
> Is virt_to_phys() correct here? I'm not an expert on x86 systems, but
> since this is a PCI device, there might be some other memory mapping
> involved.
In theory yes --- if the IPU3 were behind an IOMMU managed by the Linux
kernel. That kind of configuration wouldn't make much sense and any
attempt to use such a configuration would probably fall apart with
the assumption of single dma_ops, too.
I have to say I'm not certain if anything else than kernel configuration
would prevent this though.
--
Regards,
Sakari Ailus
sakari.ai...@linux.intel.com
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
ct device *dev)
> >> +{
> >> + struct ipu3_mmu *mmu = dev_get_drvdata(dev);
> >> +
> >> + put_iova_domain(&mmu->iova_domain);
> >> + iova_cache_put();
>
> Don't we need to set the L1 table address to something invalid and
> invalidate the TLB, so that the IOMMU doesn't reference the page freed
> below anymore?
I think the expectation is that if a device gets removed, its memory is
unmapped by that time. Unmapping that memory will cause explicit TLB flush.
--
Regards,
Sakari Ailus
e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
e whole PCI device is
> non-coherent for some reason (e.g. you can see implicit cache flushes
> for page tables). So I would have expected that a non-coherent variant
> of x86 dma_ops is used for the PCI struct device, which would do cache
> maintenance in its dma_sync_* ops.
Hi Tomasz,
On Fri, Jun 09, 2017 at 02:59:10PM +0900, Tomasz Figa wrote:
> On Fri, Jun 9, 2017 at 1:43 AM, Sakari Ailus wrote:
> >> >> +static void ipu3_mmu_domain_free(struct iommu_domain *dom)
> >> >> +{
> >> >> + struct ipu3_mmu_domain *mm
; + /*
> > +* Allocate the L1 page table.
> > +*
> > +* NOTE that the hardware does not allow changing the L1 page table
> > +* at runtime, so we use shadow L1 tables with CPU L2 table pointers
> > +* per-domain and update the L1 table on domain attach an
;
> + }
> +
> + dev->dma_ops = &ipu3_dmamap_ops;
> +
> + return 0;
> +}
> +EXPORT_SYMBOL_GPL(ipu3_dmamap_init);
> +
> +void ipu3_dmamap_cleanup(struct device *dev)
> +{
> + dev->dma_ops = &ipu3_dmamap_ops;
> + iommu_dma_cleanup();
&g
run but I don't think this
stands apart from the rest currently --- except that the MMU is only used
by a single PCI device, the same which it is contained in.
--
Kind regards,
Sakari Ailus
e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk
__
u/omap: Fix map protection value handling
drivers/iommu/omap-iommu.c | 68 --
1 file changed, 23 insertions(+), 45 deletions(-)
Until I have time to read and think about the rest, for the series,
Reviewed-by: Sakari Ailus
--
Sakari Ailus
saka
tever
hardware used in the DMA accesses to power down (and up again when needed).
The latter is hackish in my opinion but the former would also change the DMA
mapping API to a direction which not everyone would probably agree on.
I'm personally fine with the above limitation on OMAP3 but in ge
Fix this by defining IOVA library Kconfig bits independently of IOMMU
support configuration, and descending to the iommu directory
unconditionally during the build.
Signed-off-by: Sakari Ailus
---
drivers/Makefile | 2 +-
drivers/iommu/Kconfig | 7 ---
2 files changed, 5 insertions(
Hi Laurent,
On Thu, Jan 03, 2019 at 12:52:00AM +0200, Laurent Pinchart wrote:
> Hi Sakari,
>
> Thank you for the patch.
>
> On Wednesday, 2 January 2019 23:16:57 EET Sakari Ailus wrote:
> > Drivers such as the Intel IPU3 ImgU driver use the IOVA library to manage
> &g
On Tue, Apr 14, 2020 at 03:13:23PM +0200, Christoph Hellwig wrote:
> Just use vmap instead of messing with vmalloc internals.
>
> Signed-off-by: Christoph Hellwig
> Acked-by: Peter Zijlstra (Intel)
Thanks!
Acked-by: Sakari Ailus
--
The iova library is usable elsewhere than just the intel-iommu driver, thus
make it also buildable a module.
Signed-off-by: Sakari Ailus
---
drivers/iommu/Kconfig | 4
drivers/iommu/Makefile | 3 ++-
drivers/iommu/iova.c | 4
3 files changed, 10 insertions(+), 1 deletion(-)
diff
alloc_iova_mem() or free_iova_mem(), and correspondingly iova_cache_put()
after using the IOVA library.
Signed-off-by: Sakari Ailus
---
drivers/iommu/intel-iommu.c | 34 +++-
drivers/iommu/iova.c| 48 +
include/linux/iova.h
Hi,
This set separates the IOVA library from the intel-iommu driver, and makes
it usable for other implementations (such as DMA mapping) as well.
While I don't have a DMA mapping implementation to share at the moment, the
patches might be useful for the others in the meantime and I wouldn't mind
These APIs are needed in DMA mapping API implementation as a module. Device
specific IOMMUs with associated DMA mapping implementations should be
buildable as modules.
Signed-off-by: Sakari Ailus
---
mm/vmalloc.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/mm/vmalloc.c b/mm/vmalloc.c
();
This is necessary in order to use the iova library from a kernel module.
Signed-off-by: Sakari Ailus
---
drivers/iommu/iova.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/drivers/iommu/iova.c b/drivers/iommu/iova.c
index 6bc7022..e9e62f4 100644
--- a/drivers/iommu/iova.c
+++ b
the
right list to get that forward anyway.
[1]:http://thread.gmane.org/gmane.linux.ports.arm.kernel/331299
[2]:http://article.gmane.org/gmane.linux.kernel.iommu/7436
--
Kind regards,
Sakari Ailus
sakari.ai...@linux.intel.com
___
iommu mailing list
iom
is. It seems like hitting this issue is highly dependent on the
> size of the buffer one is allocating.
I guess there aren't too many drivers that may map large areas of memory
pinned using get_user_pages() to IOMMU. If dma_map_sg() couldn't be used to
allocate virtua
here are
> > multiple device and the register definition does not duplicate.
>
> I guess we didn't catch that in the review yet. It should be fixed.
>
> > You
> > recommend adding MT2712 support on top of the MT8183 series, do you mean
> > that "mediatek,
On Thu, Sep 05, 2019 at 07:53:37PM +0900, Tomasz Figa wrote:
> On Thu, Sep 5, 2019 at 7:45 PM Sakari Ailus
> wrote:
> >
> > Hi Dongchun,
> >
> > On Thu, Sep 05, 2019 at 05:41:05PM +0800, Dongchun Zhu wrote:
> >
> > ...
> >
> > &g
ould also not have access to similar
configurations (output size, cropping etc.) that now exist in the driver.
I'll review the patch itself soonish.
--
Regards,
Sakari Ailus
sakari.ai...@linux.intel.com
meaningful
> use of them. For these reasons it has been chosen video buffers to pass
Do you have a to-do list for this patchset? I think it would be useful to
maintain one, in case not all the comments have been addressed.
--
Sakari Ailus
e-mail: sakari.ai...@iki.fi
__
ut_iova_domain(&imgu->iova_domain);
> + iova_cache_put();
> + iommu_detach_device(imgu->domain, imgu->mmu);
> + iommu_domain_free(imgu->domain);
> + imgu->domain = NULL;
> +}
> +EXPORT_SYMBOL_GPL(ipu3_dmamap_exit);
> +
> +MODULE_AU
t_pteval);
> + if (!mmu->l1pt) {
> + ret = -ENOMEM;
> + goto fail_l2pts;
> + }
> +
> + pteval = IPU3_ADDR2PTE(virt_to_phys(mmu->l1pt));
> + writel(pteval, mmu->base + REG_L1_PHYS);
> + ipu3_mmu_tlb_invalidate(mmu);
> + ipu3_mmu_set_ha
#define IMGU_NODE_STAT_DVS 6 /* DVS statistics */
> +#define IMGU_NODE_STAT_LACE 7 /* Lace statistics */
> +#define IMGU_NODE_NUM8
> +
> +#define file_to_intel_ipu3_node(__file) \
> + container_of(video_devdata(__file), struct imgu_vid
epend on IOMMU_SUPPORT but that's not
declared in its Kconfig entry. I wonder if adding that would be the right
way to fix this.
Cc'ing the IOMMU list.
> select VIDEOBUF2_DMA_SG
> help
> This is the Video4Linux2 driver for Intel IPU3 image processing unit,
--
Regards,
Sakari Ailus
sakari.ai...@linux.intel.com
On Thu, Aug 15, 2019 at 07:29:59PM +0900, Tomasz Figa wrote:
> On Thu, Aug 15, 2019 at 5:25 PM Sakari Ailus
> wrote:
> >
> > Hi Helen,
> >
> > On Wed, Aug 14, 2019 at 09:58:05PM -0300, Helen Koike wrote:
> >
> > ...
> >
> > > &g
iled
-8<---
--
Kind regards,
Sakari Ailus
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
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, device
busted. */
> DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, 0x2a40, quirk_iommu_igfx);
> DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, 0x2e00, quirk_iommu_igfx);
> @@ -5657,6 +5683,9 @@ DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, 0x1632,
> quirk_i
gt; I noticed there was a typo in the recipient list:
> stable.vger.kernel.org -> sta...@vger.kernel.org
>
> no code change for resent.
When you're submitting a patch and want it reach the stable kernels, you'll
need to add a Cc tag:
Cc: sta...@vger.kernel.org
But
On Tue, Apr 20, 2021 at 02:55:33PM +0300, Andy Shevchenko wrote:
> On Tue, Apr 20, 2021 at 01:56:40PM +0300, Sakari Ailus wrote:
> > On Tue, Apr 20, 2021 at 06:34:26PM +0800, Bingbu Cao wrote:
> > > On 4/20/21 6:20 PM, Andy Shevchenko wrote:
> > > > On Tue, Apr 20, 20
On Tue, Apr 20, 2021 at 05:54:57PM +0300, Andy Shevchenko wrote:
> On Tue, Apr 20, 2021 at 05:37:27PM +0300, Sakari Ailus wrote:
> > On Tue, Apr 20, 2021 at 02:55:33PM +0300, Andy Shevchenko wrote:
> > > On Tue, Apr 20, 2021 at 01:56:40PM +0300, Sakari Ailus wrote:
> > >
Marvell 9120 SATA controller has the same issue as a number of others, use
the same quirk for this one. The other quirks were added by patch
"PCI: Add function 1 DMA alias quirk for Marvell devices"
(commit id cc346a4714a59d08c118e8f33fd86692d3563133).
Signed-off-by: Sakari Ailus
---
H
Ping.
(Cc Alex.)
Sakari Ailus wrote:
> Marvell 9120 SATA controller has the same issue as a number of others, use
> the same quirk for this one. The other quirks were added by patch
> "PCI: Add function 1 DMA alias quirk for Marvell devices"
> (commit id cc346a4714a59d08c1
Hi Alex,
Alex Williamson wrote:
> On Thu, 2015-05-21 at 12:54 +0300, Sakari Ailus wrote:
>> Ping.
>>
>> (Cc Alex.)
>
> You can add my ack, but the linux-pci list is the proper list to get
> this upstream. I suggest resending it there. Thanks,
Thank you for your
The iova library has use outside the intel-iommu driver, thus make it a
module.
Signed-off-by: Sakari Ailus
---
drivers/iommu/Kconfig | 2 +-
drivers/iommu/iova.c | 4
2 files changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/iommu/Kconfig b/drivers/iommu/Kconfig
index 40f37a2
find_vm_area() is needed in implementing the DMA mapping API as a module.
Device specific IOMMUs with associated DMA mapping implementations should be
buildable as modules.
Signed-off-by: Sakari Ailus
---
mm/vmalloc.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/mm/vmalloc.c b/mm
();
put_iova_domain();
reserve_iova();
copy_reserved_iova();
Signed-off-by: Sakari Ailus
---
drivers/iommu/iova.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/drivers/iommu/iova.c b/drivers/iommu/iova.c
index 400f4d1..dd87123 100644
--- a/drivers/iommu/iova.c
+++ b/drivers/iommu
This is necessary to separate intel-iommu from the iova library.
Signed-off-by: Sakari Ailus
---
drivers/iommu/intel-iommu.c | 6 ++--
drivers/iommu/iova.c| 83 ++---
include/linux/iova.h| 4 +--
3 files changed, 54 insertions(+), 39
Hi folks,
This set separates the IOVA library from the intel-iommu driver, and makes
it usable for other implementations (such as DMA mapping) as well.
The RFC set can be found here:
http://iommu.linux-foundation.narkive.com/t0Fa600G/rfc-0-4-separate-the-iova-library-from-the-intel-iommu-driver>
43 matches
Mail list logo
