RE: [PATCH v5 9/9] add MPC837x MDS board default device tree
> -Original Message-
> From: David Gibson [mailto:[EMAIL PROTECTED]
> Sent: Friday, October 19, 2007 8:56 AM
> To: Li Yang-r58472
> Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED];
> linuxppc-dev@ozlabs.org
> Subject: Re: [PATCH v5 9/9] add MPC837x MDS board default device tree
>
> On Thu, Oct 18, 2007 at 06:16:20PM +0800, Li Yang wrote:
> > Signed-off-by: Li Yang <[EMAIL PROTECTED]>
> > ---
> > diff --git a/arch/powerpc/boot/dts/mpc8377_mds.dts
> > b/arch/powerpc/boot/dts/mpc8377_mds.dts
> > new file mode 100644
> > index 000..8530de6
> > --- /dev/null
> > +++ b/arch/powerpc/boot/dts/mpc8377_mds.dts
> > @@ -0,0 +1,282 @@
> [snip]
> > + [EMAIL PROTECTED] {
> > + model = "SEC3";
> > + compatible = "talitos";
>
> That compatible doesn't look specific enough. It should at
> least have a vendor portion. In general it's best to have
> all the information you need to pick a driver and options in
> compatible, rather than splitting that info into model.
I think we could do this in a separate patch. Change the spec and then
update all the in-tree device tree with SEC node.
- Leo
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Merge dtc
On Fri, Oct 19, 2007 at 09:07:18AM +0200, Sam Ravnborg wrote: > > Compared to the behemoth that is Kbuild... > > > > I'm happy to improve the Makefile integration, but you seem to be > > rather vague on how, and the Kbuild documentation makes my brain hurt. > > I can make an ALL UPPERCASE VERSION if that makes it easier for you > to read ;-) Hardy har har. Since this is supposed to build both within the kernel and standalone there will necessarily be a few style conflicts at the boundary. Kbuild is not in the majority here; in fact it's close to unique. > Give me a day or two then I shall give it a try and see what I can > do about it. I will use the previsous posted URL as basis if you do > not tell me otherwise. Thank you. The previous URL should be fine, I've made no changes since then. -- David Gibson| I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Merge dtc
On Fri, Oct 19, 2007 at 12:56:41AM -0500, Milton Miller wrote: > On Oct 18, 2007, at 8:45 PM, David Gibson wrote: > > On Thu, Oct 18, 2007 at 09:59:26PM +0200, Sam Ravnborg wrote: > >> On Thu, Oct 18, 2007 at 12:49:54PM -0500, Milton Miller wrote: > >>> On Tue Oct 16 15:02:17 EST 2007, David Gibson wrote: > >>> > This very large patch incorporates a copy of dtc into the kernel > source, in arch/powerpc/boot/dtc-src. This means that dtc is no > longer an external dependency to build kernels with configurations > which need a dtb file. > > > >> As Milton already pointed out you should build dtc in the > >> dtc directory (why the -src prefix??). > > > > The -src suffix is only there because I'm not building in the > > directory - we can't have both a dtc binary and a dtc directory in > > arch/powerpc/boot. > > So run the dtc binary stored in the sub directory. Thats what we do > elsewhere. Yes, yes, which boils down to your other point of building in the subdirectory. It's not a separate issue. > > Ok, so how do I build in the subdirectory? I was going to do that, > > but couldn't for the life of me figure out how. > > Documentation/kbuild/makefiles.txt 6.4 boot images: > > "$(Q)$(MAKE) $(build)=" is the recommended way to invoke > make in a subdirectory. But where does it go? To have somewhere to put that rule, we'd still need a target in arch/powerpc/boot itself. > Section 4 Host Program Support is also relavent, and mentions $(always). I know I tried using $(always), but I couldn't figure out how to make it do something useful. > >> And the dtc specific Makefile looks like something from > >> the late 80'. Please drop all these ALLUPPERCASE variables > >> and accept a little bit of redundancy. > > > > Hrm... I'm pretty dubious about this. Practically every Makefile in > > the universe, *except* Kbuild uses uppercase for most variables. > > Makefile.dtc is imported verbatim from the standalone dtc package, and > > is supposed to have the minimal information about what needs to be > > built to import into Makefiles that actually know how to build things. > > > >> Then mere humans may be able to read the Makefile. > > > > Says a maintainer of Kbuild, about my tiny and not-very-complex > > Makefile fragment... um, ok... > > overley complex calls to override source, I'm not sure what you're referring to... even if you mean in Makefile.dtc or in the diff to arch/powerpc/boot/Makefile. >conditional rules based on > shipped files? Or here, for sure. The shipped/lex/yacc rules are just based on those from Kconfig and genksyms. > Its not a trivial fragment. Compared to the behemoth that is Kbuild... I'm happy to improve the Makefile integration, but you seem to be rather vague on how, and the Kbuild documentation makes my brain hurt. -- David Gibson| I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH v2 3/4] Implement clockevents driver for powerpc
Gabriel Paubert writes: > I'd really wish there were a guarantee of a minimum timebase > frequency, for anything above ~10MHz, we are splitting hairs > about an off-by-one error that never accumulates, but if systems > with very low TB freq exist, you have to be very careful. Exactly. In looking through the generic clockevents code, there are a few places where counts are rounded down. For example, clockevents_program_event does this to convert from nanoseconds (in "delta") to the count value for the clock event device: clc = delta * dev->mult; clc >>= dev->shift; Here the right shift can lose up to a whole count. If the clock frequency of the device is very slow, say 1kHz, then this could lose up to 99 nanoseconds. Then, on Book E, putting 1 into the decrementer could result in an interrupt anywhere from straight away to 1 millisecond later (assuming 1kHz timebase frequency, again). The net result is that delta = 199 nanoseconds could result in the interrupt coming in immediately, i.e. almost 2ms early. I believe the clockevents framework has not been designed for use with very slow one-shot clock event devices. If it is to be used with very low clock rates, then there are several points where I think the rounding/truncation issues need to be carefully thought through. In any case, the code we have at the moment won't work with timebase clock rates below 15.258kHz, because decrementer_clockevent.mult will become zero. Regards, Paul. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] bestcomm: Restrict disabling of bus prefetch to original mpc5200 silicon.
On 10/19/07, Domen Puncer <[EMAIL PROTECTED]> wrote: > On 17/10/07 10:36 -0600, Grant Likely wrote: > > From: Grant Likely <[EMAIL PROTECTED]> > > > > Only the MPC5200 needs this bug fix. MPC5200B is okay. > > > > Signed-off-by: Grant Likely <[EMAIL PROTECTED]> > > --- > > > > Sven, Domen; > > > > Can you please test this patch? > > I found no obvious problems with it on Efika (mpc5200b) Cool, I'll add it to my list of patches for Paulus to pull g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. [EMAIL PROTECTED] (403) 399-0195 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH v3 2/2] [POWERPC] MPC8568E-MDS: add support for flash
On Fri, Oct 19, 2007 at 08:23:19AM -0500, Kumar Gala wrote:
>
> On Oct 18, 2007, at 5:29 PM, Anton Vorontsov wrote:
>
>> On Thu, Oct 18, 2007 at 02:58:25PM -0500, Kumar Gala wrote:
>> [...]
+
+ [EMAIL PROTECTED],0 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "Spansion,S29GL256N11TFIV2O", "cfi-flash";
+ reg = <0 0 200>;
+ bank-width = <2>;
+ device-width = <1>;
+
>>>
>>> Are you basing the partition map on something or making it up?
>>> Clearly hrcw & u-boot are at fixed offsets, wondering about kernel &
>>> rootfs?
>>
>> I'm making it up. From the brief look at the u-boot* git sources,
>> there is no `flashboot` yet, thus I'm free to make this up...
>>
>> I've partitioned this flash based on these thoughts:
>>
>> 1. HRCW - whole sector, to not wear out it, plus it's impossible to
>>create just 64 bytes partition;
>
> this makes sense.
[Unrelated to the patch.
I've tried to erase first (hrcw) sector, everything passes fine, but
`md fe00` still gives data back. Probably some hardware magic used
to prevent this? ;-)
=> erase fe00 fe03
.. done
Erased 2 sectors
=> md fe00
fe00: 42424242 42424242 05050505 05050505
fe10: 83838383 83838383
fe20: a0a0a0a0 a0a0a0a0 60606060 60606060
...
=> md fe02
fe02:
...]
>
>> 2. Kernel - 2MB, should be enough for bootup kernels?
>
> seems reasonable.
>
>> 3. Rootfs - the rest up to...
>
> do we need a small section for the device tree?
Yes, apparently. :-)
>> 4. U-Boot at the end.
>
> can we reorder partitions? not sure if there is any value in having the
> things we know will always be there like hrcw & u-boot at fixed mtd0, mtd1,
> etc.
Good idea.
>>
>> I'm not saying that it's best map ever, I'm open to suggestions. ;-)
>>
>> * Unfortunately I didn't look at the stock Freescale u-boot, maybe
>> there was flashboot, most probably.. I'll find the CD to look this
>> up.
>
> Yeah I have no idea what we ship w/regards to the BSPs.
Here it is:
bootcmd=run ramargs;cp.b fff0 40 2000;bootm ff80 ffa0 40
I.e.
0xFF80 - kernel
0xFFA0 - ramdisk
0xFFF0 - dtb, one sector
Reworked patch (lbus+flash) follow, using this stock partitions map:
0x-0x0002 : "hrcw"<- 128 kB
0x01f8-0x0200 : "u-boot" <- 512 kB
0x0002-0x0180 : "rootfs" <- 24448 kB
0x0180-0x01a0 : "kernel" <- 2048 kB
0x01a0-0x01f0 : "ramdisk" <- 5120 kB
0x01f0-0x01f2 : "dtb" <- 128 kB
0x01f2-0x01f8 : "spare" <- 384 kB
I'm not sure about "ramdisk" partition though, maybe concatenate
kernel+ramdisk to use with initramfs kernels instead?
- - - -
From: Anton Vorontsov <[EMAIL PROTECTED]>
Subject: [PATCH] [POWERPC] MPC8568E-MDS: create localbus node, add flash support
This patch:
- creates localbus node;
- moves bcsr into it;
- creates flash node (1 32MB Spansion x16 CFI) and its partitions;
- adds localbus to the probe path.
Signed-off-by: Anton Vorontsov <[EMAIL PROTECTED]>
---
arch/powerpc/boot/dts/mpc8568mds.dts | 61 +++-
arch/powerpc/platforms/85xx/mpc85xx_mds.c |1 +
2 files changed, 59 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/boot/dts/mpc8568mds.dts
b/arch/powerpc/boot/dts/mpc8568mds.dts
index 5439437..8ddeaf8 100644
--- a/arch/powerpc/boot/dts/mpc8568mds.dts
+++ b/arch/powerpc/boot/dts/mpc8568mds.dts
@@ -42,9 +42,64 @@
reg = < 1000>;
};
- [EMAIL PROTECTED] {
- device_type = "board-control";
- reg = ;
+ [EMAIL PROTECTED] {
+ #address-cells = <2>;
+ #size-cells = <1>;
+ compatible = "fsl,mpc8568-localbus";
+ reg = ;
+ ranges = <1 0 f800 0008000
+ 0 0 fe00 200>;
+
+ [EMAIL PROTECTED],0 {
+ device_type = "board-control";
+ reg = <1 0 8000>;
+ };
+
+ [EMAIL PROTECTED],0 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "Spansion,S29GL256N11TFIV2O", "cfi-flash";
+ reg = <0 0 200>;
+ bank-width = <2>;
+ device-width = <1>;
+
+ [EMAIL PROTECTED] {
+ label = "hrcw";
+ reg = <0 2>;
+ read-only;
+ };
+
+ [EMAIL PROTECTED] {
+ label = "u-boot";
+ reg = <1f8 8>;
+
re: Linux root file system with X window support for a powerpc board
debian: (on x86/fedora development system) (used on 82xx) 1. debootstrap with the --foreign i.e. debootstrap --arch powerpc etch http://mirrors.kernel.org/debian mannually create an inittab, create/copy some default /dev entries 2. boot 74xx target with above root filesystem, run /debootstrap/debootstrap --second-stage Now add in packages using apt-get (or add them initially in step 1) -Alan Hi all Can anybody help me how to create a Linux root file system with X window support for a powerpc 74xx based board ? Any documents/links related to that is also welcome Thanks in advance R.Mahendravarman ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
DTC: DTC {before,after} Comparison Script
Guys,
And just for the record, here is the QAD script that
I used to verify that all the existing DTS files in
the arch/powerpc/boot/dts directory are byte-identical
before and after my recent modifications. Naturally,
all the DTS files are still in "legacy dts-version 0"
still. But I don't think I broke that mode now. :-)
Feel free to productize or otherwise improve on it...
jdl
#!/usr/bin/perl
my $dtc_old = "dtc/dtc-old";
my $dtc_new = "dtc/dtc-new-debug";
my $basic_options = "-b 0 -f -I dts -O dtb";
my $linux_dts_dir = "linux-2.6/arch/powerpc/boot/dts";
# Yeah, sure, we could, like, readdir() this instead...
my @boards = (
"bamboo",
"ebony",
"ep88xc",
"holly",
"kilauea",
"kuroboxHD",
"kuroboxHG",
"lite5200",
"lite5200b",
"mpc7448hpc2",
"mpc8272ads",
"mpc8313erdb",
"mpc832x_mds",
"mpc832x_rdb",
"mpc8349emitx",
"mpc8349emitxgp",
"mpc834x_mds",
"mpc836x_mds",
"mpc8540ads",
"mpc8541cds",
"mpc8544ds",
"mpc8548cds",
"mpc8555cds",
"mpc8560ads",
"mpc8568mds",
"mpc8572ds",
"mpc8610_hpcd",
"mpc8641_hpcn",
"mpc866ads", # Feh. Bad node references...
"mpc885ads",
"pq2fads",
"prpmc2800",
"ps3",
"sequoia",
"walnut",
);
foreach my $board (@boards) {
my $dts_file = "$linux_dts_dir/$board.dts";
my $old_dtb_file = "/tmp/$board.dtb.old";
my $new_dtb_file = "/tmp/$board.dtb.new";
my $cmd_old = "$dtc_old $basic_options -o $old_dtb_file $dts_file";
my $cmd_new = "$dtc_new $basic_options -o $new_dtb_file $dts_file";
my $cmd_cmp = "cmp $old_dtb_file $new_dtb_file";
print "\n";
print "OLD: $cmd_old\n";
unlink($old_dtb_file) if (-f $old_dtb_file);
system("$cmd_old >& /dev/null");
my $status = $?;
if ($status) {
print "FAILED to run old DTC on $board\n";
}
print "NEW: $cmd_new\n";
unlink($new_dtb_file) if (-f $new_dtb_file);
system("$cmd_new >& /dev/null");
$status = $?;
if ($status) {
print "FAILED to run new DTC on $board\n";
}
if (-f $old_dtb_file && -f $new_dtb_file) {
print "CMP: $cmd_cmp\n";
system($cmd_cmp);
$status = $?;
if ($status) {
print "FAILED $board\n";
}
} else {
printf "FAILED: Missing dtb file\n";
}
}
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 4/4] DTC: Begin the path to sane literals and expressions.
Add support for the "/dts-version/ ;" statment.
Make legacy DTS files version 0 whether explicitly stated
or implied by a lack of /dts-version/ statement.
Begin supporting a new /dts-version/ 1 that changes the
format of the literals in a DTS source file. In the new
format, hex constants are prefixed with 0x or 0X, and
bare numbers are decimal or octal according to standard
conventions.
Property names have been limited to start with
characters from the set [a-zA-Z,._#?]. That is, the
digits and the expression symbols have been removed.
Use of "d#', "o#", "h#" and "b#" are gone in version 1.
Several warnings are introduced for debatable constructs.
- Only /dts-version/ 0 and 1 are supported yet.
- A missing /dts-version/ statement garners a
suggestion to add one, and defaults to verion 0.
- The /memreserve/ construct using "-" for ranges looks
suspiciously like the subtraction of two expressions,
so its syntax has been changed to use ".." as the range
indicator.
Signed-off-by: Jon Loeliger <[EMAIL PROTECTED]>
---
dtc-lexer.l | 180 +
dtc-parser.y | 143 +++---
dtc.c| 26
dtc.h| 23 ++--
srcpos.h |1 +
treesource.c | 24 +++-
6 files changed, 303 insertions(+), 94 deletions(-)
diff --git a/dtc-lexer.l b/dtc-lexer.l
index 278a96e..a1c52c4 100644
--- a/dtc-lexer.l
+++ b/dtc-lexer.l
@@ -22,12 +22,19 @@
%x INCLUDE
%x CELLDATA
+%x CELLDATA_LEGACY
%x BYTESTRING
+%x BYTESTRING_LEGACY
%x MEMRESERVE
+%x MEMRESERVE_LEGACY
+DIGIT [0-9]
+HEXDIGIT [0-9a-fA-F]
+FIRSTPROPCHAR [a-zA-Z,._#?]
PROPCHAR [a-zA-Z0-9,._+*#?-]
UNITCHAR [0-9a-f,]
WS [[:space:]]
+DOT[.]
REFCHAR({PROPCHAR}|{UNITCHAR}|[/@])
@@ -46,11 +53,20 @@ REFCHAR ({PROPCHAR}|{UNITCHAR}|[/@])
#endif
+unsigned int in_lexer_use_base = 16; /* Feedback from parser. Ugh. */
+
%}
%%
+"/dts-version/"{
+ yylloc.filenum = srcpos_filenum;
+ yylloc.first_line = yylineno;
+ DPRINT("Keyword: /dts-version/\n");
+ return DT_DTS_VERSION;
+ }
+
"/include/"BEGIN(INCLUDE);
\"[^"\n]*\" {
@@ -83,24 +99,15 @@ REFCHAR ({PROPCHAR}|{UNITCHAR}|[/@])
yylloc.filenum = srcpos_filenum;
yylloc.first_line = yylineno;
DPRINT("Keyword: /memreserve/\n");
- BEGIN(MEMRESERVE);
- return DT_MEMRESERVE;
- }
-
-[0-9a-fA-F]+ {
- yylloc.filenum = srcpos_filenum;
- yylloc.first_line = yylineno;
- if (yyleng > 2*sizeof(yylval.addr)) {
- fprintf(stderr, "Address value %s too large\n",
- yytext);
+ if (dts_version == 0) {
+ BEGIN(MEMRESERVE_LEGACY);
+ } else {
+ BEGIN(MEMRESERVE);
}
- yylval.addr = (u64) strtoull(yytext, NULL, 16);
- DPRINT("Addr: %llx\n",
- (unsigned long long)yylval.addr);
- return DT_ADDR;
+ return DT_MEMRESERVE;
}
-";"{
+";" {
yylloc.filenum = srcpos_filenum;
yylloc.first_line = yylineno;
DPRINT("/MEMRESERVE\n");
@@ -117,7 +124,7 @@ REFCHAR ({PROPCHAR}|{UNITCHAR}|[/@])
return DT_LABEL;
}
-[bodh]# {
+[bodh]# {
yylloc.filenum = srcpos_filenum;
yylloc.first_line = yylineno;
if (*yytext == 'b')
@@ -132,15 +139,7 @@ REFCHAR({PROPCHAR}|{UNITCHAR}|[/@])
return DT_BASE;
}
-[0-9a-fA-F]+ {
- yylloc.filenum = srcpos_filenum;
- yylloc.first_line = yylineno;
- yylval.str = strdup(yytext);
- DPRINT("Cell: '%s'\n", yylval.str);
- return DT_CELL;
- }
-
-">" {
+">" {
yylloc.filenum = srcpos_filenum;
yylloc.first_line = yylineno;
DPRINT("/CELLDATA\n");
@@ -156,15 +155,7 @@ REFCHAR({PROPCHAR}|{UNITCHAR}|[/@])
return DT_REF;
}
-[0-9a-fA-F]{2} {
- yylloc.filenum = srcpos_filenum;
- yylloc.first_line = yylineno;
- yylval.byte = strtol(yytext, NULL, 16);
- DPRINT("Byte: %02x\n", (int)yylval.b
[PATCH 3/4] DTC: Appease the printf() format $Gods with a correct type.
Signed-off-by: Jon Loeliger <[EMAIL PROTECTED]>
---
tests/get_name.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/tests/get_name.c b/tests/get_name.c
index 2481741..a76bdf8 100644
--- a/tests/get_name.c
+++ b/tests/get_name.c
@@ -55,7 +55,7 @@ void check_name(void *fdt, const char *path)
if (len != strlen(getname))
FAIL("fdt_get_name(%s) returned length %d instead of %d",
-path, len, strlen(getname));
+path, len, (int) strlen(getname));
/* Now check that it doesn't break if we omit len */
getname2 = fdt_get_name(fdt, offset, NULL);
--
1.5.3.1.139.g9346b
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 0/4] DTC: Introduce better DTS literal support
Folks, This 4 part patch series for the DTC has: 0001-Reformat-grammar-rules-to-not-mix-language-syntax-an.patch 0002-Quiet-a-bogus-May-be-used-uninitialized-warning.patch 0003-Appease-the-printf-format-Gods-with-a-correct-typ.patch 0004-Begin-the-path-to-sane-literals-and-expressions.patch The first is a pure whitespace formatting cleaning. The second two clean compiler warnings. The final one introduces a versioned DTS file with support for C-like literals. dtc-lexer.l | 180 dtc-parser.y | 275 -- dtc.c| 26 + dtc.h| 23 - flattree.c |2 +- srcpos.h |1 + tests/get_name.c |2 +- treesource.c | 24 - 8 files changed, 413 insertions(+), 120 deletions(-) Thanks, jdl ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: powerpc 440 monitor program
In order to achieve your goal you must do at least following things: 1) enable FRAMEBUFFER_CONSOLE option in the kernel. 2) Upon reboot make getty for the monitor terminal device (could be tty1, but you must check). You may add line to your inittab file tty1::respawn:/sbin/getty 38400 tty1 Speed parameter is irrelevant and may not be needed for your getty version. 3) To see the penguin logo you must also enable one of BOOT_LOGO defines in kernel. Of course I assume that framebuffer is working in your system. You may try to check it by typing "cat /dev/zero > /dev/fb0". Terminal must be cleaned then. You also can try "dirty" hack to ensure framebuffer functionality. Type: sh > /dev/tty1 2>&1 < /dev/tty1 You must get prompt on monitor (your serial will hang) and if you have working (USB?) keyboard, you will be able to use monitor. Thanks, Leonid. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of David Gibson Sent: Thursday, October 18, 2007 8:49 PM To: Bai Shuwei Cc: linuxppc-dev@ozlabs.org; [EMAIL PROTECTED] Subject: Re: powerpc 440 monitor program On Fri, Oct 19, 2007 at 11:32:33AM +0800, Bai Shuwei wrote: > all, > hi, when I boot my system, there are no output on the screen. > I choice the framebuffer and my monitor card is ATI PAGE 128 PCI, qt/e GUI. > When i compile the kernel, the boot logo and aty 128fb has be compiled into > kernel patched with videoboot, and x86emu. The video parameters set: > video=aty128fb:[EMAIL PROTECTED] > The kenel can recognize the monitor card, and the frame buffer device > has run. > The output showed below: > > videoboot: Booting PCI video card bus 0, function 0, device 6 >aty128fb: Found Intel x86 BIOS ROM Image >aty128fb: Rage128 BIOS located >aty128fb: Rage128 RK PCI [chip rev 0x2] 32M 64-bit SDR SGRAM (2:1) >fb0: ATY Rage128 frame buffer device on Rage128 RK PCI > > My problem is there is no output on the monitor,and cannot see the penguin > boot logo. Uh.. most 440 systems use a serial console. It ought in theory to be possible to use a framebuffer instead, but it wouldn't surprise me if rather a lot of debugging was necessary. -- David Gibson| I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson ___ Linuxppc-embedded mailing list [EMAIL PROTECTED] https://ozlabs.org/mailman/listinfo/linuxppc-embedded ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: [PATCH v3] Device tree bindings for Xilinx devices
Here's a full .dts generated using an updated version of
gen_mhs_devtree.py, following the proposal.
It happens to be a microblaze system, but you get the idea.
Grant: Is this pretty what you intend?
Steve
/ {
#address-cells = <1>;
#size-cells = <1>;
compatible = "ibm,plb4";
model = "system.mhs";
Ethernet_MAC {
compatible =
"xilinx,opb-ethernet-1.04.a\0xilinx,opb-ethernet";
device_type = "opb_ethernet";
interrupt-parent = <101>;
interrupts = < 1 0 >;
reg = < 40c0 1 >;
xilinx,cam-exist = <0>;
xilinx,dev-blk-id = <0>;
xilinx,dev-mir-enable = <0>;
xilinx,dma-present = <1>;
xilinx,include-dev-pencoder = <0>;
xilinx,ipif-rdfifo-depth = <4000>;
xilinx,ipif-wrfifo-depth = <4000>;
xilinx,jumbo-exist = <0>;
xilinx,mac-fifo-depth = <10>;
xilinx,mii-exist = <1>;
xilinx,opb-clk-period-ps = <2710>;
xilinx,reset-present = <1>;
xilinx,rx-dre-type = <0>;
xilinx,rx-include-csum = <0>;
xilinx,tx-dre-type = <0>;
xilinx,tx-include-csum = <0>;
} ;
IIC_EEPROM {
compatible = "xilinx,opb-iic-1.02.a\0xilinx,opb-iic";
device_type = "opb_iic";
interrupt-parent = <101>;
interrupts = < 2 0 >;
reg = < 4080 1 >;
xilinx,clk-freq = <5f5e100>;
xilinx,iic-freq = <186a0>;
xilinx,ten-bit-adr = <0>;
} ;
RS232_Uart_1 {
compatible =
"xilinx,opb-uartlite-1.00.b\0xilinx,opb-uartlite";
device_type = "opb_uartlite";
interrupt-parent = <101>;
interrupts = < 3 0 >;
reg = < 4060 1 >;
xilinx,baudrate = <2580>;
xilinx,clk-freq = <5f5e100>;
xilinx,data-bits = <8>;
xilinx,odd-parity = <0>;
xilinx,use-parity = <0>;
} ;
chosen {
bootargs = "root=/dev/xsysace/disc0/part2";
interrupt-controller = <101>;
linux,platform = <600>;
} ;
cpus {
#address-cells = <1>;
#cpus = <1>;
#size-cells = <0>;
microblaze_0,6.00. {
32-bit;
clock-frequency = <5f5e1000>;
d-cache-line-size = <10>;
d-cache-size = <4000>;
device_type = "cpu";
i-cache-line-size = <10>;
i-cache-size = <4000>;
linux,boot-cpu;
reg = <0>;
timebase-frequency = <1fca055>;
xilinx,cache-byte-size = <4000>;
xilinx,dcache-baseaddr = <5000>;
xilinx,dcache-byte-size = <4000>;
xilinx,dcache-highaddr = <5fff>;
xilinx,debug-enabled = <1>;
xilinx,div-zero-exception = <1>;
xilinx,dopb-bus-exception = <1>;
xilinx,fpu-exception = <1>;
xilinx,icache-baseaddr = <5000>;
xilinx,icache-highaddr = <5fff>;
xilinx,ill-opcode-exception = <1>;
xilinx,iopb-bus-exception = <1>;
xilinx,number-of-pc-brk = <2>;
xilinx,pvr = <2>;
xilinx,unaligned-exceptions = <1>;
xilinx,use-barrel = <1>;
xilinx,use-dcache = <1>;
xilinx,use-div = <1>;
xilinx,use-fpu = <1>;
xilinx,use-icache = <1>;
xilinx,use-msr-instr = <1>;
xilinx,use-pcmp-instr = <1>;
} ;
} ;
debug_module {
compatible = "xilinx,opb-mdm-2.00.a\0xilinx,opb-mdm";
device_type = "opb_mdm";
reg = < 4140 1 >;
xilinx,mb-dbg-ports = <1>;
xilinx,uart-width = <8>;
xilinx,use-uart = <1>;
} ;
[EMAIL PROTECTED] {
device_type = "memory";
edk_name = "DDR2_SDRAM_32Mx32";
memreg:reg = < 5000 1000 >;
} ;
opb_hwicap_0 {
compatible =
"xilinx,opb-hwicap-1.10.a\0xilinx,opb-hwicap";
device_type = "opb_hwicap";
reg = < 4130 1 >;
} ;
opb_intc_0 {
#interrupt-cells = <2>;
Re: [PATCH] bestcomm: Restrict disabling of bus prefetch to original mpc5200 silicon.
Grant Likely wrote: > On 10/19/07, Domen Puncer <[EMAIL PROTECTED]> wrote: >> On 17/10/07 10:36 -0600, Grant Likely wrote: >>> From: Grant Likely <[EMAIL PROTECTED]> >>> >>> Only the MPC5200 needs this bug fix. MPC5200B is okay. >>> >>> Signed-off-by: Grant Likely <[EMAIL PROTECTED]> >>> --- >>> >>> Sven, Domen; >>> >>> Can you please test this patch? >> I found no obvious problems with it on Efika (mpc5200b) > > Cool, I'll add it to my list of patches for Paulus to pull See now that wasn't so hard was it? :D You earned a cookie :D -- Matt Sealey <[EMAIL PROTECTED]> Genesi, Manager, Developer Relations ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] powerpc: mpic: minor optimization of ipi handler
Optimize MPIC IPIs, by passing in the IPI number as the argument to the
handler, since all we did was translate it back based on which mpic
the interrupt came though on (and that was always the primary mpic).
Signed-off-by: Olof Johansson <[EMAIL PROTECTED]>
---
On Fri, Oct 19, 2007 at 06:31:34PM -0500, Olof Johansson wrote:
> On Sat, Oct 20, 2007 at 09:17:39AM +1000, Benjamin Herrenschmidt wrote:
> >
> > On Fri, 2007-10-19 at 13:51 -0500, Olof Johansson wrote:
> > > Jeff Garzik pointed out that we don't actually have to lookup the mpic
> > > instance since it's passed in as the interrupt handler data for IPIs.
> >
> > Note that's typically one of the annoying case where we use "irq"
> > for a good reasons, getting the way of Jeff attempt at removing
> > this argument.
> >
> > I suppose a working approach would be to have 4 mpic IPI handlers...
>
> We still need the _irq_, but we don't need to lookup the mpic based on it.
>
> We knew the mpic pointer at irq setup time, and passed it in as the
> argument to pass to the handler. Doing a second lookup is just extra
> overhead, it should return the same controller:
Oh, I see what you mean. You didn't make it easy to parse. :)
This should actually do the work.
-Olof
diff --git a/arch/powerpc/sysdev/mpic.c b/arch/powerpc/sysdev/mpic.c
index e479388..a8d7c68 100644
--- a/arch/powerpc/sysdev/mpic.c
+++ b/arch/powerpc/sysdev/mpic.c
@@ -614,10 +614,9 @@ static inline void mpic_eoi(struct mpic *mpic)
#ifdef CONFIG_SMP
static irqreturn_t mpic_ipi_action(int irq, void *data)
{
- struct mpic *mpic;
+ long ipi = (long)data;
- mpic = mpic_find(irq, NULL);
- smp_message_recv(mpic_irq_to_hw(irq) - mpic->ipi_vecs[0]);
+ smp_message_recv(ipi);
return IRQ_HANDLED;
}
@@ -1457,7 +1456,7 @@ unsigned int mpic_get_irq(void)
void mpic_request_ipis(void)
{
struct mpic *mpic = mpic_primary;
- int i, err;
+ long i, err;
static char *ipi_names[] = {
"IPI0 (call function)",
"IPI1 (reschedule)",
@@ -1472,14 +1471,14 @@ void mpic_request_ipis(void)
unsigned int vipi = irq_create_mapping(mpic->irqhost,
mpic->ipi_vecs[0] + i);
if (vipi == NO_IRQ) {
- printk(KERN_ERR "Failed to map IPI %d\n", i);
+ printk(KERN_ERR "Failed to map IPI %ld\n", i);
break;
}
err = request_irq(vipi, mpic_ipi_action,
IRQF_DISABLED|IRQF_PERCPU,
- ipi_names[i], mpic);
+ ipi_names[i], (void *)i);
if (err) {
- printk(KERN_ERR "Request of irq %d for IPI %d failed\n",
+ printk(KERN_ERR "Request of irq %d for IPI %ld
failed\n",
vipi, i);
break;
}
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] powerpc: mpic: minor optimization of ipi handler
On Sat, Oct 20, 2007 at 09:17:39AM +1000, Benjamin Herrenschmidt wrote:
>
> On Fri, 2007-10-19 at 13:51 -0500, Olof Johansson wrote:
> > Jeff Garzik pointed out that we don't actually have to lookup the mpic
> > instance since it's passed in as the interrupt handler data for IPIs.
>
> Note that's typically one of the annoying case where we use "irq"
> for a good reasons, getting the way of Jeff attempt at removing
> this argument.
>
> I suppose a working approach would be to have 4 mpic IPI handlers...
We still need the _irq_, but we don't need to lookup the mpic based on it.
We knew the mpic pointer at irq setup time, and passed it in as the
argument to pass to the handler. Doing a second lookup is just extra
overhead, it should return the same controller:
void mpic_request_ipis(void)
{
struct mpic *mpic = mpic_primary;
int i, err;
static char *ipi_names[] = {
"IPI0 (call function)",
"IPI1 (reschedule)",
"IPI2 (unused)",
"IPI3 (debugger break)",
};
BUG_ON(mpic == NULL);
printk(KERN_INFO "mpic: requesting IPIs ... \n");
for (i = 0; i < 4; i++) {
unsigned int vipi = irq_create_mapping(mpic->irqhost,
mpic->ipi_vecs[0] + i);
if (vipi == NO_IRQ) {
printk(KERN_ERR "Failed to map IPI %d\n", i);
break;
}
err = request_irq(vipi, mpic_ipi_action,
IRQF_DISABLED|IRQF_PERCPU,
ipi_names[i], mpic);
if (err) {
printk(KERN_ERR "Request of irq %d for IPI %d failed\n",
vipi, i);
break;
}
}
}
-Olof
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] powerpc: mpic: minor optimization of ipi handler
On Fri, 2007-10-19 at 13:51 -0500, Olof Johansson wrote:
> Jeff Garzik pointed out that we don't actually have to lookup the mpic
> instance since it's passed in as the interrupt handler data for IPIs.
Note that's typically one of the annoying case where we use "irq"
for a good reasons, getting the way of Jeff attempt at removing
this argument.
I suppose a working approach would be to have 4 mpic IPI handlers...
Ben.
> Signed-off-by: Olof Johansson <[EMAIL PROTECTED]>
>
> diff --git a/arch/powerpc/sysdev/mpic.c b/arch/powerpc/sysdev/mpic.c
> index e479388..6bf56f4 100644
> --- a/arch/powerpc/sysdev/mpic.c
> +++ b/arch/powerpc/sysdev/mpic.c
> @@ -612,11 +612,10 @@ static inline void mpic_eoi(struct mpic *mpic)
> }
>
> #ifdef CONFIG_SMP
> -static irqreturn_t mpic_ipi_action(int irq, void *dev_id)
> +static irqreturn_t mpic_ipi_action(int irq, void *data)
> {
> - struct mpic *mpic;
> + struct mpic *mpic = data;
>
> - mpic = mpic_find(irq, NULL);
> smp_message_recv(mpic_irq_to_hw(irq) - mpic->ipi_vecs[0]);
>
> return IRQ_HANDLED;
> ___
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] synchronize_irq needs a barrier
On Thursday 18 October 2007 03:25:42 Benjamin Herrenschmidt wrote: > synchronize_irq needs at the very least a compiler barrier and a > read barrier on SMP, but there are enough cases around where a > write barrier is also needed and it's not a hot path so I prefer > using a full smp_mb() here. > > It will degrade to a compiler barrier on !SMP. > > Signed-off-by: Benjamin Herrenschmidt <[EMAIL PROTECTED]> > --- > > Index: linux-work/kernel/irq/manage.c > === > --- linux-work.orig/kernel/irq/manage.c 2007-10-18 11:22:16.0 > +1000 > +++ linux-work/kernel/irq/manage.c2007-10-18 11:22:20.0 +1000 > @@ -33,6 +33,7 @@ void synchronize_irq(unsigned int irq) > if (irq >= NR_IRQS) > return; > > + smp_mb(); > while (desc->status & IRQ_INPROGRESS) > cpu_relax(); > } > > > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ > Hi, I have read this thread and I concluded few things: 1) It is impossible to know that the card won't send more interrupts: Even if I do a read from the device, the IRQ can be pending in the bus/APIC It is even possible (and likely) that the IRQ line will be shared, thus the handler can be called by non-relevant device. 2) the synchronize_irq(); in .suspend is useless: an IRQ can happen immediately after this synchronize_irq(); and interrupt even the .suspend() (At least theoretically) Thus I now understand that .suspend() should do: saa_writel(SAA7134_IRQ1, 0); saa_writel(SAA7134_IRQ2, 0); saa_writel(SAA7134_MAIN_CTRL, 0); dev->insuspend = 1; smp_wmb(); /* at that point the _request to disable card's IRQs was issued, we don't know that there will be no irqs anymore. the smp_mb(); guaranties that the IRQ handler will bail out in that case. */ /* ...*/ pci_save_state(pci_dev); pci_set_power_state(pci_dev, pci_choose_state(pci_dev, state)); return 0; and the interrupt handler: smp_rmb(); if (dev->insuspend) goto out; Am I right? Best regards, Maxim Levitsky ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] Fix build break in tsi108.c
Fix build break: drivers/net/tsi108_eth.c: In function 'tsi108_init_one': drivers/net/tsi108_eth.c:1633: error: expected ')' before 'dev' drivers/net/tsi108_eth.c:1633: warning: too few arguments for format make[2]: *** [drivers/net/tsi108_eth.o] Error 1 Signed-off-by: Olof Johansson <[EMAIL PROTECTED]> diff --git a/drivers/net/tsi108_eth.c b/drivers/net/tsi108_eth.c index df10af7..35d15e8 100644 --- a/drivers/net/tsi108_eth.c +++ b/drivers/net/tsi108_eth.c @@ -1629,7 +1629,7 @@ tsi108_init_one(struct platform_device *pdev) goto register_fail; } - printk(KERN_INFO "%s: Tsi108 Gigabit Ethernet, MAC: %s\n" + printk(KERN_INFO "%s: Tsi108 Gigabit Ethernet, MAC: %s\n", dev->name, print_mac(mac, dev->dev_addr)); #ifdef DEBUG data->msg_enable = DEBUG; ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [BUG] powerpc does not save msi state [was Re: [PATCH 5/7] pci: Export the pci_restore_msi_state() function
From: [EMAIL PROTECTED] (Linas Vepstas)
Date: Fri, 19 Oct 2007 19:46:10 -0500
> FWIW, it looks like not all that many arches do this; the output
> for grep -r address_hi * is pretty thin. Then, looking at
> i386/kernel/io_apic.c as an example, one can see that the
> msi state save happens "by accident" if CONFIG_SMP is enabled;
> and so its surely broekn on uniprocesor machines.
I don't see this, in all cases write_msi_msg() will transfer
the given "*msg" to entry->msg by this assignment in
drivers/pci/msi.c:
void write_msi_msg(unsigned int irq, struct msi_msg *msg)
{
...
entry->msg = *msg;
}
So as long as write_msi_msg() is invoked, it will be saved
properly.
Platforms need not do this explicitly.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[BUG] powerpc does not save msi state [was Re: [PATCH 5/7] pci: Export the pci_restore_msi_state() function
Hi, On Fri, Oct 19, 2007 at 05:27:06PM -0700, David Miller wrote: > From: [EMAIL PROTECTED] (Linas Vepstas) > Date: Fri, 19 Oct 2007 19:04:21 -0500 > > > I'm working in linux-2.6.23-rc8-mm1 at the moment, and I don't see > > that happening. viz. read_msi_msg() is not called anywhere, and I need > > to have valid msg->address_lo and msg->address_hi and msg->data > > in order to be able to restore. > > See the pci_restore_msi_state() call done from pci_restore_state() > in drivers/pci/pci.c, that pci_restore_msi_state() code in > drivers/pci/msi.c very much relies upon the entry->msg values > being uptodate and valid. > > The MSI arch layer code is supposed to fill the entry->msg values in > via arch_setup_msi_irq(). Perhaps the pseries code is forgetting to > do that. Yep. Thank you for confirming the correct location for the fix. FWIW, it looks like not all that many arches do this; the output for grep -r address_hi * is pretty thin. Then, looking at i386/kernel/io_apic.c as an example, one can see that the msi state save happens "by accident" if CONFIG_SMP is enabled; and so its surely broekn on uniprocesor machines. I'm cc'ing the powerpc mailing list to point this out: it looks like only cell/axon_msi.c and mpic_u3msi.c bother do do anything. I guess that there aren't any old macintosh laptops that have msi on them? Because without this, suspend and resume breaks. Paul, On the off chance your reading this, I'll send a pseries patch on Monday, with luck (and some other patches too). I'm not touching any of the other plaforms, you and benh would know those better. --linas ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] synchronize_irq needs a barrier
On Saturday 20 October 2007 04:25:34 Linus Torvalds wrote:
>
> On Sat, 20 Oct 2007, Maxim Levitsky wrote:
> >
> > and the interrupt handler:
> >
> > smp_rmb();
> > if (dev->insuspend)
> > goto out;
>
> Something like that can work, yes. However, you need to make sure that:
>
> - even when you ignore the interrupt (because the driver doesn't care,
>it's suspending), you need to make sure the hardware gets shut up by
>reading (or writing) the proper interrupt status register.
I agree, but while device is powered off, its registers can't be accessed
Thus, if I ack the IRQ every time the handler is called, I will access the
powered off device (this is probably won't hurt a lot, but a bit incorrectly)
>
>Otherwise, with a level interrupt, the interrupt will continue to be
>held active ("screaming") and the CPU will get interrupted over and
>over again, until the irq subsystem will just turn the irq off
>entirely.
>
> - when you resume, make sure that you get the engine going again, with
>the understanding that some interrupts may have gotten ignored.
Here it isn't a problem, this is a video capture card, and I suspend it by just
stopping dma
on all active buffers even if in the middle of capture, and I send those
buffers to card again
to fill them from the beginning during the resume.
>
> Also, in general, these kinds of things shouldn't always even be
> neicessary. If you use the suspend_late()/resume_early() hooks, those will
> be called with interrupts off, and while they can be harder to debug (and
> may be worth avoiding for non-critical drivers), they do allow for simpler
> models partly exactly because they don't need to worry about interrupts
> etc.
Exactly, I am aware of suspend_late , but I don't want to abuse it.
>
> Linus
>
Best regards,
Maxim Levitsky
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] Fix build break in tsi108.c
Olof Johansson wrote: > Fix build break: > > drivers/net/tsi108_eth.c: In function 'tsi108_init_one': > drivers/net/tsi108_eth.c:1633: error: expected ')' before 'dev' > drivers/net/tsi108_eth.c:1633: warning: too few arguments for format > make[2]: *** [drivers/net/tsi108_eth.o] Error 1 > > > Signed-off-by: Olof Johansson <[EMAIL PROTECTED]> > > diff --git a/drivers/net/tsi108_eth.c b/drivers/net/tsi108_eth.c > index df10af7..35d15e8 100644 > --- a/drivers/net/tsi108_eth.c > +++ b/drivers/net/tsi108_eth.c > @@ -1629,7 +1629,7 @@ tsi108_init_one(struct platform_device *pdev) > goto register_fail; > } > > - printk(KERN_INFO "%s: Tsi108 Gigabit Ethernet, MAC: %s\n" > + printk(KERN_INFO "%s: Tsi108 Gigabit Ethernet, MAC: %s\n", > dev->name, print_mac(mac, dev->dev_addr)); > #ifdef DEBUG applied ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] synchronize_irq needs a barrier
On Sat, Oct 20, 2007 at 02:02:42AM +, Maxim Levitsky wrote:
>
> Thus I now understand that .suspend() should do:
>
> saa_writel(SAA7134_IRQ1, 0);
> saa_writel(SAA7134_IRQ2, 0);
> saa_writel(SAA7134_MAIN_CTRL, 0);
>
> dev->insuspend = 1;
> smp_wmb();
If we patch synchronize_irq() as discussed here then you can
use it in place of smp_wmb() and remove the smp_rmb from the
interrupt handler (the latter is the path that matters).
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] phy/bitbang: missing MODULE_LICENSE
Randy Dunlap wrote: > From: Randy Dunlap <[EMAIL PROTECTED]> > > Missing MODULE_LICENSE(), loading this module taints the kernel. > > Signed-off-by: Randy Dunlap <[EMAIL PROTECTED]> > --- > drivers/net/phy/mdio-bitbang.c |2 ++ > 1 file changed, 2 insertions(+) applied this and the NAPI_Howto Kconfig patch ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] fix build break in arch/ppc/syslib/m8260_setup.c
Fix build break and warnings in current mainline git: arch/ppc/syslib/m8260_setup.c: In function 'm8260_setup_arch': arch/ppc/syslib/m8260_setup.c:63: error: implicit declaration of function 'identify_ppc_sys_by_name_and_id' arch/ppc/syslib/m8260_setup.c:64: warning: passing argument 1 of 'in_be32' makes pointer from integer without a cast arch/ppc/syslib/m8260_setup.c: In function 'm8260_show_cpuinfo': arch/ppc/syslib/m8260_setup.c:158: warning: format '%08x' expects type 'unsigned int', but argument 5 has type 'long unsigned int' arch/ppc/syslib/m8260_setup.c:158: warning: format '%d' expects type 'int', but argument 6 has type 'long unsigned int' arch/ppc/syslib/m8260_setup.c:158: warning: format '%u' expects type 'unsigned int', but argument 7 has type 'long unsigned int' arch/ppc/syslib/m8260_setup.c:158: warning: format '%u' expects type 'unsigned int', but argument 8 has type 'long unsigned int' arch/ppc/syslib/m8260_setup.c:158: warning: format '%u' expects type 'unsigned int', but argument 9 has type 'long unsigned int' make[1]: *** [arch/ppc/syslib/m8260_setup.o] Error 1 make[1]: *** Waiting for unfinished jobs Signed-off-by: Olof Johansson <[EMAIL PROTECTED]> diff --git a/arch/ppc/syslib/m8260_setup.c b/arch/ppc/syslib/m8260_setup.c index 15f0d73..46588fa 100644 --- a/arch/ppc/syslib/m8260_setup.c +++ b/arch/ppc/syslib/m8260_setup.c @@ -25,6 +25,7 @@ #include #include #include +#include #include "cpm2_pic.h" @@ -61,7 +62,7 @@ m8260_setup_arch(void) #endif identify_ppc_sys_by_name_and_id(BOARD_CHIP_NAME, - in_be32(CPM_MAP_ADDR + CPM_IMMR_OFFSET)); + in_be32((void *)CPM_MAP_ADDR + CPM_IMMR_OFFSET)); m82xx_board_setup(); } @@ -147,12 +148,12 @@ m8260_show_cpuinfo(struct seq_file *m) seq_printf(m, "vendor\t\t: %s\n" "machine\t\t: %s\n" "\n" - "mem size\t\t: 0x%08x\n" - "console baud\t\t: %d\n" + "mem size\t\t: 0x%08lx\n" + "console baud\t\t: %ld\n" "\n" - "core clock\t: %u MHz\n" - "CPM clock\t: %u MHz\n" - "bus clock\t: %u MHz\n", + "core clock\t: %lu MHz\n" + "CPM clock\t: %lu MHz\n" + "bus clock\t: %lu MHz\n", CPUINFO_VENDOR, CPUINFO_MACHINE, bp->bi_memsize, bp->bi_baudrate, bp->bi_intfreq / 100, bp->bi_cpmfreq / 100, bp->bi_busfreq / 100); ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] [POWERPC] ucc_geth: Eliminate compile warnings
From: "Medve Emilian-EMMEDVE1" <[EMAIL PROTECTED]> Date: Fri, 19 Oct 2007 06:39:12 -0700 > For the current situation, 32-bit QE, 32-bit PowerPC, do you find > the patch acceptable? No piece of code in the kernel should live in a vacuum. In order to improve overall code quality, every piece of driver code should avoid assuming things about pointer sizes and things of this nature. Then the driver can get enabled into the build on every platform, and therefore nobody will break the build of this driver again since it will get hit by "allmodconfig" et al. builds even on platforms other than the one it is meant for. This hack fix is not acceptable, really. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
ep88xc_defconfig doesn't build
Hi, Did it ever?! I get this with current mainline when building default target: WRAParch/powerpc/boot/cuImage.8xx DTC: dts->dtb on file "/work/work/linux/k.org/arch/powerpc/boot/dts/ep88xc.dts" ERROR: Missing /chosen node Input tree has errors WRAParch/powerpc/boot/zImage.ep88xc make[1]: *** [arch/powerpc/boot/cuImage.8xx] Error 1 make[1]: *** Waiting for unfinished jobs DTC: dts->dtb on file "/work/work/linux/k.org/arch/powerpc/boot/dts/ep88xc.dts" ERROR: Missing /chosen node Input tree has errors make[1]: *** [arch/powerpc/boot/zImage.ep88xc] Error 1 make: *** [zImage] Error 2 -Olof ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [microblaze-uclinux] RE: [PATCH v3] Device tree bindings for Xilinx devices
Hi Steve and all, >Here's a full .dts generated using an updated version of >gen_mhs_devtree.py, following the proposal. >It happens to be a microblaze system, but you get the idea. I think that is no good idea generate dts with all information. Especially information about PVR - number 2 means - Full PVR and you can obtain information directly from PVR. It is waste of memory space. xilinx,pvr = <2>; In my opinion will be better generate only parameters which you want not all. That smells with unusable parameters. Michal Simek ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] synchronize_irq needs a barrier
On Sat, 20 Oct 2007, Maxim Levitsky wrote:
>
> and the interrupt handler:
>
> smp_rmb();
> if (dev->insuspend)
> goto out;
Something like that can work, yes. However, you need to make sure that:
- even when you ignore the interrupt (because the driver doesn't care,
it's suspending), you need to make sure the hardware gets shut up by
reading (or writing) the proper interrupt status register.
Otherwise, with a level interrupt, the interrupt will continue to be
held active ("screaming") and the CPU will get interrupted over and
over again, until the irq subsystem will just turn the irq off
entirely.
- when you resume, make sure that you get the engine going again, with
the understanding that some interrupts may have gotten ignored.
Also, in general, these kinds of things shouldn't always even be
neicessary. If you use the suspend_late()/resume_early() hooks, those will
be called with interrupts off, and while they can be harder to debug (and
may be worth avoiding for non-critical drivers), they do allow for simpler
models partly exactly because they don't need to worry about interrupts
etc.
Linus
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [BUG] powerpc does not save msi state [was Re: [PATCH 5/7] pci: Export the pci_restore_msi_state() function
> I'm cc'ing the powerpc mailing list to point this out: > it looks like only cell/axon_msi.c and mpic_u3msi.c > bother do do anything. I guess that there aren't any old > macintosh laptops that have msi on them? Because without > this, suspend and resume breaks. The only macs that can do any form of MSIs are the G5s using mpic_u3msi.c > Paul, > On the off chance your reading this, I'll send a pseries > patch on Monday, with luck (and some other patches too). > I'm not touching any of the other plaforms, you and benh > would know those better. Or rather Michael as he wrote the ppc MSI support. I'll check with him Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] powerpc: mpic: minor optimization of ipi handler
On Fri, 2007-10-19 at 18:49 -0500, Olof Johansson wrote:
> Optimize MPIC IPIs, by passing in the IPI number as the argument to the
> handler, since all we did was translate it back based on which mpic
> the interrupt came though on (and that was always the primary mpic).
>
>
> Signed-off-by: Olof Johansson <[EMAIL PROTECTED]>
> Oh, I see what you mean. You didn't make it easy to parse. :)
>
> This should actually do the work.
>
> -Olof
Acked-by: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
>
> diff --git a/arch/powerpc/sysdev/mpic.c b/arch/powerpc/sysdev/mpic.c
> index e479388..a8d7c68 100644
> --- a/arch/powerpc/sysdev/mpic.c
> +++ b/arch/powerpc/sysdev/mpic.c
> @@ -614,10 +614,9 @@ static inline void mpic_eoi(struct mpic *mpic)
> #ifdef CONFIG_SMP
> static irqreturn_t mpic_ipi_action(int irq, void *data)
> {
> - struct mpic *mpic;
> + long ipi = (long)data;
>
> - mpic = mpic_find(irq, NULL);
> - smp_message_recv(mpic_irq_to_hw(irq) - mpic->ipi_vecs[0]);
> + smp_message_recv(ipi);
>
> return IRQ_HANDLED;
> }
> @@ -1457,7 +1456,7 @@ unsigned int mpic_get_irq(void)
> void mpic_request_ipis(void)
> {
> struct mpic *mpic = mpic_primary;
> - int i, err;
> + long i, err;
> static char *ipi_names[] = {
> "IPI0 (call function)",
> "IPI1 (reschedule)",
> @@ -1472,14 +1471,14 @@ void mpic_request_ipis(void)
> unsigned int vipi = irq_create_mapping(mpic->irqhost,
> mpic->ipi_vecs[0] + i);
> if (vipi == NO_IRQ) {
> - printk(KERN_ERR "Failed to map IPI %d\n", i);
> + printk(KERN_ERR "Failed to map IPI %ld\n", i);
> break;
> }
> err = request_irq(vipi, mpic_ipi_action,
> IRQF_DISABLED|IRQF_PERCPU,
> - ipi_names[i], mpic);
> + ipi_names[i], (void *)i);
> if (err) {
> - printk(KERN_ERR "Request of irq %d for IPI %d failed\n",
> + printk(KERN_ERR "Request of irq %d for IPI %ld
> failed\n",
> vipi, i);
> break;
> }
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] synchronize_irq needs a barrier
> > - even when you ignore the interrupt (because the driver doesn't care,
> >it's suspending), you need to make sure the hardware gets shut up by
> >reading (or writing) the proper interrupt status register.
> >
> >Otherwise, with a level interrupt, the interrupt will continue to be
> >held active ("screaming") and the CPU will get interrupted over and
> >over again, until the irq subsystem will just turn the irq off
> >entirely.
>
> His suspend routine wrote to the IRQ mask (or equivalent) register in
> his code example, thus the HW should shut up eventually, thus that isn't
> strictly necessary, the IRQ in that case is just a "short
> interrupt" (noticed by the PIC and delivered but possibly not asserted
> anymore at this stage or about to go down).
In fact, he -must not- ack it. Because is the HW is really down (in D3),
got knows what accessing the ACK register will do. I can give you
ideas... from nothing on most x86 desktops to machine checks on most
powerpc machines, though I could imagine some cards bad enough to lock
your bus up if you try to access a register while they are in D3 (I've
seen some of those critters and it seems not all bridges timeout on
cards that just keep sending retries).
Cheers,
Ben.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] synchronize_irq needs a barrier
> > - even when you ignore the interrupt (because the driver doesn't care, > >it's suspending), you need to make sure the hardware gets shut up by > >reading (or writing) the proper interrupt status register. > I agree, but while device is powered off, its registers can't be accessed > Thus, if I ack the IRQ every time the handler is called, I will access the > powered off device (this is probably won't hurt a lot, but a bit incorrectly) It will actually crash your machine on some platforms. So no, best is to -not- ack. The masking is enough, the IRQ will go down eventually. Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] synchronize_irq needs a barrier
On Fri, 2007-10-19 at 19:25 -0700, Linus Torvalds wrote:
>
> On Sat, 20 Oct 2007, Maxim Levitsky wrote:
> >
> > and the interrupt handler:
> >
> > smp_rmb();
> > if (dev->insuspend)
> > goto out;
>
> Something like that can work, yes. However, you need to make sure that:
>
> - even when you ignore the interrupt (because the driver doesn't care,
>it's suspending), you need to make sure the hardware gets shut up by
>reading (or writing) the proper interrupt status register.
>
>Otherwise, with a level interrupt, the interrupt will continue to be
>held active ("screaming") and the CPU will get interrupted over and
>over again, until the irq subsystem will just turn the irq off
>entirely.
His suspend routine wrote to the IRQ mask (or equivalent) register in
his code example, thus the HW should shut up eventually, thus that isn't
strictly necessary, the IRQ in that case is just a "short
interrupt" (noticed by the PIC and delivered but possibly not asserted
anymore at this stage or about to go down).
We have many scenario generating such short interrupts (pretty much any
time we use interrupt disable/enable on the chip, for example it's
common with NAPI).
This is one of the reasons why we used to have a "timebomb" causing an
IRQ to erroneously get disabled by the IRQ core assuming the IRQ was
stuck, just because we accumulated too many short interrupts on that
line. A recent patch by Alan fixed that to use some more sensible
algorithm checking the time since the last spurrious interrupt, though I
suspect he's being too optimistic on his timeout value and some
scenario, such as NAPI with just the wrong packet rate, can still
trigger the bug. I need to find a piece of HW slow enough in
de-asserting the IRQ to try to make a repro-case one of these days.
> - when you resume, make sure that you get the engine going again, with
>the understanding that some interrupts may have gotten ignored.
And you forgot that he still needs synchronize_irq(), or his IRQ handler
might well be in the middle of doing something on another CPU, past the
point where it tested "insuspend", which will do no good when a
simultaneous pci_set_power_state() puts the chip into D3. On some
machines, this will machine check. Either that or he needs a spinlock in
his IRQ handler that he also takes around the code that sets insuspend.
> Also, in general, these kinds of things shouldn't always even be
> neicessary. If you use the suspend_late()/resume_early() hooks, those will
> be called with interrupts off, and while they can be harder to debug (and
> may be worth avoiding for non-critical drivers), they do allow for simpler
> models partly exactly because they don't need to worry about interrupts
> etc.
Yes, this is a easier way to deal with devices that are on a directly
mapped bus (path to them isn't gone by the time you hit suspend_late)
and don't need to do fancy things involing waiting for a queue to drain
using interrupts etc... (at one stage of HW complexity, having to
re-implement polled versions of everything is just not worth the
benefit). In general, suspend_late should cover the need of most PCI
devices I suppose.
Ben.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] synchronize_irq needs a barrier
> I have read this thread and I concluded few things: > > 1) It is impossible to know that the card won't send more interrupts: > Even if I do a read from the device, the IRQ can be pending in the bus/APIC > It is even possible (and likely) that the IRQ line will be shared, thus the > handler can be called by non-relevant device. > > 2) the synchronize_irq(); in .suspend is useless: > an IRQ can happen immediately after this synchronize_irq(); > and interrupt even the .suspend() > (At least theoretically) It's not totally useless not. It guarantees that by the time your are out of your suspend(), a simultaneous instance of the IRQ handler is either finished, or it (or any subsequent occurence) have seen your insuspend flag set to 1. > Thus I now understand that .suspend() should do: > > saa_writel(SAA7134_IRQ1, 0); > saa_writel(SAA7134_IRQ2, 0); > saa_writel(SAA7134_MAIN_CTRL, 0); > > dev->insuspend = 1; > smp_wmb(); > > /* at that point the _request to disable card's IRQs was issued, we > don't know > that there will be no irqs anymore. > the smp_mb(); guaranties that the IRQ handler will bail out in that > case. */ > > /* ...*/ > > pci_save_state(pci_dev); > pci_set_power_state(pci_dev, pci_choose_state(pci_dev, state)); > return 0; The above doesn't handle the case where the IRQ handle just passed the if (insuspend) test. You may end up calling pci_set_power_state() while in the middle of some further HW accesses in the handler. You still need synchronize_irq() for that reason. Or use a spinlock. > and the interrupt handler: > > smp_rmb(); > if (dev->insuspend) > goto out; > > Am I right? Not quite :-) Also not that the work we are doing with synchronize_irq, if it gets merged, renders it unnecessary for you to add those two memory barriers, synchronize_irq will pretty much do the ordering for you. Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[bug] block subsystem related crash on Legacy iSeries viodasd.c
Hi Jens, Stephen, and Everyone else. I am seeing this crash on a legacy iSeries box. Bisect points at 70eb8040dc81212c884a464b75e37dca8014f3ad (Add chained sg support to linux/scatterlist.h). I see there were some related troubles discussed a couple days back. I've refreshed my tree, so believe I should have pulled in all the changes that fixed those issues by now, so this is an additional problem (viodasd funkyness), or I've screwed something up in my pulls, or fixes are still pending in another tree. >From the register dump, looks like sg passed into memset was a -2. (from blk_rq_map_sg()) if (!sg) sg = sglist; else sg = sg_next(sg); memset(sg, 0, sizeof(*sg)); <-- linux-2.6.git tree at commit 4fa4d23fa20de67df919030c1216295664866ad7 Merge: a9e82d3... 4f1e5ba... Author: Linus Torvalds <[EMAIL PROTECTED]> Date: Thu Oct 18 19:31:54 2007 -0700 Merge branch 'upstream-linus' of master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/netdev-2.6 > git log drivers/scsi/scsi_lib.c commit a3bec5c5aea0da263111c4d8f8eabc1f8560d7bf Author: Jens Axboe <[EMAIL PROTECTED]> Date: Wed Oct 17 19:33:05 2007 +0200 Revert "[SCSI] Remove full sg table memset()" > > git log block/ll_rw_blk.c commit ba951841ceb7fa5b06ad48caa5270cc2ae17941e Author: Jens Axboe <[EMAIL PROTECTED]> Date: Wed Oct 17 19:34:11 2007 +0200 [BLOCK] blk_rq_map_sg() next_sg fixup -- The panic is: Freeing unused kernel memory: 224k freed Unable to handle kernel paging request for data at address 0xfffe Faulting instruction address: 0xc00282f0 Oops: Kernel access of bad area, sig: 11 [#1] SMP NR_CPUS=32 iSeries Modules linked in: NIP: c00282f0 LR: c01c772c CTR: REGS: c2026b00 TRAP: 0300 Not tainted (2.6.23) MSR: 80009032 CR: 4422 XER: 0008 DAR: fffe, DSISR: 4200 TASK = c2022000[1] 'swapper' THREAD: c2024000 CPU: 1 GPR00: 0002 c2026d80 c05168c8 fffe GPR04: 001e fffe GPR08: 0001 6db6db6db6db6db7 01491000 GPR12: c058d000 c0464f80 c2027780 GPR16: c300a0c8 0001 c04d4dd0 c297e868 GPR20: c272 c2026ec0 0001 0003 GPR24: c272 1000 0003 GPR28: fffe c2a61000 c04c2510 c27f64b0 NIP [c00282f0] .memset+0x3c/0xfc LR [c01c772c] .blk_rq_map_sg+0x154/0x1e8 Call Trace: [c2026d80] [c04d4ed8] 0xc04d4ed8 (unreliable) [c2026e50] [c02283d8] .do_viodasd_request+0xb4/0x448 [c20270a0] [c01c8ddc] .__generic_unplug_device+0x54/0x6c [c2027120] [c01ca438] .generic_unplug_device+0x30/0x78 [c20271b0] [c01c5888] .blk_backing_dev_unplug+0x34/0x48 [c2027230] [c00cf75c] .block_sync_page+0x78/0x90 [c20272b0] [c0074d50] .sync_page+0x74/0x98 [c2027330] [c0344538] .__wait_on_bit_lock+0x8c/0x110 [c20273d0] [c0074c94] .__lock_page+0x70/0x90 [c20274a0] [c00758b4] .do_generic_mapping_read+0x248/0x47c [c20275a0] [c0077644] .generic_file_aio_read+0x144/0x1d4 [c2027680] [c00a3ad8] .do_sync_read+0xc4/0x124 [c2027820] [c00a4350] .vfs_read+0xd8/0x1a4 [c20278c0] [c00a965c] .kernel_read+0x38/0x5c [c2027960] [c00aad18] .do_execve+0xe8/0x208 [c2027a10] [c000e0b4] .sys_execve+0x6c/0xf0 [c2027ab0] [c0007540] syscall_exit+0x0/0x40 --- Exception: c01 at .kernel_execve+0x8/0x14 LR = .run_init_process+0x28/0x40 [c2027da0] [c00b35ec] .sys_dup+0x2c/0x44 (unreliable) [c2027e20] [c0007fb4] .init_post+0xc4/0xe8 [c2027ea0] [c0407978] .kernel_init+0x384/0x3b8 [c2027f90] [c002] .kernel_thread+0x4c/0x68 Instruction dump: 5084801e 7c850040 7884000e 7c001120 7c661b78 418400ac 41a2002c 7ca02850 409f000c 9886 38c60001 409e000c 38c60002 409d000c 9086 Kernel panic - not syncing: Attempted to kill init! Rebooting in 180 seconds.. Thanks, --Will ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Please pull from 'for-2.6.24' branch of 4xx tree
Hi Paul, Please pull from master.kernel.org:/pub/scm/linux/kernel/git/jwboyer/powerpc-4xx.git for-2.6.24 to pick up a handful of fixes for 4xx. These are mostly to enable the ibm_newemac driver for the various boards. Since a few patches to the driver are needed from Linus' tree, the branch is based off of his latest tree as of this morning. josh Josh Boyer (4): [POWERPC] 4xx: Enable EMAC on the PPC 440GP Ebony board [POWERPC] 4xx: Fix timebase clock selection on Walnut [POWERPC] 4xx: Enable EMAC for PPC405 Walnut board [POWERPC] 4xx: Enable EMAC on Bamboo board Valentine Barshak (3): [POWERPC] 4xx: Add RGMII support for Sequoia 440EPx [POWERPC] 4xx: Enable NEW EMAC support for Sequoia 440EPx. [POWERPC] 4xx: Split early debug output and early boot console for 44x ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 0/4] DTC: Introduce better DTS literal support
On Fri, Oct 19, 2007 at 12:42:02PM -0500, Jon Loeliger wrote: > Folks, > > This 4 part patch series for the DTC has: > > 0001-Reformat-grammar-rules-to-not-mix-language-syntax-an.patch > 0002-Quiet-a-bogus-May-be-used-uninitialized-warning.patch > 0003-Appease-the-printf-format-Gods-with-a-correct-typ.patch > 0004-Begin-the-path-to-sane-literals-and-expressions.patch > > The first is a pure whitespace formatting cleaning. > The second two clean compiler warnings. > The final one introduces a versioned DTS file with > support for C-like literals. I certainly have some comments on these, but I'm busy today and won't be able to comment in detail until Monday or so. Please don't apply them to mainline before then? -- David Gibson| I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH v3] pcmcia: Convert io_req_t to use unsigned int
[PCMCIA] Convert some internal-only ioaddr_t to unsigned int
Convert the io_req_t members to unsigned int, to allow use on machines
with more than 16 bits worth of IO ports (i.e. secondary busses on
ppc64, etc).
There was only a couple of places in drivers where a change was needed. I
left printk formats alone (there are lots of %04x-style formats in there),
mostly to not change the format on the platforms that only have 16-bit
io addresses, but also because the padding doesn't really add all that
much value most of the time.
I found only one sprintf of an address, and upsized the string accordingly
(I doubt anyone will have anywhere near INT_MAX as irq value, but at
least there's room for it now).
Signed-off-by: Olof Johansson <[EMAIL PROTECTED]>
---
On Sat, Sep 22, 2007 at 11:13:03AM +0200, Christoph Hellwig wrote:
> On Sat, Sep 22, 2007 at 12:25:51AM -0600, Matthew Wilcox wrote:
> > > What about the formatting and field widths ?
> > >
> > > ulong would probably be a lot saner than kio_addr_t and yet more type
> > > obfuscation.
> >
> > I don't think anyone uses ioports > 32bit. Certainly i386 takes an int
> > port as parameter to {in,out}[bwl] (and it really only uses 16-bits).
> > parisc uses 24 bits. I don't know what the various ppcs do, but pci
> > bars can only be 32-bit for ioports. So my opinion is that ioports
> > should be uint, not ulong.
>
> The kernel seems to mostly use int, sometimes uint. I never quite got
> why pcmcia had to have it's own strange typedef for them.
Ok, so let's switch to unsigned int. Only exception I made was to stick
to u_int in the struct itself to keep it common with the style in the
rest of it.
This also resulted in a much smaller diff, since I didn't have to change
any printk formats (see above about 0-padding).
-Olof
Index: k.org/drivers/char/pcmcia/cm4000_cs.c
===
--- k.org.orig/drivers/char/pcmcia/cm4000_cs.c
+++ k.org/drivers/char/pcmcia/cm4000_cs.c
@@ -308,7 +308,7 @@ static unsigned int calc_baudv(unsigned
return (wcrcf / wbrcf);
}
-static unsigned short io_read_num_rec_bytes(ioaddr_t iobase, unsigned short *s)
+static unsigned short io_read_num_rec_bytes(unsigned int iobase, unsigned
short *s)
{
unsigned short tmp;
@@ -426,7 +426,7 @@ static struct card_fixup card_fixups[] =
static void set_cardparameter(struct cm4000_dev *dev)
{
int i;
- ioaddr_t iobase = dev->p_dev->io.BasePort1;
+ unsigned int iobase = dev->p_dev->io.BasePort1;
u_int8_t stopbits = 0x02; /* ISO default */
DEBUGP(3, dev, "-> set_cardparameter\n");
@@ -459,7 +459,7 @@ static int set_protocol(struct cm4000_de
unsigned short num_bytes_read;
unsigned char pts_reply[4];
ssize_t rc;
- ioaddr_t iobase = dev->p_dev->io.BasePort1;
+ unsigned int iobase = dev->p_dev->io.BasePort1;
rc = 0;
@@ -610,7 +610,7 @@ exit_setprotocol:
return rc;
}
-static int io_detect_cm4000(ioaddr_t iobase, struct cm4000_dev *dev)
+static int io_detect_cm4000(unsigned int iobase, struct cm4000_dev *dev)
{
/* note: statemachine is assumed to be reset */
@@ -671,7 +671,7 @@ static void terminate_monitor(struct cm4
static void monitor_card(unsigned long p)
{
struct cm4000_dev *dev = (struct cm4000_dev *) p;
- ioaddr_t iobase = dev->p_dev->io.BasePort1;
+ unsigned int iobase = dev->p_dev->io.BasePort1;
unsigned short s;
struct ptsreq ptsreq;
int i, atrc;
@@ -933,7 +933,7 @@ static ssize_t cmm_read(struct file *fil
loff_t *ppos)
{
struct cm4000_dev *dev = filp->private_data;
- ioaddr_t iobase = dev->p_dev->io.BasePort1;
+ unsigned int iobase = dev->p_dev->io.BasePort1;
ssize_t rc;
int i, j, k;
@@ -1054,7 +1054,7 @@ static ssize_t cmm_write(struct file *fi
size_t count, loff_t *ppos)
{
struct cm4000_dev *dev = (struct cm4000_dev *) filp->private_data;
- ioaddr_t iobase = dev->p_dev->io.BasePort1;
+ unsigned int iobase = dev->p_dev->io.BasePort1;
unsigned short s;
unsigned char tmp;
unsigned char infolen;
@@ -1408,7 +1408,7 @@ static int cmm_ioctl(struct inode *inode
unsigned long arg)
{
struct cm4000_dev *dev = filp->private_data;
- ioaddr_t iobase = dev->p_dev->io.BasePort1;
+ unsigned int iobase = dev->p_dev->io.BasePort1;
struct pcmcia_device *link;
int size;
int rc;
Index: k.org/drivers/pcmcia/pcmcia_resource.c
===
--- k.org.orig/drivers/pcmcia/pcmcia_resource.c
+++ k.org/drivers/pcmcia/pcmcia_resource.c
@@ -65,23 +65,23 @@ extern int ds_pc_debug;
* Special stuff for managing IO windows, because they are scarce
*/
-static int alloc_io_space(struct pcmcia_socket *s, u_int attr, ioaddr_t *base,
-
Re: [PATCH] synchronize_irq needs a barrier
On Saturday 20 October 2007 05:56:01 Benjamin Herrenschmidt wrote: > > > I have read this thread and I concluded few things: > > > > 1) It is impossible to know that the card won't send more interrupts: > > Even if I do a read from the device, the IRQ can be pending in the bus/APIC > > It is even possible (and likely) that the IRQ line will be shared, thus the > > handler can be called by non-relevant device. > > > > 2) the synchronize_irq(); in .suspend is useless: > > an IRQ can happen immediately after this synchronize_irq(); > > and interrupt even the .suspend() > > (At least theoretically) > > It's not totally useless not. It guarantees that by the time your > are out of your suspend(), a simultaneous instance of the IRQ handler > is either finished, or it (or any subsequent occurence) have seen > your insuspend flag set to 1. > > > Thus I now understand that .suspend() should do: > > > > saa_writel(SAA7134_IRQ1, 0); > > saa_writel(SAA7134_IRQ2, 0); > > saa_writel(SAA7134_MAIN_CTRL, 0); > > > > dev->insuspend = 1; > > smp_wmb(); > > > > /* at that point the _request to disable card's IRQs was issued, we > > don't know > >that there will be no irqs anymore. > >the smp_mb(); guaranties that the IRQ handler will bail out in that > > case. */ > > > > /* ...*/ > > > > pci_save_state(pci_dev); > > pci_set_power_state(pci_dev, pci_choose_state(pci_dev, state)); > > return 0; > > The above doesn't handle the case where the IRQ handle just passed the > if (insuspend) test. You may end up calling pci_set_power_state() while > in the middle of some further HW accesses in the handler. > > You still need synchronize_irq() for that reason. Or use a spinlock. > > > and the interrupt handler: > > > > smp_rmb(); > > if (dev->insuspend) > > goto out; > > > > Am I right? > > Not quite :-) > > Also not that the work we are doing with synchronize_irq, if it gets > merged, renders it unnecessary for you to add those two memory barriers, > synchronize_irq will pretty much do the ordering for you. > > Cheers, > Ben. > > Fine, I Agree, and this is why I used it in first place, I just forgot. To wait for already running IRQ handler, that tested the dev->insuspend. (And I assumed that interrupts are disabled on the cpu that runs .suspend, but I know now that this isn't true.) Besides that can I ask few more .suspend/resume questions: 1) some drivers use pci_disable_device(), and pci_enable_device(). should I use it too? 2) I accidentally did this: pci_set_power_state(pci_dev, pci_choose_state(pci_dev, state)); pci_save_state(pci_dev); I somehow thought that this is correct, that I should save the pci config state after the power-down, but now I know that it isn't correct. I now need to send a patch for dmfe.c network driver that has the same commands written by me. (but it works perfectly anyway) Is it possible to access pci configuration space in D3? And lastly speaking of network drivers, one issue came to my mind: most network drivars has a packet queue and in case of dmfe it is located in main memory, and card does dma from it. in .suspend I ignore that some packets may be in that queue, and I want to ask, whenever there are better ways to do that. this is my dmfe .suspend routine. /* Disable upper layer interface */ netif_device_detach(dev); /* Disable Tx/Rx */ db->cr6_data &= ~(CR6_RXSC | CR6_TXSC); update_cr6(db->cr6_data, dev->base_addr); /* Disable Interrupt */ outl(0, dev->base_addr + DCR7); outl(inl (dev->base_addr + DCR5), dev->base_addr + DCR5); /* Fre RX buffers */ dmfe_free_rxbuffer(db); /* Enable WOL */ pci_read_config_dword(pci_dev, 0x40, &tmp); tmp &= ~(DMFE_WOL_LINKCHANGE|DMFE_WOL_MAGICPACKET); if (db->wol_mode & WAKE_PHY) tmp |= DMFE_WOL_LINKCHANGE; if (db->wol_mode & WAKE_MAGIC) tmp |= DMFE_WOL_MAGICPACKET; pci_write_config_dword(pci_dev, 0x40, tmp); pci_enable_wake(pci_dev, PCI_D3hot, 1); pci_enable_wake(pci_dev, PCI_D3cold, 1); /* Power down device*/ pci_set_power_state(pci_dev, pci_choose_state (pci_dev,state)); pci_save_state(pci_dev); I guess, everybody makes mistakes... :-) Other network drivers has a bit more complicated .suspend/.resume routines, but I didn't see a driver waiting for output queue to finish Best regards, Maxim Levitsky ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: FDT bindings for I2C devices
(it was suggested to deprecate -embedded in favour of -dev, so, added to cc:) On Fri, 19 Oct 2007, Grant Likely wrote: > On 10/19/07, Wolfgang Grandegger <[EMAIL PROTECTED]> wrote: > > Hello, > > > > is it forseen to define and configure devices like RTC, temperature > > sensors or EEPROM on the I2C bus with the Flat Device Tree? If yes, how > > would the DTS entries look like? > > booting-without-of.txt has some information about describing the controller. > > Scott Wood made an attempt at defining a device binding for I2C > devices, but it has not been merged into booting-without-of.txt yet. > I've copied what he wrote below. I would add to his definition the > following: > - If compatible is missing, driver should *not* fall back to the device name. > - 'compatible' list should include the exact device in the form "," There are also already working examples in powerpc: look at arch/powerpc/sysdev/fsl_soc.c at the i2c_devices[] array and how it is used below. There are also some .dts examples upstream already, e.g., arch/powerpc/boot/dts/kuroboxH[GD].dts. There also have been more patches recently to add further devices to the table and further .dts entries. Notice however, it would be good to move the generic code out of fsl_soc.c, as there seems to be increasing interest in describing i2c buses in .dts. Thanks Guennadi --- Guennadi Liakhovetski ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: embedded a default dtb in the kernel (was merge dtc)
On 10/19/07, Leisner, Martin <[EMAIL PROTECTED]> wrote: > Is there a way to embed a default dtb into the kernel? > When I build a kernel, I want to embed a dtb into it -- > so I don't have to deal with the headaches of finding the > right file to match the right board (its always easier to > deal with 1 file than 2). > > If there is, it makes sense to put dtc into the tree. > If there's not, there should be a way to embed dtb's; and put > dtc and dts's into the tree. > If there can't be (I haven't examined this but relaying my > experiences), then it should be in a separate repository > (but the DTS and DTC should be in one place). > It was a little difficult to cobble together a working > system the first time. > > Also, mkimage SHOULD definitely go in the tree. Its necessary > to build, hence should be in the tree... Why? mkimage is u-boot specific, and hence is maintained by u-boot. If you're not using u-boot, then you don't need mkimage. What is wrong with it being a prereq like all the other tools we use? If you're doing embedded development, you're installing non-distribution cross toolchain anyway. dtc and mkimage are embedded development tools. They belong with the embedded development toolchain. mkimage is already part of ELDK. Cheers, g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. [EMAIL PROTECTED] (403) 399-0195 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] ppc44x: support for 256K PAGE_SIZE
Dear Josh, in message <[EMAIL PROTECTED]> you wrote: > > > The following patch adds support for 256KB PAGE_SIZE on ppc44x-based > > boards. > > The applications to be run on the kernel with 256KB PAGE_SIZE have to be > > built using the modified version of binutils, where the MAXPAGESIZE > > definition is set to 0x4 (as opposite to standard 0x1). ... > > BTW, what tree did you base this on? I don't seem to have the > PPC_PAGE_* options in my tree. If you like to see the patches in context, you can find this stuff in the linux-2.6-denx repository at denx.de The 256K page size stuff is based on and requires as prerequisite the "ppc: Add support for bigger page sizes than 4KB on PPC44x" posted here on April 25, see http://patchwork.ozlabs.org/linuxppc/patch?q=Add%20support%20for%20bigger%20page%20sizes&id=10646 Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: [EMAIL PROTECTED] Q: Why do PCs have a reset button on the front? A: Because they are expected to run Microsoft operating systems. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Merge dtc
Hi David. > > Give me a day or two then I shall give it a try and see what I can > > do about it. I will use the previsous posted URL as basis if you do > > not tell me otherwise. > > Thank you. The previous URL should be fine, I've made no changes > since then. I decided to go for a kbuild specific version integrated in boot/Makefile. This is much more readable because this syntax is explicit. We do not favour 3 levels of variabls to avoid rewriting the same filename two times. I have tested the change only with a O=.. crosscompile build. I have tested the patch with and without DTC_GENPARSER=1. It does not rebuild if not needed and is OK with -j10 builds. Please consider this version in favour of your old version. Take this as review feedback. You can add: Reviewed-by: Sam Ravnborg <[EMAIL PROTECTED]> [kbuild integration only] Thanks, Sam arch/powerpc/boot/Makefile | 40 ++-- 1 files changed, 38 insertions(+), 2 deletions(-) diff --git a/arch/powerpc/boot/Makefile b/arch/powerpc/boot/Makefile index 18e3271..064dc07 100644 --- a/arch/powerpc/boot/Makefile +++ b/arch/powerpc/boot/Makefile @@ -108,17 +108,53 @@ $(patsubst %.S,%.o, $(filter %.S, $(src-boot))): %.o: %.S FORCE $(obj)/wrapper.a: $(obj-wlib) FORCE $(call if_changed,bootar) -hostprogs-y:= addnote addRamDisk hack-coff mktree +hostprogs-y:= addnote addRamDisk hack-coff mktree dtc targets+= $(patsubst $(obj)/%,%,$(obj-boot) wrapper.a) extra-y:= $(obj)/wrapper.a $(obj-plat) $(obj)/empty.o \ $(obj)/zImage.lds $(obj)/zImage.coff.lds $(obj)/zImage.ps3.lds wrapper:=$(srctree)/$(src)/wrapper -wrapperbits:= $(extra-y) $(addprefix $(obj)/,addnote hack-coff mktree) \ +wrapperbits:= $(extra-y) $(addprefix $(obj)/,addnote hack-coff mktree dtc) \ $(wrapper) FORCE # +# Bits for building dtc +# DTC_GENPARSER:= 1# Uncomment to rebuild flex/bison output + +dtc-objs := dtc.o flattree.o fstree.o data.o livetree.o treesource.o srcpos.o +dtc-objs += dtc-lexer.lex.o dtc-parser.tab.o +dtc-objs := $(addprefix dtc-src/, $(dtc-objs)) + +# prerequisites on generated files needs to be explicit +$(obj)/dtc-src/dtc-parser.tab.o: $(obj)/dtc-src/dtc-parser.tab.c $(obj)/dtc-src/dtc-parser.tab.h +$(obj)/dtc-src/dtc-lexer.lex.o: $(obj)/dtc-src/dtc-lexer.lex.c +$(obj)/dtc-src/data.o: $(obj)/dtc-src/dtc-parser.tab.h + +HOSTCFLAGS += -I$(src)/dtc-src/ + +targets += dtc-src/dtc-parser.tab.c +targets += dtc-src/dtc-lexer.lex.c + +ifdef DTC_GENPARSER +BISON = bison +FLEX = flex + +quiet_cmd_bison = BISON $@ + cmd_bison = $(BISON) -o$@ -d $<; cp $@ [EMAIL PROTECTED] +quiet_cmd_flex = FLEX$@ + cmd_flex = $(FLEX) -o$@ $<; cp $@ [EMAIL PROTECTED] + +$(obj)/dtc-src/dtc-parser.tab.c: $(src)/dtc-src/dtc-parser.y FORCE + $(call if_changed,bison) + +$(obj)/dtc-src/dtc-parser.tab.h: $(obj)/dtc-src/dtc-parser.tab.c + +$(obj)/dtc-src/dtc-lexer.lex.c: $(src)/dtc-src/dtc-lexer.l FORCE + $(call if_changed,flex) +endif + +# # Bits for building various flavours of zImage ifneq ($(CROSS32_COMPILE),) ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 1/4] DTC: Reformat grammar rules to not mix language syntax and yacc syntax.
Use consistent indenting on all rule actions.
Signed-off-by: Jon Loeliger <[EMAIL PROTECTED]>
---
No functional changes!
dtc-parser.y | 152 +-
1 files changed, 118 insertions(+), 34 deletions(-)
diff --git a/dtc-parser.y b/dtc-parser.y
index 54fd787..4698793 100644
--- a/dtc-parser.y
+++ b/dtc-parser.y
@@ -79,103 +79,187 @@ extern struct boot_info *the_boot_info;
%%
-sourcefile:memreserves devicetree {
+sourcefile:
+ memreserves devicetree
+ {
the_boot_info = build_boot_info($1, $2);
}
;
-memreserves: memreserve memreserves {
+memreserves:
+ memreserve memreserves
+ {
$$ = chain_reserve_entry($1, $2);
}
- | /* empty */ {
+ | /* empty */
+ {
$$ = NULL;
}
;
-memreserve:label DT_MEMRESERVE DT_ADDR DT_ADDR ';' {
+memreserve:
+ label DT_MEMRESERVE DT_ADDR DT_ADDR ';'
+ {
$$ = build_reserve_entry($3, $4, $1);
}
- | label DT_MEMRESERVE DT_ADDR '-' DT_ADDR ';' {
+ | label DT_MEMRESERVE DT_ADDR '-' DT_ADDR ';'
+ {
$$ = build_reserve_entry($3, $5 - $3 + 1, $1);
}
;
-devicetree:'/' nodedef {
+devicetree:
+ '/' nodedef
+ {
$$ = name_node($2, "", NULL);
}
;
-nodedef: '{' proplist subnodes '}' ';' {
+nodedef:
+ '{' proplist subnodes '}' ';'
+ {
$$ = build_node($2, $3);
}
;
-proplist: propdef proplist {
+proplist:
+ propdef proplist
+ {
$$ = chain_property($1, $2);
}
- | /* empty */ {
+ | /* empty */
+ {
$$ = NULL;
}
;
-propdef: label DT_PROPNAME '=' propdata ';' {
+propdef:
+ label DT_PROPNAME '=' propdata ';'
+ {
$$ = build_property($2, $4, $1);
}
- | label DT_PROPNAME ';' {
+ | label DT_PROPNAME ';'
+ {
$$ = build_property($2, empty_data, $1);
}
;
-propdata: propdataprefix DT_STRING { $$ = data_merge($1, $2); }
- | propdataprefix '<' celllist '>' {
- $$ = data_merge(data_append_align($1, sizeof(cell_t)),
$3);
+propdata:
+ propdataprefix DT_STRING
+ {
+ $$ = data_merge($1, $2);
+ }
+ | propdataprefix '<' celllist '>'
+ {
+ $$ = data_merge(data_append_align($1,
+ sizeof(cell_t)), $3);
+ }
+ | propdataprefix '[' bytestring ']'
+ {
+ $$ = data_merge($1, $3);
+ }
+ | propdata DT_LABEL
+ {
+ $$ = data_add_label($1, $2);
}
- | propdataprefix '[' bytestring ']' { $$ = data_merge($1, $3); }
- | propdata DT_LABEL { $$ = data_add_label($1, $2); }
;
-propdataprefix:propdata ',' { $$ = $1; }
- | propdataprefix DT_LABEL { $$ = data_add_label($1, $2); }
- | /* empty */ { $$ = empty_data; }
+propdataprefix:
+ propdata ','
+ {
+ $$ = $1;
+ }
+ | propdataprefix DT_LABEL
+ {
+ $$ = data_add_label($1, $2);
+ }
+ | /* empty */
+ {
+ $$ = empty_data;
+ }
;
opt_cell_base:
/* empty */
- { $$ = 16; }
+ {
+ $$ = 16;
+ }
| DT_BASE
;
-celllist: celllist opt_cell_base DT_CELL {
+celllist:
+ celllist opt_cell_base DT_CELL
+ {
$$ = data_append_cell($1,
cell_from_string($3, $2));
}
- | celllist DT_REF {
+ | celllist DT_REF
+ {
$$ = data_append_cell(data_add_fixup($1, $2), -1);
}
- | celllist DT_LABEL { $$ = data_add_label($1, $2); }
- | /* empty */ { $$ = empty_data; }
+ | celllist DT_LABEL
+ {
+ $$ = data_add_label($1, $2);
+ }
+ | /* empty */
+ {
+ $$ = empty_data;
+ }
;
-bytestring:bytestring DT_BYTE { $$ = data_append_byte($1, $2); }
- | bytestring DT_LABEL { $$ = data_add
Re: [PATCH] ppc44x: support for 256K PAGE_SIZE
On Thu, 18 Oct 2007 11:08:19 +0400 Yuri Tikhonov <[EMAIL PROTECTED]> wrote: > > Hello, > > The following patch adds support for 256KB PAGE_SIZE on ppc44x-based boards. > The applications to be run on the kernel with 256KB PAGE_SIZE have to be > built using the modified version of binutils, where the MAXPAGESIZE > definition is set to 0x4 (as opposite to standard 0x1). > > Signed-off-by: Pavel Kolesnikov <[EMAIL PROTECTED]> > Acked-by: Yuri Tikhonov <[EMAIL PROTECTED]> > > -- > > diff --git a/arch/ppc/Kconfig b/arch/ppc/Kconfig > index c590b18..0ee372d 100644 > --- a/arch/ppc/Kconfig > +++ b/arch/ppc/Kconfig > @@ -1223,6 +1223,9 @@ config PPC_PAGE_16K > > config PPC_PAGE_64K > bool "64 KB" if 44x > + > +config PPC_PAGE_256K > + bool "256 KB" if 44x > endchoice BTW, what tree did you base this on? I don't seem to have the PPC_PAGE_* options in my tree. josh ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] synchronize_irq needs a barrier
> 1) some drivers use pci_disable_device(), and pci_enable_device(). > should I use it too? I generally don't do the former, and I would expect the late to be done by pci_restore_state() for you. pci_disable_device(), last I looked, only cleared the bus master bit though, which might be a good idea to do. People in ACPI/x86 land, are there more good reasons to do one or the other ? That reminds me that I volunteered to write a documentation on how drivers should do all that stuff at KS and didn't get to actually doing it yet. shame ... I'll try to start something asap. > 2) I accidentally did this: > pci_set_power_state(pci_dev, pci_choose_state(pci_dev, state)); > pci_save_state(pci_dev); > > I somehow thought that this is correct, that I should save the pci config > state > after the power-down, but now I know that it isn't correct. Right, you need to do the save_state before the power down. You need to avoid pretty much any access to the device after the save state other than the pending set_power_state on resume. > I now need to send a patch for dmfe.c network driver that has the same > commands written by me. > (but it works perfectly anyway) On x86 desktop... might have surprises on others. > Is it possible to access pci configuration space in D3? It's only really safe to access the PM register itself, though I suppose you should be able to walk the capability chain to do that. But I wouldnt recommend doing anything else. > And lastly speaking of network drivers, one issue came to my mind: > most network drivars has a packet queue and in case of dmfe it is located in > main memory, > and card does dma from it. Note that the network stack nowadays does a fair bit of cleaning up for you before your suspend routine is called > > in .suspend I ignore that some packets may be in that queue, and I want > to ask, whenever there are better ways to do that. > > > this is my dmfe .suspend routine. > > /* Disable upper layer interface */ > netif_device_detach(dev); The above -might- not be needed any more, I have to check. I used to do it too on my drivers. > /* Disable Tx/Rx */ > db->cr6_data &= ~(CR6_RXSC | CR6_TXSC); > update_cr6(db->cr6_data, dev->base_addr); > > /* Disable Interrupt */ > outl(0, dev->base_addr + DCR7); > outl(inl (dev->base_addr + DCR5), dev->base_addr + DCR5); > > /* Fre RX buffers */ > dmfe_free_rxbuffer(db); > > /* Enable WOL */ > pci_read_config_dword(pci_dev, 0x40, &tmp); > tmp &= ~(DMFE_WOL_LINKCHANGE|DMFE_WOL_MAGICPACKET); > > if (db->wol_mode & WAKE_PHY) > tmp |= DMFE_WOL_LINKCHANGE; > if (db->wol_mode & WAKE_MAGIC) > tmp |= DMFE_WOL_MAGICPACKET; > > pci_write_config_dword(pci_dev, 0x40, tmp); > > pci_enable_wake(pci_dev, PCI_D3hot, 1); > pci_enable_wake(pci_dev, PCI_D3cold, 1); > > /* Power down device*/ > pci_set_power_state(pci_dev, pci_choose_state (pci_dev,state)); > pci_save_state(pci_dev); > Looks allright on a quick glance appart from the bits we already discussed. > I guess, everybody makes mistakes... :-) > > Other network drivers has a bit more complicated .suspend/.resume routines, > but I didn't see a driver waiting for output queue to finish I think the network stack does that nowadays but we'll have to double check, that's based on what DaveM told me at KS. Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] ppc44x: support for 256K PAGE_SIZE
On Oct 19, 2007, at 10:37 AM, Yuri Tikhonov wrote: > On Friday 19 October 2007 03:21, Paul Mackerras wrote: >> Have you measured the performance using a 64kB page size? If so, how >> does it compare with the 256kB page size? > > I measured the performance of the sequential full-stripe write > operations to > a RAID-5 array (P values below are in MB per second) using the h/w > accelerated > RAID-5 driver. > > Here are the comparative results for the different PAGE_SIZE values: > > PAGE_SIZE = 4K: > P = 66 MBps; > > PAGE_SIZE = 16K: > P = 145 MBps; > > PAGE_SIZE = 64K: > P = 196 MBps; > > PAGE_SIZE = 256K: > P = 217 MBps. Is this all in kernel space? or is there a user space aspect to the benchmark? >> The 64kB page size has the attraction that no binutils changes are >> required. > > That's true, but the additional performance is an attractive thing > too. - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] bestcomm: Restrict disabling of bus prefetch to original mpc5200 silicon.
On Fri, Oct 19, 2007 at 09:43:38AM -0600, Grant Likely wrote: > On 10/19/07, Sven Luther <[EMAIL PROTECTED]> wrote: > > On Fri, Oct 19, 2007 at 07:09:16AM -0600, Grant Likely wrote: > > > On 10/19/07, Domen Puncer <[EMAIL PROTECTED]> wrote: > > > > On 17/10/07 10:36 -0600, Grant Likely wrote: > > > > > From: Grant Likely <[EMAIL PROTECTED]> > > > > > > > > > > Only the MPC5200 needs this bug fix. MPC5200B is okay. > > > > > > > > > > Signed-off-by: Grant Likely <[EMAIL PROTECTED]> > > > > > --- > > > > > > > > > > Sven, Domen; > > > > > > > > > > Can you please test this patch? > > > > > > > > I found no obvious problems with it on Efika (mpc5200b) > > > > > > Cool, I'll add it to my list of patches for Paulus to pull > > > > Sorry, i have not had time to test, but there is a problem with the > > userland serial console i want to investigate. At the latest i will test > > this on monday. > > Your userland serial problems are unrelated to this patch though, right? Most definitively, sorry for the confusion. Friendly, Sven Luther ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] bestcomm: Restrict disabling of bus prefetch to original mpc5200 silicon.
On 10/19/07, Sven Luther <[EMAIL PROTECTED]> wrote: > On Fri, Oct 19, 2007 at 07:09:16AM -0600, Grant Likely wrote: > > On 10/19/07, Domen Puncer <[EMAIL PROTECTED]> wrote: > > > On 17/10/07 10:36 -0600, Grant Likely wrote: > > > > From: Grant Likely <[EMAIL PROTECTED]> > > > > > > > > Only the MPC5200 needs this bug fix. MPC5200B is okay. > > > > > > > > Signed-off-by: Grant Likely <[EMAIL PROTECTED]> > > > > --- > > > > > > > > Sven, Domen; > > > > > > > > Can you please test this patch? > > > > > > I found no obvious problems with it on Efika (mpc5200b) > > > > Cool, I'll add it to my list of patches for Paulus to pull > > Sorry, i have not had time to test, but there is a problem with the > userland serial console i want to investigate. At the latest i will test > this on monday. Your userland serial problems are unrelated to this patch though, right? g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. [EMAIL PROTECTED] (403) 399-0195 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH v7 5/9] add documentation for SATA nodes
On 10/19/07, Li Yang <[EMAIL PROTECTED]> wrote: > Signed-off-by: Li Yang <[EMAIL PROTECTED]> > --- > Documentation/powerpc/booting-without-of.txt | 32 > ++ > 1 files changed, 32 insertions(+), 0 deletions(-) > > diff --git a/Documentation/powerpc/booting-without-of.txt > b/Documentation/powerpc/booting-without-of.txt > index a96e853..8d49942 100644 > --- a/Documentation/powerpc/booting-without-of.txt > +++ b/Documentation/powerpc/booting-without-of.txt > @@ -2242,6 +2242,38 @@ platforms are moved over to use the > flattened-device-tree model. >available. >For Axon: 0x012a > > +o) SATA nodes > + > +SATA nodes are defined to describe on-chip Serial ATA controllers. > + > +Required properties: > + > +- compatible : Should specify what this SATA controller is compatible > + with. > +- reg : Offset and length of the register set for the device. > +- interrupts : where a is the interrupt number and b is a > + field that represents an encoding of the sense and level > + information for the interrupt. This should be encoded based on > + the information in section 2) depending on the type of interrupt > + controller you have. > +- interrupt-parent : the phandle for the interrupt controller that > + services interrupts for this device. > + > +Recommended properties : > + > +- phy-handle : Some SATA controller uses a shared SerDes PHY. This > + property should specify the phandle of the SerDes node. I'm not sure about this property. Does the driver need to know about this? Will this setup ever change at runtime? It seems to me that like GPIOs and chip selects, setting you which shared PHY goes with which device is something that should be done at board setup time. g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. [EMAIL PROTECTED] (403) 399-0195 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH v7 3/9] add Freescale SerDes PHY support
On 10/19/07, Li Yang <[EMAIL PROTECTED]> wrote:
> The SerDes(serializer/deserializer) PHY block is a new SoC block used
> in Freescale chips to support multiple serial interfaces, such as PCI
> Express, SGMII, SATA.
This looks like board setup behaviour. Shouldn't setting this up be
the responsibility firmware? And failing that, I think it should be
done directly by the platform setup function (in other words; make it
a helper function and call it at board setup time). Besides, you want
to provide guarantees that the board is setup correctly before the
device driver that uses it gets probed.
Cheers,
g.
>
> Signed-off-by: Li Yang <[EMAIL PROTECTED]>
> ---
> arch/powerpc/platforms/Kconfig |7 ++
> arch/powerpc/sysdev/Makefile |1 +
> arch/powerpc/sysdev/fsl_serdes.c | 195
> ++
> 3 files changed, 203 insertions(+), 0 deletions(-)
> create mode 100644 arch/powerpc/sysdev/fsl_serdes.c
>
> diff --git a/arch/powerpc/platforms/Kconfig b/arch/powerpc/platforms/Kconfig
> index 229d355..5d64f84 100644
> --- a/arch/powerpc/platforms/Kconfig
> +++ b/arch/powerpc/platforms/Kconfig
> @@ -315,6 +315,13 @@ config FSL_ULI1575
> config CPM
> bool
>
> +config FSL_SERDES
> + bool
> + help
> + The SerDes(serializer/deserializer) PHY block is a new SoC block
> + used in Freescale chips to support multiple serial interfaces,
> + such as PCI Express, SGMII, SATA.
> +
> source "arch/powerpc/sysdev/bestcomm/Kconfig"
>
> endmenu
> diff --git a/arch/powerpc/sysdev/Makefile b/arch/powerpc/sysdev/Makefile
> index 99a77d7..2343ea4 100644
> --- a/arch/powerpc/sysdev/Makefile
> +++ b/arch/powerpc/sysdev/Makefile
> @@ -20,6 +20,7 @@ obj-$(CONFIG_MV64X60) += $(mv64x60-y) mv64x60_pic.o
> mv64x60_dev.o \
>mv64x60_udbg.o
> obj-$(CONFIG_RTC_DRV_CMOS) += rtc_cmos_setup.o
> obj-$(CONFIG_AXON_RAM) += axonram.o
> +obj-$(CONFIG_FSL_SERDES) += fsl_serdes.o
>
> ifeq ($(CONFIG_PPC_MERGE),y)
> obj-$(CONFIG_PPC_INDIRECT_PCI) += indirect_pci.o
> diff --git a/arch/powerpc/sysdev/fsl_serdes.c
> b/arch/powerpc/sysdev/fsl_serdes.c
> new file mode 100644
> index 000..670015d
> --- /dev/null
> +++ b/arch/powerpc/sysdev/fsl_serdes.c
> @@ -0,0 +1,195 @@
> +/*
> + * arch/powerpc/sysdev/fsl_serdes.c
> + *
> + * Copyright (C) 2007 Freescale Semiconductor, Inc. All rights reserved.
> + *
> + * Author: Li Yang <[EMAIL PROTECTED]>
> + *
> + * Freescale SerDes initialization routines
> + *
> + * This program is free software; you can redistribute it and/or modify it
> + * under the terms of the GNU General Public License as published by the
> + * Free Software Foundation; either version 2 of the License, or (at your
> + * option) any later version.
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include
> +#include
> +#include
> +
> +#define FSL_SRDSCR0_OFFS 0x0
> +#define FSL_SRDSCR0_DPP_1V20x8800
> +#define FSL_SRDSCR1_OFFS 0x4
> +#define FSL_SRDSCR1_PLLBW 0x0040
> +#define FSL_SRDSCR2_OFFS 0x8
> +#define FSL_SRDSCR2_VDD_1V20x0080
> +#define FSL_SRDSCR2_SEIC_MASK 0x1c1c
> +#define FSL_SRDSCR2_SEIC_SATA 0x1414
> +#define FSL_SRDSCR2_SEIC_PEX 0x1010
> +#define FSL_SRDSCR2_SEIC_SGMII 0x0101
> +#define FSL_SRDSCR3_OFFS 0xc
> +#define FSL_SRDSCR3_KFR_SATA 0x1010
> +#define FSL_SRDSCR3_KPH_SATA 0x0404
> +#define FSL_SRDSCR3_SDFM_SATA_PEX 0x0101
> +#define FSL_SRDSCR3_SDTXL_SATA 0x0505
> +#define FSL_SRDSCR4_OFFS 0x10
> +#define FSL_SRDSCR4_PROT_SATA 0x0808
> +#define FSL_SRDSCR4_PROT_PEX 0x0101
> +#define FSL_SRDSCR4_PROT_SGMII 0x0505
> +#define FSL_SRDSCR4_PLANE_X2 0x0100
> +#define FSL_SRDSCR4_RFCKS_100 0x
> +#define FSL_SRDSCR4_RFCKS_125 0x1000
> +#define FSL_SRDSCR4_RFCKS_150 0x3000
> +#define FSL_SRDSRSTCTL_OFFS0x20
> +#define FSL_SRDSRSTCTL_RST 0x8000
> +#define FSL_SRDSRSTCTL_SATA_RESET 0xf
> +
> +static int fsl_serdes_probe(struct of_device *ofdev,
> + const struct of_device_id *match)
> +{
> + struct device_node *np = ofdev->node;
> + void __iomem *regs;
> + const char *prot;
> + const unsigned int *freq;
> + u32 rfcks;
> +
> + regs = of_iomap(np, 0);
> + if (!regs)
> + return -ENOMEM;
> +
> + prot = of_get_property(np, "protocol", NULL);
> + if (!prot)
> + goto out;
> + freq = of_get_property(np, "clock", NULL);
> + if (!freq)
> + goto out;
> + switch (*freq) {
> + case 100:
> + rfcks = FSL_SRDSCR4_RFCKS_100;
> + break;
>
Re: [PATCH] bestcomm: Restrict disabling of bus prefetch to original mpc5200 silicon.
On Fri, Oct 19, 2007 at 07:09:16AM -0600, Grant Likely wrote: > On 10/19/07, Domen Puncer <[EMAIL PROTECTED]> wrote: > > On 17/10/07 10:36 -0600, Grant Likely wrote: > > > From: Grant Likely <[EMAIL PROTECTED]> > > > > > > Only the MPC5200 needs this bug fix. MPC5200B is okay. > > > > > > Signed-off-by: Grant Likely <[EMAIL PROTECTED]> > > > --- > > > > > > Sven, Domen; > > > > > > Can you please test this patch? > > > > I found no obvious problems with it on Efika (mpc5200b) > > Cool, I'll add it to my list of patches for Paulus to pull Sorry, i have not had time to test, but there is a problem with the userland serial console i want to investigate. At the latest i will test this on monday. Friendly, Sven Luther ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[patch 4/4] 4xx: Enable EMAC on Bamboo board
Fix some device tree omissions that prevented the new EMAC driver from
setting up ethernet on the Bamboo board correctly and update the Bamboo
defconfig.
Signed-off-by: Josh Boyer <[EMAIL PROTECTED]>
---
arch/powerpc/boot/dts/bamboo.dts | 10 ++
arch/powerpc/configs/bamboo_defconfig | 114 --
arch/powerpc/platforms/44x/Kconfig|2
3 files changed, 76 insertions(+), 50 deletions(-)
--- linux-2.6.orig/arch/powerpc/platforms/44x/Kconfig
+++ linux-2.6/arch/powerpc/platforms/44x/Kconfig
@@ -43,7 +43,7 @@ config 440EP
bool
select PPC_FPU
select IBM440EP_ERR42
-# select IBM_NEW_EMAC_ZMII
+ select IBM_NEW_EMAC_ZMII
config 440EPX
bool
--- linux-2.6.orig/arch/powerpc/boot/dts/bamboo.dts
+++ linux-2.6/arch/powerpc/boot/dts/bamboo.dts
@@ -98,11 +98,13 @@
interrupt-parent = <&MAL0>;
interrupts = <0 1 2 3 4>;
#interrupt-cells = <1>;
+ #address-cells = <0>;
+ #size-cells = <0>;
interrupt-map = ;
+ /*RXDE*/ 4 &UIC1 2 4>;
};
POB0: opb {
@@ -196,6 +198,7 @@
};
EMAC0: [EMAIL PROTECTED] {
+ linux,network-index = <0>;
device_type = "network";
compatible = "ibm,emac-440ep",
"ibm,emac-440gp", "ibm,emac";
interrupt-parent = <&UIC1>;
@@ -210,12 +213,13 @@
rx-fifo-size = <1000>;
tx-fifo-size = <800>;
phy-mode = "rmii";
- phy-map = <0001>;
+ phy-map = <>;
zmii-device = <&ZMII0>;
zmii-channel = <0>;
};
EMAC1: [EMAIL PROTECTED] {
+ linux,network-index = <1>;
device_type = "network";
compatible = "ibm,emac-440ep",
"ibm,emac-440gp", "ibm,emac";
interrupt-parent = <&UIC1>;
@@ -230,7 +234,7 @@
rx-fifo-size = <1000>;
tx-fifo-size = <800>;
phy-mode = "rmii";
- phy-map = <0001>;
+ phy-map = <>;
zmii-device = <&ZMII0>;
zmii-channel = <1>;
};
--- linux-2.6.orig/arch/powerpc/configs/bamboo_defconfig
+++ linux-2.6/arch/powerpc/configs/bamboo_defconfig
@@ -1,7 +1,7 @@
#
# Automatically generated make config: don't edit
-# Linux kernel version: 2.6.23-rc1
-# Fri Aug 3 10:46:53 2007
+# Linux kernel version: 2.6.23
+# Fri Oct 19 09:01:11 2007
#
# CONFIG_PPC64 is not set
@@ -22,8 +22,13 @@ CONFIG_PHYS_64BIT=y
# CONFIG_PPC_MM_SLICES is not set
CONFIG_NOT_COHERENT_CACHE=y
CONFIG_PPC32=y
+CONFIG_WORD_SIZE=32
CONFIG_PPC_MERGE=y
CONFIG_MMU=y
+CONFIG_GENERIC_CMOS_UPDATE=y
+CONFIG_GENERIC_TIME=y
+CONFIG_GENERIC_TIME_VSYSCALL=y
+CONFIG_GENERIC_CLOCKEVENTS=y
CONFIG_GENERIC_HARDIRQS=y
CONFIG_IRQ_PER_CPU=y
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
@@ -67,6 +72,8 @@ CONFIG_POSIX_MQUEUE=y
# CONFIG_AUDIT is not set
# CONFIG_IKCONFIG is not set
CONFIG_LOG_BUF_SHIFT=14
+CONFIG_FAIR_GROUP_SCHED=y
+CONFIG_FAIR_USER_SCHED=y
CONFIG_SYSFS_DEPRECATED=y
# CONFIG_RELAY is not set
CONFIG_BLK_DEV_INITRD=y
@@ -87,7 +94,6 @@ CONFIG_FUTEX=y
CONFIG_ANON_INODES=y
CONFIG_EPOLL=y
CONFIG_SIGNALFD=y
-CONFIG_TIMERFD=y
CONFIG_EVENTFD=y
CONFIG_SHMEM=y
CONFIG_VM_EVENT_COUNTERS=y
@@ -133,6 +139,7 @@ CONFIG_DEFAULT_IOSCHED="anticipatory"
# CONFIG_PQ2ADS is not set
CONFIG_BAMBOO=y
# CONFIG_EBONY is not set
+# CONFIG_SEQUOIA is not set
CONFIG_440EP=y
CONFIG_IBM440EP_ERR42=y
# CONFIG_MPIC is not set
@@ -146,11 +153,16 @@ CONFIG_IBM440EP_ERR42=y
# CONFIG_GENERIC_IOMAP is not set
# CONFIG_CPU_FREQ is not set
# CONFIG_CPM2 is not set
+# CONFIG_FSL_ULI1575 is not set
#
# Kernel options
#
# CONFIG_HIGHMEM is not set
+# CONFIG_TICK_ONESHOT is not set
+# CONFIG_NO_HZ is not set
+# CONFIG_HIGH_RES_TIMERS is not set
+CONFIG_GENERIC_CLOCKEVENTS_BUILD=y
# CONFIG_HZ_100 is not set
CONFIG_HZ_250=y
# CONFIG_HZ_300 is not set
@@ -172,6 +184,7 @@ CONFIG_FLATMEM_MANUAL=y
CONFIG_FLATMEM=y
CONFIG_FLAT_NODE_MEM_MAP=y
# CONFIG_SPARSEMEM_STATIC is not set
+# CONFIG_SPARSEMEM_VMEMMAP_ENABLE is not set
CONFIG_SPLIT_PTLOCK_CPUS=4
CONFIG_RESOURCES_64BIT=y
CONFIG_ZONE_DMA_FLAG=1
@@ -197,10 +210,6 @@ CONFIG_PCI_SYSCALL=y
CONFIG_ARCH_SUPPORTS_MSI=y
# CONFIG_PCI_MSI is not set
# CONFIG_PCI_DEBUG is not set
-
-#
-# PCCARD (PCMCIA/CardBus) support
-#
[patch 2/4] 4xx: Fix timebase clock selection on Walnut
The current bootwrapper fails to set the timebase clock to the CPU clock which causes the time to increment incorrectly. This fixes it by using the correct #define for the CPC0_CR1 register. Signed-off-by: Josh Boyer <[EMAIL PROTECTED]> --- arch/powerpc/boot/treeboot-walnut.c |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) --- linux-2.6.orig/arch/powerpc/boot/treeboot-walnut.c +++ linux-2.6/arch/powerpc/boot/treeboot-walnut.c @@ -57,8 +57,8 @@ void ibm405gp_fixup_clocks(unsigned int } /* setup the timebase clock to tick at the cpu frequency */ - cpc0_cr1 = cpc0_cr1 & ~ 0x0080; - mtdcr(DCRN_CPC0_CR1, cpc0_cr1); + cpc0_cr1 = cpc0_cr1 & ~0x0080; + mtdcr(DCRN_405_CPC0_CR1, cpc0_cr1); tb = cpu; dt_fixup_cpu_clocks(cpu, tb, 0); -- ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[patch 0/4] Small 4xx fixes for 2.6.24
This series of patches enables the EMAC driver for the Ebony, Walnut, and Bamboo boards. There's also a timebase fix for Walnut. I'll put these and a few other patches that have been sent to me into my git tree later today and ask Paul to pull. josh -- ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: [PATCH] [POWERPC] ucc_geth: Eliminate compile warnings
Hello David > It only kills the warning on 32-bit systems, the cast is wrong > either way. I'm not aware of the QE being present on any 64-bit PowerPC. However, porting the entire driver to a 64-bit platform is an exercise in itself as many other things would need tweaking the QE hardware itself. But that's an orthogonal issue. For now I just want to fix that warning. > > > ugeth->tx_bd_ring_offset[j] = > > - kmalloc((u32) (length + align), > GFP_KERNEL); > > + (u32)kmalloc(length + align, > GFP_KERNEL); > > > > if (ugeth->tx_bd_ring_offset[j] != 0) > > ugeth->p_tx_bd_ring[j] = > > Pointers can be up to "unsigned long" in size, therefore that > is the minimal amount of storage you need to store them into > if they are needed in integer form for some reason. > > Any cast from pointer to integer like this is a huge red flag. Agreed, but again, I'm not trying to fix the entire driver or to port it to a different architecture. For the current situation, 32-bit QE, 32-bit PowerPC, do you find the patch acceptable? Cheers, Emil. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH v2 3/4] Implement clockevents driver for powerpc
Hello. Paul Mackerras wrote: >>The xtime_lock is still grabbed by time_init() Oops, I got distracted and hadn't finish the passage. My patch got rid of this xtime_lock stuff -- but this was in a different context, with all vDSO initialization code in between being killed by John's patch. I'm not sure it still has sense to hold this lock in time_init() around that initialization... > That was left in there because we are setting sys_tz My patch moved that to read_persistent_clock()... > and do_gtod, and do_gtod at least is only updated with the xtime_lock held. > Of course, at that early stage in the boot process, no lock is really needed, > but > xtime_lock was taken for consistency with other code. Thanks for claryfing this. >>The only thing I'm still unusre about is that deterministic accounting. >>Could you point me at the patch which deals with this (at least for System >>390 > See efe567fc8281661524ffa75477a7c4ca9b466c63 in Linus' tree, and look Wait, how this is related to the hrtimer's event handlers not being able to call account_process_time() from arch/powerpc/kernel/time.c instead of update_process_timess()? > for posts to lkml by Christian Borntraeger, who has been pursuing the > issue (subject "Re: [stable] 2.6.23 regression: top displaying % > CPU usage"). Fun. :-) > Paul. WBR, Sergei ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH v5 9/9] add MPC837x MDS board default device tree
On Oct 19, 2007, at 2:31 AM, Li Yang-r58472 wrote:
>> -Original Message-
>> From: David Gibson [mailto:[EMAIL PROTECTED]
>> Sent: Friday, October 19, 2007 8:56 AM
>> To: Li Yang-r58472
>> Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED];
>> linuxppc-dev@ozlabs.org
>> Subject: Re: [PATCH v5 9/9] add MPC837x MDS board default device tree
>>
>> On Thu, Oct 18, 2007 at 06:16:20PM +0800, Li Yang wrote:
>>> Signed-off-by: Li Yang <[EMAIL PROTECTED]>
>>> ---
>>> diff --git a/arch/powerpc/boot/dts/mpc8377_mds.dts
>>> b/arch/powerpc/boot/dts/mpc8377_mds.dts
>>> new file mode 100644
>>> index 000..8530de6
>>> --- /dev/null
>>> +++ b/arch/powerpc/boot/dts/mpc8377_mds.dts
>>> @@ -0,0 +1,282 @@
>> [snip]
>>> + [EMAIL PROTECTED] {
>>> + model = "SEC3";
>>> + compatible = "talitos";
>>
>> That compatible doesn't look specific enough. It should at
>> least have a vendor portion. In general it's best to have
>> all the information you need to pick a driver and options in
>> compatible, rather than splitting that info into model.
>
> I think we could do this in a separate patch. Change the spec and
> then
> update all the in-tree device tree with SEC node.
agreed.
- k
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] ppc44x: support for 256K PAGE_SIZE
On Oct 18, 2007, at 6:21 PM, Paul Mackerras wrote: > Yuri Tikhonov writes: > >> The following patch adds support for 256KB PAGE_SIZE on ppc44x- >> based boards. >> The applications to be run on the kernel with 256KB PAGE_SIZE have >> to be >> built using the modified version of binutils, where the MAXPAGESIZE >> definition is set to 0x4 (as opposite to standard 0x1). > > Have you measured the performance using a 64kB page size? If so, how > does it compare with the 256kB page size? I was wondering about this as well? Isn't this technically in violation of the ABI? - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Building zImage
On Oct 18, 2007, at 6:22 PM, Siva Prasad wrote: > Hi, > > When I tried to build zImage (make zImage V=1) based on the 2.6.19 > kernel for 8641HPCN board, I got the following error... > > make -f scripts/Makefile.build obj=lib > make -f > /export/beavis/work/sprasad/2.6.19/linux-2.6.19/scripts/ > Makefile.modpost > vmlinux > scripts/mod/modpost -m -o > /export/beavis/work/sprasad/2.6.19/linux-2.6.19/Module.symvers > vmlinux > rm -f .old_version > make ARCH=ppc64 -f scripts/Makefile.build obj=arch/powerpc/boot > arch/powerpc/boot/zImage > ln: accessing `arch/powerpc/boot/zImage': No such file or directory > make[1]: *** [arch/powerpc/boot/zImage] Error 1 > make: *** [zImage] Error 2 > > When I looked into the Makefile, "image-y" was having no value. So, > "ln" > was failing. Do I have to select one of the below options of zImage. I > am not really sure which one to use for 8641 supported by FreeScale. > > image-$(CONFIG_PPC_PSERIES) += zImage.pseries > image-$(CONFIG_PPC_MAPLE) += zImage.pseries > image-$(CONFIG_PPC_IBM_CELL_BLADE) += zImage.pseries > image-$(CONFIG_PPC_CHRP)+= zImage.chrp > image-$(CONFIG_PPC_PMAC)+= zImage.pmac > image-$(CONFIG_DEFAULT_UIMAGE) += uImage > > Well!... we are not using U-Boot, so uImage is not an option, and that > builds fine. > > Any way, I tried to make uImage, but I am not sure if it is including > the dts file in the final uImage built, as the wrapper was passed the > value of platform as "uboot". I am confused. > > Thanks for your help in advance. uImage's do NOT include device trees as part of the image. - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[POWERPC v2] powerpc: Add -mno-spe for ARCH=powerpc builds
Newer GCC's are capable of autovectorization for ISA extensions like AltiVec and SPE. If we happen to build with one of those compilers we will get SPE instructions in random kernel code. Today we only allow basic interger code in the kernel and FP, AltiVec, or SPE in special explicit locations that have handled the proper saving and restoring of the register state (since on uniprocessor we lazy context switch the register state for FP, AltiVec, and SPE). -mno-spe disables the compiler for automatically generating SPE instructions without our knowledge. --- Hopefully this is up to Paul's double standard :) (as normal, its in my git tree, posted here for review). arch/powerpc/Makefile |3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) diff --git a/arch/powerpc/Makefile b/arch/powerpc/Makefile index 4e16534..bd87626 100644 --- a/arch/powerpc/Makefile +++ b/arch/powerpc/Makefile @@ -107,6 +107,9 @@ endif # No AltiVec instruction when building kernel KBUILD_CFLAGS += $(call cc-option,-mno-altivec) +# No SPE instruction when building kernel +KBUILD_CFLAGS += $(call cc-option,-mno-spe) + # Enable unit-at-a-time mode when possible. It shrinks the # kernel considerably. KBUILD_CFLAGS += $(call cc-option,-funit-at-a-time) -- 1.5.2.4 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] [POWERPC] powerpc: Add -mno-spe for ARCH=powerpc builds
So, like, the other day Kumar Gala mumbled: > > On Oct 18, 2007, at 6:19 PM, Paul Mackerras wrote: > > > Your commit message doesn't give any reason why you are doing this, or > > any explanation of what goes wrong without it. In fact, the commit > > message is completely empty. :) Please resubmit with a decent commit > > message. > > I will, just as an FYI I based this on your commit for -mno-altivec > (which has no rationale for the commit) :) Hmmm. And also, let's not forget that the mail Subject: line does contribute to the git log commit message as well. Thanks, jdl ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH v2 3/4] Implement clockevents driver for powerpc
Sergei Shtylyov writes: > BTW, why not handle the decrementer difference right in set_dec() where > we > already have #ifdef'ed code? Excellent idea. Let's do that. Paul. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH v2 3/4] Implement clockevents driver for powerpc
Paul Mackerras wrote: > Sergei Shtylyov writes: >>And now you have incomplete read_persistent_clock() implementation for > I don't see anything incomplete about it. If you do, feel free to > post a patch. The xtime_lock is still grabbed by time_init() >>example, god knows why it was preferred to mine -- well, it also implemented > Your most recent post of your patch to implement read_persistent_clock > was in May -- five months ago -- and you said this about it: "This Right, the most recent was in May but that was only a recast of the October version (i.e. year old) -- that patch got somehow dropped from later the -rt patches IIRC. > patch hasn't received a good testing though". Right, it never has been tested on macines with RTC. That was a fair warning. :-) > You don't have to be a god to figure out why I preferred a patch that > had been tested, where the author was responding to comments and > posting updated versions of his patch in the period leading up to the > merge window, over that. Unfortunately, I didn't have time to try pusing it into every -rc1 since 2.6.18 -- there has been experimental hrtimers patchset at that time with even x86 stuff being unmerged to mainline, so the stuff could only be pushed into that patchset last autumn. I was going to try addressing vDSO stuff, yet there has been too much work aside of that. Still, I've answered the mails. :-) >>I just wanted the reasons clarified and got what I wanted -- as I >> thought, >>the decision behind preferring patches was somewhat biased, nobody really >>cared about code quality or just wasn't familiar with hrtimers enough to >>judge >>on the code quality... > You really know how to persuade people to cooperate, don't you... :P Well, I'm not persuading anybody, sine I don't believe that I can persuade somebody to do my work, so had to just vainly complain :-). However, I agree that my complaints/ comments might have been somewhat rash and unjust -- Tony's patches are *not* that bad after all. :-) The only thing I'm still unusre about is that deterministic accounting. Could you point me at the patch which deals with this (at least for System 390 :-)? > Paul. WBR, Sergei ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] [POWERPC] powerpc: Add -mno-spe for ARCH=powerpc builds
On Thu, 18 Oct 2007 22:20:49 -0500 Kumar Gala <[EMAIL PROTECTED]> wrote: > > On Oct 18, 2007, at 6:19 PM, Paul Mackerras wrote: > > > Kumar Gala writes: > > > >> Signed-off-by: Kumar Gala <[EMAIL PROTECTED]> > > > > Your commit message doesn't give any reason why you are doing this, or > > any explanation of what goes wrong without it. In fact, the commit > > message is completely empty. :) Please resubmit with a decent commit > > message. > > I will, just as an FYI I based this on your commit for -mno-altivec > (which has no rationale for the commit) :) Do as he says, not as he does! ;) josh ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] bestcomm: Restrict disabling of bus prefetch to original mpc5200 silicon.
On 17/10/07 10:36 -0600, Grant Likely wrote: > From: Grant Likely <[EMAIL PROTECTED]> > > Only the MPC5200 needs this bug fix. MPC5200B is okay. > > Signed-off-by: Grant Likely <[EMAIL PROTECTED]> > --- > > Sven, Domen; > > Can you please test this patch? I found no obvious problems with it on Efika (mpc5200b) Domen ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH v7 8/9] add MPC837x MDS default kernel configuration
Signed-off-by: Li Yang <[EMAIL PROTECTED]> --- arch/powerpc/configs/mpc837x_mds_defconfig | 878 1 files changed, 878 insertions(+), 0 deletions(-) create mode 100644 arch/powerpc/configs/mpc837x_mds_defconfig diff --git a/arch/powerpc/configs/mpc837x_mds_defconfig b/arch/powerpc/configs/mpc837x_mds_defconfig new file mode 100644 index 000..4f49aee --- /dev/null +++ b/arch/powerpc/configs/mpc837x_mds_defconfig @@ -0,0 +1,878 @@ +# +# Automatically generated make config: don't edit +# Linux kernel version: 2.6.23 +# Wed Oct 10 16:31:39 2007 +# +# CONFIG_PPC64 is not set + +# +# Processor support +# +CONFIG_6xx=y +# CONFIG_PPC_85xx is not set +# CONFIG_PPC_8xx is not set +# CONFIG_40x is not set +# CONFIG_44x is not set +# CONFIG_E200 is not set +CONFIG_83xx=y +CONFIG_PPC_FPU=y +CONFIG_PPC_STD_MMU=y +CONFIG_PPC_STD_MMU_32=y +# CONFIG_PPC_MM_SLICES is not set +# CONFIG_SMP is not set +CONFIG_PPC32=y +CONFIG_PPC_MERGE=y +CONFIG_MMU=y +CONFIG_GENERIC_HARDIRQS=y +CONFIG_IRQ_PER_CPU=y +CONFIG_RWSEM_XCHGADD_ALGORITHM=y +CONFIG_ARCH_HAS_ILOG2_U32=y +CONFIG_GENERIC_HWEIGHT=y +CONFIG_GENERIC_CALIBRATE_DELAY=y +CONFIG_GENERIC_FIND_NEXT_BIT=y +# CONFIG_ARCH_NO_VIRT_TO_BUS is not set +CONFIG_PPC=y +CONFIG_EARLY_PRINTK=y +CONFIG_GENERIC_NVRAM=y +CONFIG_SCHED_NO_NO_OMIT_FRAME_POINTER=y +CONFIG_ARCH_MAY_HAVE_PC_FDC=y +CONFIG_PPC_OF=y +CONFIG_OF=y +CONFIG_PPC_UDBG_16550=y +# CONFIG_GENERIC_TBSYNC is not set +CONFIG_AUDIT_ARCH=y +CONFIG_GENERIC_BUG=y +CONFIG_DEFAULT_UIMAGE=y +# CONFIG_PPC_DCR_NATIVE is not set +# CONFIG_PPC_DCR_MMIO is not set +CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config" + +# +# General setup +# +CONFIG_EXPERIMENTAL=y +CONFIG_BROKEN_ON_SMP=y +CONFIG_INIT_ENV_ARG_LIMIT=32 +CONFIG_LOCALVERSION="" +CONFIG_LOCALVERSION_AUTO=y +CONFIG_SWAP=y +CONFIG_SYSVIPC=y +CONFIG_SYSVIPC_SYSCTL=y +# CONFIG_POSIX_MQUEUE is not set +# CONFIG_BSD_PROCESS_ACCT is not set +# CONFIG_TASKSTATS is not set +# CONFIG_USER_NS is not set +# CONFIG_AUDIT is not set +# CONFIG_IKCONFIG is not set +CONFIG_LOG_BUF_SHIFT=14 +CONFIG_SYSFS_DEPRECATED=y +# CONFIG_RELAY is not set +CONFIG_BLK_DEV_INITRD=y +CONFIG_INITRAMFS_SOURCE="" +# CONFIG_CC_OPTIMIZE_FOR_SIZE is not set +CONFIG_SYSCTL=y +CONFIG_EMBEDDED=y +CONFIG_SYSCTL_SYSCALL=y +CONFIG_KALLSYMS=y +# CONFIG_KALLSYMS_EXTRA_PASS is not set +CONFIG_HOTPLUG=y +CONFIG_PRINTK=y +CONFIG_BUG=y +CONFIG_ELF_CORE=y +CONFIG_BASE_FULL=y +CONFIG_FUTEX=y +CONFIG_ANON_INODES=y +# CONFIG_EPOLL is not set +CONFIG_SIGNALFD=y +CONFIG_EVENTFD=y +CONFIG_SHMEM=y +CONFIG_VM_EVENT_COUNTERS=y +CONFIG_SLAB=y +# CONFIG_SLUB is not set +# CONFIG_SLOB is not set +CONFIG_RT_MUTEXES=y +# CONFIG_TINY_SHMEM is not set +CONFIG_BASE_SMALL=0 +CONFIG_MODULES=y +CONFIG_MODULE_UNLOAD=y +# CONFIG_MODULE_FORCE_UNLOAD is not set +# CONFIG_MODVERSIONS is not set +# CONFIG_MODULE_SRCVERSION_ALL is not set +# CONFIG_KMOD is not set +CONFIG_BLOCK=y +# CONFIG_LBD is not set +# CONFIG_BLK_DEV_IO_TRACE is not set +# CONFIG_LSF is not set +# CONFIG_BLK_DEV_BSG is not set + +# +# IO Schedulers +# +CONFIG_IOSCHED_NOOP=y +CONFIG_IOSCHED_AS=y +CONFIG_IOSCHED_DEADLINE=y +CONFIG_IOSCHED_CFQ=y +CONFIG_DEFAULT_AS=y +# CONFIG_DEFAULT_DEADLINE is not set +# CONFIG_DEFAULT_CFQ is not set +# CONFIG_DEFAULT_NOOP is not set +CONFIG_DEFAULT_IOSCHED="anticipatory" + +# +# Platform support +# +# CONFIG_PPC_MULTIPLATFORM is not set +# CONFIG_EMBEDDED6xx is not set +# CONFIG_PPC_82xx is not set +CONFIG_PPC_83xx=y +# CONFIG_PPC_86xx is not set +# CONFIG_PPC_MPC52xx is not set +# CONFIG_PPC_MPC5200 is not set +# CONFIG_PPC_CELL is not set +# CONFIG_PPC_CELL_NATIVE is not set +# CONFIG_PQ2ADS is not set +# CONFIG_MPC8313_RDB is not set +# CONFIG_MPC832x_MDS is not set +# CONFIG_MPC832x_RDB is not set +# CONFIG_MPC834x_MDS is not set +# CONFIG_MPC834x_ITX is not set +# CONFIG_MPC836x_MDS is not set +CONFIG_MPC837x_MDS=y +CONFIG_PPC_MPC837x=y +# CONFIG_MPIC is not set +# CONFIG_MPIC_WEIRD is not set +# CONFIG_PPC_I8259 is not set +# CONFIG_PPC_RTAS is not set +# CONFIG_MMIO_NVRAM is not set +# CONFIG_PPC_MPC106 is not set +# CONFIG_PPC_970_NAP is not set +# CONFIG_PPC_INDIRECT_IO is not set +# CONFIG_GENERIC_IOMAP is not set +# CONFIG_CPU_FREQ is not set +# CONFIG_CPM2 is not set +# CONFIG_FSL_ULI1575 is not set +CONFIG_FSL_SERDES=y + +# +# Kernel options +# +# CONFIG_HIGHMEM is not set +# CONFIG_HZ_100 is not set +CONFIG_HZ_250=y +# CONFIG_HZ_300 is not set +# CONFIG_HZ_1000 is not set +CONFIG_HZ=250 +CONFIG_PREEMPT_NONE=y +# CONFIG_PREEMPT_VOLUNTARY is not set +# CONFIG_PREEMPT is not set +CONFIG_BINFMT_ELF=y +# CONFIG_BINFMT_MISC is not set +CONFIG_ARCH_ENABLE_MEMORY_HOTPLUG=y +CONFIG_ARCH_FLATMEM_ENABLE=y +CONFIG_ARCH_POPULATES_NODE_MAP=y +CONFIG_SELECT_MEMORY_MODEL=y +CONFIG_FLATMEM_MANUAL=y +# CONFIG_DISCONTIGMEM_MANUAL is not set +# CONFIG_SPARSEMEM_MANUAL is not set +CONFIG_FLATMEM=y +CONFIG_FLAT_NODE_MEM_MAP=y +# CONFIG_SPARSEMEM_STATIC is not set +CONFIG_SPLIT_PTLOCK_CPUS=4 +# CONFIG_RESOURCES_64BIT is
[PATCH v7 7/9] ipic: clean up unsupported ack operations
IPIC controller doesn't support ack operations. The pending registers
are read-only. The patch removes ack operations which are not needed.
Signed-off-by: Li Yang <[EMAIL PROTECTED]>
---
arch/powerpc/sysdev/ipic.c | 40 ++--
1 files changed, 2 insertions(+), 38 deletions(-)
diff --git a/arch/powerpc/sysdev/ipic.c b/arch/powerpc/sysdev/ipic.c
index 7168b03..174fd7a 100644
--- a/arch/powerpc/sysdev/ipic.c
+++ b/arch/powerpc/sysdev/ipic.c
@@ -533,42 +533,7 @@ static void ipic_mask_irq(unsigned int virq)
temp = ipic_read(ipic->regs, ipic_info[src].mask);
temp &= ~(1 << (31 - ipic_info[src].bit));
ipic_write(ipic->regs, ipic_info[src].mask, temp);
-
- spin_unlock_irqrestore(&ipic_lock, flags);
-}
-
-static void ipic_ack_irq(unsigned int virq)
-{
- struct ipic *ipic = ipic_from_irq(virq);
- unsigned int src = ipic_irq_to_hw(virq);
- unsigned long flags;
- u32 temp;
-
- spin_lock_irqsave(&ipic_lock, flags);
-
- temp = ipic_read(ipic->regs, ipic_info[src].pend);
- temp |= (1 << (31 - ipic_info[src].bit));
- ipic_write(ipic->regs, ipic_info[src].pend, temp);
-
- spin_unlock_irqrestore(&ipic_lock, flags);
-}
-
-static void ipic_mask_irq_and_ack(unsigned int virq)
-{
- struct ipic *ipic = ipic_from_irq(virq);
- unsigned int src = ipic_irq_to_hw(virq);
- unsigned long flags;
- u32 temp;
-
- spin_lock_irqsave(&ipic_lock, flags);
-
- temp = ipic_read(ipic->regs, ipic_info[src].mask);
- temp &= ~(1 << (31 - ipic_info[src].bit));
- ipic_write(ipic->regs, ipic_info[src].mask, temp);
-
- temp = ipic_read(ipic->regs, ipic_info[src].pend);
- temp |= (1 << (31 - ipic_info[src].bit));
- ipic_write(ipic->regs, ipic_info[src].pend, temp);
+ mb();
spin_unlock_irqrestore(&ipic_lock, flags);
}
@@ -626,8 +591,7 @@ static struct irq_chip ipic_irq_chip = {
.typename = " IPIC ",
.unmask = ipic_unmask_irq,
.mask = ipic_mask_irq,
- .mask_ack = ipic_mask_irq_and_ack,
- .ack= ipic_ack_irq,
+ .mask_ack = ipic_mask_irq,
.set_type = ipic_set_irq_type,
};
--
1.5.3.2.104.g41ef
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH v7 6/9] add documentation for SerDes nodes
Signed-off-by: Li Yang <[EMAIL PROTECTED]>
---
Documentation/powerpc/booting-without-of.txt | 29 ++
1 files changed, 29 insertions(+), 0 deletions(-)
diff --git a/Documentation/powerpc/booting-without-of.txt
b/Documentation/powerpc/booting-without-of.txt
index 8d49942..8a9372e 100644
--- a/Documentation/powerpc/booting-without-of.txt
+++ b/Documentation/powerpc/booting-without-of.txt
@@ -2274,6 +2274,35 @@ platforms are moved over to use the
flattened-device-tree model.
phy-handle = < &serdes1 >;
};
+p) SerDes nodes
+
+SerDes is a serializer/deserializer used by some Freescale SoC.
+
+Required properties:
+
+- compatible : Should specify what this SerDes controller is compatible
+ with. Currently, this is most likely to be "fsl,serdes".
+- reg : Offset and length of the register set for the device.
+- protocol : Which up layer protocol is running on the serial
+ interface. Could be "sata", "pcie", "sgmii".
+- clock : Input clock frequency for SerDes in unit of MHz.
+
+Optional properties:
+
+- vdd-1v : Define this property when Vdd is 1V.
+- pcie-x2 : Define this property when using PCI Express x2 interface.
+ Valid only when protocol is set to "pcie".
+
+ Example:
+
+ serdes1:[EMAIL PROTECTED] {
+ compatible = "fsl,serdes";
+ reg = ;
+ vdd-1v;
+ protocol = "sata";
+ clock = ;
+ };
+
More devices will be defined as this spec matures.
VII - Specifying interrupt information for devices
--
1.5.3.2.104.g41ef
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH v7 4/9] add platform support for MPC837x MDS board
The MPC837x MDS is a new member of Freescale MDS reference system.
Signed-off-by: Li Yang <[EMAIL PROTECTED]>
---
arch/powerpc/platforms/83xx/Kconfig | 12 +++
arch/powerpc/platforms/83xx/Makefile |1 +
arch/powerpc/platforms/83xx/mpc837x_mds.c | 104 +
3 files changed, 117 insertions(+), 0 deletions(-)
create mode 100644 arch/powerpc/platforms/83xx/mpc837x_mds.c
diff --git a/arch/powerpc/platforms/83xx/Kconfig
b/arch/powerpc/platforms/83xx/Kconfig
index ec305f1..0c61e7a 100644
--- a/arch/powerpc/platforms/83xx/Kconfig
+++ b/arch/powerpc/platforms/83xx/Kconfig
@@ -50,6 +50,11 @@ config MPC836x_MDS
help
This option enables support for the MPC836x MDS Processor Board.
+config MPC837x_MDS
+ bool "Freescale MPC837x MDS"
+ select DEFAULT_UIMAGE
+ help
+ This option enables support for the MPC837x MDS Processor Board.
endchoice
config PPC_MPC831x
@@ -75,3 +80,10 @@ config PPC_MPC836x
select PPC_UDBG_16550
select PPC_INDIRECT_PCI
default y if MPC836x_MDS
+
+config PPC_MPC837x
+ bool
+ select PPC_UDBG_16550
+ select PPC_INDIRECT_PCI
+ select FSL_SERDES
+ default y if MPC837x_MDS
diff --git a/arch/powerpc/platforms/83xx/Makefile
b/arch/powerpc/platforms/83xx/Makefile
index 5a98f88..df46629 100644
--- a/arch/powerpc/platforms/83xx/Makefile
+++ b/arch/powerpc/platforms/83xx/Makefile
@@ -9,3 +9,4 @@ obj-$(CONFIG_MPC834x_MDS) += mpc834x_mds.o
obj-$(CONFIG_MPC834x_ITX) += mpc834x_itx.o
obj-$(CONFIG_MPC836x_MDS) += mpc836x_mds.o
obj-$(CONFIG_MPC832x_MDS) += mpc832x_mds.o
+obj-$(CONFIG_MPC837x_MDS) += mpc837x_mds.o
diff --git a/arch/powerpc/platforms/83xx/mpc837x_mds.c
b/arch/powerpc/platforms/83xx/mpc837x_mds.c
new file mode 100644
index 000..166c111
--- /dev/null
+++ b/arch/powerpc/platforms/83xx/mpc837x_mds.c
@@ -0,0 +1,104 @@
+/*
+ * arch/powerpc/platforms/83xx/mpc837x_mds.c
+ *
+ * Copyright (C) 2007 Freescale Semiconductor, Inc. All rights reserved.
+ *
+ * MPC837x MDS board specific routines
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2 of the License, or (at your
+ * option) any later version.
+ */
+
+#include
+#include
+#include
+
+#include
+#include
+#include
+#include
+
+#include "mpc83xx.h"
+
+#ifndef CONFIG_PCI
+unsigned long isa_io_base = 0;
+unsigned long isa_mem_base = 0;
+#endif
+
+/*
+ *
+ * Setup the architecture
+ *
+ */
+static void __init mpc837x_mds_setup_arch(void)
+{
+#ifdef CONFIG_PCI
+ struct device_node *np;
+#endif
+
+ if (ppc_md.progress)
+ ppc_md.progress("mpc837x_mds_setup_arch()", 0);
+
+#ifdef CONFIG_PCI
+ for_each_compatible_node(np, "pci", "fsl,mpc8349-pci")
+ mpc83xx_add_bridge(np);
+#endif
+}
+
+static struct of_device_id mpc837x_ids[] = {
+ { .type = "soc", },
+ { .compatible = "soc", },
+ {},
+};
+
+static int __init mpc837x_declare_of_platform_devices(void)
+{
+ if (!machine_is(mpc837x_mds))
+ return 0;
+
+ /* Publish of_device */
+ of_platform_bus_probe(NULL, mpc837x_ids, NULL);
+
+ return 0;
+}
+device_initcall(mpc837x_declare_of_platform_devices);
+
+static void __init mpc837x_mds_init_IRQ(void)
+{
+ struct device_node *np;
+
+ np = of_find_compatible_node(NULL, NULL, "fsl,ipic");
+ if (!np)
+ return;
+
+ ipic_init(np, 0);
+
+ /* Initialize the default interrupt mapping priorities,
+* in case the boot rom changed something on us.
+*/
+ ipic_set_default_priority();
+}
+
+/*
+ * Called very early, MMU is off, device-tree isn't unflattened
+ */
+static int __init mpc837x_mds_probe(void)
+{
+unsigned long root = of_get_flat_dt_root();
+
+return of_flat_dt_is_compatible(root, "fsl,mpc837xmds");
+}
+
+define_machine(mpc837x_mds) {
+ .name = "MPC837x MDS",
+ .probe = mpc837x_mds_probe,
+ .setup_arch = mpc837x_mds_setup_arch,
+ .init_IRQ = mpc837x_mds_init_IRQ,
+ .get_irq= ipic_get_irq,
+ .restart= mpc83xx_restart,
+ .time_init = mpc83xx_time_init,
+ .calibrate_decr = generic_calibrate_decr,
+ .progress = udbg_progress,
+};
--
1.5.3.2.104.g41ef
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 04/15] [POWERPC] CM5200 DTS
David Gibson wrote:
> On Wed, Oct 17, 2007 at 02:22:04PM +0200, Marian Balakowicz wrote:
>> David Gibson wrote:
>>> [snip]
+ [EMAIL PROTECTED] {
+ device_type = "rom";
+ compatible = "direct-mapped";
+ reg = <0c00 0200>;
+ probe-type = "CFI";
+ bank-width = <2>;
+ partitions = < 0006
+ 0006 0002
+ 0008 0002
+ 000a 0002
+ 000c 0020
+ 002c 01b4
+ 01e0 0020>;
+ partition-names =
"uboot\0env\0redund_env\0dtb\0kernel\0rootfs\0config";
+ };
>>> First, this is the old flash binding, please use the new one.
>> Ok.
>>
>>> Second, is the flash really part of the SoC?
>> Not directly, it is attached to LocalPlus Bus Controller, which is
>> part of the SoC. And the soc@ is currently the only recognized of bus
>> for mpc5200, so if we want to move it to some other place new bindings
>> will need to be defined for lpc (LocalPlus Controller) bus. But I am
>> not quite sure where this should be attached. Bus is under LPC which
>> is a part of the SoC, but on the other hand Soc address range covers
>> only device control registers not the address space LPC may handle
>> (that may be varied). Any ideas?
>
> The bus bridge has to be there. Is this something similar to the
> "localbus" / "chipselect" bus controllers that a whole bunch of the
> Freescale SoCs have?
Yes, that's kind of a local bus.
> Because the bridged addresses don't lie in the
> IMMR, althoug the control registers do, the current convention is to
> make the localbus node a sibling of /soc, even though it is really
> part of the SoC (/soc would perhaps be better called /immr, but /soc
> is established now). This approach is imperfect, but so are most of
> the other compromises we could make.
>
> Incidentally LPC is a pretty bad abbreviation, since LPC more
> frequently refers to the Low Pin Count connections that frequently
> appear on south bridges or superIO chips.
How about 'LocalPlus Bus' and 'lpb' node then?
m.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH v7 3/9] add Freescale SerDes PHY support
The SerDes(serializer/deserializer) PHY block is a new SoC block used
in Freescale chips to support multiple serial interfaces, such as PCI
Express, SGMII, SATA.
Signed-off-by: Li Yang <[EMAIL PROTECTED]>
---
arch/powerpc/platforms/Kconfig |7 ++
arch/powerpc/sysdev/Makefile |1 +
arch/powerpc/sysdev/fsl_serdes.c | 195 ++
3 files changed, 203 insertions(+), 0 deletions(-)
create mode 100644 arch/powerpc/sysdev/fsl_serdes.c
diff --git a/arch/powerpc/platforms/Kconfig b/arch/powerpc/platforms/Kconfig
index 229d355..5d64f84 100644
--- a/arch/powerpc/platforms/Kconfig
+++ b/arch/powerpc/platforms/Kconfig
@@ -315,6 +315,13 @@ config FSL_ULI1575
config CPM
bool
+config FSL_SERDES
+ bool
+ help
+ The SerDes(serializer/deserializer) PHY block is a new SoC block
+ used in Freescale chips to support multiple serial interfaces,
+ such as PCI Express, SGMII, SATA.
+
source "arch/powerpc/sysdev/bestcomm/Kconfig"
endmenu
diff --git a/arch/powerpc/sysdev/Makefile b/arch/powerpc/sysdev/Makefile
index 99a77d7..2343ea4 100644
--- a/arch/powerpc/sysdev/Makefile
+++ b/arch/powerpc/sysdev/Makefile
@@ -20,6 +20,7 @@ obj-$(CONFIG_MV64X60) += $(mv64x60-y) mv64x60_pic.o
mv64x60_dev.o \
mv64x60_udbg.o
obj-$(CONFIG_RTC_DRV_CMOS) += rtc_cmos_setup.o
obj-$(CONFIG_AXON_RAM) += axonram.o
+obj-$(CONFIG_FSL_SERDES) += fsl_serdes.o
ifeq ($(CONFIG_PPC_MERGE),y)
obj-$(CONFIG_PPC_INDIRECT_PCI) += indirect_pci.o
diff --git a/arch/powerpc/sysdev/fsl_serdes.c b/arch/powerpc/sysdev/fsl_serdes.c
new file mode 100644
index 000..670015d
--- /dev/null
+++ b/arch/powerpc/sysdev/fsl_serdes.c
@@ -0,0 +1,195 @@
+/*
+ * arch/powerpc/sysdev/fsl_serdes.c
+ *
+ * Copyright (C) 2007 Freescale Semiconductor, Inc. All rights reserved.
+ *
+ * Author: Li Yang <[EMAIL PROTECTED]>
+ *
+ * Freescale SerDes initialization routines
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2 of the License, or (at your
+ * option) any later version.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+
+#define FSL_SRDSCR0_OFFS 0x0
+#define FSL_SRDSCR0_DPP_1V20x8800
+#define FSL_SRDSCR1_OFFS 0x4
+#define FSL_SRDSCR1_PLLBW 0x0040
+#define FSL_SRDSCR2_OFFS 0x8
+#define FSL_SRDSCR2_VDD_1V20x0080
+#define FSL_SRDSCR2_SEIC_MASK 0x1c1c
+#define FSL_SRDSCR2_SEIC_SATA 0x1414
+#define FSL_SRDSCR2_SEIC_PEX 0x1010
+#define FSL_SRDSCR2_SEIC_SGMII 0x0101
+#define FSL_SRDSCR3_OFFS 0xc
+#define FSL_SRDSCR3_KFR_SATA 0x1010
+#define FSL_SRDSCR3_KPH_SATA 0x0404
+#define FSL_SRDSCR3_SDFM_SATA_PEX 0x0101
+#define FSL_SRDSCR3_SDTXL_SATA 0x0505
+#define FSL_SRDSCR4_OFFS 0x10
+#define FSL_SRDSCR4_PROT_SATA 0x0808
+#define FSL_SRDSCR4_PROT_PEX 0x0101
+#define FSL_SRDSCR4_PROT_SGMII 0x0505
+#define FSL_SRDSCR4_PLANE_X2 0x0100
+#define FSL_SRDSCR4_RFCKS_100 0x
+#define FSL_SRDSCR4_RFCKS_125 0x1000
+#define FSL_SRDSCR4_RFCKS_150 0x3000
+#define FSL_SRDSRSTCTL_OFFS0x20
+#define FSL_SRDSRSTCTL_RST 0x8000
+#define FSL_SRDSRSTCTL_SATA_RESET 0xf
+
+static int fsl_serdes_probe(struct of_device *ofdev,
+ const struct of_device_id *match)
+{
+ struct device_node *np = ofdev->node;
+ void __iomem *regs;
+ const char *prot;
+ const unsigned int *freq;
+ u32 rfcks;
+
+ regs = of_iomap(np, 0);
+ if (!regs)
+ return -ENOMEM;
+
+ prot = of_get_property(np, "protocol", NULL);
+ if (!prot)
+ goto out;
+ freq = of_get_property(np, "clock", NULL);
+ if (!freq)
+ goto out;
+ switch (*freq) {
+ case 100:
+ rfcks = FSL_SRDSCR4_RFCKS_100;
+ break;
+ case 125:
+ rfcks = FSL_SRDSCR4_RFCKS_125;
+ break;
+ case 150:
+ rfcks = FSL_SRDSCR4_RFCKS_150;
+ break;
+ default:
+ printk(KERN_ERR "SerDes: Wrong frequency\n");
+ goto out;
+ }
+
+ /* Use default prescale and counter */
+
+ /* 1.0V corevdd */
+ if (of_get_property(np, "vdd-1v", NULL)) {
+ /* DPPE/DPPA = 0 */
+ clrbits32(regs + FSL_SRDSCR0_OFFS, FSL_SRDSCR0_DPP_1V2);
+
+ /* VDD = 0 */
+ clrbits32(regs + FSL_SRDSCR2_OFFS, FSL_SRDSCR2_VDD_1V2);
+ }
+
+ /* protocol specific configuration */
+
[PATCH v7 2/9] ipic: add new interrupts introduced by new chip
These interrupts are introduced by the latest Freescale SoC such as
MPC837x.
Signed-off-by: Li Yang <[EMAIL PROTECTED]>
---
arch/powerpc/sysdev/ipic.c | 138 ++--
arch/powerpc/sysdev/ipic.h |7 +-
include/asm-powerpc/ipic.h | 12 ++--
3 files changed, 143 insertions(+), 14 deletions(-)
diff --git a/arch/powerpc/sysdev/ipic.c b/arch/powerpc/sysdev/ipic.c
index 05a56e5..7168b03 100644
--- a/arch/powerpc/sysdev/ipic.c
+++ b/arch/powerpc/sysdev/ipic.c
@@ -33,6 +33,30 @@ static struct ipic * primary_ipic;
static DEFINE_SPINLOCK(ipic_lock);
static struct ipic_info ipic_info[] = {
+ [1] = {
+ .pend = IPIC_SIPNR_H,
+ .mask = IPIC_SIMSR_H,
+ .prio = IPIC_SIPRR_C,
+ .force = IPIC_SIFCR_H,
+ .bit= 16,
+ .prio_mask = 0,
+ },
+ [2] = {
+ .pend = IPIC_SIPNR_H,
+ .mask = IPIC_SIMSR_H,
+ .prio = IPIC_SIPRR_C,
+ .force = IPIC_SIFCR_H,
+ .bit= 17,
+ .prio_mask = 1,
+ },
+ [4] = {
+ .pend = IPIC_SIPNR_H,
+ .mask = IPIC_SIMSR_H,
+ .prio = IPIC_SIPRR_C,
+ .force = IPIC_SIFCR_H,
+ .bit= 19,
+ .prio_mask = 3,
+ },
[9] = {
.pend = IPIC_SIPNR_H,
.mask = IPIC_SIMSR_H,
@@ -57,6 +81,22 @@ static struct ipic_info ipic_info[] = {
.bit= 26,
.prio_mask = 2,
},
+ [12] = {
+ .pend = IPIC_SIPNR_H,
+ .mask = IPIC_SIMSR_H,
+ .prio = IPIC_SIPRR_D,
+ .force = IPIC_SIFCR_H,
+ .bit= 27,
+ .prio_mask = 3,
+ },
+ [13] = {
+ .pend = IPIC_SIPNR_H,
+ .mask = IPIC_SIMSR_H,
+ .prio = IPIC_SIPRR_D,
+ .force = IPIC_SIFCR_H,
+ .bit= 28,
+ .prio_mask = 4,
+ },
[14] = {
.pend = IPIC_SIPNR_H,
.mask = IPIC_SIMSR_H,
@@ -201,6 +241,46 @@ static struct ipic_info ipic_info[] = {
.bit= 7,
.prio_mask = 7,
},
+ [42] = {
+ .pend = IPIC_SIPNR_H,
+ .mask = IPIC_SIMSR_H,
+ .prio = IPIC_SIPRR_B,
+ .force = IPIC_SIFCR_H,
+ .bit= 10,
+ .prio_mask = 2,
+ },
+ [44] = {
+ .pend = IPIC_SIPNR_H,
+ .mask = IPIC_SIMSR_H,
+ .prio = IPIC_SIPRR_B,
+ .force = IPIC_SIFCR_H,
+ .bit= 12,
+ .prio_mask = 4,
+ },
+ [45] = {
+ .pend = IPIC_SIPNR_H,
+ .mask = IPIC_SIMSR_H,
+ .prio = IPIC_SIPRR_B,
+ .force = IPIC_SIFCR_H,
+ .bit= 13,
+ .prio_mask = 5,
+ },
+ [46] = {
+ .pend = IPIC_SIPNR_H,
+ .mask = IPIC_SIMSR_H,
+ .prio = IPIC_SIPRR_B,
+ .force = IPIC_SIFCR_H,
+ .bit= 14,
+ .prio_mask = 6,
+ },
+ [47] = {
+ .pend = IPIC_SIPNR_H,
+ .mask = IPIC_SIMSR_H,
+ .prio = IPIC_SIPRR_B,
+ .force = IPIC_SIFCR_H,
+ .bit= 15,
+ .prio_mask = 7,
+ },
[48] = {
.pend = IPIC_SEPNR,
.mask = IPIC_SEMSR,
@@ -336,6 +416,20 @@ static struct ipic_info ipic_info[] = {
.force = IPIC_SIFCR_L,
.bit= 16,
},
+ [81] = {
+ .pend = IPIC_SIPNR_L,
+ .mask = IPIC_SIMSR_L,
+ .prio = 0,
+ .force = IPIC_SIFCR_L,
+ .bit= 17,
+ },
+ [82] = {
+ .pend = IPIC_SIPNR_L,
+ .mask = IPIC_SIMSR_L,
+ .prio = 0,
+ .force = IPIC_SIFCR_L,
+ .bit= 18,
+ },
[84] = {
.pend = IPIC_SIPNR_L,
.mask = IPIC_SIMSR_L,
@@ -350,6 +444,34 @@ static struct ipic_info ipic_info[] = {
.force = IPIC_SIFCR_L,
.bit= 21,
},
+ [86] = {
+ .pend = IPIC_SIPNR_L,
+ .mask = IPIC_SIMSR_L,
+ .prio = 0,
+ .force = IPIC_SIFCR_L,
+ .bit= 22,
+ },
+ [87] = {
+ .pend = IPIC_SIPNR_L,
+ .mask = IPIC_SIMSR_L,
+ .prio = 0,
+ .force = IPIC_SIFCR_L,
+ .bit= 23,
+ },
+ [88] = {
+ .pend = IPIC_SIPNR_L,
+ .mask = IPIC_SIMSR_L,
+
[PATCH v7 1/9] add e300c4 entry to cputable
Signed-off-by: Li Yang <[EMAIL PROTECTED]>
---
arch/powerpc/kernel/cputable.c | 13 -
1 files changed, 12 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/kernel/cputable.c b/arch/powerpc/kernel/cputable.c
index d3fb7d0..03b973f 100644
--- a/arch/powerpc/kernel/cputable.c
+++ b/arch/powerpc/kernel/cputable.c
@@ -888,7 +888,7 @@ static struct cpu_spec __initdata cpu_specs[] = {
.cpu_setup = __setup_cpu_603,
.platform = "ppc603",
},
- { /* e300c3 on 83xx */
+ { /* e300c3 (e300c1, plus one IU, half cache size) on 83xx */
.pvr_mask = 0x7fff,
.pvr_value = 0x0085,
.cpu_name = "e300c3",
@@ -899,6 +899,17 @@ static struct cpu_spec __initdata cpu_specs[] = {
.cpu_setup = __setup_cpu_603,
.platform = "ppc603",
},
+ { /* e300c4 (e300c1, plus one IU) */
+ .pvr_mask = 0x7fff,
+ .pvr_value = 0x0086,
+ .cpu_name = "e300c4",
+ .cpu_features = CPU_FTRS_E300,
+ .cpu_user_features = COMMON_USER,
+ .icache_bsize = 32,
+ .dcache_bsize = 32,
+ .cpu_setup = __setup_cpu_603,
+ .platform = "ppc603",
+ },
{ /* default match, we assume split I/D cache & TB (non-601)... */
.pvr_mask = 0x,
.pvr_value = 0x,
--
1.5.3.2.104.g41ef
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH v4] FEC - fast ethernet controller for mpc52xx
Driver for ethernet on mpc5200/mpc5200b SoCs (FEC).
Signed-off-by: Domen Puncer <[EMAIL PROTECTED]>
---
On 18/10/07 15:14 -0400, Jeff Garzik wrote:
>
> except a resend combining patches 3 and 4 as requested :)
OK, here it goes. Sorry for the delay.
diffstat:
drivers/net/Kconfig | 24
drivers/net/Makefile |4
drivers/net/fec_mpc52xx.c | 1107 ++
drivers/net/fec_mpc52xx.h | 315 +++
drivers/net/fec_mpc52xx_phy.c | 198 +++
5 files changed, 1648 insertions(+)
Index: linux.git/drivers/net/Kconfig
===
--- linux.git.orig/drivers/net/Kconfig
+++ linux.git/drivers/net/Kconfig
@@ -1895,6 +1895,30 @@ config FEC2
Say Y here if you want to use the second built-in 10/100 Fast
ethernet controller on some Motorola ColdFire processors.
+config FEC_MPC52xx
+ tristate "MPC52xx FEC driver"
+ depends on PPC_MPC52xx
+ select PPC_BESTCOMM
+ select PPC_BESTCOMM_FEC
+ select CRC32
+ select PHYLIB
+ ---help---
+ This option enables support for the MPC5200's on-chip
+ Fast Ethernet Controller
+ If compiled as module, it will be called 'fec_mpc52xx.ko'.
+
+config FEC_MPC52xx_MDIO
+ bool "MPC52xx FEC MDIO bus driver"
+ depends on FEC_MPC52xx
+ default y
+ ---help---
+ The MPC5200's FEC can connect to the Ethernet either with
+ an external MII PHY chip or 10 Mbps 7-wire interface
+ (Motorola? industry standard).
+ If your board uses an external PHY connected to FEC, enable this.
+ If not sure, enable.
+ If compiled as module, it will be called 'fec_mpc52xx_phy.ko'.
+
config NE_H8300
tristate "NE2000 compatible support for H8/300"
depends on H8300
Index: linux.git/drivers/net/Makefile
===
--- linux.git.orig/drivers/net/Makefile
+++ linux.git/drivers/net/Makefile
@@ -96,6 +96,10 @@ obj-$(CONFIG_SHAPER) += shaper.o
obj-$(CONFIG_HP100) += hp100.o
obj-$(CONFIG_SMC9194) += smc9194.o
obj-$(CONFIG_FEC) += fec.o
+obj-$(CONFIG_FEC_MPC52xx) += fec_mpc52xx.o
+ifeq ($(CONFIG_FEC_MPC52xx_MDIO),y)
+ obj-$(CONFIG_FEC_MPC52xx) += fec_mpc52xx_phy.o
+endif
obj-$(CONFIG_68360_ENET) += 68360enet.o
obj-$(CONFIG_WD80x3) += wd.o 8390.o
obj-$(CONFIG_EL2) += 3c503.o 8390.o
Index: linux.git/drivers/net/fec_mpc52xx.c
===
--- /dev/null
+++ linux.git/drivers/net/fec_mpc52xx.c
@@ -0,0 +1,1107 @@
+/*
+ * Driver for the MPC5200 Fast Ethernet Controller
+ *
+ * Originally written by Dale Farnsworth <[EMAIL PROTECTED]> and
+ * now maintained by Sylvain Munaut <[EMAIL PROTECTED]>
+ *
+ * Copyright (C) 2007 Domen Puncer, Telargo, Inc.
+ * Copyright (C) 2007 Sylvain Munaut <[EMAIL PROTECTED]>
+ * Copyright (C) 2003-2004 MontaVista, Software, Inc.
+ *
+ * This file is licensed under the terms of the GNU General Public License
+ * version 2. This program is licensed "as is" without any warranty of any
+ * kind, whether express or implied.
+ *
+ */
+
+#include
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+
+#include
+#include
+
+#include "fec_mpc52xx.h"
+
+#define DRIVER_NAME "mpc52xx-fec"
+
+static irqreturn_t mpc52xx_fec_interrupt(int, void *);
+static irqreturn_t mpc52xx_fec_rx_interrupt(int, void *);
+static irqreturn_t mpc52xx_fec_tx_interrupt(int, void *);
+static void mpc52xx_fec_stop(struct net_device *dev);
+static void mpc52xx_fec_start(struct net_device *dev);
+static void mpc52xx_fec_reset(struct net_device *dev);
+
+static u8 mpc52xx_fec_mac_addr[6];
+module_param_array_named(mac, mpc52xx_fec_mac_addr, byte, NULL, 0);
+MODULE_PARM_DESC(mac, "six hex digits, ie. 0x1,0x2,0xc0,0x01,0xba,0xbe");
+
+static void mpc52xx_fec_tx_timeout(struct net_device *dev)
+{
+ struct mpc52xx_fec_priv *priv = netdev_priv(dev);
+
+ dev_warn(&dev->dev, "transmit timed out\n");
+
+ mpc52xx_fec_reset(dev);
+
+ priv->stats.tx_errors++;
+
+ if (!priv->tx_full)
+ netif_wake_queue(dev);
+}
+
+static void mpc52xx_fec_set_paddr(struct net_device *dev, u8 *mac)
+{
+ struct mpc52xx_fec_priv *priv = netdev_priv(dev);
+ struct mpc52xx_fec __iomem *fec = priv->fec;
+
+ out_be32(&fec->paddr1, *(u32 *)(&mac[0]));
+ out_be32(&fec->paddr2, (*(u16 *)(&mac[4]) << 16) | FEC_PADDR2_TYPE);
+}
+
+static void mpc52xx_fec_get_paddr(struct net_device *dev, u8 *mac)
+{
+ struct mpc52xx_fec_priv *priv = netdev_priv(dev);
+ struct mpc52xx_fec __iomem *fec = priv->fec;
+
+ *(u32 *)(&mac[0]) = in_be32(&fec->paddr1);
+ *(u16 *)(&mac[4]) = in_be32(&fec->paddr2) >> 16;
+}
+
+static int mpc52xx_fec_set_mac_a
RE: [PATCH] qe_lib: export symbols to fix compile error when QE drivers compile as modules
> -Original Message- > From: Kumar Gala [mailto:[EMAIL PROTECTED] > Sent: Wednesday, October 17, 2007 11:30 PM > To: Li Yang-r58472 > Cc: linuxppc-dev list; Tabi Timur-B04825 > Subject: Re: [PATCH] qe_lib: export symbols to fix compile > error when QE drivers compile as modules > > > On May 25, 2007, at 7:15 AM, Kumar Gala wrote: > > > > > On May 24, 2007, at 9:45 PM, Li Yang-r58472 wrote: > > > >> > >>> -Original Message- > >>> From: Kumar Gala [mailto:[EMAIL PROTECTED] > >>> Sent: Thursday, May 24, 2007 7:44 PM > >>> To: Li Yang-r58472 > >>> Cc: Paul; linuxppc-dev@ozlabs.org > >>> Subject: Re: [PATCH] qe_lib: export symbols to fix compile error > >>> when > >> QE drivers > >>> compile as modules > >>> > >>> > >>> On May 24, 2007, at 4:14 AM, Li Yang wrote: > >>> > Export symbols of qe_lib to be used by QE drivers. > > Signed-off-by: Li Yang <[EMAIL PROTECTED]> > --- > arch/powerpc/sysdev/qe_lib/ucc.c |7 +++ > arch/powerpc/sysdev/qe_lib/ucc_fast.c |8 > arch/powerpc/sysdev/qe_lib/ucc_slow.c | 12 ++-- > 3 files changed, 25 insertions(+), 2 deletions(-) > >>> > > What happened with this? This has been merged as commit 65482ccf9d00bf4f68e17eb9c656d045d26e5d1f. - Leo ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] NULL terminate the pci_device_ids in pasemi_edac
On Fri, 2007-10-19 at 01:47 -0500, Olof Johansson wrote: > On Fri, Oct 19, 2007 at 03:07:22PM +1000, Stephen Rothwell wrote: > > Fixes: > > drivers/edac/pasemi_edac: struct pci_device_id is 32 bytes. The last of 1 > > is: > > 0x00 0x00 0x19 0x59 0x00 0x00 0xa0 0x0a 0xff 0xff 0xff 0xff 0xff 0xff 0xff > > 0xff > > 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 > > 0x00 > > FATAL: drivers/edac/pasemi_edac: struct pci_device_id is not terminated > > with a NULL entry! > > > > Signed-off-by: Stephen Rothwell <[EMAIL PROTECTED]> > > Acked-by: Olof Johansson <[EMAIL PROTECTED]> > > Thanks for fixing this, Stephen. ID lists without termination can really > cause weird problems at the most random times since it depends on how > the kernel is built whether they do any (immediate) harm or not. Kind of makes you wonder if some macro foo to automatically append the NULL entry wouldn't be a good idea. cheers -- Michael Ellerman OzLabs, IBM Australia Development Lab wwweb: http://michael.ellerman.id.au phone: +61 2 6212 1183 (tie line 70 21183) We do not inherit the earth from our ancestors, we borrow it from our children. - S.M.A.R.T Person signature.asc Description: This is a digitally signed message part ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [NET]: Fix possible dev_deactivate race condition
On Fri, 2007-10-19 at 13:36 +0800, Herbert Xu wrote:
> On Fri, Oct 19, 2007 at 12:20:25PM +0800, Herbert Xu wrote:
> >
> > In fact this bug exists elsewhere too. For example, the network
> > stack does this in net/sched/sch_generic.c:
> >
> > /* Wait for outstanding qdisc_run calls. */
> > while (test_bit(__LINK_STATE_QDISC_RUNNING, &dev->state))
> > yield();
> >
> > This has the same problem as the current synchronize_irq code.
>
> diff --git a/net/sched/sch_generic.c b/net/sched/sch_generic.c
> index e01d576..b3b7420 100644
> --- a/net/sched/sch_generic.c
> +++ b/net/sched/sch_generic.c
> @@ -556,6 +556,7 @@ void dev_deactivate(struct net_device *dev)
> {
> struct Qdisc *qdisc;
> struct sk_buff *skb;
> + int running;
>
> spin_lock_bh(&dev->queue_lock);
> qdisc = dev->qdisc;
> @@ -571,12 +572,31 @@ void dev_deactivate(struct net_device *dev)
>
> dev_watchdog_down(dev);
>
> - /* Wait for outstanding dev_queue_xmit calls. */
> + /* Wait for outstanding qdisc-less dev_queue_xmit calls. */
> synchronize_rcu();
>
> /* Wait for outstanding qdisc_run calls. */
> - while (test_bit(__LINK_STATE_QDISC_RUNNING, &dev->state))
> - yield();
> + do {
> + while (test_bit(__LINK_STATE_QDISC_RUNNING, &dev->state))
> + yield();
> +
Ouch!, is there really no sane locking alternative? Hashed waitqueues
like for the page lock come to mind.
> + /*
> +* Double-check inside queue lock to ensure that all effects
> +* of the queue run are visible when we return.
> +*/
> + spin_lock_bh(&dev->queue_lock);
> + running = test_bit(__LINK_STATE_QDISC_RUNNING, &dev->state);
> + spin_unlock_bh(&dev->queue_lock);
> +
> + /*
> +* The running flag should never be set at this point because
> +* we've already set dev->qdisc to noop_qdisc *inside* the
> same
> +* pair of spin locks. That is, if any qdisc_run starts after
> +* our initial test it should see the noop_qdisc and then
> +* clear the RUNNING bit before dropping the queue lock. So
> +* if it is set here then we've found a bug.
> +*/
> + } while (WARN_ON_ONCE(running));
> }
>
> void dev_init_scheduler(struct net_device *dev)
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] powerpc: mpic: minor optimization of ipi handler
Jeff Garzik pointed out that we don't actually have to lookup the mpic
instance since it's passed in as the interrupt handler data for IPIs.
Signed-off-by: Olof Johansson <[EMAIL PROTECTED]>
diff --git a/arch/powerpc/sysdev/mpic.c b/arch/powerpc/sysdev/mpic.c
index e479388..6bf56f4 100644
--- a/arch/powerpc/sysdev/mpic.c
+++ b/arch/powerpc/sysdev/mpic.c
@@ -612,11 +612,10 @@ static inline void mpic_eoi(struct mpic *mpic)
}
#ifdef CONFIG_SMP
-static irqreturn_t mpic_ipi_action(int irq, void *dev_id)
+static irqreturn_t mpic_ipi_action(int irq, void *data)
{
- struct mpic *mpic;
+ struct mpic *mpic = data;
- mpic = mpic_find(irq, NULL);
smp_message_recv(mpic_irq_to_hw(irq) - mpic->ipi_vecs[0]);
return IRQ_HANDLED;
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
embedded a default dtb in the kernel (was merge dtc)
Is there a way to embed a default dtb into the kernel? When I build a kernel, I want to embed a dtb into it -- so I don't have to deal with the headaches of finding the right file to match the right board (its always easier to deal with 1 file than 2). If there is, it makes sense to put dtc into the tree. If there's not, there should be a way to embed dtb's; and put dtc and dts's into the tree. If there can't be (I haven't examined this but relaying my experiences), then it should be in a separate repository (but the DTS and DTC should be in one place). It was a little difficult to cobble together a working system the first time. Also, mkimage SHOULD definitely go in the tree. Its necessary to build, hence should be in the tree... There are cases where one kernel can support multiple boards/DTBs. I guess boot flags can control whether to use an embedded DTB or one passed from uboot... marty ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 2/4] DTC: Quiet a bogus "May be used uninitialized" warning.
Signed-off-by: Jon Loeliger <[EMAIL PROTECTED]>
---
flattree.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/flattree.c b/flattree.c
index a26e71b..5889900 100644
--- a/flattree.c
+++ b/flattree.c
@@ -136,7 +136,7 @@ static void asm_emit_cell(void *e, cell_t val)
static void asm_emit_string(void *e, char *str, int len)
{
FILE *f = e;
- char c;
+ char c = 0;
if (len != 0) {
/* XXX: ewww */
--
1.5.3.1.139.g9346b
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: powerpc 440 monitor program
On Fri, Oct 19, 2007 at 11:32:33AM +0800, Bai Shuwei wrote: > all, > hi, when I boot my system, there are no output on the screen. > I choice the framebuffer and my monitor card is ATI PAGE 128 PCI, qt/e GUI. > When i compile the kernel, the boot logo and aty 128fb has be compiled into > kernel patched with videoboot, and x86emu. The video parameters set: > video=aty128fb:[EMAIL PROTECTED] > The kenel can recognize the monitor card, and the frame buffer device > has run. > The output showed below: > > videoboot: Booting PCI video card bus 0, function 0, device 6 >aty128fb: Found Intel x86 BIOS ROM Image >aty128fb: Rage128 BIOS located >aty128fb: Rage128 RK PCI [chip rev 0x2] 32M 64-bit SDR SGRAM (2:1) >fb0: ATY Rage128 frame buffer device on Rage128 RK PCI > > My problem is there is no output on the monitor,and cannot see the penguin > boot logo. > I also run a program to test the framebuffer, which can read data from the > fb. After running the qt/e program, which can run scussessfully, there is no > output.! Hi, Lots of graphics cards need their on-board BIOS to be executed to setup the card before it can be used by linux or anything else. Some firmwares have x86 emulation built-in to do this (CFE has it, SLOF might, U-boot has it for some platforms but I don't know about 4xx). -Olof ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] ppc44x: support for 256K PAGE_SIZE
On Friday 19 October 2007 03:21, Paul Mackerras wrote: > Have you measured the performance using a 64kB page size? If so, how > does it compare with the 256kB page size? I measured the performance of the sequential full-stripe write operations to a RAID-5 array (P values below are in MB per second) using the h/w accelerated RAID-5 driver. Here are the comparative results for the different PAGE_SIZE values: PAGE_SIZE = 4K: P = 66 MBps; PAGE_SIZE = 16K: P = 145 MBps; PAGE_SIZE = 64K: P = 196 MBps; PAGE_SIZE = 256K: P = 217 MBps. > The 64kB page size has the attraction that no binutils changes are > required. That's true, but the additional performance is an attractive thing too. > > Paul. > -- Yuri Tikhonov, Senior Software Engineer Emcraft Systems, www.emcraft.com ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] [POWERPC] ucc_geth: Eliminate compile warnings
Emil Medve wrote: > drivers/net/ucc_geth.c: In function 'ucc_geth_startup': > drivers/net/ucc_geth.c:2614: warning: assignment makes integer from pointer > without a cast > drivers/net/ucc_geth.c:2651: warning: assignment makes integer from pointer > without a cast > > Signed-off-by: Emil Medve <[EMAIL PROTECTED]> Acked-by: Timur Tabi <[EMAIL PROTECTED]> ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[patch 1/4] 4xx: Enable EMAC on the PPC 440GP Ebony board
Update the Ebony defconfig to enable the ibm_newemac driver. Signed-off-by: Josh Boyer <[EMAIL PROTECTED]> --- arch/powerpc/configs/ebony_defconfig | 115 +-- 1 file changed, 70 insertions(+), 45 deletions(-) --- linux-2.6.orig/arch/powerpc/configs/ebony_defconfig +++ linux-2.6/arch/powerpc/configs/ebony_defconfig @@ -1,7 +1,7 @@ # # Automatically generated make config: don't edit -# Linux kernel version: 2.6.23-rc4 -# Thu Aug 30 16:34:11 2007 +# Linux kernel version: 2.6.23 +# Thu Oct 18 08:01:57 2007 # # CONFIG_PPC64 is not set @@ -21,8 +21,13 @@ CONFIG_PHYS_64BIT=y # CONFIG_PPC_MM_SLICES is not set CONFIG_NOT_COHERENT_CACHE=y CONFIG_PPC32=y +CONFIG_WORD_SIZE=32 CONFIG_PPC_MERGE=y CONFIG_MMU=y +CONFIG_GENERIC_CMOS_UPDATE=y +CONFIG_GENERIC_TIME=y +CONFIG_GENERIC_TIME_VSYSCALL=y +CONFIG_GENERIC_CLOCKEVENTS=y CONFIG_GENERIC_HARDIRQS=y CONFIG_IRQ_PER_CPU=y CONFIG_RWSEM_XCHGADD_ALGORITHM=y @@ -66,6 +71,8 @@ CONFIG_POSIX_MQUEUE=y # CONFIG_AUDIT is not set # CONFIG_IKCONFIG is not set CONFIG_LOG_BUF_SHIFT=14 +CONFIG_FAIR_GROUP_SCHED=y +CONFIG_FAIR_USER_SCHED=y CONFIG_SYSFS_DEPRECATED=y # CONFIG_RELAY is not set CONFIG_BLK_DEV_INITRD=y @@ -86,7 +93,6 @@ CONFIG_FUTEX=y CONFIG_ANON_INODES=y CONFIG_EPOLL=y CONFIG_SIGNALFD=y -CONFIG_TIMERFD=y CONFIG_EVENTFD=y CONFIG_SHMEM=y CONFIG_VM_EVENT_COUNTERS=y @@ -130,7 +136,9 @@ CONFIG_DEFAULT_IOSCHED="anticipatory" # CONFIG_PPC_CELL is not set # CONFIG_PPC_CELL_NATIVE is not set # CONFIG_PQ2ADS is not set +# CONFIG_BAMBOO is not set CONFIG_EBONY=y +# CONFIG_SEQUOIA is not set CONFIG_440GP=y # CONFIG_MPIC is not set # CONFIG_MPIC_WEIRD is not set @@ -149,6 +157,10 @@ CONFIG_440GP=y # Kernel options # # CONFIG_HIGHMEM is not set +# CONFIG_TICK_ONESHOT is not set +# CONFIG_NO_HZ is not set +# CONFIG_HIGH_RES_TIMERS is not set +CONFIG_GENERIC_CLOCKEVENTS_BUILD=y # CONFIG_HZ_100 is not set CONFIG_HZ_250=y # CONFIG_HZ_300 is not set @@ -170,6 +182,7 @@ CONFIG_FLATMEM_MANUAL=y CONFIG_FLATMEM=y CONFIG_FLAT_NODE_MEM_MAP=y # CONFIG_SPARSEMEM_STATIC is not set +# CONFIG_SPARSEMEM_VMEMMAP_ENABLE is not set CONFIG_SPLIT_PTLOCK_CPUS=4 CONFIG_RESOURCES_64BIT=y CONFIG_ZONE_DMA_FLAG=1 @@ -194,10 +207,6 @@ CONFIG_PCI_SYSCALL=y CONFIG_ARCH_SUPPORTS_MSI=y # CONFIG_PCI_MSI is not set # CONFIG_PCI_DEBUG is not set - -# -# PCCARD (PCMCIA/CardBus) support -# # CONFIG_PCCARD is not set # CONFIG_HOTPLUG_PCI is not set @@ -212,7 +221,7 @@ CONFIG_ARCH_SUPPORTS_MSI=y CONFIG_HIGHMEM_START=0xfe00 CONFIG_LOWMEM_SIZE=0x3000 CONFIG_KERNEL_START=0xc000 -CONFIG_TASK_SIZE=0x8000 +CONFIG_TASK_SIZE=0xc000 CONFIG_CONSISTENT_START=0xff10 CONFIG_CONSISTENT_SIZE=0x0020 CONFIG_BOOT_LOAD=0x0100 @@ -249,6 +258,7 @@ CONFIG_IP_PNP_BOOTP=y # CONFIG_INET_XFRM_MODE_TRANSPORT is not set # CONFIG_INET_XFRM_MODE_TUNNEL is not set # CONFIG_INET_XFRM_MODE_BEET is not set +# CONFIG_INET_LRO is not set CONFIG_INET_DIAG=y CONFIG_INET_TCP_DIAG=y # CONFIG_TCP_CONG_ADVANCED is not set @@ -306,6 +316,7 @@ CONFIG_DEFAULT_TCP_CONG="cubic" # # Generic Driver Options # +CONFIG_UEVENT_HELPER_PATH="/sbin/hotplug" CONFIG_STANDALONE=y CONFIG_PREVENT_FIRMWARE_BUILD=y CONFIG_FW_LOADER=y @@ -332,6 +343,7 @@ CONFIG_MTD_BLOCK=y # CONFIG_INFTL is not set # CONFIG_RFD_FTL is not set # CONFIG_SSFDC is not set +# CONFIG_MTD_OOPS is not set # # RAM/ROM/Flash chip drivers @@ -364,6 +376,7 @@ CONFIG_MTD_CFI_UTIL=y # CONFIG_MTD_COMPLEX_MAPPINGS is not set # CONFIG_MTD_PHYSMAP is not set CONFIG_MTD_PHYSMAP_OF=y +# CONFIG_MTD_INTEL_VR_NOR is not set # CONFIG_MTD_PLATRAM is not set # @@ -423,10 +436,6 @@ CONFIG_MISC_DEVICES=y # CONFIG_SCSI_NETLINK is not set # CONFIG_ATA is not set # CONFIG_MD is not set - -# -# Fusion MPT device support -# # CONFIG_FUSION is not set # @@ -443,12 +452,36 @@ CONFIG_NETDEVICES=y # CONFIG_MACVLAN is not set # CONFIG_EQUALIZER is not set # CONFIG_TUN is not set +# CONFIG_VETH is not set +# CONFIG_IP1000 is not set # CONFIG_ARCNET is not set -# CONFIG_NET_ETHERNET is not set +# CONFIG_PHYLIB is not set +CONFIG_NET_ETHERNET=y +# CONFIG_MII is not set +# CONFIG_HAPPYMEAL is not set +# CONFIG_SUNGEM is not set +# CONFIG_CASSINI is not set +# CONFIG_NET_VENDOR_3COM is not set +# CONFIG_NET_TULIP is not set +# CONFIG_HP100 is not set +CONFIG_IBM_NEW_EMAC=y +CONFIG_IBM_NEW_EMAC_RXB=128 +CONFIG_IBM_NEW_EMAC_TXB=64 +CONFIG_IBM_NEW_EMAC_POLL_WEIGHT=32 +CONFIG_IBM_NEW_EMAC_RX_COPY_THRESHOLD=256 +CONFIG_IBM_NEW_EMAC_RX_SKB_HEADROOM=0 +# CONFIG_IBM_NEW_EMAC_DEBUG is not set +CONFIG_IBM_NEW_EMAC_ZMII=y +# CONFIG_IBM_NEW_EMAC_RGMII is not set +# CONFIG_IBM_NEW_EMAC_TAH is not set +# CONFIG_IBM_NEW_EMAC_EMAC4 is not set +# CONFIG_NET_PCI is not set +# CONFIG_B44 is not set CONFIG_NETDEV_1000=y # CONFIG_ACENIC is not set # CONFIG_DL2K is not set # CONFIG_E1000 is not set +# CONFIG_E1000E is not set # CONFIG_NS83820 is not set # CONFIG_HAMACHI is not set # CONFIG_YELLOWFIN is not
Re: [PATCH v3 2/2] [POWERPC] MPC8568E-MDS: add support for flash
On Oct 18, 2007, at 5:29 PM, Anton Vorontsov wrote:
> On Thu, Oct 18, 2007 at 02:58:25PM -0500, Kumar Gala wrote:
> [...]
>>> +
>>> + [EMAIL PROTECTED],0 {
>>> + #address-cells = <1>;
>>> + #size-cells = <1>;
>>> + compatible = "Spansion,S29GL256N11TFIV2O", "cfi-flash";
>>> + reg = <0 0 200>;
>>> + bank-width = <2>;
>>> + device-width = <1>;
>>> +
>>
>> Are you basing the partition map on something or making it up?
>> Clearly hrcw & u-boot are at fixed offsets, wondering about kernel &
>> rootfs?
>
> I'm making it up. From the brief look at the u-boot* git sources,
> there is no `flashboot` yet, thus I'm free to make this up...
>
> I've partitioned this flash based on these thoughts:
>
> 1. HRCW - whole sector, to not wear out it, plus it's impossible to
>create just 64 bytes partition;
this makes sense.
> 2. Kernel - 2MB, should be enough for bootup kernels?
seems reasonable.
> 3. Rootfs - the rest up to...
do we need a small section for the device tree?
> 4. U-Boot at the end.
can we reorder partitions? not sure if there is any value in having
the things we know will always be there like hrcw & u-boot at fixed
mtd0, mtd1, etc.
>
> I'm not saying that it's best map ever, I'm open to suggestions. ;-)
>
> * Unfortunately I didn't look at the stock Freescale u-boot, maybe
> there was flashboot, most probably.. I'll find the CD to look this
> up.
Yeah I have no idea what we ship w/regards to the BSPs.
- k
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH v6 4/9] add platform support for MPC837x MDS board
On Oct 18, 2007, at 7:43 PM, Stephen Rothwell wrote:
> On Thu, 18 Oct 2007 23:04:02 +0800 Li Yang <[EMAIL PROTECTED]>
> wrote:
>>
>> +++ b/arch/powerpc/platforms/83xx/mpc837x_mds.c
>> +static void __init mpc837x_mds_setup_arch(void)
>> +{
>> +#ifdef CONFIG_PCI
>> +struct device_node *np;
>> +#endif
>> +
>> +if (ppc_md.progress)
>> +ppc_md.progress("mpc837x_mds_setup_arch()", 0);
>> +
>> +#ifdef CONFIG_PCI
>> +for (np = NULL; (np = of_find_node_by_type(np, "pci")) != NULL;)
>
> for_each_node_by_type(np, "pci")
>
>> +static int __init mpc837x_mds_probe(void)
>> +{
>> +unsigned long root = of_get_flat_dt_root();
>> +
>> +return of_flat_dt_is_compatible(root, "fsl,mpc837xmds");
>
> To call these two routines, you should include directly.
what's the rule of thumb to know when to include does
everything starting with of_flat_* come from there?
- k
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] qe_lib: export symbols to fix compile error when QE drivers compile as modules
>> Export symbols of qe_lib to be used by QE drivers. >> >> Signed-off-by: Li Yang <[EMAIL PROTECTED]> >> --- >> arch/powerpc/sysdev/qe_lib/ucc.c |7 +++ >> arch/powerpc/sysdev/qe_lib/ucc_fast.c |8 >> arch/powerpc/sysdev/qe_lib/ucc_slow.c | 12 ++-- >> 3 files changed, 25 insertions(+), 2 deletions(-) > >> >> What happened with this? > > This has been merged as commit > 65482ccf9d00bf4f68e17eb9c656d045d26e5d1f. Ignore me I see the commit. Timur will just need to EXPORT_SYMBOL() what additional functions he needs for the uart driver. - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH v2 3/4] Implement clockevents driver for powerpc
Sergei Shtylyov writes: > The xtime_lock is still grabbed by time_init() That was left in there because we are setting sys_tz and do_gtod, and do_gtod at least is only updated with the xtime_lock held. Of course, at that early stage in the boot process, no lock is really needed, but xtime_lock was taken for consistency with other code. In fact there's quite a lot of stuff in there that could be removed now. I also want to make the vdso use an algorithm more like what getnstimeofday does. > The only thing I'm still unusre about is that deterministic accounting. > Could you point me at the patch which deals with this (at least for System > 390 See efe567fc8281661524ffa75477a7c4ca9b466c63 in Linus' tree, and look for posts to lkml by Christian Borntraeger, who has been pursuing the issue (subject "Re: [stable] 2.6.23 regression: top displaying % CPU usage"). Paul. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 2/2] i2c: Add devtree-aware iic support for PPC4xx
Please, take a look at my comments below
Stefan Roese wrote:
> This patch reworks existing ibm-iic driver to support of_platform_device
> and enables it to talk to device tree directly. The "old" OCP interface
> for arch/ppc is still supported via #ifdef's and shall be removed when
> arch/ppc is gone in a few months.
>
> This is done to enable I2C support for the PPC4xx platforms now
> being moved from arch/ppc (ocp) to arch/powerpc (of).
>
> Signed-off-by: Stefan Roese <[EMAIL PROTECTED]>
> ---
> drivers/i2c/busses/Kconfig |2 +-
> drivers/i2c/busses/i2c-ibm_iic.c | 209
> +-
> drivers/i2c/busses/i2c-ibm_iic.h |2 +
> 3 files changed, 211 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig
> index de95c75..a47b5e6 100644
> --- a/drivers/i2c/busses/Kconfig
> +++ b/drivers/i2c/busses/Kconfig
> @@ -241,7 +241,7 @@ config I2C_PIIX4
>
> config I2C_IBM_IIC
> tristate "IBM PPC 4xx on-chip I2C interface"
> - depends on IBM_OCP
> + depends on 4xx
> help
> Say Y here if you want to use IIC peripheral found on
> embedded IBM PPC 4xx based systems.
> diff --git a/drivers/i2c/busses/i2c-ibm_iic.c
> b/drivers/i2c/busses/i2c-ibm_iic.c
> index 956b947..78c6bf4 100644
> --- a/drivers/i2c/busses/i2c-ibm_iic.c
> +++ b/drivers/i2c/busses/i2c-ibm_iic.c
> @@ -39,8 +39,13 @@
> #include
> #include
> #include
> +
> +#ifdef CONFIG_PPC_MERGE
> +#include
> +#else
> #include
> #include
> +#endif
>
> #include "i2c-ibm_iic.h"
>
> @@ -57,6 +62,10 @@ static int iic_force_fast;
> module_param(iic_force_fast, bool, 0);
> MODULE_PARM_DESC(iic_fast_poll, "Force fast mode (400 kHz)");
>
> +#ifdef CONFIG_PPC_MERGE
> +static int device_idx = -1;
> +#endif
> +
> #define DBG_LEVEL 0
>
> #ifdef DBG
> @@ -660,8 +669,205 @@ static inline u8 iic_clckdiv(unsigned int opb)
> /*
> * Register single IIC interface
> */
> -static int __devinit iic_probe(struct ocp_device *ocp){
>
> +#ifdef CONFIG_PPC_MERGE
> +/*
> + * device-tree (of) when used from arch/powerpc
> + */
> +static int __devinit iic_probe(struct of_device *ofdev,
> +const struct of_device_id *match)
> +{
> + struct ibm_iic_private* dev;
> + struct i2c_adapter* adap;
> + struct device_node *np;
> + int ret = -ENODEV;
> + int irq, len;
> + const u32 *prop;
> + struct resource res;
> +
> + np = ofdev->node;
> + if (!(dev = kzalloc(sizeof(*dev), GFP_KERNEL))) {
> + printk(KERN_CRIT "ibm-iic(%s): failed to allocate device
> data\n",
> +np->full_name);
> + return -ENOMEM;
> + }
> +
> + dev_set_drvdata(&ofdev->dev, dev);
> +
> + dev->np = np;
> + irq = irq_of_parse_and_map(np, 0);
In case of an error irq might be NO_IRQ here (0)
This could cause problems in chacking the mode (irq or poll) later.
> +
> + if (of_address_to_resource(np, 0, &res)) {
> + printk(KERN_ERR "ibd-iic(%s): Can't get registers address\n",
> +np->full_name);
> + goto fail1;
> + }
> + dev->paddr = res.start;
> +
> + if (!request_mem_region(dev->paddr, sizeof(struct iic_regs),
> "ibm_iic")) {
> + ret = -EBUSY;
> + goto fail1;
> + }
> + dev->vaddr = ioremap(dev->paddr, sizeof(struct iic_regs));
> +
> + if (dev->vaddr == NULL) {
> + printk(KERN_CRIT "ibm-iic(%s): failed to ioremap device regs\n",
> +dev->np->full_name);
> + ret = -ENXIO;
> + goto fail2;
> + }
> +
> + init_waitqueue_head(&dev->wq);
> +
> + dev->irq = iic_force_poll ? -1 : (irq == NO_IRQ) ? -1 : irq;
> + if (dev->irq >= 0){
If irq equals NO_IRQ (irq == 0) we shouldn't assume interrupt mode here.
I'd suggest to update the driver to use (irq != NO_IRQ) checks instead
of (irq >=0)
> + /* Disable interrupts until we finish initialization,
> + * assumes level-sensitive IRQ setup...
> + */
> + iic_interrupt_mode(dev, 0);
> + if (request_irq(dev->irq, iic_handler, 0, "IBM IIC", dev)) {
> + printk(KERN_ERR "ibm-iic(%s): request_irq %d failed\n",
> +dev->np->full_name, dev->irq);
> + /* Fallback to the polling mode */
> + dev->irq = -1;
> + }
> + }
> +
> + if (dev->irq < 0)
> + printk(KERN_WARNING "ibm-iic(%s): using polling mode\n",
> +dev->np->full_name);
> +
> + /* Board specific settings */
> + prop = of_get_property(np, "iic-mode", &len);
> + /* use 400kHz only if stated in dts, 100kHz otherwise */
> + dev->fast_mode = (prop && (*prop == 400));
> + /* clckdiv is the same for *all* IIC interfaces,
> + * but I'd rather make a copy than introduce another global. --ebs
> + */
Re: [PATCH v2 3/4] Implement clockevents driver for powerpc
Hello. Paul Mackerras wrote: >>>What problem do you see arising from this? >>Timers firing too early. > Only if the minimum interrupt latency is less than 1 decrementer > tick. That seems pretty unlikely to me unless you have a very slow > timebase frequency. Well, MPC8540 has 825 MHz CPU clock yet decrementor/timebase are clocked with 25 MHz clock if I don't mistake. That gives us 33 CPU clocks of available interrupt latency... > In fact what we should program the decrementer to is: > timeout - (is_booke? 0: 1) - min_interrupt_latency BTW, why not handle the decrementer difference right in set_dec() where we already have #ifdef'ed code? > I was assuming that min_interrupt_latency (measured in timebase ticks) > would be at least 1, but apparently some systems can have a timebase > frequency as low as 1kHz, so we'll have to have an ifdef or something. IMHO it's better to have #ifdef based on the decremeter model and forget about the whole issue, rather than to #ifdef based on some bizarre system with slowish decremeter, isn't it? > Paul. WBR, Sergei ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH v7 5/9] add documentation for SATA nodes
Signed-off-by: Li Yang <[EMAIL PROTECTED]>
---
Documentation/powerpc/booting-without-of.txt | 32 ++
1 files changed, 32 insertions(+), 0 deletions(-)
diff --git a/Documentation/powerpc/booting-without-of.txt
b/Documentation/powerpc/booting-without-of.txt
index a96e853..8d49942 100644
--- a/Documentation/powerpc/booting-without-of.txt
+++ b/Documentation/powerpc/booting-without-of.txt
@@ -2242,6 +2242,38 @@ platforms are moved over to use the
flattened-device-tree model.
available.
For Axon: 0x012a
+o) SATA nodes
+
+SATA nodes are defined to describe on-chip Serial ATA controllers.
+
+Required properties:
+
+- compatible : Should specify what this SATA controller is compatible
+ with.
+- reg : Offset and length of the register set for the device.
+- interrupts : where a is the interrupt number and b is a
+ field that represents an encoding of the sense and level
+ information for the interrupt. This should be encoded based on
+ the information in section 2) depending on the type of interrupt
+ controller you have.
+- interrupt-parent : the phandle for the interrupt controller that
+ services interrupts for this device.
+
+Recommended properties :
+
+- phy-handle : Some SATA controller uses a shared SerDes PHY. This
+ property should specify the phandle of the SerDes node.
+
+ Example:
+
+ [EMAIL PROTECTED] {
+ compatible = "fsl,mpc8315-sata";
+ reg = <19000 1000>;
+ interrupts = <2d 8>;
+ interrupt-parent = < &ipic >;
+ phy-handle = < &serdes1 >;
+};
+
More devices will be defined as this spec matures.
VII - Specifying interrupt information for devices
--
1.5.3.2.104.g41ef
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH v7 0/9] Add MPC837x generic support and MPC837xE MDS support
Also includes a patch cleaning up IPIC, which could improve the performance. Hope this is the lucky version with the acceptable DTS's. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH v2 3/4] Implement clockevents driver for powerpc
On Fri, Oct 19, 2007 at 10:14:54AM +1000, Paul Mackerras wrote: > Sergei Shtylyov writes: > > > > What problem do you see arising from this? > > > > Timers firing too early. > > Only if the minimum interrupt latency is less than 1 decrementer > tick. That seems pretty unlikely to me unless you have a very slow > timebase frequency. > > In fact what we should program the decrementer to is: > > timeout - (is_booke? 0: 1) - min_interrupt_latency > > I was assuming that min_interrupt_latency (measured in timebase ticks) > would be at least 1, but apparently some systems can have a timebase > frequency as low as 1kHz, so we'll have to have an ifdef or something. If it is the case (the slowest I've seen was in the 8 MHz range), then it is better not to subtract the one: think of what happens when you have say, a 10kHz timebase/decrementer frequency and you want to interrupt after 1 ms. You actually want to interrupt after 11 transitions of the decrementer, not 10 since the result could be as low as 900us if you happen to read the timebase just before a transition. I'd really wish there were a guarantee of a minimum timebase frequency, for anything above ~10MHz, we are splitting hairs about an off-by-one error that never accumulates, but if systems with very low TB freq exist, you have to be very careful. In any case timer interrupts should never came earlier than asked for. Gabriel ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH v3] Device tree bindings for Xilinx devices
On 10/19/07, Stephen Neuendorffer <[EMAIL PROTECTED]> wrote:
>
> Here's a full .dts generated using an updated version of
> gen_mhs_devtree.py, following the proposal.
> It happens to be a microblaze system, but you get the idea.
>
> Grant: Is this pretty what you intend?
Pretty close; comments below on how we still need to change gen_mhs_devtree.py
BTW, thanks for doing this.
Cheers,
g.
>
> Steve
>
> / {
> #address-cells = <1>;
> #size-cells = <1>;
> compatible = "ibm,plb4";
Not quite; the bus itself needs to be one level deeper. Compatible
here is refering to the platform itself, not the bus and so should be
the actual board name or something similar. Maybe something like:
"xlnx,ml403","xlnx,generic-virtex4";
All devices should be children or grandchildren of a 'plb' node.
> model = "system.mhs";
Should be the model name of the board in the form ",". It
might be appropriate to also have a property which describes the
version of the FPGA build or some other way to identify where this
FPGA bitstream came from. I'll need to think about this some more.
> Ethernet_MAC {
> compatible =
> "xilinx,opb-ethernet-1.04.a\0xilinx,opb-ethernet";
Yes; this is the idea; but I don't like "xilinx,opb-ethernet". I
think we should always specify specific versions and not try to guess
what the 'generic' device compatible interface is.
Also, dtc now accepts the form "string1","string2". the embedded '\0'
is no longer needed.
> device_type = "opb_ethernet";
device_type = "network";
> interrupt-parent = <101>;
interrupt-parent = <&opb_intc0>; (and a label needs to be added to
the interrupt node).
> interrupts = < 1 0 >;
> reg = < 40c0 1 >;
> xilinx,cam-exist = <0>;
> xilinx,dev-blk-id = <0>;
> xilinx,dev-mir-enable = <0>;
> xilinx,dma-present = <1>;
> xilinx,include-dev-pencoder = <0>;
> xilinx,ipif-rdfifo-depth = <4000>;
> xilinx,ipif-wrfifo-depth = <4000>;
> xilinx,jumbo-exist = <0>;
> xilinx,mac-fifo-depth = <10>;
> xilinx,mii-exist = <1>;
> xilinx,opb-clk-period-ps = <2710>;
> xilinx,reset-present = <1>;
> xilinx,rx-dre-type = <0>;
> xilinx,rx-include-csum = <0>;
> xilinx,tx-dre-type = <0>;
> xilinx,tx-include-csum = <0>;
I got a comment from one of the ppc folks that we should use the stock
ticker abbreviation 'xlnx,' here instead of 'xilinx,'
> } ;
> IIC_EEPROM {
Node name needs to be unique. Convention is to use the form
[EMAIL PROTECTED] We could either use the instance name or the IP core
name here; I'm not sure which is best.
> compatible = "xilinx,opb-iic-1.02.a\0xilinx,opb-iic";
> device_type = "opb_iic";
device_type needs to be dropped from this node because i2c is not a
standard device type.
> interrupt-parent = <101>;
> interrupts = < 2 0 >;
> reg = < 4080 1 >;
> xilinx,clk-freq = <5f5e100>;
> xilinx,iic-freq = <186a0>;
> xilinx,ten-bit-adr = <0>;
i2c devices can optionally be listed as sub-nodes here; but of course
gen-mhs-devtree doesn't know about these.
> } ;
> RS232_Uart_1 {
> compatible =
> "xilinx,opb-uartlite-1.00.b\0xilinx,opb-uartlite";
> device_type = "opb_uartlite";
device_type = serial;
> interrupt-parent = <101>;
> interrupts = < 3 0 >;
> reg = < 4060 1 >;
> xilinx,baudrate = <2580>;
should be 'current-speed = <2580>' because this is standard device
type 'serial'.
> xilinx,clk-freq = <5f5e100>;
It might be better for this to be 'clock-frequency'; one of the
standard properties in serial devices
> xilinx,data-bits = <8>;
> xilinx,odd-parity = <0>;
> xilinx,use-parity = <0>;
> } ;
> chosen {
> bootargs = "root=/dev/xsysace/disc0/part2";
> interrupt-controller = <101>;
interrupt-controller doesn't belong here.
> linux,platform = <600>;
What's 'linux,platform' for?
> } ;
> cpus {
> #address-cells = <1>;
> #cpus = <1>;
I don't think this property is necessary.
> #size-cells = <0>;
> microblaze_0,6.00. {
> 32-bit;
> clock-frequency = <5f5e1000>;
dtc now accepts the form for decimal values; might be better
for readability here.
> d-cache-line-size = <10>;
> d-cache-size = <4000>;
> device_type = "cpu";
Re: Merge dtc
> Compared to the behemoth that is Kbuild... > > I'm happy to improve the Makefile integration, but you seem to be > rather vague on how, and the Kbuild documentation makes my brain hurt. I can make an ALL UPPERCASE VERSION if that makes it easier for you to read ;-) Give me a day or two then I shall give it a try and see what I can do about it. I will use the previsous posted URL as basis if you do not tell me otherwise. Sam ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] synchronize_irq needs a barrier
> I probably need to add this synchronize_irq() logic in dmfe.c too, but I > probably do it later, > I think I am overestimating this race, since most drivers don't do > dev->insuspend checks in IRQ handler. > Maybe even just use free_irq() after all Most drivers are probably underestimating the race :-) free_irq() would work provided that you did the masking on chip before (and unmask only after request_irq on the way back in). But it's a bit like using a 10 tons truck to crush an ant... Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [microblaze-uclinux] RE: [PATCH v3] Device tree bindings for Xilinx devices
On 10/19/07, Michal Simek <[EMAIL PROTECTED]> wrote: > Hi Steve and all, > >Here's a full .dts generated using an updated version of > >gen_mhs_devtree.py, following the proposal. > >It happens to be a microblaze system, but you get the idea. > > I think that is no good idea generate dts with all information. > Especially information about PVR - number 2 means - Full PVR and you can > obtain information directly from PVR. It is waste of memory space. > xilinx,pvr = <2>; > > In my opinion will be better generate only parameters which you want not all. > That smells with unusable parameters. That is the hard part about crafting the dts; deciding which parameters the OS is going to care about and which ones are irrelevant. The goal is to sufficiently and uniquely describe the board so that the OS can easily figure out what exactly what it needs to do to drive the board, but not to try and describe every aspect which it knows about. Anything that is pollable (ie. USB devices) doesn't need to be in the tree. It's also important to remember that the device tree will *never* be perfect. Eventually something will come up that the device tree doesn't describe well(a bug/quirk, something described poorly, etc). In this case, as long as the device tree is specific enough to identify which version of the board it is running on; we can alwasy add platform specific fixups for that unique system. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. [EMAIL PROTECTED] (403) 399-0195 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
