Hello!
> x86 isn't problem-free in this space. An x86 VM is going to know that
> the 0xfee0 address range is special, it won't be backed by RAM and
> won't be a DMA target, thus we'll never attempt to map it for an iova
> address. However, if we run a non-x86 VM or a userspace driver, it
>
Hii all,
I am new to this mailing list and i need some help.I am trying
to add exynos iommu support for my board with exynos5250-soc for fimd.I am
getting this error at exynos_sysmmu_irq.I am pretty confused with it and
didn't know what to do.I strucked at this point.So please explain wh
On Wed, Jan 27, 2016 at 07:06:48PM +, Chalamarla, Tirumalesh wrote:
> On 1/26/16, 3:54 AM, "Will Deacon" wrote:
> >The problem is that you have shared state between multiple SMMU instances,
> >which I don't think is correct. I'm fine with a workaround, but I don't
> >want this logic to be used
On 1/26/16, 3:54 AM, "Will Deacon" wrote:
>On Tue, Jan 26, 2016 at 03:11:27AM +, Chalamarla, Tirumalesh wrote:
>> one my colleague points out, ASIDPNE also implementation defined.
>
>It looks pretty well defined to me, despite being a hint:
>
> This ASIDPNE indication is only a hint, a
On 1/26/16, 3:48 AM, "Robin Murphy" wrote:
>On 26/01/16 03:11, Chalamarla, Tirumalesh wrote:
>> one my colleague points out, ASIDPNE also implementation defined.
>
>ASIDPNE only covers whether the SMMU's TLBs may ignore broadcast
>_invalidation_ or not, not lookups. Broadcast TLB lookups ar
> -Original Message-
> From: Mark Rutland [mailto:mark.rutl...@arm.com]
> Sent: 27 January 2016 17:59
> To: Anup Patel
> Cc: Catalin Marinas; Joerg Roedel; Will Deacon; Robin Murphy; Sricharan R;
> Linux IOMMU; Linux ARM Kernel; Rob Herring; Pawel Moll; Ian Campbell; Kumar
> Gala; Device
On Wed, Jan 27, 2016 at 10:51:19AM +0530, Anup Patel wrote:
> This patch adds info about 'smmu-inst-as-data' DT option in ARM
> SMMUv1/SMMUv2 driver bindings document.
>
> Signed-off-by: Anup Patel
> Reviewed-by: Ray Jui
> Reviewed-by: Vikram Prakash
> Reviewed-by: Scott Branden
> ---
> Docum
Original Message
If irq table exists in old kernel create a new one and copy the content
of old irq table to the newly created.
Signed-off-by: Baoquan He
---
drivers/iommu/amd_iommu.c | 2 +-
drivers/iommu/amd_iommu_init.c | 43
From: Lada Trimasova
Trying to build a kernel for ARC with both options CONFIG_COMPILE_TEST
and CONFIG_IOMMU_IO_PGTABLE_LPAE enabled (e.g. as a result of "make
allyesconfig") results in the following build failure:
| CC drivers/iommu/io-pgtable-arm.o
| linux/drivers/iommu/io-pgtable-arm.c: In
Original Message
This is a clean up. In get_irq_table() only if DTE entry is changed
iommu_completion_wait() need be called. Otherwise no need to do it.
Signed-off-by: Baoquan He
---
drivers/iommu/amd_iommu.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
di
Original Message
These macro definitions are also needed by irq table copy function
later, so move them to amd_iommu_types.h.
Typo for your subject (defitions?).
Signed-off-by: Baoquan He
---
drivers/iommu/amd_iommu.c | 4
drivers/iommu/amd_iommu_types.h |
Original Message
In amd-vi spec bit[60:58] are only used to store the bit[14:12] of GCR3.
No any other useage is found in several versions of amd-vi spec. So remove
them in this patch.
Also,this patch also made me confusion, please keep FC bit here, bit[60]
should be PTE's
Original Message
In amd-vi spec the name of bit0 in DTE is V. But in code it's defined
as IOMMU_PTE_P. Here change it to IOMMU_PTE_V to make it be consistent
with spec.
Hi, Baoquan
This should be PR bit which means present, So maybe you got confusion
between DTE and PTE ta
On Tue, 2016-01-26 at 17:13 +, Robin Murphy wrote:
> Add a nearly-complete ARMv7 short descriptor implementation, omitting
> only a few legacy and CPU-centric aspects which shouldn't be necessary
> for IOMMU API use anyway.
>
> Signed-off-by: Yong Wu
> Signed-off-by: Robin Murphy
This looks
Hi Pavel,
On 01/26/2016 06:25 PM, Pavel Fedin wrote:
> Hello!
> I'd like just to clarify some things for myself and better wrap my head
> around it...
>
>> On x86 all accesses to the 1MB PA region [FEE0_h - FEF0_000h] are
>> directed
>> as interrupt messages: accesses to this special PA wi
15 matches
Mail list logo
