* Re: [PATCH] cleanup for net/tipc/name_distr.c::tipc_named_node_up()
From: Per Liden @ 2006-03-22 9:56 UTC (permalink / raw)
To: Jesper Juhl; +Cc: linux-kernel
In-Reply-To: <200603190045.24176.jesper.juhl@gmail.com>
On Sun, 19 Mar 2006, Jesper Juhl wrote:
> Small cleanup patch for net/tipc/name_distr.c::tipc_named_node_up()
Not sure if you followed the discussion on the tipc mailinglist, so here's
a short summary.
> Patch does the following:
>
> - Change a few pointer assignments from 0 to NULL (makes sparse happy).
Ok.
> - Move a few variable assignment outside the tipc_nametbl_lock lock.
Ok.
> - Make sure to free the allocated buffer before returning so we don't leak.
The additional kfree_skb() looks incorrect. If a buffer if allocated it
will later be released by tipc_link_send().
/Per
^ permalink raw reply
* Re: 2.6.16-rt1
From: Sébastien Dugué @ 2006-03-22 9:59 UTC (permalink / raw)
To: Ingo Molnar, Thomas Gleixner; +Cc: linux-kernel@vger.kernel.org
Hi,
when testing 2.6.16-rt1, I noticed schedule_hrtimer() disappeared from
hrtimer.c. I was exporting and using it for a custom application so I had
to fall back to reimplementing the same functionality where it was needed.
On a more general note, wouldn't it be usefull to have that kind of
function available to the rest of the kernel?
Sébastien.
--
-----------------------------------------------------
Sébastien Dugué BULL/FREC:B1-247
phone: (+33) 476 29 77 70 Bullcom: 229-7770
mailto:sebastien.dugue@bull.net
Linux POSIX AIO: http://www.bullopensource.org/posix
http://sourceforge.net/projects/paiol
-----------------------------------------------------
^ permalink raw reply
* [PATCH] Format tweaks for asciidoc.
From: Francis Daly @ 2006-03-22 9:53 UTC (permalink / raw)
To: git
Some documentation "options" were followed by independent preformatted
paragraphs. Now they are associated plain text paragraphs. The
difference is clear in the generated html.
---
Documentation/git-grep.txt | 14 +++++++-------
Documentation/git-whatchanged.txt | 6 +++---
2 files changed, 10 insertions(+), 10 deletions(-)
b833629d00b95554b23d2239cf8d42262a7a6db6
diff --git a/Documentation/git-grep.txt b/Documentation/git-grep.txt
index fbd2394..d55456a 100644
--- a/Documentation/git-grep.txt
+++ b/Documentation/git-grep.txt
@@ -24,13 +24,13 @@ OPTIONS
<option>...::
Either an option to pass to `grep` or `git-ls-files`.
-
- The following are the specific `git-ls-files` options
- that may be given: `-o`, `--cached`, `--deleted`, `--others`,
- `--killed`, `--ignored`, `--modified`, `--exclude=*`,
- `--exclude-from=*`, and `--exclude-per-directory=*`.
-
- All other options will be passed to `grep`.
++
+The following are the specific `git-ls-files` options
+that may be given: `-o`, `--cached`, `--deleted`, `--others`,
+`--killed`, `--ignored`, `--modified`, `--exclude=\*`,
+`--exclude-from=\*`, and `--exclude-per-directory=\*`.
++
+All other options will be passed to `grep`.
<pattern>::
The pattern to look for. The first non option is taken
diff --git a/Documentation/git-whatchanged.txt b/Documentation/git-whatchanged.txt
index f02f939..641cb7e 100644
--- a/Documentation/git-whatchanged.txt
+++ b/Documentation/git-whatchanged.txt
@@ -47,9 +47,9 @@ OPTIONS
By default, differences for merge commits are not shown.
With this flag, show differences to that commit from all
of its parents.
-
- However, it is not very useful in general, although it
- *is* useful on a file-by-file basis.
++
+However, it is not very useful in general, although it
+*is* useful on a file-by-file basis.
Examples
--------
--
1.2.GIT
--
Francis Daly francis@daoine.org
^ permalink raw reply related
* [patch 1/4 MKII] cpufreq_conservative: aligning of codebase with ondemand
From: Alexander Clouter @ 2006-03-22 9:54 UTC (permalink / raw)
To: cpufreq, linux-kernel; +Cc: venkatesh.pallipadi, linux, akpm
[-- Attachment #1: Type: text/plain, Size: 1112 bytes --]
Since the conservative govenor was released its codebase has drifted from the
the direction and updates that have been applied to the ondemand govornor.
This patch addresses the lack of updates in that period and brings
conservative back up to date. The resulting diff file between
cpufreq_ondemand.c and cpufreq_conservative.c is now much smaller and shows
more clearly the differences between the two.
Another reason to do this is ages ago, knowingly, I did a piss poor attempt
at making conservative less responsive by knocking up
DEF_SAMPLING_RATE_LATENCY_MULTIPLIER by two orders of magnitude. I did fix
this ages ago but in my dis-organisation I must have toasted the diff and
left it the way it was. About two weeks ago a user contacted me saying he
was having problems with the conservative governor with his AMD Athlon XP-M
2800+ as /sys/devices/system/cpu/cpu0/cpufreq/conservative showed
sampling_rate_min 9950000
sampling_rate_max 1360065408
Nine seconds to decide about changing the frequency....not too responsive :)
Signed-off-by: Alexander Clouter <alex-kernel@digriz.org.uk>
[-- Attachment #2: 01_cpufreq-update.diff --]
[-- Type: text/plain, Size: 4631 bytes --]
--- linux-2.6.16/drivers/cpufreq/cpufreq_conservative.c.orig 2006-03-21 21:18:51.539662000 +0000
+++ linux-2.6.16/drivers/cpufreq/cpufreq_conservative.c 2006-03-21 21:26:18.631603500 +0000
@@ -35,12 +35,7 @@
*/
#define DEF_FREQUENCY_UP_THRESHOLD (80)
-#define MIN_FREQUENCY_UP_THRESHOLD (0)
-#define MAX_FREQUENCY_UP_THRESHOLD (100)
-
#define DEF_FREQUENCY_DOWN_THRESHOLD (20)
-#define MIN_FREQUENCY_DOWN_THRESHOLD (0)
-#define MAX_FREQUENCY_DOWN_THRESHOLD (100)
/*
* The polling frequency of this governor depends on the capability of
@@ -53,10 +48,14 @@
* All times here are in uS.
*/
static unsigned int def_sampling_rate;
-#define MIN_SAMPLING_RATE (def_sampling_rate / 2)
+#define MIN_SAMPLING_RATE_RATIO (2)
+/* for correct statistics, we need at least 10 ticks between each measure */
+#define MIN_STAT_SAMPLING_RATE (MIN_SAMPLING_RATE_RATIO * jiffies_to_usecs(10))
+#define MIN_SAMPLING_RATE (def_sampling_rate / MIN_SAMPLING_RATE_RATIO)
#define MAX_SAMPLING_RATE (500 * def_sampling_rate)
-#define DEF_SAMPLING_RATE_LATENCY_MULTIPLIER (100000)
-#define DEF_SAMPLING_DOWN_FACTOR (5)
+#define DEF_SAMPLING_RATE_LATENCY_MULTIPLIER (1000)
+#define DEF_SAMPLING_DOWN_FACTOR (1)
+#define MAX_SAMPLING_DOWN_FACTOR (10)
#define TRANSITION_LATENCY_LIMIT (10 * 1000)
static void do_dbs_timer(void *data);
@@ -136,7 +135,7 @@
unsigned int input;
int ret;
ret = sscanf (buf, "%u", &input);
- if (ret != 1 )
+ if (ret != 1 || input > MAX_SAMPLING_DOWN_FACTOR || input < 1)
return -EINVAL;
mutex_lock(&dbs_mutex);
@@ -173,8 +172,7 @@
ret = sscanf (buf, "%u", &input);
mutex_lock(&dbs_mutex);
- if (ret != 1 || input > MAX_FREQUENCY_UP_THRESHOLD ||
- input < MIN_FREQUENCY_UP_THRESHOLD ||
+ if (ret != 1 || input > 100 || input < 0 ||
input <= dbs_tuners_ins.down_threshold) {
mutex_unlock(&dbs_mutex);
return -EINVAL;
@@ -194,8 +192,7 @@
ret = sscanf (buf, "%u", &input);
mutex_lock(&dbs_mutex);
- if (ret != 1 || input > MAX_FREQUENCY_DOWN_THRESHOLD ||
- input < MIN_FREQUENCY_DOWN_THRESHOLD ||
+ if (ret != 1 || input > 100 || input < 0 ||
input >= dbs_tuners_ins.up_threshold) {
mutex_unlock(&dbs_mutex);
return -EINVAL;
@@ -337,7 +334,6 @@
*/
/* Check for frequency increase */
-
idle_ticks = UINT_MAX;
for_each_cpu_mask(j, policy->cpus) {
unsigned int tmp_idle_ticks, total_idle_ticks;
@@ -357,7 +353,7 @@
/* Scale idle ticks by 100 and compare with up and down ticks */
idle_ticks *= 100;
up_idle_ticks = (100 - dbs_tuners_ins.up_threshold) *
- usecs_to_jiffies(dbs_tuners_ins.sampling_rate);
+ usecs_to_jiffies(dbs_tuners_ins.sampling_rate);
if (idle_ticks < up_idle_ticks) {
down_skip[cpu] = 0;
@@ -398,6 +394,7 @@
struct cpu_dbs_info_s *j_dbs_info;
j_dbs_info = &per_cpu(cpu_dbs_info, j);
+ /* Check for frequency decrease */
total_idle_ticks = j_dbs_info->prev_cpu_idle_up;
tmp_idle_ticks = total_idle_ticks -
j_dbs_info->prev_cpu_idle_down;
@@ -414,12 +411,14 @@
freq_down_sampling_rate = dbs_tuners_ins.sampling_rate *
dbs_tuners_ins.sampling_down_factor;
down_idle_ticks = (100 - dbs_tuners_ins.down_threshold) *
- usecs_to_jiffies(freq_down_sampling_rate);
+ usecs_to_jiffies(freq_down_sampling_rate);
if (idle_ticks > down_idle_ticks) {
- /* if we are already at the lowest speed then break out early
+ /*
+ * if we are already at the lowest speed then break out early
* or if we 'cannot' reduce the speed as the user might want
- * freq_step to be zero */
+ * freq_step to be zero
+ */
if (requested_freq[cpu] == policy->min
|| dbs_tuners_ins.freq_step == 0)
return;
@@ -434,9 +433,8 @@
if (requested_freq[cpu] < policy->min)
requested_freq[cpu] = policy->min;
- __cpufreq_driver_target(policy,
- requested_freq[cpu],
- CPUFREQ_RELATION_H);
+ __cpufreq_driver_target(policy, requested_freq[cpu],
+ CPUFREQ_RELATION_H);
return;
}
}
@@ -507,13 +505,16 @@
if (dbs_enable == 1) {
unsigned int latency;
/* policy latency is in nS. Convert it to uS first */
+ latency = policy->cpuinfo.transition_latency / 1000;
+ if (latency == 0)
+ latency = 1;
- latency = policy->cpuinfo.transition_latency;
- if (latency < 1000)
- latency = 1000;
-
- def_sampling_rate = (latency / 1000) *
+ def_sampling_rate = latency *
DEF_SAMPLING_RATE_LATENCY_MULTIPLIER;
+
+ if (def_sampling_rate < MIN_STAT_SAMPLING_RATE)
+ def_sampling_rate = MIN_STAT_SAMPLING_RATE;
+
dbs_tuners_ins.sampling_rate = def_sampling_rate;
dbs_tuners_ins.ignore_nice = 0;
dbs_tuners_ins.freq_step = 5;
^ permalink raw reply
* [patch 1/4 MKII] cpufreq_conservative: aligning of codebase with ondemand
From: Alexander Clouter @ 2006-03-22 9:54 UTC (permalink / raw)
To: cpufreq, linux-kernel; +Cc: akpm, linux
[-- Attachment #1: Type: text/plain, Size: 1112 bytes --]
Since the conservative govenor was released its codebase has drifted from the
the direction and updates that have been applied to the ondemand govornor.
This patch addresses the lack of updates in that period and brings
conservative back up to date. The resulting diff file between
cpufreq_ondemand.c and cpufreq_conservative.c is now much smaller and shows
more clearly the differences between the two.
Another reason to do this is ages ago, knowingly, I did a piss poor attempt
at making conservative less responsive by knocking up
DEF_SAMPLING_RATE_LATENCY_MULTIPLIER by two orders of magnitude. I did fix
this ages ago but in my dis-organisation I must have toasted the diff and
left it the way it was. About two weeks ago a user contacted me saying he
was having problems with the conservative governor with his AMD Athlon XP-M
2800+ as /sys/devices/system/cpu/cpu0/cpufreq/conservative showed
sampling_rate_min 9950000
sampling_rate_max 1360065408
Nine seconds to decide about changing the frequency....not too responsive :)
Signed-off-by: Alexander Clouter <alex-kernel@digriz.org.uk>
[-- Attachment #2: 01_cpufreq-update.diff --]
[-- Type: text/plain, Size: 4631 bytes --]
--- linux-2.6.16/drivers/cpufreq/cpufreq_conservative.c.orig 2006-03-21 21:18:51.539662000 +0000
+++ linux-2.6.16/drivers/cpufreq/cpufreq_conservative.c 2006-03-21 21:26:18.631603500 +0000
@@ -35,12 +35,7 @@
*/
#define DEF_FREQUENCY_UP_THRESHOLD (80)
-#define MIN_FREQUENCY_UP_THRESHOLD (0)
-#define MAX_FREQUENCY_UP_THRESHOLD (100)
-
#define DEF_FREQUENCY_DOWN_THRESHOLD (20)
-#define MIN_FREQUENCY_DOWN_THRESHOLD (0)
-#define MAX_FREQUENCY_DOWN_THRESHOLD (100)
/*
* The polling frequency of this governor depends on the capability of
@@ -53,10 +48,14 @@
* All times here are in uS.
*/
static unsigned int def_sampling_rate;
-#define MIN_SAMPLING_RATE (def_sampling_rate / 2)
+#define MIN_SAMPLING_RATE_RATIO (2)
+/* for correct statistics, we need at least 10 ticks between each measure */
+#define MIN_STAT_SAMPLING_RATE (MIN_SAMPLING_RATE_RATIO * jiffies_to_usecs(10))
+#define MIN_SAMPLING_RATE (def_sampling_rate / MIN_SAMPLING_RATE_RATIO)
#define MAX_SAMPLING_RATE (500 * def_sampling_rate)
-#define DEF_SAMPLING_RATE_LATENCY_MULTIPLIER (100000)
-#define DEF_SAMPLING_DOWN_FACTOR (5)
+#define DEF_SAMPLING_RATE_LATENCY_MULTIPLIER (1000)
+#define DEF_SAMPLING_DOWN_FACTOR (1)
+#define MAX_SAMPLING_DOWN_FACTOR (10)
#define TRANSITION_LATENCY_LIMIT (10 * 1000)
static void do_dbs_timer(void *data);
@@ -136,7 +135,7 @@
unsigned int input;
int ret;
ret = sscanf (buf, "%u", &input);
- if (ret != 1 )
+ if (ret != 1 || input > MAX_SAMPLING_DOWN_FACTOR || input < 1)
return -EINVAL;
mutex_lock(&dbs_mutex);
@@ -173,8 +172,7 @@
ret = sscanf (buf, "%u", &input);
mutex_lock(&dbs_mutex);
- if (ret != 1 || input > MAX_FREQUENCY_UP_THRESHOLD ||
- input < MIN_FREQUENCY_UP_THRESHOLD ||
+ if (ret != 1 || input > 100 || input < 0 ||
input <= dbs_tuners_ins.down_threshold) {
mutex_unlock(&dbs_mutex);
return -EINVAL;
@@ -194,8 +192,7 @@
ret = sscanf (buf, "%u", &input);
mutex_lock(&dbs_mutex);
- if (ret != 1 || input > MAX_FREQUENCY_DOWN_THRESHOLD ||
- input < MIN_FREQUENCY_DOWN_THRESHOLD ||
+ if (ret != 1 || input > 100 || input < 0 ||
input >= dbs_tuners_ins.up_threshold) {
mutex_unlock(&dbs_mutex);
return -EINVAL;
@@ -337,7 +334,6 @@
*/
/* Check for frequency increase */
-
idle_ticks = UINT_MAX;
for_each_cpu_mask(j, policy->cpus) {
unsigned int tmp_idle_ticks, total_idle_ticks;
@@ -357,7 +353,7 @@
/* Scale idle ticks by 100 and compare with up and down ticks */
idle_ticks *= 100;
up_idle_ticks = (100 - dbs_tuners_ins.up_threshold) *
- usecs_to_jiffies(dbs_tuners_ins.sampling_rate);
+ usecs_to_jiffies(dbs_tuners_ins.sampling_rate);
if (idle_ticks < up_idle_ticks) {
down_skip[cpu] = 0;
@@ -398,6 +394,7 @@
struct cpu_dbs_info_s *j_dbs_info;
j_dbs_info = &per_cpu(cpu_dbs_info, j);
+ /* Check for frequency decrease */
total_idle_ticks = j_dbs_info->prev_cpu_idle_up;
tmp_idle_ticks = total_idle_ticks -
j_dbs_info->prev_cpu_idle_down;
@@ -414,12 +411,14 @@
freq_down_sampling_rate = dbs_tuners_ins.sampling_rate *
dbs_tuners_ins.sampling_down_factor;
down_idle_ticks = (100 - dbs_tuners_ins.down_threshold) *
- usecs_to_jiffies(freq_down_sampling_rate);
+ usecs_to_jiffies(freq_down_sampling_rate);
if (idle_ticks > down_idle_ticks) {
- /* if we are already at the lowest speed then break out early
+ /*
+ * if we are already at the lowest speed then break out early
* or if we 'cannot' reduce the speed as the user might want
- * freq_step to be zero */
+ * freq_step to be zero
+ */
if (requested_freq[cpu] == policy->min
|| dbs_tuners_ins.freq_step == 0)
return;
@@ -434,9 +433,8 @@
if (requested_freq[cpu] < policy->min)
requested_freq[cpu] = policy->min;
- __cpufreq_driver_target(policy,
- requested_freq[cpu],
- CPUFREQ_RELATION_H);
+ __cpufreq_driver_target(policy, requested_freq[cpu],
+ CPUFREQ_RELATION_H);
return;
}
}
@@ -507,13 +505,16 @@
if (dbs_enable == 1) {
unsigned int latency;
/* policy latency is in nS. Convert it to uS first */
+ latency = policy->cpuinfo.transition_latency / 1000;
+ if (latency == 0)
+ latency = 1;
- latency = policy->cpuinfo.transition_latency;
- if (latency < 1000)
- latency = 1000;
-
- def_sampling_rate = (latency / 1000) *
+ def_sampling_rate = latency *
DEF_SAMPLING_RATE_LATENCY_MULTIPLIER;
+
+ if (def_sampling_rate < MIN_STAT_SAMPLING_RATE)
+ def_sampling_rate = MIN_STAT_SAMPLING_RATE;
+
dbs_tuners_ins.sampling_rate = def_sampling_rate;
dbs_tuners_ins.ignore_nice = 0;
dbs_tuners_ins.freq_step = 5;
[-- Attachment #3: Type: text/plain, Size: 147 bytes --]
_______________________________________________
Cpufreq mailing list
Cpufreq@lists.linux.org.uk
http://lists.linux.org.uk/mailman/listinfo/cpufreq
^ permalink raw reply
* Re: [PATCH/RFC] Linux MTD striping middle layer
From: Artem B. Bityutskiy @ 2006-03-22 9:52 UTC (permalink / raw)
To: Alexander Belyakov; +Cc: Korolev, Alexey, linux-mtd, Kutergin, Timofey
In-Reply-To: <44211B5F.2030200@intel.com>
Alexander Belyakov wrote:
> At the stage of writing CONFIG_CMDLINE (mtdpart and mtdstripe parts)
> user generally do not know what mtd device number will be assigned to
> each partition. Using names IMO is a better solution if mtdstripe is a
> built-in module since user gives and uses partition names by himself.
>
> Using /proc/mtd and stripe mtd device by number (your suggestion) can be
> quite good for loadable from command line mtdstripe.ko module. But using
> two different configuration methods for built-in and loadable module can
> be quite confusing for user.
But still, for example, if I want to use mtdram device, it is named
"mtdram test device", and using this name as a parameter of mtdstripe.ko
looks insane.
> Suggested algorithm supports striping for devices with different
> erasesize. In that (quite uncommon) case erasesize of superdevice is not
> just erasesize of subdevice multiplied by number of subdevices.
Oh, this is interesting. You didn't mention this in the first mail,
right? You said that flashes must be the same...
So, If I have 2 flash chips, with eraseblock size X and Y, X < Y, I
still can stripe them? Well, fair enough. Am I right that you just merge
eraseblocks of the second chip to make the resulting "merged" eraseblock
not less then Y? E.g., you use N eraseblock of chip 2 for each
eraseblock of chip 1, where N = [X/Y] + 1, right?
--
Best Regards,
Artem B. Bityutskiy,
St.-Petersburg, Russia.
^ permalink raw reply
* MTD/JFFS 2 support NAND MLC (Multi Level Cell)
From: Domenico MANNA @ 2006-03-22 9:44 UTC (permalink / raw)
To: linux-mtd
Hello,
I hope this is the right address for post a question, if no, could you indicate me the right address, please ?
I would know if which version of MTD support the NAND MLC (Multi Level Cell)memory.
thank for your time.
Domenico M.
^ permalink raw reply
* [PATCH 4/4] PCIERR-IA64 : interfaces for synchronous I/O error detection
From: Hidetoshi Seto @ 2006-03-22 9:49 UTC (permalink / raw)
To: linux-ia64
This patch is 4/4 of PCIERR implementation for IA64.
This part defines ia64_mca_barrier.
This barrier makes sure that the passed value is poisoned or not.
It can say that this will work as light-version of PAL_MC_DRAIN.
Please refer the comment in patch to get more detail.
Signed-off-by: Hidetoshi Seto <seto.hidetoshi@jp.fujitsu.com>
-----
arch/ia64/kernel/mca.c | 4 +
arch/ia64/kernel/mca_asm.S | 30 +++++++++++++
include/asm-ia64/io.h | 98 +++++++++++++++++++++++++++++++++++++++++++++
3 files changed, 132 insertions(+)
Index: linux-2.6.16_WORK/arch/ia64/kernel/mca.c
=================================--- linux-2.6.16_WORK.orig/arch/ia64/kernel/mca.c 2006-03-22 14:43:31.000000000 +0900
+++ linux-2.6.16_WORK/arch/ia64/kernel/mca.c 2006-03-22 14:43:35.000000000 +0900
@@ -103,6 +103,10 @@
/* In mca_asm.S */
extern void ia64_os_init_dispatch_monarch (void);
extern void ia64_os_init_dispatch_slave (void);
+#ifdef CONFIG_PCIERR_CHECK
+extern void ia64_mca_barrier (unsigned long value);
+EXPORT_SYMBOL(ia64_mca_barrier);
+#endif
static int monarch_cpu = -1;
Index: linux-2.6.16_WORK/arch/ia64/kernel/mca_asm.S
=================================--- linux-2.6.16_WORK.orig/arch/ia64/kernel/mca_asm.S 2006-03-22 14:43:31.000000000 +0900
+++ linux-2.6.16_WORK/arch/ia64/kernel/mca_asm.S 2006-03-22 14:44:03.000000000 +0900
@@ -19,6 +19,9 @@
// 12/08/05 Keith Owens <kaos@sgi.com>
// Use per cpu MCA/INIT stacks for all data.
//
+// 06/03/22 Hidetoshi Seto <seto.hidetoshi@jp.fujitsu.com>
+// Added ia64_mca_barrier.
+//
#include <linux/config.h>
#include <linux/threads.h>
@@ -39,6 +42,7 @@
.global ia64_os_mca_dispatch
.global ia64_os_init_dispatch_monarch
.global ia64_os_init_dispatch_slave
+ .global ia64_mca_barrier
.text
.align 16
@@ -413,6 +417,32 @@
//EndMain//////////////////////////////////////////////////////////////////////
+//StartMain////////////////////////////////////////////////////////////////////
+
+//
+// ia64_mca_barrier:
+//
+// Some chipset may poison the data read, instead of signaling a BERR.
+// The consummation of poisoned data triggers a MCA, which tells us the
+// polluted address.
+// Note that the read operation by itself does not consume the bad data,
+// so we have to do something with it before it is too late.
+//
+// Calling this function forces a consumption of the passed value since
+// the compiler will have to copy it from whatever register it was in to
+// an "out" register to pass to the function.
+// To avoid possible optimization by compiler, and to make doubly sure,
+// this assenbly clearly consumes the value by moving it to r8.
+//
+// In this way, the value is guaranteed secure, not poisoned, and sanity.
+//
+
+ia64_mca_barrier:
+ mov r8=r32
+ br.ret.sptk.many rp
+
+//EndMain//////////////////////////////////////////////////////////////////////
+
// common defines for the stubs
#define ms r4
#define regs r5
Index: linux-2.6.16_WORK/include/asm-ia64/io.h
=================================--- linux-2.6.16_WORK.orig/include/asm-ia64/io.h 2006-03-22 14:43:31.000000000 +0900
+++ linux-2.6.16_WORK/include/asm-ia64/io.h 2006-03-22 14:43:35.000000000 +0900
@@ -165,6 +165,51 @@
* during optimization, which is why we use "volatile" pointers.
*/
+#ifdef CONFIG_PCIERR_CHECK
+
+extern void ia64_mca_barrier(unsigned long value);
+
+static inline unsigned int
+___ia64_inb (unsigned long port)
+{
+ volatile unsigned char *addr = __ia64_mk_io_addr(port);
+ unsigned char ret;
+
+ ret = *addr;
+ __ia64_mf_a();
+ ia64_mca_barrier(ret);
+
+ return ret;
+}
+
+static inline unsigned int
+___ia64_inw (unsigned long port)
+{
+ volatile unsigned short *addr = __ia64_mk_io_addr(port);
+ unsigned short ret;
+
+ ret = *addr;
+ __ia64_mf_a();
+ ia64_mca_barrier(ret);
+
+ return ret;
+}
+
+static inline unsigned int
+___ia64_inl (unsigned long port)
+{
+ volatile unsigned int *addr = __ia64_mk_io_addr(port);
+ unsigned int ret;
+
+ ret = *addr;
+ __ia64_mf_a();
+ ia64_mca_barrier(ret);
+
+ return ret;
+}
+
+#else /* CONFIG_PCIERR_CHECK */
+
static inline unsigned int
___ia64_inb (unsigned long port)
{
@@ -198,6 +243,8 @@
return ret;
}
+#endif /* CONFIG_PCIERR_CHECK */
+
static inline void
___ia64_outb (unsigned char val, unsigned long port)
{
@@ -314,6 +361,55 @@
* a good idea). Writes are ok though for all existing ia64 platforms (and
* hopefully it'll stay that way).
*/
+
+#ifdef CONFIG_PCIERR_CHECK
+
+static inline unsigned char
+___ia64_readb (const volatile void __iomem *addr)
+{
+ unsigned char val;
+
+ val = *(volatile unsigned char __force *)addr;
+ ia64_mca_barrier(val);
+
+ return val;
+}
+
+static inline unsigned short
+___ia64_readw (const volatile void __iomem *addr)
+{
+ unsigned short val;
+
+ val = *(volatile unsigned short __force *)addr;
+ ia64_mca_barrier(val);
+
+ return val;
+}
+
+static inline unsigned int
+___ia64_readl (const volatile void __iomem *addr)
+{
+ unsigned int val;
+
+ val = *(volatile unsigned int __force *) addr;
+ ia64_mca_barrier(val);
+
+ return val;
+}
+
+static inline unsigned long
+___ia64_readq (const volatile void __iomem *addr)
+{
+ unsigned long val;
+
+ val = *(volatile unsigned long __force *) addr;
+ ia64_mca_barrier(val);
+
+ return val;
+}
+
+#else /* CONFIG_PCIERR_CHECK */
+
static inline unsigned char
___ia64_readb (const volatile void __iomem *addr)
{
@@ -338,6 +434,8 @@
return *(volatile unsigned long __force *) addr;
}
+#endif /* CONFIG_PCIERR_CHECK */
+
static inline void
__writeb (unsigned char val, volatile void __iomem *addr)
{
^ permalink raw reply
* Warning: fetch updated the current branch head.
From: Junio C Hamano @ 2006-03-22 9:48 UTC (permalink / raw)
To: git
I was helping somebody who:
* had a clone of git.git repository;
* had "next" checked out a week or so ago;
* did not have any development on his own;
* tried to pull using the default .git/remotes/origin from me.
Somehow the index was out of sync before that pull but there was
no change in the working tree (i.e. just the cached stat was
different), and it refused to fast-forward the index and the
working tree, because if there _were_ real changes in the
working tree, they would have been lost by a fast-forward.
This patch will be in "next" and does two things:
* runs "git update-index --refresh" before the fast-forwarding,
to prevent stat-only difference from interfering;
* if there really is a local change in the working tree, show
the original branch head information in the message, to allow
the user to decide what to do next.
The first one would have made his working tree to fast-forward
correctly. If the fast-forward is still prevented, that means
there really was a change, and in such a case, the way to recover
would be:
* Examine "git diff $orig_head" output, to make sure there is
no local change since the last pull. If there is none, you
can run "git reset --hard" (you do not have to name "next",
because that is the branch you are already on) and you are
done.
* If there are local changes, stash them away as a patch,
"git reset --hard" and re-apply if they are precious.
I've considered rewinding the tracking branch to match
$orig_head in such a case just before "die", but that would be a
disservice to people behind a narrow pipe -- it would require
them to re-download the objects to update the branch.
I now realize that the "die" message is a bit confusing, after
writing the above recovery procedure. Especially, the new
"git-update-index --refresh" would say "foo: needs update", but
"update your working tree" does not mean "git update-index foo"
after such a failure. Maybe this phrasing is better:
die 'Cannot fast-forward your working tree.
After making sure that you saved anything precious from
$ git diff '$orig_head'
output, and run
$ git reset --hard
to recover.'
Opinions?
-- >8 --
[PATCH] git-pull: further safety while on tracking branch.
Running 'git pull' while on the tracking branch has a built-in
safety valve to fast-forward the index and working tree to match
the branch head, but it errs on the safe side too cautiously.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
git-pull.sh | 4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
cf46e7b8999f25d5d7f2acd64701a100e403ee03
diff --git a/git-pull.sh b/git-pull.sh
index 29c14e1..d90f7c9 100755
--- a/git-pull.sh
+++ b/git-pull.sh
@@ -55,7 +55,9 @@ then
# First update the working tree to match $curr_head.
echo >&2 "Warning: fetch updated the current branch head."
- echo >&2 "Warning: fast forwarding your working tree."
+ echo >&2 "Warning: fast forwarding your working tree from"
+ echo >&2 "Warning: $orig_head commit."
+ git-update-index --refresh 2>/dev/null
git-read-tree -u -m "$orig_head" "$curr_head" ||
die "You need to first update your working tree."
fi
--
1.2.4.gfd45
^ permalink raw reply related
* [PATCH 3/4] PCIERR-IA64 : interfaces for synchronous I/O error detection
From: Hidetoshi Seto @ 2006-03-22 9:46 UTC (permalink / raw)
To: linux-ia64
This patch is 3/4 of PCIERR implementation for IA64.
This part describes modifies in mca_drv.
If MCA happens and the error address was in resource of registered
RAS-aware driver, mca_drv notify the error to the driver and
restart the system. Soon notified driver will do its recovery.
Signed-off-by: Hidetoshi Seto <seto.hidetoshi@jp.fujitsu.com>
-----
arch/ia64/kernel/mca_drv.c | 81 +++++++++++++++++++++++++++++++++++++++++++
arch/ia64/lib/pcierr_check.c | 1
2 files changed, 82 insertions(+)
Index: linux-2.6.16_WORK/arch/ia64/kernel/mca_drv.c
=================================--- linux-2.6.16_WORK.orig/arch/ia64/kernel/mca_drv.c 2006-03-22 14:27:04.000000000 +0900
+++ linux-2.6.16_WORK/arch/ia64/kernel/mca_drv.c 2006-03-22 14:41:04.000000000 +0900
@@ -37,6 +37,11 @@
#include "mca_drv.h"
+#ifdef CONFIG_PCIERR_CHECK
+#include <linux/pci.h>
+extern struct list_head pcierr_list;
+#endif
+
/* max size of SAL error record (default) */
static int sal_rec_max = 10000;
@@ -399,6 +404,76 @@
return MCA_IS_GLOBAL;
}
+#ifdef CONFIG_PCIERR_CHECK
+
+/**
+ * get_target_identifier - get address of target_identifier
+ * @peidx: pointer of index of processor error section
+ *
+ * Return value:
+ * addr if valid / 0 if not valid
+ */
+static u64 get_target_identifier(peidx_table_t *peidx)
+{
+ sal_log_mod_error_info_t *smei;
+
+ smei = peidx_bus_check(peidx, 0);
+ if (smei->valid.target_identifier)
+ return (smei->target_identifier);
+ return 0;
+}
+
+#define isMEM64(resource) \
+(((resource).flags & (PCI_BASE_ADDRESS_SPACE|PCI_BASE_ADDRESS_MEM_TYPE_MASK)) \
+ = (PCI_BASE_ADDRESS_SPACE_MEMORY|PCI_BASE_ADDRESS_MEM_TYPE_64))
+
+/**
+ * pcierr_recovery - Check if MCA occur on transaction in pcierr_list.
+ * @peidx: pointer of index of processor error section
+ *
+ * Return value:
+ * 1 if error could be caught in driver / 0 if not
+ */
+static int pcierr_recovery(peidx_table_t *peidx)
+{
+ u64 addr;
+ int i, loop = 0;
+ struct pci_dev *tdev;
+ iocookie *cookie;
+
+ if (list_empty(&pcierr_list))
+ return 0;
+
+ addr = get_target_identifier(peidx);
+ if (!addr)
+ return 0;
+
+ list_for_each_entry(cookie, &pcierr_list, list) {
+ /* MCA is non-maskable, be careful */
+ if (loop++ > 1024 || !cookie)
+ break;
+ /* double check */
+ if (pcierr_list.next = cookie->list.next)
+ break;
+ tdev = cookie->dev;
+ if (!tdev)
+ continue;
+ for (i = 0; i < PCI_ROM_RESOURCE; i++) {
+ if (tdev->resource[i].start <= addr
+ && addr <= tdev->resource[i].end) {
+ cookie->error = 1;
+ return 1;
+ }
+ if (isMEM64(tdev->resource[i]))
+ i++;
+ }
+ }
+
+ return 0;
+}
+
+#endif /* CONFIG_PCIERR_CHECK */
+
/**
* recover_from_read_error - Try to recover the errors which type are "read"s.
* @slidx: pointer of index of SAL error record
@@ -473,6 +548,12 @@
}
+#ifdef CONFIG_PCIERR_CHECK
+ /* Are there any RAS-aware drivers? */
+ if (pcierr_recovery(peidx))
+ return 1;
+#endif
+
return 0;
}
Index: linux-2.6.16_WORK/arch/ia64/lib/pcierr_check.c
=================================--- linux-2.6.16_WORK.orig/arch/ia64/lib/pcierr_check.c 2006-03-22 14:41:03.000000000 +0900
+++ linux-2.6.16_WORK/arch/ia64/lib/pcierr_check.c 2006-03-22 14:41:04.000000000 +0900
@@ -68,5 +68,6 @@
return 0;
}
+EXPORT_SYMBOL(pcierr_list); /* for MCA driver */
EXPORT_SYMBOL(pcierr_read);
EXPORT_SYMBOL(pcierr_clear);
^ permalink raw reply
* Re: [RFC PATCH 04/35] Hypervisor interface header files.
From: Arjan van de Ven @ 2006-03-22 9:46 UTC (permalink / raw)
To: Keir Fraser
Cc: virtualization, Ian Pratt, xen-devel, linux-kernel, Chris Wright
In-Reply-To: <0ffa39bba1c9a708536286f4bb80d605@cl.cam.ac.uk>
On Wed, 2006-03-22 at 09:31 +0000, Keir Fraser wrote:
> On 22 Mar 2006, at 08:28, Arjan van de Ven wrote:
>
> >> + * This file may be distributed separately from the Linux kernel, or
> >> + * incorporated into other software packages, subject to the
> >> following license:
> >> + *
> >
> > and what, if any, is the license when distributed with the kernel, as
> > you propose? Right now there doesn't seem to be any at all, and thus it
> > would be undistributable.
>
> I thought GPLv2 would be implicit.
implicit license == bad :)
^ permalink raw reply
* [PATCH 2/4] PCIERR-IA64 : interfaces for synchronous I/O error detection
From: Hidetoshi Seto @ 2006-03-22 9:45 UTC (permalink / raw)
To: linux-ia64
This patch is 2/4 of PCIERR implementation for IA64.
This part describes base of IA64-specific PCIERR, registering
driver and checking status.
Signed-off-by: Hidetoshi Seto <seto.hidetoshi@jp.fujitsu.com>
-----
arch/ia64/lib/pcierr_check.c | 53 +++++++++++++++++++++++++++++++++++++++++--
include/asm-ia64/pci.h | 4 ++-
2 files changed, 54 insertions(+), 3 deletions(-)
Index: linux-2.6.16_WORK/arch/ia64/lib/pcierr_check.c
=================================--- linux-2.6.16_WORK.orig/arch/ia64/lib/pcierr_check.c 2006-03-22 14:41:02.000000000 +0900
+++ linux-2.6.16_WORK/arch/ia64/lib/pcierr_check.c 2006-03-22 14:41:03.000000000 +0900
@@ -8,14 +8,63 @@
void pcierr_clear(iocookie *cookie, struct pci_dev *dev);
int pcierr_read(iocookie *cookie);
+LIST_HEAD(pcierr_list); /* all iocookies are listed in this */
+DEFINE_SPINLOCK(pcierr_lock); /* to protect list above */
+
+static int have_error(struct pci_dev *dev);
+
void pcierr_clear(iocookie *cookie, struct pci_dev *dev)
{
- /* register device etc. */
+ unsigned long flag;
+
+ INIT_LIST_HEAD(&(cookie->list));
+
+ cookie->dev = dev;
+
+ spin_lock_irqsave(&pcierr_lock, flag);
+ list_add(&cookie->list, &pcierr_list);
+ spin_unlock_irqrestore(&pcierr_lock, flag);
+
+ cookie->error = 0;
}
int pcierr_read(iocookie *cookie)
{
- /* check error etc. */
+ unsigned long flag;
+ int ret = 0;
+
+ spin_lock_irqsave(&pcierr_lock, flag);
+ if (cookie->error || have_error(cookie->dev))
+ ret = 1;
+ list_del(&cookie->list);
+ spin_unlock_irqrestore(&pcierr_lock, flag);
+
+ return ret;
+}
+
+static int have_error(struct pci_dev *dev)
+{
+ u16 status;
+
+ /* check status */
+ switch (dev->hdr_type) {
+ case PCI_HEADER_TYPE_NORMAL: /* 0 */
+ pci_read_config_word(dev, PCI_STATUS, &status);
+ break;
+ case PCI_HEADER_TYPE_BRIDGE: /* 1 */
+ pci_read_config_word(dev, PCI_SEC_STATUS, &status);
+ break;
+ case PCI_HEADER_TYPE_CARDBUS: /* 2 */
+ return 0; /* FIX ME */
+ default:
+ BUG();
+ }
+
+ if ( (status & PCI_STATUS_REC_TARGET_ABORT)
+ || (status & PCI_STATUS_REC_MASTER_ABORT)
+ || (status & PCI_STATUS_DETECTED_PARITY) )
+ return 1;
+
return 0;
}
Index: linux-2.6.16_WORK/include/asm-ia64/pci.h
=================================--- linux-2.6.16_WORK.orig/include/asm-ia64/pci.h 2006-03-22 14:41:02.000000000 +0900
+++ linux-2.6.16_WORK/include/asm-ia64/pci.h 2006-03-22 14:41:03.000000000 +0900
@@ -175,7 +175,9 @@
/* Enable ia64 pcierr - See arch/ia64/lib/pcierr_check.c */
#define HAVE_ARCH_PCIERR_CHECK
typedef struct {
- int dummy;
+ struct list_head list;
+ struct pci_dev *dev; /* target device */
+ unsigned long error; /* error flag */
} iocookie;
#endif /* CONFIG_PCIERR_CHECK */
^ permalink raw reply
* [PATCH 1/4] PCIERR-IA64 : interfaces for synchronous I/O error detection
From: Hidetoshi Seto @ 2006-03-22 9:44 UTC (permalink / raw)
To: linux-ia64
This patch is 1/4 of PCIERR implementation for IA64.
This part enable us to switch IA64-specific PCIERR by config.
Signed-off-by: Hidetoshi Seto <seto.hidetoshi@jp.fujitsu.com>
-----
arch/ia64/Kconfig | 10 ++++++++++
arch/ia64/lib/Makefile | 1 +
arch/ia64/lib/pcierr_check.c | 23 +++++++++++++++++++++++
include/asm-ia64/pci.h | 8 ++++++++
4 files changed, 42 insertions(+)
Index: linux-2.6.16_WORK/arch/ia64/Kconfig
=================================--- linux-2.6.16_WORK.orig/arch/ia64/Kconfig 2006-03-22 14:27:04.000000000 +0900
+++ linux-2.6.16_WORK/arch/ia64/Kconfig 2006-03-22 14:41:02.000000000 +0900
@@ -410,6 +410,16 @@
bool
default PCI
+config PCIERR_CHECK
+ bool "Support pcierr interfaces for IO error detection."
+ depends on PCI
+ help
+ Saying Y provides pcierr infrastructure for "RAS-aware" drivers
+ to detect and recover some IO errors, which strongly required by
+ some of very-high-reliable systems.
+
+ If you don't know what to do here, say N.
+
source "drivers/pci/Kconfig"
source "drivers/pci/hotplug/Kconfig"
Index: linux-2.6.16_WORK/arch/ia64/lib/Makefile
=================================--- linux-2.6.16_WORK.orig/arch/ia64/lib/Makefile 2006-03-22 14:27:04.000000000 +0900
+++ linux-2.6.16_WORK/arch/ia64/lib/Makefile 2006-03-22 14:41:02.000000000 +0900
@@ -15,6 +15,7 @@
lib-$(CONFIG_MCKINLEY) += copy_page_mck.o memcpy_mck.o
lib-$(CONFIG_PERFMON) += carta_random.o
lib-$(CONFIG_MD_RAID5) += xor.o
+lib-$(CONFIG_PCIERR_CHECK) += pcierr_check.o
AFLAGS___divdi3.o AFLAGS___udivdi3.o = -DUNSIGNED
Index: linux-2.6.16_WORK/include/asm-ia64/pci.h
=================================--- linux-2.6.16_WORK.orig/include/asm-ia64/pci.h 2006-03-22 14:27:04.000000000 +0900
+++ linux-2.6.16_WORK/include/asm-ia64/pci.h 2006-03-22 14:41:02.000000000 +0900
@@ -171,4 +171,12 @@
#define pcibios_scan_all_fns(a, b) 0
+#ifdef CONFIG_PCIERR_CHECK
+/* Enable ia64 pcierr - See arch/ia64/lib/pcierr_check.c */
+#define HAVE_ARCH_PCIERR_CHECK
+typedef struct {
+ int dummy;
+} iocookie;
+#endif /* CONFIG_PCIERR_CHECK */
+
#endif /* _ASM_IA64_PCI_H */
Index: linux-2.6.16_WORK/arch/ia64/lib/pcierr_check.c
=================================--- /dev/null 1970-01-01 00:00:00.000000000 +0000
+++ linux-2.6.16_WORK/arch/ia64/lib/pcierr_check.c 2006-03-22 14:41:02.000000000 +0900
@@ -0,0 +1,23 @@
+/*
+ * File: pcierr_check.c
+ * Purpose: Implement the IA64 specific pcierr interfaces for RAS-drivers
+ */
+
+#include <linux/pci.h>
+
+void pcierr_clear(iocookie *cookie, struct pci_dev *dev);
+int pcierr_read(iocookie *cookie);
+
+void pcierr_clear(iocookie *cookie, struct pci_dev *dev)
+{
+ /* register device etc. */
+}
+
+int pcierr_read(iocookie *cookie)
+{
+ /* check error etc. */
+ return 0;
+}
+
+EXPORT_SYMBOL(pcierr_read);
+EXPORT_SYMBOL(pcierr_clear);
^ permalink raw reply
* Re: CE Linux Forum PM Requierments WiKi is available for review and comment.
From: Pavel Machek @ 2006-03-22 9:41 UTC (permalink / raw)
To: Gross, Mark; +Cc: linux-pm, PMWG, mli_tech, celinux-dev
In-Reply-To: <5389061B65D50446B1783B97DFDB392D2042B3@orsmsx411.amr.corp.intel.com>
[-- Attachment #1: Type: text/plain, Size: 1761 bytes --]
Hi!
> >Hmm, okay, yes, that would be useful for machines that can't do
> >throttling in hardware.
>
> Even platforms that can throttle in hardware, it could make sense for to
> throttle the OS.
Well, certainly. If you want to throttle to 1% and hardware can only
throttle to 30%, you need to do it in software.
> I think a person may want to throttle what work a laptop is doing as a
> function of being tethered or remaining battery life. If all you want
> to do is finish those last few edits to a file before your battery cuts
> you off for the rest of a long flight, you will be very willing to shut
> down most (all?) processing that's not related to what you are editing.
> Cron jobs, automatic spell checking, sound subsystems, screen savers,
> pretty much anything not related to your editing will pull down your
> battery. Most of these can be shut down from user mode, some things may
> be easier to implement robustly with some kernel support.
That will be userland parts, I'd say.
> One idea is to extend the SCHED_BATCH idea to know about power state to
> avoid running some things when un-tethered or under low battery
> conditions.
Idle thread with realtime priority could do parts of what you want.
> >> >Thanks, Sharp!
> >>
> >> Who the heck is Sharp, and why do you always thank him?
> >
> >That's a signature... Sharp is Japaneese firm, maybe you've heard
> >about them :-). Send me handheld computer, and that line becomes
> >"Thanks, Intel" ;-).
>
> Oh! Ok, that makes sense. BTW careful what you wish for....
Well, I currently have collie (sharp sl-5500) for hacking, and spitz
(c-3000) for normal use. I would not mind hacking on something not as
obsolete.
Pavel
--
Picture of sleeping (Linux) penguin wanted...
[-- Attachment #2: Type: text/plain, Size: 0 bytes --]
^ permalink raw reply
* Re: ac3 in/out
From: Johannes Berg @ 2006-03-22 9:41 UTC (permalink / raw)
To: Takashi Iwai; +Cc: Lee Revell, ALSA devel
In-Reply-To: <s5hbqvzzlss.wl%tiwai@suse.de>
[-- Attachment #1: Type: text/plain, Size: 1156 bytes --]
On Tue, 2006-03-21 at 19:37 +0100, Takashi Iwai wrote:
> The SPDIF status bits are generic and rather depending on the data
> than the device you output. That is, more or less, the SPDIF I/O is
> abstracted.
Are you talking about alsa or spdif itself?
> Regarding AC3, I'm not against to create a new easy-to-use API
> function. One reason is that AC3 over SPDIF needs conversions of
> packets and also requires the sync work, in addition to the SPDIF
> status bits mentioned in the above. Such a job can be certainly
> hidden in the system instead of application itself.
Yes, but apparently some hardware is capable of doing the conversion
(the chip apple uses for example: pcm3052, download data sheet for
pcm3052a if you're interested, it's the same chip)
On the other hand, some other chips seem to rely on software to
multiplex the channel status bits into the bitstream which is currently
done by userspace as far as I can tell.
> If we create a new one, we should better think of other compressed
> formats, too...
They're essentially the same to the spdif output though -- just a
non-pcm bitstream.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 793 bytes --]
^ permalink raw reply
* Re: [PATCH/RFC] Linux MTD striping middle layer
From: Alexander Belyakov @ 2006-03-22 9:39 UTC (permalink / raw)
To: dedekind; +Cc: Korolev, Alexey, linux-mtd, Kutergin, Timofey
In-Reply-To: <1142967444.13740.9.camel@sauron.oktetlabs.ru>
Artem,
>> Subdevices are mtd devices which participate in creation of striped mtd
>> device (superdevice). vol1, vol2 here are the names of subdevices
>> assigned on partitioning stage (for example) by the following part of
>> kernel configuration string:
>> CONFIG_CMDLINE="..........
>> mtdparts=flash1:512k(blob)ro,2m(kernel)ro,16m(root),16m(vol1);flash2:16m(vol2),8m(vol3)
>> ........."
>>
> IMO, it is better to use MTD device numbers. 0 = mtd0, 1 = mtd1, etc. I
> can always glance at /proc/mtd and realize which numbers to use. Names
> may contain white spaces, or whatever inappropriate characters one may
> conceive, right?
>
At the stage of writing CONFIG_CMDLINE (mtdpart and mtdstripe parts)
user generally do not know what mtd device number will be assigned to
each partition. Using names IMO is a better solution if mtdstripe is a
built-in module since user gives and uses partition names by himself.
Using /proc/mtd and stripe mtd device by number (your suggestion) can be
quite good for loadable from command line mtdstripe.ko module. But using
two different configuration methods for built-in and loadable module can
be quite confusing for user.
>>> 4. I erase eraseblock 0 of mtd7
>>>
>> In simple case eraseblock 0 on both subdevices 1 and 2 will be erased
>>
> I see. Why did you say "In simple case" ?
Suggested algorithm supports striping for devices with different
erasesize. In that (quite uncommon) case erasesize of superdevice is not
just erasesize of subdevice multiplied by number of subdevices.
Thanks,
Alexander Belyakov
^ permalink raw reply
* Re: More detailed Acer (Intel HDA)
From: Lee Revell @ 2006-03-22 9:38 UTC (permalink / raw)
To: Rimas Kudelis; +Cc: ALSA devel, Jonathan Woithe
In-Reply-To: <44210F4D.8070508@akl.lt>
On Wed, 2006-03-22 at 10:48 +0200, Rimas Kudelis wrote:
> Hi,
> >>>> On these Acer laptops the evidence thus far indicates that there is no
> >>>> audio connection between the CD drive and the sound card.
> >>>>
> >>> I haven't seen any evidence at all, just speculation, apparently no one
> >>> is willing to try Windows to verify this. Until there's some evidence
> >>> IMHO the CD control should stay.
> >>>
> >> The fact is that the CD control doesn't work now. And I didn't manage to
> >> find a way to make any control in the test model influence CD playback
> >> volume. Why would you want a non-working control to stay?
> >>
> > Because it may work on some other laptops, and it's better for people to
> > be able to test it.
> >
> It may or may not work. And people can still use the test model for testing.
>
Yes exactly, and a missing control is much worse than a control that
does nothing.
There just needs to be some shred of evidence beyond my speculation
about the CD pins not being connected before controls are removed from a
driver.
Lee
-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
^ permalink raw reply
* Re: [rfc] separate sharpsl_pm initialization from sysfs code
From: Pavel Machek @ 2006-03-22 9:37 UTC (permalink / raw)
To: Richard Purdie, kernel list, lenz
In-Reply-To: <20060313000231.GA6555@flint.arm.linux.org.uk>
Hi!
> > /* Register interrupt handler. */
> > if ((err = request_irq(COLLIE_IRQ_GPIO_AC_IN, sharpsl_ac_isr, SA_INTERRUPT,
> > "ACIN", sharpsl_ac_isr))) {
> > printk("Could not get irq %d.\n", COLLIE_IRQ_GPIO_AC_IN);
> > return;
> > }
> > if ((err = request_irq(COLLIE_IRQ_GPIO_CO, sharpsl_chrg_full_isr, SA_INTERRUPT,
> > "CO", sharpsl_chrg_full_isr))) {
> > free_irq(COLLIE_IRQ_GPIO_AC_IN, sharpsl_ac_isr);
> > printk("Could not get irq %d.\n", COLLIE_IRQ_GPIO_CO);
> > return;
> > }
>
> Shouldn't these be ucb1x00_hook_irq()'s?
>
> Shouldn't you only enable the ADC when you need to use it?
Yes, I should.
> This driver makes no calls to ucb1x00_enable() and ucb1x00_disable().
> They're part of power management, and if your driver doesn't appear to
> require them to work, that means some other code is buggy (or you're
> keeping the ADC always enabled.)
Keeping ADC always enabled, which interferes with touchscreen,
badly. This fixes it, and allows touchscreen and battery to coexist.
(I'll clean it up and properly submit).
Pavel
Enable/disable adc as needed. Now battery and touchscreen code seems
to cooperate.
---
commit 4907317f98c84569eb6c3d9c24b5b177fe60981b
tree 2998b0eebdd138b56740575d98f02e1cecaf4c34
parent e89a9fd829a3cd639f93ec0291251f6a99916226
author <pavel@amd.ucw.cz> Wed, 22 Mar 2006 10:22:10 +0100
committer <pavel@amd.ucw.cz> Wed, 22 Mar 2006 10:22:10 +0100
arch/arm/mach-sa1100/collie_pm.c | 8 +++++++-
drivers/mfd/ucb1x00-ts.c | 4 +++-
2 files changed, 10 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-sa1100/collie_pm.c b/arch/arm/mach-sa1100/collie_pm.c
index 1618ade..6a9f833 100644
--- a/arch/arm/mach-sa1100/collie_pm.c
+++ b/arch/arm/mach-sa1100/collie_pm.c
@@ -70,7 +70,6 @@ static void collie_charger_init(void)
ucb1x00_enable_irq(ucb, COLLIE_GPIO_AC_IN, UCB_RISING);
ucb1x00_enable_irq(ucb, COLLIE_GPIO_CO, UCB_RISING);
- ucb1x00_adc_enable(ucb);
ucb1x00_io_set_dir(ucb, 0, COLLIE_TC35143_GPIO_MBAT_ON | COLLIE_TC35143_GPIO_TMP_ON |
COLLIE_TC35143_GPIO_BBAT_ON);
return;
@@ -139,11 +138,14 @@ int collie_read_backup_battery(void)
{
int voltage;
+ ucb1x00_adc_enable(ucb);
+
/* Gives 75..130 */
ucb1x00_io_write(ucb, COLLIE_TC35143_GPIO_BBAT_ON, 0);
voltage = ucb1x00_adc_read(ucb, UCB_ADC_INP_AD1, UCB_SYNC);
ucb1x00_io_write(ucb, 0, COLLIE_TC35143_GPIO_BBAT_ON);
+ ucb1x00_adc_disable(ucb);
printk("Backup battery = %d(%d)\n", ADCtoPower(voltage), voltage);
@@ -158,6 +160,7 @@ int collie_read_main_battery(void)
collie_read_temp();
collie_read_backup_battery();
#endif
+ ucb1x00_adc_enable(ucb);
ucb1x00_io_write(ucb, 0, COLLIE_TC35143_GPIO_BBAT_ON);
ucb1x00_io_write(ucb, COLLIE_TC35143_GPIO_MBAT_ON, 0);
voltage = ucb1x00_adc_read(ucb, UCB_ADC_INP_AD1, UCB_SYNC);
@@ -170,6 +173,7 @@ int collie_read_main_battery(void)
On battery, it goes as low as 80.
*/
+ ucb1x00_adc_disable(ucb);
voltage_rev = voltage + ((ad_revise * voltage) / 652);
voltage_volts = ADCtoPower(voltage_rev);
@@ -190,9 +194,11 @@ int collie_read_temp(void)
/* temp must be > 973, main battery must be < 465 */
/* FIXME sharpsl_pm.c has both conditions negated? */
+ ucb1x00_adc_enable(ucb);
ucb1x00_io_write(ucb, COLLIE_TC35143_GPIO_TMP_ON, 0);
voltage = ucb1x00_adc_read(ucb, UCB_ADC_INP_AD0, UCB_SYNC);
ucb1x00_io_write(ucb, 0, COLLIE_TC35143_GPIO_TMP_ON);
+ ucb1x00_adc_disable(ucb);
/* >1010 = battery removed.
460 = 22C ?
--
Picture of sleeping (Linux) penguin wanted...
^ permalink raw reply related
* Re: [PATCH/RFC] Linux MTD striping middle layer
From: Alexander Belyakov @ 2006-03-22 9:36 UTC (permalink / raw)
To: Vitaly Wool; +Cc: Korolev, Alexey, linux-mtd, Kutergin, Timofey
In-Reply-To: <442017B0.4010508@ru.mvista.com>
Vitaly,
>
> What PREEMPT_ modes did you test it with?
Why do you think enabling preemptible kernel option will help to switch
two or more kernel threads with equal priority? And anyway preemptible
kernel option is an experimental one and someone willing to use striping
may not want to use it.
>
> The implementation itself seems to be quite inmature and leaves a lot
> of questions - starting from what command-line parameters do mean and
> ending up with how it's supposed to work in a workload environment,
> given the threads etc. etc. Maybe it slows down the performance of the
> whole system, even though it does speed up the block erase.
It is RFC and everything can be explained or changed.
Considering command line parameters. Suggested solution can be
configured by two ways. First applies if mtdstripe.ko is a standalone
module and user uses insmod to insert it - good for debug, etc. Second
is for solid kernel where striping is configured from kernel
configuration string. Please find some clarifications in reply to
Artem's message.
In our experience striping does not affect much overall system performance.
And not only erase speed increases due to striping, but write speed too.
Thanks,
Alexander Belyakov
^ permalink raw reply
* Re: More detailed Acer (Intel HDA)
From: Lee Revell @ 2006-03-22 9:37 UTC (permalink / raw)
To: Rimas Kudelis; +Cc: ALSA devel, Jonathan Woithe
In-Reply-To: <44210F4D.8070508@akl.lt>
On Wed, 2006-03-22 at 10:48 +0200, Rimas Kudelis wrote:
> OTOH, I just remembered I know one guy who has windows (hopefully,
> XP)
> on a similar notebook. Maybe he'll test it, if I catch him online.
> What
> app should he use for that?
I don't know, anything that lets you play CDs in analog mode.
-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
^ permalink raw reply
* new sound driver
From: Johannes Berg @ 2006-03-22 9:35 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Alastair Poole
[-- Attachment #1: Type: text/plain, Size: 4478 bytes --]
Hi,
After considering the code a while I decided that snd-powermac needs to
be rewritten. Ok, kidding, I didn't need to look at the source for
long :)
So I started to rewrite snd-powermac as snd-aoa, which I currently keep
in a git tree at http://johannes.sipsolutions.net/snd-aoa.git/
I will need a bit of help, so this email is intended to solicit that,
and to get some input on what everyone else thinks about what I've been
doing in that code.
Let me start with a brief layout. To those I've talked about this
before: please read again -- I significantly changed what I'm doing.
Since Ben says that he wants to be able to handle really old stuff with
the new driver too, I first created a virtual 'soundbus'. This is in the
module 'soundbus', and doesn't yet have any functionality in itself but
providing the driver model bus object.
I then created an i2sbus module that grabs all i2s devices from the
macio bus, enumerates their children (i2s-a, i2s-b etc) and adds them to
the soundbus.
Obviously, we'll need to add more bus backends there.
Now enter snd-aoa: snd-aoa has a rather generic architecture where the
core just initialises plugin code for different ways to find sound codec
chips. Currently, only one way is implemented -- that is going off the
layout-id property. This part (snd-aoa-fabric-layout.c) is a soundbus
driver and attaches to all soundbus nodes that have a 'sound' child with
a 'layout-id' property that it knows about. The list is encoded in
snd-aoa-layouts.c.
Plan is to make the fabrics and the codecs into modules too, but this
isn't done at the moment. Shouldn't be too hard, and should probably be
done before writing any more fabrics or codecs.
Anyway, back to what happens. Now the fabric module detects a layout-id
that it can handle, so it then goes to instantiate the codecs. Right now
I only have an onyx codec there. It tries to attach to the i2c control
interface (using two methods, but for that refer to the code). Then the
codec creates the alsa mixer devices that it can handle, using some alsa
helper code (snd-aoa-alsa) that manages the alsa card object.
That's about it. It can mute/unmute and control the left/right volume,
so it might work if you use both this and snd-powermac...
I had planned to actually get sound output working last night, but that
didn't turn out since I ended up rewriting all the lower levels.
So let me just say what the immediate plan is:
Firstly, the soundbus objects need to be able to handle data
transmission. What I'm not too sure about is how the API should look
like. I'm thinking that since all objects there are actually sound
objects (well, there's the modem too, but it can get an alsa interface
too), the soundbus objects actually get to create the alsa pcm
interfaces, somehow helped by the codecs to select the valid rates and
formats. Or the codecs create the alsa pcm streams, but refer to
soundbus object functions for handling the actual data transfer. I'd
like to push as much of the interface into the soundbus object as
possible. At this point also the question of how to program the dbdma
engine best comes up. I really don't know, because I don't quite
understand the alsa pcm api.
In any case, I'm thinking of putting dbdma register stuff into the
soundbus module and adding dbdma data to struct soundbus_dev.
Actually, this isn't quite possible. On the newer machines where you
have two codecs on the same i2s bus, we need to have the layout fabric
create the one pcm stream and have it ask the codecs what it should
advertise. Then it needs to advertise the lowest common denominator of
the multiple codecs... (Or can alsa handle pcms that change their
supported rates/formats?) Then it refers to the soundbus functions for
actual data transmission.
Another thing that needs to be done is teach the layout-id fabric module
how to handle all the dozens of platform functions and publish those to
alsa that make sense to be set by the user (like line out select etc.).
Then also register the interrupt ones and handle them appropriately. The
codecs will need to be notified on changes/interrupts though, since in
some cases things need to be switched around there too. This is just a
matter of inventing the right way to find all of the functions...
Whee. I was going to write more but for one it is already long enough,
and I also forgot what I wanted to write :)
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 793 bytes --]
^ permalink raw reply
* Re: SubmittingPatches typo
From: 祁勇 @ 2006-03-22 9:32 UTC (permalink / raw)
To: Alan Cox
Cc: J. Bruce Fields, Matheus Izvekov, Jan Engelhardt, Pavel Machek,
kernel list
In-Reply-To: <1142939779.21455.43.camel@localhost.localdomain>
Alan Cox wrote:
>>Nope. It's actually one of the amusing places where there *is* no rule.
>>Plurals that end in s always get just the apostrophe. But for singular
>>nouns that end in s, while I tend to think of "'s" as the default, some
>>people like to drop the final s if the result ("Sophocles's") would
>>otherwise sound awkward spoken aloud.
>>
>>
>
>The definitive references have this to say
>
>US English: Strunk and White says it should be "Torvalds's" and that the
>apostrophe alone is used only for ancient particularly biblical names
>ending in -es/is (eg Moses' laws)
>
>
akpm is already saying "Linus's" in his *mm-commits*:
This patch was probably dropped from -mm because
it has already been merged into a subsystem tree
or into Linus's tree
(btw, when Americans made mistakes, their English became American English.)
>UK English: The Oxford Guide To Style says
>
>"Use 's after non-classical or non-classicizing personal names ending
>with an s or z sound). It also says that Torvalds' would be acceptable.
>
>
>So both agree that
>
> Torvalds's
>
>is correct and that would appear to be the right choice to keep everyone
>both sides of the pond happy.
>
>Jan: Care to submit an updated patch as the original is indeed wrong ?
>
>Alan
>
>-
>To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>the body of a message to majordomo@vger.kernel.org
>More majordomo info at http://vger.kernel.org/majordomo-info.html
>Please read the FAQ at http://www.tux.org/lkml/
>
>
>
>
^ permalink raw reply
* Re: [RFC PATCH 14/35] subarch modify CPU capabilities
From: Keir Fraser @ 2006-03-22 9:33 UTC (permalink / raw)
To: Zachary Amsden
Cc: Chris Wright, virtualization, xen-devel, linux-kernel, Ian Pratt
In-Reply-To: <44210C4B.7050307@vmware.com>
On 22 Mar 2006, at 08:35, Zachary Amsden wrote:
> That's pretty heinous. Suppose Xen decides to start supporting any of
> these features. Now, you need to change all of the Xen modified
> kernels to remove pieces of this.
Well, old kernels would still work and most of those features aren't
all that useful in a virtualised environment anyway. But, point taken,
adding a hypervisor trap for CPUID and making use of it would clean up
that code.
-- Keir
^ permalink raw reply
* Re: [Xen-devel] [RFC PATCH 14/35] subarch modify CPU capabilities
From: Keir Fraser @ 2006-03-22 9:33 UTC (permalink / raw)
To: Zachary Amsden
Cc: virtualization, Ian Pratt, xen-devel, linux-kernel, Chris Wright
In-Reply-To: <44210C4B.7050307@vmware.com>
On 22 Mar 2006, at 08:35, Zachary Amsden wrote:
> That's pretty heinous. Suppose Xen decides to start supporting any of
> these features. Now, you need to change all of the Xen modified
> kernels to remove pieces of this.
Well, old kernels would still work and most of those features aren't
all that useful in a virtualised environment anyway. But, point taken,
adding a hypervisor trap for CPUID and making use of it would clean up
that code.
-- Keir
^ permalink raw reply
* Re: [RFC PATCH 04/35] Hypervisor interface header files.
From: Keir Fraser @ 2006-03-22 9:31 UTC (permalink / raw)
To: Arjan van de Ven
Cc: Chris Wright, virtualization, xen-devel, linux-kernel, Ian Pratt
In-Reply-To: <1143016080.2955.7.camel@laptopd505.fenrus.org>
On 22 Mar 2006, at 08:28, Arjan van de Ven wrote:
>> + * This file may be distributed separately from the Linux kernel, or
>> + * incorporated into other software packages, subject to the
>> following license:
>> + *
>
> and what, if any, is the license when distributed with the kernel, as
> you propose? Right now there doesn't seem to be any at all, and thus it
> would be undistributable.
I thought GPLv2 would be implicit. I'll add the short GPL stanza to
each of the offending source files.
Thanks for your other excellent comments by the way.
-- Keir
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.