This reverts commit 82db33dc5e49fb625262d81125625d07a0d6184e.
After the commit 29859aeb8a6e ("iommu/io-pgtable-arm-v7s: Abort
allocation when table address overflows the PTE"), v7s will return fail
if the page table allocation isn't expected. this PHYS_OFFSET check
is unnecessary now.
And this
Qcom's implementation of arm,mmu-500 works well with current
arm-smmu driver implementation. Adding a soc specific compatible
along with arm,mmu-500 makes the bindings future safe.
Signed-off-by: Vivek Gautam
Reviewed-by: Rob Herring
Cc: Will Deacon
---
Hi Joerg,
I am picking this out
On Thu, Dec 13, 2018 at 09:41:50AM +0100, Christian Zigotzky wrote:
> Today I tried the first patch (0001-get_required_mask.patch) with the last
> good commit (977706f9755d2d697aa6f45b4f9f0e07516efeda). Unfortunately this
> patch is already included in the last good commit
>
Hi Oza,
Thank you for the review.
Please find my comments in lined.
On Thu, Dec 13, 2018 at 11:33 AM wrote:
>
> On 2018-12-12 11:16, Srinath Mannam wrote:
> > IPROC host has the limitation that it can use
> > only those address ranges given by dma-ranges
> > property as inbound address.
> > So
On 12 December 2018 at 3:39PM, Christian Zigotzky wrote:
Hi Christoph,
Thanks a lot for your reply. I will test your patches tomorrow.
Cheers,
Christian
Sent from my iPhone
On 12. Dec 2018, at 15:15, Christoph Hellwig wrote:
Thanks for bisecting. I've spent some time going over the
On 2018-12-13 9:19 am, Yong Wu wrote:
This reverts commit 82db33dc5e49fb625262d81125625d07a0d6184e.
After the commit 29859aeb8a6e ("iommu/io-pgtable-arm-v7s: Abort
allocation when table address overflows the PTE"), v7s will return fail
if the page table allocation isn't expected. this
On Thu, Dec 13, 2018 at 02:35:07PM +0530, Vivek Gautam wrote:
> Qcom's implementation of arm,mmu-500 works well with current
> arm-smmu driver implementation. Adding a soc specific compatible
> along with arm,mmu-500 makes the bindings future safe.
>
> Signed-off-by: Vivek Gautam
> Reviewed-by:
On 2018-12-13 16:02, Srinath Mannam wrote:
Few SOCs have limitation that their PCIe host can't allow few inbound
address ranges.
Allowed inbound address ranges are listed in dma-ranges DT property and
this address ranges are required to do IOVA mapping.
Remaining address ranges have to be
IPROC host has the limitation that it can use only those address ranges
given by dma-ranges property as inbound address.
So that the memory address holes in dma-ranges should be reserved to
allocate as DMA address.
Inbound address of host accessed by pcie devices will not be translated
before it
On Thu, Dec 13, 2018 at 12:19:26PM +0100, Christian Zigotzky wrote:
> I tried it again but I get the following error message:
>
> MODPOST vmlinux.o
> arch/powerpc/kernel/dma-iommu.o: In function `.dma_iommu_get_required_mask':
> (.text+0x274): undefined reference to `.dma_direct_get_required_mask'
On 13 December 2018 at 10:10AM, Christoph Hellwig wrote:
On Thu, Dec 13, 2018 at 09:41:50AM +0100, Christian Zigotzky wrote:
Today I tried the first patch (0001-get_required_mask.patch) with the last
good commit (977706f9755d2d697aa6f45b4f9f0e07516efeda). Unfortunately this
patch is already
On 2018-12-13 14:47, Srinath Mannam wrote:
Hi Oza,
Thank you for the review.
Please find my comments in lined.
On Thu, Dec 13, 2018 at 11:33 AM wrote:
On 2018-12-12 11:16, Srinath Mannam wrote:
> IPROC host has the limitation that it can use
> only those address ranges given by dma-ranges
>
Add a dma_resv parameter in pci host bridge structure to hold resource
entries list of memory regions for which IOVAs have to reserve.
PCIe host driver will add resource entries to this list based on its
requirements.
Few inbound address ranges can't be allowed by few PCIe host, so those
address
PCI host bridge has list of resource entries contain address ranges for
which IOVA address mapping has to be reserve.
These address ranges are the address holes in dma-ranges DT property.
It is similar to PCI IO resources address ranges reserving in IOMMU for
each EP connected to host bridge.
Few SOCs have limitation that their PCIe host can't allow few inbound
address ranges.
Allowed inbound address ranges are listed in dma-ranges DT property and
this address ranges are required to do IOVA mapping.
Remaining address ranges have to be reserved in IOVA mapping.
PCIe Host driver of
On 2018-12-12 3:27 pm, Auger Eric wrote:
Hi,
On 12/12/18 3:56 PM, Michael S. Tsirkin wrote:
On Fri, Dec 07, 2018 at 06:52:31PM +, Jean-Philippe Brucker wrote:
Sorry for the delay, I wanted to do a little more performance analysis
before continuing.
On 27/11/2018 18:10, Michael S. Tsirkin
On Wed, Dec 12, 2018 at 10:17:02AM +0100, Joerg Roedel wrote:
> On Tue, Dec 11, 2018 at 08:08:48PM +, Will Deacon wrote:
> > The following changes since commit 9ff01193a20d391e8dbce4403dd5ef87c7eaaca6:
> >
> > Linux 4.20-rc3 (2018-11-18 13:33:44 -0800)
> >
> > are available in the git
Hi Joerg,
On 12/12/2018 10:35, Joerg Roedel wrote:
> Hi,
>
> to make progress on this, we should first agree on the protocol used
> between guest and host. I have a few points to discuss on the protocol
> first.
>
> On Tue, Dec 11, 2018 at 06:20:57PM +, Jean-Philippe Brucker wrote:
>> [1]
On Thu, Dec 13, 2018 at 12:50:29PM +, Jean-Philippe Brucker wrote:
> * DMA ops for x86 (see "HACK" commit). I'd like to use dma-iommu but I'm
> not sure how to implement the glue that sets dma_ops properly.
http://git.infradead.org/users/hch/misc.git/shortlog/refs/heads/dma-iommu-ops
On 13 December 2018 at 12:25PM, Christoph Hellwig wrote:
On Thu, Dec 13, 2018 at 12:19:26PM +0100, Christian Zigotzky wrote:
I tried it again but I get the following error message:
MODPOST vmlinux.o
arch/powerpc/kernel/dma-iommu.o: In function `.dma_iommu_get_required_mask':
(.text+0x274):
On Thu, Dec 13, 2018 at 07:45:57PM +, Lendacky, Thomas wrote:
> So I think this needs to be __phys_to_dma() here. I only recently got a
> system that had a device where the driver only supported 32-bit DMA and
> found that when SME is active this returns 0 and causes the driver to fail
> to
I've pulled v2 with the ia64 into dma-mapping for-next. This should
give us a little more than a week in linux-next to sort out any
issues.
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
On 13 December 2018 at 6:48PM, Christian Zigotzky wrote:
On 13 December 2018 at 2:34PM, Christian Zigotzky wrote:
On 13 December 2018 at 12:25PM, Christoph Hellwig wrote:
On Thu, Dec 13, 2018 at 12:19:26PM +0100, Christian Zigotzky wrote:
I tried it again but I get the following error
The dma_direct_supported() function intends to check the DMA mask against
specific values. However, the phys_to_dma() function includes the SME
encryption mask, which defeats the intended purpose of the check. This
results in drivers that support less than 48-bit DMA (SME encryption mask
is bit
Document RZ/G2E (R8A774C0) SoC bindings.
Signed-off-by: Fabrizio Castro
---
Documentation/devicetree/bindings/iommu/renesas,ipmmu-vmsa.txt | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/iommu/renesas,ipmmu-vmsa.txt
On 10/04/2018 10:13 AM, Alexander Duyck wrote:
> On Thu, Oct 4, 2018 at 4:25 AM Robin Murphy wrote:
>>
>> On 04/10/18 00:48, Alexander Duyck wrote:
>>> It appears that in commit 9d7a224b463e ("dma-direct: always allow dma mask
>>> <= physiscal memory size") the logic of the test was changed from
Support RZ/G2E (a.k.a. R8A774C0) IPMMU.
Signed-off-by: Fabrizio Castro
---
drivers/iommu/ipmmu-vmsa.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/iommu/ipmmu-vmsa.c b/drivers/iommu/ipmmu-vmsa.c
index 32e572b..8074dec 100644
--- a/drivers/iommu/ipmmu-vmsa.c
+++
On 13 December 2018 at 2:34PM, Christian Zigotzky wrote:
On 13 December 2018 at 12:25PM, Christoph Hellwig wrote:
On Thu, Dec 13, 2018 at 12:19:26PM +0100, Christian Zigotzky wrote:
I tried it again but I get the following error message:
MODPOST vmlinux.o
arch/powerpc/kernel/dma-iommu.o: In
28 matches
Mail list logo
