* Re: Interrupt handling documentation
From: Benjamin Herrenschmidt @ 2008-03-17 20:44 UTC (permalink / raw)
To: Laurent Pinchart; +Cc: linuxppc-dev
In-Reply-To: <200803171713.51671.laurentp@cse-semaphore.com>
On Mon, 2008-03-17 at 17:13 +0100, Laurent Pinchart wrote:
> The PIC I am working with is linked to a falling-edge external irq on the
> CPM2. When the first PIC interrupt was generated the kernel called the PIC
> chained irq handler endlessly.
>
> After some investigation it turned out the external interrupt bit in the CPM2
> interrupt pending register never got cleared. set_irq_chained_handler()
> registers the chained irq handler at the lowest level in the irq stack,
> bypassing all the interrupt acknowledgement/masking logic.
Yes, exactly. To answer a previous question in the thread, the reason
there are two approaches to cascades is just that:
- The "easy" approach using setup_irq(). The normal interrupt handling
is done for the cascade, it's masked/acked/whatever-is-needed as any
other interrupt before the second interrupt is fetched. This results
is slightly more kernel stack usage and overhead in getting to the
second interrupt, among other things, but is easier.
- The "fast" approach using a chained handler. This, as you noticed,
bypass pretty much the whole stack and calls the chain handler directly.
That means that your chain handler is responsible to perform all the
necessary things to ensure the cascade interrupt is properly ack'ed
etc...
> The fix was easy, all I had to do was to call desc->chip->ack(irq) at the
> beginning on the chained irq handler and desc->chip->eoi(irq) at the end.
For an edge cascade, that would do, I suppose. But beware that if you
are only calling ack() and not mask(), then a subsequent chain interrupt
from the same cascade can (and will) potentially happen while you are
calling the handler as the cascade itself has been ack'ed and not
masked. In the case of cpm2, that also probably means you don't need to
call end().
That might be fine though, but it increases the chances of having of
stack overflows caused by interrupts stacking up.
> However, I'm wondering if this really belongs in the PIC code, or if PICs
> shouldn't be registered at a higher level (setup_irq or even request_irq) so
> that they would reuse the handle_*_irq handlers. Any opinion on this ?
They can. The chain handling mechanism is an optimisation. It avoids a
spinlock and other bits & pieces which improve performance & latency of
handling cascaded interrupts, at the expense of that added complexity.
Ben.
^ permalink raw reply
* Re: Please pull linux-2.6-mpc52xx.git
From: Wolfgang Denk @ 2008-03-17 20:59 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev
In-Reply-To: <fa686aa40803171219s7135a0f8n91bcd20329a94637@mail.gmail.com>
In message <fa686aa40803171219s7135a0f8n91bcd20329a94637@mail.gmail.com> you wrote:
>
> > What is the status of the various MPC5200-related patches (support for
> > TQM5200, CM5200 and Motion-PRO boards, few drivers, etc) posted some
> > time ago by Marian Balakowicz? There's been some comments to the patches
> > on the list, which were addressed and no further discussion occurred, so
> > we were hoping that the changes would go upstream (in 2.6.25). I can see
> > that the .dts files for those boards are in the mainline already, but I
> > see no trace of for example _defconfig files -- could you shed some
> > light on this?
>
> Yes, the separate dts files have been dropped in preference for a
> single mpc5200_defconfig for all 5200 boards.
I know that my opinion doesn't matter but that's a stupid thing to
do. Do you think that this single mpc5200_defconfig will (a) work and
(b) be useful on all 5200 boards? Who hast tested it, and on which
platforms?
And what about the other patches? I see no code for these boards in
arch/powerpc/platforms/52xx/ ?
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: wd@denx.de
Minds are like parachutes - they only function when open.
^ permalink raw reply
* Re: [PATCH] net: NEWEMAC: Support for Pause packets in EMAC driver
From: Benjamin Herrenschmidt @ 2008-03-17 21:26 UTC (permalink / raw)
To: Jeff Garzik; +Cc: netdev, Stefan Roese, linuxppc-dev
In-Reply-To: <1205789101.26869.181.camel@pasglop>
On Tue, 2008-03-18 at 08:25 +1100, Benjamin Herrenschmidt wrote:
> > >
> > > Signed-off-by: Pravin M. Bathija <pbathija@amcc.com>
> > > Signed-off-by: Stefan Roese <sr@denx.de>
> > > ---
> > > drivers/net/ibm_newemac/core.c | 7 +++++++
> > > 1 files changed, 7 insertions(+), 0 deletions(-)
> >
> > applied
>
> Thanks. There's also a couple of patches from Valentine that should go
> in. I'll ask him to resend to you.
Actually, they need some arch bits so they are better off going through
Josh tree on top of the said changes.
Valentine, can you make sure Jeff at least has a chance to see them and
ack them though ?
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH] net: NEWEMAC: Support for Pause packets in EMAC driver
From: Benjamin Herrenschmidt @ 2008-03-17 21:25 UTC (permalink / raw)
To: Jeff Garzik; +Cc: netdev, Stefan Roese, linuxppc-dev
In-Reply-To: <47DE5F43.80604@garzik.org>
> >
> > Signed-off-by: Pravin M. Bathija <pbathija@amcc.com>
> > Signed-off-by: Stefan Roese <sr@denx.de>
> > ---
> > drivers/net/ibm_newemac/core.c | 7 +++++++
> > 1 files changed, 7 insertions(+), 0 deletions(-)
>
> applied
Thanks. There's also a couple of patches from Valentine that should go
in. I'll ask him to resend to you.
Cheers,
Ben.
^ permalink raw reply
* Re: Please pull linux-2.6-mpc52xx.git
From: Grant Likely @ 2008-03-17 21:43 UTC (permalink / raw)
To: Wolfgang Denk; +Cc: linuxppc-dev
In-Reply-To: <20080317205956.BAC85241A2@gemini.denx.de>
On Mon, Mar 17, 2008 at 2:59 PM, Wolfgang Denk <wd@denx.de> wrote:
> In message <fa686aa40803171219s7135a0f8n91bcd20329a94637@mail.gmail.com> you wrote:
> >
> > > What is the status of the various MPC5200-related patches (support for
> > > TQM5200, CM5200 and Motion-PRO boards, few drivers, etc) posted some
> > > time ago by Marian Balakowicz? There's been some comments to the patches
> > > on the list, which were addressed and no further discussion occurred, so
> > > we were hoping that the changes would go upstream (in 2.6.25). I can see
> > > that the .dts files for those boards are in the mainline already, but I
> > > see no trace of for example _defconfig files -- could you shed some
> > > light on this?
> >
> > Yes, the separate dts files have been dropped in preference for a
> > single mpc5200_defconfig for all 5200 boards.
>
> I know that my opinion doesn't matter but that's a stupid thing to
^^^^^^^^^^^^^^^^^^^^^^^^^
Bull. You know better than that.
> do. Do you think that this single mpc5200_defconfig will (a) work and
> (b) be useful on all 5200 boards? Who hast tested it, and on which
> platforms?
a) the same way we know that 5200 ethernet driver (for example) works
on all 5200 boards. If it breaks for one board then we fix it.
b) defconfigs is more about testing and a known working configuration
than it is about a distribution configuration. It's not intended to
be the deployed config. For a distribution/deployable image it is
expected that the engineer responsible will tailor the config.
> And what about the other patches? I see no code for these boards in
> arch/powerpc/platforms/52xx/ ?
All these boards are supported with
arch/powerpc/platforms/mpc5200_simple.c. A kernel built for that
platform will boot on any of those boards as long as it is passed the
correct device tree.
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: [PATCH] net: NEWEMAC: Support for Pause packets in EMAC driver
From: Josh Boyer @ 2008-03-17 21:43 UTC (permalink / raw)
To: benh; +Cc: netdev, Stefan Roese, Jeff Garzik, linuxppc-dev
In-Reply-To: <1205789205.26869.184.camel@pasglop>
On Tue, 18 Mar 2008 08:26:45 +1100
Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
>
> On Tue, 2008-03-18 at 08:25 +1100, Benjamin Herrenschmidt wrote:
> > > >
> > > > Signed-off-by: Pravin M. Bathija <pbathija@amcc.com>
> > > > Signed-off-by: Stefan Roese <sr@denx.de>
> > > > ---
> > > > drivers/net/ibm_newemac/core.c | 7 +++++++
> > > > 1 files changed, 7 insertions(+), 0 deletions(-)
> > >
> > > applied
> >
> > Thanks. There's also a couple of patches from Valentine that should go
> > in. I'll ask him to resend to you.
>
> Actually, they need some arch bits so they are better off going through
> Josh tree on top of the said changes.
There's also the section mismatch patch I sent you. I don't care who's
tree they go through, but I'd need to know either way so keep me in the
loop please.
josh
^ permalink raw reply
* Re: [PATCH] [POWERPC] 83xx: MPC837xRDB's VSC7385 ethernet switch isn't on the MDIO bus
From: Timur Tabi @ 2008-03-17 21:46 UTC (permalink / raw)
To: joakim.tjernlund; +Cc: linuxppc-dev
In-Reply-To: <1205782935.7589.55.camel@gentoo-jocke.transmode.se>
Joakim Tjernlund wrote:
> Trying to add fixed-link support for ucc_geth as this is broken too. I
> noticed that ifconfig eth1 up follwed by ifconfig eth1 down hangs
> my board once I got the ucc_geth driver to recognize fixed-link.
> Does it work for you?
A long time ago there was a bug where "ifconfig eth1 down" would cause a kernel
panic if eth0 was also up. The root cause was a bug in rheap.c. However, this
code was fixed a year ago. Could it be a similar bug?
--
Timur Tabi
Linux kernel developer at Freescale
^ permalink raw reply
* Re: [PATCH] net: NEWEMAC: Support for Pause packets in EMAC driver
From: Benjamin Herrenschmidt @ 2008-03-17 21:52 UTC (permalink / raw)
To: Josh Boyer; +Cc: netdev, Stefan Roese, Jeff Garzik, linuxppc-dev
In-Reply-To: <20080317164341.12075616@zod.rchland.ibm.com>
> There's also the section mismatch patch I sent you. I don't care who's
> tree they go through, but I'd need to know either way so keep me in the
> loop please.
Jeff, do you mind if we get those patches through the powerpc tree ?
EMAC is very powerpc specific and these are mostly internal driver
cuisine.
Ben.
^ permalink raw reply
* Re: [PATCH] [POWERPC] 83xx: MPC837xRDB's VSC7385 ethernet switch isn't on the MDIO bus
From: Joakim Tjernlund @ 2008-03-17 22:22 UTC (permalink / raw)
To: Timur Tabi; +Cc: linuxppc-dev
In-Reply-To: <47DEE6CF.7040801@freescale.com>
On Mon, 2008-03-17 at 16:46 -0500, Timur Tabi wrote:
> Joakim Tjernlund wrote:
>
> > Trying to add fixed-link support for ucc_geth as this is broken too. I
> > noticed that ifconfig eth1 up follwed by ifconfig eth1 down hangs
> > my board once I got the ucc_geth driver to recognize fixed-link.
> > Does it work for you?
>
> A long time ago there was a bug where "ifconfig eth1 down" would cause a kernel
> panic if eth0 was also up. The root cause was a bug in rheap.c. However, this
> code was fixed a year ago. Could it be a similar bug?
eth0 is also up, was it commit 4942bd80e83d13bf394df4a8109bee39d861820f
that fixed that bug? 2.6.23 works fine for me.
Jocke
^ permalink raw reply
* Re: powerpc: cuImage.* creation error
From: Adrian Bunk @ 2008-03-17 22:23 UTC (permalink / raw)
To: Paul Gortmaker; +Cc: linuxppc-dev, Paul Mackerras, linux-kernel
In-Reply-To: <20080317200754.GA7383@windriver.com>
On Mon, Mar 17, 2008 at 04:07:55PM -0400, Paul Gortmaker wrote:
> In message: powerpc: cuImage.* creation error
> on 17/03/2008 Adrian Bunk wrote:
>
> > When building all powerpc defconfigs in 2.6.25-rc6 exactly three of
> > them fail to build, and all with similar problems:
> >
> > <-- snip -->
> >
> >
> > sbc8548_defconfig:
> >
> > <-- snip -->
> >
> > ...
> > Entry Point: 0x00000000
> > make[2]: *** No rule to make target `arch/powerpc/boot/cuImage.tqm8548', needed by `arch/powerpc/boot/zImage'. Stop.
> >
>
> Untested, but I'll guess that this is at least part of the problem for
> the sbc one...
It doesn't fix the build, and adds sbc8560_defconfig to the list of
non-compiling defconfigs:
<-- snip -->
...
WRAP arch/powerpc/boot/cuImage.sbc8560
DTC: dts->dtb on file "/home/bunk/linux/kernel-2.6/git/linux-2.6/arch/powerpc/boot/dts/sbc8560.dts"
powerpc64-linux-ld: arch/powerpc/boot/cuboot-sbc8560.o: No such file: No such file or directory
make[2]: *** [arch/powerpc/boot/cuImage.sbc8560] Error 1
<-- snip -->
> Thanks,
> Paul.
>
> ---
>
> Author: Paul Gortmaker <paul.gortmaker@windriver.com>
> Date: Mon Mar 17 15:47:03 2008 -0400
>
> cuimage: fix board names in Makefile
>
> Fix the copy and paste error from 25431333813686654907ab987fb5de10c10a16db
> for the sbc8548 and sbc8560
>
> Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
>
> diff --git a/arch/powerpc/boot/Makefile b/arch/powerpc/boot/Makefile
> index 4974d9e..1aded8f 100644
> --- a/arch/powerpc/boot/Makefile
> +++ b/arch/powerpc/boot/Makefile
> @@ -253,8 +253,8 @@ image-$(CONFIG_TQM8540) += cuImage.tqm8540
> image-$(CONFIG_TQM8541) += cuImage.tqm8541
> image-$(CONFIG_TQM8555) += cuImage.tqm8555
> image-$(CONFIG_TQM8560) += cuImage.tqm8560
> -image-$(CONFIG_SBC8548) += cuImage.tqm8548
> -image-$(CONFIG_SBC8560) += cuImage.tqm8560
> +image-$(CONFIG_SBC8548) += cuImage.sbc8548
> +image-$(CONFIG_SBC8560) += cuImage.sbc8560
>
> # Board ports in arch/powerpc/platform/embedded6xx/Kconfig
> image-$(CONFIG_STORCENTER) += cuImage.storcenter
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
^ permalink raw reply
* Re: Please pull linux-2.6-mpc52xx.git
From: Wolfgang Denk @ 2008-03-17 22:28 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev
In-Reply-To: <fa686aa40803171443q7a53f0balbb49740116c6552@mail.gmail.com>
In message <fa686aa40803171443q7a53f0balbb49740116c6552@mail.gmail.com> you wrote:
>
> b) defconfigs is more about testing and a known working configuration
> than it is about a distribution configuration. It's not intended to
> be the deployed config. For a distribution/deployable image it is
> expected that the engineer responsible will tailor the config.
This may be true in general, but for the boards in question it is
definitely incorrect:
* The TQM5200 configuration as provided is intended for shipping as
default configuration for this board. The "engineer responsible"
already *did* the tailoring and put that state in the defconfig
file.
* The CM5200 and Motion-Pro boards are custom designs, where the
defconfig file matches exactly the requirements of the respective
customers.
I feel it is very important to be able to include this configuration
information somewhere with the kernel source tree - and to me the
defconfig file for a board is the most natural place to put such
information.
Please understand that we do NOT expect the end user having to
"tailor the config" - instead, we want to provide a default
configuration that can be used as is, at least for default usage
cases.
If you don't want to use a board specific default configuration, then
please tell me what the recommended way is to provide a knwon to be
working, tested *and* *useful* default configuration for custom
boards in the Linux kernel tree?
> All these boards are supported with
> arch/powerpc/platforms/mpc5200_simple.c. A kernel built for that
> platform will boot on any of those boards as long as it is passed the
> correct device tree.
I don't doubt that the kernel will boot. But that does not mean that
it is ready for use for the intended purpose. For example,
arch/powerpc/platforms/52xx/motionpro.c contains code to setup some
custom LEDs on this board. I can't find that code in
arch/powerpc/platforms/mpc5200_simple.c.
It may be argued that this code should be moved somewhere else, but I
don't remeber to have seen any such review comments.
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: wd@denx.de
You don't have to stay up nights to succeed; you have to stay awake
days.
^ permalink raw reply
* Re: [PATCH] [POWERPC] 83xx: MPC837xRDB's VSC7385 ethernet switch isn't on the MDIO bus
From: Joakim Tjernlund @ 2008-03-17 22:29 UTC (permalink / raw)
To: Timur Tabi; +Cc: linuxppc-dev
In-Reply-To: <47DEE6CF.7040801@freescale.com>
On Mon, 2008-03-17 at 16:46 -0500, Timur Tabi wrote:
> Joakim Tjernlund wrote:
>
> > Trying to add fixed-link support for ucc_geth as this is broken too. I
> > noticed that ifconfig eth1 up follwed by ifconfig eth1 down hangs
> > my board once I got the ucc_geth driver to recognize fixed-link.
> > Does it work for you?
>
> A long time ago there was a bug where "ifconfig eth1 down" would cause a kernel
> panic if eth0 was also up. The root cause was a bug in rheap.c. However, this
> code was fixed a year ago. Could it be a similar bug?
BTW, I get this on the console:
BUG: soft lockup - CPU#0 stuck for 61s! [ifconfig:263]
NIP: c013649c LR: c0136490 CTR: c0015a34
REGS: c78a9cf0 TRAP: 0901 Not tainted (2.6.25-rc5)
MSR: 00009032 <EE,ME,IR,DR> CR: 24022448 XER: 00000000
TASK = c7822430[263] 'ifconfig' THREAD: c78a8000
GPR00: 00000000 c78a9da0 c7822430 00000000 00000000 00000006 00000000 02400000
GPR08: 00009032 c9062210 c02a0000 00000000 0000000c
NIP [c013649c] ugeth_disable+0x13c/0x18c
LR [c0136490] ugeth_disable+0x130/0x18c
Call Trace:
[c78a9dc0] [c0136c8c] ucc_geth_stop+0x24/0xa0
[c78a9de0] [c01393e8] ucc_geth_close+0x9c/0xd8
[c78a9e00] [c0166f54] dev_close+0xac/0xb0
[c78a9e10] [c0169a7c] dev_change_flags+0x98/0x1c4
[c78a9e30] [c01b4a78] devinet_ioctl+0x668/0x79c
[c78a9eb0] [c01b6a94] inet_ioctl+0xb4/0xc4
[c78a9ec0] [c015a7a4] sock_ioctl+0x174/0x240
[c78a9ee0] [c0072efc] vfs_ioctl+0x88/0x9c
[c78a9ef0] [c0072fc8] do_vfs_ioctl+0xb8/0x400
[c78a9f10] [c0073350] sys_ioctl+0x40/0x74
[c78a9f40] [c000f2b0] ret_from_syscall+0x0/0x38
--- Exception: c01 at 0xff65760
LR = 0xffeae5c
Instruction dump:
91490000 81630000 806b0000 4bedf571 38a0000c 38c00000 7c641b78 38600005
4bedd70d 813e0008 7c0004ac 80090000 <0c000000> 4c00012c 740b2000 4182ffe
Which appear to be the last IN_BE call in ugeth_disable:
7d4: 48 00 00 01 bl 7d4 <ugeth_disable+0x12c>
7d8: 81 3e 00 08 lwz r9,8(r30)
DEF_MMIO_OUT(name, u##size, __stringify(insn)" %1,0,%2")
DEF_MMIO_IN_BE(in_8, 8, lbz);
DEF_MMIO_IN_BE(in_be16, 16, lhz);
DEF_MMIO_IN_BE(in_be32, 32, lwz);
7dc: 7c 00 04 ac sync
7e0: 80 09 00 00 lwz r0,0(r9)
---> 7e4: 0c 00 00 00 twi 0,r0,0
7e8: 4c 00 01 2c isync
7ec: 74 0b 20 00 andis. r11,r0,8192
7f0: 41 82 ff ec beq+ 7dc <ugeth_disable+0x134>
^ permalink raw reply
* Re: [PATCH] net: NEWEMAC: Support for Pause packets in EMAC driver
From: Jeff Garzik @ 2008-03-17 22:31 UTC (permalink / raw)
To: benh; +Cc: netdev, Stefan Roese, linuxppc-dev
In-Reply-To: <1205790747.26869.187.camel@pasglop>
Benjamin Herrenschmidt wrote:
>> There's also the section mismatch patch I sent you. I don't care who's
>> tree they go through, but I'd need to know either way so keep me in the
>> loop please.
>
> Jeff, do you mind if we get those patches through the powerpc tree ?
> EMAC is very powerpc specific and these are mostly internal driver
> cuisine.
Fine with me in concept, though I haven't seen the patches in question.
Jeff
^ permalink raw reply
* Re: [Patch] 8xx: MGSUVD support
From: Scott Wood @ 2008-03-17 22:38 UTC (permalink / raw)
To: Vitaly Bordug; +Cc: linuxppc-dev, hs
In-Reply-To: <20080309195914.69d51e68@kernel.crashing.org>
On Sun, Mar 09, 2008 at 07:59:14PM +0300, Vitaly Bordug wrote:
> I would like all the comments to be consistent C style (because that's it
> for the most other dts'es).
$ fgrep -rI // arch/powerpc/boot/dts/ | wc -l
539
-Scott
^ permalink raw reply
* Re: powerpc: cuImage.* creation error
From: Grant Likely @ 2008-03-17 22:39 UTC (permalink / raw)
To: Adrian Bunk; +Cc: Paul Gortmaker, Paul Mackerras, linux-kernel, linuxppc-dev
In-Reply-To: <20080317193652.GA9550@cs181133002.pp.htv.fi>
On Mon, Mar 17, 2008 at 1:36 PM, Adrian Bunk <bunk@kernel.org> wrote:
> When building all powerpc defconfigs in 2.6.25-rc6 exactly three of
> them fail to build, and all with similar problems:
>
Looks like I added a bogus target (no dts file for the board yet) and
didn't match correctly the init code for the other two. Please try
this:
--- a/arch/powerpc/boot/Makefile
+++ b/arch/powerpc/boot/Makefile
@@ -253,7 +253,6 @@ image-$(CONFIG_TQM8540) += cuImage.tqm85
image-$(CONFIG_TQM8541) += cuImage.tqm8541
image-$(CONFIG_TQM8555) += cuImage.tqm8555
image-$(CONFIG_TQM8560) += cuImage.tqm8560
-image-$(CONFIG_SBC8548) += cuImage.tqm8548
image-$(CONFIG_SBC8560) += cuImage.tqm8560
# Board ports in arch/powerpc/platform/embedded6xx/Kconfig
diff --git a/arch/powerpc/boot/wrapper b/arch/powerpc/boot/wrapper
index d50e498..511e09e 100755
--- a/arch/powerpc/boot/wrapper
+++ b/arch/powerpc/boot/wrapper
@@ -174,7 +174,7 @@ cuboot*)
*-mpc83*)
platformo=$object/cuboot-83xx.o
;;
- *-tqm8541|*-mpc8560*|*-tqm8560|*-tqm8555*)
+ *-tqm854?|*-mpc8560*|*-tqm8560|*-tqm8555*)
platformo=$object/cuboot-85xx-cpm2.o
;;
*-mpc85*)
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply related
* Re: powerpc: cuImage.* creation error
From: Grant Likely @ 2008-03-17 22:41 UTC (permalink / raw)
To: Paul Gortmaker; +Cc: linuxppc-dev, Adrian Bunk, Paul Mackerras, linux-kernel
In-Reply-To: <20080317200754.GA7383@windriver.com>
On Mon, Mar 17, 2008 at 2:07 PM, Paul Gortmaker
<paul.gortmaker@windriver.com> wrote:
> In message: powerpc: cuImage.* creation error
>
> @@ -253,8 +253,8 @@ image-$(CONFIG_TQM8540) += cuImage.tqm8540
> image-$(CONFIG_TQM8541) += cuImage.tqm8541
> image-$(CONFIG_TQM8555) += cuImage.tqm8555
> image-$(CONFIG_TQM8560) += cuImage.tqm8560
> -image-$(CONFIG_SBC8548) += cuImage.tqm8548
> -image-$(CONFIG_SBC8560) += cuImage.tqm8560
> +image-$(CONFIG_SBC8548) += cuImage.sbc8548
> +image-$(CONFIG_SBC8560) += cuImage.sbc8560
No, the suffix in the cuImage targets has a 1:1 relationship with dts
files in arch/powerpc/boot/dts/. If a file doesn't exist there, then
the target cannot be built.
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: powerpc: cuImage.* creation error
From: Paul Gortmaker @ 2008-03-17 22:46 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev, Adrian Bunk, Paul Mackerras, linux-kernel
In-Reply-To: <fa686aa40803171541t6357d304i2e7e5292f084d09d@mail.gmail.com>
In message: Re: powerpc: cuImage.* creation error
on 17/03/2008 Grant Likely wrote:
> On Mon, Mar 17, 2008 at 2:07 PM, Paul Gortmaker
> <paul.gortmaker@windriver.com> wrote:
> > In message: powerpc: cuImage.* creation error
> >
> > @@ -253,8 +253,8 @@ image-$(CONFIG_TQM8540) += cuImage.tqm8540
> > image-$(CONFIG_TQM8541) += cuImage.tqm8541
> > image-$(CONFIG_TQM8555) += cuImage.tqm8555
> > image-$(CONFIG_TQM8560) += cuImage.tqm8560
> > -image-$(CONFIG_SBC8548) += cuImage.tqm8548
> > -image-$(CONFIG_SBC8560) += cuImage.tqm8560
> > +image-$(CONFIG_SBC8548) += cuImage.sbc8548
> > +image-$(CONFIG_SBC8560) += cuImage.sbc8560
>
> No, the suffix in the cuImage targets has a 1:1 relationship with dts
> files in arch/powerpc/boot/dts/. If a file doesn't exist there, then
> the target cannot be built.
You should have both the sbc8548.dts and the sbc8560.dts in your tree.
They have been in there for several weeks now.
I just tested with the above here, and I was just about to hit send on
this extra chunk to fix the second half of the problem.
Note that I didn't lump the tqm8540 in with the other tqm, because the
defconfig tends to indicate it doesn't need 85xx-cpm2; just 85xx.
Thanks,
Paul.
--
Author: Paul Gortmaker <paul.gortmaker@windriver.com>
Date: Mon Mar 17 18:33:52 2008 -0400
wrapper: Add entries for tqm8540 and sbc85xx
The wrapper script didn't have entries for the TQM8540 board and the
SBC8548 or SBC8560 boards. I've assumed that the TQM8540 console is
8250 based and not CPM based by looking at its defconfig. There was
also a trailing * on the TQM8555 entry that I removed too.
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
diff --git a/arch/powerpc/boot/wrapper b/arch/powerpc/boot/wrapper
index d50e498..8ec8ea8 100755
--- a/arch/powerpc/boot/wrapper
+++ b/arch/powerpc/boot/wrapper
@@ -174,7 +174,10 @@ cuboot*)
*-mpc83*)
platformo=$object/cuboot-83xx.o
;;
- *-tqm8541|*-mpc8560*|*-tqm8560|*-tqm8555*)
+ *-tqm8540|*-sbc85*)
+ platformo=$object/cuboot-85xx.o
+ ;;
+ *-tqm8541|*-mpc8560*|*-tqm8560|*-tqm8555)
platformo=$object/cuboot-85xx-cpm2.o
;;
*-mpc85*)
^ permalink raw reply related
* Re: [PATCH v2] 8xx: Add support for the MPC852 based board from keymile.
From: Scott Wood @ 2008-03-17 22:46 UTC (permalink / raw)
To: Heiko Schocher; +Cc: linuxppc-dev, Stephen Rothwell
In-Reply-To: <47DA444E.9050507@denx.de>
On Fri, Mar 14, 2008 at 10:24:30AM +0100, Heiko Schocher wrote:
> + setbits16(&mpc8xx_immr->im_ioport.iop_pcso, 0x300);
> + cpm1_clk_setup(CPM_CLK_SCC3, CPM_CLK5, CPM_CLK_RX);
> + cpm1_clk_setup(CPM_CLK_SCC3, CPM_CLK6, CPM_CLK_TX);
> + setbits32(&mpc8xx_immr->im_cpm.cp_pbpar, 0x300);
> + setbits32(&mpc8xx_immr->im_cpm.cp_pbdir, 0x300);
Any particular reason not to use cpm1_set_pin() rather than those setbits?
> +static void __init mgsuvd_setup_arch(void)
> +{
> + struct device_node *cpu;
> +
> + cpu = of_find_node_by_type(NULL, "cpu");
> + if (cpu != 0) {
> + const unsigned int *fp;
> +
> + fp = of_get_property(cpu, "clock-frequency", NULL);
> + if (fp != 0)
> + loops_per_jiffy = *fp / HZ;
> + else
> + loops_per_jiffy = 50000000 / HZ;
> + of_node_put(cpu);
> + }
> +
This is obsolete and unnecessary.
> + ROOT_DEV = Root_NFS;
Likewise.
> +static int __init mgsuvd_probe(void)
> +{
> + char *model = of_get_flat_dt_prop(of_get_flat_dt_root(),
> + "model", NULL);
> + if (model == NULL)
> + return 0;
> + if (strcmp(model, "MGSUVD"))
> + return 0;
> +
> + return 1;
> +}
Check compatible (using of_flat_dt_is_compatible), not model.
-Scott
^ permalink raw reply
* Re: [PATCH] [POWERPC] 83xx: MPC837xRDB's VSC7385 ethernet switch isn't on the MDIO bus
From: Timur Tabi @ 2008-03-17 23:08 UTC (permalink / raw)
To: joakim.tjernlund; +Cc: linuxppc-dev
In-Reply-To: <1205792537.7589.64.camel@gentoo-jocke.transmode.se>
Joakim Tjernlund wrote:
> eth0 is also up, was it commit 4942bd80e83d13bf394df4a8109bee39d861820f
> that fixed that bug?
Yep. Unfortunately, I don't really know enough about the ucc_geth driver to
know what could be wrong. I just noticed your message and remembered that old bug.
--
Timur Tabi
Linux kernel developer at Freescale
^ permalink raw reply
* Re: powerpc: cuImage.* creation error
From: Grant Likely @ 2008-03-17 23:22 UTC (permalink / raw)
To: Paul Gortmaker; +Cc: linuxppc-dev, Adrian Bunk, Paul Mackerras, linux-kernel
In-Reply-To: <20080317224607.GA10732@windriver.com>
On Mon, Mar 17, 2008 at 4:46 PM, Paul Gortmaker
<paul.gortmaker@windriver.com> wrote:
> In message: Re: powerpc: cuImage.* creation error
>
>
> on 17/03/2008 Grant Likely wrote:
>
> > On Mon, Mar 17, 2008 at 2:07 PM, Paul Gortmaker
> > <paul.gortmaker@windriver.com> wrote:
> > > In message: powerpc: cuImage.* creation error
> > >
> > > @@ -253,8 +253,8 @@ image-$(CONFIG_TQM8540) += cuImage.tqm8540
> > > image-$(CONFIG_TQM8541) += cuImage.tqm8541
> > > image-$(CONFIG_TQM8555) += cuImage.tqm8555
> > > image-$(CONFIG_TQM8560) += cuImage.tqm8560
> > > -image-$(CONFIG_SBC8548) += cuImage.tqm8548
> > > -image-$(CONFIG_SBC8560) += cuImage.tqm8560
> > > +image-$(CONFIG_SBC8548) += cuImage.sbc8548
> > > +image-$(CONFIG_SBC8560) += cuImage.sbc8560
> >
> > No, the suffix in the cuImage targets has a 1:1 relationship with dts
> > files in arch/powerpc/boot/dts/. If a file doesn't exist there, then
> > the target cannot be built.
>
> You should have both the sbc8548.dts and the sbc8560.dts in your tree.
> They have been in there for several weeks now.
Heh; oops. I looked but somehow missed them. I guess I didn't look
hard enough.
Yes, this looks like the right solution.
> Author: Paul Gortmaker <paul.gortmaker@windriver.com>
> Date: Mon Mar 17 18:33:52 2008 -0400
>
> wrapper: Add entries for tqm8540 and sbc85xx
>
> The wrapper script didn't have entries for the TQM8540 board and the
> SBC8548 or SBC8560 boards. I've assumed that the TQM8540 console is
> 8250 based and not CPM based by looking at its defconfig. There was
> also a trailing * on the TQM8555 entry that I removed too.
>
>
> Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
Acked-by: Grant Likely <grant.likely@secretlab.ca>
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: [PATCH] arch/powerpc/platforms/iseries/pci.c: Use time_* macros
From: Stephen Rothwell @ 2008-03-17 23:31 UTC (permalink / raw)
To: S.Çağlar Onur
Cc: linuxppc-dev, Andrew Morton, Paul Mackerras, linux-kernel
In-Reply-To: <1205746593-24820-4-git-send-email-caglar@pardus.org.tr>
[-- Attachment #1: Type: text/plain, Size: 699 bytes --]
On Mon, 17 Mar 2008 11:36:26 +0200 S.Çağlar Onur <caglar@pardus.org.tr> wrote:
>
> The functions time_before, time_before_eq, time_after, and time_after_eq are more robust for comparing jiffies against other values.
>
> So following patch implements usage of the time_after() macro, defined at linux/jiffies.h, which deals with wrapping correctly
>
> Cc: linuxppc-dev@ozlabs.org
> Cc: Paul Mackerras <paulus@samba.org>
> Cc: Andrew Morton <akpm@linux-foundation.org>
> Signed-off-by: S.Çağlar Onur <caglar@pardus.org.tr>
Acked-by: Stephen Rothwell <sfr@canb.auug.org.au>
--
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: Please pull linux-2.6-mpc52xx.git
From: Grant Likely @ 2008-03-17 23:43 UTC (permalink / raw)
To: Wolfgang Denk; +Cc: linuxppc-dev
In-Reply-To: <20080317222836.AFA66241A2@gemini.denx.de>
On Mon, Mar 17, 2008 at 4:28 PM, Wolfgang Denk <wd@denx.de> wrote:
> In message <fa686aa40803171443q7a53f0balbb49740116c6552@mail.gmail.com> you wrote:
>
> * The TQM5200 configuration as provided is intended for shipping as
> default configuration for this board. The "engineer responsible"
> already *did* the tailoring and put that state in the defconfig
> file.
>
> * The CM5200 and Motion-Pro boards are custom designs, where the
> defconfig file matches exactly the requirements of the respective
> customers.
>
> I feel it is very important to be able to include this configuration
> information somewhere with the kernel source tree - and to me the
> defconfig file for a board is the most natural place to put such
> information.
(copied from my comments in an off-list conversation)
However, I have declined (for now) to pick up the defconfigs for those
boards and instead merged in the config features they require into the
mpc5200 defconfig. My primary reason for doing so is to increase the
likelyhood that full featured kernels are built and tested so that
situations where board ports conflict with each other are caught and
fixed.
ojn has also been complaining about the number of defconfigs he needs
to build to test all the powerpc configurations without any
indications about which ones are important and which ones are not.
There has been some discussion about having a subdirectory for
optimized board configs, but nobody has done anything about it yet.
The one part that I have a really strong opinion on is that there
should be a full featured mpc5200 defconfig for build testing. Beyond
that (and if ojn can also be appeased) I can probably be convinced. :-)
> > All these boards are supported with
> > arch/powerpc/platforms/mpc5200_simple.c. A kernel built for that
> > platform will boot on any of those boards as long as it is passed the
> > correct device tree.
>
> I don't doubt that the kernel will boot. But that does not mean that
> it is ready for use for the intended purpose. For example,
> arch/powerpc/platforms/52xx/motionpro.c contains code to setup some
> custom LEDs on this board. I can't find that code in
>
> arch/powerpc/platforms/mpc5200_simple.c.
>
> It may be argued that this code should be moved somewhere else, but I
> don't remeber to have seen any such review comments.
The LED code just hasn't been picked up. IIRC, it was reworked to
make it a proper driver in drivers/leds. I need to look at it again,
but it is a lot of code for a very simple thing and I wasn't sure if I
should be the one to pick it up because it is in drivers/leds which
has a different maintainer.
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: [PATCH] [POWERPC] 83xx: MPC837xRDB's VSC7385 ethernet switch isn't on the MDIO bus
From: Joakim Tjernlund @ 2008-03-17 23:53 UTC (permalink / raw)
To: Timur Tabi; +Cc: linuxppc-dev
In-Reply-To: <47DEF9E7.5030808@freescale.com>
On Mon, 2008-03-17 at 18:08 -0500, Timur Tabi wrote:
> Joakim Tjernlund wrote:
>
> > eth0 is also up, was it commit 4942bd80e83d13bf394df4a8109bee39d861820f
> > that fixed that bug?
>
> Yep. Unfortunately, I don't really know enough about the ucc_geth driver to
> know what could be wrong. I just noticed your message and remembered that old bug.
>
I noticed that ugeth_graceful_stop_rx() is lacking in_8()/out_8() so I
am adding that, but I cant test until tmw.
Also notice that there is a lot of in_beX()/out_beX() in the driver and
those functions use the sync instruction. Won't that much suny usage
hurt performance and is sync really needed?
Jocke
^ permalink raw reply
* Re: [PATCH] net: NEWEMAC: Support for Pause packets in EMAC driver
From: Benjamin Herrenschmidt @ 2008-03-17 23:55 UTC (permalink / raw)
To: Jeff Garzik; +Cc: netdev, Stefan Roese, linuxppc-dev
In-Reply-To: <47DEF159.3020504@garzik.org>
On Mon, 2008-03-17 at 18:31 -0400, Jeff Garzik wrote:
> > Jeff, do you mind if we get those patches through the powerpc tree ?
> > EMAC is very powerpc specific and these are mostly internal driver
> > cuisine.
>
> Fine with me in concept, though I haven't seen the patches in
> question.
Yup, I've asked people to copy you on them so you get a chance to ack
them :-)
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH v2] pasemi_dma: Driver for PA Semi PWRficient on-chip DMAengine
From: Olof Johansson @ 2008-03-18 0:21 UTC (permalink / raw)
To: Nelson, Shannon
Cc: hskinnemoen, Sosnowski, Maciej, linux-kernel, linuxppc-dev,
pasemi-linux, Williams, Dan J
In-Reply-To: <BAE9DCEF64577A439B3A37F36F9B691C043E6716@orsmsx418.amr.corp.intel.com>
Hi,
On Mon, Mar 17, 2008 at 01:34:05PM -0700, Nelson, Shannon wrote:
> In the future please copy Maciej as one of "the DMA guys" as he has
> taken over ioatdma for me. Beyond that, one little picky comment
> below...
Time to set up a list, or have everyone monitor lkml, I'd say. I'd
prefer the former.
> >+static unsigned int channels = 4;
> >+module_param(channels, uint, S_IRUGO);
> >+MODULE_PARM_DESC(channels, "Number of channels for copy
> >(default: 2)");
>
> Is the number of channels defaulting to 2 or 4?
Ah, yes, good catch.
-Olof
^ 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