* Re: Bamboo PCI interrupt issues
From: Benjamin Herrenschmidt @ 2008-03-04 20:41 UTC (permalink / raw)
To: Segher Boessenkool
Cc: kvm-ppc-devel, linuxppc-dev, Stefan Roese, Hollis Blanchard
In-Reply-To: <9eeb7e8e1acf8a9217a5121fe4ec69d8@kernel.crashing.org>
On Tue, 2008-03-04 at 21:39 +0100, Segher Boessenkool wrote:
> >> Using '8' is correct. PCI interrupts are *always* level sensitive and
> >> active
> >> low.
> >
> > Unless you use one of those strange bridges that stick not gates on the
> > PCI IRQ inputs :-) But I don't think that's the case on the 440EP.
>
> More generally, the target interrupt descriptors (sense values, in
> particular) in a device tree interrupt map describe the interrupts as
> seen on the target interrupt controller, *not* as seen on this (source)
> interrupt domain. This should be obvious, but since the source
> interrupt
> descriptor for PCI doesn't have a sense value (it's always level low,
> after all), it can be confusing. Well, interrupts always are confusing
> :-)
Sure. But if your stupid bridge sticks a not gate between the PIRQ input
and the UIC (interrupt controller), effectively, the UIC sees a reversed
polarity. Thus you need to put in your interrupt map a reversed polarity
information for the UIC interrupt specifiers.
Ben.
^ permalink raw reply
* Re: [BUG] 2.6.25-rc3-mm1 kernel panic while bootup on powerpc ()
From: Pekka Enberg @ 2008-03-04 20:44 UTC (permalink / raw)
To: Andrew Morton
Cc: linux-mm, mel, kamalesh, linuxppc-dev, stable, Christoph Lameter
In-Reply-To: <20080304123459.364f879b.akpm@linux-foundation.org>
Andrew Morton wrote:
> On Tue, 4 Mar 2008 12:07:39 -0800 (PST)
> Christoph Lameter <clameter@sgi.com> wrote:
>
>> I think this is the correct fix.
>>
>> The NUMA fallback logic should be passing local_flags to kmem_get_pages()
>> and not simply the flags.
>>
>> Maybe a stable candidate since we are now simply
>> passing on flags to the page allocator on the fallback path.
>
> Do we know why this is only reported in 2.6.25-rc3-mm1?
>
> Why does this need fixing in 2.6.24.x?
Looking at the code, it's triggerable in 2.6.24.3 at least. Why we don't
have a report yet, probably because (1) the default allocator is SLUB
which doesn't suffer from this and (2) you need a big honkin' NUMA box
that causes fallback allocations to happen to trigger it.
Pekka
^ permalink raw reply
* Re: [PATCH] [POWERPC] (testers ?) Fix sleep on some powerbooks
From: Gaudenz Steinlin @ 2008-03-04 20:21 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: debian-powerpc, linuxppc-dev
In-Reply-To: <20080304161518.GA4523@localhost>
Hi Ben
On Tue, Mar 04, 2008 at 05:15:18PM +0100, Wolfgang Pfeiffer wrote:
> Hi Ben, Gaudenz - Hi All
>
> On Mon, Mar 03 2008, at 17:27 +1100, Benjamin Herrenschmidt wrote:
> > The PMU backlight code would kick in during sleep/resume even on
> > machines that use a different backlight method. This appears to
> > break sleep on my PowerBook, though I can't test that patch at
> > the moment as the machine died while I was bisecting.
> >
> > So if anybody around has one of those latest revision PowerPC
> > PowerBooks, the one just before they went to Intel,
>
> yes, I think so:
>
> $ cat /proc/cpuinfo
> processor : 0
> cpu : 7447A, altivec supported
> clock : 1666.666000MHz
> revision : 0.5 (pvr 8003 0105)
> bogomips : 33.15
> timebase : 8320000
> platform : PowerMac
> machine : PowerBook5,8
> motherboard : PowerBook5,8 MacRISC3 Power Macintosh
> detected as : 287 (PowerBook G4 15")
> pmac flags : 00000019
> L2 cache : 512K unified
> pmac-generation : NewWorld
>
>
> > and have a
> > problem with suspend/resume, please test this and let me know
> > if it helps.
>
> It helps. Thanks a lot .. :) ...
For me it fixes the problem too. I have the same machine.
Gaudenz
--
Ever tried. Ever failed. No matter.
Try again. Fail again. Fail better.
~ Samuel Beckett ~
^ permalink raw reply
* Re: Bamboo PCI interrupt issues
From: Segher Boessenkool @ 2008-03-04 20:59 UTC (permalink / raw)
To: benh; +Cc: kvm-ppc-devel, linuxppc-dev, Stefan Roese, Hollis Blanchard
In-Reply-To: <1204663317.21545.73.camel@pasglop>
>> More generally, the target interrupt descriptors (sense values, in
>> particular) in a device tree interrupt map describe the interrupts as
>> seen on the target interrupt controller, *not* as seen on this
>> (source)
>> interrupt domain. This should be obvious, but since the source
>> interrupt
>> descriptor for PCI doesn't have a sense value (it's always level low,
>> after all), it can be confusing. Well, interrupts always are
>> confusing
>> :-)
>
> Sure. But if your stupid bridge sticks a not gate between the PIRQ
> input
> and the UIC (interrupt controller), effectively, the UIC sees a
> reversed
> polarity. Thus you need to put in your interrupt map a reversed
> polarity
> information for the UIC interrupt specifiers.
That's what I said, isn't it? :-)
Segher
^ permalink raw reply
* Re: Bamboo PCI interrupt issues
From: Benjamin Herrenschmidt @ 2008-03-04 21:01 UTC (permalink / raw)
To: Segher Boessenkool
Cc: kvm-ppc-devel, linuxppc-dev, Stefan Roese, Hollis Blanchard
In-Reply-To: <1a852cd10d2aab54aaa7d810649ab1b3@kernel.crashing.org>
On Tue, 2008-03-04 at 21:59 +0100, Segher Boessenkool wrote:
> >> More generally, the target interrupt descriptors (sense values, in
> >> particular) in a device tree interrupt map describe the interrupts as
> >> seen on the target interrupt controller, *not* as seen on this
> >> (source)
> >> interrupt domain. This should be obvious, but since the source
> >> interrupt
> >> descriptor for PCI doesn't have a sense value (it's always level low,
> >> after all), it can be confusing. Well, interrupts always are
> >> confusing
> >> :-)
> >
> > Sure. But if your stupid bridge sticks a not gate between the PIRQ
> > input
> > and the UIC (interrupt controller), effectively, the UIC sees a
> > reversed
> > polarity. Thus you need to put in your interrupt map a reversed
> > polarity
> > information for the UIC interrupt specifiers.
>
> That's what I said, isn't it? :-)
Maybe, I wasn't sure I decrypted you properly :-)
Ben.
^ permalink raw reply
* Re: [PATCH] [POWERPC] (testers ?) Fix sleep on some powerbooks
From: Wolfgang Pfeiffer @ 2008-03-04 21:28 UTC (permalink / raw)
To: debian-powerpc; +Cc: linuxppc-dev
In-Reply-To: <20080304161518.GA4523@localhost>
On Tue, Mar 04 2008, at 17:15 +0100, Wolfgang Pfeiffer wrote:
>
>
> [ ... ]
> I uploaded this fresh kernel .deb, patched with your code, up to
> rapidshare:
> http://rapidshare.com/files/96992135/linux-image-2.6.25-rc3-g7704a8b-with-ben.s-pmu-patch_2008.02.29_powerpc.deb.html
>
> md5sum for the file above is 7a7613e0c52e179acf7caacaa3890901
"the file" should say:
linux-image-2.6.25-rc3-g7704a8b-with-ben.s-pmu-patch_2008.02.29_powerpc.deb
Sorry for the overhead ...
Regards
--
Wolfgang
http://heelsbroke.blogspot.com/
http://keyserver.mine.nu/pks/lookup?search=0xE3037113&fingerprint=on
^ permalink raw reply
* Re: V4L2: __ucmpdi2 undefined on ppc
From: Paul Mackerras @ 2008-03-04 21:44 UTC (permalink / raw)
To: Segher Boessenkool
Cc: linuxppc-dev, henrik.sorensen, Stephane Marchesin,
David Woodhouse
In-Reply-To: <15d7ac5a7542b05fb9b9abb5d4c7a22d@kernel.crashing.org>
Segher Boessenkool writes:
> Every occurrence of r7 here is wrong (and some of the r6). Is there
> any reason to do this in assembler code at all?
The fact that the obvious C code generates ... a call to __ucmpdi2? :)
Paul.
^ permalink raw reply
* Re: [BUG] 2.6.25-rc3-mm1 kernel panic while bootup on powerpc ()
From: Christoph Lameter @ 2008-03-04 21:44 UTC (permalink / raw)
To: Pekka Enberg; +Cc: linux-mm, mel, kamalesh, linuxppc-dev, Andrew Morton, stable
In-Reply-To: <47CDB498.6040003@cs.helsinki.fi>
On Tue, 4 Mar 2008, Pekka Enberg wrote:
> Looking at the code, it's triggerable in 2.6.24.3 at least. Why we don't have
> a report yet, probably because (1) the default allocator is SLUB which doesn't
> suffer from this and (2) you need a big honkin' NUMA box that causes fallback
> allocations to happen to trigger it.
Plus the issue only became a problem after the antifrag stuff went in.
That came with SLUB as the default.
^ permalink raw reply
* Re: V4L2: __ucmpdi2 undefined on ppc
From: Scott Wood @ 2008-03-04 21:47 UTC (permalink / raw)
To: Paul Mackerras
Cc: linuxppc-dev, henrik.sorensen, Stephane Marchesin,
David Woodhouse
In-Reply-To: <18381.49853.255430.142431@cargo.ozlabs.ibm.com>
Paul Mackerras wrote:
> Segher Boessenkool writes:
>
>> Every occurrence of r7 here is wrong (and some of the r6). Is there
>> any reason to do this in assembler code at all?
>
> The fact that the obvious C code generates ... a call to __ucmpdi2? :)
So use the correct C code, not the obvious C code. :-)
-Scott
^ permalink raw reply
* Re: [BUG] 2.6.25-rc3-mm1 kernel bug while running libhugetlbfs
From: Adam Litke @ 2008-03-04 22:01 UTC (permalink / raw)
To: Andrew Morton; +Cc: linuxppc-dev, balbir, linux-kernel, Kamalesh Babulal
In-Reply-To: <20080304115158.505f33eb.akpm@linux-foundation.org>
On Tue, 2008-03-04 at 11:51 -0800, Andrew Morton wrote:
> hugetlb-correct-page-count-for-surplus-huge-pages.patch adds:
>
> if (page) {
> /*
> * This page is now managed by the hugetlb allocator and has
> * no users -- drop the buddy allocator's reference.
> */
> int page_count = put_page_testzero(page);
> BUG_ON(page_count != 0);
>
>
Ugh I got bitten by put_page_testzero(). When it returns 1, the page
count is zero (not the page count).
My initial version had a BUG_ON() with side-effects. When a reviewer
pointed it out, I thought I could fix the patch up on its way out the
door. I have self-administered my punishment. This patch will fix it:
Signed-off-by: Adam Litke <agl@us.ibm.com>
--- mm/hugetlb.c.orig 2008-03-04 13:36:30.000000000 -0800
+++ mm/hugetlb.c 2008-03-04 13:39:30.000000000 -0800
@@ -291,8 +291,8 @@ static struct page *alloc_buddy_huge_pag
* This page is now managed by the hugetlb allocator and has
* no users -- drop the buddy allocator's reference.
*/
- int page_count = put_page_testzero(page);
- BUG_ON(page_count != 0);
+ put_page_testzero(page);
+ VM_BUG_ON(page_count(page));
nid = page_to_nid(page);
set_compound_page_dtor(page, free_huge_page);
/*
--
Adam Litke - (agl at us.ibm.com)
IBM Linux Technology Center
^ permalink raw reply
* Unable to set cache write-thru on 7447A
From: Matthew Clark @ 2008-03-04 21:56 UTC (permalink / raw)
To: Linuxppc-dev
I'm trying to run my 2.6.14 Gentoo distro on a 7447A system I have
with different cache configurations (ie, write back vs write thru) for
both the kernel, system apps (sshd, etc) and user apps. I first
wanted to run entirely in Write-Thru to get a worst-case benchmark,
but after discovering (to my chagrin) that the 7447A doesn't honor the
L2CR_L2WT bit, I tried something a bit more adventurous by setting the
WIMG bits on the linux PTE's in the arch/ppc files.
Rather, I thought I would. Nothing I've tried seems to work.
In arch/ppc/mm/ppc_mmu.c
Adding _PAGE_WRITETHRU to the _PAGE_RAM flag in the setbat calls at
lines 112 & 120 results in a kernel that won't go past the
"Uncompressing" step.
In arch/ppc/mm/pgtables.c
If I add _PAGE_WRITETHRU to the _PAGE_RAM flag in mapin_ram and
map_page allows the kernel to boot, and in fact shows no noticable
performance difference.
I found in arch/ppc/mm/hashtable.S that the linux PTE's aren't
entirely transferred into the HPTE's of the PPC, so with some
reluctance, I tried adding a line turning on WRITETHRU at line 350 in
create_hpte:
ori r8,r8,_PAGE_WRITETHRU
The kernel will come up, but init promptly dies with Signal 11.
There's little documentation on PPC Memory management & the linux
kernel, so I'm not sure what do to from here. Can anyone help me out
here? Thanks.
Matt
^ permalink raw reply
* Re: V4L2: __ucmpdi2 undefined on ppc
From: Segher Boessenkool @ 2008-03-04 22:43 UTC (permalink / raw)
To: Paul Mackerras
Cc: linuxppc-dev, henrik.sorensen, Stephane Marchesin,
David Woodhouse
In-Reply-To: <18381.49853.255430.142431@cargo.ozlabs.ibm.com>
>> Every occurrence of r7 here is wrong (and some of the r6). Is there
>> any reason to do this in assembler code at all?
>
> The fact that the obvious C code generates ... a call to __ucmpdi2? :)
Hrm? Here's the "obvious" C code, portable to all architectures
(modulo the specific types used, this isn't a proposed patch):
unsigned int ucmpdi2(unsigned long long a, unsigned long long b)
{
unsigned long ahi, bhi, alo, blo;
ahi = a >> 32;
bhi = b >> 32;
if (ahi < bhi)
return 0;
if (ahi > bhi)
return 2;
alo = a;
blo = b;
if (alo < blo)
return 0;
if (alo > blo)
return 2;
return 1;
}
(libgcc does it a bit differently, with unions and stuff).
Segher
^ permalink raw reply
* Re: [PATCH 3/4] Emerson KSI8560 device tree
From: David Gibson @ 2008-03-04 23:29 UTC (permalink / raw)
To: Alexandr Smirnov; +Cc: linuxppc-dev
In-Reply-To: <20080304163540.GD19634@ru.mvista.com>
On Tue, Mar 04, 2008 at 07:35:40PM +0300, Alexandr Smirnov wrote:
> Add device tree file for Emerson KSI8560 board.
>
> Signed-off-by: Alexandr Smirnov <asmirnov@ru.mvista.com>
[snip]
> + enet0: ethernet@24000 {
> + linux,network-index = <0>;
We're trying to get rid of this. Since I assume you're using u-boot,
I'm not sure why you'd need it now anyway.
> + device_type = "network";
> + model = "TSEC";
> + compatible = "gianfar";
This still looks like the old binding.
[snip]
> + cpld@4,0 {
> + compatible = "altera,maxii";
I'm guessing an Altera Maxii is just the name of the FPGA chip into
which the CPLD is programmed? If so, it's not a suitable "comaptible"
value, because that needs to describe the register interface. You
probably want something like
compatible = "emerson,KSI8560-cpld";
here.
--
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
* Virtual device hdlc0 asks to que packet!
From: Russell McGuire @ 2008-03-04 23:33 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <mailman.1516.1204637021.17968.linuxppc-embedded@ozlabs.org>
All,
Background MPC8360, using a T1 PHY as an HDLC device.
Developing my hdlc driver, and was writing a simple send utility. To test it
out. Things seem well when I had massive delays in between the write() or
sendot(), and I was able to attain 100+Kbytes/sec. However, when I replaced
the simple usleeps(xxx) with select statements, suddenly I started getting a
ton of these messages.
"Virtual device hdlc0 asks to que packet!"
Along with dropped or non-sent data.
In my driver I am tracking the available TX buffers, and issue a
netif_stop_que() statement inside the start_xmit() call, with a
corresponding netif_wake_que() in the tx_handler.
Is there something else that needs to be done in order to make a select
statement wait for the socket to not be busy? It seems that it always
returns immediately with no timeout.
I guess the other pieces of the scenario are as follows:
* Using 'sethdlc hdlc0 hdlc' for the mode, so no IP stack is used.
* Opening the socket to the hdlc device directly to the device itself, i.e.
no port number socket(PF_PACKET, SOCK_RAW, htons(ETH_P_ALL));
I have used both sendto() and write() to pass data down, and they both
return as if all the data has been sent, i.e. I never get an error.
-Russ
^ permalink raw reply
* Re: dtc: Make some functions local to parser
From: David Gibson @ 2008-03-05 0:38 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev
In-Reply-To: <20080304191844.GA7810@loki.buserror.net>
On Tue, Mar 04, 2008 at 01:18:44PM -0600, Scott Wood wrote:
> On Tue, Mar 04, 2008 at 03:37:00PM +1100, David Gibson wrote:
> > * The Bison documentation explicitly permits yyerror() to be a
> > variadic function, so fold yyerror() and yyerrorf() into a single
> > printf-style function.
>
> Then the bison documentation is not consistent with the bison
> implementation when verbose error messages are enabled. How can it possibly
> know whether to put % or %% in the string when an unexpected % is
> encountered?
Ah crap. I'd forgotten the specific case you mentioned before.
> Reading bison internals makes my head hurt...
>
> > The combined function is defined and used
> > only in the parse, so make it static.
>
> Static-izing something that is used externally in a posted patch where
> you've provided no alternate to use is rather bad form...
IIRC, I already asked you *not* to use it externally, though. And a
lot of these patches I've been posting lately are yak-shaving leading
up to a generally available error function.
Still, forget this patch for now.
--
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
* dtc: Make eval_literal() static
From: David Gibson @ 2008-03-05 0:47 UTC (permalink / raw)
To: Jon Loeliger; +Cc: linuxppc-dev
eval_literal() is used only in the parser, so make it a static
function.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
---
dtc-parser.y | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
Applies instead of the earlier patch that also localised yyerror().
Index: dtc/dtc-parser.y
===================================================================
--- dtc.orig/dtc-parser.y 2008-03-05 11:45:54.000000000 +1100
+++ dtc/dtc-parser.y 2008-03-05 11:46:07.000000000 +1100
@@ -24,12 +24,12 @@
#include "dtc.h"
#include "srcpos.h"
-int yylex(void);
-unsigned long long eval_literal(const char *s, int base, int bits);
+extern int yylex(void);
extern struct boot_info *the_boot_info;
extern int treesource_error;
+static unsigned long long eval_literal(const char *s, int base, int bits);
%}
%union {
@@ -330,7 +330,7 @@
yyerrorf("%s", s);
}
-unsigned long long eval_literal(const char *s, int base, int bits)
+static unsigned long long eval_literal(const char *s, int base, int bits)
{
unsigned long long val;
char *e;
--
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: [PATCH 11/17] Add memory mapping driver to RapidIO.
From: Zhang Wei @ 2008-03-05 1:59 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: linuxppc-dev, linux-kernel
In-Reply-To: <20080304213735.c77d6203.sfr@canb.auug.org.au>
Hi, Stephen,
Thanks! I'm considering to commit a updated patch or new code cleaning
patch.
How about your idea?
Cheers!
Wei=20
> -----Original Message-----
> From: Stephen Rothwell [mailto:sfr@canb.auug.org.au]=20
> Sent: Tuesday, March 04, 2008 6:38 PM
> To: Zhang Wei
> Cc: mporter@kernel.crashing.org; galak@kernel.crashing.org;=20
> linuxppc-dev@ozlabs.org; linux-kernel@vger.kernel.org
> Subject: Re: [PATCH 11/17] Add memory mapping driver to RapidIO.
>=20
> On Wed, 5 Mar 2008 00:29:56 +0800 Zhang Wei=20
> <wei.zhang@freescale.com> wrote:
> >
> > + if (!(rmem->virt =3D dma_alloc_coherent(NULL, rmem->size,
> > + &rmem->iores.start, GFP_KERNEL))) {
>=20
> Please separate assignments from tests.
>=20
> > + if ((ret =3D rio_space_claim(rmem))) {
>=20
> Again.
>=20
> --=20
> Cheers,
> Stephen Rothwell sfr@canb.auug.org.au
> http://www.canb.auug.org.au/~sfr/
>=20
^ permalink raw reply
* Re: [BUG] 2.6.25-rc3-mm1 kernel panic while bootup on powerpc ()
From: Kamalesh Babulal @ 2008-03-05 2:28 UTC (permalink / raw)
To: Pekka Enberg
Cc: linux-mm, Mel Gorman, linuxppc-dev, Andrew Morton,
Christoph Lameter
In-Reply-To: <47CDAC58.6090207@cs.helsinki.fi>
Pekka Enberg wrote:
> Christoph Lameter wrote:
>> I think this is the correct fix.
>>
>> The NUMA fallback logic should be passing local_flags to kmem_get_pages()
>> and not simply the flags.
>>
>> Maybe a stable candidate since we are now simply
>> passing on flags to the page allocator on the fallback path.
>>
>> Signed-off-by: Christoph Lameter <clameter@sgi.com>
>
> Indeed, good catch. I spotted the same thing just few seconds ago.
>
> Reviewed-by: Pekka Enberg <penberg@cs.helsinki.fi>
>
> Was it you Kamalesh that reported this? Can you please re-test?
Thanks the patch fixes the kernel bug.
Tested-by: Kamalesh Babulal <kamalesh@linux.vnet.ibm.com>
--
Thanks & Regards,
Kamalesh Babulal,
Linux Technology Center,
IBM, ISTL.
^ permalink raw reply
* linux-headers (powerpc v. ppc)
From: Ron Sass @ 2008-03-05 2:34 UTC (permalink / raw)
To: linuxppc-embedded
I hope this is to the right list... the recent discussion of
retiring ppc arch encouraged me to ask.
Ultimately, I'm trying to build a native PPC 405 compiler (i.e
Canadian cross). I've got a crosstool's generated cross-compiler
and I have glibc and a native bintools on my 405 root filesystem.
What I'd like to do is:
make ARCH=ppc headers_check
make ARCH=ppc INSTALL_HDR_PATH=dest headers_install
but that's not supported in the ppc tree.
So my question is, can I just ...
make ARCH=powerpc headers_check
make ARCH=powerpc INSTALL_HDR_PATH=dest headers_install
and then switch to ppc when I build the kernel?
I suspect it will work but just don't know if there is a
subtle difference that will come back to haunt me at
run-time.
Any advice would be greatly appreciated!
Ron
^ permalink raw reply
* Re: [PATCH 11/17] Add memory mapping driver to RapidIO.
From: Stephen Rothwell @ 2008-03-05 2:51 UTC (permalink / raw)
To: Zhang Wei; +Cc: linuxppc-dev, linux-kernel
In-Reply-To: <ABF87B0B6A38C0458E319AC973ED68AECE4522@zch01exm26.fsl.freescale.net>
[-- Attachment #1: Type: text/plain, Size: 462 bytes --]
Hi Weu,
On Wed, 5 Mar 2008 09:59:38 +0800 "Zhang Wei" <Wei.Zhang@freescale.com> wrote:
>
> Thanks! I'm considering to commit a updated patch or new code cleaning
> patch.
> How about your idea?
Preferably, fix up the patches. If that is a pain, then a followup patch
that cleans up is ok as these do not affect the correctness of the code.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: linux-headers (powerpc v. ppc)
From: Arnd Bergmann @ 2008-03-05 2:51 UTC (permalink / raw)
To: linuxppc-embedded, Ron Sass
In-Reply-To: <200803050234.m252Y6Um026382@rsass-homer.uncc.edu>
On Wednesday 05 March 2008, Ron Sass wrote:
> So my question is, can I just ...
>
> make ARCH=powerpc headers_check
> make ARCH=powerpc INSTALL_HDR_PATH=dest headers_install
>
> and then switch to ppc when I build the kernel?
Yes, that is exactly what you are meant to do. The headers
need to be compatible, otherwise we would have bigger problems
running user space programs built against an older kernel
on current machines.
Arnd <><
^ permalink raw reply
* [PATCH][POWERPC] Fix of_serial section mismatch warnings
From: Josh Boyer @ 2008-03-05 3:02 UTC (permalink / raw)
To: arnd; +Cc: linuxppc-dev
Fix the following section mismatches:
WARNING: drivers/built-in.o(.exit.text+0x5a): Section mismatch in reference from the function of_platform_serial_exit() to the variable .devinit.data:of_platform_serial_driver
The function __exit of_platform_serial_exit() references
a variable __devinitdata of_platform_serial_driver.
Signed-off-by: Josh Boyer <jwboyer@linux.vnet.ibm.com>
---
drivers/serial/of_serial.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- linux-2.6.orig/drivers/serial/of_serial.c
+++ linux-2.6/drivers/serial/of_serial.c
@@ -138,7 +138,7 @@ static struct of_device_id __devinitdata
{ /* end of list */ },
};
-static struct of_platform_driver __devinitdata of_platform_serial_driver = {
+static struct of_platform_driver of_platform_serial_driver = {
.owner = THIS_MODULE,
.name = "of_serial",
.probe = of_platform_serial_probe,
^ permalink raw reply
* Re: [PATCH] add strncmp to PowerPC
From: Paul Mackerras @ 2008-03-05 4:03 UTC (permalink / raw)
To: benh; +Cc: linuxppc-dev, LKML, Steven Rostedt
In-Reply-To: <1204340690.15052.457.camel@pasglop>
Benjamin Herrenschmidt writes:
> Do we have any indication that it performs better than the C one ?
I would expect it to, given that the assembler one has two branches in
the per-byte loop compared to 3 in the C version.
Paul.
^ permalink raw reply
* Re: ARCH=ppc -> ARCH=powerpc : help needed for dts file
From: David Gibson @ 2008-03-05 4:52 UTC (permalink / raw)
To: Philippe De Muyter; +Cc: Scott Wood, linuxppc-dev
In-Reply-To: <20080304091059.GD18829@netgate.macqel>
On Tue, Mar 04, 2008 at 10:10:59AM +0100, Philippe De Muyter wrote:
> Hi Ben,
>
> On Tue, Mar 04, 2008 at 07:22:19PM +1100, Benjamin Herrenschmidt wrote:
These comments aren't relevant to the problems you're seeing, but
they're a good idea for writing device trees in general.
First, you may want to consider moving to the version 1 dts format
which uses C-style integer values throughout, instead of hex by
default.
[snip]
> i2c@3000 {
> #address-cells = <1>;
> #size-cells = <0>;
> device_type = "i2c";
device_type shouldn't be included here.
> compatible = "fsl-i2c";
> reg = <3000 100>;
> interrupts = <2b 2>;
> interrupt-parent = <&mpic>;
> dfsrr;
>
> rtc@68 {
> compatible = "stm,m41t81";
> reg = <68>;
> };
> };
>
> mdio@24520 {
> #address-cells = <1>;
> #size-cells = <0>;
> device_type = "mdio";
> compatible = "gianfar";
[snip]
> ethernet@24000 {
> #address-cells = <1>;
> #size-cells = <0>;
> device_type = "network";
> model = "TSEC";
> compatible = "gianfar";
The binding for gianfar mdio and ethernet devices has been updated to
better fit conventions for use of device_type and compatible
properties. Check booting-without-of.txt for the details.
Can someone from freescale please go though and update the existing
device trees, so that people stop copying the old crap.
[snip]
> ethernet@24000 {
> #address-cells = <1>;
> #size-cells = <0>;
> device_type = "network";
> model = "TSEC";
> compatible = "gianfar";
> reg = <24000 1000>;
> /*
> * address is deprecated and will be removed
> * in 2.6.25. Only recent versions of
> * U-Boot support local-mac-address, however.
> */
> address = [ 00 00 00 00 00 00 ];
And since this is a new port, you ought to be able to use a recent
u-boot and drop this backwards compatibility property.
--
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: ARCH=ppc -> ARCH=powerpc : help needed for dts file
From: Benjamin Herrenschmidt @ 2008-03-05 5:01 UTC (permalink / raw)
To: Philippe De Muyter; +Cc: Scott Wood, linuxppc-dev
In-Reply-To: <20080304091059.GD18829@netgate.macqel>
> I also attach my current (not working) dts file attempt. It is actually
> a modified mpc8540ads.dts file.
>
> I now thinks that the ide-cs (hda) discovery or not depends on the cold
> or warm reboot.
>
> Here are the patches for my config (MEIP_8540) relative to a vanilla
> linux-2.6.24. I hacked the MPC8540ADS config. The PCI4520 is the
> multi-function chip from TI (dual-socket pc-card + iee1394 ohci and two-port
> phy)
.../...
> +#ifdef CONFIG_MEIP_8540
> + (IRQ_SENSE_LEVEL | IRQ_POLARITY_NEGATIVE), // External 0 : nINTPFO
> + (IRQ_SENSE_LEVEL | IRQ_POLARITY_NEGATIVE), // External 1 : nINTRTC
> + (IRQ_SENSE_LEVEL | IRQ_POLARITY_NEGATIVE), // External 2 : nINTPLD
> + (IRQ_SENSE_LEVEL | IRQ_POLARITY_NEGATIVE), // External 3 : nINTSTX
> + (IRQ_SENSE_LEVEL | IRQ_POLARITY_NEGATIVE), // External 4 : nINTPHY
> +#if defined(CONFIG_PCI)
> + (IRQ_SENSE_LEVEL | IRQ_POLARITY_NEGATIVE), /* External 5 : PCI4520 MFUNC 0 */
> + (IRQ_SENSE_LEVEL | IRQ_POLARITY_NEGATIVE), /* External 6 : PCI4520 MFUNC 1 */
> + (IRQ_SENSE_LEVEL | IRQ_POLARITY_NEGATIVE), /* External 7 : PCI4520 MFUNC 2 */
> + (IRQ_SENSE_LEVEL | IRQ_POLARITY_NEGATIVE), /* External 8 : PCI4520 MFUNC 3 */
> + (IRQ_SENSE_LEVEL | IRQ_POLARITY_NEGATIVE), /* External 9 : PCI4520 MFUNC 4 */
> + (IRQ_SENSE_LEVEL | IRQ_POLARITY_NEGATIVE), /* External 10 : PCI4520 MFUNC 5 */
> + (IRQ_SENSE_LEVEL | IRQ_POLARITY_NEGATIVE), /* External 11 : PCI4520 MFUNC 6 */
> +#else
> + 0x0, /* External 6: */
> + 0x0, /* External 7: */
> + 0x0, /* External 8: */
> + 0x0, /* External 9: */
> + 0x0, /* External 10: */
> + 0x0, /* External 11: */
> +#endif
> +#else
> 0x0, /* External 0: */
> #if defined(CONFIG_PCI)
> (IRQ_SENSE_LEVEL | IRQ_POLARITY_NEGATIVE), /* External 1: PCI slot 0 */
> @@ -77,6 +100,7 @@
> 0x0, /* External 9: */
> 0x0, /* External 10: */
> 0x0, /* External 11: */
> +#endif
> };
Ok, so based on the above, I deduce that you have 12 external interrupt
sources:
0...4 are those nINT* things. They correspond apparently do discrete
devices on your board. You will have to create device nodes in your .dts
for these with the appropriate interrupts property for each of these.
The rest are ... hrm... weird. You -appear- to have 5 to 8 going to PCI,
to PIRQA...D. Do that mean that you have wired your connectors on the board
such that the interrupt does not depend on the actual slot number ?
Or are you doing some swizzling ?
Also, I would need to know how those external IRQs are connected to the MPIC,
I don't have the spec of that chip here. Hrm. Somebody from freescale can
help him here ?
It's also not clear to me what your interrupts 9 10 and 11 are since you
seem to only talk about PIRQA...D which is only 4 lines ..
So at this stage, that's not enough information. We need to know exactly how
you have wired things on your board, and somebody from fsl needs to tell
me how the ExtIrq are routed to the MPIC on that guy.
Once that's done, you seem to have grasped the interrupt map... for any
device or slot, you provide the mapping between idsel/pirq line on one side,
and mpic interrupt & sense on the other. For PCI, sense is always 1 for an
mpic so you mostly have to check your actual MPIC source numbers.
>From your .dts, I see you've been doing some swizzling of slots using
interrupts 1...4 ... do that correspond to EXTIRQ 5....8 ?
Ben.
>
> /* ************************************************************************ */
> --- ./arch/ppc/platforms/85xx/mpc85xx_ads_common.hbk 2008-01-24 22:58:37.000000000 +0000
> +++ ./arch/ppc/platforms/85xx/mpc85xx_ads_common.h 2008-02-20 16:36:07.000000000 +0000
> @@ -29,10 +29,17 @@
> extern void mpc85xx_ads_map_io(void) __init;
>
> /* PCI interrupt controller */
> +#ifdef CONFIG_MEIP_8540
> +#define PIRQA MPC85xx_IRQ_EXT5
> +#define PIRQB MPC85xx_IRQ_EXT6
> +#define PIRQC MPC85xx_IRQ_EXT7
> +#define PIRQD MPC85xx_IRQ_EXT8
> +#else
> #define PIRQA MPC85xx_IRQ_EXT1
> #define PIRQB MPC85xx_IRQ_EXT2
> #define PIRQC MPC85xx_IRQ_EXT3
> #define PIRQD MPC85xx_IRQ_EXT4
> +#endif
>
> #define MPC85XX_PCI1_LOWER_IO 0x00000000
> #define MPC85XX_PCI1_UPPER_IO 0x00ffffff
^ 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