* [-next Nov 25] eHEA driver failure during boot.
From: Sachin Sant @ 2009-11-26 8:36 UTC (permalink / raw)
To: Linux/PPC Development
Cc: Stephen Rothwell, HERING2, linux-next, Jan-Bernd Themann
In-Reply-To: <20091125235333.37c425ec.sfr@canb.auug.org.au>
eHEA driver fails to initialize on a power6 box while booting
20091125 next(f3645ca..). Following are the messages which gets
logged during failure.
Unable to handle kernel paging request for data at address 0x409d0148e8e40018
Faulting instruction address: 0xc00000000003c0cc
Oops: Kernel access of bad area, sig: 11 [#1]
SMP NR_CPUS=1024 NUMA pSeries
Modules linked in: fuse loop dm_mod sr_mod cdrom ehea sg sd_mod crc_t10dif ibmvscsic scsi_transport_srp scsi_tgt scsi_mod
NIP: c00000000003c0cc LR: c00000000003ce50 CTR: 0000000000091b94
REGS: c00000000cade820 TRAP: 0300 Not tainted (2.6.32-rc8-autotest-next-20091125)
MSR: 8000000000001032 <ME,IR,DR> CR: 28020424 XER: 00000020
DAR: 409d0148e8e40018, DSISR: 0000000040000000
TASK = c00000000c818d60[1683] 'ip' THREAD: c00000000cadc000 CPU: 1
GPR00: 0000000000000010 c00000000cadeaa0 c000000000b28340 409d0148e8e40008
GPR04: d00008008000f040 c00000000cadeb20 0000000000001000 0000000000000000
GPR08: 000000000000001c c0000000018c0398 0000000000000000 c000000000bc0000
GPR12: 8000000000009032 c000000000bc2880 00000000ffffffff ffffffffffffffff
GPR16: 00000000203c8fc0 c00000000cadf4a8 c00000000cadf450 c00000000e4c0000
GPR20: 0000000000000300 0000000000000201 c000000000c68590 c000000000bc0000
GPR24: 0000000000000000 0000000000e5f87e 0000000000000001 c000000009920000
GPR28: 0000000000000000 d00008008000f040 0000000000000000 c000000000a63328
NIP [c00000000003c0cc] .subpage_protection+0x48/0x8c
LR [c00000000003ce50] .hash_page+0x3e0/0x45c
Call Trace:
[c00000000cadeaa0] [00000000ffffffff] 0xffffffff (unreliable)
[c00000000cadeb90] [c0000000000055d0] .do_hash_page+0x50/0x6c
--- Exception: 301 at .ehea_create_cq+0x234/0x2bc [ehea]
LR = .ehea_create_cq+0x1c0/0x2bc [ehea]
[c00000000cadef40] [d0000000015e46fc] .ehea_init_port_res+0xb4/0x47c [ehea]
[c00000000cadf000] [d0000000015e4bd8] .ehea_up+0x114/0x6bc [ehea]
[c00000000cadf110] [d0000000015e51e0] .ehea_open+0x60/0x114 [ehea]
[c00000000cadf1b0] [c000000000542e7c] .dev_open+0x11c/0x19c
[c00000000cadf240] [c000000000541e7c] .dev_change_flags+0x10c/0x214
[c00000000cadf2e0] [c00000000054e0f8] .do_setlink+0x304/0x41c
[c00000000cadf3c0] [c00000000054f324] .rtnl_newlink+0x388/0x600
[c00000000cadf5d0] [c00000000054ef50] .rtnetlink_rcv_msg+0x260/0x2ac
[c00000000cadf680] [c000000000568104] .netlink_rcv_skb+0x74/0x108
[c00000000cadf710] [c00000000054eccc] .rtnetlink_rcv+0x34/0x58
[c00000000cadf7a0] [c000000000567bfc] .netlink_unicast+0x32c/0x408
[c00000000cadf870] [c0000000005688d8] .netlink_sendmsg+0x2d0/0x310
[c00000000cadf950] [c000000000529c9c] .sock_sendmsg+0xe0/0x11c
[c00000000cadfb50] [c000000000529fc8] .SyS_sendmsg+0x1f4/0x288
[c00000000cadfd70] [c000000000527f88] .SyS_socketcall+0x214/0x280
[c00000000cadfe30] [c0000000000085b4] syscall_exit+0x0/0x40
Instruction dump:
78000020 7fa40040 409d0020 7889aae0 39290072 79291f24 7d2b4a14 e8690010
2fa30000 419e0048 788014e2 78001f24 <7c63002a> 2fa30000 419e0034 788084a2
---[ end trace cacb4bbddb53f7bd ]---
Thanks
-Sachin
--
---------------------------------
Sachin Sant
IBM Linux Technology Center
India Systems and Technology Labs
Bangalore, India
---------------------------------
^ permalink raw reply
* Re: [PATCH] zlib: Optimize inffast when copying direct from output
From: Joakim Tjernlund @ 2009-11-26 8:30 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev@ozlabs.org
In-Reply-To: <1259032363.16367.108.camel@pasglop>
Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote on 24/11/2009 04:12:43:
>
> On Tue, 2009-11-10 at 10:00 +0100, Joakim Tjernlund wrote:
> > JFFS2 uses lesser compression ratio and inflate always
> > ends up in "copy direct from output" case.
> > This patch tries to optimize the direct copy procedure.
> > Uses get_unaligned() but only in one place.
> > The copy loop just above this one can also use this
> > optimization, but I havn't done so as I have not tested if it
> > is a win there too.
> > On my MPC8321 this is about 17% faster on my JFFS2 root FS
> > than the original.
> > ---
> >
> > Would like some testing of the PowerPC boot wrapper and
> > a LE target before sending it upstream.
>
> Well, you should probably submit that patch to lkml then :-)
I have(with LE fixes), Andrew Morton has it.
>
> I'm not sure its going to work to use get_unaligned() like that on all
> archs .. it might be definitely something to discuss on some more
> appropriate mailing list.
Oh, why not? Is that because I am using it wrongly or because xx_unaligned
is impl. incorrectly on some archs?
Jocke
^ permalink raw reply
* Re: [RFC PATCH 03/19] powerpc: gamecube: bootwrapper bits
From: Gabriel Paubert @ 2009-11-26 8:17 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: Albert Herranz, linuxppc-dev
In-Reply-To: <1259210216.16367.249.camel@pasglop>
On Thu, Nov 26, 2009 at 03:36:56PM +1100, Benjamin Herrenschmidt wrote:
> 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.
Hmm, this really depends on whether the DMA transfers generate bus cycles
that require coherency or not. Not the other way around. M=1 only forces
bus cycles to be snooped by other processors (asserting the GBL signal
on 603/604/750 busses).
The host bridge is free to systematically snoop processor accesses (to make
sure that data queued in the bridge and not yet written to memory is seen
in the coherent memory domain even if, for example, interrupts propagate
so fast that DMA target addresses are accessed before it is written to RAM).
On memory coherent systems, the host bridge has to assert the GBL signal,
to force data to be written to memory (for most DMA accesses), or to
invalidate caches (for full line writes from devices).
Gabriel
^ permalink raw reply
* [PATCH] powerpc/mm: honor O_SYNC flag for memory mapping
From: Li Yang @ 2009-11-26 8:02 UTC (permalink / raw)
To: benh, linuxppc-dev
There was no way to set mapped memory as cacheable if the memory
is not managed by Linux kernel. It's not rare in real system to
allocate some dedicated memory to a certain application which is not
managed by kernel and then mmap'ed the memory to the application.
The memory should be cacheable but we can't map it to be cacheable
due to the intelligent setting of cacheability.
The patch makes the cacheability depend on O_SYNC flag of the file
mapped for non-kernel managed memory. Also prints a deprecation
warning for mmap users without using O_SYNC.
Signed-off-by: Li Yang <leoli@freescale.com>
---
arch/powerpc/mm/mem.c | 13 +++++++++++--
1 files changed, 11 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/mm/mem.c b/arch/powerpc/mm/mem.c
index 579382c..b9ef77a 100644
--- a/arch/powerpc/mm/mem.c
+++ b/arch/powerpc/mm/mem.c
@@ -101,8 +101,17 @@ pgprot_t phys_mem_access_prot(struct file *file, unsigned long pfn,
if (ppc_md.phys_mem_access_prot)
return ppc_md.phys_mem_access_prot(file, pfn, size, vma_prot);
- if (!page_is_ram(pfn))
- vma_prot = pgprot_noncached(vma_prot);
+ /* kernel managed memory is always cacheable, otherwise is controlled
+ * by O_SYNC flag of open() */
+ if (!page_is_ram(pfn)) {
+ if (file->f_flags & O_SYNC)
+ vma_prot = pgprot_noncached(vma_prot);
+ else
+ printk(KERN_WARNING
+ "Warning: mmap on file without O_SYNC will be "
+ "mapped as cacheable. Make sure it is desired."
+ "\n");
+ }
return vma_prot;
}
--
1.6.4
^ permalink raw reply related
* Re: [PATCH 04/11] of/flattree: eliminate cell_t typedef
From: Mitch Bradley @ 2009-11-26 7:52 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: sfr, microblaze-uclinux, devicetree-discuss, sparclinux,
linuxppc-dev, davem, M. Warner Losh
In-Reply-To: <1259219171.16367.331.camel@pasglop>
>
> Right, that's the only sane way to do it, I just didn't remember off
> hand what was said in the OF spec :-)
3.2.2.1.2 Property values
The property-encoding format is independent of hardware byte order and
alignment characteristics. The encoded byte order is well-defined (in
particular, it is big endian). ...
...
-- 32-bit integer. A 32-bit integer is encoded into a property value
byte array by storing the most significant byte at the next available
address, followed (at address+1) by the high middle byte, the low middle
byte, and (at address+3) the least significant byte.
^ permalink raw reply
* Re: [RFC] powerpc/mm: honor O_SYNC flag for memory map
From: Li Yang @ 2009-11-26 7:43 UTC (permalink / raw)
To: Gabriel Paubert; +Cc: linuxppc-dev, Li Yang-R58472
In-Reply-To: <20091125113023.GC12738@iram.es>
On Wed, Nov 25, 2009 at 7:30 PM, Gabriel Paubert <paubert@iram.es> wrote:
> On Wed, Nov 25, 2009 at 04:07:46PM +0800, Li Yang wrote:
>> On Sun, Nov 22, 2009 at 4:01 AM, Segher Boessenkool
>> <segher@kernel.crashing.org> wrote:
>> >>> You need to be a bit more careful tho. You must not allow RAM manage=
d by
>> >>> the kernel to be mapped non-cachable.
>> >>
>> >> Even if the user explicitly sets the O_SYNC flag? =C2=A0IMHO, it's a =
bug of
>> >> the application if it uses O_SYNC on main memory to be mmap'ed later.
>> >> And we don't need to cover up the bug.
>> >
>> > Is that "embedded thinking"? =C2=A0Conflicts like this cause machine c=
hecks or
>> > checkstops on many PowerPC implementations, we do not normally allow s=
uch
>> > to be caused by userland.
>>
>> So what you are saying is that if the kernel has mapped a physical
>> page as cacheable while user application is trying to map it as
>> non-cacheable, there will be machine checks and checkstops rather than
>> just performance drop? =C2=A0This is new to me. =C2=A0Could you elaborat=
e a bit?
>
> That's called cache paradoxes. And yes they may be a problem.
Thanks. I will prevent this from happening.
>
> Besides that, existing =C2=A0application may have used mmap without O_SYN=
C on
> I/O devices, knowing that the kernel would map them uncached. Your
> patch would break them by using cached accesses (and it can cause
> really hard to debug lockups, I've seen this, probably caused by
> infinite retries on the PCI bus).
That's my concern too. But after all mmap without O_SYNC on I/O
devices should be deprecated. A warning message in deprecation period
could reduce potential problem caused by this change.
- Leo
^ 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
* 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 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: [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: 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: 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: [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 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: [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 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 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
* 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 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
* 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 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: [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 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: [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 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
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