* RTC/I2C problems
From: kevin morizur @ 2006-04-11 8:20 UTC (permalink / raw)
To: linuxppc-embedded
Hi everybody.
I have a problem with my RTC, i work on a MEN A12 board with MPC8245 and
when my kernel start it takes 8 min to run. I have find the problem but i
don't know how to solve it. In time.c the function time_init execute the
following lines :
if (__USE_RTC()) {
/* 601 processor: dec counts down by 128 every 128ns */
tb_ticks_per_jiffy = DECREMENTER_COUNT_601;
/* mulhwu_scale_factor(1000000000, 1000000) is 0x418937 */
tb_to_us = 0x0x418937;
} else {
ppc_md.calibrate_decr();
tb_to_ns_scale = mulhwu(tb_to_us, 1000 << 10);
}
this is the ppc_md.calibrate_decr() function that takes a lot of time and i
don't know how to solve the problem. USE_RTC is fixed at 0 for 6xx config
maybe it must be at 1 ? My RTC run with SMBus (I2C). I work with ELDK 4.0
and linux 2.6.15.
Thanks in advance.
Regards.
_________________________________________________________________
Tout savoir sur la sécurité de vos enfants sur Internet !
http://go.msn.fr/10-channel/80-security/protection/default.asp
^ permalink raw reply
* init issue on linux 2.4 devel and busybox
From: jean-francois.hasson @ 2006-04-11 7:25 UTC (permalink / raw)
To: linuxppc-embedded
Hi,
I have been working on porting linux 2.4 devel to the ml403 board. It boots
well and then it goes on the CompactFlash to get the root filesystem where
the executables are from busybox. The init program is found and launches
well however the message is that init.d/rcS can't be found. I have looked
up my inittab file and the first line is ::sysinit:/etc/init.d/rcS. I do
not understand why init can't find the rcS file when it seems correct in
inittab and I have checked that the file rcS is in /etc/init.d. Does anyone
have an idea as to what might be wrong ?
Thanks,
JF Hasson
#
This e-mail and any attached documents may contain confidential or proprietary information. If you are not the intended recipient, please advise the sender immediately and delete this e-mail and all attached documents from your computer system. Any unauthorised disclosure, distribution or copying hereof is prohibited.
Ce courriel et les documents qui y sont attaches peuvent contenir des informations confidentielles. Au cas ou vous ne seriez pas le destinataire de ce courriel, vous etes prie d'en informer l'expediteur immediatement et de le detruire ainsi que tous les documents attaches de votre systeme informatique. Toute divulgation, distribution ou copie du present courriel et des documents attaches sans autorisation prealable de son emetteur est interdite.
#
^ permalink raw reply
* Re: MPC83xx: CF access in True IDE mode
From: Kumar Gala @ 2006-04-11 4:11 UTC (permalink / raw)
To: SIP COP 009; +Cc: linuxppc-embedded
In-Reply-To: <5a4792c00604101600v37616adao2f2598483a65e4d@mail.gmail.com>
On Apr 10, 2006, at 6:00 PM, SIP COP 009 wrote:
> Hi !
>
> I am looking out for some pointers to get CF working in the TRUE
> IDE mode on Linux2.6
>
> Any pointers and help would be greatly appreciated.
There was a driver posted to the linux kernel list for using CF on a
localbus.
- k
^ permalink raw reply
* Re: Create permanent mapping from PCI bus to region of physical memory
From: David Hawkins @ 2006-04-11 3:52 UTC (permalink / raw)
To: Howard, Marc; +Cc: linuxppc-embedded
In-Reply-To: <91B22F93A880FA48879475E134D6F0BE386FBD@CA1EXCLV02.adcorp.kla-tencor.com>
> Not if you're tight on routing resouces and/or design time ;-)
Yep, understood.
> Dave, I appreciate your input but scatter/gather just isn't
> an option here for a variety of reasons. Bandwidth/complexity/
> latency/time to design/time to debug/FPGA density all
> factor into this decision. BTW we're talking 66/64 PCI-X;
> 33/32 PCI isn't nearly fast enough.
No problem.
> Nope, I disagree. The MMU isn't involved here at all. I'm
> talking about setting up the PIM (PCI Inbound Map) via
> a system call as opposed to just writing it directly.
The MMU is involved since its responsible for all memory,
i.e., Linux is told that all physical memory is under
its control. I haven't looked at the PCI inbound map,
but I would assume that it can be setup to say map all
of the incoming PCI addresses to all of the SDRAM
addresses, or some block thereof. So the FPGA can see physical
pages that Linux is busy swapping data into and out of.
What you are wanting to do is tell Linux to lay-off
managing a block of SDRAM, but make it visible to the
kernel as a memory area.
So, you need the kernel to setup page tables that map
to those physical addresses and you need to tell Linux
not to treat them like it does the rest of SDRAM.
So I believe the MMU/page tables are involved.
> I really can't go into detail about my application for a
> variety of reasons (both technical and legal) but suffice
> it to say that 16 MB is just the starting point.
No sweat, it never hurts to ask.
> I guess I'll dig a little deeper into the source to see
> where the kernel does the PIM mapping. Re-architecting
> our app at this stage just isn't a practical consideration.
You always have the hack of reserving a block of memory
at the top of SDRAM, i.e., lie to Linux and tell it it
has less memory. It sounds like that might be the least
effort. Rubini has an example of how to do that.
Dave
^ permalink raw reply
* RE: Create permanent mapping from PCI bus to region of physical memory
From: Howard, Marc @ 2006-04-11 3:42 UTC (permalink / raw)
To: David Hawkins; +Cc: linuxppc-embedded
In-Reply-To: <443B1EE9.5030104@ovro.caltech.edu>
[-- Attachment #1: Type: text/plain, Size: 3052 bytes --]
>> The periperal is an FPGA. No, there is no internal processor;
>> everything is coded in Verilog.
>>
>> Scatter/gather isn't a viable option because of this.
>Er, why not, its an FPGA, everything is possible :)
Not if you're tight on routing resouces and/or design time ;-)
>So you have a PCI core, since you are planning to write to
>the host memory space, its a Bus Master PCI core.
>Who's FPGA, Altera, Xilinx, or someone else?
Xilinx Virtex 4, no internal PPC. The vendor really isn't
germain to the problem at hand however.
>> Additionally non-contiguous memory would reduce bandwidth
>> and increase FPGA design complexity.
>Not necessarily. If the target is using bus master DMA to
>write to the host memory, then you can hit pretty close
>to the bandwidth of the PCI bus. If you are DMAing in
>big blocks, the overhead of a block change isn't too much.
>I did tests with the 440EP using a DMA controller on an
>adapter board and found that the PCI bridge in the 440EP
>was the limiting factor, i.e., for a 33MHz 32-bit bus
>with a potential for 132MB/s, the *best* you can do is
>about 40MB/s since the bridge only accepts data in cache
>line sizes before sending a retry to the target. I can
>send you those results.
Dave, I appreciate your input but scatter/gather just isn't
an option here for a variety of reasons. Bandwidth/complexity/
latency/time to design/time to debug/FPGA density all
factor into this decision. BTW we're talking 66/64 PCI-X;
33/32 PCI isn't nearly fast enough.
>Randomly accessible from where; the host or an I/O interface
>at the FPGA. The pages can be made to appear contiguous to
>a host processor user-space process using the nopage callback
>of the VMA.
>From the point of view of the FPGA.
>> I realize this isn't a standard linux request but having
>> fixed, linear memory is quite common in embedded apps. There
>> should be a way to create this mapping in the 440GX's hardware
>> and I'm just looking for a system call (if there is one) to
>> implement it.
>Alas, this is one of the concessions one must make if you
>want to use a processor that enables the MMU.
Nope, I disagree. The MMU isn't involved here at all. I'm
talking about setting up the PIM (PCI Inbound Map) via
a system call as opposed to just writing it directly.
>However,
>I don't see any fundamental limitation in the design
>that would preclude a little extra work on the FPGA.
>But, it does require additional Verilog to support
>the flexibility. The long-term advantage is that you
>don't have to provide a hack (eg. reserve a block of
>high-memory under Linux).
I really can't go into detail about my application for a
variety of reasons (both technical and legal) but suffice
it to say that 16 MB is just the starting point.
I guess I'll dig a little deeper into the source to see
where the kernel does the PIM mapping. Re-architecting
our app at this stage just isn't a practical consideration.
Thanks again,
Marc
[-- Attachment #2: Type: text/html, Size: 3973 bytes --]
^ permalink raw reply
* Re: Create permanent mapping from PCI bus to region of physical memory
From: David Hawkins @ 2006-04-11 3:13 UTC (permalink / raw)
To: Howard, Marc; +Cc: linuxppc-embedded
In-Reply-To: <91B22F93A880FA48879475E134D6F0BE386FBC@CA1EXCLV02.adcorp.kla-tencor.com>
Hi Marc,
> The periperal is an FPGA. No, there is no internal processor;
> everything is coded in Verilog.
>
> Scatter/gather isn't a viable option because of this.
Er, why not, its an FPGA, everything is possible :)
So you have a PCI core, since you are planning to write to
the host memory space, its a Bus Master PCI core.
Who's FPGA, Altera, Xilinx, or someone else?
> Additionally non-contiguous memory would reduce bandwidth
> and increase FPGA design complexity.
Not necessarily. If the target is using bus master DMA to
write to the host memory, then you can hit pretty close
to the bandwidth of the PCI bus. If you are DMAing in
big blocks, the overhead of a block change isn't too much.
I did tests with the 440EP using a DMA controller on an
adapter board and found that the PCI bridge in the 440EP
was the limiting factor, i.e., for a 33MHz 32-bit bus
with a potential for 132MB/s, the *best* you can do is
about 40MB/s since the bridge only accepts data in cache
line sizes before sending a retry to the target. I can
send you those results.
> The data must be contignuous because
> of these reasons and the need for the data to be randomly
> accessible from the outside using simple address arithmetic.
Randomly accessible from where; the host or an I/O interface
at the FPGA. The pages can be made to appear contiguous to
a host processor user-space process using the nopage callback
of the VMA.
> I realize this isn't a standard linux request but having
> fixed, linear memory is quite common in embedded apps. There
> should be a way to create this mapping in the 440GX's hardware
> and I'm just looking for a system call (if there is one) to
> implement it.
Alas, this is one of the concessions one must make if you
want to use a processor that enables the MMU. However,
I don't see any fundamental limitation in the design
that would preclude a little extra work on the FPGA.
But, it does require additional Verilog to support
the flexibility. The long-term advantage is that you
don't have to provide a hack (eg. reserve a block of
high-memory under Linux).
So how about this concession. If Linux lets you alloc_pages
in 2MB max chunks, create 8 address decode regions on your
FPGA. Provide the host access to the 8 address registers.
When the Linux driver is installed, the driver alloc_pages
8 times and loads the PCI address of those regions into
the 8 registers.
On the FPGA side of things create a flat 16MB region, as
an address passes through a 2MB block, it changes the PCI
address it decodes to. So, your FPGA believes it has
a 16MB continuous block, and Linux can supply the memory
as 8 non-contiguous chunks. Back in user-space on Linux,
the nopage VMA call is used to map a page-at-a-time
and the 2MB regions appear as a 16MB contiguous region to
user-space. (There are probably other ways to make user
space see it as one block too)
Cheers
Dave
^ permalink raw reply
* RE: Create permanent mapping from PCI bus to region of physical memory
From: Howard, Marc @ 2006-04-11 2:56 UTC (permalink / raw)
To: David Hawkins; +Cc: linuxppc-embedded
In-Reply-To: <443B0718.3050001@ovro.caltech.edu>
[-- Attachment #1: Type: text/plain, Size: 2082 bytes --]
Howard, Marc wrote:
>> Hi,
>>
>> I'm working on a PPC440GX based board in which a PCI based peripheral
>> communicates with the host via a shared region of processor memory. The
>> peripheral will read and write this region autonomously. Because of
>> this I need a fixed mapping FROM the PCI bus TO system memory.
>>
>> It's easy enough to rope off the top 16 MB or so of system physical
>> memory by lying to linux in the boot arguments. What I can't seem find
>> is a system call to use to create a fixed, permanent mapping of PPC
>> memory as seen from the PCI bus.
>>
>> Has anyone out there done this and could share a code snippet with me?
>>
>Hi Marc,
>So the PPC440GX is the host, but what is the peripheral, and
>what restricts it to require a fixed address? Can it handle
>a set of fixed addresses, eg. a scatter-gather buffer setup
>by the host? Can the host and peripheral communicate in any
>other way, eg. when the peripheral changes something in the
>shared memory, surely it has to interrupt the host to let it
>know?
>Does the peripheral contain a CPU, if thats the case, then
>the host and peripheral could also maintain a smaller region
>that contains addresses of other pages, i.e., no need to
>restrict the design to a single block of memory, you just
>need a page of pointers to other shared blocks of pages.
Dave,
The periperal is an FPGA. No, there is no internal processor;
everything is coded in Verilog.
Scatter/gather isn't a viable option because of this. Additionally
non-contiguous memory would reduce bandwidth and increase
FPGA design complexity. The data must be contignuous because
of these reasons and the need for the data to be randomly
accessible from the outside using simple address arithmetic.
I realize this isn't a standard linux request but having
fixed, linear memory is quite common in embedded apps. There
should be a way to create this mapping in the 440GX's hardware
and I'm just looking for a system call (if there is one) to
implement it.
Thanks,
Marc
[-- Attachment #2: Type: text/html, Size: 2869 bytes --]
^ permalink raw reply
* Re: Oops: machine check, sig: 7 [#1] - 16-bit Pccard - SOLVED!!!
From: Benjamin Herrenschmidt @ 2006-04-11 1:30 UTC (permalink / raw)
To: Daniel Ritz; +Cc: linuxppc-dev, Edward Felberbaum, linux-pcmcia, paulus
In-Reply-To: <200604092257.52206.daniel.ritz-ml@swissonline.ch>
> > I see from the dmesg output from my original post that memory ranges
> > 0xfdd7f000 and 0xfddff000 are used by the Gatwick and Heathrow mac io
> > controllers. That explains the conflict with PCMCIA over 0xfd000000.
>
> interesting...the memory ranges are used by other devices yet the
> request_resource() call in PCMCIA succeeds,,,and PCI resources shoudn't
> be there in the first place then...
>
> ok, it's in file arch/powerpc/platforms/powermac/feature.c...
> i can't see any request_resource() calls in there...so CC'ing the PPC guys..
> they can sure comment...
Most of the macio stuff is in drivers/macintosh/macio_asic.c ... the
whole macio itself is a PCI device and thus should already "occupy" it's
possibly address range...
> >
> > Question, can I minimize the range of memory that is reserved 0xffffff - or
> > is it a waste of time?
> >
>
> yeah, you probably could, but it sounds like a waste of time...
>
> > Eddie
> >
>
> rgds
> -daniel
^ permalink raw reply
* Re: Create permanent mapping from PCI bus to region of physical memory
From: David Hawkins @ 2006-04-11 1:32 UTC (permalink / raw)
To: Howard, Marc; +Cc: linuxppc-embedded
In-Reply-To: <91B22F93A880FA48879475E134D6F0BE026CD163@CA1EXCLV02.adcorp.kla-tencor.com>
Howard, Marc wrote:
> Hi,
>
> I'm working on a PPC440GX based board in which a PCI based peripheral
> communicates with the host via a shared region of processor memory. The
> peripheral will read and write this region autonomously. Because of
> this I need a fixed mapping FROM the PCI bus TO system memory.
>
> It's easy enough to rope off the top 16 MB or so of system physical
> memory by lying to linux in the boot arguments. What I can't seem find
> is a system call to use to create a fixed, permanent mapping of PPC
> memory as seen from the PCI bus.
>
> Has anyone out there done this and could share a code snippet with me?
>
Hi Marc,
So the PPC440GX is the host, but what is the peripheral, and
what restricts it to require a fixed address? Can it handle
a set of fixed addresses, eg. a scatter-gather buffer setup
by the host? Can the host and peripheral communicate in any
other way, eg. when the peripheral changes something in the
shared memory, surely it has to interrupt the host to let it
know?
Does the peripheral contain a CPU, if thats the case, then
the host and peripheral could also maintain a smaller region
that contains addresses of other pages, i.e., no need to
restrict the design to a single block of memory, you just
need a page of pointers to other shared blocks of pages.
For example, the alloc_pages call can be used to get order 11
pages, eg. 2^11 x 4096-byte pages, 8MB (hmm, thats sounds a bit
big, I seem to recall 2MB was the maximum). So your 16MBs
could be 8 separate blocks.
Anyway the comment is that you can use alloc_pages() to give
you a contiguous chunk of memory at some allocation-time
address, but not a 16MB chunk.
Of course if the peripheral is fairly dumb, then you can't do
this. But if it indicates a buffer-used condition, perhaps you
can swap over to a new 2MB block.
If you can provide a few more details on the restriction of
the peripheral, then I or others can suggest options.
Dave
^ permalink raw reply
* Re: [Cbe-oss-dev] [PATCH 4/5] powerpc: export symbols for page size selection
From: Benjamin Herrenschmidt @ 2006-04-11 1:21 UTC (permalink / raw)
To: Christoph Hellwig; +Cc: linuxppc-dev, cbe-oss-dev, Arnd Bergmann
In-Reply-To: <20060407152813.GA382@lst.de>
On Fri, 2006-04-07 at 17:28 +0200, Christoph Hellwig wrote:
> On Fri, Apr 07, 2006 at 12:00:04AM +0200, arnd@arndb.de wrote:
> > We need access to some symbols in powerpc memory management
> > from spufs in order to create proper SLB entries.
>
> One more reason to disallow modular spufs..
Why ? It's not problem as long as they are exported GPL only ...
Ben.
^ permalink raw reply
* Create permanent mapping from PCI bus to region of physical memory
From: Howard, Marc @ 2006-04-11 0:17 UTC (permalink / raw)
To: linuxppc-embedded
Hi,
I'm working on a PPC440GX based board in which a PCI based peripheral
communicates with the host via a shared region of processor memory. The
peripheral will read and write this region autonomously. Because of
this I need a fixed mapping FROM the PCI bus TO system memory.
It's easy enough to rope off the top 16 MB or so of system physical
memory by lying to linux in the boot arguments. What I can't seem find
is a system call to use to create a fixed, permanent mapping of PPC
memory as seen from the PCI bus.
Has anyone out there done this and could share a code snippet with me?
Thanks,
Marc W. Howard
^ permalink raw reply
* Re: [PATCH] 2 of 3 kdump-ppc64-soft-reset-fixes
From: Andrew Morton @ 2006-04-10 22:58 UTC (permalink / raw)
To: David Wilder; +Cc: mchintage, linuxppc-dev, fastboot, paulus
In-Reply-To: <443ADCCE.1070504@us.ibm.com>
David Wilder <dwilder@us.ibm.com> wrote:
>
>
Please don't use a filename as a patch title. See section 2 of
http://www.zip.com.au/~akpm/linux/patches/stuff/tpp.txt.
> --- 2617-rc1.orig/arch/powerpc/kernel/crash.c 2006-04-05 13:20:38.000000000 -0700
> +++ 2617-rc1/arch/powerpc/kernel/crash.c 2006-04-05 13:24:19.000000000 -0700
> @@ -23,6 +23,7 @@
> #include <linux/elfcore.h>
> #include <linux/init.h>
> #include <linux/types.h>
> +#include <linux/irq.h>
>
> #include <asm/processor.h>
> #include <asm/machdep.h>
> @@ -40,6 +41,9 @@
>
> /* This keeps a track of which one is crashing cpu. */
> int crashing_cpu = -1;
> +static cpumask_t cpus_in_crash = CPU_MASK_NONE;
> +extern struct kimage *kexec_crash_image;
> +extern cpumask_t cpus_in_sr;
extern declarations should be placed in .h, not in .c.
> + while (!cpu_isset(crashing_cpu, cpus_in_crash))
> + barrier();
The patch contains lots of busy-loops which all do barrier().
barrier() is purely a compiler thing. I suspect you meant cpu_relax().
Either way, there should be a cpu_relax() in these loops.
> +
> +/*
> + * This function will be called by secondary cpus or by kexec cpu
> + * if soft-reset is activated to stop some CPUs.
> + */
> +void crash_kexec_secondary(struct pt_regs *regs)
> +{
> + int cpu = smp_processor_id();
> + unsigned long flags;
> + int msecs = 5;
> +
> + local_irq_save(flags);
> + /* Wait 5ms if the kexec CPU is not entered yet. */
> + while (crashing_cpu < 0) {
> + if (--msecs < 0) {
> + /*
> + * Either kdump image is not loaded or
> + * kdump process is not started - Probably xmon
> + * exited using 'x'(exit and recover) or
> + * kexec_should_crash() failed for all running tasks.
> + */
> + cpu_clear(cpu, cpus_in_sr);
> + local_irq_restore(flags);
> + return;
> + }
> + mdelay(1);
> + barrier();
> + }
> + if (cpu == crashing_cpu) {
Whitespace broke here.
> + /*
> + * Panic CPU will enter this func only via soft-reset.
> + * Wait until all secondary CPUs entered and
> + * then start kexec boot.
> + */
> + crash_soft_reset_check(cpu);
> + cpu_set(crashing_cpu, cpus_in_crash);
> + if (ppc_md.kexec_cpu_down)
> + ppc_md.kexec_cpu_down(1, 0);
> + machine_kexec(kexec_crash_image);
> + /* NOTREACHED */
> + }
> + crash_ipi_callback(regs);
> +}
^ permalink raw reply
* [PATCH] 2 of 3 kdump-ppc64-soft-reset-fixes
From: David Wilder @ 2006-04-10 22:31 UTC (permalink / raw)
To: fastboot, linuxppc-dev, akpm, mchintage, paulus, hbabu
[-- Attachment #1: Type: text/plain, Size: 1680 bytes --]
- When a system hangs, user will activate the soft-reset to initiate the
kdump boot. But, soft-reset behavior is indeterminate on sending FWNMI
to all CPUS. i.e, all CPUs will not get FW NMI at the same time. When
the first CPU entered (calling primary CPU here onwards) kdump using
crash_kexec(), sends an IPI to other CPUs. Some CPUs will respond to
this IPI and execute crash_ipi_callback() before receive NMI. When they
receive FW NMI, will execute die() and waiting forever since no more
kdump IPI coming from the primary CPU. This issue will be fixed by
invoking crash_kexec_secondary() directly from die().
Since the secondary CPUs will enter the IPI_callback function two times,
CPU states have to be saved only once and the primary CPU has to start
kdump boot after all CPUs are stopped. Hence, cpus_in_crash bitmap is
used to determine whether pt_regs is saved. If the bit is not set, regs
will be saved. Introduced cpus_in_sr bitmap and enter_on_soft_reset
counter which are used to let the primary CPU know that all secondary
CPUs entered via soft-reset and ready to do down.
- For the crash scenario, when a CPU hangs with interrupts disabled and
the other CPUs panic or user invoked kdump boot using sysrq-c. In this
case, the hung CPU can not be stopped and causes the kdump boot not
successful. This case can be treated as complete system hang and asks
the user to activate soft-reset if all secondary CPUs are not stopped.
Please pick-up this patch. (Note this patch is dependent on
kdump-image-rm-static.patch, see my earlier posting)
--
David Wilder
IBM Linux Technology Center
Beaverton, Oregon, USA
dwilder@us.ibm.com
(503)578-3789
[-- Attachment #2: kdump-ppc64-soft-reset-fixes.patch --]
[-- Type: text/x-patch, Size: 10588 bytes --]
- When a system hangs, user will activate the soft-reset to initiate the kdump boot. But, soft-reset behavior is indeterminate on sending FWNMI to all CPUS. i.e, all CPUs will not get FW NMI at the same time. When the first CPU entered (calling primary CPU here onwards) kdump using crash_kexec(), sends an IPI to other CPUs. Some CPUs will respond to this IPI and execute crash_ipi_callback() before receive NMI. When they receive FW NMI, will execute die() and waiting forever since no more kdump IPI coming from the primary CPU. This issue will be fixed by invoking crash_kexec_secondary() directly from die().
Since the secondary CPUs will enter the IPI_callback function two times, CPU states have to be saved only once and the primary CPU has to start kdump boot after all CPUs are stopped. Hence, cpus_in_crash bitmap is used to determine whether pt_regs is saved. If the bit is not set, regs will be saved. Introduced cpus_in_sr bitmap and enter_on_soft_reset counter which are used to let the primary CPU know that all secondary CPUs entered via soft-reset and ready to do down.
- For the crash scenario, when a CPU hangs with interrupts disabled and the other CPUs panic or user invoked kdump boot using sysrq-c. In this case, the hung CPU can not be stopped and causes the kdump boot not successful. This case can be treated as complete system hang and asks the user to activate soft-reset if all secondary CPUs are not stopped.
Signed-off-by: David Wilder <dwilder@us.ibm.com>
Signed-off-by: Haren Myneni <haren@us.ibm.com>
diff -Naurp 2617-rc1.orig/arch/powerpc/kernel/crash.c 2617-rc1/arch/powerpc/kernel/crash.c
--- 2617-rc1.orig/arch/powerpc/kernel/crash.c 2006-04-05 13:20:38.000000000 -0700
+++ 2617-rc1/arch/powerpc/kernel/crash.c 2006-04-05 13:24:19.000000000 -0700
@@ -23,6 +23,7 @@
#include <linux/elfcore.h>
#include <linux/init.h>
#include <linux/types.h>
+#include <linux/irq.h>
#include <asm/processor.h>
#include <asm/machdep.h>
@@ -40,6 +41,9 @@
/* This keeps a track of which one is crashing cpu. */
int crashing_cpu = -1;
+static cpumask_t cpus_in_crash = CPU_MASK_NONE;
+extern struct kimage *kexec_crash_image;
+extern cpumask_t cpus_in_sr;
static u32 *append_elf_note(u32 *buf, char *name, unsigned type, void *data,
size_t data_len)
@@ -97,34 +101,66 @@ static void crash_save_this_cpu(struct p
}
#ifdef CONFIG_SMP
-static atomic_t waiting_for_crash_ipi;
+static atomic_t enter_on_soft_reset = ATOMIC_INIT(0);
void crash_ipi_callback(struct pt_regs *regs)
{
int cpu = smp_processor_id();
- if (cpu == crashing_cpu)
- return;
-
if (!cpu_online(cpu))
return;
- if (ppc_md.kexec_cpu_down)
- ppc_md.kexec_cpu_down(1, 1);
-
local_irq_disable();
+ if (!cpu_isset(cpu, cpus_in_crash))
+ crash_save_this_cpu(regs, cpu);
+ cpu_set(cpu, cpus_in_crash);
- crash_save_this_cpu(regs, cpu);
- atomic_dec(&waiting_for_crash_ipi);
+ /*
+ * Entered via soft-reset - could be the kdump
+ * process is invoked using soft-reset or user activated
+ * it if some CPU did not respond to an IPI.
+ * For soft-reset, the secondary CPU can enter this func
+ * twice. 1 - using IPI, and 2. soft-reset.
+ * Tell the kexec CPU that entered via soft-reset and ready
+ * to go down.
+ */
+ if (cpu_isset(cpu, cpus_in_sr)) {
+ cpu_clear(cpu, cpus_in_sr);
+ atomic_inc(&enter_on_soft_reset);
+ }
+
+ /*
+ * Starting the kdump boot.
+ * This barrier is needed to make sure that all CPUs are stopped.
+ * If not, soft-reset will be invoked to bring other CPUs.
+ */
+ while (!cpu_isset(crashing_cpu, cpus_in_crash))
+ barrier();
+
+ if (ppc_md.kexec_cpu_down)
+ ppc_md.kexec_cpu_down(1, 1);
kexec_smp_wait();
/* NOTREACHED */
}
-static void crash_kexec_prepare_cpus(void)
+/*
+ * Wait until all CPUs are entered via soft-reset.
+ */
+static void crash_soft_reset_check(int cpu)
+{
+ unsigned int ncpus = num_online_cpus() - 1;/* Excluding the panic cpu */
+
+ cpu_clear(cpu, cpus_in_sr);
+ while (atomic_read(&enter_on_soft_reset) != ncpus)
+ barrier();
+}
+
+
+static void crash_kexec_prepare_cpus(int cpu)
{
unsigned int msecs;
- atomic_set(&waiting_for_crash_ipi, num_online_cpus() - 1);
+ unsigned int ncpus = num_online_cpus() - 1;/* Excluding the panic cpu */
crash_send_ipi(crash_ipi_callback);
smp_wmb();
@@ -132,13 +168,12 @@ static void crash_kexec_prepare_cpus(voi
/*
* FIXME: Until we will have the way to stop other CPUSs reliabally,
* the crash CPU will send an IPI and wait for other CPUs to
- * respond. If not, proceed the kexec boot even though we failed to
- * capture other CPU states.
+ * respond.
* Delay of at least 10 seconds.
*/
- printk(KERN_ALERT "Sending IPI to other cpus...\n");
+ printk(KERN_EMERG "Sending IPI to other cpus...\n");
msecs = 10000;
- while ((atomic_read(&waiting_for_crash_ipi) > 0) && (--msecs > 0)) {
+ while ((cpus_weight(cpus_in_crash) < ncpus) && (--msecs > 0)) {
barrier();
mdelay(1);
}
@@ -148,18 +183,71 @@ static void crash_kexec_prepare_cpus(voi
/*
* FIXME: In case if we do not get all CPUs, one possibility: ask the
* user to do soft reset such that we get all.
- * IPI handler is already set by the panic cpu initially. Therefore,
- * all cpus could invoke this handler from die() and the panic CPU
- * will call machine_kexec() directly from this handler to do
- * kexec boot.
- */
- if (atomic_read(&waiting_for_crash_ipi))
- printk(KERN_ALERT "done waiting: %d cpus not responding\n",
- atomic_read(&waiting_for_crash_ipi));
+ * Soft-reset will be used until better mechanism is implemented.
+ */
+ if (cpus_weight(cpus_in_crash) < ncpus) {
+ printk(KERN_EMERG "done waiting: %d cpu(s) not responding\n",
+ ncpus - cpus_weight(cpus_in_crash));
+ printk(KERN_EMERG "Activate soft-reset to stop other cpu(s)\n");
+ cpus_in_sr = CPU_MASK_NONE;
+ atomic_set(&enter_on_soft_reset, 0);
+ while (cpus_weight(cpus_in_crash) < ncpus)
+ barrier();
+ }
+ /*
+ * Make sure all CPUs are entered via soft-reset if the kdump is
+ * invoked using soft-reset.
+ */
+ if (cpu_isset(cpu, cpus_in_sr))
+ crash_soft_reset_check(cpu);
/* Leave the IPI callback set */
}
+
+/*
+ * This function will be called by secondary cpus or by kexec cpu
+ * if soft-reset is activated to stop some CPUs.
+ */
+void crash_kexec_secondary(struct pt_regs *regs)
+{
+ int cpu = smp_processor_id();
+ unsigned long flags;
+ int msecs = 5;
+
+ local_irq_save(flags);
+ /* Wait 5ms if the kexec CPU is not entered yet. */
+ while (crashing_cpu < 0) {
+ if (--msecs < 0) {
+ /*
+ * Either kdump image is not loaded or
+ * kdump process is not started - Probably xmon
+ * exited using 'x'(exit and recover) or
+ * kexec_should_crash() failed for all running tasks.
+ */
+ cpu_clear(cpu, cpus_in_sr);
+ local_irq_restore(flags);
+ return;
+ }
+ mdelay(1);
+ barrier();
+ }
+ if (cpu == crashing_cpu) {
+ /*
+ * Panic CPU will enter this func only via soft-reset.
+ * Wait until all secondary CPUs entered and
+ * then start kexec boot.
+ */
+ crash_soft_reset_check(cpu);
+ cpu_set(crashing_cpu, cpus_in_crash);
+ if (ppc_md.kexec_cpu_down)
+ ppc_md.kexec_cpu_down(1, 0);
+ machine_kexec(kexec_crash_image);
+ /* NOTREACHED */
+ }
+ crash_ipi_callback(regs);
+}
+
#else
-static void crash_kexec_prepare_cpus(void)
+static void crash_kexec_prepare_cpus(int cpu)
{
/*
* move the secondarys to us so that we can copy
@@ -170,6 +258,10 @@ static void crash_kexec_prepare_cpus(voi
smp_release_cpus();
}
+void crash_kexec_secondary(struct pt_regs *regs)
+{
+ cpus_in_sr = CPU_MASK_NONE;
+}
#endif
void default_machine_crash_shutdown(struct pt_regs *regs)
@@ -185,15 +277,14 @@ void default_machine_crash_shutdown(stru
* The kernel is broken so disable interrupts.
*/
local_irq_disable();
-
- if (ppc_md.kexec_cpu_down)
- ppc_md.kexec_cpu_down(1, 0);
-
/*
* Make a note of crashing cpu. Will be used in machine_kexec
* such that another IPI will not be sent.
*/
crashing_cpu = smp_processor_id();
- crash_kexec_prepare_cpus();
crash_save_this_cpu(regs, crashing_cpu);
+ crash_kexec_prepare_cpus(crashing_cpu);
+ cpu_set(crashing_cpu, cpus_in_crash);
+ if (ppc_md.kexec_cpu_down)
+ ppc_md.kexec_cpu_down(1, 0);
}
diff -Naurp 2617-rc1.orig/arch/powerpc/kernel/traps.c 2617-rc1/arch/powerpc/kernel/traps.c
--- 2617-rc1.orig/arch/powerpc/kernel/traps.c 2006-04-05 13:20:33.000000000 -0700
+++ 2617-rc1/arch/powerpc/kernel/traps.c 2006-04-05 13:22:00.000000000 -0700
@@ -51,9 +51,13 @@
#include <asm/firmware.h>
#include <asm/processor.h>
#endif
+#include <asm/kexec.h>
#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
@@ -96,7 +100,7 @@ static DEFINE_SPINLOCK(die_lock);
int die(const char *str, struct pt_regs *regs, long err)
{
- static int die_counter, crash_dump_start = 0;
+ static int die_counter;
if (debugger(regs))
return 1;
@@ -128,22 +132,12 @@ int die(const char *str, struct pt_regs
print_modules();
show_regs(regs);
bust_spinlocks(0);
-
- if (!crash_dump_start && kexec_should_crash(current)) {
- crash_dump_start = 1;
- spin_unlock_irq(&die_lock);
- crash_kexec(regs);
- /* NOTREACHED */
- }
spin_unlock_irq(&die_lock);
- if (crash_dump_start)
- /*
- * Only for soft-reset: Other CPUs will be responded to an IPI
- * sent by first kexec CPU.
- */
- for(;;)
- ;
+ if (kexec_should_crash(current))
+ crash_kexec(regs);
+ crash_kexec_secondary(regs);
+
if (in_interrupt())
panic("Fatal exception in interrupt");
@@ -205,6 +199,10 @@ void system_reset_exception(struct pt_re
if (ppc_md.system_reset_exception(regs))
return;
}
+
+#ifdef CONFIG_KEXEC
+ cpu_set(smp_processor_id(), cpus_in_sr);
+#endif
die("System Reset", regs, SIGABRT);
diff -Naurp 2617-rc1.orig/include/asm-powerpc/kexec.h 2617-rc1/include/asm-powerpc/kexec.h
--- 2617-rc1.orig/include/asm-powerpc/kexec.h 2006-04-05 13:20:53.000000000 -0700
+++ 2617-rc1/include/asm-powerpc/kexec.h 2006-04-05 13:18:27.000000000 -0700
@@ -123,8 +123,10 @@ extern int default_machine_kexec_prepare
extern void default_machine_crash_shutdown(struct pt_regs *regs);
extern void machine_kexec_simple(struct kimage *image);
-
+extern void crash_kexec_secondary(struct pt_regs *regs);
#endif /* ! __ASSEMBLY__ */
+#else
+static inline void crash_kexec_secondary(struct pt_regs *regs) { }
#endif /* CONFIG_KEXEC */
#endif /* __KERNEL__ */
#endif /* _ASM_POWERPC_KEXEC_H */
^ permalink raw reply
* MPC83xx: CF access in True IDE mode
From: SIP COP 009 @ 2006-04-10 23:00 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 172 bytes --]
Hi !
I am looking out for some pointers to get CF working in the TRUE IDE mode on
Linux2.6
Any pointers and help would be greatly appreciated.
Thanks!
ashutosh
[-- Attachment #2: Type: text/html, Size: 209 bytes --]
^ permalink raw reply
* [PATCH] kdump-ppc64-xmon-stop-cpu
From: David Wilder @ 2006-04-10 22:32 UTC (permalink / raw)
To: fastboot, linuxppc-dev, akpm, mchintage, paulus, hbabu
[-- Attachment #1: Type: text/plain, Size: 493 bytes --]
Patch 3 of 3
- During CPU(s) hang scenarios, kdump could not stop these CPUs.
However, the user could invoke soft-reset to shoot down CPUs reliably.
But, when the debugger is enabled, these CPUs are returned to hang state
after they exited from the debugger. This patch fixes this issue by
calling crash_kexec_secondary() before returns to previous state.
Please pick up this patch.
--
David Wilder
IBM Linux Technology Center
Beaverton, Oregon, USA
dwilder@us.ibm.com
(503)578-3789
[-- Attachment #2: kdump-ppc64-xmon-stop-cpu.patch --]
[-- Type: text/x-patch, Size: 1273 bytes --]
- During CPU(s) hang scenarios, kdump could not stop these CPUs. However, the user could invoke soft-reset to shoot down CPUs reliably. But, when the debugger is enabled, these CPUs are returned to hang state after they exited from the debugger. This patch fixes this issue by calling crash_kexec_secondary() before returns to previous state.
Signed-off-by: David Wilder <dwilder@us.ibm.com>
Signed-off-by: Haren Myneni <haren@us.ibm.com>
--- 2617-rc1/arch/powerpc/kernel/traps.c.orig 2006-04-05 13:25:22.000000000 -0700
+++ 2617-rc1/arch/powerpc/kernel/traps.c 2006-04-05 13:25:33.000000000 -0700
@@ -206,6 +206,16 @@ void system_reset_exception(struct pt_re
die("System Reset", regs, SIGABRT);
+ /*
+ * Some CPUs which got released from debugger will execute this path.
+ * These CPUs entered debugger first time via soft-reset - Means,
+ * could be possible that these CPUs may not repond to an IPI later.
+ * Therefore, has to call kdump func directly.
+ * Not a problem if we exited from debugger to recover. In this case
+ * there will not be any primary kexec CPU. Hence, will be returned.
+ */
+ crash_kexec_secondary(regs);
+
/* Must die if the interrupt is not recoverable */
if (!(regs->msr & MSR_RI))
panic("Unrecoverable System Reset");
^ permalink raw reply
* Re: freescale lite 5200 board and kernel 2.6
From: Domenico Andreoli @ 2006-04-10 21:54 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <20060408082100.GA54030@server.idefix.loc>
On Sat, Apr 08, 2006 at 10:21:00AM +0200, Matthias Fechner wrote:
> Hello Domenico,
Hello Matthias,
> * Domenico Andreoli <cavokz@gmail.com> [07-04-06 00:10]:
> > kernel is built following the instructions on your wiki, i attached
> > the config file. please have a look, let me know if any check/test may
> > be advised.
>
> sry, but I have now time to try your kernel config, but I attached
> mine which is working fine for me.
> Maybe this helps you.
unfortunately it does not :/
sometimes kernel prints "eth0: config: auto-negotiation on, 100HDX,
10HDX.", the eth0 is up and everything works.
most of the times "eth0: config: auto-negotiation off, No speed/duplex
selected?." is instead printed and eth0 seems to not exist.
i tend to exclude hw problems, older kernel 2.4.x always succeed in
using eth0.
is there any way to force eth0 auto-negotiation?
thank you
domenico
-----[ Domenico Andreoli, aka cavok
--[ http://people.debian.org/~cavok/gpgkey.asc
---[ 3A0F 2F80 F79C 678A 8936 4FEE 0677 9033 A20E BC50
^ permalink raw reply
* [PATCH] kdump-image-rm-static
From: David Wilder @ 2006-04-10 22:30 UTC (permalink / raw)
To: fastboot, linuxppc-dev, akpm, mchintage, paulus, hbabu
[-- Attachment #1: Type: text/plain, Size: 974 bytes --]
I am posting three patches (in separate emails) to both these lists.
The 2nd and 3d patches have dependencies on the first patch that I have
attached to this email (changing a static to non-static). This patch
applies to generic code where the other two are powerpc specific. Please
pick up these patchs.
On powerpc, the panic CPU sends an IPI to shoot down other CPUs. Since
the IPI is not an NMI, it may not be able to stop all CPUs before kdump
boot. However, one solution could be, if some CPUs are not stopped,
asking the user to activate soft-reset (either from management console
or pressing soft-reset button) which sends FW NMI to all CPUs. These
CPUS will execute arch specific kdump func which has to be invoked
machine_kexec() directly. At present, kexec_crash_image is not passed to
machine_crash_shutdown() or defined as static in kexec.c.
--
David Wilder
IBM Linux Technology Center
Beaverton, Oregon, USA
dwilder@us.ibm.com
(503)578-3789
[-- Attachment #2: kdump-image-rm-static.patch --]
[-- Type: text/x-patch, Size: 1658 bytes --]
On powerpc, the panic CPU sends an IPI to shoot down other CPUs. Since not an NMI, may not able to stop all CPUs before kdump boot. However, one solution could be, if some CPUs are not stopped, asking the user to activate soft-reset (either from management console or pressing soft-reset button) which sends FW NMI to all CPUs. These CPUS will execute arch specific kdump func which has to be invoked machine_kexec() directly. At present, kexec_crash_image is not passed to machine_crash_shutdown() or defined as static in kexec.c.
Signed-off-by: David Wilder <dwilder@us.ibm.com>
Signed-off-by: Haren Myneni <haren@us.ibm.com>
--- 2617-rc1/kernel/kexec.c.orig 2006-04-05 13:27:53.000000000 -0700
+++ 2617-rc1/kernel/kexec.c 2006-04-05 13:27:43.000000000 -0700
@@ -903,7 +903,7 @@ static int kimage_load_segment(struct ki
* that to happen you need to do that yourself.
*/
struct kimage *kexec_image = NULL;
-static struct kimage *kexec_crash_image = NULL;
+struct kimage *kexec_crash_image = NULL;
/*
* A home grown binary mutex.
* Nothing can wait so this mutex is safe to use
@@ -1042,7 +1042,6 @@ asmlinkage long compat_sys_kexec_load(un
void crash_kexec(struct pt_regs *regs)
{
- struct kimage *image;
int locked;
@@ -1056,12 +1055,11 @@ void crash_kexec(struct pt_regs *regs)
*/
locked = xchg(&kexec_lock, 1);
if (!locked) {
- image = xchg(&kexec_crash_image, NULL);
- if (image) {
+ if (kexec_crash_image) {
struct pt_regs fixed_regs;
crash_setup_regs(&fixed_regs, regs);
machine_crash_shutdown(&fixed_regs);
- machine_kexec(image);
+ machine_kexec(kexec_crash_image);
}
xchg(&kexec_lock, 0);
}
^ permalink raw reply
* hdlc_enet
From: Antonio Di Bacco @ 2006-04-10 20:51 UTC (permalink / raw)
To: linuxppc-embedded
Hi,
I want to use the hdlc_enet driver, to use both scc2 and scc4 connected
together on a MBX card.
To get my hdlc_enet_init called shoudl I patch Space.c adding a list of hdlc
devices?
Anyone could help?
Bye,
Antonio.
^ permalink raw reply
* Re: GPIO endianness on MPC8349
From: Ben Warren @ 2006-04-10 20:20 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-embedded
In-Reply-To: <6518EE00-812C-4839-AF00-AA976C35E799@kernel.crashing.org>
[-- Attachment #1: Type: text/plain, Size: 1389 bytes --]
Sorry for wasting bandwidth (again). Turns out my schematic is for an
earlier spin of the board.
regards,
Ben
On Mon, 2006-04-10 at 15:06 -0500, Kumar Gala wrote:
> On Apr 10, 2006, at 2:48 PM, Ben Warren wrote:
>
> > Hello,
> >
> > I'm a noobie to this CPU, and am utterly confused with how the bits
> > are
> > ordered on the GPIO ports. I imagine it's the same as all Freescale
> > PPCs, but who knows. Anyway...
> >
> > Using an MPC8349MDS eval board, I have one LED to play with. From the
> > schematic, it's connected to GPIO1[1]. From other processors that
> > I've
> > worked with, I would have expected to toggle it with either 0x40000000
> > (IBM 405) or 0x00000002 (68360). Nope. To make this bit move, I mess
> > with bit 0x00000040 in the appropriate DAT register. This leads me to
> > believe that either the bit ordering is something
> > like ...89abcdef01234567 (sorry for the confusing notation, but
> > hopefully it makes sense) or the schematic has a typo. Since I'm
> > trying
> > to write a generic GPIO handler, I'd like to have a little
> > confidence in
> > my extrapolation from a single point.
> >
> > Can anybody shed some light on this?
>
> This is because the Freescale docs are misleading. If you look at
> the schematic you will see the LED is wired to GPIO1[5] which makes
> sense for the 0x40 value you have to use.
>
> - kumar
[-- Attachment #2: Type: text/html, Size: 2480 bytes --]
^ permalink raw reply
* Re: GPIO endianness on MPC8349
From: Kumar Gala @ 2006-04-10 20:06 UTC (permalink / raw)
To: bwarren; +Cc: linuxppc-embedded
In-Reply-To: <1144698501.972.103.camel@saruman.qstreams.net>
On Apr 10, 2006, at 2:48 PM, Ben Warren wrote:
> Hello,
>
> I'm a noobie to this CPU, and am utterly confused with how the bits
> are
> ordered on the GPIO ports. I imagine it's the same as all Freescale
> PPCs, but who knows. Anyway...
>
> Using an MPC8349MDS eval board, I have one LED to play with. From the
> schematic, it's connected to GPIO1[1]. From other processors that
> I've
> worked with, I would have expected to toggle it with either 0x40000000
> (IBM 405) or 0x00000002 (68360). Nope. To make this bit move, I mess
> with bit 0x00000040 in the appropriate DAT register. This leads me to
> believe that either the bit ordering is something
> like ...89abcdef01234567 (sorry for the confusing notation, but
> hopefully it makes sense) or the schematic has a typo. Since I'm
> trying
> to write a generic GPIO handler, I'd like to have a little
> confidence in
> my extrapolation from a single point.
>
> Can anybody shed some light on this?
This is because the Freescale docs are misleading. If you look at
the schematic you will see the LED is wired to GPIO1[5] which makes
sense for the 0x40 value you have to use.
- kumar
^ permalink raw reply
* GPIO endianness on MPC8349
From: Ben Warren @ 2006-04-10 19:48 UTC (permalink / raw)
To: linuxppc-embedded
Hello,
I'm a noobie to this CPU, and am utterly confused with how the bits are
ordered on the GPIO ports. I imagine it's the same as all Freescale
PPCs, but who knows. Anyway...
Using an MPC8349MDS eval board, I have one LED to play with. From the
schematic, it's connected to GPIO1[1]. From other processors that I've
worked with, I would have expected to toggle it with either 0x40000000
(IBM 405) or 0x00000002 (68360). Nope. To make this bit move, I mess
with bit 0x00000040 in the appropriate DAT register. This leads me to
believe that either the bit ordering is something
like ...89abcdef01234567 (sorry for the confusing notation, but
hopefully it makes sense) or the schematic has a typo. Since I'm trying
to write a generic GPIO handler, I'd like to have a little confidence in
my extrapolation from a single point.
Can anybody shed some light on this?
thanks,
Ben
^ permalink raw reply
* Re: Slab errors on 4xx (STB04)
From: Andre Draszik @ 2006-04-10 19:48 UTC (permalink / raw)
To: Andre Draszik, linuxppc-embedded
In-Reply-To: <20060410071457.GA16898@gate.ebshome.net>
Eugene Surovegin wrote:
> On Mon, Apr 10, 2006 at 12:33:56AM +0200, Andre Draszik wrote:
>> Since it _seems_ to work nevertheless - is CONFIG_DEBUG_SLAB known to be
>> broken on this platform?
>
> Yes, it's very likely that CONFIG_DEBUG_SLAB is the culprit here. This
> [...]
Thanks Roland and Eugene for the advice.
> You can try changing __dma_sync() to do flush_dcache_range() even for
> DMA_FROM_DEVICE case. However, do this only to check this theory, not
> as a permanent solution :).
OK, I will play with the cache later today... I wanted DEBUG_SLAB turned
on for some other unrelated problem, so just for debugging, this hack
would be fine if it worked :)
Greetings,
Andre'
^ permalink raw reply
* [PATCH] powerpc: fixup pci resource DBG code to handle size change
From: Kumar Gala @ 2006-04-10 18:11 UTC (permalink / raw)
To: Andrew Morton; +Cc: linuxppc-dev, linux-kernel
A number of DBG() calls needed to be fixed up to properly handle the size
change in struct resource
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
---
commit 8e55334e29b2996d921641911a3802f9d004566d
tree 723945265ad953fd6ce4f59c66e560165e78da41
parent 6d05f46f58f45d4aa74cf328f9f7935a71d4fe87
author Kumar Gala <galak@kernel.crashing.org> Mon, 10 Apr 2006 13:10:45 -0500
committer Kumar Gala <galak@kernel.crashing.org> Mon, 10 Apr 2006 13:10:45 -0500
arch/powerpc/kernel/pci_32.c | 28 ++++++++++++++--------------
arch/ppc/kernel/pci.c | 2 +-
2 files changed, 15 insertions(+), 15 deletions(-)
diff --git a/arch/powerpc/kernel/pci_32.c b/arch/powerpc/kernel/pci_32.c
index 96a5ee9..9607a09 100644
--- a/arch/powerpc/kernel/pci_32.c
+++ b/arch/powerpc/kernel/pci_32.c
@@ -99,7 +99,7 @@ pcibios_fixup_resources(struct pci_dev *
if (!res->flags)
continue;
if (res->end == 0xffffffff) {
- DBG("PCI:%s Resource %d [%08lx-%08lx] is unassigned\n",
+ DBG("PCI:%s Resource %d [%016llx-%016llx] is unassigned\n",
pci_name(dev), i, res->start, res->end);
res->end -= res->start;
res->start = 0;
@@ -117,7 +117,7 @@ pcibios_fixup_resources(struct pci_dev *
res->start += offset;
res->end += offset;
#ifdef DEBUG
- printk("Fixup res %d (%lx) of dev %s: %lx -> %lx\n",
+ printk("Fixup res %d (%lx) of dev %s: %llx -> %llx\n",
i, res->flags, pci_name(dev),
res->start - offset, res->start);
#endif
@@ -179,7 +179,7 @@ void pcibios_align_resource(void *data,
struct pci_dev *dev = data;
if (res->flags & IORESOURCE_IO) {
- unsigned long start = res->start;
+ u64 start = res->start;
if (size > 0x100) {
printk(KERN_ERR "PCI: I/O Region %s/%d too large"
@@ -255,8 +255,8 @@ pcibios_allocate_bus_resources(struct li
}
}
- DBG("PCI: bridge rsrc %lx..%lx (%lx), parent %p\n",
- res->start, res->end, res->flags, pr);
+ DBG("PCI: bridge rsrc %llx..%llx (%lx), parent %p\n",
+ res->start, res->end, res->flags, pr);
if (pr) {
if (request_resource(pr, res) == 0)
continue;
@@ -306,7 +306,7 @@ reparent_resources(struct resource *pare
*pp = NULL;
for (p = res->child; p != NULL; p = p->sibling) {
p->parent = res;
- DBG(KERN_INFO "PCI: reparented %s [%lx..%lx] under %s\n",
+ DBG(KERN_INFO "PCI: reparented %s [%llx..%llx] under %s\n",
p->name, p->start, p->end, res->name);
}
return 0;
@@ -362,7 +362,7 @@ pci_relocate_bridge_resource(struct pci_
try = conflict->start - 1;
}
if (request_resource(pr, res)) {
- DBG(KERN_ERR "PCI: huh? couldn't move to %lx..%lx\n",
+ DBG(KERN_ERR "PCI: huh? couldn't move to %llx..%llx\n",
res->start, res->end);
return -1; /* "can't happen" */
}
@@ -480,14 +480,14 @@ static inline void alloc_resource(struct
{
struct resource *pr, *r = &dev->resource[idx];
- DBG("PCI:%s: Resource %d: %08lx-%08lx (f=%lx)\n",
+ DBG("PCI:%s: Resource %d: %016llx-%016llx (f=%lx)\n",
pci_name(dev), idx, r->start, r->end, r->flags);
pr = pci_find_parent_resource(dev, r);
if (!pr || request_resource(pr, r) < 0) {
printk(KERN_ERR "PCI: Cannot allocate resource region %d"
" of device %s\n", idx, pci_name(dev));
if (pr)
- DBG("PCI: parent is %p: %08lx-%08lx (f=%lx)\n",
+ DBG("PCI: parent is %p: %016llx-%016llx (f=%lx)\n",
pr, pr->start, pr->end, pr->flags);
/* We'll assign a new address later */
r->flags |= IORESOURCE_UNSET;
@@ -957,7 +957,7 @@ pci_process_bridge_OF_ranges(struct pci_
res = &hose->io_resource;
res->flags = IORESOURCE_IO;
res->start = ranges[2];
- DBG("PCI: IO 0x%lx -> 0x%lx\n",
+ DBG("PCI: IO 0x%llx -> 0x%llx\n",
res->start, res->start + size - 1);
break;
case 2: /* memory space */
@@ -979,7 +979,7 @@ pci_process_bridge_OF_ranges(struct pci_
if(ranges[0] & 0x40000000)
res->flags |= IORESOURCE_PREFETCH;
res->start = ranges[na+2];
- DBG("PCI: MEM[%d] 0x%lx -> 0x%lx\n", memno,
+ DBG("PCI: MEM[%d] 0x%llx -> 0x%llx\n", memno,
res->start, res->start + size - 1);
}
break;
@@ -1075,7 +1075,7 @@ do_update_p2p_io_resource(struct pci_bus
DBG("Remapping Bus %d, bridge: %s\n", bus->number, pci_name(bridge));
res.start -= ((unsigned long) hose->io_base_virt - isa_io_base);
res.end -= ((unsigned long) hose->io_base_virt - isa_io_base);
- DBG(" IO window: %08lx-%08lx\n", res.start, res.end);
+ DBG(" IO window: %016llx-%016llx\n", res.start, res.end);
/* Set up the top and bottom of the PCI I/O segment for this bus. */
pci_read_config_dword(bridge, PCI_IO_BASE, &l);
@@ -1223,8 +1223,8 @@ do_fixup_p2p_level(struct pci_bus *bus)
continue;
if ((r->flags & IORESOURCE_IO) == 0)
continue;
- DBG("Trying to allocate from %08lx, size %08lx from parent"
- " res %d: %08lx -> %08lx\n",
+ DBG("Trying to allocate from %016llx, size %016llx from parent"
+ " res %d: %016llx -> %016llx\n",
res->start, res->end, i, r->start, r->end);
if (allocate_resource(r, res, res->end + 1, res->start, max,
diff --git a/arch/ppc/kernel/pci.c b/arch/ppc/kernel/pci.c
index ffbae40..fb25b30 100644
--- a/arch/ppc/kernel/pci.c
+++ b/arch/ppc/kernel/pci.c
@@ -960,7 +960,7 @@ static pgprot_t __pci_mmap_set_pgprot(st
else
prot |= _PAGE_GUARDED;
- printk("PCI map for %s:%lx, prot: %lx\n", pci_name(dev), rp->start,
+ printk("PCI map for %s:%llx, prot: %llx\n", pci_name(dev), rp->start,
prot);
return __pgprot(prot);
^ permalink raw reply related
* Re: [PATCH 2/2] Base pSeries PCIe support
From: Jake Moilanen @ 2006-04-10 15:39 UTC (permalink / raw)
To: paulus; +Cc: linuxppc-dev
In-Reply-To: <20060401165723.ab77c81f.moilanen@austin.ibm.com>
On Sat, 1 Apr 2006 16:57:23 -0600
Jake Moilanen <moilanen@austin.ibm.com> wrote:
> On Sat, 1 Apr 2006 19:36:07 +1100
> Paul Mackerras <paulus@samba.org> wrote:
>
> > Jake Moilanen writes:
> >
> > > The NR_IRQS got bumped up to 1024, as vectors can go much higher.
> > > Unfortunately, this number was arbitrarily picked as there is no claim
> > > at what the max number really is by either the firmware team, or the
> > > PAPR+.
> >
> > What matters is the number of different vectors, not the actual value
> > of the vectors, because we remap interrupt numbers that the firmware
> > gives us to logical Linux irq numbers between 0 and NR_IRQS-1. We had
> > to do that when the POWER5 systems came out, because the interrupt
> > numbers there occupy 24 bits.
>
> Ah. That sounds right. I haven't had a chance to test this version of
> the patch. Firmware is currently broken on my machine.
I was able to validate that these patches do work, and we are receiving
MSI interrupts correctly.
Is it too late to get into 2.6.17?
Jake
^ permalink raw reply
* Re: [PATCH 2/4] tickless idle cpu: Skip ticks when CPU is idle
From: Srivatsa Vaddagiri @ 2006-04-10 12:23 UTC (permalink / raw)
To: Kumar Gala; +Cc: sri_vatsa_v, paulus, linuxppc-dev
In-Reply-To: <981C3B4E-7336-403D-AF58-3B36AA071866@kernel.crashing.org>
On Fri, Apr 07, 2006 at 09:16:58AM -0500, Kumar Gala wrote:
> >+config NO_IDLE_HZ
> >+ depends on EXPERIMENTAL && (PPC_PSERIES || PPC_PMAC || PPC_MAPLE)
> >+ bool "Switch off timer ticks on idle CPUs"
> >+ help
> >+ Switches the HZ timer interrupts off when a CPU is idle.
> >+
>
> any reason not to provide this for all 6xx class processors?
I think the same patch would work mostly for 6xx cpus as well. I however
dont think have any hardware to test it. If I am not mistaken, to
support 6xx CPUs, only ppc6xx_idle needs to be modified to call stop_hz_timer
before going into power-save mode?
--
Regards,
vatsa
^ 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