* Re: [RFC PATCH 02/19] powerpc: gamecube: device tree
From: Benjamin Herrenschmidt @ 2009-11-26 4:27 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: Albert Herranz, linuxppc-dev
In-Reply-To: <49443.84.105.60.153.1259172058.squirrel@gate.crashing.org>
On Wed, 2009-11-25 at 19:00 +0100, Segher Boessenkool wrote:
> > + memory {
> > + device_type = "memory";
> > + /* 24M minus framebuffer memory area (640*576*2*2) */
> > + reg = <0x00000000 0x01698000>;
>
> Put the whole 24MB here, probe the framebuffer address and size
> in the platform code?
Agreed. That's what I was proposing. Though you need to be careful about
early boot code that will try to allocate the hash table etc... or even
the DT itself. So you need to probe and reserve the fb really early,
for example in the platform probe() routine itself. Or you can stick it
in the reserve map too I suppose.
> > + video@0c002000 {
> > + compatible = "nintendo,flipper-video";
> > + reg = <0x0c002000 0x100>;
> > + interrupts = <8>;
> > + interrupt-parent = <&pic>;
> > + /* XFB is the eXternal FrameBuffer */
> > + xfb-start = <0x01698000>; /* end-of-ram - xfb-size */
> > + xfb-size = <0x168000>;
>
> XFB address isn't fixed on the hardware, and the kernel might
> want to move it, and you can easily probe for it anyway. Remove
> these last two properties please.
Ok but you need to know what it was setup to by the FW no ? To avoid
having a temporary display "glitch" while booting... Also on a 24M
config,it might get tough for the driver to allocate 2M contiguous like
that if it's done late in the boot process.
>
> > + auxram@0c005000 {
> > + compatible = "nintendo,flipper-auxram";
> > + reg = <0x0c005000 0x200>; /* DSP */
> > + interrupts = <6>;
> > + interrupt-parent = <&pic>;
> > + };
> > +
> > + audio@0c005000 {
> > + compatible = "nintendo,flipper-audio";
> > + reg = <0x0c005000 0x200 /* DSP */
> > + 0x0c006c00 0x20>; /* AI */
> > + interrupts = <6>;
> > + interrupt-parent = <&pic>;
> > + };
>
> These two have the same address, not good. Just remove the
> auxram node?
Or make it a child of audio ? :-)
Cheers,
Ben.
^ permalink raw reply
* Re: [RFC PATCH 03/19] powerpc: gamecube: bootwrapper bits
From: Benjamin Herrenschmidt @ 2009-11-26 4:35 UTC (permalink / raw)
To: Albert Herranz; +Cc: linuxppc-dev
In-Reply-To: <4B0C1A25.8030401@yahoo.es>
On Tue, 2009-11-24 at 18:38 +0100, Albert Herranz wrote:
> Segher Boessenkool wrote:
> > Hi Albert,
> >
> >> +asm ("\n\
> >
> >
> > A file scope asm?! Please don't.
> >
>
> So what's your proposal then? Placing it within a fake func?
Just do a .S file :-)
> That asm snippet is the entry point. I took as an example how prpmc2800.c
> deals with that, providing an own version of the (weak) _zImage_start.
Right but I agree with Segher here, it would be nicer as a .S file.
> >> + * We enter with the cache enabled, the MMU enabled and some known
> >> legacy
> >> + * memory mappings active. xBAT3 is unused
> >
> > It would be good if you could depend as little as possible on these things;
> > that makes writing another bootloader a lot easier.
> >
>
> Ok. I'll do a similar approach as done on the wii bootwrapper.
>
> >> + /* IBAT3,DBAT3 for first 16Mbytes */\n\
> >> + li 8, 0x01ff /* 16MB */\n\
> >> + li 9, 0x0002 /* rw */\n\
> >> + mtspr 0x216, 8 /* IBAT3U */\n\
> >> + mtspr 0x217, 9 /* IBAT3L */\n\
> >> + mtspr 0x21e, 8 /* DBAT3U */\n\
> >> + mtspr 0x21f, 9 /* DBAT3L */\n\
> >
> > WIMG=0000, are you sure? Not M=1?
> >
>
> To be honest, I don't recall the details now.
> But it was tested in the very early days, the result was not the expected one and,
> in the end, manual cache coherency management was still needed.
Ouch. I wouldn't be surprised if those guys don't do cache coherency
in the bridge anyways.
> So everything is designed and working assuming M=0.
> This can be re-checked again later if needed.
Agreed.
> >> + bcl- 20,4*cr7+so,1f\n\
> >
> > Just write bcl 20,31,1f .
>
> Ok, I used two variants for this and I know which one you like now ;).
Cheers,
Ben.
> >
> >
> > Segher
> >
> >
>
> Thanks,
> Albert
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
^ permalink raw reply
* Re: [RFC PATCH 03/19] powerpc: gamecube: bootwrapper bits
From: Benjamin Herrenschmidt @ 2009-11-26 4:36 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: Albert Herranz, linuxppc-dev
In-Reply-To: <CC1D5EB1-27C2-47A1-96D8-D007D86C4881@kernel.crashing.org>
On Tue, 2009-11-24 at 22:00 +0100, Segher Boessenkool wrote:
>
> Sure, the memory controllers don't do coherency. I'm slightly worried
> about two things:
> 1) Will the generic code use M=0 as well? Is it a problem if it
> doesn't?
We can make it not do it.
> 2) Do lwarx. etc. work in M=0?
They should hopefully... as long as you don't rely on the reservation
blowing as a result of a DMA write.
Cheers,
Ben
^ permalink raw reply
* Re: [RFC PATCH 02/19] powerpc: gamecube: device tree
From: Grant Likely @ 2009-11-26 4:38 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: Albert Herranz, linuxppc-dev
In-Reply-To: <1259209283.16367.241.camel@pasglop>
On Wed, Nov 25, 2009 at 9:21 PM, Benjamin Herrenschmidt
<benh@kernel.crashing.org> wrote:
> On Sun, 2009-11-22 at 16:02 -0700, Grant Likely wrote:
>> > +
>> > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 video@0c002000 {
>> > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 compatible =3D "nintendo=
,flipper-video";
>> > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 reg =3D <0x0c002000 0x10=
0>;
>> > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 interrupts =3D <8>;
>> > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 interrupt-parent =3D <&p=
ic>;
>>
>> Hint: =A0If you move the interrupt-parent property up to the root node,
>> then you don't need to specify it in every single device node; it will
>> just inherit from the parent.
>
> Note that this is a linux-ism no ? (aka ePAPRism). If they aim toward
> having a real OF which I think they do they may wish to pass on this
> trick.
But this isn't real OF. Real OF can generate its own valid tree.
This is a flat tree, and it is valid according to all users of the
flat tree. Besides, the last time we talked about this, you told me
that moving it to the root was a good idea, and I happily changed all
the 5200 .dts files. :-)
http://lists.ozlabs.org/pipermail/linuxppc-dev/2009-January/067046.html
g.
--=20
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: [RFC PATCH 04/19] powerpc: wii: device tree
From: Benjamin Herrenschmidt @ 2009-11-26 4:45 UTC (permalink / raw)
To: Albert Herranz; +Cc: linuxppc-dev
In-Reply-To: <1258927311-4340-5-git-send-email-albert_herranz@yahoo.es>
On Sun, 2009-11-22 at 23:01 +0100, Albert Herranz wrote:
> +/memreserve/ 0x01800000 0xe800000; /* memory hole (includes I/O area) */
> +/memreserve/ 0x10000000 0x0004000; /* DSP RAM */
Weird layout... nothing you can do about I suppose.
Out of curiosity, what is that DSP RAM ? Some actual DSP core somewhere
in the IO chip setup to use memory from up there ?
I'll skip on some things that I'm sure others will have commented
about :-)
> + /*
> + * The Nintendo Wii has two discontiguous RAM memory areas called
> + * MEM1 and MEM2.
> + * MEM1 starts at 0x00000000 and contains 24MB of 1T-SRAM.
> + * MEM2 starts at 0x10000000 and contains 64MB of DDR2 RAM.
> + * Between both memory address ranges there is an address space
> + * where memory-mapped I/O registers are found.
> + *
> + * Currently, Linux 32-bit PowerPC does not support RAM in
> + * discontiguous memory address spaces. Thus, in order to use
> + * both RAM areas, we declare as RAM the range from the start of
> + * MEM1 to the end of useable MEM2 and exclude the needed parts
> + * with /memreserve/ statements, at the expense of wasting a bit
> + * of memory.
> + */
> + memory {
> + device_type = "memory";
> + /* MEM1 + memory hole + MEM2 - firmware/buffers area */
> + reg = <0x00000000 0x133e0000>;
> + };
So we do have a nasty hole here in the middle. How bad it is if you try
to just have two ranges in there (ie as if it was discontiguous) ? We
shouldn't be far from being able to do discontig mem actually, should be
easy enough to fix. Tho I don't have (yet) the HW :-) (I'm tempted...)
Same comment as other discussions about the framebuffer here.
> + cpus {
> + #cpus = <1>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + PowerPC,broadway@0 {
> + device_type = "cpu";
> + reg = <0>;
> + clock-frequency = <729000000>; /* 729MHz */
> + bus-frequency = <243000000>; /* 243MHz core-to-bus 3x */
> + timebase-frequency = <60750000>; /* 243MHz / 4 */
> + i-cache-line-size = <32>;
> + d-cache-line-size = <32>;
> + i-cache-size = <32768>;
> + d-cache-size = <32768>;
> + };
> + };
> +
> + /* devices contained in the hollywood chipset */
> + soc {
Call it "hollywood"
> + #address-cells = <1>;
> + #size-cells = <1>;
> + #interrupt-cells = <1>;
> + model = "hollywood";
> + compatible = "nintendo,hollywood";
> + clock-frequency = <243000000>; /* 243MHz */
> + ranges = <0x0c000000 0x0c000000 0x00010000
> + 0x0d000000 0x0d000000 0x00010000
> + 0x0d040000 0x0d040000 0x00050000
> + 0x0d800000 0x0d800000 0x00001000
> + 0x133e0000 0x133e0000 0x00c20000>;
> +
> + video@0c002000 {
> + compatible = "nintendo,hollywood-video";
> + reg = <0x0c002000 0x100>;
> + interrupts = <8>;
> + interrupt-parent = <&PIC0>;
> + };
> +
> + PIC0: pic0@0c003000 {
> + #interrupt-cells = <1>;
> + compatible = "nintendo,flipper-pic";
> + reg = <0x0c003000 0x8>;
> + interrupt-controller;
> + };
> +
> + resetswitch@0c003000 {
> + compatible = "nintendo,hollywood-resetswitch";
> + reg = <0x0c003000 0x4>;
> + interrupts = <1>;
> + interrupt-parent = <&PIC0>;
> + };
> +
> + audio@0c005000 {
> + compatible = "nintendo,hollywood-audio";
> + reg = <0x0c005000 0x200 /* DSP */
> + 0x0d006c00 0x20>; /* AI */
> + interrupts = <6>;
> + interrupt-parent = <&PIC0>;
> + };
> +
> + /* Team Twiizers' 'mini' firmware IPC */
Out of curiosity, what are these ? :-)
> + mini@0d000000 {
> + #address-cells = <1>;
> + #size-cells = <1>;
> + #interrupt-cells = <1>;
> + compatible = "twiizers,starlet-mini-ipc";
> + reg = <0x0d000000 0x40 /* IPC */
> + 0x13fffffc 0x4>; /* mini header pointer */
> + };
> +
> + serial@0d006400 {
> + compatible = "nintendo,hollywood-serial";
> + reg = <0x0d006400 0x100>;
> + interrupts = <3>;
> + interrupt-parent = <&PIC0>;
> + };
> +
> + /* External Interface bus */
> + exi@0d006800 {
> + #address-cells = <1>;
> + #size-cells = <1>;
> + compatible = "nintendo,hollywood-exi";
> + reg = <0x0d006800 0x40>;
> + interrupts = <4>;
> + interrupt-parent = <&PIC0>;
> +
> + USBGECKO0: usbgecko@0d006814 {
> + compatible = "usbgecko,usbgecko";
> + reg = <0x0d006814 0x14>;
> + virtual-reg = <0xcd006814>;
> + };
> + };
Similar comment as before, could the above be dynamically probed ? If
you are not a hacker you may not need that at all to use some linux
based piece of SW on the wii right ?
> + ehci@0d040000 {
> + compatible = "nintendo,hollywood-ehci";
> + reg = <0x0d040000 0x100
> + 0x133e0000 0x80000>; /* 512 KB */
> + interrupts = <4>;
> + interrupt-parent = <&PIC1>;
> + };
> +
> + ohci0@0d050000 {
> + compatible = "nintendo,hollywood-ohci";
> + reg = <0x0d050000 0x100
> + 0x13460000 0x80000>; /* 512 KB */
> + interrupts = <5>;
> + interrupt-parent = <&PIC1>;
> + };
> +
> + ohci1@0d060000 {
Why the "1" ?
> + compatible = "nintendo,hollywood-ohci";
> + reg = <0x0d060000 0x100
> + 0x134e0000 0x80000>; /* 512 KB */
> + interrupts = <6>;
> + interrupt-parent = <&PIC1>;
> + };
Are the above OHCI and EHCI "special" ? If not, there's an existing
binding for that sort of thing, which btw requires properties to
indicate the endianness of the registers and in-memory data structures
etc...
> + sdhc0@0d070000 {
> + compatible = "nintendo,hollywood-sdhci";
> + reg = <0x0d070000 0x200>;
> + interrupts = <7>;
> + interrupt-parent = <&PIC1>;
> + };
> +
> + sdhc1@0d080000 {
> + compatible = "nintendo,hollywood-sdhci";
> + reg = <0x0d080000 0x200>;
> + interrupts = <8>;
> + interrupt-parent = <&PIC1>;
> + };
Again, no need for a "1" in there. Names don't have to be unique if the
unit address is different.
> + PIC1: pic1@0d800030 {
> + #interrupt-cells = <1>;
> + compatible = "nintendo,hollywood-pic";
> + reg = <0x0d800030 0x8>;
> + interrupt-controller;
> + interrupts = <14>;
> + interrupt-parent = <&PIC0>;
> + };
Ah, a cascaded PIC, fun fun fun
> + hollywood-ahbprot@0d800064 {
> + compatible = "nintendo,hollywood-ahbprot";
> + reg = <0x0d800064 0x4>;
> + };
What is this ?
> + gpio0: hollywood-gpio@0d8000c0 {
> + compatible = "nintendo,hollywood-gpio";
> + reg = <0x0d8000c0 0x20>;
> + gpio-controller;
> + #gpio-cells = <2>;
> + };
> +
> + gpio1: hollywood-gpio@0d8000e0 {
> + compatible = "nintendo,hollywood-gpio";
> + reg = <0x0d8000e0 0x20>;
> + gpio-controller;
> + #gpio-cells = <2>;
> + };
Same comment about the "1"
> + hollywood-resets@0d800194 {
> + compatible = "nintendo,hollywood-resets";
> + reg = <0x0d800194 0x4>;
> + };
> +
> + i2c-video {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + compatible = "virtual,i2c-gpio";
> +
> + gpios = <&gpio0 16 0 /* 31-15 */
> + &gpio0 17 0 /* 31-14 */
> + >;
> + sda-is-open-drain = <1>;
> + sda-enforce-dir = <1>;
> + scl-is-open-drain = <1>;
> + scl-is-output-only = <1>;
> + udelay = <2>;
> +
> + audio-video-encoder {
> + compatible = "nintendo,wii-ave-rvl";
> + reg = <0x70>;
> + };
> + };
> + };
> +};
> +
Cheers,
Ben.
^ permalink raw reply
* Re: [RFC PATCH 04/19] powerpc: wii: device tree
From: Benjamin Herrenschmidt @ 2009-11-26 4:51 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: Albert Herranz, linuxppc-dev
In-Reply-To: <49436.84.105.60.153.1259171377.squirrel@gate.crashing.org>
On Wed, 2009-11-25 at 18:49 +0100, Segher Boessenkool wrote:
> > +/memreserve/ 0x01800000 0xe800000; /* memory hole (includes I/O area) */
>
> Like others have said already, don't do this. If you need
> a workaround, put it in the platform code.
>
> > +/memreserve/ 0x10000000 0x0004000; /* DSP RAM */
>
> This address is fixed in the DSP hardware, right? If not,
> you shouldn't do a reserve here.
>
> > + chosen {
> > + /* root filesystem on 2nd partition of SD card */
> > + bootargs = "nobats root=/dev/mmcblk0p2 rootwait udbg-immortal";
>
> Question: why do you need/want nobats?
Good point. I can't even guarantee that the kernel will work reliably
with nobats :-) At least you really want the kernel .text to be fully
covered by an IBAT.
> What does this clock freq mean? Hollywood has lots of
> clocks, many of them configurable. Bus frequency is in
> the cpu node already. The binding doesn't say what this
> is either, since you didn't write a binding :-)
>
> Just remove it?
BTW. If we want to play with clocks, maybe you should look at
my proposed binding for clocks and implementing the clk API :-)
> > + ranges = <0x0c000000 0x0c000000 0x00010000
> > + 0x0d000000 0x0d000000 0x00010000
> > + 0x0d040000 0x0d040000 0x00050000
> > + 0x0d800000 0x0d800000 0x00001000
>
> All of 0cXXXXXX and 0dXXXXXX actually.
>
> > + 0x133e0000 0x133e0000 0x00c20000>;
>
> This is just part of MEM2, don't treat it special here.
>
> > + video@0c002000 {
> > + compatible = "nintendo,hollywood-video";
> > + reg = <0x0c002000 0x100>;
> > + interrupts = <8>;
> > + interrupt-parent = <&PIC0>;
>
> If you say interrupt-parent = <..> in the root node, you can
> leave it out in most of the rest of the tree. Using the Flipper
> PIC for this sounds like a good plan.
Well, for the rest of the tree except stuff whose interrupt parent
is PIC1. With two PICs I prefer being explicit.
> > + PIC0: pic0@0c003000 {
> > + #interrupt-cells = <1>;
> > + compatible = "nintendo,flipper-pic";
> > + reg = <0x0c003000 0x8>;
>
> This register block is bigger actually. It's not only PIC,
> but some other bus stuff as well, dunno what to do here.
Add nodes for the other things ?
> > + interrupt-controller;
> > + };
> > +
> > + resetswitch@0c003000 {
> > + compatible = "nintendo,hollywood-resetswitch";
> > + reg = <0x0c003000 0x4>;
>
> That's the same address. Don't do that.
>
> Create a flipper-processor-interface node for the whole 3000
> block (size 100)? You can hang the PIC as a subnode under it,
> without a "reg".
Yeah.
> > + /* Team Twiizers' 'mini' firmware IPC */
> > + mini@0d000000 {
>
> Although mini is awesome, it isn't hardware, and doesn't
> belong in the device tree.
So what is at d0000000 ?
> > + serial@0d006400 {
> > + compatible = "nintendo,hollywood-serial";
>
> You might want to pick a more descriptive name for this,
> "serial" is usually understaood to mean "RS232". Which
> this isn't.
What is it then ? You definitely want some other name if it's not
classic rs232 style serial.
Cheers,
Ben.
^ permalink raw reply
* Re: [RFC PATCH 04/19] powerpc: wii: device tree
From: Benjamin Herrenschmidt @ 2009-11-26 4:58 UTC (permalink / raw)
To: Albert Herranz; +Cc: linuxppc-dev
In-Reply-To: <4B0D78B0.502@yahoo.es>
On Wed, 2009-11-25 at 19:34 +0100, Albert Herranz wrote:
>
> We need nobats (or a hack in the mmu_mapin_ram() code) because of the
> discontiguous ram problem.
I would vote for a hack in mmu_mapin_ram() for now.
Cheers,
Ben.
^ permalink raw reply
* Re: [RFC PATCH 06/19] powerpc: gamecube/wii: introduce GAMECUBE_COMMON
From: Benjamin Herrenschmidt @ 2009-11-26 5:08 UTC (permalink / raw)
To: Albert Herranz; +Cc: linuxppc-dev
In-Reply-To: <4B0C2002.4050704@yahoo.es>
On Tue, 2009-11-24 at 19:03 +0100, Albert Herranz wrote:
> Segher Boessenkool wrote:
> >> Add a config option GAMECUBE_COMMON to be used as a dependency for all
> >> options common to the Nintendo GameCube and Wii video game consoles.
> >
> > Maybe something like GAMECUBE_OR_WII instead? "COMMON" is so
> > common it's meaningless.
> >
>
> I don't like either GAMECUBE_OR_WII.
> It looks as if it can be used to match options for the GAMECUBE _or_ WII. But that's not the meaning of it.
>
> This option should be used only for options applicable to both the GAMECUBE and WII, i.e. basically those options in the WII which where "inherited" from the GAMECUBE to make it retro-compatible.
>
> If GAMECUBE_COMMON is unacceptable, maybe GAMECUBE_LEGACY or GAMECUBE_COMPAT?
I don't have any strong opinion. Maybe NINTENDO_COMMON ?
Cheers,
Ben.
^ permalink raw reply
* Re: [RFC PATCH 07/19] powerpc: gamecube/wii: declare as non-coherent platforms
From: Benjamin Herrenschmidt @ 2009-11-26 5:09 UTC (permalink / raw)
To: Albert Herranz; +Cc: linuxppc-dev
In-Reply-To: <1258927311-4340-8-git-send-email-albert_herranz@yahoo.es>
On Sun, 2009-11-22 at 23:01 +0100, Albert Herranz wrote:
> The processors bundled in the Nintendo GameCube and Wii video game consoles
> require explicit cache handling when DMA engines are used.
That reminds me we really need to make that a runtime option some day...
Cheers,
Ben.
> Signed-off-by: Albert Herranz <albert_herranz@yahoo.es>
> ---
> arch/powerpc/platforms/Kconfig.cputype | 2 +-
> arch/powerpc/platforms/embedded6xx/Kconfig | 1 +
> 2 files changed, 2 insertions(+), 1 deletions(-)
>
> diff --git a/arch/powerpc/platforms/Kconfig.cputype b/arch/powerpc/platforms/Kconfig.cputype
> index e382cae..80d934b 100644
> --- a/arch/powerpc/platforms/Kconfig.cputype
> +++ b/arch/powerpc/platforms/Kconfig.cputype
> @@ -312,7 +312,7 @@ config NR_CPUS
>
> config NOT_COHERENT_CACHE
> bool
> - depends on 4xx || 8xx || E200 || PPC_MPC512x
> + depends on 4xx || 8xx || E200 || PPC_MPC512x || GAMECUBE_COMMON
> default y
>
> config CHECK_CACHE_COHERENCY
> diff --git a/arch/powerpc/platforms/embedded6xx/Kconfig b/arch/powerpc/platforms/embedded6xx/Kconfig
> index 97a2dbc..31487e4 100644
> --- a/arch/powerpc/platforms/embedded6xx/Kconfig
> +++ b/arch/powerpc/platforms/embedded6xx/Kconfig
> @@ -93,4 +93,5 @@ config MPC10X_STORE_GATHERING
>
> config GAMECUBE_COMMON
> bool
> + select NOT_COHERENT_CACHE
>
^ permalink raw reply
* Re: [PATCH v5 2/4] pSeries: Add hooks to put the CPU into an appropriate offline state
From: Anton Blanchard @ 2009-11-26 5:10 UTC (permalink / raw)
To: Gautham R Shenoy
Cc: Benjamin Herrenschmidt, Peter Zijlstra, linux-kernel,
Arun R Bharadwaj, Andrew Morton, linuxppc-dev, Ingo Molnar
In-Reply-To: <20091030052253.25493.65063.stgit@sofia.in.ibm.com>
Hi Gautham,
> + call_status = rtas_call(rtas_token("ibm,get-system-parameter"), 3, 1,
> + NULL,
> + CEDE_LATENCY_TOKEN,
> + __pa(cede_parameters),
> + CEDE_LATENCY_PARAM_MAX_LENGTH);
> +
> + if (call_status != 0)
> + printk(KERN_INFO "CEDE_LATENCY: \
> + %s %s Error calling get-system-parameter(0x%x)\n",
> + __FILE__, __func__, call_status);
> + else
> + printk(KERN_INFO "CEDE_LATENCY: \
> + get-system-parameter successful.\n");
I'm seeing this on a POWER6 box:
CEDE_LATENCY: arch/powerpc/platforms/pseries/hotplug-cpu.c parse_cede_parameters Error calling get-system-parameter(0xfffffffd)
Seems overly verbose. Do we need to print success/fail on this call? Perhaps
a summary line if anything during initialisation failed:
Cede latency not supported
and
Cede latency supported
If it all worked.
Anton
^ permalink raw reply
* Re: [RFC PATCH 08/19] powerpc: gamecube/wii: do not include PCI support
From: Benjamin Herrenschmidt @ 2009-11-26 5:10 UTC (permalink / raw)
To: Grant Likely; +Cc: Albert Herranz, linuxppc-dev
In-Reply-To: <fa686aa40911221521h4844db3cpb33a1afb41833d46@mail.gmail.com>
On Sun, 2009-11-22 at 16:21 -0700, Grant Likely wrote:
> On Sun, Nov 22, 2009 at 3:01 PM, Albert Herranz <albert_herranz@yahoo.es> wrote:
> > The Nintendo GameCube and Wii video game consoles do not have PCI hardware.
> > Avoid wasting their scarce memory by not including PCI support into the
> > kernel.
> >
> > Signed-off-by: Albert Herranz <albert_herranz@yahoo.es>
> > ---
> > arch/powerpc/Kconfig | 2 +-
> > 1 files changed, 1 insertions(+), 1 deletions(-)
> >
> > diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
> > index 2ba14e7..84b2566 100644
> > --- a/arch/powerpc/Kconfig
> > +++ b/arch/powerpc/Kconfig
> > @@ -679,7 +679,7 @@ config PPC_PCI_CHOICE
> > config PCI
> > bool "PCI support" if PPC_PCI_CHOICE
> > default y if !40x && !CPM2 && !8xx && !PPC_83xx \
> > - && !PPC_85xx && !PPC_86xx
> > + && !PPC_85xx && !PPC_86xx && !GAMECUBE_COMMON
>
> phew, this is getting ugly. But I won't ask you to clean it up. Ack
Right. We should have the platforms that want PCI do a select
instead :-)
Cheers,
Ben.
^ permalink raw reply
* Re: [RFC PATCH 09/19] powerpc: gamecube/wii: udbg support for usbgecko
From: Benjamin Herrenschmidt @ 2009-11-26 5:12 UTC (permalink / raw)
To: Albert Herranz; +Cc: linuxppc-dev
In-Reply-To: <1258927311-4340-10-git-send-email-albert_herranz@yahoo.es>
On Sun, 2009-11-22 at 23:01 +0100, Albert Herranz wrote:
> Add support for using the USB Gecko adapter via the udbg facility on
> the Nintendo GameCube and Wii video game consoles.
> The USB Gecko is a 3rd party memory card interface adapter that provides
> a EXI (External Interface) to USB serial converter.
The main issue here is that the gecko is supposed to be something you
can plug or unplug no ? Is it hotswap or only at boot ? In the later
case, maybe the node should be created by the boot wrapper when
detecting the presence of the device. If it's hotplug, then we need
something smarter...
Cheers,
Ben.
> Signed-off-by: Albert Herranz <albert_herranz@yahoo.es>
> ---
> arch/powerpc/platforms/embedded6xx/Kconfig | 13 +
> arch/powerpc/platforms/embedded6xx/Makefile | 1 +
> arch/powerpc/platforms/embedded6xx/usbgecko_udbg.c | 285 ++++++++++++++++++++
> arch/powerpc/platforms/embedded6xx/usbgecko_udbg.h | 30 ++
> 4 files changed, 329 insertions(+), 0 deletions(-)
> create mode 100644 arch/powerpc/platforms/embedded6xx/usbgecko_udbg.c
> create mode 100644 arch/powerpc/platforms/embedded6xx/usbgecko_udbg.h
>
> diff --git a/arch/powerpc/platforms/embedded6xx/Kconfig b/arch/powerpc/platforms/embedded6xx/Kconfig
> index 31487e4..bfd88be 100644
> --- a/arch/powerpc/platforms/embedded6xx/Kconfig
> +++ b/arch/powerpc/platforms/embedded6xx/Kconfig
> @@ -95,3 +95,16 @@ config GAMECUBE_COMMON
> bool
> select NOT_COHERENT_CACHE
>
> +config USBGECKO_UDBG
> + bool "USB Gecko udbg console for the Nintendo GameCube/Wii"
> + depends on GAMECUBE_COMMON
> + help
> + If you say yes to this option, support will be included for the
> + USB Gecko adapter as an udbg console.
> + The USB Gecko is a EXI to USB Serial converter that can be plugged
> + into a memcard slot in the Nintendo GameCube/Wii.
> +
> + This driver bypasses the EXI layer completely.
> +
> + If in doubt, say N here.
> +
> diff --git a/arch/powerpc/platforms/embedded6xx/Makefile b/arch/powerpc/platforms/embedded6xx/Makefile
> index 0773c08..0ab7492 100644
> --- a/arch/powerpc/platforms/embedded6xx/Makefile
> +++ b/arch/powerpc/platforms/embedded6xx/Makefile
> @@ -7,3 +7,4 @@ obj-$(CONFIG_STORCENTER) += storcenter.o
> obj-$(CONFIG_PPC_HOLLY) += holly.o
> obj-$(CONFIG_PPC_PRPMC2800) += prpmc2800.o
> obj-$(CONFIG_PPC_C2K) += c2k.o
> +obj-$(CONFIG_USBGECKO_UDBG) += usbgecko_udbg.o
> diff --git a/arch/powerpc/platforms/embedded6xx/usbgecko_udbg.c b/arch/powerpc/platforms/embedded6xx/usbgecko_udbg.c
> new file mode 100644
> index 0000000..49f86e8
> --- /dev/null
> +++ b/arch/powerpc/platforms/embedded6xx/usbgecko_udbg.c
> @@ -0,0 +1,285 @@
> +/*
> + * arch/powerpc/platforms/embedded6xx/usbgecko_udbg.c
> + *
> + * udbg serial input/output routines for the USB Gecko adapter.
> + * Copyright (C) 2008-2009 The GameCube Linux Team
> + * Copyright (C) 2008,2009 Albert Herranz
> + *
> + * 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 <asm/io.h>
> +#include <asm/prom.h>
> +#include <asm/udbg.h>
> +
> +#include <mm/mmu_decl.h>
> +
> +#include "usbgecko_udbg.h"
> +
> +
> +#define EXI_CLK_32MHZ 5
> +
> +#define EXI_CSR 0x00
> +#define EXI_CSR_CLKMASK (0x7<<4)
> +#define EXI_CSR_CLK_32MHZ (EXI_CLK_32MHZ<<4)
> +#define EXI_CSR_CSMASK (0x7<<7)
> +#define EXI_CSR_CS_0 (0x1<<7) /* Chip Select 001 */
> +
> +#define EXI_CR 0x0c
> +#define EXI_CR_TSTART (1<<0)
> +#define EXI_CR_WRITE (1<<2)
> +#define EXI_CR_READ_WRITE (2<<2)
> +#define EXI_CR_TLEN(len) (((len)-1)<<4)
> +
> +#define EXI_DATA 0x10
> +
> +#define UG_READ_ATTEMPTS 100
> +#define UG_WRITE_ATTEMPTS 100
> +
> +
> +static void __iomem *ug_io_base;
> +
> +/*
> + * Performs one input/output transaction between the exi host and the usbgecko.
> + */
> +static u32 ug_io_transaction(u32 in)
> +{
> + u32 __iomem *csr_reg = ug_io_base + EXI_CSR;
> + u32 __iomem *data_reg = ug_io_base + EXI_DATA;
> + u32 __iomem *cr_reg = ug_io_base + EXI_CR;
> + u32 csr, data, cr;
> +
> + /* select */
> + csr = EXI_CSR_CLK_32MHZ | EXI_CSR_CS_0;
> + out_be32(csr_reg, csr);
> +
> + /* read/write */
> + data = in;
> + out_be32(data_reg, data);
> + cr = EXI_CR_TLEN(2) | EXI_CR_READ_WRITE | EXI_CR_TSTART;
> + out_be32(cr_reg, cr);
> +
> + while (in_be32(cr_reg) & EXI_CR_TSTART)
> + barrier();
> +
> + /* deselect */
> + out_be32(csr_reg, 0);
> +
> + /* result */
> + data = in_be32(data_reg);
> +
> + return data;
> +}
> +
> +/*
> + * Returns true if an usbgecko adapter is found.
> + */
> +static int ug_is_adapter_present(void)
> +{
> + if (!ug_io_base)
> + return 0;
> +
> + return ug_io_transaction(0x90000000) == 0x04700000;
> +}
> +
> +/*
> + * Returns true if the TX fifo is ready for transmission.
> + */
> +static int ug_is_txfifo_ready(void)
> +{
> + return ug_io_transaction(0xc0000000) & 0x04000000;
> +}
> +
> +/*
> + * Tries to transmit a character.
> + * If the TX fifo is not ready the result is undefined.
> + */
> +static void ug_raw_putc(char ch)
> +{
> + ug_io_transaction(0xb0000000 | (ch << 20));
> +}
> +
> +/*
> + * Transmits a character.
> + * It silently fails if the TX fifo is not ready after a number of retries.
> + */
> +static void ug_putc(char ch)
> +{
> + int count = UG_WRITE_ATTEMPTS;
> +
> + if (!ug_io_base)
> + return;
> +
> + if (ch == '\n')
> + ug_putc('\r');
> +
> + while (!ug_is_txfifo_ready() && count--)
> + barrier();
> + if (count)
> + ug_raw_putc(ch);
> +}
> +
> +#if 0
> +/*
> + * Trasmits a null terminated character string.
> + */
> +static void ug_puts(char *s)
> +{
> + while (*s)
> + ug_putc(*s++);
> +}
> +#endif
> +
> +/*
> + * Returns true if the RX fifo is ready for transmission.
> + */
> +static int ug_is_rxfifo_ready(void)
> +{
> + return ug_io_transaction(0xd0000000) & 0x04000000;
> +}
> +
> +/*
> + * Tries to receive a character.
> + * If a character is unavailable the function returns -1.
> + */
> +static int ug_raw_getc(void)
> +{
> + u32 data = ug_io_transaction(0xa0000000);
> + if (data & 0x08000000)
> + return (data >> 16) & 0xff;
> + else
> + return -1;
> +}
> +
> +/*
> + * Receives a character.
> + * It fails if the RX fifo is not ready after a number of retries.
> + */
> +static int ug_getc(void)
> +{
> + int count = UG_READ_ATTEMPTS;
> +
> + if (!ug_io_base)
> + return -1;
> +
> + while (!ug_is_rxfifo_ready() && count--)
> + barrier();
> + return ug_raw_getc();
> +}
> +
> +/*
> + * udbg functions.
> + *
> + */
> +
> +/*
> + * Transmits a character.
> + */
> +void ug_udbg_putc(char ch)
> +{
> + ug_putc(ch);
> +}
> +
> +/*
> + * Receives a character. Waits until a character is available.
> + */
> +static int ug_udbg_getc(void)
> +{
> + int ch;
> +
> + while ((ch = ug_getc()) == -1)
> + barrier();
> + return ch;
> +}
> +
> +/*
> + * Receives a character. If a character is not available, returns -1.
> + */
> +static int ug_udbg_getc_poll(void)
> +{
> + if (!ug_is_rxfifo_ready())
> + return -1;
> + return ug_getc();
> +}
> +
> +/*
> + * Retrieves and prepares the virtual address needed to access the hardware.
> + */
> +static void __iomem *ug_udbg_setup_io_base(struct device_node *np)
> +{
> + phys_addr_t paddr;
> + const unsigned int *reg;
> +
> + reg = of_get_property(np, "reg", NULL);
> + if (reg) {
> + paddr = of_translate_address(np, reg);
> + if (paddr) {
> + ug_io_base = ioremap(paddr, reg[1]);
> + return ug_io_base;
> + }
> + }
> + return NULL;
> +}
> +
> +/*
> + * USB Gecko udbg support initialization.
> + */
> +void __init ug_udbg_init(void)
> +{
> + struct device_node *np = NULL;
> + struct device_node *stdout;
> + const char *path;
> +
> + if (!of_chosen) {
> + udbg_printf("%s: missing of_chosen\n", __func__);
> + goto done;
> + }
> +
> + path = of_get_property(of_chosen, "linux,stdout-path", NULL);
> + if (!path) {
> + udbg_printf("%s: missing %s property", __func__,
> + "linux,stdout-path");
> + goto done;
> + }
> +
> + stdout = of_find_node_by_path(path);
> + if (!stdout) {
> + udbg_printf("%s: missing path %s", __func__, path);
> + goto done;
> + }
> +
> + for (np = NULL;
> + (np = of_find_compatible_node(np, NULL, "usbgecko,usbgecko"));)
> + if (np == stdout)
> + break;
> +
> + of_node_put(stdout);
> + if (!np) {
> + udbg_printf("%s: stdout is not an usbgecko", __func__);
> + goto done;
> + }
> +
> + if (!ug_udbg_setup_io_base(np)) {
> + udbg_printf("%s: failed to setup io base", __func__);
> + goto done;
> + }
> +
> + if (!ug_is_adapter_present()) {
> + udbg_printf("usbgecko_udbg: not found\n");
> + ug_io_base = NULL;
> + } else {
> + udbg_putc = ug_udbg_putc;
> + udbg_getc = ug_udbg_getc;
> + udbg_getc_poll = ug_udbg_getc_poll;
> + udbg_printf("usbgecko_udbg: ready\n");
> + }
> +
> +done:
> + if (np)
> + of_node_put(np);
> + return;
> +}
> diff --git a/arch/powerpc/platforms/embedded6xx/usbgecko_udbg.h b/arch/powerpc/platforms/embedded6xx/usbgecko_udbg.h
> new file mode 100644
> index 0000000..3929de3
> --- /dev/null
> +++ b/arch/powerpc/platforms/embedded6xx/usbgecko_udbg.h
> @@ -0,0 +1,30 @@
> +/*
> + * arch/powerpc/platforms/embedded6xx/usbgecko_udbg.h
> + *
> + * udbg serial input/output routines for the USB Gecko adapter.
> + * Copyright (C) 2008-2009 The GameCube Linux Team
> + * Copyright (C) 2008,2009 Albert Herranz
> + *
> + * 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 __USBGECKO_UDBG_H
> +#define __USBGECKO_UDBG_H
> +
> +#ifdef CONFIG_USBGECKO_UDBG
> +
> +extern void __init ug_udbg_init(void);
> +
> +#else
> +
> +static inline void __init ug_udbg_init(void)
> +{
> +}
> +
> +#endif /* CONFIG_USBGECKO_UDBG */
> +
> +#endif /* __USBGECKO_UDBG_H */
^ permalink raw reply
* Re: [RFC PATCH 10/19] powerpc: gamecube/wii: early debugging using usbgecko
From: Benjamin Herrenschmidt @ 2009-11-26 5:14 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: Albert Herranz, linuxppc-dev
In-Reply-To: <200911222327.37949.arnd@arndb.de>
On Sun, 2009-11-22 at 23:27 +0100, Arnd Bergmann wrote:
>
> This will probably break other platforms if
> CONFIG_PPC_EARLY_DEBUG_USBGECKO
> is set. In general, we try hard to make it possible to build generic
> kernels for multiple systems, so it would be better to also add a
> runtime check here.
No Arnd. The whole point of EARLY_DEBUG is that it is -known- to break
other platforms :-) So that we can use it before we even get to probe
anything.
I am still tempted, one day, to change the kernel early init to setup a
stack in .bss and go straight to C to do that sort of stuff by parsing
the flat DT, this could be done using pretty much completely generic
code :-) But not right now.
Cheers,
Ben.
^ permalink raw reply
* Make the kernel accept ePAPR style phandle information
From: David Gibson @ 2009-11-26 5:16 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev, devicetree-discuss
Grant, this is based on your test-devicetree branch, if it could be
merged via there would be great.
Currently when processing flattened device trees, the kernel expects
the phandle in a property called "linux,phandle". The ePAPR spec -
not being Linux specific - instead requires phandles to be encoded in
a property named simply "phandle". This patch makes the kernel accept
either form when unflattening the device tree.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Index: working-2.6/drivers/of/fdt.c
===================================================================
--- working-2.6.orig/drivers/of/fdt.c 2009-11-26 09:58:06.052792325 +1100
+++ working-2.6/drivers/of/fdt.c 2009-11-26 10:00:08.309570256 +1100
@@ -314,10 +314,19 @@ unsigned long __init unflatten_dt_node(u
pp = unflatten_dt_alloc(&mem, sizeof(struct property),
__alignof__(struct property));
if (allnextpp) {
- if (strcmp(pname, "linux,phandle") == 0) {
+ /* We accept flattened tree phandles either in
+ * ePAPR-style "phandle" properties, or the
+ * legacy "linux,phandle" properties. If both
+ * appear and have different values, things
+ * will get weird. Don't do that. */
+ if ((strcmp(pname, "phandle") == 0)
+ || (strcmp(pname, "linux,phandle") == 0)) {
if (np->phandle == 0)
np->phandle = *((u32 *)*p);
}
+ /* And we process the "ibm,phandle" property
+ * used in pSeries dynamic device tree
+ * stuff */
if (strcmp(pname, "ibm,phandle") == 0)
np->phandle = *((u32 *)*p);
pp->name = pname;
--
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
^ permalink raw reply
* Re: [RFC PATCH 11/19] powerpc: gamecube/wii: flipper interrupt controller support
From: Benjamin Herrenschmidt @ 2009-11-26 5:18 UTC (permalink / raw)
To: Albert Herranz; +Cc: linuxppc-dev
In-Reply-To: <1258927311-4340-12-git-send-email-albert_herranz@yahoo.es>
On Sun, 2009-11-22 at 23:01 +0100, Albert Herranz wrote:
> +static void flipper_pic_mask_and_ack(unsigned int virq)
> +{
> + int irq = virq_to_hw(virq);
> + void __iomem *io_base = get_irq_chip_data(virq);
> +
> + clear_bit(irq, io_base + FLIPPER_IMR);
> + set_bit(irq, io_base + FLIPPER_ICR);
> +}
Do not use clear_bit and set_bit on IOs. They will do lwarx/stwcx. which
is really not what you want. You can use __clear_bit and __set_bit but
it's still fishy. Those operate on unsigned long, so the size vary
between 32 and 64 bit etc... not something you care that much about, but
it's still the wrong tool for the job.
Do those guys have more than 32 interrupts ? If not, just hand
code the msak & shifts. If they do, then maybe stick with __clear_bit()
and __set_bit() which are the non atomic variants.
Cheers,
Ben.
^ permalink raw reply
* Re: [RFC PATCH 11/19] powerpc: gamecube/wii: flipper interrupt controller support
From: Benjamin Herrenschmidt @ 2009-11-26 5:18 UTC (permalink / raw)
To: Grant Likely; +Cc: Albert Herranz, linuxppc-dev
In-Reply-To: <fa686aa40911221528y1980a95bw1dc8aa75a86c061e@mail.gmail.com>
On Sun, 2009-11-22 at 16:28 -0700, Grant Likely wrote:
> > +unsigned int flipper_pic_get_irq(void)
> > +{
> > + void __iomem *io_base = flipper_irq_host->host_data;
> > + int irq;
> > + u32 irq_status;
> > +
> > + irq_status = in_be32(io_base + FLIPPER_ICR) &
> > + in_be32(io_base + FLIPPER_IMR);
> > + if (irq_status == 0)
> > + return -1; /* no more IRQs pending */
>
> NO_IRQ_IGNORE
Why no just 0 ? (aka NO_IRQ)
Or do you know you are getting lots of spurrious that you don't want to
account ?
Cheers,
Ben.
^ permalink raw reply
* Re: [RFC PATCH 14/19] powerpc: allow ioremap within reserved fake ram regions
From: Benjamin Herrenschmidt @ 2009-11-26 5:22 UTC (permalink / raw)
To: Albert Herranz; +Cc: linuxppc-dev
In-Reply-To: <4B0C1337.6070309@yahoo.es>
On Tue, 2009-11-24 at 18:09 +0100, Albert Herranz wrote:
> I could use ppc_md.ioremap to duplicate ioremap except for the ioremap
> ram check.
> But calling the stock ioremap without modifying it is not possible
> because it checks and bails out when ioremapping a region marked as
> ram (even if it's not real ram and it's memreserved).
>
> Is the list of memreserved areas preserved once the kernel is running?
> If it is preserved another option would be to unban ioremapping ram if
> memreserved.
Yes, check lmb's they should still be around.
Cheers,
Ben.
^ permalink raw reply
* Re: [RFC PATCH 16/19] powerpc: wii: hollywood interrupt controller support
From: Benjamin Herrenschmidt @ 2009-11-26 5:23 UTC (permalink / raw)
To: Albert Herranz; +Cc: linuxppc-dev
In-Reply-To: <1258927311-4340-17-git-send-email-albert_herranz@yahoo.es>
On Sun, 2009-11-22 at 23:01 +0100, Albert Herranz wrote:
> +static void hlwd_pic_mask_and_ack(unsigned int virq)
> +{
> + int irq = virq_to_hw(virq);
> + void __iomem *io_base = get_irq_chip_data(virq);
> +
> + clear_bit(irq, io_base + HW_BROADWAY_IMR);
> + set_bit(irq, io_base + HW_BROADWAY_ICR);
> +}
Same comment as with flipper. BTW. It looks really similar, can't you
use the same driver ?
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH 04/11] of/flattree: eliminate cell_t typedef
From: Benjamin Herrenschmidt @ 2009-11-26 5:27 UTC (permalink / raw)
To: Grant Likely
Cc: sfr, monstr, microblaze-uclinux, devicetree-discuss, sparclinux,
linuxppc-dev, davem
In-Reply-To: <fa686aa40911252005o2db85dfk3d9acc61c12ca5e5@mail.gmail.com>
On Wed, 2009-11-25 at 21:05 -0700, Grant Likely wrote:
>
> You're right, it's not, but makes merging less complex, and then I can
> refactor properly.
Still, make them __be32 at least
Cheers,
Ben.
^ permalink raw reply
* Re: [RFC PATCH 02/19] powerpc: gamecube: device tree
From: Benjamin Herrenschmidt @ 2009-11-26 5:29 UTC (permalink / raw)
To: Grant Likely; +Cc: Albert Herranz, linuxppc-dev
In-Reply-To: <fa686aa40911252038y37da8c72y54314a6cc337fc66@mail.gmail.com>
On Wed, 2009-11-25 at 21:38 -0700, Grant Likely wrote:
>
> But this isn't real OF. Real OF can generate its own valid tree.
> This is a flat tree, and it is valid according to all users of the
> flat tree. Besides, the last time we talked about this, you told me
> that moving it to the root was a good idea, and I happily changed all
> the 5200 .dts files. :-)
>
> http://lists.ozlabs.org/pipermail/linuxppc-dev/2009-January/067046.html
Oh sure. I wasn't sure what the situation vs. real OF was. I just know
Segher is doing one and it would be nice to have the closest tree :-)
But no big deal, I'm happy with it at the root. I prefer not ommiting it
completely tho.
Cheers,
Ben.
^ permalink raw reply
* Re: Make the kernel accept ePAPR style phandle information
From: Grant Likely @ 2009-11-26 5:46 UTC (permalink / raw)
To: Grant Likely, linuxppc-dev, devicetree-discuss
In-Reply-To: <20091126051641.GB27334@yookeroo>
On Wed, Nov 25, 2009 at 10:16 PM, David Gibson
<david@gibson.dropbear.id.au> wrote:
> Grant, this is based on your test-devicetree branch, if it could be
> merged via there would be great.
>
> Currently when processing flattened device trees, the kernel expects
> the phandle in a property called "linux,phandle". =A0The ePAPR spec -
> not being Linux specific - instead requires phandles to be encoded in
> a property named simply "phandle". =A0This patch makes the kernel accept
> either form when unflattening the device tree.
>
> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Looks okay to me.
g.
>
> Index: working-2.6/drivers/of/fdt.c
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> --- working-2.6.orig/drivers/of/fdt.c =A0 2009-11-26 09:58:06.052792325 +=
1100
> +++ working-2.6/drivers/of/fdt.c =A0 =A0 =A0 =A02009-11-26 10:00:08.30957=
0256 +1100
> @@ -314,10 +314,19 @@ unsigned long __init unflatten_dt_node(u
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0pp =3D unflatten_dt_alloc(&mem, sizeof(str=
uct property),
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0__alignof__(struct property));
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0if (allnextpp) {
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 if (strcmp(pname, "linux,ph=
andle") =3D=3D 0) {
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 /* We accept flattened tree=
phandles either in
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0* ePAPR-style "phandle" =
properties, or the
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0* legacy "linux,phandle"=
properties. =A0If both
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0* appear and have differ=
ent values, things
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0* will get weird. =A0Don=
't do that. */
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 if ((strcmp(pname, "phandle=
") =3D=3D 0)
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 || (strcmp(pname, "=
linux,phandle") =3D=3D 0)) {
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0if (np->ph=
andle =3D=3D 0)
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0np->phandle =3D *((u32 *)*p);
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0}
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 /* And we process the "ibm,=
phandle" property
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0* used in pSeries dynami=
c device tree
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0* stuff */
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0if (strcmp(pname, "ibm,pha=
ndle") =3D=3D 0)
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0np->phandl=
e =3D *((u32 *)*p);
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0pp->name =3D pname;
>
>
> --
> David Gibson =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| I'll have my music =
baroque, and my code
> david AT gibson.dropbear.id.au =A0| minimalist, thank you. =A0NOT _the_ _=
other_
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| _way_ _a=
round_!
> http://www.ozlabs.org/~dgibson
>
--=20
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: [RFC PATCH 02/19] powerpc: gamecube: device tree
From: Grant Likely @ 2009-11-26 5:51 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: Albert Herranz, linuxppc-dev
In-Reply-To: <1259213345.16367.275.camel@pasglop>
On Wed, Nov 25, 2009 at 10:29 PM, Benjamin Herrenschmidt
<benh@kernel.crashing.org> wrote:
> On Wed, 2009-11-25 at 21:38 -0700, Grant Likely wrote:
>>
>> But this isn't real OF. =A0Real OF can generate its own valid tree.
>> This is a flat tree, and it is valid according to all users of the
>> flat tree. =A0Besides, the last time we talked about this, you told me
>> that moving it to the root was a good idea, and I happily changed all
>> the 5200 .dts files. =A0:-)
>>
>> http://lists.ozlabs.org/pipermail/linuxppc-dev/2009-January/067046.html
>
> Oh sure. I wasn't sure what the situation vs. real OF was. I just know
> Segher is doing one and it would be nice to have the closest tree :-)
>
> But no big deal, I'm happy with it at the root. I prefer not ommiting it
> completely tho.
agreed.
g.
--=20
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: [PATCH 04/11] of/flattree: eliminate cell_t typedef
From: M. Warner Losh @ 2009-11-26 6:28 UTC (permalink / raw)
To: grant.likely
Cc: sfr, devicetree-discuss, microblaze-uclinux, sparclinux,
linuxppc-dev, davem
In-Reply-To: <fa686aa40911252005o2db85dfk3d9acc61c12ca5e5@mail.gmail.com>
In message: <fa686aa40911252005o2db85dfk3d9acc61c12ca5e5@mail.gmail.com>
Grant Likely <grant.likely@secretlab.ca> writes:
: Word from Mitch is the device tree is network byte order. period.
OpenFirmware defines the order to be big endian always, even on little
endian processors.
Warner
^ permalink raw reply
* Re: [PATCH 04/11] of/flattree: eliminate cell_t typedef
From: Benjamin Herrenschmidt @ 2009-11-26 7:06 UTC (permalink / raw)
To: M. Warner Losh
Cc: sfr, microblaze-uclinux, devicetree-discuss, sparclinux,
linuxppc-dev, davem
In-Reply-To: <20091125.232818.-1350498258.imp@bsdimp.com>
On Wed, 2009-11-25 at 23:28 -0700, M. Warner Losh wrote:
> In message:
> <fa686aa40911252005o2db85dfk3d9acc61c12ca5e5@mail.gmail.com>
> Grant Likely <grant.likely@secretlab.ca> writes:
> : Word from Mitch is the device tree is network byte order. period.
>
> OpenFirmware defines the order to be big endian always, even on little
> endian processors.
Right, that's the only sane way to do it, I just didn't remember off
hand what was said in the OF spec :-)
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH] [PPC4xx] Fix device tree dts file for katmai board.
From: Stefan Roese @ 2009-11-26 7:22 UTC (permalink / raw)
To: Pravin Bathija; +Cc: linuxppc-dev
In-Reply-To: <1259017573-27985-1-git-send-email-pbathija@amcc.com>
On Tuesday 24 November 2009 00:06:13 Pravin Bathija wrote:
> Description: Set PCI-E node inbound DMA ranges size to 4GB for correct
> boot up of katmai. Including only changes for PCI-E DMA ranges as
> suggested by Stefan.
>
> Signed-off-by: Pravin Bathija <pbathija@amcc.com>
> Acked-by: Feng Kan <fkan@amcc.com>
> Acked-by: Prodyut Hazarika <phazarika@amcc.com>
> Acked-by: Loc Ho <lho@amcc.com>
> Acked-by: Tirumala Reddy Marri <tmarri@amcc.com>
> Acked-by: Victor Gallardo <vgallardo@amcc.com>
Acked-by: Stefan Roese <sr@denx.de>
Cheers,
Stefan
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox