Re: 2.6.24-rc3-mm1- powerpc link failure
Hi Andrew, The kernel build fails on powerpc while linking, AS .tmp_kallsyms3.o LD vmlinux.o ld: TOC section size exceeds 64k make: *** [vmlinux.o] Error 1 The patch posted at http://lkml.org/lkml/2007/11/13/414, solves this failure. -- Thanks & Regards, Kamalesh Babulal, Linux Technology Center, IBM, ISTL. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: [PATCH v7 3/9] add Freescale SerDes PHY support
> I'm ok for it to be taken care of in u-boot for now. However, if we > later plan to add power management support to this block. We probably > have to do it in kernel. In that case, can't it be just saving/restoring ? That's easier than supporting full configuration of random user setups Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] [POWERPC] Emulate isel (Integer Select) instruction
On Tue, 2007-11-20 at 15:01 -0600, Kumar Gala wrote: > > Given that the instruction is meant to be a performance enhancement, > > we should probably warn the first few times it's emulated, so the > user > > knows they should change their toolchain setup if possible. > > The same is true of mcrxr, popcntb, and possibly string ld/st. > > Feel free to submit a patch that warns about their usage. At least we should keep counters... best would be per-task counters in /proc but that sounds harder :-) I remember in the early days of powerpc, it wasn't uncommon to have apps with issues because they used 601 only bits on 603/4 that had to be emulated (such as old POWER opcodes). On MacOS, we used to have a system-wide counter of the number of emulated instructions we could use to detect these things. Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] [POWERPC] Emulate isel (Integer Select) instruction
On Tue, 20 Nov 2007, Kumar Gala wrote:
> On Nov 20, 2007, at 11:54 AM, Scott Wood wrote:
> > On Mon, Nov 19, 2007 at 09:36:57PM -0600, Kumar Gala wrote:
> >> isel (Integer Select) is a new user space instruction in the
> >> PowerISA 2.04 spec. Not all processors implement it so lets emulate
> >> to ensure code built with isel will run everywhere.
> >
> > Given that the instruction is meant to be a performance enhancement,
> > we should probably warn the first few times it's emulated, so the user
> > knows they should change their toolchain setup if possible.
>
> The same is true of mcrxr, popcntb, and possibly string ld/st.
>
> Feel free to submit a patch that warns about their usage.
Something like this?
Probably we also want it for:
- arch/powerpc/kernel/align.c
o emulate_dcbz()
o emulate_multiple()
o emulate_fp_pair()
o emulate_spe()
- arch/powerpc/kernel/softemu8xx.c
o Soft_emulate_8xx()
- arch/powerpc/kernel/traps.c
o SoftwareEmulation()
- arch/powerpc/kernel/vecemu.c
o emulate_altivec()
Question: do we want it for emulate_single_step(), too?
So far my Debian userland didn't trigger any of them on the PS3, I had to
write an explicit test ;-)
---
arch/powerpc/kernel/traps.c | 19 +--
1 files changed, 17 insertions(+), 2 deletions(-)
--- a/arch/powerpc/kernel/traps.c
+++ b/arch/powerpc/kernel/traps.c
@@ -707,6 +707,14 @@ static int emulate_popcntb_inst(struct p
return 0;
}
+#define WARN_EMULATE(type) \
+ do {\
+ static unsigned int count; \
+ if (count++ < 10) \
+ pr_warning("%s used emulated %s instruction\n", \
+ current->comm, type);\
+ } while (0)
+
static int emulate_instruction(struct pt_regs *regs)
{
u32 instword;
@@ -721,31 +729,38 @@ static int emulate_instruction(struct pt
/* Emulate the mfspr rD, PVR. */
if ((instword & INST_MFSPR_PVR_MASK) == INST_MFSPR_PVR) {
+ WARN_EMULATE("mfpvr");
rd = (instword >> 21) & 0x1f;
regs->gpr[rd] = mfspr(SPRN_PVR);
return 0;
}
/* Emulating the dcba insn is just a no-op. */
- if ((instword & INST_DCBA_MASK) == INST_DCBA)
+ if ((instword & INST_DCBA_MASK) == INST_DCBA) {
+ WARN_EMULATE("dcba");
return 0;
+ }
/* Emulate the mcrxr insn. */
if ((instword & INST_MCRXR_MASK) == INST_MCRXR) {
int shift = (instword >> 21) & 0x1c;
unsigned long msk = 0xf000UL >> shift;
+ WARN_EMULATE("mcrxr");
regs->ccr = (regs->ccr & ~msk) | ((regs->xer >> shift) & msk);
regs->xer &= ~0xf000UL;
return 0;
}
/* Emulate load/store string insn. */
- if ((instword & INST_STRING_GEN_MASK) == INST_STRING)
+ if ((instword & INST_STRING_GEN_MASK) == INST_STRING) {
+ WARN_EMULATE("string");
return emulate_string_inst(regs, instword);
+ }
/* Emulate the popcntb (Population Count Bytes) instruction. */
if ((instword & INST_POPCNTB_MASK) == INST_POPCNTB) {
+ WARN_EMULATE("popcntb");
return emulate_popcntb_inst(regs, instword);
}
With kind regards,
Geert Uytterhoeven
Software Architect
Sony Network and Software Technology Center Europe
The Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · Belgium
Phone:+32 (0)2 700 8453
Fax: +32 (0)2 700 8622
E-mail: [EMAIL PROTECTED]
Internet: http://www.sony-europe.com/
Sony Network and Software Technology Center Europe
A division of Sony Service Centre (Europe) N.V.
Registered office: Technologielaan 7 · B-1840 Londerzeel · Belgium
VAT BE 0413.825.160 · RPR Brussels
Fortis Bank Zaventem · Swift GEBABEBB08A · IBAN BE39001382358619___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC/PATCH 5/14] powerpc: Fix 440/440A machine check handling
On Wed, 21 Nov 2007 17:16:24 +1100
Benjamin Herrenschmidt <[EMAIL PROTECTED]> wrote:
> This removes CONFIG_440A which was a problem for multiplatform
> kernels and instead fixes up the IVOR at runtime from a setup_cpu
> function. The "A" version of the machine check also tweaks the
> regs->trap value to differenciate the 2 versions at the C level.
>
> void machine_check_exception(struct pt_regs *regs)
> {
> @@ -463,8 +489,20 @@ void machine_check_exception(struct pt_r
> /* See if any machine dependent calls */
> if (ppc_md.machine_check_exception)
> recover = ppc_md.machine_check_exception(regs);
> - else
> - recover = generic_machine_check_exception(regs);
> + else {
> +#ifdef CONFIG_4xx
> + if (IS_MCHECK_EXC(regs))
> + recover = decode_machine_check_4xxA(regs);
> + else
> + recover = decode_machine_check_4xx(regs);
> +#elif defined (CONFIG_E500)
> + recover = decode_machine_check_e500(regs);
> +#elif defined (CONFIG_E200)
> + recover = decode_machine_check_e200(regs);
> +#else
> + recover = decode_machine_check_generic(regs);
> +#endif
Why didn't you just add a ppc_md.machine_check_exception to the
effected boards? Then you could have gotten rid of the ifdefs all
together.
josh
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC/PATCH 13/14] powerpc: EP405 boards support for arch/powerpc
On Wed, 21 Nov 2007 17:16:31 +1100 Benjamin Herrenschmidt <[EMAIL PROTECTED]> wrote: > Brings EP405 support to arch/powerpc. The IRQ routing for the CPLD > comes from a device-tree property, PCI is working to the point where > I can see the video card, USB device, and south bridge. > > This should work with both EP405 and EP405PC. > > I've not totally figured out how IRQs are wired on this hardware > though, thus at this stage, expect only USB interrupts working, > pretty much the same as what arch/ppc did. > > Also, the flash, nvram, rtc and temp control still have to be wired. > > Signed-off-by: Benjamin Herrenschmidt <[EMAIL PROTECTED]> > --- > Index: linux-work/arch/powerpc/boot/dts/ep405.dts > === > --- /dev/null 1970-01-01 00:00:00.0 + > +++ linux-work/arch/powerpc/boot/dts/ep405.dts2007-11-21 > 16:23:03.0 +1100 > @@ -0,0 +1,221 @@ > +/* > + * Device Tree Source for EP405 > + * > + * Copyright 2007 IBM Corp. > + * Josh Boyer <[EMAIL PROTECTED]> Hm... odd. I don't remember writing this device tree ;) josh ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC/PATCH 0/14] powerpc: 4xx PCI and PCI-X support
On Wed, 21 Nov 2007 17:16:17 +1100 Benjamin Herrenschmidt <[EMAIL PROTECTED]> wrote: > Here's a set of patches that bring PCI and PCI-X support for > 4xx (PCIe still missing) in arch/powerpc. > > This is for review before I ask paulus to pull that into his > for 2.6.25 tree. Some of the patches still need a bit more > testing vs. regressions on other platforms such as the > 64 bits resource fixup one. I'm starting my 2.6.25 branch today. I'll probably throw these in there after I've tested a bit, since I need them to make further progress with 4xx anyway. josh ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC/PATCH 14/14] powerpc: Add PCI to Walnut platform
On Wed, 21 Nov 2007 17:16:32 +1100 Benjamin Herrenschmidt <[EMAIL PROTECTED]> wrote: > This wires up the 4xx PCI support & device-tree bits for the > 405GP based Walnut platform. > > Signed-off-by: Benjamin Herrenschmidt <[EMAIL PROTECTED]> > --- > > This one is untested, haven't had time to dig my walnut and put it > back into working condition. Josh, can you verify that IRQs are > working (routing is correct ?) Thanks ! Yep, I'll try it out early next week. josh ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC/PATCH 0/14] powerpc: 4xx PCI and PCI-X support
On Wednesday 21 November 2007, Josh Boyer wrote: > Benjamin Herrenschmidt <[EMAIL PROTECTED]> wrote: > > Here's a set of patches that bring PCI and PCI-X support for > > 4xx (PCIe still missing) in arch/powerpc. > > > > This is for review before I ask paulus to pull that into his > > for 2.6.25 tree. Some of the patches still need a bit more > > testing vs. regressions on other platforms such as the > > 64 bits resource fixup one. > > I'm starting my 2.6.25 branch today. I'll probably throw these in > there after I've tested a bit, since I need them to make further > progress with 4xx anyway. Yes, it would be great to have an "official" repo with all the new 4xx stuff (PCI, EMAC...) stuff. Thanks. Best regards, Stefan ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] [POWERPC] Emulate isel (Integer Select) instruction
On Nov 21, 2007, at 3:12 AM, Benjamin Herrenschmidt wrote: > > On Tue, 2007-11-20 at 15:01 -0600, Kumar Gala wrote: >>> Given that the instruction is meant to be a performance enhancement, >>> we should probably warn the first few times it's emulated, so the >> user >>> knows they should change their toolchain setup if possible. >> >> The same is true of mcrxr, popcntb, and possibly string ld/st. >> >> Feel free to submit a patch that warns about their usage. > > At least we should keep counters... best would be per-task counters > in /proc but that sounds harder :-) > > I remember in the early days of powerpc, it wasn't uncommon to have > apps > with issues because they used 601 only bits on 603/4 that had to be > emulated (such as old POWER opcodes). On MacOS, we used to have a > system-wide counter of the number of emulated instructions we could > use > to detect these things. I think having some form of per insn group counters would be useful as well. I know it would be helpful to debug user problems if they are doing a lot of FP emu or the like and don't know it. - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] [POWERPC] Emulate isel (Integer Select) instruction
On Nov 21, 2007, at 7:09 AM, Geert Uytterhoeven wrote:
> On Tue, 20 Nov 2007, Kumar Gala wrote:
>> On Nov 20, 2007, at 11:54 AM, Scott Wood wrote:
>>> On Mon, Nov 19, 2007 at 09:36:57PM -0600, Kumar Gala wrote:
isel (Integer Select) is a new user space instruction in the
PowerISA 2.04 spec. Not all processors implement it so lets
emulate
to ensure code built with isel will run everywhere.
>>>
>>> Given that the instruction is meant to be a performance enhancement,
>>> we should probably warn the first few times it's emulated, so the
>>> user
>>> knows they should change their toolchain setup if possible.
>>
>> The same is true of mcrxr, popcntb, and possibly string ld/st.
>>
>> Feel free to submit a patch that warns about their usage.
>
> Something like this?
>
> Probably we also want it for:
>
> - arch/powerpc/kernel/align.c
> o emulate_dcbz()
> o emulate_multiple()
> o emulate_fp_pair()
> o emulate_spe()
>
> - arch/powerpc/kernel/softemu8xx.c
> o Soft_emulate_8xx()
>
> - arch/powerpc/kernel/traps.c
> o SoftwareEmulation()
You missed math_emu.
> - arch/powerpc/kernel/vecemu.c
> o emulate_altivec()
I'm not sure I would concern this one emulation, there isn't much you
can do about the denorm fixup.
How about some per processor counters in sysfs under the processor.
> Question: do we want it for emulate_single_step(), too?
What do you mean, we should could the emulation, the emulate single
step just is for handling if you are doing debug while hitting an
emulated insn.
> So far my Debian userland didn't trigger any of them on the PS3, I
> had to
> write an explicit test ;-)
> ---
> arch/powerpc/kernel/traps.c | 19 +--
> 1 files changed, 17 insertions(+), 2 deletions(-)
>
> --- a/arch/powerpc/kernel/traps.c
> +++ b/arch/powerpc/kernel/traps.c
> @@ -707,6 +707,14 @@ static int emulate_popcntb_inst(struct p
> return 0;
> }
>
> +#define WARN_EMULATE(type) \
> + do {\
> + static unsigned int count; \
> + if (count++ < 10) \
> + pr_warning("%s used emulated %s instruction\n", \
> +current->comm, type);\
> + } while (0)
> +
> static int emulate_instruction(struct pt_regs *regs)
> {
> u32 instword;
> @@ -721,31 +729,38 @@ static int emulate_instruction(struct pt
>
> /* Emulate the mfspr rD, PVR. */
> if ((instword & INST_MFSPR_PVR_MASK) == INST_MFSPR_PVR) {
> + WARN_EMULATE("mfpvr");
> rd = (instword >> 21) & 0x1f;
> regs->gpr[rd] = mfspr(SPRN_PVR);
> return 0;
> }
>
> /* Emulating the dcba insn is just a no-op. */
> - if ((instword & INST_DCBA_MASK) == INST_DCBA)
> + if ((instword & INST_DCBA_MASK) == INST_DCBA) {
> + WARN_EMULATE("dcba");
> return 0;
> + }
>
> /* Emulate the mcrxr insn. */
> if ((instword & INST_MCRXR_MASK) == INST_MCRXR) {
> int shift = (instword >> 21) & 0x1c;
> unsigned long msk = 0xf000UL >> shift;
>
> + WARN_EMULATE("mcrxr");
> regs->ccr = (regs->ccr & ~msk) | ((regs->xer >> shift) & msk);
> regs->xer &= ~0xf000UL;
> return 0;
> }
>
> /* Emulate load/store string insn. */
> - if ((instword & INST_STRING_GEN_MASK) == INST_STRING)
> + if ((instword & INST_STRING_GEN_MASK) == INST_STRING) {
> + WARN_EMULATE("string");
> return emulate_string_inst(regs, instword);
> + }
>
> /* Emulate the popcntb (Population Count Bytes) instruction. */
> if ((instword & INST_POPCNTB_MASK) == INST_POPCNTB) {
> + WARN_EMULATE("popcntb");
> return emulate_popcntb_inst(regs, instword);
> }
>
This looks good as a start.
- k
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] [POWERPC] Emulate isel (Integer Select) instruction
On Wed, 21 Nov 2007, Kumar Gala wrote: > On Nov 21, 2007, at 7:09 AM, Geert Uytterhoeven wrote: > > On Tue, 20 Nov 2007, Kumar Gala wrote: > > > On Nov 20, 2007, at 11:54 AM, Scott Wood wrote: > > > > On Mon, Nov 19, 2007 at 09:36:57PM -0600, Kumar Gala wrote: > > > > > isel (Integer Select) is a new user space instruction in the > > > > > PowerISA 2.04 spec. Not all processors implement it so lets emulate > > > > > to ensure code built with isel will run everywhere. > > > > > > > > Given that the instruction is meant to be a performance enhancement, > > > > we should probably warn the first few times it's emulated, so the user > > > > knows they should change their toolchain setup if possible. > > > > > > The same is true of mcrxr, popcntb, and possibly string ld/st. > > > > > > Feel free to submit a patch that warns about their usage. > > > > Something like this? > > > > Probably we also want it for: > > > > - arch/powerpc/kernel/align.c > > o emulate_dcbz() > > o emulate_multiple() > > o emulate_fp_pair() > > o emulate_spe() > > > > - arch/powerpc/kernel/softemu8xx.c > > o Soft_emulate_8xx() > > > > - arch/powerpc/kernel/traps.c > > o SoftwareEmulation() > > You missed math_emu. > > > - arch/powerpc/kernel/vecemu.c > > o emulate_altivec() > > I'm not sure I would concern this one emulation, there isn't much you can do > about the denorm fixup. > > How about some per processor counters in sysfs under the processor. Good idea! > > Question: do we want it for emulate_single_step(), too? > > What do you mean, we should could the emulation, the emulate single step just > is for handling if you are doing debug while hitting an emulated insn. I mean: should these be counted? With kind regards, Geert Uytterhoeven Software Architect Sony Network and Software Technology Center Europe The Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · Belgium Phone:+32 (0)2 700 8453 Fax: +32 (0)2 700 8622 E-mail: [EMAIL PROTECTED] Internet: http://www.sony-europe.com/ Sony Network and Software Technology Center Europe A division of Sony Service Centre (Europe) N.V. Registered office: Technologielaan 7 · B-1840 Londerzeel · Belgium VAT BE 0413.825.160 · RPR Brussels Fortis Bank Zaventem · Swift GEBABEBB08A · IBAN BE39001382358619___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC/PATCH 0/14] powerpc: 4xx PCI and PCI-X support
On Wed, 21 Nov 2007 15:04:12 +0100 Stefan Roese <[EMAIL PROTECTED]> wrote: > On Wednesday 21 November 2007, Josh Boyer wrote: > > Benjamin Herrenschmidt <[EMAIL PROTECTED]> wrote: > > > Here's a set of patches that bring PCI and PCI-X support for > > > 4xx (PCIe still missing) in arch/powerpc. > > > > > > This is for review before I ask paulus to pull that into his > > > for 2.6.25 tree. Some of the patches still need a bit more > > > testing vs. regressions on other platforms such as the > > > 64 bits resource fixup one. > > > > I'm starting my 2.6.25 branch today. I'll probably throw these in > > there after I've tested a bit, since I need them to make further > > progress with 4xx anyway. > > Yes, it would be great to have an "official" repo with all the new 4xx stuff > (PCI, EMAC...) stuff. Sure, I can do that. I'll probably use my master branch for this instead, and reserve for-2.6.25 for sending stuff to Paul. Reason being that lots of useful things for 4xx don't actually go through my tree (like EMAC, MTD stuff, etc). I'll send out an email when I've queued up some stuff. josh ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 3/3] [POWERPC] Add docs for Freescale DMA & DMA channel device tree nodes
Kumar Gala wrote:
> + * 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"
Shouldn't we put some text somewhere that we're calling it the Elo controller
even though that word isn't used in the reference manual?
> + * Freescale 85xx DMA Controller
And 86xx.
> +
> +Freescale PowerPC 85xx 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 :
> +- 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"
> + - reg :
> + - interrupts:
> + - interrupt-parent : optional, if needed for interrupt mapping
> +
> + Example:
> + [EMAIL PROTECTED] {
Shouldn't this be [EMAIL PROTECTED]
> + #address-cells = <1>;
> + #size-cells = <1>;
> + compatible = "fsl,mpc8540-dma", "fsl,eloplus-dma";
> + reg = <21300 4>;
> + ranges = <0 21100 200>;
> + [EMAIL PROTECTED] {
> + compatible = "fsl,mpc8540-dma-channel",
> "fsl,eloplus-dma-channel";
> + reg = <0 80>;
> + interrupt-parent = <&mpic>;
> + interrupts = <14 2>;
> + };
The DMA controller and the DMA channels need a "device-id", so that they can
be identified by number. Some peripherals, like the SSI, can only use the
controller and channel number. This is what I have in my 8610 DTS:
[EMAIL PROTECTED] {
#address-cells = <1>;
#size-cells = <1>;
compatible = "fsl,mpc8610-dma", "fsl,mpc8540-dma";
--> device-id = <0>;
reg = <21300 4>; /* DMA general status register */
ranges = <0 21100 200>;
[EMAIL PROTECTED] {
compatible = "fsl,mpc8610-dma-channel",
"fsl,mpc8540-dma-channel";
--> device-id = <0>;
reg = <0 80>;
interrupt-parent = <&mpic>;
interrupts = <14 2>;
};
--
Timur Tabi
Linux Kernel Developer @ Freescale
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 3/3] [POWERPC] Add docs for Freescale DMA & DMA channel device tree nodes
On Nov 21, 2007, at 8:59 AM, Timur Tabi wrote:
> Kumar Gala wrote:
>
>> + * 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"
>
> Shouldn't we put some text somewhere that we're calling it the Elo
> controller even though that word isn't used in the reference manual?
we don't really have a place to put that. its effectively documented
right here.
>
>
>> + * Freescale 85xx DMA Controller
>
> And 86xx.
yes, true.
>> +
>> +Freescale PowerPC 85xx 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 : > status reg>
>> +- 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"
>> +- reg :
>> +- interrupts:
>> +- interrupt-parent : optional, if needed for interrupt mapping
>> +
>> + Example:
>> +[EMAIL PROTECTED] {
>
> Shouldn't this be [EMAIL PROTECTED]
its an example that has not basis is reality :)
>> +#address-cells = <1>;
>> +#size-cells = <1>;
>> +compatible = "fsl,mpc8540-dma", "fsl,eloplus-dma";
>> +reg = <21300 4>;
>> +ranges = <0 21100 200>;
>> +[EMAIL PROTECTED] {
>> +compatible = "fsl,mpc8540-dma-channel",
>> "fsl,eloplus-dma-
>> channel";
>> +reg = <0 80>;
>> +interrupt-parent = <&mpic>;
>> +interrupts = <14 2>;
>> +};
>
> The DMA controller and the DMA channels need a "device-id", so that
> they can be identified by number. Some peripherals, like the SSI,
> can only use the controller and channel number. This is what I have
> in my 8610 DTS:
Why not use reg for this? I don't see any reason to add another
"unique id" when there is already one.
>[EMAIL PROTECTED] {
>#address-cells = <1>;
>#size-cells = <1>;
>compatible = "fsl,mpc8610-dma", "fsl,mpc8540-
> dma";
>--> device-id = <0>;
>reg = <21300 4>; /* DMA general status
> register */
>ranges = <0 21100 200>;
>
>[EMAIL PROTECTED] {
>compatible = "fsl,mpc8610-dma-channel",
>"fsl,mpc8540-dma-channel";
>--> device-id = <0>;
>reg = <0 80>;
>interrupt-parent = <&mpic>;
>interrupts = <14 2>;
>};
>
- k
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] [POWERPC] Emulate isel (Integer Select) instruction
On Nov 21, 2007, at 8:33 AM, Geert Uytterhoeven wrote: > On Wed, 21 Nov 2007, Kumar Gala wrote: >> On Nov 21, 2007, at 7:09 AM, Geert Uytterhoeven wrote: >>> On Tue, 20 Nov 2007, Kumar Gala wrote: On Nov 20, 2007, at 11:54 AM, Scott Wood wrote: > On Mon, Nov 19, 2007 at 09:36:57PM -0600, Kumar Gala wrote: >> isel (Integer Select) is a new user space instruction in the >> PowerISA 2.04 spec. Not all processors implement it so lets >> emulate >> to ensure code built with isel will run everywhere. > > Given that the instruction is meant to be a performance > enhancement, > we should probably warn the first few times it's emulated, so > the user > knows they should change their toolchain setup if possible. The same is true of mcrxr, popcntb, and possibly string ld/st. Feel free to submit a patch that warns about their usage. >>> >>> Something like this? >>> >>> Probably we also want it for: >>> >>> - arch/powerpc/kernel/align.c >>> o emulate_dcbz() >>> o emulate_multiple() >>> o emulate_fp_pair() >>> o emulate_spe() >>> >>> - arch/powerpc/kernel/softemu8xx.c >>> o Soft_emulate_8xx() >>> >>> - arch/powerpc/kernel/traps.c >>> o SoftwareEmulation() >> >> You missed math_emu. >> >>> - arch/powerpc/kernel/vecemu.c >>> o emulate_altivec() >> >> I'm not sure I would concern this one emulation, there isn't much >> you can do >> about the denorm fixup. >> >> How about some per processor counters in sysfs under the processor. > > Good idea! > >>> Question: do we want it for emulate_single_step(), too? >> >> What do you mean, we should could the emulation, the emulate single >> step just >> is for handling if you are doing debug while hitting an emulated >> insn. > > I mean: should these be counted? the number of emulated single steps insn? not sure I follow. I think we should count regardless if we go through emulate_single_step(). - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
annoying prinkts during vmemmap initialization
Hi Andi, your patch 'ppc64: SPARSEMEM_VMEMMAP support' adds the following two lines: + printk(KERN_WARNING "vmemmap %08lx allocated at %p, " + "physical %p.\n", start, p, __pa(p)); in a loop around basically every page. That's a lot of flooding (with the wrong printk level, btw) and really slows down booting my cell blade a lot (these only have a very slow serial over lan console). Any reason to keep this? And if yes can we please make it conditional on some kind of vmemmap_debug boot option? ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/8] ibm_newemac: Fix possible lockup on close
On Wed, Nov 21, 2007 at 05:06:39PM +1100, Benjamin Herrenschmidt wrote: > It's a bad idea to call flush_scheduled_work from within a > netdev->stop because the linkwatch will occasionally take the > rtnl lock from a workqueue context, and thus that can deadlock. > > This reworks things a bit in that area to avoid the problem. So from the name of the driver you want to keep the previous emac driver around. Is there a good reason for that? ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/8] ibm_newemac: Fix possible lockup on close
On Wed, 21 Nov 2007 16:41:23 +0100 Christoph Hellwig <[EMAIL PROTECTED]> wrote: > On Wed, Nov 21, 2007 at 05:06:39PM +1100, Benjamin Herrenschmidt wrote: > > It's a bad idea to call flush_scheduled_work from within a > > netdev->stop because the linkwatch will occasionally take the > > rtnl lock from a workqueue context, and thus that can deadlock. > > > > This reworks things a bit in that area to avoid the problem. > > So from the name of the driver you want to keep the previous emac > driver around. Is there a good reason for that? It's being kept around until arch/ppc dies. Then things should get renamed. josh ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 2/2][2.6.24] ehea: Reworked rcv queue handling to log only fatal errors
Prevent driver from brawly logging packet checksum errors.
Signed-off-by: Thomas Klein <[EMAIL PROTECTED]>
---
drivers/net/ehea/ehea.h |2 +-
drivers/net/ehea/ehea_main.c | 11 +--
drivers/net/ehea/ehea_qmr.h |4 ++--
3 files changed, 8 insertions(+), 9 deletions(-)
diff --git a/drivers/net/ehea/ehea.h b/drivers/net/ehea/ehea.h
index 5935899..ea67615 100644
--- a/drivers/net/ehea/ehea.h
+++ b/drivers/net/ehea/ehea.h
@@ -40,7 +40,7 @@
#include
#define DRV_NAME "ehea"
-#define DRV_VERSION"EHEA_0082"
+#define DRV_VERSION"EHEA_0083"
/* eHEA capability flags */
#define DLPAR_PORT_ADD_REM 1
diff --git a/drivers/net/ehea/ehea_main.c b/drivers/net/ehea/ehea_main.c
index d2f715d..869e160 100644
--- a/drivers/net/ehea/ehea_main.c
+++ b/drivers/net/ehea/ehea_main.c
@@ -410,11 +410,6 @@ static int ehea_treat_poll_error(struct ehea_port_res *pr,
int rq,
if (cqe->status & EHEA_CQE_STAT_ERR_CRC)
pr->p_stats.err_frame_crc++;
- if (netif_msg_rx_err(pr->port)) {
- ehea_error("CQE Error for QP %d", pr->qp->init_attr.qp_nr);
- ehea_dump(cqe, sizeof(*cqe), "CQE");
- }
-
if (rq == 2) {
*processed_rq2 += 1;
skb = get_skb_by_index(pr->rq2_skba.arr, pr->rq2_skba.len, cqe);
@@ -426,7 +421,11 @@ static int ehea_treat_poll_error(struct ehea_port_res *pr,
int rq,
}
if (cqe->status & EHEA_CQE_STAT_FAT_ERR_MASK) {
- ehea_error("Critical receive error. Resetting port.");
+ if (netif_msg_rx_err(pr->port)) {
+ ehea_error("Critical receive error for QP %d. "
+ "Resetting port.", pr->qp->init_attr.qp_nr);
+ ehea_dump(cqe, sizeof(*cqe), "CQE");
+ }
schedule_work(&pr->port->reset_task);
return 1;
}
diff --git a/drivers/net/ehea/ehea_qmr.h b/drivers/net/ehea/ehea_qmr.h
index 562de0e..bc62d38 100644
--- a/drivers/net/ehea/ehea_qmr.h
+++ b/drivers/net/ehea/ehea_qmr.h
@@ -145,8 +145,8 @@ struct ehea_rwqe {
#define EHEA_CQE_VLAN_TAG_XTRACT 0x0400
#define EHEA_CQE_TYPE_RQ 0x60
-#define EHEA_CQE_STAT_ERR_MASK 0x720F
-#define EHEA_CQE_STAT_FAT_ERR_MASK 0x1F
+#define EHEA_CQE_STAT_ERR_MASK 0x700F
+#define EHEA_CQE_STAT_FAT_ERR_MASK 0xF
#define EHEA_CQE_STAT_ERR_TCP 0x4000
#define EHEA_CQE_STAT_ERR_IP 0x2000
#define EHEA_CQE_STAT_ERR_CRC 0x1000
--
1.5.2
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] [POWERPC] Emulate isel (Integer Select) instruction
On Wed, 21 Nov 2007, Kumar Gala wrote: > On Nov 21, 2007, at 7:09 AM, Geert Uytterhoeven wrote: > > On Tue, 20 Nov 2007, Kumar Gala wrote: > > > On Nov 20, 2007, at 11:54 AM, Scott Wood wrote: > > > > Given that the instruction is meant to be a performance enhancement, > > > > we should probably warn the first few times it's emulated, so the user > > > > knows they should change their toolchain setup if possible. > > > > > > The same is true of mcrxr, popcntb, and possibly string ld/st. > > > > > > Feel free to submit a patch that warns about their usage. > > How about some per processor counters in sysfs under the processor. Per processor? That means it has to be per_cpu, which sounds a bit like overkill to me. With kind regards, Geert Uytterhoeven Software Architect Sony Network and Software Technology Center Europe The Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · Belgium Phone:+32 (0)2 700 8453 Fax: +32 (0)2 700 8622 E-mail: [EMAIL PROTECTED] Internet: http://www.sony-europe.com/ Sony Network and Software Technology Center Europe A division of Sony Service Centre (Europe) N.V. Registered office: Technologielaan 7 · B-1840 Londerzeel · Belgium VAT BE 0413.825.160 · RPR Brussels Fortis Bank Zaventem · Swift GEBABEBB08A · IBAN BE39001382358619___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 1/2][2.6.24] ehea: Improve tx packets counting
Using own tx_packets counter instead of firmware counters.
Signed-off-by: Thomas Klein <[EMAIL PROTECTED]>
---
drivers/net/ehea/ehea.h |2 +-
drivers/net/ehea/ehea_main.c |9 +++--
2 files changed, 8 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ehea/ehea.h b/drivers/net/ehea/ehea.h
index f78e5bf..5935899 100644
--- a/drivers/net/ehea/ehea.h
+++ b/drivers/net/ehea/ehea.h
@@ -40,7 +40,7 @@
#include
#define DRV_NAME "ehea"
-#define DRV_VERSION"EHEA_0080"
+#define DRV_VERSION"EHEA_0082"
/* eHEA capability flags */
#define DLPAR_PORT_ADD_REM 1
diff --git a/drivers/net/ehea/ehea_main.c b/drivers/net/ehea/ehea_main.c
index f0319f1..d2f715d 100644
--- a/drivers/net/ehea/ehea_main.c
+++ b/drivers/net/ehea/ehea_main.c
@@ -136,7 +136,7 @@ static struct net_device_stats *ehea_get_stats(struct
net_device *dev)
struct ehea_port *port = netdev_priv(dev);
struct net_device_stats *stats = &port->stats;
struct hcp_ehea_port_cb2 *cb2;
- u64 hret, rx_packets;
+ u64 hret, rx_packets, tx_packets;
int i;
memset(stats, 0, sizeof(*stats));
@@ -162,7 +162,11 @@ static struct net_device_stats *ehea_get_stats(struct
net_device *dev)
for (i = 0; i < port->num_def_qps; i++)
rx_packets += port->port_res[i].rx_packets;
- stats->tx_packets = cb2->txucp + cb2->txmcp + cb2->txbcp;
+ tx_packets = 0;
+ for (i = 0; i < port->num_def_qps + port->num_add_tx_qps; i++)
+ tx_packets += port->port_res[i].tx_packets;
+
+ stats->tx_packets = tx_packets;
stats->multicast = cb2->rxmcp;
stats->rx_errors = cb2->rxuerr;
stats->rx_bytes = cb2->rxo;
@@ -2000,6 +2004,7 @@ static int ehea_start_xmit(struct sk_buff *skb, struct
net_device *dev)
}
ehea_post_swqe(pr->qp, swqe);
+ pr->tx_packets++;
if (unlikely(atomic_read(&pr->swqe_avail) <= 1)) {
spin_lock_irqsave(&pr->netif_queue, flags);
--
1.5.2
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 2/3] [POWERPC] Add docs for Freescale RapidIO device tree node
On Tue, Nov 20, 2007 at 11:13:58PM -0600, Kumar Gala wrote:
> Required properties:
> - compatible: compatible list, contains 2 entries, first is
> - "fsl,sata-CHIP", where CHIP is the processor
> + "fsl,CHIP-sata", where CHIP is the processor
>(mpc8315, mpc8379, etc.) and the second is
> - "fsl,sata-pq2pro"
> + "fsl,pq2pro-sata"
> - interrupts:
> - interrupt-parent : optional, if needed for interrupt mapping
> - reg :
> @@ -2531,12 +2531,53 @@ platforms are moved over to use the
> flattened-device-tree model.
> Example:
>
> [EMAIL PROTECTED] {
> - compatible = "fsl,mpc8315-sata", "fsl,sata-pq2pro;
> + compatible = "fsl,mpc8315-sata", "fsl,pq2pro-sata;
I think you meant to merge these changes with the previous patch...
-Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 3/3] [POWERPC] Add docs for Freescale DMA & DMA channel device tree nodes
On Tue, Nov 20, 2007 at 11:14:40PM -0600, Kumar Gala wrote: > +- 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" So if the DMA register set gets tweaked again, will we have eloplusplus? :-) Maybe elo2 would be better. Do we really need completely separate descriptions of the two, or can we just describe the difference in the compatible section? -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 3/3] [POWERPC] Add docs for Freescale DMA & DMA channel device tree nodes
On Wed, Nov 21, 2007 at 09:33:05AM -0600, Kumar Gala wrote:
> On Nov 21, 2007, at 8:59 AM, Timur Tabi wrote:
> >> + Example:
> >> + [EMAIL PROTECTED] {
> >
> > Shouldn't this be [EMAIL PROTECTED]
>
> its an example that has not basis is reality :)
But it should at least be internally consistent with this:
> >> + reg = <21300 4>;
[snip]
> > The DMA controller and the DMA channels need a "device-id", so that
> > they can be identified by number. Some peripherals, like the SSI,
> > can only use the controller and channel number. This is what I have
> > in my 8610 DTS:
>
> Why not use reg for this? I don't see any reason to add another
> "unique id" when there is already one.
A cell-index property would be useful here for indexing into the summary
status register.
>
> >[EMAIL PROTECTED] {
> >#address-cells = <1>;
> >#size-cells = <1>;
> >compatible = "fsl,mpc8610-dma", "fsl,mpc8540-
> > dma";
> >--> device-id = <0>;
I don't see any justification for having such a property in the parent node,
though.
-Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/5] PowerPC 74xx: Katana Qp device tree
On Fri, 16 Nov 2007 19:12:53 +0300
Andrei Dolnikov wrote:
> Device tree source file for the Emerson Katana Qp board
>
> Signed-off-by: Andrei Dolnikov <[EMAIL PROTECTED]>
>
> ---
> arch/powerpc/boot/dts/katanaqp.dts | 357
> + 1 files changed, 357
> insertions(+)
>
> diff --git a/arch/powerpc/boot/dts/katanaqp.dts
> b/arch/powerpc/boot/dts/katanaqp.dts new file mode 100644
> index 000..9273c4e
> --- /dev/null
> +++ b/arch/powerpc/boot/dts/katanaqp.dts
> @@ -0,0 +1,357 @@
> +/* Device Tree Source for Emerson Katana Qp
> + *
> + * Authors: Vladislav Buzov <[EMAIL PROTECTED]>
> + * Andrei Dolnikov <[EMAIL PROTECTED]>
> + *
> + * Based on prpmc8200.dts by Mark A. Greer <[EMAIL PROTECTED]>
> + *
> + * 2007 (c) MontaVista, Software, Inc. This file is licensed under
> + * the terms of the GNU General Public License version 2. This
> program
> + * is licensed "as is" without any warranty of any kind, whether
> express
> + * or implied.
> + *
> + */
> +
> +/ {
> + #address-cells = <1>;
> + #size-cells = <1>;
> + model = "Katana-Qp"; /* Default */
> + compatible = "emerson,Katana-Qp";
> + coherency-off;
> +
> + cpus {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + PowerPC,[EMAIL PROTECTED] {
> + device_type = "cpu";
> + reg = <0>;
> + clock-frequency = <0>; /*
> From U-boot */
> + bus-frequency = <0>;/* From
> U-boot */
> + timebase-frequency = <0>; /* From
> U-boot */
> + i-cache-line-size = <20>;
> + d-cache-line-size = <20>;
> + i-cache-size = <8000>;
> + d-cache-size = <8000>;
> + };
> + };
> +
> + memory {
> + device_type = "memory";
> + reg = < 2000>; /* Default (512MB)
> */
> + };
> +
shouldn't this come from the firmware if possible?
> + [EMAIL PROTECTED] { /* Marvell Discovery */
> + #address-cells = <1>;
> + #size-cells = <1>;
> + model = "mv64460"; /* Default
> */
> + compatible = "marvell,mv64x60";
> + clock-frequency = <7f28155>;/*
> 133.33 MHz */
This should be updated somewhere in fw or bootwrapper.. Or is it hardcoded
value that is not going to change?
> + reg = ;
> + virtual-reg = ;
> + ranges = I/O Space */
> + 9000 9000 3000/* PCI 1
> MEM Space */
> + e800 e800 0400/* User
> FLASH: Up to 64Mb */
> + f810 0001/*
> Bridge's regs */
> + f850 f850 0004>; /*
> Integrated SRAM */ +
> + [EMAIL PROTECTED] {
> + compatible = "cfi-flash";
> + reg = ; /* Default (16MB)
> */
> + probe-type = "CFI";
> + bank-width = <4>;
> +
> + [EMAIL PROTECTED] {
> + label = "Primary Monitor";
> + reg = <0 10>; /* 1Mb */
> + read-only;
> + };
> +
> + [EMAIL PROTECTED] {
> + label = "Primary Kernel";
> + reg = <10 20>; /* 2 Mb */
> + };
> +
> + [EMAIL PROTECTED] {
> + label = "Primary FS";
> + reg = <30 d0>; /* 13 Mb */
> + };
> +
> + };
> +
> + [EMAIL PROTECTED] {
> + compatible = "altera,maxii";
> + reg = ;
> + virtual-reg = ;
> + };
> +
> + mdio {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + compatible = "marvell,mv64x60-mdio";
> + [EMAIL PROTECTED] {
> + block-index = <0>;
> + compatible = "marvell,mv88e";
> + reg = ;
> + };
> + [EMAIL PROTECTED] {
> + compatible = "marvell,mv88e";
> + block-index = <1>;
> + reg = ;
> + };
> + [EMAIL PROTECTED] {
> + compatible = "marvell,mv88e";
> + block-index = <2>;
> + reg = <6>;
> + };
> + };
> +
> + [EMAIL PROTECTED] {
> + reg = <2000 2000>;
> + eth0 {
>
Re: [PATCH 3/3] [POWERPC] Add docs for Freescale DMA & DMA channel device tree nodes
On Nov 21, 2007, at 11:33 AM, Scott Wood wrote: > On Tue, Nov 20, 2007 at 11:14:40PM -0600, Kumar Gala wrote: >> +- 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" > > So if the DMA register set gets tweaked again, will we have > eloplusplus? :-) > Maybe elo2 would be better. Seem unlikely for the forseeable future. > Do we really need completely separate descriptions of the two, or > can we just describe the difference in the compatible section? it seemed easier to duplicate and fix. - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 2/3] [POWERPC] Add docs for Freescale RapidIO device tree node
On Nov 21, 2007, at 11:29 AM, Scott Wood wrote:
> On Tue, Nov 20, 2007 at 11:13:58PM -0600, Kumar Gala wrote:
>> Required properties:
>> - compatible: compatible list, contains 2 entries,
>> first is
>> - "fsl,sata-CHIP", where CHIP is the processor
>> + "fsl,CHIP-sata", where CHIP is the processor
>> (mpc8315, mpc8379, etc.) and the second is
>> - "fsl,sata-pq2pro"
>> + "fsl,pq2pro-sata"
>> - interrupts:
>> - interrupt-parent : optional, if needed for interrupt mapping
>> - reg :
>> @@ -2531,12 +2531,53 @@ platforms are moved over to use the
>> flattened-device-tree model.
>>Example:
>>
>> [EMAIL PROTECTED] {
>> -compatible = "fsl,mpc8315-sata", "fsl,sata-pq2pro;
>> +compatible = "fsl,mpc8315-sata", "fsl,pq2pro-sata;
>
> I think you meant to merge these changes with the previous patch...
Yeah a merge issue, I'll look into it.
- k
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 3/3] [POWERPC] Add docs for Freescale DMA & DMA channel device tree nodes
On Nov 21, 2007, at 11:35 AM, Scott Wood wrote:
> On Wed, Nov 21, 2007 at 09:33:05AM -0600, Kumar Gala wrote:
>> On Nov 21, 2007, at 8:59 AM, Timur Tabi wrote:
+ Example:
+ [EMAIL PROTECTED] {
>>>
>>> Shouldn't this be [EMAIL PROTECTED]
>>
>> its an example that has not basis is reality :)
>
> But it should at least be internally consistent with this:
>
+ reg = <21300 4>;
ahh, i see.. yes I'll fix that.
> [snip]
>>> The DMA controller and the DMA channels need a "device-id", so that
>>> they can be identified by number. Some peripherals, like the SSI,
>>> can only use the controller and channel number. This is what I have
>>> in my 8610 DTS:
>>
>> Why not use reg for this? I don't see any reason to add another
>> "unique id" when there is already one.
>
> A cell-index property would be useful here for indexing into the
> summary
> status register.
Divide by 0x80.
>>> [EMAIL PROTECTED] {
>>> #address-cells = <1>;
>>> #size-cells = <1>;
>>> compatible = "fsl,mpc8610-dma", "fsl,mpc8540-
>>> dma";
>>> --> device-id = <0>;
>
> I don't see any justification for having such a property in the
> parent node,
> though.
huh?
- k
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 4/5] PowerPC 74xx: Katana Qp base support
Hi Andrei,
Looks okay in general, some notes below...
On Fri, 16 Nov 2007 19:31:16 +0300
Andrei Dolnikov wrote:
> Emerson Katana Qp platform specific code
>
> Signed-off-by: Andrei Dolnikov <[EMAIL PROTECTED]>
>
> ---
> arch/powerpc/platforms/embedded6xx/Kconfig|9 +
> arch/powerpc/platforms/embedded6xx/Makefile |1
> arch/powerpc/platforms/embedded6xx/katanaqp.c | 180
> ++ 3 files changed, 190 insertions(+)
>
> diff --git a/arch/powerpc/platforms/embedded6xx/Kconfig
> b/arch/powerpc/platforms/embedded6xx/Kconfig index 8924095..33190bd
> 100644 --- a/arch/powerpc/platforms/embedded6xx/Kconfig
> +++ b/arch/powerpc/platforms/embedded6xx/Kconfig
> @@ -46,6 +46,15 @@ config PPC_PRPMC2800
> help
> This option enables support for the Motorola PrPMC2800
> board
> +config PPC_KATANAQP
> + bool "Emerson-Katana Qp"
> + depends on EMBEDDED6xx
> + select MV64X60
> + select NOT_COHERENT_CACHE
> + select WANT_DEVICE_TREE
> + help
> + This option enables support for the Emerson Katana Qp board
> +
> config TSI108_BRIDGE
> bool
> depends on MPC7448HPC2 || PPC_HOLLY
> diff --git a/arch/powerpc/platforms/embedded6xx/Makefile
> b/arch/powerpc/platforms/embedded6xx/Makefile index 844947c..c83558f
> 100644 --- a/arch/powerpc/platforms/embedded6xx/Makefile
> +++ b/arch/powerpc/platforms/embedded6xx/Makefile
> @@ -5,3 +5,4 @@ obj-$(CONFIG_MPC7448HPC2) += mpc7448_hpc2.o
> obj-$(CONFIG_LINKSTATION)+= linkstation.o ls_uart.o
> obj-$(CONFIG_PPC_HOLLY) += holly.o
> obj-$(CONFIG_PPC_PRPMC2800) += prpmc2800.o
> +obj-$(CONFIG_PPC_KATANAQP) += katanaqp.o
> diff --git a/arch/powerpc/platforms/embedded6xx/katanaqp.c
> b/arch/powerpc/platforms/embedded6xx/katanaqp.c new file mode 100644
> index 000..c0a8469
> --- /dev/null
> +++ b/arch/powerpc/platforms/embedded6xx/katanaqp.c
> @@ -0,0 +1,180 @@
> +/*
> + * Board setup routines for the Emerson Katana Qp
> + *
> + * Authors: Vladislav Buzov <[EMAIL PROTECTED]>
> + * Andrei Dolnikov <[EMAIL PROTECTED]>
> + *
> + * Based on prpmc2800.c by Dale Farnsworth <[EMAIL PROTECTED]>
> + *
> + * 2007 (c) MontaVista, Software, Inc. This file is licensed under
> + * the terms of the GNU General Public License version 2. This
> program
> + * is licensed "as is" without any warranty of any kind, whether
> express
> + * or implied.
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include
> +
> +#include
> +
> +#define PLATFORM_NAME_MAX64
> +
> +/* CPLD registers definitions */
> +#define KATANAQP_CPLD_RCR0x0004 /* Reset command */
> +#define KATANAQP_CPLD_RCR_CPUHR (1 << 7)
> +
> +#define KATANAQP_CPLD_HVR0x0020
> +
> +#define KATANAQP_CPLD_PSR0x0030 /* PCI status */
> +#define KATANAQP_CPLD_PSR_PMCM (1 << 1)
> +
> +#define KATANAQP_CPLD_HCR0x0044
> +
> +static char katanaqp_platform_name[PLATFORM_NAME_MAX];
> +
> +static void __iomem *cpld_base;
> +
> +int katanaqp_exclude_device(struct pci_controller *hose, u_char bus,
> + u_char devfn)
> +{
> + if (bus == 0 && PCI_SLOT(devfn) == 0)
> + return PCIBIOS_DEVICE_NOT_FOUND;
> + else
> + return PCIBIOS_SUCCESSFUL;
> +}
> +
> +static int __init katanaqp_is_monarch(void)
> +{
> + return !(in_8((volatile char *)(cpld_base +
> KATANAQP_CPLD_PSR)) &
> + KATANAQP_CPLD_PSR_PMCM);
> +}
> +
> +static void __init katanaqp_setup_arch(void)
> +{
> + struct device_node *cpld;
> + const unsigned int *reg;
> +
> + /*
> + * ioremap cpld registers in case they are later
> + * needed by katanaqp_reset_board().
> + */
> + cpld =
> of_find_node_by_path("/[EMAIL PROTECTED]/[EMAIL PROTECTED]");
> + reg = of_get_property(cpld, "reg", NULL);
> + of_node_put(cpld);
> + cpld_base = ioremap(reg[0], reg[1]);
> +
use of_iomap here?
> +#ifdef CONFIG_PCI
> + if (katanaqp_is_monarch()) {
> + mv64x60_pci_init();
> + ppc_md.pci_exclude_device = katanaqp_exclude_device;
> + }
> +#endif
> +
> + printk("Emerson Network Power %s\n", katanaqp_platform_name);
> +}
> +
> +static void katanaqp_reset_board(void)
> +{
> + local_irq_disable();
> +
> + /* issue hard reset to the reset command register */
> + out_8((volatile char *)(cpld_base + KATANAQP_CPLD_RCR),
> + KATANAQP_CPLD_RCR_CPUHR);
> + for (;;) ;
> +}
> +
> +static void katanaqp_restart(char *cmd)
> +{
> + katanaqp_reset_board();
> +}
> +
> +#ifdef CONFIG_NOT_COHERENT_CACHE
> +#define KATANAQP_COHERENCY_SETTING "off"
> +#else
> +#define KATANAQP_COHERENCY_SETTING "on"
> +#endif
> +
Does it mean this HW supports both coherent and non-coherent case?
I don't think we need to add this just "for the future" if QP doesn't have it.
If it does, I dont' see how it's being
Re: [PATCH] [POWERPC] Emulate isel (Integer Select) instruction
On Nov 21, 2007, at 10:50 AM, Geert Uytterhoeven wrote: > On Wed, 21 Nov 2007, Kumar Gala wrote: >> On Nov 21, 2007, at 7:09 AM, Geert Uytterhoeven wrote: >>> On Tue, 20 Nov 2007, Kumar Gala wrote: On Nov 20, 2007, at 11:54 AM, Scott Wood wrote: > Given that the instruction is meant to be a performance > enhancement, > we should probably warn the first few times it's emulated, so > the user > knows they should change their toolchain setup if possible. The same is true of mcrxr, popcntb, and possibly string ld/st. Feel free to submit a patch that warns about their usage. >> >> How about some per processor counters in sysfs under the processor. > > Per processor? That means it has to be per_cpu, which sounds a bit > like > overkill to me. I can probably live with global, not sure that would work with sysfs. - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 3/3] [POWERPC] Add docs for Freescale DMA & DMA channel device tree nodes
Kumar Gala wrote:
> On Nov 21, 2007, at 11:35 AM, Scott Wood wrote:
>> A cell-index property would be useful here for indexing into the summary
>> status register.
>
> Divide by 0x80.
:-P
Using cell-index for things like this is reasonably common, and endorsed
by current ePAPR drafts.
[EMAIL PROTECTED] {
#address-cells = <1>;
#size-cells = <1>;
compatible = "fsl,mpc8610-dma", "fsl,mpc8540-
dma";
--> device-id = <0>;
>>
>> I don't see any justification for having such a property in the parent
>> node,
>> though.
>
> huh?
Timur put device-id properties in both the parent and the channel nodes.
I was wondering why he did the former.
-Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC/PATCH 5/14] powerpc: Fix 440/440A machine check handling
> Why didn't you just add a ppc_md.machine_check_exception to the > effected boards? Then you could have gotten rid of the ifdefs all > together. Hrm... it's per processor, not per board. I didn't feel like digging which board uses which processor and go fixup all the ppc_md's Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC/PATCH 13/14] powerpc: EP405 boards support for arch/powerpc
> > Hm... odd. I don't remember writing this device tree ;) Heh, oops... it's mostly copied from walnut. I'll fix that up. Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC/PATCH 5/14] powerpc: Fix 440/440A machine check handling
On Thu, 22 Nov 2007 06:48:50 +1100 Benjamin Herrenschmidt <[EMAIL PROTECTED]> wrote: > > > Why didn't you just add a ppc_md.machine_check_exception to the > > effected boards? Then you could have gotten rid of the ifdefs all > > together. > > Hrm... it's per processor, not per board. I didn't feel like digging > which board uses which processor and go fixup all the ppc_md's Sounds like something a generic function could probe for from the DTS. I'll look at doing something here when I start making 44x multiplatform (soon). josh ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC/PATCH 0/14] powerpc: 4xx PCI and PCI-X support
On Wed, 2007-11-21 at 07:23 -0600, Josh Boyer wrote: > On Wed, 21 Nov 2007 17:16:17 +1100 > Benjamin Herrenschmidt <[EMAIL PROTECTED]> wrote: > > > Here's a set of patches that bring PCI and PCI-X support for > > 4xx (PCIe still missing) in arch/powerpc. > > > > This is for review before I ask paulus to pull that into his > > for 2.6.25 tree. Some of the patches still need a bit more > > testing vs. regressions on other platforms such as the > > 64 bits resource fixup one. > > I'm starting my 2.6.25 branch today. I'll probably throw these in > there after I've tested a bit, since I need them to make further > progress with 4xx anyway. Don't until I submit them for inclusion (when I said paulus above, I actually meant you of course :-), I want one more round (I already have enough comments to do minor fixups on most of them) But I would definitely appreciate testing :-) Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC/PATCH 0/14] powerpc: 4xx PCI and PCI-X support
On Wed, 2007-11-21 at 15:04 +0100, Stefan Roese wrote: > On Wednesday 21 November 2007, Josh Boyer wrote: > > Benjamin Herrenschmidt <[EMAIL PROTECTED]> wrote: > > > Here's a set of patches that bring PCI and PCI-X support for > > > 4xx (PCIe still missing) in arch/powerpc. > > > > > > This is for review before I ask paulus to pull that into his > > > for 2.6.25 tree. Some of the patches still need a bit more > > > testing vs. regressions on other platforms such as the > > > 64 bits resource fixup one. > > > > I'm starting my 2.6.25 branch today. I'll probably throw these in > > there after I've tested a bit, since I need them to make further > > progress with 4xx anyway. > > Yes, it would be great to have an "official" repo with all the new 4xx stuff > (PCI, EMAC...) stuff. It would be good, but not in the form of a for-2.6.25 because some of the patches aren't yet dry enough, more like something paulus could pull into powerpc.git... Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/8] ibm_newemac: Fix possible lockup on close
On Wed, 2007-11-21 at 16:41 +0100, Christoph Hellwig wrote: > On Wed, Nov 21, 2007 at 05:06:39PM +1100, Benjamin Herrenschmidt wrote: > > It's a bad idea to call flush_scheduled_work from within a > > netdev->stop because the linkwatch will occasionally take the > > rtnl lock from a workqueue context, and thus that can deadlock. > > > > This reworks things a bit in that area to avoid the problem. > > So from the name of the driver you want to keep the previous emac > driver around. Is there a good reason for that? Until arch/ppc is gone... the previous driver works with arch/ppc the new one with arch/powerpc. If we kill arch/ppc in .25, then we'll remove the old driver and rename the new one. If not, that will wait til .26 I'm hard at work porting as much of 4xx over I can to get to the point where we -can- kill arch/ppc but I'm not done yet. Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC/PATCH 5/14] powerpc: Fix 440/440A machine check handling
On Wed, 2007-11-21 at 13:51 -0600, Josh Boyer wrote: > > Hrm... it's per processor, not per board. I didn't feel like digging > > which board uses which processor and go fixup all the ppc_md's > > Sounds like something a generic function could probe for from the DTS. > I'll look at doing something here when I start making 44x > multiplatform > (soon). Well... we already probe the CPU type from cputable. So if there was a place to put that, it would be the cputable. Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] [POWERPC] Emulate isel (Integer Select) instruction
Geert Uytterhoeven writes:
> +#define WARN_EMULATE(type) \
> + do {\
> + static unsigned int count; \
> + if (count++ < 10) \
> + pr_warning("%s used emulated %s instruction\n", \
> +current->comm, type);\
Thinking about this a bit more, if an instruction gets emulated 10
times then I don't care, since it's probably only cost me 10
microseconds or so. If it gets emulated a million times then I might
want to look at it. So in fact this approach doesn't give me the
information I need to know whether there is a real problem or not.
Paul.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] [POWERPC] Emulate isel (Integer Select) instruction
Geert Uytterhoeven writes:
> @@ -721,31 +729,38 @@ static int emulate_instruction(struct pt
>
> /* Emulate the mfspr rD, PVR. */
> if ((instword & INST_MFSPR_PVR_MASK) == INST_MFSPR_PVR) {
> + WARN_EMULATE("mfpvr");
mfpvr is a bit different from the others in that it is actually a
privileged instruction, so I don't think it helps to warn about it.
Also, I think the warnings should be optional.
Paul.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] [POWERPC] Emulate isel (Integer Select) instruction
Geert Uytterhoeven writes: > Question: do we want it for emulate_single_step(), too? No, because that's not emulating an instruction. Paul. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] [POWERPC] Emulate isel (Integer Select) instruction
Paul Mackerras wrote:
> Geert Uytterhoeven writes:
>
>> +#define WARN_EMULATE(type) \
>> +do {\
>> +static unsigned int count; \
>> +if (count++ < 10) \
>> +pr_warning("%s used emulated %s instruction\n", \
>> + current->comm, type);\
>
> Thinking about this a bit more, if an instruction gets emulated 10
> times then I don't care, since it's probably only cost me 10
> microseconds or so. If it gets emulated a million times then I might
> want to look at it. So in fact this approach doesn't give me the
> information I need to know whether there is a real problem or not.
Maybe print the first time, then when it's happened 10 times, then 100,
then 1000, etc.
-Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
pseries (power3) boot hang (pageblock_nr_pages==0)
Hi Folks,
I've been seeing a boot hang/crash on power3 systems for a few weeks.
(hangs on a 270, drops to SP on a p610). This afternoon I got around
to tracking it down to the changes in
commit d9c2340052278d8eb2ffb16b0484f8f794def4de
Do not depend on MAX_ORDER when grouping pages by mobility
cpu 0x0: Vector: 100 (System Reset) at [c0006e803ae0]
pc: c009bf50: .setup_per_zone_pages_min+0x298/0x34c
lr: c009be38: .setup_per_zone_pages_min+0x180/0x34c
[c0006e803e20] c05e3898 .init_per_zone_pages_min+0x80/0xa0
[c0006e803ea0] c05c9c04 .kernel_init+0x214/0x3d8
[c0006e803f90] c0026cac .kernel_thread+0x4c/0x68
I narrowed it down to the for loop within setup_zone_migrate_reserve(),
called by setup_per_zone_pages_min(). The loop spins forever due to
pageblock_nr_pages being 0.
I imagine this would be properly fixed with something similar to the
change for iSeries. Depending on how obvious, quick and easy it is for
the experts to come up with a proper fix, I'll be able to do additional
debug and hacking after turkey-day. :-)
For the moment, I've hacked it with the following patch. (tested on
both the 270 and the p610):
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -2454,6 +2454,9 @@ static void setup_zone_migrate_reserve(struct zone
*zone)
reserve = roundup(zone->pages_min, pageblock_nr_pages) >>
pageblock_order;
+/* this is a cheap and dirty bailout, probally not a proper fix. */
+ if (pageblock_nr_pages==0) return;
+
for (pfn = start_pfn; pfn < end_pfn; pfn += pageblock_nr_pages)
{
if (!pfn_valid(pfn))
continue;
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] [POWERPC] Emulate isel (Integer Select) instruction
On Wed, 21 Nov 2007 15:41:00 -0600
Scott Wood <[EMAIL PROTECTED]> wrote:
> Paul Mackerras wrote:
> > Geert Uytterhoeven writes:
> >
> >> +#define WARN_EMULATE(type)
> >> \
> >> + do {\
> >> + static unsigned int count; \
> >> + if (count++ < 10) \
> >> + pr_warning("%s used emulated %s instruction\n", \
> >> + current->comm, type);\
> >
> > Thinking about this a bit more, if an instruction gets emulated 10
> > times then I don't care, since it's probably only cost me 10
> > microseconds or so. If it gets emulated a million times then I might
> > want to look at it. So in fact this approach doesn't give me the
> > information I need to know whether there is a real problem or not.
>
> Maybe print the first time, then when it's happened 10 times, then 100,
> then 1000, etc.
>
or just use printk_ratelimit().
Kim
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH/RFC 0/6]: phyp dump: hypervisor-assisted dump
The following series of patches implement a basic framework for hypervisor-assisted dump. The very first patch provides documentation explaining what this is :-). Yes, its supposed to be an improvement over kdump. The patches mostly sort-of work; a list of open issues is inculded in the documentation. It also appears that the not-yet-released firmware versions this was tested on are still, ahem, incomplete; this work is also pending. -- Linas & Manish ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: pseries (power3) boot hang (pageblock_nr_pages==0)
On (21/11/07 15:55), Will Schmidt didst pronounce: > Hi Folks, > > I've been seeing a boot hang/crash on power3 systems for a few weeks. > (hangs on a 270, drops to SP on a p610). This afternoon I got around > to tracking it down to the changes in > > commit d9c2340052278d8eb2ffb16b0484f8f794def4de > Do not depend on MAX_ORDER when grouping pages by mobility > > cpu 0x0: Vector: 100 (System Reset) at [c0006e803ae0] > pc: c009bf50: .setup_per_zone_pages_min+0x298/0x34c > lr: c009be38: .setup_per_zone_pages_min+0x180/0x34c > [c0006e803e20] c05e3898 .init_per_zone_pages_min+0x80/0xa0 > [c0006e803ea0] c05c9c04 .kernel_init+0x214/0x3d8 > [c0006e803f90] c0026cac .kernel_thread+0x4c/0x68 > > I narrowed it down to the for loop within setup_zone_migrate_reserve(), > called by setup_per_zone_pages_min(). The loop spins forever due to > pageblock_nr_pages being 0. > > I imagine this would be properly fixed with something similar to the > change for iSeries. Have you tried with the patch that fixed the iSeries boot problem? Thanks for tracking down the problem to such a specific place. Here it the iSeries fix in case it applies to this as well. == Ordinarily, the size of a pageblock is determined at compile-time based on the hugepage size. On PPC64, the hugepage size is determined at runtime based on what is supported by the machine. On legacy machines such as iSeries which do not support hugepages, HPAGE_SHIFT is 0. This results in pageblock_order being set to -PAGE_SHIFT and a crash results shortly afterwards. This patch checks that HPAGE_SHIFT is a sensible value before using the hugepage size. If it is 0, MAX_ORDER-1 is used instead as this is a sensible value of pageblock_order. This is a fix for 2.6.24. Credit goes to Stephen Rothwell for identifying the bug and testing on iSeries. Additional credit goes to David Gibson for testing with the libhugetlbfs test suite. Signed-off-by: Mel Gorman <[EMAIL PROTECTED]> --- arch/powerpc/Kconfig |5 + mm/page_alloc.c | 11 ++- 2 files changed, 15 insertions(+), 1 deletion(-) diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig index 18f397c..232c298 100644 --- a/arch/powerpc/Kconfig +++ b/arch/powerpc/Kconfig @@ -187,6 +187,11 @@ config FORCE_MAX_ZONEORDER default "9" if PPC_64K_PAGES default "13" +config HUGETLB_PAGE_SIZE_VARIABLE + bool + depends on HUGETLB_PAGE + default y + config MATH_EMULATION bool "Math emulation" depends on 4xx || 8xx || E200 || PPC_MPC832x || E500 diff --git a/mm/page_alloc.c b/mm/page_alloc.c index da69d83..14e0ac3 100644 --- a/mm/page_alloc.c +++ b/mm/page_alloc.c @@ -3386,7 +3386,16 @@ static void __meminit free_area_init_core(struct pglist_data *pgdat, if (!size) continue; - set_pageblock_order(HUGETLB_PAGE_ORDER); + /* +* If HPAGE_SHIFT is a sensible value, base the size of a +* pageblock on the hugepage size. Otherwise MAX_ORDER-1 +* is a sensible choice +*/ + if (HPAGE_SHIFT > PAGE_SHIFT) + set_pageblock_order(HUGETLB_PAGE_ORDER); + else + set_pageblock_order(MAX_ORDER-1); + setup_usemap(pgdat, zone, size); ret = init_currently_empty_zone(zone, zone_start_pfn, size, MEMMAP_EARLY); -- -- Mel Gorman Part-time Phd Student Linux Technology Center University of Limerick IBM Dublin Software Lab ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH/RFC 1/6]: phyp dump: Documentation
Basic documentation for hypervisor-assisted dump. Signed-off-by: Linas Vepstas <[EMAIL PROTECTED]> Documentation/powerpc/phyp-assisted-dump.txt | 126 +++ 1 file changed, 126 insertions(+) Index: linux-2.6.24-rc3-git1/Documentation/powerpc/phyp-assisted-dump.txt === --- /dev/null 1970-01-01 00:00:00.0 + +++ linux-2.6.24-rc3-git1/Documentation/powerpc/phyp-assisted-dump.txt 2007-11-21 16:26:44.0 -0600 @@ -0,0 +1,126 @@ + + Hypervisor-Assisted Dump + + November 2007 + +The goal of hypervisor-assisted dump is to enable the dump of +a crashed system, and to do so from a fully-reset system, and +to minimize the total elapsed time until the system is back +in production use. + +As compared to kdump or other strategies, hypervisor-assisted +dump offers several strong, practical advantages: + +-- Unlike kdump, the system has been reset, and loaded + with a fresh copy of the kernel. In particular, + PCI and I/O devices have been reinitialized and are + in a clean, consistent state. +-- As the dump is performed, the dumped memory becomes + immediately available to the system for normal use. +-- After the dump is completed, no further reboots are + required; the system will be fully usable, and running + in it's normal, production mode on it normal kernel. + +The above can only be accomplished by coordination with, +and assistance from the hypervisor. The procedure is +as follows: + +-- When a system crashes, the hypervisor will save + the low 256MB of RAM to a previously registered + save region. It will also save system state, system + registers, and hardware PTE's. + +-- After the low 256MB area has been saved, the + hypervisor will reset PCI and other hardware state. + It will *not* clear RAM. It will then launch the + bootloader, as normal. + +-- The freshly booted kernel will notice that there + is a new node (ibm,dump-kernel) in the device tree, + indicating that there is crash data available from + a previous boot. It will boot into only 256MB of RAM, + reserving the rest of system memory. + +-- Userspace tools will read /proc/kcore to obtain the + contents of memory, which holds the previous crashed + kernel. The userspace tools may copy this info to + disk, or network, nas, san, iscsi, etc. as desired. + +-- As the userspace tools complete saving a portion of + dump, they echo an offset and size to + /sys/kernel/release_region to release the reserved + memory back to general use. + + An example of this is: + "echo 0x4000 0x1000 > /sys/kernel/release_region" + which will release 256MB at the 1GB boundary. + +Please note that the hypervisor-assisted dump feature +is only available on Power6-based systems with recent +firmware versions. + +Implementation details: +-- +In order for this scheme to work, memory needs to be reserved +quite early in the boot cycle. However, access to the device +tree this early in the boot cycle is difficult, and device-tree +access is needed to determine if there is a crash data waiting. +To work around this problem, all but 256MB of RAM is reserved +during early boot. A short while later in boot, a check is made +to determine if there is dump data waiting. If there isn't, +then the reserved memory is released to general kernel use. +If there is dump data, then the /sys/kernel/release_region +file is created, and the reserved memory is held. + +If there is no waiting dump data, then all but 256MB of the +reserved ram will be released for general kernel use. The +highest 256 MB of RAM will *not* be released: this region +will be kept permanently reserved, so that it can act as +a receptacle for a copy of the low 256MB in the case a crash +does occur. See, however, "open issues" below, as to whether +such a reserved region is really needed. + +General notes: +-- +Security: please note that there are potential security issues +with any sort of dump mechanism. In particular, plaintext +(unencrypted) data, and possibly passwords, may be present in +the dump data. Userspace tools must take adequate precautions to +preserve security. + +Open issues: + + o User-space dump tool integration is completely unresolved. + + o The various code paths that tell the hypervisor that a crash + occurred, vs. it simply being a normal reboot, should be + reviewed, and possibly clarified/fixed. + + o The real-virtual mapping is awkward and unaddressed. There + is currently no clear way of matching up the contents of + /proc/kcore to the values that need to be sent to + /sys/kernel/release_region + + o Instead of using /sys/kernel, should there be a /sys/dump + instead? There is a dump_subsys being created by the s390 code, + perhaps the pseries code should use a similar layout as well.
[PATCH/RFC 2/6]: phyp dump: config file
Add hypervisor-assisted dump to kernel config Signed-off-by: Linas Vepstas <[EMAIL PROTECTED]> - 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.0 -0600 +++ linux-2.6.24-rc2-git4/arch/powerpc/Kconfig 2007-11-15 14:27:33.0 -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 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH/RFC 3/6]: phyp dump: reserve-release proof-of-concept
Initial rough-in/proof of concept of reserving memory in
early boot, and freeing it later. If the previous boot
had ended with a crash, the reserved memory would contain
a copy of the crashed kernel data.
Signed-off-by: Manish Ahuja <[EMAIL PROTECTED]>
Signed-off-by: Linas Vepstas <[EMAIL PROTECTED]>
arch/powerpc/kernel/prom.c | 33 +
arch/powerpc/platforms/pseries/Makefile|1
arch/powerpc/platforms/pseries/phyp_dump.c | 71 +
include/asm-powerpc/phyp_dump.h| 32 +
4 files changed, 137 insertions(+)
Index: linux-2.6.24-rc2-git4/include/asm-powerpc/phyp_dump.h
===
--- /dev/null 1970-01-01 00:00:00.0 +
+++ linux-2.6.24-rc2-git4/include/asm-powerpc/phyp_dump.h 2007-11-19
17:44:21.0 -0600
@@ -0,0 +1,32 @@
+/*
+ * Hypervisor-assisted dump
+ *
+ * Linas Vepstas, Manish Ahuja 2007
+ * 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
+ * as published by the Free Software Foundation; either version
+ * 2 of the License, or (at your option) any later version.
+ */
+
+#ifndef _PPC64_PHYP_DUMP_H
+#define _PPC64_PHYP_DUMP_H
+
+#ifdef CONFIG_PHYP_DUMP
+
+/* The RMR region will be saved for later dumping
+ * whenever the kernel crashes. Set this to 256MB. */
+#define PHYP_DUMP_RMR_START 0x0
+#define PHYP_DUMP_RMR_END (1UL<<28)
+
+struct phyp_dump {
+ /* Memory that is reserved during very early boot. */
+ unsigned long init_reserve_start;
+ unsigned long init_reserve_size;
+};
+
+extern struct phyp_dump *phyp_dump_info;
+
+#endif /* CONFIG_PHYP_DUMP */
+#endif /* _PPC64_PHYP_DUMP_H */
Index: linux-2.6.24-rc2-git4/arch/powerpc/platforms/pseries/phyp_dump.c
===
--- /dev/null 1970-01-01 00:00:00.0 +
+++ linux-2.6.24-rc2-git4/arch/powerpc/platforms/pseries/phyp_dump.c
2007-11-19 19:07:49.0 -0600
@@ -0,0 +1,71 @@
+/*
+ * Hypervisor-assisted dump
+ *
+ * Linas Vepstas, Manish Ahuja 2007
+ * Copyrhgit (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
+ * as published by the Free Software Foundation; either version
+ * 2 of the License, or (at your option) any later version.
+ *
+ */
+
+#include
+#include
+#include
+#include
+
+#include
+#include
+
+/* Global, used to communicate data between early boot and late boot */
+static struct phyp_dump phyp_dump_global;
+struct phyp_dump *phyp_dump_info = &phyp_dump_global;
+
+/**
+ * release_memory_range -- release memory previously lmb_reserved
+ * @start_pfn: starting physical frame number
+ * @nr_pages: number of pages to free.
+ *
+ * This routine will release memory that had been previously
+ * 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)
+{
+ struct page *rpage;
+ unsigned long end_pfn;
+ long i;
+
+ end_pfn = start_pfn + nr_pages;
+
+ for (i=start_pfn; i <= end_pfn; i++) {
+ rpage = pfn_to_page(i);
+ if (PageReserved(rpage)) {
+ ClearPageReserved(rpage);
+ init_page_count(rpage);
+ __free_page(rpage);
+ totalram_pages++;
+ }
+ }
+}
+
+static int __init phyp_dump_setup(void)
+{
+ unsigned long start_pfn, nr_pages;
+
+ /* If no memory was reserved in early boot, there is nothing to do */
+ if (phyp_dump_info->init_reserve_size == 0)
+ return 0;
+
+ /* Release memory that was reserved in early boot */
+ start_pfn = PFN_DOWN(phyp_dump_info->init_reserve_start);
+ nr_pages = PFN_DOWN(phyp_dump_info->init_reserve_size);
+ release_memory_range(start_pfn, nr_pages);
+
+ return 0;
+}
+
+subsys_initcall(phyp_dump_setup);
Index: linux-2.6.24-rc2-git4/arch/powerpc/platforms/pseries/Makefile
===
--- linux-2.6.24-rc2-git4.orig/arch/powerpc/platforms/pseries/Makefile
2007-11-19 17:43:52.0 -0600
+++ linux-2.6.24-rc2-git4/arch/powerpc/platforms/pseries/Makefile
2007-11-19 17:44:21.0 -0600
@@ -18,3 +18,4 @@ obj-$(CONFIG_HOTPLUG_CPU) += hotplug-cpu
obj-$(CONFIG_HVC_CONSOLE) += hvconsole.o
obj-$(CONFIG_HVCS) += hvcserver.o
obj-$(CONFIG_HCALL_STATS) += hvCall_inst.o
+obj-$(CONFIG_PHYP_DUMP)+= phyp_dump.o
Index: linux-2.6.24-rc2-git4/arch/powerpc/kernel/prom.c
===
--- linux-2.6.24-rc2-git4.orig/arch/po
[PATCH/RFC 4/6]: phyp dump: use sysfs to release reserved mem
Check to see if there actually is data from a previously
crashed kernel waiting. If so, Allow user-sapce tools to
grab the data (by reading /proc/kcore). When user-space
finishes dumping a section, it must release that memory
by writing to sysfs. For example,
echo "0x4000 0x1000" > /sys/kernel/release_region
will release 256MB starting at the 1GB. The released memory
becomes free for general use.
Signed-off-by: Linas Vepstas <[EMAIL PROTECTED]>
Signed-off-by: Manish Ahuja <[EMAIL PROTECTED]>
--
arch/powerpc/platforms/pseries/phyp_dump.c | 101 +++--
1 file changed, 96 insertions(+), 5 deletions(-)
Index: linux-2.6.24-rc3-git1/arch/powerpc/platforms/pseries/phyp_dump.c
===
--- linux-2.6.24-rc3-git1.orig/arch/powerpc/platforms/pseries/phyp_dump.c
2007-11-21 13:15:05.0 -0600
+++ linux-2.6.24-rc3-git1/arch/powerpc/platforms/pseries/phyp_dump.c
2007-11-21 13:24:30.0 -0600
@@ -12,17 +12,24 @@
*/
#include
+#include
#include
+#include
#include
#include
+#include
#include
#include
+#include
/* Global, used to communicate data between early boot and late boot */
static struct phyp_dump phyp_dump_global;
struct phyp_dump *phyp_dump_info = &phyp_dump_global;
+static int ibm_configure_kernel_dump;
+
+/* - */
/**
* release_memory_range -- release memory previously lmb_reserved
* @start_pfn: starting physical frame number
@@ -52,18 +59,102 @@ release_memory_range(unsigned long start
}
}
-static int __init phyp_dump_setup(void)
+/* - */
+/**
+ * sysfs_release_region -- sysfs interface to release memory range.
+ *
+ * Usage:
+ * "echo > /sys/kernel/release_region"
+ *
+ * Example:
+ * "echo 0x4000 0x1000 > /sys/kernel/release_region"
+ *
+ * will release 256MB starting at 1GB.
+ */
+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;
+ ssize_t ret;
- /* If no memory was reserved in early boot, there is nothing to do */
- if (phyp_dump_info->init_reserve_size == 0)
- return 0;
+ ret = sscanf(buf, "%lx %lx", &start_addr, &length);
+ if (ret != 2)
+ return -EINVAL;
+
+ /* Range-check - don't free any reserved memory that
+* wasn't reserved for phyp-dump */
+ if (start_addr < phyp_dump_info->init_reserve_start)
+ start_addr = phyp_dump_info->init_reserve_start;
+
+ end_addr = phyp_dump_info->init_reserve_start +
+ phyp_dump_info->init_reserve_size;
+ if (start_addr+length > end_addr)
+ length = end_addr - start_addr;
+
+ /* Release the region of memory assed in by user */
+ start_pfn = PFN_DOWN(start_addr);
+ nr_pages = PFN_DOWN(length);
+ release_memory_range (start_pfn, nr_pages);
+
+ return count;
+}
+
+static ssize_t
+show_release_region(struct kset * kset, char *buf)
+{
+ return sprintf(buf, "ola\n");
+}
+
+static struct subsys_attribute rr = __ATTR(release_region, 0600,
+show_release_region,
+store_release_region);
+
+/* - */
+
+static void release_all (void)
+{
+ unsigned long start_pfn, nr_pages;
- /* Release memory that was reserved in early boot */
+ /* Release all memory that was reserved in early boot */
start_pfn = PFN_DOWN(phyp_dump_info->init_reserve_start);
nr_pages = PFN_DOWN(phyp_dump_info->init_reserve_size);
release_memory_range(start_pfn, nr_pages);
+}
+
+static int __init phyp_dump_setup(void)
+{
+ struct device_node *rtas;
+ const int *dump_header;
+ int header_len = 0;
+ int rc;
+
+ /* If no memory was reserved in early boot, there is nothing to do */
+ if (phyp_dump_info->init_reserve_size == 0)
+ return 0;
+
+ /* Return if phyp dump not supported */
+ ibm_configure_kernel_dump = rtas_token("ibm,configure-kernel-dump");
+ if (ibm_configure_kernel_dump == RTAS_UNKNOWN_SERVICE) {
+ release_all();
+ return -ENOSYS;
+ }
+
+ /* Is there dump data waiting for us? */
+ rtas = of_find_node_by_path("/rtas");
+ dump_header = of_get_property(rtas, "ibm,kernel-dump", &header_len);
+ if (dump_header == NULL) {
+ release_all();
+ return 0;
+ }
+
+ /* Should we create a dump_subsys, analogous to s390/ipl.c ? */
+ rc = subsys_create_file(&kernel_subsys, &rr);
+ if (rc) {
+ printk (KERN_ERR "phyp-dump: unable to create sysfs file
(%d)\n", rc);
+ release_
Re: annoying prinkts during vmemmap initialization
Hi Christoph, On Wed, 21 Nov 2007 16:35:26 +0100 Christoph Hellwig <[EMAIL PROTECTED]> wrote: > > Hi Andi, > > your patch 'ppc64: SPARSEMEM_VMEMMAP support' adds the following two lines: > > + printk(KERN_WARNING "vmemmap %08lx allocated at %p, " > + "physical %p.\n", start, p, __pa(p)); > > in a loop around basically every page. That's a lot of flooding (with > the wrong printk level, btw) and really slows down booting my cell blade > a lot (these only have a very slow serial over lan console). > > Any reason to keep this? And if yes can we please make it conditional > on some kind of vmemmap_debug boot option? These have been changed to pr_debug() in 2.6.24-rc3 kernel. -- Cheers, Stephen Rothwell[EMAIL PROTECTED] http://www.canb.auug.org.au/~sfr/ pgpRV8DD2rCY6.pgp Description: PGP signature ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH/RFC 5/6]: phyp dump: register the dump area
Set up the actual dump header, register it with the hypervisor.
Signed-off-by: Manish Ahuja <[EMAIL PROTECTED]>
Signed-off-by: Linas Vepstas <[EMAIL PROTECTED]>
--
arch/powerpc/platforms/pseries/phyp_dump.c | 169 +++--
1 file changed, 163 insertions(+), 6 deletions(-)
Index: linux-2.6.24-rc3-git1/arch/powerpc/platforms/pseries/phyp_dump.c
===
--- linux-2.6.24-rc3-git1.orig/arch/powerpc/platforms/pseries/phyp_dump.c
2007-11-21 15:55:37.0 -0600
+++ linux-2.6.24-rc3-git1/arch/powerpc/platforms/pseries/phyp_dump.c
2007-11-21 16:06:52.0 -0600
@@ -30,6 +30,134 @@ struct phyp_dump *phyp_dump_info = &phyp
static int ibm_configure_kernel_dump;
/* - */
+/* RTAS interfaces to declare the dump regions */
+
+struct dump_section {
+ u32 dump_flags;
+ u16 source_type;
+ u16 error_flags;
+ u64 source_address;
+ u64 source_length;
+ u64 length_copied;
+ u64 destination_address;
+};
+
+struct phyp_dump_header {
+ u32 version;
+ u16 num_of_sections;
+ u16 status;
+
+ u32 first_offset_section;
+ u32 dump_disk_section;
+ u64 block_num_dd;
+ u64 num_of_blocks_dd;
+ u32 offset_dd;
+ u32 maxtime_to_auto;
+ /* No dump disk path string used */
+
+ struct dump_section cpu_data;
+ struct dump_section hpte_data;
+ struct dump_section kernel_data;
+};
+
+/* The dump header *must be* in low memory, so .bss it */
+static struct phyp_dump_header phdr;
+
+#define NUM_DUMP_SECTIONS 3
+#define DUMP_HEADER_VERSION 0x1
+#define DUMP_REQUEST_FLAG 0x1
+#define DUMP_SOURCE_CPU 0x0001
+#define DUMP_SOURCE_HPTE 0x0002
+#define DUMP_SOURCE_RMO 0x0011
+
+/**
+ * init_dump_header() - initialize the header declaring a dump
+ * Returns: length of dump save area.
+ *
+ * When the hypervisor saves crashed state, it needs to put
+ * it somewhere. The dump header tells the hypervisor where
+ * the data can be saved.
+ */
+static unsigned long init_dump_header(struct phyp_dump_header *ph)
+{
+ struct device_node *rtas;
+ const unsigned int *sizes;
+ int len;
+ unsigned long cpu_state_size = 0;
+ unsigned long hpte_region_size = 0;
+ unsigned long addr_offset = 0;
+
+ /* Get the required dump region sizes */
+ rtas = of_find_node_by_path("/rtas");
+ sizes = of_get_property(rtas, "ibm,configure-kernel-dump-sizes", &len);
+ if (!sizes || len < 20)
+ return 0;
+
+ if (sizes[0] == 1)
+ cpu_state_size = *((unsigned long *) &sizes[1]);
+
+ if (sizes[3] == 2)
+ hpte_region_size = *((unsigned long *) &sizes[4]);
+
+ /* Set up the dump header */
+ ph->version = DUMP_HEADER_VERSION;
+ ph->num_of_sections = NUM_DUMP_SECTIONS;
+ ph->status = 0;
+
+ ph->first_offset_section =
+ (u32) &(((struct phyp_dump_header *) 0)->cpu_data);
+ ph->dump_disk_section = 0;
+ ph->block_num_dd = 0;
+ ph->num_of_blocks_dd = 0;
+ ph->offset_dd = 0;
+
+ ph->maxtime_to_auto = 0; /* disabled */
+
+ /* The first two sections are mandatory */
+ ph->cpu_data.dump_flags = DUMP_REQUEST_FLAG;
+ ph->cpu_data.source_type = DUMP_SOURCE_CPU;
+ ph->cpu_data.source_address = 0;
+ ph->cpu_data.source_length = cpu_state_size;
+ ph->cpu_data.destination_address = addr_offset;
+ addr_offset += cpu_state_size;
+
+ ph->hpte_data.dump_flags = DUMP_REQUEST_FLAG;
+ ph->hpte_data.source_type = DUMP_SOURCE_HPTE;
+ ph->hpte_data.source_address = 0;
+ ph->hpte_data.source_length = hpte_region_size;
+ ph->hpte_data.destination_address = addr_offset;
+ addr_offset += hpte_region_size;
+
+ /* This section describes the low kernel region */
+ ph->kernel_data.dump_flags = DUMP_REQUEST_FLAG;
+ ph->kernel_data.source_type = DUMP_SOURCE_RMO;
+ ph->kernel_data.source_address = PHYP_DUMP_RMR_START;
+ ph->kernel_data.source_length = PHYP_DUMP_RMR_END;
+ ph->kernel_data.destination_address = addr_offset;
+ addr_offset += ph->kernel_data.source_length;
+
+ return addr_offset;
+}
+
+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;
+
+ do {
+ rc = rtas_call(ibm_configure_kernel_dump, 3, 1, NULL,
+ 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);
+ }
+}
+
+/* - */
/**
* release_memory
[PATCH/RFC 6/6]: phyp dump: debugging print routines.
Provide some basic debugging support.
Signed-off-by: Manish Ahuja <[EMAIL PROTECTED]>
Signed-off-by: Linas Vepsts <[EMAIL PROTECTED]>
-
arch/powerpc/platforms/pseries/phyp_dump.c | 51 +
1 file changed, 51 insertions(+)
Index: linux-2.6.24-rc3-git1/arch/powerpc/platforms/pseries/phyp_dump.c
===
--- linux-2.6.24-rc3-git1.orig/arch/powerpc/platforms/pseries/phyp_dump.c
2007-11-21 16:12:21.0 -0600
+++ linux-2.6.24-rc3-git1/arch/powerpc/platforms/pseries/phyp_dump.c
2007-11-21 16:12:46.0 -0600
@@ -139,6 +139,51 @@ static unsigned long init_dump_header(st
return addr_offset;
}
+#ifdef DEBUG
+static void print_dump_header(const struct phyp_dump_header *ph)
+{
+ 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;
@@ -154,6 +199,9 @@ static void register_dump_area(struct ph
if (rc)
{
printk (KERN_ERR "phyp-dump: unexpected error (%d) on
register\n", rc);
+#ifdef DEBUG
+ print_dump_header (ph);
+#endif
}
}
@@ -292,6 +340,9 @@ static int __init phyp_dump_setup(void)
register_dump_area (&phdr, dump_area_start);
goto release_mem;
}
+#ifdef DEBUG
+ print_dump_header (dump_header);
+#endif
/* Don't allow user to release the 256MB scratch area */
phyp_dump_info->init_reserve_size = free_area_length;
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: annoying prinkts during vmemmap initialization
On Thu, Nov 22, 2007 at 09:41:45AM +1100, Stephen Rothwell wrote: > > Any reason to keep this? And if yes can we please make it conditional > > on some kind of vmemmap_debug boot option? > > These have been changed to pr_debug() in 2.6.24-rc3 kernel. Ah, sorry for not checking. Looks like the spufs tree lags a little behind. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: 2.6.24-rc3-mm1- powerpc link failure
On Wed, 21 Nov 2007 13:36:30 +0530 Kamalesh Babulal <[EMAIL PROTECTED]> wrote: > > The kernel build fails on powerpc while linking, Only for allyesconfig (or maybe some other config that builds a lot of stuff in. > AS .tmp_kallsyms3.o > LD vmlinux.o > ld: TOC section size exceeds 64k > make: *** [vmlinux.o] Error 1 > > The patch posted at http://lkml.org/lkml/2007/11/13/414, solves this > failure. However, that patch needs more testing especially to figure out what performance effects it has. i.e. not for merging, yet. -- Cheers, Stephen Rothwell[EMAIL PROTECTED] http://www.canb.auug.org.au/~sfr/ pgpJfg6lsFgkM.pgp Description: PGP signature ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] PPC: fix missed increment on device interface counter
From: Cyrill Gorcunov <[EMAIL PROTECTED]>
This patch adds simple increment on device interface counter
(it seems to be accidently missed)
Signed-off-by: Cyrill Gorcunov <[EMAIL PROTECTED]>
---
arch/powerpc/platforms/pasemi/electra_ide.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/platforms/pasemi/electra_ide.c
b/arch/powerpc/platforms/pasemi/electra_ide.c
index 12fb0c9..8e73086 100644
--- a/arch/powerpc/platforms/pasemi/electra_ide.c
+++ b/arch/powerpc/platforms/pasemi/electra_ide.c
@@ -42,7 +42,7 @@ static int __devinit electra_ide_init(void)
np = of_find_compatible_node(NULL, "ide", "electra-ide");
i = 0;
- while (np && i < MAX_IFS) {
+ while (np && i++ < MAX_IFS) {
memset(r, 0, sizeof(r));
/* pata_platform wants two address ranges: one for the base
registers,
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[RFC] PPC: convert for(...) cycles into for_each... form
From: Cyrill Gorcunov <[EMAIL PROTECTED]>
This patch does convert cyclic calls to of_find_compatible_node()
and of_find_node_by_type() into appropriate macroses. It does reduce
code a bit.
Signed-off-by: Cyrill Gorcunov <[EMAIL PROTECTED]>
---
WARNING: I've no PowerPC to test it - please reiew the patch
closely. Thanks.
arch/powerpc/kernel/legacy_serial.c |8
arch/powerpc/platforms/82xx/pq2.c |4 ++--
arch/powerpc/platforms/celleb/scc_sio.c |5 ++---
arch/powerpc/platforms/powermac/low_i2c.c |3 +--
arch/powerpc/sysdev/mv64x60_pci.c |4 ++--
arch/powerpc/sysdev/mv64x60_udbg.c|4 ++--
arch/powerpc/sysdev/uic.c | 17 +
7 files changed, 18 insertions(+), 27 deletions(-)
diff --git a/arch/powerpc/kernel/legacy_serial.c
b/arch/powerpc/kernel/legacy_serial.c
index 4ed5887..b5dc646 100644
--- a/arch/powerpc/kernel/legacy_serial.c
+++ b/arch/powerpc/kernel/legacy_serial.c
@@ -307,7 +307,7 @@ void __init find_legacy_serial_ports(void)
}
/* First fill our array with SOC ports */
- for (np = NULL; (np = of_find_compatible_node(np, "serial", "ns16550"))
!= NULL;) {
+ for_each_compatible_node(np, "serial", "ns16550") {
struct device_node *soc = of_get_parent(np);
if (soc && !strcmp(soc->type, "soc")) {
index = add_legacy_soc_port(np, np);
@@ -318,7 +318,7 @@ void __init find_legacy_serial_ports(void)
}
/* First fill our array with ISA ports */
- for (np = NULL; (np = of_find_node_by_type(np, "serial"));) {
+ for_each_node_by_type(np, "serial") {
struct device_node *isa = of_get_parent(np);
if (isa && !strcmp(isa->name, "isa")) {
index = add_legacy_isa_port(np, isa);
@@ -329,7 +329,7 @@ void __init find_legacy_serial_ports(void)
}
/* First fill our array with tsi-bridge ports */
- for (np = NULL; (np = of_find_compatible_node(np, "serial", "ns16550"))
!= NULL;) {
+ for_each_compatible_node(np, "serial", "ns16550") {
struct device_node *tsi = of_get_parent(np);
if (tsi && !strcmp(tsi->type, "tsi-bridge")) {
index = add_legacy_soc_port(np, np);
@@ -340,7 +340,7 @@ void __init find_legacy_serial_ports(void)
}
/* First fill our array with opb bus ports */
- for (np = NULL; (np = of_find_compatible_node(np, "serial", "ns16550"))
!= NULL;) {
+ for_each_compatible_node(np, "serial", "ns16550") {
struct device_node *opb = of_get_parent(np);
if (opb && (!strcmp(opb->type, "opb") ||
of_device_is_compatible(opb, "ibm,opb"))) {
diff --git a/arch/powerpc/platforms/82xx/pq2.c
b/arch/powerpc/platforms/82xx/pq2.c
index a497cba..9e74393 100644
--- a/arch/powerpc/platforms/82xx/pq2.c
+++ b/arch/powerpc/platforms/82xx/pq2.c
@@ -72,11 +72,11 @@ err:
void __init pq2_init_pci(void)
{
- struct device_node *np = NULL;
+ struct device_node *np;
ppc_md.pci_exclude_device = pq2_pci_exclude_device;
- while ((np = of_find_compatible_node(np, NULL, "fsl,pq2-pci")))
+ for_each_compatible_node(np, NULL, "fsl,pq2-pci")
pq2_pci_add_bridge(np);
}
#endif
diff --git a/arch/powerpc/platforms/celleb/scc_sio.c
b/arch/powerpc/platforms/celleb/scc_sio.c
index 6100082..5e43bac 100644
--- a/arch/powerpc/platforms/celleb/scc_sio.c
+++ b/arch/powerpc/platforms/celleb/scc_sio.c
@@ -42,14 +42,13 @@ static struct {
static int __init txx9_serial_init(void)
{
extern int early_serial_txx9_setup(struct uart_port *port);
- struct device_node *node = NULL;
+ struct device_node *node;
int i;
struct uart_port req;
struct of_irq irq;
struct resource res;
- while ((node = of_find_compatible_node(node,
- "serial", "toshiba,sio-scc")) != NULL) {
+ for_each_compatible_node(node, "serial", "toshiba,sio-scc") {
for (i = 0; i < ARRAY_SIZE(txx9_scc_tab); i++) {
if (!(txx9_serial_bitmap & (1irqhost);
of_node_put(np);
/* The scan again for cascaded UICs */
- np = of_find_compatible_node(NULL, NULL, "ibm,uic");
- while (np) {
+ for_each_compatible_node(np, NULL, "ibm,uic") {
interrupts = of_get_property(np, "interrupts", NULL);
if (interrupts) {
/* Secondary UIC */
@@ -355,7 +350,7 @@ void __init uic_init_tree(void)
int ret;
uic = uic_init_one(np);
- if (! uic)
+ if (!uic)
panic("Unable to initialize a secondary UIC
%s\n",
np->full_name);
oops trying to execute sh
I'm trying to boot linux 2.6.22.9 on an mpc860c rev d4.
When init trys to spawn sh, during the exec, the kernel oopses as seen
below:
## Starting application at 0x0040 ...
loaded at: 0040 004EF15C
board data at: 03F9FBC0 03F9FBFC
relocated to: 00404044 00404080
zimage at: 00404E74 004EC662
avail ram: 004F 0400
Linux/PPC load: console=ttyCPM,38400
Uncompressing Linux...done.
Now booting the kernel
Linux version 2.6.22.9 ([EMAIL PROTECTED]) (gcc version 4.2.1) #113 Wed Nov 21
10:49:36 PST 2007
Zone PFN ranges:
DMA 0 ->16384
Normal 16384 ->16384
early_node_map[1] active PFN ranges
0:0 ->16384
Built 1 zonelists. Total pages: 16256
Kernel command line: console=ttyCPM,38400
PID hash table entries: 256 (order: 8, 1024 bytes)
Decrementer Frequency = 18375/60
Console: colour dummy device 80x25
cpm_uart: console: compat mode
Dentry cache hash table entries: 8192 (order: 3, 32768 bytes)
Inode-cache hash table entries: 4096 (order: 2, 16384 bytes)
Memory: 63244k available (880k kernel code, 268k data, 444k init, 0k highmem)
Mount-cache hash table entries: 512
ADDSI: Init
io scheduler noop registered (default)
Serial: CPM driver $Revision: 0.02 $
ttyCPM0 at MMIO 0xc5000a80 (irq = 20) is a CPM UART
mice: PS/2 mouse device common for all mice
Freeing unused kernel memory: 444k init
init started: BusyBox v1.8.0 (2007-11-16 14:24:51 PST)
starting pid 103, tty '': '/bin/sh'
Oops: kernel access of bad area, sig: 11 [#1]
NIP: c0044ed0 LR: c0044ff0 CTR: 0001
REGS: c3c0bd00 TRAP: 0300 Not tainted (2.6.22.9)
MSR: 9032 CR: 30099099 XER: a0008c7f
DAR: ff80103f, DSISR: c000
TASK = c0288070[103] 'init' THREAD: c3c0a000
GPR00: c0044ff0 c3c0bdb0 c0288070 ff800fff 7faf8000
GPR08: c01a8f58 c017d91c 0002 c0179cd0 30099093 1007687c 0002 c00f8744
GPR16: c00f0a64 c011d1ac c00f0aa4 c00f0a90 c012 0001 0003
GPR24: c3c1ce00 c018 c0247550 c3c0bdc8 c0179cd0 ff800fff
NIP [c0044ed0] remove_vma+0x14/0x70
LR [c0044ff0] exit_mmap+0xc4/0xf0
Call Trace:
[c3c0bdb0] [c3c0bdc8] 0xc3c0bdc8 (unreliable)
[c3c0bdc0] [c0044ff0] exit_mmap+0xc4/0xf0
[c3c0bdf0] [c000f74c] mmput+0x50/0xd4
[c3c0be00] [c00591f4] flush_old_exec+0x3b8/0x7a8
[c3c0be50] [c0086cc0] load_elf_binary+0x2e8/0x1454
[c3c0bee0] [c005892c] search_binary_handler+0x58/0x12c
[c3c0bf00] [c0059d64] do_execve+0x13c/0x1f0
[c3c0bf20] [c00089b4] sys_execve+0x50/0x90
[c3c0bf40] [c0002a40] ret_from_syscall+0x0/0x38
Instruction dump:
7d808120 38210040 4e800020 83c3 4b18 38a0 4b9c 7c0802a6
9421fff0 bfc10008 90010014 7c7f1b78 <81230040> 83c3000c 2f89 419e0018
The interesting thing is that r3 points to something funny. While tracing
this problem down, I replaced the remove_vma function with the following:
/*
* Close a vm structure and free it, returning the next.
*/
static struct vm_area_struct * __attribute__((__noinline__))
__remove_vma(struct vm_area_struct *vma)
{
struct vm_area_struct *next = vma->vm_next;
might_sleep();
if (vma->vm_ops && vma->vm_ops->close)
vma->vm_ops->close(vma);
if (vma->vm_file)
fput(vma->vm_file);
mpol_free(vma_policy(vma));
kmem_cache_free(vm_area_cachep, vma);
return next;
}
static struct vm_area_struct *remove_vma(struct vm_area_struct *vma)
{
asm volatile (
"lis 4,-128\n"
"ori 4,4,4095\n"
"tweq 3,4\n"
"lwz 5,0(1)\n"
"tweq 3,4\n"
);
return __remove_vma( vma );
}
With this code, the kernel oopses on the *second* tweq instruction:
Kernel BUG at c0045fd4 [verbose debug info unavailable]
Oops: Exception in kernel mode, sig: 5 [#1]
NIP: c0045fd4 LR: c00460a0 CTR: 0001
REGS: c3c0bd10 TRAP: 0700 Not tainted (2.6.22.9)
MSR: 00029032 CR: 30099099 XER: a0008c7f
TASK = c0292b40[103] 'init' THREAD: c3c0a000
GPR00: 0001 c3c0bdc0 c0292b40 ff800fff ff800fff c3c0bdf0
GPR08: c0219398 c017d91c 0002 c0179cd0 30099093 1007687c 0002 c00f8744
GPR16: c00f0a64 c011d1ac c00f0aa4 c00f0a90 c012 0001 0003
GPR24: c3c32e00 c018 c0247080 c3c0bdc8 c0179cd0 c017641c
NIP [c0045fd4] remove_vma+0x10/0x18
LR [c00460a0] exit_mmap+0xc4/0xf0
Call Trace:
[c3c0bdc0] [c0046074] exit_mmap+0x98/0xf0 (unreliable)
[c3c0bdf0] [c000f74c] mmput+0x50/0xd4
[c3c0be00] [c005920c] flush_old_exec+0x3b8/0x7a8
[c3c0be50] [c0086cd8] load_elf_binary+0x2e8/0x1454
[c3c0bee0] [c0058944] search_binary_handler+0x58/0x12c
[c3c0bf00] [c0059d7c] do_execve+0x13c/0x1f0
[c3c0bf20] [c00089b4] sys_execve+0x50/0x90
[c3c0bf40] [c0002a40] ret_from_syscall+0x0/0x38
Instruction dump:
7fe4fb78 4800a0ed 80010014 7fc3f378 7c0803a6 bbc10008 38210010 4e800020
3c80ff80 60840fff 7c832008 80a1 <7c832008> 4b7c 7c0802a6 9421ffd0
The access of memory throug
Re: [PATCH 3/3] [POWERPC] Add docs for Freescale DMA & DMA channel device tree nodes
On Wed, Nov 21, 2007 at 01:27:03PM -0600, Scott Wood wrote: > Kumar Gala wrote: > > On Nov 21, 2007, at 11:35 AM, Scott Wood wrote: > >> A cell-index property would be useful here for indexing into the summary > >> status register. > > > > Divide by 0x80. > > :-P > > Using cell-index for things like this is reasonably common, and endorsed > by current ePAPR drafts. Indeed, indexing or writing into shared registers is exactly what cell-index is for. -- David Gibson| I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC/PATCH 12/14] powerpc: Add early udbg support for 40x processors
On Wed, Nov 21, 2007 at 05:16:30PM +1100, Benjamin Herrenschmidt wrote: > This adds some basic real mode based early udbg support for 40x > in order to debug things more easily Shouldn't we be able to share code with the Maple realmode udbg()? -- David Gibson| I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 12/14] powerpc: Add early udbg support for 40x processors
On 11/20/07, Benjamin Herrenschmidt <[EMAIL PROTECTED]> wrote: > This adds some basic real mode based early udbg support for 40x > in order to debug things more easily > > Signed-off-by: Benjamin Herrenschmidt <[EMAIL PROTECTED]> > --- > --- linux-work.orig/arch/powerpc/platforms/Kconfig.cputype 2007-11-21 > 12:50:16.0 +1100 > +++ linux-work/arch/powerpc/platforms/Kconfig.cputype 2007-11-21 > 12:50:18.0 +1100 > @@ -43,6 +43,7 @@ config 40x > bool "AMCC 40x" > select PPC_DCR_NATIVE > select WANT_DEVICE_TREE > + select PPC_UDBG_16550 Unfortunately, this isn't always true. The Xilinx Virtex parts us config 40x, but not all FPGA bitstreams have a 16550 serial port. Sometimes it's a uartlite instead. Cheers, g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. [EMAIL PROTECTED] (403) 399-0195 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 12/14] powerpc: Add early udbg support for 40x processors
On Wed, 2007-11-21 at 16:47 -0700, Grant Likely wrote: > On 11/20/07, Benjamin Herrenschmidt <[EMAIL PROTECTED]> wrote: > > This adds some basic real mode based early udbg support for 40x > > in order to debug things more easily > > > > Signed-off-by: Benjamin Herrenschmidt <[EMAIL PROTECTED]> > > --- > > --- linux-work.orig/arch/powerpc/platforms/Kconfig.cputype 2007-11-21 > > 12:50:16.0 +1100 > > +++ linux-work/arch/powerpc/platforms/Kconfig.cputype 2007-11-21 > > 12:50:18.0 +1100 > > @@ -43,6 +43,7 @@ config 40x > > bool "AMCC 40x" > > select PPC_DCR_NATIVE > > select WANT_DEVICE_TREE > > + select PPC_UDBG_16550 > > Unfortunately, this isn't always true. The Xilinx Virtex parts us > config 40x, but not all FPGA bitstreams have a 16550 serial port. > Sometimes it's a uartlite instead. What does uartlite looks like ? Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC/PATCH 12/14] powerpc: Add early udbg support for 40x processors
On Thu, 2007-11-22 at 09:58 +1100, David Gibson wrote: > On Wed, Nov 21, 2007 at 05:16:30PM +1100, Benjamin Herrenschmidt wrote: > > This adds some basic real mode based early udbg support for 40x > > in order to debug things more easily > > Shouldn't we be able to share code with the Maple realmode udbg()? Do you really care ? Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 12/14] powerpc: Add early udbg support for 40x processors
On 11/21/07, Benjamin Herrenschmidt <[EMAIL PROTECTED]> wrote: > > On Wed, 2007-11-21 at 16:47 -0700, Grant Likely wrote: > > On 11/20/07, Benjamin Herrenschmidt <[EMAIL PROTECTED]> wrote: > > > This adds some basic real mode based early udbg support for 40x > > > in order to debug things more easily > > > > > > Signed-off-by: Benjamin Herrenschmidt <[EMAIL PROTECTED]> > > > --- > > > --- linux-work.orig/arch/powerpc/platforms/Kconfig.cputype > > > 2007-11-21 12:50:16.0 +1100 > > > +++ linux-work/arch/powerpc/platforms/Kconfig.cputype 2007-11-21 > > > 12:50:18.0 +1100 > > > @@ -43,6 +43,7 @@ config 40x > > > bool "AMCC 40x" > > > select PPC_DCR_NATIVE > > > select WANT_DEVICE_TREE > > > + select PPC_UDBG_16550 > > > > Unfortunately, this isn't always true. The Xilinx Virtex parts us > > config 40x, but not all FPGA bitstreams have a 16550 serial port. > > Sometimes it's a uartlite instead. > > What does uartlite looks like ? fixed speed 4 registers: rx, tx, status & control rx & tx are... well... rx and tx registers status has a number of bits reporting fifos full/empty etc. control has three bits; reset tx, reset rx and interrupt enable. See the top of drivers/serial/uartlite.c Very simple stuff; but definitely not 16550. g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. [EMAIL PROTECTED] (403) 399-0195 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
dtc: Merge refs and labels into single "markers" list
Currently, every 'data' object, used to represent property values, has
two lists of fixup structures - one for labels and one for references.
Sometimes we want to look at them separately, but other times we need
to consider both types of fixup.
I'm planning to implement string references, where a full path rather
than a phandle is substituted into a property value. Adding yet
another list of fixups for that would start to get messy. So, this
patch merges the "refs" and "labels" lists into a single list of
"markers", each of which has a type field indicating if it represents
a label or a phandle reference. String references or any other new
type of in-data marker will then just need a new type value - merging
data blocks and other common manipulations will just work.
While I was at it I made some cleanups to the handling of fixups which
simplify things further.
Signed-off-by: David Gibson <[EMAIL PROTECTED]>
---
Applies after my patch with the new checking/fixup infrastructure.
checks.c | 22 +---
data.c | 101 ---
dtc-parser.y | 11 +++---
dtc.h| 24 +-
flattree.c | 11 +++---
treesource.c | 62 ++--
6 files changed, 98 insertions(+), 133 deletions(-)
Index: dtc/checks.c
===
--- dtc.orig/checks.c 2007-11-22 10:04:46.0 +1100
+++ dtc/checks.c2007-11-22 10:30:40.0 +1100
@@ -224,33 +224,29 @@
static void fixup_references(struct check *c, struct node *dt,
struct node *node, struct property *prop)
{
- struct fixup *f = prop->val.refs;
+ struct marker *m = prop->val.markers;
struct node *refnode;
cell_t phandle;
- while (f) {
- if (f->ref[0] == '/') {
+ for_each_marker_of_type(m, REF_PHANDLE) {
+ if (m->ref[0] == '/') {
/* Reference to full path */
- refnode = get_node_by_path(dt, f->ref);
+ refnode = get_node_by_path(dt, m->ref);
if (! refnode)
FAIL(c, "Reference to non-existent node \"%s\"\n",
- f->ref);
+ m->ref);
} else {
- refnode = get_node_by_label(dt, f->ref);
+ refnode = get_node_by_label(dt, m->ref);
if (! refnode)
FAIL(c, "Reference to non-existent node label
\"%s\"\n",
- f->ref);
+ m->ref);
}
phandle = get_node_phandle(dt, refnode);
- assert(f->offset + sizeof(cell_t) <= prop->val.len);
+ assert(m->offset + sizeof(cell_t) <= prop->val.len);
- *((cell_t *)(prop->val.val + f->offset)) = cpu_to_be32(phandle);
-
- prop->val.refs = f->next;
- fixup_free(f);
- f = prop->val.refs;
+ *((cell_t *)(prop->val.val + m->offset)) = cpu_to_be32(phandle);
}
}
CHECK(references, NULL, NULL, fixup_references, NULL, ERROR,
Index: dtc/data.c
===
--- dtc.orig/data.c 2007-11-21 17:55:50.0 +1100
+++ dtc/data.c 2007-11-22 10:51:09.0 +1100
@@ -20,28 +20,16 @@
#include "dtc.h"
-void fixup_free(struct fixup *f)
-{
- free(f->ref);
- free(f);
-}
-
void data_free(struct data d)
{
- struct fixup *f, *nf;
+ struct marker *m, *nm;
- f = d.refs;
- while (f) {
- nf = f->next;
- fixup_free(f);
- f = nf;
- }
-
- f = d.labels;
- while (f) {
- nf = f->next;
- fixup_free(f);
- f = nf;
+ m = d.markers;
+ while (m) {
+ nm = m->next;
+ free(m->ref);
+ free(m);
+ m = nm;
}
assert(!d.val || d.asize);
@@ -214,37 +202,29 @@
return d;
}
-void fixup_merge(struct fixup **fd, struct fixup **fd2, int d1_len)
+struct data data_append_markers(struct data d, struct marker *m)
{
- struct fixup **ff;
- struct fixup *f, *f2;
-
- /* Extract d2's fixups */
- f2 = *fd2;
- *fd2 = NULL;
-
- /* Tack them onto d's list of fixups */
- ff = fd;
- while (*ff)
- ff = &((*ff)->next);
- *ff = f2;
-
- /* And correct them for their new position */
- for (f = f2; f; f = f->next)
- f->offset += d1_len;
-
+ struct marker **mp = &d.markers;
+ /* Find the end of the markerlist */
+ while (*mp)
+ mp = &((*mp)->next);
+ *mp = m;
+ return d;
}
struct data data_merge(struct data d1, struct data d2)
{
struct dat
Re: [RFC/PATCH 12/14] powerpc: Add early udbg support for 40x processors
On Thu, Nov 22, 2007 at 11:00:15AM +1100, Benjamin Herrenschmidt wrote: > > On Thu, 2007-11-22 at 09:58 +1100, David Gibson wrote: > > On Wed, Nov 21, 2007 at 05:16:30PM +1100, Benjamin Herrenschmidt wrote: > > > This adds some basic real mode based early udbg support for 40x > > > in order to debug things more easily > > > > Shouldn't we be able to share code with the Maple realmode udbg()? > > Do you really care ? Not very much, no. -- David Gibson| I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 3/3] [POWERPC] Add docs for Freescale DMA & DMA channel device tree nodes
David Gibson wrote: > Indeed, indexing or writing into shared registers is exactly what > cell-index is for. I don't care whether it's cell-index or device-id, but I need to know which DMA controller is #0 and which one is #1, and I need to know which channel is #0, which one is #1, etc. Dividing register offsets by 0x80 is not acceptable, because what if we have an elo-plus-plus that has 0x100 bytes per register, where the additional 0x20 bytes are for enhanced features? -- Timur Tabi Linux Kernel Developer @ Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 12/14] powerpc: Add early udbg support for 40x processors
> fixed speed > 4 registers: rx, tx, status & control > > rx & tx are... well... rx and tx registers > status has a number of bits reporting fifos full/empty etc. > control has three bits; reset tx, reset rx and interrupt enable. > > See the top of drivers/serial/uartlite.c > > Very simple stuff; but definitely not 16550. Yuck, they could have made it look like 16550 at least... Oh well, that's allright, select'ing it wont break anything anyway. Ultimately, we can if we want have a list of all support 40x (and 4xx) variants and select what we want in a given kernel build. Those variants would themselves select the individual bits they care about... Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 3/3] [POWERPC] Add docs for Freescale DMA & DMA channel device tree nodes
Scott Wood wrote: > I don't see any justification for having such a property in the parent node, > though. The SSI needs to know which DMA controller is #0 and which one is #1. I literally program the SSI and the GUTS registers with the DMA controller and channels numbers. I need to know which one is which! -- Timur Tabi Linux Kernel Developer @ Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 3/3] [POWERPC] Add docs for Freescale DMA & DMA channel device tree nodes
Kumar Gala wrote:
>> Shouldn't we put some text somewhere that we're calling it the Elo
>> controller even though that word isn't used in the reference manual?
>
> we don't really have a place to put that. its effectively documented
> right here.
I still think we need something. Otherwise, people are going to be confused.
I know I would. I'd be searching the RM for the string "ELO" and wonder why
it wasn't there.
>>> + Example:
>>> +[EMAIL PROTECTED] {
>>
>> Shouldn't this be [EMAIL PROTECTED]
>
> its an example that has not basis is reality :)
Eh?
>> The DMA controller and the DMA channels need a "device-id", so that
>> they can be identified by number. Some peripherals, like the SSI, can
>> only use the controller and channel number. This is what I have in my
>> 8610 DTS:
>
> Why not use reg for this? I don't see any reason to add another "unique
> id" when there is already one.
There isn't one. Why should the driver assume that reg/80 == channel #?
Besides, I still can't differentiate between DMA controller 0 and DMA
controller 1 that way. No, we need a device-id.
--
Timur Tabi
Linux Kernel Developer @ Freescale
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
dtc: Flexible tree checking infrastructure (v2)
dtc: Flexible tree checking infrastructure
Here, at last, is a substantial start on revising dtc's infrastructure
for checking the tree; this is the rework I've been saying was
necessary practically since dtc was first release.
In the new model, we have a table of "check" structures, each with a
name, references to checking functions, and status variables. Each
check can (in principle) be individually switched off or on (as either
a warning or error). Checks have a list of prerequisites, so if
checks need to rely on results from earlier checks to make sense (or
even to avoid crashing) they just need to list the relevant other
checks there.
For now, only the "structural" checks and the fixups for phandle
references are converted to the new mechanism. The rather more
involved semantic checks (which is where this new mechanism will
really be useful) will have to be converted in future patches.
At present, there's no user interface for turning on/off the checks -
the -f option now forces output even if "error" level checks fail.
Again, future patches will be needed to add the fine-grained control,
but that should be quite straightforward with the infrastructure
implemented here.
Also adds a testcase for the handling of bad references, which catches
a bug encountered while developing this patch.
Signed-off-by: David Gibson <[EMAIL PROTECTED]>
---
Oops, the original version had a bug: processing a bad reference would
cause dtc to SEGV. Plus the sense was backwards when checking the
value of 'quiet' to suppress errors/warnings. Fixed here and some
other small changes:
- cleanups to reference processing code
- cleanups to error/warning message printing code
- added a tracing mechanism (compile time option) useful for
debugging problems with the checks
Index: dtc/checks.c
===
--- dtc.orig/checks.c 2007-11-22 13:03:05.0 +1100
+++ dtc/checks.c2007-11-22 14:02:26.0 +1100
@@ -20,104 +20,293 @@
#include "dtc.h"
-/*
- * Structural check functions
- */
+#ifdef TRACE_CHECKS
+#define TRACE(c, ...) \
+ do { \
+ fprintf(stderr, "=== %s: ", (c)->name); \
+ fprintf(stderr, __VA_ARGS__); \
+ fprintf(stderr, "\n"); \
+ } while (0)
+#else
+#define TRACE(c, fmt, ...) do { } while (0)
+#endif
+
+enum checklevel {
+ IGNORE = 0,
+ WARN = 1,
+ ERROR = 2,
+};
-#define ERRMSG(...) if (quiet < 2) fprintf(stderr, "ERROR: " __VA_ARGS__)
-#define WARNMSG(...) if (quiet < 1) fprintf(stderr, "Warning: " __VA_ARGS__)
+enum checkstatus {
+ UNCHECKED = 0,
+ PREREQ,
+ PASSED,
+ FAILED,
+};
-#define DO_ERR(...) do {ERRMSG(__VA_ARGS__); ok = 0; } while (0)
+struct check;
-static int check_names(struct node *tree)
-{
- struct node *child, *child2;
- struct property *prop, *prop2;
- int len = strlen(tree->name);
- int ok = 1;
+typedef void (*tree_check_fn)(struct check *c, struct node *dt);
+typedef void (*node_check_fn)(struct check *c, struct node *dt, struct node
*node);
+typedef void (*prop_check_fn)(struct check *c, struct node *dt,
+ struct node *node, struct property *prop);
+
+struct check {
+ const char *name;
+ tree_check_fn tree_fn;
+ node_check_fn node_fn;
+ prop_check_fn prop_fn;
+ void *data;
+ enum checklevel level;
+ enum checkstatus status;
+ int inprogress;
+ int num_prereqs;
+ struct check **prereq;
+};
- if (len == 0 && tree->parent)
- DO_ERR("Empty, non-root nodename at %s\n", tree->fullpath);
+#define CHECK(nm, tfn, nfn, pfn, d, lvl, ...) \
+ static struct check *nm##_prereqs[] = { __VA_ARGS__ }; \
+ static struct check nm = { \
+ .name = #nm, \
+ .tree_fn = (tfn), \
+ .node_fn = (nfn), \
+ .prop_fn = (pfn), \
+ .data = (d), \
+ .level = (lvl), \
+ .status = UNCHECKED, \
+ .num_prereqs = ARRAY_SIZE(nm##_prereqs), \
+ .prereq = nm##_prereqs, \
+ };
+
+#define TREE_CHECK(nm, d, lvl, ...) \
+ CHECK(nm, check_##nm, NULL, NULL, d, lvl, __VA_ARGS__)
+#define NODE_CHECK(nm, d, lvl, ...) \
+ CHECK(nm, NULL, check_##nm, NULL, d, lvl, __VA_ARGS__)
+#define PROP_CHECK(nm, d, lvl, ...) \
+ CHECK(nm, NULL, NULL, check_##nm, d, lvl, __VA_ARGS__)
+#define BATCH_CHECK(nm, lvl, ...) \
+ CHECK(nm, NULL, NULL, NULL, NULL, lvl, __VA_ARGS__)
+
+static inline void check_msg(struct check *c, const char *fmt, ...)
+{
+ va_list ap;
+ va_start(ap, fmt);
+
+ if ((c->level < WARN) || (c->level <= quiet))
+ return; /* Suppress message */
+
+ fprintf(stderr, "%s (%s): ",
+ (c->level == ERROR) ? "ERROR" : "Warning", c->name);
+ vfprintf(stderr, fmt, ap);
+ fprintf(s
dtc: Merge refs and labels into single "markers" list (v2)
Currently, every 'data' object, used to represent property values, has
two lists of fixup structures - one for labels and one for references.
Sometimes we want to look at them separately, but other times we need
to consider both types of fixup.
I'm planning to implement string references, where a full path rather
than a phandle is substituted into a property value. Adding yet
another list of fixups for that would start to get silly. So, this
patch merges the "refs" and "labels" lists into a single list of
"markers", each of which has a type field indicating if it represents
a label or a phandle reference. String references or any other new
type of in-data marker will then just need a new type value - merging
data blocks and other common manipulations will just work.
While I was at it I made some cleanups to the handling of fixups which
simplify things further.
Signed-off-by: David Gibson <[EMAIL PROTECTED]>
---
Updated to apply on top of the new version of the checking
infrastructure patch.
checks.c | 20 ---
data.c | 101 ---
dtc-parser.y | 11 +++---
dtc.h| 24 +-
flattree.c | 11 +++---
treesource.c | 62 ++--
6 files changed, 97 insertions(+), 132 deletions(-)
Index: dtc/checks.c
===
--- dtc.orig/checks.c 2007-11-22 14:02:26.0 +1100
+++ dtc/checks.c2007-11-22 14:38:39.0 +1100
@@ -243,26 +243,22 @@
static void fixup_phandle_references(struct check *c, struct node *dt,
struct node *node, struct property *prop)
{
- struct fixup *f = prop->val.refs;
+ struct marker *m = prop->val.markers;
struct node *refnode;
cell_t phandle;
- while (f) {
- assert(f->offset + sizeof(cell_t) <= prop->val.len);
+ for_each_marker_of_type(m, REF_PHANDLE) {
+ assert(m->offset + sizeof(cell_t) <= prop->val.len);
- refnode = get_node_by_ref(dt, f->ref);
+ refnode = get_node_by_ref(dt, m->ref);
if (! refnode) {
FAIL(c, "Reference to non-existent node or label
\"%s\"\n",
- f->ref);
- } else {
- phandle = get_node_phandle(dt, refnode);
-
- *((cell_t *)(prop->val.val + f->offset)) =
cpu_to_be32(phandle);
+ m->ref);
+ continue;
}
- prop->val.refs = f->next;
- fixup_free(f);
- f = prop->val.refs;
+ phandle = get_node_phandle(dt, refnode);
+ *((cell_t *)(prop->val.val + m->offset)) = cpu_to_be32(phandle);
}
}
CHECK(phandle_references, NULL, NULL, fixup_phandle_references, NULL, ERROR,
Index: dtc/data.c
===
--- dtc.orig/data.c 2007-11-22 13:54:57.0 +1100
+++ dtc/data.c 2007-11-22 14:38:39.0 +1100
@@ -20,28 +20,16 @@
#include "dtc.h"
-void fixup_free(struct fixup *f)
-{
- free(f->ref);
- free(f);
-}
-
void data_free(struct data d)
{
- struct fixup *f, *nf;
+ struct marker *m, *nm;
- f = d.refs;
- while (f) {
- nf = f->next;
- fixup_free(f);
- f = nf;
- }
-
- f = d.labels;
- while (f) {
- nf = f->next;
- fixup_free(f);
- f = nf;
+ m = d.markers;
+ while (m) {
+ nm = m->next;
+ free(m->ref);
+ free(m);
+ m = nm;
}
assert(!d.val || d.asize);
@@ -214,37 +202,29 @@
return d;
}
-void fixup_merge(struct fixup **fd, struct fixup **fd2, int d1_len)
+struct data data_append_markers(struct data d, struct marker *m)
{
- struct fixup **ff;
- struct fixup *f, *f2;
-
- /* Extract d2's fixups */
- f2 = *fd2;
- *fd2 = NULL;
-
- /* Tack them onto d's list of fixups */
- ff = fd;
- while (*ff)
- ff = &((*ff)->next);
- *ff = f2;
-
- /* And correct them for their new position */
- for (f = f2; f; f = f->next)
- f->offset += d1_len;
-
+ struct marker **mp = &d.markers;
+ /* Find the end of the markerlist */
+ while (*mp)
+ mp = &((*mp)->next);
+ *mp = m;
+ return d;
}
struct data data_merge(struct data d1, struct data d2)
{
struct data d;
+ struct marker *m2 = d2.markers;
- d = data_append_data(d1, d2.val, d2.len);
+ d = data_append_markers(data_append_data(d1, d2.val, d2.len), m2);
- fixup_merge(&d.refs, &d2.refs, d1.len);
- fixup_merge(&d.labels, &d2.labels, d1.len);
+ /* Adjust for the length of d1 */
+ for_each_marker(m2)
+
dtc: RFC: Fix some lexical problems with references
The recent change to the lexer to only recognize property and node
names in the appropriate context removed a number of lexical warts in
our language that would have gotten ugly as we add expression support
and so forth.
But there's one nasty one remaining: references can contain a full
path, including the various problematic node name characters (',', '+'
and '-', for example). This would cause trouble with expressions, and
it also causes trouble with the patch I'm working on to allow
expanding references to paths rather than phandles. This patch
therefore reworks the lexer to mitigate these problems.
- References to labels cause no problems. These are now
recognized separately from references to full paths. No syntax change
here.
- References to full paths, including problematic characters
are allowed by "quoting" the path with braces
e.g. &{/[EMAIL PROTECTED]/[EMAIL PROTECTED],8000}. The braces protect any
internal
problematic characters from being confused with operators or whatever.
- For compatibility with existing dts files, in v0 dts files
we allow bare references to paths as before &/foo/bar/whatever - but
*only* if the path contains no troublesome characters. Specifically
only [a-zA-Z0-9_@/] are allowed.
This is an incompatible change to the dts-v1 format, but since AFAIK
no-one has yet switched to dts-v1 files, I think we can get away with
it. Better to make the transition when people to convert to v1, and
get rid of the problematic old syntax.
Strictly speaking, it's also an incompatible change to the v0 format,
since some path references that were allowed before are no longer
allowed. I suspect no-one has been using the no-longer-supported
forms (certainly none of the kernel dts files will cause trouble). We
might need to think about this harder, though.
Signed-off-by: David Gibson <[EMAIL PROTECTED]>
Index: dtc/dtc-lexer.l
===
--- dtc.orig/dtc-lexer.l2007-11-22 16:33:47.0 +1100
+++ dtc/dtc-lexer.l 2007-11-22 16:40:48.0 +1100
@@ -25,12 +25,12 @@
%x PROPNODENAME
%s V1
-PROPCHAR [a-zA-Z0-9,._+*#?-]
-UNITCHAR [0-9a-f,]
+PROPNODECHAR [a-zA-Z0-9,[EMAIL PROTECTED]
+PATHCHAR ({PROPNODECHAR}|[/])
+LEGACYPATHCHAR [a-zA-Z0-9_@/]
+LABEL [a-zA-Z_][a-zA-Z0-9_]*
WS [[:space:]]
-REFCHAR({PROPCHAR}|{UNITCHAR}|[/@])
-
%{
#include "dtc.h"
#include "srcpos.h"
@@ -102,7 +102,7 @@
return DT_MEMRESERVE;
}
-<*>[a-zA-Z_][a-zA-Z0-9_]*: {
+<*>{LABEL}:{
yylloc.filenum = srcpos_filenum;
yylloc.first_line = yylineno;
DPRINT("Label: %s\n", yytext);
@@ -142,7 +142,24 @@
return DT_LITERAL;
}
-\&{REFCHAR}* {
+\&{LABEL} { /* label reference */
+ yylloc.filenum = srcpos_filenum;
+ yylloc.first_line = yylineno;
+ DPRINT("Ref: %s\n", yytext+1);
+ yylval.labelref = strdup(yytext+1);
+ return DT_REF;
+ }
+
+"&{/"{PATHCHAR}+\} { /* new-style path reference */
+ yylloc.filenum = srcpos_filenum;
+ yylloc.first_line = yylineno;
+ yytext[yyleng-1] = '\0';
+ DPRINT("Ref: %s\n", yytext+2);
+ yylval.labelref = strdup(yytext+2);
+ return DT_REF;
+ }
+
+"&/"{LEGACYPATHCHAR}+ { /* old-style path reference */
yylloc.filenum = srcpos_filenum;
yylloc.first_line = yylineno;
DPRINT("Ref: %s\n", yytext+1);
@@ -166,7 +183,7 @@
return ']';
}
-{PROPCHAR}+(@{UNITCHAR}+)? {
+{PROPNODECHAR}+ {
yylloc.filenum = srcpos_filenum;
yylloc.first_line = yylineno;
DPRINT("PropNodeName: %s\n", yytext);
Index: dtc/tests/nonexist-node-ref.dts
===
--- dtc.orig/tests/nonexist-node-ref.dts2007-11-22 16:33:47.0
+1100
+++ dtc/tests/nonexist-node-ref.dts 2007-11-22 16:34:12.0 +1100
@@ -1,8 +1,8 @@
/dts-v1/;
/ {
- ref = < &/node >;
- badref = < &/nosuchnode >;
+ ref = < &{/node} >;
+ badref = < &{/nosuchnode} >;
label: node {
};
};
Index: dtc/tests/references.dts
===
--- dtc.orig/tests/references.dts 2007-11-22 16:33:47.0 +1100
+++ dtc/tests/references.dts2007-11-22 16:34:12.0 +1100
@@ -4,18 +4,18 @@
/* Explicit phandles */
n1: node1 {
linux,phandle = <0x2000>;
- ref = <
Re: dtc: RFC: Fix some lexical problems with references
On Thu, Nov 22, 2007 at 05:10:07PM +1100, David Gibson wrote:
> The recent change to the lexer to only recognize property and node
> names in the appropriate context removed a number of lexical warts in
> our language that would have gotten ugly as we add expression support
> and so forth.
>
> But there's one nasty one remaining: references can contain a full
> path, including the various problematic node name characters (',', '+'
> and '-', for example). This would cause trouble with expressions, and
> it also causes trouble with the patch I'm working on to allow
> expanding references to paths rather than phandles. This patch
> therefore reworks the lexer to mitigate these problems.
>
> - References to labels cause no problems. These are now
> recognized separately from references to full paths. No syntax change
> here.
>
> - References to full paths, including problematic characters
> are allowed by "quoting" the path with braces
> e.g. &{/[EMAIL PROTECTED]/[EMAIL PROTECTED],8000}. The braces protect any
> internal
> problematic characters from being confused with operators or whatever.
>
> - For compatibility with existing dts files, in v0 dts files
> we allow bare references to paths as before &/foo/bar/whatever - but
> *only* if the path contains no troublesome characters. Specifically
> only [a-zA-Z0-9_@/] are allowed.
>
> This is an incompatible change to the dts-v1 format, but since AFAIK
> no-one has yet switched to dts-v1 files, I think we can get away with
> it. Better to make the transition when people to convert to v1, and
> get rid of the problematic old syntax.
>
> Strictly speaking, it's also an incompatible change to the v0 format,
> since some path references that were allowed before are no longer
> allowed. I suspect no-one has been using the no-longer-supported
> forms (certainly none of the kernel dts files will cause trouble). We
> might need to think about this harder, though.
Just to note: we need to do something here, but there are approaches
other than the one above (hence the RFC). For example, if we just
separate the lexical recognition of refs-to-labels from refs-to-paths
then we can continue to recognize full bare path references. However,
in some circumstances it might be necessary to add whitespace in the
dts to correctly mark the end of the path (in the case '/' and ' '
would essentially take the place of the braces for delimiting the
path). That maintains full compatibility, and avoids the arguably
ugly &{/foo} syntax, but it does mean there are some odd situations
like the fact that (once string references are implemented):
&label1, &label2
and &label1 , &label2
would be equivalent, but the following two:
&/node1, &/node2
&/node1 , &/node2
would not be equivalent (depending on context one or both of them
could be syntax errors). The first is a reference to the node
"/node1," then a reference to the node "/node2", the second is a
reference to the node "/node1" then a comma then a reference to the
node "/node2".
--
David Gibson| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
