* [PATCH 2/5] printk: move printk to the end of the file
From: Marc Andre Tanner @ 2009-09-02 14:25 UTC (permalink / raw)
To: linux-embedded; +Cc: mat
In-Reply-To: <1251901505-4313-1-git-send-email-mat@brain-dump.org>
A later patch will #undef printk because the macro would otherwise
conflict with the function definition. Moving the printk function
to the end of the file makes sure that the macro is expanded within
the rest of the file.
Signed-off-by: Marc Andre Tanner <mat@brain-dump.org>
---
kernel/printk.c | 72 ++++++++++++++++++++++++++++--------------------------
1 files changed, 37 insertions(+), 35 deletions(-)
diff --git a/kernel/printk.c b/kernel/printk.c
index b4d97b5..5455d41 100644
--- a/kernel/printk.c
+++ b/kernel/printk.c
@@ -551,40 +551,6 @@ static int have_callable_console(void)
return 0;
}
-/**
- * printk - print a kernel message
- * @fmt: format string
- *
- * This is printk(). It can be called from any context. We want it to work.
- *
- * We try to grab the console_sem. If we succeed, it's easy - we log the output and
- * call the console drivers. If we fail to get the semaphore we place the output
- * into the log buffer and return. The current holder of the console_sem will
- * notice the new output in release_console_sem() and will send it to the
- * consoles before releasing the semaphore.
- *
- * One effect of this deferred printing is that code which calls printk() and
- * then changes console_loglevel may break. This is because console_loglevel
- * is inspected when the actual printing occurs.
- *
- * See also:
- * printf(3)
- *
- * See the vsnprintf() documentation for format string extensions over C99.
- */
-
-asmlinkage int printk(const char *fmt, ...)
-{
- va_list args;
- int r;
-
- va_start(args, fmt);
- r = vprintk(fmt, args);
- va_end(args);
-
- return r;
-}
-
/* cpu currently holding logbuf_lock */
static volatile unsigned int printk_cpu = UINT_MAX;
@@ -770,7 +736,6 @@ out_restore_irqs:
preempt_enable();
return printed_len;
}
-EXPORT_SYMBOL(printk);
EXPORT_SYMBOL(vprintk);
#else
@@ -1337,3 +1302,40 @@ bool printk_timed_ratelimit(unsigned long *caller_jiffies,
}
EXPORT_SYMBOL(printk_timed_ratelimit);
#endif
+
+#ifdef CONFIG_PRINTK
+/**
+ * printk - print a kernel message
+ * @fmt: format string
+ *
+ * This is printk(). It can be called from any context. We want it to work.
+ *
+ * We try to grab the console_sem. If we succeed, it's easy - we log the output and
+ * call the console drivers. If we fail to get the semaphore we place the output
+ * into the log buffer and return. The current holder of the console_sem will
+ * notice the new output in release_console_sem() and will send it to the
+ * consoles before releasing the semaphore.
+ *
+ * One effect of this deferred printing is that code which calls printk() and
+ * then changes console_loglevel may break. This is because console_loglevel
+ * is inspected when the actual printing occurs.
+ *
+ * See also:
+ * printf(3)
+ *
+ * See the vsnprintf() documentation for format string extensions over C99.
+ */
+
+asmlinkage int printk(const char *fmt, ...)
+{
+ va_list args;
+ int r;
+
+ va_start(args, fmt);
+ r = vprintk(fmt, args);
+ va_end(args);
+
+ return r;
+}
+EXPORT_SYMBOL(printk);
+#endif
--
1.6.3.3
^ permalink raw reply related
* [PATCH 3/5] printk: introduce printk_unfiltered as an alias to printk
From: Marc Andre Tanner @ 2009-09-02 14:25 UTC (permalink / raw)
To: linux-embedded; +Cc: mat
In-Reply-To: <1251901505-4313-1-git-send-email-mat@brain-dump.org>
The standard printk function will be wrapped by a macro which
filters out messages above a certain verbosity level. Because
this might not be desired in certain situations we provide an
unfiltered variant.
Signed-off-by: Marc Andre Tanner <mat@brain-dump.org>
---
include/linux/kernel.h | 5 +++++
kernel/printk.c | 23 +++++++++++++++++++++++
2 files changed, 28 insertions(+), 0 deletions(-)
diff --git a/include/linux/kernel.h b/include/linux/kernel.h
index d6320a3..c2b3047 100644
--- a/include/linux/kernel.h
+++ b/include/linux/kernel.h
@@ -239,6 +239,8 @@ asmlinkage int vprintk(const char *fmt, va_list args)
__attribute__ ((format (printf, 1, 0)));
asmlinkage int printk(const char * fmt, ...)
__attribute__ ((format (printf, 1, 2))) __cold;
+asmlinkage int printk_unfiltered(const char *fmt, ...)
+ __attribute__ ((format (printf, 1, 2))) __cold;
extern struct ratelimit_state printk_ratelimit_state;
extern int printk_ratelimit(void);
@@ -265,6 +267,9 @@ static inline int vprintk(const char *s, va_list args) { return 0; }
static inline int printk(const char *s, ...)
__attribute__ ((format (printf, 1, 2)));
static inline int __cold printk(const char *s, ...) { return 0; }
+static inline int printk_unfiltered(const char *s, ...)
+ __attribute__ ((format (printf, 1, 2)));
+static inline int __cold printk_unfiltered(const char *s, ...) { return 0; }
static inline int printk_ratelimit(void) { return 0; }
static inline bool printk_timed_ratelimit(unsigned long *caller_jiffies, \
unsigned int interval_msec) \
diff --git a/kernel/printk.c b/kernel/printk.c
index 5455d41..0a2f654 100644
--- a/kernel/printk.c
+++ b/kernel/printk.c
@@ -1310,6 +1310,11 @@ EXPORT_SYMBOL(printk_timed_ratelimit);
*
* This is printk(). It can be called from any context. We want it to work.
*
+ * Note that depending on the kernel configuration printk might be wrapped by
+ * a macro which will filter out messages above a certain verbosity level.
+ * In cases where it's important that the message will get through independenly
+ * of the configuration setting printk_unfiltered should be used instead.
+ *
* We try to grab the console_sem. If we succeed, it's easy - we log the output and
* call the console drivers. If we fail to get the semaphore we place the output
* into the log buffer and return. The current holder of the console_sem will
@@ -1326,6 +1331,14 @@ EXPORT_SYMBOL(printk_timed_ratelimit);
* See the vsnprintf() documentation for format string extensions over C99.
*/
+/*
+ * We need to #undef the printk macro from <linux/kernel.h> because
+ * it would otherwise conflict with the function implementation.
+ */
+#ifdef printk
+# undef printk
+#endif
+
asmlinkage int printk(const char *fmt, ...)
{
va_list args;
@@ -1338,4 +1351,14 @@ asmlinkage int printk(const char *fmt, ...)
return r;
}
EXPORT_SYMBOL(printk);
+
+/*
+ * Because printk might be wrapped by a macro which will filter out messages
+ * above a certain verbosity level we provide an unfiltered variant for use
+ * cases where the filtering isn't desired.
+ */
+
+asmlinkage int printk_unfiltered(const char *fmt, ...)
+ __attribute__((alias("printk")));
+EXPORT_SYMBOL(printk_unfiltered);
#endif
--
1.6.3.3
^ permalink raw reply related
* [PATCH 4/5] char/mem: replace printk with printk_unfiltered
From: Marc Andre Tanner @ 2009-09-02 14:25 UTC (permalink / raw)
To: linux-embedded; +Cc: mat
In-Reply-To: <1251901505-4313-1-git-send-email-mat@brain-dump.org>
We don't want to filter user space data which comes from /dev/kmsg.
Signed-off-by: Marc Andre Tanner <mat@brain-dump.org>
---
drivers/char/mem.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/char/mem.c b/drivers/char/mem.c
index afa8813..ba48b82 100644
--- a/drivers/char/mem.c
+++ b/drivers/char/mem.c
@@ -850,7 +850,7 @@ static ssize_t kmsg_write(struct file * file, const char __user * buf,
ret = -EFAULT;
if (!copy_from_user(tmp, buf, count)) {
tmp[count] = 0;
- ret = printk("%s", tmp);
+ ret = printk_unfiltered("%s", tmp);
if (ret > count)
/* printk can add a prefix */
ret = count;
--
1.6.3.3
^ permalink raw reply related
* [PATCH 5/5] printk: provide a filtering macro for printk
From: Marc Andre Tanner @ 2009-09-02 14:25 UTC (permalink / raw)
To: linux-embedded; +Cc: mat
In-Reply-To: <1251901505-4313-1-git-send-email-mat@brain-dump.org>
The macro filters out printk messages based on a configurable verbosity
level (CONFIG_PRINTK_VERBOSITY).
Signed-off-by: Marc Andre Tanner <mat@brain-dump.org>
---
include/linux/kernel.h | 23 +++++++++++++++++++++++
1 files changed, 23 insertions(+), 0 deletions(-)
diff --git a/include/linux/kernel.h b/include/linux/kernel.h
index c2b3047..1ecc338 100644
--- a/include/linux/kernel.h
+++ b/include/linux/kernel.h
@@ -242,6 +242,29 @@ asmlinkage int printk(const char * fmt, ...)
asmlinkage int printk_unfiltered(const char *fmt, ...)
__attribute__ ((format (printf, 1, 2))) __cold;
+#if defined(CONFIG_PRINTK_VERBOSITY) && CONFIG_PRINTK_VERBOSITY > 0
+/*
+ * The idea here is to wrap the actual printk function with a macro which
+ * will filter out all messages above a certain verbosity level. Because
+ * the if condition evaluates to a constant expression the compiler will be
+ * able to eliminate it and the resulting kernel image will be smaller.
+ */
+
+#include <linux/stringify.h>
+
+#define PRINTK_FILTER(fmt) ( \
+ (((const char *)(fmt))[0] != '<' && CONFIG_PRINTK_VERBOSITY >= 4) || \
+ (((const char *)(fmt))[0] == '<' && \
+ ((const char *)(fmt))[1] <= *__stringify(CONFIG_PRINTK_VERBOSITY)) \
+)
+
+#define printk(fmt, ...) ( \
+ (!__builtin_constant_p(PRINTK_FILTER((fmt))) || PRINTK_FILTER((fmt))) ? \
+ printk((fmt), ##__VA_ARGS__) : 0 \
+)
+
+#endif /* CONFIG_PRINTK_VERBOSITY */
+
extern struct ratelimit_state printk_ratelimit_state;
extern int printk_ratelimit(void);
extern bool printk_timed_ratelimit(unsigned long *caller_jiffies,
--
1.6.3.3
^ permalink raw reply related
* Re: [PATCH 7/7] printk: provide a filtering macro for printk
From: Jamie Lokier @ 2009-09-02 14:30 UTC (permalink / raw)
To: Mike Frysinger; +Cc: Marc Andre Tanner, Bill Gatliff, linux-embedded
In-Reply-To: <8bd0f97a0909020554j9ebdf54v813a6ec74c5c1e7c@mail.gmail.com>
Mike Frysinger wrote:
> it depends completely on how the macro is intended to be used. if you
> want to maintain the "this macro has a return value", then you have to
> use ({...}). if you want the macro to return a void, then you have to
> use do{...}while(0).
Actually no. The difference is do {...} while(0) is a _statement_ and
cannot be used in an expression. Whereas a void value can be used in
expressions like A?B:C, (A,B) and returned from a function, it just
has type void.
-- Jamie
^ permalink raw reply
* Re: [PATCH 1/5] printk: introduce CONFIG_PRINTK_VERBOSITY
From: Marco Stornelli @ 2009-09-02 16:44 UTC (permalink / raw)
To: Marc Andre Tanner; +Cc: linux-embedded
In-Reply-To: <1251901505-4313-2-git-send-email-mat@brain-dump.org>
Marc Andre Tanner ha scritto:
> Introduce a config option which allows to selectively compile out
> printk messages based on a specified verbosity level.
>
> Signed-off-by: Marc Andre Tanner <mat@brain-dump.org>
> ---
> init/Kconfig | 29 +++++++++++++++++++++++++++++
> 1 files changed, 29 insertions(+), 0 deletions(-)
>
> diff --git a/init/Kconfig b/init/Kconfig
> index 3f7e609..549ed95 100644
> --- a/init/Kconfig
> +++ b/init/Kconfig
> @@ -833,6 +833,35 @@ config PRINTK
> very difficult to diagnose system problems, saying N here is
> strongly discouraged.
>
> +config PRINTK_VERBOSITY
> + int "Printk compile time verbosity"
> + depends on EMBEDDED && PRINTK
> + range 0 7
> + default 0
> + help
> +
> + Select the maximum printk verbosity level to be compiled into
> + the kernel.
> +
> + Messages above the specified verbosity level are removed from
> + the kernel at compile time. This reduces the kernel image size
> + at the cost of a calmer kernel.
> +
> + Possible verbosity levels are listed below. Note that messages
> + without an explicit loglevel will be classified as KERN_WARNING.
> +
> + 0 Disable this feature and compile all messages in.
> +
> + 1 KERN_ALERT /* action must be taken immediately */
> + 2 KERN_CRIT /* critical conditions */
> + 3 KERN_ERR /* error conditions */
> + 4 KERN_WARNING /* warning conditions */
> + 5 KERN_NOTICE /* normal but significant condition */
> + 6 KERN_INFO /* informational */
> + 7 KERN_DEBUG /* debug-level messages */
> +
> + If unsure, just move on and leave this option alone.
> +
> config BUG
> bool "BUG() support" if EMBEDDED
> default y
If there are some problems to handle KERN_CONT you should say something
here. You should even add in cc: the kernel ML, however it seems a good
work.
Marco
^ permalink raw reply
* Re: [PATCH 5/5] printk: provide a filtering macro for printk
From: Marco Stornelli @ 2009-09-02 16:44 UTC (permalink / raw)
To: Marc Andre Tanner; +Cc: linux-embedded
In-Reply-To: <1251901505-4313-6-git-send-email-mat@brain-dump.org>
Marc Andre Tanner ha scritto:
> +#define printk(fmt, ...) ( \
Shouldn't it be an and?
> + (!__builtin_constant_p(PRINTK_FILTER((fmt))) || PRINTK_FILTER((fmt))) ? \
> + printk((fmt), ##__VA_ARGS__) : 0 \
> +)
> +
> +#endif /* CONFIG_PRINTK_VERBOSITY */
> +
Marco
^ permalink raw reply
* Re: [PATCH 7/7] printk: provide a filtering macro for printk
From: Tim Bird @ 2009-09-02 17:05 UTC (permalink / raw)
To: Marc Andre Tanner
Cc: H Hartley Sweeten, linux-embedded, Ingo Molnar, linux kernel
In-Reply-To: <20090902130943.GE2736@debbook.brain-dump.org>
Marc Andre Tanner wrote:
> On Tue, Sep 01, 2009 at 07:32:25PM -0400, H Hartley Sweeten wrote:
>> On Tuesday, September 01, 2009 4:24 PM, Tim Bird wrote:
>>> Some places in the kernel break the message into pieces, like so:
>>>
>>> printk(KERN_ERR, "Error: first part ");
>>> ...
>>> printk(" more info for error.\n");
>> Technically, shouldn't the second part of the message actually be:
>>
>> printk(KERN_CONT " more info for error.\n");
>>
>> Maybe some mechanism could be created to handle the continued message
>> if they have the KERN_CONT?
>
> Yes it's true that KERN_CONT isn't handled correctly, but I don't see a way
> to change that.
>
>>> These parts would not be handled consistently under certain
>>> conditions.
>>>
>>> It would be confusing to see only part of the message,
>>> but I don't know how often this construct is used.
>
> $ grep -R KERN_CONT linux-2.6 | wc -l
> 373
>
>>> Maybe
>>> another mechanism is needed to ensure that continuation
>>> printk lines have the same log level as their start strings.
>
> I currently don't see a way to achieve this with the CPP.
If it's that few, then maybe it's OK to actually change
the code for those printk statements. (Heck, these locations
were all changed in the last 2 years anyway.)
I'm just brainstorming here, but how about changing them from:
printk(KERN_INFO "foo");
printk(KERN_CONT "bar\n");
to:
printk(KERN_INFO "foo");
printk_cont(KERN_INFO "bar\n");
This way the continuation line has the log level, and can
be conditionally compiled based on the VERBOSITY level. A little
magic would be needed to strip the first 3 chars of the fmt
string in printk_cont().
I think this makes the printk messages a bit more consistent anyway,
and still marks lines that are continuation lines.
>>> But, overall, very slick! It's nice to see a solution that doesn't
>>> require changing all printks statements in the kernel.
>
> Yes that's what I thought too. Thanks to the comments so far the next
> version of the patch will contain even less changes to the rest of the
> kernel.
>
>> I haven't looked over this patch series yet but does it work with the
>> pr_<level> macros (pr_info, pr_err, etc.)?
>
> It should work, yes.
-- Tim
=============================
Tim Bird
Architecture Group Chair, CE Linux Forum
Senior Staff Engineer, Sony Corporation of America
=============================
^ permalink raw reply
* Re: [PATCH 5/5] printk: provide a filtering macro for printk
From: Marc Andre Tanner @ 2009-09-02 17:27 UTC (permalink / raw)
To: Marco Stornelli; +Cc: linux-embedded
In-Reply-To: <4A9EA0E3.8000603@gmail.com>
On Wed, Sep 02, 2009 at 06:44:19PM +0200, Marco Stornelli wrote:
>
>
> Marc Andre Tanner ha scritto:
> > +#define printk(fmt, ...) ( \
>
> Shouldn't it be an and?
Don't think so. If the expression isn't constant we are unable to filter it
and therefore printk is called anyway. However if the expression is constant
the second part of the condition is evaluated and we filter based on the
verbosity level.
> > + (!__builtin_constant_p(PRINTK_FILTER((fmt))) || PRINTK_FILTER((fmt))) ? \
> > + printk((fmt), ##__VA_ARGS__) : 0 \
> > +)
> > +
> > +#endif /* CONFIG_PRINTK_VERBOSITY */
> > +
Marc
--
Marc Andre Tanner >< http://www.brain-dump.org/ >< GPG key: CF7D56C0
^ permalink raw reply
* Re: [PATCH 7/7] printk: provide a filtering macro for printk
From: Tim Bird @ 2009-09-02 17:31 UTC (permalink / raw)
To: Marc Andre Tanner
Cc: H Hartley Sweeten, linux-embedded, Ingo Molnar, linux kernel
In-Reply-To: <4A9EA5C9.3010900@am.sony.com>
Tim Bird wrote:
> Marc Andre Tanner wrote:
>> On Tue, Sep 01, 2009 at 07:32:25PM -0400, H Hartley Sweeten wrote:
>>> On Tuesday, September 01, 2009 4:24 PM, Tim Bird wrote:
>>>> Some places in the kernel break the message into pieces, like so:
>>>>
>>>> printk(KERN_ERR, "Error: first part ");
>>>> ...
>>>> printk(" more info for error.\n");
>>> Technically, shouldn't the second part of the message actually be:
>>>
>>> printk(KERN_CONT " more info for error.\n");
>>>
>>> Maybe some mechanism could be created to handle the continued message
>>> if they have the KERN_CONT?
>> Yes it's true that KERN_CONT isn't handled correctly, but I don't see a way
>> to change that.
>>
>>>> These parts would not be handled consistently under certain
>>>> conditions.
>>>>
>>>> It would be confusing to see only part of the message,
>>>> but I don't know how often this construct is used.
>> $ grep -R KERN_CONT linux-2.6 | wc -l
>> 373
>>
>>>> Maybe
>>>> another mechanism is needed to ensure that continuation
>>>> printk lines have the same log level as their start strings.
>> I currently don't see a way to achieve this with the CPP.
>
> If it's that few, then maybe it's OK to actually change
> the code for those printk statements. (Heck, these locations
> were all changed in the last 2 years anyway.)
>
> I'm just brainstorming here, but how about changing them from:
> printk(KERN_INFO "foo");
> printk(KERN_CONT "bar\n");
> to:
> printk(KERN_INFO "foo");
> printk_cont(KERN_INFO "bar\n");
>
> This way the continuation line has the log level, and can
> be conditionally compiled based on the VERBOSITY level. A little
> magic would be needed to strip the first 3 chars of the fmt
> string in printk_cont().
>
> I think this makes the printk messages a bit more consistent anyway,
> and still marks lines that are continuation lines.
Just another note. Detecting continuation lines also complicates
the printk timestamping code. If all continuation lines were
distinguishable by the printk code, then it might be possible
to simplify the timestamping code as a side effect of the
change.
-- Tim
=============================
Tim Bird
Architecture Group Chair, CE Linux Forum
Senior Staff Engineer, Sony Corporation of America
=============================
^ permalink raw reply
* Re: [PATCH 1/5] printk: introduce CONFIG_PRINTK_VERBOSITY
From: Marc Andre Tanner @ 2009-09-02 17:32 UTC (permalink / raw)
To: Marco Stornelli; +Cc: linux-embedded
In-Reply-To: <4A9EA0D6.2030504@gmail.com>
On Wed, Sep 02, 2009 at 06:44:06PM +0200, Marco Stornelli wrote:
> Marc Andre Tanner ha scritto:
> > Introduce a config option which allows to selectively compile out
> > printk messages based on a specified verbosity level.
> >
> > Signed-off-by: Marc Andre Tanner <mat@brain-dump.org>
> > ---
> > init/Kconfig | 29 +++++++++++++++++++++++++++++
> > 1 files changed, 29 insertions(+), 0 deletions(-)
> >
> > diff --git a/init/Kconfig b/init/Kconfig
> > index 3f7e609..549ed95 100644
> > --- a/init/Kconfig
> > +++ b/init/Kconfig
> > @@ -833,6 +833,35 @@ config PRINTK
> > very difficult to diagnose system problems, saying N here is
> > strongly discouraged.
> >
> > +config PRINTK_VERBOSITY
> > + int "Printk compile time verbosity"
> > + depends on EMBEDDED && PRINTK
> > + range 0 7
> > + default 0
> > + help
> > +
> > + Select the maximum printk verbosity level to be compiled into
> > + the kernel.
> > +
> > + Messages above the specified verbosity level are removed from
> > + the kernel at compile time. This reduces the kernel image size
> > + at the cost of a calmer kernel.
> > +
> > + Possible verbosity levels are listed below. Note that messages
> > + without an explicit loglevel will be classified as KERN_WARNING.
> > +
> > + 0 Disable this feature and compile all messages in.
> > +
> > + 1 KERN_ALERT /* action must be taken immediately */
> > + 2 KERN_CRIT /* critical conditions */
> > + 3 KERN_ERR /* error conditions */
> > + 4 KERN_WARNING /* warning conditions */
> > + 5 KERN_NOTICE /* normal but significant condition */
> > + 6 KERN_INFO /* informational */
> > + 7 KERN_DEBUG /* debug-level messages */
> > +
> > + If unsure, just move on and leave this option alone.
> > +
> > config BUG
> > bool "BUG() support" if EMBEDDED
> > default y
>
> If there are some problems to handle KERN_CONT you should say something
> here.
ACK.
> You should even add in cc: the kernel ML, however it seems a good
> work.
Well I first wanted to get some feedback from the embedded people.
I will probably send it to LKML after the 2.6.31 release, don't know
how the chances for inclusion are though.
Marc
--
Marc Andre Tanner >< http://www.brain-dump.org/ >< GPG key: CF7D56C0
^ permalink raw reply
* RE: [PATCH 7/7] printk: provide a filtering macro for printk
From: H Hartley Sweeten @ 2009-09-02 18:22 UTC (permalink / raw)
To: Tim Bird, Marc Andre Tanner; +Cc: linux-embedded, Ingo Molnar, linux kernel
In-Reply-To: <4A9EA5C9.3010900@am.sony.com>
On Wednesday, September 02, 2009 10:05 AM, Tim Bird wrote:
> Marc Andre Tanner wrote:
>> On Tue, Sep 01, 2009 at 07:32:25PM -0400, H Hartley Sweeten wrote:
>>> On Tuesday, September 01, 2009 4:24 PM, Tim Bird wrote:
>>>> Some places in the kernel break the message into pieces, like so:
>>>>
>>>> printk(KERN_ERR, "Error: first part ");
>>>> ...
>>>> printk(" more info for error.\n");
>>> Technically, shouldn't the second part of the message actually be:
>>>
>>> printk(KERN_CONT " more info for error.\n");
>>>
>>> Maybe some mechanism could be created to handle the continued message
>>> if they have the KERN_CONT?
>>
>> Yes it's true that KERN_CONT isn't handled correctly, but I don't see a way
>> to change that.
>>
>>>> These parts would not be handled consistently under certain
>>>> conditions.
>>>>
>>>> It would be confusing to see only part of the message,
>>>> but I don't know how often this construct is used.
>>
>> $ grep -R KERN_CONT linux-2.6 | wc -l
>> 373
>>
>>>> Maybe
>>>> another mechanism is needed to ensure that continuation
>>>> printk lines have the same log level as their start strings.
>>
>> I currently don't see a way to achieve this with the CPP.
>
> If it's that few, then maybe it's OK to actually change
> the code for those printk statements. (Heck, these locations
> were all changed in the last 2 years anyway.)
>
> I'm just brainstorming here, but how about changing them from:
> printk(KERN_INFO "foo");
> printk(KERN_CONT "bar\n");
> to:
> printk(KERN_INFO "foo");
> printk_cont(KERN_INFO "bar\n");
>
Unfortunately not all the continued printk statements in the kernel are
properly tagged with KERN_CONT (or pr_cont, etc.).
> This way the continuation line has the log level, and can
> be conditionally compiled based on the VERBOSITY level. A little
> magic would be needed to strip the first 3 chars of the fmt
> string in printk_cont().
>
> I think this makes the printk messages a bit more consistent anyway,
> and still marks lines that are continuation lines.
>
>>>> But, overall, very slick! It's nice to see a solution that doesn't
>>>> require changing all printks statements in the kernel.
>>
>> Yes that's what I thought too. Thanks to the comments so far the next
>> version of the patch will contain even less changes to the rest of the
>> kernel.
>>
>>> I haven't looked over this patch series yet but does it work with the
>>> pr_<level> macros (pr_info, pr_err, etc.)?
>>
>> It should work, yes.
Regards,
Hartley
^ permalink raw reply
* Re: 100Mbit ethernet performance on embedded devices
From: David Acker @ 2009-09-02 19:35 UTC (permalink / raw)
To: Johannes Stezenbach; +Cc: linux-embedded, netdev
In-Reply-To: <20090819145057.GA25400@sig21.net>
Johannes Stezenbach wrote:
> What I'm interested in are some numbers for similar hardware,
> to find out if my hardware and/or ethernet driver can be improved,
> or if the CPU will always be the limiting factor.
> I'd also be interested to know if hardware checksumming
> support would improve throughput noticably in such a system,
> or if it is only useful for 1Gbit and above.
>
> Did anyone actually manage to get close to 100Mbit/sec
> with similar CPU resources?
I have a pico station, http://ubnt.com/products/picostation.php with
Atheros MIPS 4KC @ 180MHz. Iperf on this device gives 46.0 Mbits/sec
sending TCP from a PC to the device and 36.2 Mbits/sec sending TCP from
the device to a PC. The NIC is part of the Atheros chipset so PCI is
not involved.
-ack
^ permalink raw reply
* Re: [PATCH 5/5] printk: provide a filtering macro for printk
From: Marco Stornelli @ 2009-09-03 6:29 UTC (permalink / raw)
To: Marc Andre Tanner; +Cc: linux-embedded
In-Reply-To: <20090902172724.GA5811@debbook.brain-dump.org>
2009/9/2 Marc Andre Tanner <mat@brain-dump.org>:
> On Wed, Sep 02, 2009 at 06:44:19PM +0200, Marco Stornelli wrote:
>>
>>
>> Marc Andre Tanner ha scritto:
>> > +#define printk(fmt, ...) ( \
>>
>> Shouldn't it be an and?
>
> Don't think so. If the expression isn't constant we are unable to filter it
> and therefore printk is called anyway. However if the expression is constant
> the second part of the condition is evaluated and we filter based on the
> verbosity level.
>
Yes, you're right.
Marco
^ permalink raw reply
* Re: [PATCH 7/7] printk: provide a filtering macro for printk
From: Marc Andre Tanner @ 2009-09-04 14:05 UTC (permalink / raw)
To: H Hartley Sweeten; +Cc: Tim Bird, linux-embedded, Ingo Molnar, linux kernel
In-Reply-To: <BD79186B4FD85F4B8E60E381CAEE190901C55DE5@mi8nycmail19.Mi8.com>
On Wed, Sep 02, 2009 at 02:22:52PM -0400, H Hartley Sweeten wrote:
> On Wednesday, September 02, 2009 10:05 AM, Tim Bird wrote:
> > Marc Andre Tanner wrote:
> >> On Tue, Sep 01, 2009 at 07:32:25PM -0400, H Hartley Sweeten wrote:
> >>> On Tuesday, September 01, 2009 4:24 PM, Tim Bird wrote:
> >>>> Some places in the kernel break the message into pieces, like so:
> >>>>
> >>>> printk(KERN_ERR, "Error: first part ");
> >>>> ...
> >>>> printk(" more info for error.\n");
> >>> Technically, shouldn't the second part of the message actually be:
> >>>
> >>> printk(KERN_CONT " more info for error.\n");
> >>>
> >>> Maybe some mechanism could be created to handle the continued message
> >>> if they have the KERN_CONT?
> >>
> >> Yes it's true that KERN_CONT isn't handled correctly, but I don't see a way
> >> to change that.
> >>
> >>>> These parts would not be handled consistently under certain
> >>>> conditions.
> >>>>
> >>>> It would be confusing to see only part of the message,
> >>>> but I don't know how often this construct is used.
> >>
> >> $ grep -R KERN_CONT linux-2.6 | wc -l
> >> 373
> >>
> >>>> Maybe
> >>>> another mechanism is needed to ensure that continuation
> >>>> printk lines have the same log level as their start strings.
> >>
> >> I currently don't see a way to achieve this with the CPP.
> >
> > If it's that few, then maybe it's OK to actually change
> > the code for those printk statements. (Heck, these locations
> > were all changed in the last 2 years anyway.)
> >
> > I'm just brainstorming here, but how about changing them from:
> > printk(KERN_INFO "foo");
> > printk(KERN_CONT "bar\n");
> > to:
> > printk(KERN_INFO "foo");
> > printk_cont(KERN_INFO "bar\n");
>
> Unfortunately not all the continued printk statements in the kernel are
> properly tagged with KERN_CONT (or pr_cont, etc.).
Yes and a quick search revealed that there are actually quite a lot of
those untagged messages.
As I needed some distraction from some other work I played around a bit
more with a solution which wouldn't require to change existing kernel
code. It uses a variable which would have to be available in every
function to store the loglevel of messages which are split over multiple
printk calls. Here is what I came up with so far:
#define PRINTK_IS_LINE(fmt) ( \
((const char*)(fmt))[sizeof((fmt)) - 2] == '\n' \
)
#define PRINTK_LEVEL(fmt) ( \
(((const char *)(fmt))[0] == '<' && \
((const char *)(fmt))[1] >= '0' && \
((const char *)(fmt))[1] <= '9' \
) ? ((const char *)(fmt))[1] - '0' : 4 \
)
#define printk(fmt, ...) ({ \
int __printk_ret = 0; \
int __printk_level = __printk_cont_level; \
\
if (__builtin_constant_p((fmt)) && ((fmt))) { \
/* check if we are dealing with a line ending */ \
if (PRINTK_IS_LINE((fmt))) { \
/* check if it was a whole line */ \
if (__printk_cont_level == -1) \
__printk_level = PRINTK_LEVEL((fmt)); \
__printk_cont_level = -1; \
} else if (__printk_cont_level == -1) /* first part of a line? */ \
__printk_level = __printk_cont_level = PRINTK_LEVEL((fmt)); \
} \
\
if (!__builtin_constant_p((fmt)) || __printk_level <= CONFIG_PRINTK_VERBOSITY) \
__printk_ret = printk((fmt), ##__VA_ARGS__); \
\
__printk_ret; \
})
Apart from the fact that it's getting uglier it obviously depends on
the availability of __printk_cont_level (which would get compiled out,
at least I hope so) in every function.
So
void demo() {
...
}
would have to become:
void demo() {
int __printk_cont_level = -1;
...
}
I don't know whether this is possible at all through some kind of gcc
magic. There is also the problem of introducing warnings when
__prink_cont_level isn't used in a function but I guess this could be
dealt with some __attribute__ setting.
Anyway just wanted to share the results of a brainstorming session.
Marc
--
Marc Andre Tanner >< http://www.brain-dump.org/ >< GPG key: CF7D56C0
^ permalink raw reply
* Re: [PATCH 4/6 v2] Add support for LZO-compressed kernels for ARM
From: Albin Tonnerre @ 2009-09-04 15:31 UTC (permalink / raw)
To: Russell King - ARM Linux
Cc: sam, hpa, alain, linux-kernel, linux-embedded, akpm
In-Reply-To: <20090814100828.GD5985@pc-ras4041.res.insa>
On Fri, Aug 14, 2009 at 12:08:28PM +0200, Albin Tonnerre wrote :
> This is the second part of patch. This part includes:
> - changes to ach/arch/boot/Makefile to make it easier to add new
> compression types
> - new piggy.lzo.S necessary for lzo compression
> - changes in arch/arm/boot/compressed/misc.c to allow the use of lzo or
> gzip, depending on the config
> - Kconfig support
>
> Signed-off-by: Albin Tonnerre <albin.tonnerre@free-electrons.com>
> ---
> Changes:
> Compiling with -Os failed due to missing __aeabi_uidivmod.
> Link using arch/arm/lib/lib1funcs.o which provides this symbol, and
> define a dummy __div0 function in arch/arm/boot/compressed/misc.c, as
> this symbol is required by lib1funcs.
Hi Russell,
Does that solve the concerns/issues you had with this patch?
If so, it might be worth getting the updaed version in Andrew's branch.
Regards,
--
Albin Tonnerre, Free Electrons
Kernel, drivers and embedded Linux development,
consulting, training and support.
http://free-electrons.com
^ permalink raw reply
* Re: New fast(?)-boot results on ARM
From: Wolfram Sang @ 2009-09-04 16:16 UTC (permalink / raw)
To: Johannes Stezenbach
Cc: Robert Schwebel, Denys Vlasenko, linux-kernel, linux-embedded,
Arjan van de Ven, Tim Bird, kernel
In-Reply-To: <20090815103532.GA5596@sig21.net>
[-- Attachment #1: Type: text/plain, Size: 418 bytes --]
> Now that microcom is in Debian sid (thanks!), where can I find ptx_ts?
> It seems to be quite useful.
Back from the holidays, so here it is:
http://pengutronix.de/software/ptx_ts/index_en.html
Hope it can be useful...
Regards,
Wolfram
--
Pengutronix e.K. | Wolfram Sang |
Industrial Linux Solutions | http://www.pengutronix.de/ |
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: New fast(?)-boot results on ARM
From: Johannes Stezenbach @ 2009-09-09 14:33 UTC (permalink / raw)
To: Wolfram Sang
Cc: Robert Schwebel, Denys Vlasenko, linux-kernel, linux-embedded,
Arjan van de Ven, Tim Bird, kernel
In-Reply-To: <20090904161626.GD3207@pengutronix.de>
Sorry for slow reply.
On Fri, Sep 04, 2009 at 06:16:26PM +0200, Wolfram Sang wrote:
>
> > Now that microcom is in Debian sid (thanks!), where can I find ptx_ts?
> > It seems to be quite useful.
>
> Back from the holidays, so here it is:
>
> http://pengutronix.de/software/ptx_ts/index_en.html
>
> Hope it can be useful...
Yes, it is. Thanks!
BTW, some feedback about microcom:
- the choice of ^\ as an escape charater is unfortunate since that
is usually mapped to set SIGQUIT in the tty; a btter choice would
be ^] (like telnet) or ^A (like minicom)
- typing the escape character immediate causes the menu to be displayed,
so one cannot send a break sequence for SysRq without cluttering up the screen
Would you take patches for that?
Johannes
^ permalink raw reply
* Re: New fast(?)-boot results on ARM
From: Denys Vlasenko @ 2009-09-10 0:03 UTC (permalink / raw)
To: Johannes Stezenbach
Cc: Wolfram Sang, Robert Schwebel, linux-kernel, linux-embedded,
Arjan van de Ven, Tim Bird, kernel
In-Reply-To: <20090909143354.GA15973@sig21.net>
On Wednesday 09 September 2009 16:33, Johannes Stezenbach wrote:
> Sorry for slow reply.
>
> On Fri, Sep 04, 2009 at 06:16:26PM +0200, Wolfram Sang wrote:
> >
> > > Now that microcom is in Debian sid (thanks!), where can I find ptx_ts?
> > > It seems to be quite useful.
> >
> > Back from the holidays, so here it is:
> >
> > http://pengutronix.de/software/ptx_ts/index_en.html
> >
> > Hope it can be useful...
>
> Yes, it is. Thanks!
>
> BTW, some feedback about microcom:
>
> - the choice of ^\ as an escape charater is unfortunate since that
> is usually mapped to set SIGQUIT in the tty; a btter choice would
> be ^] (like telnet) or ^A (like minicom)
> - typing the escape character immediate causes the menu to be displayed,
> so one cannot send a break sequence for SysRq without cluttering up the screen
>
> Would you take patches for that?
Sure.
--
vda
^ permalink raw reply
* Re: [PATCH 7/7] printk: provide a filtering macro for printk
From: Geert Uytterhoeven @ 2009-09-10 9:22 UTC (permalink / raw)
To: Tim Bird
Cc: Marc Andre Tanner, H Hartley Sweeten, linux-embedded, Ingo Molnar,
linux kernel
In-Reply-To: <4A9EA5C9.3010900@am.sony.com>
On Wed, 2 Sep 2009, Tim Bird wrote:
> Marc Andre Tanner wrote:
> > On Tue, Sep 01, 2009 at 07:32:25PM -0400, H Hartley Sweeten wrote:
> >> On Tuesday, September 01, 2009 4:24 PM, Tim Bird wrote:
> >>> Some places in the kernel break the message into pieces, like so:
> >>>
> >>> printk(KERN_ERR, "Error: first part ");
> >>> ...
> >>> printk(" more info for error.\n");
> >> Technically, shouldn't the second part of the message actually be:
> >>
> >> printk(KERN_CONT " more info for error.\n");
> >>
> >> Maybe some mechanism could be created to handle the continued message
> >> if they have the KERN_CONT?
> >
> > Yes it's true that KERN_CONT isn't handled correctly, but I don't see a way
> > to change that.
> >
> >>> These parts would not be handled consistently under certain
> >>> conditions.
> >>>
> >>> It would be confusing to see only part of the message,
> >>> but I don't know how often this construct is used.
> >
> > $ grep -R KERN_CONT linux-2.6 | wc -l
> > 373
> >
> >>> Maybe
> >>> another mechanism is needed to ensure that continuation
> >>> printk lines have the same log level as their start strings.
> >
> > I currently don't see a way to achieve this with the CPP.
>
> If it's that few, then maybe it's OK to actually change
> the code for those printk statements. (Heck, these locations
> were all changed in the last 2 years anyway.)
>
> I'm just brainstorming here, but how about changing them from:
> printk(KERN_INFO "foo");
> printk(KERN_CONT "bar\n");
> to:
> printk(KERN_INFO "foo");
> printk_cont(KERN_INFO "bar\n");
>
> This way the continuation line has the log level, and can
> be conditionally compiled based on the VERBOSITY level. A little
> magic would be needed to strip the first 3 chars of the fmt
> string in printk_cont().
You could strip the first 3 chars by adding 3 to the pointer. Which will
fail horribly if the KERN_* is forgotten and the format string is very short.
And the KERN_* still consumes memory.
Or make the KERN_* an explicit first parameter:
printk_cont(KERN_INFO, "bar\n");
Is "strcmp(p, KERN_INFO)" optimized away for constant strings?
> I think this makes the printk messages a bit more consistent anyway,
> and still marks lines that are continuation lines.
With kind regards,
Geert Uytterhoeven
Software Architect
Techsoft Centre
Technology and Software Centre Europe
The Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · Belgium
Phone: +32 (0)2 700 8453
Fax: +32 (0)2 700 8622
E-mail: Geert.Uytterhoeven@sonycom.com
Internet: http://www.sony-europe.com/
A division of Sony Europe (Belgium) N.V.
VAT BE 0413.825.160 · RPR Brussels
Fortis · BIC GEBABEBB · IBAN BE41293037680010
^ permalink raw reply
* [BUG]: v2.6.31: always output black in beagle DVI LCD
From: Ming Lei @ 2009-09-18 15:52 UTC (permalink / raw)
To: linux-omap, Linux-ARM Kernel, linux-embedded
Board: beagle B5
LCD: can show beagle logo in uboot
Once I upgrade to v2.6.31 from
git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap-2.6.git
and apply the patch:
omapfb: Reorder Register_framebuffer call
http://marc.info/?l=linux-omap&m=125277326104621&w=2
the dvi lcd can't show anything but black colour. And from view of the monitor,
there is video signal outputed from beagle, which can be indicated the
green-led of
monitor.
Also the fb device(/dev/fb0) can be accessed well by my test code.
I can provide more information if anyone needs.
Thanks.
--
Lei Ming
^ permalink raw reply
* Re: [BUG]: v2.6.31: always output black in beagle DVI LCD
From: Ming Lei @ 2009-09-19 14:01 UTC (permalink / raw)
To: linux-omap, linux-embedded
In-Reply-To: <d82e647a0909180852u13dc1751pc1ae88413707706@mail.gmail.com>
2009/9/18 Ming Lei <tom.leiming@gmail.com>:
> Board: beagle B5
> LCD: can show beagle logo in uboot
>
> Once I upgrade to v2.6.31 from
> git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap-2.6.git
>
> and apply the patch:
> omapfb: Reorder Register_framebuffer call
> http://marc.info/?l=linux-omap&m=125277326104621&w=2
>
> the dvi lcd can't show anything but black colour. And from view of the monitor,
> there is video signal outputed from beagle, which can be indicated the
> green-led of
> monitor.
>
> Also the fb device(/dev/fb0) can be accessed well by my test code.
>
> I can provide more information if anyone needs.
dmesg:
Linux version 2.6.31-omap1-05924-g3a3575e-dirty (lm@linux-lm) (gcc
version 4.2.1 (CodeSourcery S
ourcery G++ Lite 2007q3-51)) #80 Fri Sep 18 23:35:02 CST 2009
CPU: ARMv7 Processor [411fc082] revision 2 (ARMv7), cr=10c53c7f
CPU: VIPT nonaliasing data cache, VIPT nonaliasing instruction cache
Machine: OMAP3 Beagle Board
Memory policy: ECC disabled, Data cache writeback
On node 0 totalpages: 32768
free_area_init_node: node 0, pgdat c03862c0, node_mem_map c03a2000
Normal zone: 256 pages used for memmap
Normal zone: 0 pages reserved
Normal zone: 32512 pages, LIFO batch:7
OMAP3430 ES2.1
SRAM: Mapped pa 0x40200000 to va 0xe3000000 size: 0x100000
Built 1 zonelists in Zone order, mobility grouping on. Total pages: 32512
Kernel command line: console=ttyS2,115200n8 root=/dev/mmcblk0p2 rw
rootdelay=5 omapfb.mode=dvi:1
440x900MR-16@60
Unknown boot option `omapfb.mode=dvi:1440x900MR-16@60': ignoring
PID hash table entries: 512 (order: 9, 2048 bytes)
Dentry cache hash table entries: 16384 (order: 4, 65536 bytes)
Inode-cache hash table entries: 8192 (order: 3, 32768 bytes)
Memory: 128MB = 128MB total
Memory: 126080KB available (3144K code, 296K data, 132K init, 0K highmem)
NR_IRQS:402
Clocking rate (Crystal/Core/MPU): 26.0/332/500 MHz
Reprogramming SDRC clock to 332000000 Hz
GPMC revision 5.0
IRQ: Found an INTC at 0xd8200000 (revision 4.0) with 96 interrupts
Total of 96 interrupts on 1 active controller
OMAP34xx GPIO hardware version 2.5
OMAP clockevent source: GPTIMER12 at 32768 Hz
Console: colour dummy device 80x30
Calibrating delay loop... 316.17 BogoMIPS (lpj=1236992)
Mount-cache hash table entries: 512
CPU: Testing write buffer coherency: ok
regulator: core version 0.5
NET: Registered protocol family 16
Found NAND on CS0
Registering NAND on CS0
OMAP DMA hardware revision 4.0
bio: create slab <bio-0> at 0
i2c_omap i2c_omap.1: bus 1 rev3.12 at 2600 kHz
twl4030: PIH (irq 7) chaining IRQs 368..375
twl4030: power (irq 373) chaining IRQs 376..383
twl4030: gpio (irq 368) chaining IRQs 384..401
regulator: VMMC1: 1850 <--> 3150 mV normal standby
regulator: VDAC: 1800 mV normal standby
regulator: VUSB1V5: 1500 mV normal standby
regulator: VUSB1V8: 1800 mV normal standby
regulator: VUSB3V1: 3100 mV normal standby
regulator: VPLL2: 1800 mV normal standby
regulator: VSIM: 1800 <--> 3000 mV normal standby
i2c_omap i2c_omap.3: bus 3 rev3.12 at 100 kHz
SCSI subsystem initialized
usbcore: registered new interface driver usbfs
usbcore: registered new interface driver hub
usbcore: registered new device driver usb
twl4030_usb twl4030_usb: Initialized TWL4030 USB module
musb_hdrc: version 6.0, musb-dma, otg (peripheral+host), debug=0
musb_hdrc: ConfigData=0xde (UTMI-8, dyn FIFOs, bulk combine (X), bulk
split (X), HB-ISO Rx, HB-I
SO Tx, SoftConn)
musb_hdrc: MHDRC RTL version 1.400
musb_hdrc: setup fifo_mode 4
musb_hdrc: 28/31 max ep, 16384/16384 memory
musb_hdrc: hw_ep 0shared, max 64
musb_hdrc: hw_ep 1tx, max 512
musb_hdrc: hw_ep 1rx, max 512
musb_hdrc: hw_ep 2tx, max 512
musb_hdrc: hw_ep 2rx, max 512
musb_hdrc: hw_ep 3tx, max 512
musb_hdrc: hw_ep 3rx, max 512
musb_hdrc: hw_ep 4tx, max 512
musb_hdrc: hw_ep 4rx, max 512
musb_hdrc: hw_ep 5tx, max 512
musb_hdrc: hw_ep 5rx, max 512
musb_hdrc: hw_ep 6tx, max 512
musb_hdrc: hw_ep 6rx, max 512
musb_hdrc: hw_ep 7tx, max 512
musb_hdrc: hw_ep 7rx, max 512
musb_hdrc: hw_ep 8tx, max 512
musb_hdrc: hw_ep 8rx, max 512
musb_hdrc: hw_ep 9tx, max 512
musb_hdrc: hw_ep 9rx, max 512
musb_hdrc: hw_ep 10tx, max 256
musb_hdrc: hw_ep 10rx, max 64
musb_hdrc: hw_ep 11tx, max 256
musb_hdrc: hw_ep 11rx, max 64
musb_hdrc: hw_ep 12tx, max 256
musb_hdrc: hw_ep 12rx, max 64
musb_hdrc: hw_ep 13shared, max 4096
musb_hdrc: hw_ep 14shared, max 1024
musb_hdrc: hw_ep 15shared, max 1024
musb_hdrc: USB OTG mode controller at d80ab000 using DMA, IRQ 92
NET: Registered protocol family 2
IP route cache hash table entries: 1024 (order: 0, 4096 bytes)
TCP established hash table entries: 4096 (order: 3, 32768 bytes)
TCP bind hash table entries: 4096 (order: 2, 16384 bytes)
TCP: Hash tables configured (established 4096 bind 4096)
TCP reno registered
NET: Registered protocol family 1
NetWinder Floating Point Emulator V0.97 (double precision)
Switched to high resolution mode on CPU 0
VFS: Disk quotas dquot_6.5.2
Dquot-cache hash table entries: 1024 (order 0, 4096 bytes)
JFFS2 version 2.2. (NAND) 侣� 2001-2006 Red Hat, Inc.
msgmni has been set to 246
alg: No test for stdrng (krng)
io scheduler noop registered
io scheduler anticipatory registered (default)
io scheduler deadline registered
io scheduler cfq registered
omapfb: configured for panel omap3beagle
omapfb: DISPC version 3.0 initialized
Console: switching to colour frame buffer device 128x48
omapfb: Framebuffer initialized. Total vram 1572864 planes 1
omapfb: Pixclock 48000 kHz hfreq 44.7 kHz vfreq 57.7 Hz
Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled
serial8250.0: ttyS0 at MMIO 0x4806a000 (irq = 72) is a ST16654
serial8250.1: ttyS1 at MMIO 0x4806c000 (irq = 73) is a ST16654
serial8250.2: ttyS2 at MMIO 0x49020000 (irq = 74) is a ST16654
console [ttyS2] enabled
brd: module loaded
loop: module loaded
i2c /dev entries driver
usbmon: debugfs is not available
ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
ehci-omap ehci-omap.0: OMAP-EHCI Host Controller
ehci-omap ehci-omap.0: new USB bus registered, assigned bus number 1
ehci-omap ehci-omap.0: irq 77, io mem 0x48064800
ehci-omap ehci-omap.0: USB 2.0 started, EHCI 1.00
usb usb1: configuration #1 chosen from 1 choice
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 3 ports detected
g_ether gadget: using random self ethernet address
g_ether gadget: using random host ethernet address
usb0: MAC 36:4b:c8:25:70:04
usb0: HOST MAC e2:1d:b8:ec:4e:2a
g_ether gadget: Ethernet Gadget, version: Memorial Day 2008
g_ether gadget: g_ether ready
musb_hdrc musb_hdrc: MUSB HDRC host driver
musb_hdrc musb_hdrc: new USB bus registered, assigned bus number 2
usb usb2: configuration #1 chosen from 1 choice
hub 2-0:1.0: USB hub found
hub 2-0:1.0: 1 port detected
mmci-omap-hs mmci-omap-hs.0: Failed to get debounce clock
TCP cubic registered
NET: Registered protocol family 17
NET: Registered protocol family 15
RPC: Registered udp transport module.
RPC: Registered tcp transport module.
Power Management for TI OMAP3.
VFP support v0.3: implementor 41 architecture 3 part 30 variant c rev 1
regulator_init_complete: incomplete constraints, leaving VDVI on
regulator_init_complete: incomplete constraints, leaving VDAC on
drivers/rtc/hctosys.c: unable to open rtc device (rtc0)
Waiting 5sec before mounting root device...
mmc0: new SD card at address 0001
mmcblk0: mmc0:0001 064MB 118 MiB
mmcblk0: p1 p2
g_ether gadget: high speed config #1: CDC Ethernet (ECM)
kjournald starting. Commit interval 5 seconds
EXT3-fs warning: maximal mount count reached, running e2fsck is recommended
EXT3 FS on mmcblk0p2, internal journal
EXT3-fs: recovery complete.
EXT3-fs: mounted filesystem with writeback data mode.
VFS: Mounted root (ext3 filesystem) on device 179:2.
Freeing init memory: 132K
--
Lei Ming
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* GPIO driver for MPC8313.
From: Johnny Hung @ 2009-09-23 3:55 UTC (permalink / raw)
To: linuxppc-dev, linux-embedded
Hi All:
Is there a alreday written GPIO dirver or example for
MPC8313/similar ppc platform. It looks like many people need GPIO
dirver to control LED, etc... I think is it possible to write a
general gpio driver for all ppc platform and only need to modify gpio
iomap information of dtb file. Please give me a advice. Thanks in
advanced.
BRs, H. Johnny
^ permalink raw reply
* Re: GPIO driver for MPC8313.
From: Peter Korsgaard @ 2009-09-23 6:57 UTC (permalink / raw)
To: Johnny Hung; +Cc: linuxppc-dev, linux-embedded
In-Reply-To: <cb9ecdfa0909222055x1d691698sb516b5b8f5f81d@mail.gmail.com>
>>>>> "Johnny" == Johnny Hung <johnny.hacking@gmail.com> writes:
Johnny> Hi All:
Johnny> Is there a alreday written GPIO dirver or example for
Johnny> MPC8313/similar ppc platform. It looks like many people need GPIO
Johnny> dirver to control LED, etc... I think is it possible to write a
Johnny> general gpio driver for all ppc platform and only need to modify gpio
Johnny> iomap information of dtb file. Please give me a advice. Thanks in
Johnny> advanced.
Sure, it's arch/powerpc/sysdev/mpc8xxx_gpio.c, included since 2.6.28. To
use it, simply enable CONFIG_MPC8xxx_GPIO and add a gpio-controller node
to your dts, similar to how it's done in
arch/powerpc/boot/dts/mpc837*_rdb.dts.
See Documentation/powerpc/dts-bindings/fsl/8xxx_gpio.txt for details of
the dts bindings.
--
Bye, Peter Korsgaard
^ permalink raw reply
* Re: GPIO driver for MPC8313.
From: Johnny Hung @ 2009-09-23 10:52 UTC (permalink / raw)
To: Peter Korsgaard; +Cc: linuxppc-dev, linux-embedded
In-Reply-To: <87y6o6rvvc.fsf@macbook.be.48ers.dk>
Thanks, got it. BTW, how to trigger GPIO level in user space
application? I also found arch/powerpc/platforms/52xx/mpc52xx_gpio.c
is a good example. Any reply is appreciate.
BRs, H. Johnny
2009/9/23 Peter Korsgaard <jacmet@sunsite.dk>:
>>>>>> "Johnny" == Johnny Hung <johnny.hacking@gmail.com> writes:
>
> Johnny> Hi All:
> Johnny> Is there a alreday written GPIO dirver or example for
> Johnny> MPC8313/similar ppc platform. It looks like many people need GPIO
> Johnny> dirver to control LED, etc... I think is it possible to write a
> Johnny> general gpio driver for all ppc platform and only need to modify gpio
> Johnny> iomap information of dtb file. Please give me a advice. Thanks in
> Johnny> advanced.
>
> Sure, it's arch/powerpc/sysdev/mpc8xxx_gpio.c, included since 2.6.28. To
> use it, simply enable CONFIG_MPC8xxx_GPIO and add a gpio-controller node
> to your dts, similar to how it's done in
> arch/powerpc/boot/dts/mpc837*_rdb.dts.
>
> See Documentation/powerpc/dts-bindings/fsl/8xxx_gpio.txt for details of
> the dts bindings.
>
> --
> Bye, Peter Korsgaard
>
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox