* Re: ARCH=ppc -> ARCH=powerpc : help needed for dts file
From: Philippe De Muyter @ 2008-03-04 8:08 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev
In-Reply-To: <47CC73CE.4080801@freescale.com>
Hi Scott,
On Mon, Mar 03, 2008 at 03:55:26PM -0600, Scott Wood wrote:
> Philippe De Muyter wrote:
>> The following seems important also :
>> /*
>> interrupts = <18 2>;
>> */
>> /* interrupts number are coded in hexa ! */
>> interrupts = <12 2 19 2 1a 2 1b 2 35 2 36 2 37 2>;
>> I have replaced the interrupts spec in comments by the longer interrupts
>> spec
>> below,
>
> Why?
because of the error message regarding unhandled interrupt. As I wrote I do
not know anything about dts files, just that it is needed to have one
for a non OF board if I want to use the ARCH=powerpc tree.
>
>> and it seems to have some positive effect,
>
> What kind of positive effect? I'd think the extra interrupts would just be
> ignored. The interrupts property for the PCI node itself is generally for
> error reporting.
My compact-flash device is discovered, but interrupts still do not work.
In the log, at the end of the boot,
this :
rtc-m41t80 0-0068: hctosys: invalid date/time
Waiting 3sec before mounting root device...
VFS: Cannot open root device "hda1" or unknown-block(0,0)
Please append a correct "root=" boot option; here are the
available partitions:
1f00 1920 mtdblock0 (driver?)
1f01 1920 mtdblock1 (driver?)
1f02 1920 mtdblock2 (driver?)
1f03 1920 mtdblock3 (driver?)
1f04 512 mtdblock4 (driver?)
Kernel panic - not syncing: VFS: Unable to mount root fs on
unknown-block(0,0)
Rebooting in 180 seconds..
is replaced by that :
hda: TRANSCEND, CFA DISK drive
ide0 at 0x000-0x007,0x00e on irq 18
hda: max request size: 128KiB
hda: 8077104 sectors (4135 MB) w/1KiB Cache, CHS=8013/16/63
hda:<4>hda: lost interrupt
[same message repeated]
hda: lost interrupt
hda1
ide-cs: hda: Vpp = 0.0
rtc-m41t80 0-0068: hctosys: invalid date/time
Waiting 3sec before mounting root device...
hda: lost interrupt
[same message repeated]
EXT2-fs warning (device hda1): ext2_fill_super: mounting ext3 filesystem as ext2
VFS: Mounted root (ext2 filesystem) readonly.
Freeing unused kernel memory: 116k init
hda: lost interrupt
[same message repeated]
>
>> I know that 25, 26, 27, 53, 54 and 55 decimal i(hence 19, 1a etc...) are
>> the
>> interrupts numbers that I had in the ARCH=ppc version. I added 18 because
>> of the error message, but it did not help.
>
> What ARCH=ppc version? There are no device trees for non-OF boards in
> arch/ppc.
With ARCH=ppc, all those interrupt's info's are hardcoded in the .c files.
But I expected I could fill the dts file for ARCH=powerpc from info's I
could collect in /proc on a running ARCH=ppc linux without dts file
for the same board.
Philippe
^ permalink raw reply
* out of vmalloc
From: Alain.Cadillac @ 2008-03-04 7:44 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 316 bytes --]
Hi my name is Alain
I'm working on plateform MPC8541 with linux 2.6.14 kernel.
I must to increase the kernel space area (1GB) beacause I had an
"out of vmalloc message" when i tried to reserve 256 Mo of PCI area.
*Does anyone tell me where i can found some information on HOW to do it?*
Thanks for help.
[-- Attachment #2: Type: text/html, Size: 536 bytes --]
^ permalink raw reply
* Re: Bamboo PCI interrupt issues
From: Benjamin Herrenschmidt @ 2008-03-04 6:33 UTC (permalink / raw)
To: Stefan Roese; +Cc: kvm-ppc-devel, linuxppc-dev, Hollis Blanchard
In-Reply-To: <200803040715.22301.sr@denx.de>
On Tue, 2008-03-04 at 07:15 +0100, Stefan Roese 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.
Ben.
^ permalink raw reply
* Re: Bamboo PCI interrupt issues
From: Benjamin Herrenschmidt @ 2008-03-04 6:18 UTC (permalink / raw)
To: Josh Boyer; +Cc: kvm-ppc-devel, linuxppc-dev, Hollis Blanchard
In-Reply-To: <20080303213718.12291eee@zod.rchland.ibm.com>
On Mon, 2008-03-03 at 21:37 -0600, Josh Boyer wrote:
> I plugged in an old 3Com ethernet card tonight. Slot 0. It was
> assigned dev #4 IRQ 25. Using the device tree as-is, I could see
> interrupts happening in /proc/interrupts but ethernet traffic failed.
>
> Then I changed the sense level to 4 as you suggested, and my card hung
> hard on the first ethernet traffic. I've no idea if we're dealing
> with
> a crappy card or a crappy driver but the device tree seems to be
> working ok. If I can find a different card to test with I will.
>
> Ben, do you have any input here?
Other than bamboo has the weirdest combination of FPGA/CPLD/DIP switches
that I could never figure out if PCI was clocked properly ?
That might just be the problem :-)
I do remember having issues now that we talk about it. Though not
specifically what they were.
Ben.
^ permalink raw reply
* Re: Bamboo PCI interrupt issues
From: Stefan Roese @ 2008-03-04 6:15 UTC (permalink / raw)
To: linuxppc-dev; +Cc: kvm-ppc-devel, Hollis Blanchard
In-Reply-To: <20080303213718.12291eee@zod.rchland.ibm.com>
On Tuesday 04 March 2008, Josh Boyer wrote:
> > Is anybody using Bamboo PCI support right now? Does it actually work?
>
> I plugged in an old 3Com ethernet card tonight. Slot 0. It was
> assigned dev #4 IRQ 25. Using the device tree as-is, I could see
> interrupts happening in /proc/interrupts but ethernet traffic failed.
>
> Then I changed the sense level to 4 as you suggested, and my card hung
> hard on the first ethernet traffic.
Using '8' is correct. PCI interrupts are *always* level sensitive and active
low.
> I've no idea if we're dealing with
> a crappy card or a crappy driver but the device tree seems to be
> working ok. If I can find a different card to test with I will.
One thing always worth to check on 4xx IRQ problems is, if the external IRQ
pins are configured correctly for IRQ usage. Most of the times, the external
IRQ's are shared with other peripheral pins and/or GPIO pins. This
configuration is done in the GPIO core (and sometimes SDR PFCx registers).
This should be done correctly by the bootloader but sometimes the
configuration is wrong. I have to admit that I probably never tested PCI on
Bamboo. Just a thought.
Best regards,
Stefan
^ permalink raw reply
* Re: dtc: Make dt_from_blob() open its own file
From: David Gibson @ 2008-03-04 5:15 UTC (permalink / raw)
To: Jon Loeliger, linuxppc-dev
In-Reply-To: <20080304051039.GC2757@localhost.localdomain>
On Tue, Mar 04, 2008 at 04:10:39PM +1100, David Gibson wrote:
> dt_from_source() and dt_from_fs() both take a filename (or directory
> name) argument and open files as necessary themselves.
> dt_from_blob(), however, expects the caller to open a file and pass it
> in.
>
> This patch makes dt_from_blob() take a filename and open its own
> files, removing the inconsistency. In addition, dt_from_blob() now
> correctly uses dtc_close_file() to close the file opened with
> dtc_open_file(), rather than directly calling fclose() on the
> contained FILE *.
>
> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Sorry, ignore. There's a bug in this one, revised version coming.
--
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 dt_from_blob() open its own file
From: David Gibson @ 2008-03-04 5:10 UTC (permalink / raw)
To: Jon Loeliger; +Cc: linuxppc-dev
dt_from_source() and dt_from_fs() both take a filename (or directory
name) argument and open files as necessary themselves.
dt_from_blob(), however, expects the caller to open a file and pass it
in.
This patch makes dt_from_blob() take a filename and open its own
files, removing the inconsistency. In addition, dt_from_blob() now
correctly uses dtc_close_file() to close the file opened with
dtc_open_file(), rather than directly calling fclose() on the
contained FILE *.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
---
dtc.c | 11 +----------
dtc.h | 4 ++--
flattree.c | 10 +++++++++-
3 files changed, 12 insertions(+), 13 deletions(-)
Index: dtc/dtc.c
===================================================================
--- dtc.orig/dtc.c 2008-03-04 15:58:49.000000000 +1100
+++ dtc/dtc.c 2008-03-04 16:02:12.000000000 +1100
@@ -118,7 +118,6 @@ int main(int argc, char *argv[])
int force = 0, check = 0;
const char *arg;
int opt;
- struct dtc_file *inf = NULL;
FILE *outf = NULL;
int outversion = DEFAULT_FDT_VERSION;
int boot_cpuid_phys = 0xfeedbeef;
@@ -192,19 +191,11 @@ int main(int argc, char *argv[])
} else if (streq(inform, "fs")) {
bi = dt_from_fs(arg);
} else if(streq(inform, "dtb")) {
- inf = dtc_open_file(arg, NULL);
- if (!inf)
- die("Couldn't open \"%s\": %s\n", arg,
- strerror(errno));
-
- bi = dt_from_blob(inf->file);
+ bi = dt_from_blob(arg);
} else {
die("Unknown input format \"%s\"\n", inform);
}
- if (inf && inf->file != stdin)
- fclose(inf->file);
-
if (! bi || ! bi->dt || bi->error)
die("Couldn't read input tree\n");
Index: dtc/flattree.c
===================================================================
--- dtc.orig/flattree.c 2008-03-04 15:59:53.000000000 +1100
+++ dtc/flattree.c 2008-03-04 16:06:55.000000000 +1100
@@ -19,6 +19,7 @@
*/
#include "dtc.h"
+#include "srcpos.h"
#define FTF_FULLPATH 0x1
#define FTF_VARALIGN 0x2
@@ -780,8 +781,10 @@ static struct node *unflatten_tree(struc
}
-struct boot_info *dt_from_blob(FILE *f)
+struct boot_info *dt_from_blob(const char *fname)
{
+ struct dtc_file *dtcf;
+ FILE *f;
u32 magic, totalsize, version, size_dt;
u32 off_dt, off_str, off_mem_rsvmap;
int rc;
@@ -796,6 +799,9 @@ struct boot_info *dt_from_blob(FILE *f)
u32 val;
int flags = 0;
+ dtcf = dtc_open_file(fname, NULL);
+ f = dtcf->file;
+
rc = fread(&magic, sizeof(magic), 1, f);
if (ferror(f))
die("Error reading DT blob magic number: %s\n",
@@ -902,5 +908,7 @@ struct boot_info *dt_from_blob(FILE *f)
free(blob);
+ dtc_close_file(dtcf);
+
return build_boot_info(reservelist, tree);
}
Index: dtc/dtc.h
===================================================================
--- dtc.orig/dtc.h 2008-03-04 16:01:22.000000000 +1100
+++ dtc/dtc.h 2008-03-04 16:01:43.000000000 +1100
@@ -250,12 +250,12 @@ void dt_to_blob(FILE *f, struct boot_inf
void dt_to_asm(FILE *f, struct boot_info *bi, int version,
int boot_cpuid_phys);
-struct boot_info *dt_from_blob(FILE *f);
+struct boot_info *dt_from_blob(const char *fname);
/* Tree source */
void dt_to_source(FILE *f, struct boot_info *bi);
-struct boot_info *dt_from_source(const char *f);
+struct boot_info *dt_from_source(const char *fname);
/* FS trees */
--
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 some functions local to parser
From: David Gibson @ 2008-03-04 4:37 UTC (permalink / raw)
To: Jon Loeliger; +Cc: linuxppc-dev
* eval_literal() is defined and used only in the parser, so make it
static.
* The Bison documentation explicitly permits yyerror() to be a
variadic function, so fold yyerror() and yyerrorf() into a single
printf-style function. The combined function is defined and used
only in the parse, so make it static.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
---
dtc-parser.y | 14 +++++---------
srcpos.h | 3 ---
2 files changed, 5 insertions(+), 12 deletions(-)
Index: dtc/dtc-parser.y
===================================================================
--- dtc.orig/dtc-parser.y 2008-03-04 15:29:09.000000000 +1100
+++ dtc/dtc-parser.y 2008-03-04 15:31:32.000000000 +1100
@@ -24,12 +24,13 @@
#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 void yyerror(char const *, ...) __attribute__((format(printf, 1, 2)));
+static unsigned long long eval_literal(const char *s, int base, int bits);
%}
%union {
@@ -308,7 +309,7 @@ label:
%%
-void yyerrorf(char const *s, ...)
+static void yyerror(char const *s, ...)
{
const char *fname = srcpos_file ? srcpos_file->name : "<no-file>";
va_list va;
@@ -325,12 +326,7 @@ void yyerrorf(char const *s, ...)
va_end(va);
}
-void yyerror (char const *s)
-{
- 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;
Index: dtc/srcpos.h
===================================================================
--- dtc.orig/srcpos.h 2008-03-04 15:30:06.000000000 +1100
+++ dtc/srcpos.h 2008-03-04 15:30:09.000000000 +1100
@@ -70,9 +70,6 @@ typedef struct YYLTYPE {
-extern void yyerror(char const *);
-extern void yyerrorf(char const *, ...) __attribute__((format(printf, 1, 2)));
-
extern struct dtc_file *srcpos_file;
extern void push_input_file(const char *filename);
--
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
* [PATCH] Correct a terrible scheduling error
From: Segher Boessenkool @ 2008-03-04 3:42 UTC (permalink / raw)
To: linuxppc-dev
It would be a pity if we can't all enjoy this.
Signed-off-by: Segher Boessenkool <segher@kernel.crashing.org>
---
Documentation/feature-removal-schedule.txt | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/Documentation/feature-removal-schedule.txt b/Documentation/feature-removal-schedule.txt
index c1d1fd0..78021bf 100644
--- a/Documentation/feature-removal-schedule.txt
+++ b/Documentation/feature-removal-schedule.txt
@@ -201,13 +201,13 @@ Who: Tejun Heo <htejun@gmail.com>
---------------------------
What: The arch/ppc and include/asm-ppc directories
-When: Jun 2008
+When: end of July 2008
Why: The arch/powerpc tree is the merged architecture for ppc32 and ppc64
platforms. Currently there are efforts underway to port the remaining
arch/ppc platforms to the merged tree. New submissions to the arch/ppc
tree have been frozen with the 2.6.22 kernel release and that tree will
remain in bug-fix only mode until its scheduled removal. Platforms
- that are not ported by June 2008 will be removed due to the lack of an
+ that are not ported by July 2008 will be removed due to the lack of an
interested maintainer.
Who: linuxppc-dev@ozlabs.org
--
1.5.3.4.208.g805a
^ permalink raw reply related
* Re: Bamboo PCI interrupt issues
From: Josh Boyer @ 2008-03-04 3:37 UTC (permalink / raw)
To: Hollis Blanchard; +Cc: kvm-ppc-devel, linuxppc-dev
In-Reply-To: <1204588953.7921.13.camel@basalt>
On Mon, 03 Mar 2008 18:02:33 -0600
Hollis Blanchard <hollisb@us.ibm.com> wrote:
> I'm having two problems with PCI interrupts as described in bamboo.dts.
> Here is are the properties in question:
>
> /* Bamboo has all 4 IRQ pins tied together per slot */
> interrupt-map-mask = <f800 0 0 0>;
> interrupt-map = <
> /* IDSEL 1 */
> 0800 0 0 0 &UIC0 1c 8
>
> /* IDSEL 2 */
> 1000 0 0 0 &UIC0 1b 8
>
> /* IDSEL 3 */
> 1800 0 0 0 &UIC0 1a 8
>
> /* IDSEL 4 */
> 2000 0 0 0 &UIC0 19 8
> >;
>
>
> First, the 440EP[1] and Bamboo[2] user manuals indicate that PCI IRQ 0-3
> -> board IRQ 2-5 -> UIC IRQ 25-28. However, the device tree has that
> reversed, so PCI IRQ 0 appears as UIC IRQ 28 (0x1c).
Actually, the device tree is right. I got annoyed with myself for not
knowing how this works so I went and figured it out.
2000 0 0 0 is device #4. According to the specs, device #4 has AD(14)
asserted during type 0 configuration. Looking at the board schematics,
PCI slot 0 has it's IDSEL line tied to AD(14). So:
dev #4 -> PCI 0 -> board IRQ 2 -> UIC IRQ 25.
which is exactly what the device tree has.
> Second, the sensitivity seems to be wrong. All these interrupts have the
> sensitivity encoded as 8, which means "high to low edge" in the OpenPIC
> binding. Now, 440EP has a UIC, rather than an OpenPIC, but there is no
> UIC binding AFAICS.
There isn't. It uses the sense numbers from linux/irq.h. Which means
8 is level, low. This matches exactly what the board manual says for
IRQ2-5 on page 69.
> When I change the 8 to a 4 ("active high level"), I see the proper
> values in the UIC polarity register, and PCI interrupts start working in
> KVM.
That's odd.
> Is anybody using Bamboo PCI support right now? Does it actually work?
I plugged in an old 3Com ethernet card tonight. Slot 0. It was
assigned dev #4 IRQ 25. Using the device tree as-is, I could see
interrupts happening in /proc/interrupts but ethernet traffic failed.
Then I changed the sense level to 4 as you suggested, and my card hung
hard on the first ethernet traffic. I've no idea if we're dealing with
a crappy card or a crappy driver but the device tree seems to be
working ok. If I can find a different card to test with I will.
Ben, do you have any input here?
josh
^ permalink raw reply
* Re: Bamboo PCI interrupt issues
From: David Gibson @ 2008-03-04 2:15 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: kvm-ppc-devel, linuxppc-dev, Hollis Blanchard
In-Reply-To: <08b18695c383fb829ecf3ab6c2822bd1@kernel.crashing.org>
On Tue, Mar 04, 2008 at 03:07:50AM +0100, Segher Boessenkool wrote:
> >>> Uh.. there's no binding written down, it's just encoded into uic.c.
> >>> But UIC doesn't use OpenPIC sensitivity encoding. Like FSL's IPIC,
> >>> it
> >>> uses Linux IRQ_TYPE values from include/linux/irq.h which makes 8
> >>> "level sensitive, active-low".
> >>
> >> On a related note: aren't we taking a risk here of seeing those values
> >> change in linux ?
> >
> > We've discussed this before. If that happens, the binding must remain
> > on the old values. It means the driver will then need a translation
> > which it doesn't now, but we can deal with it.
>
> It also means it should be written down in the binding _already_.
Well, yes, there should be, but isn't, a written binding for this,
amongst many other things.
> Come on, how much work is that?
Greater than zero.
--
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: Bamboo PCI interrupt issues
From: Segher Boessenkool @ 2008-03-04 2:07 UTC (permalink / raw)
To: David Gibson; +Cc: kvm-ppc-devel, linuxppc-dev, Hollis Blanchard
In-Reply-To: <20080304015329.GE1393@localhost.localdomain>
>>> Uh.. there's no binding written down, it's just encoded into uic.c.
>>> But UIC doesn't use OpenPIC sensitivity encoding. Like FSL's IPIC,
>>> it
>>> uses Linux IRQ_TYPE values from include/linux/irq.h which makes 8
>>> "level sensitive, active-low".
>>
>> On a related note: aren't we taking a risk here of seeing those values
>> change in linux ?
>
> We've discussed this before. If that happens, the binding must remain
> on the old values. It means the driver will then need a translation
> which it doesn't now, but we can deal with it.
It also means it should be written down in the binding _already_.
Come on, how much work is that?
Segher
^ permalink raw reply
* Re: Bamboo PCI interrupt issues
From: David Gibson @ 2008-03-04 1:53 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: kvm-ppc-devel, linuxppc-dev, Hollis Blanchard
In-Reply-To: <1204594967.21545.46.camel@pasglop>
On Tue, Mar 04, 2008 at 12:42:47PM +1100, Benjamin Herrenschmidt wrote:
>
> On Tue, 2008-03-04 at 11:59 +1100, David Gibson wrote:
> >
> > Uh.. there's no binding written down, it's just encoded into uic.c.
> > But UIC doesn't use OpenPIC sensitivity encoding. Like FSL's IPIC, it
> > uses Linux IRQ_TYPE values from include/linux/irq.h which makes 8
> > "level sensitive, active-low".
>
> On a related note: aren't we taking a risk here of seeing those values
> change in linux ?
We've discussed this before. If that happens, the binding must remain
on the old values. It means the driver will then need a translation
which it doesn't now, but we can deal with it.
--
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 and Git and MontaVista
From: Jon Loeliger @ 2008-03-04 1:52 UTC (permalink / raw)
To: linuxppc-dev
Guys,
Sorry to bother everyone, but someone at MontaVista
who was trying to get the DTC today needs to update
their version of git to be something modern.
Thanks,
jdl
^ permalink raw reply
* Re: Bamboo PCI interrupt issues
From: Benjamin Herrenschmidt @ 2008-03-04 1:42 UTC (permalink / raw)
To: David Gibson; +Cc: kvm-ppc-devel, linuxppc-dev, Hollis Blanchard
In-Reply-To: <20080304005922.GB1393@localhost.localdomain>
On Tue, 2008-03-04 at 11:59 +1100, David Gibson wrote:
>
> Uh.. there's no binding written down, it's just encoded into uic.c.
> But UIC doesn't use OpenPIC sensitivity encoding. Like FSL's IPIC, it
> uses Linux IRQ_TYPE values from include/linux/irq.h which makes 8
> "level sensitive, active-low".
On a related note: aren't we taking a risk here of seeing those values
change in linux ?
Ben.
^ permalink raw reply
* Re: Bamboo PCI interrupt issues
From: David Gibson @ 2008-03-04 0:59 UTC (permalink / raw)
To: Hollis Blanchard; +Cc: kvm-ppc-devel, linuxppc-dev
In-Reply-To: <1204588953.7921.13.camel@basalt>
On Mon, Mar 03, 2008 at 06:02:33PM -0600, Hollis Blanchard wrote:
> I'm having two problems with PCI interrupts as described in bamboo.dts.
> Here is are the properties in question:
>
> /* Bamboo has all 4 IRQ pins tied together per slot */
> interrupt-map-mask = <f800 0 0 0>;
> interrupt-map = <
> /* IDSEL 1 */
> 0800 0 0 0 &UIC0 1c 8
>
> /* IDSEL 2 */
> 1000 0 0 0 &UIC0 1b 8
>
> /* IDSEL 3 */
> 1800 0 0 0 &UIC0 1a 8
>
> /* IDSEL 4 */
> 2000 0 0 0 &UIC0 19 8
> >;
>
>
> First, the 440EP[1] and Bamboo[2] user manuals indicate that PCI IRQ 0-3
> -> board IRQ 2-5 -> UIC IRQ 25-28. However, the device tree has that
> reversed, so PCI IRQ 0 appears as UIC IRQ 28 (0x1c).
>
> Second, the sensitivity seems to be wrong. All these interrupts have the
> sensitivity encoded as 8, which means "high to low edge" in the OpenPIC
> binding. Now, 440EP has a UIC, rather than an OpenPIC, but there is no
> UIC binding AFAICS.
Uh.. there's no binding written down, it's just encoded into uic.c.
But UIC doesn't use OpenPIC sensitivity encoding. Like FSL's IPIC, it
uses Linux IRQ_TYPE values from include/linux/irq.h which makes 8
"level sensitive, active-low".
> When I change the 8 to a 4 ("active high level"), I see the proper
> values in the UIC polarity register, and PCI interrupts start working in
> KVM.
>
> Is anybody using Bamboo PCI support right now? Does it actually work?
>
> [1]
> https://www.amcc.com/MyAMCC/retrieveDocument/PowerPC/440EP/PPC440EP_UM2000.pdf
> [2] Seems to have been deleted from the web. Thanks, AMCC.
>
--
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 2/2 v2] [POWERPC] Ignore disabled serial ports
From: Arnd Bergmann @ 2008-03-04 0:42 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Scott Wood, Nathan Lynch, paulus
In-Reply-To: <20080303214028.GE4712@localdomain>
On Monday 03 March 2008, Nathan Lynch wrote:
> I agree. =A0Josh's patch is immediately useful to other code as-is.
>=20
> used-by-rtas is powerpc-specific and doesn't belong in drivers/of IMO.
Ok, makes sense, plus paulus looked at the PAPR spec with me and we found
that used-by-rtas doesn't necessarily mean "don't touch" in all
circumstances, so original patch
Acked-by: Arnd Bergmann <arnd@arndb.de>
^ permalink raw reply
* Re: [PATCH 3/3] ppc64-specific memory notifier support
From: Nathan Lynch @ 2008-02-29 0:39 UTC (permalink / raw)
To: Michael Ellerman; +Cc: linuxppc-dev, Badari Pulavarty
In-Reply-To: <1204243875.7729.3.camel@concordia.ozlabs.ibm.com>
Michael Ellerman wrote:
> On Thu, 2008-02-28 at 08:46 -0800, Badari Pulavarty wrote:
> > Hotplug memory notifier for ppc64. This gets invoked by writing
> > the device-node that needs to be removed to /proc/ppc64/ofdt.
> > We need to adjust the sections and remove sysfs entries by
> > calling __remove_pages(). Then call arch specific code to
> > get rid of htab mappings for the section of memory.
> >
> > Signed-off-by: Badari Pulavarty <pbadari@us.ibm.com>
> > ---
> > arch/powerpc/platforms/pseries/Makefile | 1
> > arch/powerpc/platforms/pseries/hotplug-memory.c | 98 ++++++++++++++++++++++++
> > 2 files changed, 99 insertions(+)
> >
> > Index: linux-2.6.25-rc2/arch/powerpc/platforms/pseries/hotplug-memory.c
> > ===================================================================
> > --- /dev/null 1970-01-01 00:00:00.000000000 +0000
> > +++ linux-2.6.25-rc2/arch/powerpc/platforms/pseries/hotplug-memory.c 2008-02-28 08:20:14.000000000 -0800
>
> > +
> > +static struct notifier_block pseries_smp_nb = {
> > + .notifier_call = pseries_memory_notifier,
> > +};
> > +
> > +static int __init pseries_memory_hotplug_init(void)
> > +{
> > + if (firmware_has_feature(FW_FEATURE_LPAR))
> > + pSeries_reconfig_notifier_register(&pseries_smp_nb);
> > +
> > + return 0;
> > +}
> > +arch_initcall(pseries_memory_hotplug_init);
>
> This is going to fire on non-pseries LPAR platforms, like iSeries and
> PS3. Which is not what you want I think.
Well, the notifier will be registered, yes, but it will never be
called because that path is reachable only from a write to
/proc/ppc64/ofdt, which is not created on non-pseries.
Maybe it should be
machine_device_initcall(pseries, pseries_memory_hotplug_init);
(and pseries_cpu_hotplug_init in hotplug-cpu.c should be changed to
machine_arch_initcall)
^ permalink raw reply
* Bamboo PCI interrupt issues
From: Hollis Blanchard @ 2008-03-04 0:02 UTC (permalink / raw)
To: linuxppc-dev; +Cc: kvm-ppc-devel
I'm having two problems with PCI interrupts as described in bamboo.dts.
Here is are the properties in question:
/* Bamboo has all 4 IRQ pins tied together per slot */
interrupt-map-mask = <f800 0 0 0>;
interrupt-map = <
/* IDSEL 1 */
0800 0 0 0 &UIC0 1c 8
/* IDSEL 2 */
1000 0 0 0 &UIC0 1b 8
/* IDSEL 3 */
1800 0 0 0 &UIC0 1a 8
/* IDSEL 4 */
2000 0 0 0 &UIC0 19 8
>;
First, the 440EP[1] and Bamboo[2] user manuals indicate that PCI IRQ 0-3
-> board IRQ 2-5 -> UIC IRQ 25-28. However, the device tree has that
reversed, so PCI IRQ 0 appears as UIC IRQ 28 (0x1c).
Second, the sensitivity seems to be wrong. All these interrupts have the
sensitivity encoded as 8, which means "high to low edge" in the OpenPIC
binding. Now, 440EP has a UIC, rather than an OpenPIC, but there is no
UIC binding AFAICS.
When I change the 8 to a 4 ("active high level"), I see the proper
values in the UIC polarity register, and PCI interrupts start working in
KVM.
Is anybody using Bamboo PCI support right now? Does it actually work?
[1]
https://www.amcc.com/MyAMCC/retrieveDocument/PowerPC/440EP/PPC440EP_UM2000.pdf
[2] Seems to have been deleted from the web. Thanks, AMCC.
--
Hollis Blanchard
IBM Linux Technology Center
^ permalink raw reply
* Re: [PATCH 0/8] pseries: phyp dump: hypervisor-assisted dump
From: Joel Schopp @ 2008-03-03 23:37 UTC (permalink / raw)
To: Manish Ahuja; +Cc: ppc-dev, Linas Vepstas, paulus
In-Reply-To: <47C74A66.1060105@austin.ibm.com>
This looks like it is to a stable usable point now. In my opinion it is
ready to be merged into the next tree for 2.6.26.
Reviewed-by: Joel Schopp <jschopp@austin.ibm.com>
Manish Ahuja wrote:
> Changes from previous version:
>
> The only changes are in patch 2.
> moved early_init_dt_scan_phyp_dump from rtas.c to phyp_dump.c
> Added dummy function in phyp_dump.h
>
> Patch 3 required repatching due to changes to patch 2.
> Resubmitting all patches to avoid confusion.
>
> Thanks,
> Manish
>
>
> Michael Ellerman wrote:
>
>> On Sun, 2008-02-17 at 22:53 -0600, Manish Ahuja wrote:
>>
>>> The following series of patches implement a basic framework
>>> for hypervisor-assisted dump. The very first patch provides
>>> documentation explaining what this is :-) . Yes, its supposed
>>> to be an improvement over kdump.
>>>
>>> A list of open issues / todo list is included in the documentation.
>>> It also appears that the not-yet-released firmware versions this was tested
>>> on are still, ahem, incomplete; this work is also pending.
>>>
>>> I have included most of the changes requested. Although, I did find
>>> one or two, fixed in a later patch file rather than the first location
>>> they appeared at.
>>>
>> This series still doesn't build on !CONFIG_RTAS configs:
>> http://kisskb.ellerman.id.au/kisskb/head/629/
>>
>> This solution is to move early_init_dt_scan_phyp_dump() into
>> arch/powerpc/platforms/pseries/phyp_dump.c and provide a dummy
>> implementation in asm-powerpc/phyp_dump.c for the !CONFIG_PHYP_DUMP
>> case.
>>
>> cheers
>>
>>
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
>
^ permalink raw reply
* RE: locking problem in sata_sil24?
From: Johannes Berg @ 2008-03-03 23:28 UTC (permalink / raw)
To: benh; +Cc: linuxppc-dev, linux-ide
In-Reply-To: <1204585095.21545.37.camel@pasglop>
[-- Attachment #1: Type: text/plain, Size: 550 bytes --]
> In fact, I remember working on 64 bits lockdep, based on patches from
> Johannes,
Your patches never really worked for me so far but I'll be happy to try
new ones, haven't gotten around to checking into the differences.
> but I didn't do 32 bits. I think somebody worked on it, but
> now I can't find the patches...
>
> Whoever did it can bounce them back to me ? I intend to do some more
> work on this soon.
That was Dale Farnsworth, with the subject
"[RFC/PATCH] powerpc: Add irqtrace support to 32-bit powerpc"
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]
^ permalink raw reply
* RE: locking problem in sata_sil24?
From: Rune Torgersen @ 2008-03-03 23:13 UTC (permalink / raw)
To: benh; +Cc: linuxppc-dev, linux-ide
In-Reply-To: <1204585095.21545.37.camel@pasglop>
> From: Benjamin Herrenschmidt
> In fact, I remember working on 64 bits lockdep, based on patches from
> Johannes, but I didn't do 32 bits. I think somebody worked on it, but
> now I can't find the patches...
http://patchwork.ozlabs.org/linuxppc/patch?id=3D16652
> Whoever did it can bounce them back to me ? I intend to do some more
> work on this soon.
^ permalink raw reply
* RE: locking problem in sata_sil24?
From: Benjamin Herrenschmidt @ 2008-03-03 22:58 UTC (permalink / raw)
To: Rune Torgersen; +Cc: linuxppc-dev, linux-ide
In-Reply-To: <DCEAAC0833DD314AB0B58112AD99B93B0410A575@ismail.innsys.innovsys.com>
On Mon, 2008-03-03 at 16:44 -0600, Rune Torgersen wrote:
> Benjamin Herrenschmidt wrote:
> > On Mon, 2008-03-03 at 16:10 -0600, Rune Torgersen wrote:
> >> Hi I am trying to get PREEMPT_RT pach to wokr on my 2.6.24 kernel,
>
> > What core is in the 8280 ? At this stage, I wouldn't rule out a bug in
> > the lockdep patches, I need to do more work on them.
>
> Should be an 603e
> adn revision (from u-boot)
> CPU: MPC8280 (HiP7 Rev 14, Mask 1.0 1K49M) at 447.897 MHz
>
>
>
> I am currently compiling a LOCKDEP kernel for my x86 desktop, as it has
> the exact same SiliconImage controller on a card, so I'll see if it gets
> a similar detection.
In fact, I remember working on 64 bits lockdep, based on patches from
Johannes, but I didn't do 32 bits. I think somebody worked on it, but
now I can't find the patches...
Whoever did it can bounce them back to me ? I intend to do some more
work on this soon.
Cheers,
Ben.
^ permalink raw reply
* RE: locking problem in sata_sil24?
From: Rune Torgersen @ 2008-03-03 22:44 UTC (permalink / raw)
To: benh; +Cc: linuxppc-dev, linux-ide
In-Reply-To: <1204583866.21545.31.camel@pasglop>
Benjamin Herrenschmidt wrote:
> On Mon, 2008-03-03 at 16:10 -0600, Rune Torgersen wrote:
>> Hi I am trying to get PREEMPT_RT pach to wokr on my 2.6.24 kernel,
> What core is in the 8280 ? At this stage, I wouldn't rule out a bug in
> the lockdep patches, I need to do more work on them.
Should be an 603e
adn revision (from u-boot)
CPU: MPC8280 (HiP7 Rev 14, Mask 1.0 1K49M) at 447.897 MHz
I am currently compiling a LOCKDEP kernel for my x86 desktop, as it has
the exact same SiliconImage controller on a card, so I'll see if it gets
a similar detection.
^ permalink raw reply
* Re: locking problem in sata_sil24?
From: Benjamin Herrenschmidt @ 2008-03-03 22:37 UTC (permalink / raw)
To: Rune Torgersen; +Cc: linuxppc-dev, linux-ide
In-Reply-To: <DCEAAC0833DD314AB0B58112AD99B93B0410A524@ismail.innsys.innovsys.com>
On Mon, 2008-03-03 at 16:10 -0600, Rune Torgersen wrote:
> Hi I am trying to get PREEMPT_RT pach to wokr on my 2.6.24 kernel, but
> kept gettign a BUG() (kernel BUG at kernel/rtmutex.c:692).
> While tryiong to figure out what it was, I saw some mention of trying
> LOCKDEP to see what is going on, so I patched my -rt1 kernel with some
> lockdep patches from BenH.
>
> Now I get an "inconsistent locking state", but I need help in trying to
> fiure out what I should look for.
> kernel is fo an Freescale 8280 and the locking seems to occur in the
> driver for a Silicon Image SII3124 SATA disk driver
What core is in the 8280 ? At this stage, I wouldn't rule out a bug in
the lockdep patches, I need to do more work on them.
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