* Re: [PATCH POWERPC] i2c: adds support for i2c bus on Frescale CPM1/CPM2 controllers
From: Jochen Friedrich @ 2007-12-22 9:59 UTC (permalink / raw)
To: Vitaly Bordug; +Cc: Scott Wood, linuxppc-dev, khali, linux-kernel, i2c
In-Reply-To: <20071222001112.691b80c8@kernel.crashing.org>
Hi Vitaly,
> I had an attempt a while ago to do this but haven't had enough time to get it completed, so
> I am glad to see it finally picked up. There was some sort of discussion that time, you seem to have some of those points
> addressed but something not, please
> check: http://lkml.org/lkml/2007/5/8/45
>
> (for instance, cpm_i2c_shutdown() and i2c_cpm_del_bus() are void because they cant' fail)
>
I'll resend a fixed patch.
> Also, why this was directed to Scott? This is lm-sensors stuff and is
> Jean Delvare <khali@linux-fr.org> material..
Scott reviewed this driver last time and i hope to get some further
comments from him. But thanks for adding
Jean as well.
Thanks,
Jochen
^ permalink raw reply
* Re: [PATCH 4/4] [POWERPC] CPM1: implement GPIO API
From: Jochen Friedrich @ 2007-12-22 9:54 UTC (permalink / raw)
To: Anton Vorontsov; +Cc: linuxppc-dev
In-Reply-To: <20071221203431.GD4633@localhost.localdomain>
Hi Anton,
> Jochen, I kept your Signed-off-by, though this isn't your original
> patch. Hope you're okay with it. I also hope you'll test it. ;-)
>
that's OK.
Thanks,
Jochen
^ permalink raw reply
* Loop at starting pid 164, tty '': '/sbin/getty'
From: ramkumarj Ramkumar @ 2007-12-22 8:51 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 864 bytes --]
Hi All,
I m trying to run Linux 2.6 ( From Grant) on ML-403. I used the
busybox-1.7.2. During booting, I found the following logs and it keeps
trying to respawn the getty.It keeps looping and I never see the login
prompt. Am I missing something.
<snip>
Starting system...
mounting /proc: done.
Mounting '/' read-write: done.
brining up loopback interface: done.
Mounting /tmp: done.
Starting syslogd: done.
Starting klogd: done.
Starting inetd: done.
System started.
starting pid 163, tty '': '/sbin/getty'
[ 7.218444] XSysAce: Queue is plugged
process '/sbin/getty 38400 tts/0' (pid 163) exited. Scheduling it for
restart.
starting pid 164, tty '': '/sbin/getty'
process '/sbin/getty 38400 tts/0' (pid 164) exited. Scheduling it for
restart.
starting pid 165, tty '': '/sbin/getty'
Any suggestion or pointers would be very helpful.
Best Regards,
Ramkumar
[-- Attachment #2: Type: text/html, Size: 1154 bytes --]
^ permalink raw reply
* Re: [PATCH 4/4] PowerPC: Add PCI node to 440GRx Rainier DTS.
From: Stefan Roese @ 2007-12-22 5:54 UTC (permalink / raw)
To: linuxppc-dev, benh
In-Reply-To: <1198272111.6737.9.camel@pasglop>
On Friday 21 December 2007, Benjamin Herrenschmidt wrote:
> On Fri, 2007-12-21 at 19:27 +0300, Valentine Barshak wrote:
> > + /* All PCI interrupts are routed to IRQ 67 */
> > + interrupt-map-mask = <0000 0 0 0>;
> > + interrupt-map = < 0000 0 0 0 &UIC2 3 8 >;
> > + };
>
> Same question as for Sequoia...
Correct here too. Rainier (440GRx) is basically a stripped of version of the
Sequioa (440EPx).
Berst regards,
Stefan
^ permalink raw reply
* Re: [PATCH 3/4] PowerPC: Add PCI entry to 440EPx Sequoia DTS.
From: Stefan Roese @ 2007-12-22 5:53 UTC (permalink / raw)
To: linuxppc-dev, benh
In-Reply-To: <1198272085.6737.6.camel@pasglop>
On Friday 21 December 2007, Benjamin Herrenschmidt wrote:
> On Fri, 2007-12-21 at 19:26 +0300, Valentine Barshak wrote:
> > +
> > + /* All PCI interrupts are routed to IRQ 67 */
> > + interrupt-map-mask = <0000 0 0 0>;
> > + interrupt-map = < 0000 0 0 0 &UIC2 3 8 >;
> > + };
> > };
>
> Wow, all 4 lines of all slots ?
Yes, that's unfortunately correct. :-(
Best regards,
Stefan
^ permalink raw reply
* Re: [PATCH 4/4] PowerPC: Add PCI node to 440GRx Rainier DTS.
From: Benjamin Herrenschmidt @ 2007-12-22 5:58 UTC (permalink / raw)
To: Stefan Roese; +Cc: linuxppc-dev
In-Reply-To: <200712220654.51132.sr@denx.de>
On Sat, 2007-12-22 at 06:54 +0100, Stefan Roese wrote:
> On Friday 21 December 2007, Benjamin Herrenschmidt wrote:
> > On Fri, 2007-12-21 at 19:27 +0300, Valentine Barshak wrote:
> > > + /* All PCI interrupts are routed to IRQ 67 */
> > > + interrupt-map-mask = <0000 0 0 0>;
> > > + interrupt-map = < 0000 0 0 0 &UIC2 3 8 >;
> > > + };
> >
> > Same question as for Sequoia...
>
> Correct here too. Rainier (440GRx) is basically a stripped of version of the
> Sequioa (440EPx).
I hope they accompany it with a design note: "don't do that in your
actual products" :-)
Ben.
^ permalink raw reply
* Re: [RESEND DTC PATCH 2/2] Add support for binary includes.
From: David Gibson @ 2007-12-22 2:51 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev, jdl, u-boot-users
In-Reply-To: <20071221170921.GA6977@ld0162-tx32.am.freescale.net>
On Fri, Dec 21, 2007 at 11:09:21AM -0600, Scott Wood wrote:
> On Fri, Dec 21, 2007 at 11:29:22AM +1100, David Gibson wrote:
> > On Thu, Dec 20, 2007 at 01:52:59PM -0600, Scott Wood wrote:
> > > A property's data can be populated with a file's contents
> > > as follows:
> > >
> > > node {
> > > prop = /bin-include/ "path/to/data";
> > > };
> >
> > I'd be inclined to use /incbin/ rather than /bin-include/. It's only
> > slightly less obvious, but it's then the same as the gas pseudo-op as
> > well as being a little briefer.
>
> OK.
>
> > > Search paths are not yet implemented; non-absolute lookups are relative to
> > > the directory from which dtc was invoked.
> >
> > Hrm. I think that's a bit too bogus. Although it's rather more work
> > to implement, I think we have to make relative paths relative to the
> > location of the dts file until search paths are implemented.
>
> OK. I was being lazy. :-P
In general I'd approve, but having to invoke dtc in the right place
for the dts file is a bit too big a usability problem, I think.
> > > + | propdataprefix DT_BININCLUDE DT_STRING
> > > + {
> > > + struct stat st;
> > > + FILE *f;
> > > + int fd;
> > > +
> > > + f = fopen($3.val, "rb");
> > > + if (!f) {
> > > + yyerrorf("Cannot open file \"%s\": %s",
> > > + $3.val, strerror(errno));
> > > + YYERROR;
> >
> > Hrm. I'm not sure that being unable to open the file should cause a
> > *parse* error which is what YYERROR will do. Probably better to print
> > an error message, but let the parsing continue, with the property
> > value being as though the file were empty.
>
> Yeah, I wanted something that would cause dtc to return an error code,
> and it doesn't seem that calling yyerror(f) will do that at present. I
> guess I should fix that rather than overload YYERROR.
No. As per the yacc interface, yyerror() prints only, it doesn't
terminate.
You could use die(), although that might be an excessively scary
message for the situation.
> > > + }
> > > +
> > > + fd = fileno(f);
> > > + if (fstat(fd, &st) < 0) {
> > > + yyerrorf("Cannot stat file \"%s\": %s",
> > > + $3.val, strerror(errno));
> > > + YYERROR;
> > > + }
> >
> > I'm also not sure that stat()ing the file is a good way to get the
> > size. This requires that the included file be a regular file with a
> > sane st_size value, and I can imagine cases where it might be useful
> > to incbin from a /dev node or other special file. Obviosuly
> > implementing that will require work to data_copy_file().
>
> Hmm... do you have a use case in mind?
Nothing really specific. I'm thinking of a dts that maybe pulls in
some blobs from a pre-existing firmware, by sucking in files from
/proc/device-tree. Or maybe something to produce a dts for a guest
under a hypervisor that takes an image of a real NVRAM or other device
to embed in the tree as a virtual NVRAM for the guest.
It's not a big deal, but since it shouldn't be that hard in principle
to read in a whole file without getting an st_size first.
> > Actually, I think the way to go here would be to have two variants of
> > the incbin directive: one which takes just a filename and includes
> > the whole file contents, another which takes a filename and a number
> > and includes just the first N bytes of the file.
>
> Maybe. /incbinrange/ "path/name" start len?
I'd prefer to avoid two different keywords if possible. I'll see if I
can think of a reasonable syntax.
> > > diff --git a/dtc.h b/dtc.h
> > > index 9b89689..87b5bb1 100644
> > > --- a/dtc.h
> > > +++ b/dtc.h
> > > @@ -138,6 +138,7 @@ struct data data_grow_for(struct data d, int xlen);
> > > struct data data_copy_mem(const char *mem, int len);
> > > struct data data_copy_escape_string(const char *s, int len);
> > > struct data data_copy_file(FILE *f, size_t len);
> > > +struct data data_bin_include(const char *filename);
> >
> > This looks like a hangover from an earlier version.
>
> Oops, yes.
>
> -Scott
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
>
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Re: [DTC PATCH 1/2] Add yyerrorf() for formatted error messages.
From: David Gibson @ 2007-12-22 2:43 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev, jdl, u-boot-users
In-Reply-To: <20071221212856.GA8208@ld0162-tx32.am.freescale.net>
On Fri, Dec 21, 2007 at 03:28:56PM -0600, Scott Wood wrote:
> On Fri, Dec 21, 2007 at 11:04:39AM +1100, David Gibson wrote:
> > On Thu, Dec 20, 2007 at 10:48:23AM -0600, Scott Wood wrote:
> > > Signed-off-by: Scott Wood <scottwood@freescale.com>
> >
> > No need for a new function. If yyerror() is defined as a varargs
> > function it's still compatible with bison's built-in usage.
>
> Not if yyerror() is called with a percent symbol in the string, which
> looks possible if a percent token is added and verbose syntax errors are
> enabled.
Ah, yes, I guess so.
However from discussion on the other thread, it looks like this
extended yyerror() isn't really what you want. Maybe instead we
should look a more general error/warning printing function, and make
yyerror() call that.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Re: GPIO causing bus error
From: Jeff Mock @ 2007-12-22 2:10 UTC (permalink / raw)
To: Wyse, Chris
Cc: Slimm, Rob, linuxppc-dev, support, Wessel, Jason, Ayer, Charles,
+linux-eng, +techfield, linux-kernel, linuxppc-embedded,
Read, Tricia, +linux-embedded, Touron, Emmanuel
In-Reply-To: <AF1602CB2550CE4381C0C75118A7856B020C60D7@ala-mail02.corp.ad.wrs.com>
Well, I have a system that is pretty similar to yours. Our boards have
a 440GX and two Xilinx 2VP70's. The FPGAs are loaded using slave serial
mode (not jtag) from GPIO pins, but still pretty similar.
I haven't had any problems loading the FPGAs this way.
From your description I can't tell when you load the FPGAs during the
boot process. Our approach is as follows:
A module is loaded that creates /dev/fpga. You can 'cat' a bitstream
file to /dev/fpga and the driver will wiggle the GPIO pins appropriately
to the load the bitstream in the FPGAs. The script run at boot time
will do something like:
# zcat /etc/fpga_img.gz > /dev/fpga
At that point we load modules that create devices appropriate for the
FPGA image and the system is off running a domain specific application.
The process can be reversed to unload the drivers, load a new FPGA image
and new drivers without rebooting.
One thing that comes to mind is that our GPIO pins are used for a number
of disparate needs beyond FPGA loading. I keep a semaphore for
accessing the GPIO pins so that the different drivers that touch the
GPIO pins don't step on each other. Only one driver can touch the GPIO
pins at a time. Failing to do this in our application would definitely
create occasional failures.
jeff
Wyse, Chris wrote:
> Hi,
>
> I'm having trouble with an unusual problem. I'm working on relatively
> new hardware, so it's possible that there could be a hardware issue
> involved.
>
> I have an FPGA on my PPC440GX board that gets loaded via JTAG during the
> kernel boot process (Linux 2.6.10). It uses the 440GX GPIO lines to
> send the necessary JTAG commands to the FPGA to perform the initial
> load. This process is USUALLY functional, but on some of the boards
> (which we produce), the GPIO write fails with a bus error. On the
> boards that fail, it only occurs after a cold boot, and only if the
> board has been powered off for a few minutes. A quick hard reboot will
> not generate the problem. When I issue the failing write to the GPIO
> lines, some of the SDRAM gets corrupted. I don't appear to be taking
> any interrupts that might have corrupted the RAM.
>
> I've checked the TLB entries, and it maps correctly to the PPC register
> area. Additionally, I can read and write to other registers using the
> same TLB mapping WITHOUT any error. I can also READ the GPIO lines
> without an error - the error is only on the write. I've checked the
> SDR0_PFC0 bits to make sure everything is set properly (it is). The bus
> error indicates "PLB Timeout Error Status Master 2, Master 2 slave error
> occurred" (Master 2 is the write-only data cache unit (DCU)) and "Write
> Error Interrupt Master 2, Write error detected - master 2 interrupt
> request is active". I'm not sure why there would be any error in the
> DCU, since the region I'm writing to is cache inhibited and guarded.
>
> If I issue a soft reset of the GPIO subsystem, I can read and write to
> the GPIO lines again.
>
> The error does not occur on the first write to the GPIO. I go through
> the failing routine several times before it fails. However, when it
> fails, it consistently fails at the same spot, after the same number of
> passes through the code.
>
> I'm using RGMII ethernet on EMAC2 (Group 4), but the GPIO lines that I'm
> using are not the Trace/GPIO lines (26-31) so I believe that they should
> work fine (and they usually do). Also, the errata mentions that
> SDR0_PFC0[G11E] has no effect - but I'm not using GPIO 11 anyway.
>
> Here are some relevant register values after the error:
>
> SDR0_PFC0 : 0x083FFE00
> POB0_BESR0: 0x00008400
> POB0_BEARH: 0x00000001
> POB0_BEARL: 0x40000701
> GPIO0_OR : 0x000400C0
> GPIO0_TCR : 0x00278AE0
> GPIO0_ODR : 0x00000000
> GPIO0_IR : 0x00000000
>
> I've attached two log files, that contain most of the 440 registers, one
> for before the error and one after. In the log files, the bus error has
> been cleared, so use the values shown above.
>
> I'm looking for some suggestions on what to try to debug/resolve this
> issue. I'm open to both hardware and software based suggestions. Any
> help would be greatly appreciated.
>
>
> Chris Wyse
> Senior Member of Technical Staff
> Embedded Technologies
> 860-978-0849 cell/office
> 413-778-9101 fax
> http://www.windriver.com <http://www.windriver.com/>
>
>
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
^ permalink raw reply
* Re: [PATCH 2/3] sbc8548: Add device tree source for Wind River SBC8548 board
From: David Gibson @ 2007-12-22 2:05 UTC (permalink / raw)
To: Paul Gortmaker; +Cc: linuxppc-dev
In-Reply-To: <20071221172023.GA23220@windriver.com>
On Fri, Dec 21, 2007 at 12:20:24PM -0500, Paul Gortmaker wrote:
> In message: Re: [PATCH 2/3] sbc8548: Add device tree source for Wind River SBC8548 board
> on 21/12/2007 Kumar Gala wrote:
>
> >
> > On Dec 21, 2007, at 12:43 AM, Paul Gortmaker wrote:
> >
> >> This adds the device tree source for the Wind River SBC8548 board.
>
> [...]
>
> > mind looking at converting this to a dts-v1 format?
> >
> > - k
>
> I figured there might be value in having it as a separate commit, seeing
> as there aren't that many other dts-v1 as a reference (yet). Not sure
> if I've got all the v1 type changes in that you had in mind, but I fed
> it through the latest dtc from git and fed it to the board and it still
> seems happy with it.
There are really only two changes with dts-v1.
1) All integers become C-style, so, decimal by default with
leading 0, 0x or 0b for octal/hex/binary. d# h# o# are no longer
supported.
2) References to pths must be writte as &{/some/node/or/other}
instead of &/some/node/or/other. References to labels remain fine as
just &label.
The explicit new source version isn't because the format changes are
large, just because there was no way to make them in a
backwards-compatible way.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Re: [PATCH 17/21] [POWERPC] Base support for 440SPe "Katmai" eval board
From: Josh Boyer @ 2007-12-22 1:48 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: linuxppc-dev
In-Reply-To: <20071222112105.b24c85c5.sfr@canb.auug.org.au>
On Sat, 22 Dec 2007 11:21:05 +1100
Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> On Fri, 21 Dec 2007 15:39:34 +1100 Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
> >
> > +++ linux-merge/arch/powerpc/platforms/44x/katmai.c 2007-12-21 14:34:33.000000000 +1100
> > +
> > +static struct of_device_id katmai_of_bus[] = {
>
> __initdata (preferably) or const, please.
I'll fix this with a separate commit. The same comment applies for all
the 4xx platforms already in the kernel.
josh
^ permalink raw reply
* Re: [PATCH 8/21] [POWERPC] EP405 boards support for arch/powerpc
From: Josh Boyer @ 2007-12-21 23:55 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: linuxppc-dev
In-Reply-To: <20071222102424.bc96d03c.sfr@canb.auug.org.au>
On Sat, 22 Dec 2007 10:24:24 +1100
Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> Hi Ben,
>
> Just a couple of trivial things.
All fair comments. And I realize that everyone is busy and such,
but this is the 4th or 5th time these patches have hit the list.
I'm hesitant to let perfection get in the way of good enough at this
point. I can always fix these up when I commit.
josh
^ permalink raw reply
* Re: [PATCH 1/4] [POWERPC] qe_lib and users: get rid of device_type and model
From: Anton Vorontsov @ 2007-12-22 0:23 UTC (permalink / raw)
To: Olof Johansson; +Cc: linuxppc-dev
In-Reply-To: <20071221212553.GA11910@lixom.net>
On Fri, Dec 21, 2007 at 03:25:53PM -0600, Olof Johansson wrote:
> Hi,
>
> On Fri, Dec 21, 2007 at 11:20:54PM +0300, Anton Vorontsov wrote:
> > diff --git a/arch/powerpc/platforms/85xx/mpc85xx_mds.c b/arch/powerpc/platforms/85xx/mpc85xx_mds.c
> > index e6c63a5..a152bf8 100644
> > --- a/arch/powerpc/platforms/85xx/mpc85xx_mds.c
> > +++ b/arch/powerpc/platforms/85xx/mpc85xx_mds.c
> > @@ -94,7 +94,8 @@ static void __init mpc85xx_mds_setup_arch(void)
> > #endif
> >
> > #ifdef CONFIG_QUICC_ENGINE
> > - if ((np = of_find_node_by_name(NULL, "qe")) != NULL) {
> > + np = of_find_node_by_name(NULL, "fsl,qe");
> > + if (np) {
>
> That won't work. Did you mean of_find_compatible_node()?
Yes. :-(
> If so, you
> still need to fall back to looking up by name for older device trees
> that don't have the compatible field.
Yup.
Okay.. I'm approaching lucky v7. ;-)
Much thanks for catching this,
--
Anton Vorontsov
email: cbou@mail.ru
backup email: ya-cbou@yandex.ru
irc://irc.freenode.net/bd2
^ permalink raw reply
* Re: [PATCH 0/4] PowerPC: implement GPIO API
From: Anton Vorontsov @ 2007-12-22 0:16 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev
In-Reply-To: <fa686aa40712211317o401be150n32196a25b5ab1481@mail.gmail.com>
On Fri, Dec 21, 2007 at 02:17:57PM -0700, Grant Likely wrote:
> On 12/21/07, Anton Vorontsov <avorontsov@ru.mvista.com> wrote:
> > As I've probably said once already: if there are plans to build single
> > kernel with QE+CPM1+CPM2 inside tomorrow -- then of course, I'd better
> > wait.
> >
> > But if these plans are distant enough, I see no reason why we can't
> > enjoy of current API.
>
> Oh, I'm not saying don't enjoy it. :-) I'm just saying keep it out
> of mainline. I've got a bunch of Virtex stuff that falls into that
> category. Those who are interested can pick the non mainlined patches
> out of my git tree.
Ok. I'm fine either way.
Here we go. For anyone interested in the GPIOs on PowerPC, you
can keep an eye on this git tree:
git://git.infradead.org/users/cbou/powerpc-gpio.git
As time will permit, I'll start gpiolib work in the "gpiolib"
branch in that repo, which will include gpiolib -mm patches +
powerpc bits.
Note: I'm quite often rebasing my work, be aware. ;-)
Thanks!
--
Anton Vorontsov
email: cbou@mail.ru
backup email: ya-cbou@yandex.ru
irc://irc.freenode.net/bd2
^ permalink raw reply
* Re: [PATCH 17/21] [POWERPC] Base support for 440SPe "Katmai" eval board
From: Stephen Rothwell @ 2007-12-22 0:21 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev
In-Reply-To: <20071221043938.9C15EDDFBF@ozlabs.org>
[-- Attachment #1: Type: text/plain, Size: 397 bytes --]
On Fri, 21 Dec 2007 15:39:34 +1100 Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
>
> +++ linux-merge/arch/powerpc/platforms/44x/katmai.c 2007-12-21 14:34:33.000000000 +1100
> +
> +static struct of_device_id katmai_of_bus[] = {
__initdata (preferably) or const, please.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH 10/21] [POWERPC] Base support for 440GX Taishan eval board
From: Stephen Rothwell @ 2007-12-22 0:12 UTC (permalink / raw)
To: Hugh Blemings; +Cc: linuxppc-dev
In-Reply-To: <20071221043932.C2FA1DDEDD@ozlabs.org>
[-- Attachment #1: Type: text/plain, Size: 399 bytes --]
On Fri, 21 Dec 2007 15:39:28 +1100 Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
>
> +++ linux-merge/arch/powerpc/platforms/44x/taishan.c 2007-12-21 14:20:04.000000000 +1100
> +
> +static struct of_device_id taishan_of_bus[] = {
__initdata (preferably) or const, please.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH 3/4] [POWERPC] CPM2: implement GPIO API
From: Anton Vorontsov @ 2007-12-21 23:58 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: linuxppc-dev
In-Reply-To: <200712212216.32922.arnd@arndb.de>
On Fri, Dec 21, 2007 at 10:16:32PM +0100, Arnd Bergmann wrote:
> On Friday 21 December 2007, Anton Vorontsov wrote:
> >
> > +static spinlock_t cpm2_port_lock = __SPIN_LOCK_UNLOCKED(cpm2_port_lock);
>
> This needs to be
>
> static DEFINE_SPINLOCK(cpm2_port_lock);
These are equivalents.
#define DEFINE_SPINLOCK(x) spinlock_t x = __SPIN_LOCK_UNLOCKED(x)
> I think at least lockdep doesn't work the way you do it here.
Is it anyhow special regarding what exact macro is used?..
spinlocks.txt says:
SPIN_LOCK_UNLOCKED and RW_LOCK_UNLOCKED defeat lockdep state tracking and
are hence deprecated.
Please use DEFINE_SPINLOCK()/DEFINE_RWLOCK() or
__SPIN_LOCK_UNLOCKED()/__RW_LOCK_UNLOCKED() as appropriate for static
initialization.
-
..should be equivalent, though I prefer open-coded version, until
it fits 80 column width. ;-)
> > +int cpm2_init_par_io(void)
> > +{
> > + struct device_node *np;
> > + const u32 *num_ports;
> > +
> > + np = of_find_compatible_node(NULL, NULL, "fsl,cpm2-pario");
> > + if (!np)
> > + return -ENOENT;
> > +
> > + num_ports = of_get_property(np, "num-ports", NULL);
> > + if (!num_ports) {
> > + of_node_put(np);
> > + return -ENOENT;
> > + }
> > + cpm2_num_ports = *num_ports;
> > +
> > + np->data = &of_gpio_chip;
> > +
> > + return 0;
> > +}
>
> This function should also do the call to of_iomap, so you don't
> need to pull the address out of the cpm2_immr, which I believe
> we're trying to get rid of.
Yup, thanks!
--
Anton Vorontsov
email: cbou@mail.ru
backup email: ya-cbou@yandex.ru
irc://irc.freenode.net/bd2
^ permalink raw reply
* Re: [PATCH 8/21] [POWERPC] EP405 boards support for arch/powerpc
From: Benjamin Herrenschmidt @ 2007-12-22 0:01 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: linuxppc-dev
In-Reply-To: <20071222102424.bc96d03c.sfr@canb.auug.org.au>
On Sat, 2007-12-22 at 10:24 +1100, Stephen Rothwell wrote:
> > +++ linux-merge/arch/powerpc/boot/4xx.c 2007-12-21 14:19:46.000000000 +1100
> > @@ -179,13 +179,16 @@ void ibm40x_dbcr_reset(void)
> > #define EMAC_RESET 0x20000000
> > void ibm4xx_quiesce_eth(u32 *emac0, u32 *emac1)
> > {
> > - /* Quiesce the MAL and EMAC(s) since PIBS/OpenBIOS don't do this for us */
> > + /* Quiesce the MAL and EMAC(s) since PIBS/OpenBIOS don't
> > + * do this for us
> > + */
> > if (emac0)
> > *emac0 = EMAC_RESET;
> > if (emac1)
> > *emac1 = EMAC_RESET;
> >
> > mtdcr(DCRN_MAL0_CFG, MAL_RESET);
> > + while (mfdcr(DCRN_MAL0_CFG) & MAL_RESET) {};
>
> You need the {} or the ; but not both and please put them indented on the
> next line so that it is very clear that this is an empty loop.
Code was copy/pasted from somewhere else... we can always do a fixup
later.
> > + if (cpc0_cr0 & 0x80) {
> > + /* uart0 uses the external clock */
> > + uart0 = ser_clk;
> > + } else {
> > + uart0 = cpu / udiv;
> > + }
>
> The braces aren't really needed. (Yes, I noticed that you just moved the
> code here)
Yup :-)
> > + if (cpc0_cr0 & 0x40) {
> > + /* uart1 uses the external clock */
> > + uart1 = ser_clk;
> > + } else {
> > + uart1 = cpu / udiv;
> > + }
>
> And again.
I'd rather do cleanups separately. I won't send new patches until I'm
back from vacation so Josh, if you want to fix those little nits up,
feel free.
> > +++ linux-merge/arch/powerpc/platforms/40x/ep405.c 2007-12-21 14:19:46.000000000 +1100
> > +
> > +static struct of_device_id ep405_of_bus[] = {
>
> __initdata (preferably) or const
Ben.
^ permalink raw reply
* Re: Oops: Kernel access of bad area
From: Christian Kujau @ 2007-12-21 23:34 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Nathan Lynch
In-Reply-To: <20071220214705.GA28696@localdomain>
On Thu, 20 Dec 2007, Nathan Lynch wrote:
> Better to include the full stack trace in such reports,
Hm, I did not want to clutter the mail with all this stuff, but you're
right, in this case it would've made sense...
> So it looks like the kernel oopsed while firefox was dumping core,
> yuck. It's a real bug. Hopefully someone on the list can help...
As it's the first time this happened and I could not reproduce it so far
(the only thing I can reproduce is the ffox crash :)), I doubt it'll be
"fixable" somehow...
Thanks,
Christian.
--
BOFH excuse #247:
Due to Federal Budget problems we have been forced to cut back on the number of users able to access the system at one time. (namely none allowed....)
^ permalink raw reply
* Re: [PATCH 8/21] [POWERPC] EP405 boards support for arch/powerpc
From: Stephen Rothwell @ 2007-12-21 23:24 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev
In-Reply-To: <20071221043931.1A5CCDDEC0@ozlabs.org>
[-- Attachment #1: Type: text/plain, Size: 1540 bytes --]
Hi Ben,
Just a couple of trivial things.
On Fri, 21 Dec 2007 15:39:26 +1100 Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
>
> +++ linux-merge/arch/powerpc/boot/4xx.c 2007-12-21 14:19:46.000000000 +1100
> @@ -179,13 +179,16 @@ void ibm40x_dbcr_reset(void)
> #define EMAC_RESET 0x20000000
> void ibm4xx_quiesce_eth(u32 *emac0, u32 *emac1)
> {
> - /* Quiesce the MAL and EMAC(s) since PIBS/OpenBIOS don't do this for us */
> + /* Quiesce the MAL and EMAC(s) since PIBS/OpenBIOS don't
> + * do this for us
> + */
> if (emac0)
> *emac0 = EMAC_RESET;
> if (emac1)
> *emac1 = EMAC_RESET;
>
> mtdcr(DCRN_MAL0_CFG, MAL_RESET);
> + while (mfdcr(DCRN_MAL0_CFG) & MAL_RESET) {};
You need the {} or the ; but not both and please put them indented on the
next line so that it is very clear that this is an empty loop.
> + if (cpc0_cr0 & 0x80) {
> + /* uart0 uses the external clock */
> + uart0 = ser_clk;
> + } else {
> + uart0 = cpu / udiv;
> + }
The braces aren't really needed. (Yes, I noticed that you just moved the
code here)
> + if (cpc0_cr0 & 0x40) {
> + /* uart1 uses the external clock */
> + uart1 = ser_clk;
> + } else {
> + uart1 = cpu / udiv;
> + }
And again.
> +++ linux-merge/arch/powerpc/platforms/40x/ep405.c 2007-12-21 14:19:46.000000000 +1100
> +
> +static struct of_device_id ep405_of_bus[] = {
__initdata (preferably) or const
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH 18/21] [POWERPC] bamboo: remove bogus "ranges" property in EBC node
From: Josh Boyer @ 2007-12-21 22:08 UTC (permalink / raw)
To: benh; +Cc: linuxppc-dev
In-Reply-To: <1198271815.6737.4.camel@pasglop>
On Sat, 22 Dec 2007 08:16:55 +1100
Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
>
> On Fri, 2007-12-21 at 06:09 -0600, Josh Boyer wrote:
> > On Fri, 21 Dec 2007 15:39:35 +1100
> > Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
> >
> > > This removes a bogus empty "ranges" property in the EBC device node
> > > of the Bamboo board device-tree.
> > >
> > > The "ranges" property will be created by the boot wrapper, there is
> > > no need to have an empty property there, and that causes recent
> > > dtc to complain.
> >
> > The wrapper doesn't do anything with EBC for bamboo because the EBC
> > stuff is a nightmare on this board. The patch can stand, but I'll
> > fixup the comments in the changelog.
>
> The wrapper could still create ranges for the chip select settings no ?
It could. It doesn't though. Perhaps our interpretation of "will be
created" differed.
> In any case, empty "ranges" is bogus.
Correct. Which is why I said I'd just edit the changelog :).
josh
^ permalink raw reply
* Re: [DTC PATCH 1/2] Add yyerrorf() for formatted error messages.
From: Scott Wood @ 2007-12-21 21:28 UTC (permalink / raw)
To: jdl, linuxppc-dev, u-boot-users
In-Reply-To: <20071221000439.GC2665@localhost.localdomain>
On Fri, Dec 21, 2007 at 11:04:39AM +1100, David Gibson wrote:
> On Thu, Dec 20, 2007 at 10:48:23AM -0600, Scott Wood wrote:
> > Signed-off-by: Scott Wood <scottwood@freescale.com>
>
> No need for a new function. If yyerror() is defined as a varargs
> function it's still compatible with bison's built-in usage.
Not if yyerror() is called with a percent symbol in the string, which
looks possible if a percent token is added and verbose syntax errors are
enabled.
-Scott
^ permalink raw reply
* Re: Enable RTC for Ebony and Walnut
From: Olof Johansson @ 2007-12-21 21:29 UTC (permalink / raw)
To: Josh Boyer, Paul Mackerras, linuxppc-dev
In-Reply-To: <20071221022130.GI2665@localhost.localdomain>
Hi,
On Fri, Dec 21, 2007 at 01:21:30PM +1100, David Gibson wrote:
> Index: working-2.6/arch/powerpc/platforms/Kconfig
> ===================================================================
> --- working-2.6.orig/arch/powerpc/platforms/Kconfig 2007-12-10 10:52:44.000000000 +1100
> +++ working-2.6/arch/powerpc/platforms/Kconfig 2007-12-21 13:11:34.000000000 +1100
> @@ -315,6 +315,9 @@ config FSL_ULI1575
> config CPM
> bool
>
> +config OF_RTC
> + bool
> +
New config options should have descriptions, even if they're silent
ones.
Thanks,
-Olof
^ permalink raw reply
* Re: [PATCH 4/4] PowerPC: Add PCI node to 440GRx Rainier DTS.
From: Benjamin Herrenschmidt @ 2007-12-21 21:21 UTC (permalink / raw)
To: Valentine Barshak; +Cc: linuxppc-dev
In-Reply-To: <20071221162708.GA1724@ru.mvista.com>
On Fri, 2007-12-21 at 19:27 +0300, Valentine Barshak wrote:
> + /* All PCI interrupts are routed to IRQ 67 */
> + interrupt-map-mask = <0000 0 0 0>;
> + interrupt-map = < 0000 0 0 0 &UIC2 3 8 >;
> + };
Same question as for Sequoia...
Ben.
^ permalink raw reply
* Re: [PATCH 3/4] PowerPC: Add PCI entry to 440EPx Sequoia DTS.
From: Benjamin Herrenschmidt @ 2007-12-21 21:21 UTC (permalink / raw)
To: Valentine Barshak; +Cc: linuxppc-dev
In-Reply-To: <20071221162601.GA1700@ru.mvista.com>
On Fri, 2007-12-21 at 19:26 +0300, Valentine Barshak wrote:
> +
> + /* All PCI interrupts are routed to IRQ 67 */
> + interrupt-map-mask = <0000 0 0 0>;
> + interrupt-map = < 0000 0 0 0 &UIC2 3 8 >;
> + };
> };
Wow, all 4 lines of all slots ?
Ben.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox