Re: [PATCH 1/1] PM: Thaws refrigerated and to be exited kernel threads
On Sun 2009-11-08 09:52:52, Dasgupta, Romit wrote:
Subject: Re: [PATCH 1/1] PM: Thaws refrigerated and to be exited kernel
threads
Hi!
Kicks out a frozen thread from the refrigerator when an active thread has
invoked kthread_stop on the frozen thread.
...
@@ -49,7 +50,7 @@ void refrigerator(void)
for (;;) {
set_current_state(TASK_UNINTERRUPTIBLE);
- if (!frozen(current))
+ if (!frozen(current) || (!current-mm kthread_should_stop()))
break;
schedule();
Well, what if the thread does some processing before stopping? That
would break refrigerator assumptions...
The suspend thread will block until the 'to be stopped' thread clears up.
That is what any call to kthread_stop would boil down to. The target thread
would anyway be out of the refrigerator so I am not sure what assumption you
mean here. Eventually, the target thread would clear up and wake up the
suspend thread and then things would go on as usual.
(Please format to 80 columns).
No, I do not get it.
Lets say we have
evil_data_writer thread that needs to be stopped becuase it writes to
filesystem
nofreeze random_stopper thread
now we create the suspend image, and start writing it out. But that's
okay, evil_data_writer is stopped so it can't do no harm. But now
random_stopper decides to thread_stop() the evil_data_writer, and this
new code allows it to exit the refrigerator, *do some writing*, and
then stop.
That's bad, right?
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures)
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
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
RE: [PATCH 1/1] PM: Thaws refrigerated and to be exited kernel threads
-Original Message-
From: Pavel Machek [mailto:pa...@ucw.cz]
Sent: Sunday, November 08, 2009 1:57 PM
To: Dasgupta, Romit
Cc: Rafael J. Wysocki; linux-omap@vger.kernel.org;
linux-ker...@vger.kernel.org;
linux...@lists.linux-foundation.org
Subject: Re: [PATCH 1/1] PM: Thaws refrigerated and to be exited kernel
threads
On Sun 2009-11-08 09:52:52, Dasgupta, Romit wrote:
Subject: Re: [PATCH 1/1] PM: Thaws refrigerated and to be exited kernel
threads
Hi!
Kicks out a frozen thread from the refrigerator when an active thread
has
invoked kthread_stop on the frozen thread.
...
@@ -49,7 +50,7 @@ void refrigerator(void)
for (;;) {
set_current_state(TASK_UNINTERRUPTIBLE);
- if (!frozen(current))
+ if (!frozen(current) || (!current-mm
kthread_should_stop()))
break;
schedule();
Well, what if the thread does some processing before stopping? That
would break refrigerator assumptions...
The suspend thread will block until the 'to be stopped' thread clears up.
That is
what any call to kthread_stop would boil down to. The target thread would
anyway be out of the refrigerator so I am not sure what assumption you mean
here. Eventually, the target thread would clear up and wake up the suspend
thread and then things would go on as usual.
(Please format to 80 columns).
No, I do not get it.
Lets say we have
evil_data_writer thread that needs to be stopped becuase it writes to
filesystem
nofreeze random_stopper thread
now we create the suspend image, and start writing it out. But that's
okay, evil_data_writer is stopped so it can't do no harm. But now
random_stopper decides to thread_stop() the evil_data_writer, and this
new code allows it to exit the refrigerator, *do some writing*, and
then stop.
That's bad, right?
evil_data_writer will enter refrigerator after invoking 'try_to_freeze'. This
should be followed by a call to kthread_should_stop. There it decides if it
needs to exit the thread (after cleanups if necessary) or not. I have seen that
the bdi_writeback_task function is like that. It does not care if there is
pending data to be written if it detects that someone have invoked a
'kthread_stop' on it. It simply exits. I have seen some other kernel threads
that do not follow this and I think that probably is not right.
--
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
RE: [PATCH 1/1] PM: Thaws refrigerated and to be exited kernel threads
(Resending with 80 column restriction)
-Original Message-
From: Pavel Machek [mailto:pa...@ucw.cz]
Sent: Sunday, November 08, 2009 1:57 PM
To: Dasgupta, Romit
Cc: Rafael J. Wysocki; linux-omap@vger.kernel.org;
linux-ker...@vger.kernel.org; linux...@lists.linux-foundation.org
Subject: Re: [PATCH 1/1] PM: Thaws refrigerated and to be
exited kernel threads
On Sun 2009-11-08 09:52:52, Dasgupta, Romit wrote:
Subject: Re: [PATCH 1/1] PM: Thaws refrigerated and to be
exited kernel
threads
Hi!
Kicks out a frozen thread from the refrigerator when an
active thread has
invoked kthread_stop on the frozen thread.
...
@@ -49,7 +50,7 @@ void refrigerator(void)
for (;;) {
set_current_state(TASK_UNINTERRUPTIBLE);
- if (!frozen(current))
+ if (!frozen(current) || (!current-mm
kthread_should_stop()))
break;
schedule();
Well, what if the thread does some processing before
stopping? That
would break refrigerator assumptions...
The suspend thread will block until the 'to be stopped'
thread clears up. That is what any call to kthread_stop would
boil down to. The target thread would anyway be out of the
refrigerator so I am not sure what assumption you mean here.
Eventually, the target thread would clear up and wake up the
suspend thread and then things would go on as usual.
(Please format to 80 columns).
No, I do not get it.
Lets say we have
evil_data_writer thread that needs to be stopped becuase it writes to
filesystem
nofreeze random_stopper thread
now we create the suspend image, and start writing it out. But that's
okay, evil_data_writer is stopped so it can't do no harm. But now
random_stopper decides to thread_stop() the evil_data_writer, and this
new code allows it to exit the refrigerator, *do some writing*, and
then stop.
That's bad, right?
evil_data_writer will enter refrigerator after invoking 'try_to_freeze'. This
should be followed by a call to kthread_should_stop. There it decides if it
needs to exit the thread (after cleanups if necessary) or not. I have seen that
the bdi_writeback_task function is like that. It does not care if there is
pending data to be written if it detects that someone have invoked a
'kthread_stop' on it. It simply exits. I have seen some other kernel threads
that do not follow this and I think that probably is not right.
--
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
omap3 otg host not working since 2.6.28?
I can't get OTG host mode to work with any recent kernels. I'm curious if anyone else has tried this. It may well be something most people don't do. I've tried this on our custom hardware (omap3530/tps65930) and on a beagleboard with the same results. Our OTG hardware is identical to the beagleboard. I am using a special mini-B cable which has the ID pin grounded. I know about forcing the mode with echo host /sys/devices/platform/musb_hdrc/mode. When I use a 2.6.28 kernel built using the same patches as are in OE, OTG host works fine. I can get the controller into host mode. When I use any kernels from the omap git tree past 2.6.28 it doesn't work. The controller stays in b-mode and won't switch. I can dig into it and figure out why, but I thought I'd ask in case anyone else has already solved it. I've written some diagnostics for the OTG controller and found it's finicky about getting into host mode, sometimes wanting the phy to be reset before it will switch. -brad --- Brad Parker Heeltoe Consulting http://www.heeltoe.com 781-483-3101 -- 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
Re: Newbie doubt
On Mon, Nov 9, 2009 at 6:59 AM, Niamathullah sharief omap...@gmail.com wrote: Hi, I want to know that what are all the OMAP based boards available other than beagle board?in that which one will be better for me as a newbie. As far as I knnow you can use beagle board or ready-to-use devices such as gumstix. -- With Best Regards, Andy Shevchenko -- 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
RE: Newbie doubt
-Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of Niamathullah sharief Sent: Monday, November 09, 2009 10:30 AM To: linux-omap@vger.kernel.org Subject: Newbie doubt Hi, I want to know that what are all the OMAP based boards available other than beagle board?in that which one will be better for me as a newbie. Slightly older list is here http://wiki.davincidsp.com/index.php/OMAP3_Boards It depends on the cost and support your might be interested in Regards, Khasim http://hawkboard.org http://hawkboard.wordpress.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 at http://vger.kernel.org/majordomo-info.html
RE: Newbie doubt
You may also want to consider EVM from Mistral. Please see the link below for more details. http://www.mistralsolutions.com/products/omap_3evm.php with regards, - Nagendra. -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Andy Shevchenko Sent: Monday, November 09, 2009 11:23 AM To: Niamathullah sharief Cc: linux-omap@vger.kernel.org Subject: Re: Newbie doubt On Mon, Nov 9, 2009 at 6:59 AM, Niamathullah sharief omap...@gmail.com wrote: Hi, I want to know that what are all the OMAP based boards available other than beagle board?in that which one will be better for me as a newbie. As far as I knnow you can use beagle board or ready-to-use devices such as gumstix. -- With Best Regards, Andy Shevchenko -- 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 Please do not print this email unless it is absolutely necessary. Spread environmental awareness. ---DISCLAIMER-- The information transmitted herewith is confidential and proprietary information intended only for use by the individual or entity to which it is addressed. If the reader of this message is not the intended recipient, you are hereby notified that any review, retransmission, dissemination, distribution, copying or other use of, or taking of any action in reliance upon this information is strictly prohibited. If you have received this communication in error, please contact the sender and delete the material from your computer. --- -- 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
RE: [PATCH 4/5] Regulator: Adding OMAP3EVM/TWL4030 specific code in board-omap35x-pmic.c
-Original Message-
From: Mike Rapoport [mailto:mike.rapop...@gmail.com]
Sent: Friday, November 06, 2009 8:06 PM
To: Aggarwal, Anuj
Cc: linux-omap@vger.kernel.org; broo...@opensource.wolfsonmicro.com;
l...@slimlogic.co.uk
Subject: Re: [PATCH 4/5] Regulator: Adding OMAP3EVM/TWL4030 specific code
in board-omap35x-pmic.c
On Fri, Nov 6, 2009 at 8:47 AM, Aggarwal, Anuj anuj.aggar...@ti.com
wrote:
-Original Message-
From: Mike Rapoport [mailto:mike.rapop...@gmail.com]
Sent: Friday, November 06, 2009 2:46 AM
To: Aggarwal, Anuj
Cc: linux-omap@vger.kernel.org; broo...@opensource.wolfsonmicro.com;
l...@slimlogic.co.uk
Subject: Re: [PATCH 4/5] Regulator: Adding OMAP3EVM/TWL4030 specific
code
in board-omap35x-pmic.c
On Thu, Nov 5, 2009 at 6:39 PM, Anuj Aggarwal anuj.aggar...@ti.com
wrote:
Adding various regulator-consumers for OMAP3EVM-TWL4030 combination
in board-omap35x-pmic.c. Also, populating the respective fields
for omap3evm_twldata structure.
Signed-off-by: Anuj Aggarwal anuj.aggar...@ti.com
---
arch/arm/mach-omap2/board-omap35x-pmic.c | 81
+-
arch/arm/mach-omap2/board-omap3evm.c | 2 +-
2 files changed, 80 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-omap2/board-omap35x-pmic.c
b/arch/arm/mach-
omap2/board-omap35x-pmic.c
index aae07ab..2ef4932 100644
--- a/arch/arm/mach-omap2/board-omap35x-pmic.c
+++ b/arch/arm/mach-omap2/board-omap35x-pmic.c
@@ -24,10 +24,87 @@
* Definitions specific to TWL4030/TPS65950
*/
#if defined(CONFIG_PMIC_TWL4030)
-static inline void pmic_twl4030_init(void)
+#if defined(CONFIG_MACH_OMAP3EVM)
What about beagle, overo and others that use the same regulator for
the same purposes?
[Aggarwal, Anuj] This file can be used to accommodate all the common
Regulator f/w related code for OMAP3 based platforms. Depending upon
the regulators' usage across EVMs, the code can be split in generic and
platform specific code.
I agree that common regulator functionality should reside in one place
rather than be copy-pasted between board files. But adding file with
#defined(CONFIG_MACH_OMAP3EVM) and #defined(CONFIG_MACH_OMAP3BEAGLE)
does not make it generic. Every single line of code that is inside
such #ifdef can be perfectly well placed in the appropriate board-X.c
As far as I can tell, all platforms use the very same definitions of
regulator and regulator supplies both for MMC and VDVI and VENC. So,
why not just create some macros wrapping these definitions and use
them every time 'struct regulator_consumer_supply' and 'struct
regulator_init_data' need to be instantiated?
Based on your suggestions, I tried creating macros specific to TWL
regulators in a common header file. This file then can be included by
the different board files and the structures can then be appropriately
created.
Here is the sample of what could be done on these lines:
#define TWL_VDAC_SUPPLY(device) { \
static struct regulator_consumer_supply vdac_supply[] = { \
{ \
.supply = vdac, \
.dev = device, \
}, \
}; \
}
#define TWL_VPLL2_SUPPLY(device){ \
static struct regulator_consumer_supply vpll2_supply[] = { \
{ \
.supply = vpll2, \
.dev = device, \
}, \
}; \
}
And similarly:
#define TWL_VAUX1_VDAC_DATA() { \
static struct regulator_init_data vdac_data = { \
.constraints = { \
.min_uV = 180, \
.max_uV = 180, \
.apply_uV = true, \
.valid_modes_mask = REGULATOR_MODE_NORMAL \
| REGULATOR_MODE_STANDBY, \
.valid_ops_mask = REGULATOR_CHANGE_MODE \
| REGULATOR_CHANGE_STATUS, \
}, \
.num_consumer_supplies = ARRAY_SIZE(vdac_supply), \
.consumer_supplies = vdac_supply, \
}; \
}
This way, user can define his board-specific regulators in the board-*
file.
Only problem I can forsee in this approach is how to create regulators
supplying multiple devices? VLPP2 might be supplying 2-3 devices in the
system which the above #define doesn't take care. How that can be
solved?
+#include linux/i2c/twl4030.h
+
+extern struct twl4030_platform_data omap3evm_twldata;
The *twldata does not have to be global, it can be passed to pmic_init
as a parameter.
+/* VDAC */
+static struct regulator_consumer_supply vdac_consumers[] = {
+ {
+ .supply = dac,
+ },
+};
+
+static struct regulator_init_data vdac_data = {
+ .constraints = {
Re: [PATCH 4/5] Regulator: Adding OMAP3EVM/TWL4030 specific code in board-omap35x-pmic.c
On Mon, Nov 9, 2009 at 8:34 AM, Aggarwal, Anuj anuj.aggar...@ti.com wrote:
Based on your suggestions, I tried creating macros specific to TWL
regulators in a common header file. This file then can be included by
the different board files and the structures can then be appropriately
created.
Here is the sample of what could be done on these lines:
#define TWL_VDAC_SUPPLY(device) { \
The brace is not needed here --^
static struct regulator_consumer_supply vdac_supply[] = { \
{ \
.supply = vdac, \
.dev = device, \
}, \
}; \
}
ditto
#define TWL_VPLL2_SUPPLY(device) { \
the same here ^
static struct regulator_consumer_supply vpll2_supply[] = { \
{ \
.supply = vpll2, \
.dev = device, \
}, \
}; \
}
and here
And similarly:
#define TWL_VAUX1_VDAC_DATA() { \
static struct regulator_init_data vdac_data = { \
.constraints = { \
.min_uV = 180, \
.max_uV = 180, \
.apply_uV = true, \
.valid_modes_mask = REGULATOR_MODE_NORMAL \
| REGULATOR_MODE_STANDBY, \
.valid_ops_mask = REGULATOR_CHANGE_MODE \
| REGULATOR_CHANGE_STATUS, \
}, \
.num_consumer_supplies = ARRAY_SIZE(vdac_supply), \
.consumer_supplies = vdac_supply, \
}; \
}
This way, user can define his board-specific regulators in the board-*
file.
Only problem I can forsee in this approach is how to create regulators
supplying multiple devices? VLPP2 might be supplying 2-3 devices in the
system which the above #define doesn't take care. How that can be
solved?
The macros should be usable for the common case to avoid code
duplication in the board-* files. Boards with different supplies
configuration will explicitly define their regulator_consumer_supply
and regulator_init_data.
+#include linux/i2c/twl4030.h
+
+extern struct twl4030_platform_data omap3evm_twldata;
The *twldata does not have to be global, it can be passed to pmic_init
as a parameter.
+/* VDAC */
+static struct regulator_consumer_supply vdac_consumers[] = {
+ {
+ .supply = dac,
+ },
+};
+
+static struct regulator_init_data vdac_data = {
+ .constraints = {
+ .name = VDAC,
+ .min_uV = 180,
+ .max_uV = 180,
+ .apply_uV = true,
+ .valid_modes_mask = REGULATOR_MODE_NORMAL
+ | REGULATOR_MODE_STANDBY,
+ .valid_ops_mask = REGULATOR_CHANGE_MODE
+ | REGULATOR_CHANGE_STATUS,
+ },
+ .num_consumer_supplies = ARRAY_SIZE(vdac_consumers),
+ .consumer_supplies = vdac_consumers,
+};
+
+/* VPLL2 */
+static struct regulator_consumer_supply vpll2_consumers[] = {
+ {
+ .supply = lcd,
+ },
+ {
+ .supply = sdi,
+ },
+};
+
+static struct regulator_init_data vpll2_data = {
+ .constraints = {
+ .name = VPLL2,
+ .min_uV = 180,
+ .max_uV = 180,
+ .apply_uV = true,
+ .valid_modes_mask = REGULATOR_MODE_NORMAL
+ | REGULATOR_MODE_STANDBY,
+ .valid_ops_mask = REGULATOR_CHANGE_MODE
+ | REGULATOR_CHANGE_STATUS,
+ },
+ .num_consumer_supplies = ARRAY_SIZE(vpll2_consumers),
+ .consumer_supplies = vpll2_consumers,
+};
+
+/* VMMC1 */
+struct regulator_consumer_supply vmmc1_consumers[] = {
+ {
+ .supply = mmc,
+ },
+};
+
+static struct regulator_init_data vmmc1_data = {
+ .constraints = {
+ .name = VMMC1,
+ .min_uV = 185,
+ .max_uV = 315,
+ .valid_modes_mask = REGULATOR_MODE_NORMAL
+ | REGULATOR_MODE_STANDBY,
+ .valid_ops_mask = REGULATOR_CHANGE_VOLTAGE
+ | REGULATOR_CHANGE_MODE |
REGULATOR_CHANGE_STATUS,
+ },
+ .num_consumer_supplies = ARRAY_SIZE(vmmc1_consumers),
+ .consumer_supplies = vmmc1_consumers,
+};
+
+static void __init pmic_twl4030_init(void)
{
- /* TWL4030 specific init code */
+ /* Initialize the regulator specific fields here */
+ omap3evm_twldata.vdac = vdac_data;
+
Re: [alsa-devel] [PATCH 2/4 v2] OMAP: Configure audio_mclk for twl4030-codec MFD
Hello Tony,
On Wednesday 04 November 2009 09:58:18 Ujfalusi Peter (Nokia-D/Tampere) wrote:
audio_mclk value is going to be handled by the
twl4030-codec MFD driver, configure the correct
value for boards, which is using the twl4030 audio.
Signed-off-by: Peter Ujfalusi peter.ujfal...@nokia.com
---
arch/arm/mach-omap2/board-3430sdp.c |1 +
arch/arm/mach-omap2/board-omap3beagle.c |1 +
arch/arm/mach-omap2/board-omap3evm.c |1 +
arch/arm/mach-omap2/board-omap3pandora.c |1 +
arch/arm/mach-omap2/board-overo.c|1 +
arch/arm/mach-omap2/board-zoom2.c|1 +
6 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-3430sdp.c
b/arch/arm/mach-omap2/board-3430sdp.c index 4f91f7a..9afd957 100644
--- a/arch/arm/mach-omap2/board-3430sdp.c
+++ b/arch/arm/mach-omap2/board-3430sdp.c
@@ -415,6 +415,7 @@ static struct twl4030_codec_audio_data sdp3430_audio =
{ };
static struct twl4030_codec_data sdp3430_codec = {
+ .audio_mclk = 2600,
.audio = sdp3430_audio,
};
diff --git a/arch/arm/mach-omap2/board-omap3beagle.c
b/arch/arm/mach-omap2/board-omap3beagle.c index 2161d85..8f0c106 100644
--- a/arch/arm/mach-omap2/board-omap3beagle.c
+++ b/arch/arm/mach-omap2/board-omap3beagle.c
@@ -259,6 +259,7 @@ static struct twl4030_codec_audio_data
beagle_audio_data = { };
static struct twl4030_codec_data beagle_codec_data = {
+ .audio_mclk = 2600,
.audio = beagle_audio_data,
};
diff --git a/arch/arm/mach-omap2/board-omap3evm.c
b/arch/arm/mach-omap2/board-omap3evm.c index d9a6103..5bb30cb 100644
--- a/arch/arm/mach-omap2/board-omap3evm.c
+++ b/arch/arm/mach-omap2/board-omap3evm.c
@@ -199,6 +199,7 @@ static struct twl4030_codec_audio_data
omap3evm_audio_data = { };
static struct twl4030_codec_data omap3evm_codec_data = {
+ .audio_mclk = 2600,
.audio = omap3evm_audio_data,
};
diff --git a/arch/arm/mach-omap2/board-omap3pandora.c
b/arch/arm/mach-omap2/board-omap3pandora.c index 5036b56..77790ee 100644
--- a/arch/arm/mach-omap2/board-omap3pandora.c
+++ b/arch/arm/mach-omap2/board-omap3pandora.c
@@ -286,6 +286,7 @@ static struct twl4030_codec_audio_data
omap3pandora_audio_data = { };
static struct twl4030_codec_data omap3pandora_codec_data = {
+ .audio_mclk = 2600,
.audio = omap3pandora_audio_data,
};
diff --git a/arch/arm/mach-omap2/board-overo.c
b/arch/arm/mach-omap2/board-overo.c index dc55008..e1fb504 100644
--- a/arch/arm/mach-omap2/board-overo.c
+++ b/arch/arm/mach-omap2/board-overo.c
@@ -334,6 +334,7 @@ static struct twl4030_codec_audio_data overo_audio_data
= { };
static struct twl4030_codec_data overo_codec_data = {
+ .audio_mclk = 2600,
.audio = overo_audio_data,
};
diff --git a/arch/arm/mach-omap2/board-zoom2.c
b/arch/arm/mach-omap2/board-zoom2.c index f1b4e7c..de3a38d 100644
--- a/arch/arm/mach-omap2/board-zoom2.c
+++ b/arch/arm/mach-omap2/board-zoom2.c
@@ -234,6 +234,7 @@ static struct twl4030_codec_audio_data zoom2_audio_data
= { };
static struct twl4030_codec_data zoom2_codec_data = {
+ .audio_mclk = 2600,
.audio = zoom2_audio_data,
};
--
1.6.5.2
Can you take a look at this patch?
The rest of the series has already got Ack from Samuel and Mark, and only your
verdict for the OMAP part is missing.
Thank you,
Péter
--
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
Re: [alsa-devel] [PATCH] OMAP: McBSP: Do not use extensive spin locks for dma_op_mode
On Thursday 29 October 2009 09:15:24 ext Jarkko Nikula wrote: On Thu, 29 Oct 2009 08:35:51 +0200 Peter Ujfalusi peter.ujfal...@nokia.com wrote: The spinlocks are unnecessary. In the above example, you get the same with just return mcbsp-dma_op_mode; - Peter's patch is a good cleanup. Jarkko: are we going to take this? Yep, you can have my Acked-by: Jarkko Nikula jhnik...@gmail.com Just want to bring up this thread. Should I resend the patch? -- Péter -- 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
