;
> Signed-off-by: Guillaume Aubertin
Acked-by: Ohad Ben-Cohen
> ---
> drivers/iommu/omap-iommu.c |2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/iommu/omap-iommu.c b/drivers/iommu/omap-iommu.c
> index badc17c..a0fcad2 100644
> --
anding comment or issue that might show up.
Joerg, can you please take it (or at least its first four patches) ?
We have Tony's ack for the mach-omap2 parts.
Tested-by: Ohad Ben-Cohen
Thanks,
Ohad.
___
iommu mailing list
iommu@list
Hi Omar,
On Thu, Nov 15, 2012 at 6:53 PM, Omar Ramirez Luna wrote:
> On 14 November 2012 03:54, Ohad Ben-Cohen wrote:
>> Most of the above questions imply this patch not only converts the
>> iommu to runtime PM, but may carry additional changes that may imply
>> previous
Hi Omar,
On Wed, Nov 14, 2012 at 4:34 AM, Omar Ramirez Luna wrote:
> Use runtime PM functionality interfaced with hwmod enable/idle
> functions, to replace direct clock operations and sysconfig
> handling.
>
> Dues to reset sequence, pm_runtime_put_sync must be used, to avoid
> possible operation
+ Paul
On Tue, Jul 17, 2012 at 1:11 PM, Joerg Roedel wrote:
> On Fri, Jun 15, 2012 at 08:55:58PM -0500, Omar Ramirez Luna wrote:
>> Omar Ramirez Luna (6):
>> ARM: OMAP: iommu: fix including iommu.h without IOMMU_API selected
>> ARM: OMAP3: hwmod data: add mmu data for iva and isp
>> ARM: OM
ppens.
The patch also adopts remoteproc to the new fault handling
interface, but the real functionality using this (recovery of
remote processors) will only be added later in a subsequent patch
set.
Cc: Fernando Guzman Lugo
Signed-off-by: Ohad Ben-Cohen
---
drivers/iommu/iommu.c|
On Mon, May 21, 2012 at 4:25 PM, Joerg Roedel wrote:
> May break compilation for !CONFIG_IOMMU_API.
Good point. I'll squash this in:
diff --git a/include/linux/iommu.h b/include/linux/iommu.h
index eb72d3b..450293f 100644
--- a/include/linux/iommu.h
+++ b/include/linux/iommu.h
@@ -193,7 +193,7 @
igned-off-by: Ohad Ben-Cohen
---
drivers/iommu/iommu.c |5 -
include/linux/iommu.h |8 +---
2 files changed, 9 insertions(+), 4 deletions(-)
diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
index 2198b2d..8b9ded8 100644
--- a/drivers/iommu/iommu.c
+++ b/drivers/iommu/io
For some weird (freudian?) reason, commit 435792d "ARM: OMAP: make
iommu subsys_initcall to fix builtin omap3isp" unintentionally changed
the mailbox's initcall instead of the iommu's.
Fix that.
Reported-by: Fernando Guzman Lugo
Signed-off-by: Ohad Ben-Cohen
Cc: Laurent
Hi Laurent,
On Thu, Mar 1, 2012 at 6:37 PM, Laurent Pinchart
wrote:
> I'll try that then. How expensive is the iommu_attach_device() (and detach)
> operation in terms of CPU time ?
omap_iommu_attach() basically enables the iommu clock and configures
that IP block.
I suspect it's negligible but
Hi Laurent,
On Mon, Feb 27, 2012 at 12:47 AM, Laurent Pinchart
wrote:
> I'm asking about the probe deferral mechanism. The omap3-isp driver will still
> call iommu_attach_device() in its probe function. What will happen then ? Will
> it return an error ? On what basis will it do so ?
Yes, iommu_
Hi Laurent,
On Sun, Feb 26, 2012 at 7:34 PM, Laurent Pinchart
wrote:
> On Sunday 26 February 2012 12:14:14 Ohad Ben-Cohen wrote:
>> omap3isp depends on omap's iommu and will fail to probe if
>> initialized before it (which always happen if they are builtin).
>
ned-off-by: Ohad Ben-Cohen
Cc: stable
Cc: Tony Lindgren
Cc: Hiroshi Doyu
Cc: Joerg Roedel
---
arch/arm/mach-omap2/mailbox.c |3 ++-
drivers/iommu/omap-iommu.c|3 ++-
2 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/mailbox.c b/arch/arm/mach-omap2/mailb
On Fri, Feb 24, 2012 at 1:01 PM, Joerg Roedel wrote:
> These patches make a lot more sense to me than fixing this by relying on
> some random linker behavior. Can you please send a fix like this with a
> proper commit-msg?
Done, thanks.
___
iommu mailin
On Fri, Feb 24, 2012 at 3:16 PM, Joerg Roedel wrote:
> Applied both and added stable-tag to the second patch. I'll send the
> pull-request when you guys also send me the correct fix for the
> outstanding initialization order issue on OMAP.
It's out, thanks!
___
On Thu, Feb 23, 2012 at 6:59 PM, Ohad Ben-Cohen wrote:
> diff --git a/arch/arm/mach-omap2/mailbox.c b/arch/arm/mach-omap2/mailbox.c
> index 609ea2d..f992395 100644
> --- a/arch/arm/mach-omap2/mailbox.c
> +++ b/arch/arm/mach-omap2/mailbox.c
> @@ -412,7 +412,7 @@ static void __exit
Hi Laurent,
On Thu, Feb 23, 2012 at 6:38 PM, Laurent Pinchart
wrote:
> Ping ? I've discussed this with Ohad last week, and we agreed that there was
> indeed an issue with the IOMMU subsystem and/or the OMAP3 IOMMU driver. Could
> you please have a look at my explanation below ?
Oops - for some r
On Thu, Feb 23, 2012 at 6:11 PM, Joerg Roedel wrote:
> I guess these patches are 3.3 material?
Yes.
> How about tagging them for stable too?
Good point. But it's only relevant for this 2nd patch (the NULL
pointer dereference fix), as the first one is a 3.3 regression. Let me
know if you want me
; /debug/iommu/ducati/mem' Oops sibling, too.
Signed-off-by: Ohad Ben-Cohen
Cc: Tony Lindgren
Cc: Hiroshi Doyu
Cc: Laurent Pinchart
Cc: Russell King
Cc: Joerg Roedel
---
v2: omap_find_iovm_area only returns NULL for errors. thanks, rmk.
drivers/iommu/omap-iommu-debug.c |4 ++--
On Wed, Feb 22, 2012 at 10:56 AM, Russell King - ARM Linux
wrote:
> There's something else which needs fixing here - the return code. If
> omap_find_iovm_area() returns an error code that needs propagating.
> Otherwise it might as well just return NULL for all errors.
Seems like it does just ret
ng API which is otherwise not needed.
It should better be more tightly coupled with omap-iommu, to prevent
further bit rot and avoid exposing redundant API. Naturally that's out
of scope for the -rc cycle, so for now just fix the obvious.
Reported-by: Russell King
Signed-off-by: Ohad Ben-Cohen
C
; /debug/iommu/ducati/mem' Oops sibling, too.
Signed-off-by: Ohad Ben-Cohen
Cc: Tony Lindgren
Cc: Hiroshi Doyu
Cc: Laurent Pinchart
Cc: Russell King
Cc: Joerg Roedel
---
drivers/iommu/omap-iommu-debug.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drive
On Thu, Feb 9, 2012 at 9:25 AM, Laurent Pinchart
wrote:
> Ohad, Joerg, would this be an acceptable fix ?
What does this fix ? care to attach the oops ?
Thanks,
Ohad.
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.
On Mon, Jan 30, 2012 at 4:49 PM, Joerg Roedel wrote:
> Hardware specific attributes are intended, but not limited to hardware
> specific drivers. A generic driver that _may_ run on a given hardware
> can use a hardware specific attribute too. If it doesn't run on this
> hardware it will just get -
On Fri, Jan 27, 2012 at 3:03 PM, Joerg Roedel wrote:
> Note that only the read-side is handled by the core. An IOMMU driver may
> decide to implement a write-side for the geometry which would be not in
> the core then. Having a dedicated function for the write-side does not
> make sense because (f
On Fri, Jan 27, 2012 at 12:26 PM, Joerg Roedel wrote:
> I fell also uncomfortable with the missing type-safety of this
> interface. But the alternative is to have dedicated functions for
> set/get each attribute. Well, it depends on how many attributes we have
> in the end, but given that the PAMU
Hi Joerg,
On Thu, Jan 26, 2012 at 8:40 PM, Joerg Roedel wrote:
> Implement the attribute itself and add the code for the
> AMD IOMMU driver.
It's somewhat non-intuitive to have the generic attribute code bundled
with the AMD implementation in the same patch (took me some time to
find it here :).
Hi Joerg,
On Mon, Jan 23, 2012 at 4:03 PM, Joerg Roedel wrote:
> Please tell me when I mis-read the code, otherwise please fix this in
> your drivers so that we can get consistent behavior for IOMMU-API
> users :-)
I'm a bit tied up with some schedule I have to meet this week, but
I'll definitel
28 matches
Mail list logo
