Hi, all.
Any comments?
On Mon, Feb 27, 2017 at 2:30 PM, Oleksandr Tyshchenko
wrote:
> Hi.
>
> There is a small patch series which contains the same fix for both
> descriptor formats based on the preceding RFC patches:
> https://lists.linuxfoundation.org/pipermail/iommu/2017-February/020411.html
On 16/03/17 09:19, Oleksandr Tyshchenko wrote:
> Hi, all.
>
> Any comments?
Er, no, but in a good way ;)
Patches look fine to me, and I see Will's already queued them anyway.
Thanks for the respin, and apologies for losing it in my inbox!
Robin.
>
> On Mon, Feb 27, 2017 at 2:30 PM, Oleksandr
On Thu, Mar 16, 2017 at 1:19 PM, Robin Murphy wrote:
> On 16/03/17 09:19, Oleksandr Tyshchenko wrote:
>> Hi, all.
>>
>> Any comments?
>
> Er, no, but in a good way ;)
>
> Patches look fine to me, and I see Will's already queued them anyway.
>
> Thanks for the respin, and apologies for losing it in
On Wed, Mar 15, 2017 at 7:03 PM, Robin Murphy wrote:
> Hi all,
>
> Here's the first bit of lock contention removal to chew on - feedback
> welcome! Note that for the current users of the io-pgtable framework,
> this is most likely to simply push more contention onto the io-pgtable
> lock, so may n
There is no need to have a temporary variable.
Signed-off-by: Andy Shevchenko
---
drivers/iommu/dmar.c | 14 --
1 file changed, 8 insertions(+), 6 deletions(-)
diff --git a/drivers/iommu/dmar.c b/drivers/iommu/dmar.c
index edcf7410f736..71d774f1d406 100644
--- a/drivers/iommu/dmar.c
There is already helper functions to do 64-bit I/O on 32-bit machines or
buses, thus we don't need to reinvent the wheel.
Signed-off-by: Andy Shevchenko
---
include/linux/intel-iommu.h | 18 ++
1 file changed, 2 insertions(+), 16 deletions(-)
diff --git a/include/linux/intel-iom
Usual pattern when we check for return code, which might be negative
errno, is either (ret) or (!ret).
Remove extra ' != 0' from condition.
Signed-off-by: Andy Shevchenko
---
drivers/iommu/dmar.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/iommu/dmar.c b/drivers/
There is no need to assign ret to 0 in some cases. Moreover it might
shadow some errors in the future.
Remove such assignments.
Signed-off-by: Andy Shevchenko
---
drivers/iommu/dmar.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/iommu/dmar.c b/drivers/iommu/dm
There is inconsistency in return codes across the functions called from
detect_intel_iommu().
Make it consistent and propagate return code to the caller.
Signed-off-by: Andy Shevchenko
---
drivers/iommu/dmar.c | 15 +++
1 file changed, 7 insertions(+), 8 deletions(-)
diff --git a/d
Hi Will,
On 2017-03-10 15:49, Will Deacon wrote:
In preparation for allowing the default domain type to be overridden,
this patch adds support for IOMMU_DOMAIN_IDENTITY domains to the
ARM SMMUv3 driver.
An identity domain is created by placing the corresponding stream table
entries into "bypass
Hi Will,
On 2017-03-10 15:49, Will Deacon wrote:
arm_smmu_install_ste_for_dev cannot fail and always returns 0, however
the fact that it returns int means that callers end up implementing
redundant error handling code which complicates STE tracking and is
never executed.
This patch changes the
The introduction of reserved regions has left a couple of rough edges
which we could do with sorting out sooner rather than later. Since we
are not yet addressing the potential dynamic aspect of software-managed
reservations and presenting them at arbitrary fixed addresses, it is
incongruous that w
Even if a host controller's CPU-side MMIO windows into PCI I/O space do
happen to leak into PCI memory space such that it might treat them as
peer addresses, trying to reserve the corresponding I/O space addresses
doesn't do anything to help solve that problem. Stop doing a silly thing.
Fixes: fad
Hi Joerg,
Here's v2 incorporating Eric's feedback and R-b tags, with patch #4 added
to finish the job. Whilst presented as a logical series because it's all
touching the same code, it doesn't necessarily need merging as such - I'd
be happier with patch #1 going into 4.11 before anyone starts using
Now that it's simple to discover the necessary reservations for a given
device/IOMMU combination, let's wire up the appropriate handling. Basic
reserved regions and direct-mapped regions we simply have to carve out
of IOVA space (the IOMMU core having already mapped the latter before
attaching the
Now that we're applying the IOMMU API reserved regions to our IOVA
domains, we shouldn't need to privately special-case PCI windows, or
indeed anything else which isn't specific to our iommu-dma layer.
However, since those aren't IOMMU-specific either, rather than start
duplicating code into IOMMU
Hi Nate, Will,
On 16/03/17 16:24, Nate Watterson wrote:
> Hi Will,
>
> On 2017-03-10 15:49, Will Deacon wrote:
>> In preparation for allowing the default domain type to be overridden,
>> this patch adds support for IOMMU_DOMAIN_IDENTITY domains to the
>> ARM SMMUv3 driver.
>>
>> An identity domai
On Thu, Mar 09, 2017 at 09:05:45PM +0530, Sricharan R wrote:
> The MMU400x/500 is the implementation of the SMMUv2
> arch specification. It is split in to two blocks
> TBU, TCU. TBU caches the page table, instantiated
> for each master locally, clocked by the TBUn_clk.
> TCU manages the address tra
On Thu, Mar 09, 2017 at 09:05:46PM +0530, Sricharan R wrote:
> The QCOM_SMMUV2 is an implementation of the arm,smmu-v2 architecture.
> The qcom,smmu is instantiated for each of the multimedia cores (for eg)
> Venus (video encoder/decoder), mdp (display) etc, and they are connected
> to the Multimed
On Thu, Mar 9, 2017 at 10:35 AM, Sricharan R wrote:
> The MMU400x/500 is the implementation of the SMMUv2
> arch specification. It is split in to two blocks
> TBU, TCU. TBU caches the page table, instantiated
> for each master locally, clocked by the TBUn_clk.
> TCU manages the address translation
Hi,
On 3/17/2017 4:22 AM, Rob Clark wrote:
On Thu, Mar 9, 2017 at 10:35 AM, Sricharan R wrote:
The MMU400x/500 is the implementation of the SMMUv2
arch specification. It is split in to two blocks
TBU, TCU. TBU caches the page table, instantiated
for each master locally, clocked by the TBUn_clk
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,
Hi,
There are certain areas which requires contemplation.
And this problem requires more attention from Pci of framework and iommu,
and integration of both.
Regards,
Oza.
-Original Message-
From: Oza Pawandeep [mailto:oza@broadcom.com]
Sent: Friday, March 17, 2017 11:41 AM
To: Joerg
23 matches
Mail list logo
