* Re: [PATCH] Fix PMU + soft interrupt disable bug
From: Olof Johansson @ 2008-03-18 0:36 UTC (permalink / raw)
To: Anton Blanchard; +Cc: linuxppc-dev, paulus
In-Reply-To: <20080317042709.GA10594@kryten>
On Sun, Mar 16, 2008 at 11:27:09PM -0500, Anton Blanchard wrote:
>
> Since the PMU is an NMI now, it can come at any time we are only soft
> disabled. We must hard disable around the two places we allow the kernel
> stack SLB and r1 to go out of sync. Otherwise the PMU exception can
> force a kernel stack SLB into another slot.
>
> Signed-off-by: Anton Blanchard <anton@samba.org>
Acked-by: Olof Johansson <olof@lixom.net>
This fixes some problems we've seen with multi-slb hits when running
oprofile.
^ permalink raw reply
* Re: [Patch] 8xx: MGSUVD support
From: Vitaly Bordug @ 2008-03-18 0:27 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev, hs
In-Reply-To: <20080317223821.GA3622@loki.buserror.net>
On Mon, 17 Mar 2008 17:38:21 -0500
Scott Wood wrote:
> 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
>
So, we should go ahead and add a bit more hassle :) ?
By consistent C style I mean:
+ clock-frequency = <0>; /* Filled in by u-boot */ */
+ interrupts = <f 2>; // decrementer interrupt
using either one or other way for same-type comments.
-Vitaly
^ permalink raw reply
* Re: [PATCH v2] pasemi_dma: Driver for PA Semi PWRficient on-chip DMA engine
From: Olof Johansson @ 2008-03-18 0:27 UTC (permalink / raw)
To: Dan Williams
Cc: linuxppc-dev, pasemi-linux, shannon.nelson, linux-kernel,
hskinnemoen
In-Reply-To: <e9c3a7c20803171146m5a7f0e11m31e074634de22b42@mail.gmail.com>
On Mon, Mar 17, 2008 at 11:46:39AM -0700, Dan Williams wrote:
> Looks good, makes me want to go back and cleanup iop-adma a bit. A
> few fyi's below, but no other review comments.
>
> > Note that this still needs to go on top of the powerpc.git tree due to the
> > pasemi_dma.h updates that this driver depends on. I suggest merging this
> > through pasemi.git->powerpc.git->linus with an Acked-by from the DMA guys.
>
> Ok, it still may not compile in mainline until after 2.6.26-rc1 due to
> additional dmaengine cleanups like the ack-to-flags change I posted
> earlier. Any better way to handle this? Go through -mm?
Either go through -mm where Andrew can keep it applied in appropriate
order and send upstream, or just merge it late. It's a new driver, and
they're normally OK to go in a little later. That might be the easiest
solution in this case.
> Acked-by: Dan Williams <dan.j.williams@intel.com>
Thanks!
-Olof
^ permalink raw reply
* Re: [PATCH v2] Force 4K pages for IO addresses.
From: Olof Johansson @ 2008-03-18 0:34 UTC (permalink / raw)
To: Tony Breeds
Cc: LinuxPPC-dev, Jan-Bernd Themann, Paul Mackerras, Stephen Rothwell
In-Reply-To: <20080317035419.GH6887@bakeyournoodle.com>
On Mon, Mar 17, 2008 at 02:54:19PM +1100, Tony Breeds wrote:
> Currently HEA requires 4K pages for IO resources. Just set the pages size to
> IO to 4K.
Well, that's too bad. Why penalize all platforms for it?
I.e.: Nack, we use 64K iopages on pa6t and it works well. No need to
waste tlb and erat space.
-Olof
^ permalink raw reply
* Re: Please pull linux-2.6-mpc52xx.git
From: Wolfgang Denk @ 2008-03-18 0:26 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev
In-Reply-To: <fa686aa40803171643y7db21cadsc454a713ba6c4342@mail.gmail.com>
Dear Grant,
in message <fa686aa40803171643y7db21cadsc454a713ba6c4342@mail.gmail.com> you wrote:
>
> 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.
I know what you mean, and I agree with the idea.
Unfortunately I think it's impossible to implement, especially on such
embedded processors with their high level of pin multiplexing.
For example, if you want to include testing of the FEC ethernet
driver, you will probably fail to test the second USB port. I think
it's simply not possible to test all possible options in a single
kernel configuration - first it doesn't work (for example because of
pin multiplexing issues), second you will likely not be able to find
hardware that implements all features at once.
My dream is to have a distributed test environment - a framework
which can be used for automatic testing which includes building and
running the code on a set of systems, and which will then report the
test results to a central location.
We have the same problem (probably to a much higher degree) in
U-Boot; nobody can test all board configurations because nobody has
all the cross-tools installed nor the 500+ boards available.
> 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.
again, some distributed test tool might help - we would get not only
information abouyt test results, but also which configurations have
been tested how frequently.
> There has been some discussion about having a subdirectory for
> optimized board configs, but nobody has done anything about it yet.
Is this a hint?
> 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. :-)
Maybe my expectations for "full featured' are just too high..
> 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.
I see. Thanks.
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
If some day we are defeated, well, war has its fortunes, good and
bad.
-- Commander Kor, "Errand of Mercy", stardate 3201.7
^ 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
* 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] [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: 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] 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: 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] [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: [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: 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: 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: 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: [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: [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] [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: 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: 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: [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: [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: 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: 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
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