* Re: [PATCH 3/5] powerpc: Introduce CONFIG_PPC_BOOK3S
From: Arnd Bergmann @ 2009-06-02 10:49 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <20090602075022.57FE2DDF72@ozlabs.org>
On Tuesday 02 June 2009, Benjamin Herrenschmidt wrote:
> --- linux-work.orig/arch/powerpc/platforms/Kconfig.cputype 2009-06-02 16:29:27.000000000 +1000
> +++ linux-work/arch/powerpc/platforms/Kconfig.cputype 2009-06-02 16:55:01.000000000 +1000
> @@ -9,7 +9,6 @@ menu "Processor support"
> choice
> prompt "Processor Type"
> depends on PPC32
> - default 6xx
> help
> There are five families of 32 bit PowerPC chips supported.
> The most common ones are the desktop and server CPUs (601, 603,
It looks like you couldn't decide which route to take here. You leave the
'depends on PPC32' above, but
> @@ -21,24 +20,27 @@ choice
>
> If unsure, select 52xx/6xx/7xx/74xx/82xx/83xx/86xx.
>
> -config 6xx
> +config PPC_BOOK3S
> bool "512x/52xx/6xx/7xx/74xx/82xx/83xx/86xx"
> select PPC_FPU
>
> config PPC_85xx
> bool "Freescale 85xx"
> + depends on PPC32
> select E500
> select FSL_SOC
> select MPC85xx
>
> config PPC_8xx
> bool "Freescale 8xx"
> + depends on PPC32
> select FSL_SOC
> select 8xx
> select PPC_LIB_RHEAP
also add it (redundantly) in all other processor types except BOOK3S, and
> -# Until we have a choice of exclusive CPU types on 64-bit, we always
> -# use PPC_BOOK3S. On 32-bit, this is equivalent to 6xx which is
> -# "classic" MMU
> -
> config PPC_BOOK3S
> - def_bool y
> - depends on PPC64 || 6xx
> + default y
> + depends on PPC64
> + select PPC_FPU
> +
then add the other BOOK3S option depending on PPC64. Even though
it might look silly to have a choice statement with just one possible
option in case of PPC64, why not integrate it right away, for consistency
reasons. It seems strange to have the same Kconfig symbol both
as a choice and a simple bool.
> @@ -125,6 +131,7 @@ config BOOKE
> config FSL_BOOKE
> bool
> depends on E200 || E500
> + select PPC_BOOK3E_MMU
> default y
>
> config FSL_EMB_PERFMON
> @@ -203,7 +210,7 @@ config SPE
>
> config PPC_STD_MMU
> bool
> - depends on 6xx || PPC64
> + depends on PPC_BOOK3S
> default y
>
> config PPC_STD_MMU_32
This also feels inconsistent, using a 'select' in one case and 'depends on' in the
other one. The two ways are obviously equivalent, but I find it a bit confusing
to mix them.
Arnd <><
^ permalink raw reply
* How to add i2c platform data in dts file
From: Stefan Strobl @ 2009-06-02 10:54 UTC (permalink / raw)
To: ppc-dev
Hi
I'm using the i2c/chips/tsl2550 driver. In the tsl2550_probe() function
the driver checks for platform data to set the operating_mode. I suppose
I can provide this data in my dts file but I don't know how to do that.
Currently my dts looks like this:
tsl2550@39 {
compatible = "taos,tsl2550";
reg = <0x39>;
};
Can anyone help me on how to set the operating_mode here?
Thanks, Stefan.
^ permalink raw reply
* Re: [PATCH 3/5] powerpc: Introduce CONFIG_PPC_BOOK3S
From: Benjamin Herrenschmidt @ 2009-06-02 11:37 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: linuxppc-dev
In-Reply-To: <200906021149.17816.arnd@arndb.de>
On Tue, 2009-06-02 at 11:49 +0100, Arnd Bergmann wrote:
> On Tuesday 02 June 2009, Benjamin Herrenschmidt wrote:
> > --- linux-work.orig/arch/powerpc/platforms/Kconfig.cputype 2009-06-02 16:29:27.000000000 +1000
> > +++ linux-work/arch/powerpc/platforms/Kconfig.cputype 2009-06-02 16:55:01.000000000 +1000
> > @@ -9,7 +9,6 @@ menu "Processor support"
> > choice
> > prompt "Processor Type"
> > depends on PPC32
> > - default 6xx
> > help
> > There are five families of 32 bit PowerPC chips supported.
> > The most common ones are the desktop and server CPUs (601, 603,
>
> It looks like you couldn't decide which route to take here. You leave the
> 'depends on PPC32' above, but
The choice depends on PPC32 since there is no choice .. yet for 64-bit.
I removed the default 6xx because I noticed a warning from Kbuild that
it doesn't like defaults for choices.
> > config PPC_85xx
> > bool "Freescale 85xx"
> > + depends on PPC32
Ah right, I can remove these. Initially, the choice was available for
both 32 and 64 bit ;-) That's an artifact of the patch splitting since I
only introduce Book3E for 64-bit later.
> also add it (redundantly) in all other processor types except BOOK3S, and
Right. As I said, artifact of the split. I'll remove them for now.
> > -# Until we have a choice of exclusive CPU types on 64-bit, we always
> > -# use PPC_BOOK3S. On 32-bit, this is equivalent to 6xx which is
> > -# "classic" MMU
> > -
> > config PPC_BOOK3S
> > - def_bool y
> > - depends on PPC64 || 6xx
> > + default y
> > + depends on PPC64
> > + select PPC_FPU
> > +
>
> then add the other BOOK3S option depending on PPC64. Even though
> it might look silly to have a choice statement with just one possible
> option in case of PPC64, why not integrate it right away, for consistency
> reasons. It seems strange to have the same Kconfig symbol both
> as a choice and a simple bool.
Well, I was hesitating. The initial patch added the choice with E and S
for both 32 and 64 as you can guess. But we aren't ready for that yet.
I suppose I can do a one-option choice in the meantime.
> > @@ -125,6 +131,7 @@ config BOOKE
> > config FSL_BOOKE
> > bool
> > depends on E200 || E500
> > + select PPC_BOOK3E_MMU
> > default y
> >
> > config FSL_EMB_PERFMON
> > @@ -203,7 +210,7 @@ config SPE
> >
> > config PPC_STD_MMU
> > bool
> > - depends on 6xx || PPC64
> > + depends on PPC_BOOK3S
> > default y
> >
> > config PPC_STD_MMU_32
>
> This also feels inconsistent, using a 'select' in one case and 'depends on' in the
> other one. The two ways are obviously equivalent, but I find it a bit confusing
> to mix them.
Right, I should probably use select in both.
Cheers,
Ben.
^ permalink raw reply
* Re: MPC8343 - serial8250: too much work
From: Alemao @ 2009-06-02 13:24 UTC (permalink / raw)
To: linuxppc-dev, linux-kernel
In-Reply-To: <1243817268.4375.28.camel@concordia>
Hi all,
In a normal situation, I have something like this:
serial8250_interrupt()
serial8250_handle_port()
transmit_chars()
pass_counter: 0
serial8250_handle_port()
pass_counter: 1
serial8250_handle_port()
pass_counter: 2
pass_counter: 3
But when the problem happends:
serial8250_interrupt(16)
serial8250_handle_port()
transmit_chars()
uart_circ_empty()
pass_counter: 0
.
.
.
serial8250_handle_port()
transmit_chars()
uart_circ_empty()
pass_counter: 257
serial8250: too much work for irq16
If the circ buffer is empty, why iterate 256 times?
How can I trace the application that is calling serial routines?
Its difficult to debug cause I use serial console to communicate with the board.
Thanks in advance,
--
Alemao
^ permalink raw reply
* Re: [PATCH 1/4] net/phy/marvell: update m88e1111 support for SGMII mode
From: Haiying Wang @ 2009-06-02 14:03 UTC (permalink / raw)
To: David Miller; +Cc: linuxppc-dev, netdev
In-Reply-To: <20090601.025151.146454973.davem@davemloft.net>
On Mon, 2009-06-01 at 02:51 -0700, David Miller wrote:
> Patch 3 of this series doesn't apply cleanly to net-next-2.6
> so I'm dropping the entire patch set.
> Also, in patch 3 you put your signoff in the Subject line.
>
> Please fix all of this up and resubmit your patch series.
I only verified the first three patches could be applied to your
net-2.6, did not verify whether they could be applied for net-next-2.6.
Sorry.
I've fixed the patch3 against net-next-2.6 now, and will resubmit the
patches.
But the patch4 can not be applied to your net-next-2.6 since there is
not 8569mds support in that tree. Hope Kumar can pick up the patch 4.
Thanks.
Haiying
^ permalink raw reply
* [PATCH 1/4] net/phy/marvell: update m88e1111 support for SGMII mode
From: Haiying Wang @ 2009-06-02 14:04 UTC (permalink / raw)
To: davem, galak; +Cc: linuxppc-dev, Haiying Wang, netdev
Disable fiber/copper auto selection for Marvell m88e1111 SGMII support.
Signed-off-by: Haiying Wang <Haiying.Wang@freescale.com>
---
drivers/net/phy/marvell.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/net/phy/marvell.c b/drivers/net/phy/marvell.c
index 7a3ec9d..dd6f54d 100644
--- a/drivers/net/phy/marvell.c
+++ b/drivers/net/phy/marvell.c
@@ -243,6 +243,7 @@ static int m88e1111_config_init(struct phy_device *phydev)
temp &= ~(MII_M1111_HWCFG_MODE_MASK);
temp |= MII_M1111_HWCFG_MODE_SGMII_NO_CLK;
+ temp |= MII_M1111_HWCFG_FIBER_COPPER_AUTO;
err = phy_write(phydev, MII_M1111_PHY_EXT_SR, temp);
if (err < 0)
--
1.6.0.2
^ permalink raw reply related
* [PATCH 2/4] fsl_pq_mido: Set the first UCC as the mii management interface master
From: Haiying Wang @ 2009-06-02 14:04 UTC (permalink / raw)
To: davem, galak; +Cc: linuxppc-dev, Haiying Wang, netdev
In-Reply-To: <1243951456-4685-1-git-send-email-Haiying.Wang@freescale.com>
Current code makes the UCC whose register range includes the current mdio
register to be the MII managemnt interface master of the QE. If there is more
than one mdio bus for QE, the UCC of the last mdio bus will be the MII
management interface master which will make the primary mdio bus working
unproperly, e.g. can not get the right clock. Normally the primary mdio bus is
the first UEC's mdio bus.
This patch allows the first UCC to be the MII management interface master of the
multiple UCC mdio buses.
Signed-off-by: Haiying Wang <Haiying.Wang@freescale.com>
---
drivers/net/fsl_pq_mdio.c | 6 +++++-
1 files changed, 5 insertions(+), 1 deletions(-)
diff --git a/drivers/net/fsl_pq_mdio.c b/drivers/net/fsl_pq_mdio.c
index d12e0e0..3af5813 100644
--- a/drivers/net/fsl_pq_mdio.c
+++ b/drivers/net/fsl_pq_mdio.c
@@ -301,13 +301,17 @@ static int fsl_pq_mdio_probe(struct of_device *ofdev,
of_device_is_compatible(np, "ucc_geth_phy")) {
#ifdef CONFIG_UCC_GETH
u32 id;
+ static u32 mii_mng_master;
tbipa = ®s->utbipar;
if ((err = get_ucc_id_for_range(addr, addr + size, &id)))
goto err_free_irqs;
- ucc_set_qe_mux_mii_mng(id - 1);
+ if (!mii_mng_master) {
+ mii_mng_master = id;
+ ucc_set_qe_mux_mii_mng(id - 1);
+ }
#else
err = -ENODEV;
goto err_free_irqs;
--
1.6.0.2
^ permalink raw reply related
* [PATCH 3/4 v2] net/ucc_geth: Add SGMII support for UEC GETH driver
From: Haiying Wang @ 2009-06-02 14:04 UTC (permalink / raw)
To: davem, galak; +Cc: linuxppc-dev, Haiying Wang, netdev
In-Reply-To: <1243951456-4685-2-git-send-email-Haiying.Wang@freescale.com>
Signed-off-by: Haiying Wang <Haiying.Wang@freescale.com>
---
arch/powerpc/include/asm/qe.h | 2 +
drivers/net/ucc_geth.c | 79 ++++++++++++++++++++++++++++++++++++++++-
drivers/net/ucc_geth.h | 28 ++++++++++++++-
3 files changed, 107 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/include/asm/qe.h b/arch/powerpc/include/asm/qe.h
index 2701753..4459d20 100644
--- a/arch/powerpc/include/asm/qe.h
+++ b/arch/powerpc/include/asm/qe.h
@@ -668,6 +668,8 @@ struct ucc_slow_pram {
#define UCC_GETH_UPSMR_RMM 0x00001000
#define UCC_GETH_UPSMR_CAM 0x00000400
#define UCC_GETH_UPSMR_BRO 0x00000200
+#define UCC_GETH_UPSMR_SMM 0x00000080
+#define UCC_GETH_UPSMR_SGMM 0x00000020
/* UCC Transmit On Demand Register (UTODR) */
#define UCC_SLOW_TOD 0x8000
diff --git a/drivers/net/ucc_geth.c b/drivers/net/ucc_geth.c
index 0cf22c4..fd6140b 100644
--- a/drivers/net/ucc_geth.c
+++ b/drivers/net/ucc_geth.c
@@ -1,5 +1,5 @@
/*
- * Copyright (C) 2006-2007 Freescale Semicondutor, Inc. All rights reserved.
+ * Copyright (C) 2006-2009 Freescale Semicondutor, Inc. All rights reserved.
*
* Author: Shlomi Gridish <gridish@freescale.com>
* Li Yang <leoli@freescale.com>
@@ -65,6 +65,8 @@
static DEFINE_SPINLOCK(ugeth_lock);
+static void uec_configure_serdes(struct net_device *dev);
+
static struct {
u32 msg_enable;
} debug = { -1 };
@@ -1410,6 +1412,9 @@ static int adjust_enet_interface(struct ucc_geth_private *ugeth)
(ugeth->phy_interface == PHY_INTERFACE_MODE_RTBI)) {
upsmr |= UCC_GETH_UPSMR_TBIM;
}
+ if ((ugeth->phy_interface == PHY_INTERFACE_MODE_SGMII))
+ upsmr |= UCC_GETH_UPSMR_SGMM;
+
out_be32(&uf_regs->upsmr, upsmr);
/* Disable autonegotiation in tbi mode, because by default it
@@ -1554,6 +1559,9 @@ static int init_phy(struct net_device *dev)
return -ENODEV;
}
+ if (priv->phy_interface == PHY_INTERFACE_MODE_SGMII)
+ uec_configure_serdes(dev);
+
phydev->supported &= (ADVERTISED_10baseT_Half |
ADVERTISED_10baseT_Full |
ADVERTISED_100baseT_Half |
@@ -1569,7 +1577,41 @@ static int init_phy(struct net_device *dev)
return 0;
}
+/* Initialize TBI PHY interface for communicating with the
+ * SERDES lynx PHY on the chip. We communicate with this PHY
+ * through the MDIO bus on each controller, treating it as a
+ * "normal" PHY at the address found in the UTBIPA register. We assume
+ * that the UTBIPA register is valid. Either the MDIO bus code will set
+ * it to a value that doesn't conflict with other PHYs on the bus, or the
+ * value doesn't matter, as there are no other PHYs on the bus.
+ */
+static void uec_configure_serdes(struct net_device *dev)
+{
+ struct ucc_geth_private *ugeth = netdev_priv(dev);
+
+ if (!ugeth->tbiphy) {
+ printk(KERN_WARNING "SGMII mode requires that the device "
+ "tree specify a tbi-handle\n");
+ return;
+ }
+
+ /*
+ * If the link is already up, we must already be ok, and don't need to
+ * configure and reset the TBI<->SerDes link. Maybe U-Boot configured
+ * everything for us? Resetting it takes the link down and requires
+ * several seconds for it to come back.
+ */
+ if (phy_read(ugeth->tbiphy, ENET_TBI_MII_SR) & TBISR_LSTATUS)
+ return;
+
+ /* Single clk mode, mii mode off(for serdes communication) */
+ phy_write(ugeth->tbiphy, ENET_TBI_MII_ANA, TBIANA_SETTINGS);
+ phy_write(ugeth->tbiphy, ENET_TBI_MII_TBICON, TBICON_CLK_SELECT);
+
+ phy_write(ugeth->tbiphy, ENET_TBI_MII_CR, TBICR_SETTINGS);
+
+}
static int ugeth_graceful_stop_tx(struct ucc_geth_private *ugeth)
{
@@ -3523,6 +3565,8 @@ static phy_interface_t to_phy_interface(const char *phy_connection_type)
return PHY_INTERFACE_MODE_RGMII_RXID;
if (strcasecmp(phy_connection_type, "rtbi") == 0)
return PHY_INTERFACE_MODE_RTBI;
+ if (strcasecmp(phy_connection_type, "sgmii") == 0)
+ return PHY_INTERFACE_MODE_SGMII;
return PHY_INTERFACE_MODE_MII;
}
@@ -3567,6 +3611,7 @@ static int ucc_geth_probe(struct of_device* ofdev, const struct of_device_id *ma
PHY_INTERFACE_MODE_RMII, PHY_INTERFACE_MODE_RGMII,
PHY_INTERFACE_MODE_GMII, PHY_INTERFACE_MODE_RGMII,
PHY_INTERFACE_MODE_TBI, PHY_INTERFACE_MODE_RTBI,
+ PHY_INTERFACE_MODE_SGMII,
};
ugeth_vdbg("%s: IN", __func__);
@@ -3682,6 +3727,7 @@ static int ucc_geth_probe(struct of_device* ofdev, const struct of_device_id *ma
case PHY_INTERFACE_MODE_RGMII_TXID:
case PHY_INTERFACE_MODE_TBI:
case PHY_INTERFACE_MODE_RTBI:
+ case PHY_INTERFACE_MODE_SGMII:
max_speed = SPEED_1000;
break;
default:
@@ -3756,6 +3802,37 @@ static int ucc_geth_probe(struct of_device* ofdev, const struct of_device_id *ma
ugeth->ndev = dev;
ugeth->node = np;
+ /* 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 of_device *ofdev;
+ struct mii_bus *bus;
+ const unsigned int *id;
+
+ if (!tbi)
+ return 0;
+
+ mdio = of_get_parent(tbi);
+ if (!mdio)
+ return 0;
+
+ ofdev = of_find_device_by_node(mdio);
+
+ of_node_put(mdio);
+
+ id = of_get_property(tbi, "reg", NULL);
+ if (!id)
+ return 0;
+ of_node_put(tbi);
+
+ bus = dev_get_drvdata(&ofdev->dev);
+ if (!bus)
+ return 0;
+
+ ugeth->tbiphy = bus->phy_map[*id];
+ }
+
return 0;
}
diff --git a/drivers/net/ucc_geth.h b/drivers/net/ucc_geth.h
index dca628a..deb962b 100644
--- a/drivers/net/ucc_geth.h
+++ b/drivers/net/ucc_geth.h
@@ -1,5 +1,5 @@
/*
- * Copyright (C) Freescale Semicondutor, Inc. 2006. All rights reserved.
+ * Copyright (C) Freescale Semicondutor, Inc. 2006-2009. All rights reserved.
*
* Author: Shlomi Gridish <gridish@freescale.com>
*
@@ -193,6 +193,31 @@ struct ucc_geth {
#define ENET_TBI_MII_JD 0x10 /* Jitter diagnostics */
#define ENET_TBI_MII_TBICON 0x11 /* TBI control */
+/* TBI MDIO register bit fields*/
+#define TBISR_LSTATUS 0x0004
+#define TBICON_CLK_SELECT 0x0020
+#define TBIANA_ASYMMETRIC_PAUSE 0x0100
+#define TBIANA_SYMMETRIC_PAUSE 0x0080
+#define TBIANA_HALF_DUPLEX 0x0040
+#define TBIANA_FULL_DUPLEX 0x0020
+#define TBICR_PHY_RESET 0x8000
+#define TBICR_ANEG_ENABLE 0x1000
+#define TBICR_RESTART_ANEG 0x0200
+#define TBICR_FULL_DUPLEX 0x0100
+#define TBICR_SPEED1_SET 0x0040
+
+#define TBIANA_SETTINGS ( \
+ TBIANA_ASYMMETRIC_PAUSE \
+ | TBIANA_SYMMETRIC_PAUSE \
+ | TBIANA_FULL_DUPLEX \
+ )
+#define TBICR_SETTINGS ( \
+ TBICR_PHY_RESET \
+ | TBICR_ANEG_ENABLE \
+ | TBICR_FULL_DUPLEX \
+ | TBICR_SPEED1_SET \
+ )
+
/* UCC GETH MACCFG1 (MAC Configuration 1 Register) */
#define MACCFG1_FLOW_RX 0x00000020 /* Flow Control
Rx */
@@ -1188,6 +1213,7 @@ struct ucc_geth_private {
struct ugeth_mii_info *mii_info;
struct phy_device *phydev;
+ struct phy_device *tbiphy;
phy_interface_t phy_interface;
int max_speed;
uint32_t msg_enable;
--
1.6.0.2
^ permalink raw reply related
* [PATCH 4/4] MPC85xx: Add UCC6 and UCC8 nodes in SGMII mode for MPC8569MDS
From: Haiying Wang @ 2009-06-02 14:04 UTC (permalink / raw)
To: davem, galak; +Cc: linuxppc-dev, Haiying Wang, netdev
In-Reply-To: <1243951456-4685-3-git-send-email-Haiying.Wang@freescale.com>
Signed-off-by: Haiying Wang <Haiying.Wang@freescale.com>
---
arch/powerpc/boot/dts/mpc8569mds.dts | 63 ++++++++++++++++++++++++++++++++++
1 files changed, 63 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/boot/dts/mpc8569mds.dts b/arch/powerpc/boot/dts/mpc8569mds.dts
index 39c2927..4e95abd 100644
--- a/arch/powerpc/boot/dts/mpc8569mds.dts
+++ b/arch/powerpc/boot/dts/mpc8569mds.dts
@@ -24,6 +24,8 @@
ethernet1 = &enet1;
ethernet2 = &enet2;
ethernet3 = &enet3;
+ ethernet5 = &enet5;
+ ethernet7 = &enet7;
pci1 = &pci1;
rapidio0 = &rio0;
};
@@ -466,6 +468,37 @@
reg = <0x3>;
device_type = "ethernet-phy";
};
+ qe_phy5: ethernet-phy@04 {
+ interrupt-parent = <&mpic>;
+ reg = <0x04>;
+ device_type = "ethernet-phy";
+ };
+ qe_phy7: ethernet-phy@06 {
+ interrupt-parent = <&mpic>;
+ reg = <0x6>;
+ device_type = "ethernet-phy";
+ };
+ };
+ mdio@3520 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0x3520 0x18>;
+ compatible = "fsl,ucc-mdio";
+
+ tbi0: tbi-phy@15 {
+ reg = <0x15>;
+ device_type = "tbi-phy";
+ };
+ };
+ mdio@3720 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0x3720 0x38>;
+ compatible = "fsl,ucc-mdio";
+ tbi1: tbi-phy@17 {
+ reg = <0x17>;
+ device_type = "tbi-phy";
+ };
};
enet2: ucc@2200 {
@@ -513,6 +546,36 @@
phy-connection-type = "rgmii-id";
};
+ enet5: ucc@3400 {
+ device_type = "network";
+ compatible = "ucc_geth";
+ cell-index = <6>;
+ reg = <0x3400 0x200>;
+ interrupts = <41>;
+ interrupt-parent = <&qeic>;
+ local-mac-address = [ 00 00 00 00 00 00 ];
+ rx-clock-name = "none";
+ tx-clock-name = "none";
+ tbi-handle = <&tbi0>;
+ phy-handle = <&qe_phy5>;
+ phy-connection-type = "sgmii";
+ };
+
+ enet7: ucc@3600 {
+ device_type = "network";
+ compatible = "ucc_geth";
+ cell-index = <8>;
+ reg = <0x3600 0x200>;
+ interrupts = <43>;
+ interrupt-parent = <&qeic>;
+ local-mac-address = [ 00 00 00 00 00 00 ];
+ rx-clock-name = "none";
+ tx-clock-name = "none";
+ tbi-handle = <&tbi1>;
+ phy-handle = <&qe_phy7>;
+ phy-connection-type = "sgmii";
+ };
+
muram@10000 {
#address-cells = <1>;
#size-cells = <1>;
--
1.6.0.2
^ permalink raw reply related
* MPC52xx simple GPIO support
From: Stefan Strobl @ 2009-06-02 17:02 UTC (permalink / raw)
To: ppc-dev
Hi
I still don't quite understand how to use the Flattened Device Tree /
Open Firmware. I see there's a driver (mpc52xx_gpt.c) that supports to
use the Pins on the GPT as simple GPIOs. I activated it by adding these
lines to my dts file:
gpt2: timer@620 {
compatible = "fsl,mpc5200b-gpt-gpio","fsl,mpc5200-gpt-gpio";
reg = <0x620 0x10>;
interrupts = <1 11 0>;
gpio-controller;
#gpio-cells = <2>;
};
I can see the appropriate entries in sysfs
(/sys/devices/f0000000.soc5200/f0000620.timer), but how can I actually
use these GPIO's now?
Many thanks
Stefan.
^ permalink raw reply
* Re: MPC52xx simple GPIO support
From: Anton Vorontsov @ 2009-06-02 17:15 UTC (permalink / raw)
To: Stefan Strobl; +Cc: ppc-dev
In-Reply-To: <4A255B21.8040002@gersys.de>
Hi Stefan,
On Tue, Jun 02, 2009 at 07:02:25PM +0200, Stefan Strobl wrote:
> Hi
> I still don't quite understand how to use the Flattened Device Tree /
> Open Firmware. I see there's a driver (mpc52xx_gpt.c) that supports to
> use the Pins on the GPT as simple GPIOs. I activated it by adding these
> lines to my dts file:
>
> gpt2: timer@620 {
> compatible = "fsl,mpc5200b-gpt-gpio","fsl,mpc5200-gpt-gpio";
> reg = <0x620 0x10>;
> interrupts = <1 11 0>;
> gpio-controller;
> #gpio-cells = <2>;
> };
>
> I can see the appropriate entries in sysfs
> (/sys/devices/f0000000.soc5200/f0000620.timer), but how can I actually
> use these GPIO's now?
For in-kernel usage example you can take a look at:
arch/powerpc/boot/dts/mpc836x_rdk.dts (upm node, notice gpios = <>)
drivers/mtd/nand/fsl_upm.c (of_get_gpio() then gpio_request()).
For userland usage you need to enable CONFIG_GPIO_SYSFS, and then
look into /sys/class/gpio/{gpiochip,export,gpioNNN}.
--
Anton Vorontsov
email: cbouatmailru@gmail.com
irc://irc.freenode.net/bd2
^ permalink raw reply
* Re: [PATCH] mmc: Fix the wrong accessor to HOSTVER register
From: Anton Vorontsov @ 2009-06-02 17:26 UTC (permalink / raw)
To: Dave Liu; +Cc: linuxppc-dev, pierre, sdhci-devel, ben-linux, drzeus-sdhci
In-Reply-To: <1241606407-18685-1-git-send-email-daveliu@freescale.com>
On Wed, May 06, 2009 at 06:40:07PM +0800, Dave Liu wrote:
> Freescale eSDHC controller has the special order for
> the HOST version register. that is not same as the other's
> registers. The address of HOSTVER in spec is 0xFE, and
> we need use the in_be16(0xFE) to access it, not in_be16(0xFC).
>
> Signed-off-by: Dave Liu <daveliu@freescale.com>
Sorry for the delay Dave. This patch is surely
Acked-by: Anton Vorontsov <avorontsov@ru.mvista.com>
> ---
> drivers/mmc/host/sdhci-of.c | 8 +++++++-
> 1 files changed, 7 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/mmc/host/sdhci-of.c b/drivers/mmc/host/sdhci-of.c
> index 3ff4ac3..e167131 100644
> --- a/drivers/mmc/host/sdhci-of.c
> +++ b/drivers/mmc/host/sdhci-of.c
> @@ -55,7 +55,13 @@ static u32 esdhc_readl(struct sdhci_host *host, int reg)
>
> static u16 esdhc_readw(struct sdhci_host *host, int reg)
> {
> - return in_be16(host->ioaddr + (reg ^ 0x2));
> + u16 ret;
> +
> + if (unlikely(reg == SDHCI_HOST_VERSION))
> + ret = in_be16(host->ioaddr + reg);
> + else
> + ret = in_be16(host->ioaddr + (reg ^ 0x2));
> + return ret;
> }
>
> static u8 esdhc_readb(struct sdhci_host *host, int reg)
> --
> 1.5.4
Thanks,
--
Anton Vorontsov
email: cbouatmailru@gmail.com
irc://irc.freenode.net/bd2
^ permalink raw reply
* Re: [PATCH] powerpc: tiny memcpy_(to|from)io optimisation
From: Albrecht Dreß @ 2009-06-02 18:45 UTC (permalink / raw)
To: Joakim Tjernlund; +Cc: linuxppc-dev
In-Reply-To: <OFEEF9A8F1.2B11D1F7-ONC12575C8.00214DF9-C12575C8.00224E4F@transmode.se>
[-- Attachment #1: Type: text/plain, Size: 1857 bytes --]
Am 01.06.09 08:14 schrieb(en) Joakim Tjernlund:
> .. not even 4.2.2 which is fairly modern will get it right. It breaks
> very easy as gcc has never been any good at this type of
> optimization. Sometimes small changes will make gcc unhappy and it
> won't do the right optimization.
It's even worse... Looking at the assembly output of the simple
function
<snip>
void loop2(void * src, void * dst, int n)
{
volatile uint32_t * _dst = (volatile uint32_t *) (dst - 4);
volatile uint32_t * _src = (volatile uint32_t *) (src - 4);
n >>= 2;
do {
*(++_dst) = *(++_src);
} while (--n);
}
</snip>
gcc 4.0.1 coming with Apple's Developer Tools (on Tiger) with options
"-O3 -mcpu=603e -mtune=603e" produces
<snip>
_loop2:
srawi r5,r5,2
mtctr r5
addi r4,r4,-4
addi r3,r3,-4
L11:
lwzu r0,4(r3)
stwu r0,4(r4)
bdnz L11
blr
</snip>
which looks perfect to me. However, gcc 4.3.3 on Ubuntu/PPC produces
with the same options
<snip>
loop2:
srawi 5,5,2
stwu 1,-16(1)
mtctr 5
li 9,0
.L8:
lwzx 0,3,9
stwx 0,4,9
addi 9,9,4
bdnz .L8
addi 1,1,16
blr
</snip>
wasting a register and a statement in the loop core, and fiddles around
with the stack pointer for no good reason. Gcc 4.4.0 produces
<snip>
loop2:
srawi 5,5,2
mtctr 5
li 9,0
.L9:
lwzx 0,3,9
stwx 0,4,9
addi 9,9,4
bdnz .L9
blr
</snip>
which drops the r1 accesses, but still produces the sub-optimal loop.
Is this a gcc regression, or did I miss something here? Probably the
only bullet-proof way is to write some core loops in assembly... :-/
Thanks, Albrecht.
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: is the resolution of do_gettimeofday in usec?
From: Chris Friesen @ 2009-06-02 20:28 UTC (permalink / raw)
To: wael showair; +Cc: linuxppc-dev
In-Reply-To: <23807779.post@talk.nabble.com>
wael showair wrote:
> Hi All,
> i have board that contains MPC8555 processor with linux 2.6.27 ported to it.
> i want to use an accurate function to measure the time. i searched the
> kernel code & i found several functions but i read that the do_gettimeofday
> is the most accurate one since it has a timer resolution of usec.
You might also look at clock_gettime(), which has a theoretical accuracy
of nanoseconds. Both this and gettimeofday are NTP-corrected if you are
synced to an NTP clock.
> my question is how this function give this accuracy while the kernel timer
> is 4msec?
The accuracy of the timestamp is not related to the tick interval.
Chris
^ permalink raw reply
* Re: [PATCH v2] i2c-mpc: generate START condition after STOP caused by read i2c_msg
From: Ben Dooks @ 2009-06-02 22:25 UTC (permalink / raw)
To: Esben Haabendal; +Cc: Kumar Gala, linux-i2c, linuxppc-dev
In-Reply-To: <d2b9ea600905281315x435cdb05ia7b016b3d60c4a65@mail.gmail.com>
On Thu, May 28, 2009 at 10:15:22PM +0200, Esben Haabendal wrote:
> On Thu, May 28, 2009 at 9:31 PM, Grant Likely <grant.likely@secretlab.ca> wrote:
> > On Tue, May 26, 2009 at 5:30 AM, Esben Haabendal wrote:
> >> On Tue, May 19, 2009 at 7:22 AM, Esben Haabendal wrote:
> >>> This fixes MAL (arbitration lost) bug caused by illegal use of
> >>> RSTA (repeated START) after STOP condition generated after last byte
> >>> of reads. With this patch, it is possible to do an i2c_transfer() with
> >>> additional i2c_msg's following the I2C_M_RD messages.
> >>>
> >>> It still needs to be resolved if it is possible to fix this issue
> >>> by removing the STOP condition after reads in a robust way.
> >>>
> >>> Signed-off-by: Esben Haabendal <eha@doredevelopment.dk>
> >>> ---
> >>> ?drivers/i2c/busses/i2c-mpc.c | ? ?9 +++++++--
> >>> ?1 files changed, 7 insertions(+), 2 deletions(-)
> >>
> >> Any blockers to get this accepted?
> >
> > It helps if you cc: developers/maintainers of the device. ?ie. Kumar
> > for mpc8xxx, me for 52xx.
> >
> > This is the first time I noticed your posting. ?It will take me a few
> > days before I get a chance to review it.
>
> Kumar, will you take a look at this patch?
is anyone else likely to review it, or should I merge?
--
Ben (ben@fluff.org, http://www.fluff.org/)
'a smiley only costs 4 bytes'
^ permalink raw reply
* Re: [PATCH] powerpc: tiny memcpy_(to|from)io optimisation
From: Benjamin Herrenschmidt @ 2009-06-02 22:51 UTC (permalink / raw)
To: Albrecht Dreß; +Cc: linuxppc-dev
In-Reply-To: <1243968361.4951.0@antares>
On Tue, 2009-06-02 at 20:45 +0200, Albrecht Dreß wrote:
>
> which drops the r1 accesses, but still produces the sub-optimal loop.
> Is this a gcc regression, or did I miss something here? Probably the
> only bullet-proof way is to write some core loops in assembly... :-/
Well, gcc may be right here. What you call the "optimal" loop uses the
lwzu instruction. An interesting thing about this instruction is that
it updates two GPRs at completion (I'm ignoring the load multiple and
string instructions on purpose here).
Now, quite a few simple implementations don't have two write ports to
the GPR file, nor the logic to handle hazards properly with two GPRs
being updated... which means the instruction is very likely to take a
very inefficient path through the pipeline. On server processors, I'm
pretty sure it's just cracked into a load and an add anyway.
I wouldn't be surprised thus if the loop variant with the separate add
ends up more efficient on most implementations around.
Of course, the loop above could use some unrolling to put some distance
between the load and the store of the loaded value.
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH v2] i2c-mpc: generate START condition after STOP caused by read i2c_msg
From: Grant Likely @ 2009-06-02 23:12 UTC (permalink / raw)
To: Esben Haabendal; +Cc: linuxppc-dev, linux-i2c, Ben Dooks
In-Reply-To: <4A124202.4010201@doredevelopment.dk>
Hi Esben and Ben,
Sorry for the lateness in reviewing this. FWIW, here are my comments.
g.
On Mon, May 18, 2009 at 11:22 PM, Esben Haabendal
<eha@doredevelopment.dk> wrote:
> This fixes MAL (arbitration lost) bug caused by illegal use of
> RSTA (repeated START) after STOP condition generated after last byte
> of reads. With this patch, it is possible to do an i2c_transfer() with
> additional i2c_msg's following the I2C_M_RD messages.
>
> It still needs to be resolved if it is possible to fix this issue
> by removing the STOP condition after reads in a robust way.
>
> Signed-off-by: Esben Haabendal <eha@doredevelopment.dk>
> ---
> =A0drivers/i2c/busses/i2c-mpc.c | =A0 =A09 +++++++--
> =A01 files changed, 7 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/i2c/busses/i2c-mpc.c b/drivers/i2c/busses/i2c-mpc.c
> index 4af5c09..0199f9a 100644
> --- a/drivers/i2c/busses/i2c-mpc.c
> +++ b/drivers/i2c/busses/i2c-mpc.c
> @@ -456,17 +456,22 @@ static int mpc_xfer(struct i2c_adapter *adap, struc=
t
> i2c_msg *msgs, int num)
> =A0 =A0 =A0 =A0}
>
> =A0 =A0 =A0 =A0for (i =3D 0; ret >=3D 0 && i < num; i++) {
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 int restart =3D i;
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0pmsg =3D &msgs[i];
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0dev_dbg(i2c->dev,
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0"Doing %s %d bytes to 0x%0=
2x - %d of %d messages\n",
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0pmsg->flags & I2C_M_RD ? "=
read" : "write",
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0pmsg->len, pmsg->addr, i +=
1, num);
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 if (i > 0 && ((pmsg - 1)->flags & I2C_M_RD)=
)
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 restart =3D 0;
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0if (pmsg->flags & I2C_M_RD)
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0ret =3D
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 mpc_read(i2c, pmsg-=
>addr, pmsg->buf, pmsg->len,
> i);
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 mpc_read(i2c, pmsg-=
>addr, pmsg->buf, pmsg->len,
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
restart);
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0else
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0ret =3D
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 mpc_write(i2c, pmsg=
->addr, pmsg->buf, pmsg->len,
> i);
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 mpc_write(i2c, pmsg=
->addr, pmsg->buf, pmsg->len,
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
restart);
> =A0 =A0 =A0 =A0}
Hmmm, seems to be a rather convoluted code path. Surely this could be
handled in a clearer way. The whole (pmsg - 1) bit raises my eyebrows
(I'd rather see msgs[i-1]). At the very least this deserves an
comment describing what it is doing. The following might be better
for the next person who has to read this code:
+ int restart =3D 0;
for (i =3D 0; ret >=3D 0 && i < num; i++) {
pmsg =3D &msgs[i];
dev_dbg(i2c->dev,
"Doing %s %d bytes to 0x%02x - %d of %d messages\n",
pmsg->flags & I2C_M_RD ? "read" : "write",
pmsg->len, pmsg->addr, i + 1, num);
if (pmsg->flags & I2C_M_RD)
ret =3D
- mpc_read(i2c, pmsg->addr, pmsg->buf, pmsg->len,
i);
+ mpc_read(i2c, pmsg->addr, pmsg->buf, pmsg->len,
+ restart);
else
ret =3D
- mpc_write(i2c, pmsg->addr, pmsg->buf, pmsg->len=
,
i);
+ mpc_write(i2c, pmsg->addr, pmsg->buf, pmsg->len=
,
+ restart);
+ /* Only set the restart flag if this was not an
I2C_M_RD transaction
+ * because it causes an illegal use of
+ * RSTA (repeated START) after STOP condition
generated after last byte
+ * of reads */
+ restart =3D (pmsg->flags & I2C_M_RD =3D=3D 0);
}
g.
--=20
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* [git pull] Please pull powerpc.git merge branch
From: Benjamin Herrenschmidt @ 2009-06-02 23:22 UTC (permalink / raw)
To: Linus Torvalds; +Cc: linuxppc-dev list, Andrew Morton, Linux Kernel list
Hi Linus !
Here's a defconfig update if you still get things in .30
Cheers,
Ben.
The following changes since commit d9244b5d2fbfe9fa540024b410047af13ceec90f:
Linus Torvalds (1):
Merge branch 'hwmon-for-linus' of git://git.kernel.org/.../jdelvare/staging
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc.git merge
Benjamin Herrenschmidt (1):
powerpc/pmac: Update PowerMac 32-bit defconfig
arch/powerpc/configs/pmac32_defconfig | 278 +++++++++++++++++++++++----------
1 files changed, 195 insertions(+), 83 deletions(-)
^ permalink raw reply
* Re: [PATCH 3/5] powerpc: Introduce CONFIG_PPC_BOOK3S
From: Benjamin Herrenschmidt @ 2009-06-03 1:54 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: linuxppc-dev
In-Reply-To: <200906021149.17816.arnd@arndb.de>
On Tue, 2009-06-02 at 11:49 +0100, Arnd Bergmann wrote:
>
> then add the other BOOK3S option depending on PPC64. Even though
> it might look silly to have a choice statement with just one possible
> option in case of PPC64, why not integrate it right away, for
> consistency
> reasons. It seems strange to have the same Kconfig symbol both
> as a choice and a simple bool.
After some thinking I decided to keep the PPC64 variant as a separate
simple bool for now, among others, because it should be a separate
choice anyway due to the help text being different for 32 and 64-bit
anyway and I'm not fan of a one-option choice.
Ben.
^ permalink raw reply
* [PATCH] powerpc/spufs: remove unused error path
From: Stephen Rothwell @ 2009-06-03 4:00 UTC (permalink / raw)
To: Jeremy Kerr; +Cc: ppc-dev, Jan Blunck, cbe-oss-dev, Arnd Bergmann
Commit 45db9240890d9343c934db1fe82d6e68ac2d28da ("powerpc/spufs: Remove
double check for non-negative dentry") removed the only user of the
out_dput label, so remove it and the code following it.
Gets rid of this warning:
arch/powerpc/platforms/cell/spufs/inode.c: In function 'spufs_create':
arch/powerpc/platforms/cell/spufs/inode.c:647: warning: label 'out_dput' defined but not used
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
arch/powerpc/platforms/cell/spufs/inode.c | 2 --
1 files changed, 0 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/platforms/cell/spufs/inode.c b/arch/powerpc/platforms/cell/spufs/inode.c
index 36b6700..24b30b6 100644
--- a/arch/powerpc/platforms/cell/spufs/inode.c
+++ b/arch/powerpc/platforms/cell/spufs/inode.c
@@ -644,8 +644,6 @@ long spufs_create(struct nameidata *nd, unsigned int flags, mode_t mode,
fsnotify_mkdir(nd->path.dentry->d_inode, dentry);
return ret;
-out_dput:
- dput(dentry);
out_dir:
mutex_unlock(&nd->path.dentry->d_inode->i_mutex);
out:
--
1.6.3.1
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
^ permalink raw reply related
* [PATCH] powerpc: fix warning when printing a resource_size_t
From: Stephen Rothwell @ 2009-06-03 4:10 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev
resource_size_t is 64 bits on PowerPC 64.
Gets rid of this warning:
arch/powerpc/kernel/pci_64.c: In function 'pcibios_map_io_space':
arch/powerpc/kernel/pci_64.c:504: warning: format '%016lx' expects type 'long unsigned int', but argument 2 has type 'resource_size_t'
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
arch/powerpc/kernel/pci_64.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/kernel/pci_64.c b/arch/powerpc/kernel/pci_64.c
index dd6c7a3..a165fec 100644
--- a/arch/powerpc/kernel/pci_64.c
+++ b/arch/powerpc/kernel/pci_64.c
@@ -501,7 +501,7 @@ int __devinit pcibios_map_io_space(struct pci_bus *bus)
pr_debug("IO mapping for PHB %s\n", hose->dn->full_name);
pr_debug(" phys=0x%016llx, virt=0x%p (alloc=0x%p)\n",
hose->io_base_phys, hose->io_base_virt, hose->io_base_alloc);
- pr_debug(" size=0x%016lx (alloc=0x%016lx)\n",
+ pr_debug(" size=0x%016llx (alloc=0x%016lx)\n",
hose->pci_io_size, size_page);
/* Establish the mapping */
--
1.6.3.1
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
^ permalink raw reply related
* [PATCH] powerpc/xmon: remove unused variable in xmon.c
From: Stephen Rothwell @ 2009-06-03 4:15 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: ppc-dev, Vinay Sridhar
Gets rid of this warning:
arch/powerpc/xmon/xmon.c: In function 'dump_log_buf':
arch/powerpc/xmon/xmon.c:2133: warning: unused variable 'i'
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
arch/powerpc/xmon/xmon.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/xmon/xmon.c b/arch/powerpc/xmon/xmon.c
index 08121d3..e1f33a8 100644
--- a/arch/powerpc/xmon/xmon.c
+++ b/arch/powerpc/xmon/xmon.c
@@ -2130,7 +2130,7 @@ void
dump_log_buf(void)
{
const unsigned long size = 128;
- unsigned long i, end, addr;
+ unsigned long end, addr;
unsigned char buf[size + 1];
addr = 0;
--
1.6.3.1
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
^ permalink raw reply related
* [PATCH] powerpc/pseries: fix warnings when printing resource_size_t
From: Stephen Rothwell @ 2009-06-03 4:21 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: ppc-dev
resource_size_t is 64 bits on pseries
Gets rid of these warnings:
arch/powerpc/platforms/pseries/iommu.c: In function 'pci_dma_bus_setup_pSeries':
arch/powerpc/platforms/pseries/iommu.c:391: warning: format '%lx' expects type 'long unsigned int', but argument 2 has type 'resource_size_t'
arch/powerpc/platforms/pseries/iommu.c:417: warning: format '%lx' expects type 'long unsigned int', but argument 2 has type 'resource_size_t'
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
arch/powerpc/platforms/pseries/iommu.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/platforms/pseries/iommu.c b/arch/powerpc/platforms/pseries/iommu.c
index 3ee01b4..661c8e0 100644
--- a/arch/powerpc/platforms/pseries/iommu.c
+++ b/arch/powerpc/platforms/pseries/iommu.c
@@ -388,7 +388,7 @@ static void pci_dma_bus_setup_pSeries(struct pci_bus *bus)
while (pci->phb->dma_window_size * children > 0x80000000ul)
pci->phb->dma_window_size >>= 1;
- pr_debug("No ISA/IDE, window size is 0x%lx\n",
+ pr_debug("No ISA/IDE, window size is 0x%llx\n",
pci->phb->dma_window_size);
pci->phb->dma_window_base_cur = 0;
@@ -414,7 +414,7 @@ static void pci_dma_bus_setup_pSeries(struct pci_bus *bus)
while (pci->phb->dma_window_size * children > 0x70000000ul)
pci->phb->dma_window_size >>= 1;
- pr_debug("ISA/IDE, window size is 0x%lx\n", pci->phb->dma_window_size);
+ pr_debug("ISA/IDE, window size is 0x%llx\n", pci->phb->dma_window_size);
}
--
1.6.3.1
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
^ permalink raw reply related
* MPC8572 PCIe error recovery
From: Reifman, Boris @ 2009-06-03 4:15 UTC (permalink / raw)
To: linuxppc-dev
[-- Attachment #1.1: Type: text/plain, Size: 1585 bytes --]
We are using the MPC8572 running SMP Linux 2.6.23 kernel. Having
problems reliably recovering from core_fault_in which is generated by
the PCIe 2 Controller (RC) on reception of UR/CA messages. The PCIe
Controller has error detection and interrupts turned on in PEX_ERR_XX
registers. Also, AER capability is enabled via controller configuration
space. The ISR handler which performs recovery action uses the following
epilog: if the ISR is running on the same core (0 or 1) from which the
failed PCIe transaction was made, it increments NIP by 4 and exits. If
the core is different, the ISR sends an IPI message to the other core
which in its turn does all chores and then recovers the execution in a
similar way, i.e., it bumps NIP by 4 and exits. The code works well
when running on core 0; however, the moment it switches to core 1, it
always generates a kernel paging error:
[ 77.169436] Unable to handle kernel paging request for data at
address 0x00000080
[ 77.176899] Faulting instruction address: 0xc0006d94
[ 77.181850] Oops: Kernel access of bad area, sig: 11 [#1]
Anyone has any idea why Core 1 chokes on the code which Core 0 runs
flawlessly? Is there a known problem with 2.6.23 kernel? Should I be
concern with L1/L2 icache state?
Any pointers would be greatly appreciated!
Thanks in advance...
Boris Reifman | Principal Engineer P&T
breifman@ciena.com | 1185 Sanctuary Parkway, Suite 300 | Alpharetta, GA
30009 USA
Direct +1.678.867.3323 | Mobile +1.770.851.3440 | Fax +1.678.867.5101
[-- Attachment #1.2: Type: text/html, Size: 7577 bytes --]
[-- Attachment #2: Type: image/gif, Size: 3410 bytes --]
^ permalink raw reply
* [PATCH] powerpc/mm: Fix a AB->BA deadlock scenario with nohash MMU context lock
From: Benjamin Herrenschmidt @ 2009-06-03 4:53 UTC (permalink / raw)
To: linuxppc-dev
The MMU context_lock can be taken from switch_mm() while the
rq->lock is held. The rq->lock can also be taken from interrupts,
thus if we get interrupted in destroy_context() with the context
lock held and that interrupt tries to take the rq->lock, there's
a possible deadlock scenario with another CPU having the rq->lock
and calling switch_mm() which takes our context lock.
The fix is to always ensure interrupts are off when taking our
context lock. The switch_mm() path is already good so this fixes
the destroy_context() path.
While at it, turn the context lock into a new style spinlock.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
---
arch/powerpc/mm/mmu_context_nohash.c | 7 ++++---
1 file changed, 4 insertions(+), 3 deletions(-)
--- linux-work.orig/arch/powerpc/mm/mmu_context_nohash.c 2009-06-03 14:14:47.000000000 +1000
+++ linux-work/arch/powerpc/mm/mmu_context_nohash.c 2009-06-03 14:25:30.000000000 +1000
@@ -46,7 +46,7 @@ static unsigned int next_context, nr_fre
static unsigned long *context_map;
static unsigned long *stale_map[NR_CPUS];
static struct mm_struct **context_mm;
-static spinlock_t context_lock = SPIN_LOCK_UNLOCKED;
+static DEFINE_SPINLOCK(context_lock);
#define CTX_MAP_SIZE \
(sizeof(unsigned long) * (last_context / BITS_PER_LONG + 1))
@@ -272,6 +272,7 @@ int init_new_context(struct task_struct
*/
void destroy_context(struct mm_struct *mm)
{
+ unsigned long flags;
unsigned int id;
if (mm->context.id == MMU_NO_CONTEXT)
@@ -279,7 +280,7 @@ void destroy_context(struct mm_struct *m
WARN_ON(mm->context.active != 0);
- spin_lock(&context_lock);
+ spin_lock_irqsave(&context_lock, flags);
id = mm->context.id;
if (id != MMU_NO_CONTEXT) {
__clear_bit(id, context_map);
@@ -290,7 +291,7 @@ void destroy_context(struct mm_struct *m
#endif
nr_free_contexts++;
}
- spin_unlock(&context_lock);
+ spin_unlock_irqrestore(&context_lock, flags);
}
#ifdef CONFIG_SMP
^ 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