* Re: [PATCH] [POWERPC] Add docs for Freescale PowerQUICC SATA device tree nodes
From: Kumar Gala @ 2008-01-22 22:05 UTC (permalink / raw)
To: Grant Likely; +Cc: Scott Wood, linuxppc-dev, Timur Tabi
In-Reply-To: <fa686aa40801221354i53b5e8ebn8fc547b8eea75ebe@mail.gmail.com>
On Jan 22, 2008, at 3:54 PM, Grant Likely wrote:
> On 1/22/08, Kumar Gala <galak@kernel.crashing.org> wrote:
>> Signed-off-by: Li Yang <leoli@freescale.com>
>> Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
>> ---
>> Documentation/powerpc/booting-without-of.txt | 30 ++++++++++++++++
>> ++++++++++
>> 1 files changed, 30 insertions(+), 0 deletions(-)
>>
>> diff --git a/Documentation/powerpc/booting-without-of.txt b/
>> Documentation/powerpc/booting-without-of.txt
>> index 3584c33..387310a 100644
>> --- a/Documentation/powerpc/booting-without-of.txt
>> +++ b/Documentation/powerpc/booting-without-of.txt
>> @@ -2743,6 +2743,36 @@ platforms are moved over to use the
>> flattened-device-tree model.
>> };
>> };
>>
>> + * Freescale 8xxx/3.0 Gb/s SATA nodes
>> +
>> + SATA nodes are defined to describe on-chip Serial ATA
>> controllers.
>> + Each SATA port should have its own node.
>> +
>> + Required properties:
>> + - compatible : compatible list, contains 2 entries,
>> first is
>> + "fsl,CHIP-sata", where CHIP is the processor
>> + (mpc8315, mpc8379, etc.) and the second is
>> + "fsl,pq-sata"
>
> As discussed on IRC, I don't like the approach of trying to define
> generic names for these ip cores. Too much can change in the future
> to make the definition of the generic type drift over time. Better to
> always refer to exact chip variants.
>
> ie. Assuming mpc8315 was the first part to contain the sata core; the
> dts should claim "fsl,CHIP-sata","fsl,mpc8315-sata" instead of
> "fsl,CHIP-sata","fsl,pq-sata".
>
> It ends up being the same amount of work to support, but it doesn't
> fall into the trap of making stuff up.
>
> Another example; when describing serial ports, we still use an
> *ancient* device to claim compatibility with: "ns16550". ns16550 is
> specific, not generic, yet everyone still knows what it means.
Think of the 'specific' name as 'fsl,pq-sata'. Just like ns16550
there are lot of variants that do slightly different things which is
captured by the even more specific 'fsl,mpc8313-sata' name.
I note your disagreement. :)
- k
^ permalink raw reply
* Re: [PATCH] [POWERPC] Add docs for Freescale DMA & DMA channel device tree nodes
From: Kumar Gala @ 2008-01-22 22:02 UTC (permalink / raw)
To: Timur Tabi; +Cc: Scott Wood, linuxppc-dev
In-Reply-To: <4796605B.2000807@freescale.com>
On Jan 22, 2008, at 3:30 PM, Timur Tabi wrote:
> Kumar Gala wrote:
>> Signed-off-by: Zhang Wei <wei.zhang@freescale.com>
>> Signed-off-by: Ebony Zhu <ebony.zhu@freescale.com>
>> Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
>> ---
>> Guys please review and make sure I got all your previous comments
>> fixed
>> up. I've added cell-index. and the examples should represent real
>> HW.
>> Documentation/powerpc/booting-without-of.txt | 128 ++++++++++++++++
>> ++++++++++
>> 1 files changed, 128 insertions(+), 0 deletions(-)
>> diff --git a/Documentation/powerpc/booting-without-of.txt b/
>> Documentation/powerpc/booting-without-of.txt
>> index da98154..3584c33 100644
>> --- a/Documentation/powerpc/booting-without-of.txt
>> +++ b/Documentation/powerpc/booting-without-of.txt
>> @@ -2615,6 +2615,134 @@ platforms are moved over to use the
>> flattened-device-tree model.
>> - clock-frequency : The frequency of the input clock, which
>> typically
>> comes from an on-board dedicated
>> oscillator.
>> + * Freescale 83xx DMA Controller
>> +
>> + Freescale PowerPC 83xx have on chip general purpose DMA
>> controllers.
>> +
>> + Required properties:
>> +
>> + - compatible : compatible list, contains 2 entries,
>> first is
>> + "fsl,CHIP-dma", where CHIP is the processor
>> + (mpc8349, mpc8360, etc.) and the second is
>> + "fsl,elo-dma"
>> + - reg : <registers mapping for DMA general
>> status reg>
>> + - ranges : Should be defined as specified in 1) to describe
>> the
>> + DMA controller channels.
>
> What does "Should be defined as specified in 1)" mean?
Its referring to section 1 of the doc on ranges. Other nodes use this
description for ranges. (soc, muram)
>> + - cell-index : controller index. 0 for controller @
>> 0x8100
>
> This should be more generic. I believe for each of our SoCs, we
> designation one DMA controller to be "DMA Controller 1", and that
> one should have a cell-index of "0".
Ok, on 83xx that controller is always at offset 0x8100.
- k
^ permalink raw reply
* Re: [PATCH 0/6] PS3: gelic: gelic updates for 2.6.25
From: John W. Linville @ 2008-01-22 21:12 UTC (permalink / raw)
To: Masakazu Mokuno; +Cc: netdev, Linux/PPC Development
In-Reply-To: <20071213181146.BF69.MOKUNO@sm.sony.co.jp>
On Thu, Dec 13, 2007 at 07:38:28PM +0900, Masakazu Mokuno wrote:
> Here is a set of updates for PS3 gelic network driver.
> This patch set requires other patches which were already submitted by
> Geert (http://marc.info/?l=linux-kernel&m=119626095605487).
>
> [1] PS3: gelic: Fix the wrong dev_id passed
> [2] PS3: gelic: Add endianness macros
> [3] PS3: gelic: Code cleanup
> [4] PS3: gelic: Remove duplicated ethtool handers
> [5] PS3: gelic: Add support for port link status
> [6] PS3: gelic: Add support for dual network interface
>
> This is also a set of prerequisite for new wireless driver for PS3, which
> I'll submit later.
These seem to not have been applied, but I couldn't find any stated
reason. Did they just get lost? Withdrawn?
Will these be applied? There is a wireless patch that depends on them.
If not, will the wireless portion be refactored to not require these
patches?
Thanks,
John
--
John W. Linville
linville@tuxdriver.com
^ permalink raw reply
* Re: [PATCH] [POWERPC] Add docs for Freescale DMA & DMA channel device tree nodes
From: Kumar Gala @ 2008-01-22 22:00 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev, Timur Tabi
In-Reply-To: <479664AE.9060107@freescale.com>
On Jan 22, 2008, at 3:48 PM, Scott Wood wrote:
> Timur Tabi wrote:
>> On 83xx, all DMA channels share the same interrupt?
>
> Yes.
>
>> Couldn't we just specify the same IRQ in each channel's node, so
>> that they look the same across 83xx, 85xx, and 86xx?
>
> The consensus that I thought we had reached was to let 83xx specify
> the interrupt in the controller node (to make things simple for a
> driver using the shared summary register rather than registering
> four handlers for the same IRQ), but require that it also be in the
> channel node, and that if there is an interrupt in the controller
> node, that it be the same as in all the channels.
This was my understanding.. however we might not be documentation that
clearly at this point.
>> My sound driver doesn't use Extended Mode, but it does check for
>> "fsl,8610-dma-channel". I'm thinking that maybe I should change to
>> to look for "elo" or "eloplus", but it would be nice if we could
>> make the DMA node for an 86xx SoC compatible with a driver that
>> expects "fsl,elo-dma-channel".
>
> Sure it'd be nice, but it's not possible without going back in time
> and convincing the hardware people to make them 100% compatible.
exactly. You forget minor things like 83xx reg set is little endian
and 85xx/86xx is big endian.
- k
^ permalink raw reply
* Re: [PATCH] [POWERPC] Add docs for Freescale PowerQUICC SATA device tree nodes
From: Grant Likely @ 2008-01-22 21:54 UTC (permalink / raw)
To: Kumar Gala; +Cc: Scott Wood, linuxppc-dev, Timur Tabi
In-Reply-To: <Pine.LNX.4.64.0801221536430.25559@blarg.am.freescale.net>
On 1/22/08, Kumar Gala <galak@kernel.crashing.org> wrote:
> Signed-off-by: Li Yang <leoli@freescale.com>
> Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
> ---
> Documentation/powerpc/booting-without-of.txt | 30 ++++++++++++++++++++++++++
> 1 files changed, 30 insertions(+), 0 deletions(-)
>
> diff --git a/Documentation/powerpc/booting-without-of.txt b/Documentation/powerpc/booting-without-of.txt
> index 3584c33..387310a 100644
> --- a/Documentation/powerpc/booting-without-of.txt
> +++ b/Documentation/powerpc/booting-without-of.txt
> @@ -2743,6 +2743,36 @@ platforms are moved over to use the flattened-device-tree model.
> };
> };
>
> + * Freescale 8xxx/3.0 Gb/s SATA nodes
> +
> + SATA nodes are defined to describe on-chip Serial ATA controllers.
> + Each SATA port should have its own node.
> +
> + Required properties:
> + - compatible : compatible list, contains 2 entries, first is
> + "fsl,CHIP-sata", where CHIP is the processor
> + (mpc8315, mpc8379, etc.) and the second is
> + "fsl,pq-sata"
As discussed on IRC, I don't like the approach of trying to define
generic names for these ip cores. Too much can change in the future
to make the definition of the generic type drift over time. Better to
always refer to exact chip variants.
ie. Assuming mpc8315 was the first part to contain the sata core; the
dts should claim "fsl,CHIP-sata","fsl,mpc8315-sata" instead of
"fsl,CHIP-sata","fsl,pq-sata".
It ends up being the same amount of work to support, but it doesn't
fall into the trap of making stuff up.
Another example; when describing serial ports, we still use an
*ancient* device to claim compatibility with: "ns16550". ns16550 is
specific, not generic, yet everyone still knows what it means.
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: [PATCH] [POWERPC] Add docs for Freescale DMA & DMA channel device tree nodes
From: Scott Wood @ 2008-01-22 21:48 UTC (permalink / raw)
To: Timur Tabi; +Cc: linuxppc-dev
In-Reply-To: <4796605B.2000807@freescale.com>
Timur Tabi wrote:
> On 83xx, all DMA channels share the same interrupt?
Yes.
> Couldn't we just
> specify the same IRQ in each channel's node, so that they look the same
> across 83xx, 85xx, and 86xx?
The consensus that I thought we had reached was to let 83xx specify the
interrupt in the controller node (to make things simple for a driver
using the shared summary register rather than registering four handlers
for the same IRQ), but require that it also be in the channel node, and
that if there is an interrupt in the controller node, that it be the
same as in all the channels.
> My sound driver doesn't use Extended Mode,
> but it does check for "fsl,8610-dma-channel". I'm thinking that maybe I
> should change to to look for "elo" or "eloplus", but it would be nice if
> we could make the DMA node for an 86xx SoC compatible with a driver that
> expects "fsl,elo-dma-channel".
Sure it'd be nice, but it's not possible without going back in time and
convincing the hardware people to make them 100% compatible.
-Scott
^ permalink raw reply
* Re: crash in kmem_cache_init
From: Olaf Hering @ 2008-01-22 21:45 UTC (permalink / raw)
To: Mel Gorman
Cc: lee.schermerhorn, Linux MM, linux-kernel, linuxppc-dev,
Pekka Enberg, Aneesh Kumar K.V, hanth Aravamudan, akpm,
KAMEZAWA Hiroyuki, Christoph Lameter
In-Reply-To: <20080122195448.GA15567@csn.ul.ie>
On Tue, Jan 22, Mel Gorman wrote:
> http://www.csn.ul.ie/~mel/postings/slab-20080122/partial-revert-slab-changes.patch
> .. Can you please check on your machine if it fixes your problem?
It does not fix or change the nature of the crash.
> Olaf, please confirm whether you need the patch below as well as the
> revert to make your machine boot.
It crashes now in a different way if the patch below is applied:
Linux version 2.6.24-rc8-ppc64 (olaf@lingonberry) (gcc version 4.1.2 20070115 (prerelease) (SUSE Linux)) #43 SMP Tue Jan 22 22:39:05 CET 2008
[boot]0012 Setup Arch
EEH: PCI Enhanced I/O Error Handling Enabled
PPC64 nvram contains 8192 bytes
Zone PFN ranges:
DMA 0 -> 892928
Normal 892928 -> 892928
Movable zone start PFN for each node
early_node_map[1] active PFN ranges
1: 0 -> 892928
Could not find start_pfn for node 0
[boot]0015 Setup Done
Built 2 zonelists in Node order, mobility grouping on. Total pages: 880720
Policy zone: DMA
Kernel command line: debug xmon=on panic=1
[boot]0020 XICS Init
xics: no ISA interrupt controller
[boot]0021 XICS Done
PID hash table entries: 4096 (order: 12, 32768 bytes)
time_init: decrementer frequency = 275.070000 MHz
time_init: processor frequency = 2197.800000 MHz
clocksource: timebase mult[e8ab05] shift[22] registered
clockevent: decrementer mult[466a] shift[16] cpu[0]
Console: colour dummy device 80x25
console handover: boot [udbg-1] -> real [hvc0]
Dentry cache hash table entries: 524288 (order: 10, 4194304 bytes)
Inode-cache hash table entries: 262144 (order: 9, 2097152 bytes)
freeing bootmem node 1
Memory: 3496632k/3571712k available (6188k kernel code, 75080k reserved, 1324k data, 1220k bss, 304k init)
Unable to handle kernel paging request for data at address 0x00000058
Faulting instruction address: 0xc0000000000fe018
cpu 0x0: Vector: 300 (Data Access) at [c00000000075bac0]
pc: c0000000000fe018: .setup_cpu_cache+0x184/0x1f4
lr: c0000000000fdfa8: .setup_cpu_cache+0x114/0x1f4
sp: c00000000075bd40
msr: 8000000000009032
dar: 58
dsisr: 42000000
current = 0xc000000000665a50
paca = 0xc000000000666380
pid = 0, comm = swapper
enter ? for help
[c00000000075bd40] c0000000000fb368 .kmem_cache_create+0x3c0/0x478 (unreliable)
[c00000000075be20] c0000000005e6780 .kmem_cache_init+0x284/0x4f4
[c00000000075bee0] c0000000005bf8ec .start_kernel+0x2f8/0x3fc
[c00000000075bf90] c000000000008590 .start_here_common+0x60/0xd0
0:mon>
0xc0000000000fe018 is in setup_cpu_cache (/home/olaf/kernel/git/linux-2.6-numa/mm/slab.c:2111).
2106 BUG_ON(!cachep->nodelists[node]);
2107 kmem_list3_init(cachep->nodelists[node]);
2108 }
2109 }
2110 }
2111 cachep->nodelists[numa_node_id()]->next_reap =
2112 jiffies + REAPTIMEOUT_LIST3 +
2113 ((unsigned long)cachep) % REAPTIMEOUT_LIST3;
2114
2115 cpu_cache_get(cachep)->avail = 0;
^ permalink raw reply
* [PATCH] [POWERPC] Add docs for Freescale PowerQUICC SATA device tree nodes
From: Kumar Gala @ 2008-01-22 21:37 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Scott Wood, Timur Tabi
Signed-off-by: Li Yang <leoli@freescale.com>
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
---
Documentation/powerpc/booting-without-of.txt | 30 ++++++++++++++++++++++++++
1 files changed, 30 insertions(+), 0 deletions(-)
diff --git a/Documentation/powerpc/booting-without-of.txt b/Documentation/powerpc/booting-without-of.txt
index 3584c33..387310a 100644
--- a/Documentation/powerpc/booting-without-of.txt
+++ b/Documentation/powerpc/booting-without-of.txt
@@ -2743,6 +2743,36 @@ platforms are moved over to use the flattened-device-tree model.
};
};
+ * Freescale 8xxx/3.0 Gb/s SATA nodes
+
+ SATA nodes are defined to describe on-chip Serial ATA controllers.
+ Each SATA port should have its own node.
+
+ Required properties:
+ - compatible : compatible list, contains 2 entries, first is
+ "fsl,CHIP-sata", where CHIP is the processor
+ (mpc8315, mpc8379, etc.) and the second is
+ "fsl,pq-sata"
+ - interrupts : <interrupt mapping for SATA IRQ>
+ - cell-index : controller index.
+ 1 for controller @ 0x18000
+ 2 for controller @ 0x19000
+ 3 for controller @ 0x1a000
+ 4 for controller @ 0x1b000
+
+ Optional properties:
+ - interrupt-parent : optional, if needed for interrupt mapping
+ - reg : <registers mapping>
+
+ Example:
+
+ sata@18000 {
+ compatible = "fsl,mpc8379-sata", "fsl,pq-sata";
+ reg = <0x18000 0x1000>;
+ cell-index = <1>;
+ interrupts = <2c 8>;
+ interrupt-parent = < &ipic >;
+ };
More devices will be defined as this spec matures.
--
1.5.3.7
^ permalink raw reply related
* Re: crash in kmem_cache_init
From: Christoph Lameter @ 2008-01-22 21:34 UTC (permalink / raw)
To: Mel Gorman
Cc: lee.schermerhorn, Olaf Hering, Linux MM, linux-kernel,
linuxppc-dev, Pekka Enberg, Aneesh Kumar K.V, hanth Aravamudan,
akpm, KAMEZAWA Hiroyuki
In-Reply-To: <20080122212654.GB15567@csn.ul.ie>
On Tue, 22 Jan 2008, Mel Gorman wrote:
> > After you reverted the slab memoryless node patch there should be per node
> > structures created for node 0 unless the node is marked offline. Is it? If
> > so then you are booting a cpu that is associated with an offline node.
> >
>
> I'll roll a patch that prints out the online states before startup and
> see what it looks like.
Ok. Great.
>
> > > Can you see a better solution than this?
> >
> > Well this means that bootstrap will work by introducing foreign objects
> > into the per cpu queue (should only hold per cpu objects). They will
> > later be consumed and then the queues will contain the right objects so
> > the effect of the patch is minimal.
> >
>
> By minimal, do you mean that you expect it to break in some other
> respect later or minimal as in "this is bad but should not have no
> adverse impact".
Should not have any adverse impact after the objects from the cpu queue
have been consumed. If the cache_reaper tries to shift objects back
from the per cpu queue into slabs then BUG_ONs may be triggered. Make sure
you run the tests with full debugging please.
> Whatever this was a problem fixed in the past or not, it's broken again now
> :( . It's possible that there is a __GFP_THISNODE that can be dropped early
> at boot-time that would also fix this problem in a way that doesn't
> affect runtime (like altering cache_grow in my patch does).
The dropping of GFP_THISNODE has the same effect as your patch.
Objects from another node get into the per cpu queue. And on free we
assume that per cpu queue objects are from the local node. If debug is on
then we check that with BUG_ONs.
^ permalink raw reply
* Re: [PATCH] [POWERPC] Add docs for Freescale DMA & DMA channel device tree nodes
From: Timur Tabi @ 2008-01-22 21:30 UTC (permalink / raw)
To: Kumar Gala; +Cc: Scott Wood, linuxppc-dev
In-Reply-To: <Pine.LNX.4.64.0801221511540.24873@blarg.am.freescale.net>
Kumar Gala wrote:
> Signed-off-by: Zhang Wei <wei.zhang@freescale.com>
> Signed-off-by: Ebony Zhu <ebony.zhu@freescale.com>
> Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
> ---
>
> Guys please review and make sure I got all your previous comments fixed
> up. I've added cell-index. and the examples should represent real HW.
>
> Documentation/powerpc/booting-without-of.txt | 128 ++++++++++++++++++++++++++
> 1 files changed, 128 insertions(+), 0 deletions(-)
>
> diff --git a/Documentation/powerpc/booting-without-of.txt b/Documentation/powerpc/booting-without-of.txt
> index da98154..3584c33 100644
> --- a/Documentation/powerpc/booting-without-of.txt
> +++ b/Documentation/powerpc/booting-without-of.txt
> @@ -2615,6 +2615,134 @@ platforms are moved over to use the flattened-device-tree model.
> - clock-frequency : The frequency of the input clock, which typically
> comes from an on-board dedicated oscillator.
>
> + * Freescale 83xx DMA Controller
> +
> + Freescale PowerPC 83xx have on chip general purpose DMA controllers.
> +
> + Required properties:
> +
> + - compatible : compatible list, contains 2 entries, first is
> + "fsl,CHIP-dma", where CHIP is the processor
> + (mpc8349, mpc8360, etc.) and the second is
> + "fsl,elo-dma"
> + - reg : <registers mapping for DMA general status reg>
> + - ranges : Should be defined as specified in 1) to describe the
> + DMA controller channels.
What does "Should be defined as specified in 1)" mean?
> + - cell-index : controller index. 0 for controller @ 0x8100
This should be more generic. I believe for each of our SoCs, we designation one
DMA controller to be "DMA Controller 1", and that one should have a cell-index
of "0".
> + - interrupts : <interrupt mapping for DMA IRQ>
> + - interrupt-parent : optional, if needed for interrupt mapping
On 83xx, all DMA channels share the same interrupt? Couldn't we just specify
the same IRQ in each channel's node, so that they look the same across 83xx,
85xx, and 86xx? My sound driver doesn't use Extended Mode, but it does check
for "fsl,8610-dma-channel". I'm thinking that maybe I should change to to look
for "elo" or "eloplus", but it would be nice if we could make the DMA node for
an 86xx SoC compatible with a driver that expects "fsl,elo-dma-channel".
--
Timur Tabi
Linux kernel developer at Freescale
^ permalink raw reply
* Re: crash in kmem_cache_init
From: Mel Gorman @ 2008-01-22 21:26 UTC (permalink / raw)
To: Christoph Lameter
Cc: lee.schermerhorn, Olaf Hering, Linux MM, linux-kernel,
linuxppc-dev, Pekka Enberg, Aneesh Kumar K.V, hanth Aravamudan,
akpm, KAMEZAWA Hiroyuki
In-Reply-To: <Pine.LNX.4.64.0801221203340.27950@schroedinger.engr.sgi.com>
On (22/01/08 12:11), Christoph Lameter didst pronounce:
> On Tue, 22 Jan 2008, Mel Gorman wrote:
>
> > Christoph/Pekka, this patch is papering over the problem and something
> > more fundamental may be going wrong. The crash occurs because l3 is NULL
> > and the cache is kmem_cache so this is early in the boot process. It is
> > selecting l3 based on node 2 which is correct in terms of available memory
> > but it initialises the lists on node 0 because that is the node the CPUs are
> > located. Hence later it uses an uninitialised nodelists and BLAM. Relevant
> > parts of the log for seeing the memoryless nodes in relation to CPUs is;
>
> Would it be possible to run the bootstrap on a cpu that has a
> node with memory associated to it?
Not in the way the machine is currently configured. All the CPUs appear to
be on a node with no memory. It's best to assume I cannot get the machine
reconfigured (which just hides the bug anyway). Physically, it's thousands
of miles away so I can't do the work. I can get lab support to do the job
but that will take a fair while and at the end of the day, it doesn't tell
us a lot. We know that other PPC64 machines work so it's not a general problem.
> I believe we had the same situation
> last year when GFP_THISNODE was introduced?
>
It feels vaguely familiar but I don't recall the details in sufficient detail
to recognise if this is the same problem or not.
> After you reverted the slab memoryless node patch there should be per node
> structures created for node 0 unless the node is marked offline. Is it? If
> so then you are booting a cpu that is associated with an offline node.
>
I'll roll a patch that prints out the online states before startup and
see what it looks like.
> > Can you see a better solution than this?
>
> Well this means that bootstrap will work by introducing foreign objects
> into the per cpu queue (should only hold per cpu objects). They will
> later be consumed and then the queues will contain the right objects so
> the effect of the patch is minimal.
>
By minimal, do you mean that you expect it to break in some other
respect later or minimal as in "this is bad but should not have no
adverse impact".
> I thought we fixed the similar situation last year by dropping
> GFP_THISNODE for some allocations?
>
Whatever this was a problem fixed in the past or not, it's broken again now
:( . It's possible that there is a __GFP_THISNODE that can be dropped early
at boot-time that would also fix this problem in a way that doesn't
affect runtime (like altering cache_grow in my patch does).
--
Mel Gorman
Part-time Phd Student Linux Technology Center
University of Limerick IBM Dublin Software Lab
^ permalink raw reply
* Re: [PATCH v2 1/2] Add localbus and flash nodes to mpc8641_hpcn.dts
From: Jon Loeliger @ 2008-01-22 21:22 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
In-Reply-To: <65C80AAA-CC92-41BC-86FC-D74A2C7D5059@kernel.crashing.org>
Kumar Gala wrote:
> I'm assuming he's listed CS1, CS2, and CS3 even though we don't have a
> children yet. (second flash chip, CF, and pixis).
>
> - k
OK -- I just wasn't sure if you wanted the other
CS entries for nodes that weren't actually present yet.
jdl
^ permalink raw reply
* Re: [PATCH v2 1/2] Add localbus and flash nodes to mpc8641_hpcn.dts
From: Wade Farnsworth @ 2008-01-22 21:19 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
In-Reply-To: <65C80AAA-CC92-41BC-86FC-D74A2C7D5059@kernel.crashing.org>
On Tue, 2008-01-22 at 15:07 -0600, Kumar Gala wrote:
> On Jan 22, 2008, at 2:41 PM, Jon Loeliger wrote:
>
> > Wade Farnsworth wrote:
> >
> >> +
> >> + ranges = <0 0 ff800000 00800000
> >> + 1 0 fe000000 01000000
> >> + 2 0 f8200000 00100000
> >> + 3 0 f8100000 00100000>;
> >> +
> >
> > I think you want just:
> >
> > ranges = <0 0 f8000000 8000000>
Wouldn't that cover all of the CCSR regs, not just CS0?
> >
> > right? And is it really on CS 0?
>
> I'm assuming he's listed CS1, CS2, and CS3 even though we don't have a
> children yet. (second flash chip, CF, and pixis).
Yes that's correct.
--Wade
^ permalink raw reply
* [PATCH] [POWERPC] Add docs for Freescale DMA & DMA channel device tree nodes
From: Kumar Gala @ 2008-01-22 21:13 UTC (permalink / raw)
To: Timur Tabi, Scott Wood; +Cc: linuxppc-dev
Signed-off-by: Zhang Wei <wei.zhang@freescale.com>
Signed-off-by: Ebony Zhu <ebony.zhu@freescale.com>
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
---
Guys please review and make sure I got all your previous comments fixed
up. I've added cell-index. and the examples should represent real HW.
Documentation/powerpc/booting-without-of.txt | 128 ++++++++++++++++++++++++++
1 files changed, 128 insertions(+), 0 deletions(-)
diff --git a/Documentation/powerpc/booting-without-of.txt b/Documentation/powerpc/booting-without-of.txt
index da98154..3584c33 100644
--- a/Documentation/powerpc/booting-without-of.txt
+++ b/Documentation/powerpc/booting-without-of.txt
@@ -2615,6 +2615,134 @@ platforms are moved over to use the flattened-device-tree model.
- clock-frequency : The frequency of the input clock, which typically
comes from an on-board dedicated oscillator.
+ * Freescale 83xx DMA Controller
+
+ Freescale PowerPC 83xx have on chip general purpose DMA controllers.
+
+ Required properties:
+
+ - compatible : compatible list, contains 2 entries, first is
+ "fsl,CHIP-dma", where CHIP is the processor
+ (mpc8349, mpc8360, etc.) and the second is
+ "fsl,elo-dma"
+ - reg : <registers mapping for DMA general status reg>
+ - ranges : Should be defined as specified in 1) to describe the
+ DMA controller channels.
+ - cell-index : controller index. 0 for controller @ 0x8100
+ - interrupts : <interrupt mapping for DMA IRQ>
+ - interrupt-parent : optional, if needed for interrupt mapping
+
+
+ - DMA channel nodes:
+ - compatible : compatible list, contains 2 entries, first is
+ "fsl,CHIP-dma-channel", where CHIP is the processor
+ (mpc8349, mpc8350, etc.) and the second is
+ "fsl,elo-dma-channel"
+ - reg : <registers mapping for channel>
+ - cell-index : dma channel index starts at 0.
+
+ Optional properties:
+ - interrupts : <interrupt mapping for DMA channel IRQ>
+ (on 83xx this is expected to be identical to
+ the interrupts property of the parent node)
+ - interrupt-parent : optional, if needed for interrupt mapping
+
+ Example:
+ dma@82a8 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "fsl,mpc8349-dma", "fsl,elo-dma";
+ reg = <82a8 4>;
+ ranges = <0 8100 1a4>;
+ interrupt-parent = <&ipic>;
+ interrupts = <47 8>;
+ cell-index = <0>;
+ dma-channel@0 {
+ compatible = "fsl,mpc8349-dma-channel", "fsl,elo-dma-channel";
+ cell-index = <0>;
+ reg = <0 80>;
+ };
+ dma-channel@80 {
+ compatible = "fsl,mpc8349-dma-channel", "fsl,elo-dma-channel";
+ cell-index = <1>;
+ reg = <80 80>;
+ };
+ dma-channel@100 {
+ compatible = "fsl,mpc8349-dma-channel", "fsl,elo-dma-channel";
+ cell-index = <2>;
+ reg = <100 80>;
+ };
+ dma-channel@180 {
+ compatible = "fsl,mpc8349-dma-channel", "fsl,elo-dma-channel";
+ cell-index = <3>;
+ reg = <180 80>;
+ };
+ };
+
+ * Freescale 85xx/86xx DMA Controller
+
+ Freescale PowerPC 85xx/86xx have on chip general purpose DMA controllers.
+
+ Required properties:
+
+ - compatible : compatible list, contains 2 entries, first is
+ "fsl,CHIP-dma", where CHIP is the processor
+ (mpc8540, mpc8540, etc.) and the second is
+ "fsl,eloplus-dma"
+ - reg : <registers mapping for DMA general status reg>
+ - cell-index : controller index. 0 for controller @ 0x21000,
+ 1 for controller @ 0xc000
+ - ranges : Should be defined as specified in 1) to describe the
+ DMA controller channels.
+
+ - DMA channel nodes:
+ - compatible : compatible list, contains 2 entries, first is
+ "fsl,CHIP-dma-channel", where CHIP is the processor
+ (mpc8540, mpc8560, etc.) and the second is
+ "fsl,eloplus-dma-channel"
+ - cell-index : dma channel index starts at 0.
+ - reg : <registers mapping for channel>
+ - interrupts : <interrupt mapping for DMA channel IRQ>
+ - interrupt-parent : optional, if needed for interrupt mapping
+
+ Example:
+ dma@21300 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "fsl,mpc8540-dma", "fsl,eloplus-dma";
+ reg = <21300 4>;
+ ranges = <0 21100 200>;
+ cell-index = <0>;
+ dma-channel@0 {
+ compatible = "fsl,mpc8540-dma-channel", "fsl,eloplus-dma-channel";
+ reg = <0 80>;
+ cell-index = <0>;
+ interrupt-parent = <&mpic>;
+ interrupts = <14 2>;
+ };
+ dma-channel@80 {
+ compatible = "fsl,mpc8540-dma-channel", "fsl,eloplus-dma-channel";
+ reg = <80 80>;
+ cell-index = <1>;
+ interrupt-parent = <&mpic>;
+ interrupts = <15 2>;
+ };
+ dma-channel@100 {
+ compatible = "fsl,mpc8540-dma-channel", "fsl,eloplus-dma-channel";
+ reg = <100 80>;
+ cell-index = <2>;
+ interrupt-parent = <&mpic>;
+ interrupts = <16 2>;
+ };
+ dma-channel@180 {
+ compatible = "fsl,mpc8540-dma-channel", "fsl,eloplus-dma-channel";
+ reg = <180 80>;
+ cell-index = <3>;
+ interrupt-parent = <&mpic>;
+ interrupts = <17 2>;
+ };
+ };
+
More devices will be defined as this spec matures.
--
1.5.3.7
^ permalink raw reply related
* [PATCH 8/8] pseries: phyp dump: config file
From: Manish Ahuja @ 2008-01-22 21:09 UTC (permalink / raw)
To: ppc-dev, paulus; +Cc: mahuja, linasvepstas, lkessler, strosake
In-Reply-To: <4796401D.5010907@austin.ibm.com>
To: linuxppc-dev@ozlabs.org
Add hypervisor-assisted dump to kernel config
Signed-off-by: Linas Vepstas <linasvepstas@gmail.com>
-----
arch/powerpc/Kconfig | 11 +++++++++++
1 file changed, 11 insertions(+)
Index: linux-2.6.24-rc2-git4/arch/powerpc/Kconfig
===================================================================
--- linux-2.6.24-rc2-git4.orig/arch/powerpc/Kconfig 2007-11-14 16:39:20.000000000 -0600
+++ linux-2.6.24-rc2-git4/arch/powerpc/Kconfig 2007-11-15 14:27:33.000000000 -0600
@@ -261,6 +261,17 @@ config CRASH_DUMP
Don't change this unless you know what you are doing.
+config PHYP_DUMP
+ bool "Hypervisor-assisted dump (EXPERIMENTAL)"
+ depends on PPC_PSERIES && EXPERIMENTAL
+ default y
+ help
+ Hypervisor-assisted dump is meant to be a kdump replacement
+ offering robustness and speed not possible without system
+ hypervisor assistence.
+
+ If unsure, say "Y"
+
config PPCBUG_NVRAM
bool "Enable reading PPCBUG NVRAM during boot" if PPLUS || LOPEC
default y if PPC_PREP
^ permalink raw reply
* Re: [PATCH v2 1/2] Add localbus and flash nodes to mpc8641_hpcn.dts
From: Kumar Gala @ 2008-01-22 21:07 UTC (permalink / raw)
To: Jon Loeliger; +Cc: linuxppc-dev
In-Reply-To: <47965506.9070305@freescale.com>
On Jan 22, 2008, at 2:41 PM, Jon Loeliger wrote:
> Wade Farnsworth wrote:
>
>> +
>> + ranges = <0 0 ff800000 00800000
>> + 1 0 fe000000 01000000
>> + 2 0 f8200000 00100000
>> + 3 0 f8100000 00100000>;
>> +
>
> I think you want just:
>
> ranges = <0 0 f8000000 8000000>
>
> right? And is it really on CS 0?
I'm assuming he's listed CS1, CS2, and CS3 even though we don't have a
children yet. (second flash chip, CF, and pixis).
- k
^ permalink raw reply
* [PATCH 7/8] pseries: phyp dump: Tracking memory range freed.
From: Manish Ahuja @ 2008-01-22 21:07 UTC (permalink / raw)
To: ppc-dev, paulus; +Cc: mahuja, linasvepstas, lkessler, strosake
In-Reply-To: <4796401D.5010907@austin.ibm.com>
This patch tracks the size freed. For now it does a simple
rudimentary calculation of the ranges freed. The idea is
to keep it simple at the external shell script level and
send in large chunks for now.
Signed-off-by: Manish Ahuja <mahuja@us.ibm.com>
-----
---
arch/powerpc/platforms/pseries/phyp_dump.c | 35 +++++++++++++++++++++++++++++
1 file changed, 35 insertions(+)
Index: 2.6.24-rc5/arch/powerpc/platforms/pseries/phyp_dump.c
===================================================================
--- 2.6.24-rc5.orig/arch/powerpc/platforms/pseries/phyp_dump.c 2008-01-21 23:30:18.000000000 -0600
+++ 2.6.24-rc5/arch/powerpc/platforms/pseries/phyp_dump.c 2008-01-21 23:42:04.000000000 -0600
@@ -275,6 +275,39 @@ void release_memory_range(unsigned long
}
}
+/**
+ * track_freed_range -- Counts the range being freed.
+ * Once the counter goes to zero, it re-registers dump for
+ * future use.
+ */
+static void
+track_freed_range(unsigned long addr, unsigned long length)
+{
+ static unsigned long scratch_area_size, reserved_area_size;
+
+ if (addr < phyp_dump_info->init_reserve_start)
+ return;
+
+ if ((addr >= phyp_dump_info->init_reserve_start) &&
+ (addr <= phyp_dump_info->init_reserve_start +
+ phyp_dump_info->init_reserve_size))
+ reserved_area_size += length;
+
+ if ((addr >= phyp_dump_info->reserved_scratch_addr) &&
+ (addr <= phyp_dump_info->reserved_scratch_addr +
+ phyp_dump_info->reserved_scratch_size))
+ scratch_area_size += length;
+
+ if ((reserved_area_size == phyp_dump_info->init_reserve_size) &&
+ (scratch_area_size == phyp_dump_info->reserved_scratch_size)) {
+
+ invalidate_last_dump(&phdr,
+ phyp_dump_info->reserved_scratch_addr);
+ register_dump_area (&phdr,
+ phyp_dump_info->reserved_scratch_addr);
+ }
+}
+
/* ------------------------------------------------- */
/**
* sysfs_release_region -- sysfs interface to release memory range.
@@ -298,6 +331,8 @@ ssize_t store_release_region(struct kset
if (ret != 2)
return -EINVAL;
+ track_freed_range(start_addr, length);
+
/* Range-check - don't free any reserved memory that
* wasn't reserved for phyp-dump */
if (start_addr < phyp_dump_info->init_reserve_start)
^ permalink raw reply
* Re: [PATCH] Various new ibm405 DCRN #defines
From: Benjamin Herrenschmidt @ 2008-01-22 20:58 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-dev, Joshua Williams
In-Reply-To: <20080122111038.1072dac4@weaponx>
On Tue, 2008-01-22 at 11:10 -0600, Josh Boyer wrote:
> On Tue, 22 Jan 2008 11:08:38 -0600
> Joshua Williams <joshua.williams@qlogic.com> wrote:
>
> > Benjamin Herrenschmidt wrote:
> > > On Mon, 2008-01-21 at 16:43 -0600, Joshua Williams wrote:
> > >> Various new ibm405 DCRN #defines.
> > >>
> > >> Signed-off-by: Joshua Williams <joshua.williams@qlogic.com>
> > >
> > > May I ask what for ? :-) Also, it's all arch/ppc, not arch/powerpc...
> > > nothing we want to improve to much on at this stage unless there's a
> > > really good reason.
> >
> > The 405x #defines were incomplete and this was meant to
> > make them a bit tighter. Since arch/ppc is in life support
> > mode this can wait until the 405x stuff gets moved over to
> > arch/powerpc.
>
> Which 405x stuff? Walnut is moved over already. Other boards will
> need to be ported by people that have those boards.
I have no objection with adding #define's to arch/powerpc somewhere
though I'd like to avoid having 36 different .h files per processor
type.
Ben.
^ permalink raw reply
* [PATCH 6/8] pseries: phyp dump: Unregister and print dump areas.
From: Manish Ahuja @ 2008-01-22 21:05 UTC (permalink / raw)
To: ppc-dev, paulus; +Cc: mahuja, linasvepstas, lkessler, strosake
In-Reply-To: <4796401D.5010907@austin.ibm.com>
Routines to invalidate and unregister dump routines.
Unregister has not been used yet, I will release another
patch for that at a later stage with the kdump integration patches.
There is also a routine which calculates the regions to be
freed and exports that through sysfs.
Signed-off-by: Manish Ahuja <mahuja@us.ibm.com>
-----
---
arch/powerpc/platforms/pseries/phyp_dump.c | 101 +++++++++++++++++++++++++----
include/asm/phyp_dump.h | 3
2 files changed, 93 insertions(+), 11 deletions(-)
Index: 2.6.24-rc5/arch/powerpc/platforms/pseries/phyp_dump.c
===================================================================
--- 2.6.24-rc5.orig/arch/powerpc/platforms/pseries/phyp_dump.c 2008-01-21 23:06:20.000000000 -0600
+++ 2.6.24-rc5/arch/powerpc/platforms/pseries/phyp_dump.c 2008-01-21 23:49:10.000000000 -0600
@@ -69,6 +69,10 @@ static struct phyp_dump_header phdr;
#define DUMP_SOURCE_CPU 0x0001
#define DUMP_SOURCE_HPTE 0x0002
#define DUMP_SOURCE_RMO 0x0011
+#define DUMP_ERROR_FLAG 0x2000
+#define DUMP_TRIGGERED 0x4000
+#define DUMP_PERFORMED 0x8000
+
/**
* init_dump_header() - initialize the header declaring a dump
@@ -180,9 +184,15 @@ static void print_dump_header(const stru
static void register_dump_area(struct phyp_dump_header *ph, unsigned long addr)
{
int rc;
- ph->cpu_data.destination_address += addr;
- ph->hpte_data.destination_address += addr;
- ph->kernel_data.destination_address += addr;
+
+ /* Add addr value if not initialized before */
+ if (ph->cpu_data.destination_address == 0) {
+ ph->cpu_data.destination_address += addr;
+ ph->hpte_data.destination_address += addr;
+ ph->kernel_data.destination_address += addr;
+ }
+
+ /* ToDo Invalidate kdump and free memory range. */
do {
rc = rtas_call(ibm_configure_kernel_dump, 3, 1, NULL,
@@ -195,6 +205,46 @@ static void register_dump_area(struct ph
}
}
+static
+void invalidate_last_dump(struct phyp_dump_header *ph, unsigned long addr)
+{
+ int rc;
+
+ /* Add addr value if not initialized before */
+ if (ph->cpu_data.destination_address == 0) {
+ ph->cpu_data.destination_address += addr;
+ ph->hpte_data.destination_address += addr;
+ ph->kernel_data.destination_address += addr;
+ }
+
+ do {
+ rc = rtas_call(ibm_configure_kernel_dump, 3, 1, NULL,
+ 2, ph, sizeof(struct phyp_dump_header));
+ } while (rtas_busy_delay(rc));
+
+ if (rc) {
+ printk (KERN_ERR "phyp-dump: unexpected error (%d) "
+ "on invalidate\n", rc);
+ print_dump_header(ph);
+ }
+}
+
+static void unregister_dump_area(struct phyp_dump_header *ph)
+{
+ int rc;
+
+ do {
+ rc = rtas_call(ibm_configure_kernel_dump, 3, 1, NULL,
+ 3, ph, sizeof(struct phyp_dump_header));
+ } while (rtas_busy_delay(rc));
+
+ if (rc) {
+ printk (KERN_ERR "phyp-dump: unexpected error (%d) "
+ "on unregister\n", rc);
+ print_dump_header(ph);
+ }
+}
+
/* ------------------------------------------------- */
/**
* release_memory_range -- release memory previously lmb_reserved
@@ -205,8 +255,8 @@ static void register_dump_area(struct ph
* lmb_reserved in early boot. The released memory becomes
* available for genreal use.
*/
-static void
-release_memory_range(unsigned long start_pfn, unsigned long nr_pages)
+static
+void release_memory_range(unsigned long start_pfn, unsigned long nr_pages)
{
struct page *rpage;
unsigned long end_pfn;
@@ -237,8 +287,8 @@ release_memory_range(unsigned long start
*
* will release 256MB starting at 1GB.
*/
-static ssize_t
-store_release_region(struct kset *kset, const char *buf, size_t count)
+static
+ssize_t store_release_region(struct kset *kset, const char *buf, size_t count)
{
unsigned long start_addr, length, end_addr;
unsigned long start_pfn, nr_pages;
@@ -266,10 +316,23 @@ store_release_region(struct kset *kset,
return count;
}
-static ssize_t
-show_release_region(struct kset * kset, char *buf)
+static ssize_t show_release_region(struct kset * kset, char *buf)
{
- return sprintf(buf, "ola\n");
+ u64 second_addr_range;
+
+ /* total reserved size - start of scratch area */
+ second_addr_range = phyp_dump_info->init_reserve_size -
+ phyp_dump_info->reserved_scratch_size;
+ return sprintf(buf, "CPU:0x%lx-0x%lx: HPTE:0x%lx-0x%lx:"
+ " DUMP:0x%lx-0x%lx, 0x%lx-0x%lx:\n",
+ phdr.cpu_data.destination_address,
+ phdr.cpu_data.length_copied,
+ phdr.hpte_data.destination_address,
+ phdr.hpte_data.length_copied,
+ phdr.kernel_data.destination_address,
+ phdr.kernel_data.length_copied,
+ phyp_dump_info->init_reserve_start,
+ second_addr_range);
}
static struct subsys_attribute rr = __ATTR(release_region, 0600,
@@ -307,7 +370,6 @@ static int __init phyp_dump_setup(void)
release_all();
return -ENOSYS;
}
- print_dump_header(dump_header);
/* Is there dump data waiting for us? If there isn't,
* then register a new dump area, and release all of
@@ -319,6 +381,7 @@ static int __init phyp_dump_setup(void)
rtas = of_find_node_by_path("/rtas");
dump_header = of_get_property(rtas, "ibm,kernel-dump", &header_len);
of_node_put(rtas);
+ print_dump_header(dump_header);
dump_area_length = init_dump_header(&phdr);
dump_area_start = phyp_dump_info->init_reserve_start & PAGE_MASK; /* align down */
@@ -328,6 +391,22 @@ static int __init phyp_dump_setup(void)
return 0;
}
+ /* re-register the dump area, if old dump was invalid */
+ if ((dump_header) && (dump_header->status & DUMP_ERROR_FLAG)) {
+ invalidate_last_dump(&phdr, dump_area_start);
+ register_dump_area(&phdr, dump_area_start);
+ return 0;
+ }
+
+ if (dump_header) {
+ phyp_dump_info->reserved_scratch_addr =
+ dump_header->cpu_data.destination_address;
+ phyp_dump_info->reserved_scratch_size =
+ dump_header->cpu_data.source_length +
+ dump_header->hpte_data.source_length +
+ dump_header->kernel_data.source_length;
+ }
+
/* Should we create a dump_subsys, analogous to s390/ipl.c ? */
rc = subsys_create_file(&kernel_subsys, &rr);
if (rc)
Index: 2.6.24-rc5/include/asm/phyp_dump.h
===================================================================
--- 2.6.24-rc5.orig/include/asm/phyp_dump.h 2008-01-21 22:21:01.000000000 -0600
+++ 2.6.24-rc5/include/asm/phyp_dump.h 2008-01-21 23:29:05.000000000 -0600
@@ -29,6 +29,9 @@ struct phyp_dump {
/* store cpu & hpte size */
unsigned long cpu_state_size;
unsigned long hpte_region_size;
+ /* previous scratch area values */
+ unsigned long reserved_scratch_addr;
+ unsigned long reserved_scratch_size;
};
extern struct phyp_dump *phyp_dump_info;
^ permalink raw reply
* [PATCH 5/8] pseries: phyp dump: debugging print routines.
From: Manish Ahuja @ 2008-01-22 21:02 UTC (permalink / raw)
To: ppc-dev, paulus; +Cc: mahuja, linasvepstas, lkessler, strosake
In-Reply-To: <4796401D.5010907@austin.ibm.com>
Provide some basic debugging support.
Signed-off-by: Manish Ahuja <mahuja@us.ibm.com>
Signed-off-by: Linas Vepstas <linasvepstas@gmail.com>
-----
arch/powerpc/platforms/pseries/phyp_dump.c | 64 +++++++++++++++++++++++++++--
1 file changed, 60 insertions(+), 4 deletions(-)
Index: 2.6.24-rc5/arch/powerpc/platforms/pseries/phyp_dump.c
===================================================================
--- 2.6.24-rc5.orig/arch/powerpc/platforms/pseries/phyp_dump.c 2008-01-21 02:51:54.000000000 -0600
+++ 2.6.24-rc5/arch/powerpc/platforms/pseries/phyp_dump.c 2008-01-21 02:58:41.000000000 -0600
@@ -2,7 +2,7 @@
* Hypervisor-assisted dump
*
* Linas Vepstas, Manish Ahuja 2007
- * Copyrhgit (c) 2007 IBM Corp.
+ * Copyright (c) 2007 IBM Corp.
*
* This program is free software; you can redistribute it and/or
* modify it under the terms of the GNU General Public License
@@ -122,6 +122,61 @@ static unsigned long init_dump_header(st
return addr_offset;
}
+static void print_dump_header(const struct phyp_dump_header *ph)
+{
+#ifdef DEBUG
+ printk(KERN_INFO "dump header:\n");
+ /* setup some ph->sections required */
+ printk(KERN_INFO "version = %d\n", ph->version);
+ printk(KERN_INFO "Sections = %d\n", ph->num_of_sections);
+ printk(KERN_INFO "Status = 0x%x\n", ph->status);
+
+ /* No ph->disk, so all should be set to 0 */
+ printk(KERN_INFO "Offset to first section 0x%x\n",
+ ph->first_offset_section);
+ printk(KERN_INFO "dump disk sections should be zero\n");
+ printk(KERN_INFO "dump disk section = %d\n", ph->dump_disk_section);
+ printk(KERN_INFO "block num = %ld\n", ph->block_num_dd);
+ printk(KERN_INFO "number of blocks = %ld\n", ph->num_of_blocks_dd);
+ printk(KERN_INFO "dump disk offset = %d\n", ph->offset_dd);
+ printk(KERN_INFO "Max auto time= %d\n", ph->maxtime_to_auto);
+
+ /*set cpu state and hpte states as well scratch pad area */
+ printk(KERN_INFO " CPU AREA \n");
+ printk(KERN_INFO "cpu dump_flags =%d\n", ph->cpu_data.dump_flags);
+ printk(KERN_INFO "cpu source_type =%d\n", ph->cpu_data.source_type);
+ printk(KERN_INFO "cpu error_flags =%d\n", ph->cpu_data.error_flags);
+ printk(KERN_INFO "cpu source_address =%lx\n",
+ ph->cpu_data.source_address);
+ printk(KERN_INFO "cpu source_length =%lx\n",
+ ph->cpu_data.source_length);
+ printk(KERN_INFO "cpu length_copied =%lx\n",
+ ph->cpu_data.length_copied);
+
+ printk(KERN_INFO " HPTE AREA \n");
+ printk(KERN_INFO "HPTE dump_flags =%d\n", ph->hpte_data.dump_flags);
+ printk(KERN_INFO "HPTE source_type =%d\n", ph->hpte_data.source_type);
+ printk(KERN_INFO "HPTE error_flags =%d\n", ph->hpte_data.error_flags);
+ printk(KERN_INFO "HPTE source_address =%lx\n",
+ ph->hpte_data.source_address);
+ printk(KERN_INFO "HPTE source_length =%lx\n",
+ ph->hpte_data.source_length);
+ printk(KERN_INFO "HPTE length_copied =%lx\n",
+ ph->hpte_data.length_copied);
+
+ printk(KERN_INFO " SRSD AREA \n");
+ printk(KERN_INFO "SRSD dump_flags =%d\n", ph->kernel_data.dump_flags);
+ printk(KERN_INFO "SRSD source_type =%d\n", ph->kernel_data.source_type);
+ printk(KERN_INFO "SRSD error_flags =%d\n", ph->kernel_data.error_flags);
+ printk(KERN_INFO "SRSD source_address =%lx\n",
+ ph->kernel_data.source_address);
+ printk(KERN_INFO "SRSD source_length =%lx\n",
+ ph->kernel_data.source_length);
+ printk(KERN_INFO "SRSD length_copied =%lx\n",
+ ph->kernel_data.length_copied);
+#endif
+}
+
static void register_dump_area(struct phyp_dump_header *ph, unsigned long addr)
{
int rc;
@@ -134,9 +189,9 @@ static void register_dump_area(struct ph
1, ph, sizeof(struct phyp_dump_header));
} while (rtas_busy_delay(rc));
- if (rc)
- {
- printk (KERN_ERR "phyp-dump: unexpected error (%d) on register\n", rc);
+ if (rc) {
+ printk(KERN_ERR "phyp-dump: unexpected error (%d) on register\n", rc);
+ print_dump_header(ph);
}
}
@@ -249,6 +304,7 @@ static int __init phyp_dump_setup(void)
release_all();
return -ENOSYS;
}
+ print_dump_header(dump_header);
/* Is there dump data waiting for us? If there isn't,
* then register a new dump area, and release all of
^ permalink raw reply
* Re: [PATCH 2/8] pseries: phyp dump: reserve-release proof-of-concept
From: Manish Ahuja @ 2008-01-22 21:00 UTC (permalink / raw)
To: ppc-dev, paulus, linasvepstas
In-Reply-To: <47964422.7080505@austin.ibm.com>
Reposted this one. I got the email id wrong in this one.
Sorry about that.
Manish
^ permalink raw reply
* Re: Trying 10/HALF
From: Andy Fleming @ 2008-01-22 20:55 UTC (permalink / raw)
To: Siva Prasad; +Cc: linuxppc-dev, linuxppc-embedded
In-Reply-To: <D83235F0F3C86D4D889D8B9A0DA8C6D701494071@corpexc01.corp.networkrobots.com>
On Jan 9, 2008, at 13:35, Siva Prasad wrote:
> Hi,
>
>
>
> After booting, my MPC8641 based board keeps printing =93Trying 10/=20
> HALF=94 for ever. I am unable to use the Ethernet, even though there =20=
> are interrupts occuring. Based on /proc/interrupts, both tx and rx =20
> interrupt count is increasing, and zero count for enet_error =20
> interrupt.
>
>
>
> I think this is coming from drivers/net/phy/phy.c during =20
> autonegotiation. However, I am not sure how to take care of this. =20
> Appreciate some pointers.
>
Hm. That's a bit strange. What kind of PHY are you using? The PHY =20
layer acts like that if auto-negotiation fails and it couldn't =20
establish a link using any other method.
Some things to double-check:
* Are your etsec interrupts correct in your dts. Shouldn't be an =20
issue, but if you copied them from the wrong place, or used an out-of-=20=
date dts, the numbers could be wrong
* Are your PHY interrupts correct in your dts. If the PHY interrupts =20=
are wrong, the PHY Lib might never discover that a link was established
Andy=
^ permalink raw reply
* Re: [PATCH v2 1/2] Add localbus and flash nodes to mpc8641_hpcn.dts
From: Jon Loeliger @ 2008-01-22 20:41 UTC (permalink / raw)
To: Wade Farnsworth; +Cc: linuxppc-dev
In-Reply-To: <1201032819.5716.170.camel@rhino>
Wade Farnsworth wrote:
> +
> + ranges = <0 0 ff800000 00800000
> + 1 0 fe000000 01000000
> + 2 0 f8200000 00100000
> + 3 0 f8100000 00100000>;
> +
I think you want just:
ranges = <0 0 f8000000 8000000>
right? And is it really on CS 0?
jdl
^ permalink raw reply
* Re: [PATCH v2 1/2] Add localbus and flash nodes to mpc8641_hpcn.dts
From: Kumar Gala @ 2008-01-22 20:37 UTC (permalink / raw)
To: Wade Farnsworth; +Cc: linuxppc-dev
In-Reply-To: <1201032819.5716.170.camel@rhino>
On Tue, 22 Jan 2008, Wade Farnsworth wrote:
> Add local bus, flash, and MTD partition nodes to mpc8641_hpcn.dts
>
> Also add compatible field for the soc node, so that it will be picked up
> by of_platform_bus_probe().
>
> Signed-off-by: Wade Farnsworth <wfarnsworth@mvista.com>
>
> ---
> Updated per Kumar's comments.
>
> arch/powerpc/boot/dts/mpc8641_hpcn.dts | 42 +++++++++++++++++++++++
> 1 file changed, 42 insertions(+)
>
applied.
- k
^ permalink raw reply
* Re: [PATCH v2 2/2] MPC8641 HPCN: call of_platform_bus_probe()
From: Kumar Gala @ 2008-01-22 20:36 UTC (permalink / raw)
To: Wade Farnsworth; +Cc: linuxppc-dev
In-Reply-To: <1201033065.5716.175.camel@rhino>
On Tue, 22 Jan 2008, Wade Farnsworth wrote:
> Call of_platform_bus_probe() on the MPC8641 HPCN, similar to what is
> done for other platforms.
>
> Signed-off-by: Wade Farnsworth <wfarnsworth@mvista.com>
>
> ---
> Updated per Kumar's comments.
>
> arch/powerpc/platforms/86xx/mpc86xx_hpcn.c | 14 ++++++++++++++
> 1 file changed, 14 insertions(+)
applied.
- k
^ 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