* [PATCH 1/3][POWERPC][V2] of_serial: Fix possible null dereference.
From: John Linn @ 2008-04-02 16:52 UTC (permalink / raw)
To: linuxppc-dev, grant.likely; +Cc: John Linn
From: Stephen Neuendorffer <stephen.neuendorffer@xilinx.com>
The of_serial driver queries the current-speed property and attempts
to use it to register the custom_divisor property of the uart_port.
However, if current-speed is not set, then this code will dereference
a bad pointer. The fix is to only set custom_divisor when a
current-speed property appears in the device tree.
Signed-off-by: Stephen Neuendorffer <stephen.neuendorffer@xilinx.com>
Signed-off-by: John Linn <john.linn@xilinx.com>
---
drivers/serial/of_serial.c | 4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/drivers/serial/of_serial.c b/drivers/serial/of_serial.c
index a64d858..2efb892 100644
--- a/drivers/serial/of_serial.c
+++ b/drivers/serial/of_serial.c
@@ -56,7 +56,9 @@ static int __devinit of_platform_serial_setup(struct of_device *ofdev,
port->flags = UPF_SHARE_IRQ | UPF_BOOT_AUTOCONF | UPF_IOREMAP
| UPF_FIXED_PORT;
port->dev = &ofdev->dev;
- port->custom_divisor = *clk / (16 * (*spd));
+ /* If current-speed was set, then try not to change it. */
+ if (spd)
+ port->custom_divisor = *clk / (16 * (*spd));
return 0;
}
--
1.5.2.1
^ permalink raw reply related
* [PATCH 2/3][POWERPC][V2] Xilinx: of_serial support for Xilinx uart 16550.
From: John Linn @ 2008-04-02 16:52 UTC (permalink / raw)
To: linuxppc-dev, grant.likely; +Cc: John Linn
In-Reply-To: <12071551354058-git-send-email-john.linn@xilinx.com>
The Xilinx 16550 uart core is not a standard 16550 because it uses
word-based addressing rather than byte-based addressing. With
additional properties it is compatible with the open firmware
'ns16550' compatible binding.
This code updates the of_serial driver to handle the reg-offset
and reg-shift properties to enable this core to be used.
Signed-off-by: John Linn <john.linn@xilinx.com>
---
Documentation/powerpc/booting-without-of.txt | 11 +++++++++++
drivers/serial/of_serial.c | 15 +++++++++++++--
2 files changed, 24 insertions(+), 2 deletions(-)
diff --git a/Documentation/powerpc/booting-without-of.txt b/Documentation/powerpc/booting-without-of.txt
index 87f4d84..af112d9 100644
--- a/Documentation/powerpc/booting-without-of.txt
+++ b/Documentation/powerpc/booting-without-of.txt
@@ -2539,6 +2539,17 @@ platforms are moved over to use the flattened-device-tree model.
differ between different families. May be
'virtex2p', 'virtex4', or 'virtex5'.
+ iv) Xilinx Uart 16550
+
+ Xilinx UART 16550 devices are very similar to the NS16550 such that they
+ use the ns16550 binding with properties to specify register spacing and
+ an offset from the base address.
+
+ Requred properties:
+ - clock-frequency : Frequency of the clock input
+ - reg-offset : A value of 3 is required
+ - reg-shift : A value of 2 is required
+
More devices will be defined as this spec matures.
VII - Specifying interrupt information for devices
diff --git a/drivers/serial/of_serial.c b/drivers/serial/of_serial.c
index 2efb892..af9ed48 100644
--- a/drivers/serial/of_serial.c
+++ b/drivers/serial/of_serial.c
@@ -30,7 +30,7 @@ static int __devinit of_platform_serial_setup(struct of_device *ofdev,
{
struct resource resource;
struct device_node *np = ofdev->node;
- const unsigned int *clk, *spd;
+ const unsigned int *clk, *spd, *reg_offset, *reg_shift;
int ret;
memset(port, 0, sizeof *port);
@@ -48,7 +48,18 @@ static int __devinit of_platform_serial_setup(struct of_device *ofdev,
}
spin_lock_init(&port->lock);
- port->mapbase = resource.start;
+
+ reg_offset = of_get_property(np, "reg-offset", NULL);
+ reg_shift = of_get_property(np, "reg-shift", NULL);
+
+ if (!reg_offset)
+ port->mapbase = resource.start;
+ else
+ port->mapbase = resource.start + *reg_offset;
+
+ if (reg_shift)
+ port->regshift = *reg_shift;
+
port->irq = irq_of_parse_and_map(np, 0);
port->iotype = UPIO_MEM;
port->type = type;
--
1.5.2.1
^ permalink raw reply related
* [PATCH 3/3][POWERPC][V2] Xilinx: boot support for Xilinx uart 16550.
From: John Linn @ 2008-04-02 16:52 UTC (permalink / raw)
To: linuxppc-dev, grant.likely; +Cc: John Linn
In-Reply-To: <12071551351007-git-send-email-john.linn@xilinx.com>
The Xilinx 16550 uart core is not a standard 16550 because it uses
word-based addressing rather than byte-based adressing. With
additional properties it is compatible with the open firmware
'ns16550' compatible binding.
This code updates the ns16550 driver to use the reg-offset property
so that the Xilinx UART 16550 can be used with it. The reg-shift
was already being handled.
Signed-off-by: John Linn <john.linn@xilinx.com>
---
arch/powerpc/boot/ns16550.c | 5 +++++
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/boot/ns16550.c b/arch/powerpc/boot/ns16550.c
index f8f1b2f..da9d2c2 100644
--- a/arch/powerpc/boot/ns16550.c
+++ b/arch/powerpc/boot/ns16550.c
@@ -56,6 +56,7 @@ int ns16550_console_init(void *devp, struct serial_console_data *scdp)
{
int n;
unsigned long reg_phys;
+ u32 reg_offset;
n = getprop(devp, "virtual-reg", ®_base, sizeof(reg_base));
if (n != sizeof(reg_base)) {
@@ -65,6 +66,10 @@ int ns16550_console_init(void *devp, struct serial_console_data *scdp)
reg_base = (void *)reg_phys;
}
+ n = getprop(devp, "reg-offset", ®_offset, sizeof(reg_offset));
+ if (n == sizeof(reg_offset))
+ reg_base += reg_offset;
+
n = getprop(devp, "reg-shift", ®_shift, sizeof(reg_shift));
if (n != sizeof(reg_shift))
reg_shift = 0;
--
1.5.2.1
^ permalink raw reply related
* Re: [Cbe-oss-dev] [PATCH] Cell OProfile: SPU mutex lock fix
From: Carl Love @ 2008-04-02 17:02 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: linuxppc-dev, cel, cbe-oss-dev, linux-kernel
In-Reply-To: <1207154567.7132.396.camel@carll-linux-desktop>
On Wed, 2008-04-02 at 09:42 -0700, Carl Love wrote:
> On Wed, 2008-04-02 at 07:21 +0200, Arnd Bergmann wrote:
> > On Tuesday 25 March 2008, Carl Love wrote:
> > > This patch fixes a bug in the code that records the SPU data and
> > > context switches. The buffer_mutex lock must be held when the
> > > kernel is adding data to the buffer between the kernel and the
> > > OProfile daemon. The lock is not being held in the current code
> > > base. This patch fixes the bug using work queues. The data to
> > > be passed to the daemon is caputured by the interrupt handler.
> > > The workqueue function is invoked to grab the buffer_mutex lock
> > > and add the data to the buffer.
> >
> > So what was the exact bug you're fixing with this? There was no
> > buffer_mutex before, so why do you need it now? Can't this be a
> > spinlock so you can get it from interrupt context instead of
> > using a workqueue?
>
> The generic OProfile code defines a mutex lock, called buffer_mutex, to
> protect the kernel/daemon data buffer from being writen by the kernal
> and simultaneously read by the Daemon. When adding a PPU sample the
> oprofile routine oprofile_add_ext_sample(pc, regs, i, is_kernel) is
> called from the interrupt context to request the sample be stored. The
> generic oprofile code takes care of passing the data to a non interrupt
> context where the mutex lock is held and the necessary sequence of data
> is written into the kernel/daemon data buffer. However, OProfile does
> not have any built in functions for handling the SPU. Hence, we have to
> implement the code to capture the data in the interrupt context, pass it
> to a non interrupt context and put it into the buffer. This was not
> done correctly in the original implementation. Specifically, the mutex
> lock was not being held.
>
> Writing data to the OProfile buffer consists of a sequence of items.
> For example when writing an SPU entry, first comes the escape code so
> the daemon knows this is a new entry. The next item is the SPU context
> switch code which says the data which will follow is the information
> about a new context. There is a different code to identify the data as
> an address sample. Finally the data about the SPU context switch is
> entered into the buffer. The issue is the OProfile daemon is read all
> of the entire sequence of items then process the data. Without the
> mutex lock, the daemon may read part of the sequence try to process it
> before everything is written into the buffer. When the daemon reads
> again, it doesn't see the escape code as the first item and isn't smart
> enough to realize it is part of a previous sequence. The generic
> OProfile code defines the mutex lock and calls it buffer_mutex. The
> OProfile kernel/daemon API uses the mutex lock. The mutex lock can only
> be held in a non interrupt context. The current implementation uses a
> spin lock to make sure the kernel writes each sequence if items into the
> buffer but since the API does not use a spin lock we have no way to
> prevent the daemon from reading the buffer until the entire sequence of
> items has been written to the buffer. Hence the need to hold the
> buffer_mutex lock which prevents the daemon from accessing the buffer.
>
> >
> > > Index: linux-2.6.25-rc4/arch/powerpc/oprofile/cell/spu_profiler.c
> > > ===================================================================
> > > --- linux-2.6.25-rc4.orig/arch/powerpc/oprofile/cell/spu_profiler.c
> > > +++ linux-2.6.25-rc4/arch/powerpc/oprofile/cell/spu_profiler.c
> > > @@ -16,6 +16,7 @@
> > > #include <linux/smp.h>
> > > #include <linux/slab.h>
> > > #include <asm/cell-pmu.h>
> > > +#include <linux/workqueue.h>
> > > #include "pr_util.h"
> > >
> >
> > Please keep #include statements in alphabetical order, with all linux/ files
> > before the asm/ files.
> >
> > > #define TRACE_ARRAY_SIZE 1024
> > > @@ -32,9 +33,19 @@ static unsigned int profiling_interval;
> > >
> > > #define SPU_PC_MASK 0xFFFF
> > >
> > > +/* The generic OProfile code uses the buffer_mutex to protect the buffer
> > > + * between the kernel and the daemon. The SPU code needs to use the buffer
> > > + * to ensure that the kernel SPU writes complete as a single block before
> > > + * being consumed by the daemon.
> > > + */
> > > +extern struct mutex buffer_mutex;
> > > +
> > > static DEFINE_SPINLOCK(sample_array_lock);
> > > unsigned long sample_array_lock_flags;
> > >
> > > +struct work_struct spu_record_wq;
> > > +extern struct workqueue_struct *oprofile_spu_wq;
> > > +
> > > void set_spu_profiling_frequency(unsigned int freq_khz, unsigned int cycles_reset)
> > > {
> > > unsigned long ns_per_cyc;
> >
> > Never put extern statements in the implementation, they describe the
> > interface between two parts of the code and should be inside of a
> > common header.
> >
> > Why do you want to have your own workqueue instead of using the
> > global one?
It is important that the data get context switch data get recorded as
quickly as possible to avoid dropping data unnecessarily. The PC
counter data for each SPU is ignored until the context switch record is
put into the kernel/daemon buffer. The API documentation says that
using a private workqueue has better performance then using the global
workqueue. There is a comment in the code about this, perhaps it is not
clear enough.
> >
> > > @@ -123,14 +134,14 @@ static int cell_spu_pc_collection(int cp
> > > return entry;
> > > }
> > >
> > > -
> > > -static enum hrtimer_restart profile_spus(struct hrtimer *timer)
> > > -{
> > > - ktime_t kt;
> > > +static void profile_spus_record_samples (struct work_struct *ws) {
> > > + /* This routine is called via schedule_work() to record the
> > > + * spu data. It must be run in a normal kernel mode to
> > > + * grab the OProfile mutex lock.
> > > + */
> > > int cpu, node, k, num_samples, spu_num;
> > >
> > > - if (!spu_prof_running)
> > > - goto stop;
> > > + mutex_lock(&buffer_mutex);
> > >
> > > for_each_online_cpu(cpu) {
> > > if (cbe_get_hw_thread_id(cpu))
> > > @@ -170,6 +181,20 @@ static enum hrtimer_restart profile_spus
> > > smp_wmb(); /* insure spu event buffer updates are written */
> > > /* don't want events intermingled... */
> > >
> > > + mutex_unlock(&buffer_mutex);
> > > +}
> > > +
> > > +static enum hrtimer_restart profile_spus(struct hrtimer *timer)
> > > +{
> > > + ktime_t kt;
> > > +
> > > +
> > > + if (!spu_prof_running)
> > > + goto stop;
> > > +
> > > + /* schedule the funtion to record the data */
> > > + schedule_work(&spu_record_wq);
> > > +
> > > kt = ktime_set(0, profiling_interval);
> > > if (!spu_prof_running)
> > > goto stop;
> >
> > This looks like you want to use a delayed_work rather than building your
> > own out of hrtimer and work. Is there any point why you want to use
> > an hrtimer?
>
> The current implementation uses the hrtimer to schedule when to read the
> trace buffer the next time. This patch does not change how the
> scheduling of the buffer reads is done. Yes, you could change the
> implementation to use workqueues instead. If you feel that it is better
> to use the workqueue then we could make that change. Not sure that
> making that change in this bug fix patch is appropriate. I would need
> to create a second patch for that change.
> >
> > > -static DEFINE_SPINLOCK(buffer_lock);
> > > +extern struct mutex buffer_mutex;
> > > +extern struct workqueue_struct *oprofile_spu_wq;
> > > +extern int calls_to_record_switch;
> > > +
> >
> > Again, public interfaces need to go to a header file, and should
> > have a name that identifies the interface. "buffer_mutex" is
> > certainly not a suitable name for a kernel-wide global variable!
>
> As stated earlier, the generic OProfile code defines the variable
> "buffer_mutex". Changing the name in the generic OProfile code is
> beyond the scope of this patch.
>
> >
> > > static DEFINE_SPINLOCK(cache_lock);
> > > static int num_spu_nodes;
> > > +
> > > int spu_prof_num_nodes;
> > > int last_guard_val[MAX_NUMNODES * 8];
> > > +int cnt_swtch_processed_flag[MAX_NUMNODES * 8];
> > > +
> > > +struct spus_profiling_code_data_s {
> > > + int num_spu_nodes;
> > > + struct work_struct spu_prof_code_wq;
> > > +} spus_profiling_code_data;
> > > +
> > > +struct spu_context_switch_data_s {
> > > + struct spu *spu;
> > > + unsigned long spu_cookie;
> > > + unsigned long app_dcookie;
> > > + unsigned int offset;
> > > + unsigned long objectId;
> > > + int valid_entry;
> > > +} spu_context_switch_data;
> >
> > I don't understand what these variables are really doing, but
> > having e.g. just one spu_context_switch_data for all the SPUs
> > doesn't seem to make much sense. What happens when two SPUs do
> > a context switch at the same time?
>
> This is the data same data that was being put into the event buffer
> directly from the interrupt context. We need to store the data that is
> only available in the interrupt context so the same data can be put into
> the buffer by the work queue function in the non interrupt context.
> This is the declaration of the data needed per SPU. Below in the
> spu_cntx_sw_data structure, we declare an array of entries so we can
> store the switch
oops, accidentally hit save when I tried to move the window. Sorry.
data on a per SPU basis as you alluded to.
> >
> > > +int calls_to_record_switch = 0;
> > > +int record_spu_start_flag = 0;
> > > +
> > > +struct spus_cntxt_sw_data_s {
> > > + int num_spu_nodes;
> > > + struct spu_context_switch_data_s spu_data[MAX_NUMNODES * 8];
> > > + struct work_struct spu_cntxt_work;
> > > +} spus_cntxt_sw_data;
> >
> > Something is very wrong if you need so many global variables!
The calls_to_record_switch variable is not used, my mistake for not
getting it out of the patch. The record_spu_stat_flag is used. It is
set in the spu_sync_start when SPU profiling is started. The first time
the work function is called to record SPU context switches it sees the
flag is set and writes the initial record to the daemon/kernel buffer
stating that this is an SPU profile run not a PPU profile run. The
daemon needs to know this as it effects how the postprocessing is done.
The initial record is only written once.
The spus_context_sw_data structure has the array per SPU for all off the
interrupt context data that was recorded and needs to be written to the
kernel/daemon buffer.
> >
> > > /* Container for caching information about an active SPU task. */
> > > struct cached_info {
> > > @@ -44,6 +73,8 @@ struct cached_info {
> > > struct kref cache_ref;
> > > };
> > >
> > > +struct workqueue_struct *oprofile_spu_wq;
> > > +
> > > static struct cached_info *spu_info[MAX_NUMNODES * 8];
> >
> > While you're cleaning this up, I guess the cached_info should
> > be moved into a pointer from struct spu as well, instead of
> > having this global variable here.
This would be a functional change and it belongs in a functional change
patch not in a bug fix patch.
> >
> > > @@ -375,16 +457,30 @@ int spu_sync_start(void)
> > > int k;
> > > int ret = SKIP_GENERIC_SYNC;
> > > int register_ret;
> > > - unsigned long flags = 0;
> > >
> > > spu_prof_num_nodes = number_of_online_nodes();
> > > num_spu_nodes = spu_prof_num_nodes * 8;
> > >
> > > - spin_lock_irqsave(&buffer_lock, flags);
> > > - add_event_entry(ESCAPE_CODE);
> > > - add_event_entry(SPU_PROFILING_CODE);
> > > - add_event_entry(num_spu_nodes);
> > > - spin_unlock_irqrestore(&buffer_lock, flags);
> > > + /* create private work queue, execution of work is time critical */
> > > + oprofile_spu_wq = create_workqueue("spu_oprofile");
> > > +
> > > + /* due to a race when the spu is already running stuff, need to
> > > + * set a flag to tell the spu context switch to record the start
> > > + * before recording the context switches.
> > > + */
> > > + record_spu_start_flag = 1;
> > > +
> > > + spus_profiling_code_data.num_spu_nodes = num_spu_nodes;
> > > +
> > > + /* setup work queue functiion for recording context switch info */
> > > + spus_cntxt_sw_data.num_spu_nodes = num_spu_nodes;
> > > + for (k = 0; k<(MAX_NUMNODES * 8); k++) {
> > > + spus_cntxt_sw_data.spu_data[k].valid_entry = 0;
> > > + cnt_swtch_processed_flag[k] = 0;
> > > + }
> > > +
> > > + INIT_WORK(&spus_cntxt_sw_data.spu_cntxt_work,
> > > + record_spu_process_switch);
> >
> > I would guess that you need one work struct per SPU instead of a global
> > one, if you want to pass the SPU pointer as an argument.
> >
> > Arnd <><
We only need one work struct because we have an array that contains the
data for each SPU that has done a context switch.
^ permalink raw reply
* Re: [PATCH 01/11] [POWERPC] bootwrapper: Allow specifying of image physical offset
From: Segher Boessenkool @ 2008-04-02 17:03 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <0F53B076-0A94-4A2D-8D9A-ED507B53ABE6@kernel.crashing.org>
> Ideally we get set the phys address the PHDR, but I'm not sure how to
> get the linker to do that.
I think you want to look at "AT" in the ld manual.
Segher
^ permalink raw reply
* Re: [RESEND3 PATCH] [POWERPC] mpc5200: Amalgamated DTS fixes and updates
From: Segher Boessenkool @ 2008-04-02 17:08 UTC (permalink / raw)
To: Bartlomiej Sieka; +Cc: linuxppc-dev
In-Reply-To: <20080402142417.5557.90153.stgit@pollux.denx.de>
> + lpb {
> + model = "fsl,lpb";
> + compatible = "fsl,lpb";
Please use a more descriptive name, if you can still change the binding.
"localplus" or something like that.
Maybe it's time to start an International Obfuscated Device Tree
Contest,
to serve as a warning by example?
:-)
Segher
^ permalink raw reply
* Re: [BUG] 2.6.25-rc8-mm1 kernel panic while bootup on powerpc
From: Kamalesh Babulal @ 2008-04-02 17:09 UTC (permalink / raw)
To: michael
Cc: linuxppc-dev, Andrew Morton, Badari Pulavarty, linux-kernel,
Balbir Singh
In-Reply-To: <1207120676.7349.11.camel@concordia.ozlabs.ibm.com>
Michael Ellerman wrote:
> On Wed, 2008-04-02 at 12:38 +0530, Kamalesh Babulal wrote:
>> Andrew Morton wrote:
>>> On Wed, 02 Apr 2008 11:55:36 +0530 Kamalesh Babulal <kamalesh@linux.vnet.ibm.com> wrote:
>>>
>>>> Hi Andrew,
>>>>
>>>> The 2.6.25-rc8-mm1 kernel panic's while bootup on the power machine(s).
>>>>
>>>> [ 0.000000] ------------[ cut here ]------------
>>>> [ 0.000000] kernel BUG at arch/powerpc/mm/init_64.c:240!
>>>> [ 0.000000] Oops: Exception in kernel mode, sig: 5 [#1]
>>>> [ 0.000000] SMP NR_CPUS=32 NUMA PowerMac
>>>> [ 0.000000] Modules linked in:
>>>> [ 0.000000] NIP: c0000000003d1dcc LR: c0000000003d1dc4 CTR: c00000000002b6ac
>>>> [ 0.000000] REGS: c00000000049b960 TRAP: 0700 Not tainted (2.6.25-rc8-mm1-autokern1)
>>>> [ 0.000000] MSR: 9000000000021032 <ME,IR,DR> CR: 44000088 XER: 20000000
>>>> [ 0.000000] TASK = c0000000003f9c90[0] 'swapper' THREAD: c000000000498000 CPU: 0
>>>> [ 0.000000] GPR00: c0000000003d1dc4 c00000000049bbe0 c0000000004989d0 0000000000000001
>>>> [ 0.000000] GPR04: d59aca40f0000000 000000000b000000 0000000000000010 0000000000000000
>>>> [ 0.000000] GPR08: 0000000000000004 0000000000000001 c00000027e520800 c0000000004bf0f0
>>>> [ 0.000000] GPR12: c0000000004bf020 c0000000003fa900 0000000000000000 0000000000000000
>>>> [ 0.000000] GPR16: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
>>>> [ 0.000000] GPR20: 0000000000000000 0000000000000000 0000000000000000 4000000001400000
>>>> [ 0.000000] GPR24: 00000000017d64b0 c0000000003d6250 0000000000000000 c000000000504000
>>>> [ 0.000000] GPR28: 0000000000000000 cf000000001f8000 0000000001000000 cf00000000000000
>>>> [ 0.000000] NIP [c0000000003d1dcc] .vmemmap_populate+0xb8/0xf4
>>>> [ 0.000000] LR [c0000000003d1dc4] .vmemmap_populate+0xb0/0xf4
>>>> [ 0.000000] Call Trace:
>>>> [ 0.000000] [c00000000049bbe0] [c0000000003d1dc4] .vmemmap_populate+0xb0/0xf4 (unreliable)
>>>> [ 0.000000] [c00000000049bc70] [c0000000003d2ee8] .sparse_mem_map_populate+0x38/0x60
>>>> [ 0.000000] [c00000000049bd00] [c0000000003c242c] .sparse_early_mem_map_alloc+0x54/0x94
>>>> [ 0.000000] [c00000000049bd90] [c0000000003c250c] .sparse_init+0xa0/0x20c
>>>> [ 0.000000] [c00000000049be50] [c0000000003ab7d0] .setup_arch+0x1ac/0x218
>>>> [ 0.000000] [c00000000049bee0] [c0000000003a36ac] .start_kernel+0xe0/0x3fc
>>>> [ 0.000000] [c00000000049bf90] [c000000000008594] .start_here_common+0x54/0xc0
>>>> [ 0.000000] Instruction dump:
>>>> [ 0.000000] 7fe3fb78 7ca02a14 4082000c 3860fff4 4800003c e92289c8 e96289c0 e9090002
>>>> [ 0.000000] e8eb0002 4bc575cd 60000000 78630fe0 <0b030000> 7ffff214 7fbfe840 7fe3fb78
>>>> [ 0.000000] ---[ end trace 31fd0ba7d8756001 ]---
>>>> [ 0.000000] Kernel panic - not syncing: Attempted to kill the idle task!
>>>>
>>> int __meminit vmemmap_populate(struct page *start_page,
>>> unsigned long nr_pages, int node)
>>> {
>>> unsigned long mode_rw;
>>> unsigned long start = (unsigned long)start_page;
>>> unsigned long end = (unsigned long)(start_page + nr_pages);
>>> unsigned long page_size = 1 << mmu_psize_defs[mmu_linear_psize].shift;
>>>
>>> mode_rw = _PAGE_ACCESSED | _PAGE_DIRTY | _PAGE_COHERENT | PP_RWXX;
>>>
>>> /* Align to the page size of the linear mapping. */
>>> start = _ALIGN_DOWN(start, page_size);
>>>
>>> for (; start < end; start += page_size) {
>>> int mapped;
>>> void *p;
>>>
>>> if (vmemmap_populated(start, page_size))
>>> continue;
>>>
>>> p = vmemmap_alloc_block(page_size, node);
>>> if (!p)
>>> return -ENOMEM;
>>>
>>> pr_debug("vmemmap %08lx allocated at %p, physical %08lx.\n",
>>> start, p, __pa(p));
>>>
>>> mapped = htab_bolt_mapping(start, start + page_size,
>>> __pa(p), mode_rw, mmu_linear_psize,
>>> mmu_kernel_ssize);
>>> =====> BUG_ON(mapped < 0);
>>> }
>>>
>>> return 0;
>>> }
>>>
>>> Beats me. pseries? Badari has been diddling with the bolted memory code
>>> in git-powerpc...
>> One of the machines is the Power5 and another is PowerMac G5, on which the
>> same kernel panic is seen.
>
> Can you enable DEBUG_LOW in arch/powerpc/platforms/pseries/lpar.c, that
> should show what's happening in hpte_insert().
>
> cheers
>
Just define DEBUG_LOW did not fetch and debug information, so added some printk to
htab_bolt_mapping () and pSeries_lpar_hpte_insert ()
[boot]0012 Setup Arch
htab_bolt_mapping (vstart cf00000000000000, vend cf00000001000000, pstart 3000000,mode 190, psize 4, ssize 0)
htab_bolt_mapping: calling c000000000888f00
_hpte_insert(group=252078, va=d59aca40f0000000, pa=0000000003000000, rflags=194, vflags=10, psize=4 ssize=0)
htab_bolt_mapping (vstart cf00000000000000, vend cf00000001000000, pstart 4000000,mode 190, psize 4, ssize 0)
htab_bolt_mapping: calling c000000000888f00
_hpte_insert(group=252078, va=d59aca40f0000000, pa=0000000004000000, rflags=194, vflags=10, psize=4 ssize=0)
htab_bolt_mapping (vstart cf00000000000000, vend cf00000001000000, pstart 5000000,mode 190, psize 4, ssize 0)
htab_bolt_mapping: calling c000000000888f00
_hpte_insert(group=252078, va=d59aca40f0000000, pa=0000000005000000, rflags=194, vflags=10, psize=4 ssize=0)
htab_bolt_mapping (vstart cf00000000000000, vend cf00000001000000, pstart 6000000,mode 190, psize 4, ssize 0)
htab_bolt_mapping: calling c000000000888f00
_hpte_insert(group=252078, va=d59aca40f0000000, pa=0000000006000000, rflags=194, vflags=10, psize=4 ssize=0)
htab_bolt_mapping (vstart cf00000000000000, vend cf00000001000000, pstart 8000000,mode 190, psize 4, ssize 0)
htab_bolt_mapping: calling c000000000888f00
_hpte_insert(group=252078, va=d59aca40f0000000, pa=0000000008000000, rflags=194, vflags=10, psize=4 ssize=0)
htab_bolt_mapping (vstart cf00000000000000, vend cf00000001000000, pstart 9000000,mode 190, psize 4, ssize 0)
htab_bolt_mapping: calling c000000000888f00
_hpte_insert(group=252078, va=d59aca40f0000000, pa=0000000009000000, rflags=194, vflags=10, psize=4 ssize=0)
htab_bolt_mapping (vstart cf00000000000000, vend cf00000001000000, pstart a000000,mode 190, psize 4, ssize 0)
htab_bolt_mapping: calling c000000000888f00
_hpte_insert(group=252078, va=d59aca40f0000000, pa=000000000a000000, rflags=194, vflags=10, psize=4 ssize=0)
htab_bolt_mapping (vstart cf00000000000000, vend cf00000001000000, pstart b000000,mode 190, psize 4, ssize 0)
htab_bolt_mapping: calling c000000000888f00
_hpte_insert(group=252078, va=d59aca40f0000000, pa=000000000b000000, rflags=194, vflags=10, psize=4 ssize=0)
htab_bolt_mapping (vstart cf00000000000000, vend cf00000001000000, pstart c000000,mode 190, psize 4, ssize 0)
htab_bolt_mapping: calling c000000000888f00
_hpte_insert(group=252078, va=d59aca40f0000000, pa=000000000c000000, rflags=194, vflags=10, psize=4 ssize=0)
------------[ cut here ]------------
kernel BUG at arch/powerpc/mm/init_64.c:240!
Oops: Exception in kernel mode, sig: 5 [#1]
SMP NR_CPUS=128 NUMA pSeries
Modules linked in:
NIP: c000000000774b88 LR: c000000000774b80 CTR: 0000000000000000
REGS: c0000000008f7950 TRAP: 0700 Not tainted (2.6.25-rc8-mm1-autotest)
MSR: 8000000000021032 <ME,IR,DR> CR: 24000088 XER: 00000001
TASK = c0000000007dffd0[0] 'swapper' THREAD: c0000000008f4000 CPU: 0
GPR00: c000000000774b80 c0000000008f7bd0 c0000000008f6c00 0000000000000001
GPR04: fffffffffffffffa 000000000000005f 000000000000005e 0000000000000477
GPR08: 00000009b346bb78 8000000006520800 fffffffffffffffa ffffffffffffffff
GPR12: 0000000024000082 c0000000007e0980 0000000000000000 c00000000069ab58
GPR16: 4000000001c00000 c0000000006993e8 0000000000000000 00000000002b1000
GPR20: 000000000237b450 c00000000077b450 000000000237b6c0 c00000000077b6c0
GPR24: c00000000069a5a0 0000000002700000 c0000000009b0000 0000000000000000
GPR28: cf000000001f8000 cf00000001000000 0000000001000000 cf00000000000000
NIP [c000000000774b88] .vmemmap_populate+0xbc/0x100
LR [c000000000774b80] .vmemmap_populate+0xb4/0x100
Call Trace:
[c0000000008f7bd0] [c000000000774b80] .vmemmap_populate+0xb4/0x100 (unreliable)
[c0000000008f7c70] [c0000000007757e4] .sparse_mem_map_populate+0x38/0x5c
[c0000000008f7d00] [c000000000762f14] .sparse_early_mem_map_alloc+0x54/0x94
[c0000000008f7d90] [c000000000763348] .sparse_init+0x1e8/0x224
[c0000000008f7e50] [c00000000074f428] .setup_arch+0x1ac/0x218
[c0000000008f7ee0] [c0000000007466bc] .start_kernel+0xe0/0x414
[c0000000008f7f90] [c000000000008594] .start_here_common+0x54/0xc0
Instruction dump:
7fe3fb78 7ca02a14 4082000c 3860fff4 48000040 e9228980 e9628988 e8e90002
e90b0002 4b8b712d 60000000 78630fe0 <0b030000> 7ffff214 7fbdf214 7fbfe040
---[ end trace 31fd0ba7d8756001 ]---
Kernel panic - not syncing: Attempted to kill the idle task!
--
Thanks & Regards,
Kamalesh Babulal,
Linux Technology Center,
IBM, ISTL.
^ permalink raw reply
* Re: [BUG] 2.6.25-rc8-mm1 kernel panic while bootup on powerpc
From: Badari Pulavarty @ 2008-04-02 18:15 UTC (permalink / raw)
To: Kamalesh Babulal; +Cc: linuxppc-dev, Andrew Morton, lkml, Balbir Singh
In-Reply-To: <47F3BDD4.1010905@linux.vnet.ibm.com>
On Wed, 2008-04-02 at 22:39 +0530, Kamalesh Babulal wrote:
> Michael Ellerman wrote:
> > On Wed, 2008-04-02 at 12:38 +0530, Kamalesh Babulal wrote:
> >> Andrew Morton wrote:
> >>> On Wed, 02 Apr 2008 11:55:36 +0530 Kamalesh Babulal <kamalesh@linux.vnet.ibm.com> wrote:
> >>>
> >>>> Hi Andrew,
> >>>>
> >>>> The 2.6.25-rc8-mm1 kernel panic's while bootup on the power machine(s).
> >>>>
> >>>> [ 0.000000] ------------[ cut here ]------------
> >>>> [ 0.000000] kernel BUG at arch/powerpc/mm/init_64.c:240!
> >>>> [ 0.000000] Oops: Exception in kernel mode, sig: 5 [#1]
> >>>> [ 0.000000] SMP NR_CPUS=32 NUMA PowerMac
> >>>> [ 0.000000] Modules linked in:
> >>>> [ 0.000000] NIP: c0000000003d1dcc LR: c0000000003d1dc4 CTR: c00000000002b6ac
> >>>> [ 0.000000] REGS: c00000000049b960 TRAP: 0700 Not tainted (2.6.25-rc8-mm1-autokern1)
> >>>> [ 0.000000] MSR: 9000000000021032 <ME,IR,DR> CR: 44000088 XER: 20000000
> >>>> [ 0.000000] TASK = c0000000003f9c90[0] 'swapper' THREAD: c000000000498000 CPU: 0
> >>>> [ 0.000000] GPR00: c0000000003d1dc4 c00000000049bbe0 c0000000004989d0 0000000000000001
> >>>> [ 0.000000] GPR04: d59aca40f0000000 000000000b000000 0000000000000010 0000000000000000
> >>>> [ 0.000000] GPR08: 0000000000000004 0000000000000001 c00000027e520800 c0000000004bf0f0
> >>>> [ 0.000000] GPR12: c0000000004bf020 c0000000003fa900 0000000000000000 0000000000000000
> >>>> [ 0.000000] GPR16: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
> >>>> [ 0.000000] GPR20: 0000000000000000 0000000000000000 0000000000000000 4000000001400000
> >>>> [ 0.000000] GPR24: 00000000017d64b0 c0000000003d6250 0000000000000000 c000000000504000
> >>>> [ 0.000000] GPR28: 0000000000000000 cf000000001f8000 0000000001000000 cf00000000000000
> >>>> [ 0.000000] NIP [c0000000003d1dcc] .vmemmap_populate+0xb8/0xf4
> >>>> [ 0.000000] LR [c0000000003d1dc4] .vmemmap_populate+0xb0/0xf4
> >>>> [ 0.000000] Call Trace:
> >>>> [ 0.000000] [c00000000049bbe0] [c0000000003d1dc4] .vmemmap_populate+0xb0/0xf4 (unreliable)
> >>>> [ 0.000000] [c00000000049bc70] [c0000000003d2ee8] .sparse_mem_map_populate+0x38/0x60
> >>>> [ 0.000000] [c00000000049bd00] [c0000000003c242c] .sparse_early_mem_map_alloc+0x54/0x94
> >>>> [ 0.000000] [c00000000049bd90] [c0000000003c250c] .sparse_init+0xa0/0x20c
> >>>> [ 0.000000] [c00000000049be50] [c0000000003ab7d0] .setup_arch+0x1ac/0x218
> >>>> [ 0.000000] [c00000000049bee0] [c0000000003a36ac] .start_kernel+0xe0/0x3fc
> >>>> [ 0.000000] [c00000000049bf90] [c000000000008594] .start_here_common+0x54/0xc0
> >>>> [ 0.000000] Instruction dump:
> >>>> [ 0.000000] 7fe3fb78 7ca02a14 4082000c 3860fff4 4800003c e92289c8 e96289c0 e9090002
> >>>> [ 0.000000] e8eb0002 4bc575cd 60000000 78630fe0 <0b030000> 7ffff214 7fbfe840 7fe3fb78
> >>>> [ 0.000000] ---[ end trace 31fd0ba7d8756001 ]---
> >>>> [ 0.000000] Kernel panic - not syncing: Attempted to kill the idle task!
> >>>>
> >>> int __meminit vmemmap_populate(struct page *start_page,
> >>> unsigned long nr_pages, int node)
> >>> {
> >>> unsigned long mode_rw;
> >>> unsigned long start = (unsigned long)start_page;
> >>> unsigned long end = (unsigned long)(start_page + nr_pages);
> >>> unsigned long page_size = 1 << mmu_psize_defs[mmu_linear_psize].shift;
> >>>
> >>> mode_rw = _PAGE_ACCESSED | _PAGE_DIRTY | _PAGE_COHERENT | PP_RWXX;
> >>>
> >>> /* Align to the page size of the linear mapping. */
> >>> start = _ALIGN_DOWN(start, page_size);
> >>>
> >>> for (; start < end; start += page_size) {
> >>> int mapped;
> >>> void *p;
> >>>
> >>> if (vmemmap_populated(start, page_size))
> >>> continue;
> >>>
> >>> p = vmemmap_alloc_block(page_size, node);
> >>> if (!p)
> >>> return -ENOMEM;
> >>>
> >>> pr_debug("vmemmap %08lx allocated at %p, physical %08lx.\n",
> >>> start, p, __pa(p));
> >>>
> >>> mapped = htab_bolt_mapping(start, start + page_size,
> >>> __pa(p), mode_rw, mmu_linear_psize,
> >>> mmu_kernel_ssize);
> >>> =====> BUG_ON(mapped < 0);
> >>> }
> >>>
> >>> return 0;
> >>> }
> >>>
> >>> Beats me. pseries? Badari has been diddling with the bolted memory code
> >>> in git-powerpc...
> >> One of the machines is the Power5 and another is PowerMac G5, on which the
> >> same kernel panic is seen.
> >
> > Can you enable DEBUG_LOW in arch/powerpc/platforms/pseries/lpar.c, that
> > should show what's happening in hpte_insert().
> >
> > cheers
> >
> Just define DEBUG_LOW did not fetch and debug information, so added some printk to
> htab_bolt_mapping () and pSeries_lpar_hpte_insert ()
>
> [boot]0012 Setup Arch
> htab_bolt_mapping (vstart cf00000000000000, vend cf00000001000000, pstart 3000000,mode 190, psize 4, ssize 0)
> htab_bolt_mapping: calling c000000000888f00
> _hpte_insert(group=252078, va=d59aca40f0000000, pa=0000000003000000, rflags=194, vflags=10, psize=4 ssize=0)
> htab_bolt_mapping (vstart cf00000000000000, vend cf00000001000000, pstart 4000000,mode 190, psize 4, ssize 0)
> htab_bolt_mapping: calling c000000000888f00
> _hpte_insert(group=252078, va=d59aca40f0000000, pa=0000000004000000, rflags=194, vflags=10, psize=4 ssize=0)
> htab_bolt_mapping (vstart cf00000000000000, vend cf00000001000000, pstart 5000000,mode 190, psize 4, ssize 0)
> htab_bolt_mapping: calling c000000000888f00
> _hpte_insert(group=252078, va=d59aca40f0000000, pa=0000000005000000, rflags=194, vflags=10, psize=4 ssize=0)
> htab_bolt_mapping (vstart cf00000000000000, vend cf00000001000000, pstart 6000000,mode 190, psize 4, ssize 0)
> htab_bolt_mapping: calling c000000000888f00
> _hpte_insert(group=252078, va=d59aca40f0000000, pa=0000000006000000, rflags=194, vflags=10, psize=4 ssize=0)
> htab_bolt_mapping (vstart cf00000000000000, vend cf00000001000000, pstart 8000000,mode 190, psize 4, ssize 0)
> htab_bolt_mapping: calling c000000000888f00
> _hpte_insert(group=252078, va=d59aca40f0000000, pa=0000000008000000, rflags=194, vflags=10, psize=4 ssize=0)
> htab_bolt_mapping (vstart cf00000000000000, vend cf00000001000000, pstart 9000000,mode 190, psize 4, ssize 0)
> htab_bolt_mapping: calling c000000000888f00
> _hpte_insert(group=252078, va=d59aca40f0000000, pa=0000000009000000, rflags=194, vflags=10, psize=4 ssize=0)
> htab_bolt_mapping (vstart cf00000000000000, vend cf00000001000000, pstart a000000,mode 190, psize 4, ssize 0)
> htab_bolt_mapping: calling c000000000888f00
> _hpte_insert(group=252078, va=d59aca40f0000000, pa=000000000a000000, rflags=194, vflags=10, psize=4 ssize=0)
> htab_bolt_mapping (vstart cf00000000000000, vend cf00000001000000, pstart b000000,mode 190, psize 4, ssize 0)
> htab_bolt_mapping: calling c000000000888f00
> _hpte_insert(group=252078, va=d59aca40f0000000, pa=000000000b000000, rflags=194, vflags=10, psize=4 ssize=0)
> htab_bolt_mapping (vstart cf00000000000000, vend cf00000001000000, pstart c000000,mode 190, psize 4, ssize 0)
> htab_bolt_mapping: calling c000000000888f00
> _hpte_insert(group=252078, va=d59aca40f0000000, pa=000000000c000000, rflags=194, vflags=10, psize=4 ssize=0)
>
> ------------[ cut here ]------------
> kernel BUG at arch/powerpc/mm/init_64.c:240!
> Oops: Exception in kernel mode, sig: 5 [#1]
> SMP NR_CPUS=128 NUMA pSeries
> Modules linked in:
> NIP: c000000000774b88 LR: c000000000774b80 CTR: 0000000000000000
> REGS: c0000000008f7950 TRAP: 0700 Not tainted (2.6.25-rc8-mm1-autotest)
> MSR: 8000000000021032 <ME,IR,DR> CR: 24000088 XER: 00000001
> TASK = c0000000007dffd0[0] 'swapper' THREAD: c0000000008f4000 CPU: 0
>
> GPR00: c000000000774b80 c0000000008f7bd0 c0000000008f6c00 0000000000000001
> GPR04: fffffffffffffffa 000000000000005f 000000000000005e 0000000000000477
> GPR08: 00000009b346bb78 8000000006520800 fffffffffffffffa ffffffffffffffff
> GPR12: 0000000024000082 c0000000007e0980 0000000000000000 c00000000069ab58
> GPR16: 4000000001c00000 c0000000006993e8 0000000000000000 00000000002b1000
> GPR20: 000000000237b450 c00000000077b450 000000000237b6c0 c00000000077b6c0
> GPR24: c00000000069a5a0 0000000002700000 c0000000009b0000 0000000000000000
> GPR28: cf000000001f8000 cf00000001000000 0000000001000000 cf00000000000000
>
> NIP [c000000000774b88] .vmemmap_populate+0xbc/0x100
> LR [c000000000774b80] .vmemmap_populate+0xb4/0x100
>
> Call Trace:
> [c0000000008f7bd0] [c000000000774b80] .vmemmap_populate+0xb4/0x100 (unreliable)
> [c0000000008f7c70] [c0000000007757e4] .sparse_mem_map_populate+0x38/0x5c
> [c0000000008f7d00] [c000000000762f14] .sparse_early_mem_map_alloc+0x54/0x94
> [c0000000008f7d90] [c000000000763348] .sparse_init+0x1e8/0x224
> [c0000000008f7e50] [c00000000074f428] .setup_arch+0x1ac/0x218
> [c0000000008f7ee0] [c0000000007466bc] .start_kernel+0xe0/0x414
> [c0000000008f7f90] [c000000000008594] .start_here_common+0x54/0xc0
>
> Instruction dump:
> 7fe3fb78 7ca02a14 4082000c 3860fff4 48000040 e9228980 e9628988 e8e90002
> e90b0002 4b8b712d 60000000 78630fe0 <0b030000> 7ffff214 7fbdf214 7fbfe040
> ---[ end trace 31fd0ba7d8756001 ]---
> Kernel panic - not syncing: Attempted to kill the idle task!
>
Kamalesh,
With your config, I am able to reproduce the problem. I haven't touched
that part of code. I can take a look at it. It looks like we are trying
to create mapping for same "vaddr" multiple times and we get failures
after few creates. I am not sure why we are trying to create so many
times with same vaddr.
Thanks,
Badari
^ permalink raw reply
* u-boot ppc440epx bootstrap configuration without eval board
From: Dave Cogley @ 2008-04-02 17:14 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 765 bytes --]
Hello,
We are using the new AMCC ppc440epx 667MHz chip and I am trying to get
u-boot to recognize the clock rate of the new chip (we were using the
533MHz). I notice in the cmd_sequoia.c module that there is an option to
setup some sort of strapping in the configuration FPGA that was present on
the evaluation card. We do not have this configuration FPGA present in our
production board. Is there some sort of build flag I can specify to
"hardwire" this bootstrap information? Or at least some I can tell u-boot
to startup with the 667MHz clock rate? I believe we are using option 7 in
the configuration array for the "bootstrap" command.
Thanks,
Dave Cogley
Software Engineer
Ultra Stereo Labs, Inc.
(805) 549-0161
mailto:dcogley@uslinc.com
[-- Attachment #2: Type: text/html, Size: 3297 bytes --]
^ permalink raw reply
* Re: [PATCH 1/3][POWERPC][V2] of_serial: Fix possible null dereference.
From: Grant Likely @ 2008-04-02 17:46 UTC (permalink / raw)
To: John Linn, Paul Mackerras; +Cc: linuxppc-dev
In-Reply-To: <20080402165216.8FD2BC9807F@mail21-dub.bigfish.com>
On Wed, Apr 2, 2008 at 10:52 AM, John Linn <john.linn@xilinx.com> wrote:
> From: Stephen Neuendorffer <stephen.neuendorffer@xilinx.com>
>
> The of_serial driver queries the current-speed property and attempts
> to use it to register the custom_divisor property of the uart_port.
> However, if current-speed is not set, then this code will dereference
> a bad pointer. The fix is to only set custom_divisor when a
> current-speed property appears in the device tree.
>
> Signed-off-by: Stephen Neuendorffer <stephen.neuendorffer@xilinx.com>
> Signed-off-by: John Linn <john.linn@xilinx.com>
Acked-by: Grant Likely <grant.likely@secretlab.ca>
Paul, can you please pick this one up for .25? It is pure bug fix.
Thanks,
g.
> ---
> drivers/serial/of_serial.c | 4 +++-
> 1 files changed, 3 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/serial/of_serial.c b/drivers/serial/of_serial.c
> index a64d858..2efb892 100644
> --- a/drivers/serial/of_serial.c
> +++ b/drivers/serial/of_serial.c
> @@ -56,7 +56,9 @@ static int __devinit of_platform_serial_setup(struct of_device *ofdev,
> port->flags = UPF_SHARE_IRQ | UPF_BOOT_AUTOCONF | UPF_IOREMAP
> | UPF_FIXED_PORT;
> port->dev = &ofdev->dev;
> - port->custom_divisor = *clk / (16 * (*spd));
> + /* If current-speed was set, then try not to change it. */
> + if (spd)
> + port->custom_divisor = *clk / (16 * (*spd));
>
> return 0;
> }
> --
> 1.5.2.1
>
>
>
>
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: [PATCH 3/3][POWERPC][V2] Xilinx: boot support for Xilinx uart 16550.
From: Grant Likely @ 2008-04-02 17:52 UTC (permalink / raw)
To: John Linn; +Cc: linuxppc-dev
In-Reply-To: <20080402165216.C835D1CF8088@mail12-sin.bigfish.com>
On Wed, Apr 2, 2008 at 10:52 AM, John Linn <john.linn@xilinx.com> wrote:
> The Xilinx 16550 uart core is not a standard 16550 because it uses
> word-based addressing rather than byte-based adressing. With
> additional properties it is compatible with the open firmware
> 'ns16550' compatible binding.
>
> This code updates the ns16550 driver to use the reg-offset property
> so that the Xilinx UART 16550 can be used with it. The reg-shift
> was already being handled.
>
> Signed-off-by: John Linn <john.linn@xilinx.com>
Acked-by: Grant Likely <grant.likely@secretlab.ca>
> ---
> arch/powerpc/boot/ns16550.c | 5 +++++
> 1 files changed, 5 insertions(+), 0 deletions(-)
>
> diff --git a/arch/powerpc/boot/ns16550.c b/arch/powerpc/boot/ns16550.c
> index f8f1b2f..da9d2c2 100644
> --- a/arch/powerpc/boot/ns16550.c
> +++ b/arch/powerpc/boot/ns16550.c
> @@ -56,6 +56,7 @@ int ns16550_console_init(void *devp, struct serial_console_data *scdp)
> {
> int n;
> unsigned long reg_phys;
> + u32 reg_offset;
>
> n = getprop(devp, "virtual-reg", ®_base, sizeof(reg_base));
> if (n != sizeof(reg_base)) {
> @@ -65,6 +66,10 @@ int ns16550_console_init(void *devp, struct serial_console_data *scdp)
> reg_base = (void *)reg_phys;
> }
>
> + n = getprop(devp, "reg-offset", ®_offset, sizeof(reg_offset));
> + if (n == sizeof(reg_offset))
> + reg_base += reg_offset;
> +
> n = getprop(devp, "reg-shift", ®_shift, sizeof(reg_shift));
> if (n != sizeof(reg_shift))
> reg_shift = 0;
> --
> 1.5.2.1
>
>
>
>
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: [PATCH 2/3][POWERPC][V2] Xilinx: of_serial support for Xilinx uart 16550.
From: Grant Likely @ 2008-04-02 18:00 UTC (permalink / raw)
To: John Linn; +Cc: linuxppc-dev
In-Reply-To: <20080402165222.2468414080A9@mail104-dub.bigfish.com>
On Wed, Apr 2, 2008 at 10:52 AM, John Linn <john.linn@xilinx.com> wrote:
> The Xilinx 16550 uart core is not a standard 16550 because it uses
> word-based addressing rather than byte-based addressing. With
> additional properties it is compatible with the open firmware
> 'ns16550' compatible binding.
>
> This code updates the of_serial driver to handle the reg-offset
> and reg-shift properties to enable this core to be used.
>
> Signed-off-by: John Linn <john.linn@xilinx.com>
Comments below...
> ---
> Documentation/powerpc/booting-without-of.txt | 11 +++++++++++
> drivers/serial/of_serial.c | 15 +++++++++++++--
> 2 files changed, 24 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/powerpc/booting-without-of.txt b/Documentation/powerpc/booting-without-of.txt
> index 87f4d84..af112d9 100644
> --- a/Documentation/powerpc/booting-without-of.txt
> +++ b/Documentation/powerpc/booting-without-of.txt
> @@ -2539,6 +2539,17 @@ platforms are moved over to use the flattened-device-tree model.
> differ between different families. May be
> 'virtex2p', 'virtex4', or 'virtex5'.
>
> + iv) Xilinx Uart 16550
> +
> + Xilinx UART 16550 devices are very similar to the NS16550 such that they
> + use the ns16550 binding with properties to specify register spacing and
> + an offset from the base address.
> +
> + Requred properties:
> + - clock-frequency : Frequency of the clock input
> + - reg-offset : A value of 3 is required
> + - reg-shift : A value of 2 is required
> +
> More devices will be defined as this spec matures.
>
> VII - Specifying interrupt information for devices
> diff --git a/drivers/serial/of_serial.c b/drivers/serial/of_serial.c
> index 2efb892..af9ed48 100644
> --- a/drivers/serial/of_serial.c
> +++ b/drivers/serial/of_serial.c
> @@ -30,7 +30,7 @@ static int __devinit of_platform_serial_setup(struct of_device *ofdev,
> {
> struct resource resource;
> struct device_node *np = ofdev->node;
> - const unsigned int *clk, *spd;
> + const unsigned int *clk, *spd, *reg_offset, *reg_shift;
These should really be u32's I believe; on 64 bit architectures this
will misbehave (not an immediate practical problem, but it's best to
be explicit about these things).
> int ret;
>
> memset(port, 0, sizeof *port);
> @@ -48,7 +48,18 @@ static int __devinit of_platform_serial_setup(struct of_device *ofdev,
> }
>
> spin_lock_init(&port->lock);
> - port->mapbase = resource.start;
> +
> + reg_offset = of_get_property(np, "reg-offset", NULL);
> + reg_shift = of_get_property(np, "reg-shift", NULL);
> +
> + if (!reg_offset)
> + port->mapbase = resource.start;
> + else
> + port->mapbase = resource.start + *reg_offset;
> +
> + if (reg_shift)
> + port->regshift = *reg_shift;
> +
This is a little unsafe since it doesn't check the property size, I'd
do the following instead:
port->mapbase = resource.start
/* Check for shifted address mapping */
prop = of_get_property(np, "reg-offset", &prop_size);
if (prop && (prop_size == sizeof(u32))
port->mapbase += *prop;
/* Check for registers offset within the devices address range */
prop = of_get_property(np, "reg-shift", &prop_size);
if (prop && (prop_size == sizeof(u32)))
port->regshift = *prop;
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* RE: u-boot ppc440epx bootstrap configuration without eval board
From: Dave Cogley @ 2008-04-02 18:03 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 1183 bytes --]
Disregard the boot strapping problem. It appears we are hardwired strapped
to use option "C" however my CPU is not being recognized as a 667MHz. Which
option should I be using for the 667MHz processor?
_____
From: Dave Cogley [mailto:dcogley@uslinc.com]
Sent: Wednesday, April 02, 2008 10:15 AM
To: 'linuxppc-embedded@ozlabs.org'
Subject: u-boot ppc440epx bootstrap configuration without eval board
Hello,
We are using the new AMCC ppc440epx 667MHz chip and I am trying to get
u-boot to recognize the clock rate of the new chip (we were using the
533MHz). I notice in the cmd_sequoia.c module that there is an option to
setup some sort of strapping in the configuration FPGA that was present on
the evaluation card. We do not have this configuration FPGA present in our
production board. Is there some sort of build flag I can specify to
"hardwire" this bootstrap information? Or at least some I can tell u-boot
to startup with the 667MHz clock rate? I believe we are using option 7 in
the configuration array for the "bootstrap" command.
Thanks,
Dave Cogley
Software Engineer
Ultra Stereo Labs, Inc.
(805) 549-0161
mailto:dcogley@uslinc.com
[-- Attachment #2: Type: text/html, Size: 5247 bytes --]
^ permalink raw reply
* RE: [PATCH 2/3][POWERPC][V2] Xilinx: of_serial support for Xilinx uart 16550.
From: John Linn @ 2008-04-02 18:20 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev
In-Reply-To: <fa686aa40804021100j13a7e223jde9d222df379b1f8@mail.gmail.com>
Sounds good, those are easy changes and make sense.
Since I'm a newbie, I don't know any better sometimes when I copy other
code that may not be as safe. =20
The same thing, of_get_property(np, "current-speed", NULL);, is done
right above my code I added. =20
Should the other code in the driver using the same method be fixed, or
just my patch?
Thanks for your patience,
John
-----Original Message-----
From: glikely@secretlab.ca [mailto:glikely@secretlab.ca] On Behalf Of
Grant Likely
Sent: Wednesday, April 02, 2008 12:00 PM
To: John Linn
Cc: linuxppc-dev@ozlabs.org
Subject: Re: [PATCH 2/3][POWERPC][V2] Xilinx: of_serial support for
Xilinx uart 16550.
On Wed, Apr 2, 2008 at 10:52 AM, John Linn <john.linn@xilinx.com> wrote:
> The Xilinx 16550 uart core is not a standard 16550 because it uses
> word-based addressing rather than byte-based addressing. With
> additional properties it is compatible with the open firmware
> 'ns16550' compatible binding.
>
> This code updates the of_serial driver to handle the reg-offset
> and reg-shift properties to enable this core to be used.
>
> Signed-off-by: John Linn <john.linn@xilinx.com>
Comments below...
> ---
> Documentation/powerpc/booting-without-of.txt | 11 +++++++++++
> drivers/serial/of_serial.c | 15 +++++++++++++--
> 2 files changed, 24 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/powerpc/booting-without-of.txt
b/Documentation/powerpc/booting-without-of.txt
> index 87f4d84..af112d9 100644
> --- a/Documentation/powerpc/booting-without-of.txt
> +++ b/Documentation/powerpc/booting-without-of.txt
> @@ -2539,6 +2539,17 @@ platforms are moved over to use the
flattened-device-tree model.
> differ between different families. May be
> 'virtex2p', 'virtex4', or 'virtex5'.
>
> + iv) Xilinx Uart 16550
> +
> + Xilinx UART 16550 devices are very similar to the NS16550 such
that they
> + use the ns16550 binding with properties to specify register
spacing and
> + an offset from the base address.
> +
> + Requred properties:
> + - clock-frequency : Frequency of the clock input
> + - reg-offset : A value of 3 is required
> + - reg-shift : A value of 2 is required
> +
> More devices will be defined as this spec matures.
>
> VII - Specifying interrupt information for devices
> diff --git a/drivers/serial/of_serial.c b/drivers/serial/of_serial.c
> index 2efb892..af9ed48 100644
> --- a/drivers/serial/of_serial.c
> +++ b/drivers/serial/of_serial.c
> @@ -30,7 +30,7 @@ static int __devinit
of_platform_serial_setup(struct of_device *ofdev,
> {
> struct resource resource;
> struct device_node *np =3D ofdev->node;
> - const unsigned int *clk, *spd;
> + const unsigned int *clk, *spd, *reg_offset, *reg_shift;
These should really be u32's I believe; on 64 bit architectures this
will misbehave (not an immediate practical problem, but it's best to
be explicit about these things).
> int ret;
>
> memset(port, 0, sizeof *port);
> @@ -48,7 +48,18 @@ static int __devinit
of_platform_serial_setup(struct of_device *ofdev,
> }
>
> spin_lock_init(&port->lock);
> - port->mapbase =3D resource.start;
> +
> + reg_offset =3D of_get_property(np, "reg-offset", NULL);
> + reg_shift =3D of_get_property(np, "reg-shift", NULL);
> +
> + if (!reg_offset)
> + port->mapbase =3D resource.start;
> + else
> + port->mapbase =3D resource.start + *reg_offset;
> +
> + if (reg_shift)
> + port->regshift =3D *reg_shift;
> +
This is a little unsafe since it doesn't check the property size, I'd
do the following instead:
port->mapbase =3D resource.start
/* Check for shifted address mapping */
prop =3D of_get_property(np, "reg-offset", &prop_size);
if (prop && (prop_size =3D=3D sizeof(u32))
port->mapbase +=3D *prop;
/* Check for registers offset within the devices address range */
prop =3D of_get_property(np, "reg-shift", &prop_size);
if (prop && (prop_size =3D=3D sizeof(u32)))
port->regshift =3D *prop;
Cheers,
g.
--=20
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: [BUG] 2.6.25-rc8-mm1 kernel panic while bootup on powerpc
From: Badari Pulavarty @ 2008-04-02 19:22 UTC (permalink / raw)
To: michael, yhlu.kernel
Cc: linuxppc-dev, Andrew Morton, Balbir Singh, lkml, Kamalesh Babulal
In-Reply-To: <1207120676.7349.11.camel@concordia.ozlabs.ibm.com>
On Wed, 2008-04-02 at 18:17 +1100, Michael Ellerman wrote:
> On Wed, 2008-04-02 at 12:38 +0530, Kamalesh Babulal wrote:
> > Andrew Morton wrote:
> > > On Wed, 02 Apr 2008 11:55:36 +0530 Kamalesh Babulal <kamalesh@linux.vnet.ibm.com> wrote:
> > >
> > >> Hi Andrew,
> > >>
> > >> The 2.6.25-rc8-mm1 kernel panic's while bootup on the power machine(s).
> > >>
> > >> [ 0.000000] ------------[ cut here ]------------
> > >> [ 0.000000] kernel BUG at arch/powerpc/mm/init_64.c:240!
> > >> [ 0.000000] Oops: Exception in kernel mode, sig: 5 [#1]
> > >> [ 0.000000] SMP NR_CPUS=32 NUMA PowerMac
> > >> [ 0.000000] Modules linked in:
> > >> [ 0.000000] NIP: c0000000003d1dcc LR: c0000000003d1dc4 CTR: c00000000002b6ac
> > >> [ 0.000000] REGS: c00000000049b960 TRAP: 0700 Not tainted (2.6.25-rc8-mm1-autokern1)
> > >> [ 0.000000] MSR: 9000000000021032 <ME,IR,DR> CR: 44000088 XER: 20000000
> > >> [ 0.000000] TASK = c0000000003f9c90[0] 'swapper' THREAD: c000000000498000 CPU: 0
> > >> [ 0.000000] GPR00: c0000000003d1dc4 c00000000049bbe0 c0000000004989d0 0000000000000001
> > >> [ 0.000000] GPR04: d59aca40f0000000 000000000b000000 0000000000000010 0000000000000000
> > >> [ 0.000000] GPR08: 0000000000000004 0000000000000001 c00000027e520800 c0000000004bf0f0
> > >> [ 0.000000] GPR12: c0000000004bf020 c0000000003fa900 0000000000000000 0000000000000000
> > >> [ 0.000000] GPR16: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
> > >> [ 0.000000] GPR20: 0000000000000000 0000000000000000 0000000000000000 4000000001400000
> > >> [ 0.000000] GPR24: 00000000017d64b0 c0000000003d6250 0000000000000000 c000000000504000
> > >> [ 0.000000] GPR28: 0000000000000000 cf000000001f8000 0000000001000000 cf00000000000000
> > >> [ 0.000000] NIP [c0000000003d1dcc] .vmemmap_populate+0xb8/0xf4
> > >> [ 0.000000] LR [c0000000003d1dc4] .vmemmap_populate+0xb0/0xf4
> > >> [ 0.000000] Call Trace:
> > >> [ 0.000000] [c00000000049bbe0] [c0000000003d1dc4] .vmemmap_populate+0xb0/0xf4 (unreliable)
> > >> [ 0.000000] [c00000000049bc70] [c0000000003d2ee8] .sparse_mem_map_populate+0x38/0x60
> > >> [ 0.000000] [c00000000049bd00] [c0000000003c242c] .sparse_early_mem_map_alloc+0x54/0x94
> > >> [ 0.000000] [c00000000049bd90] [c0000000003c250c] .sparse_init+0xa0/0x20c
> > >> [ 0.000000] [c00000000049be50] [c0000000003ab7d0] .setup_arch+0x1ac/0x218
> > >> [ 0.000000] [c00000000049bee0] [c0000000003a36ac] .start_kernel+0xe0/0x3fc
> > >> [ 0.000000] [c00000000049bf90] [c000000000008594] .start_here_common+0x54/0xc0
> > >> [ 0.000000] Instruction dump:
> > >> [ 0.000000] 7fe3fb78 7ca02a14 4082000c 3860fff4 4800003c e92289c8 e96289c0 e9090002
> > >> [ 0.000000] e8eb0002 4bc575cd 60000000 78630fe0 <0b030000> 7ffff214 7fbfe840 7fe3fb78
> > >> [ 0.000000] ---[ end trace 31fd0ba7d8756001 ]---
> > >> [ 0.000000] Kernel panic - not syncing: Attempted to kill the idle task!
> > >>
> > >
> > > int __meminit vmemmap_populate(struct page *start_page,
> > > unsigned long nr_pages, int node)
> > > {
> > > unsigned long mode_rw;
> > > unsigned long start = (unsigned long)start_page;
> > > unsigned long end = (unsigned long)(start_page + nr_pages);
> > > unsigned long page_size = 1 << mmu_psize_defs[mmu_linear_psize].shift;
> > >
> > > mode_rw = _PAGE_ACCESSED | _PAGE_DIRTY | _PAGE_COHERENT | PP_RWXX;
> > >
> > > /* Align to the page size of the linear mapping. */
> > > start = _ALIGN_DOWN(start, page_size);
> > >
> > > for (; start < end; start += page_size) {
> > > int mapped;
> > > void *p;
> > >
> > > if (vmemmap_populated(start, page_size))
> > > continue;
> > >
> > > p = vmemmap_alloc_block(page_size, node);
> > > if (!p)
> > > return -ENOMEM;
> > >
> > > pr_debug("vmemmap %08lx allocated at %p, physical %08lx.\n",
> > > start, p, __pa(p));
> > >
> > > mapped = htab_bolt_mapping(start, start + page_size,
> > > __pa(p), mode_rw, mmu_linear_psize,
> > > mmu_kernel_ssize);
> > > =====> BUG_ON(mapped < 0);
> > > }
> > >
> > > return 0;
> > > }
> > >
> > > Beats me. pseries? Badari has been diddling with the bolted memory code
> > > in git-powerpc...
> >
> > One of the machines is the Power5 and another is PowerMac G5, on which the
> > same kernel panic is seen.
>
> Can you enable DEBUG_LOW in arch/powerpc/platforms/pseries/lpar.c, that
> should show what's happening in hpte_insert().
>
> cheers
>
Okay. Found it.
Root cause is:
mm-make-mem_map-allocation-continuous.patch
and its friends in -mm.
You have to call sparse_init_one_section() on each pmap and usemap
as we allocate - since valid_section() depends on it (which is needed
by vmemmap_populate() to check if the section is populated or not).
On ppc, we need to call htab_bolted_mapping() on each section and
we need to skip existing sections.
These patches tried to group all allocations together and then later
calls sparse_init_one_section() - which is not good :(
Please let me know, if its doesn't make sense - I will try to explain
better :)
Thanks,
Badari
^ permalink raw reply
* ppc405ep and Ready enable in EBC0_BnAP register
From: ravi.rao @ 2008-04-02 18:35 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 2330 bytes --]
Hi All,
Our target is based on PPC405EP and we are using a TDMoIP chip on the
peripheral bus with chipselect 2. Since the access time to the chip is not
deterministic we are planning to use the Ready enable. By probing into
Chipselect and ready enable bits it looks like the chip select gets
extended untill the ready enable becomes 1 but the access crashes with a
Bus error.
But If I just set the twt to a very high value say 20 with ready enable
set to 0 then it works. Any pointers to understand what is happening
will be of great help.
####################### Screen Dump #################################
Data machine check in kernel mode.
PLB0: BEAR= 0xf8000000 ACR= 0x00000000 BESR= 0x00000000
PLB0 to OPB: BEAR= 0x01000000 BESR0= 0x00000000 BESR1= 0x00000000
Oops: machine check, sig: 7 [#5]
NIP: C90C69BC LR: C90C6AA4 CTR: 000003E0
REGS: c023ef50 TRAP: 0202 Not tainted (2.6.21)
MSR: 00029030 <EE,ME,IR,DR> CR: 84044408 XER: 00000007
TASK = c3fab050[666] 'cat' THREAD: c2710000
GPR00: 00000000 C2711650 C3FAB050 C2729000 C2711EAC 00000000 00000C00
C2711EA8
GPR08: 00000000 00000040 FFFFFFFF C9400000 44044408 100A54C0 03FF9C00
00000001
GPR16: 0000005E C01DA824 C02E7F78 C01E0C50 C2711EA8 C01E0C20 C2711EAC
C25DC320
GPR24: C2729000 00000000 C2711F20 C90C7FF4 C2729000 C2711EA8 C2711658
C2729000
Call Trace:
[C2711E80] [C90C6AA4]
[C2711EA0] [C009BA60]
[C2711EF0] [C0063E6C]
[C2711F10] [C00642C8]
[C2711F40] [C0002CB4]
Instruction dump:
bf210814 3b697ff4 90010834 817b006c 7c7f1b78 a00b0000 39200002 b0010008
380003ff 7c0903a6 3bc10008 7c0b4a2e <7c09f32e> 39290002 4200fff4 3c80c90c
Bus error
Thanks,
Ravishankar Govindarao
RFL Electronics Inc.
E-mail : Ravi.Rao@rflelect.com
Voice: 973.334.3100 Ext. 233
Fax: 973.334.3863
CONFIDENTIALITY NOTE
This e-mail, including any attachments, may contain confidential and/or
legally privileged information. The Information is intended only for the
use of the individual or entity named on this e-mail . If you are not the
intended recipient, you are hereby notified that any disclosure, copying,
distribution, or the taking of any action in reliance on the contents of
this transmitted Information is strictly prohibited. Further, if you are
not the intended recipient, please notify us by return e-mail and delete
the Information promptly.
[-- Attachment #2: Type: text/html, Size: 4149 bytes --]
^ permalink raw reply
* [PATCH] E500 Make steal_context SMP-safe.
From: Randy Vinson @ 2008-04-02 17:55 UTC (permalink / raw)
To: linuxppc-dev@ozlabs.org
>From c4923d80bbd40f91c7b402db37fabb4995632b7e Mon Sep 17 00:00:00 2001
From: Randy Vinson <rvinson@mvista.com>
Date: Tue, 1 Apr 2008 17:19:06 -0700
Subject: [PATCH] E500 Make steal_context SMP-safe.
When steal_context is used on SMP systems, it can steal a context in
use by one of the other processors. This patch adds context tracking to
prevent this as suggested by BenH.
Signed-off-by: Randy Vinson <rvinson@mvista.com>
---
Note: This is a proof-of-concept patch. This isn't my area of expertise,
so I'd greatly appreciate any guidance I can get. I'm considering the
use of for_each_online_cpu() instead of for_each_possible_cpu() and
possibly putting the changes under a CONFIG_SMP switch to prevent unnecessary
overhead in the non-SMP case.
Thx,
Randy Vinson
arch/powerpc/mm/mmu_context_32.c | 27 +++++++++++++++++++++++++++
include/asm-powerpc/mmu_context.h | 5 +++++
2 files changed, 32 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/mm/mmu_context_32.c b/arch/powerpc/mm/mmu_context_32.c
index cc32ba4..cf04aa8 100644
--- a/arch/powerpc/mm/mmu_context_32.c
+++ b/arch/powerpc/mm/mmu_context_32.c
@@ -34,6 +34,8 @@ unsigned long context_map[LAST_CONTEXT / BITS_PER_LONG + 1];
atomic_t nr_free_contexts;
struct mm_struct *context_mm[LAST_CONTEXT+1];
void steal_context(void);
+DEFINE_SPINLOCK(mm_lock);
+DEFINE_PER_CPU(struct mm_struct *, curr_mm);
#endif /* FEW_CONTEXTS */
/*
@@ -42,6 +44,9 @@ void steal_context(void);
void __init
mmu_context_init(void)
{
+#ifdef FEW_CONTEXTS
+ int cpu;
+#endif
/*
* Some processors have too few contexts to reserve one for
* init_mm, and require using context 0 for a normal task.
@@ -52,6 +57,8 @@ mmu_context_init(void)
next_mmu_context = FIRST_CONTEXT;
#ifdef FEW_CONTEXTS
atomic_set(&nr_free_contexts, LAST_CONTEXT - FIRST_CONTEXT + 1);
+ for_each_possible_cpu(cpu)
+ per_cpu(curr_mm, cpu) = NULL;
#endif /* FEW_CONTEXTS */
}
@@ -72,6 +79,24 @@ void
steal_context(void)
{
struct mm_struct *mm;
+ int cpu;
+ cpumask_t local_cpumask = cpumask_of_cpu(smp_processor_id());
+
+ do {
+ /* free up context `next_mmu_context' */
+ /* if we shouldn't free context 0, don't... */
+ if (next_mmu_context < FIRST_CONTEXT)
+ next_mmu_context = FIRST_CONTEXT;
+ mm = context_mm[next_mmu_context];
+ for_each_possible_cpu(cpu) {
+ if ((cpu != smp_processor_id()) &&
+ per_cpu(curr_mm, cpu) == mm) {
+ mm = NULL;
+ next_mmu_context = (next_mmu_context + 1) &
+ LAST_CONTEXT;
+ }
+ }
+ } while(!mm);
/* free up context `next_mmu_context' */
/* if we shouldn't free context 0, don't... */
@@ -80,5 +105,7 @@ steal_context(void)
mm = context_mm[next_mmu_context];
flush_tlb_mm(mm);
destroy_context(mm);
+ if (!cpus_equal(mm->cpu_vm_mask, local_cpumask))
+ flush_tlb_mm(mm);
}
#endif /* FEW_CONTEXTS */
diff --git a/include/asm-powerpc/mmu_context.h b/include/asm-powerpc/mmu_context.h
index 9102b8b..e083b25 100644
--- a/include/asm-powerpc/mmu_context.h
+++ b/include/asm-powerpc/mmu_context.h
@@ -113,6 +113,8 @@ extern unsigned long next_mmu_context;
extern atomic_t nr_free_contexts;
extern struct mm_struct *context_mm[LAST_CONTEXT+1];
extern void steal_context(void);
+extern spinlock_t mm_lock;
+DECLARE_PER_CPU(struct mm_struct *, curr_mm);
#endif
/*
@@ -125,6 +127,7 @@ static inline void get_mmu_context(struct mm_struct *mm)
if (mm->context.id != NO_CONTEXT)
return;
#ifdef FEW_CONTEXTS
+ spin_lock(&mm_lock);
while (atomic_dec_if_positive(&nr_free_contexts) < 0)
steal_context();
#endif
@@ -138,6 +141,8 @@ static inline void get_mmu_context(struct mm_struct *mm)
mm->context.id = ctx;
#ifdef FEW_CONTEXTS
context_mm[ctx] = mm;
+ per_cpu(curr_mm, smp_processor_id()) = mm;
+ spin_unlock(&mm_lock);
#endif
}
--
1.5.4.4.551.g1658c
^ permalink raw reply related
* Re: [PATCH] RTAS - adapt procfs interface
From: Nathan Lynch @ 2008-04-02 18:54 UTC (permalink / raw)
To: Paul Mackerras; +Cc: maxim, cbe-oss-dev, linuxppc-dev
In-Reply-To: <18419.29333.344126.231799@cargo.ozlabs.ibm.com>
Paul Mackerras wrote:
> Nathan Lynch writes:
>
> > I think this is better... the way these files are used is lame, but
> > this should preserve the existing behavior. I haven't yet tested
> > this, can you?
>
> Looks OK -- can I have a proper patch description and a signed-off-by
> line for this please?
Actually, my patch has the potentially undesirable consequence of
allowing only one of the three flash-related proc files to be open at
any time, whereas the previous behavior enforced exclusive open on a
per-file basis.
If you want something for 2.6.25, I think the patch Jens posted is
of lower risk.
^ permalink raw reply
* Re: u-boot ppc440epx bootstrap configuration without eval board
From: Stefan Roese @ 2008-04-02 19:00 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <000901c894eb$e0707170$2001a8c0@DCOGLEYNEW>
On Wednesday 02 April 2008, Dave Cogley wrote:
> Disregard the boot strapping problem. It appears we are hardwired strapped
> to use option "C" however my CPU is not being recognized as a 667MHz.
> Which option should I be using for the 667MHz processor?
First, this is the wrong mailing list for this discussion. Please post to the
U-Boot list instead.
But here some general comments:
The bootstrap controller has multiple configuration options. Some of them
result in hardwired frequencies (CPU, PLB, OPB...), and some of them load the
PLL setup from an I2C EEPROM. Using this bootstrap EEPROM is the most
flexible solution. If you have only option "C", then you hardwired to 533MHz.
There is no way to "detect" which frequency this CPU is labeled.
But it *is* possible to reconfigure the PLL from within U-Boot an reset the
PPC to run with this different PLL setup. I just recently added some code the
u-boot-ppc4xx custodian repository.
Let's continue this thread on the U-Boot list.
Best regards,
Stefan
=====================================================================
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: office@denx.de
=====================================================================
^ permalink raw reply
* Re: [PATCH 2/3][POWERPC][V2] Xilinx: of_serial support for Xilinx uart 16550.
From: Sergei Shtylyov @ 2008-04-02 19:19 UTC (permalink / raw)
To: John Linn; +Cc: linuxppc-dev
In-Reply-To: <20080402165222.2468414080A9@mail104-dub.bigfish.com>
Hello.
John Linn wrote:
> The Xilinx 16550 uart core is not a standard 16550 because it uses
> word-based addressing rather than byte-based addressing. With
> additional properties it is compatible with the open firmware
> 'ns16550' compatible binding.
> This code updates the of_serial driver to handle the reg-offset
> and reg-shift properties to enable this core to be used.
> Signed-off-by: John Linn <john.linn@xilinx.com>
> diff --git a/Documentation/powerpc/booting-without-of.txt b/Documentation/powerpc/booting-without-of.txt
> index 87f4d84..af112d9 100644
> --- a/Documentation/powerpc/booting-without-of.txt
> +++ b/Documentation/powerpc/booting-without-of.txt
> @@ -2539,6 +2539,17 @@ platforms are moved over to use the flattened-device-tree model.
> differ between different families. May be
> 'virtex2p', 'virtex4', or 'virtex5'.
>
> + iv) Xilinx Uart 16550
> +
> + Xilinx UART 16550 devices are very similar to the NS16550 such that they
> + use the ns16550 binding with properties to specify register spacing and
> + an offset from the base address.
> +
> + Requred properties:
> + - clock-frequency : Frequency of the clock input
> + - reg-offset : A value of 3 is required
I'm proposing you to use the already existing "big-endian" property ISO
"reg-offset" (used in the nodes describing OpenPIC, for example).
WBR, Sergei
^ permalink raw reply
* Two MPC8641D's on a single JTAG chain with BDI2000/3000. Anyone got it to work?
From: Phil Terry @ 2008-04-02 19:14 UTC (permalink / raw)
To: linuxppc-dev
Hi Guys'n'Gals,
We have a board with two Freescale MPC8641D chips (ie four cores, two in
each chip) on a single jtag chain, nothing else on the chain. We are
unable to get BDI and WindRiver jtag debuggers to work with both chips,
only the second (last) chip works. With the BDI we can configure to work
with both cores in the second chip, with windriver only one core in
second chip configuration works.
If we split the jtag chain in the lab we can work with each processor
independently with no problems. We want both to work however.
On the BDI if we configure predecessor 1,8, successor 0,0 we can talk to
the second chip as expected, but if we try predecessor 0,0 successor 1,8
to talk to the first chip we get nothing.
Is there something else we need to configure in either the BDM or the
Freescale chip to get this to work?
Any suggestions or pointers to helpful resources welcome, either
privately or to the list if this isn't too far off topic.
Cheers
Phil
^ permalink raw reply
* Re: [PATCH 2/3][POWERPC][V2] Xilinx: of_serial support for Xilinx uart 16550.
From: Grant Likely @ 2008-04-02 19:27 UTC (permalink / raw)
To: John Linn; +Cc: linuxppc-dev
In-Reply-To: <20080402182023.8FA7318B808D@mail52-dub.bigfish.com>
On Wed, Apr 2, 2008 at 12:20 PM, John Linn <John.Linn@xilinx.com> wrote:
> Sounds good, those are easy changes and make sense.
>
> Since I'm a newbie, I don't know any better sometimes when I copy other
> code that may not be as safe.
>
> The same thing, of_get_property(np, "current-speed", NULL);, is done
> right above my code I added.
>
> Should the other code in the driver using the same method be fixed, or
> just my patch?
It would be good to fix the other code, but not in this patch. Write
another patch to fix that.
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* RE: Ethernet Jumbo Frames
From: Rick Moleres @ 2008-04-02 21:15 UTC (permalink / raw)
To: Darcy Watkins, LinuxPPC-Embedded
In-Reply-To: <D61182AC8012EA4EBC531B3AF23BE109582F00@tranzeo-mail2.12stewart.tranzeo.com>
Sure, it can be done. The Xilinx 10/100 Ethernet drivers have jumbo
frame support in MontaVista/WindRiver Linux. As long as both ends are
talking jumbo frames, works just fine.
-Rick
-----Original Message-----
From: linuxppc-embedded-bounces+moleres=3Dxilinx.com@ozlabs.org
[mailto:linuxppc-embedded-bounces+moleres=3Dxilinx.com@ozlabs.org] On
Behalf Of Darcy Watkins
Sent: Monday, March 31, 2008 2:48 PM
To: LinuxPPC-Embedded
Subject: Ethernet Jumbo Frames
Has anyone on this list ever been given a requirement to implement
support for ethernet frames larger than the standard MTU of 1500? ...
... for normal 10/100 Ethernet? ... not gigabit.
The application is to support certain encapsulation protocols without
imposing smaller than 1500 byte MTU restrictions on the innermost
protocol.
I have been tasked to investigate this for a system based on PPC405EP.
Can it be done using the IBM EMAC, Linux drivers, etc?
Regards,
Darcy
_______________________________________________
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
^ permalink raw reply
* Re: u-boot ppc440epx bootstrap configuration without eval board
From: Wolfgang Denk @ 2008-04-02 21:16 UTC (permalink / raw)
To: Dave Cogley; +Cc: linuxppc-embedded
In-Reply-To: <000901c894eb$e0707170$2001a8c0@DCOGLEYNEW>
In message <000901c894eb$e0707170$2001a8c0@DCOGLEYNEW> you wrote:
>
> Disregard the boot strapping problem. It appears we are hardwired strapped
> to use option "C" however my CPU is not being recognized as a 667MHz. Which
> option should I be using for the 667MHz processor?
U-Boot related questions are off topic here. You should try the
u-boot-users mailing list instead...
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
When the ax entered the forest, the trees said, "The handle is one of
us!" -- Turkish proverb
^ permalink raw reply
* RE: Ethernet Jumbo Frames
From: Darcy Watkins @ 2008-04-02 21:32 UTC (permalink / raw)
To: LinuxPPC-Embedded
In-Reply-To: <20080402211552.729E82B007F@mail93-dub.bigfish.com>
Thanks for the comments...
I have hacked the IBM EMAC driver (Xenomai-2.3.0 Real Time Linux
2.6.19.2) and got jumbo frames to pass back and forth between two such
embedded boards. Checked it using ping, iperf and httpd / wget file
transfer with md5sum check.
Still have to clean things up a bit and do some more tests before I can
share it as a patch.
Regards,
Darcy
-----Original Message-----
Sure, it can be done. The Xilinx 10/100 Ethernet drivers have jumbo
frame support in MontaVista/WindRiver Linux. As long as both ends are
talking jumbo frames, works just fine.
-Rick
-----Original Message-----
We've done it for our 2.4 based kernel that runs on a Freescale MPC8270.
10/100/1000 doesn't really make any difference. For us the trick was to
support receving jumbo frames in multiple RX BufDescriptors (because our
MPC8270 FCC eth driver pre-allocates 2k buffers per RX BD).
For transmitting hardly any changes were necessary.
From linux (driver) standpoint there should be no problems,
the question is whether your ethernet MAC (IBM EMAC) properly supports
it.
hth,
N. van Bolhuis.
^ 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