[resubmitting due to l-o being dropped from this discussion fork.
Thanks Russell for catching this]
On Wed, Oct 20, 2010 at 1:31 AM, Daniel Walker wrote:
> On Mon, 2010-10-18 at 09:44 +0200, Ohad Ben-Cohen wrote:
>> OMAP4 introduces a Spinlock hardware module, which provides
On Tue, Oct 19, 2010 at 7:16 PM, Kevin Hilman
wrote:
> Ohad Ben-Cohen writes:
>
>> From: Simon Que
>>
>> Add driver for OMAP's Hardware Spinlock module.
>>
>> The OMAP Hardware Spinlock module, initially introduced in OMAP4,
>> provides hard
On Wed, Oct 20, 2010 at 1:12 AM, Grant Likely wrote:
> On Tue, Oct 19, 2010 at 3:02 PM, Ohad Ben-Cohen wrote:
...
>> i2c-omap, which is subsys_initcall (the I2C bus is shared between the
>> A9 and the M3 on some OMAP4 boards).
...
> Man. this is getting ugly. I think we need
On Wed, Oct 20, 2010 at 1:53 AM, Kevin Hilman
wrote:
>> And to allow early board code to reserve specific hwspinlock numbers
>> for predefined use-cases, we probably want to be before arch_initcall.
>
> There's no reason for board code to have to do this at initcall time.
If we want to have allow
On Wed, Oct 20, 2010 at 8:37 PM, Kevin Hilman
wrote:
>> Let's take the i2c-omap for example.
>>
>> It sounds like it must have a predefined hwspinlock, but what if:
>>
>> 1. It will use omap_hwspinlock_request() to dynamically allocate a hwspinlock
>> 2. Obviously, the hwspinlock id number must be
On Tue, Oct 19, 2010 at 11:08 PM, Arnd Bergmann wrote:
> Right. There are two more things to consider though:
>
> If you know that interrupts are disabled, you may still want to avoid
> having to save the interrupt flag to the stack, to save some cycles
> saving and restoring it. I don't know how
[removed that bouncing email address we had all along :]
On Thu, Oct 21, 2010 at 1:58 AM, Kevin Hilman
wrote:
Why would we need platform-specific function pointers here ? I'm not
sure I'm following this one.
>>>
>>> So that board code (built-in) does not call the hwspinlock driver
>>> (
On Thu, Oct 21, 2010 at 10:36 AM, Kamoolkar, Mugdha wrote:
>> wrote:
>> > Yes, that would indeed simplify things.
>>
>> Balaji, Nishant, are you OK with this ?
>>
> The problem with this approach is that the i2c driver would have to
> sync up on the shared memory location that it uses to share th
On Thu, Oct 21, 2010 at 11:04 AM, Arnd Bergmann wrote:
> On Thursday 21 October 2010, Ohad Ben-Cohen wrote:
>> This sounds like adding a set of API that resembles spin_{unlock,lock}_irq.
>>
>> My gut feeling here is that while this may be useful and simple at
>> cer
On Fri, Oct 22, 2010 at 11:59 AM, Kamoolkar, Mugdha wrote:
>> From: Ohad Ben-Cohen [mailto:o...@wizery.com]
>> I agree.
>>
>> But we seem to have this sort of problem anyway:
>>
...
> That is true. Perhaps we should consider adding a software
> implementat
Hi Tony,
On Fri, Oct 22, 2010 at 6:56 PM, Tony Lindgren wrote:
> Guys, let's try to come up with a generic interface for this instead of
> polluting the device drivers with more omap specific interfaces.
>
> We really want to keep the drivers generic and platform independent.
I share this concer
On Mon, Oct 25, 2010 at 9:02 PM, Tony Lindgren wrote:
>> if you feel that (2) is justifiable/desirable, I would be more
>> than happy to submit that version.
>
> Yes (2) please. I would assume there will be more use of this. And then
> we (or probably me again!) don't have to deal with cleaning up
15
[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 generic framework
Simon Que (2):
drivers: hwspinlock: add OMAP implementation
omap: add hwspinlock device
Documentation/hwspi
ck/hwspinlock.h
@@ -0,0 +1,61 @@
+/*
+ * Hardware spinlocks internal header
+ *
+ * Copyright (C) 2010 Texas Instruments Incorporated - http://www.ti.com
+ *
+ * Contact: Ohad Ben-Cohen
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU Gene
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
---
arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 63
1 files changed, 63 insertions(+), 0
generic hwspinlock api, 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: Tony Lindgren
---
drivers/hwspinlock/Kconfig |9 ++
drivers
: Hari Kanigeri
Signed-off-by: Ohad Ben-Cohen
Cc: Benoit Cousson
Cc: Kevin Hilman
Cc: Paul Walmsley
---
arch/arm/mach-omap2/Makefile |1 +
arch/arm/mach-omap2/hwspinlock.c | 63 ++
2 files changed, 64 insertions(+), 0 deletions(-)
create mode
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
---
arch/arm/mach-omap2/Kconfig |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff
On Wed, Nov 24, 2010 at 1:23 AM, Ionut Nicu wrote:
> At iounmap_base you unmap state->io_base, but that's set only after this
> check. You should probably iounmap(io_base).
Of course. Thanks.
>
> Regards,
> Ionut.
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap"
Hi Mugdha,
On Wed, Nov 24, 2010 at 9:44 AM, Kamoolkar, Mugdha wrote:
> How do multiple clients get a handle that they can use? Are they expected to
> share the handle they get from the call above?
Currently, yes.
> What if they are independent
> clients with no means of communication between th
On Thu, Nov 25, 2010 at 5:59 AM, David Brownell wrote:
> My rule of thumb is that nothing is "generic"
> until at least three whatever-it-is instances
> plug in to it. Sometimes this is called
> the "Rule of Three".
>
> Other than OMAP, what's providing hardware
> spinlocks that plug into this fr
On Thu, Nov 25, 2010 at 8:05 AM, Kamoolkar, Mugdha 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
> the criti
On Thu, Nov 25, 2010 at 10:22 PM, David Brownell 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 was the
> imp
mp;hwspinlock_tree_lock);
>> +
>> + /* make sure the hwspinlock is used */
>> + ret = radix_tree_tag_get(&hwspinlock_tree, hwlock->id,
>> + HWSPINLOCK_UNUSED);
>> + if (ret == 1) {
>> + dev_err(hwlock->dev, "%s: hwlock is already free\n", __func__);
>
> Double free. WARN_ON() seems appropriate?
I don't want that this message will ever get compiled out.
>
>> + ret = -EINVAL;
>> + goto out;
>> + }
>> +
>> + /* notify the underlying device that power is not needed */
>> + ret = pm_runtime_put(hwlock->dev);
>> + if (ret < 0)
>> + goto out;
>> +
>> + /* mark this hwspinlock as available */
>> + tmp = radix_tree_tag_set(&hwspinlock_tree, hwlock->id,
>> + HWSPINLOCK_UNUSED);
>> +
>> + /* sanity check (this shouldn't happen) */
>> + WARN_ON(tmp != hwlock);
>
> No need for this.
Please see explanations above why I added those sanity checks (despite
my explicit comment saying this shouldn't happen).
Thanks!
Ohad.
>
>> +
>> + module_put(hwlock->owner);
>> +
>> +out:
>> + spin_unlock(&hwspinlock_tree_lock);
>> + return ret;
>> +}
>> +EXPORT_SYMBOL_GPL(hwspinlock_free);
>> +
>> +MODULE_LICENSE("GPL v2");
>> +MODULE_DESCRIPTION("Generic hardware spinlock interface");
>> +MODULE_AUTHOR("Ohad Ben-Cohen ");
>
>
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Fri, Nov 26, 2010 at 11:18 AM, Russell King - ARM Linux
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)
>> >> +{
>> >> +
On Fri, Nov 26, 2010 at 12:45 PM, Russell King - ARM Linux
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
>> wrote:
>> > On Fri, Nov 26, 2010 at 10:53:10AM +0200, Ohad Ben-Co
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:
On Sat, Nov 27, 2010 at 12:53 AM, Russell King - ARM Linux
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
On Sat, Nov 27, 2010 at 3:24 AM, David Brownell 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 hardware spinlocks
Hi Olof,
On Sat, Nov 27, 2010 at 12:51 AM, Olof Johansson wrote:
>> >> +int __hwspin_trylock(struct hwspinlock *hwlock, int mode, unsigned long
>> >> *flags)
>> >> +{
>> >> + int ret;
>> >> +
>> >> + if (unlikely(!hwlock)) {
>> >> + pr_err("invalid hwlock\n");
>> >
>> > These
On Tue, Nov 30, 2010 at 11:00 AM, Tony Lindgren 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 hwspin_lock_timeout
815
[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 implementation
omap: add hwspinlock device
Documentation/hwspinlo
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
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
---
arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 64
1 files changed, 64 insertions(+), 0
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: Tony Lindgren
---
drivers/hwspinlock/Kconfig |9 ++
drivers/hwspinlock
: Hari Kanigeri
Signed-off-by: Ohad Ben-Cohen
Cc: Benoit Cousson
Cc: Kevin Hilman
Cc: Paul Walmsley
---
arch/arm/mach-omap2/Makefile |1 +
arch/arm/mach-omap2/hwspinlock.c | 63 ++
2 files changed, 64 insertions(+), 0 deletions(-)
create mode
On Sat, Dec 4, 2010 at 2:29 AM, David Daney 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
http://www.mail-archive.com/linux-omap@vger.kernel.org/msg39413.html).
Btw, you might
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
Signed-off-by: Ohad Ben-Cohen
---
Compile tested on ARM and x86-64.
Relevant threads:
1
On Wed, Dec 8, 2010 at 2:10 AM, Andrew Morton 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 :)
>> +/**
>> + * BUG_ON_MAPPABLE_NULL() - BUG_ON(cond
On Sat, Dec 11, 2010 at 9:59 PM, Elvis Dowson 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 community can help
Hi Laurent,
On Sun, Dec 12, 2010 at 2:44 PM, Laurent Pinchart
> > [ 191.085479] {IN-SOFTIRQ-W}
state was registered at:
> [ 191.090576] [] __lock_acquire+0x5f0/0x17c4
> [ 191.095947] [] lock_acquire+0xd8/0xfc
> [ 191.100860] [] _raw_spin_lock+0x30/0x40
> [ 191.105957] [] omap_mbox_ms
On Sun, Dec 12, 2010 at 4:15 PM, Ionut Nicu 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 mailbox
tasklet.
>
>
On Mon, Dec 13, 2010 at 6:45 PM, Laurent Pinchart
>> On Sun, Dec 12, 2010 at 4:15
PM, Ionut Nicu 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, sinc
Hi Greg, Tony,
On Sat, Dec 4, 2010 at 1:50 AM, Ohad Ben-Cohen 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 operati
On Tue, Dec 14, 2010 at 7:06 PM, Greg KH 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.
>
> I've seen a
Hi Tony,
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.
Not sure if you picked this up ?
We nee
On Tue, Dec 14, 2010 at 8:40 PM, Ohad Ben-Cohen wrote:
> On Tue, Dec 14, 2010 at 7:06 PM, Greg KH 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 prefe
On Thu, Dec 16, 2010 at 11:08 PM, Greg KH 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 wit
King. Currently only a single device is
supported; multi-device support will be introduced only when/if required
Patches are based on 2.6.36-rc3 and tested on ZOOM3.
Thanks,
Ohad Ben-Cohen (7):
wireless: wl1271: make wl12xx.h common to both spi and sdio
wireless: wl1271: support return value
Move wl12xx.h outside of the spi-specific location,
so it can be shared with both spi and sdio solutions.
Signed-off-by: Ohad Ben-Cohen
---
drivers/net/wireless/wl12xx/wl1251_sdio.c |2 +-
drivers/net/wireless/wl12xx/wl1251_spi.c |2 +-
drivers/net/wireless/wl12xx/wl1271_spi.c |2
Make it possible for the set power method to indicate a
success/failure return value. This is needed to support
more complex power on/off operations such as bringing up
(and down) sdio functions.
Signed-off-by: Ohad Ben-Cohen
---
drivers/net/wireless/wl12xx/wl1271.h |2 +-
drivers/net
Add a simple mechanism to pass platform data to the
SDIO instances of wl12xx.
This way there is no confusion over who owns the 'embedded data',
typechecking is preserved, and no possibility for the wrong driver to
pick up the data.
Originally proposed by Russell King.
Signed-off-by
Remove the hard coded irq information, and instead take
the irq information from the board's platform data.
Signed-off-by: Ohad Ben-Cohen
---
drivers/net/wireless/wl12xx/wl1271_sdio.c | 14 +++---
1 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/net/wir
The wl1271 device is using a reference clock that may change
between board to board.
Make the ref_clock parameter configurable by the board
files that set up the device, instead of having a hard coded
value in the driver source itself.
Signed-off-by: Ohad Ben-Cohen
---
drivers/net/wireless
Add MMC3 support on ZOOM, which is hardwired to the wl1271 device.
The wl1271 is a 4-wire, 1.8V, embedded SDIO WLAN device with an
external IRQ line, and power-controlled by a GPIO-based fixed regulator.
Signed-off-by: Ohad Ben-Cohen
---
arch/arm/mach-omap2/board-zoom-peripherals.c | 19
Add a fixed regulator vmmc device to enable power control
of the wl1271 wlan device.
Signed-off-by: Ohad Ben-Cohen
---
arch/arm/mach-omap2/board-zoom-peripherals.c | 35 ++
1 files changed, 35 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-zoom
2010/9/4 Michał Mirosław :
> 2010/9/1 Ohad Ben-Cohen :
>> Add a simple mechanism to pass platform data to the
>> SDIO instances of wl12xx.
>>
>> This way there is no confusion over who owns the 'embedded data',
>> typechecking is preserved, and no possibi
2010/9/6 Russell King - ARM Linux :
> We could instead make wl12xx_get_platform_data() return a const pointer
> to its own internal storage instead, or ERR pointers for the various
> failure cases.
Sounds good:
diff --git a/drivers/net/wireless/wl12xx/wl12xx_platform_data.c
b/drivers/net/wireless
2010/9/6 Michał Mirosław :
> W dniu 6 września 2010 14:07 użytkownik Russell King - ARM Linux
> napisał:
>> On Sat, Sep 04, 2010 at 02:23:19PM +0200, Michał Mirosław wrote:
>>> 2010/9/1 Ohad Ben-Cohen :
>>> > Add a simple mechanism to pass platform data to t
On Wed, Sep 1, 2010 at 11:26 PM, Ohad Ben-Cohen wrote:
> This patchset adds wl1271 support on ZOOM2/3 boards.
Tony, John, let me please suggest merging this through the wireless tree.
wl1271 is a moving target - it keeps changing in the wireless tree and
merging this patchset there will al
On Wed, Sep 15, 2010 at 6:34 PM, Tony Lindgren wrote:
> * John W. Linville [100915 06:21]:
>> On Wed, Sep 15, 2010 at 01:08:18PM +0200, Vitaly Wool wrote:
>> > On Wed, Sep 15, 2010 at 11:21 AM, Ohad Ben-Cohen wrote:
>> > > On Wed, Sep 1, 2010 at 11:26 PM, Ohad
This patchset adds wl1271 support on ZOOM2/3 boards.
Only basic support is included; power manipulation is submitted separately as
SDIO Runtime PM support.
Changes since v5:
- rebase to wireless-testing
- remove 2nd copy from wl12xx_platform_data (keep the 1st one though)
Thanks,
Ohad Ben
Move wl12xx.h outside of the spi-specific location,
so it can be shared with both spi and sdio solutions.
Signed-off-by: Ohad Ben-Cohen
---
drivers/net/wireless/wl12xx/wl1251_sdio.c |2 +-
drivers/net/wireless/wl12xx/wl1251_spi.c |2 +-
drivers/net/wireless/wl12xx/wl1271_spi.c |2
Make it possible for the set power method to indicate a
success/failure return value. This is needed to support
more complex power on/off operations such as SDIO
power manipulations.
Signed-off-by: Ohad Ben-Cohen
---
drivers/net/wireless/wl12xx/wl1271.h |2 +-
drivers/net/wireless
Add a simple mechanism to pass platform data to the
SDIO instances of wl12xx.
This way there is no confusion over who owns the 'embedded data',
typechecking is preserved, and no possibility for the wrong driver to
pick up the data.
Originally proposed by Russell King.
Signed-off-by
Remove the hard coded irq information, and instead take
the irq information from the board's platform data.
Signed-off-by: Ohad Ben-Cohen
---
drivers/net/wireless/wl12xx/wl1271_sdio.c | 15 ---
1 files changed, 8 insertions(+), 7 deletions(-)
diff --git a/drivers/net/wir
The wl1271 device is using a reference clock that may change
between board to board.
Make the ref_clock parameter configurable by board settings
instead of having a hard coded value in the sources.
Signed-off-by: Ohad Ben-Cohen
---
drivers/net/wireless/wl12xx/wl1271.h |1 +
drivers
Add a fixed regulator vmmc device to enable power control
of the wl1271 wlan device.
Signed-off-by: Ohad Ben-Cohen
---
arch/arm/mach-omap2/board-zoom-peripherals.c | 35 ++
1 files changed, 35 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-zoom
Add MMC3 support on ZOOM, which has the wl1271 device hardwired to.
The wl1271 is a 4-wire, 1.8V, embedded SDIO WLAN device with an
external IRQ line, and power-controlled by a GPIO-based fixed regulator.
Signed-off-by: Ohad Ben-Cohen
---
arch/arm/mach-omap2/board-zoom-peripherals.c | 19
On Thu, Sep 16, 2010 at 12:17 PM, Teemu Paasikivi
wrote:
> On Thu, 2010-09-16 at 01:22 +0200, ext Ohad Ben-Cohen wrote:
>> Move wl12xx.h outside of the spi-specific location,
>> so it can be shared with both spi and sdio solutions.
>>
>> Signed-off-by: Ohad Ben-Cohen
Move wl12xx.h outside of the spi-specific location,
so it can be shared with both spi and sdio solutions.
Update all users of spi/wl12xx.h accordingly
Signed-off-by: Ohad Ben-Cohen
---
MAINTAINERS |2 +-
arch/arm/mach-omap2/board-omap3pandora.c |2
Hi John,
On Thu, Sep 16, 2010 at 1:16 PM, Ohad Ben-Cohen wrote:
> Move wl12xx.h outside of the spi-specific location,
> so it can be shared with both spi and sdio solutions.
>
> Update all users of spi/wl12xx.h accordingly
>
> Signed-off-by: Ohad Ben-Cohen
> ---
This updat
On Thu, Sep 16, 2010 at 7:44 PM, Tony Lindgren wrote:
> These are usually aligned with tabs before the = sign.
Fixed.
> Acked-by: Tony Lindgren
Thanks, Tony.
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majo
On Thu, Sep 16, 2010 at 9:40 PM, Luciano Coelho
wrote:
>> + int ret = wl->if_ops->power(wl, true);
>
> I think it look nicer if you keep the "int ret" in one line by itself
> and then do a ret = wl->if_ops... on another one.
Fixed.
>> +static int wl1271_sdio_power_on(struct wl1271 *wl)
>> {
On Thu, Sep 16, 2010 at 8:35 PM, Luciano Coelho
wrote:
> Acked-by: Luciano Coelho
>
> I just wonder why the wl12xx.h move wasn't detected as a rename. Did
> you forget to use the -M option in format-patch?
I thought it's because I stripped the SPI_ from the
#ifndef _LINUX_SPI_WL12XX_H, but it s
Hi Hari,
On Thu, Aug 12, 2010 at 12:44 AM, Kanigeri, Hari wrote:
>> > +/* Attempt to acquire a spinlock once */
>> > +int hwspinlock_trylock(struct hwspinlock *handle)
>> > +{
>> > + int retval = 0;
>> > +
>> > + if (WARN_ON(handle == NULL))
>> > + return -EINVAL;
>> > +
On Thu, Sep 23, 2010 at 2:20 PM, Felipe Balbi wrote:
> Hi Luca,
>
> On Thu, Sep 23, 2010 at 07:17:33AM -0500, Luciano Coelho wrote:
>>
>> On Thu, 2010-09-23 at 13:45 +0200, ext Felipe Balbi wrote:
>>>
>>> On Thu, Sep 23, 2010 at 03:20:03AM -0500, Luciano Coelho wrote:
>>> > static struct mtd_parti
On Fri, Oct 1, 2010 at 10:33 PM, Anand Gadiyar wrote:
> Fix this build break when CONFIG_WL12XX_PLATFORM_DATA is not set.
A similar fix was already submitted and is pending to be merged
(http://permalink.gmane.org/gmane.linux.kernel.wireless.general/56595)
> There are still many warnings about t
On Sat, Oct 2, 2010 at 1:02 AM, Anand Gadiyar wrote:
> I picked up your patch and the warnings are gone. The key difference
> was I missed marking the alternative function as an inline.
Ok, thanks for the update.
>
> Without that, I was seeing warnings like these:
> include/linux/wl12xx.h:42: w
On Mon, Oct 4, 2010 at 2:20 PM, G, Manjunath Kondaiah wrote:
> Can you post complete boot log? so far, it failed on one blaze and
> one 3430sdp both of them are having es2.0
Sure:
wizery.com/ohad/blaze-linux-omap.txt.gz
Summary of my setup:
- Blaze ES2.0
- linux-omap-2.6 master branch (commit
0
On Mon, Oct 4, 2010 at 9:49 AM, G, Manjunath Kondaiah wrote:
> Booting with zoom3 seems to be fine but observed issues with omap4 blaze
> board.
FWIW, for me it worked just fine with blaze
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord
On Mon, Oct 4, 2010 at 2:13 PM, G, Manjunath Kondaiah wrote:
> ES2.0 or ES1.0?
2.0
>
> -Manjunath
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Mon, Oct 4, 2010 at 2:52 PM, G, Manjunath Kondaiah wrote:
> Remove nosmp from your bootargs and try.
Indeed, it doesn't boot.
wizery.com/ohad/blaze-linux-omap-smp.txt.gz
>
> -Manjunath
>
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to
Hi Sanjay,
On Wed, Oct 13, 2010 at 12:57 PM, wrote:
> Sanjay Kumar Champati (5):
> ARM: Supported MMC 2 features for OMAP3EVM
> ARM: Supported for Standard SDIO driver on OMAP3EVM for WL1271 DC
> ARM: Supported for BT enable on OMAP3EVM for WL1271 DC
> ARM: Added ALSA audio support for WL127
OMAP4 introduces a Spinlock hardware module, which provides hardware
assistance for synchronization and mutual exclusion between heterogeneous
processors and those not operating under a single, shared operating system
(e.g. OMAP4 has dual Cortex-A9, dual Cortex-M3 and a C64x+ DSP).
The intention o
ff-by: Ohad Ben-Cohen
Cc: Benoit Cousson
Cc: Tony Lindgren
---
Documentation/misc-devices/omap_hwspinlock.txt | 199 +
drivers/misc/Kconfig | 10 +
drivers/misc/Makefile |1 +
drivers/misc/omap_hwspinlock.c |
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
---
arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 63
1 files changed, 63 insertions(+), 0
: Hari Kanigeri
Signed-off-by: Ohad Ben-Cohen
Cc: Benoit Cousson
---
arch/arm/mach-omap2/Makefile |1 +
arch/arm/mach-omap2/hwspinlock.c | 67 ++
2 files changed, 68 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/mach-omap2/hwspinlock.c
On Mon, Oct 18, 2010 at 3:43 PM, Peter Zijlstra wrote:
> Right, so the problem is that there simply is no way to do atomic memory
> access from these auxiliary processing units wrt the main CPU?
Yes. There are a few relevant system-wide limitations, one of them is
that simply the system interconn
On Mon, Oct 18, 2010 at 4:33 PM, Peter Zijlstra wrote:
> Without coherency everybody needs to be damn sure to flush the relevant
> bits before unlocking and such.
Yes, either that, or use non-cacheable memory.
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of
On Mon, Oct 18, 2010 at 5:32 PM, Peter Zijlstra wrote:
> Sure, but you can 'easily' extend your coherency protocols with support
In our case, there are no coherency protocols supported between the
A9, M3 and the DSP.
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the
On Tue, Oct 19, 2010 at 5:46 PM, Greg KH wrote:
> On Mon, Oct 18, 2010 at 09:44:33AM +0200, Ohad Ben-Cohen wrote:
>> +#else /* !CONFIG_OMAP_HWSPINLOCK */
>> +
>> +static inline struct omap_hwspinlock *omap_hwspinlock_request(void)
>> +{
>> + return ERR_PTR(-EN
On Tue, Oct 19, 2010 at 6:58 PM, Kevin Hilman
wrote:
>> + * This spin_trylock_irqsave serves two purposes:
>> +
>> + * 1. Disable local interrupts and preemption, in order to
>> + * minimize the period of time in which the hwspinlock
>> + * is taken (so caller will not pr
On Tue, Oct 19, 2010 at 7:01 PM, Grant Likely wrote:
>> + struct omap_hwspinlock *omap_hwspinlock_request(void);
...
> ERR_PTR() is only appropriate when the caller actually cares about the
> failure code and has different behaviour depending on the result.
Agree; the hwspinlock users can surely
On Tue, Oct 19, 2010 at 7:21 PM, Arnd Bergmann wrote:
> On Monday 18 October 2010 09:44:33 Ohad Ben-Cohen wrote:
>> + int omap_hwspin_lock(struct omap_hwspinlock *hwlock, unsigned long
>> *flags);
>> ...
>> + The flags parameter is a pointer to where
On Tue, Oct 19, 2010 at 7:03 PM, Kevin Hilman
wrote:
>> +postcore_initcall(hwspinlocks_init);
>
> Any reason this needs to be a postcore_initcall? Are there users of
> hwspinlocks this early in boot?
i2c-omap, which is subsys_initcall (the I2C bus is shared between the
A9 and the M3 on some OMAP
On Tue, Oct 19, 2010 at 10:58 PM, Arnd Bergmann wrote:
>> If a hwspinlock is taken over a long period of time, its other user
>> (with which we try to achieve synchronization) might be polling the
>> OMAP interconnect for too long (trying to take the hwspinlock) and
>> thus preventing it to be use
Hi Felipe,
On Mon, Dec 20, 2010 at 8:43 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.
Thanks for reporting this !
> So, use the existing proc_lock for that.
I d
Hi Felipe,
On Tue, Dec 21, 2010 at 6:44 PM, Felipe Contreras
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(), proc_end_dma(), proc_map() and
proc_un
On Mon, Dec 27, 2010 at 3:55 PM, Felipe Contreras
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 version), how and under which wo
1 - 100 of 824 matches
Mail list logo
