Hi, Baolu,
On Fri, Sep 27, 2019 at 10:27:24AM +0800, Lu Baolu wrote:
> > > > > + spin_lock(&(domain)->page_table_lock);
> > > > > \
> > > >
> > > > Is this intended to lock here instead of taking the lock during the
> > > > whole page table walk? Is it safe?
> > >
Hi Peter,
On 9/26/19 11:49 AM, Peter Xu wrote:
On Thu, Sep 26, 2019 at 10:35:24AM +0800, Lu Baolu wrote:
[...]
@@ -0,0 +1,342 @@
+// SPDX-License-Identifier: GPL-2.0
+/**
+ * intel-pgtable.c - Intel IOMMU page table manipulation library
Could this be a bit misleading? Normally I'll use
On Thu, 26 Sep 2019 14:04:13 +0100
Robin Murphy wrote:
> On 26/09/2019 13:37, Halil Pasic wrote:
> > On Mon, 23 Sep 2019 17:21:17 +0200
> > Christoph Hellwig wrote:
> >
> >> On Mon, Sep 23, 2019 at 02:34:16PM +0200, Halil Pasic wrote:
> >>> Before commit 57bf5a8963f8 ("dma-mapping: clear
On Thu, Sep 26, 2019 at 5:05 AM wrote:
>
> From: AngeloGioacchino Del Regno
>
> As specified in this driver, the context banks are 0x1000 apart.
> Problem is that sometimes the context number (our asid) does not
> match this logic and we end up using the wrong one: this starts
> being a problem
Hi Geert,
Thanks for the feedback.
> Subject: Re: [PATCH] iommu/ipmmu-vmsa: Hook up r8a774b1 DT matching
> code
>
> Hi Biju,
>
> On Tue, Sep 24, 2019 at 9:43 AM Biju Das wrote:
> > Support RZ/G2N (R8A774B1) IPMMU.
> >
> > Signed-off-by: Biju Das
>
> Thanks for your patch!
>
> > ---
Hi Biju,
On Tue, Sep 24, 2019 at 9:43 AM Biju Das wrote:
> Support RZ/G2N (R8A774B1) IPMMU.
>
> Signed-off-by: Biju Das
Thanks for your patch!
> --- a/drivers/iommu/ipmmu-vmsa.c
> +++ b/drivers/iommu/ipmmu-vmsa.c
> static const struct soc_device_attribute soc_rcar_gen3_whitelist[] = {
>
On 26/09/2019 13:37, Halil Pasic wrote:
On Mon, 23 Sep 2019 17:21:17 +0200
Christoph Hellwig wrote:
On Mon, Sep 23, 2019 at 02:34:16PM +0200, Halil Pasic wrote:
Before commit 57bf5a8963f8 ("dma-mapping: clear harmful GFP_* flags in
common code") tweaking the client code supplied GFP_* flags
On Tue, Sep 24, 2019 at 9:41 AM Biju Das wrote:
> Document RZ/G2N (R8A774B1) SoC bindings.
>
> Signed-off-by: Biju Das
Reviewed-by: Geert Uytterhoeven
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In
From: AngeloGioacchino Del Regno
This IOMMU is yet another Qualcomm variant of known IOMMUs, found in
Family-B SoCs, such as MSM8956, MSM8976, MSM8953, MSM8917 and others,
and that firmware perfectly adheres to this driver logic.
This time, though, the catch is that the secure contexts are also
From: AngeloGioacchino Del Regno
Some IOMMUs associated with some TZ firmwares may support switching
to the AArch64 pagetable format by sending a "set pagetable format"
scm command indicating the IOMMU secure ID and the context number
to switch.
Add a DT property "qcom,use-aarch64-pagetables"
From: AngeloGioacchino Del Regno
As also stated in the arm-smmu driver, we must write the TCR before
writing the TTBRs, since the TCR determines the access behavior of
some fields.
Signed-off-by: AngeloGioacchino Del Regno
---
drivers/iommu/qcom_iommu.c | 14 +++---
1 file changed, 7
From: AngeloGioacchino Del Regno
This driver was indexing the contexts by asid-1, which is probably
done under the assumption that the first ASID is always 1.
Unfortunately this is not entirely true: at least in the MSM8956
and MSM8976 GPU IOMMU, the gpu_user context's ASID number is zero.
To
From: AngeloGioacchino Del Regno
As specified in this driver, the context banks are 0x1000 apart.
Problem is that sometimes the context number (our asid) does not
match this logic and we end up using the wrong one: this starts
being a problem in the case that we need to send TZ commands
to do
From: AngeloGioacchino Del Regno
Some Qualcomm Family-B SoCs have got a different version of the QCOM
IOMMU, specifically v2 and 500, which perfectly adhere to the current
qcom_iommu driver, but need some variations due to slightly different
hypervisor behavior.
The personal aim is to upstream
From: AngeloGioacchino Del Regno
To avoid context faults reset the context entirely on detach and
to ensure a fresh clean start also do a complete reset before
programming the context for domain initialization.
Signed-off-by: AngeloGioacchino Del Regno
---
drivers/iommu/qcom_iommu.c | 23
On Wed Sep 25 19, Joerg Roedel wrote:
From: Joerg Roedel
The traversing of this list requires protection_domain->lock to be taken
to avoid nasty races with attach/detach code. Make sure the lock is held
on all code-paths traversing this list.
Reported-by: Filippo Sironi
Fixes: 92d420ec028d
On Wed Sep 25 19, Joerg Roedel wrote:
From: Joerg Roedel
Make sure that attaching a detaching a device can't race against each
other and protect the iommu_dev_data with a spin_lock in these code
paths.
Fixes: 92d420ec028d ("iommu/amd: Relax locking in dma_ops path")
Signed-off-by: Joerg
On Wed Sep 25 19, Joerg Roedel wrote:
From: Joerg Roedel
Check early in attach_device whether the device is already attached to a
domain. This also simplifies the code path so that __attach_device() can
be removed.
Fixes: 92d420ec028d ("iommu/amd: Relax locking in dma_ops path")
On Wed Sep 25 19, Joerg Roedel wrote:
From: Joerg Roedel
The code-paths before __attach_device() and __detach_device() are called
also access and modify domain state, so take the domain lock there too.
This allows to get rid of the __detach_device() function.
Fixes: 92d420ec028d ("iommu/amd:
On Wed Sep 25 19, Joerg Roedel wrote:
From: Joerg Roedel
The lock is not necessary because the device table does not
contain shared state that needs protection. Locking is only
needed on an individual entry basis, and that needs to
happen on the iommu_dev_data level.
Fixes: 92d420ec028d
On Wed Sep 25 19, Joerg Roedel wrote:
From: Joerg Roedel
This struct member was used to track whether a domain
change requires updates to the device-table and IOMMU cache
flushes. The problem is, that access to this field is racy
since locking in the common mapping code-paths has been
In case of 4k video buffer, the allocation from a reserved memory is
taking a long time, ~500ms. This is root caused to the memset()
operations on the allocated memory which is consuming more cpu cycles.
Due to this delay, we see that initial frames are being dropped.
To fix this, we have wrapped
22 matches
Mail list logo
