prefetch_iotlb_entry
to better reflect the purpose of that function.
Signed-off-by: Ohad Ben-Cohen
---
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..
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
---
arch/arm/plat-omap/include/plat/iommu.h |8
drivers/iommu/omap-io
th OMAP's iommu).
Eventually, iovmm will be completely replaced with the generic,
iommu-based, dma-mapping API.
Signed-off-by: Ohad Ben-Cohen
---
arch/arm/plat-omap/Kconfig | 14 --
arch/arm/plat-omap/Makefile|2 --
arch/arm/pl
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
---
arch/arm/plat-omap/Kconfig |4 +-
arch/arm/plat-omap/inclu
es its
entire functionality via the generic IOMMU API).
2) omap-iovmm is removed.
Changes:
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
+ Paul, Benoit, Rajendra
On Tue, Aug 9, 2011 at 2:26 PM, Luciano Coelho 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) Driver
> [
Hi Pavel,
On Thu, Jun 9, 2011 at 8:12 PM, Pavel Machek 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 in, would b
On Wed, Jun 29, 2011 at 6:43 PM, Grant Likely 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 fixed to remove
> the kfre
On Fri, Jul 1, 2011 at 10:00 AM, Tony Lindgren 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 features th
tory at:
git://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-
On Fri, Jul 1, 2011 at 3:33 AM, Rafael J. Wysocki 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 core to pr
On Tue, Jun 28, 2011 at 12:00 AM, Grant Likely
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 driver, which has the TH
On Wed, Jun 29, 2011 at 2:59 PM, Arnd Bergmann wrote:
> On Wednesday 29 June 2011, Ohad Ben-Cohen wrote:
>> On Wed, Jun 29, 2011 at 2:44 AM, Randy Dunlap wrote:
>> >> +hardware accelerators, and therefore are often used to offload
>> >&g
Hi Randy,
Thanks for your comments !
On Wed, Jun 29, 2011 at 2:44 AM, Randy Dunlap wrote:
>> +hardware accelerators, and therefore are often used to offload cpu-intensive
>
> prefer: CPU-
> throughout.
Isn't that changing the meaning a b
On Wed, Jun 29, 2011 at 1:51 AM, Grant Likely 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
with the original kref in
Hi Grant,
On Tue, Jun 28, 2011 at 1:21 AM, Grant Likely 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 get enabled on the
On Tue, Jun 28, 2011 at 2:29 AM, Russell King - ARM Linux
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 really want to end up
Hi Grant,
Thanks a lot for the exhaustive review and comments !
On Mon, Jun 27, 2011 at 11:49 PM, Grant Likely
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, but it can get
> u
On Tue, Jun 28, 2011 at 12:22 AM, Grosen, Mark 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 with the PIL
Hi Stephen,
On Fri, Jun 24, 2011 at 11:16 PM, Stephen Boyd 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, virtio is a key factor
Hi Randy,
On Wed, Jun 22, 2011 at 8:55 PM, Randy Dunlap 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
On Wed, Jun 22, 2011 at 4:05 PM, Arnd Bergmann 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 eventually, too,
Hi Arnd,
On Tue, Jun 21, 2011 at 5:20 PM, Arnd Bergmann 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.
Thanks !
> One
On Wed, Jun 22, 2011 at 1:05 PM, Will Newton wrote:
> On Tue, Jun 21, 2011 at 8:18 AM, Ohad Ben-Cohen wrote:
>
>> +/* bootaddr isn't needed for the dual M3's */
>> +static inline int omap_rproc_start(struct rproc *rproc, u64 bootaddr)
>
>> +static inline in
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:
>> Add a virtio-based IPC bus, which enables kernel users to communicate
>> with remote processors over shared memory using a simple messaging
>> protocol.
&
On Tue, Jun 21, 2011 at 10:50 AM, Ohad Ben-Cohen 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-panda:
erved memory and handling IOMMUs, consider
moving to the generic DMA mapping API (with a CMA backend)
Signed-off-by: Ohad Ben-Cohen
---
Documentation/remoteproc.txt| 170 +
drivers/Kconfig |2 +
drivers/Makefile|1 +
drivers/remoteproc/Kconf
specific component.
This patch depends on OMAP's IOMMU API migration, as posted here:
https://lkml.org/lkml/2011/6/2/369
[o...@wizery.com: commit log, generic iommu api migration, refactoring,
cleanups]
Signed-off-by: Guzman Lugo, Fernando
Signed-off-by: Ohad Ben-Cohen
---
arch/arm/pla
From: Guzman Lugo, Fernando
Add omap remoteproc devices for the ipu and dsp remote processors.
TODO:
- rework to use CMA instead of reserving memory at boot
[o...@wizery.com: commit log, refactored and simplified, still wip]
Signed-off-by: Guzman Lugo, Fernando
Signed-off-by: Ohad Ben-Cohen
From: Mark Grosen
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
Signed-off-by: Ohad Ben-Cohen
---
It'd be nice to split this patch to the different components it changes
s omap 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
---
drivers/rpmsg/Kconfig |2 +
drivers/rpmsg/Makefile |2 +
drivers/rpmsg/host/Kconfig
From: Mark Grosen
Add remoteproc implementation for da850, so we can boot its DSP.
Signed-off-by: Mark Grosen
Signed-off-by: Ohad Ben-Cohen
---
arch/arm/mach-davinci/include/mach/remoteproc.h | 28 +
drivers/remoteproc/Kconfig | 16 +++
drivers/remoteproc
;).
This patch 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
---
arch/arm/plat-omap/Kconfig|8
arch/arm/plat-omap/devices.c | 14
d not
wait until everything is finished.
Guzman Lugo, Fernando (2):
remoteproc: add omap implementation
omap: add remoteproc devices
Mark Grosen (2):
remoteproc: add davinci implementation
davinci: da850: add remoteproc dsp device
Ohad Ben-Cohen (4):
drivers: add generic remoteproc frame
0e43327 "OMAP4: clock: Fix clock names and align with hwmod names"
renamed ducati_ick to ipu_fck.
Update OMAP4's iommu_device accordingly, so that omap_iommu_probe
doesn't break when calling clk_get.
Signed-off-by: Ohad Ben-Cohen
---
arch/arm/mach-omap2/omap-iommu.c |2
On Tue, Jun 14, 2011 at 1:29 PM, Roedel, Joerg 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 too.
Tell me if you
On Mon, Jun 13, 2011 at 7:41 PM, Laurent Pinchart
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 ?
Sure I can. I'll make sure
. 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
---
sorry, not tested on ia64 (not even compiled)
arch/ia64/Kconfig | 21 -
arch/x
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
---
arch/x86/Kconfig | 28
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
---
arch/arm/mach-msm/Kconfig | 16
differently (or duplicated) in each driver.
Signed-off-by: Ohad Ben-Cohen
---
arch/arm/mach-msm/Kconfig |3 ---
arch/ia64/Kconfig |3 ---
arch/x86/Kconfig|5 ++---
drivers/Kconfig |2 ++
drivers/Makefile|1 +
drivers
x27;s iommu_dev as well (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/iom
On Thu, Jun 9, 2011 at 1:27 AM, David Brown 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 list: send the line
On Wed, Jun 8, 2011 at 1:46 PM, Laurent Pinchart
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=linux-o
On Wed, Jun 8, 2011 at 8:47 PM, Chris Wright 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 the line "unsubsc
On Wed, Jun 8, 2011 at 4:05 PM, Matthew Wilcox 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 drivers" is c
On Wed, Jun 8, 2011 at 12:17 PM, David Woodhouse 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 address space.
>
>
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
---
arch/arm/mach-msm/Kconfig | 12
arch
differently (or duplicated) in each driver.
Signed-off-by: Ohad Ben-Cohen
---
arch/arm/mach-msm/Kconfig |3 ---
arch/x86/Kconfig|5 ++---
drivers/Kconfig |2 ++
drivers/Makefile|1 +
drivers/base/Makefile |1 -
drivers
,
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/io
. This is handled
in this patch, too.
Compile-tested on x86_64.
Signed-off-by: Ohad Ben-Cohen
---
arch/x86/Kconfig | 11 ---
drivers/iommu/Kconfig| 11 +++
drivers/iommu/Makefile |1 +
drivers/{pci => iommu}/intel-iomm
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
---
arch/x86/Kconfig | 28
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
Signed-off-by: Ohad Ben-Cohen
---
arch/arm/plat-omap/iovmm.c |6 +++---
1 files changed
Hi Laurent,
On Tue, Jun 7, 2011 at 2:26 PM, Laurent Pinchart
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
> start on page boundaries.
On Tue, Jun 7, 2011 at 2:40 PM, Laurent Pinchart
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 allocator that guarantees it
> anyway.
Hi Laurent,
On Tue, Jun 7, 2011 at 12:22 PM, Laurent Pinchart
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 which case the BUG_ON() is unne
On Tue, Jun 7, 2011 at 12:58 PM, Roedel, Joerg 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 great. Thanks!
--
Hi Laurent,
On Tue, Jun 7, 2011 at 12:05 PM, Laurent Pinchart
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 other) boundary ?
Right now we h
On Tue, Jun 7, 2011 at 10:52 AM, Roedel, Joerg 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 with additional re
On Mon, Jun 6, 2011 at 10:20 PM, Roedel, Joerg 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
> backend implementation
On Mon, Jun 6, 2011 at 6:35 PM, Roedel, Joerg 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,
>&
On Mon, Jun 6, 2011 at 12:10 PM, Arnd Bergmann 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 use it
Hi Joerg,
On Mon, Jun 6, 2011 at 1:09 PM, Roedel, Joerg 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 hardware (we can't assume
Hi Kyungmin,
On Fri, Jun 3, 2011 at 2:57 AM, Kyungmin Park 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 list: send the li
Hi Arnd,
On Fri, Jun 3, 2011 at 6:53 PM, Arnd Bergmann 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 tell, once
calls omap-specific 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
---
arch/arm/pl
ual memory manager framework).
Signed-off-by: Ohad Ben-Cohen
---
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/ispstat
the omap iommu), 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
---
arch/a
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
---
arch/arm/mach-msm/Kconfig | 12
arch/arm/mach-msm/Makefile
differently (or duplicated) in each driver.
Signed-off-by: Ohad Ben-Cohen
---
arch/arm/mach-msm/Kconfig |3 ---
arch/arm/plat-omap/Kconfig |3 ---
arch/x86/Kconfig|5 ++---
drivers/Kconfig |2 ++
drivers/Makefile|1 +
drivers
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
---
arch/arm/plat-omap/Kconfig |7 +-
squashing the first three patches)
- Based on and tested with 3.0-rc1
- 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 wa
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
---
drivers/media/video/omap3isp/isp.c |2 +-
1 files changed, 1 insertions
On Mon, May 30, 2011 at 5:57 PM, Laurent Pinchart
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" feeling every time I
recompiled it
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
---
drivers/media/video/omap3isp/isp.c |2 +-
1 files changed, 1 insert
N'T ASK 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
Date: Fri, 18 Mar 2011 10:01:11 +0200
Subject: [PATCH] hwspinlock: de
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
---
arch/arm/mach-omap2/board-zoo
On Mon, Mar 7, 2011 at 8:02 PM, Felipe Contreras
wrote:
> On Mon, Dec 20, 2010 at 7:12 PM, Felipe Contreras
> 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. So, use the existing proc
Hi Eyal,
On Thu, Feb 24, 2011 at 1:47 PM, Tony Lindgren 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
...
>> +struct wl12xx_platform_data omap3evm_wlan_data __initdata = {
>> + .irq = OMAP_GPIO_I
Hi Pandu,
On Mon, Feb 14, 2011 at 9:19 AM, 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 the host to pull it up
(wa
: Hari Kanigeri
Signed-off-by: Ohad Ben-Cohen
Cc: Benoit Cousson
Cc: Kevin Hilman
Cc: Paul Walmsley
Acked-by: Tony Lindgren
---
arch/arm/mach-omap2/Makefile |1 +
arch/arm/mach-omap2/hwspinlock.c | 63 ++
2 files changed, 64 insertions(+), 0
From: Benoit Cousson
Add hwspinlock hwmod data for OMAP4 chip
Signed-off-by: Cousson, Benoit
Signed-off-by: Hari Kanigeri
Signed-off-by: Ohad Ben-Cohen
Cc: Paul Walmsley
Acked-by: Tony Lindgren
---
arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 63
1 files
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
hwspinlock framework, tidy up]
Signed-off-by: Simon Que
Signed-off-by: Hari Kanigeri
Signed-off-by: Krishnamoorthy, Balaji T
Signed-off-by: Ohad Ben-Cohen
Cc: Benoit Cousson
Cc: Kevin Hilman
Cc: Grant Likely
Cc: Arnd Bergmann
Cc: Paul Walmsley
Cc: Russell King
Acked-by: Tony Lindgren
8917
[3] http://thread.gmane.org/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
O
On Wed, Feb 2, 2011 at 2:11 AM, Tony Lindgren wrote:
> * Ohad Ben-Cohen [110122 07:47]:
>> On Sat, Jan 22, 2011 at 5:30 PM, Koen Kooi
>> wrote:
>> > That was indeed the problem, not I get:
>> >
>> > [ 35.417053] wl1271: firmware booted (Rev
On Tue, Feb 1, 2011 at 9:40 AM, Andrew Morton wrote:
> On Tue, 1 Feb 2011 09:36:22 +0200 Ohad Ben-Cohen wrote:
>
>> On Tue, Feb 1, 2011 at 8:38 AM, Andrew Morton
>> wrote:
>> >> I'll do a quick respin of the patches with that and the
>> >> hw
On Tue, Feb 1, 2011 at 8:38 AM, Andrew Morton 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,
Ohad.
--
To unsub
On Tue, Feb 1, 2011 at 1:38 AM, Andrew Morton 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
>> + * @hwlock: the hw
: Hari Kanigeri
Signed-off-by: Ohad Ben-Cohen
Cc: Benoit Cousson
Cc: Kevin Hilman
Cc: Paul Walmsley
Acked-by: Tony Lindgren
---
arch/arm/mach-omap2/Makefile |1 +
arch/arm/mach-omap2/hwspinlock.c | 63 ++
2 files changed, 64 insertions(+), 0
From: Benoit Cousson
Add hwspinlock hwmod data for OMAP4 chip
Signed-off-by: Cousson, Benoit
Signed-off-by: Hari Kanigeri
Signed-off-by: Ohad Ben-Cohen
Cc: Paul Walmsley
Acked-by: Tony Lindgren
---
arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 63
1 files
hwspinlock framework, tidy up]
Signed-off-by: Simon Que
Signed-off-by: Hari Kanigeri
Signed-off-by: Krishnamoorthy, Balaji T
Signed-off-by: Ohad Ben-Cohen
Cc: Benoit Cousson
Cc: Kevin Hilman
Cc: Grant Likely
Cc: Arnd Bergmann
Cc: Paul Walmsley
Acked-by: Tony Lindgren
---
drivers/hwspinlock
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
tp://thread.gmane.org/gmane.linux.ports.arm.omap/38917
[3] http://thread.gmane.org/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 (
On Sat, Jan 22, 2011 at 5:30 PM, Koen Kooi 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 scanning | grep ESSID
Hi Koen,
On Fri, Jan 21, 2011 at 4:49 PM, Luciano Coelho 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 Tue, Jan 4, 2011 at 10:19 PM, Andrew Morton
wrote:
>> > Acked-by: Tony Lindgren
>>
>> 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 patchsets - please refresh, retest and
On Tue, Jan 4, 2011 at 9:17 PM, Tony Lindgren wrote:
> * Ohad Ben-Cohen [110104 10:04]:
>> On Wed, Nov 24, 2010 at 12:04 PM, Ohad Ben-Cohen wrote:
>> > Power to the wl12xx wlan device is controlled by a fixed regulator.
>> >
>> > Boards that have the wl12xx s
On Wed, Nov 24, 2010 at 12:04 PM, Ohad Ben-Cohen 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
> ---
Hi T
Hi Andrew,
On Sat, Dec 18, 2010 at 2:53 AM, Tony Lindgren wrote:
> * Ohad Ben-Cohen [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
401 - 500 of 824 matches
Mail list logo
