LinuxPPC-Dev Archive on lore.kernel.org
 help / color / mirror / Atom feed
* Re: [PATCH 00/33] My PS3-specific patches for 2.6.31
From: Benjamin Herrenschmidt @ 2009-06-11  1:35 UTC (permalink / raw)
  To: michael; +Cc: linuxppc-dev list, Gary Thomas
In-Reply-To: <1244683951.4674.5.camel@concordia>

On Thu, 2009-06-11 at 11:32 +1000, Michael Ellerman wrote:
> The way I think of it is that the "merge window" is the time for
> maintainers to merge with Linus.
> 
> So if you're sending patches to a maintainer you need to have sent all
> your patches to them _before_ then. So the merge window for you is the
> weeks prior to the "merge window".

Right. But a patch generally needs time to be reviewed, spun several
times, etc... so just the week before the merge window is probably too
late :-)

A good rule is that people should start sending things to the list for
review about one kernel release in advance :-)

Now, -rc4 should generally be the wakeup call. It's when I start
frowning even on bug fixes, and putting together a next branch, at least
normally. I can be flexible but people need to try to play nicely too.

Cheers,
Ben.

^ permalink raw reply

* Re: [PATCH 4/4] MPC85xx: Add UCC6 and UCC8 nodes in SGMII mode for MPC8569MDS
From: Kumar Gala @ 2009-06-11  1:35 UTC (permalink / raw)
  To: David Miller; +Cc: linuxppc-dev, netdev, Haiying.Wang
In-Reply-To: <20090603.035132.157926180.davem@davemloft.net>


On Jun 3, 2009, at 5:51 AM, David Miller wrote:

> From: Haiying Wang <Haiying.Wang@freescale.com>
> Date: Tue,  2 Jun 2009 10:04:16 -0400
>
>> Signed-off-by: Haiying Wang <Haiying.Wang@freescale.com>
>
> I couldn't apply this to net-next-2.6 because this DTS
> file being patched doesn't exist there.
>
> Perhaps the powerpc-next tree can suck it in...

I'll pick this one up and send it via the powerpc tree.

- k

^ permalink raw reply

* linux-next: powerpc tree build warning
From: Stephen Rothwell @ 2009-06-11  1:39 UTC (permalink / raw)
  To: Benjamin Herrenschmidt
  Cc: linuxppc-dev, linux-next, Paul Mackerras, linux-kernel

