From: Mark Grosen mgro...@ti.com
Add remoteproc implementation for da850, so we can boot its DSP.
Signed-off-by: Mark Grosen mgro...@ti.com
Signed-off-by: Ohad Ben-Cohen o...@wizery.com
---
arch/arm/mach-davinci/include/mach/remoteproc.h | 28 +
drivers/remoteproc/Kconfig
implementation in a dedicated drivers/rpmsg/host folder,
with the intention of stacking different rpmsg host implementations
in one place.
Signed-off-by: Ohad Ben-Cohen o...@wizery.com
---
drivers/rpmsg/Kconfig |2 +
drivers/rpmsg/Makefile |2 +
drivers/rpmsg/host/Kconfig
From: Mark Grosen mgro...@ti.com
Add davinci remoteproc device for the da850's C674x dsp remote
processor, and support it on the da850-evm and omapl138-hawk boards.
Signed-off-by: Mark Grosen mgro...@ti.com
Signed-off-by: Ohad Ben-Cohen o...@wizery.com
---
It'd be nice to split this patch
...@ti.com
Signed-off-by: Ohad Ben-Cohen o...@wizery.com
---
arch/arm/mach-omap2/Makefile |2 +
arch/arm/mach-omap2/remoteproc.c | 159 ++
2 files changed, 161 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/mach-omap2/remoteproc.c
diff --git
-off-by: Ohad Ben-Cohen o...@wizery.com
---
arch/arm/plat-omap/include/plat/remoteproc.h | 41 +
drivers/remoteproc/Kconfig | 21 +++
drivers/remoteproc/Makefile |1 +
drivers/remoteproc/omap_remoteproc.c | 243 ++
4
and handling IOMMUs, consider
moving to the generic DMA mapping API (with a CMA backend)
Signed-off-by: Ohad Ben-Cohen o...@wizery.com
---
Documentation/remoteproc.txt| 170 +
drivers/Kconfig |2 +
drivers/Makefile|1 +
drivers/remoteproc/Kconfig
On Tue, Jun 21, 2011 at 10:50 AM, Ohad Ben-Cohen o...@wizery.com wrote:
root@omap4430-panda:~# cat /debug/remoteproc/omap-rproc.1/state
running (2)
At this point, the two remote M3 cores also start dumping trace logs to
shared memory buffers, which are exposed by debugfs entries:
root@omap4430
On Tue, Jun 14, 2011 at 1:29 PM, Roedel, Joerg joerg.roe...@amd.com wrote:
Btw, what tree do these patches apply against?
v3.0-rc2
I tried to apply them to v3.0-rc3 and got conflicts.
What kind of conflicts ? I just tried rc3 and it applied cleanly.
Just in case, I'm attaching the patches
On Mon, Jun 13, 2011 at 7:41 PM, Laurent Pinchart
laurent.pinch...@ideasonboard.com wrote:
Laurent Pinchart (2):
...
omap3: iovmm: Support non page-aligned buffers in iommu_vmap
...
OK. Ohad, could you please apply this patch to your tree and submit it with
the whole series for 3.1 ?
On Thu, Jun 9, 2011 at 1:27 AM, David Brown dav...@codeaurora.org wrote:
Moving the driver is good. I'm wondering what we should do with
iommu_dev.c, though. Wouldn't it make sense to move this file as well?
Yeah, it does make sense. I'll move that one too, thanks.
--
To unsubscribe from this
(David Brown)
* dmar: depend on x86/ia64, fix ia64 Kconfig, drop EXPERIMENTAL (Chris Wright)
Ohad Ben-Cohen (4):
drivers: iommu: move to a dedicated folder
msm: iommu: move to drivers/iommu/
x86: amd_iommu: move to drivers/iommu/
x86/ia64: intel-iommu: move to drivers/iommu/
arch/arm/mach-msm
differently (or duplicated) in each driver.
Signed-off-by: Ohad Ben-Cohen o...@wizery.com
---
arch/arm/mach-msm/Kconfig |3 ---
arch/ia64/Kconfig |3 ---
arch/x86/Kconfig|5 ++---
drivers/Kconfig |2 ++
drivers/Makefile
This should ease finding similarities with different platforms,
with the intention of solving problems once in a generic framework
which everyone can use.
Compile-tested for MSM8X60.
Signed-off-by: Ohad Ben-Cohen o...@wizery.com
---
arch/arm/mach-msm/Kconfig | 16
This should ease finding similarities with different platforms,
with the intention of solving problems once in a generic framework
which everyone can use.
Compile-tested on x86_64.
Signed-off-by: Ohad Ben-Cohen o...@wizery.com
---
arch/x86/Kconfig | 28
. This is handled
in this patch, too.
As suggested, also drop DMAR's EXPERIMENTAL tag while we're at it.
Compile-tested on x86_64.
Signed-off-by: Ohad Ben-Cohen o...@wizery.com
---
sorry, not tested on ia64 (not even compiled)
arch/ia64/Kconfig | 21 -
arch/x86
On Wed, Jun 8, 2011 at 1:46 PM, Laurent Pinchart
laurent.pinch...@ideasonboard.com wrote:
On Tuesday 07 June 2011 15:46:26 Ohad Ben-Cohen wrote:
Where do you take care of those potential offsets today ? Or do you
simply ignore the offsets and map the entire page ?
Here http://marc.info/?l
iovmm is erroneously using sg_dma_len with unmapped (DMA API-wise)
SG entries, and will break if CONFIG_NEED_SG_DMA_LENGTH is enabled.
Fix that by using sg-length instead.
Reported-by: Russell King li...@arm.linux.org.uk
Signed-off-by: Ohad Ben-Cohen o...@wizery.com
---
arch/arm/plat-omap
This should ease finding similarities with different platforms,
with the intention of solving problems once in a generic framework
which everyone can use.
Compile-tested on x86_64.
Signed-off-by: Ohad Ben-Cohen o...@wizery.com
---
arch/x86/Kconfig | 28
. This is handled
in this patch, too.
Compile-tested on x86_64.
Signed-off-by: Ohad Ben-Cohen o...@wizery.com
---
arch/x86/Kconfig | 11 ---
drivers/iommu/Kconfig| 11 +++
drivers/iommu/Makefile |1 +
drivers/{pci = iommu}/intel
,
in a generic framework, which everyone can use.
OMAP's iommu will be moved too as soon as it's migrated.
For previous discussions on this, please see:
https://lkml.org/lkml/2011/6/2/369
Ohad Ben-Cohen (4):
drivers: iommu: move to a dedicated folder
msm: iommu: move to drivers/iommu/
x86
differently (or duplicated) in each driver.
Signed-off-by: Ohad Ben-Cohen o...@wizery.com
---
arch/arm/mach-msm/Kconfig |3 ---
arch/x86/Kconfig|5 ++---
drivers/Kconfig |2 ++
drivers/Makefile|1 +
drivers/base/Makefile
This should ease finding similarities with different platforms,
with the intention of solving problems once in a generic framework
which everyone can use.
Compile-tested for MSM8X60.
Signed-off-by: Ohad Ben-Cohen o...@wizery.com
---
arch/arm/mach-msm/Kconfig | 12
On Wed, Jun 8, 2011 at 12:17 PM, David Woodhouse dw...@infradead.org wrote:
At least iova.o wants to go with it. That's one of the parts that is a
candidate for harmonisation across IOMMU implementations, either by
removing it or by having others use it too. It's how we allocate virtual
I/O
On Wed, Jun 8, 2011 at 4:05 PM, Matthew Wilcox matt...@wil.cx wrote:
You've missed at least parisc, ia64, alpha, sparc, powerpc and sh which
have IOMMUs.
None of these seem to call register_iommu.
Not that they necessarily all need to be moved across in
one patchset, but saying all iommu
On Wed, Jun 8, 2011 at 8:47 PM, Chris Wright chr...@sous-sol.org wrote:
You may want to further restrict to x86 and ia64
And I think you'll need to fixup arch/ia64/Kconfig
BTW, I think EXPERIMENTAL can be dropped by now.
Sounds all good, thanks a lot !
--
To unsubscribe from this list: send
On Tue, Jun 7, 2011 at 10:52 AM, Roedel, Joerg joerg.roe...@amd.com wrote:
Yup. Btw, is there any IOMMU hardware which supports non-natural
alignment? In this case we need to expose these requirements somehow.
Not sure there are. Let's start with natural alignment, and extend it
only if someone
Hi Laurent,
On Tue, Jun 7, 2011 at 12:05 PM, Laurent Pinchart
laurent.pinch...@ideasonboard.com wrote:
pgsz isn't used anymore, you can remove it.
Ok.
+ order = get_order(bytes);
Does iommu_map() handle offsets correctly, or does it expect pa to be aligned
to an order (or
On Tue, Jun 7, 2011 at 12:58 PM, Roedel, Joerg joerg.roe...@amd.com wrote:
Btw, mind to split out your changes which move the iommu-api into
drivers/iommu? I can merge them meanwhile into my iommu tree and start
working on a proposal for the generic large page-size support.
Sure, that will be
Hi Laurent,
On Tue, Jun 7, 2011 at 12:22 PM, Laurent Pinchart
laurent.pinch...@ideasonboard.com wrote:
+ BUG_ON(!IS_ALIGNED((long)omap_domain-pgtable, IOPGD_TABLE_SIZE));
Either __get_free_pages() guarantees that the allocated memory will be aligned
on an IOPGD_TABLE_SIZE boundary, in
On Tue, Jun 7, 2011 at 2:40 PM, Laurent Pinchart
laurent.pinch...@ideasonboard.com wrote:
My point is that if the allocator guarantees the alignment (not as a side
effect of the implementation, but per its API) there's no need to check it
again. As the alignement is required, we need an
Hi Laurent,
On Tue, Jun 7, 2011 at 2:26 PM, Laurent Pinchart
laurent.pinch...@ideasonboard.com wrote:
Right now we have a BUG_ON if pa is unaligned, but that can be changed
if needed (do we want it to handle offsets ?).
At least for the OMAP3 ISP we need to, as video buffers don't necessarily
Hi Joerg,
On Mon, Jun 6, 2011 at 1:09 PM, Roedel, Joerg joerg.roe...@amd.com wrote:
The IOMMU-API already supports multiple page-sizes. See the
'order'-parameter of the map/unmap functions.
This is insufficient; users need somehow to tell what page sizes are
supported by the underlying
On Mon, Jun 6, 2011 at 12:10 PM, Arnd Bergmann a...@arndb.de wrote:
I'd still prefer us to take small steps here, and not gate the omap
iommu cleanups with Marek's generic dma_map_ops work though. Let's go
forward and migrate omap's iommu to the generic iommu API, so new code
will be able to
On Mon, Jun 6, 2011 at 6:35 PM, Roedel, Joerg joerg.roe...@amd.com wrote:
On Mon, Jun 06, 2011 at 11:15:30AM -0400, Ohad Ben-Cohen wrote:
This is insufficient; users need somehow to tell what page sizes are
supported by the underlying hardware (we can't assume host page-sizes,
and we want
On Mon, Jun 6, 2011 at 10:20 PM, Roedel, Joerg joerg.roe...@amd.com wrote:
Well, it certainly makes sense to have a single implementation for this.
But I want to hide this complexity to the user of the IOMMU-API. The
best choice is to put this into the layer between the IOMMU-API and the
Hi Arnd,
On Fri, Jun 3, 2011 at 6:53 PM, Arnd Bergmann a...@arndb.de wrote:
I think the future of iovmm is looking not so good. Marek Szyprowski
is working on a generic version of the dma-mapping API (dma_map_ops)
based on the iommu API.
Nice! I missed Marek's work somehow.
As far as I can
Hi Kyungmin,
On Fri, Jun 3, 2011 at 2:57 AM, Kyungmin Park kmp...@infradead.org wrote:
Please see the RFC patch, ARM: DMA-mapping IOMMU integration
http://www.spinics.net/lists/linux-mm/msg19856.html
Marek's work somehow escaped me, thanks for the pointers !
Ohad.
--
To unsubscribe from this
- OMAP's iommu code was tested on both OMAP3 and OMAP4
- omap3isp code was tested with a sensor-less OMAP3 (memory-to-memory only)
(thanks Laurent Pinchart for showing me the magic needed to test omap3isp :)
- MSM code was only compile tested
Ohad Ben-Cohen (6):
omap: iommu: generic iommu api
Migrate OMAP's iommu to the generic iommu api, so users can stay
generic, and non-omap-specific code can be removed and eventually
consolidated into a generic framework.
Tested on both OMAP3 and OMAP4.
Signed-off-by: Ohad Ben-Cohen o...@wizery.com
---
arch/arm/plat-omap/Kconfig
differently (or duplicated) in each driver.
Signed-off-by: Ohad Ben-Cohen o...@wizery.com
---
arch/arm/mach-msm/Kconfig |3 ---
arch/arm/plat-omap/Kconfig |3 ---
arch/x86/Kconfig|5 ++---
drivers/Kconfig |2 ++
drivers/Makefile
This should ease finding similarities with other platforms,
with the intention of solving problems once in a generic framework
which everyone can use.
Signed-off-by: Ohad Ben-Cohen o...@wizery.com
---
arch/arm/mach-msm/Kconfig | 12
arch/arm/mach-msm
), and exposing it will ease its generalization,
consolidation, or removal (once a generic virtual memory manager and allocator
would materialize).
Move omap's iommu debug driver to the generic folder as well, for the
same reasons.
Signed-off-by: Ohad Ben-Cohen o...@wizery.com
---
arch/arm/plat
manager framework).
Signed-off-by: Ohad Ben-Cohen o...@wizery.com
---
drivers/media/video/omap3isp/isp.c | 41 +-
drivers/media/video/omap3isp/isp.h |3 ++
drivers/media/video/omap3isp/ispccdc.c | 16 ++--
drivers/media/video/omap3isp
iommu map/unmap api).
Further generalizing of iovmm (or complete removal) should take place
together with broader plans of providing a generic virtual memory manager
and allocation framework (de-coupled from specific mappers).
Signed-off-by: Ohad Ben-Cohen o...@wizery.com
---
arch/arm/plat-omap
Fix a potential NULL pointer dereference by skipping registration of
external entities in case none are provided.
This is useful at least when testing mere memory-to-memory scenarios.
Signed-off-by: Ohad Ben-Cohen o...@wizery.com
---
drivers/media/video/omap3isp/isp.c |2 +-
1 files changed
On Mon, May 30, 2011 at 5:57 PM, Laurent Pinchart
laurent.pinch...@ideasonboard.com wrote:
Thanks for the patch, but I've already applied something similar to my tree.
Sorry :-)
np, thanks. I'm just playing with omap3isp a bit and wanted to get rid
of that hey what did I do wrong this time
Trivially fix this:
drivers/media/video/omap3isp/isp.c: In function 'isp_isr_dbg':
drivers/media/video/omap3isp/isp.c:394: warning: zero-length gnu_printf format
string
Signed-off-by: Ohad Ben-Cohen o...@wizery.com
---
drivers/media/video/omap3isp/isp.c |2 +-
1 files changed, 1 insertions
IT!
No problem, let's make it depends on OMAP4.
(patch also attached in case gmail eats my whitespace)
From d086e8f994b9272f8c999af0a4d32d870749c77a Mon Sep 17 00:00:00 2001
From: Ohad Ben-Cohen o...@wizery.com
Date: Fri, 18 Mar 2011 10:01:11 +0200
Subject: [PATCH] hwspinlock: depend on OMAP4
The wl1271's irq line is completely controlled by the 1271 device, and
the host does not not need to pull it up.
While there's no functional effect, letting the host pull this line up is
just redundant, and wastes power.
Signed-off-by: Ohad Ben-Cohen o...@wizery.com
---
arch/arm/mach-omap2
On Mon, Mar 7, 2011 at 8:02 PM, Felipe Contreras
felipe.contre...@gmail.com wrote:
On Mon, Dec 20, 2010 at 7:12 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
Hi Eyal,
On Thu, Feb 24, 2011 at 1:47 PM, Tony Lindgren t...@atomide.com wrote:
Sorry still can't get this one to apply. Can you please rebase
this on top of the current omap-for-linus branch?
...
+#include linux/wl12xx.h
...
+struct wl12xx_platform_data omap3evm_wlan_data __initdata = {
+
Hi Pandu,
On Mon, Feb 14, 2011 at 9:19 AM, panduranga_mallire...@ti.com wrote:
+ /* WLAN IRQ - GPIO 53 */
+ OMAP4_MUX(GPMC_NCS3, OMAP_MUX_MODE3 | OMAP_PIN_INPUT_PULLUP),
Actually we don't need to pull up the IRQ line - it is always held by
the 1271 device, and there's no need for
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
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
/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,
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
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
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
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
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
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
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 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
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.
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 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 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
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 :)
+/**
+ *
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
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
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
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
401 - 500 of 776 matches
Mail list logo
