On 3/30/2017 7:16 PM, Rob Clark wrote:
On Thu, Mar 30, 2017 at 2:19 AM, Archit Taneja wrote:
Hi,
On 03/14/2017 08:48 PM, Rob Clark wrote:
An iommu driver for Qualcomm "B" family devices which do not completely
implement the ARM SMMU spec. These devices have context-bank register
layout th
On 2017/3/23 20:11, Robin Murphy wrote:
> On 22/03/17 06:27, Zhen Lei wrote:
>> Below judgement can only be satisfied at the last time, which produced 2N
>> judgements(suppose N times failed, 0 or 1 time successed) in vain.
>>
>> if ((pfn >= iova->pfn_lo) && (pfn <= iova->pfn_hi)) {
>> retur
Because the problem of my email-server, all patches sent to Joerg Roedel
failed.
So I repost this email again.
On 2017/3/24 11:43, Leizhen (ThunderTown) wrote:
>
>
> On 2017/3/23 21:01, Robin Murphy wrote:
>> On 22/03/17 06:27, Zhen Lei wrote:
>>> Reserve the first granule size memory(start a
On 2017/3/24 10:27, Leizhen (ThunderTown) wrote:
>
>
> On 2017/3/23 19:42, Robin Murphy wrote:
>> On 22/03/17 06:27, Zhen Lei wrote:
>>> Keep these four variables type consistent with the paramters of function
>>> __alloc_and_insert_iova_range and the members of struct iova:
>>>
>>> 1. static i
I'm not sure whether the compiler can optimize it, but move it out will
be better. At least, it does not require lock protection.
Signed-off-by: Zhen Lei
---
drivers/iommu/iova.c | 22 ++
1 file changed, 10 insertions(+), 12 deletions(-)
diff --git a/drivers/iommu/iova.c b/d
Below judgement can only be satisfied at the last time, which produced 2N
judgements(suppose N times failed, 0 or 1 time successed) in vain.
if ((pfn >= iova->pfn_lo) && (pfn <= iova->pfn_hi)) {
return iova;
}
Signed-off-by: Zhen Lei
---
drivers/iommu/iova.c | 9 +++--
1 file change
Keep these four variables type consistent with the paramters of function
__alloc_and_insert_iova_range and the members of struct iova:
1. static int __alloc_and_insert_iova_range(struct iova_domain *iovad,
unsigned long size, unsigned long limit_pfn,
2. struct iova {
unsig
To make sure iovad->cached32_node and iovad->cached64_node can exactly
control dma32 and dma64 area. It also help us to remove the parameter
pfn_32bit of init_iova_domain.
Signed-off-by: Zhen Lei
---
drivers/iommu/amd_iommu.c| 7 ++-
drivers/iommu/dma-iommu.c| 22 +--
v1 -> v2:
Because the problem of my email-server, all patches sent to Joerg Roedel
failed.
So I repost all these patches again, there is no changes.
v1:
64 bits devices is very common now. But currently we only defined a
cached32_node
to optimize the allocation performance of dma32, and I saw s
Currently we always search free iova space for dma64 begin at the last
node of iovad rb-tree. In the worst case, there maybe too many nodes exist
at the tail, so that we should traverse many times for the first loop in
__alloc_and_insert_iova_range. As we traced, more than 10K times for the
case of
For case 2 and 3, adjust cached32_node to the new place, case 1 keep no
change.
For example:
case1: (the right part was allocated)
|--|
|<-free>|<--new_iova-->|
|
|
cached32_node
case2: (all was allocated)
|---
Reserve the first granule size memory(start at start_pfn) as boundary
iova, to make sure that iovad->cached32_node can not be NULL in future.
Meanwhile, changed the assignment of iovad->cached32_node from rb_next to
rb_prev of &free->node in function __cached_rbnode_delete_update.
Signed-off-by: Z
On Thu, Mar 30, 2017 at 05:56:32PM +0100, Robin Murphy wrote:
> On relatively slow development platforms and software models, the
> inefficiency of our TLB sync loop tends not to show up - for instance on
> a Juno r1 board I typically see the TLBI has completed of its own accord
> by the time we ge
On Thu, Mar 30, 2017 at 05:56:30PM +0100, Robin Murphy wrote:
> ARM_AMMU_CB() is calculated relative to ARM_SMMU_CB_BASE(), but the
> latter is never of use on its own, and what we end up with is the same
> ARM_SMMU_CB_BASE() + ARM_AMMU_CB() expression being duplicated at every
> callsite. Folding
On Thu, Mar 30, 2017 at 05:56:29PM +0100, Robin Murphy wrote:
> Calculating ASIDs/VMIDs dynamically from arm_smmu_cfg was a neat trick,
> but the global uniqueness workaround makes it somewhat more awkward, and
> means we end up having to pass extra state around in certain cases just
> to keep a ha
Calculating ASIDs/VMIDs dynamically from arm_smmu_cfg was a neat trick,
but the global uniqueness workaround makes it somewhat more awkward, and
means we end up having to pass extra state around in certain cases just
to keep a handle on the offset.
We already have 16 bits going spare in arm_smmu_c
On relatively slow development platforms and software models, the
inefficiency of our TLB sync loop tends not to show up - for instance on
a Juno r1 board I typically see the TLBI has completed of its own accord
by the time we get to the sync, such that the latter finishes instantly.
However, on l
ARM_AMMU_CB() is calculated relative to ARM_SMMU_CB_BASE(), but the
latter is never of use on its own, and what we end up with is the same
ARM_SMMU_CB_BASE() + ARM_AMMU_CB() expression being duplicated at every
callsite. Folding the two together gives us a self-contained context
bank accessor which
TLB synchronisation typically involves the SMMU blocking all incoming
transactions until the TLBs report completion of all outstanding
operations. In the common SMMUv2 configuration of a single distributed
SMMU serving multiple peripherals, that means that a single unmap
request has the potential t
Hi Will,
Here's a quick v2 to address your comments and drop the needless meddling
(whaddaya know, it makes the whole lot look simpler!)
I'll put it on my list to take a look at SMMUv3 queue polling as suggested.
Robin.
Robin Murphy (4):
iommu/arm-smmu: Simplify ASID/VMID handling
iommu/arm
On 30/03/17 15:37, Will Deacon wrote:
> Hi Robin,
>
> This mostly looks great, but I have a couple of minor comments below.
>
> On Tue, Mar 07, 2017 at 06:09:07PM +, Robin Murphy wrote:
>> TLB synchronisation typically involves the SMMU blocking all incoming
>> transactions until the TLBs rep
>-Original Message-
>From: Daniel Drake [mailto:dr...@endlessm.com]
>Sent: Thursday, March 30, 2017 7:15 PM
>To: Nath, Arindam
>Cc: j...@8bytes.org; Deucher, Alexander; Bridgman, John; amd-
>g...@lists.freedesktop.org; iommu@lists.linux-foundation.org; Suthikulpanit,
>Suravee; Linux Upstrea
On Tue, Mar 07, 2017 at 06:09:03PM +, Robin Murphy wrote:
> The discussion around context-level access for Qualcomm SMMUs reminded
> me to dig up this patch I started ages ago and finish it off. As it's
> ended up, it's now a mini-series, with some new preparatory cleanup
> manifesting as patch
On Thu, Mar 23, 2017 at 05:59:40PM +, Robin Murphy wrote:
> On relatively slow development platforms and software models, the
> inefficiency of our TLB sync loop tends not to show up - for instance on
> a Juno r1 board I typically see the TLBI has completed of its own accord
> by the time we ge
Hi Robin,
This mostly looks great, but I have a couple of minor comments below.
On Tue, Mar 07, 2017 at 06:09:07PM +, Robin Murphy wrote:
> TLB synchronisation typically involves the SMMU blocking all incoming
> transactions until the TLBs report completion of all outstanding
> operations. In
On 30/03/17 12:53, Geert Uytterhoeven wrote:
> Hi Robin,
>
> On Thu, Mar 30, 2017 at 1:46 PM, Robin Murphy wrote:
>> On 30/03/17 12:16, Andrzej Hajda wrote:
>> [...]
>>> I guess Geert's proposition to create pages permanently is also not
>>> acceptable[2]. So how to fix crashes which appe
Hi Robin,
On Tue, Mar 07, 2017 at 06:09:04PM +, Robin Murphy wrote:
> We currently warn if the firmware-described region size differs from the
> SMMU address space size reported by the hardware, but continue to use
> the former to calculate where our context bank base should be,
> effectively
On Thu, Mar 30, 2017 at 2:19 AM, Archit Taneja wrote:
> Hi,
>
> On 03/14/2017 08:48 PM, Rob Clark wrote:
>>
>> An iommu driver for Qualcomm "B" family devices which do not completely
>> implement the ARM SMMU spec. These devices have context-bank register
>> layout that is similar to ARM SMMU, bu
On Thu, Mar 30, 2017 at 12:23 AM, Nath, Arindam wrote:
> Daniel, did you get chance to test this patch?
Not yet. Should we test it alone or alongside "PCI: Blacklist AMD
Stoney GPU devices for ATS"?
Thanks
Daniel
___
iommu mailing list
iommu@lists.linu
Hi Robin,
On Thu, Mar 30, 2017 at 1:46 PM, Robin Murphy wrote:
> On 30/03/17 12:16, Andrzej Hajda wrote:
> [...]
>> I guess Geert's proposition to create pages permanently is also not
>> acceptable[2]. So how to fix crashes which appeared after patch adding
> If I'm not mistaken, crea
On 30/03/17 12:16, Andrzej Hajda wrote:
[...]
> I guess Geert's proposition to create pages permanently is also not
> acceptable[2]. So how to fix crashes which appeared after patch adding
If I'm not mistaken, creating the pages permanently is what the
!DMA_ATTR_FORCE_CONTIGUOUS d
Hi Robin,
On 30.03.2017 12:44, Robin Murphy wrote:
> On 30/03/17 09:30, Andrzej Hajda wrote:
>> On 30.03.2017 09:40, Geert Uytterhoeven wrote:
>>> Hi Andrzej,
>>>
>>> On Thu, Mar 30, 2017 at 8:51 AM, Andrzej Hajda wrote:
On 29.03.2017 17:33, Robin Murphy wrote:
> On 29/03/17 16:12, Andrz
On 30/03/17 09:30, Andrzej Hajda wrote:
> On 30.03.2017 09:40, Geert Uytterhoeven wrote:
>> Hi Andrzej,
>>
>> On Thu, Mar 30, 2017 at 8:51 AM, Andrzej Hajda wrote:
>>> On 29.03.2017 17:33, Robin Murphy wrote:
On 29/03/17 16:12, Andrzej Hajda wrote:
> On 29.03.2017 14:55, Robin Murphy wrot
On Tue, Mar 28, 2017 at 7:43 PM, Rob Herring wrote:
> On Tue, Mar 28, 2017 at 12:27 AM, Oza Oza wrote:
>> On Mon, Mar 27, 2017 at 8:16 PM, Rob Herring wrote:
>>> On Sat, Mar 25, 2017 at 12:31 AM, Oza Pawandeep
>>> wrote:
it is possible that PCI device supports 64-bit DMA addressing,
On Thu, Mar 30, 2017 at 8:51 AM, Oza Oza wrote:
> On Wed, Mar 29, 2017 at 11:12 PM, Robin Murphy wrote:
>> On 29/03/17 06:46, Oza Oza wrote:
>>> On Wed, Mar 29, 2017 at 10:23 AM, Oza Oza wrote:
On Wed, Mar 29, 2017 at 12:27 AM, Robin Murphy
wrote:
> For PCI masters not represente
current device frmework and of framework integration assumes dma-ranges
in a way where memory-mapped devices define their dma-ranges.
dma-ranges: (child-bus-address, parent-bus-address, length).
but iproc based SOCs and other SOCs(rcar) have PCI world dma-ranges.
dma-ranges = <0x4300 0x00 0x00
it is possible that PCI device supports 64-bit DMA addressing,
and thus it's driver sets device's dma_mask to DMA_BIT_MASK(64),
however PCI host bridge may have limitations on the inbound
transaction addressing. As an example, consider NVME SSD device
connected to iproc-PCIe controller.
Currently,
On 30.03.2017 09:40, Geert Uytterhoeven wrote:
> Hi Andrzej,
>
> On Thu, Mar 30, 2017 at 8:51 AM, Andrzej Hajda wrote:
>> On 29.03.2017 17:33, Robin Murphy wrote:
>>> On 29/03/17 16:12, Andrzej Hajda wrote:
On 29.03.2017 14:55, Robin Murphy wrote:
> On 29/03/17 11:05, Andrzej Hajda wrote:
Hi Andrzej,
On Thu, Mar 30, 2017 at 8:51 AM, Andrzej Hajda wrote:
> On 29.03.2017 17:33, Robin Murphy wrote:
>> On 29/03/17 16:12, Andrzej Hajda wrote:
>>> On 29.03.2017 14:55, Robin Murphy wrote:
On 29/03/17 11:05, Andrzej Hajda wrote:
> In case of DMA_ATTR_FORCE_CONTIGUOUS allocations
39 matches
Mail list logo
