* [PATCH] Wire up recvmmsg syscall
From: Benjamin Herrenschmidt @ 2010-01-14 4:11 UTC (permalink / raw)
To: linuxppc-dev
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
---
arch/powerpc/include/asm/systbl.h | 2 ++
arch/powerpc/include/asm/unistd.h | 3 ++-
2 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/include/asm/systbl.h b/arch/powerpc/include/asm/systbl.h
index 07d2d19..0e92c23 100644
--- a/arch/powerpc/include/asm/systbl.h
+++ b/arch/powerpc/include/asm/systbl.h
@@ -326,3 +326,5 @@ SYSCALL_SPU(perf_event_open)
COMPAT_SYS_SPU(preadv)
COMPAT_SYS_SPU(pwritev)
COMPAT_SYS(rt_tgsigqueueinfo)
+COMPAT_SYS_SPU(recvmmsg)
+
diff --git a/arch/powerpc/include/asm/unistd.h b/arch/powerpc/include/asm/unistd.h
index f6ca761..bbf2ee9 100644
--- a/arch/powerpc/include/asm/unistd.h
+++ b/arch/powerpc/include/asm/unistd.h
@@ -345,10 +345,11 @@
#define __NR_preadv 320
#define __NR_pwritev 321
#define __NR_rt_tgsigqueueinfo 322
+#define __NR_recvmmsg 323
#ifdef __KERNEL__
-#define __NR_syscalls 323
+#define __NR_syscalls 324
#define __NR__exit __NR_exit
#define NR_syscalls __NR_syscalls
--
1.6.3.3
^ permalink raw reply related
* Re: [PATCH] Wire up recvmmsg syscall
From: Benjamin Herrenschmidt @ 2010-01-14 4:21 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <1263442293.724.324.camel@pasglop>
On Thu, 2010-01-14 at 15:11 +1100, Benjamin Herrenschmidt wrote:
> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> ---
> arch/powerpc/include/asm/systbl.h | 2 ++
> arch/powerpc/include/asm/unistd.h | 3 ++-
> 2 files changed, 4 insertions(+), 1 deletions(-)
>
> diff --git a/arch/powerpc/include/asm/systbl.h b/arch/powerpc/include/asm/systbl.h
> index 07d2d19..0e92c23 100644
> --- a/arch/powerpc/include/asm/systbl.h
> +++ b/arch/powerpc/include/asm/systbl.h
> @@ -326,3 +326,5 @@ SYSCALL_SPU(perf_event_open)
> COMPAT_SYS_SPU(preadv)
> COMPAT_SYS_SPU(pwritev)
> COMPAT_SYS(rt_tgsigqueueinfo)
> +COMPAT_SYS_SPU(recvmmsg)
> +
Ignore. We don't need it, it's part of socketcalls. In fact, i386
neither, it's a bug there.
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH] powerpc/4xx: Add support for type 1 pci transactions on 4xx boards
From: Benjamin Herrenschmidt @ 2010-01-14 4:56 UTC (permalink / raw)
To: Stef van Os; +Cc: linuxppc-dev, Felix Radensky, Stefan Roese, Feng Kan
In-Reply-To: <1263338326.724.216.camel@pasglop>
On Wed, 2010-01-13 at 10:18 +1100, Benjamin Herrenschmidt wrote:
> On Tue, 2010-01-12 at 15:09 +0100, Stef van Os wrote:
> > This patch adds type 1 PCI transactions to 4xx PCI code, enabling the
> > discovery of
> > devices behind a PCI bridge.
>
> Your patch appears word wrapped and whitespace damaged...
>
> I'll fix it up manually this time around but please check your mailer
> setup :-)
Allright, it's not quite that.
I've looked at my docs, and it looks like older parts such as the 440EP
do -not- take the config type in the low bit.
More interestingly, they only generate config 0 cycles if you pass a bus
number of 0 :-)
So we'll need do do something a little bit different here. We probably
need to indicate in the device-tree what kind of SoC we have (whether
it supports the explicit bit to choose between type 0 and type 1 or
not).
If not, we should then set the "self_busno" field of the bridge to 0,
causing indirect_pci to always use bus number 0 when trying to talk
to the bus segment behind the bridge, whatever the linux bus number
for it actually is.
Now, we need to make a precise list here of what SoC uses what. 460xx
seem to all support the explicit bit. 440EP doesn't. What else ?
Somebody from AMCC can dbl check that ?
Cheers,
Ben.
^ permalink raw reply
* Inclusion of 85xx cache-sram patch series
From: Mahajan Vivek-B08308 @ 2010-01-14 6:10 UTC (permalink / raw)
To: Gala Kumar-B11780; +Cc: linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 211 bytes --]
Any plans to include this patch series at
http://lists.ozlabs.org/pipermail/linuxppc-dev/2009-December/078693.html
into your 'next' branch or there are some outstanding issues with this.
Thanks,
Vivek
[-- Attachment #2: Type: text/html, Size: 951 bytes --]
^ permalink raw reply
* Re: [PATCH]: powerpc: Fix build breakage due to incorrect location of autoconf.h
From: Joakim Tjernlund @ 2010-01-14 7:47 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Stephen Rothwell, Roel Kluin, linuxppc-dev@ozlabs.org list,
Richard Purdie, Anton Blanchard, Andrew Morton, David Woodhouse
In-Reply-To: <1263412963.724.223.camel@pasglop>
Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote on 13/01/2010 21:02:43:
>
> On Wed, 2010-01-13 at 12:54 -0600, Kumar Gala wrote:
>
> > >
> > > BOOTCFLAGS += -I$(obj) -I$(srctree)/$(obj)
> > > -BOOTCFLAGS += -include include/linux/autoconf.h -Iarch/powerpc/include
> > > -BOOTCFLAGS += -Iinclude
> > > +BOOTCFLAGS += -include include/generated/autoconf.h
> > > +BOOTCFLAGS += -I$(srctree)/arch/powerpc/include -I$(srctree)/include
> > >
> > > DTS_FLAGS ?= -p 1024
> > >
> >
> > Ack, this works for me (seeing as -rc4 doesn't generate uImages w/o it :)
> >
>
> I sent a different patch to Linus yesterday for that.
Seen it now as it is in Linus tree:
1) IMHO it would have been nicer to use #ifdef __KERNEL__
instead of CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS
as then arches that don't define CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS
at all will never use the new optimization or was that what you intended?
2) You really should add an comment in the Makefile about not using
autoconf.h/-D__KERNEL__
^ permalink raw reply
* [PATCH 1/4] dts/mpc8569mds: Cleanup tbi phy to support rtbi
From: Liu Yu @ 2010-01-14 8:13 UTC (permalink / raw)
To: galak, davem; +Cc: netdev, Liu Yu, linuxppc-dev
After these change, when need to work in rtbi mode,
just change phy-connection-type to "rtbi".
Also, this work can be done by u-boot.
Signed-off-by: Liu Yu <yu.liu@freescale.com>
---
arch/powerpc/boot/dts/mpc8569mds.dts | 47 ++++++++++++++++++++++++++++++---
1 files changed, 42 insertions(+), 5 deletions(-)
diff --git a/arch/powerpc/boot/dts/mpc8569mds.dts b/arch/powerpc/boot/dts/mpc8569mds.dts
index 795eb36..8b72eaf 100644
--- a/arch/powerpc/boot/dts/mpc8569mds.dts
+++ b/arch/powerpc/boot/dts/mpc8569mds.dts
@@ -535,6 +535,7 @@
rx-clock-name = "none";
tx-clock-name = "clk12";
pio-handle = <&pio1>;
+ tbi-handle = <&tbi1>;
phy-handle = <&qe_phy0>;
phy-connection-type = "rgmii-id";
};
@@ -579,7 +580,7 @@
reg = <0x6>;
device_type = "ethernet-phy";
};
- tbi-phy@11 {
+ tbi1: tbi-phy@11 {
reg = <0x11>;
device_type = "tbi-phy";
};
@@ -590,7 +591,7 @@
reg = <0x3520 0x18>;
compatible = "fsl,ucc-mdio";
- tbi0: tbi-phy@15 {
+ tbi6: tbi-phy@15 {
reg = <0x15>;
device_type = "tbi-phy";
};
@@ -600,7 +601,7 @@
#size-cells = <0>;
reg = <0x3720 0x38>;
compatible = "fsl,ucc-mdio";
- tbi1: tbi-phy@17 {
+ tbi8: tbi-phy@17 {
reg = <0x17>;
device_type = "tbi-phy";
};
@@ -617,10 +618,22 @@
rx-clock-name = "none";
tx-clock-name = "clk12";
pio-handle = <&pio3>;
+ tbi-handle = <&tbi3>;
phy-handle = <&qe_phy2>;
phy-connection-type = "rgmii-id";
};
+ mdio@2320 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0x2320 0x18>;
+ compatible = "fsl,ucc-mdio";
+ tbi3: tbi-phy@11 {
+ reg = <0x11>;
+ device_type = "tbi-phy";
+ };
+ };
+
enet1: ucc@3000 {
device_type = "network";
compatible = "ucc_geth";
@@ -632,10 +645,22 @@
rx-clock-name = "none";
tx-clock-name = "clk17";
pio-handle = <&pio2>;
+ tbi-handle = <&tbi2>;
phy-handle = <&qe_phy1>;
phy-connection-type = "rgmii-id";
};
+ mdio@3120 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0x3120 0x18>;
+ compatible = "fsl,ucc-mdio";
+ tbi2: tbi-phy@11 {
+ reg = <0x11>;
+ device_type = "tbi-phy";
+ };
+ };
+
enet3: ucc@3200 {
device_type = "network";
compatible = "ucc_geth";
@@ -647,10 +672,22 @@
rx-clock-name = "none";
tx-clock-name = "clk17";
pio-handle = <&pio4>;
+ tbi-handle = <&tbi4>;
phy-handle = <&qe_phy3>;
phy-connection-type = "rgmii-id";
};
+ mdio@3320 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0x3320 0x18>;
+ compatible = "fsl,ucc-mdio";
+ tbi4: tbi-phy@11 {
+ reg = <0x11>;
+ device_type = "tbi-phy";
+ };
+ };
+
enet5: ucc@3400 {
device_type = "network";
compatible = "ucc_geth";
@@ -661,7 +698,7 @@
local-mac-address = [ 00 00 00 00 00 00 ];
rx-clock-name = "none";
tx-clock-name = "none";
- tbi-handle = <&tbi0>;
+ tbi-handle = <&tbi6>;
phy-handle = <&qe_phy5>;
phy-connection-type = "sgmii";
};
@@ -676,7 +713,7 @@
local-mac-address = [ 00 00 00 00 00 00 ];
rx-clock-name = "none";
tx-clock-name = "none";
- tbi-handle = <&tbi1>;
+ tbi-handle = <&tbi8>;
phy-handle = <&qe_phy7>;
phy-connection-type = "sgmii";
};
--
1.6.4
^ permalink raw reply related
* [PATCH 2/4] mpc8569mds: Add bscr setting for rtbi mode
From: Liu Yu @ 2010-01-14 8:13 UTC (permalink / raw)
To: galak, davem; +Cc: netdev, Liu Yu, linuxppc-dev
In-Reply-To: <1263456799-3306-1-git-send-email-yu.liu@freescale.com>
Signed-off-by: Liu Yu <yu.liu@freescale.com>
---
arch/powerpc/platforms/85xx/mpc85xx_mds.c | 24 ++++++++++++++++++++++++
1 files changed, 24 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/platforms/85xx/mpc85xx_mds.c b/arch/powerpc/platforms/85xx/mpc85xx_mds.c
index c5028a2..0872e4a 100644
--- a/arch/powerpc/platforms/85xx/mpc85xx_mds.c
+++ b/arch/powerpc/platforms/85xx/mpc85xx_mds.c
@@ -237,6 +237,8 @@ static void __init mpc85xx_mds_setup_arch(void)
} else if (machine_is(mpc8569_mds)) {
#define BCSR7_UCC12_GETHnRST (0x1 << 2)
#define BCSR8_UEM_MARVELL_RST (0x1 << 1)
+#define BCSR_UCC_RGMII (0x1 << 6)
+#define BCSR_UCC_RTBI (0x1 << 5)
/*
* U-Boot mangles interrupt polarity for Marvell PHYs,
* so reset built-in and UEM Marvell PHYs, this puts
@@ -247,6 +249,28 @@ static void __init mpc85xx_mds_setup_arch(void)
setbits8(&bcsr_regs[7], BCSR7_UCC12_GETHnRST);
clrbits8(&bcsr_regs[8], BCSR8_UEM_MARVELL_RST);
+
+ for (np = NULL; (np = of_find_compatible_node(np,
+ "network",
+ "ucc_geth")) != NULL;) {
+ const unsigned int *prop;
+ int ucc_num;
+
+ prop = of_get_property(np, "cell-index", NULL);
+ if (prop == NULL)
+ continue;
+
+ ucc_num = *prop - 1;
+
+ prop = of_get_property(np, "phy-connection-type", NULL);
+ if (prop == NULL)
+ continue;
+
+ if (strcmp("rtbi", (const char *)prop) == 0)
+ clrsetbits_8(&bcsr_regs[7 + ucc_num],
+ BCSR_UCC_RGMII, BCSR_UCC_RTBI);
+ }
+
}
iounmap(bcsr_regs);
}
--
1.6.4
^ permalink raw reply related
* [PATCH 4/4] phy: add RTBI mode for m88e1111
From: Liu Yu @ 2010-01-14 8:13 UTC (permalink / raw)
To: galak, davem; +Cc: netdev, Liu Yu, linuxppc-dev
In-Reply-To: <1263456799-3306-3-git-send-email-yu.liu@freescale.com>
Signed-off-by: Liu Yu <yu.liu@freescale.com>
---
drivers/net/phy/marvell.c | 38 ++++++++++++++++++++++++++++++++++++++
1 files changed, 38 insertions(+), 0 deletions(-)
diff --git a/drivers/net/phy/marvell.c b/drivers/net/phy/marvell.c
index 6f69b9b..65ed385 100644
--- a/drivers/net/phy/marvell.c
+++ b/drivers/net/phy/marvell.c
@@ -63,6 +63,7 @@
#define MII_M1111_HWCFG_MODE_COPPER_RGMII 0xb
#define MII_M1111_HWCFG_MODE_FIBER_RGMII 0x3
#define MII_M1111_HWCFG_MODE_SGMII_NO_CLK 0x4
+#define MII_M1111_HWCFG_MODE_COPPER_RTBI 0x9
#define MII_M1111_HWCFG_FIBER_COPPER_AUTO 0x8000
#define MII_M1111_HWCFG_FIBER_COPPER_RES 0x2000
@@ -269,6 +270,43 @@ static int m88e1111_config_init(struct phy_device *phydev)
return err;
}
+ if (phydev->interface == PHY_INTERFACE_MODE_RTBI) {
+ temp = phy_read(phydev, MII_M1111_PHY_EXT_CR);
+ if (temp < 0)
+ return temp;
+ temp |= (MII_M1111_RX_DELAY | MII_M1111_TX_DELAY);
+ err = phy_write(phydev, MII_M1111_PHY_EXT_CR, temp);
+ if (err < 0)
+ return err;
+
+ temp = phy_read(phydev, MII_M1111_PHY_EXT_SR);
+ if (temp < 0)
+ return temp;
+ temp &= ~(MII_M1111_HWCFG_MODE_MASK | MII_M1111_HWCFG_FIBER_COPPER_RES);
+ temp |= 0x7 | MII_M1111_HWCFG_FIBER_COPPER_AUTO;
+ err = phy_write(phydev, MII_M1111_PHY_EXT_SR, temp);
+ if (err < 0)
+ return err;
+
+ /* soft reset */
+ err = phy_write(phydev, MII_BMCR, BMCR_RESET);
+ if (err < 0)
+ return err;
+ do
+ temp = phy_read(phydev, MII_BMCR);
+ while (temp & BMCR_RESET);
+
+ temp = phy_read(phydev, MII_M1111_PHY_EXT_SR);
+ if (temp < 0)
+ return temp;
+ temp &= ~(MII_M1111_HWCFG_MODE_MASK | MII_M1111_HWCFG_FIBER_COPPER_RES);
+ temp |= MII_M1111_HWCFG_MODE_COPPER_RTBI | MII_M1111_HWCFG_FIBER_COPPER_AUTO;
+ err = phy_write(phydev, MII_M1111_PHY_EXT_SR, temp);
+ if (err < 0)
+ return err;
+ }
+
+
err = phy_write(phydev, MII_BMCR, BMCR_RESET);
if (err < 0)
return err;
--
1.6.4
^ permalink raw reply related
* [PATCH 3/4] ucc_geth: update the tbi-phy setting
From: Liu Yu @ 2010-01-14 8:13 UTC (permalink / raw)
To: galak, davem; +Cc: netdev, Liu Yu, linuxppc-dev
In-Reply-To: <1263456799-3306-2-git-send-email-yu.liu@freescale.com>
Old method only set tbi-phy for eth0.
Signed-off-by: Liu Yu <yu.liu@freescale.com>
---
drivers/net/ucc_geth.c | 23 +++++++++++++++--------
1 files changed, 15 insertions(+), 8 deletions(-)
diff --git a/drivers/net/ucc_geth.c b/drivers/net/ucc_geth.c
index 750d86d..0e72013 100644
--- a/drivers/net/ucc_geth.c
+++ b/drivers/net/ucc_geth.c
@@ -37,6 +37,7 @@
#include <asm/qe.h>
#include <asm/ucc.h>
#include <asm/ucc_fast.h>
+#include <asm/machdep.h>
#include "ucc_geth.h"
#include "fsl_pq_mdio.h"
@@ -1334,7 +1335,7 @@ static int adjust_enet_interface(struct ucc_geth_private *ugeth)
struct ucc_geth __iomem *ug_regs;
struct ucc_fast __iomem *uf_regs;
int ret_val;
- u32 upsmr, maccfg2, tbiBaseAddress;
+ u32 upsmr, maccfg2;
u16 value;
ugeth_vdbg("%s: IN", __func__);
@@ -1389,14 +1390,20 @@ static int adjust_enet_interface(struct ucc_geth_private *ugeth)
/* Note that this depends on proper setting in utbipar register. */
if ((ugeth->phy_interface == PHY_INTERFACE_MODE_TBI) ||
(ugeth->phy_interface == PHY_INTERFACE_MODE_RTBI)) {
- tbiBaseAddress = in_be32(&ug_regs->utbipar);
- tbiBaseAddress &= UTBIPAR_PHY_ADDRESS_MASK;
- tbiBaseAddress >>= UTBIPAR_PHY_ADDRESS_SHIFT;
- value = ugeth->phydev->bus->read(ugeth->phydev->bus,
- (u8) tbiBaseAddress, ENET_TBI_MII_CR);
+ struct ucc_geth_info *ug_info = ugeth->ug_info;
+ struct phy_device *tbiphy;
+
+ if (!ug_info->tbi_node)
+ ugeth_warn("TBI mode requires that the device "
+ "tree specify a tbi-handle\n");
+
+ tbiphy = of_phy_find_device(ug_info->tbi_node);
+ if (!tbiphy)
+ ugeth_warn("Could not get TBI device\n");
+
+ value = phy_read(tbiphy, ENET_TBI_MII_CR);
value &= ~0x1000; /* Turn off autonegotiation */
- ugeth->phydev->bus->write(ugeth->phydev->bus,
- (u8) tbiBaseAddress, ENET_TBI_MII_CR, value);
+ phy_write(tbiphy, ENET_TBI_MII_CR, value);
}
init_check_frame_length_mode(ug_info->lengthCheckRx, &ug_regs->maccfg2);
--
1.6.4
^ permalink raw reply related
* Re: [PATCH]: powerpc: Fix build breakage due to incorrect location of autoconf.h
From: Benjamin Herrenschmidt @ 2010-01-14 8:57 UTC (permalink / raw)
To: Joakim Tjernlund
Cc: Stephen Rothwell, Roel Kluin, linuxppc-dev@ozlabs.org list,
Richard Purdie, Anton Blanchard, Andrew Morton, David Woodhouse
In-Reply-To: <OF20873087.ECC43BEB-ONC12576AB.0029EA9A-C12576AB.002AC5CA@transmode.se>
> Seen it now as it is in Linus tree:
>
> 1) IMHO it would have been nicer to use #ifdef __KERNEL__
> instead of CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS
> as then arches that don't define CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS
> at all will never use the new optimization or was that what you intended?
No, that was on purpose. If an arch doesn't have efficient unaligned
accesses, then they should not use the optimization since it will result
in a lot of unaligned accesses :-) In which case they are better off
falling back to the old byte-by-byte method.
The advantage also of doing it this way is that x86 will benefit from
the optimisation at boot time since it does include autoconf.h in its
boot wrapper (and deals with unaligned accesses just fine at any time)
though something tells me that it won't make much of a difference in
performances on any recent x86 (it might on some of the newer low power
embedded ones, I don't know for sure).
> 2) You really should add an comment in the Makefile about not using
> autoconf.h/-D__KERNEL__
That's true :-)
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH]: powerpc: Fix build breakage due to incorrect location of autoconf.h
From: Joakim Tjernlund @ 2010-01-14 9:12 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Stephen Rothwell, Roel Kluin, linuxppc-dev@ozlabs.org list,
Richard Purdie, Anton Blanchard, Andrew Morton, David Woodhouse
In-Reply-To: <1263459431.724.352.camel@pasglop>
Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote on 14/01/2010 09:57:11:
> Subject: Re: [PATCH]: powerpc: Fix build breakage due to incorrect location ofautoconf.h
>
>
> > Seen it now as it is in Linus tree:
> >
> > 1) IMHO it would have been nicer to use #ifdef __KERNEL__
> > instead of CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS
> > as then arches that don't define CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS
> > at all will never use the new optimization or was that what you intended?
>
> No, that was on purpose. If an arch doesn't have efficient unaligned
> accesses, then they should not use the optimization since it will result
> in a lot of unaligned accesses :-) In which case they are better off
> falling back to the old byte-by-byte method.
Not quite, it is only 1 of 4 accesses that uses unaligned and
that accesses is only unaligned 50% in average, it might still
be faster. We will never know now.
>
> The advantage also of doing it this way is that x86 will benefit from
> the optimisation at boot time since it does include autoconf.h in its
But so does my suggestion, doesn't it?
> boot wrapper (and deals with unaligned accesses just fine at any time)
> though something tells me that it won't make much of a difference in
> performances on any recent x86 (it might on some of the newer low power
> embedded ones, I don't know for sure).
^ permalink raw reply
* Re: [PATCH]: powerpc: Fix build breakage due to incorrect location of autoconf.h
From: Benjamin Herrenschmidt @ 2010-01-14 9:43 UTC (permalink / raw)
To: Joakim Tjernlund
Cc: Stephen Rothwell, Roel Kluin, linuxppc-dev@ozlabs.org list,
Richard Purdie, Anton Blanchard, Andrew Morton, David Woodhouse
In-Reply-To: <OF7EAC50CA.1271BCB8-ONC12576AB.00321D31-C12576AB.00329588@transmode.se>
On Thu, 2010-01-14 at 10:12 +0100, Joakim Tjernlund wrote:
> > No, that was on purpose. If an arch doesn't have efficient unaligned
> > accesses, then they should not use the optimization since it will
> result
> > in a lot of unaligned accesses :-) In which case they are better off
> > falling back to the old byte-by-byte method.
>
> Not quite, it is only 1 of 4 accesses that uses unaligned and
> that accesses is only unaligned 50% in average, it might still
> be faster. We will never know now.
Why ? If you think it's a win, then it's easy to make a patch to turn
it to __KERNEL__ and ask some people from ARM and MIPS or even sparc
land for example to give it a spin. If it's indeed a win, then submit it
to Linus and/or Andrew and there's no reason for it not to go in.
I simply took a more conservative approach for post -rc4
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH]: powerpc: Fix build breakage due to incorrect location of autoconf.h
From: Joakim Tjernlund @ 2010-01-14 10:22 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Stephen Rothwell, Roel Kluin, linuxppc-dev@ozlabs.org list,
Richard Purdie, Anton Blanchard, Andrew Morton, David Woodhouse
In-Reply-To: <1263462224.724.356.camel@pasglop>
Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote on 14/01/2010 10:43:44:
> On Thu, 2010-01-14 at 10:12 +0100, Joakim Tjernlund wrote:
> > > No, that was on purpose. If an arch doesn't have efficient unaligned
> > > accesses, then they should not use the optimization since it will
> > result
> > > in a lot of unaligned accesses :-) In which case they are better off
> > > falling back to the old byte-by-byte method.
> >
> > Not quite, it is only 1 of 4 accesses that uses unaligned and
> > that accesses is only unaligned 50% in average, it might still
> > be faster. We will never know now.
>
> Why ? If you think it's a win, then it's easy to make a patch to turn
> it to __KERNEL__ and ask some people from ARM and MIPS or even sparc
> land for example to give it a spin. If it's indeed a win, then submit it
> to Linus and/or Andrew and there's no reason for it not to go in.
>
> I simply took a more conservative approach for post -rc4
Perhaps for the best this late. I will just leave it as is. If ARM/MIPS et. all
wants, they can test it whenever they want.
Jocke
^ permalink raw reply
* Re: [PATCH]: powerpc: Fix build breakage due to incorrect location of autoconf.h
From: Joakim Tjernlund @ 2010-01-14 13:27 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Stephen Rothwell, Roel Kluin, linuxppc-dev@ozlabs.org list,
Richard Purdie, Anton Blanchard, Andrew Morton, David Woodhouse
In-Reply-To: <1263462224.724.356.camel@pasglop>
Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote on 14/01/2010 10:43:44:
>
> On Thu, 2010-01-14 at 10:12 +0100, Joakim Tjernlund wrote:
> > > No, that was on purpose. If an arch doesn't have efficient unaligned
> > > accesses, then they should not use the optimization since it will
> > result
> > > in a lot of unaligned accesses :-) In which case they are better off
> > > falling back to the old byte-by-byte method.
> >
> > Not quite, it is only 1 of 4 accesses that uses unaligned and
> > that accesses is only unaligned 50% in average, it might still
> > be faster. We will never know now.
>
> Why ? If you think it's a win, then it's easy to make a patch to turn
> it to __KERNEL__ and ask some people from ARM and MIPS or even sparc
> land for example to give it a spin. If it's indeed a win, then submit it
> to Linus and/or Andrew and there's no reason for it not to go in.
>
> I simply took a more conservative approach for post -rc4
It would probably be a good idea to redefine UP_UNALIGNED macro to
do 2 byte accesses in the non CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS case.
I don't think I will revisit this any time soon so I figured I should
mention it in case someone else wants to try it.
Jocke
^ permalink raw reply
* Re: [PATCH 1/2] pmac-zilog: add platform driver, version 3
From: Geert Uytterhoeven @ 2010-01-14 13:38 UTC (permalink / raw)
To: Finn Thain; +Cc: linux-m68k, linuxppc-dev
In-Reply-To: <alpine.OSX.2.00.1001110325430.620@localhost>
On Sun, Jan 10, 2010 at 17:29, Finn Thain <fthain@telegraphics.com.au> wrote:
> Add platform driver support to the pmac-zilog driver, for m68k macs.
> Place the powermac-specific code inside #ifdef CONFIG_PPC_PMAC.
>
> Signed-off-by: Finn Thain <fthain@telegraphics.com.au>
>
> ---
>
> This patch should be applied after "[PATCH 3/13] pmac-zilog: cleanup".
> It obsoletes "[PATCH 4/13] pmac-zilog, mac68k: replace mac68k SCC code
> with platform device" listed in the linux-ppc patchwork.
>
> Version 2 of this patch adopts Geert's suggestions: make better use of
> dev_{dbg,err,info} macros, change platform_driver_register() to
> platform_driver_probe(), and use __init and __exit attributes.
> Version 3 does not #include <macints.h>.
Thanks, applied.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH 4/4] phy: add RTBI mode for m88e1111
From: Kumar Gala @ 2010-01-14 16:20 UTC (permalink / raw)
To: Liu Yu; +Cc: netdev, linuxppc-dev, davem
In-Reply-To: <1263456799-3306-4-git-send-email-yu.liu@freescale.com>
On Jan 14, 2010, at 2:13 AM, Liu Yu wrote:
> Signed-off-by: Liu Yu <yu.liu@freescale.com>
> ---
> drivers/net/phy/marvell.c | 38 =
++++++++++++++++++++++++++++++++++++++
> 1 files changed, 38 insertions(+), 0 deletions(-)
>=20
> diff --git a/drivers/net/phy/marvell.c b/drivers/net/phy/marvell.c
> index 6f69b9b..65ed385 100644
> --- a/drivers/net/phy/marvell.c
> +++ b/drivers/net/phy/marvell.c
> @@ -63,6 +63,7 @@
> #define MII_M1111_HWCFG_MODE_COPPER_RGMII 0xb
> #define MII_M1111_HWCFG_MODE_FIBER_RGMII 0x3
> #define MII_M1111_HWCFG_MODE_SGMII_NO_CLK 0x4
> +#define MII_M1111_HWCFG_MODE_COPPER_RTBI 0x9
> #define MII_M1111_HWCFG_FIBER_COPPER_AUTO 0x8000
> #define MII_M1111_HWCFG_FIBER_COPPER_RES 0x2000
>=20
> @@ -269,6 +270,43 @@ static int m88e1111_config_init(struct phy_device =
*phydev)
> return err;
> }
>=20
> + if (phydev->interface =3D=3D PHY_INTERFACE_MODE_RTBI) {
> + temp =3D phy_read(phydev, MII_M1111_PHY_EXT_CR);
> + if (temp < 0)
> + return temp;
> + temp |=3D (MII_M1111_RX_DELAY | MII_M1111_TX_DELAY);
> + err =3D phy_write(phydev, MII_M1111_PHY_EXT_CR, temp);
> + if (err < 0)
> + return err;
> +
> + temp =3D phy_read(phydev, MII_M1111_PHY_EXT_SR);
> + if (temp < 0)
> + return temp;
> + temp &=3D ~(MII_M1111_HWCFG_MODE_MASK | =
MII_M1111_HWCFG_FIBER_COPPER_RES);
> + temp |=3D 0x7 | MII_M1111_HWCFG_FIBER_COPPER_AUTO;
Does this magic 0x7 have some meaning?
> + err =3D phy_write(phydev, MII_M1111_PHY_EXT_SR, temp);
> + if (err < 0)
> + return err;
> +
> + /* soft reset */
> + err =3D phy_write(phydev, MII_BMCR, BMCR_RESET);
> + if (err < 0)
> + return err;
> + do
> + temp =3D phy_read(phydev, MII_BMCR);
> + while (temp & BMCR_RESET);
> +
> + temp =3D phy_read(phydev, MII_M1111_PHY_EXT_SR);
> + if (temp < 0)
> + return temp;
> + temp &=3D ~(MII_M1111_HWCFG_MODE_MASK | =
MII_M1111_HWCFG_FIBER_COPPER_RES);
> + temp |=3D MII_M1111_HWCFG_MODE_COPPER_RTBI | =
MII_M1111_HWCFG_FIBER_COPPER_AUTO;
> + err =3D phy_write(phydev, MII_M1111_PHY_EXT_SR, temp);
> + if (err < 0)
> + return err;
> + }
> +
> +
> err =3D phy_write(phydev, MII_BMCR, BMCR_RESET);
> if (err < 0)
> return err;
> --=20
> 1.6.4
^ permalink raw reply
* [PATCH] Move /proc/ppc64 to /proc/powerpc update
From: Nathan Fontenot @ 2010-01-14 19:45 UTC (permalink / raw)
To: linuxppc-dev
It looks like the previous patch sent out to move RTAS and
other items from /proc/ppc64 to /proc/powerpc missed a few
files needed for RAS and DLPAR functionality.
Original Patch here:
http://lists.ozlabs.org/pipermail/linuxppc-dev/2009-September/076096.html
This patch updates the remaining files to be created under /proc/powerpc.
Signed-off-by: Nathan Fontenot <nfont@austin.ibm.com>
---
arch/powerpc/kernel/rtas-proc.c | 14 +++++++-------
1 file changed, 7 insertions(+), 7 deletions(-)
Index: powerpc/arch/powerpc/kernel/rtas-proc.c
===================================================================
--- powerpc.orig/arch/powerpc/kernel/rtas-proc.c 2009-12-18 09:21:51.000000000 -0600
+++ powerpc/arch/powerpc/kernel/rtas-proc.c 2010-01-14 12:25:22.000000000 -0600
@@ -262,19 +262,19 @@
if (rtas_node == NULL)
return -ENODEV;
- proc_create("ppc64/rtas/progress", S_IRUGO|S_IWUSR, NULL,
+ proc_create("powerpc/rtas/progress", S_IRUGO|S_IWUSR, NULL,
&ppc_rtas_progress_operations);
- proc_create("ppc64/rtas/clock", S_IRUGO|S_IWUSR, NULL,
+ proc_create("powerpc/rtas/clock", S_IRUGO|S_IWUSR, NULL,
&ppc_rtas_clock_operations);
- proc_create("ppc64/rtas/poweron", S_IWUSR|S_IRUGO, NULL,
+ proc_create("powerpc/rtas/poweron", S_IWUSR|S_IRUGO, NULL,
&ppc_rtas_poweron_operations);
- proc_create("ppc64/rtas/sensors", S_IRUGO, NULL,
+ proc_create("powerpc/rtas/sensors", S_IRUGO, NULL,
&ppc_rtas_sensors_operations);
- proc_create("ppc64/rtas/frequency", S_IWUSR|S_IRUGO, NULL,
+ proc_create("powerpc/rtas/frequency", S_IWUSR|S_IRUGO, NULL,
&ppc_rtas_tone_freq_operations);
- proc_create("ppc64/rtas/volume", S_IWUSR|S_IRUGO, NULL,
+ proc_create("powerpc/rtas/volume", S_IWUSR|S_IRUGO, NULL,
&ppc_rtas_tone_volume_operations);
- proc_create("ppc64/rtas/rmo_buffer", S_IRUSR, NULL,
+ proc_create("powerpc/rtas/rmo_buffer", S_IRUSR, NULL,
&ppc_rtas_rmo_buf_ops);
return 0;
}
^ permalink raw reply
* [PATCH] Move cpu hotplug driver lock from pseries to powerpc
From: Nathan Fontenot @ 2010-01-14 19:52 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Andreas Schwab
Move the defintion and lock helper routines for the cpu hotplug driver
lock from pseries to powerpc code to avoid build breaks for platforms
other than pseries that use cpu hotplug.
Signed-off-by: Nathan Fontenot <nfont@austin.ibm.com>
---
arch/powerpc/kernel/smp.c | 12 ++++++++++++
arch/powerpc/platforms/pseries/dlpar.c | 12 ------------
2 files changed, 12 insertions(+), 12 deletions(-)
Index: powerpc/arch/powerpc/kernel/smp.c
===================================================================
--- powerpc.orig/arch/powerpc/kernel/smp.c 2010-01-11 12:19:06.000000000 -0600
+++ powerpc/arch/powerpc/kernel/smp.c 2010-01-14 09:44:35.000000000 -0600
@@ -619,4 +619,16 @@
if (smp_ops->cpu_die)
smp_ops->cpu_die(cpu);
}
+
+static DEFINE_MUTEX(powerpc_cpu_hotplug_driver_mutex);
+
+void cpu_hotplug_driver_lock()
+{
+ mutex_lock(&powerpc_cpu_hotplug_driver_mutex);
+}
+
+void cpu_hotplug_driver_unlock()
+{
+ mutex_unlock(&powerpc_cpu_hotplug_driver_mutex);
+}
#endif
Index: powerpc/arch/powerpc/platforms/pseries/dlpar.c
===================================================================
--- powerpc.orig/arch/powerpc/platforms/pseries/dlpar.c 2010-01-14 09:37:48.000000000 -0600
+++ powerpc/arch/powerpc/platforms/pseries/dlpar.c 2010-01-14 09:42:50.000000000 -0600
@@ -344,18 +344,6 @@
#ifdef CONFIG_ARCH_CPU_PROBE_RELEASE
-static DEFINE_MUTEX(pseries_cpu_hotplug_mutex);
-
-void cpu_hotplug_driver_lock()
-{
- mutex_lock(&pseries_cpu_hotplug_mutex);
-}
-
-void cpu_hotplug_driver_unlock()
-{
- mutex_unlock(&pseries_cpu_hotplug_mutex);
-}
-
static int dlpar_online_cpu(struct device_node *dn)
{
int rc = 0;
^ permalink raw reply
* Re: [PATCH]: powerpc: Fix build breakage due to incorrect location of autoconf.h
From: Benjamin Herrenschmidt @ 2010-01-14 19:59 UTC (permalink / raw)
To: Joakim Tjernlund
Cc: Stephen Rothwell, Roel Kluin, linuxppc-dev@ozlabs.org list,
Richard Purdie, Anton Blanchard, Andrew Morton, David Woodhouse
In-Reply-To: <OF101A0E86.03F58830-ONC12576AB.00495BF7-C12576AB.0049E2DF@transmode.se>
On Thu, 2010-01-14 at 14:27 +0100, Joakim Tjernlund wrote:
>
> It would probably be a good idea to redefine UP_UNALIGNED macro to
> do 2 byte accesses in the non CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS
> case.
>
> I don't think I will revisit this any time soon so I figured I should
> mention it in case someone else wants to try it.
Well, get_unaligned() does just that...
Ben.
^ permalink raw reply
* [PATCH 0/2] Add max CPU nodes field to ibm,client-architecture call
From: Joel Schopp @ 2010-01-14 20:38 UTC (permalink / raw)
To: linuxppc-dev
Large NUMA machines require Linux to indicate support for more than 64
cpu cores. This is done through the ibm,client-architecture call, and
is documented in the PAPR. There is also another new field added to
indicate that the OS is Linux as a hint for possible future performance
settings.
The first patch attempts to statically initialize the number of
supported cores with NR_CPUS, the maximum Linux could boot if the cpus
did not have multi-threading (SMT). It can overestimate by the factor
of SMT. For instance on Power6 with 2 way SMT it would overestimate by
a factor of 2. The result of this overestimation is that Linux might
not be able boot all the cpus assigned to it, but would still boot
NR_CPUS worth of SMT threads.
The second patch adjusts for SMT by reading the device tree before
unflattening.
I've updated patch 1 from previous comments. Patch 1 can be taken on its
own if Patch 2 seems like overkill.
^ permalink raw reply
* [PATCH 1/2] Add static fields to ibm,client-architecture call
From: Joel Schopp @ 2010-01-14 20:40 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <1263501508.4869.133.camel@jschopp-laptop>
This patch adds 2 fields to the ibm_architecture_vec array.
The first of these fields indicates the number of cores which Linux can
boot. It does not account for SMT, so it may result in cpus assigned to
Linux which cannot be booted. A second patch follows that dynamically
updates this for SMT.
The second field just indicates that our OS is Linux, and not another
OS. The system may or may not use this hint to performance tune
settings for Linux.
Signed-off-by:Joel Schopp<jschopp@austin.ibm.com>
Index: linux-2.6.git/arch/powerpc/kernel/prom_init.c
===================================================================
--- linux-2.6.git.orig/arch/powerpc/kernel/prom_init.c
+++ linux-2.6.git/arch/powerpc/kernel/prom_init.c
@@ -654,6 +656,9 @@ static void __init early_cmdline_parse(v
#define OV5_CMO 0x00
#endif
+/* Option Vector 6: IBM PAPR hints */
+#define OV6_LINUX 0x02 /* Linux is our OS */
+
/*
* The architecture vector has an array of PVR mask/value pairs,
* followed by # option vectors - 1, followed by the option vectors.
@@ -665,7 +670,7 @@ static unsigned char ibm_architecture_ve
W(0xffffffff), W(0x0f000003), /* all 2.06-compliant */
W(0xffffffff), W(0x0f000002), /* all 2.05-compliant */
W(0xfffffffe), W(0x0f000001), /* all 2.04-compliant and earlier */
- 5 - 1, /* 5 option vectors */
+ 6 - 1, /* 6 option vectors */
/* option vector 1: processor architectures supported */
3 - 2, /* length */
@@ -697,12 +702,24 @@ static unsigned char ibm_architecture_ve
0, /* don't halt */
/* option vector 5: PAPR/OF options */
- 5 - 2, /* length */
+ 13 - 2, /* length */
0, /* don't ignore, don't halt */
OV5_LPAR | OV5_SPLPAR | OV5_LARGE_PAGES | OV5_DRCONF_MEMORY |
OV5_DONATE_DEDICATE_CPU | OV5_MSI,
0,
OV5_CMO,
+ 0,
+ 0,
+ 0,
+ 0,
+ W(NR_CPUS), /* number of cores supported*/
+
+ /* option vector 6: IBM PAPR hints */
+ 4 - 2, /* length */
+ 0,
+ 0,
+ OV6_LINUX,
+
};
/* Old method - ELF header with PT_NOTE sections */
^ permalink raw reply
* [PATCH 2/2] Update ibm,client-architecture call field based on device tree
From: Joel Schopp @ 2010-01-14 20:41 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <1263501508.4869.133.camel@jschopp-laptop>
In the previous patch the client-architecture field for the number of
cores supported is set statically as high as is possible. However, that
static setting could be too high if the system supports smt, resulting
in cpus assigned to Linux that are not booted. This patch reads the
device tree (before it is unflattened) to determine the amount of smt.
It then dynamically updates the entires in the array with the proper
number of cores supported. Tests show this correctly detecting SMT4 on
a Power7 and still booting all the supported cores on a large machine.
Signed-off-by:Joel Schopp<jschopp@austin.ibm.com>
Index: linux-2.6.git/arch/powerpc/kernel/prom_init.c
===================================================================
--- linux-2.6.git.orig/arch/powerpc/kernel/prom_init.c
+++ linux-2.6.git/arch/powerpc/kernel/prom_init.c
@@ -141,6 +141,8 @@ typedef u32 cell_t;
extern void __start(unsigned long r3, unsigned long r4, unsigned long r5);
+static int __init prom_smt_way(void);
+
#ifdef CONFIG_PPC64
extern int enter_prom(struct prom_args *args, unsigned long entry);
#else
@@ -811,9 +813,17 @@ static void __init prom_send_capabilitie
{
ihandle elfloader, root;
prom_arg_t ret;
+ u32 *cores;
root = call_prom("open", 1, 1, ADDR("/"));
if (root != 0) {
+ /*
+ * If you add to the struct, please be sure the 100 index
+ * didn't change. The BUILD_BUG_ON is a reminder.
+ */
+ BUILD_BUG_ON(sizeof(ibm_architecture_vec) != 108);
+ cores = (u32 *) &ibm_architecture_vec[100];
+ *cores = (u32) (NR_CPUS/prom_smt_way());
/* try calling the ibm,client-architecture-support method */
prom_printf("Calling ibm,client-architecture-support...");
if (call_prom_ret("call-method", 3, 2, &ret,
@@ -1031,6 +1041,45 @@ static void __init reserve_mem(u64 base,
RELOC(mem_reserve_cnt) = cnt + 1;
}
+
+static int __init prom_smt_way(void)
+{
+ phandle node;
+ char type[64];
+ unsigned int plen;
+
+ for (node = 0; prom_next_node(&node); ) {
+ type[0] = 0;
+ prom_getprop(node, "device_type", type, sizeof(type));
+
+ if (type[0] == 0) {
+ /*
+ * CHRP Longtrail machines have no device_type
+ * on the memory node, so check the name instead...
+ */
+ prom_getprop(node, "name", type, sizeof(type));
+ }
+ if (strcmp(type, RELOC("cpu")))
+ continue;
+
+ /*
+ * There is an entry for each smt thread, each entry being
+ * 4 bytes long. All cpus should have the same number of
+ * smt threads, so return after finding the first.
+ */
+ plen = prom_getproplen(node, "ibm,ppc-interrupt-server#s");
+ prom_debug("smt %x\n", (unsigned long) plen);
+ if (plen >= 4)
+ return plen / 4;
+ }
+ /*
+ * If things go wrong and we get here fallback to SMT1
+ */
+ prom_debug("unable to determine smt from device tree, guessing smt1\n");
+ return 1;
+
+}
+
/*
* Initialize memory allocation mechanism, parse "memory" nodes and
* obtain that way the top of memory and RMO to setup out local allocator
^ permalink raw reply
* Problem dtb file booting Kernel 2.6.32
From: Andres F Marquez @ 2010-01-14 20:40 UTC (permalink / raw)
To: linuxppc-dev
Hello,
I am working on a MPC8265 board which I have successfully ported Linux
Kernel 2.6.25 to. I am trying to upgrade the Kernel but have not got
good results (I am able to compile the Kernel for my powerpc, but not to
boot it). The problem appears to be something related to the interaction
between the dtb and the Kernel. I am not sure if the syntax for the dts
file may have changed from Kernel 2.6.25 to newer versions (I have tried
2.6.27.43 - 2.6.32.2 and 2.6.31.11 getting very similar results).
When I build the dtb file from the /arch/powerpc/boot/dts/MPC8272ADS.dts
file that comes with the new Kernel, the booting process gets stuck
after trying to load the device tree:
## Booting image at ff810000 ...
Image Name: Linux-2.6.27.43
Image Type: PowerPC Linux Kernel Image (gzip
compressed)
Data Size: 1365263 Bytes = 1.3 MB
Load Address: 00000000
Entry Point: 00000000
Verifying Checksum ... OK
Uncompressing Kernel Image ... OK
Booting using the fdt at 0xff802000
Loading Device Tree to 007fc000, end 007fefff ... OK
However, when I boot the new Kernel with the old compiled dtb file
(the one that works with the Kernel 2.6.25) the process moves forward
but stops at a time when displaying information about IRQ 40 line
(related to the Programmable Interrup Controller (PIC)):
## Booting image at ff810000 ...
Image Name: Linux-2.6.32.2
Image Type: PowerPC Linux Kernel Image (gzip compressed)
Data Size: 1431026 Bytes = 1.4 MB
Load Address: 00000000
Entry Point: 00000000
Verifying Checksum ... OK
Uncompressing Kernel Image ... OK
Booting using the fdt at 0xff802000
Loading Device Tree to 007fc000, end 007fefff ... OK
id mach(): done
MMU:enter
MMU:hw init
MMU:mapin
MMU:setio
MMU:exit
Using Freescale PQ2FADS machine description
Linux version 2.6.32.2 (nirmala@localhost.localdomain) (gcc
version
4.2.1 (Sourcery G++ Lite 4.2-82)) #11 Wed Jan 13 15:54:33 EST
2010
bootconsole [udbg0] enabled
setup_arch: bootmem
pq2fads_setup_arch()
No fsl,pq2fads-bcsr in device tree
arch: exit
Top of RAM: 0x2000000, Total RAM: 0x2000000
Memory hole size: 0MB
Zone PFN ranges:
DMA 0x00000000 -> 0x00002000
Normal 0x00002000 -> 0x00002000
Movable zone start PFN for each node
early_node_map[1] active PFN ranges
0: 0x00000000 -> 0x00002000
On node 0 totalpages: 8192
free_area_init_node: node 0, pgdat c02dfa18, node_mem_map
c0304000
DMA zone: 64 pages used for memmap
DMA zone: 0 pages reserved
DMA zone: 8128 pages, LIFO batch:0
Built 1 zonelists in Zone order, mobility grouping on. Total
pages: 8128
Kernel command line: console=ttyCPM0,9600 panic=10 root=1f03 rw
rootfstype=jffs2 mtdparts=physmap-flash.0:8K(reserved),56K(
fdt),1408K(uimab
PID hash table entries: 128 (order: -3, 512 bytes)
Dentry cache hash table entries: 4096 (order: 2, 16384 bytes)
Inode-cache hash table entries: 2048 (order: 1, 8192 bytes)
Memory: 29380k/32768k available (2824k kernel code, 3388k
reserved, 160k
data, 101k bss, 172k init)
Kernel virtual memory layout:
* 0xffffe000..0xfffff000 : fixmap
* 0xfe000000..0xfe000000 : early ioremap
* 0xc3000000..0xfe000000 : vmalloc & ioremap
SLUB: Genslabs=13, HWalign=32, Order=0-3, MinObjects=0, CPUs=1,
Nodes=1
Hierarchical RCU implementation.
NR_IRQS:512
No pci pic node in device tree.
time_init: decrementer frequency = 16.500000 MHz
time_init: processor frequency = 231.000000 MHz
clocksource: timebase mult[f26c9b2] shift[22] registered
clockevent: decrementer mult[4395810] shift[32] cpu[0]
Console: colour dummy device 80x25
irq: irq 40 on host /soc@f0000000/interrupt-controller@10c00
mapped to
virtual irq 40
I am attching below the MPC8272ADS.dts file that works for me for Kernel
2.6.25 (the dts file that I am trying to make work for newer Kernel):
/*
* Device Tree for the PQ2FADS-ZU board with an MPC8280 chip.
*
* Copyright 2007 Freescale Semiconductor Inc.
*
* 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.
*/
/ {
model = "pq2fads";
compatible = "fsl,pq2fads";
#address-cells = <1>;
#size-cells = <1>;
cpus {
#address-cells = <1>;
#size-cells = <0>;
cpu@0 {
device_type = "cpu";
reg = <0>;
d-cache-line-size = <d#32>;
i-cache-line-size = <d#32>;
d-cache-size = <d#16384>;
i-cache-size = <d#16384>;
timebase-frequency = <0>;
clock-frequency = <0>;
};
};
memory {
device_type = "memory";
reg = <0 0>;
};
soc@f0000000 {
#address-cells = <1>;
#size-cells = <1>;
device_type = "soc";
compatible = "fsl,mpc8280", "fsl,pq2-soc";
ranges = <00000000 f0000000 00053000>;
// Temporary -- will go away once kernel uses ranges
// for get_immrbase().
reg = <f0000000 00053000>;
cpm@119c0 {
#address-cells = <1>;
#size-cells = <1>;
#interrupt-cells = <2>;
compatible = "fsl,mpc8280-cpm", "fsl,cpm2";
reg = <119c0 30>;
ranges;
muram@0 {
#address-cells = <1>;
#size-cells = <1>;
ranges = <0 0 10000>;
data@0 {
compatible = "fsl,cpm-muram-data";
reg = <0 2000 9800 800>;
};
};
brg@119f0 {
compatible = "fsl,mpc8280-brg",
"fsl,cpm2-brg",
"fsl,cpm-brg";
reg = <119f0 10 115f0 10>;
};
serial@11a00 {
device_type = "serial";
compatible = "fsl,mpc8280-scc-uart",
"fsl,cpm2-scc-uart";
reg = <11a00 20 8000 100>;
interrupts = <28 8>;
interrupt-parent = <&PIC>;
fsl,cpm-brg = <1>;
fsl,cpm-command = <00800000>;
};
serial@11a20 {
device_type = "serial";
compatible = "fsl,mpc8280-scc-uart",
"fsl,cpm2-scc-uart";
reg = <11a20 20 8100 100>;
interrupts = <29 8>;
interrupt-parent = <&PIC>;
fsl,cpm-brg = <2>;
fsl,cpm-command = <04a00000>;
};
ethernet@11320 {
device_type = "network";
compatible = "fsl,mpc8280-fcc-enet",
"fsl,cpm2-fcc-enet";
reg = <11320 20 8500 100 113b0 1>;
interrupts = <21 8>;
interrupt-parent = <&PIC>;
phy-handle = <&PHY0>;
linux,network-index = <0>;
fsl,cpm-command = <16200300>;
local-mac-address = [00 e0 0a 03 79 01];
};
ethernet@11340 {
device_type = "network";
compatible = "fsl,mpc8280-fcc-enet",
"fsl,cpm2-fcc-enet";
reg = <11340 20 8600 100 113d0 1>;
interrupts = <22 8>;
interrupt-parent = <&PIC>;
phy-handle = <&PHY1>;
linux,network-index = <1>;
fsl,cpm-command = <1a400300>;
local-mac-address = [00 e0 0c 00 79 01];
};
mdio@10d40 {
device_type = "mdio";
compatible = "fsl,pq2fads-mdio-bitbang",
"fsl,mpc8280-mdio-bitbang",
"fsl,cpm2-mdio-bitbang";
#address-cells = <1>;
#size-cells = <0>;
reg = <10d40 14>;
fsl,mdio-pin = <9>;
fsl,mdc-pin = <a>;
PHY0: ethernet-phy@0 {
interrupt-parent = <&PIC>;
interrupts = <19 2>;
reg = <0>;
device_type = "ethernet-phy";
};
PHY1: ethernet-phy@1 {
interrupt-parent = <&PIC>;
interrupts = <19 2>;
reg = <3>;
device_type = "ethernet-phy";
};
};
};
PIC: interrupt-controller@10c00 {
#interrupt-cells = <2>;
interrupt-controller;
reg = <10c00 80>;
compatible = "fsl,mpc8280-pic", "fsl,cpm2-pic";
};
};
chosen {
linux,stdout-path = "/soc/cpm/serial@11a00";
};
};
Any help would be greatly appreciated.
--
Andres F Marquez
EdgeAccess
Development
amarquez@edgeaccess.net
^ permalink raw reply
* Re: Problem dtb file booting Kernel 2.6.32
From: Scott Wood @ 2010-01-14 21:44 UTC (permalink / raw)
To: Andres Marquez; +Cc: linuxppc-dev
In-Reply-To: <1263501641.12055.9.camel@localhost.localdomain>
Andres F Marquez wrote:
> Hello,
>
> I am working on a MPC8265 board which I have successfully ported Linux
> Kernel 2.6.25 to. I am trying to upgrade the Kernel but have not got
> good results (I am able to compile the Kernel for my powerpc, but not to
> boot it). The problem appears to be something related to the interaction
> between the dtb and the Kernel. I am not sure if the syntax for the dts
> file may have changed from Kernel 2.6.25 to newer versions (I have tried
> 2.6.27.43 - 2.6.32.2 and 2.6.31.11 getting very similar results).
Can you bisect between 2.6.25 and 2.6.27 to see which commit may have
broken it?
What sort of changes did you make to get 2.6.25 to work?
> When I build the dtb file from the /arch/powerpc/boot/dts/MPC8272ADS.dts
> file that comes with the new Kernel, the booting process gets stuck
> after trying to load the device tree:
>
> ## Booting image at ff810000 ...
> Image Name: Linux-2.6.27.43
> Image Type: PowerPC Linux Kernel Image (gzip
> compressed)
> Data Size: 1365263 Bytes = 1.3 MB
> Load Address: 00000000
> Entry Point: 00000000
> Verifying Checksum ... OK
> Uncompressing Kernel Image ... OK
> Booting using the fdt at 0xff802000
> Loading Device Tree to 007fc000, end 007fefff ... OK
>
>
> However, when I boot the new Kernel with the old compiled dtb file
> (the one that works with the Kernel 2.6.25) the process moves forward
> but stops at a time when displaying information about IRQ 40 line
> (related to the Programmable Interrup Controller (PIC)):
Decompile that device tree blob using dtc -I dtb -O dts, and look for
differences.
-Scott
^ permalink raw reply
* powerpc: should mem_end be assigned to dt_struct_end in flatten_device_tree()?
From: Roel Kluin @ 2010-01-14 23:00 UTC (permalink / raw)
To: Paul Mackerras, linuxppc-dev
vi arch/powerpc/kernel/prom_init.c +1961 and note that in
flatten_device_tree() we do a
RELOC(dt_struct_end) = PAGE_ALIGN(mem_start);
should that maybe be
RELOC(dt_struct_end) = PAGE_ALIGN(mem_end);
thanks,
Roel
^ 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