On Sun, Oct 2, 2011 at 4:45 PM, Arnd Bergmann wrote:
> The iommu module on omap contains a few functions that are
> only used by the debug module. These are however only there
> when the debug code is built as a module. Since it is possible
> to build the debug code into the kernel, the functions
here comes the revised patch.
Thanks for your review!
Ohad.
>From 042690394b1a121202e0eeeb47d267b1a8d65132 Mon Sep 17 00:00:00 2001
From: Ohad Ben-Cohen
Date: Wed, 31 Aug 2011 16:46:47 +0300
Subject: [PATCH 2/7] iommu/core: split mapping to page sizes as
supported by the hardware
When mapping a memory region, split it
Hi Kevin,
On Tue, Sep 27, 2011 at 1:53 AM, Kevin Hilman wrote:
> Benoit did just this in preparation for DT.
>
> http://marc.info/?l=linux-omap&m=131672480111927&w=2
>
> Will that meet your needs?
It's almost there, but not entirely.
Benoit's alloc/delete functions focus on the omap_devic
On Tue, Sep 27, 2011 at 4:12 PM, Roedel, Joerg wrote:
> You pass a pointer to an unsigned long for the page-size bitmap. This
> allows to use an array of unsigned long. But a single unsigned long is
> sufficient
This is fine; I can change that if you like it better (though without
doing the chang
On Tue, Sep 27, 2011 at 1:05 PM, Roedel, Joerg wrote:
> On Fri, Sep 16, 2011 at 01:51:41PM -0400, Ohad Ben-Cohen wrote:
>> int iommu_map(struct iommu_domain *domain, unsigned long iova,
>> - phys_addr_t paddr, int gfp_order, int prot)
>> + phys_addr
ping
On Fri, Sep 16, 2011 at 8:51 PM, Ohad Ben-Cohen wrote:
> v2->v3:
>
> - s/KB/KiB/ (David W)
>
> v1->v2:
>
> - split to patches (by keeping the old code around until all drivers are
> converted) (Joerg)
>
>
> Ohad Ben-Cohen (6):
> iommu/core: split
Bind OMAP3's isp device to the isp's dedicated iommu, by setting
the device's archdata iommu member.
This way omap3isp will be able to use the generic IOMMU API without
having to call any omap-specific binding method.
Signed-off-by: Ohad Ben-Cohen
Cc: Tony Lindgren
Cc: L
p appropriately.
Signed-off-by: Ohad Ben-Cohen
Cc: Hiroshi DOYU
Cc: Laurent Pinchart
Cc: Tony Lindgren
---
arch/arm/plat-omap/include/plat/iommu.h |5 +--
arch/arm/plat-omap/include/plat/iovmm.h | 12 +++---
drivers/iommu/omap-iommu.c | 58 ++-
dri
e the retrieval of the
omap_iommu handle from a user device.
Signed-off-by: Ohad Ben-Cohen
Cc: Tony Lindgren
Cc: Hiroshi DOYU
---
arch/arm/plat-omap/include/plat/iommu.h | 26 ++
1 files changed, 26 insertions(+), 0 deletions(-)
diff --git a/arch/arm/plat-omap/include/plat/io
do with plain devices).
Signed-off-by: Ohad Ben-Cohen
Cc: Benoit Cousson
Cc: Kevin Hilman
---
This is obviously not yet based on Benoit's recent changes; I'll do so after
we'll settle on the approach we want to take here.
arch/arm/plat-omap/include/plat/omap_device.h |6
*' is currently used
(the downside is reduced typesafety).
Note: ia64, x86 and sparc have this exact iommu extension as well, and
if others are likely to adopt it too, we might want to consider
adding this to the device struct itself directly.
Signed-off-by: Ohad Ben-Cohen
Cc: Russell King
will now work on OMAP without
utilizing any omap-specific API.
The changes are tested on OMAP3 (with omap3isp) and OMAP4 (with
remoteproc/rpmsg).
This is still RFC (2nd patch is probably the least elegant).
Ohad Ben-Cohen (5):
ARM: dev_archdata: add private iommu extension
ARM: OMAP: omap_d
On Wed, Sep 21, 2011 at 7:14 PM, Tony Lindgren wrote:
> OK acked the related patch.
Thanks!
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wed, Sep 21, 2011 at 6:56 PM, Ohad Ben-Cohen wrote:
> On Wed, Sep 21, 2011 at 6:28 PM, Tony Lindgren wrote:
>> Ohad can you please try this first? Just please make sure your patches are
>> first in next tree before sending in the pull request.
>
> Sure thing.
>
>
On Wed, Sep 21, 2011 at 6:28 PM, Tony Lindgren wrote:
> Ohad can you please try this first? Just please make sure your patches are
> first in next tree before sending in the pull request.
Sure thing.
Stephen, I'll send you the location of my tree in a few.
Thanks,
Ohad.
--
To unsubscribe from t
On Mon, Sep 12, 2011 at 7:46 PM, Ohad Ben-Cohen wrote:
> This series includes a new u8500 hwspinlock driver from Mathieu,
> a core fix from Juan and several other cleanups/fixes
> (some of which were reported by Arnd while reviewing Mathieu's
> driver).
...
> Document
Now that all IOMMU drivers are converted to the new
register_iommu_pgsize() API, the old code can be removed, and
we can s/register_iommu_pgsize/register_iommu/.
Signed-off-by: Ohad Ben-Cohen
Cc: Joerg Roedel
Cc: David Woodhouse
Cc: David Brown
Cc: Stepan Moskovchenko
---
drivers/iommu
Let the IOMMU core know we support 4KiB, 64KiB, 1MiB and 16MiB page sizes.
This way the IOMMU core can split any arbitrary-sized physically
contiguous regions (that it needs to map) as needed.
Signed-off-by: Ohad Ben-Cohen
Cc: Hiroshi DOYU
---
drivers/iommu/omap-iommu.c |6 +-
1 files
capabilities seem to have the potential
to be different between different DMA remapping devices.
Signed-off-by: Ohad Ben-Cohen
Cc: David Woodhouse
---
drivers/iommu/intel-iommu.c | 21 -
1 files changed, 20 insertions(+), 1 deletions(-)
diff --git a/drivers/iommu/intel-iomm
Let the IOMMU core know we support arbitrary page sizes (as long as
they're an order of 4KiB).
This way the IOMMU core will retain the existing behavior we're used to;
it will let us map regions that:
- their size is an order of 4KiB
- they are naturally aligned
Signed-off-by: Ohad Ben
Let the IOMMU core know we support 4KiB, 64KiB, 1MiB and 16MiB page sizes.
This way the IOMMU core can split any arbitrary-sized physically
contiguous regions (that it needs to map) as needed.
Signed-off-by: Ohad Ben-Cohen
Cc: David Brown
Cc: Stepan Moskovchenko
---
drivers/iommu/msm_iommu.c
e in bytes instead of in page order.
Signed-off-by: Ohad Ben-Cohen
Cc: David Brown
Cc: David Woodhouse
Cc: Joerg Roedel
Cc: Stepan Moskovchenko
Cc: Hiroshi DOYU
Cc: Laurent Pinchart
Cc: k...@vger.kernel.org
---
drivers/iommu/iommu.c | 158 +---
v2->v3:
- s/KB/KiB/ (David W)
v1->v2:
- split to patches (by keeping the old code around until all drivers are
converted) (Joerg)
Ohad Ben-Cohen (6):
iommu/core: split mapping to page sizes as supported by the hardware
iommu/omap: announce supported page sizes
iommu/msm: an
On Thu, Sep 15, 2011 at 1:45 PM, Roedel, Joerg wrote:
> This doesn't work on platforms that may have more than one possible
> iommu driver, like x86 for example.
Ok.
Acked-by: Ohad Ben-Cohen
(cc'ing Laurent for the VIDEO_OMAP3 part)
--
To unsubscribe from this list: send the l
On Thu, Sep 15, 2011 at 3:12 AM, Rusty Russell wrote:
> 7... numbers are cheap :)
7 it is :)
Thanks,
Ohad.
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.
On Thu, Sep 15, 2011 at 4:40 PM, Stuart Brown wrote:
> What would the procedure be to get this patch applied to the arago-project?
I have a feeling that asking Sanjeev will help ;)
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.
Hi Stuart,
On Thu, Sep 15, 2011 at 3:22 PM, Stuart Brown wrote:
> Doing some investigation it looks like the for loop in mach-omap2/mailbox.c:
> omap_mbox_get() might be wrong:
>
> for(mbox = *mboxes; mbox; mbox++)
...
> I'm hesitant to query this as it looks like this change has been in th
On Wed, Sep 14, 2011 at 5:07 PM, Joerg Roedel wrote:
> Without this patch it is possible to select the VIDEO_OMAP3
> driver which then selects OMAP_IOVMM. But the omap iommu
> driver is not compiled without IOMMU_SUPPORT enabled. Fix
> that by forcing OMAP_IOMMU and OMAP_IOVMM are enabled before
>
Hi Rusty,
On Wed, Jun 22, 2011 at 1:46 PM, Ohad Ben-Cohen wrote:
> On Wed, Jun 22, 2011 at 5:42 AM, Rusty Russell wrote:
>> On Tue, 21 Jun 2011 10:18:33 +0300, Ohad Ben-Cohen wrote:
>>> +#define VIRTIO_ID_RPMSG 10 /* virtio remote processor
>>> messagin
On Wed, Sep 14, 2011 at 12:32 AM, David Woodhouse wrote:
> On Tue, 2011-09-13 at 22:31 +0300, Ohad Ben-Cohen wrote:
>> + * Traditionally the IOMMU core just handed us the mappings directly,
>> + * after making sure the size is an order of a 4KB page and that the
>> +
Let the IOMMU core know we support arbitrary page sizes (as long as
they're an order of 4KB).
This way the IOMMU core will retain the existing behavior we're used to;
it will let us map regions that:
- their size is an order of 4KB
- they are naturally aligned
Signed-off-by: Ohad Ben
size capabilities seem to have the potential
to be different between different DMA remapping devices.
Signed-off-by: Ohad Ben-Cohen
Cc: David Woodhouse
---
drivers/iommu/intel-iommu.c | 21 -
1 files changed, 20 insertions(+), 1 deletions(-)
diff --git a/drivers/iommu/inte
Now that all IOMMU drivers are converted to the new
register_iommu_pgsize() API, the old code can be removed, and
we can s/register_iommu_pgsize/register_iommu/.
Signed-off-by: Ohad Ben-Cohen
Cc: Joerg Roedel
Cc: David Woodhouse
Cc: David Brown
Cc: Stepan Moskovchenko
---
drivers/iommu
Let the IOMMU core know we support 4KB, 64KB, 1MB and 16MB page sizes.
This way the IOMMU core can split any arbitrary-sized physically
contiguous regions (that it needs to map) as needed.
Signed-off-by: Ohad Ben-Cohen
---
drivers/iommu/omap-iommu.c |6 +-
1 files changed, 5 insertions
Let the IOMMU core know we support 4KB, 64KB, 1MB and 16MB page sizes.
This way the IOMMU core can split any arbitrary-sized physically
contiguous regions (that it needs to map) as needed.
Signed-off-by: Ohad Ben-Cohen
Cc: David Brown
Cc: Stepan Moskovchenko
---
drivers/iommu/msm_iommu.c
e in bytes instead of in page order.
Signed-off-by: Ohad Ben-Cohen
Cc: David Brown
Cc: David Woodhouse
Cc: Joerg Roedel
Cc: Stepan Moskovchenko
Cc: Hiroshi DOYU
Cc: Laurent Pinchart
Cc: k...@vger.kernel.org
---
v1->v2: keep old code around until all drivers are convert
namic PTE/TLB loading is not supported.
Signed-off-by: Ohad Ben-Cohen
---
arch/arm/plat-omap/include/plat/iommu.h |3 +--
drivers/iommu/omap-iommu.c | 31 +++
2 files changed, 4 insertions(+), 30 deletions(-)
diff --git a/arch/arm/plat-omap/include
is a remote processor for example)
- implement dynamic PTE/TLB loading
A dedicated iommu_set_fault_handler() API has been added to allow
users, who are interested to receive such reports, to provide
their handler.
Signed-off-by: Ohad Ben-Cohen
---
v1->v2: remove 'event' parameter
On Tue, Sep 13, 2011 at 1:44 PM, Roedel, Joerg wrote:
> Not necessarily. You could implement this side-by-side with the old code
> until all drivers are converted and remove the old code then. This keeps
> bisectability.
Ok.
>> > Intel IOMMU does not support arbitrary page-sizes, afaik.
>>
>> It
Hi Joerg,
On Tue, Sep 13, 2011 at 1:10 PM, Roedel, Joerg wrote:
> Please split this patch into the core-change and patches for the
> individual iommu-drivers and post this as a seperate patch-set.
But we'll be breaking bisectibility this way, no ?
> Intel IOMMU does not support arbitrary page-s
On Tue, Sep 13, 2011 at 1:00 PM, Roedel, Joerg wrote:
> For now I think it is the best to remove this IOMMU_ERROR thing. It is
> inherent to the function call already. When a real use-case comes up we
> can easily add it later.
I'm fine with this, will post an update.
Thanks,
Ohad.
--
To unsubsc
On Mon, Sep 12, 2011 at 7:58 PM, Joe Perches wrote:
>> +F: Documentation/hwspinlock.h
>
> F: Documentation/hwspinlock.txt
thanks :)
> Maybe
> F: drivers/hwspinlock/hwspinlock_*
ok, why not.
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a mes
Instead of allocating every hwspinlock separately, allocate
them all in one shot.
This both simplifies the driver and helps achieving better
slab utilization.
Reported-by: Arnd Bergmann
Signed-off-by: Ohad Ben-Cohen
---
drivers/hwspinlock/omap_hwspinlock.c | 51
hwspinlock drivers must anyway select CONFIG_HWSPINLOCK,
so there's no point in having register/unregister stubs.
Removing those stubs will only make it easier for developers
to catch CONFIG_HWSPINLOCK mis-.config-urations.
Signed-off-by: Ohad Ben-Cohen
---
include/linux/hwspinlock.h |
an explicit
error message in case an hwspinlock is registered with an id number
that already exists; this will help users catch such base id issues.
Reported-by: Arnd Bergmann
Signed-off-by: Ohad Ben-Cohen
---
arch/arm/mach-omap2/hwspinlock.c |8 +++-
drivers/hwspinlock/hwspinlock_
Use struct device_driver's owner member instead of asking drivers to
explicitly pass the owner again.
This simplifies drivers and also save some memory, since there's no
point now in maintaining a separate owner pointer per hwspinlock.
Signed-off-by: Ohad Ben-Cohen
---
Doc
a dedicated menu is added).
Signed-off-by: Ohad Ben-Cohen
---
drivers/hwspinlock/Kconfig | 16 +++-
1 files changed, 7 insertions(+), 9 deletions(-)
diff --git a/drivers/hwspinlock/Kconfig b/drivers/hwspinlock/Kconfig
index 1f29bab..c8e7bda 100644
--- a/drivers/hwspinlock/K
ts in hwspinlock.txt]
Signed-off-by: Ohad Ben-Cohen
---
Documentation/hwspinlock.txt | 18 +
drivers/hwspinlock/hwspinlock_core.c | 45 +++---
2 files changed, 27 insertions(+), 36 deletions(-)
diff --git a/Documentation/hwspinlock.txt b/Document
Mark omap_hwspinlock_remove with __devexit (and use __devexit_p
appropriately) so the function can be discarded when the conditions are met.
Signed-off-by: Ohad Ben-Cohen
---
drivers/hwspinlock/omap_hwspinlock.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers
Update MAINTAINERS with entries for hwspinlock/core and hwspinlock/omap
files.
Signed-off-by: Ohad Ben-Cohen
---
MAINTAINERS | 15 +++
1 files changed, 15 insertions(+), 0 deletions(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index 28f65c2..92cee8e 100644
--- a/MAINTAINERS
+++ b
m: set the owner member of the driver]
[o...@wizery.com: mark ->remove() function as __devexit]
[o...@wizery.com: write commit log]
[o...@wizery.com: small cleanups]
Signed-off-by: Ohad Ben-Cohen
---
drivers/hwspinlock/Kconfig | 11 ++
drivers/hwspinlock/Makefile |2 +
drive
tic to derive it.
As a result of this change, hwspinlocks drivers are now simpler and smaller
(about %20 code reduction) and the memory footprint of the hwspinlock
framework is reduced.
Signed-off-by: Ohad Ben-Cohen
---
Documentation/hwspinlock.txt | 58 +++
dr
nlock struct).
The result is ~20% code reduction in the hwspinlock drivers and
a smaller memory footprint.
Juan Gutierrez (1):
hwspinlock/core: use a mutex to protect the radix tree
Mathieu J. Poirier (1):
hwspinlock/u8500: add hwspinlock driver
Ohad Ben-Cohen (8):
hwspinlock/core: sim
On Mon, Sep 12, 2011 at 7:02 PM, Roedel, Joerg wrote:
> I still don't get the need for this. It would make sense to encode
> different types of faults, like page-faults or interrupt-faults.
Right.
> When I read the comment above it sounds more like you want to encode
> different error-levels, li
On Fri, Sep 9, 2011 at 3:58 PM, Arnd Bergmann wrote:
> For dynamic allocation, my impression is that we don't
> need any link from the spinlock user device to the controller at all,
I agree.
> but instead the controller should have a list of the available
> spinlocks.
Might make more sense to g
Hi KyongHo,
On Thu, Sep 8, 2011 at 3:51 PM, KyongHo Cho wrote:
> 16MB page is less practical in Linux because Linux kernel is unable
> to allocated larger physically contiguous memory than 4MB by default.
> But I also think that it is needed to support 16MB mapping for IO
> virtualization someday
On Thu, Sep 8, 2011 at 11:07 AM, Cousson, Benoit wrote:
> The (small) issue for my point of view is that the #hwspinlock is already
> encoded in the IP itself. So adding a baseid directly in DT will look like
> duplicating indirectly something that is already there in the HW.
> That being said, si
Hi Benoit,
On Thu, Sep 8, 2011 at 10:14 AM, Cousson, Benoit wrote:
> Hehe, I'm not the one who wrote that driver :-)
>
> This is not wrong for the current HW. The point is do we want to anticipate
> potential HW evolution that might never happen on that IP?
I originally really thought we can ign
Signed-off-by: Benoit Cousson
> Cc: Grant Likely
> Cc: Ohad Ben-Cohen
> ---
...
> + spinlock {
> + compatible = "ti,omap-spinlock";
> + hwmods = "spinlock";
> + };
This seem to satisfy t
dvertise support
for 4KB, 64KB, 1MB and 16MB (as supported by their hardware).
Mainline users of the IOMMU API (kvm and omap-iovmm) are adopted
to send the mapping size in bytes instead of in page order.
Tested with OMAP3 and OMAP4. Compile tested on X86-64.
Signed-off-by: Ohad Ben-Cohen
Cc: Da
emote processor, they could restart it.
Dynamic PTE/TLB loading is not supported.
Signed-off-by: Ohad Ben-Cohen
---
arch/arm/plat-omap/include/plat/iommu.h |3 +--
drivers/iommu/omap-iommu.c | 31 +++
2 files changed, 4 insertions(+), 30 deletions(-)
, who will require additional fault types, will add
new events as needed.
Signed-off-by: Ohad Ben-Cohen
---
drivers/iommu/iommu.c | 13 ++
include/linux/iommu.h | 65 +
2 files changed, 78 insertions(+), 0 deletions(-)
diff --git a/drivers
On Mon, Sep 5, 2011 at 1:00 PM, Roedel, Joerg wrote:
> Please add a seperate function for setting the fault-handler. It is
> optional, so no need to be a value of the alloc-function.
Will do.
> Can you elaborate a bit on what the user of the api will do different
> between IOMMU_TLBMISS and IOMM
Hi Cho,
On Wed, Sep 7, 2011 at 4:30 AM, KyongHo Cho wrote:
> Please find the following link that I submitted for our IOMMU.
> https://lkml.org/lkml/2011/7/3/152
>
> s5p_iommu_map/unmap accepts any order of physical address and iova
> without support of your suggestion if the order is not less tha
On Tue, Sep 6, 2011 at 1:15 PM, Roedel, Joerg wrote:
> Ok, I applied 1-5 to their respective branches. Patch 6 needs some more
> discussion to make sure the interface is generally usable. Patch 7 seems
> to be a starting point for now. This definitly requires conversion of
> the other IOMMU driver
Replace iommu's alignment checks with the existing IS_ALIGNED macro,
to drop a few lines of code and utilize IS_ALIGNED's type safety.
Signed-off-by: Ohad Ben-Cohen
---
drivers/iommu/iommu.c |9 +++--
1 files changed, 3 insertions(+), 6 deletions(-)
diff --git a/drivers/iommu
Users of the IOMMU API (kvm specifically) assume that iommu_unmap()
returns the order of the unmapped page (on success).
Fix msm_iommu_unmap() accordingly.
Signed-off-by: Ohad Ben-Cohen
Cc: Stepan Moskovchenko
Cc: David Brown
---
drivers/iommu/msm_iommu.c |7 +++
1 files changed, 7
re adopted
appropriately. Only OMAP and MSM were changed to advertise the supported
page sizes at this point (so this is definitely not merging material).
Signed-off-by: Ohad Ben-Cohen
---
drivers/iommu/iommu.c | 127 +++
drivers/iommu/msm_iommu.c |
f-by: Ohad Ben-Cohen
---
arch/arm/plat-omap/include/plat/iommu.h |3 +-
drivers/iommu/iommu.c | 10 +-
drivers/iommu/omap-iommu.c | 31 ++--
drivers/media/video/omap3isp/isp.c |2 +-
include/linux/iommu.h
Users of the IOMMU API (kvm specifically) assume that iommu_unmap()
returns the order of the unmapped page.
Fix omap_iommu_unmap() to do so and adopt omap-iovmm accordingly.
Signed-off-by: Ohad Ben-Cohen
---
drivers/iommu/omap-iommu.c | 13 -
drivers/iommu/omap-iovmm.c |2
Tiny cleanup that removes a redundant 'return' statement.
Signed-off-by: Ohad Ben-Cohen
---
drivers/iommu/omap-iommu.c |6 ++
1 files changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/iommu/omap-iommu.c b/drivers/iommu/omap-iommu.c
index 90744af..4311bc3 10
device address.
Signed-off-by: Laurent Pinchart
Acked-by: Hiroshi DOYU
[o...@wizery.com: rebased, but tested only with aligned buffers]
[o...@wizery.com: slightly edited the commit log]
Signed-off-by: Ohad Ben-Cohen
---
drivers/iommu/omap-iovmm.c | 36 ++--
1 files
rt (1):
iommu/omap-iovmm: support non page-aligned buffers in iommu_vmap
Ohad Ben-Cohen (6):
iommu/omap: cleanup: remove a redundant 'return' statement
iommu/core: use the existing IS_ALIGNED macro
iommu/omap: ->unmap() should return order of unmapped page
iommu/msm: ->unmap(
On Thu, Sep 1, 2011 at 4:59 PM, Laurent Pinchart
wrote:
> It looks good to me.
Thanks.
> I haven't tested it though.
I did, but I always get aligned buffers so my testing is a bit moot. I
can't see how unmap could work without this patch, though, so I'll
squash this and re-post.
--
To unsubscri
On Wed, Aug 31, 2011 at 1:52 PM, Ohad Ben-Cohen wrote:
> From: Laurent Pinchart
>
> omap_iovmm requires page-aligned buffers, and that sometimes causes
> omap3isp failures (i.e. whenever the buffer passed from userspace is not
> page-aligned).
>
> Remove this limitation by
Hi Laurent, Joerg,
On Wed, Aug 31, 2011 at 7:56 PM, Laurent Pinchart
wrote:
> On Wednesday 31 August 2011 15:06:42 Roedel, Joerg wrote:
>> Do you mean the parts of the pages you map to the device that are not in
>> the requested range (basically everything before offset and all after
>> size)?
>>
On Mon, Aug 29, 2011 at 10:36 PM, Ohad Ben-Cohen wrote:
> From: Laurent Pinchart
>
> omap_iovmm requires page-aligned buffers, and that sometimes causes
> omap3isp failures (i.e. whenever the buffer passed from userspace is not
> page-aligned).
>
> Remove this limitation by
device address.
Signed-off-by: Laurent Pinchart
Acked-by: Hiroshi DOYU
[o...@wizery.com: slightly edited the commit log]
Signed-off-by: Ohad Ben-Cohen
---
A fix by Laurent that was waiting until omap's iommu lands in drivers/.
Generally we're not extending omap-iovmm anymore, but this fi
On Fri, Aug 26, 2011 at 2:25 PM, Roedel, Joerg wrote:
> Applied all to arm/omap, thanks Ohad. I also put a commit on-top which
> finished the mutex->spin_lock conversion. Looks like one call-place was
> missed. See attached patch.
>
> commit 4234541f1a64d9dc6d489cf8f614dc01c62360f6
> Author: Joerg
Prepend 'omap_' to OMAP's 'struct iommu' and exposed API, to prevent
namespace pollution and generally to improve readability of the code
that still uses the driver directly.
Update the users as needed as well.
Signed-off-by: Ohad Ben-Cohen
Acked-by: Laurent Pinchar
s iommu will be evaluated
and eventually either added to the generic IOMMU API (if relevant),
or completely removed.
The intention is that OMAP's iommu driver will eventually not expose
any public API.
Signed-off-by: Ohad Ben-Cohen
Acked-by: Hiroshi DOYU
---
arch/arm/plat-omap/include/plat/iommu.
Remove unused functionality from OMAP's iovmm module.
The intention is to eventually completely replace iovmm with the
generic DMA-API, so new code that'd need this iovmm functionality
will have to extend the DMA-API instead.
Signed-off-by: Ohad Ben-Cohen
Acked-by: Hiroshi DOYU
---
Use PREFETCH_IOTLB to control the content of the called function,
instead of inlining it in the code.
This improves readability of the code, and also prevents an "unused
function" warning to show up when PREFETCH_IOTLB isn't set.
Signed-off-by: Ohad Ben-Cohen
Acked-b
on't break.
The plan is to eventually remove iovmm completely by replacing it
with the (upcoming) IOMMU-based DMA-API.
Tested on OMAP3 (with omap3isp) and OMAP4 (with rpmsg/remoteproc).
Signed-off-by: Ohad Ben-Cohen
Acked-by: Laurent Pinchart
Acked-by: Hiroshi DOYU
---
arch/arm/pl
th OMAP's iommu).
Eventually, iovmm will be completely replaced with the generic,
iommu-based, dma-mapping API.
Signed-off-by: Ohad Ben-Cohen
Acked-by: Laurent Pinchart
Acked-by: Hiroshi DOYU
---
arch/arm/plat-omap/Kconfig | 14 --
arch/ar
Stop exporting functions that are used only within the iommu
driver itself.
Eventually OMAP's iommu driver should only expose API via the generic
IOMMU framework.
Signed-off-by: Ohad Ben-Cohen
Acked-by: Hiroshi DOYU
---
arch/arm/plat-omap/include/plat/iommu.h |8
drivers/
(Joerg)
3. iovmm: remove obsolete comment (Hiroshi)
4. iommu: don't rename load_iotlb_entry directly (Hiroshi)
5. Rebase to 3.1-rc3
rfc->v1:
1. Migrate iommu, iovmm and omap3isp in a single patch for bisectibility sake.
2. Apply Laurent Pinchart's comments (thanks Laurent!)
3. Rebase
On Wed, Aug 24, 2011 at 4:15 PM, Roedel, Joerg wrote:
> Yes, it should be safe in your context. But the iommu-api is generic and
> I would prefer that all functions it provides can be called from any
> context.
Not a problem.
I thought you only cared about map/unmap, but if you prefer
attach/dea
On Tue, Aug 23, 2011 at 5:59 PM, Ohad Ben-Cohen wrote:
> On Tue, Aug 23, 2011 at 5:07 PM, Roedel, Joerg wrote:
>> Can this be easily converted to a spin_lock?
>
> Sure, thanks for reviewing.
Taking a second look, I don't think it's necessary - the mutex isn't
used
On Tue, Aug 23, 2011 at 5:26 PM, Roedel, Joerg wrote:
> Besides the locking issue these patches look good to me. Please repost
> when this is solved and I will put it in my tree then.
Great, thanks !
I'll do a quick re-spin with the collected comments and ACKs and repost.
At least for the first
On Tue, Aug 23, 2011 at 5:07 PM, Roedel, Joerg wrote:
> Can this be easily converted to a spin_lock?
Sure, thanks for reviewing.
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kerne
On Thu, Aug 18, 2011 at 4:38 PM, Arnd Bergmann wrote:
> On Thursday 18 August 2011, Ohad Ben-Cohen wrote:
>> arch/arm/plat-omap/Kconfig | 14 --
>> arch/arm/plat-omap/Makefile | 2 --
>> arch/arm/plat-o
Hi David,
On Thu, Aug 18, 2011 at 4:40 PM, David Cohen wrote:
>> Not sure if David or anyone is using this, but if someone is, it must
>> be out-of-tree.
>
> I am fine to remove it.
OK, thanks for confirming!
Ohad.
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the
Hi Hiroshi,
On Thu, Aug 18, 2011 at 1:49 PM, Hiroshi DOYU wrote:
>> -extern void iommu_set_twl(struct iommu *obj, bool on);
>
> This function was introduced by "Hari Kanigeri" for some OMAP4 case,
> which is only using TLB, not H/W table walk.
We discussed that internally, and concluded it's not
On Thu, Aug 18, 2011 at 1:19 PM, Hiroshi DOYU wrote:
> Maybe it's better to remove the comments explaining unnecessary
> functions too. Now the function comparison table doesn't make sense
Sure, will do.
> From: Hiroshi DOYU
> Date: Thu, 18 Aug 2011 13:13:53 +0300
> Subject: [PATCH 1/1] oma
Hi Laurent,
On Thu, Aug 18, 2011 at 12:01 PM, Laurent Pinchart
wrote:
> Just one small comment in case you resubmit the whole series for another
> reason.
..
> You can directly return -ENOMEM here, and remove the "out:" label.
Sure thing,
Thanks,
Ohad.
--
To unsubscribe from this list: send the
Hi Hiroshi,
On Thu, Aug 18, 2011 at 8:27 AM, Hiroshi DOYU wrote:
>> While we're at it, rename load_iotlb_entry to prefetch_iotlb_entry
>> to better reflect the purpose of that function.
>
> Considering that, originally this function is the counterpart of
> "flush_iotlb_page()" among load_iotlb_/f
Prepend 'omap_' to OMAP's 'struct iommu' and exposed API, to prevent
namespace pollution and generally to improve readability of the code
that still uses the driver directly.
Update the users as needed as well.
Signed-off-by: Ohad Ben-Cohen
---
arc
s iommu will be evaluated
and eventually either added to the generic IOMMU API (if relevant),
or completely removed.
The intention is that OMAP's iommu driver will eventually not expose
any public API.
Signed-off-by: Ohad Ben-Cohen
---
arch/arm/plat-omap/include/plat/iommu.h |3 --
driver
Remove unused functionality from OMAP's iovmm module.
The intention is to eventually completely replace iovmm with the
generic DMA-API, so new code that'd need this iovmm functionality
will have to extend the DMA-API instead.
Signed-off-by: Ohad Ben-Cohen
---
arch/arm/plat-omap/in
301 - 400 of 824 matches
Mail list logo
