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 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 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
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
> ---
> 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: [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 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
>> >> > +
>> >> > +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 |
>> >> RE
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
> 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
> >> 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
> >> > ---
> >> > 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
> >> > +
> >> > +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[] = {
> >> > + {
> >> > +
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 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: 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
On Mon, Nov 9, 2009 at 6:59 AM, Niamathullah sharief 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
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. -- 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: [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
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
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
