* Re: [PATCH] powerpc: Fix loss of interrupts with MPIC (#2)
From: Benjamin Herrenschmidt @ 2006-07-05 5:36 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev list, Linus Torvalds, Linux Kernel list
In-Reply-To: <1152076021.17790.10.camel@localhost.localdomain>
And here's the right version of the patch, pls drop the other one,
sorry....
With the new interrupt rework, an interrupt "host" map() callback can be
called after the interrupt is already active (it's called again for an
already mapped interrupt to allow changing the trigger
setup, and currently this is not guarded with a test of wether the
interrupt is requested or not, I plan to change some of this logic to be
a bit less lenient against random reconfiguring of live
interrupts but just not yet). The ported MPIC driver has a bug where
when that happens, it will mask the interrupt. This changes it to
preserve the previous masking of the interrupt instead.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
---
Linus: It would be nice if that could still sneak into -rc1 as it causes
hangs and other bad issues on PowerMac.
Index: linux-irq-work/arch/powerpc/sysdev/mpic.c
===================================================================
--- linux-irq-work.orig/arch/powerpc/sysdev/mpic.c 2006-07-05 14:46:11.000000000 +1000
+++ linux-irq-work/arch/powerpc/sysdev/mpic.c 2006-07-05 15:34:50.000000000 +1000
@@ -405,20 +405,22 @@
unsigned int loops = 100000;
struct mpic *mpic = mpic_from_irq(irq);
unsigned int src = mpic_irq_to_hw(irq);
+ unsigned long flags;
DBG("%p: %s: enable_irq: %d (src %d)\n", mpic, mpic->name, irq, src);
+ spin_lock_irqsave(&mpic_lock, flags);
mpic_irq_write(src, MPIC_IRQ_VECTOR_PRI,
mpic_irq_read(src, MPIC_IRQ_VECTOR_PRI) &
~MPIC_VECPRI_MASK);
-
/* make sure mask gets to controller before we return to user */
do {
if (!loops--) {
printk(KERN_ERR "mpic_enable_irq timeout\n");
break;
}
- } while(mpic_irq_read(src, MPIC_IRQ_VECTOR_PRI) & MPIC_VECPRI_MASK);
+ } while(mpic_irq_read(src, MPIC_IRQ_VECTOR_PRI) & MPIC_VECPRI_MASK);
+ spin_unlock_irqrestore(&mpic_lock, flags);
}
static void mpic_mask_irq(unsigned int irq)
@@ -426,9 +428,11 @@
unsigned int loops = 100000;
struct mpic *mpic = mpic_from_irq(irq);
unsigned int src = mpic_irq_to_hw(irq);
+ unsigned long flags;
DBG("%s: disable_irq: %d (src %d)\n", mpic->name, irq, src);
+ spin_lock_irqsave(&mpic_lock, flags);
mpic_irq_write(src, MPIC_IRQ_VECTOR_PRI,
mpic_irq_read(src, MPIC_IRQ_VECTOR_PRI) |
MPIC_VECPRI_MASK);
@@ -440,6 +444,7 @@
break;
}
} while(!(mpic_irq_read(src, MPIC_IRQ_VECTOR_PRI) & MPIC_VECPRI_MASK));
+ spin_unlock_irqrestore(&mpic_lock, flags);
}
static void mpic_end_irq(unsigned int irq)
@@ -624,9 +629,10 @@
struct irq_desc *desc = get_irq_desc(virq);
struct irq_chip *chip;
struct mpic *mpic = h->host_data;
- unsigned int vecpri = MPIC_VECPRI_SENSE_LEVEL |
+ u32 v, vecpri = MPIC_VECPRI_SENSE_LEVEL |
MPIC_VECPRI_POLARITY_NEGATIVE;
int level;
+ unsigned long iflags;
pr_debug("mpic: map virq %d, hwirq 0x%lx, flags: 0x%x\n",
virq, hw, flags);
@@ -668,11 +674,21 @@
}
#endif
- /* Reconfigure irq */
- vecpri |= MPIC_VECPRI_MASK | hw | (8 << MPIC_VECPRI_PRIORITY_SHIFT);
- mpic_irq_write(hw, MPIC_IRQ_VECTOR_PRI, vecpri);
+ /* Reconfigure irq. We must preserve the mask bit as we can be called
+ * while the interrupt is still active (This may change in the future
+ * but for now, it is the case).
+ */
+ spin_lock_irqsave(&mpic_lock, iflags);
+ v = mpic_irq_read(hw, MPIC_IRQ_VECTOR_PRI);
+ vecpri = (v &
+ ~(MPIC_VECPRI_POLARITY_MASK | MPIC_VECPRI_SENSE_MASK)) |
+ vecpri;
+ if (vecpri != v)
+ mpic_irq_write(hw, MPIC_IRQ_VECTOR_PRI, vecpri);
+ spin_unlock_irqrestore(&mpic_lock, iflags);
- pr_debug("mpic: mapping as IRQ\n");
+ pr_debug("mpic: mapping as IRQ, vecpri = 0x%08x (was 0x%08x)\n",
+ vecpri, v);
set_irq_chip_data(virq, mpic);
set_irq_chip_and_handler(virq, chip, handle_fasteoi_irq);
@@ -904,8 +920,8 @@
/* do senses munging */
if (mpic->senses && i < mpic->senses_count)
- vecpri = mpic_flags_to_vecpri(mpic->senses[i],
- &level);
+ vecpri |= mpic_flags_to_vecpri(mpic->senses[i],
+ &level);
else
vecpri |= MPIC_VECPRI_SENSE_LEVEL;
@@ -955,14 +971,17 @@
void __init mpic_set_serial_int(struct mpic *mpic, int enable)
{
+ unsigned long flags;
u32 v;
+ spin_lock_irqsave(&mpic_lock, flags);
v = mpic_read(mpic->gregs, MPIC_GREG_GLOBAL_CONF_1);
if (enable)
v |= MPIC_GREG_GLOBAL_CONF_1_SIE;
else
v &= ~MPIC_GREG_GLOBAL_CONF_1_SIE;
mpic_write(mpic->gregs, MPIC_GREG_GLOBAL_CONF_1, v);
+ spin_unlock_irqrestore(&mpic_lock, flags);
}
void mpic_irq_set_priority(unsigned int irq, unsigned int pri)
^ permalink raw reply
* [PATCH] powerpc: Fix loss of interrupts with MPIC
From: Benjamin Herrenschmidt @ 2006-07-05 5:07 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev list, Linus Torvalds, Linux Kernel list
With the new interrupt rework, an interrupt "host" map() callback can be
called after the interrupt is already active (it's called again for an
already mapped interrupt to allow changing the trigger
setup, and currently this is not guarded with a test of wether the
interrupt is requested or not, I plan to change some of this logic to be
a bit less lenient against random reconfiguring of live
interrupts but just not yet). The ported MPIC driver has a bug where
when that happens, it will mask the interrupt. This changes it to
preserve the previous masking of the interrupt instead.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
---
Linus: It would be nice if that could still sneak into -rc1 as it causes
hangs and other bad issues on PowerMac.
Index: linux-irq-work/arch/powerpc/sysdev/mpic.c
===================================================================
--- linux-irq-work.orig/arch/powerpc/sysdev/mpic.c 2006-07-05 14:46:11.000000000 +1000
+++ linux-irq-work/arch/powerpc/sysdev/mpic.c 2006-07-05 15:00:48.000000000 +1000
@@ -405,20 +405,22 @@
unsigned int loops = 100000;
struct mpic *mpic = mpic_from_irq(irq);
unsigned int src = mpic_irq_to_hw(irq);
+ unsigned long flags;
DBG("%p: %s: enable_irq: %d (src %d)\n", mpic, mpic->name, irq, src);
+ spin_lock_irqsave(&mpic_lock, flags);
mpic_irq_write(src, MPIC_IRQ_VECTOR_PRI,
mpic_irq_read(src, MPIC_IRQ_VECTOR_PRI) &
~MPIC_VECPRI_MASK);
-
/* make sure mask gets to controller before we return to user */
do {
if (!loops--) {
printk(KERN_ERR "mpic_enable_irq timeout\n");
break;
}
- } while(mpic_irq_read(src, MPIC_IRQ_VECTOR_PRI) & MPIC_VECPRI_MASK);
+ } while(mpic_irq_read(src, MPIC_IRQ_VECTOR_PRI) & MPIC_VECPRI_MASK);
+ spin_unlock_irqrestore(&mpic_lock, flags);
}
static void mpic_mask_irq(unsigned int irq)
@@ -426,9 +428,11 @@
unsigned int loops = 100000;
struct mpic *mpic = mpic_from_irq(irq);
unsigned int src = mpic_irq_to_hw(irq);
+ unsigned long flags;
DBG("%s: disable_irq: %d (src %d)\n", mpic->name, irq, src);
+ spin_lock_irqsave(&mpic_lock, flags);
mpic_irq_write(src, MPIC_IRQ_VECTOR_PRI,
mpic_irq_read(src, MPIC_IRQ_VECTOR_PRI) |
MPIC_VECPRI_MASK);
@@ -440,6 +444,7 @@
break;
}
} while(!(mpic_irq_read(src, MPIC_IRQ_VECTOR_PRI) & MPIC_VECPRI_MASK));
+ spin_unlock_irqrestore(&mpic_lock, flags);
}
static void mpic_end_irq(unsigned int irq)
@@ -624,7 +629,7 @@
struct irq_desc *desc = get_irq_desc(virq);
struct irq_chip *chip;
struct mpic *mpic = h->host_data;
- unsigned int vecpri = MPIC_VECPRI_SENSE_LEVEL |
+ u32 v, vecpri = MPIC_VECPRI_SENSE_LEVEL |
MPIC_VECPRI_POLARITY_NEGATIVE;
int level;
@@ -668,11 +673,21 @@
}
#endif
- /* Reconfigure irq */
- vecpri |= MPIC_VECPRI_MASK | hw | (8 << MPIC_VECPRI_PRIORITY_SHIFT);
- mpic_irq_write(hw, MPIC_IRQ_VECTOR_PRI, vecpri);
+ /* Reconfigure irq. We must preserve the mask bit as we can be called
+ * while the interrupt is still active (This may change in the future
+ * but for now, it is the case).
+ */
+ spin_lock_irqsave(&mpic_lock, flags);
+ v = mpic_irq_read(hw, MPIC_IRQ_VECTOR_PRI);
+ vecpri = (v &
+ ~(MPIC_VECPRI_POLARITY_MASK | MPIC_VECPRI_SENSE_MASK)) |
+ vecpri;
+ if (vecpri != v)
+ mpic_irq_write(hw, MPIC_IRQ_VECTOR_PRI, vecpri);
+ spin_unlock_irqrestore(&mpic_lock, flags);
- pr_debug("mpic: mapping as IRQ\n");
+ pr_debug("mpic: mapping as IRQ, vecpri = 0x%08x (was 0x%08x)\n",
+ vecpri, v);
set_irq_chip_data(virq, mpic);
set_irq_chip_and_handler(virq, chip, handle_fasteoi_irq);
@@ -904,8 +919,8 @@
/* do senses munging */
if (mpic->senses && i < mpic->senses_count)
- vecpri = mpic_flags_to_vecpri(mpic->senses[i],
- &level);
+ vecpri |= mpic_flags_to_vecpri(mpic->senses[i],
+ &level);
else
vecpri |= MPIC_VECPRI_SENSE_LEVEL;
@@ -955,14 +970,17 @@
void __init mpic_set_serial_int(struct mpic *mpic, int enable)
{
+ unsigned long flags;
u32 v;
+ spin_lock_irqsave(&mpic_lock, flags);
v = mpic_read(mpic->gregs, MPIC_GREG_GLOBAL_CONF_1);
if (enable)
v |= MPIC_GREG_GLOBAL_CONF_1_SIE;
else
v &= ~MPIC_GREG_GLOBAL_CONF_1_SIE;
mpic_write(mpic->gregs, MPIC_GREG_GLOBAL_CONF_1, v);
+ spin_unlock_irqrestore(&mpic_lock, flags);
}
void mpic_irq_set_priority(unsigned int irq, unsigned int pri)
^ permalink raw reply
* Re: [PATCH 13/20] [powerpc, video & agp] Constify & voidify get_property()
From: Paul Mackerras @ 2006-07-05 4:56 UTC (permalink / raw)
To: Dave Jones; +Cc: linuxppc-dev, davej
In-Reply-To: <20060704190054.GA20952@redhat.com>
Dave Jones writes:
> I assume this stuff is going in through the ppc tree?
Yes, I'll take care of it. Once Linus releases -rc1 I'll start
pushing the for-2.6.19 patches (including these) to the master branch
of the powerpc.git tree.
Paul.
^ permalink raw reply
* [RFC/PATCH 2/2] Make crash.c work on 32-bit and 64-bit
From: Michael Ellerman @ 2006-07-05 4:39 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
In-Reply-To: <1152074382.592260.383409859049.qpush@concordia>
To compile kexec on 32-bit we need a few more bits and pieces. Rather
than add empty definitions, we can make crash.c work on 32-bit, with
only a couple of kludges.
Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
---
arch/powerpc/kernel/Makefile | 4 ++--
arch/powerpc/kernel/crash.c | 11 +++++++++++
arch/powerpc/kernel/machine_kexec_64.c | 1 -
arch/powerpc/kernel/traps.c | 3 ---
include/asm-powerpc/kexec.h | 3 +--
5 files changed, 14 insertions(+), 8 deletions(-)
Index: to-merge/arch/powerpc/kernel/Makefile
===================================================================
--- to-merge.orig/arch/powerpc/kernel/Makefile
+++ to-merge/arch/powerpc/kernel/Makefile
@@ -67,9 +67,9 @@ pci64-$(CONFIG_PPC64) += pci_64.o pci_d
pci_direct_iommu.o iomap.o
pci32-$(CONFIG_PPC32) := pci_32.o
obj-$(CONFIG_PCI) += $(pci64-y) $(pci32-y)
-kexec-$(CONFIG_PPC64) := machine_kexec_64.o crash.o
+kexec-$(CONFIG_PPC64) := machine_kexec_64.o
kexec-$(CONFIG_PPC32) := machine_kexec_32.o
-obj-$(CONFIG_KEXEC) += machine_kexec.o $(kexec-y)
+obj-$(CONFIG_KEXEC) += machine_kexec.o crash.o $(kexec-y)
ifeq ($(CONFIG_PPC_ISERIES),y)
$(obj)/head_64.o: $(obj)/lparmap.s
Index: to-merge/arch/powerpc/kernel/crash.c
===================================================================
--- to-merge.orig/arch/powerpc/kernel/crash.c
+++ to-merge/arch/powerpc/kernel/crash.c
@@ -44,6 +44,7 @@
/* This keeps a track of which one is crashing cpu. */
int crashing_cpu = -1;
static cpumask_t cpus_in_crash = CPU_MASK_NONE;
+cpumask_t cpus_in_sr = CPU_MASK_NONE;
static u32 *append_elf_note(u32 *buf, char *name, unsigned type, void *data,
size_t data_len)
@@ -139,7 +140,13 @@ void crash_ipi_callback(struct pt_regs *
if (ppc_md.kexec_cpu_down)
ppc_md.kexec_cpu_down(1, 1);
+
+#ifdef CONFIG_PPC64
kexec_smp_wait();
+#else
+ for (;;); /* FIXME */
+#endif
+
/* NOTREACHED */
}
@@ -255,7 +262,11 @@ static void crash_kexec_prepare_cpus(int
*
* do this if kexec in setup.c ?
*/
+#ifdef CONFIG_PPC64
smp_release_cpus();
+#else
+ /* FIXME */
+#endif
}
void crash_kexec_secondary(struct pt_regs *regs)
Index: to-merge/arch/powerpc/kernel/machine_kexec_64.c
===================================================================
--- to-merge.orig/arch/powerpc/kernel/machine_kexec_64.c
+++ to-merge/arch/powerpc/kernel/machine_kexec_64.c
@@ -10,7 +10,6 @@
*/
-#include <linux/cpumask.h>
#include <linux/kexec.h>
#include <linux/smp.h>
#include <linux/thread_info.h>
Index: to-merge/arch/powerpc/kernel/traps.c
===================================================================
--- to-merge.orig/arch/powerpc/kernel/traps.c
+++ to-merge/arch/powerpc/kernel/traps.c
@@ -55,9 +55,6 @@
#ifdef CONFIG_PPC64 /* XXX */
#define _IO_BASE pci_io_base
-#ifdef CONFIG_KEXEC
-cpumask_t cpus_in_sr = CPU_MASK_NONE;
-#endif
#endif
#ifdef CONFIG_DEBUGGER
Index: to-merge/include/asm-powerpc/kexec.h
===================================================================
--- to-merge.orig/include/asm-powerpc/kexec.h
+++ to-merge/include/asm-powerpc/kexec.h
@@ -32,6 +32,7 @@
#endif
#ifndef __ASSEMBLY__
+#include <linux/cpumask.h>
#ifdef CONFIG_KEXEC
@@ -109,7 +110,6 @@ static inline void crash_setup_regs(stru
#define MAX_NOTE_BYTES 1024
-#ifdef __powerpc64__
extern void kexec_smp_wait(void); /* get and clear naca physid, wait for
master to copy new code to 0 */
extern int crashing_cpu;
@@ -119,7 +119,6 @@ static inline int kexec_sr_activated(int
{
return cpu_isset(cpu,cpus_in_sr);
}
-#endif /* __powerpc64 __ */
struct kimage;
struct pt_regs;
^ permalink raw reply
* [RFC/PATCH 1/2] Move some kexec logic into machine_kexec.c
From: Michael Ellerman @ 2006-07-05 4:39 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
We're missing a few functions for kexec to compile on 32-bit. There's
nothing really 64-bit specific about the 64-bit versions, so make them
generic rather than adding empty definitions for 32-bit.
Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
---
arch/powerpc/kernel/machine_kexec.c | 56 +++++++++++++++++++++++++++++++++
arch/powerpc/kernel/machine_kexec_64.c | 56 ---------------------------------
2 files changed, 56 insertions(+), 56 deletions(-)
Index: to-merge/arch/powerpc/kernel/machine_kexec.c
===================================================================
--- to-merge.orig/arch/powerpc/kernel/machine_kexec.c
+++ to-merge/arch/powerpc/kernel/machine_kexec.c
@@ -13,6 +13,7 @@
#include <linux/reboot.h>
#include <linux/threads.h>
#include <asm/machdep.h>
+#include <asm/lmb.h>
void machine_crash_shutdown(struct pt_regs *regs)
{
@@ -59,3 +60,58 @@ NORET_TYPE void machine_kexec(struct kim
}
for(;;);
}
+
+static int __init early_parse_crashk(char *p)
+{
+ unsigned long size;
+
+ if (!p)
+ return 1;
+
+ size = memparse(p, &p);
+
+ if (*p == '@')
+ crashk_res.start = memparse(p + 1, &p);
+ else
+ crashk_res.start = KDUMP_KERNELBASE;
+
+ crashk_res.end = crashk_res.start + size - 1;
+
+ return 0;
+}
+early_param("crashkernel", early_parse_crashk);
+
+void __init reserve_crashkernel(void)
+{
+ unsigned long size;
+
+ if (crashk_res.start == 0)
+ return;
+
+ /* We might have got these values via the command line or the
+ * device tree, either way sanitise them now. */
+
+ size = crashk_res.end - crashk_res.start + 1;
+
+ if (crashk_res.start != KDUMP_KERNELBASE)
+ printk("Crash kernel location must be 0x%x\n",
+ KDUMP_KERNELBASE);
+
+ crashk_res.start = KDUMP_KERNELBASE;
+ size = PAGE_ALIGN(size);
+ crashk_res.end = crashk_res.start + size - 1;
+
+ /* Crash kernel trumps memory limit */
+ if (memory_limit && memory_limit <= crashk_res.end) {
+ memory_limit = crashk_res.end + 1;
+ printk("Adjusted memory limit for crashkernel, now 0x%lx\n",
+ memory_limit);
+ }
+
+ lmb_reserve(crashk_res.start, size);
+}
+
+int overlaps_crashkernel(unsigned long start, unsigned long size)
+{
+ return (start + size) > crashk_res.start && start <= crashk_res.end;
+}
Index: to-merge/arch/powerpc/kernel/machine_kexec_64.c
===================================================================
--- to-merge.orig/arch/powerpc/kernel/machine_kexec_64.c
+++ to-merge/arch/powerpc/kernel/machine_kexec_64.c
@@ -21,7 +21,6 @@
#include <asm/machdep.h>
#include <asm/cacheflush.h>
#include <asm/paca.h>
-#include <asm/lmb.h>
#include <asm/mmu.h>
#include <asm/sections.h> /* _end */
#include <asm/prom.h>
@@ -385,58 +384,3 @@ static int __init kexec_setup(void)
return 0;
}
__initcall(kexec_setup);
-
-static int __init early_parse_crashk(char *p)
-{
- unsigned long size;
-
- if (!p)
- return 1;
-
- size = memparse(p, &p);
-
- if (*p == '@')
- crashk_res.start = memparse(p + 1, &p);
- else
- crashk_res.start = KDUMP_KERNELBASE;
-
- crashk_res.end = crashk_res.start + size - 1;
-
- return 0;
-}
-early_param("crashkernel", early_parse_crashk);
-
-void __init reserve_crashkernel(void)
-{
- unsigned long size;
-
- if (crashk_res.start == 0)
- return;
-
- /* We might have got these values via the command line or the
- * device tree, either way sanitise them now. */
-
- size = crashk_res.end - crashk_res.start + 1;
-
- if (crashk_res.start != KDUMP_KERNELBASE)
- printk("Crash kernel location must be 0x%x\n",
- KDUMP_KERNELBASE);
-
- crashk_res.start = KDUMP_KERNELBASE;
- size = PAGE_ALIGN(size);
- crashk_res.end = crashk_res.start + size - 1;
-
- /* Crash kernel trumps memory limit */
- if (memory_limit && memory_limit <= crashk_res.end) {
- memory_limit = crashk_res.end + 1;
- printk("Adjusted memory limit for crashkernel, now 0x%lx\n",
- memory_limit);
- }
-
- lmb_reserve(crashk_res.start, size);
-}
-
-int overlaps_crashkernel(unsigned long start, unsigned long size)
-{
- return (start + size) > crashk_res.start && start <= crashk_res.end;
-}
^ permalink raw reply
* RE: Linux 2.6.x : cpm_dpalloc alignment bug perhaps not fully r esolved
From: Li Yang-r58472 @ 2006-07-05 2:32 UTC (permalink / raw)
To: Laurent Lagrange, pantelis; +Cc: linuxppc-embedded
Did you apply the alignment patch too? AFAIK, the problem is never fixed in
mainstream trees.
Best Regards,
Leo
> -----Original Message-----
> From: linuxppc-embedded-bounces+leoli=freescale.com@ozlabs.org
> [mailto:linuxppc-embedded-bounces+leoli=freescale.com@ozlabs.org] On Behalf
> Of Laurent Lagrange
> Sent: Tuesday, July 04, 2006 11:37 PM
> To: pantelis@embeddedalley.com
> Cc: linuxppc-embedded@ozlabs.org
> Subject: Linux 2.6.x : cpm_dpalloc alignment bug perhaps not fully resolved
>
>
> Hello Pantelis,
>
> Few months ago (25 January 2006), I sent a mail about an alignment bug in
> cpm_dpalloc.
> I applied and verified the provided patch. I was very satisfied with the
> result.
>
> Today I port a driver from Linux 2.4 to Linux 2.6 and I have strange
> results.
>
> The driver allocates rx and tx bds (8 bytes aligned) in the module_init for
> 4 SCC ports.
> That is always right. Then one port is opened by an application and a user
> configuration
> is set via an ioctl (set_conf).
>
> This ioctl first frees the old bds :
> cpm_dpfree(chan->rx_bd_offset);
> cpm_dpfree(chan->tx_bd_offset);
> then allocates the new ones :
> chan->rx_bd_offset = cpm_dpalloc(sizeof(cbd_t) * chan->conf.rx_bufnbr,
> 8);
> chan->tx_bd_offset = cpm_dpalloc(sizeof(cbd_t) * chan->conf.tx_bufnbr,
> 8);
> with rx_bufnbr == 8 and tx_bufnbr == 2
>
> module_init
> SCC1 rx_bd_offset=160
> SCC1 tx_bd_offset=1a8
> SCC2 rx_bd_offset=1c0
> SCC2 tx_bd_offset=208
> SCC3 rx_bd_offset=220
> SCC3 tx_bd_offset=260
> SCC4 rx_bd_offset=278
> SCC4 tx_bd_offset=2c0
> set_conf
> SCC1 rx_bd_offset=160
> SCC1 tx_bd_offset=1a4 -> ???
>
> module_init
> SCC1 rx_bd_offset=160
> SCC1 tx_bd_offset=1a8
> SCC2 rx_bd_offset=1c0
> SCC2 tx_bd_offset=208
> SCC3 rx_bd_offset=220
> SCC3 tx_bd_offset=260
> SCC4 rx_bd_offset=278
> SCC4 tx_bd_offset=2c0
> set_conf
> SCC2 rx_bd_offset=1c0
> SCC2 tx_bd_offset=202 -> ???
>
> module_init
> SCC1 rx_bd_offset=160
> SCC1 tx_bd_offset=1a8
> SCC2 rx_bd_offset=1c0
> SCC2 tx_bd_offset=208
> SCC3 rx_bd_offset=220
> SCC3 tx_bd_offset=260
> SCC4 rx_bd_offset=278
> SCC4 tx_bd_offset=2c0
> set_conf
> SCC3 rx_bd_offset=220
> SCC3 tx_bd_offset=260 -> ok
>
> module_init
> SCC1 rx_bd_offset=160
> SCC1 tx_bd_offset=1a8
> SCC2 rx_bd_offset=1c0
> SCC2 tx_bd_offset=208
> SCC3 rx_bd_offset=220
> SCC3 tx_bd_offset=260
> SCC4 rx_bd_offset=278
> SCC4 tx_bd_offset=2c0
> set_conf
> SCC4 rx_bd_offset=278
> SCC4 tx_bd_offset=2c0 -> ok
>
> WARNING : if I only uses the SCC1 port without allocating bds for the other
> ports,
> I can free and reallocate the bds for the SCC1 port as many times I want.
>
> module_init
> SCC1 rx_bd_offset=160
> SCC1 tx_bd_offset=1a8
> set_conf
> SCC1 rx_bd_offset=160
> SCC1 tx_bd_offset=1a8 -> ok
>
> Really, I don't understand how this can arise.
> Any idea ?
>
> Thanks
> Laurent
>
>
>
>
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
^ permalink raw reply
* Re: [PATCH 3/20] [powerpc] Remove linux,pci-domain properties
From: Jeremy Kerr @ 2006-07-04 23:22 UTC (permalink / raw)
To: Milton Miller; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <e53c7a64d7260d56983e22360cb5dd5a@bga.com>
Milton,
> Without looking at the mentioned utilities, DLPAR and PCI Hotplug get
> a location code, so I'm hoping that the pci slot name is identified
> by that. Is lsvpd scanning? Or does it scan sysfs first and
> /proc/device-tree secondarly?
Yes, lsvpd scans sysfs first, then uses devspec to refer to the device
tree. and AFAICT, the slot id can't be extracted from the location
code.
So you're saying that the linux,pci-domain property is still in use,
right? If so, I'll do up a patch to fix add_linux_pci_domain rather
than removing it.
Cheers,
Jeremy
^ permalink raw reply
* RE: [PATCH 1/7] powerpc: Add mpc8360epb platform support
From: Benjamin Herrenschmidt @ 2006-07-04 22:39 UTC (permalink / raw)
To: Li Yang-r58472
Cc: Phillips Kim-R1AAHA, Yin Olivia-r63875,
'linux-kernel@vger.kernel.org', linuxppc-dev,
'Paul Mackerras', Chu hanjin-r52514
In-Reply-To: <9FCDBA58F226D911B202000BDBAD467306E05003@zch01exm40.ap.freescale.net>
> The problem is that we don't have this PPC_UBDG_16550 option configurable now,
> and it is only made by default for several boards including pseries, chrp, prep, cell,
> and all 83xx and 85xx platforms. If we need to change the whole thing, how should we do it?
It's up to your platformn code to enable it though. udbg will only kick
in from the legacy serial console code if your firmware indicates that
stdout is on a serial port. If the firmware doesn't, udbg won't kick in.
But yeah, build it in by default if you want then.
Ben.
^ permalink raw reply
* Re: what is the MPC8260 spi maximum rate ?
From: Wolfgang Denk @ 2006-07-04 19:49 UTC (permalink / raw)
To: hubert.loewenguth; +Cc: linuxppc-embedded
In-Reply-To: <44AA22E3.3050701@thales-bm.com>
Hello,
in message <44AA22E3.3050701@thales-bm.com> you wrote:
>
> It is written in MPC8260 documentation (SPI chapter) : " The maximum
> sustained data rate that the SPI supports is SYSTEMCLK/50. However the
> spi can transfer a single character at much higher rates (SYSTEMCLK/4 in
> master mode)".
>
> My really stupid question is ...... what is "SYSTEMCLK" ???????
> is it the BRG_CLK ? the CPM_CLK or the CPU_CLK ????
The performance-limiting factor is the CPM, so it's most probably the
CPM clock.
> This question is quite stupid but very important for me in order to know
> if that controller permit to exchange data with one of our extention
> board at 1.2 MHz.
Keep in mind that SPI is implemented in software on the CPM, and that
it's running at very low priority. All calculations assume an
otherise unloaded CPM - but if you add load to the CPM, things will
change.
We haven't run specific measurements on the 8260, but on the MPC860
we ran into a *lot* of ugly SPI problems when the CPM load got
higher, missing interrupts etc. being just one of the issues. At this
time, Motorola added a note to their FAQ base, which stetd pretty
clear that SPI was "not designed for high-bandwidth data communi-
cations".
Best regards,
Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
Due to lack of disk space, this fortune database has been discontinued.
^ permalink raw reply
* Re: [PATCH 13/20] [powerpc, video & agp] Constify & voidify get_property()
From: Dave Jones @ 2006-07-04 19:00 UTC (permalink / raw)
To: Jeremy Kerr; +Cc: linuxppc-dev, davej
On Tue, Jul 04, 2006 at 04:47:56PM +1000, Jeremy Kerr wrote:
> Now that get_property() returns a void *, there's no need to cast its
> return value. Also, treat the return value as const, so we can
> constify get_property later.
>
> powerpc-specific video & agp driver changes.
>
> Signed-off-by: Jeremy Kerr <jk@ozlabs.org>
Signed-off-by: Dave Jones <davej@redhat.com>
I assume this stuff is going in through the ppc tree?
Holler if not, and I'll push it through agpgart.git
Thanks,
Dave
--
http://www.codemonkey.org.uk
^ permalink raw reply
* Re: [Alsa-devel] sound connector detection
From: Johannes Berg @ 2006-07-04 18:51 UTC (permalink / raw)
To: Takashi Iwai
Cc: Dmitry Torokhov, Linux Kernel list, linuxppc-dev list,
Richard Purdie, linux-input, alsa-devel
In-Reply-To: <s5hmzbp2wlu.wl%tiwai@suse.de>
[-- Attachment #1: Type: text/plain, Size: 767 bytes --]
On Tue, 2006-07-04 at 17:55 +0200, Takashi Iwai wrote:
> Such a control element doesn't have to be IFACE_MIXER if you want to
> hide. You can use IFACE_CARD, for example, for a card-specific
> element but not belonging to the mixer component.
Oh. Good, I'll submit a patch to change that then so that it isn't
there. Someone's probably gonna lart me for it though because it isn't
visible any more ;)
> That's true. OTOH, invoking a command at each time isn't always a
> good solution, depending on the event-frequency and heaviness.
Yeah, that's the downside of a hotplug type approach.
Well, I'm open for other suggestions. I just dislike the current state
of pushing events through the alsa control elements. Sorta feels wrong.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]
^ permalink raw reply
* Re: JFFS2 FS is read-only (not what I want)
From: David Hawkins @ 2006-07-03 16:08 UTC (permalink / raw)
To: Ben Warren; +Cc: linuxppc-embedded
In-Reply-To: <44A6E57A.3080302@qstreams.com>
Ben Warren wrote:
> Hello,
>
> When I boot from a JFFS2 file system on my eval board, the file system
> is effectively read-only, and I can't figure out why. I'm pretty sure
> the kernel's configured for R/W MTD block access. Any help is greatly
> appreciated.
The default uboot command line on the 8349E was:
bootargs=root=/dev/mtdblock1 rootfstype=jffs2 rw console=ttyS0,115200
so I suspect you have dropped the rw ... try adding that.
> The hardware in use is:
>
> Freescale MPC8349EMDS eval board.
> 8MB Q-flash with 64 uniform 128k sectors
I'm also working with that board, feel free to contact me off
list and we can compare notes.
When I've finished my evaluation I'll post a link to the list
for anyone else thats interested.
Cheers
Dave
^ permalink raw reply
* Re: [Alsa-devel] sound connector detection
From: Takashi Iwai @ 2006-07-04 15:55 UTC (permalink / raw)
To: Johannes Berg
Cc: Dmitry Torokhov, Linux Kernel list, linuxppc-dev list,
Richard Purdie, linux-input, alsa-devel
In-Reply-To: <1151933414.20701.38.camel@localhost>
At Mon, 03 Jul 2006 15:30:14 +0200,
Johannes Berg wrote:
>
>
> > I am not too happy with putting this kind of switches into input layer,
> > it should be reserved for "real" buttons, ones that user can explicitely
> > push or toggle (lid switch is on the edge here but it and sleep button
> > are used for similar purposes so it makes sense to have it in input layer
> > too). But "cable X connected" kind of events is too much [for input layer,
> > there could well be a separate layer for it]. If we go this way we'd have
> > to move cable detection code from network to input layer as well ;)
>
> I sort of see the point. But I think it is indeed unfortunate that we
> have all these events scattered throughout. I could live with the
> current approach abusing the alsa mixer API, but there's little point in
> making that element user-visible. So maybe I just need some new alsa
> definitions here.
Such a control element doesn't have to be IFACE_MIXER if you want to
hide. You can use IFACE_CARD, for example, for a card-specific
element but not belonging to the mixer component.
> Although, come to think of it, a daemon keeping the mixer open blocks
> unloading the module. I suppose I'd rather have it the other way around
> like the eventdev system does -- the device goes away and all reads to
> it fail.
That's true. OTOH, invoking a command at each time isn't always a
good solution, depending on the event-frequency and heaviness.
Takashi
^ permalink raw reply
* Linux 2.6.x : cpm_dpalloc alignment bug perhaps not fully resolved
From: Laurent Lagrange @ 2006-07-04 15:37 UTC (permalink / raw)
To: pantelis; +Cc: linuxppc-embedded
In-Reply-To: <200601251814.17331.pantelis@embeddedalley.com>
Hello Pantelis,
Few months ago (25 January 2006), I sent a mail about an alignment bug in
cpm_dpalloc.
I applied and verified the provided patch. I was very satisfied with the
result.
Today I port a driver from Linux 2.4 to Linux 2.6 and I have strange
results.
The driver allocates rx and tx bds (8 bytes aligned) in the module_init for
4 SCC ports.
That is always right. Then one port is opened by an application and a user
configuration
is set via an ioctl (set_conf).
This ioctl first frees the old bds :
cpm_dpfree(chan->rx_bd_offset);
cpm_dpfree(chan->tx_bd_offset);
then allocates the new ones :
chan->rx_bd_offset = cpm_dpalloc(sizeof(cbd_t) * chan->conf.rx_bufnbr, 8);
chan->tx_bd_offset = cpm_dpalloc(sizeof(cbd_t) * chan->conf.tx_bufnbr, 8);
with rx_bufnbr == 8 and tx_bufnbr == 2
module_init
SCC1 rx_bd_offset=160
SCC1 tx_bd_offset=1a8
SCC2 rx_bd_offset=1c0
SCC2 tx_bd_offset=208
SCC3 rx_bd_offset=220
SCC3 tx_bd_offset=260
SCC4 rx_bd_offset=278
SCC4 tx_bd_offset=2c0
set_conf
SCC1 rx_bd_offset=160
SCC1 tx_bd_offset=1a4 -> ???
module_init
SCC1 rx_bd_offset=160
SCC1 tx_bd_offset=1a8
SCC2 rx_bd_offset=1c0
SCC2 tx_bd_offset=208
SCC3 rx_bd_offset=220
SCC3 tx_bd_offset=260
SCC4 rx_bd_offset=278
SCC4 tx_bd_offset=2c0
set_conf
SCC2 rx_bd_offset=1c0
SCC2 tx_bd_offset=202 -> ???
module_init
SCC1 rx_bd_offset=160
SCC1 tx_bd_offset=1a8
SCC2 rx_bd_offset=1c0
SCC2 tx_bd_offset=208
SCC3 rx_bd_offset=220
SCC3 tx_bd_offset=260
SCC4 rx_bd_offset=278
SCC4 tx_bd_offset=2c0
set_conf
SCC3 rx_bd_offset=220
SCC3 tx_bd_offset=260 -> ok
module_init
SCC1 rx_bd_offset=160
SCC1 tx_bd_offset=1a8
SCC2 rx_bd_offset=1c0
SCC2 tx_bd_offset=208
SCC3 rx_bd_offset=220
SCC3 tx_bd_offset=260
SCC4 rx_bd_offset=278
SCC4 tx_bd_offset=2c0
set_conf
SCC4 rx_bd_offset=278
SCC4 tx_bd_offset=2c0 -> ok
WARNING : if I only uses the SCC1 port without allocating bds for the other
ports,
I can free and reallocate the bds for the SCC1 port as many times I want.
module_init
SCC1 rx_bd_offset=160
SCC1 tx_bd_offset=1a8
set_conf
SCC1 rx_bd_offset=160
SCC1 tx_bd_offset=1a8 -> ok
Really, I don't understand how this can arise.
Any idea ?
Thanks
Laurent
^ permalink raw reply
* Re: How do you set up a PPC440GX with a P HY on emac2 only?
From: Denny @ 2006-07-04 14:24 UTC (permalink / raw)
To: marc.howard, linuxppc-embedded
In-Reply-To: <91B22F93A880FA48879475E134D6F0BE386FD4@CA1EXCLV02.adcorp.kla-tencor.com>
[-- Attachment #1: Type: text/plain, Size: 140 bytes --]
Also, I failed to setup my PHY on the emac0,can anyone tell me how to setup the PHY on PPC440GP, thanks!
Thanks & regards!
- Denny
[-- Attachment #2: Type: text/html, Size: 691 bytes --]
^ permalink raw reply
* Re: [PATCH] powermac: defer work in backlight key press
From: Johannes Berg @ 2006-07-04 11:16 UTC (permalink / raw)
To: Aristeu Sergio Rozanski Filho; +Cc: linuxppc-dev
In-Reply-To: <20060704110354.GA30435@cathedrallabs.org>
[-- Attachment #1: Type: text/plain, Size: 621 bytes --]
On Tue, 2006-07-04 at 08:03 -0300, Aristeu Sergio Rozanski Filho wrote:
> today pmac_backlight_key() is called either with 0 (to reduce backlight
> level) or 1 (to increase).
Oh, it looked on first look like it was -1 or 1, I see it now.
> I found that actually happening two
> keystrokes between interrupt being serviced and actually running that
> work queue would be so damn small that the extra code wouldn't be worth.
> but if you think it's worth for, I can fix it, no problem.
Yeah, you're right. Unless that thing has some fast repeat if you hold
keys... Not sure what I was thinking.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]
^ permalink raw reply
* Re: [PATCH] powermac: defer work in backlight key press
From: Aristeu Sergio Rozanski Filho @ 2006-07-04 11:03 UTC (permalink / raw)
To: Johannes Berg; +Cc: linuxppc-dev
In-Reply-To: <1152000419.20701.48.camel@localhost>
> > + /* we can receive multiple interrupts here, but the scheduled work
> > + * will run only once, with the last value */
> > + pmac_backlight_key_queued = direction;
>
> Shouldn't you be doing something like using the whole
> pmac_backlight_key_queued in the workqueue, then setting it to 0 there
> and using += here? That way all keypresses will be adhered to.
today pmac_backlight_key() is called either with 0 (to reduce backlight
level) or 1 (to increase). I found that actually happening two
keystrokes between interrupt being serviced and actually running that
work queue would be so damn small that the extra code wouldn't be worth.
but if you think it's worth for, I can fix it, no problem.
--
Aristeu
^ permalink raw reply
* Re: JFFS2 FS is read-only (not what I want)
From: Mathieu Deschamps @ 2006-07-04 8:59 UTC (permalink / raw)
To: bwarren; +Cc: linuxppc-embedded
In-Reply-To: <1151957564.12449.39.camel@saruman.qstreams.net>
On Monday 03 July 2006 22:12, Ben Warren wrote:
> On Mon, 2006-07-03 at 15:38 -0400, Ben Warren wrote:
> > This is starting to look to me like a generation-time issue. I built
> > another JFFS2 partition out of a random directory on my workstation, and
> > it's behaving properly:
>
> Sorry for filling people's inboxes, but it turns out the problem was
> between the chair and keyboard.
arf ! computer hardly ever suffer this problem :)
>My JFFS2 partition was slightly less
> than 2MB, which I guess decompresses to > 2 MB, filling up the
> partition. I must have been in the wrong directory when issuing the
> 'du' command. On the plus side, I've learned quite a bit about MTD and
> JFFS2 going through this exercise!
>
> regards,
> Ben
Regards,
mathdesc
-------
I guess this illustrate a difference between knowledge and
understanding. The first without second is confusion, the second without
first is a miss.
^ permalink raw reply
* what is the MPC8260 spi maximum rate ?
From: hubert.loewenguth @ 2006-07-04 8:12 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 901 bytes --]
Hi everybody
I have a question about the spi on the MPC8260.
I have written a driver for this controller but there is something in
the MPC8260 documentation I don't understand:
It is written in MPC8260 documentation (SPI chapter) : " The maximum
sustained data rate that the SPI supports is SYSTEMCLK/50. However the
spi can transfer a single character at much higher rates (SYSTEMCLK/4 in
master mode)".
My really stupid question is ...... what is "SYSTEMCLK" ???????
is it the BRG_CLK ? the CPM_CLK or the CPU_CLK ????
Seeing that in the SPMODE register, the maximum SPI CLK possible is
BRG_CLK/4, I imagine that this "SYSTEMCLK" is BRG_CLK, but this looks
very strange .....
This question is quite stupid but very important for me in order to know
if that controller permit to exchange data with one of our extention
board at 1.2 MHz.
Anybody knows ?
Thanks very much for any help .
[-- Attachment #2: hubert.loewenguth.vcf --]
[-- Type: text/x-vcard, Size: 285 bytes --]
begin:vcard
fn:Hubert Loewenguth
n:Loewenguth;Hubert
org:Thales Broadcast & Multimedia
adr:;;1 rue de l'hautil;Conflans Ste Honorine;;78700;France
email;internet:hubert.loewenguth@thales-bm.com
title:Software Engineer
tel;work:01-34-90-37-56
x-mozilla-html:TRUE
version:2.1
end:vcard
^ permalink raw reply
* Re: [PATCH] powermac: defer work in backlight key press
From: Johannes Berg @ 2006-07-04 8:06 UTC (permalink / raw)
To: Aristeu Sergio Rozanski Filho; +Cc: linuxppc-dev
In-Reply-To: <20060704013923.GG27596@cathedrallabs.org>
[-- Attachment #1: Type: text/plain, Size: 377 bytes --]
>
> + /* we can receive multiple interrupts here, but the scheduled work
> + * will run only once, with the last value */
> + pmac_backlight_key_queued = direction;
Shouldn't you be doing something like using the whole
pmac_backlight_key_queued in the workqueue, then setting it to 0 there
and using += here? That way all keypresses will be adhered to.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]
^ permalink raw reply
* Re: [PATCH 3/20] [powerpc] Remove linux,pci-domain properties
From: Milton Miller @ 2006-07-04 7:55 UTC (permalink / raw)
To: Jeremy Kerr; +Cc: linuxppc-dev, Paul Mackerras
On Tue Jul 4 16:47:18 EST 2006, Jeremy Kerr wrote:
> The linux,pci-domain property is no longer used by DLPAR/PCI Hotplug
> utilites, or LSVPD. This change removes it.
So if I have some device-tree path and want to find the sysfs node
for it or run something like lspci on it, I have to search all of
sysfs for a matching devspec file? (And this can change each boot.)
Without looking at the mentioned utilities, DLPAR and PCI Hotplug get a
location code, so I'm hoping that the pci slot name is identified by
that. Is lsvpd scanning? Or does it scan sysfs first and
/proc/device-tree secondarly?
milton
^ permalink raw reply
* Re: "boot: mem=1024M" causes only one CPU is brought up in 2.6.17-mm4
From: Michael Ellerman @ 2006-07-04 7:18 UTC (permalink / raw)
To: Raid Cheng; +Cc: linuxppc-dev list
In-Reply-To: <b7ddee480606300005p15367a6al4db562f8d0b885d9@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 646 bytes --]
On Fri, 2006-06-30 at 15:05 +0800, Raid Cheng wrote:
> I installed latest mm kernel 2.6.17-mm4 on ppc64 with RHEL4-U3.
> When i tried to limit the memory to 1024M by modifying yaboot.conf or
> typing on the boot line, I found some error messages in dmesg log
> and only one CPU is brought up by checking /proc/cpuinfo.
I've just posted a fix:
"[PATCH] Fix mem= handling when the memory limit is > RMO".
cheers
--
Michael Ellerman
IBM OzLabs
wwweb: http://michael.ellerman.id.au
phone: +61 2 6212 1183 (tie line 70 21183)
We do not inherit the earth from our ancestors,
we borrow it from our children. - S.M.A.R.T Person
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 191 bytes --]
^ permalink raw reply
* [PATCH] Fix mem= handling when the memory limit is > RMO size
From: Michael Ellerman @ 2006-07-04 7:13 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
There's a bug in my cleaned up mem= handling, if the memory limit is
larger than the RMO size we'll erroneously enlarge the RMO size.
Fix is to only change the RMO size if the memory limit is less than
the current RMO value.
Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
---
arch/powerpc/mm/lmb.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
Index: to-merge/arch/powerpc/mm/lmb.c
===================================================================
--- to-merge.orig/arch/powerpc/mm/lmb.c
+++ to-merge/arch/powerpc/mm/lmb.c
@@ -320,7 +320,8 @@ void __init lmb_enforce_memory_limit(uns
break;
}
- lmb.rmo_size = lmb.memory.region[0].size;
+ if (lmb.memory.region[0].size < lmb.rmo_size)
+ lmb.rmo_size = lmb.memory.region[0].size;
/* And truncate any reserves above the limit also. */
for (i = 0; i < lmb.reserved.cnt; i++) {
^ permalink raw reply
* [PATCH] powerpc: More offb/bootx fixes
From: Benjamin Herrenschmidt @ 2006-07-04 7:07 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev list
There were still some issues with offb when BootX doesn't provide a
proper display node,
this fixes them. This also re-instates the palette hacks that were
disabled a couple of
kernel versions ago when I converted to the new OF parsing and shuffles
some functions
around to avoid prototypes.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Index: linux-irq-work/arch/powerpc/platforms/powermac/bootx_init.c
===================================================================
--- linux-irq-work.orig/arch/powerpc/platforms/powermac/bootx_init.c 2006-07-04 09:37:03.000000000 +1000
+++ linux-irq-work/arch/powerpc/platforms/powermac/bootx_init.c 2006-07-04 17:05:13.000000000 +1000
@@ -181,13 +181,18 @@
}
static void __init bootx_add_display_props(unsigned long base,
- unsigned long *mem_end)
+ unsigned long *mem_end,
+ int has_real_node)
{
boot_infos_t *bi = bootx_info;
u32 tmp;
- bootx_dt_add_prop("linux,boot-display", NULL, 0, mem_end);
- bootx_dt_add_prop("linux,opened", NULL, 0, mem_end);
+ if (has_real_node) {
+ bootx_dt_add_prop("linux,boot-display", NULL, 0, mem_end);
+ bootx_dt_add_prop("linux,opened", NULL, 0, mem_end);
+ } else
+ bootx_dt_add_prop("linux,bootx-noscreen", NULL, 0, mem_end);
+
tmp = bi->dispDeviceDepth;
bootx_dt_add_prop("linux,bootx-depth", &tmp, 4, mem_end);
tmp = bi->dispDeviceRect[2] - bi->dispDeviceRect[0];
@@ -241,11 +246,6 @@
DBG(" detected display ! adding properties names !\n");
bootx_dt_add_string("linux,boot-display", mem_end);
bootx_dt_add_string("linux,opened", mem_end);
- bootx_dt_add_string("linux,bootx-depth", mem_end);
- bootx_dt_add_string("linux,bootx-width", mem_end);
- bootx_dt_add_string("linux,bootx-height", mem_end);
- bootx_dt_add_string("linux,bootx-linebytes", mem_end);
- bootx_dt_add_string("linux,bootx-addr", mem_end);
strncpy(bootx_disp_path, namep, 255);
}
@@ -329,10 +329,13 @@
ppp = &pp->next;
}
- if (node == bootx_node_chosen)
+ if (node == bootx_node_chosen) {
bootx_add_chosen_props(base, mem_end);
- if (node == bootx_info->dispDeviceRegEntryOffset)
- bootx_add_display_props(base, mem_end);
+ if (bootx_info->dispDeviceRegEntryOffset == 0)
+ bootx_add_display_props(base, mem_end, 0);
+ }
+ else if (node == bootx_info->dispDeviceRegEntryOffset)
+ bootx_add_display_props(base, mem_end, 1);
/* do all our children */
cpp = &np->child;
@@ -374,6 +377,14 @@
mem_end += 4;
bootx_dt_strend = mem_end;
bootx_scan_dt_build_strings(base, 4, &mem_end);
+ /* Add some strings */
+ bootx_dt_add_string("linux,bootx-noscreen", &mem_end);
+ bootx_dt_add_string("linux,bootx-depth", &mem_end);
+ bootx_dt_add_string("linux,bootx-width", &mem_end);
+ bootx_dt_add_string("linux,bootx-height", &mem_end);
+ bootx_dt_add_string("linux,bootx-linebytes", &mem_end);
+ bootx_dt_add_string("linux,bootx-addr", &mem_end);
+ /* Wrap up strings */
hdr->off_dt_strings = bootx_dt_strbase - mem_start;
hdr->dt_strings_size = bootx_dt_strend - bootx_dt_strbase;
@@ -471,6 +482,7 @@
if (bi->dispDeviceDepth == 16)
bi->dispDeviceDepth = 15;
+
#ifdef CONFIG_BOOTX_TEXT
ptr = (unsigned long)bi->logicalDisplayBase;
ptr += bi->dispDeviceRect[1] * bi->dispDeviceRowBytes;
@@ -508,6 +520,7 @@
#ifdef CONFIG_BOOTX_TEXT
btext_welcome(bi);
#endif
+
/* New BootX enters kernel with MMU off, i/os are not allowed
* here. This hack will have been done by the boostrap anyway.
*/
Index: linux-irq-work/drivers/video/offb.c
===================================================================
--- linux-irq-work.orig/drivers/video/offb.c 2006-07-04 09:37:04.000000000 +1000
+++ linux-irq-work/drivers/video/offb.c 2006-07-04 16:52:37.000000000 +1000
@@ -63,8 +63,6 @@
* Interface used by the world
*/
-int offb_init(void);
-
static int offb_setcolreg(u_int regno, u_int red, u_int green, u_int blue,
u_int transp, struct fb_info *info);
static int offb_blank(int blank, struct fb_info *info);
@@ -73,11 +71,6 @@
extern boot_infos_t *boot_infos;
#endif
-static void offb_init_nodriver(struct device_node *);
-static void offb_init_fb(const char *name, const char *full_name,
- int width, int height, int depth, int pitch,
- unsigned long address, struct device_node *dp);
-
static struct fb_ops offb_ops = {
.owner = THIS_MODULE,
.fb_setcolreg = offb_setcolreg,
@@ -230,123 +223,17 @@
return 0;
}
- /*
- * Initialisation
- */
-int __init offb_init(void)
+static void __iomem *offb_map_reg(struct device_node *np, int index,
+ unsigned long offset, unsigned long size)
{
- struct device_node *dp = NULL, *boot_disp = NULL;
-
- if (fb_get_options("offb", NULL))
- return -ENODEV;
+ struct resource r;
- for (dp = NULL; (dp = of_find_node_by_type(dp, "display"));) {
- if (get_property(dp, "linux,opened", NULL) &&
- get_property(dp, "linux,boot-display", NULL)) {
- boot_disp = dp;
- offb_init_nodriver(dp);
- }
- }
- for (dp = NULL; (dp = of_find_node_by_type(dp, "display"));) {
- if (get_property(dp, "linux,opened", NULL) &&
- dp != boot_disp)
- offb_init_nodriver(dp);
- }
-
- return 0;
-}
-
-
-static void __init offb_init_nodriver(struct device_node *dp)
-{
- unsigned int len;
- int i, width = 640, height = 480, depth = 8, pitch = 640;
- unsigned int flags, rsize, addr_prop = 0;
- unsigned long max_size = 0;
- u64 rstart, address = OF_BAD_ADDR;
- u32 *pp, *addrp, *up;
- u64 asize;
-
- pp = (u32 *)get_property(dp, "linux,bootx-depth", &len);
- if (pp == NULL)
- pp = (u32 *)get_property(dp, "depth", &len);
- if (pp && len == sizeof(u32))
- depth = *pp;
-
- pp = (u32 *)get_property(dp, "linux,bootx-width", &len);
- if (pp == NULL)
- pp = (u32 *)get_property(dp, "width", &len);
- if (pp && len == sizeof(u32))
- width = *pp;
-
- pp = (u32 *)get_property(dp, "linux,bootx-height", &len);
- if (pp == NULL)
- pp = (u32 *)get_property(dp, "height", &len);
- if (pp && len == sizeof(u32))
- height = *pp;
-
- pp = (u32 *)get_property(dp, "linux,bootx-linebytes", &len);
- if (pp == NULL)
- pp = (u32 *)get_property(dp, "linebytes", &len);
- if (pp && len == sizeof(u32))
- pitch = *pp;
- else
- pitch = width * ((depth + 7) / 8);
-
- rsize = (unsigned long)pitch * (unsigned long)height;
-
- /* Ok, now we try to figure out the address of the framebuffer.
- *
- * Unfortunately, Open Firmware doesn't provide a standard way to do
- * so. All we can do is a dodgy heuristic that happens to work in
- * practice. On most machines, the "address" property contains what
- * we need, though not on Matrox cards found in IBM machines. What I've
- * found that appears to give good results is to go through the PCI
- * ranges and pick one that is both big enough and if possible encloses
- * the "address" property. If none match, we pick the biggest
- */
- up = (u32 *)get_property(dp, "linux,bootx-addr", &len);
- if (up == NULL)
- up = (u32 *)get_property(dp, "address", &len);
- if (up && len == sizeof(u32))
- addr_prop = *up;
-
- for (i = 0; (addrp = of_get_address(dp, i, &asize, &flags))
- != NULL; i++) {
- int match_addrp = 0;
-
- if (!(flags & IORESOURCE_MEM))
- continue;
- if (asize < rsize)
- continue;
- rstart = of_translate_address(dp, addrp);
- if (rstart == OF_BAD_ADDR)
- continue;
- if (addr_prop && (rstart <= addr_prop) &&
- ((rstart + asize) >= (addr_prop + rsize)))
- match_addrp = 1;
- if (match_addrp) {
- address = addr_prop;
- break;
- }
- if (rsize > max_size) {
- max_size = rsize;
- address = OF_BAD_ADDR;
- }
-
- if (address == OF_BAD_ADDR)
- address = rstart;
- }
- if (address == OF_BAD_ADDR && addr_prop)
- address = (u64)addr_prop;
- if (address != OF_BAD_ADDR) {
- /* kludge for valkyrie */
- if (strcmp(dp->name, "valkyrie") == 0)
- address += 0x1000;
- offb_init_fb(dp->name, dp->full_name, width, height, depth,
- pitch, address, dp);
- }
+ if (of_address_to_resource(np, index, &r))
+ return 0;
+ if ((r.start + offset + size) > r.end)
+ return 0;
+ return ioremap(r.start + offset, size);
}
static void __init offb_init_fb(const char *name, const char *full_name,
@@ -403,45 +290,39 @@
par->cmap_type = cmap_unknown;
if (depth == 8) {
-
/* Palette hacks disabled for now */
-#if 0
if (dp && !strncmp(name, "ATY,Rage128", 11)) {
- unsigned long regbase = dp->addrs[2].address;
- par->cmap_adr = ioremap(regbase, 0x1FFF);
- par->cmap_type = cmap_r128;
+ par->cmap_adr = offb_map_reg(dp, 2, 0, 0x1fff);
+ if (par->cmap_adr)
+ par->cmap_type = cmap_r128;
} else if (dp && (!strncmp(name, "ATY,RageM3pA", 12)
|| !strncmp(name, "ATY,RageM3p12A", 14))) {
- unsigned long regbase =
- dp->parent->addrs[2].address;
- par->cmap_adr = ioremap(regbase, 0x1FFF);
- par->cmap_type = cmap_M3A;
+ par->cmap_adr = offb_map_reg(dp, 2, 0, 0x1fff);
+ if (par->cmap_adr)
+ par->cmap_type = cmap_M3A;
} else if (dp && !strncmp(name, "ATY,RageM3pB", 12)) {
- unsigned long regbase =
- dp->parent->addrs[2].address;
- par->cmap_adr = ioremap(regbase, 0x1FFF);
- par->cmap_type = cmap_M3B;
+ par->cmap_adr = offb_map_reg(dp, 2, 0, 0x1fff);
+ if (par->cmap_adr)
+ par->cmap_type = cmap_M3B;
} else if (dp && !strncmp(name, "ATY,Rage6", 9)) {
- unsigned long regbase = dp->addrs[1].address;
- par->cmap_adr = ioremap(regbase, 0x1FFF);
- par->cmap_type = cmap_radeon;
+ par->cmap_adr = offb_map_reg(dp, 1, 0, 0x1fff);
+ if (par->cmap_adr)
+ par->cmap_type = cmap_radeon;
} else if (!strncmp(name, "ATY,", 4)) {
unsigned long base = address & 0xff000000UL;
par->cmap_adr =
ioremap(base + 0x7ff000, 0x1000) + 0xcc0;
par->cmap_data = par->cmap_adr + 1;
par->cmap_type = cmap_m64;
- } else if (device_is_compatible(dp, "pci1014,b7")) {
- unsigned long regbase = dp->addrs[0].address;
- par->cmap_adr = ioremap(regbase + 0x6000, 0x1000);
- par->cmap_type = cmap_gxt2000;
+ } else if (dp && device_is_compatible(dp, "pci1014,b7")) {
+ par->cmap_adr = offb_map_reg(dp, 0, 0x6000, 0x1000);
+ if (par->cmap_adr)
+ par->cmap_type = cmap_gxt2000;
}
-#endif
- fix->visual = par->cmap_adr ? FB_VISUAL_PSEUDOCOLOR
- : FB_VISUAL_STATIC_PSEUDOCOLOR;
+ fix->visual = (par->cmap_type != cmap_unknown) ?
+ FB_VISUAL_PSEUDOCOLOR : FB_VISUAL_STATIC_PSEUDOCOLOR;
} else
- fix->visual = /* par->cmap_adr ? FB_VISUAL_DIRECTCOLOR
- : */ FB_VISUAL_TRUECOLOR;
+ fix->visual = FB_VISUAL_TRUECOLOR;
var->xoffset = var->yoffset = 0;
switch (depth) {
@@ -521,5 +402,139 @@
info->node, full_name);
}
+
+static void __init offb_init_nodriver(struct device_node *dp, int no_real_node)
+{
+ unsigned int len;
+ int i, width = 640, height = 480, depth = 8, pitch = 640;
+ unsigned int flags, rsize, addr_prop = 0;
+ unsigned long max_size = 0;
+ u64 rstart, address = OF_BAD_ADDR;
+ u32 *pp, *addrp, *up;
+ u64 asize;
+
+ pp = (u32 *)get_property(dp, "linux,bootx-depth", &len);
+ if (pp == NULL)
+ pp = (u32 *)get_property(dp, "depth", &len);
+ if (pp && len == sizeof(u32))
+ depth = *pp;
+
+ pp = (u32 *)get_property(dp, "linux,bootx-width", &len);
+ if (pp == NULL)
+ pp = (u32 *)get_property(dp, "width", &len);
+ if (pp && len == sizeof(u32))
+ width = *pp;
+
+ pp = (u32 *)get_property(dp, "linux,bootx-height", &len);
+ if (pp == NULL)
+ pp = (u32 *)get_property(dp, "height", &len);
+ if (pp && len == sizeof(u32))
+ height = *pp;
+
+ pp = (u32 *)get_property(dp, "linux,bootx-linebytes", &len);
+ if (pp == NULL)
+ pp = (u32 *)get_property(dp, "linebytes", &len);
+ if (pp && len == sizeof(u32))
+ pitch = *pp;
+ else
+ pitch = width * ((depth + 7) / 8);
+
+ rsize = (unsigned long)pitch * (unsigned long)height;
+
+ /* Ok, now we try to figure out the address of the framebuffer.
+ *
+ * Unfortunately, Open Firmware doesn't provide a standard way to do
+ * so. All we can do is a dodgy heuristic that happens to work in
+ * practice. On most machines, the "address" property contains what
+ * we need, though not on Matrox cards found in IBM machines. What I've
+ * found that appears to give good results is to go through the PCI
+ * ranges and pick one that is both big enough and if possible encloses
+ * the "address" property. If none match, we pick the biggest
+ */
+ up = (u32 *)get_property(dp, "linux,bootx-addr", &len);
+ if (up == NULL)
+ up = (u32 *)get_property(dp, "address", &len);
+ if (up && len == sizeof(u32))
+ addr_prop = *up;
+
+ /* Hack for when BootX is passing us */
+ if (no_real_node)
+ goto skip_addr;
+
+ for (i = 0; (addrp = of_get_address(dp, i, &asize, &flags))
+ != NULL; i++) {
+ int match_addrp = 0;
+
+ if (!(flags & IORESOURCE_MEM))
+ continue;
+ if (asize < rsize)
+ continue;
+ rstart = of_translate_address(dp, addrp);
+ if (rstart == OF_BAD_ADDR)
+ continue;
+ if (addr_prop && (rstart <= addr_prop) &&
+ ((rstart + asize) >= (addr_prop + rsize)))
+ match_addrp = 1;
+ if (match_addrp) {
+ address = addr_prop;
+ break;
+ }
+ if (rsize > max_size) {
+ max_size = rsize;
+ address = OF_BAD_ADDR;
+ }
+
+ if (address == OF_BAD_ADDR)
+ address = rstart;
+ }
+ skip_addr:
+ if (address == OF_BAD_ADDR && addr_prop)
+ address = (u64)addr_prop;
+ if (address != OF_BAD_ADDR) {
+ /* kludge for valkyrie */
+ if (strcmp(dp->name, "valkyrie") == 0)
+ address += 0x1000;
+ offb_init_fb(no_real_node ? "bootx" : dp->name,
+ no_real_node ? "display" : dp->full_name,
+ width, height, depth, pitch, address,
+ no_real_node ? dp : NULL);
+ }
+}
+
+static int __init offb_init(void)
+{
+ struct device_node *dp = NULL, *boot_disp = NULL;
+
+ if (fb_get_options("offb", NULL))
+ return -ENODEV;
+
+ /* Check if we have a MacOS display without a node spec */
+ if (get_property(of_chosen, "linux,bootx-noscreen", NULL) != NULL) {
+ /* The old code tried to work out which node was the MacOS
+ * display based on the address. I'm dropping that since the
+ * lack of a node spec only happens with old BootX versions
+ * (users can update) and with this code, they'll still get
+ * a display (just not the palette hacks).
+ */
+ offb_init_nodriver(of_chosen, 1);
+ }
+
+ for (dp = NULL; (dp = of_find_node_by_type(dp, "display"));) {
+ if (get_property(dp, "linux,opened", NULL) &&
+ get_property(dp, "linux,boot-display", NULL)) {
+ boot_disp = dp;
+ offb_init_nodriver(dp, 0);
+ }
+ }
+ for (dp = NULL; (dp = of_find_node_by_type(dp, "display"));) {
+ if (get_property(dp, "linux,opened", NULL) &&
+ dp != boot_disp)
+ offb_init_nodriver(dp, 0);
+ }
+
+ return 0;
+}
+
+
module_init(offb_init);
MODULE_LICENSE("GPL");
^ permalink raw reply
* RE: [PATCH 1/7] powerpc: Add mpc8360epb platform support
From: Li Yang-r58472 @ 2006-07-04 7:00 UTC (permalink / raw)
To: 'Benjamin Herrenschmidt'
Cc: Phillips Kim-R1AAHA, Yin Olivia-r63875,
'linux-kernel@vger.kernel.org', linuxppc-dev,
'Paul Mackerras', Chu hanjin-r52514
> -----Original Message-----
> From: Benjamin Herrenschmidt [mailto:benh@kernel.crashing.org]
> Sent: Saturday, July 01, 2006 5:00 PM
> To: Li Yang-r58472
> Cc: 'Vitaly Bordug'; 'Paul Mackerras'; linuxppc-dev@ozlabs.org; Phillips
> Kim-R1AAHA; Chu hanjin-r52514; Yin Olivia-r63875;
> 'linux-kernel@vger.kernel.org'
> Subject: RE: [PATCH 1/7] powerpc: Add mpc8360epb platform support
>
> On Fri, 2006-06-30 at 18:27 +0800, Li Yang-r58472 wrote:
> > > -----Original Message-----
> > > From: Vitaly Bordug [mailto:vbordug@ru.mvista.com]
> > > Sent: Thursday, June 29, 2006 12:59 AM
> > > To: Li Yang-r58472
> > > Cc: 'Paul Mackerras'; linuxppc-dev@ozlabs.org; Phillips Kim-R1AAHA; Chu
> > > hanjin-r52514; Yin Olivia-r63875; 'linux-kernel@vger.kernel.org'
> > > Subject: Re: [PATCH 1/7] powerpc: Add mpc8360epb platform support
> > >
> > > On Wed, 28 Jun 2006 22:23:03 +0800
> > > Li Yang-r58472 <LeoLi@freescale.com> wrote:
> > >
> > [snip]
> > >
> > > >
> > > > config MPC834x
> > > > @@ -24,4 +31,10 @@ config MPC834x
> > > > select PPC_INDIRECT_PCI
> > > > default y if MPC834x_SYS
> > > >
> > > > +config MPC836x
> > > > + bool
> > > > + select PPC_UDBG_16550
> > >
> > > debug option made default?
> >
> > I'm afraid this is needed to boot. 83xx family platforms need it to
> initialize early console. And it does appear in several defconfigs of other
> platforms.
>
> How so ? Why would having a serial console be mandatory ? Embedded might
> want to boot without a console and use the serial port for other things.
> This should be left as a config option (though you are welcome to put it
> in the defconfig for your platform)
The problem is that we don't have this PPC_UBDG_16550 option configurable now, and it is only made by default for several boards including pseries, chrp, prep, cell, and all 83xx and 85xx platforms. If we need to change the whole thing, how should we do it?
>
> > > > + select PPC_INDIRECT_PCI
> > > > + default y if MPC8360E_PB
> > > > +
> > > > endmenu
> >
> > -
> > 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
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