On 2014-09-09 23:11, Nathan Zimmer wrote:
> The previous change (iommu/vt-d: Don't store SIRTP request) to this area
> caused a crash in our simulator. In particular is seems that by the time a
> UART interrupt is sent through the system, we don't see interrupt remapping
> to be enabled. So the in
On Tue, Aug 26 2014 at 07:27:58 AM, Will Deacon wrote:
> [adding Mike]
>
> On Tue, Aug 19, 2014 at 08:03:09PM +0100, Olav Haugan wrote:
>> Hi Will,
>
> Hi Olav,
>
>> On 8/19/2014 5:58 AM, Will Deacon wrote:
>> > On Wed, Aug 13, 2014 at 01:51:34AM +0100, Mitchel Humpherys wrote:
>> >> On some platf
Hi Alex,
I've attached what you've requested after I reenabled iommu.
On Fri, Sep 5, 2014 at 9:01 PM, Alex Williamson
wrote:
> On Fri, 2014-09-05 at 20:00 -0700, Jason Newton wrote:
>> Hi,
>>
>> I have an AR9462 connected over minipcie, it came with the ASRock
>> FM2A88x-itx motherboard and I'm
The previous change (iommu/vt-d: Don't store SIRTP request) to this area
caused a crash in our simulator. In particular is seems that by the time a
UART interrupt is sent through the system, we don't see interrupt remapping
to be enabled. So the interrupt does not get translated to a logical
inter
Hi Laurent,
> On Tuesday 09 September 2014 16:33:11 Suman Anna wrote:
>> On 09/09/2014 10:45 AM, Laurent Pinchart wrote:
>>> The OMAP IOMMU driver supports both the OMAP1 and OMAP2+ IOMMU variants
>>> by splitting the driver into a core module and a thin arch-specific
>>> operations module.
>>>
>>
Hi Suman,
On Tuesday 09 September 2014 16:33:11 Suman Anna wrote:
> On 09/09/2014 10:45 AM, Laurent Pinchart wrote:
> > The OMAP IOMMU driver supports both the OMAP1 and OMAP2+ IOMMU variants
> > by splitting the driver into a core module and a thin arch-specific
> > operations module.
> >
> > (I
Hi Laurent,
On 09/09/2014 10:45 AM, Laurent Pinchart wrote:
> The owner field is never set. Remove it.
Thanks, this seems to have been dead code since the days OMAP IOMMU has
been converted from building as modules to built-in as part of the IOMMU
API adoption. So,
Acked-by: Suman Anna
regards
Hi Laurent,
On 09/09/2014 10:45 AM, Laurent Pinchart wrote:
> The OMAP IOMMU driver supports both the OMAP1 and OMAP2+ IOMMU variants
> by splitting the driver into a core module and a thin arch-specific
> operations module.
>
> (In practice only the OMAP2+ module omap-iommu2 is implemented, but
> -Original Message-
> From: Joerg Roedel [mailto:j...@8bytes.org]
> Sent: Friday, September 05, 2014 4:23 PM
> To: iommu@lists.linux-foundation.org
> Cc: linux-ker...@vger.kernel.org; Joerg Roedel; Sethi Varun-B16395
> Subject: [PATCH 05/12] iommu/fsl: Convert to iommu_capable() API func
From: Joerg Roedel
Now that the mmu_notifier_invalidate_range() calls are in
place, add the call-back to allow subsystems to register
against it.
Reviewed-by: Andrea Arcangeli
Reviewed-by: Jérôme Glisse
Signed-off-by: Joerg Roedel
---
include/linux/mmu_notifier.h | 37 +++
The owner field is never set. Remove it.
Signed-off-by: Laurent Pinchart
---
drivers/iommu/omap-iommu.c | 11 ---
drivers/iommu/omap-iommu.h | 1 -
2 files changed, 12 deletions(-)
diff --git a/drivers/iommu/omap-iommu.c b/drivers/iommu/omap-iommu.c
index 192c367..fdfe732 100644
--- a/
Hello,
Those two patches clean up the OMAP IOMMU driver. Please see individual commit
messages for more information.
Laurent Pinchart (2):
iommu/omap: Reverse dependency between omap-iommu and omap-iommu2
iommu/omap: Remove omap_iommu unused owner field
drivers/iommu/omap-iommu-debug.c |
The OMAP IOMMU driver supports both the OMAP1 and OMAP2+ IOMMU variants
by splitting the driver into a core module and a thin arch-specific
operations module.
(In practice only the OMAP2+ module omap-iommu2 is implemented, but
let's not denigrate the effort.)
The arch-specific operations module r
From: Joerg Roedel
This notifier closes two important gaps with the current
invalidate_range_start()/end() notifiers. The _start() part
is called when all pages are still mapped while the _end()
notifier is called when all pages are potentially unmapped
and already freed.
This does not allow to
From: Joerg Roedel
Add calls to the new mmu_notifier_invalidate_range()
function to all places if the VMM that need it.
Reviewed-by: Andrea Arcangeli
Reviewed-by: Jérôme Glisse
Signed-off-by: Joerg Roedel
---
include/linux/mmu_notifier.h | 41 +
kernel
Changes V2->V3:
* Rebased to v3.17-rc4
* Fixed compile error because pmdp_get_and_clear_notify was
missing
Changes V1->V2:
* Rebase to v3.16-rc7
* Added call of ->invalidate_range to
__mmu_notifier_invalidate_end() so that the subsystem
doesn't need to register an ->invalidate_end() call-b
Hi Will,
On 09/08/2014 01:31 PM, Will Deacon wrote:
> On Fri, Sep 05, 2014 at 04:37:41PM +0100, Grygorii Strashko wrote:
>
>> On 09/02/2014 08:56 PM, Will Deacon wrote:
>>> set_arch_dma_coherent_ops is called from of_dma_configure in order to
>>> swizzle the architectural dma-mapping functions ov
Hi Will,
On Mon, Sep 08, 2014 at 05:51:36PM +0100, Will Deacon wrote:
> On Fri, Sep 05, 2014 at 11:52:56AM +0100, Joerg Roedel wrote:
> > switch (cap) {
> > case IOMMU_CAP_CACHE_COHERENCY:
> > - return features & ARM_SMMU_FEAT_COHERENT_WALK;
> > + /*
> > +*
Hi, Joerg,
> The problem you describe here should also be fixed by this (simpler)
> patch. Can you test this please?
The running result of this patch is correct.
My opinion is we should avoid modifying the original data
"early_ioapic_map[i].devid" and "devid from IVHD" since they are original d
19 matches
Mail list logo
