On Thu, Nov 25, 2010 at 8:05 AM, Kamoolkar, Mugdha mug...@ti.com wrote:
Consider a software module on top of the hwspinlock, which provides a
generic way for multi-core critical section, say GateMP. This module enables
users to create critical section objects by name. Any other client can open
On Thu, Nov 25, 2010 at 10:22 PM, David Brownell davi...@pacbell.net wrote:
So there's no strong reason to think this is
actually ggeneric. Function names no longer
specify OMAP, but without other hardware under
the interface, calling it generic reflects
more optimism than reality. (That
(hwspinlock_free);
+
+MODULE_LICENSE(GPL v2);
+MODULE_DESCRIPTION(Generic hardware spinlock interface);
+MODULE_AUTHOR(Ohad Ben-Cohen o...@wizery.com);
--
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
On Fri, Nov 26, 2010 at 11:18 AM, Russell King - ARM Linux
li...@arm.linux.org.uk wrote:
On Fri, Nov 26, 2010 at 10:53:10AM +0200, Ohad Ben-Cohen wrote:
+int __hwspin_trylock(struct hwspinlock *hwlock, int mode, unsigned long
*flags)
+{
+ int ret;
+
+ if (unlikely(!hwlock
On Fri, Nov 26, 2010 at 12:45 PM, Russell King - ARM Linux
li...@arm.linux.org.uk wrote:
On Fri, Nov 26, 2010 at 12:16:39PM +0200, Ohad Ben-Cohen wrote:
On Fri, Nov 26, 2010 at 11:18 AM, Russell King - ARM Linux
li...@arm.linux.org.uk wrote:
On Fri, Nov 26, 2010 at 10:53:10AM +0200, Ohad Ben
This patch complements ed919b0 mmc: sdio: fix runtime PM anomalies by
introducing MMC_CAP_POWER_OFF_CARD by declaring MMC_CAP_POWER_OFF_CARD
on the ZOOM's wl1271 mmc slot.
This is required in order not to break runtime PM support for the wl1271
sdio driver.
Signed-off-by: Ohad Ben-Cohen o
On Sat, Nov 27, 2010 at 12:53 AM, Russell King - ARM Linux
li...@arm.linux.org.uk wrote:
On Sat, Nov 27, 2010 at 12:18:55AM +0200, Ohad Ben-Cohen wrote:
But then there's the other (quite reasonable) claim that says we
shouldn't crash the machine because of a non fatal bug: if a crappy
driver
On Sat, Nov 27, 2010 at 3:24 AM, David Brownell davi...@pacbell.net wrote:
Your intent generic is fine, but you've not achieved it and thus I
think you shouldn't imply that you have. Dropping the word generic
should suffice; it _is_ a framework, and maybe the next person working
with
Hi Olof,
On Sat, Nov 27, 2010 at 12:51 AM, Olof Johansson o...@lixom.net wrote:
+int __hwspin_trylock(struct hwspinlock *hwlock, int mode, unsigned long
*flags)
+{
+ int ret;
+
+ if (unlikely(!hwlock)) {
+ pr_err(invalid hwlock\n);
These kind of errors can
On Tue, Nov 30, 2010 at 11:00 AM, Tony Lindgren t...@atomide.com wrote:
Do we even need the hwspin_lock variants,
I personally don't have any specific use case in mind.
It's just a simple wrapper over the _timeout variants, provided for
API completeness, but -
why can't we always use the
Cousson (1):
OMAP4: hwmod data: Add hwspinlock
Ohad Ben-Cohen (1):
drivers: hwspinlock: add framework
Simon Que (2):
drivers: hwspinlock: add OMAP implementation
omap: add hwspinlock device
Documentation/hwspinlock.txt | 299 +++
arch/arm/mach-omap2/Makefile
Add a platform-independent hwspinlock framework.
Hardware spinlock devices are needed, e.g., in order to access data
that is shared between remote processors, that otherwise have no
alternative mechanism to accomplish synchronization and mutual exclusion
operations.
Signed-off-by: Ohad Ben-Cohen
From: Benoit Cousson b-cous...@ti.com
Add hwspinlock hwmod data for OMAP4 chip
Signed-off-by: Cousson, Benoit b-cous...@ti.com
Signed-off-by: Hari Kanigeri h-kanige...@ti.com
Signed-off-by: Ohad Ben-Cohen o...@wizery.com
Cc: Paul Walmsley p...@pwsan.com
---
arch/arm/mach-omap2
: adapt to hwspinlock framework, tidy up]
Signed-off-by: Simon Que s...@ti.com
Signed-off-by: Hari Kanigeri h-kanige...@ti.com
Signed-off-by: Krishnamoorthy, Balaji T balaj...@ti.com
Signed-off-by: Ohad Ben-Cohen o...@wizery.com
Cc: Benoit Cousson b-cous...@ti.com
Cc: Kevin Hilman khil
...@ti.com
Signed-off-by: Hari Kanigeri h-kanige...@ti.com
Signed-off-by: Ohad Ben-Cohen o...@wizery.com
Cc: Benoit Cousson b-cous...@ti.com
Cc: Kevin Hilman khil...@deeprootsystems.com
Cc: Paul Walmsley p...@pwsan.com
---
arch/arm/mach-omap2/Makefile |1 +
arch/arm/mach-omap2/hwspinlock.c
On Sat, Dec 4, 2010 at 2:29 AM, David Daney dda...@caviumnetworks.com wrote:
Does anything other than OMAP4 have one of these things?
I'm not aware of any, but David Brownell had some ideas about it in
our previous v2 discussion (see
Introduce BUG_ON_MAPPABLE_NULL in order to eliminate redundant BUG_ON
code, checking for NULL addresses, on architectures where the zero
address can never be mapped.
Originally proposed by Russell King li...@arm.linux.org.uk
Signed-off-by: Ohad Ben-Cohen o...@wizery.com
---
Compile tested on ARM
On Wed, Dec 8, 2010 at 2:10 AM, Andrew Morton a...@linux-foundation.org wrote:
Every time someone sends me a patch with text after the ---, I decide
it was good changelog material and I promote it to above the ---.
How's about you save us the effort :)
sure :)
+/**
+ *
On Sat, Dec 11, 2010 at 9:59 PM, Elvis Dowson elvis.dow...@mac.com wrote:
mmc1: card claims to support voltages below the defined range. These will be
ignored.
This is expected - not an error.
When I build the TI WiLink drivers from the ti rowboat hardware/ti/wlan
project
The linux-omap
Hi Laurent,
On Sun, Dec 12, 2010 at 2:44 PM, Laurent Pinchart
laurent.pinch...@ideasonboard.com [ 191.085479] {IN-SOFTIRQ-W}
state was registered at:
[ 191.090576] [c008e914] __lock_acquire+0x5f0/0x17c4
[ 191.095947] [c008fbc0] lock_acquire+0xd8/0xfc
[ 191.100860] [c0373d3c]
On Sun, Dec 12, 2010 at 4:15 PM, Ionut Nicu ionut.n...@mindbit.ro wrote:
I noticed this too, but this patch should fix it:
https://patchwork.kernel.org/patch/365292/
True. And in this patch the move to spin_lock_bh() is justifiable,
too, since it adds a sending path which is parallel to the
On Mon, Dec 13, 2010 at 6:45 PM, Laurent Pinchart
laurent.pinch...@ideasonboard.com On Sun, Dec 12, 2010 at 4:15
PM, Ionut Nicu ionut.n...@mindbit.ro wrote:
I noticed this too, but this patch should fix it:
https://patchwork.kernel.org/patch/365292/
True. And in this patch the move to
Hi Greg, Tony,
On Sat, Dec 4, 2010 at 1:50 AM, Ohad Ben-Cohen o...@wizery.com wrote:
OMAP4 introduces a Hardware Spinlock device, which provides hardware
assistance for synchronization and mutual exclusion between heterogeneous
processors and those not operating under a single, shared
On Tue, Dec 14, 2010 at 7:06 PM, Greg KH g...@kroah.com wrote:
Can you please have a look and say if this looks OK ?
Look at what, I don't see a patch here.
Here's the complete patchset:
http://www.mail-archive.com/linux-omap@vger.kernel.org/msg39833.html
If you prefer, I can resubmit.
Hi Tony,
On Wed, Nov 24, 2010 at 12:04 PM, Ohad Ben-Cohen o...@wizery.com wrote:
Power to the wl12xx wlan device is controlled by a fixed regulator.
Boards that have the wl12xx should select REGULATOR_FIXED_VOLTAGE so
users will not be baffled.
Not sure if you picked this up ?
We need
On Tue, Dec 14, 2010 at 8:40 PM, Ohad Ben-Cohen o...@wizery.com wrote:
On Tue, Dec 14, 2010 at 7:06 PM, Greg KH g...@kroah.com wrote:
Like the most important one, why is this generic code if
it's only for one specific platform?
We started out with an omap-specific driver, but Tony preferred
On Thu, Dec 16, 2010 at 11:08 PM, Greg KH g...@kroah.com wrote:
I've seen a lot of discussion about this, are all of the review comments
now addressed?
Yes, all comments were addressed in this v3 iteration, and this thread
has been idle for about 10 days.
That's because we are all busy
Hi Felipe,
On Mon, Dec 20, 2010 at 8:43 PM, Felipe Contreras
felipe.contre...@nokia.com wrote:
We need to protect not only the dmm_map list, but the individual
map_obj's, otherwise, we might be building the scatter-gather list with
garbage.
Thanks for reporting this !
So, use the existing
Hi Felipe,
On Tue, Dec 21, 2010 at 6:44 PM, Felipe Contreras
felipe.contre...@gmail.com wrote:
Wouldn't you want the proc_*_dma() operations to finish before
unmaping the pages?
Yes, but that's not what your patch is doing exactly: it serializes
the execution of proc_begin_dma(),
On Mon, Dec 27, 2010 at 3:55 PM, Felipe Contreras
felipe.contre...@nokia.com wrote:
So, effectively, serializing the proc_begin_dma() and proc_end_dma()
would not affect anyone negatively for the time being.
You can never really tell who is using the kernel (or will be using
this kernel
On Tue, Dec 28, 2010 at 12:36 PM, Felipe Contreras
felipe.contre...@gmail.com wrote:
You can never really tell who is using the kernel (or will be using
this kernel version), how and under which workload.
No, but it's better to address real issues rather than hypothetical.
Right. and both
On Tue, Dec 28, 2010 at 2:12 PM, Felipe Contreras
felipe.contre...@gmail.com wrote:
I haven't investigated why that happens, but kernel-space should not
panic regardless of what user-space does.
Agree of course. But that's not what we were discussing...
Anyhow, a thread that is calling
On Tue, Dec 28, 2010 at 2:24 PM, Felipe Contreras
felipe.contre...@gmail.com wrote:
user-space crashed, not kernel-space; the code would continue to run
and eventually release the lock.
So you'll have to be more specific about the scenario you are describing.
If there's a user thread that is
On Tue, Dec 28, 2010 at 2:12 PM, Felipe Contreras
felipe.contre...@gmail.com wrote:
On Tue, Dec 28, 2010 at 12:56 PM, Ohad Ben-Cohen o...@wizery.com wrote:
I still don't know how exactly you triggered the bug: is gst-dsp
multithreaded ? and one of its threads invoked proc_un_map() while
On Wed, Dec 29, 2010 at 11:39 AM, Felipe Contreras
felipe.contre...@gmail.com wrote:
On Tue, Dec 28, 2010 at 2:37 PM, Ohad Ben-Cohen o...@wizery.com wrote:
On Tue, Dec 28, 2010 at 2:24 PM, Felipe Contreras
felipe.contre...@gmail.com wrote:
user-space crashed, not kernel-space; the code would
Hi Andrew,
On Sat, Dec 18, 2010 at 2:53 AM, Tony Lindgren t...@atomide.com wrote:
* Ohad Ben-Cohen o...@wizery.com [101216 13:34]:
Tony, Andrew, can you please have a look ?
Any comment or suggestion is appreciated.
Looks sane to me from omap point of view and it seems the locks
are now
On Wed, Nov 24, 2010 at 12:04 PM, Ohad Ben-Cohen o...@wizery.com wrote:
Power to the wl12xx wlan device is controlled by a fixed regulator.
Boards that have the wl12xx should select REGULATOR_FIXED_VOLTAGE so
users will not be baffled.
Signed-off-by: Ohad Ben-Cohen o...@wizery.com
---
Hi
On Tue, Jan 4, 2011 at 9:17 PM, Tony Lindgren t...@atomide.com wrote:
* Ohad Ben-Cohen o...@wizery.com [110104 10:04]:
On Wed, Nov 24, 2010 at 12:04 PM, Ohad Ben-Cohen o...@wizery.com wrote:
Power to the wl12xx wlan device is controlled by a fixed regulator.
Boards that have the wl12xx
On Tue, Jan 4, 2011 at 10:19 PM, Andrew Morton
a...@linux-foundation.org wrote:
Acked-by: Tony Lindgren t...@atomide.com
Can you please have a look at this patch set (see link no. [1] below) ?
I looked - it looks reasonable. This is exactly the wrong time to be
looking at large new
Hi Koen,
On Fri, Jan 21, 2011 at 4:49 PM, Luciano Coelho coe...@ti.com wrote:
My patch basically does:
--- a/arch/arm/mach-omap2/board-omap3beagle.c
+++ b/arch/arm/mach-omap2/board-omap3beagle.c
@@ -270,7 +270,7 @@ static struct omap2_hsmmc_info mmc[] = {
{
.name
On Sat, Jan 22, 2011 at 5:30 PM, Koen Kooi k...@dominion.thruhere.net wrote:
That was indeed the problem, not I get:
[ 35.417053] wl1271: firmware booted (Rev 6.1.0.0.343)
and
root@beagleboard-xm-next:~# ifconfig wlan0 hw eth 00:11:22:33:44:55
root@beagleboard-xm-next:~# iwlist wlan0
/gmane.linux.ports.arm.omap/39187
[4] http://thread.gmane.org/gmane.linux.ports.arm.omap/39365
[5] http://thread.gmane.org/gmane.linux.ports.arm.omap/39815
[6] http://thread.gmane.org/gmane.linux.ports.arm.omap/40901
Benoit Cousson (1):
OMAP4: hwmod data: Add hwspinlock
Ohad Ben-Cohen (1):
drivers: hwspinlock: add
Add a platform-independent hwspinlock framework.
Hardware spinlock devices are needed, e.g., in order to access data
that is shared between remote processors, that otherwise have no
alternative mechanism to accomplish synchronization and mutual exclusion
operations.
Signed-off-by: Ohad Ben-Cohen
: adapt to hwspinlock framework, tidy up]
Signed-off-by: Simon Que s...@ti.com
Signed-off-by: Hari Kanigeri h-kanige...@ti.com
Signed-off-by: Krishnamoorthy, Balaji T balaj...@ti.com
Signed-off-by: Ohad Ben-Cohen o...@wizery.com
Cc: Benoit Cousson b-cous...@ti.com
Cc: Kevin Hilman khil...@ti.com
Cc
From: Benoit Cousson b-cous...@ti.com
Add hwspinlock hwmod data for OMAP4 chip
Signed-off-by: Cousson, Benoit b-cous...@ti.com
Signed-off-by: Hari Kanigeri h-kanige...@ti.com
Signed-off-by: Ohad Ben-Cohen o...@wizery.com
Cc: Paul Walmsley p...@pwsan.com
Acked-by: Tony Lindgren t...@atomide.com
...@ti.com
Signed-off-by: Hari Kanigeri h-kanige...@ti.com
Signed-off-by: Ohad Ben-Cohen o...@wizery.com
Cc: Benoit Cousson b-cous...@ti.com
Cc: Kevin Hilman khil...@ti.com
Cc: Paul Walmsley p...@pwsan.com
Acked-by: Tony Lindgren t...@atomide.com
---
arch/arm/mach-omap2/Makefile |1 +
arch
On Tue, Feb 1, 2011 at 1:38 AM, Andrew Morton a...@linux-foundation.org wrote:
It's a little irritating having two hwspinlock.h's.
hwspinlock_internal.h wold be a conventional approach. But it's not a
big deal.
...
+/**
+ * __hwspin_lock_timeout() - lock an hwspinlock with timeout limit
+
On Tue, Feb 1, 2011 at 8:38 AM, Andrew Morton a...@linux-foundation.org wrote:
I'll do a quick respin of the patches with that and the
hwspinlock_internal.h comment above.
OK..
The patch series looks OK to me.
Can I add your Acked-by on the non-omap parts when I respin the series ?
Thanks,
On Tue, Feb 1, 2011 at 9:40 AM, Andrew Morton a...@linux-foundation.org wrote:
On Tue, 1 Feb 2011 09:36:22 +0200 Ohad Ben-Cohen o...@wizery.com wrote:
On Tue, Feb 1, 2011 at 8:38 AM, Andrew Morton a...@linux-foundation.org
wrote:
I'll do a quick respin of the patches
On Wed, Feb 2, 2011 at 2:11 AM, Tony Lindgren t...@atomide.com wrote:
* Ohad Ben-Cohen o...@wizery.com [110122 07:47]:
On Sat, Jan 22, 2011 at 5:30 PM, Koen Kooi k...@dominion.thruhere.net
wrote:
That was indeed the problem, not I get:
[ 35.417053] wl1271: firmware booted (Rev
/gmane.linux.ports.arm.omap/39365
[5] http://thread.gmane.org/gmane.linux.ports.arm.omap/39815
[6] http://thread.gmane.org/gmane.linux.ports.arm.omap/40901
Benoit Cousson (1):
OMAP4: hwmod data: Add hwspinlock
Ohad Ben-Cohen (1):
drivers: hwspinlock: add framework
Simon Que (2):
drivers: hwspinlock: add OMAP
: adapt to hwspinlock framework, tidy up]
Signed-off-by: Simon Que s...@ti.com
Signed-off-by: Hari Kanigeri h-kanige...@ti.com
Signed-off-by: Krishnamoorthy, Balaji T balaj...@ti.com
Signed-off-by: Ohad Ben-Cohen o...@wizery.com
Cc: Benoit Cousson b-cous...@ti.com
Cc: Kevin Hilman khil...@ti.com
Cc
Add a platform-independent hwspinlock framework.
Hardware spinlock devices are needed, e.g., in order to access data
that is shared between remote processors, that otherwise have no
alternative mechanism to accomplish synchronization and mutual exclusion
operations.
Signed-off-by: Ohad Ben-Cohen
From: Benoit Cousson b-cous...@ti.com
Add hwspinlock hwmod data for OMAP4 chip
Signed-off-by: Cousson, Benoit b-cous...@ti.com
Signed-off-by: Hari Kanigeri h-kanige...@ti.com
Signed-off-by: Ohad Ben-Cohen o...@wizery.com
Cc: Paul Walmsley p...@pwsan.com
Acked-by: Tony Lindgren t...@atomide.com
...@ti.com
Signed-off-by: Hari Kanigeri h-kanige...@ti.com
Signed-off-by: Ohad Ben-Cohen o...@wizery.com
Cc: Benoit Cousson b-cous...@ti.com
Cc: Kevin Hilman khil...@ti.com
Cc: Paul Walmsley p...@pwsan.com
Acked-by: Tony Lindgren t...@atomide.com
---
arch/arm/mach-omap2/Makefile |1 +
arch
.
Please review and let me know your comments.
Thanks,
Ohad Ben-Cohen (4):
omap: mailbox cleanup: convert rwlocks to spinlock
omap: mailbox cleanup: split MODULE_AUTHOR line
omap: mailbox: fix reverse likeliness
omap: mailbox: convert block api to kfifo
arch/arm/mach-omap2/mailbox.c
rwlocks are slower and have potential starvation issues so spinlocks are
generally preferred
Signed-off-by: Ohad Ben-Cohen o...@wizery.com
---
arch/arm/plat-omap/mailbox.c | 20 ++--
1 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/arch/arm/plat-omap/mailbox.c b
use multiple MODULE_AUTHOR lines for multiple authors
Signed-off-by: Ohad Ben-Cohen o...@wizery.com
---
arch/arm/mach-omap2/mailbox.c |3 ++-
arch/arm/plat-omap/mailbox.c |3 ++-
2 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/mailbox.c b/arch/arm/mach
Fix reverse likeliness
Signed-off-by: Ohad Ben-Cohen o...@wizery.com
---
arch/arm/plat-omap/mailbox.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/plat-omap/mailbox.c b/arch/arm/plat-omap/mailbox.c
index 8abf0e8..72b17ad 100644
--- a/arch/arm/plat-omap
The underlying buffering implementation of mailbox
is converted from block API to kfifo due to the simplicity
and speed of kfifo.
Signed-off-by: Ohad Ben-Cohen o...@wizery.com
Signed-off-by: Hari Kanigeri h-kanige...@ti.com
---
arch/arm/plat-omap/include/plat/mailbox.h |5 +-
arch/arm/plat
Hi Hiroshi,
On Wed, Apr 28, 2010 at 10:50 AM, Hiroshi DOYU hiroshi.d...@nokia.com wrote:
Hi Ohad,
From: ext Ohad Ben-Cohen o...@wizery.com
Subject: [PATCH 1/4] omap: mailbox cleanup: convert rwlocks to spinlock
Date: Tue, 27 Apr 2010 19:56:19 +0200
rwlocks are slower and have potential
Hi Hiroshi,
On Wed, Apr 28, 2010 at 8:52 AM, Hiroshi DOYU hiroshi.d...@nokia.com wrote:
Hi Ohad,
From: ext Ohad Ben-Cohen o...@wizery.com
Subject: [PATCH 4/4] omap: mailbox: convert block api to kfifo
Date: Tue, 27 Apr 2010 19:56:22 +0200
The underlying buffering implementation of mailbox
On Wed, Apr 28, 2010 at 8:56 AM, Hiroshi DOYU hiroshi.d...@nokia.com wrote:
From: ext Ohad Ben-Cohen o...@wizery.com
Subject: [PATCH 4/4] omap: mailbox: convert block api to kfifo
Date: Tue, 27 Apr 2010 19:56:22 +0200
The underlying buffering implementation of mailbox
is converted from block
On Wed, Apr 28, 2010 at 2:16 PM, Hiroshi DOYU hiroshi.d...@nokia.com wrote:
From: ext Ohad Ben-Cohen o...@wizery.com
Subject: Re: [PATCH 4/4] omap: mailbox: convert block api to kfifo
Date: Wed, 28 Apr 2010 13:02:06 +0200
diff --git a/arch/arm/plat-omap/mailbox.c b/arch/arm/plat-omap
On Wed, Apr 28, 2010 at 2:52 PM, Hiroshi DOYU hiroshi.d...@nokia.com wrote:
From: ext Ohad Ben-Cohen o...@wizery.com
Subject: Re: [PATCH 4/4] omap: mailbox: convert block api to kfifo
Date: Wed, 28 Apr 2010 13:25:41 +0200
On Wed, Apr 28, 2010 at 2:16 PM, Hiroshi DOYU hiroshi.d...@nokia.com
-ops-shutdown(mbox);
- write_unlock(mboxes_lock);
+ spin_unlock(mboxes_lock);
}
}
--
-Original Message-
From: Ohad Ben-Cohen [mailto:o...@wizery.com]
Sent: Tuesday, April 27, 2010 12:56 PM
To: linux-omap@vger.kernel.org
Cc
On Thu, Apr 29, 2010 at 4:14 PM, Ohad Ben-Cohen o...@wizery.com wrote:
Hi Hari,
On Thu, Apr 29, 2010 at 3:44 PM, Kanigeri, Hari h-kanige...@ti.com wrote:
Ohad,
Looks like the conversion was missed in few places resulting in compile
warnings.
Thanks for pointing that out - that's really
reach me at ohadb at ti dot com .
Ohad Ben-Cohen (6):
DSPBRIDGE: add memory_map_info to PROC
DSPBRIDGE: remember mapping and page info in proc_map
DSPBRIDGE: remove mapping information in proc_unmap
DSPBRIDGE: do not call follow_page
DSPBRIDGE: do not use low level cache manipulation
Add the memory_map_info structure which will be used to maintain
mapping and page information. Every memory mapping requested by the
MM application will be remembered and kept in a linked list
inside the proc object.
Signed-off-by: Ohad Ben-Cohen o...@wizery.com
---
If you want, you can also
Every time the MM application calls proc_map to map
a memory area, remember the details of that mapping,
together with the related page structures.
Signed-off-by: Ohad Ben-Cohen o...@wizery.com
---
If you want, you can also reach me at ohadb at ti dot com .
arch/arm/plat-omap/include
Clean up all mapping information resources whenever
a buffer is unmapped.
Signed-off-by: Ohad Ben-Cohen o...@wizery.com
---
If you want, you can also reach me at ohadb at ti dot com .
drivers/dsp/bridge/rmgr/proc.c | 43
1 files changed, 43
Eliminate the call to follow_page. Instead, use the page
information that was kept during the proc_map call.
This also has the advantage that users can now only
specify memory areas that were previously mapped.
Signed-off-by: Ohad Ben-Cohen o...@wizery.com
---
If you want, you can also reach me
memory mapping of that
application, the request is denied.
Signed-off-by: Ohad Ben-Cohen o...@wizery.com
---
If you want, you can also reach me at ohadb at ti dot com .
arch/arm/plat-omap/include/dspbridge/_dcd.h |4 +-
arch/arm/plat-omap/include/dspbridge/proc.h |4 +-
arch/arm
application can mark the end of a DMA transfer (and thus regain
ownership of the buffer).
Signed-off-by: Ohad Ben-Cohen o...@wizery.com
---
If you want, you can also reach me at ohadb at ti dot com .
arch/arm/plat-omap/include/dspbridge/_dcd.h |2 +
arch/arm/plat-omap/include/dspbridge/proc.h
On Sat, May 1, 2010 at 11:44 PM, Ohad Ben-Cohen o...@wizery.com wrote:
Instead of using low level cache manipulation API,
use the standard DMA API. This changes the concept
of the dspbridge cache API a little, hence the naming changes:
* Flush marks the beginning of a DMA transfer from
.
Ohad Ben-Cohen (4):
omap: mailbox: convert rwlocks to spinlock
omap: mailbox cleanup: split MODULE_AUTHOR line
omap: mailbox: fix reverse likeliness
omap: mailbox: convert block api to kfifo
arch/arm/mach-omap2/mailbox.c |3 +-
arch/arm/plat-omap/Kconfig|9
rwlocks are slower and have potential starvation issues
therefore spinlocks are generally preferred.
see also: http://lwn.net/Articles/364583/
Signed-off-by: Ohad Ben-Cohen o...@wizery.com
Signed-off-by: Kanigeri Hari h-kanige...@ti.com
---
If you want, you can also reach me at ohadb at ti dot
use multiple MODULE_AUTHOR lines for multiple authors
Signed-off-by: Ohad Ben-Cohen o...@wizery.com
---
If you want, you can also reach me at ohadb at ti dot com .
arch/arm/mach-omap2/mailbox.c |3 ++-
arch/arm/plat-omap/mailbox.c |3 ++-
2 files changed, 4 insertions(+), 2 deletions
On Sun, May 2, 2010 at 4:17 PM, Felipe Contreras
felipe.contre...@gmail.com wrote:
On Sat, May 1, 2010 at 11:44 PM, Ohad Ben-Cohen o...@wizery.com wrote:
This patchset introduces an approach to eliminate the direct calls
to follow_page and to the low level cache APIs.
The patchset works
On Mon, May 3, 2010 at 8:30 AM, Hiroshi DOYU hiroshi.d...@nokia.com wrote:
Hi Ohad,
From: ext Ohad Ben-Cohen o...@wizery.com
Subject: [PATCH v2 4/4] omap: mailbox: convert block api to kfifo
Date: Sun, 2 May 2010 17:44:31 +0200
The underlying buffering implementation of mailbox
On Mon, May 3, 2010 at 9:07 AM, Hiroshi DOYU hiroshi.d...@nokia.com wrote:
From: Hiroshi DOYU hiroshi.d...@nokia.com
Subject: Re: [PATCH v2 4/4] omap: mailbox: convert block api to kfifo
Date: Mon, 03 May 2010 08:30:36 +0300 (EEST)
Hi Ohad,
From: ext Ohad Ben-Cohen o...@wizery.com
Subject
(via the mbox_kfifo_size module parameter).
Signed-off-by: Ohad Ben-Cohen o...@wizery.com
Signed-off-by: Hari Kanigeri h-kanige...@ti.com
---
if you want, you can also reach me at ohadb at ti dot com .
arch/arm/plat-omap/Kconfig|9 +++
arch/arm/plat-omap/include/plat/mailbox.h
On Mon, May 3, 2010 at 9:02 PM, Tony Lindgren t...@atomide.com wrote:
* Ohad Ben-Cohen o...@wizery.com [100502 08:40]:
Fix reverse likeliness
Signed-off-by: Ohad Ben-Cohen o...@wizery.com
---
If you want, you can also reach me at ohadb at ti dot com .
arch/arm/plat-omap/mailbox.c | 4
On Wed, May 5, 2010 at 6:21 PM, Tony Lindgren t...@atomide.com wrote:
* Ohad Ben-Cohen o...@wizery.com [100504 04:42]:
On Mon, May 3, 2010 at 9:02 PM, Tony Lindgren t...@atomide.com wrote:
* Ohad Ben-Cohen o...@wizery.com [100502 08:40]:
Fix reverse likeliness
Signed-off-by: Ohad Ben
This series includes comments from Hiroshi and Tony (thanks!).
Changes since v2:
- add mbox_kfifo_size module parameter sanity checks
- remove (un)likely macros from cold mailbox paths
Thanks,
Ohad.
---
If you want, you can also reach me at ohadb at ti dot com .
Ohad Ben-Cohen (4):
omap
rwlocks are slower and have potential starvation issues
therefore spinlocks are generally preferred.
see also: http://lwn.net/Articles/364583/
Signed-off-by: Ohad Ben-Cohen o...@wizery.com
Signed-off-by: Kanigeri Hari h-kanige...@ti.com
---
If you want, you can also reach me at ohadb at ti dot
use multiple MODULE_AUTHOR lines for multiple authors
Signed-off-by: Ohad Ben-Cohen o...@wizery.com
---
If you want, you can also reach me at ohadb at ti dot com .
arch/arm/mach-omap2/mailbox.c |3 ++-
arch/arm/plat-omap/mailbox.c |3 ++-
2 files changed, 4 insertions(+), 2 deletions
Signed-off-by: Ohad Ben-Cohen o...@wizery.com
---
If you want, you can also reach me at ohadb at ti dot com .
arch/arm/plat-omap/mailbox.c | 10 +-
1 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/arch/arm/plat-omap/mailbox.c b/arch/arm/plat-omap/mailbox.c
index 5140efc
(via the mbox_kfifo_size module parameter).
Signed-off-by: Ohad Ben-Cohen o...@wizery.com
Signed-off-by: Hari Kanigeri h-kanige...@ti.com
---
If you want, you can also reach me at ohadb at ti dot com .
arch/arm/plat-omap/Kconfig|9 +++
arch/arm/plat-omap/include/plat/mailbox.h
Hi Felipe,
On Fri, May 14, 2010 at 10:27 PM, Felipe Contreras
felipe.contre...@gmail.com wrote:
Hi,
I spent some time looking deeper into this patch series, and I have some
doubts.
On Sun, May 2, 2010 at 8:47 PM, Ohad Ben-Cohen o...@wizery.com wrote:
On Sun, May 2, 2010 at 4:17 PM, Felipe
PM, Ohad Ben-Cohen o...@wizery.com wrote:
Basically you're right, but the patches currently silently allow
today's user space
to somehow work (because if you don't use dma bounce buffers and you feel
lucky
about speculative prefetching then you might get away with not calling
dma unmap).
I
Hi Felipe,
On Sat, May 15, 2010 at 11:34 AM, Felipe Contreras
felipe.contre...@gmail.com wrote:
On Sat, May 1, 2010 at 11:44 PM, Ohad Ben-Cohen o...@wizery.com wrote:
Every time the MM application calls proc_map to map
a memory area, remember the details of that mapping,
together
Hi Felipe,
On Sat, May 15, 2010 at 11:38 AM, Felipe Contreras
felipe.contre...@gmail.com wrote:
On Sat, May 1, 2010 at 11:44 PM, Ohad Ben-Cohen o...@wizery.com wrote:
Clean up all mapping information resources whenever
a buffer is unmapped.
If I understand correctly the previous patch
On Mon, May 17, 2010 at 2:15 AM, Felipe Contreras
felipe.contre...@gmail.com wrote:
Hi Ohad,
On Mon, May 17, 2010 at 1:35 AM, Ohad Ben-Cohen o...@wizery.com wrote:
On Fri, May 14, 2010 at 10:27 PM, Felipe Contreras
felipe.contre...@gmail.com wrote:
I looked into the dma code (I guess it's
On Mon, May 17, 2010 at 2:15 AM, Felipe Contreras
felipe.contre...@gmail.com wrote:
Hi Ohad,
On Mon, May 17, 2010 at 1:35 AM, Ohad Ben-Cohen o...@wizery.com wrote:
On Fri, May 14, 2010 at 10:27 PM, Felipe Contreras
felipe.contre...@gmail.com wrote:
I looked into the dma code (I guess it's
Hi Felipe,
On Mon, May 17, 2010 at 3:05 AM, Felipe Contreras
felipe.contre...@gmail.com wrote:
On Mon, May 17, 2010 at 2:25 AM, Ohad Ben-Cohen o...@wizery.com wrote:
Out of curiosity, what board/environment do you use to play with
the code ? I'd like to run the same use cases you do, so I can
On Mon, May 17, 2010 at 2:51 AM, Felipe Contreras
felipe.contre...@gmail.com wrote:
So currently (v2.6.33), before sending a read-olny buffer (TO_DEVICE),
we do dmac_flush_range (should be clean, but whatever) and before
sending a write-only (FROM_DEVICE), we do dmac_inv_range.
On v2.6.33 the
On Tue, May 18, 2010 at 2:02 PM, Felipe Contreras
felipe.contre...@gmail.com wrote:
On Tue, May 18, 2010 at 11:05 AM, Ohad Ben-Cohen o...@wizery.com wrote:
On Mon, May 17, 2010 at 2:51 AM, Felipe Contreras
felipe.contre...@gmail.com wrote:
So currently (v2.6.33), before sending a read-olny
On Tue, May 18, 2010 at 2:43 PM, Felipe Contreras
felipe.contre...@gmail.com wrote:
On Tue, May 18, 2010 at 2:14 PM, Ohad Ben-Cohen o...@wizery.com wrote:
Unfortunately I don't have a setup right now to test this, but the code
seems to be ok for our needs, don't you think ?
But yeah, actually
On Tue, May 18, 2010 at 3:24 PM, Felipe Contreras
felipe.contre...@gmail.com wrote:
Cool. I actually tried your patches to render to the framebuffer, and
everything seemed to work fine. I didn't check for error codes or
anything, so I'm not sure what's going on.
How is the framebuffer mmap'ed
101 - 200 of 776 matches
Mail list logo
