* Re: Board level compatibility matching
From: Grant Likely @ 2008-08-01 14:27 UTC (permalink / raw)
To: benh; +Cc: linuxppc-dev, devicetree-discuss
In-Reply-To: <1217564739.11188.482.camel@pasglop>
On Thu, Jul 31, 2008 at 10:25 PM, Benjamin Herrenschmidt
<benh@kernel.crashing.org> wrote:
> About this whole generic board mumbo-jumbo: not happening. It's a pipe
> dream, it doesn't work, and it leads to the sort of mess we have in chrp
> where we end up having hacks to identify what exact sort of chrp we have
> and do things differently etc...
I am fully aware of the hell and hacks that went along with chrp. I
am *not* suggesting a do everything platform that must figure out all
the quirks of a board in a single machine definition. I know too well
that is the way of pain.
>
> NOT HAPPENING.
>
> Now, there are two approaches here that are possible:
>
> - Your board is really pretty much exactly the same as board XXX,
> except maybe you have a different flash size or such, and the support
> for board XXX can cope perfectly with it simply due to the device-tree
> the right information.
>
> If that happens to be the case, make your board compatible with board
> XXX. Make that entry -second- in your compatible list, because one day
> you'll figure out that there -is- indeed a difference and I don't want
> to see board XXX code start to grow code to recognise your other board
> and work around the difference. So at that stage, copy board XXX.c file
> and start over with your own board support that matches on your first
> compatible propery entry.
I agree with most of your argument, except I really have problems with
boards claiming compatibility with an older board. My reason is
exactly the reason you state; One day you'll figure out that there is
indeed a difference. The problem is; when the original board (the one
others are claiming compatibility with) gains additional code to fixup
quirks or something, then that code will get changed with no
visibility that it is borking up other boards that are currently
depending on it.
I far prefer the solution I'm currently using in 5200-land where there
is a simple (boring?) board port which *explicitly* states which
boards it supports (see arch/powerpc/platforms/52xx/mpc5200_simple.c).
When someone goes to modify that file, it is explicit that it
currently supports multiple boards. If a board becomes 'non-boring',
then it is removed from the simple platform; the simple platform is
*not* extended to accommodate it.
I *fully* agree that it is insane for the code to grow detection logic
and I've been explicit about not doing anything of the sort in 5200
land. What I am suggesting is that if nothing else claims the board,
then allow the simple platform to bind against it based on the fact
that it uses the same SoC.
However, if I can't get concensus on this approach, then I do /not/
want to go to a boards compatible with other boards scheme. It will
cause breakage and pain that is non-obvious to debug for many users.
BTW, I am also not suggesting that the .dts files themselves try to
claim some kind of 'generic' compatibility. I'm proposing handling
any catch-all cases in the Linux code itself, where it is easy to
change because it is just an implementation detail. Trying to make
the dt 'generic' doesn't make any sense because doing so is almost
always wrong (or will become wrong in the future).
> - Once you figure out that really, those 5 boards here -do- share 99%
> of the code... it's just that one need a workaround at the IRQ fixup
> level, maybe one needs a tweak on a GPIO at boot and one has an issue on
> reboot that needs to be whacked a bit differently ... well, make
> -library- code.
>
> I have no objection of having something like for each ppc_md field
> called X, having a utility file providing an mpc52xx_generic_X function.
> Such a board could then basically have a small .c file whose ppc_md just
> use the generic functions for all except the ones that need to be
> hooked/wrapped/replaced/whatever.
I agree. 5200 code already does this.
g.
^ permalink raw reply
* Re: [i2c] [PATCH] powerpc: i2c-mpc: make speed registers configurable via FDT
From: Grant Likely @ 2008-08-01 14:38 UTC (permalink / raw)
To: Wolfgang Grandegger
Cc: Trent Piepho, Linuxppc-dev, Scott Wood, Timur Tabi, Linux I2C
In-Reply-To: <4892BA6F.3010000@grandegger.com>
On Fri, Aug 1, 2008 at 1:25 AM, Wolfgang Grandegger <wg@grandegger.com> wrote:
> Jon Smirl wrote:
>>
>> On 7/31/08, Trent Piepho <xyzzy@speakeasy.org> wrote:
>>>
>>> On Thu, 31 Jul 2008, Jon Smirl wrote:
>>> > As for the source clock, how about creating a new global like
>>> > ppc_proc_freq called ppc_ipb_freq. The platform code can then set the
>>> > right clock value into the variable. For mpc8xxxx get it from uboot.
>>> > mpc5200 can easily compute it from ppc_proc_freq and checking how the
>>> > ipb divider is set. That will move the clock problem out of the i2c
>>> > driver.
>>>
>>>
>>> There is a huge variation in where the I2C source clock comes from.
>>> Sometimes it's the system bus, sometimes ethernet, sometimes SEC, etc.
>>> If
>>> I look at u-boot (which might not be entirely correct or complete), I
>>> see:
>>>
>>> 83xx: 5 different clock sources
>>> 85xx: 3 different clock sources
>>> 86xx: 2 different clock sources
>>>
>>> But there's more. Sometimes the two I2C controllers don't use the same
>>> clock! So even if you add 10 globals with different clocks, and then
>>> add
>>> code to the mpc i2c driver so if can figure out which one to use given
>>> the
>>> platform, it's still not enough because you need to know which
>>> controller
>>> the device node is for.
>>>
>>> IMHO, what Timur suggested of having u-boot put the source clock into
>>> the
>>> i2c node makes the most sense. U-boot has to figure this out, so why
>>> duplicate the work?
>>>
>>> Here's my idea:
>>>
>>> i2c@0 {
>>> compatible = "fsl-i2c";
>>> bus-frequency = <100000>;
>>>
>>> /* Either */
>>> source-clock-frequency = <0>;
>>> /* OR */
>>> source-clock = <&ccb>;
>>> };
>>
>> Can't we hide a lot of this on platforms where the source clock is not
>> messed up? For example the mpc5200 doesn't need any of this, the
>> needed frequency is already available in mpc52xx_find_ipb_freq().
>> mpc5200 doesn't need any uboot change.
>>
>> Next would be normal mpc8xxx platforms where i2c is driven by a single
>> clock, add a uboot filled in parameter in the root node (or I think it
>> can be computed off of the ones uboot is already filling in). make a
>> mpc8xxx_find_i2c_freq() function. May not need to change device tree
>> and uboot.
>>
>> Finally use this for those days when the tea leaves were especially
>> bad. Both a device tree and uboot change.
>>
>>> Except the i2c clock isn't always a based on an integer divider of the
>>> CCB
>>> frequency. What's more, it's not always the same for both i2c
>>> controllers.
>>> Suppose i2c #1 uses CCB times 2/3 and i2c #2 uses CCB/2, how would
>>> fsl_get_i2c_freq() figure that out from bus-frequency and
>>> i2c-clock-divider?
>>
>> If you get the CCB frequency from uboot and know the chip model, can't
>> you compute these in the platform code? Then make a
>> mpc8xxx_find_i2c_freq(cell_index).
>
> We can, of course, but do we want to? #ifdef's are not acceptable for Linux
> which means scanning the model property to get the divider from some table.
> And when a new MPC model shows up, we need to update the table. This can all
> be saved and avoided by adding a I2C clock source divider or frequency
> property to the FDT. The FDT is to describe the hardware and the fixed
> divider value is a property of it.
>
> I'm in favor of a I2C node specific "divider" property because it does not
> rely on a boot-loader filling in the real value. It's fixed for a certain
> MPC model. And the I2C source clock frequency is then just:
That is true; and if pin-strapping/dip-switch settings are changed,
then that too should be described in the device tree. However, as
Trent stated, that still leaves the question of *which* clock is the
divider applied against. If it isn't the bus-frequency, then there
needs to be a way to override it (an optional property would be usable
here).
> Furthermore, mpc52xx_find_ipb_freq() does the same as fsl_get_sys_freq(). It
> looks up the value for the property "bus-frequency" of the soc. We don't
> need a mpc8xxx_find_i2c_freq() but a common fsl_get_i2c_freq() for all MPCs.
implementation detail. Get the device tree binding correct first.
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: [i2c] [PATCH] powerpc: i2c-mpc: make speed registers configurable via FDT
From: Grant Likely @ 2008-08-01 14:34 UTC (permalink / raw)
To: Trent Piepho; +Cc: Scott Wood, Linuxppc-dev, Timur Tabi, Linux I2C
In-Reply-To: <Pine.LNX.4.58.0807311742230.10341@shell4.speakeasy.net>
On Thu, Jul 31, 2008 at 6:46 PM, Trent Piepho <xyzzy@speakeasy.org> wrote:
> The i2c controller just uses some system clock that was handy. For each
> chip, the designers consult tea leaves to choose a system clock at random
> to connect to the i2c controller.
heh; I thought it was the phase of the moon.
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: [i2c] [PATCH] powerpc: i2c-mpc: make speed registers configurable via FDT
From: Jon Smirl @ 2008-08-01 14:32 UTC (permalink / raw)
To: Timur Tabi; +Cc: Linuxppc-dev, Trent Piepho, Scott Wood, Linux I2C
In-Reply-To: <ed82fe3e0808010625q53680d42l83f28a6df835f959@mail.gmail.com>
On 8/1/08, Timur Tabi <timur@freescale.com> wrote:
> On Thu, Jul 31, 2008 at 9:35 PM, Jon Smirl <jonsmirl@gmail.com> wrote:
>
> > I've having trouble with whether these clocks are a system resource or
> > something that belongs to i2c. If they are a system resource then we
> > should make nodes in the root and use a phandle in the i2c node to
> > link to them.
>
>
> I can't speak for 52xx, but for 8[356]xx, I would say the clocks
> belong to the I2C devices. The screwball determination of whether to
> divide by 1, 2, or 3 only applies to the I2C device only. The divider
> itself is not used to drive a clock for any other device. If you
> disable I2C support, then you don't need to care about the divider (or
> its output clock) at all. That's why I think have the I2C clock in
> the parent node is wrong, because it would only be used if you had I2C
> child nodes. If you didn't have any I2C nodes, then you would need to
> delete the property from the parent node as well.
I see this as being one of three ways...
The source clocks belong to the platform and the clock messiness
belongs in the platform code.
The source clocks belong to i2c. The i2c driver needs to use platform
specific bindings like Grant proposed.
I don't like the third choice. Keep a simple Linux driver for i2c and
the platform, and then move all of the messy code into uboot. BTW,
the messy code is about 10 lines. It's going to take more than 10
lines to hide those 10 lines.
I'm also of the view that all clocks are system resources. Linux is
designed to have clock domains, we just aren't using them on PowerPC.
Check out arch/powerpc/kernel/clock.c. They are mostly used on ARM.
Could we define domains I2C1, I2C2,.. and then implement them? That
implies using the root node to communicate the clock speeds to Linux.
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: [i2c] [PATCH] powerpc: i2c-mpc: make speed registers configurable via FDT
From: Jon Smirl @ 2008-08-01 14:28 UTC (permalink / raw)
To: Timur Tabi; +Cc: Linuxppc-dev, Trent Piepho, Scott Wood, Linux I2C
In-Reply-To: <ed82fe3e0808010625q53680d42l83f28a6df835f959@mail.gmail.com>
On 8/1/08, Timur Tabi <timur@freescale.com> wrote:
> On Thu, Jul 31, 2008 at 9:35 PM, Jon Smirl <jonsmirl@gmail.com> wrote:
>
> > I've having trouble with whether these clocks are a system resource or
> > something that belongs to i2c. If they are a system resource then we
> > should make nodes in the root and use a phandle in the i2c node to
> > link to them.
>
>
> I can't speak for 52xx, but for 8[356]xx, I would say the clocks
> belong to the I2C devices. The screwball determination of whether to
> divide by 1, 2, or 3 only applies to the I2C device only. The divider
> itself is not used to drive a clock for any other device. If you
> disable I2C support, then you don't need to care about the divider (or
> its output clock) at all. That's why I think have the I2C clock in
> the parent node is wrong, because it would only be used if you had I2C
> child nodes. If you didn't have any I2C nodes, then you would need to
> delete the property from the parent node as well.
I see this as being one of three ways...
The source clocks belong to the platform and the clock messiness
belongs in the platform code.
The source clocks belong to i2c. The i2c driver needs to use platform
specific bindings like Grant proposed.
I don't like the third choice. Keep a simple Linux driver for i2c and
the platform, and then move all of the messy code into uboot. BTW,
the messy code is about 10 lines. It's going to take more than 10
lines to hide those 10 lines.
I'm also of the view that all clocks are system resources. Linux is
designed to have clock domains, we just aren't using them on PowerPC.
Check out arch/powerpc/kernel/clock.c. They are mostly used on ARM.
Could we define domains I2C1, I2C2,.. and then implement them? That
implies using the root node to communicate the clock speeds to Linux.
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: [RFC][PATCH 0/8] kexec/kdump support for ppc32
From: Kumar Gala @ 2008-08-01 14:21 UTC (permalink / raw)
To: avorontsov; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <20080801141306.GA29127@polina.dev.rtsoft.ru>
On Aug 1, 2008, at 9:13 AM, Anton Vorontsov wrote:
> Hi all,
>
> I refreshed some Dale Farnsworth's kexec/kdump patches[1] against
> the latest kernel, and here they are.
>
> There is a difference though. Dale's patches were using
> kmap_atomic_pfn() to map oldmem memory, while for this patches
> I took PPC64 approach to use ioremap(). This is done to be able
> to support kdump on !HIGHMEM kernels.
>
> Also, please take a special look into 8/8 patch, there is a hunk
> marked with "XXX:", which I don't quite understand for PPC64 case
> (this hunk also persist in the original Dale's patch, and w/o it
> the capturing kernel doesn't boot on ppc32).
>
> I'll try to refresh BookE support as soon as I'll find some BookE
> board.
>
> The patchset includes:
>
> - Kexec support
>
> [PATCH 1/8] powerpc: set up OF properties for ppc32 kexec
> [PATCH 2/8] powerpc: make default kexec/crash_kernel ops implicit
> [PATCH 3/8] powerpc: remove default kexec/crash_kernel ops
> assignments
>
> 2/8 and 3/8 patches are used to avoid adding lots of default ops
> to the board files.
>
> - Kdump support
>
> [PATCH 4/8] powerpc: add the ability for a classic ppc kernel to be
> loaded at 32M
> [PATCH 5/8] powerpc: allow to ioremap RAM addresses for kdump
> kernel on ppc32
> [PATCH 6/8] powerpc: set up OF properties for ppc32 kdump
> [PATCH 7/8] powerpc: implement crash_setup_regs for ppc32
> [PATCH 8/8] powerpc: last bits to support kdump on ppc32
>
> [1] http://ozlabs.org/pipermail/linuxppc-dev/2007-November/046739.html
What's the state of the kexec tools for ppc32?
- k
^ permalink raw reply
* [PATCH 8/8] powerpc: last bits to support kdump on ppc32
From: Anton Vorontsov @ 2008-08-01 14:14 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Paul Mackerras
In-Reply-To: <20080801141306.GA29127@polina.dev.rtsoft.ru>
From: Dale Farnsworth <dale@farnsworth.org>
Wire up the trampoline code for ppc32 to relay exceptions from the
vectors at address 0 to vectors at address 32MB, and modify Kconfig
to enable Kdump support for all powerpcs (except BookE, for now).
Signed-off-by: Dale Farnsworth <dale@farnsworth.org>
Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
---
arch/powerpc/Kconfig | 2 +-
arch/powerpc/kernel/crash_dump.c | 6 +++++-
arch/powerpc/kernel/setup_32.c | 2 ++
3 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index 587da5e..006a475 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -321,7 +321,7 @@ config KEXEC
config CRASH_DUMP
bool "Build a kdump crash kernel"
- depends on PPC_MULTIPLATFORM && PPC64
+ depends on PPC_MULTIPLATFORM && !BOOKE
help
Build a kernel suitable for use as a kdump capture kernel.
The kernel will be linked at a different address than normal, and
diff --git a/arch/powerpc/kernel/crash_dump.c b/arch/powerpc/kernel/crash_dump.c
index e0debcc..96cd521 100644
--- a/arch/powerpc/kernel/crash_dump.c
+++ b/arch/powerpc/kernel/crash_dump.c
@@ -34,7 +34,11 @@ void __init reserve_kdump_trampoline(void)
static void __init create_trampoline(unsigned long addr)
{
- unsigned int *p = (unsigned int *)addr;
+ unsigned int *p;
+
+ /* XXX: why this code is working without += PAGE_OFFSET on PPC64? */
+ addr += PAGE_OFFSET;
+ p = (unsigned int *)addr;
/* The maximum range of a single instruction branch, is the current
* instruction's address + (32 MB - 4) bytes. For the trampoline we
diff --git a/arch/powerpc/kernel/setup_32.c b/arch/powerpc/kernel/setup_32.c
index 066e65c..1d76afc 100644
--- a/arch/powerpc/kernel/setup_32.c
+++ b/arch/powerpc/kernel/setup_32.c
@@ -121,6 +121,8 @@ notrace void __init machine_init(unsigned long dt_ptr, unsigned long phys)
probe_machine();
+ setup_kdump_trampoline();
+
#ifdef CONFIG_6xx
if (cpu_has_feature(CPU_FTR_CAN_DOZE) ||
cpu_has_feature(CPU_FTR_CAN_NAP))
--
1.5.5.4
^ permalink raw reply related
* [PATCH 7/8] powerpc: implement crash_setup_regs for ppc32
From: Anton Vorontsov @ 2008-08-01 14:14 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Paul Mackerras
In-Reply-To: <20080801141306.GA29127@polina.dev.rtsoft.ru>
From: Dale Farnsworth <dale@farnsworth.org>
Signed-off-by: Dale Farnsworth <dale@farnsworth.org>
Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
---
include/asm-powerpc/kexec.h | 60 ++++++++++++++++++++++++++++++++++++------
1 files changed, 51 insertions(+), 9 deletions(-)
diff --git a/include/asm-powerpc/kexec.h b/include/asm-powerpc/kexec.h
index acdcdc6..9ecc307 100644
--- a/include/asm-powerpc/kexec.h
+++ b/include/asm-powerpc/kexec.h
@@ -38,7 +38,6 @@ typedef void (*crash_shutdown_t)(void);
#ifdef CONFIG_KEXEC
-#ifdef __powerpc64__
/*
* This function is responsible for capturing register states if coming
* via panic or invoking dump using sysrq-trigger.
@@ -51,6 +50,7 @@ static inline void crash_setup_regs(struct pt_regs *newregs,
else {
/* FIXME Merge this with xmon_save_regs ?? */
unsigned long tmp1, tmp2;
+#ifdef __powerpc64__
__asm__ __volatile__ (
"std 0,0(%2)\n"
"std 1,8(%2)\n"
@@ -99,16 +99,58 @@ static inline void crash_setup_regs(struct pt_regs *newregs,
: "=&r" (tmp1), "=&r" (tmp2)
: "b" (newregs)
: "memory");
+#else /* __powerpc64__ */
+ __asm__ __volatile__ (
+ "stw 0,0(%2)\n"
+ "stw 1,4(%2)\n"
+ "stw 2,8(%2)\n"
+ "stw 3,12(%2)\n"
+ "stw 4,16(%2)\n"
+ "stw 5,20(%2)\n"
+ "stw 6,24(%2)\n"
+ "stw 7,28(%2)\n"
+ "stw 8,32(%2)\n"
+ "stw 9,36(%2)\n"
+ "stw 10,40(%2)\n"
+ "stw 11,44(%2)\n"
+ "stw 12,48(%2)\n"
+ "stw 13,52(%2)\n"
+ "stw 14,56(%2)\n"
+ "stw 15,60(%2)\n"
+ "stw 16,64(%2)\n"
+ "stw 17,68(%2)\n"
+ "stw 18,72(%2)\n"
+ "stw 19,76(%2)\n"
+ "stw 20,80(%2)\n"
+ "stw 21,84(%2)\n"
+ "stw 22,88(%2)\n"
+ "stw 23,92(%2)\n"
+ "stw 24,96(%2)\n"
+ "stw 25,100(%2)\n"
+ "stw 26,104(%2)\n"
+ "stw 27,108(%2)\n"
+ "stw 28,112(%2)\n"
+ "stw 29,116(%2)\n"
+ "stw 30,120(%2)\n"
+ "stw 31,124(%2)\n"
+ "mfmsr %0\n"
+ "stw %0,132(%2)\n"
+ "mfctr %0\n"
+ "stw %0,140(%2)\n"
+ "mflr %0\n"
+ "stw %0,144(%2)\n"
+ "bl 1f\n"
+ "1: mflr %1\n"
+ "stw %1,128(%2)\n"
+ "mtlr %0\n"
+ "mfxer %0\n"
+ "stw %0,148(%2)\n"
+ : "=&r" (tmp1), "=&r" (tmp2)
+ : "b" (newregs)
+ : "memory");
+#endif /* __powerpc64 __ */
}
}
-#else
-/*
- * Provide a dummy definition to avoid build failures. Will remain
- * empty till crash dump support is enabled.
- */
-static inline void crash_setup_regs(struct pt_regs *newregs,
- struct pt_regs *oldregs) { }
-#endif /* !__powerpc64 __ */
extern void kexec_smp_wait(void); /* get and clear naca physid, wait for
master to copy new code to 0 */
--
1.5.5.4
^ permalink raw reply related
* [PATCH 6/8] powerpc: set up OF properties for ppc32 kdump
From: Anton Vorontsov @ 2008-08-01 14:14 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Paul Mackerras
In-Reply-To: <20080801141306.GA29127@polina.dev.rtsoft.ru>
From: Dale Farnsworth <dale@farnsworth.org>
Refactor the setting of kexec OF properties, moving the common code
from machine_kexec_64.c to machine_kexec.c where it can be used on
both ppc64 and ppc32. This will be needed for kdump to work on ppc32
platforms.
Signed-off-by: Dale Farnsworth <dale@farnsworth.org>
Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
---
arch/powerpc/kernel/machine_kexec.c | 38 ++++++++++++++++++++++++++++
arch/powerpc/kernel/machine_kexec_64.c | 43 --------------------------------
2 files changed, 38 insertions(+), 43 deletions(-)
diff --git a/arch/powerpc/kernel/machine_kexec.c b/arch/powerpc/kernel/machine_kexec.c
index ac42cfb..bfef717 100644
--- a/arch/powerpc/kernel/machine_kexec.c
+++ b/arch/powerpc/kernel/machine_kexec.c
@@ -117,6 +117,7 @@ int overlaps_crashkernel(unsigned long start, unsigned long size)
/* Values we need to export to the second kernel via the device tree. */
static unsigned long kernel_end;
+static unsigned long crashk_size;
static struct property kernel_end_prop = {
.name = "linux,kernel-end",
@@ -124,6 +125,41 @@ static struct property kernel_end_prop = {
.value = &kernel_end,
};
+static struct property crashk_base_prop = {
+ .name = "linux,crashkernel-base",
+ .length = sizeof(unsigned long),
+ .value = &crashk_res.start,
+};
+
+static struct property crashk_size_prop = {
+ .name = "linux,crashkernel-size",
+ .length = sizeof(unsigned long),
+ .value = &crashk_size,
+};
+
+static void __init export_crashk_values(struct device_node *node)
+{
+ struct property *prop;
+
+ /* There might be existing crash kernel properties, but we can't
+ * be sure what's in them, so remove them. */
+ prop = of_find_property(node, "linux,crashkernel-base", NULL);
+ if (prop)
+ prom_remove_property(node, prop);
+
+ prop = of_find_property(node, "linux,crashkernel-size", NULL);
+ if (prop)
+ prom_remove_property(node, prop);
+
+ if (crashk_res.start != 0) {
+ prom_add_property(node, &crashk_base_prop);
+ crashk_size = crashk_res.end - crashk_res.start + 1;
+ prom_add_property(node, &crashk_size_prop);
+ }
+
+ of_node_put(node);
+}
+
static int __init kexec_setup(void)
{
struct device_node *node;
@@ -135,6 +171,8 @@ static int __init kexec_setup(void)
kernel_end = __pa(_end);
prom_add_property(node, &kernel_end_prop);
+ export_crashk_values(node);
+
of_node_put(node);
return 0;
}
diff --git a/arch/powerpc/kernel/machine_kexec_64.c b/arch/powerpc/kernel/machine_kexec_64.c
index c30678d..2aab296 100644
--- a/arch/powerpc/kernel/machine_kexec_64.c
+++ b/arch/powerpc/kernel/machine_kexec_64.c
@@ -322,52 +322,9 @@ static void __init export_htab_values(void)
of_node_put(node);
}
-static struct property crashk_base_prop = {
- .name = "linux,crashkernel-base",
- .length = sizeof(unsigned long),
- .value = &crashk_res.start,
-};
-
-static unsigned long crashk_size;
-
-static struct property crashk_size_prop = {
- .name = "linux,crashkernel-size",
- .length = sizeof(unsigned long),
- .value = &crashk_size,
-};
-
-static void __init export_crashk_values(void)
-{
- struct device_node *node;
- struct property *prop;
-
- node = of_find_node_by_path("/chosen");
- if (!node)
- return;
-
- /* There might be existing crash kernel properties, but we can't
- * be sure what's in them, so remove them. */
- prop = of_find_property(node, "linux,crashkernel-base", NULL);
- if (prop)
- prom_remove_property(node, prop);
-
- prop = of_find_property(node, "linux,crashkernel-size", NULL);
- if (prop)
- prom_remove_property(node, prop);
-
- if (crashk_res.start != 0) {
- prom_add_property(node, &crashk_base_prop);
- crashk_size = crashk_res.end - crashk_res.start + 1;
- prom_add_property(node, &crashk_size_prop);
- }
-
- of_node_put(node);
-}
-
static int __init kexec_setup(void)
{
export_htab_values();
- export_crashk_values();
return 0;
}
__initcall(kexec_setup);
--
1.5.5.4
^ permalink raw reply related
* [PATCH 5/8] powerpc: allow to ioremap RAM addresses for kdump kernel on ppc32
From: Anton Vorontsov @ 2008-08-01 14:14 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Paul Mackerras
In-Reply-To: <20080801141306.GA29127@polina.dev.rtsoft.ru>
While for debugging it is good to catch bogus users of ioremap, but
for kdump support it is more convenient to use ioremap for
copy_oldmem_page() (exactly as we do for PPC64 currently).
The other option is to use kmap_atomic_pfn()*, but it will not work for
kernels compiled without HIGHMEM.
That is, on a board with 256MB RAM and crashkernel=64M@32M case, the
!HIGHMEM capturing kernel maps 0-96M range, which does not include all
the memory needed to capture the dump. And obviously accessing anything
upper than 96M will cause faults.
* http://ozlabs.org/pipermail/linuxppc-dev/2007-November/046747.html
Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
---
arch/powerpc/mm/pgtable_32.c | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/mm/pgtable_32.c b/arch/powerpc/mm/pgtable_32.c
index ea50968..3e69b0d 100644
--- a/arch/powerpc/mm/pgtable_32.c
+++ b/arch/powerpc/mm/pgtable_32.c
@@ -194,6 +194,7 @@ __ioremap(phys_addr_t addr, unsigned long size, unsigned long flags)
if (p < 16*1024*1024)
p += _ISA_MEM_BASE;
+#ifndef CONFIG_CRASH_DUMP
/*
* Don't allow anybody to remap normal RAM that we're using.
* mem_init() sets high_memory so only do the check after that.
@@ -203,6 +204,7 @@ __ioremap(phys_addr_t addr, unsigned long size, unsigned long flags)
(unsigned long long)p, __builtin_return_address(0));
return NULL;
}
+#endif
if (size == 0)
return NULL;
--
1.5.5.4
^ permalink raw reply related
* [PATCH 4/8] powerpc: add the ability for a classic ppc kernel to be loaded at 32M
From: Anton Vorontsov @ 2008-08-01 14:14 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Paul Mackerras
In-Reply-To: <20080801141306.GA29127@polina.dev.rtsoft.ru>
From: Dale Farnsworth <dale@farnsworth.org>
Add the ability for a classic ppc kernel to be loaded at an address
of 32MB. This done by fixing a few places that assume we are loaded
at address 0, and by changing several uses of KERNELBASE to use
PAGE_OFFSET, instead.
Signed-off-by: Dale Farnsworth <dale@farnsworth.org>
Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
---
arch/powerpc/kernel/head_32.S | 11 ++++++-----
arch/powerpc/mm/init_32.c | 2 +-
arch/powerpc/mm/pgtable_32.c | 4 ++--
arch/powerpc/mm/ppc_mmu_32.c | 8 ++++----
include/asm-powerpc/ppc_asm.h | 4 ++--
5 files changed, 15 insertions(+), 14 deletions(-)
diff --git a/arch/powerpc/kernel/head_32.S b/arch/powerpc/kernel/head_32.S
index 99ee2f0..45e612b 100644
--- a/arch/powerpc/kernel/head_32.S
+++ b/arch/powerpc/kernel/head_32.S
@@ -176,7 +176,8 @@ __after_mmu_off:
bl reloc_offset
mr r26,r3
addis r4,r3,KERNELBASE@h /* current address of _start */
- cmpwi 0,r4,0 /* are we already running at 0? */
+ lis r5,PHYSICAL_START@h
+ cmplw 0,r4,r5 /* already running at PHYSICAL_START? */
bne relocate_kernel
/*
* we now have the 1st 16M of ram mapped with the bats.
@@ -804,13 +805,13 @@ giveup_altivec:
/*
* This code is jumped to from the startup code to copy
- * the kernel image to physical address 0.
+ * the kernel image to physical address PHYSICAL_START.
*/
relocate_kernel:
addis r9,r26,klimit@ha /* fetch klimit */
lwz r25,klimit@l(r9)
addis r25,r25,-KERNELBASE@h
- li r3,0 /* Destination base address */
+ lis r3,PHYSICAL_START@h /* Destination base address */
li r6,0 /* Destination offset */
li r5,0x4000 /* # bytes of memory to copy */
bl copy_and_flush /* copy the first 0x4000 bytes */
@@ -1172,11 +1173,11 @@ mmu_off:
/*
* Use the first pair of BAT registers to map the 1st 16MB
- * of RAM to KERNELBASE. From this point on we can't safely
+ * of RAM to PAGE_OFFSET. From this point on we can't safely
* call OF any more.
*/
initial_bats:
- lis r11,KERNELBASE@h
+ lis r11,PAGE_OFFSET@h
mfspr r9,SPRN_PVR
rlwinm r9,r9,16,16,31 /* r9 = 1 for 601, 4 for 604 */
cmpwi 0,r9,1
diff --git a/arch/powerpc/mm/init_32.c b/arch/powerpc/mm/init_32.c
index 388ceda..4ac0e4e 100644
--- a/arch/powerpc/mm/init_32.c
+++ b/arch/powerpc/mm/init_32.c
@@ -49,7 +49,7 @@
#if defined(CONFIG_KERNEL_START_BOOL) || defined(CONFIG_LOWMEM_SIZE_BOOL)
/* The ammount of lowmem must be within 0xF0000000 - KERNELBASE. */
-#if (CONFIG_LOWMEM_SIZE > (0xF0000000 - KERNELBASE))
+#if (CONFIG_LOWMEM_SIZE > (0xF0000000 - PAGE_OFFSET))
#error "You must adjust CONFIG_LOWMEM_SIZE or CONFIG_START_KERNEL"
#endif
#endif
diff --git a/arch/powerpc/mm/pgtable_32.c b/arch/powerpc/mm/pgtable_32.c
index 2001abd..ea50968 100644
--- a/arch/powerpc/mm/pgtable_32.c
+++ b/arch/powerpc/mm/pgtable_32.c
@@ -288,7 +288,7 @@ int map_page(unsigned long va, phys_addr_t pa, int flags)
}
/*
- * Map in all of physical memory starting at KERNELBASE.
+ * Map in all of physical memory starting at PAGE_OFFSET.
*/
void __init mapin_ram(void)
{
@@ -297,7 +297,7 @@ void __init mapin_ram(void)
int ktext;
s = mmu_mapin_ram();
- v = KERNELBASE + s;
+ v = PAGE_OFFSET + s;
p = memstart_addr + s;
for (; s < total_lowmem; s += PAGE_SIZE) {
ktext = ((char *) v >= _stext && (char *) v < etext);
diff --git a/arch/powerpc/mm/ppc_mmu_32.c b/arch/powerpc/mm/ppc_mmu_32.c
index c53145f..7c86103 100644
--- a/arch/powerpc/mm/ppc_mmu_32.c
+++ b/arch/powerpc/mm/ppc_mmu_32.c
@@ -95,16 +95,16 @@ unsigned long __init mmu_mapin_ram(void)
break;
}
- setbat(2, KERNELBASE, 0, bl, _PAGE_RAM);
- done = (unsigned long)bat_addrs[2].limit - KERNELBASE + 1;
+ setbat(2, PAGE_OFFSET, 0, bl, _PAGE_RAM);
+ done = (unsigned long)bat_addrs[2].limit - PAGE_OFFSET + 1;
if ((done < tot) && !bat_addrs[3].limit) {
/* use BAT3 to cover a bit more */
tot -= done;
for (bl = 128<<10; bl < max_size; bl <<= 1)
if (bl * 2 > tot)
break;
- setbat(3, KERNELBASE+done, done, bl, _PAGE_RAM);
- done = (unsigned long)bat_addrs[3].limit - KERNELBASE + 1;
+ setbat(3, PAGE_OFFSET+done, done, bl, _PAGE_RAM);
+ done = (unsigned long)bat_addrs[3].limit - PAGE_OFFSET + 1;
}
return done;
diff --git a/include/asm-powerpc/ppc_asm.h b/include/asm-powerpc/ppc_asm.h
index 0966899..d0c7f33 100644
--- a/include/asm-powerpc/ppc_asm.h
+++ b/include/asm-powerpc/ppc_asm.h
@@ -425,14 +425,14 @@ END_FTR_SECTION_IFCLR(CPU_FTR_601)
#define fromreal(rd) tovirt(rd,rd)
#define tophys(rd,rs) \
-0: addis rd,rs,-KERNELBASE@h; \
+0: addis rd,rs,-PAGE_OFFSET@h; \
.section ".vtop_fixup","aw"; \
.align 1; \
.long 0b; \
.previous
#define tovirt(rd,rs) \
-0: addis rd,rs,KERNELBASE@h; \
+0: addis rd,rs,PAGE_OFFSET@h; \
.section ".ptov_fixup","aw"; \
.align 1; \
.long 0b; \
--
1.5.5.4
^ permalink raw reply related
* [PATCH 3/8] powerpc: remove default kexec/crash_kernel ops assignments
From: Anton Vorontsov @ 2008-08-01 14:14 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Paul Mackerras
In-Reply-To: <20080801141306.GA29127@polina.dev.rtsoft.ru>
Default ops are implicit now.
Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
---
arch/powerpc/platforms/cell/celleb_setup.c | 9 ---------
arch/powerpc/platforms/cell/setup.c | 6 ------
arch/powerpc/platforms/embedded6xx/c2k.c | 6 ------
arch/powerpc/platforms/embedded6xx/prpmc2800.c | 6 ------
arch/powerpc/platforms/maple/setup.c | 6 ------
arch/powerpc/platforms/powermac/setup.c | 6 ------
arch/powerpc/platforms/ps3/setup.c | 4 ----
7 files changed, 0 insertions(+), 43 deletions(-)
diff --git a/arch/powerpc/platforms/cell/celleb_setup.c b/arch/powerpc/platforms/cell/celleb_setup.c
index b11cb30..07c234f 100644
--- a/arch/powerpc/platforms/cell/celleb_setup.c
+++ b/arch/powerpc/platforms/cell/celleb_setup.c
@@ -45,7 +45,6 @@
#include <asm/mmu.h>
#include <asm/processor.h>
#include <asm/io.h>
-#include <asm/kexec.h>
#include <asm/prom.h>
#include <asm/machdep.h>
#include <asm/cputable.h>
@@ -226,9 +225,6 @@ define_machine(celleb_beat) {
.pci_setup_phb = celleb_setup_phb,
#ifdef CONFIG_KEXEC
.kexec_cpu_down = beat_kexec_cpu_down,
- .machine_kexec = default_machine_kexec,
- .machine_kexec_prepare = default_machine_kexec_prepare,
- .machine_crash_shutdown = default_machine_crash_shutdown,
#endif
};
@@ -248,9 +244,4 @@ define_machine(celleb_native) {
.pci_probe_mode = celleb_pci_probe_mode,
.pci_setup_phb = celleb_setup_phb,
.init_IRQ = celleb_init_IRQ_native,
-#ifdef CONFIG_KEXEC
- .machine_kexec = default_machine_kexec,
- .machine_kexec_prepare = default_machine_kexec_prepare,
- .machine_crash_shutdown = default_machine_crash_shutdown,
-#endif
};
diff --git a/arch/powerpc/platforms/cell/setup.c b/arch/powerpc/platforms/cell/setup.c
index ab721b5..5930536 100644
--- a/arch/powerpc/platforms/cell/setup.c
+++ b/arch/powerpc/platforms/cell/setup.c
@@ -35,7 +35,6 @@
#include <asm/mmu.h>
#include <asm/processor.h>
#include <asm/io.h>
-#include <asm/kexec.h>
#include <asm/pgtable.h>
#include <asm/prom.h>
#include <asm/rtas.h>
@@ -289,9 +288,4 @@ define_machine(cell) {
.progress = cell_progress,
.init_IRQ = cell_init_irq,
.pci_setup_phb = cell_setup_phb,
-#ifdef CONFIG_KEXEC
- .machine_kexec = default_machine_kexec,
- .machine_kexec_prepare = default_machine_kexec_prepare,
- .machine_crash_shutdown = default_machine_crash_shutdown,
-#endif
};
diff --git a/arch/powerpc/platforms/embedded6xx/c2k.c b/arch/powerpc/platforms/embedded6xx/c2k.c
index d0b25b8..19d3bc4 100644
--- a/arch/powerpc/platforms/embedded6xx/c2k.c
+++ b/arch/powerpc/platforms/embedded6xx/c2k.c
@@ -20,7 +20,6 @@
#include <linux/seq_file.h>
#include <linux/time.h>
#include <linux/of.h>
-#include <linux/kexec.h>
#include <asm/machdep.h>
#include <asm/prom.h>
@@ -150,9 +149,4 @@ define_machine(c2k) {
.get_irq = mv64x60_get_irq,
.restart = c2k_restart,
.calibrate_decr = generic_calibrate_decr,
-#ifdef CONFIG_KEXEC
- .machine_kexec = default_machine_kexec,
- .machine_kexec_prepare = default_machine_kexec_prepare,
- .machine_crash_shutdown = default_machine_crash_shutdown,
-#endif
};
diff --git a/arch/powerpc/platforms/embedded6xx/prpmc2800.c b/arch/powerpc/platforms/embedded6xx/prpmc2800.c
index 5a19b9a..e40b5a8 100644
--- a/arch/powerpc/platforms/embedded6xx/prpmc2800.c
+++ b/arch/powerpc/platforms/embedded6xx/prpmc2800.c
@@ -19,7 +19,6 @@
#include <asm/prom.h>
#include <asm/system.h>
#include <asm/time.h>
-#include <asm/kexec.h>
#include <mm/mmu_decl.h>
@@ -158,9 +157,4 @@ define_machine(prpmc2800){
.get_irq = mv64x60_get_irq,
.restart = prpmc2800_restart,
.calibrate_decr = generic_calibrate_decr,
-#ifdef CONFIG_KEXEC
- .machine_kexec = default_machine_kexec,
- .machine_kexec_prepare = default_machine_kexec_prepare,
- .machine_crash_shutdown = default_machine_crash_shutdown,
-#endif
};
diff --git a/arch/powerpc/platforms/maple/setup.c b/arch/powerpc/platforms/maple/setup.c
index 3647147..1be9b7c 100644
--- a/arch/powerpc/platforms/maple/setup.c
+++ b/arch/powerpc/platforms/maple/setup.c
@@ -51,7 +51,6 @@
#include <asm/system.h>
#include <asm/pgtable.h>
#include <asm/io.h>
-#include <asm/kexec.h>
#include <asm/pci-bridge.h>
#include <asm/iommu.h>
#include <asm/machdep.h>
@@ -336,9 +335,4 @@ define_machine(maple) {
.calibrate_decr = generic_calibrate_decr,
.progress = maple_progress,
.power_save = power4_idle,
-#ifdef CONFIG_KEXEC
- .machine_kexec = default_machine_kexec,
- .machine_kexec_prepare = default_machine_kexec_prepare,
- .machine_crash_shutdown = default_machine_crash_shutdown,
-#endif
};
diff --git a/arch/powerpc/platforms/powermac/setup.c b/arch/powerpc/platforms/powermac/setup.c
index 88ccf3a..5e0999b 100644
--- a/arch/powerpc/platforms/powermac/setup.c
+++ b/arch/powerpc/platforms/powermac/setup.c
@@ -61,7 +61,6 @@
#include <asm/system.h>
#include <asm/pgtable.h>
#include <asm/io.h>
-#include <asm/kexec.h>
#include <asm/pci-bridge.h>
#include <asm/ohare.h>
#include <asm/mediabay.h>
@@ -741,11 +740,6 @@ define_machine(powermac) {
.pci_probe_mode = pmac_pci_probe_mode,
.power_save = power4_idle,
.enable_pmcs = power4_enable_pmcs,
-#ifdef CONFIG_KEXEC
- .machine_kexec = default_machine_kexec,
- .machine_kexec_prepare = default_machine_kexec_prepare,
- .machine_crash_shutdown = default_machine_crash_shutdown,
-#endif
#endif /* CONFIG_PPC64 */
#ifdef CONFIG_PPC32
.pcibios_enable_device_hook = pmac_pci_enable_device_hook,
diff --git a/arch/powerpc/platforms/ps3/setup.c b/arch/powerpc/platforms/ps3/setup.c
index a413abb..a8b99a6 100644
--- a/arch/powerpc/platforms/ps3/setup.c
+++ b/arch/powerpc/platforms/ps3/setup.c
@@ -23,7 +23,6 @@
#include <linux/fs.h>
#include <linux/root_dev.h>
#include <linux/console.h>
-#include <linux/kexec.h>
#include <linux/bootmem.h>
#include <asm/machdep.h>
@@ -278,8 +277,5 @@ define_machine(ps3) {
.halt = ps3_halt,
#if defined(CONFIG_KEXEC)
.kexec_cpu_down = ps3_kexec_cpu_down,
- .machine_kexec = default_machine_kexec,
- .machine_kexec_prepare = default_machine_kexec_prepare,
- .machine_crash_shutdown = default_machine_crash_shutdown,
#endif
};
--
1.5.5.4
^ permalink raw reply related
* [PATCH 1/8] powerpc: set up OF properties for ppc32 kexec
From: Anton Vorontsov @ 2008-08-01 14:14 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Paul Mackerras
In-Reply-To: <20080801141306.GA29127@polina.dev.rtsoft.ru>
From: Dale Farnsworth <dale@farnsworth.org>
Refactor the setting of kexec OF properties, moving the common code
from machine_kexec_64.c to machine_kexec.c where it can be used on
both ppc64 and ppc32. This is needed for kexec to work on ppc32
platforms.
Signed-off-by: Dale Farnsworth <dale@farnsworth.org>
Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
---
arch/powerpc/kernel/machine_kexec.c | 27 +++++++++++++++++++++++++++
arch/powerpc/kernel/machine_kexec_64.c | 20 +++++---------------
2 files changed, 32 insertions(+), 15 deletions(-)
diff --git a/arch/powerpc/kernel/machine_kexec.c b/arch/powerpc/kernel/machine_kexec.c
index aab7688..a625673 100644
--- a/arch/powerpc/kernel/machine_kexec.c
+++ b/arch/powerpc/kernel/machine_kexec.c
@@ -13,8 +13,10 @@
#include <linux/reboot.h>
#include <linux/threads.h>
#include <linux/lmb.h>
+#include <linux/of.h>
#include <asm/machdep.h>
#include <asm/prom.h>
+#include <asm/sections.h>
void machine_crash_shutdown(struct pt_regs *regs)
{
@@ -116,3 +118,28 @@ int overlaps_crashkernel(unsigned long start, unsigned long size)
{
return (start + size) > crashk_res.start && start <= crashk_res.end;
}
+
+/* Values we need to export to the second kernel via the device tree. */
+static unsigned long kernel_end;
+
+static struct property kernel_end_prop = {
+ .name = "linux,kernel-end",
+ .length = sizeof(unsigned long),
+ .value = &kernel_end,
+};
+
+static int __init kexec_setup(void)
+{
+ struct device_node *node;
+
+ node = of_find_node_by_path("/chosen");
+ if (!node)
+ return -ENOENT;
+
+ kernel_end = __pa(_end);
+ prom_add_property(node, &kernel_end_prop);
+
+ of_node_put(node);
+ return 0;
+}
+__initcall(kexec_setup);
diff --git a/arch/powerpc/kernel/machine_kexec_64.c b/arch/powerpc/kernel/machine_kexec_64.c
index a168514..c30678d 100644
--- a/arch/powerpc/kernel/machine_kexec_64.c
+++ b/arch/powerpc/kernel/machine_kexec_64.c
@@ -289,7 +289,7 @@ void default_machine_kexec(struct kimage *image)
}
/* Values we need to export to the second kernel via the device tree. */
-static unsigned long htab_base, kernel_end;
+static unsigned long htab_base;
static struct property htab_base_prop = {
.name = "linux,htab-base",
@@ -303,32 +303,22 @@ static struct property htab_size_prop = {
.value = &htab_size_bytes,
};
-static struct property kernel_end_prop = {
- .name = "linux,kernel-end",
- .length = sizeof(unsigned long),
- .value = &kernel_end,
-};
-
static void __init export_htab_values(void)
{
struct device_node *node;
+ /* On machines with no htab htab_address is NULL */
+ if (NULL == htab_address)
+ return;
+
node = of_find_node_by_path("/chosen");
if (!node)
return;
- kernel_end = __pa(_end);
- prom_add_property(node, &kernel_end_prop);
-
- /* On machines with no htab htab_address is NULL */
- if (NULL == htab_address)
- goto out;
-
htab_base = __pa(htab_address);
prom_add_property(node, &htab_base_prop);
prom_add_property(node, &htab_size_prop);
- out:
of_node_put(node);
}
--
1.5.5.4
^ permalink raw reply related
* [PATCH 2/8] powerpc: make default kexec/crash_kernel ops implicit
From: Anton Vorontsov @ 2008-08-01 14:14 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Paul Mackerras
In-Reply-To: <20080801141306.GA29127@polina.dev.rtsoft.ru>
This patch removes need for each platform to specify default kexec and
crash kernel ops, thus effectively adds a working kexec support for most
boards.
Platforms that can't cope with default ops will explode in some weird
way, which means that the board's kexec support should be fixed or
blacklisted via dummy _prepare callback returning -ENOSYS.
Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
---
arch/powerpc/kernel/machine_kexec.c | 20 ++++++++------------
1 files changed, 8 insertions(+), 12 deletions(-)
diff --git a/arch/powerpc/kernel/machine_kexec.c b/arch/powerpc/kernel/machine_kexec.c
index a625673..ac42cfb 100644
--- a/arch/powerpc/kernel/machine_kexec.c
+++ b/arch/powerpc/kernel/machine_kexec.c
@@ -22,6 +22,8 @@ void machine_crash_shutdown(struct pt_regs *regs)
{
if (ppc_md.machine_crash_shutdown)
ppc_md.machine_crash_shutdown(regs);
+ else
+ return default_machine_crash_shutdown(regs);
}
/*
@@ -33,11 +35,8 @@ int machine_kexec_prepare(struct kimage *image)
{
if (ppc_md.machine_kexec_prepare)
return ppc_md.machine_kexec_prepare(image);
- /*
- * Fail if platform doesn't provide its own machine_kexec_prepare
- * implementation.
- */
- return -ENOSYS;
+ else
+ return default_machine_kexec_prepare(image);
}
void machine_kexec_cleanup(struct kimage *image)
@@ -54,13 +53,10 @@ void machine_kexec(struct kimage *image)
{
if (ppc_md.machine_kexec)
ppc_md.machine_kexec(image);
- else {
- /*
- * Fall back to normal restart if platform doesn't provide
- * its own kexec function, and user insist to kexec...
- */
- machine_restart(NULL);
- }
+ else
+ default_machine_kexec(image);
+ /* Fall back to normal restart if we're still alive. */
+ machine_restart(NULL);
for(;;);
}
--
1.5.5.4
^ permalink raw reply related
* [RFC][PATCH 0/8] kexec/kdump support for ppc32
From: Anton Vorontsov @ 2008-08-01 14:13 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Paul Mackerras
Hi all,
I refreshed some Dale Farnsworth's kexec/kdump patches[1] against
the latest kernel, and here they are.
There is a difference though. Dale's patches were using
kmap_atomic_pfn() to map oldmem memory, while for this patches
I took PPC64 approach to use ioremap(). This is done to be able
to support kdump on !HIGHMEM kernels.
Also, please take a special look into 8/8 patch, there is a hunk
marked with "XXX:", which I don't quite understand for PPC64 case
(this hunk also persist in the original Dale's patch, and w/o it
the capturing kernel doesn't boot on ppc32).
I'll try to refresh BookE support as soon as I'll find some BookE
board.
The patchset includes:
- Kexec support
[PATCH 1/8] powerpc: set up OF properties for ppc32 kexec
[PATCH 2/8] powerpc: make default kexec/crash_kernel ops implicit
[PATCH 3/8] powerpc: remove default kexec/crash_kernel ops assignments
2/8 and 3/8 patches are used to avoid adding lots of default ops
to the board files.
- Kdump support
[PATCH 4/8] powerpc: add the ability for a classic ppc kernel to be loaded at 32M
[PATCH 5/8] powerpc: allow to ioremap RAM addresses for kdump kernel on ppc32
[PATCH 6/8] powerpc: set up OF properties for ppc32 kdump
[PATCH 7/8] powerpc: implement crash_setup_regs for ppc32
[PATCH 8/8] powerpc: last bits to support kdump on ppc32
[1] http://ozlabs.org/pipermail/linuxppc-dev/2007-November/046739.html
--
Anton Vorontsov
email: cbouatmailru@gmail.com
irc://irc.freenode.net/bd2
^ permalink raw reply
* Re: [i2c] [PATCH] powerpc: i2c-mpc: make speed registers configurable via FDT
From: Timur Tabi @ 2008-08-01 13:25 UTC (permalink / raw)
To: Jon Smirl; +Cc: Linuxppc-dev, Trent Piepho, Scott Wood, Linux I2C
In-Reply-To: <9e4733910807311935n1f81f18dw135372d97d3dcb45@mail.gmail.com>
On Thu, Jul 31, 2008 at 9:35 PM, Jon Smirl <jonsmirl@gmail.com> wrote:
> I've having trouble with whether these clocks are a system resource or
> something that belongs to i2c. If they are a system resource then we
> should make nodes in the root and use a phandle in the i2c node to
> link to them.
I can't speak for 52xx, but for 8[356]xx, I would say the clocks
belong to the I2C devices. The screwball determination of whether to
divide by 1, 2, or 3 only applies to the I2C device only. The divider
itself is not used to drive a clock for any other device. If you
disable I2C support, then you don't need to care about the divider (or
its output clock) at all. That's why I think have the I2C clock in
the parent node is wrong, because it would only be used if you had I2C
child nodes. If you didn't have any I2C nodes, then you would need to
delete the property from the parent node as well.
> The phandle in the mpc5200 case could be implicit since it is fixed in silicon.
If we want to use the same I2C driver for 52xx and 83xx, it shouldn't
be implicit. Otherwise, the driver will have to check the platform to
determine where to look.
> Is this register in a system register bank or an i2c one?
> gur->pordevsr2 & MPC85xx_PORDEVSR2_SEC_CFG
That should be "guts->" I think. The global utilities is a block of
miscellaneous registers, one per SOC. It's not part of the I2C block.
--
Timur Tabi
Linux kernel developer at Freescale
^ permalink raw reply
* Re: [i2c] [PATCH] powerpc: i2c-mpc: make speed registers configurable via FDT
From: Timur Tabi @ 2008-08-01 13:17 UTC (permalink / raw)
To: Trent Piepho; +Cc: Scott Wood, Linuxppc-dev, Linux I2C
In-Reply-To: <Pine.LNX.4.58.0807311610170.10341@shell4.speakeasy.net>
On Thu, Jul 31, 2008 at 6:32 PM, Trent Piepho <xyzzy@speakeasy.org> wrote:
> The real problem, which kept me from making a patch to do this months ago,
> is that the source clock that the I2C freq divider applies to is different
> for just about every MPC8xxx platform. Not just a different value, but a
> totally different internal clock. Sometimes is CCB, sometimes CCB/2,
> sometimes tsec2's clock, etc.
On which SOC is it the tesc2 clock?
> Sometimes the two i2c controllers don't even
> have the same clock.
On which platform is that the case? I thought I had all 8[356]xx
boards covered. Did I miss some?
--
Timur Tabi
Linux kernel developer at Freescale
^ permalink raw reply
* Re: libata badness
From: Kumar Gala @ 2008-08-01 12:46 UTC (permalink / raw)
To: Ben Dooks; +Cc: linux-ide, Jeff Garzik, Linux Kernel list, linuxppc-dev list
In-Reply-To: <20080801104347.GM26938@trinity.fluff.org>
On Aug 1, 2008, at 5:43 AM, Ben Dooks wrote:
> On Thu, Jul 31, 2008 at 04:58:05PM -0500, Kumar Gala wrote:
>> I figured out the issue. Its related to the interrupt routing being
>> conveyed to the code from the device tree. We have a missing 'space'
>> causing issues.
>
> out of interest, is the M5229 attached to a single IRQ in this device
> or has the bridge been configured to route the IRQs from the IDE to
> the same pin on the PIC?
The bridge is routing interrupts via an i8259 to a single interrupt on
the OpenPIC (primary pic).
- k
^ permalink raw reply
* Re: Board level compatibility matching
From: Josh Boyer @ 2008-08-01 12:28 UTC (permalink / raw)
To: benh; +Cc: linuxppc-dev, devicetree-discuss
In-Reply-To: <20080801080632.35edcb04@zod.rchland.ibm.com>
On Fri, 2008-08-01 at 08:06 -0400, Josh Boyer wrote:
> On Fri, 01 Aug 2008 14:25:39 +1000
> Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
>
> > About this whole generic board mumbo-jumbo: not happening. It's a pipe
> > dream, it doesn't work, and it leads to the sort of mess we have in chrp
> > where we end up having hacks to identify what exact sort of chrp we have
> > and do things differently etc...
> >
> > NOT HAPPENING.
> >
> > Now, there are two approaches here that are possible:
> >
> > - Your board is really pretty much exactly the same as board XXX,
> > except maybe you have a different flash size or such, and the support
> > for board XXX can cope perfectly with it simply due to the device-tree
> > the right information.
> >
> > If that happens to be the case, make your board compatible with board
> > XXX. Make that entry -second- in your compatible list, because one day
> > you'll figure out that there -is- indeed a difference and I don't want
> > to see board XXX code start to grow code to recognise your other board
> > and work around the difference. So at that stage, copy board XXX.c file
> > and start over with your own board support that matches on your first
> > compatible propery entry.
>
> 44x does this today for a small number of boards. The "issue", if
> there really is one, is that there's no clear definition on what is
> acceptable to be called "compatible". If _Linux_ platform support for
> board FOO
Ignore that last line. Emailing before coffee is considered dangerous.
josh
^ permalink raw reply
* Re: Board level compatibility matching
From: Josh Boyer @ 2008-08-01 12:06 UTC (permalink / raw)
To: benh; +Cc: linuxppc-dev, devicetree-discuss
In-Reply-To: <1217564739.11188.482.camel@pasglop>
On Fri, 01 Aug 2008 14:25:39 +1000
Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
> About this whole generic board mumbo-jumbo: not happening. It's a pipe
> dream, it doesn't work, and it leads to the sort of mess we have in chrp
> where we end up having hacks to identify what exact sort of chrp we have
> and do things differently etc...
>
> NOT HAPPENING.
>
> Now, there are two approaches here that are possible:
>
> - Your board is really pretty much exactly the same as board XXX,
> except maybe you have a different flash size or such, and the support
> for board XXX can cope perfectly with it simply due to the device-tree
> the right information.
>
> If that happens to be the case, make your board compatible with board
> XXX. Make that entry -second- in your compatible list, because one day
> you'll figure out that there -is- indeed a difference and I don't want
> to see board XXX code start to grow code to recognise your other board
> and work around the difference. So at that stage, copy board XXX.c file
> and start over with your own board support that matches on your first
> compatible propery entry.
44x does this today for a small number of boards. The "issue", if
there really is one, is that there's no clear definition on what is
acceptable to be called "compatible". If _Linux_ platform support for
board FOO
>
> - Once you figure out that really, those 5 boards here -do- share 99%
> of the code... it's just that one need a workaround at the IRQ fixup
> level, maybe one needs a tweak on a GPIO at boot and one has an issue on
> reboot that needs to be whacked a bit differently ... well, make
> -library- code.
>
> I have no objection of having something like for each ppc_md field
> called X, having a utility file providing an mpc52xx_generic_X function.
> Such a board could then basically have a small .c file whose ppc_md just
> use the generic functions for all except the ones that need to be
> hooked/wrapped/replaced/whatever.
This is sort of the part that sucks. Look at 44x. There are 10
board.c files there. There really only needs to be 3 or 4 (sam440ep,
warp, virtex, and "generic") because the board files are identical in
everything except name. By doing the library code approach, one still
has to create a board.c file for a new board and plug in the library
functions to ppc_md.
Alternatively, you could do the:
compatible = "specific-board", "similar-board"
approach that has been done for e.g. Bamboo and Yosemite. Again, the
issue is that is that OK? Is it OK for a board to claim compatibility
with another board when it might not have all the devices of that
board, or might have additional devices, etc. I was of the opinion
it is, and the device tree handles this just fine, as does the platform
code. But it can be confusing, hence the discussion here.
josh
^ permalink raw reply
* Re: floating point support in the driver.
From: Misbah khan @ 2008-08-01 12:00 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <200808011332.25368.laurentp@cse-semaphore.com>
I am not very clear Why floating point support in the Kernel should be
avoided ?
We want our DSP algorithm to run at the boot time and since kernel thread
having higher priority , i assume that it would be faster than user
application.
If i really have to speed up my application execution what mechanism will
you suggest me to try ?
After using Hardware VFP support also i am still laging the timing
requirement by 800 ms in my case
---- Misbah <><
Laurent Pinchart-4 wrote:
>
> On Friday 01 August 2008, Misbah khan wrote:
>>
>> Hi all,
>>
>> I have a DSP algorithm which i am running in the application even after
>> enabling the VFP support it is taking a lot of time to get executed hence
>>
>> I want to transform the same into the driver insted of an user
>> application.
>> Can anybody suggest whether doing the same could be a better solution and
>> what could be the chalenges that i have to face by implimenting such
>> floating point support in the driver.
>>
>> Is there a way in the application itself to make it execute faster.
>
> Floating-point in the kernel should be avoided. FPU state save/restore
> operations are costly and are not performed by the kernel when switching
> from userspace to kernelspace context. You will have to protect
> floating-point sections with kernel_fpu_begin/kernel_fpu_end which, if I'm
> not mistaken, disables preemption. That's probably not something you want
> to do. Why would the same code run faster in kernelspace then userspace ?
>
> --
> Laurent Pinchart
> CSE Semaphore Belgium
>
> Chaussee de Bruxelles, 732A
> B-1410 Waterloo
> Belgium
>
> T +32 (2) 387 42 59
> F +32 (2) 387 42 75
>
>
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
--
View this message in context: http://www.nabble.com/floating-point-support-in-the-driver.-tp18772109p18772952.html
Sent from the linuxppc-embedded mailing list archive at Nabble.com.
^ permalink raw reply
* Re: floating point support in the driver.
From: Laurent Pinchart @ 2008-08-01 11:32 UTC (permalink / raw)
To: linuxppc-embedded; +Cc: Misbah khan
In-Reply-To: <18772109.post@talk.nabble.com>
[-- Attachment #1: Type: text/plain, Size: 1149 bytes --]
On Friday 01 August 2008, Misbah khan wrote:
>
> Hi all,
>
> I have a DSP algorithm which i am running in the application even after
> enabling the VFP support it is taking a lot of time to get executed hence
>
> I want to transform the same into the driver insted of an user application.
> Can anybody suggest whether doing the same could be a better solution and
> what could be the chalenges that i have to face by implimenting such
> floating point support in the driver.
>
> Is there a way in the application itself to make it execute faster.
Floating-point in the kernel should be avoided. FPU state save/restore operations are costly and are not performed by the kernel when switching from userspace to kernelspace context. You will have to protect floating-point sections with kernel_fpu_begin/kernel_fpu_end which, if I'm not mistaken, disables preemption. That's probably not something you want to do. Why would the same code run faster in kernelspace then userspace ?
--
Laurent Pinchart
CSE Semaphore Belgium
Chaussee de Bruxelles, 732A
B-1410 Waterloo
Belgium
T +32 (2) 387 42 59
F +32 (2) 387 42 75
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* floating point support in the driver.
From: Misbah khan @ 2008-08-01 10:57 UTC (permalink / raw)
To: linuxppc-embedded
Hi all,
I have a DSP algorithm which i am running in the application even after
enabling the VFP support it is taking a lot of time to get executed hence
I want to transform the same into the driver insted of an user application.
Can anybody suggest whether doing the same could be a better solution and
what could be the chalenges that i have to face by implimenting such
floating point support in the driver.
Is there a way in the application itself to make it execute faster.
---- Misbah <><
--
View this message in context: http://www.nabble.com/floating-point-support-in-the-driver.-tp18772109p18772109.html
Sent from the linuxppc-embedded mailing list archive at Nabble.com.
^ permalink raw reply
* Re: ide pmac breakage
From: Bartlomiej Zolnierkiewicz @ 2008-08-01 10:54 UTC (permalink / raw)
To: benh; +Cc: FUJITA Tomonori, linux-ide, petkovbb, linuxppc-dev
In-Reply-To: <200807311251.02251.bzolnier@gmail.com>
On Thursday 31 July 2008, Bartlomiej Zolnierkiewicz wrote:
[...]
Sorry if my mails were a bit harsh but nobody likes to be pushed around.
[ It is not like I don't want to add proper hot-plugging support or do test
on more hardware but my time schedule is already tight enough and there are
still more fundamental things to address (which take priority). ]
> - host->dev[0] = hws[0]->dev;
> + host->dev[0] = hws[0]->parent ? hws[0]->parent : hws[0]->dev;
>
> Could you please try it together with my previous patch for
> ide_device_{get,put}()?
Please test it when you have some time.
^ permalink raw reply
* Re: libata badness
From: Ben Dooks @ 2008-08-01 10:43 UTC (permalink / raw)
To: Kumar Gala; +Cc: linux-ide, Jeff Garzik, Linux Kernel list, linuxppc-dev list
In-Reply-To: <DAE7C7B4-CE5B-45EB-B3B4-E5491A843CD9@kernel.crashing.org>
On Thu, Jul 31, 2008 at 04:58:05PM -0500, Kumar Gala wrote:
> I figured out the issue. Its related to the interrupt routing being
> conveyed to the code from the device tree. We have a missing 'space'
> causing issues.
out of interest, is the M5229 attached to a single IRQ in this device
or has the bridge been configured to route the IRQs from the IDE to
the same pin on the PIC?
--
Ben
Q: What's a light-year?
A: One-third less calories than a regular year.
^ 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