On 09/30/2014 07:45 PM, Thomas Gleixner wrote:
> Whether the proposed patchset is the correct solution to support it is
> a completely different question.
This patchset has been in mainline since 3.16 and has already caused
regressions, so the question of whether this is the correct solution has
a
From: Matt Wagantall
It is sometimes necessary to poll a memory-mapped register until its value
satisfies some condition. Introduce a family of convenience macros that do
this. Tight-looping, sleeping, and timing out can all be accomplished using
these macros.
Cc: Thierry Reding
Cc: Will Deacon
On Tue, Sep 30 2014 at 03:23:34 AM, Will Deacon wrote:
> Hi Mitch,
>
> On Sun, Sep 28, 2014 at 04:27:29AM +0100, Mitchel Humpherys wrote:
>> Currently, we provide the iommu_ops.iova_to_phys service by doing a
>> table walk in software to translate IO virtual addresses to physical
>> addresses. On
Currently, we provide the iommu_ops.iova_to_phys service by doing a
table walk in software to translate IO virtual addresses to physical
addresses. On SMMUs that support it, it can be useful to ask the SMMU
itself to do the translation. This can be used to warm the TLBs for an
SMMU. It can also be
This series introduces support for performing iova-to-phys translations via
the ARM SMMU hardware on supported implementations. We also make use of
some new generic macros for polling hardware registers.
v1..v2:
- Renamed one of the iopoll macros to use the more standard `_atomic'
suffix
On 09/30/2014 07:45 PM, Thomas Gleixner wrote:
> On Tue, 30 Sep 2014, Peter Hurley wrote:
>> I read the UFS Unified Memory Extension v1.0 (JESD220-1) specification and
>> it is not clear to me that using DMA mapping is the right approach to
>> supporting UM, at least on x86.
>>
>> And without a mai
On Tue, 30 Sep 2014, Peter Hurley wrote:
> I read the UFS Unified Memory Extension v1.0 (JESD220-1) specification and
> it is not clear to me that using DMA mapping is the right approach to
> supporting UM, at least on x86.
>
> And without a mainline user, the merits of this approach are not evide
2014-09-30 23:34 GMT+09:00 Peter Hurley :
> On 09/29/2014 10:32 AM, Akinobu Mita wrote:
>> 2014-09-29 21:09 GMT+09:00 Peter Hurley :
>>> On 09/27/2014 08:31 PM, Akinobu Mita wrote:
2014-09-27 23:30 GMT+09:00 Peter Hurley :
> On 04/15/2014 09:08 AM, Akinobu Mita wrote:
>> This patch set
Any debugfs access on an OMAP IOMMU that is not enabled (done during
attach) results in a bus error due to access of registers without
the clock or the reset enabled for the respective IOMMU. So, add a
check to make sure the IOMMU is enabled/attached by a client device.
This gracefully prints a "Op
The OMAP IOMMU driver was originally designed as modules, and split
into a core module and a thin arch-specific module through the OMAP
arch-specific struct iommu_functions, to scale for both OMAP1 and
OMAP2+ IOMMU variants. The driver can only be built for OMAP2+
platforms currently, and also can
The isr_priv field is a left-over from before the IOMMU API
adaptation, this was used to store the callback data. This is
no longer relevant, so remove it.
Signed-off-by: Suman Anna
---
drivers/iommu/omap-iommu.h | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/iommu/omap-iommu.h b/dri
The exported functions omap_foreach_iommu_device() and
omap_iotlb_cr_to_e() have been deleted, as they are no
longer needed.
The function omap_foreach_iommu_device() is not required
after the consolidation of the OMAP IOMMU debug module,
and the function omap_iotlb_cr_to_e() is not required
after
The function omap2_iommu_fault_isr() does an unnecessary
recomputation of the return value. The logic relies on
setting the same bit fields as the MMU fault error status
bits, so simplify this function and remove the unneeded
macros. These macros were originally exported to notify
MMU faults to use
The debugfs support for OMAP IOMMU is currently implemented
as a module, warranting certain OMAP-specific IOMMU API to
be exported. The OMAP IOMMU, when enabled, can only be built-in
into the kernel, so integrate the OMAP IOMMU debug module
into the OMAP IOMMU driver. This helps in eliminating the
Hi,
The OMAP IOMMU driver is currently designed as three different
pieces - a core OMAP IOMMU driver that implements the generic
IOMMU API ops, a OMAP arch-specific layer that implements the
OMAP specific arch iommu_functions, and an independent debugfs
module. The former two are always built-in,
The debugfs entry 'ver' to read the OMAP IOMMU version is
not much useful for developers, so it has been removed. The
same can be deduced from the register dump, provided by the
debugfs entry 'regs', REVISION register. This also allows us
to remove the omap_iommu_arch_revision() which is currently
The .domain field in omap_iommu struct is set properly when the
OMAP IOMMU device is attached to, but is never reset properly
on detach. Reset this properly so that the OMAP IOMMU debugfs
logic can depend on this field before allowing the debugfs
operations.
Signed-off-by: Suman Anna
---
drivers
The debugfs entry 'pagetable' that shows the page table entry
(PTE) data currently outputs only data that can be fit into a
page. Switch the entry to use the seq_file interface so that
it can show all the valid page table entries.
The patch also corrected the output for L2 entries, and prints
the
The function omap_iommu_arch_version() is not used anymore,
and is not required either, so remove it. The .version field
in struct iommu_functions that this function uses is also
removed, as it is not really an ops to retrieve a version and
there won't be any usage for this field either.
Signed-of
The following functions were exported previously for usage by
the OMAP IOMMU debug module:
omap_iommu_dump_ctx()
omap_dump_tlb_entries()
omap_iopgtable_store_entry()
These functions need not be exported anymore as the OMAP IOMMU
debugfs code is integrated with the OMAP IOMM
The omap2_iommu_save_ctx() and omap2_iommu_restore_ctx()
performs a sanity version check against a fixed value
that is correct only for OMAP2/OMAP3 IOMMUs. This fixed check
does not scale for all OMAP2+ IOMMUs and is not absolutely
required, so it has been removed.
Signed-off-by: Suman Anna
---
The permissions on the debugfs entry "nr_tlb_entries" should
have been octal, not decimal, so fix it.
Signed-off-by: Suman Anna
---
drivers/iommu/omap-iommu-debug.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/iommu/omap-iommu-debug.c b/drivers/iommu/omap-iommu-deb
Remove the writeability on the 'pagetable' debugfs entry,
so that the mapping/unmapping into an OMAP IOMMU is only
limited to actual client devices/drivers at kernel-level.
Signed-off-by: Suman Anna
---
drivers/iommu/omap-iommu-debug.c | 48 ++--
1 file change
The refcount field in omap_iommu object is primarily used to check
if an IOMMU device has already been enabled, but this is already
implicit in the omap_iommu_attach_dev() which ensures that only
a single device can attach to an IOMMU. This field is redundant,
and so has been cleaned up.
Signed-of
The dev_to_omap_iommu() is local to the OMAP IOMMU modules, and
need not be defined conditionally. The CONFIG_IOMMU_API dependency
check was added in the past to fix a compilation issue back when
the header resided in the arch/arm layers, and is no longer
needed.
While at this, fix the header agai
The omap_iommu_save_ctx() and omap_iommu_restore_ctx() declarations
are defined in include/linux/omap-iommu.h and do not belong in the
internal drivers/iommu/omap-iommu.h header, so remove them.
Signed-off-by: Suman Anna
---
drivers/iommu/omap-iommu.h | 3 ---
1 file changed, 3 deletions(-)
dif
Hi Thierry,
On Thu, Sep 25, 2014 at 07:40:23AM +0100, Thierry Reding wrote:
> On Wed, Sep 24, 2014 at 05:33:38PM +0100, Will Deacon wrote:
> > On Tue, Sep 23, 2014 at 08:14:01AM +0100, Thierry Reding wrote:
> > > On Mon, Sep 22, 2014 at 06:43:37PM +0100, Will Deacon wrote:
> > > > Yup. In this cas
On 09/29/2014 10:32 AM, Akinobu Mita wrote:
> 2014-09-29 21:09 GMT+09:00 Peter Hurley :
>> On 09/27/2014 08:31 PM, Akinobu Mita wrote:
>>> 2014-09-27 23:30 GMT+09:00 Peter Hurley :
On 04/15/2014 09:08 AM, Akinobu Mita wrote:
> This patch set enhances the DMA Contiguous Memory Allocator on
From: Joerg Roedel
This event closes an important gap in the bus notifiers.
There is already the BUS_NOTIFY_DEL_DEVICE event, but that
is sent when the device is still bound to its device driver.
This is too early for the IOMMU code to destroy any mappings
for the device, as they might still be
From: Joerg Roedel
This makes sure any RMRR mappings stay in place when the
driver is unbound from the device.
Signed-off-by: Joerg Roedel
---
drivers/iommu/intel-iommu.c | 11 +--
1 file changed, 1 insertion(+), 10 deletions(-)
diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu
Hi,
here is a patch-set to fix an issue recently discovered when
the Intel IOMMU is in use with devices that need RMRR
mappings.
The problem is that the RMRR mappings are destroyed when the
device driver is unbound from the device, causing DMAR
faults.
To solve this problem a device driver core
Hi Mitch,
On Sun, Sep 28, 2014 at 04:27:29AM +0100, Mitchel Humpherys wrote:
> Currently, we provide the iommu_ops.iova_to_phys service by doing a
> table walk in software to translate IO virtual addresses to physical
> addresses. On SMMUs that support it, it can be useful to ask the SMMU
> itself
32 matches
Mail list logo
