From: Wan Zongshun
AMD has more drivers will use ACPI to platform bus driver later,
all those devices need iommu support, for example: eMMC driver.
For latest AMD eMMC controller, it will utilize sdhci-acpi.c driver,
which will rely on platform bus to match device and driver, where we
will set '
On 5/10/2016 4:22 AM, Rob Herring wrote:
> On Mon, May 09, 2016 at 04:00:12PM +0800, honghui.zh...@mediatek.com wrote:
>> From: Honghui Zhang
>>
>> This patch defines the local arbitor port IDs for mediatek SoC MT2701 and
>> add descriptions of binding for mediatek generation one iommu and smi.
>>
On Wed, 4 May 2016 14:06:19 +0200
Eric Auger wrote:
> Hi Alex,
> On 05/04/2016 01:54 PM, Eric Auger wrote:
> > This patch allows the user-space to retrieve the MSI geometry. The
> > implementation is based on capability chains, now also added to
> > VFIO_IOMMU_GET_INFO.
>
> If you prefer we co
On Wed, 4 May 2016 11:54:18 +
Eric Auger wrote:
> This patch allows the user-space to retrieve the MSI geometry. The
> implementation is based on capability chains, now also added to
> VFIO_IOMMU_GET_INFO.
>
> The returned info comprise:
> - whether the MSI IOVA are constrained to a reserve
On Wed, 4 May 2016 11:54:16 +
Eric Auger wrote:
> On x86 IRQ remapping is abstracted by the IOMMU. On ARM this is abstracted
> by the msi controller. vfio_safe_irq_domain allows to check whether
> interrupts are "safe" for a given device. They are if the device does
> not use MSI
Are we sur
On Wed, 4 May 2016 11:54:13 +
Eric Auger wrote:
> In our RB-tree we now have slots of different types (USER and RESERVED).
> It becomes useful to be able to search for dma slots of a specific type or
> any type. This patch proposes an implementation for that modality and also
> changes the e
On Wed, 4 May 2016 11:54:14 +
Eric Auger wrote:
> Before allowing the end-user to create VFIO_IOVA_RESERVED dma slots,
> let's implement the expected behavior for removal and replay. As opposed
> to user dma slots, IOVAs are not systematically bound to PAs and PAs are
> not pinned. VFIO just
On Mon, May 09, 2016 at 01:24:02PM +0200, Joerg Roedel wrote:
>On Sun, May 08, 2016 at 01:22:53PM +, Wei Yang wrote:
>> >Wei Yang (4):
>> > iommu/vt-d: replace *hdr with {drhd/atsr}[0] in struct
>> >dmar_{drhd/atsr}_unit
>> > iommu/vt-d: use zero-sized array in DMAR related ACPI structure
On 05/09/2016 10:13 AM, Paolo Bonzini wrote:
>
>
> On 02/05/2016 20:31, Andy Lutomirski wrote:
>> And did the SEV implementation remember to encrypt the guest register
>> state? Because, if not, everything of importance will leak out
>> through the VMCB and/or GPRs.
>
> No, it doesn't. And SEV
On Wed, 4 May 2016 11:40:03 +
Eric Auger wrote:
> iommu_get/put_msi_cookie allocates/frees the resource used to store
> and ref count the MSI doorbell mappings. iommu_msi_set_aperture
> initializes the iova domain used for MSI IOVA allocation and sets the
> iommu domain's msi geometry.
>
>
On Mon, May 09, 2016 at 04:00:12PM +0800, honghui.zh...@mediatek.com wrote:
> From: Honghui Zhang
>
> This patch defines the local arbitor port IDs for mediatek SoC MT2701 and
> add descriptions of binding for mediatek generation one iommu and smi.
>
> Signed-off-by: Honghui Zhang
> ---
> .../
A unconfirmed hardware bug prevents channel 0 and 15 to be used by the
DMAC together with the IPMMU. The DMAC driver will disable the channels
reducing the effective number of channels to 14 per DMAC.
Signed-off-by: Niklas Söderlund
Acked-by: Laurent Pinchart
---
arch/arm/boot/dts/r8a7791.dtsi
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: Laurent Pinchart
---
arch/arm/mm/dma-mapping.c | 63 ++
Group slave address and transfer size in own structs for source and
destination. This is in preparation for hooking up the dma-mapping API
to the slave addresses.
Signed-off-by: Niklas Söderlund
Reviewed-by: Laurent Pinchart
---
drivers/dma/sh/rcar-dmac.c | 38 ++
Enable slave transfers to a device behind a IPMMU by mapping the slave
addresses using the dma-mapping API.
Signed-off-by: Niklas Söderlund
---
drivers/dma/sh/rcar-dmac.c | 82 +-
1 file changed, 74 insertions(+), 8 deletions(-)
diff --git a/drivers/d
A unconfirmed hardware bug prevents channel 0 and 15 to be used by the
DMAC together with the IPMMU. The DMAC driver will disable the channels
reducing the effective number of channels to 14 per DMAC.
Signed-off-by: Niklas Söderlund
Acked-by: Laurent Pinchart
---
arch/arm/boot/dts/r8a7790.dtsi
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
---
Documentation/DMA-API.txt | 22 +-
include/linux/dma-mapping.h | 36
2 files ch
A MMIO mapped resource can not be represented by a struct page so a new
debug type is needed to handle this. This patch add such type and
functionality to add/remove entries and how to translate them to a
physical address.
Signed-off-by: Niklas Söderlund
---
include/linux/dma-debug.h | 19 ++
Hi,
This series tries to solve the problem with DMA with device registers
(MMIO registers) that are behind an IOMMU for the rcar-dmac driver. A
recent patch '9575632 (dmaengine: make slave address physical)'
clarifies that DMA slave address provided by clients is the physical
address. This puts th
Add methods to handle mapping of device resources from a physical
address. This is needed for example to be able to map MMIO FIFO
registers to a IOMMU.
Signed-off-by: Niklas Söderlund
Reviewed-by: Laurent Pinchart
---
include/linux/dma-mapping.h | 6 ++
1 file changed, 6 insertions(+)
diff
Now that we can accurately reflect the context format we choose for each
domain, do that instead of imposing the global lowest-common-denominator
restriction and potentially ending up with nothing. We currently have a
strict 1:1 correspondence between domains and context banks, so we don't
need to
On Mon, May 09, 2016 at 08:17:12PM +0800, Wan Zongshun wrote:
> Currently, Only New eMMC driver will rely on this sdhci-acpi.c, but
> I could not find a suitable ifdef XXX micro to limit this
> platform_bus_type here like AMBA bus type before.
>
> Do you think this MMC_SDHCI_ACPI is ok?
Okay, loo
On Mon, May 09, 2016 at 04:18:39PM +0100, Robin Murphy wrote:
> Bah, I saw last week's "Merge remote-tracking branch
> 'will/for-joerg/arm-smmu/updates' into HEAD" commit on that branch
> without spotting it was no longer up to date, sorry. Yes, it's
> probably safest if I rebase on top of your mer
On 5/9/16, 12:48 AM, "Eric Auger" wrote:
>Hi Chalarmala,
>On 05/05/2016 07:44 PM, Chalamarla, Tirumalesh wrote:
>> Hi Eric,
>>
>> Does this series supports gicv3-its emulation?
>> Do we have a tree with all the dependent patches
>GICv3 ITS emulation support comes with:
>[PATCH v4 00/12] KVM
On 09/05/16 15:51, Joerg Roedel wrote:
On Mon, May 09, 2016 at 12:45:39PM +0100, Robin Murphy wrote:
Thanks a lot! I was expecting to pick this up again after the merge
window and post an updated version then; as you may already have
found, patch 5 conflicts somewhat with the SMMUv2 context form
On 02/05/2016 20:31, Andy Lutomirski wrote:
> And did the SEV implementation remember to encrypt the guest register
> state? Because, if not, everything of importance will leak out
> through the VMCB and/or GPRs.
No, it doesn't. And SEV is very limited unless you paravirtualize
everything.
Fo
On Mon, May 09, 2016 at 12:45:39PM +0100, Robin Murphy wrote:
> Thanks a lot! I was expecting to pick this up again after the merge
> window and post an updated version then; as you may already have
> found, patch 5 conflicts somewhat with the SMMUv2 context format
> changes in Will's updates branc
Hi Joerg,
On 09/05/16 12:21, Joerg Roedel wrote:
On Thu, Apr 07, 2016 at 06:42:03PM +0100, Robin Murphy wrote:
Hi all,
Since this area seems to be in vogue at the moment, here's what I was
working on when the related patches[1][2] popped up, which happens to
be more or less the intersection of
On Sun, May 08, 2016 at 01:22:53PM +, Wei Yang wrote:
> >Wei Yang (4):
> > iommu/vt-d: replace *hdr with {drhd/atsr}[0] in struct
> >dmar_{drhd/atsr}_unit
> > iommu/vt-d: use zero-sized array in DMAR related ACPI structures
> > iommu/vt-d: check Register Base Address at the beginning of
On Thu, Apr 07, 2016 at 06:42:03PM +0100, Robin Murphy wrote:
> Hi all,
>
> Since this area seems to be in vogue at the moment, here's what I was
> working on when the related patches[1][2] popped up, which happens to
> be more or less the intersection of both. As I recycled some of Will's
> old s
On 28/04/2016 17:37, Michael S. Tsirkin wrote:
> > All the internally-emulated devices *can* be either translated or
> > untranslated. That's just a matter of software. Surely, you currently
> > *can't* have translated assigned devices (until someone implements the
> > whole VT-d page table shado
On Thu, Apr 14, 2016 at 09:28:53AM -0400, Wan Zongshun wrote:
> From: Wan Zongshun
>
> AMD has more drivers will use ACPI to platform bus driver later,
> all those devices need iommu support, such as eMMC acpi driver.
>
> Signed-off-by: Wan Zongshun
> ---
> drivers/iommu/amd_iommu.c | 4
>
On 08/05/16 10:33, Jayachandran C via iommu wrote:
Add a new flag PCI_DEV_FLAGS_DMA_ALIAS_ROOT to limit the DMA alias
search to go no further than the bridge where the IOMMU is attached.
This has been added to support Broadcom's Vulcan which has the SMMUv3
and GIC ITS associated with an intermed
On Wed, May 04, 2016 at 02:45:31PM +0100, Will Deacon wrote:
> Peng Fan (1):
> iommu/arm-smmu: Clear cache lock bit of ACR
>
> Robin Murphy (7):
> iommu/arm-smmu: Differentiate specific implementations
> iommu/arm-smmu: Convert ThunderX workaround to new method
> iommu/arm-
On 09/05/16 10:37, Robin Murphy wrote:
Hi Niklas,
On 08/05/16 11:59, Niklas Söderlund wrote:
Hi,
While using CONFIG_DMA_API_DEBUG i came across this warning which I
think is a false positive. As shown dma_sync_single_for_device() are
called from the dma_map_single() call path. This triggers th
Hi Niklas,
On 08/05/16 11:59, Niklas Söderlund wrote:
Hi,
While using CONFIG_DMA_API_DEBUG i came across this warning which I
think is a false positive. As shown dma_sync_single_for_device() are
called from the dma_map_single() call path. This triggers the warning
since the dma-debug code have
On Sun, May 08, 2016 at 12:59:56PM +0200, Niklas Söderlund wrote:
> The call to dma_sync_single_for_device() can be reached from
> dma_map_single(). If CONFIG_DMA_API_DEBUG is enabled this would result
> in a check that the mapping being synced is valid. Since the call to
> dma_map_single is not ye
Hi Chalamarla,
On 05/05/2016 09:23 PM, Chalamarla, Tirumalesh wrote:
>
>
>
>
>
> On 5/4/16, 4:54 AM, "linux-arm-kernel on behalf of Eric Auger"
> eric.au...@linaro.org> wrote:
>
>> On x86 IRQ remapping is abstracted by the IOMMU. On ARM this is abstracted
>> by the msi controller. vfio_safe
From: Honghui Zhang
Mediatek SoC's M4U have two generations of HW architcture. Generation one
use flat, one layer pagetable, and was shipped with ARM architecture, it
only support 4K size page mapping. MT2701 SoC use this generation one
m4u HW. Generation two uses the ARM short-descriptor transla
From: Honghui Zhang
Move the struct defines of mtk iommu into a new header files for
common use.
Signed-off-by: Honghui Zhang
---
drivers/iommu/mtk_iommu.c | 62 +---
drivers/iommu/mtk_iommu.h | 90 +++
2 files changed, 91
From: Honghui Zhang
Mediatek's m4u(Multimedia Memory Management Unit) and SMI(Smart
Multimedia Interface)have two generations HW. They basically sharing the
same hardware block diagram, but have some difference as below:
Generation one m4u only support one layer, flat pagetable addressing, a
From: Honghui Zhang
Add the dtsi node of iommu and smi for mt2701.
Signed-off-by: Honghui Zhang
---
arch/arm/boot/dts/mt2701.dtsi | 51 +++
1 file changed, 51 insertions(+)
diff --git a/arch/arm/boot/dts/mt2701.dtsi b/arch/arm/boot/dts/mt2701.dtsi
index
From: Honghui Zhang
Mediatek SMI have two generation HW architecture, mt8173 use the
secondary generation of SMI HW while mt2701 use the first generation
HW of SMI.
There's slight differences between the two generation, for generation 2,
the register which control the iommu port access PA or IOV
From: Honghui Zhang
This patch defines the local arbitor port IDs for mediatek SoC MT2701 and
add descriptions of binding for mediatek generation one iommu and smi.
Signed-off-by: Honghui Zhang
---
.../devicetree/bindings/iommu/mediatek,iommu.txt | 13 +++-
.../memory-controllers/mediatek,sm
Hi Chalamarla,
On 05/05/2016 09:22 PM, Chalamarla, Tirumalesh wrote:
>
>
>
>
>
> On 5/4/16, 4:54 AM, "linux-arm-kernel on behalf of Eric Auger"
> eric.au...@linaro.org> wrote:
>
>> The user is allowed to register a reserved MSI IOVA range by using the
>> DMA MAP API and setting the new flag
Hi Chalarmala,
On 05/05/2016 07:44 PM, Chalamarla, Tirumalesh wrote:
> Hi Eric,
>
> Does this series supports gicv3-its emulation?
> Do we have a tree with all the dependent patches
GICv3 ITS emulation support comes with:
[PATCH v4 00/12] KVM: arm64: GICv3 ITS emulation
http://permalink.gmane.org/
46 matches
Mail list logo
