Hi Stuart,
On Thu, Sep 15, 2011 at 3:22 PM, Stuart Brown stuart.br...@plexus.com 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
On Thu, Sep 15, 2011 at 4:40 PM, Stuart Brown stuart.br...@plexus.com 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
On Thu, Sep 15, 2011 at 3:12 AM, Rusty Russell ru...@rustcorp.com.au 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
Hi Rusty,
On Wed, Jun 22, 2011 at 1:46 PM, Ohad Ben-Cohen o...@wizery.com wrote:
On Wed, Jun 22, 2011 at 5:42 AM, Rusty Russell ru...@rustcorp.com.au wrote:
On Tue, 21 Jun 2011 10:18:33 +0300, Ohad Ben-Cohen o...@wizery.com wrote:
+#define VIRTIO_ID_RPMSG 10 /* virtio remote
On Wed, Sep 14, 2011 at 5:07 PM, Joerg Roedel joerg.roe...@amd.com 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
On Tue, Sep 13, 2011 at 1:00 PM, Roedel, Joerg joerg.roe...@amd.com 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,
Hi Joerg,
On Tue, Sep 13, 2011 at 1:10 PM, Roedel, Joerg joerg.roe...@amd.com 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
On Tue, Sep 13, 2011 at 1:44 PM, Roedel, Joerg joerg.roe...@amd.com 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,
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 o...@wizery.com
---
v1-v2: remove 'event' parameter
PTE/TLB loading is not supported.
Signed-off-by: Ohad Ben-Cohen o...@wizery.com
---
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
.
Signed-off-by: Ohad Ben-Cohen o...@wizery.com
Cc: David Brown dav...@codeaurora.org
Cc: David Woodhouse dw...@infradead.org
Cc: Joerg Roedel joerg.roe...@amd.com
Cc: Stepan Moskovchenko step...@codeaurora.org
Cc: Hiroshi DOYU hiroshi.d...@nokia.com
Cc: Laurent Pinchart laurent.pinch...@ideasonboard.com
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 o...@wizery.com
Cc: David Brown dav...@codeaurora.org
Cc: Stepan Moskovchenko
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 o...@wizery.com
Cc: Joerg Roedel joerg.roe...@amd.com
Cc: David Woodhouse dw...@infradead.org
Cc: David
to have the potential
to be different between different DMA remapping devices.
Signed-off-by: Ohad Ben-Cohen o...@wizery.com
Cc: David Woodhouse dw...@infradead.org
---
drivers/iommu/intel-iommu.c | 21 -
1 files changed, 20 insertions(+), 1 deletions(-)
diff --git a/drivers
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 o...@wizery.com
---
drivers/iommu/omap-iommu.c |6 +-
1 files
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-Cohen o
On Wed, Sep 14, 2011 at 12:32 AM, David Woodhouse dw...@infradead.org 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
+ * mapping has
On Mon, Sep 12, 2011 at 7:02 PM, Roedel, Joerg joerg.roe...@amd.com 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
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: simplify
, 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 o...@wizery.com
---
Documentation/hwspinlock.txt | 58 +++
drivers/hwspinlock/hwspinlock_core.c | 165
: adopt recent hwspin_lock_{un}register API changes]
[o...@wizery.com: 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 o...@wizery.com
---
drivers/hwspinlock
Update MAINTAINERS with entries for hwspinlock/core and hwspinlock/omap
files.
Signed-off-by: Ohad Ben-Cohen o...@wizery.com
---
MAINTAINERS | 15 +++
1 files changed, 15 insertions(+), 0 deletions(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index 28f65c2..92cee8e 100644
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 o...@wizery.com
---
drivers/hwspinlock/omap_hwspinlock.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff
: update register/unregister parts in hwspinlock.txt]
Signed-off-by: Ohad Ben-Cohen o...@wizery.com
---
Documentation/hwspinlock.txt | 18 +
drivers/hwspinlock/hwspinlock_core.c | 45 +++---
2 files changed, 27 insertions(+), 36 deletions(-)
diff --git
is added).
Signed-off-by: Ohad Ben-Cohen o...@wizery.com
---
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/Kconfig
+++ b
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 o...@wizery.com
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 a...@arndb.de
Signed-off-by: Ohad Ben-Cohen o...@wizery.com
---
arch/arm/mach-omap2/hwspinlock.c |8 +++-
drivers/hwspinlock
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 o...@wizery.com
---
include/linux
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 a...@arndb.de
Signed-off-by: Ohad Ben-Cohen o...@wizery.com
---
drivers/hwspinlock/omap_hwspinlock.c | 51
On Mon, Sep 12, 2011 at 7:58 PM, Joe Perches j...@perches.com 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
On Fri, Sep 9, 2011 at 3:58 PM, Arnd Bergmann a...@arndb.de 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
Hi Benoit,
On Thu, Sep 8, 2011 at 10:14 AM, Cousson, Benoit b-cous...@ti.com 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
On Thu, Sep 8, 2011 at 11:07 AM, Cousson, Benoit b-cous...@ti.com 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
Hi KyongHo,
On Thu, Sep 8, 2011 at 3:51 PM, KyongHo Cho pullip@samsung.com 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
Hi Cho,
On Wed, Sep 7, 2011 at 4:30 AM, KyongHo Cho pullip@samsung.com 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
On Mon, Sep 5, 2011 at 1:00 PM, Roedel, Joerg joerg.roe...@amd.com 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
processor, they could restart it.
Dynamic PTE/TLB loading is not supported.
Signed-off-by: Ohad Ben-Cohen o...@wizery.com
---
arch/arm/plat-omap/include/plat/iommu.h |3 +--
drivers/iommu/omap-iommu.c | 31 +++
2 files changed, 4 insertions(+), 30
, who will require additional fault types, will add
new events as needed.
Signed-off-by: Ohad Ben-Cohen o...@wizery.com
---
drivers/iommu/iommu.c | 13 ++
include/linux/iommu.h | 65 +
2 files changed, 78 insertions(+), 0 deletions(-)
diff
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 o...@wizery.com
Cc: David
-by: Benoit Cousson b-cous...@ti.com
Cc: Grant Likely grant.lik...@secretlab.ca
Cc: Ohad Ben-Cohen o...@wizery.com
---
...
+ spinlock {
+ compatible = ti,omap-spinlock;
+ hwmods = spinlock;
+ };
This seem to satisfy
On Tue, Sep 6, 2011 at 1:15 PM, Roedel, Joerg joerg.roe...@amd.com 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
):
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() should return order
Tiny cleanup that removes a redundant 'return' statement.
Signed-off-by: Ohad Ben-Cohen o...@wizery.com
---
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
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 o...@wizery.com
---
drivers/iommu/omap-iommu.c | 13 -
drivers/iommu/omap
, and adding the offset back to the device address.
Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
Acked-by: Hiroshi DOYU hiroshi.d...@nokia.com
[o...@wizery.com: rebased, but tested only with aligned buffers]
[o...@wizery.com: slightly edited the commit log]
Signed-off-by: Ohad Ben
Ben-Cohen o...@wizery.com
---
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 | 60
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 o...@wizery.com
---
drivers/iommu/iommu.c | 127 +++
drivers/iommu/msm_iommu.c |8 +++-
drivers
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 o...@wizery.com
Cc: Stepan Moskovchenko step...@codeaurora.org
Cc: David Brown dav...@codeaurora.org
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 o...@wizery.com
---
drivers/iommu/iommu.c |9 +++--
1 files changed, 3 insertions(+), 6 deletions(-)
diff --git a/drivers
On Wed, Aug 31, 2011 at 1:52 PM, Ohad Ben-Cohen o...@wizery.com wrote:
From: Laurent Pinchart laurent.pinch...@ideasonboard.com
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
On Mon, Aug 29, 2011 at 10:36 PM, Ohad Ben-Cohen o...@wizery.com wrote:
From: Laurent Pinchart laurent.pinch...@ideasonboard.com
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
Hi Laurent, Joerg,
On Wed, Aug 31, 2011 at 7:56 PM, Laurent Pinchart
laurent.pinch...@ideasonboard.com 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
, and adding the offset back to the device address.
Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
Acked-by: Hiroshi DOYU hiroshi.d...@nokia.com
[o...@wizery.com: slightly edited the commit log]
Signed-off-by: Ohad Ben-Cohen o...@wizery.com
---
A fix by Laurent that was waiting until
On Fri, Aug 26, 2011 at 2:25 PM, Roedel, Joerg joerg.roe...@amd.com 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
On Tue, Aug 23, 2011 at 5:59 PM, Ohad Ben-Cohen o...@wizery.com wrote:
On Tue, Aug 23, 2011 at 5:07 PM, Roedel, Joerg joerg.roe...@amd.com 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 Wed, Aug 24, 2011 at 4:15 PM, Roedel, Joerg joerg.roe...@amd.com 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
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 to 3.1-rc2
Ohad Ben-Cohen (7):
omap: iommu: migrate
).
Eventually, iovmm will be completely replaced with the generic,
iommu-based, dma-mapping API.
Signed-off-by: Ohad Ben-Cohen o...@wizery.com
Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
Acked-by: Hiroshi DOYU hiroshi.d...@nokia.com
---
arch/arm/plat-omap/Kconfig
.
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 o...@wizery.com
Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
Acked-by: Hiroshi
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 o...@wizery.com
Acked-by: Hiroshi DOYU
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 o...@wizery.com
Acked-by: Hiroshi DOYU
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 o...@wizery.com
Acked-by: Hiroshi DOYU hiroshi.d...@nokia.com
---
arch/arm/plat-omap
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 o...@wizery.com
Acked-by: Laurent Pinchart
On Tue, Aug 23, 2011 at 5:07 PM, Roedel, Joerg joerg.roe...@amd.com 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
On Tue, Aug 23, 2011 at 5:26 PM, Roedel, Joerg joerg.roe...@amd.com 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
Hi Hiroshi,
On Thu, Aug 18, 2011 at 8:27 AM, Hiroshi DOYU hiroshi.d...@nokia.com 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
Hi Laurent,
On Thu, Aug 18, 2011 at 12:01 PM, Laurent Pinchart
laurent.pinch...@ideasonboard.com 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
On Thu, Aug 18, 2011 at 1:19 PM, Hiroshi DOYU hiroshi.d...@nokia.com 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 hiroshi.d...@nokia.com
Date: Thu, 18 Aug 2011
Hi Hiroshi,
On Thu, Aug 18, 2011 at 1:49 PM, Hiroshi DOYU hiroshi.d...@nokia.com 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
Hi David,
On Thu, Aug 18, 2011 at 4:40 PM, David Cohen daco...@gmail.com 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
On Thu, Aug 18, 2011 at 4:38 PM, Arnd Bergmann a...@arndb.de 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-omap/{ = include/plat
.
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 o...@wizery.com
---
arch/arm/plat-omap/Kconfig |4 +-
arch/arm/plat-omap
).
Eventually, iovmm will be completely replaced with the generic,
iommu-based, dma-mapping API.
Signed-off-by: Ohad Ben-Cohen o...@wizery.com
---
arch/arm/plat-omap/Kconfig | 14 --
arch/arm/plat-omap/Makefile|2 --
arch/arm/plat
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 o...@wizery.com
---
arch/arm/plat-omap/include/plat/iommu.h |8
drivers/iommu/omap
to better reflect the purpose of that function.
Signed-off-by: Ohad Ben-Cohen o...@wizery.com
---
drivers/iommu/omap-iommu.c | 18 +-
1 files changed, 13 insertions(+), 5 deletions(-)
diff --git a/drivers/iommu/omap-iommu.c b/drivers/iommu/omap-iommu.c
index ed81977..7280e5b
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 o...@wizery.com
---
arch/arm/plat-omap/include/plat/iommu.h |3 --
drivers/iommu/omap
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 o...@wizery.com
---
arch/arm/mach-omap2/iommu2.c
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 o...@wizery.com
---
arch/arm/plat-omap
+ Paul, Benoit, Rajendra
On Tue, Aug 9, 2011 at 2:26 PM, Luciano Coelho coe...@ti.com wrote:
I'm again getting a very similar oops with 3.1-rc1 on my pandaboard:
[ 2.054351] usbcore: registered new interface driver cdc_ncm
[ 2.061431] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI)
Hi Pavel,
On Thu, Jun 9, 2011 at 8:12 PM, Pavel Machek pa...@ucw.cz wrote:
So this is basically networking... right? Why not implement it as
sockets? (accept, connect, read, write)?
This patch focuses on adding the core rpmsg kernel infrastructure. The
next step, after getting the basic stuff
://github.com/ohadbc/omap-iommu.git for-tony
Ohad Ben-Cohen (2):
OMAP4: iommu: fix clock name
omap: iovmm: s/sg_dma_len(sg)/sg-length/
Suman Anna (1):
omap: iommu: fix pte attributes for super section
arch/arm/mach-omap2/iommu2.c |4 ++--
arch/arm/mach-omap2/omap-iommu.c
On Fri, Jul 1, 2011 at 10:00 AM, Tony Lindgren t...@atomide.com wrote:
These look like real fixes, but can you please update the commits
with something like This fixes an issue with foo when doing bar.
Done, please tell me if it's OK now.
Otherwise it's easy to claim that these are fixes for
On Wed, Jun 29, 2011 at 6:43 PM, Grant Likely grant.lik...@secretlab.ca wrote:
So you are right that device_unregister drops the refcount to zero,
but the code still needs to be fixed to not call kfree() directly.
Good point, thanks !
It also looks like rpmsg_destroy_channel() needs to be
On Fri, Jul 1, 2011 at 3:33 AM, Rafael J. Wysocki r...@sisk.pl wrote:
In theory it is possible that a subsystem (e.g. bus type) will enable
runtime PM for devices without drivers and will (for example) put them
into low power states until the drivers are loaded. Then, it makes
sense for the
Hi Randy,
Thanks for your comments !
On Wed, Jun 29, 2011 at 2:44 AM, Randy Dunlap rdun...@xenotime.net wrote:
+hardware accelerators, and therefore are often used to offload cpu-intensive
prefer: CPU-
throughout.
Isn't that changing
On Wed, Jun 29, 2011 at 2:59 PM, Arnd Bergmann a...@arndb.de wrote:
On Wednesday 29 June 2011, Ohad Ben-Cohen wrote:
On Wed, Jun 29, 2011 at 2:44 AM, Randy Dunlap rdun...@xenotime.net wrote:
+hardware accelerators, and therefore are often used to offload
cpu-intensive
prefer
On Tue, Jun 28, 2011 at 12:00 AM, Grant Likely
grant.lik...@secretlab.ca wrote:
Very little for me to comment on here. However, something I just
noticed. Why is it necessary to pass in THIS_MODULE to the
rproc_register function? Having a reference to the pdev gives you the
pointer to the
On Tue, Jun 28, 2011 at 12:22 AM, Grosen, Mark mgro...@ti.com wrote:
2. We added a special section (resource table) that is interpreted as part
of the loading process. The tool that generates our simple format just
recognizes a named section (.resource_table), so perhaps that could be
done
Hi Grant,
Thanks a lot for the exhaustive review and comments !
On Mon, Jun 27, 2011 at 11:49 PM, Grant Likely
grant.lik...@secretlab.ca wrote:
+ my_rproc = rproc_get(ipu);
I tend to be suspicious of apis whose primary interface is by-name
lookup. It works fine when the system is small,
On Tue, Jun 28, 2011 at 2:29 AM, Russell King - ARM Linux
li...@arm.linux.org.uk wrote:
(Don't have the original message to reply to...)
Sorry about that.
My recent emails to linux-arm-kernel were bounced with a Message has
a suspicious header reason. not sure what am I doing wrong..
Do we
Hi Grant,
On Tue, Jun 28, 2011 at 1:21 AM, Grant Likely grant.lik...@secretlab.ca wrote:
Nice patch. I'm quite thrilled to see this implemented. Some
comments below, but otherwise I think it looks pretty good.
Thanks !
+source drivers/virtio/Kconfig
What happens when kvm and rpmsg both
On Wed, Jun 29, 2011 at 1:51 AM, Grant Likely grant.lik...@secretlab.ca wrote:
It's not the device_for_each_child() that you're 'putting' back from
here. Its the original kref initialization when the device was
created.
device_unregister() is already calling put_device(), doesn't that deal
Hi Stephen,
On Fri, Jun 24, 2011 at 11:16 PM, Stephen Boyd sb...@codeaurora.org wrote:
This sounds a lot like SMD (shared memory driver) on MSM. The main
difference I see is that SMD uses the platform bus instead of the virtio
bus and it has its own protocol for channel allocation.
Yeah,
On Wed, Jun 22, 2011 at 5:42 AM, Rusty Russell ru...@rustcorp.com.au wrote:
On Tue, 21 Jun 2011 10:18:33 +0300, Ohad Ben-Cohen o...@wizery.com wrote:
Add a virtio-based IPC bus, which enables kernel users to communicate
with remote processors over shared memory using a simple messaging
On Wed, Jun 22, 2011 at 1:05 PM, Will Newton will.new...@gmail.com wrote:
On Tue, Jun 21, 2011 at 8:18 AM, Ohad Ben-Cohen o...@wizery.com wrote:
+/* bootaddr isn't needed for the dual M3's */
+static inline int omap_rproc_start(struct rproc *rproc, u64 bootaddr)
+static inline int
Hi Arnd,
On Tue, Jun 21, 2011 at 5:20 PM, Arnd Bergmann a...@arndb.de wrote:
This looks really nice overall, but I don't currently have time for a
more in-depth review. My feeling is that you are definitely on the right
track here, and the plans you list as TODO to continue are all good.
On Wed, Jun 22, 2011 at 4:05 PM, Arnd Bergmann a...@arndb.de wrote:
Ok, I see. In that case I agree that using debugfs is fine, but I would
recommend trying to use fewer macros and just open-coding the file
operations for better readability.
Sure thing. It didn't end up saving much code
Hi Randy,
On Wed, Jun 22, 2011 at 8:55 PM, Randy Dunlap rdun...@xenotime.net wrote:
On Tue, 21 Jun 2011 10:18:27 +0300 Ohad Ben-Cohen wrote:
Hi,
Just a few minor nits inline...
Thanks!
Ohad.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message
implementation
davinci: da850: add remoteproc dsp device
Ohad Ben-Cohen (4):
drivers: add generic remoteproc framework
omap: add carveout memory support for remoteproc
drivers: introduce rpmsg, a remote-processor messaging bus
rpmsg: add omap host backend
Documentation/ABI/testing/sysfs-bus-rpmsg
also breaks tidspbridge. Use it only if you want to try out
rpmsg/remoteproc on OMAP4, and you don't care too much about multi-board
kernels.
Signed-off-by: Ohad Ben-Cohen o...@wizery.com
---
arch/arm/plat-omap/Kconfig|8
arch/arm/plat-omap/devices.c | 14
301 - 400 of 776 matches
Mail list logo
