Hi Yong,
On Mon, Sep 30, 2019 at 2:42 PM Yong Wu wrote:
>
> The commit 4d689b619445 ("iommu/io-pgtable-arm-v7s: Convert to IOMMU API
> TLB sync") help move the tlb_sync of unmap from v7s into the iommu
> framework. It helps add a new function "mtk_iommu_iotlb_sync", But it
> lacked the dom->pgtlo
Hi Geert-san,
> From: Geert Uytterhoeven, Sent: Wednesday, October 2, 2019 3:06 AM
>
> As platform_get_irq() now prints an error when the interrupt does not
> exist, calling it gratuitously causes scary messages like:
>
> ipmmu-vmsa e674.mmu: IRQ index 0 not found
>
> Fix this by moving
From: Jean-Philippe Brucker
Some devices might support multiple DMA address spaces, in particular
those that have the PCI PASID feature. PASID (Process Address Space ID)
allows to share process address spaces with devices (SVA), partition a
device into VM-assignable entities (VFIO mdev) or simply
IOASID allocation may rely on platform specific methods. One use case is
that when running in the guest, in order to obtain system wide global
IOASIDs, emulated allocation interface is needed to communicate with the
host. Here we call these platform specific allocators custom allocators.
Custom IO
Guest shared virtual address (SVA) may require host to shadow guest
PASID tables. Guest PASID can also be allocated from the host via
enlightened interfaces. In this case, guest needs to bind the guest
mm, i.e. cr3 in guest physical address to the actual PASID table in
the host IOMMU. Nesting will
From: Yi L Liu
In any virtualization use case, when the first translation stage
is "owned" by the guest OS, the host IOMMU driver has no knowledge
of caching structure updates unless the guest invalidation activities
are trapped by the virtualizer and passed down to the host.
Since the invalidat
This set consists of IOMMU APIs to support SVA in the guest, a.k.a nested
SVA. As the complete SVA support is complex, we break down the enabling
effort into three stages:
1. PCI device direct assignment
2. Fault handling, especially page request service support
3. Mediated device assignment
Each
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" fo
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
s
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 al
From: "Angelo G. Del Regno"
Add a function to change the IOMMU pagetable addressing to
AArch32 LPAE or AArch64. If doing that, then this must be
done for each IOMMU context (not necessarily at the same time).
---
drivers/firmware/qcom_scm-32.c | 6 ++
drivers/firmware/qcom_scm-64.c | 15 +++
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 any
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 i
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 +
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 M
On Tue, Sep 03, 2019 at 01:30:59PM +0200, Krzysztof Wilczynski wrote:
> Remove and from being included
> directly as part of the include/linux/of_pci.h, and remove
> superfluous declaration of struct of_phandle_args.
>
> Move users of include to include
> and directly rather than rely on both
As platform_get_irq() now prints an error when the interrupt does not
exist, calling it gratuitously causes scary messages like:
ipmmu-vmsa e674.mmu: IRQ index 0 not found
Fix this by moving the call to platform_get_irq() down, where the
existence of the interrupt is mandatory.
Fixes: 77
From: Andrei Dulea
[ Upstream commit 6ccb72f8374e17d60b58a7bfd5570496332c54e2 ]
Downgrading an existing large mapping to a mapping using smaller
page-sizes works only for the mappings created with page-mode 7 (i.e.
non-default page size).
Treat large mappings created with page-mode 0 (i.e. defa
From: Andrei Dulea
[ Upstream commit 6ccb72f8374e17d60b58a7bfd5570496332c54e2 ]
Downgrading an existing large mapping to a mapping using smaller
page-sizes works only for the mappings created with page-mode 7 (i.e.
non-default page size).
Treat large mappings created with page-mode 0 (i.e. defa
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 al
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" fo
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 i
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
s
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 +
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 any
From: "Angelo G. Del Regno"
Add a function to change the IOMMU pagetable addressing to
AArch32 LPAE or AArch64. If doing that, then this must be
done for each IOMMU context (not necessarily at the same time).
---
drivers/firmware/qcom_scm-32.c | 6 ++
drivers/firmware/qcom_scm-64.c | 15 +
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 M
Hi Baolu,
On Tuesday, September 3, 2019 9:41:23 AM CEST Janusz Krzysztofik wrote:
> Hi Baolu,
>
> On Tuesday, September 3, 2019 3:29:40 AM CEST Lu Baolu wrote:
> > Hi Janusz,
> >
> > On 9/2/19 4:37 PM, Janusz Krzysztofik wrote:
> > >> I am not saying that keeping data is not acceptable. I just w
Since we have a generic helper, drop custom implementation in the driver.
Signed-off-by: Andy Shevchenko
Reviewed-by: Mika Westerberg
---
drivers/mmc/host/sdhci-acpi.c | 49 ---
1 file changed, 16 insertions(+), 33 deletions(-)
diff --git a/drivers/mmc/host/sdhc
There are users outside of ACPI realm which reimplementing the comparator
function to check if the given device matches to given HID and UID.
For better utilization, introduce a helper for everyone to use.
Signed-off-by: Andy Shevchenko
Reviewed-by: Mika Westerberg
---
drivers/acpi/utils.c
Since we have a generic helper, drop custom implementation in the driver.
Signed-off-by: Andy Shevchenko
Reviewed-by: Mika Westerberg
---
drivers/iommu/amd_iommu.c | 30 +-
1 file changed, 5 insertions(+), 25 deletions(-)
diff --git a/drivers/iommu/amd_iommu.c b/dri
We have a stub defined for the acpi_dev_get_first_match_dev() in acpi.h
for the case when CONFIG_ACPI=n.
Moreover, acpi_dev_put(), counterpart function, is already placed under
CONFIG_ACPI.
Thus, move acpi_dev_get_first_match_dev() under CONFIG_ACPI as well.
Fixes: 817b4d64da03 ("Introduce acpi_
Kernel documentation script complains that some of the function parameters
are not described:
drivers/acpi/utils.c:462: warning: Function parameter or member 'handle' not
described in 'acpi_handle_path'
drivers/acpi/utils.c:484: warning: Function parameter or member 'level' not
described in 'acp
Since we have a generic helper, drop custom implementation in the driver.
Signed-off-by: Andy Shevchenko
Reviewed-by: Mika Westerberg
---
drivers/acpi/acpi_lpss.c | 21 +++--
1 file changed, 3 insertions(+), 18 deletions(-)
diff --git a/drivers/acpi/acpi_lpss.c b/drivers/acpi/a
There are few users outside of ACPI realm that re-introduce a custom
solution to match ACPI device against HID/UID. Add a generic helper for
them.
The series is supposed to go via linux-pm tree.
In v3:
- correct logic in sdhci-acpi for qcom devices (Adrian)
- add Mika's Ack
In v2:
- add patch 2
On 24/09/19 10:37 PM, Andy Shevchenko wrote:
> Since we have a generic helper, drop custom implementation in the driver.
>
> Signed-off-by: Andy Shevchenko
> ---
> drivers/mmc/host/sdhci-acpi.c | 49 ---
> 1 file changed, 16 insertions(+), 33 deletions(-)
>
> dif
On Tue, Oct 01, 2019 at 03:37:08PM +0300, Adrian Hunter wrote:
> On 24/09/19 10:37 PM, Andy Shevchenko wrote:
> > Since we have a generic helper, drop custom implementation in the driver.
> > - if (strcmp(hid, "QCOM8051"))
> > + if (acpi_dev_hid_uid_match(adev, "QCOM8051", NULL))
>
> Logic is
On Tue, Oct 01, 2019 at 12:38:54PM +0300, Mika Westerberg wrote:
> On Tue, Sep 24, 2019 at 10:37:36PM +0300, Andy Shevchenko wrote:
> > There are users outside of ACPI realm which reimplementing the comparator
> > function to check if the given device matches to given HID and UID.
> >
> > For bett
On Tue, Sep 24, 2019 at 10:37:39PM +0300, Andy Shevchenko wrote:
> Since we have a generic helper, drop custom implementation in the driver.
>
> Signed-off-by: Andy Shevchenko
Reviewed-by: Mika Westerberg
___
iommu mailing list
iommu@lists.linux-found
On Tue, Sep 24, 2019 at 10:37:37PM +0300, Andy Shevchenko wrote:
> Since we have a generic helper, drop custom implementation in the driver.
>
> Signed-off-by: Andy Shevchenko
Reviewed-by: Mika Westerberg
___
iommu mailing list
iommu@lists.linux-found
On Tue, Sep 24, 2019 at 10:37:38PM +0300, Andy Shevchenko wrote:
> Since we have a generic helper, drop custom implementation in the driver.
>
> Signed-off-by: Andy Shevchenko
Reviewed-by: Mika Westerberg
___
iommu mailing list
iommu@lists.linux-found
On Tue, Sep 24, 2019 at 10:37:36PM +0300, Andy Shevchenko wrote:
> There are users outside of ACPI realm which reimplementing the comparator
> function to check if the given device matches to given HID and UID.
>
> For better utilization, introduce a helper for everyone to use.
>
> Signed-off-by:
On Tue, Sep 24, 2019 at 10:37:35PM +0300, Andy Shevchenko wrote:
> We have a stub defined for the acpi_dev_get_first_match_dev() in acpi.h
> for the case when CONFIG_ACPI=n.
>
> Moreover, acpi_dev_put(), counterpart function, is already placed under
> CONFIG_ACPI.
>
> Thus, move acpi_dev_get_firs
On Tue, Sep 24, 2019 at 10:37:34PM +0300, Andy Shevchenko wrote:
> Kernel documentation script complains that some of the function parameters
> are not described:
>
> drivers/acpi/utils.c:462: warning: Function parameter or member 'handle' not
> described in 'acpi_handle_path'
> drivers/acpi/util
44 matches
Mail list logo
