27;m afraid I don't. You know my usual opinion of SoC-specific compatible
strings :-)
> At least R-Car V3M/V3H/D3 have slight differences in the register bits,
> but I don't think that was the reason.
--
Regards,
Laurent Pinchart
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Cc: Miquel Raynal
> Cc: Richard Weinberger
> Cc: Vignesh Raghavendra
> Cc: Alessandro Zummo
> Cc: Alexandre Belloni
> Cc: Greg Kroah-Hartman
> Cc: Sureshkumar Relli
> Cc: Brian Norris
> Cc: Kamal Dasu
> Cc: Linus Walleij
> Cc: Sebastian Siewior
> Cc: Laurent Pinc
1 std 10.430 min 268.837 max (uS)
> header: 54308/5000 uS/qty: 10.861 avg 5.104 std 0.778 min 54.736 max (uS)
> latency: 268799/5000 uS/qty: 53.759 avg 21.827 std 6.095 min 255.153 max (uS)
> decode: 5/5000 uS/qty: 10.444 avg 7.137 std 1.874 min 71.103 max (uS)
> raw decode speed:
Hi Ricardo,
On Fri, Mar 12, 2021 at 11:15:46PM +0100, Ricardo Ribalda Delgado wrote:
> On Fri, Mar 12, 2021 at 10:19 PM Laurent Pinchart wrote:
> > On Fri, Mar 12, 2021 at 01:57:09PM +0100, Ricardo Ribalda wrote:
> > > On architectures where there is no coherent caching s
files changed, 74 insertions(+), 23 deletions(-)
>
> diff --git a/drivers/media/usb/uvc/uvc_video.c
> b/drivers/media/usb/uvc/uvc_video.c
> index f2f565281e63..8e60f81e2257 100644
> --- a/drivers/media/usb/uvc/uvc_video.c
> +++ b/drivers/media/usb/uvc/uvc_video.c
> @@ -6,11
And I forgot to mention:
On Fri, Mar 12, 2021 at 03:42:14AM +0200, Laurent Pinchart wrote:
> Hi Christoph and Ricardo,
>
> Thank you for the patch.
>
> On Mon, Mar 01, 2021 at 09:52:36AM +0100, Christoph Hellwig wrote:
> > From: Ricardo Ribalda
> >
> >
vcvideo.h | 4 +-
> 2 files changed, 60 insertions(+), 23 deletions(-)
>
> diff --git a/drivers/media/usb/uvc/uvc_video.c
> b/drivers/media/usb/uvc/uvc_video.c
> index f2f565281e63ff..d008c68fb6c806 100644
> --- a/drivers/media/usb/uvc/uvc_video.c
> +++ b/drivers/medi
your tree with a S-o-B
> > > him?
> >
> > I though I had all the ACKs to queue it up. Is that not what was
> > intended? Queueing up the API without a user is generally a bad idea.
> >
>
> I am pretty sure we need the ack from Laurent. He maintains uvc
>
du_map_sg() function.
>
> Signed-off-by: Marek Szyprowski
This is a very nice simplification, I've always foudn the dma_map_sg API
cumbersome to use.
Reviewed-by: Laurent Pinchart
I assume you will get the whole series merged in one go. If I need to
pick the patch up at any p
_alloc_wc(&dispc->pdev->dev, i734_buf.size,
> + &i734_buf.paddr, GFP_KERNEL);
I would have indented this line to match the rest. Apart from that,
Reviewed-by: Laurent Pinchart
> if (!i734_buf.vaddr) {
> - dev_err(&dispc->pdev->
Hi Geert,
On Wed, Feb 20, 2019 at 05:05:49PM +0100, Geert Uytterhoeven wrote:
> On Wed, Feb 20, 2019 at 4:42 PM Laurent Pinchart wrote:
> > On Wed, Feb 20, 2019 at 04:05:31PM +0100, Geert Uytterhoeven wrote:
> >> During PSCI system suspend, R-Car Gen3 SoCs are powered down,
et up the correct value for both R-Car Gen2
> and Gen3 SoCs.
>
> Note that currently no code uses this value.
>
> Signed-off-by: Geert Uytterhoeven
Reviewed-by: Laurent Pinchart
> ---
> drivers/iommu/ipmmu-vmsa.c | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-
atic const struct dev_pm_ops ipmmu_pm = {
> + SET_NOIRQ_SYSTEM_SLEEP_PM_OPS(NULL, ipmmu_resume_noirq)
> +};
> +#define DEV_PM_OPS &ipmmu_pm
> +#else
> +#define DEV_PM_OPS NULL
> +#endif /* CONFIG_PM_SLEEP && CONFIG_ARM_PSCI_FW */
> +
> static struct platfo
root, domain);
> + if (ret < 0)
> + return ret;
> +
> + domain->context_id = ret;
> +
> + domain->iop = alloc_io_pgtable_ops(ARM_32_LPAE_S1, &domain->cfg,
> +domain);
> + if (!domain->iop) {
> + ipmmu_domain_free_context(domain->mmu->root,
> + domain->context_id);
> + return -EINVAL;
> + }
>
> + ipmmu_context_init(domain);
> return 0;
> }
>
--
Regards,
Laurent Pinchart
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
t;
> if (!(status & (IMSTR_PF | IMSTR_TF)))
> @@ -559,7 +563,7 @@ static irqreturn_t ipmmu_domain_irq(struct
> ipmmu_vmsa_domain *domain)
> return IRQ_HANDLED;
>
> dev_err_ratelimited(mmu->dev,
> - "Unhan
> Signed-off-by: Geert Uytterhoeven
Reviewed-by: Laurent Pinchart
> ---
> drivers/iommu/ipmmu-vmsa.c | 5 ++---
> 1 file changed, 2 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/iommu/ipmmu-vmsa.c b/drivers/iommu/ipmmu-vmsa.c
> index 4d07c26c97848b65..4e3134a9a52f8d8
TX_SIZE + reg, data);
> + ipmmu_ctx_write_root(domain, reg, data);
This makes the code harder to read in my opinion, and I don't think it
bring much optimization.
> }
>
> /*
> -----
--
Regards,
uot; subdirectories are empty.
> Likewise, devices tied to an IOMMU do not have an "iommu" backlink.
>
> Make sure all links are created, on both arm32 and arm64.
>
> Signed-off-by: Geert Uytterhoeven
Reviewed-by: Laurent Pinchart
> ---
> drivers/iommu/ipmm
> > *dev,
> >
> > fwspec->iommu_priv = platform_get_drvdata(ipmmu_pdev);
> >
> > + if (!fwspec->iommu_priv)
> > + put_device(&ipmmu_pdev->dev);
> > +
This doesn't seem to match the patch's subject, and doesn'
ver wants it.
> config IOMMU_API
> bool
> @@ -81,9 +85,6 @@ config IOMMU_DEFAULT_PASSTHROUGH
>
> If unsure, say N here.
>
> -config IOMMU_IOVA
> - tristate
> -
> config OF_IOMMU
> def_bool y
> depends on
change, the blank line after MODULE_DEVICE_TABLE() removed, and
moved to keep alphabetical order sorting of the includes,
please add
Reviewed-by: Laurent Pinchart
to v2. Thank you for the patch.
> > >+ * IOMMU API for Renesas VMSA-compatible IPMMU
> > >+ * Author: Laurent P
pletely...). Do you have plans to address this ? If not,
could you please add it to your to-do list ?
> ret = platform_driver_register(&ipmmu_driver);
> if (ret < 0)
> return ret;
--
Regards,
Laurent Pinchart
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
;
> Signed-off-by: Geert Uytterhoeven
Reviewed-by: Laurent Pinchart
> ---
> drivers/iommu/Kconfig | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/iommu/Kconfig b/drivers/iommu/Kconfig
> index 568ae81b0e99b67b..c69dc0b29b5df37f 100644
domain(io_domain);
> - unsigned long flags;
> unsigned int i;
> int ret = 0;
>
> @@ -654,7 +653,7 @@ static int ipmmu_attach_device(struct iommu_domain
> *io_domain, return -ENXIO;
> }
>
> - spin_lock_irqsave(&domain->lock, flags);
> + mutex
Hi Rich,
On Monday, 9 April 2018 18:11:13 EEST Rich Felker wrote:
> On Mon, Apr 09, 2018 at 04:06:15PM +0300, Laurent Pinchart wrote:
> > On Monday, 9 April 2018 14:11:22 EEST Robin Murphy wrote:
> >> On 09/04/18 08:25, jacopo mondi wrote:
> >>> Hi Robin, Laurent,
should be postponed until we know
that cpu_addr represents memory that is guaranteed to be backed by a struct
page is a good starting point. You can mention SH4 as an example of an
architecture that will crash when calling virt_to_page() in such a case, but
the fix isn't specific to SH4.
ff-by: Magnus Damm
Reviewed-by: Laurent Pinchart
> ---
>
> Documentation/devicetree/bindings/iommu/renesas,ipmmu-vmsa.txt |1 +
> 1 file changed, 1 insertion(+)
>
> --- 0001/Documentation/devicetree/bindings/iommu/renesas,ipmmu-vmsa.txt
> +++
> work/Documentation/device
Hi Ananth,
On Tuesday, 19 September 2017 09:54:49 EEST Jasty, Ananth wrote:
> On Sep 18, 2017, at 11:49 PM, Laurent Pinchart wrote:
> > On Tuesday, 19 September 2017 03:43:05 EEST Jasty, Ananth wrote:
> >> Hi, with your IPMMU driver enabled under 4.13 we’re seeing a
n some devices losing IOMMU support.
> Now that the ipmmu_init() and ipmmu_exit() functions are simple calls to
> platform_driver_register() and platform_driver_unregister(), replace
> them with the module_platform_driver() macro call.
>
> Signed-off-by: Liviu Dudau
> Cc: L
m_bus_type, &ipmmu_ops);
> +
> return 0;
> }
>
> @@ -1108,9 +,6 @@ static int __init ipmmu_init(void)
> if (ret < 0)
> return ret;
>
> - if (!iommu_present(&platform_bus_type))
> -
hat is more the pagetable init/cleanup code could require
> the context to be set up.
>
> Signed-off-by: Oleksandr Tyshchenko
> CC: Robin Murphy
> CC: Laurent Pinchart
> CC: Joerg Roedel
Reviewed-by: Laurent Pinchart
> ---
> This patch fixes a bug during rollback log
Hi Oleksandr,
On Wednesday, 23 August 2017 14:58:47 EEST Oleksandr Tyshchenko wrote:
> On Wed, Aug 23, 2017 at 1:05 PM, Robin Murphy wrote:
> > On 23/08/17 10:36, Oleksandr Tyshchenko wrote:
> >> On Wed, Aug 23, 2017 at 12:25 AM, Laurent Pinchart wrote:
> >>> On M
sense to allocate the pgtable ops after initializing the
context (moving the ipmmu_domain_allocate_context() call to the very end of
the function) ? That way we would be less dependent on changes to pgtable ops
init/cleanup code that could require the context to be set up.
> f
check it for a valid value (< IPMMU_CTX_MAX)
> > before calling ipmmu_tlb_invalidate().
> >
> > Signed-off-by: Oleksandr Tyshchenko
> > ---
> >
> > drivers/iommu/ipmmu-vmsa.c | 4
> > 1 file changed, 4 insertions(
s once.
I apologize for the delay, I had to resurrect my Beagleboard-xM, which
involved updating and then debugging U-Boot.
Tested-by: Laurent Pinchart
--
Regards,
Laurent Pinchart
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
figure dma operations at probe time for
> platform/amba/pci bus devices")
Reviewed-by: Laurent Pinchart
Could you please push this upstream along with "[PATCH] ARM: dma-mapping:
Don't tear third-party mappings" ?
(And feel free to s/tear/tear down/ in the subject of that p
Hi Russell,
On Thursday 25 May 2017 16:05:41 Russell King - ARM Linux wrote:
> On Wed, May 24, 2017 at 02:26:13PM +0300, Laurent Pinchart wrote:
> > Again, the patch I propose is the simplest v4.12-rc fix I can think of,
> > short of reverting your complete IOMMU probe deferr
Hello,
On Wednesday 24 May 2017 16:01:45 Sricharan R wrote:
> On 5/24/2017 4:12 AM, Russell King - ARM Linux wrote:
> > On Wed, May 24, 2017 at 12:46:51AM +0300, Laurent Pinchart wrote:
> >> On Tuesday 23 May 2017 18:53:19 Russell King - ARM Linux wrote:
> >>> On T
n v4.12-rc1 and
breaks IOMMU operations on several platforms. We need a fix for v4.12-rc that
should be as nonintrusive as possible, as a larger cleanup is likely not -rc
material. Beside reverting the whole series, the simplest option I came up
with was [1]. Note that this is not the only fix needed to fix v4.12-rc1 IOMMU
breakage, there are four more patches in the series that Sricharan plans to
get merged soon. I don't think there are dependencies between the other four
drivers/ patches and the arch/arm/ patch, so the latter could be merged
independently through your tree as soon as it's deemed ready.
[1] https://www.spinics.net/lists/arm-kernel/msg583019.html
--
Regards,
Laurent Pinchart
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
concern and let the master work without IOMMU, thus
> restoring the old behavior.
>
> Fixes: 7b07cbefb68d ("iommu: of: Handle IOMMU lookup failure with deferred
> probing or error") Reported-by: Geert Uytterhoeven
> Tested-by: Magnus Damn
> Signed-off-by: Sricharan R
Revi
Hi Sricharan
On Thursday 18 May 2017 19:08:12 Sricharan R wrote:
> On 5/18/2017 6:00 PM, Laurent Pinchart wrote:
> > On Thursday 18 May 2017 17:26:14 Sricharan R wrote:
> >> On 5/18/2017 4:09 PM, Laurent Pinchart wrote:
> >>> On Thursday 18 May 2017 15:37:09 S
Hi Sricharan,
On Thursday 18 May 2017 17:26:14 Sricharan R wrote:
> On 5/18/2017 4:09 PM, Laurent Pinchart wrote:
> > On Thursday 18 May 2017 15:37:09 Sricharan R wrote:
> >> While deferring the probe of IOMMU masters,
> >> xlate and add_device callback can pass
/* Ignore all other errors apart from EPROBE_DEFER */
> + if (IS_ERR(ops) && (PTR_ERR(ops) != -EPROBE_DEFER)) {
> + dev_info(dev, "Adding to IOMMU failed: %ld\n", PTR_ERR(ops));
> + ops = NULL;
> + }
> +
> return ops;
> }
--
Regards,
Laurent P
Fixes: 7b07cbefb68d ("iommu: of: Handle IOMMU lookup failure with deferred
> probing or error") Signed-off-by: Sricharan R
> Reported-by: Geert Uytterhoeven
> Tested-by: Will Deacon
> Tested-by: Magnus Damn
> Acked-by: Will Deacon
Reviewed-by: Laurent Pinchart
>
Hi Robin,
On Tuesday 16 May 2017 16:47:36 Robin Murphy wrote:
> On 16/05/17 16:14, Laurent Pinchart wrote:
> > arch_setup_dma_ops() is used in device probe code paths to create an
> > IOMMU mapping and attach it to the device. The function assumes that the
> > device is
68d ("iommu: of: Handle IOMMU lookup failure with deferred
probing or error")
Signed-off-by: Laurent Pinchart
---
arch/arm/include/asm/device.h | 3 ++-
arch/arm/mm/dma-mapping.c | 5 +
2 files changed, 7 insertions(+), 1 deletion(-)
diff --git a/arch/arm/include/asm/device.h b/arch
Hi Sricharan,
On Tuesday 16 May 2017 19:59:01 sricha...@codeaurora.org wrote:
> On 2017-05-16 19:40, Laurent Pinchart wrote:
> > On Tuesday 16 May 2017 15:04:55 Robin Murphy wrote:
> >> On 16/05/17 08:17, Laurent Pinchart wrote:
> >> > On Tuesday 16 May 2017 07:
Hi Robin,
On Tuesday 16 May 2017 15:04:55 Robin Murphy wrote:
> On 16/05/17 08:17, Laurent Pinchart wrote:
> > On Tuesday 16 May 2017 07:53:57 sricha...@codeaurora.org wrote:
[snip]
> >> arch_teardown_dma_ops() being the inverse of arch_setup_dma_ops()
> >> ,dma_o
Hi Sricharan,
On Tuesday 16 May 2017 19:10:03 sricha...@codeaurora.org wrote:
> On 2017-05-16 12:47, Laurent Pinchart wrote:
> > On Tuesday 16 May 2017 07:53:57 sricha...@codeaurora.org wrote:
> >> On 2017-05-16 03:04, Laurent Pinchart wrote:
> >>> On Monday 15 May
Hi Sricharan,
On Tuesday 16 May 2017 07:53:57 sricha...@codeaurora.org wrote:
> On 2017-05-16 03:04, Laurent Pinchart wrote:
> > On Monday 15 May 2017 23:37:16 Laurent Pinchart wrote:
> >> On Wednesday 03 May 2017 15:54:59 Sricharan R wrote:
> >>> On 5/3/20
Hi Sricharan,
On Monday 15 May 2017 23:37:16 Laurent Pinchart wrote:
> On Wednesday 03 May 2017 15:54:59 Sricharan R wrote:
> > On 5/3/2017 3:24 PM, Robin Murphy wrote:
> >> On 02/05/17 19:35, Geert Uytterhoeven wrote:
> >>> On Fri, Feb 3, 2017 at 4:48 PM, Sricharan
Hi Sricharan,
On Wednesday 03 May 2017 15:54:59 Sricharan R wrote:
> On 5/3/2017 3:24 PM, Robin Murphy wrote:
> > On 02/05/17 19:35, Geert Uytterhoeven wrote:
> >> On Fri, Feb 3, 2017 at 4:48 PM, Sricharan R wrote:
> >>> From: Laurent Pinchart
> >>>
pt bit number associated with the particular cache IPMMU
> device.
> +The interrupt bit number needs to match the main IPMMU IMSSTR register.
> +Only used by cache IPMMU instances.
> +
> +
> Each bus master connected to an IPMMU must reference the IPMMU in its
> device node with the following property:
--
Regards,
Laurent Pinchart
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
ometry to fix this.
>
> Signed-off-by: Geert Uytterhoeven
> Reviewed-by: Robin Murphy
Reviewed-by: Laurent Pinchart
> ---
> v2:
> - Add Reviewed-by.
> ---
> drivers/iommu/ipmmu-vmsa.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/iomm
0));
> + if (!addr)
> + iommu_dma_free(dev, pages, iosize, handle);
> }
> return addr;
> }
> @@ -626,6 +642,8 @@ static void __iommu_free_attrs(struct device *dev,
> size_t size, void *cpu_addr, size = PAGE_ALIGN(size);
> /*
>* @cpu_add
llocate and export buffers from the device
with the strictest requirements, or to implement a central buffer allocator.
In any case, I don't think DMA_ATTR_FORCE_CONTIGUOUS is the right solution to
that problem.
Forcing contiguous allocation can however help with performance optimization,
as mapping physically co
Hi Niklas,
On Monday 05 Sep 2016 12:52:44 Laurent Pinchart wrote:
> On Wednesday 10 Aug 2016 13:22:19 Niklas Söderlund wrote:
> > Enable slave transfers to a device behind a IPMMU by mapping the slave
> > addresses using the dma-mapping API.
> >
> > Sign
Hi Robin,
On Friday 11 Nov 2016 14:44:29 Robin Murphy wrote:
> On 11/11/16 01:50, Laurent Pinchart wrote:
> > On Friday 21 Oct 2016 18:52:53 Robin Murphy wrote:
> >> On 20/10/16 00:36, Magnus Damm wrote:
> >>> From: Magnus Damm
> >>>
> >>>
ic const struct iommu_ops ipmmu_ops = {
- .domain_alloc = ipmmu_domain_alloc_dma,
- .domain_free = ipmmu_domain_free_dma,
+ .domain_alloc = ipmmu_domain_alloc,
+ .domain_free = ipmmu_domain_free,
.attach_dev = ipmmu_attach_device,
.detach_dev = ipmmu_detach_dev
OMMU_DOMAIN_DMA))
return NULL;
But how about just
if (type != IOMMU_DOMAIN_UNMANAGED && type != IOMMU_DOMAIN_DMA))
return NULL;
as type will never be set to IOMMU_DOMAIN_DMA on ARM32 ?
> it shouldn't be necessary to split the
gt;archdata.iommu;
> > - mmu = archdata->mmu;
> > + mmu = to_archdata(dev)->mmu;
> >
> > if (!mmu->mapping) {
> >
> > struct dma_iommu_mapping *mapping;
> >
> > @@ -783,7 +800,7 @@ error:
> >
o_phys = ipmmu_iova_to_phys,
> + .add_device = ipmmu_add_device_dma,
> + .remove_device = ipmmu_remove_device_dma,
> + .device_group = ipmmu_device_group_dma,
> + .pgsize_bitmap = SZ_1G | SZ_2M | SZ_4K,
> + .of_xlate = ipmmu_of_xlate_dma,
The ARM i
ew comments about the other patches (sorry for the late
review, I got delayed by KS and LPC), the follow-up patch should probably be
squashed into this one when Magnus addresses my comments. Could you please
hold off pushing the arm/renesas branch until Magnus replies to this ?
--
Regards,
: Joerg Roedel
This looks good to me,
Reviewed-by: Laurent Pinchart
(assuming my review of the next patches in the series won't make me conclude
that this patch isn't needed :-))
> ---
>
> Changes since V5:
> - None
>
> Changes since V4:
> - None
>
gt; - arm_iommu_release_mapping(mmu->mapping);
> -
> - kfree(dev->archdata.iommu);
> - kfree(utlbs);
> + if (mmu)
> + arm_iommu_release_mapping(mmu->mapping);
Looking at the surrounding code, shouldn't the mapping only be destroyed here
if
-
> -- @@ -437,16 +482,25 @@ static irqreturn_t ipmmu_domain_irq(stru
> static irqreturn_t ipmmu_irq(int irq, void *dev)
> {
> struct ipmmu_vmsa_device *mmu = dev;
> - struct iommu_domain *io_domain;
> - struct ipmmu
Hi Robin,
On Friday 16 Sep 2016 13:49:21 Robin Murphy wrote:
> On 16/09/16 13:05, Laurent Pinchart wrote:
> [...]
>
> >>>> One concern I have is that we might get an awkward situation if we ever
> >>>> encounter one DMA engine hardware that is used in di
Hi Arnd,
On Friday 16 Sep 2016 14:22:31 Arnd Bergmann wrote:
> On Friday, September 16, 2016 3:09:29 PM CEST Laurent Pinchart wrote:
> >> I wasn't thinking quite that far, though that is also a theoretical
> >> problem. However, the simple solution would be to have a bit
Hi Arnd,
On Friday 16 Sep 2016 14:02:35 Arnd Bergmann wrote:
> On Friday, September 16, 2016 12:48:23 PM CEST Laurent Pinchart wrote:
> > On Friday 16 Sep 2016 11:07:48 Arnd Bergmann wrote:
> >> On Thursday, September 15, 2016 9:56:51 PM CEST Vinod Koul wrote:
> >>>
Hi Rubin,
On Friday 16 Sep 2016 11:36:29 Robin Murphy wrote:
> On 16/09/16 10:48, Laurent Pinchart wrote:
> > On Friday 16 Sep 2016 11:07:48 Arnd Bergmann wrote:
> >> On Thursday, September 15, 2016 9:56:51 PM CEST Vinod Koul wrote:
> >>> On Wed, Aug 10, 2016 at 11:0
dma-mapping: use unsigned long for dma_attrs
We still have enough bits to reserve some of them for a channel number, but
I'm not very happy with that patch as I can see how a future proposal to
handle the channel number through the DMA attributes will get rejected on the
grounds of bits starvation then :-(
> I don't have any idea for how this could be handled in a generic way, so my
> best answer here is to hope we never get there, and if we do, handle it
> using some local hack in the driver.
--
Regards,
Laurent Pinchart
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Add methods to map/unmap device resources addresses for dma_map_ops that
> > are IOMMU aware. This is needed to map a device MMIO register from a
> > physical address.
> >
> > Signed-off-by: Niklas Söderlund
> > Reviewed-by: Laur
return NULL;
> +
> sg_len = buf_len / period_len;
> if (sg_len > RCAR_DMAC_MAX_SG_LEN) {
> dev_err(chan->device->dev,
> @@ -1100,9 +1168,7 @@ rcar_dmac_prep_dma_cyclic(struct dma_chan *chan,
> dma_addr_t buf_addr, sg_dma_len(&sgl[i]) = period_len;
> }
>
> - dev_addr = dir == DMA_DEV_TO_MEM
> - ? rchan->src.slave_addr : rchan->dst.slave_addr;
> - desc = rcar_dmac_chan_prep_sg(rchan, sgl, sg_len, dev_addr,
> + desc = rcar_dmac_chan_prep_sg(rchan, sgl, sg_len, rchan->map.addr,
> dir, flags, true);
>
> kfree(sgl);
--
Regards,
Laurent Pinchart
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Hi Niklas,
Thank you for the patch.
On Wednesday 10 Aug 2016 13:22:16 Niklas Söderlund wrote:
> Map/Unmap a device MMIO resource from a physical address. If no dma_map_ops
> method is available the operation is a no-op.
>
> Signed-off-by: Niklas Söderlund
Acked-by: Laur
translate them to a
> physical address.
>
> Signed-off-by: Niklas Söderlund
Acked-by: Laurent Pinchart
> ---
> include/linux/dma-debug.h | 19 +
> lib/dma-debug.c | 52 +--
> 2 files changed, 69 insertion
HERENT
>
> static void dmam_coherent_decl_release(struct device *dev, void *res)
> diff --git a/include/linux/dma-mapping.h b/include/linux/dma-mapping.h
> index 71c1b21..a49aac9 100644
> --- a/include/linux/dma-mapping.h
> +++ b/include/linux/dma-mapping.h
> @@ -613,6 +
Hi Tomasz,
On Friday 12 Aug 2016 16:31:47 Tomasz Figa wrote:
> On Tue, Aug 9, 2016 at 7:49 AM, Sricharan R wrote:
> > From: Laurent Pinchart
> >
> > The of_configure_dma() function configures both the DMA masks and ops.
> > Moving DMA ops configuration to probe
On Tuesday 09 Aug 2016 16:17:57 Laurent Pinchart wrote:
> On Wednesday 08 Jun 2016 18:12:31 Magnus Damm wrote:
> > On Wed, Jun 8, 2016 at 5:48 PM, Laurent Pinchart wrote:
> >> On Wednesday 08 Jun 2016 09:04:17 Geert Uytterhoeven wrote:
> >>> On Wed, Jun 8, 2016 at 2
Hi Magnus,
On Wednesday 08 Jun 2016 18:12:31 Magnus Damm wrote:
> On Wed, Jun 8, 2016 at 5:48 PM, Laurent Pinchart wrote:
> > On Wednesday 08 Jun 2016 09:04:17 Geert Uytterhoeven wrote:
> >> On Wed, Jun 8, 2016 at 2:18 AM, Laurent Pinchart wrote:
> >>>> --
Hi Geert,
On Wednesday 08 Jun 2016 09:04:17 Geert Uytterhoeven wrote:
> On Wed, Jun 8, 2016 at 2:18 AM, Laurent Pinchart wrote:
> >> --- 0031/drivers/iommu/ipmmu-vmsa.c
> >> +++ work/drivers/iommu/ipmmu-vmsa.c 2016-06-06 11:19:40.210607110 +0900
> >> @@ -1074,7
ake sure the of_iommu code does not install ops
> + * even though the iommu device is disabled
> + */
> + if (!of_device_is_available(spec->np))
> + return -ENODEV;
> +
> return 0;
> }
--
Regards,
Laurent Pinchart
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
96",
> + ipmmu_vmsa_iommu_of_setup);
How about a Gen3 generic compatible string in addition to the SoC-specific
ones ?
> #endif
>
> MODULE_DESCRIPTION("IOMMU API for Renesas VMSA-compatible IPMMU");
--
Regards,
Laurent Pinchart
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Hi Magnus,
Thank you for the patch.
On Tuesday 07 Jun 2016 12:39:27 Magnus Damm wrote:
> From: Magnus Damm
>
> Update the IPMMU DT binding documentation to include the r8a7796 compat
> string for R-Car M3-W.
>
> Signed-off-by: Magnus Damm
Acked-by
asheet uses a 0-38 utlb range.
> spin_lock_init(&mmu->lock);
> bitmap_zero(mmu->ctx, IPMMU_CTX_MAX);
> mmu->features = match->data;
--
Regards,
Laurent Pinchart
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
cks =
> + <&mmcc SMMU_AHB_CLK>,
> + <&mmcc MDP_AXI_CLK>;
> + reg = <0x0750 0x10>;
> + interrupts =
> + ,
> + ;
> +
-off-by: Niklas Söderlund
Reviewed-by: Laurent Pinchart
> ---
> drivers/dma/sh/rcar-dmac.c | 38 ++
> 1 file changed, 22 insertions(+), 16 deletions(-)
>
> diff --git a/drivers/dma/sh/rcar-dmac.c b/drivers/dma/sh/rcar-dmac.c
> index 01cf82f..b391
H/RFC 00/10] iommu/ipmmu-vmsa: Experimental r8a7795 support
>
> Signed-off-by: Magnus Damm
Great ! Thanks a lot for the work, I'm really happy to see this being
addressed.
For patches 1/4 to 3/4,
Reviewed-by: Laurent Pinchart
For patch 4/4, please see my comments in the reply to the p
h the dma addresses (I'm
thinking about the IOMMU subsystem and the ipmmu-vmsa driver in particular) ?
--
Regards,
Laurent Pinchart
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
return 0;
>
> error:
> - arm_iommu_release_mapping(mmu->mapping);
> -
> kfree(dev->archdata.iommu);
> kfree(utlbs);
>
> @@ -745,7 +775,7 @@ static void ipmmu_remove_device(struct d
> {
> struct ipmmu_vmsa_archdata *a
I's memory type flags, so that callers can let the IOMMU
> drivers know to do the right thing.
>
> Signed-off-by: Robin Murphy
> Signed-off-by: Niklas Söderlund
Reviewed-by: Laurent Pinchart
> ---
> drivers/iommu/io-pgtable-arm.c | 9 +++--
> include/linux/iom
tomic. Let's use explicit locking in every location where
the contexts bitmap is accessed in a racy way.
> + continue;
> + if (ipmmu_domain_irq(mmu->domains[i]) == IRQ_HANDLED)
> + status = IRQ_HANDLED;
> +
rted by of_iommu.h and
> it is wrapped in #ifdefs to also compile of x86_64.
>
> Signed-off-by: Magnus Damm
Nice work, thanks a lot. With the two comments below addressed,
Reviewed-by: Laurent Pinchart
> ---
>
> drivers/iommu/ipmmu-vmsa.c | 94 +++
gt; + phys_addr_t dst_slave_addr;
This moves the cast from phys_addr_t to dma_addr_t from the driver's DMA
engine operations to other places. I'm not sure there's much value in doing
so. I'd squash this patch with 7/9, the result will be easier to review
o_one_initcall) from []
> (kernel_init_freeable+0x120/0x1e8)
> [] (kernel_init_freeable) from [] (kernel_init+0x8/0xec)
> [] (kernel_init) from [] (ret_from_fork+0x14/0x2c)
> Code: 1a03 e7f001f2 e3130001 0a00 (e7f001f2)
> ---[ end trace 190f6f6b84352efd ]---
> Kernel pani
to be a more
> appropriate name than SHMOBILE for the majority of Renesas ARM based SoCs.
>
> Signed-off-by: Simon Horman
Acked-by: Laurent Pinchart
> ---
> drivers/iommu/Kconfig | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> Based on the next branch
line.
> - Enough of a difference that I don't feel comfortable putting
> Laurent's reviewed-by from v1 on it...
Here it is again.
Reviewed-by: Laurent Pinchart
> [1]:http://thread.gmane.org/gmane.linux.kernel.iommu/12007
> [2]:http://thread.gmane.org/gmane.linux.kernel
pgsize_bitmap;
> > unsigned intias;
> > unsigned intoas;
> >
> > @@ -173,10 +187,12 @@ static inline void io_pgtable_tlb_sync(struct
> > io_pgtable *iop)
> > *
> > * @alloc: Allo
t;
> To that end:
> - Indicate exactly which quirks each format can/does support.
> - Fail creating a table if a caller wants unsupported quirks.
> - Properly document where each quirk applies and why.
>
> Signed-off-by: Robin Murphy
Reviewed-by: Laurent Pinchart
> ---
>
: Niklas Söderlund
Acked-by: Laurent Pinchart
Same comment and ack for patch 8/8.
Note that we should still try to find a way to selectively enable the IOMMU in
a per-device fashion, as system integrators might want it to be disabled for
some devices. There's no urgency though.
> ---
gt;src_addr,
> + cfg->src_addr_width);
> + if (ret)
> + return ret;
> +
> + ret = rcar_dmac_set_slave_addr(chan, &rchan->dst, cfg->dst_addr,
> + cfg->dst_addr_width);
You could align cfg with chan on the
1 - 100 of 468 matches
Mail list logo