[-- Attachment #1: Type: text/plain, Size: 373 bytes --]

Hi Ben,

Today's linux-next build (powerpc ppc64_defconfig) produced this warning:

arch/powerpc/platforms/Kconfig.cputype:60:warning: defaults for choice values not supported

We appear to have CONFIG_PPC_BOOK3S int two places which is confusing
Kconfig.

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

^ permalink raw reply

* Re: [PATCH v2] Add MSI interrupts to DTS of MPC8315E-RDB
From: Kumar Gala @ 2009-06-11  1:50 UTC (permalink / raw)
  To: leon.woestenberg; +Cc: Leon Woestenberg, linux-kernel, linuxppc-dev
In-Reply-To: <4a2a9611.06c8100a.49ae.ffff88e4@mx.google.com>


On Jun 6, 2009, at 11:15 AM, leon.woestenberg@gmail.com wrote:

> The PCIe MSI interrupts are missing from the device tree source, and
> thus were not enabled. This patch adds them.
>
> v2 of the patch fixes inconsistent white space, reported by David  
> Gibson.
>
> Tested to work on MPC8315E-RDB with custom FPGA PCIe device.
>
> Signed-off-by: Leon Woestenberg <leon@sidebranch.com>
> Tested-by: Leon Woestenberg <leon@sidebranch.com>

applied to next.

- k

^ permalink raw reply

* Re: [PATCH] powerpc/86xx: Add I2C device mappings in DTS for SBC610
From: Kumar Gala @ 2009-06-11  1:50 UTC (permalink / raw)
  To: Martyn Welch; +Cc: linuxppc-dev
In-Reply-To: <20090519094057.11438.12921.stgit@ES-J7S4D2J>


On May 19, 2009, at 4:40 AM, Martyn Welch wrote:

> Mappings for temperature sensors (adt7461 and lm92) are missing from  
> the
> SBC610's DTS file.
>
> Signed-off-by: Martyn Welch <martyn.welch@gefanuc.com>
> ---
>
> arch/powerpc/boot/dts/gef_sbc610.dts |   10 ++++++++++
> 1 files changed, 10 insertions(+), 0 deletions(-)


applied to next.

- k

^ permalink raw reply

* Re: [PATCH] powerpc/83xx: Update sdhci nodes per new bindings
From: Kumar Gala @ 2009-06-11  1:51 UTC (permalink / raw)
  To: Anton Vorontsov; +Cc: linuxppc-dev
In-Reply-To: <20090610151926.GA32386@oksana.dev.rtsoft.ru>


On Jun 10, 2009, at 10:19 AM, Anton Vorontsov wrote:

> As of commit 404614728f857d0ac63d29c3a29d0cf392a15598 ("Update FSL
> esdhc binding"), we use "fsl,esdhc" compatible entry as a base
> match. U-Boot will use the same compatible to fixup esdhc nodes.
>
> This patch updates 83xx dts files so that they conform to the new
> bindings.
>
> Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
> ---
> arch/powerpc/boot/dts/mpc8377_mds.dts |    2 +-
> arch/powerpc/boot/dts/mpc8377_rdb.dts |    2 +-
> arch/powerpc/boot/dts/mpc8378_mds.dts |    2 +-
> arch/powerpc/boot/dts/mpc8378_rdb.dts |    2 +-
> arch/powerpc/boot/dts/mpc8379_mds.dts |    2 +-
> arch/powerpc/boot/dts/mpc8379_rdb.dts |    2 +-
> 6 files changed, 6 insertions(+), 6 deletions(-)


applied to next.

- k

^ permalink raw reply

* Re: [PATCH 4/4] MPC85xx: Add UCC6 and UCC8 nodes in SGMII mode for MPC8569MDS
From: Kumar Gala @ 2009-06-11  1:51 UTC (permalink / raw)
  To: Haiying Wang; +Cc: linuxppc-dev, davem, netdev
In-Reply-To: <1243951456-4685-4-git-send-email-Haiying.Wang@freescale.com>


On Jun 2, 2009, at 9:04 AM, Haiying Wang wrote:

> Signed-off-by: Haiying Wang <Haiying.Wang@freescale.com>
> ---
> arch/powerpc/boot/dts/mpc8569mds.dts |   63 +++++++++++++++++++++++++ 
> +++++++++
> 1 files changed, 63 insertions(+), 0 deletions(-)


applied to next.

- k

^ permalink raw reply

* Re: [PATCH] [PowerPC] MPC8272ADS: fix device tree for 8 MB flash size
From: Kumar Gala @ 2009-06-11  1:51 UTC (permalink / raw)
  To: Wolfgang Denk; +Cc: Scott Wood, linuxppc-dev, linux-kernel
In-Reply-To: <1242155174-2513-1-git-send-email-wd@denx.de>


On May 12, 2009, at 2:06 PM, Wolfgang Denk wrote:

> The current device tree for the MPC8272ADS assumes a mapping of 32 MB
> of NOR flash at 0xFE00.0000, while there are actually only 8 MB on
> the boards, mapped at 0xFF80.0000. When booting an uImage with such a
> device tree, the kernel crashes because 0xFE00.0000 is not mapped.
>
> Also introduce aliases for serial[01] and ethernet[01].
>
> Signed-off-by: Wolfgang Denk <wd@denx.de>
> Cc: Scott Wood <scottwood@freescale.com>
> cc: Kumar Gala <galak@kernel.crashing.org>
> ---
> I am not really sure what the typical flash size on MPC8272ADS boards
> is. The board I used for testing is marked as "Prototype", so it may
> not be the release configuration. On the other hand, the manual also
> says 8 MB, Vitaly Borduk confirms 8 MB on his board, too, and Scott
> Wood eventually tested only with cuImage which fixes up the localbus
> mappings, thus eventually concealing the issue.
>
> I'm posting this as reference in case the 8 MB should turn out to be
> correct. -- wd
>
> arch/powerpc/boot/dts/mpc8272ads.dts |   19 +++++++++++++------
> 1 files changed, 13 insertions(+), 6 deletions(-)


applied to next.

- k

^ permalink raw reply

* Re: [PATCH] Re:[BUILD FAILURE 04/04] Next June 04:PPC64 randconfig [drivers/net/ucc_geth.o]
From: Subrata Modak @ 2009-06-11  1:56 UTC (permalink / raw)
  To: Stephen Rothwell, netdev, Li Yang
  Cc: Sachin P Sant, Linuxppc-dev, Linux-Next, Linux-Kernel,
	Balbir Singh
In-Reply-To: <20090611110523.1fd56a41.sfr@canb.auug.org.au>

On Thu, 2009-06-11 at 11:05 +1000, Stephen Rothwell wrote:
> Hi Subrata,
> 
> On Wed, 10 Jun 2009 23:13:23 +0530 Subrata Modak <subrata@linux.vnet.ibm.com> wrote:
> >
> >  	/* Find the TBI PHY.  If it's not there, we don't support SGMII */
> > -	ph = of_get_property(np, "tbi-handle", NULL);
> > +	ph = (phandle *)of_get_property(np, "tbi-handle", NULL);
> 
> You don't need this cast because of_get_property() returns "void *".

Stephen,

True. But without this gcc complains:

CC [M]  drivers/net/ucc_geth.o
drivers/net/ucc_geth.c: In function ‘ucc_geth_probe’:
drivers/net/ucc_geth.c:3824: warning: assignment discards qualifiers
from pointer target type

Else gcc just builds fine:

CC [M]  drivers/net/ucc_geth.o

This is an just an extra caution to fix both the build and warning
regression(s).

Regards--
Subrata

> 

^ permalink raw reply

* Re: [PATCH 00/33] My PS3-specific patches for 2.6.31
From: Michael Ellerman @ 2009-06-11  2:01 UTC (permalink / raw)
  To: Benjamin Herrenschmidt; +Cc: linuxppc-dev list, Gary Thomas
In-Reply-To: <1244684128.5739.30.camel@pasglop>

[-- Attachment #1: Type: text/plain, Size: 1170 bytes --]

On Thu, 2009-06-11 at 11:35 +1000, Benjamin Herrenschmidt wrote:
> On Thu, 2009-06-11 at 11:32 +1000, Michael Ellerman wrote:
> > The way I think of it is that the "merge window" is the time for
> > maintainers to merge with Linus.
> > 
> > So if you're sending patches to a maintainer you need to have sent all
> > your patches to them _before_ then. So the merge window for you is the
> > weeks prior to the "merge window".
> 
> Right. But a patch generally needs time to be reviewed, spun several
> times, etc... so just the week before the merge window is probably too
> late :-)

Sure. I mean that's when you should be sending polished code that's
ready to merge. In the same way that the maintainers are sending
polished ready to merge code to Linus during the merge window.

But absolutely, most patches need to be reviewed at least once before
they're ready, which is probably a week at best.


But really people should just be sending patches ASAP, even if they're
not 100% finished, so they get as much exposure as early as possible.

Sitting on patches waiting for the "right time" to send them is the
wrong approach IMHO.

cheers

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

^ permalink raw reply

* Re: [PATCH] Re:[BUILD FAILURE 04/04] Next June 04:PPC64 randconfig [drivers/net/ucc_geth.o]
From: Michael Ellerman @ 2009-06-11  2:03 UTC (permalink / raw)
  To: subrata
  Cc: Sachin P Sant, Stephen Rothwell, netdev, Linux-Kernel,
	Linuxppc-dev, Linux-Next, Li Yang, Balbir Singh
In-Reply-To: <1244685364.6494.14.camel@subratamodak.linux.ibm.com>

[-- Attachment #1: Type: text/plain, Size: 940 bytes --]

On Thu, 2009-06-11 at 07:26 +0530, Subrata Modak wrote:
> On Thu, 2009-06-11 at 11:05 +1000, Stephen Rothwell wrote:
> > Hi Subrata,
> > 
> > On Wed, 10 Jun 2009 23:13:23 +0530 Subrata Modak <subrata@linux.vnet.ibm.com> wrote:
> > >
> > >  	/* Find the TBI PHY.  If it's not there, we don't support SGMII */
> > > -	ph = of_get_property(np, "tbi-handle", NULL);
> > > +	ph = (phandle *)of_get_property(np, "tbi-handle", NULL);
> > 
> > You don't need this cast because of_get_property() returns "void *".
> 
> Stephen,
> 
> True. But without this gcc complains:
> 
> CC [M]  drivers/net/ucc_geth.o
> drivers/net/ucc_geth.c: In function ‘ucc_geth_probe’:
> drivers/net/ucc_geth.c:3824: warning: assignment discards qualifiers from pointer target type
                                                           ^^^^^^^^^^^

And what does that warning actually mean?

Your cast actually introduces a bug.

cheers

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

^ permalink raw reply

* [PATCH][Resend][BUILD FAILURE 04/04] Next June 04:PPC64 randconfig [drivers/net/ucc_geth.o]
From: Subrata Modak @ 2009-06-11  2:13 UTC (permalink / raw)
  To: michael, netdev, Li Yang, Stephen Rothwell
  Cc: Sachin P Sant, Linux-Kernel, Linuxppc-dev, Linux-Next,
	Subrata Modak, Balbir Singh

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2274 bytes --]

Hi Michael,

>On Thu, 2009-06-11 at 12:03 +1000, Michael Ellerman wrote:
>On Thu, 2009-06-11 at 07:26 +0530, Subrata Modak wrote:
> > On Thu, 2009-06-11 at 11:05 +1000, Stephen Rothwell wrote:
> > > Hi Subrata,
> > > 
> > > On Wed, 10 Jun 2009 23:13:23 +0530 Subrata Modak <subrata@linux.vnet.ibm.com> wrote:
> > > >
> > > >  	/* Find the TBI PHY.  If it's not there, we don't support SGMII */
> > > > -	ph = of_get_property(np, "tbi-handle", NULL);
> > > > +	ph = (phandle *)of_get_property(np, "tbi-handle", NULL);
> > > 
> > > You don't need this cast because of_get_property() returns "void *".
> > 
> > Stephen,
> > 
> > True. But without this gcc complains:
> > 
> > CC [M]  drivers/net/ucc_geth.o
> > drivers/net/ucc_geth.c: In function ‘ucc_geth_probe’:
> > drivers/net/ucc_geth.c:3824: warning: assignment discards qualifiers from pointer target type
>                                                            ^^^^^^^^^^^
> 
> And what does that warning actually mean?
> 
> Your cast actually introduces a bug.
>

Ok fine. Here is a revised patch.

Subject: [PATCH][Resend][BUILD FAILURE 04/04] Next June 04:PPC64 randconfig [drivers/net/ucc_geth.o]
Reference(s):
http://lkml.org/lkml/2009/6/4/241,
http://lkml.org/lkml/2009/6/10/338,

Fix the following build error:

drivers/net/ucc_geth.c: In function bucc_geth_probeb:
drivers/net/ucc_geth.c:3822: error: 'ph' undeclared (first use in this function)
drivers/net/ucc_geth.c:3822: error: (Each undeclared identifier is reported only once
drivers/net/ucc_geth.c:3822: error: for each function it appears in.)
drivers/net/ucc_geth.c:3832: error: 'mdio' undeclared (first use in this function)
make[2]: *** [drivers/net/ucc_geth.o] Error 1

Signed-off-by: Subrata Modak <subrata@linux.vnet.ibm.com>
---

--- linux-2.6.30-rc8/drivers/net/ucc_geth.c.orig	2009-06-10 11:58:39.000000000 -0500
+++ linux-2.6.30-rc8/drivers/net/ucc_geth.c	2009-06-10 20:53:25.000000000 -0500
@@ -3595,6 +3595,8 @@ static const struct net_device_ops ucc_g
 
 static int ucc_geth_probe(struct of_device* ofdev, const struct of_device_id *match)
 {
+	struct device_node *mdio;
+	phandle *ph;
 	struct device *device = &ofdev->dev;
 	struct device_node *np = ofdev->node;
 	struct net_device *dev = NULL;

---
Regards--
Subrata

> cheers

^ permalink raw reply

* Re: [PATCH] Re:[BUILD FAILURE 04/04] Next June 04:PPC64 randconfig [drivers/net/ucc_geth.o]
From: Tony Breeds @ 2009-06-11  2:22 UTC (permalink / raw)
  To: Subrata Modak
  Cc: Sachin P Sant, Stephen Rothwell, netdev, Linux-Kernel,
	Linuxppc-dev, Linux-Next, Li Yang, Balbir Singh
In-Reply-To: <1244685364.6494.14.camel@subratamodak.linux.ibm.com>

On Thu, Jun 11, 2009 at 07:26:04AM +0530, Subrata Modak wrote:
> On Thu, 2009-06-11 at 11:05 +1000, Stephen Rothwell wrote:
> > Hi Subrata,
> > 
> > On Wed, 10 Jun 2009 23:13:23 +0530 Subrata Modak <subrata@linux.vnet.ibm.com> wrote:
> > >
> > >  	/* Find the TBI PHY.  If it's not there, we don't support SGMII */
> > > -	ph = of_get_property(np, "tbi-handle", NULL);
> > > +	ph = (phandle *)of_get_property(np, "tbi-handle", NULL);
> > 
> > You don't need this cast because of_get_property() returns "void *".
> 
> Stephen,
> 
> True. But without this gcc complains:
> 
> CC [M]  drivers/net/ucc_geth.o
> drivers/net/ucc_geth.c: In function ‘ucc_geth_probe’:
> drivers/net/ucc_geth.c:3824: warning: assignment discards qualifiers
> from pointer target type
> 
> Else gcc just builds fine:
> 
> CC [M]  drivers/net/ucc_geth.o
> 
> This is an just an extra caution to fix both the build and warning
> regression(s).

ph needs to be const.

I think the following untested (and hence un-signed-off-by) patch is closer,
however I also think that the whole SGMII setup code could use the various OF
helper functions better :)

diff --git a/drivers/net/ucc_geth.c b/drivers/net/ucc_geth.c
index e2f2e91..796253d 100644
--- a/drivers/net/ucc_geth.c
+++ b/drivers/net/ucc_geth.c
@@ -3603,6 +3603,7 @@ static int ucc_geth_probe(struct of_device* ofdev, const struct of_device_id *ma
 	struct resource res;
 	struct device_node *phy;
 	int err, ucc_num, max_speed = 0;
+	const phandle *ph;
 	const u32 *fixed_link;
 	const unsigned int *prop;
 	const char *sprop;
@@ -3821,7 +3822,7 @@ static int ucc_geth_probe(struct of_device* ofdev, const struct of_device_id *ma
 	/* Find the TBI PHY.  If it's not there, we don't support SGMII */
 	ph = of_get_property(np, "tbi-handle", NULL);
 	if (ph) {
-		struct device_node *tbi = of_find_node_by_phandle(*ph);
+		struct device_node *tbi = of_find_node_by_phandle(*ph), *mdio;
 		struct of_device *ofdev;
 		struct mii_bus *bus;
 		const unsigned int *id;

Yours Tony

^ permalink raw reply related

* Re: [PATCH] powerpc/85xx: add nor flash partitions for mpc8569mds
From: Kumar Gala @ 2009-06-11  2:20 UTC (permalink / raw)
  To: Kevin Hao; +Cc: linuxppc-dev, Haiying Wang
In-Reply-To: <1243389905.13410.6.camel@kevin>


On May 26, 2009, at 9:05 PM, Kevin Hao wrote:

> Add 4 partitions in nor flash. Also fix nor flash
> bank width bug.

Can you explain this.. I'm trying to understand why you set the bank- 
width to 1

- k

>
>
> Signed-off-by: Kevin Hao <kexin.hao@windriver.com>
> ---
> arch/powerpc/boot/dts/mpc8569mds.dts |   24 +++++++++++++++++++++++-
> 1 files changed, 23 insertions(+), 1 deletions(-)
>
> diff --git a/arch/powerpc/boot/dts/mpc8569mds.dts b/arch/powerpc/ 
> boot/dts/mpc8569mds.dts
> index 39c2927..1f98990 100644
> --- a/arch/powerpc/boot/dts/mpc8569mds.dts
> +++ b/arch/powerpc/boot/dts/mpc8569mds.dts
> @@ -70,8 +70,30 @@
> 			#size-cells = <1>;
> 			compatible = "cfi-flash";
> 			reg = <0x0 0x0 0x02000000>;
> -			bank-width = <2>;
> +			bank-width = <1>;
> 			device-width = <1>;
> +			partition@0 {
> +				label = "ramdisk";
> +				reg = <0x00000000 0x01c00000>;
> +			};
> +			partition@1c00000 {
> +				label = "kernel";
> +				reg = <0x01c00000 0x002e0000>;
> +			};
> +			partiton@1ee0000 {
> +				label = "dtb";
> +				reg = <0x01ee0000 0x00020000>;
> +			};
> +			partition@1f00000 {
> +				label = "firmware";
> +				reg = <0x01f00000 0x00080000>;
> +				read-only;
> +			};
> +			partition@1f80000 {
> +				label = "u-boot";
> +				reg = <0x01f80000 0x00080000>;
> +				read-only;
> +			};
> 		};
>
> 		bcsr@1,0 {
> -- 
> 1.6.0.4.771.gef3b3

^ permalink raw reply

* Re: [PATCH] Re:[BUILD FAILURE 04/04] Next June 04:PPC64 randconfig [drivers/net/ucc_geth.o]
From: Nathan Lynch @ 2009-06-11  2:28 UTC (permalink / raw)
  To: subrata
  Cc: Sachin P Sant, Stephen Rothwell, netdev, Linux-Kernel,
	Linuxppc-dev, Linux-Next, Li Yang, Balbir Singh
In-Reply-To: <1244685364.6494.14.camel@subratamodak.linux.ibm.com>

Subrata Modak <subrata@linux.vnet.ibm.com> writes:

> On Thu, 2009-06-11 at 11:05 +1000, Stephen Rothwell wrote:
>> Hi Subrata,
>>=20
>> On Wed, 10 Jun 2009 23:13:23 +0530 Subrata Modak <subrata@linux.vnet.ibm=
.com> wrote:
>> >
>> >  	/* Find the TBI PHY.  If it's not there, we don't support SGMII */
>> > -	ph =3D of_get_property(np, "tbi-handle", NULL);
>> > +	ph =3D (phandle *)of_get_property(np, "tbi-handle", NULL);
>>=20
>> You don't need this cast because of_get_property() returns "void *".
>
> Stephen,
>
> True. But without this gcc complains:
>
> CC [M]  drivers/net/ucc_geth.o
> drivers/net/ucc_geth.c: In function =E2=80=98ucc_geth_probe=E2=80=99:
> drivers/net/ucc_geth.c:3824: warning: assignment discards qualifiers
> from pointer target type

ph should be declared const phandle *.  Look at other uses of
of_get_property.

^ permalink raw reply

* Re: [PATCH v2] 83xx: add support for the kmeter1 board.
From: Kumar Gala @ 2009-06-11  2:43 UTC (permalink / raw)
  To: hs; +Cc: Scott Wood, linuxppc-dev
In-Reply-To: <49F7DC0C.3080409@denx.de>


On Apr 28, 2009, at 11:48 PM, Heiko Schocher wrote:

> The following series implements basic board support for
> the kmeter1 board from keymile, based on a MPC8360.
>
> This series provides the following functionality:
>
> - The board can boot with a serial console on UART1
> - Ethernet:
>    UCC1 in RGMII mode
>    UCC2 in RGMII mode
>    UCC4 in RMII mode
>    UCC5 in RMII mode
>    UCC6 in RMII mode
>    UCC7 in RMII mode
>    UCC8 in RMII mode
>
>    following patch is necessary for working UCC in RMII mode:
>
>    http://ozlabs.org/pipermail/linuxppc-dev/2009-April/070909.html
>
> - Flash accessed via MTD layer
>
>  On this hardware there is an Intel P30 flash, following patch
>  series is necessary for working with this hardware:
>
>  http://ozlabs.org/pipermail/linuxppc-dev/2009-April/070716.html
>
> - I2C using I2C Bus 1 from the MPC8360 cpu
>
> Signed-off-by: Heiko Schocher <hs@denx.de>
> ---
> changes since v1:
> - added comments from Kumar Gala and Scott Wood
> - get rid of using get_immrbase() in board specific code
>
> $ ./scripts/checkpatch.pl 0001--Patch-v2-83xx-add-support-for-the- 
> kmeter1-board.patch
> total: 0 errors, 0 warnings, 1626 lines checked
>
> 0001--Patch-v2-83xx-add-support-for-the-kmeter1-board.patch has no  
> obvious style problems and is ready for submission.
>
> arch/powerpc/boot/dts/kmeter1.dts           |  513 +++++++++++++++
> arch/powerpc/configs/83xx/kmeter1_defconfig |  908 ++++++++++++++++++ 
> +++++++++
> arch/powerpc/platforms/83xx/Kconfig         |    7 +
> arch/powerpc/platforms/83xx/Makefile        |    1 +
> arch/powerpc/platforms/83xx/kmeter1.c       |  188 ++++++
> 5 files changed, 1617 insertions(+), 0 deletions(-)
> create mode 100644 arch/powerpc/boot/dts/kmeter1.dts
> create mode 100644 arch/powerpc/configs/83xx/kmeter1_defconfig
> create mode 100644 arch/powerpc/platforms/83xx/kmeter1.c
>
> diff --git a/arch/powerpc/boot/dts/kmeter1.dts b/arch/powerpc/boot/ 
> dts/kmeter1.dts
> new file mode 100644
> index 0000000..63c27da
> --- /dev/null
> +++ b/arch/powerpc/boot/dts/kmeter1.dts
> @@ -0,0 +1,513 @@
> +/*
> + * Keymile KMETER1 Device Tree Source
> + *
> + * 2008 DENX Software Engineering GmbH
> + *
> + * This program is free software; you can redistribute  it and/or  
> modify it
> + * under  the terms of  the GNU General  Public License as  
> published by the
> + * Free Software Foundation;  either version 2 of the  License, or  
> (at your
> + * option) any later version.
> + */
> +
> +/dts-v1/;
> +
> +/ {
> +	model = "KMETER1";
> +	compatible = "keymile,KMETER1";
> +	#address-cells = <1>;
> +	#size-cells = <1>;
> +
> +	aliases {
> +		ethernet0 = &enet_piggy2;
> +		ethernet1 = &enet_estar1;
> +		ethernet2 = &enet_estar2;
> +		ethernet3 = &enet_eth1;
> +		ethernet4 = &enet_eth2;
> +		ethernet5 = &enet_eth3;
> +		ethernet6 = &enet_eth4;
> +		serial0 = &serial0;
> +	};
> +
> +	cpus {
> +		#address-cells = <1>;
> +		#size-cells = <0>;
> +
> +		PowerPC,8360@0 {
> +			device_type = "cpu";
> +			reg = <0x0>;
> +			d-cache-line-size = <32>;	// 32 bytes
> +			i-cache-line-size = <32>;	// 32 bytes
> +			d-cache-size = <32768>;		// L1, 32K
> +			i-cache-size = <32768>;		// L1, 32K
> +			timebase-frequency = <0>;	/* Filled in by U-Boot */
> +			bus-frequency = <0>;	/* Filled in by U-Boot */
> +			clock-frequency = <0>;	/* Filled in by U-Boot */
> +		};
> +	};
> +
> +	memory {
> +		device_type = "memory";
> +		reg = <0 0>;	/* Filled in by U-Boot */
> +	};
> +
> +	soc8360@e0000000 {
> +		#address-cells = <1>;
> +		#size-cells = <1>;
> +		device_type = "soc";
> +		compatible = "simple-bus";


this should be:

                 compatible = "fsl,mpc8360-immr", "simple-bus";

>
> +		ranges = <0x0 0xe0000000 0x00200000>;
> +		reg = <0xe0000000 0x00000200>;
> +		bus-frequency = <0>;	/* Filled in by U-Boot */
> +

>
> +		ipic: pic@700 {
> +			#address-cells = <0>;
> +			#interrupt-cells = <2>;
> +			compatible = "fsl,pq2pro-pic", "fsl,ipic";
> +			interrupt-controller;
> +			reg = <0x700 0x100>;
> +			device_type = "ipic";

drop the device_type.

>
> +		};
> +


> +		qe@100000 {
> +			#address-cells = <1>;
> +			#size-cells = <1>;
> +			device_type = "qe";
> +			compatible = "fsl,qe";
> +			ranges = <0x0 0x100000 0x100000>;
> +			reg = <0x100000 0x480>;
> +			clock-frequency = <0>;	/* Filled in by U-Boot */
> +			brg-frequency = <0>;	/* Filled in by U-Boot */
> +			bus-frequency = <0>;	/* Filled in by U-Boot */
> +
> +


> +
> +			mdio@3320 {
> +				#address-cells = <1>;
> +				#size-cells = <0>;
> +				reg = <0x3320 0x18>;
> +				compatible = "fsl,ucc-mdio";
> +
> +				/* Piggy2 (UCC4, MDIO 0x00, RMII) */
> +				phy_piggy2: ethernet-phy@00 {
> +					reg = <0x0>;
> +					device_type = "ethernet-phy";

drop the device_type (and the one's below)

>
> +				};
> +
> +				/* Eth-1 (UCC5, MDIO 0x08, RMII) */
> +				phy_eth1: ethernet-phy@08 {
> +					reg = <0x08>;
> +					device_type = "ethernet-phy";
> +				};
> +
> +				/* Eth-2 (UCC6, MDIO 0x09, RMII) */
> +				phy_eth2: ethernet-phy@09 {
> +					reg = <0x09>;
> +					device_type = "ethernet-phy";
> +				};
> +
> +				/* Eth-3 (UCC7, MDIO 0x0a, RMII) */
> +				phy_eth3: ethernet-phy@0a {
> +					reg = <0x0a>;
> +					device_type = "ethernet-phy";
> +				};
> +
> +				/* Eth-4 (UCC8, MDIO 0x0b, RMII) */
> +				phy_eth4: ethernet-phy@0b {
> +					reg = <0x0b>;
> +					device_type = "ethernet-phy";
> +				};
> +
> +				/* ESTAR-1 (UCC1, MDIO 0x10, RGMII) */
> +				phy_estar1: ethernet-phy@10 {
> +					interrupt-parent = <&ipic>;
> +					interrupts = <17 0x8>;
> +					reg = <0x10>;
> +					device_type = "ethernet-phy";
> +				};
> +
> +				/* ESTAR-2 (UCC2, MDIO 0x11, RGMII) */
> +				phy_estar2: ethernet-phy@11 {
> +					interrupt-parent = <&ipic>;
> +					interrupts = <18 0x8>;
> +					reg = <0x11>;
> +					device_type = "ethernet-phy";
> +				};
> +			};
> +
> +			qeic: interrupt-controller@80 {
> +				interrupt-controller;
> +				compatible = "fsl,qe-ic";
> +				#address-cells = <0>;
> +				#interrupt-cells = <1>;
> +				reg = <0x80 0x80>;
> +				interrupts = <32 8 33 8>;
> +				interrupt-parent = <&ipic>;
> +			};
> +		};
> +	};
> +
> +	localbus@e0005000 {
> +		#address-cells = <2>;
> +		#size-cells = <1>;
> +		compatible = "fsl,mpc8360-localbus", "fsl,pq2pro-localbus",
> +			     "simple-bus";
> +		reg = <0xe0005000 0xd8>;
> +		ranges = <0 0 0xf0000000 0x04000000>;	/* Filled in by U-Boot */
> +
> +		flash@f0000000,0 {
> +			compatible = "cfi-flash";
> +			/*
> +			 * The Intel P30 chip has 2 non-identical chips on
> +			 * one die, so we need to define 2 seperate regions
> +			 * that are scanned by physmap_of independantly.
> +			 */
> +			reg = <0 0x00000000 0x02000000
> +			       0 0x02000000 0x02000000>;	/* Filled in by U-Boot */
> +			bank-width = <2>;
> +			#address-cells = <1>;
> +			#size-cells = <1>;
> +			partition@0 {
> +				label = "u-boot";
> +				reg = <0 0x40000>;
> +			};
> +			partition@40000 {
> +				label = "env";
> +				reg = <0x40000 0x40000>;
> +			};
> +			partition@80000 {
> +				label = "dtb";
> +				reg = <0x80000 0x20000>;
> +			};
> +			partition@a0000 {
> +				label = "kernel";
> +				reg = <0xa0000 0x300000>;
> +			};
> +			partition@3a0000 {
> +				label = "ramdisk";
> +				reg = <0x3a0000 0x800000>;
> +			};
> +			partition@ba0000 {
> +				label = "user";
> +				reg = <0xba0000 0x3460000>;
> +			};
> +		};
> +	};
> +};

Sorry for taking so long to review this again.

- k

^ permalink raw reply

* Re: [PATCH] powerpc: minimizing the configuration of linkstation_defconfig
From: Kumar Gala @ 2009-06-11  2:46 UTC (permalink / raw)
  To: Rogério Brito; +Cc: linuxppc-dev, Guennadi Liakhovetski, linux-kernel
In-Reply-To: <20090516160453.GA15138@ime.usp.br>


On May 16, 2009, at 11:04 AM, Rog=E9rio Brito wrote:

> Hi, Kumar, Guennadi, and Co.
>
>
> This patch addresses the following issues:
>
> 01. makes CFQ the default scheduler, to be in line with the rest of
> the kernel.
>
> 02. since linkstations are meant to store files, enable large blk
> devices.
>
> 03. disable CONFIG_MIGRATION in in such low memory devices.
>
> 04. disable CONFIG_BLK_DEV_RAM.
>
> 05. disable CONFIG_SCSI_LOWLEVEL, as no device under that tree is
> used.
>
> 06. idem for CONFIG_NETDEV_10000.
>
> 07. idem for CONFIG_WIRELESS.
>
> 08. idem for CONFIG_HWMON.
>
> 09. idem for CONFIG_CRYPTO_HW.
>
> 10. disable CONFIG_VIDEO_OUTPUT_CONTROL.
>
> 11. keep consistency and disable extended attributes in CIFS, ext3,
> and NFS.
>
> 12. enable CONFIG_PRINTK_TIME.
>
> Signed-off-by: Rog=E9rio Brito <rbrito@ime.usp.br>
>
> ---
>
> This is the patch for tidying the defconfig. I'm still having issues
> with the MTD devices, it seems. :-( I will investigate this now.
>
> I can send a similar patch to storcenter.

Did you ever resolve the MTD issue?

- k=

^ permalink raw reply

* Re: [PATCH] fsldma: use PCI Read Multiple command
From: Kumar Gala @ 2009-06-11  2:45 UTC (permalink / raw)
  To: Dan Williams
  Cc: David Hawkins, Ira Snyder, Liu Dave-R63238, linux-kernel,
	linuxppc-dev, Timur Tabi
In-Reply-To: <e9c3a7c20904271349m134ff7f2s9d7901015454cf3d@mail.gmail.com>


On Apr 27, 2009, at 3:49 PM, Dan Williams wrote:

> On Mon, Apr 27, 2009 at 1:47 PM, Timur Tabi <timur@freescale.com>  
> wrote:
>> Adding Kumar to the CC: list, since he might pick up the patch.
>>
>
> Acked-by: Dan Williams <dan.j.williams@intel.com>
>
> I agree with taking this through Kumar's tree.

I'm going through patches for .31.. Should I still pick this up?   
Going forward should I pick up fsldma patches?

- k

^ permalink raw reply

* Re: [PATCH] powerpc/boot: cuboot: Fix up ethernet3 MAC address on MPC85xx
From: Kumar Gala @ 2009-06-11  2:54 UTC (permalink / raw)
  To: Nate Case; +Cc: linuxppc-dev
In-Reply-To: <1244499462-18719-1-git-send-email-ncase@xes-inc.com>


On Jun 8, 2009, at 5:17 PM, Nate Case wrote:

> MPC85xx platforms do support 4 ethernet ports, so make sure the boot
> wrapper fixes up all of them in the fdt.
>
> Signed-off-by: Nate Case <ncase@xes-inc.com>
> ---
> arch/powerpc/boot/cuboot-85xx.c |    2 ++
> 1 files changed, 2 insertions(+), 0 deletions(-)
>
> diff --git a/arch/powerpc/boot/cuboot-85xx.c b/arch/powerpc/boot/ 
> cuboot-85xx.c
> index 6776a1a..277ba4a 100644
> --- a/arch/powerpc/boot/cuboot-85xx.c
> +++ b/arch/powerpc/boot/cuboot-85xx.c
> @@ -15,6 +15,7 @@
> #include "cuboot.h"
>
> #define TARGET_85xx
> +#define TARGET_HAS_ETH3

This is problematic in that we'd be changing the memory layout of the  
bd_t and not ALL 85xx's have HAS_ETH3 set.

- k

^ permalink raw reply

* [PATCH] powerpc/fsl_lbc: Increase the number of possible lbc banks
From: mware @ 2009-06-11  3:01 UTC (permalink / raw)
  To: linuxppc-dev

Currently the fsl,*lbc devices support 8 banks (ie OR and BR registers).
This is adequate for most pq2 and pq3 processors, but not the MPC8280 which
has 12 banks.

Signed-Off-By: Mark Ware <mware@elphinstone.net>
---
 arch/powerpc/include/asm/fsl_lbc.h |    4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/powerpc/include/asm/fsl_lbc.h b/arch/powerpc/include/asm/=
fsl_lbc.h
index 63a4f77..1b5a210 100644
--- a/arch/powerpc/include/asm/fsl_lbc.h
+++ b/arch/powerpc/include/asm/fsl_lbc.h
@@ -95,8 +95,8 @@ struct fsl_lbc_bank {
 };

 struct fsl_lbc_regs {
-       struct fsl_lbc_bank bank[8];
-       u8 res0[0x28];
+       struct fsl_lbc_bank bank[12];
+       u8 res0[0x8];
        __be32 mar;             /**< UPM Address Register */
        u8 res1[0x4];
        __be32 mamr;            /**< UPMA Mode Register */
--
1.5.6.5

^ permalink raw reply related

* Re: linux-next: powerpc tree build warning
From: Benjamin Herrenschmidt @ 2009-06-11  3:14 UTC (permalink / raw)
  To: Stephen Rothwell; +Cc: linuxppc-dev, linux-next, Paul Mackerras, linux-kernel
In-Reply-To: <20090611113930.78a42893.sfr@canb.auug.org.au>

On Thu, 2009-06-11 at 11:39 +1000, Stephen Rothwell wrote:
> Hi Ben,
> 
> Today's linux-next build (powerpc ppc64_defconfig) produced this warning:
> 
> arch/powerpc/platforms/Kconfig.cputype:60:warning: defaults for choice values not supported
> 
> We appear to have CONFIG_PPC_BOOK3S int two places which is confusing
> Kconfig.

Yes, I see that. One place depends on PPC32 and the other one PPC64, but
it still seems to be somewhat confused. In any case, it seems to still
do the right thing, so not a big hurry here, but I'll do a patch that
does it differently.

Cheers,
Ben.

^ permalink raw reply

* Re: ipr boot failure caused by MSI (2.6.30-rc1+)
From: Wayne Boyer @ 2009-06-11  3:23 UTC (permalink / raw)
  To: Brian King; +Cc: James Bottomley, ppc-dev, linux-scsi
In-Reply-To: <4A205B40.30306@linux.vnet.ibm.com>



Brian King wrote:
> James Bottomley wrote:
>> On Thu, 2009-05-21 at 14:51 -0500, James Bottomley wrote:
>> I saw the quirk fix for this go by:
>>
>> http://ozlabs.org/pipermail/linuxppc-dev/2009-May/072436.html
>>
>> Is there an easy way to trigger an interrupt on this device?  Preferably
>> in ipr_probe_ioa() so we can at least print out if the interrupts are
>> misrouted and fall back from MSI to normal using the PCI infrastructure?
> 
> I just talked with one of the adapter firmware developers and it sounds like
> this might be possible. I'll work with Wayne on coding something up to try.
> 
> -Brian
> 

I've put together some code to trigger the test MSI and either fall back to
LSI if it isn't detected, or continue on using MSI.  In the routine that
does the setup and test I have this call to request_irq:

rc = request_irq(pdev->irq, ipr_test_intr, 0, IPR_NAME, ioa_cfg);

Note that the flags value is '0'.  The question came up as to whether or
not this value should really be IRQF_SHARED.  Given that this is for an MSI
interrupt and MSI interrupts are not shared by definition, IRQF_SHARED did
not seem correct.

What should the flags value be in this case?


-- 
Wayne Boyer
IBM - Beaverton, Oregon
LTC S/W Development - eServerIO
(503) 578-5236, T/L 775-5236

^ permalink raw reply

* Re: [PATCH] mpc83xx/usb.c: fix usb mux setup for mpc834x
From: Kumar Gala @ 2009-06-11  3:32 UTC (permalink / raw)
  To: Peter Korsgaard; +Cc: linuxppc-dev
In-Reply-To: <1244547812-3811-1-git-send-email-jacmet@sunsite.dk>


On Jun 9, 2009, at 6:43 AM, Peter Korsgaard wrote:

> usb0 and usb1 mux settings in the sicrl register were swapped (twice!)
> in mpc834x_usb_cfg(), leading to various strange issues with fsl-ehci
> and full speed devices.
>
> The USB port config on mpc834x is done using 2 muxes: Port 0 is always
> used for MPH port 0, and port 1 can either be used for MPH port 1 or  
> DR
> (unless DR uses TMDI phy or OTG, then it uses both ports) - See 8349  
> RM
> figure 1-4..
>
> mpc8349_usb_cfg() had this inverted for the DR, and it also had the  
> bit
> positions of the usb0 / usb1 mux settings swapped. It would basically
> work if you specified port1 instead of port0 for the MPH controller  
> (and
> happened to use ULPI phys), which is what all the 834x dts have done,
> even though that configuration is physically invalid.
>
> Instead fix mpc8349_usb_cfg() and adjust the dts files to match  
> reality.
>
> Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
> ---
> arch/powerpc/boot/dts/asp834x-redboot.dts |    2 +-
> arch/powerpc/boot/dts/mpc8349emitx.dts    |    2 +-
> arch/powerpc/boot/dts/mpc834x_mds.dts     |    2 +-
> arch/powerpc/boot/dts/sbc8349.dts         |    2 +-
> arch/powerpc/platforms/83xx/mpc83xx.h     |    4 ++--
> arch/powerpc/platforms/83xx/usb.c         |   10 +++++-----
> 6 files changed, 11 insertions(+), 11 deletions(-)

applied.. Please remind me to send this linux-stable for .30 and .29

- k

^ permalink raw reply

* [PATCH][Resend 2][BUILD FAILURE 04/04] Next June 04:PPC64 randconfig [drivers/net/ucc_geth.o]
From: Subrata Modak @ 2009-06-11  3:37 UTC (permalink / raw)
  To: Tony Breeds, netdev, michael, Li Yang, Stephen Rothwell,
	Nathan Lynch
  Cc: Sachin P Sant, Linux-Kernel, Linuxppc-dev, Linux-Next,
	Subrata Modak, Balbir Singh

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2187 bytes --]

Hi Nathan,

>On Wed, 2009-06-10 at 21:28 -0500, Nathan Lynch wrote:
>Subrata Modak <subrata@linux.vnet.ibm.com> writes:
> 
> > On Thu, 2009-06-11 at 11:05 +1000, Stephen Rothwell wrote:
> >> Hi Subrata,
> >> 
> >> On Wed, 10 Jun 2009 23:13:23 +0530 Subrata Modak <subrata@linux.vnet.ibm.com> wrote:
> >> >
> >> >  	/* Find the TBI PHY.  If it's not there, we don't support SGMII */
> >> > -	ph = of_get_property(np, "tbi-handle", NULL);
> >> > +	ph = (phandle *)of_get_property(np, "tbi-handle", NULL);
> >> 
> >> You don't need this cast because of_get_property() returns "void *".
> >
> > Stephen,
> >
> > True. But without this gcc complains:
> >
> > CC [M]  drivers/net/ucc_geth.o
> > drivers/net/ucc_geth.c: In function ‘ucc_geth_probe’:
> > drivers/net/ucc_geth.c:3824: warning: assignment discards qualifiers
> > from pointer target type
> 
> ph should be declared const phandle *.  Look at other uses of
> of_get_property.
>

Ok fine. Here is a revised patch again.

Subject: [PATCH][Resend 2][BUILD FAILURE 04/04] Next June 04:PPC64 randconfig [drivers/net/ucc_geth.o]
Reference(s):
http://lkml.org/lkml/2009/6/4/241,
http://lkml.org/lkml/2009/6/10/338,

Fix the following build error:

drivers/net/ucc_geth.c: In function bucc_geth_probeb:
drivers/net/ucc_geth.c:3822: error: 'ph' undeclared (first use in this function)
drivers/net/ucc_geth.c:3822: error: (Each undeclared identifier is reported only once
drivers/net/ucc_geth.c:3822: error: for each function it appears in.)
drivers/net/ucc_geth.c:3832: error: 'mdio' undeclared (first use in this function)
make[2]: *** [drivers/net/ucc_geth.o] Error 1

Signed-off-by: Subrata Modak <subrata@linux.vnet.ibm.com>
---

--- linux-2.6.30-rc8/drivers/net/ucc_geth.c.orig	2009-06-10 11:58:39.000000000 -0500
+++ linux-2.6.30-rc8/drivers/net/ucc_geth.c	2009-06-10 22:28:13.000000000 -0500
@@ -3595,6 +3595,8 @@ static const struct net_device_ops ucc_g
 
 static int ucc_geth_probe(struct of_device* ofdev, const struct of_device_id *match)
 {
+	struct device_node *mdio;
+	const phandle *ph;
 	struct device *device = &ofdev->dev;
 	struct device_node *np = ofdev->node;
 	struct net_device *dev = NULL;

---
Regards--
Subrata

^ permalink raw reply

* Re: [PATCH -next] powerpc/fsl-booke: Enable L1 cache on e500v1/e500v2/e500mc CPUs
From: Kumar Gala @ 2009-06-11  3:39 UTC (permalink / raw)
  To: Nate Case; +Cc: linuxppc-dev
In-Reply-To: <1244666248-23322-1-git-send-email-ncase@xes-inc.com>


On Jun 10, 2009, at 3:37 PM, Nate Case wrote:

> Some boot loaders may not enable L1 instruction/data cache.  Check if
> data and instruction caches are enabled, and enable them if needed.
>
> Signed-off-by: Nate Case <ncase@xes-inc.com>
> ---
> arch/powerpc/include/asm/reg_booke.h      |    2 +
> arch/powerpc/kernel/cpu_setup_fsl_booke.S |   49 ++++++++++++++++++++ 
> +++++++--
> 2 files changed, 48 insertions(+), 3 deletions(-)

applied to next

- k

^ permalink raw reply


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox