* Re: [PATCH 5/6] perf_counter: powerpc: Add processor back-end for MPC7450 family
From: Paul Mackerras @ 2009-06-17 23:24 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev, Ingo Molnar, Peter Zijlstra, linux-kernel
In-Reply-To: <34BD6A89-A05E-40CC-A495-017BFB08B796@kernel.crashing.org>
Kumar Gala writes:
> This should be something like:
>
> obj64-$(CONFIG_PPC_PERF_CTRS)-$(PPC_BOOK3S_64)
>
> > +obj32-$(CONFIG_PPC_PERF_CTRS) += mpc7450-pmu.o
>
> obj32-$(CONFIG_PPC_PERF_CTRS)-$(PPC_BOOK3S_32)
>
> Or use new Kconfig types as I suggested on patch 1/6
Feel free to send a patch making those changes along with adding the
code to support the Freescale embedded PMU. :)
Paul.
^ permalink raw reply
* Re: [PATCH 1/6] perf_counter: powerpc: Enable use of software counters on 32-bit powerpc
From: Paul Mackerras @ 2009-06-17 23:22 UTC (permalink / raw)
To: Kumar Gala; +Cc: Ingo Molnar, Peter Zijlstra, linux-kernel, linuxppc-dev
In-Reply-To: <A731338A-E954-46D9-8BF7-6E74C797209C@kernel.crashing.org>
Kumar Gala writes:
> On Jun 17, 2009, at 6:50 AM, Paul Mackerras wrote:
> > +config PPC_HAVE_PMU_SUPPORT
> > + bool
>
> what does this mean?
At the moment it means that arch/powerpc/kernel/perf_counters.c works
for at least some processors in the selected processor family.
> > +
> > +config PPC_PERF_CTRS
> > + def_bool y
> > + depends on PERF_COUNTERS && PPC_HAVE_PMU_SUPPORT
> > + help
> > + This enables the powerpc-specific perf_counter back-end.
>
> Can we distinguish between the two different architected perf counters
> programming models to start with. Maybe something like:
>
> PPC_BOOK3S_PERF_CTRS and PPC_BOOK3E_PERF_CTRS (or
> PPC_SERVER_PERF_CTRS / PPC_EMB_PERF_CTRS)
We can do that once we have code to support the Freescale embedded PMU
and we know how much of arch/powerpc/kernel/perf_counters.c is or
isn't useful there. We don't have to get to the final state in one
patch. I'd rather put this patch in as-is and then see a patch series
that adds the Freescale embedded PMU support and makes whatever
Kconfig changes are necessary later.
Paul.
^ permalink raw reply
* [PATCH 2/2] net/ucc_geth: Add SGMII support for UCC GETH driver
From: Grant Likely @ 2009-06-17 23:16 UTC (permalink / raw)
To: Stephen Rothwell, subrata, netdev
Cc: Sachin P Sant, linux-kernel, Linuxppc-dev, Linux-Next,
Nathan Lynch, Haiying Wang, Li Yang, davem, Balbir Singh
In-Reply-To: <20090617231306.7051.56146.stgit@localhost.localdomain>
From: Haiying Wang <Haiying.Wang@freescale.com>
-- derived from reverted commit 047584ce94108012288554a5f84585d792cc7f8f
-- reworked by Grant Likely to play nice with commit:
"net: Rework ucc_geth driver to use of_mdio infrastructure"
(0b9da337dca972e7a4144e298ec3adb8f244d4a4)
Signed-off-by: Haiying Wang <Haiying.Wang@freescale.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
---
arch/powerpc/include/asm/qe.h | 2 +
drivers/net/ucc_geth.c | 58 ++++++++++++++++++++++++++++++++++++++++-
drivers/net/ucc_geth.h | 28 +++++++++++++++++++-
3 files changed, 86 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/include/asm/qe.h b/arch/powerpc/include/asm/qe.h
index e0faf33..157c5ca 100644
--- a/arch/powerpc/include/asm/qe.h
+++ b/arch/powerpc/include/asm/qe.h
@@ -675,6 +675,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 5118993..40c6eba 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>
@@ -1410,6 +1410,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
@@ -1531,6 +1534,49 @@ static void adjust_link(struct net_device *dev)
spin_unlock_irqrestore(&ugeth->lock, flags);
}
+/* 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);
+ struct ucc_geth_info *ug_info = ugeth->ug_info;
+ struct phy_device *tbiphy;
+
+ if (!ug_info->tbi_node) {
+ dev_warn(&dev->dev, "SGMII mode requires that the device "
+ "tree specify a tbi-handle\n");
+ return;
+ }
+
+ tbiphy = of_phy_find_device(ug_info->tbi_node);
+ if (!tbiphy) {
+ dev_err(&dev->dev, "error: Could not get TBI device\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(tbiphy, ENET_TBI_MII_SR) & TBISR_LSTATUS)
+ return;
+
+ /* Single clk mode, mii mode off(for serdes communication) */
+ phy_write(tbiphy, ENET_TBI_MII_ANA, TBIANA_SETTINGS);
+
+ phy_write(tbiphy, ENET_TBI_MII_TBICON, TBICON_CLK_SELECT);
+
+ phy_write(tbiphy, ENET_TBI_MII_CR, TBICR_SETTINGS);
+}
+
/* Configure the PHY for dev.
* returns 0 if success. -1 if failure
*/
@@ -1554,6 +1600,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 |
@@ -3531,6 +3580,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;
}
@@ -3575,6 +3626,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__);
@@ -3666,6 +3718,9 @@ static int ucc_geth_probe(struct of_device* ofdev, const struct of_device_id *ma
}
ug_info->phy_node = phy;
+ /* Find the TBI PHY node. If it's not there, we don't support SGMII */
+ ug_info->tbi_node = of_parse_phandle(np, "tbi-handle", 0);
+
/* get the phy interface type, or default to MII */
prop = of_get_property(np, "phy-connection-type", NULL);
if (!prop) {
@@ -3690,6 +3745,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:
diff --git a/drivers/net/ucc_geth.h b/drivers/net/ucc_geth.h
index 8160276..195ab26 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 */
@@ -1100,6 +1125,7 @@ struct ucc_geth_info {
u16 pausePeriod;
u16 extensionField;
struct device_node *phy_node;
+ struct device_node *tbi_node;
u8 weightfactor[NUM_TX_QUEUES];
u8 interruptcoalescingmaxvalue[NUM_RX_QUEUES];
u8 l2qt[UCC_GETH_VLAN_PRIORITY_MAX];
^ permalink raw reply related
* [PATCH 1/2] Revert "net/ucc_geth: Add SGMII support for UEC GETH driver"
From: Grant Likely @ 2009-06-17 23:16 UTC (permalink / raw)
To: Stephen Rothwell, subrata, netdev
Cc: Sachin P Sant, linux-kernel, Linuxppc-dev, Linux-Next,
Nathan Lynch, Haiying Wang, Li Yang, davem, Balbir Singh
In-Reply-To: <20090617231306.7051.56146.stgit@localhost.localdomain>
From: Grant Likely <grant.likely@secretlab.ca>
This reverts commit 047584ce94108012288554a5f84585d792cc7f8f.
This patch meshes badly with "net: Rework ucc_geth driver to use
of_mdio infrastructure" (0b9da337dca972e7a4144e298ec3adb8f244d4a4).
Since most of the patch needs to be reworked, it is clearer to revert
the patch and then apply the corrected version
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
---
arch/powerpc/include/asm/qe.h | 2 -
drivers/net/ucc_geth.c | 79 +----------------------------------------
drivers/net/ucc_geth.h | 28 +--------------
3 files changed, 2 insertions(+), 107 deletions(-)
diff --git a/arch/powerpc/include/asm/qe.h b/arch/powerpc/include/asm/qe.h
index 157c5ca..e0faf33 100644
--- a/arch/powerpc/include/asm/qe.h
+++ b/arch/powerpc/include/asm/qe.h
@@ -675,8 +675,6 @@ 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 e2f2e91..5118993 100644
--- a/drivers/net/ucc_geth.c
+++ b/drivers/net/ucc_geth.c
@@ -1,5 +1,5 @@
/*
- * Copyright (C) 2006-2009 Freescale Semicondutor, Inc. All rights reserved.
+ * Copyright (C) 2006-2007 Freescale Semicondutor, Inc. All rights reserved.
*
* Author: Shlomi Gridish <gridish@freescale.com>
* Li Yang <leoli@freescale.com>
@@ -65,8 +65,6 @@
static DEFINE_SPINLOCK(ugeth_lock);
-static void uec_configure_serdes(struct net_device *dev);
-
static struct {
u32 msg_enable;
} debug = { -1 };
@@ -1412,9 +1410,6 @@ 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
@@ -1559,9 +1554,6 @@ 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 |
@@ -1577,41 +1569,7 @@ 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)
{
@@ -3573,8 +3531,6 @@ 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;
}
@@ -3619,7 +3575,6 @@ 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__);
@@ -3735,7 +3690,6 @@ 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:
@@ -3818,37 +3772,6 @@ 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 5beba4c..8160276 100644
--- a/drivers/net/ucc_geth.h
+++ b/drivers/net/ucc_geth.h
@@ -1,5 +1,5 @@
/*
- * Copyright (C) Freescale Semicondutor, Inc. 2006-2009. All rights reserved.
+ * Copyright (C) Freescale Semicondutor, Inc. 2006. All rights reserved.
*
* Author: Shlomi Gridish <gridish@freescale.com>
*
@@ -193,31 +193,6 @@ 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 */
@@ -1213,7 +1188,6 @@ 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;
^ permalink raw reply related
* [PATCH 0/2] Revert and reimplement Add SGMII support to UCC GETH
From: Grant Likely @ 2009-06-17 23:15 UTC (permalink / raw)
To: Stephen Rothwell, subrata, netdev
Cc: Sachin P Sant, linux-kernel, Linuxppc-dev, Linux-Next,
Nathan Lynch, Haiying Wang, Li Yang, davem, Balbir Singh
(REPOST; I messed up an email address first time around and apparently my
posting got rejected. If you've already received this message, then
I apologize for the noise)
Here is a fix for the build failure discovered during the 2.6.31 merge
window on ucc_geth.c. I decided to revert and reapply a fixed version
of the patch to make the new version easier to review and bisect if I
got the fixup wrong. I've compile tested both patches, but I do not have
hardware to run test.
Haiying, please confirm that I haven't horribly trashed your hard work
with my changes.
For anyone interested, I've also pushed these patches out to the -next-net
branch of my git tree:
The following changes since commit 65795efbd380a832ae508b04dba8f8e53f0b84d9:
Linus Torvalds (1):
Merge branch 'next-i2c' of git://aeryn.fluff.org.uk/bjdooks/linux
are available in the git repository at:
git://git.secretlab.ca/git/linux-2.6 next-net
Grant Likely (1):
Revert "net/ucc_geth: Add SGMII support for UEC GETH driver"
Haiying Wang (1):
net/ucc_geth: Add SGMII support for UCC GETH driver
drivers/net/ucc_geth.c | 113 +++++++++++++++++++----------------------------
drivers/net/ucc_geth.h | 2 +-
2 files changed, 47 insertions(+), 68 deletions(-)
--
Grant Likely, B.Sc. P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* [PATCH 2/2] net/ucc_geth: Add SGMII support for UCC GETH driver
From: Grant Likely @ 2009-06-17 21:09 UTC (permalink / raw)
To: Stephen Rothwell, subrata, netdev
Cc: Sachin P Sant, linux-kernel, Linuxppc-dev, Linux-Next,
Nathan Lynch, Haiying Wang, Li Yang, David S. Miller,
Balbir Singh
In-Reply-To: <20090617210356.18435.96410.stgit@localhost.localdomain>
From: Haiying Wang <Haiying.Wang@freescale.com>
-- derived from reverted commit 047584ce94108012288554a5f84585d792cc7f8f
-- reworked by Grant Likely to play nice with commit:
"net: Rework ucc_geth driver to use of_mdio infrastructure"
(0b9da337dca972e7a4144e298ec3adb8f244d4a4)
Signed-off-by: Haiying Wang <Haiying.Wang@freescale.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
---
arch/powerpc/include/asm/qe.h | 2 +
drivers/net/ucc_geth.c | 58 ++++++++++++++++++++++++++++++++++++++++-
drivers/net/ucc_geth.h | 28 +++++++++++++++++++-
3 files changed, 86 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/include/asm/qe.h b/arch/powerpc/include/asm/qe.h
index e0faf33..157c5ca 100644
--- a/arch/powerpc/include/asm/qe.h
+++ b/arch/powerpc/include/asm/qe.h
@@ -675,6 +675,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 5118993..40c6eba 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>
@@ -1410,6 +1410,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
@@ -1531,6 +1534,49 @@ static void adjust_link(struct net_device *dev)
spin_unlock_irqrestore(&ugeth->lock, flags);
}
+/* 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);
+ struct ucc_geth_info *ug_info = ugeth->ug_info;
+ struct phy_device *tbiphy;
+
+ if (!ug_info->tbi_node) {
+ dev_warn(&dev->dev, "SGMII mode requires that the device "
+ "tree specify a tbi-handle\n");
+ return;
+ }
+
+ tbiphy = of_phy_find_device(ug_info->tbi_node);
+ if (!tbiphy) {
+ dev_err(&dev->dev, "error: Could not get TBI device\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(tbiphy, ENET_TBI_MII_SR) & TBISR_LSTATUS)
+ return;
+
+ /* Single clk mode, mii mode off(for serdes communication) */
+ phy_write(tbiphy, ENET_TBI_MII_ANA, TBIANA_SETTINGS);
+
+ phy_write(tbiphy, ENET_TBI_MII_TBICON, TBICON_CLK_SELECT);
+
+ phy_write(tbiphy, ENET_TBI_MII_CR, TBICR_SETTINGS);
+}
+
/* Configure the PHY for dev.
* returns 0 if success. -1 if failure
*/
@@ -1554,6 +1600,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 |
@@ -3531,6 +3580,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;
}
@@ -3575,6 +3626,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__);
@@ -3666,6 +3718,9 @@ static int ucc_geth_probe(struct of_device* ofdev, const struct of_device_id *ma
}
ug_info->phy_node = phy;
+ /* Find the TBI PHY node. If it's not there, we don't support SGMII */
+ ug_info->tbi_node = of_parse_phandle(np, "tbi-handle", 0);
+
/* get the phy interface type, or default to MII */
prop = of_get_property(np, "phy-connection-type", NULL);
if (!prop) {
@@ -3690,6 +3745,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:
diff --git a/drivers/net/ucc_geth.h b/drivers/net/ucc_geth.h
index 8160276..195ab26 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 */
@@ -1100,6 +1125,7 @@ struct ucc_geth_info {
u16 pausePeriod;
u16 extensionField;
struct device_node *phy_node;
+ struct device_node *tbi_node;
u8 weightfactor[NUM_TX_QUEUES];
u8 interruptcoalescingmaxvalue[NUM_RX_QUEUES];
u8 l2qt[UCC_GETH_VLAN_PRIORITY_MAX];
^ permalink raw reply related
* [PATCH 1/2] Revert "net/ucc_geth: Add SGMII support for UEC GETH driver"
From: Grant Likely @ 2009-06-17 21:09 UTC (permalink / raw)
To: Stephen Rothwell, subrata, netdev
Cc: Sachin P Sant, linux-kernel, Linuxppc-dev, Linux-Next,
Nathan Lynch, Haiying Wang, Li Yang, David S. Miller,
Balbir Singh
In-Reply-To: <20090617210356.18435.96410.stgit@localhost.localdomain>
From: Grant Likely <grant.likely@secretlab.ca>
This reverts commit 047584ce94108012288554a5f84585d792cc7f8f.
This patch meshes badly with "net: Rework ucc_geth driver to use
of_mdio infrastructure" (0b9da337dca972e7a4144e298ec3adb8f244d4a4).
Since most of the patch needs to be reworked, it is clearer to revert
the patch and then apply the corrected version
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
---
arch/powerpc/include/asm/qe.h | 2 -
drivers/net/ucc_geth.c | 79 +----------------------------------------
drivers/net/ucc_geth.h | 28 +--------------
3 files changed, 2 insertions(+), 107 deletions(-)
diff --git a/arch/powerpc/include/asm/qe.h b/arch/powerpc/include/asm/qe.h
index 157c5ca..e0faf33 100644
--- a/arch/powerpc/include/asm/qe.h
+++ b/arch/powerpc/include/asm/qe.h
@@ -675,8 +675,6 @@ 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 e2f2e91..5118993 100644
--- a/drivers/net/ucc_geth.c
+++ b/drivers/net/ucc_geth.c
@@ -1,5 +1,5 @@
/*
- * Copyright (C) 2006-2009 Freescale Semicondutor, Inc. All rights reserved.
+ * Copyright (C) 2006-2007 Freescale Semicondutor, Inc. All rights reserved.
*
* Author: Shlomi Gridish <gridish@freescale.com>
* Li Yang <leoli@freescale.com>
@@ -65,8 +65,6 @@
static DEFINE_SPINLOCK(ugeth_lock);
-static void uec_configure_serdes(struct net_device *dev);
-
static struct {
u32 msg_enable;
} debug = { -1 };
@@ -1412,9 +1410,6 @@ 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
@@ -1559,9 +1554,6 @@ 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 |
@@ -1577,41 +1569,7 @@ 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)
{
@@ -3573,8 +3531,6 @@ 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;
}
@@ -3619,7 +3575,6 @@ 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__);
@@ -3735,7 +3690,6 @@ 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:
@@ -3818,37 +3772,6 @@ 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 5beba4c..8160276 100644
--- a/drivers/net/ucc_geth.h
+++ b/drivers/net/ucc_geth.h
@@ -1,5 +1,5 @@
/*
- * Copyright (C) Freescale Semicondutor, Inc. 2006-2009. All rights reserved.
+ * Copyright (C) Freescale Semicondutor, Inc. 2006. All rights reserved.
*
* Author: Shlomi Gridish <gridish@freescale.com>
*
@@ -193,31 +193,6 @@ 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 */
@@ -1213,7 +1188,6 @@ 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;
^ permalink raw reply related
* [PATCH 0/2] Revert and reimplement Add SGMII support to UCC GETH
From: Grant Likely @ 2009-06-17 21:09 UTC (permalink / raw)
To: Stephen Rothwell, subrata, netdev
Cc: Sachin P Sant, linux-kernel, Linuxppc-dev, Linux-Next,
Nathan Lynch, Haiying Wang, Li Yang, David S. Miller,
Balbir Singh
Here is a fix for the build failure discovered during the 2.6.31 merge
window on ucc_geth.c. I decided to revert and reapply a fixed version
of the patch to make the new version easier to review and bisect if I
got the fixup wrong. I've compile tested both patches, but I do not have
hardware to run test.
Haiying, please confirm that I haven't horribly trashed your hard work
with my changes.
For anyone interested, I've also pushed these patches out to the -next-net
branch of my git tree:
The following changes since commit 65795efbd380a832ae508b04dba8f8e53f0b84d9:
Linus Torvalds (1):
Merge branch 'next-i2c' of git://aeryn.fluff.org.uk/bjdooks/linux
are available in the git repository at:
git://git.secretlab.ca/git/linux-2.6 next-net
Grant Likely (1):
Revert "net/ucc_geth: Add SGMII support for UEC GETH driver"
Haiying Wang (1):
net/ucc_geth: Add SGMII support for UCC GETH driver
drivers/net/ucc_geth.c | 113 +++++++++++++++++++----------------------------
drivers/net/ucc_geth.h | 2 +-
2 files changed, 47 insertions(+), 68 deletions(-)
--
Grant Likely, B.Sc. P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* [PATCH 1/2] Revert "net/ucc_geth: Add SGMII support for UEC GETH driver"
From: Grant Likely @ 2009-06-17 21:02 UTC (permalink / raw)
To: Stephen Rothwell, subrata, netdev
Cc: Sachin P Sant, linux-kernel, Linuxppc-dev, Linux-Next,
Nathan Lynch, Haiying Wang, Li Yang, David S. Miller,
Balbir Singh
From: Grant Likely <grant.likely@secretlab.ca>
This reverts commit 047584ce94108012288554a5f84585d792cc7f8f.
This patch meshes badly with "net: Rework ucc_geth driver to use
of_mdio infrastructure" (0b9da337dca972e7a4144e298ec3adb8f244d4a4).
Since most of the patch needs to be reworked, it is clearer to revert
the patch and then apply the corrected version
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
---
arch/powerpc/include/asm/qe.h | 2 -
drivers/net/ucc_geth.c | 79 +----------------------------------------
drivers/net/ucc_geth.h | 28 +--------------
3 files changed, 2 insertions(+), 107 deletions(-)
diff --git a/arch/powerpc/include/asm/qe.h b/arch/powerpc/include/asm/qe.h
index 157c5ca..e0faf33 100644
--- a/arch/powerpc/include/asm/qe.h
+++ b/arch/powerpc/include/asm/qe.h
@@ -675,8 +675,6 @@ 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 e2f2e91..5118993 100644
--- a/drivers/net/ucc_geth.c
+++ b/drivers/net/ucc_geth.c
@@ -1,5 +1,5 @@
/*
- * Copyright (C) 2006-2009 Freescale Semicondutor, Inc. All rights reserved.
+ * Copyright (C) 2006-2007 Freescale Semicondutor, Inc. All rights reserved.
*
* Author: Shlomi Gridish <gridish@freescale.com>
* Li Yang <leoli@freescale.com>
@@ -65,8 +65,6 @@
static DEFINE_SPINLOCK(ugeth_lock);
-static void uec_configure_serdes(struct net_device *dev);
-
static struct {
u32 msg_enable;
} debug = { -1 };
@@ -1412,9 +1410,6 @@ 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
@@ -1559,9 +1554,6 @@ 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 |
@@ -1577,41 +1569,7 @@ 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)
{
@@ -3573,8 +3531,6 @@ 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;
}
@@ -3619,7 +3575,6 @@ 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__);
@@ -3735,7 +3690,6 @@ 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:
@@ -3818,37 +3772,6 @@ 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 5beba4c..8160276 100644
--- a/drivers/net/ucc_geth.h
+++ b/drivers/net/ucc_geth.h
@@ -1,5 +1,5 @@
/*
- * Copyright (C) Freescale Semicondutor, Inc. 2006-2009. All rights reserved.
+ * Copyright (C) Freescale Semicondutor, Inc. 2006. All rights reserved.
*
* Author: Shlomi Gridish <gridish@freescale.com>
*
@@ -193,31 +193,6 @@ 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 */
@@ -1213,7 +1188,6 @@ 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;
^ permalink raw reply related
* Re: [PATCH v2] sdhci: Add support for hosts that are only capable of 1-bit transfers
From: Grant Likely @ 2009-06-17 20:55 UTC (permalink / raw)
To: Anton Vorontsov
Cc: linuxppc-dev, Pierre Ossman, devicetree-discuss, sdhci-devel
In-Reply-To: <20090617201408.GA17909@oksana.dev.rtsoft.ru>
On Wed, Jun 17, 2009 at 2:14 PM, Anton
Vorontsov<avorontsov@ru.mvista.com> wrote:
> Some hosts (hardware configurations, or particular SD/MMC slots) may
> not support 4-bit bus. For example, on MPC8569E-MDS boards we can
> switch between serial (1-bit only) and nibble (4-bit) modes, thought
> we have to disable more peripherals to work in 4-bit mode.
>
> Along with some small core changes, this patch modifies sdhci-of
> driver, so that now it looks for "sdhci,1-bit-only" property in the
> device-tree, and if specified we enable a proper quirk.
>
> Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
Looks good to me.
Acked-by: Grant Likely <grant.likely@secretlab.ca>
g.
> ---
>
> Pierre,
>
> As promised, here is a version with a quirk.
> Also incorporated suggestions by Grant Likely.
>
>
> Thanks,
>
> =A0Documentation/powerpc/dts-bindings/fsl/esdhc.txt | =A0 =A02 ++
> =A0drivers/mmc/host/sdhci-of.c =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0| =A0 =A03 +++
> =A0drivers/mmc/host/sdhci.c =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 | =A0 =A05 ++++-
> =A0drivers/mmc/host/sdhci.h =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 | =A0 =A02 ++
> =A04 files changed, 11 insertions(+), 1 deletions(-)
>
> diff --git a/Documentation/powerpc/dts-bindings/fsl/esdhc.txt b/Documenta=
tion/powerpc/dts-bindings/fsl/esdhc.txt
> index 5093ddf..3ed3797 100644
> --- a/Documentation/powerpc/dts-bindings/fsl/esdhc.txt
> +++ b/Documentation/powerpc/dts-bindings/fsl/esdhc.txt
> @@ -10,6 +10,8 @@ Required properties:
> =A0 - interrupts : should contain eSDHC interrupt.
> =A0 - interrupt-parent : interrupt source phandle.
> =A0 - clock-frequency : specifies eSDHC base clock frequency.
> + =A0- sdhci,1-bit-only : (optional) specifies that a controller can
> + =A0 =A0only handle 1-bit data transfers.
>
> =A0Example:
>
> diff --git a/drivers/mmc/host/sdhci-of.c b/drivers/mmc/host/sdhci-of.c
> index 09cc597..dd65f84 100644
> --- a/drivers/mmc/host/sdhci-of.c
> +++ b/drivers/mmc/host/sdhci-of.c
> @@ -244,6 +244,9 @@ static int __devinit sdhci_of_probe(struct of_device =
*ofdev,
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0host->ops =3D &sdhci_of_data->ops;
> =A0 =A0 =A0 =A0}
>
> + =A0 =A0 =A0 if (of_get_property(np, "sdhci,1-bit-only", NULL))
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 host->quirks |=3D SDHCI_QUIRK_FORCE_1_BIT_D=
ATA;
> +
> =A0 =A0 =A0 =A0clk =3D of_get_property(np, "clock-frequency", &size);
> =A0 =A0 =A0 =A0if (clk && size =3D=3D sizeof(*clk) && *clk)
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0of_host->clock =3D *clk;
> diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
> index 9234be2..f28f94a 100644
> --- a/drivers/mmc/host/sdhci.c
> +++ b/drivers/mmc/host/sdhci.c
> @@ -1721,7 +1721,10 @@ int sdhci_add_host(struct sdhci_host *host)
> =A0 =A0 =A0 =A0mmc->ops =3D &sdhci_ops;
> =A0 =A0 =A0 =A0mmc->f_min =3D host->max_clk / 256;
> =A0 =A0 =A0 =A0mmc->f_max =3D host->max_clk;
> - =A0 =A0 =A0 mmc->caps =3D MMC_CAP_4_BIT_DATA | MMC_CAP_SDIO_IRQ;
> + =A0 =A0 =A0 mmc->caps =3D MMC_CAP_SDIO_IRQ;
> +
> + =A0 =A0 =A0 if (!(host->quirks & SDHCI_QUIRK_FORCE_1_BIT_DATA))
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 mmc->caps |=3D MMC_CAP_4_BIT_DATA;
>
> =A0 =A0 =A0 =A0if (caps & SDHCI_CAN_DO_HISPD)
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0mmc->caps |=3D MMC_CAP_SD_HIGHSPEED;
> diff --git a/drivers/mmc/host/sdhci.h b/drivers/mmc/host/sdhci.h
> index 65c6f99..834f877 100644
> --- a/drivers/mmc/host/sdhci.h
> +++ b/drivers/mmc/host/sdhci.h
> @@ -226,6 +226,8 @@ struct sdhci_host {
> =A0#define SDHCI_QUIRK_RESTORE_IRQS_AFTER_RESET =A0 =A0 =A0 =A0 =A0 (1<<1=
9)
> =A0/* Controller has to be forced to use block size of 2048 bytes */
> =A0#define SDHCI_QUIRK_FORCE_BLK_SZ_2048 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0(1<<20)
> +/* Controller can only handle 1-bit data transfers */
> +#define SDHCI_QUIRK_FORCE_1_BIT_DATA =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
(1<<21)
>
> =A0 =A0 =A0 =A0int =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 irq; =A0 =A0 =
=A0 =A0 =A0 =A0/* Device IRQ */
> =A0 =A0 =A0 =A0void __iomem * =A0 =A0 =A0 =A0 =A0ioaddr; =A0 =A0 =A0 =A0 =
/* Mapped address */
> --
> 1.6.3.1
>
--=20
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: [PATCH][Resend 2][BUILD FAILURE 04/04] Next June 04:PPC64 randconfig [drivers/net/ucc_geth.o]
From: Grant Likely @ 2009-06-17 20:37 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Sachin P Sant, netdev, Linux-Kernel, Linuxppc-dev, Linux-Next,
Nathan Lynch, Haiying Wang, Li Yang, subrata, David S. Miller,
Balbir Singh
In-Reply-To: <fa686aa40906171029p4d5b876fm16d0f144b1a19346@mail.gmail.com>
On Wed, Jun 17, 2009 at 11:29 AM, Grant Likely<grant.likely@secretlab.ca> w=
rote:
> On Wed, Jun 17, 2009 at 7:34 AM, Stephen Rothwell<sfr@canb.auug.org.au> w=
rote:
>> On Wed, 17 Jun 2009 23:23:41 +1000 Stephen Rothwell <sfr@canb.auug.org.a=
u> wrote:
>>>
>>> Hi Kumar,
>>>
>>> On Wed, 17 Jun 2009 08:07:47 -0500 Kumar Gala <galak@kernel.crashing.or=
g> wrote:
>>> >
>>> >
>>> > I'm confused by the proposed fix as we already have *mdio & *ph
>>> > defined in this function:
>>>
>>> Which tree are you looking at? =A0Linus' tree, and linux-next, do not h=
ave
>>> those local variables ...
>>
>> Hmmm, commit 0b9da337dca972e7a4144e298ec3adb8f244d4a4 ("net: Rework
>> ucc_geth driver to use of_mdio infrastructure") removed the locals along
>> with their usages, then commit 047584ce94108012288554a5f84585d792cc7f8f
>> ("net/ucc_geth: Add SGMII support for UEC GETH driver") added more uses
>> without adding the variables back.
>>
>> Here is the patch again:
>>
>> From: Subrata Modak <subrata@linux.vnet.ibm.com>
>> Subject: [PATCH] Fix build error in ucc_geth.c
>>
>> 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 f=
unction)
>> drivers/net/ucc_geth.c:3822: error: (Each undeclared identifier is repor=
ted 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 =A0 =A0 =A0 =A02009-06-=
10 11:58:39.000000000 -0500
>> +++ linux-2.6.30-rc8/drivers/net/ucc_geth.c =A0 =A0 2009-06-10 22:28:13.=
000000000 -0500
>> @@ -3595,6 +3595,8 @@ static const struct net_device_ops ucc_g
>>
>> =A0static int ucc_geth_probe(struct of_device* ofdev, const struct of_de=
vice_id *match)
>> =A0{
>> + =A0 =A0 =A0 struct device_node *mdio;
>> + =A0 =A0 =A0 const phandle *ph;
>> =A0 =A0 =A0 =A0struct device *device =3D &ofdev->dev;
>> =A0 =A0 =A0 =A0struct device_node *np =3D ofdev->node;
>> =A0 =A0 =A0 =A0struct net_device *dev =3D NULL;
>
> Ah, this might not be the right fix then. =A0I'll look.
Yeah, this is not the right fix. The SGMII change doesn't mesh well
with the of_mdio changes and needed some rewriting. I'm about to post
a patch (compile tested only) which should make things happy.
--=20
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* [PATCH v2] sdhci: Add support for hosts that are only capable of 1-bit transfers
From: Anton Vorontsov @ 2009-06-17 20:14 UTC (permalink / raw)
To: Pierre Ossman; +Cc: linuxppc-dev, devicetree-discuss, sdhci-devel
In-Reply-To: <20090611201545.GA15942@oksana.dev.rtsoft.ru>
Some hosts (hardware configurations, or particular SD/MMC slots) may
not support 4-bit bus. For example, on MPC8569E-MDS boards we can
switch between serial (1-bit only) and nibble (4-bit) modes, thought
we have to disable more peripherals to work in 4-bit mode.
Along with some small core changes, this patch modifies sdhci-of
driver, so that now it looks for "sdhci,1-bit-only" property in the
device-tree, and if specified we enable a proper quirk.
Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
---
Pierre,
As promised, here is a version with a quirk.
Also incorporated suggestions by Grant Likely.
Thanks,
Documentation/powerpc/dts-bindings/fsl/esdhc.txt | 2 ++
drivers/mmc/host/sdhci-of.c | 3 +++
drivers/mmc/host/sdhci.c | 5 ++++-
drivers/mmc/host/sdhci.h | 2 ++
4 files changed, 11 insertions(+), 1 deletions(-)
diff --git a/Documentation/powerpc/dts-bindings/fsl/esdhc.txt b/Documentation/powerpc/dts-bindings/fsl/esdhc.txt
index 5093ddf..3ed3797 100644
--- a/Documentation/powerpc/dts-bindings/fsl/esdhc.txt
+++ b/Documentation/powerpc/dts-bindings/fsl/esdhc.txt
@@ -10,6 +10,8 @@ Required properties:
- interrupts : should contain eSDHC interrupt.
- interrupt-parent : interrupt source phandle.
- clock-frequency : specifies eSDHC base clock frequency.
+ - sdhci,1-bit-only : (optional) specifies that a controller can
+ only handle 1-bit data transfers.
Example:
diff --git a/drivers/mmc/host/sdhci-of.c b/drivers/mmc/host/sdhci-of.c
index 09cc597..dd65f84 100644
--- a/drivers/mmc/host/sdhci-of.c
+++ b/drivers/mmc/host/sdhci-of.c
@@ -244,6 +244,9 @@ static int __devinit sdhci_of_probe(struct of_device *ofdev,
host->ops = &sdhci_of_data->ops;
}
+ if (of_get_property(np, "sdhci,1-bit-only", NULL))
+ host->quirks |= SDHCI_QUIRK_FORCE_1_BIT_DATA;
+
clk = of_get_property(np, "clock-frequency", &size);
if (clk && size == sizeof(*clk) && *clk)
of_host->clock = *clk;
diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
index 9234be2..f28f94a 100644
--- a/drivers/mmc/host/sdhci.c
+++ b/drivers/mmc/host/sdhci.c
@@ -1721,7 +1721,10 @@ int sdhci_add_host(struct sdhci_host *host)
mmc->ops = &sdhci_ops;
mmc->f_min = host->max_clk / 256;
mmc->f_max = host->max_clk;
- mmc->caps = MMC_CAP_4_BIT_DATA | MMC_CAP_SDIO_IRQ;
+ mmc->caps = MMC_CAP_SDIO_IRQ;
+
+ if (!(host->quirks & SDHCI_QUIRK_FORCE_1_BIT_DATA))
+ mmc->caps |= MMC_CAP_4_BIT_DATA;
if (caps & SDHCI_CAN_DO_HISPD)
mmc->caps |= MMC_CAP_SD_HIGHSPEED;
diff --git a/drivers/mmc/host/sdhci.h b/drivers/mmc/host/sdhci.h
index 65c6f99..834f877 100644
--- a/drivers/mmc/host/sdhci.h
+++ b/drivers/mmc/host/sdhci.h
@@ -226,6 +226,8 @@ struct sdhci_host {
#define SDHCI_QUIRK_RESTORE_IRQS_AFTER_RESET (1<<19)
/* Controller has to be forced to use block size of 2048 bytes */
#define SDHCI_QUIRK_FORCE_BLK_SZ_2048 (1<<20)
+/* Controller can only handle 1-bit data transfers */
+#define SDHCI_QUIRK_FORCE_1_BIT_DATA (1<<21)
int irq; /* Device IRQ */
void __iomem * ioaddr; /* Mapped address */
--
1.6.3.1
^ permalink raw reply related
* Re: [PATCH] sdhci: Add support for hosts that are only capable of 1-bit transfers
From: Anton Vorontsov @ 2009-06-17 20:13 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev, Pierre Ossman, devicetree-discuss, sdhci-devel
In-Reply-To: <fa686aa40906130840lfb751a7xc9e24646c860a76d@mail.gmail.com>
On Sat, Jun 13, 2009 at 09:40:02AM -0600, Grant Likely wrote:
> On Thu, Jun 11, 2009 at 2:15 PM, Anton
> Vorontsov<avorontsov@ru.mvista.com> wrote:
> > Some hosts (hardware configurations, or particular SD/MMC slots) may
> > not support 4-bit bus. For example, on MPC8569E-MDS boards we can
> > switch between serial (1-bit only) and nibble (4-bit) modes, thought
> > we have to disable more peripherals to work in 4-bit mode.
> >
> > Along with some small core changes, this patch modifies sdhci-of
> > driver, so that now it looks for "mode" property in the device-tree.
> >
> > Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
> > ---
> >
> > Pierre, I'm not sure if a quirk would be appropriate here. If so,
> > I can redo the patch with FORCE_1_BIT_DATA quirk.
> >
> > Thanks,
> >
> > Documentation/powerpc/dts-bindings/fsl/esdhc.txt | 2 ++
> > drivers/mmc/host/sdhci-of.c | 7 +++++++
> > drivers/mmc/host/sdhci-pci.c | 1 +
> > drivers/mmc/host/sdhci.c | 2 +-
> > 4 files changed, 11 insertions(+), 1 deletions(-)
> >
> > diff --git a/Documentation/powerpc/dts-bindings/fsl/esdhc.txt b/Documentation/powerpc/dts-bindings/fsl/esdhc.txt
> > index 5093ddf..298b865 100644
> > --- a/Documentation/powerpc/dts-bindings/fsl/esdhc.txt
> > +++ b/Documentation/powerpc/dts-bindings/fsl/esdhc.txt
> > @@ -10,6 +10,8 @@ Required properties:
> > - interrupts : should contain eSDHC interrupt.
> > - interrupt-parent : interrupt source phandle.
> > - clock-frequency : specifies eSDHC base clock frequency.
> > + - mode : specifies eSDHC mode, valid values are: "1-bit" and "4-bit".
> > + If mode is unspecified, then 4-bit mode is assumed.
>
> In light of Pierre's comment that 4-bit is mandatory and this is a
> deviation, perhaps it would be better to define an empty property to
> indicate that only 1-bit transfers work. Maybe something along the
> lines of "sdhc-1-bit-only"?
Yeah, since it turned up to be a quirk, we'd better use a named
property.
(I think that by convention we should use commas for
controller-specific properties, i.e. "sdhci,property".)
Thanks!
--
Anton Vorontsov
email: cbouatmailru@gmail.com
irc://irc.freenode.net/bd2
^ permalink raw reply
* Re: [BUILD FAILURE 02/04] Next June 04:PPC64 randconfig [drivers/usb/host/ohci-hcd.o]
From: Grant Likely @ 2009-06-17 20:06 UTC (permalink / raw)
To: subrata
Cc: Sachin P Sant, Randy Dunlap, Arnd Bergmann, Stephen Rothwell,
linux-usb, Linux-Kernel, David Brownell, Linuxppc-dev, Linux-Next,
kernel
In-Reply-To: <fa686aa40906171115m3e3faab2r63814ea8013056d0@mail.gmail.com>
On Wed, Jun 17, 2009 at 12:15 PM, Grant Likely<grant.likely@secretlab.ca> w=
rote:
> On Wed, Jun 17, 2009 at 6:53 AM, Subrata
> Modak<subrata@linux.vnet.ibm.com> wrote:
>> On Mon, 2009-06-15 at 12:21 +0530, Subrata Modak wrote:
>>> On Fri, 2009-06-12 at 15:05 +0530, Subrata Modak wrote:
>>> > On Tue, 2009-06-09 at 17:38 -0700, David Brownell wrote:
>>> > > On Friday 05 June 2009, Subrata Modak wrote:
>>> > > > Correct, it fixes the issue. However, since few changes might hav=
e gone
>>> > > > to the Kconfig, the patch does not apply cleanly. Below is the pa=
tch, just
>>> > > > a retake of the earlier one, but on the latest code.
>>> > >
>>> > > And it got mangled a bit along the way. =A0Plus, the original one
>>> > > goofed up Kconfig dependency displays ... both issues fixed in
>>> > > this version, against current mainline GIT.
>>> > >
>>> > > If someone can verify all four PPC/OF/OHCI configs build on
>>> > > on PPC64, I'm OK with it.
>>> > >
>>> > > - Dave
>>> >
>>> > Dave,
>>> >
>>> > Sorry for being late. The patch fixes the issue on the latest git for
>>> > PPC64. Infact, the whole drivers/usb/host/ builds just fine:
>>> >
>>> > linux-2.6 # make drivers/usb/host/
>>> > =A0 CHK =A0 =A0 include/linux/version.h
>>> > =A0 CHK =A0 =A0 include/linux/utsrelease.h
>>> > =A0 SYMLINK include/asm -> include/asm-powerpc
>>> > =A0 CALL =A0 =A0scripts/checksyscalls.sh
>>> > =A0 CC =A0 =A0 =A0drivers/usb/host/ohci-hcd.o
>>> > =A0 CC =A0 =A0 =A0drivers/usb/host/pci-quirks.o
>>> > =A0 CC =A0 =A0 =A0drivers/usb/host/uhci-hcd.o
>>> > =A0 LD =A0 =A0 =A0drivers/usb/host/built-in.o
>>> > =A0 CC [M] =A0drivers/usb/host/isp116x-hcd.o
>>> > =A0 CC [M] =A0drivers/usb/host/u132-hcd.o
>>> >
>>> > You can check in the patch now.
>>>
>>> Dave,
>>>
>>> Have you checked in this patch ? Or, does it require some more
>>> modification/updates from somebody=B4s side ?
>>>
>>
>> Dave,
>>
>> Would you consider checking in this patch ?
>
> Hold off please; give me a couple of hours to investigate.
Never mind; I replied to the wrong email. Please ignore my comments.
g.
--=20
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: [RFC PATCH] fsldma: Add DMA_SLAVE support
From: Ira Snyder @ 2009-06-17 18:29 UTC (permalink / raw)
To: Dan Williams; +Cc: linuxppc-dev@ozlabs.org, Li Yang
In-Reply-To: <4A392542.6010306@intel.com>
On Wed, Jun 17, 2009 at 10:17:54AM -0700, Dan Williams wrote:
> Ira Snyder wrote:
>>> Using EXPORT_SYMBOL would defeat the purpose of conforming to the
>>> dmaengine api which should allow other subsystems to generically
>>> discover an fsldma resource.
>>>
>>
>> Any driver would still use dma_request_channel(), etc. to get access to
>> a DMA channel. AFAICT, DMA_SLAVE is intended for doing something
>> completely hardware-specific with the DMA controller.
>
> Yes. Specifically DMA_SLAVE operations imply a pre-established context
> with a 3rd device (the other 2 devices being system memory and the dma
> channel), as compared to plain memcpy. The assumption is that a dma
> device with this capability may not be shared with other requesters
> until the context is torn down.
>
> [..]
>> What I've implemented is this: (sorry about the poor drawing)
>>
>> scatterlist fsl_dma_hw_addr
>> +--------+ +-------+
>> | DATA | --------> | DEST1 |
>> | DATA | ----+ +-------+
>> | DATA | |
>> | DATA | | +-------+
>> | DATA | +---> | DEST2 |
>> | DATA | +-------+
>> +--------+
>> .
>> .
>> .
>>
>> Of course, the reverse works as well. You can copy from a list of
>> hardware address/length pairs to a scatterlist.
>>
>> So, using my implementation of the DMA_SLAVE feature, you can take a big
>> chunk of data (which is organized into a scatterlist) and DMA it
>> directly to a set of hardware addresses, all in a single, unbroken
>> transaction.
>
> Could the same effect be achieved by calling ->prep_slave_sg multiple
> times? Once you need to add dma-driver specific helper routines you are
> effectively extending the dmaengine interface in an fsldma specific
> fashion. Can we reduce this to just the existing primitives? If it
> turns out that this is untenable can we extend dmaengine to make this a
> generic capability? My preference is the former.
>
I can do something similar by calling device_prep_dma_memcpy() lots of
times. Once for each page in the scatterlist.
This has the advantage of not changing the DMAEngine API.
This has the disadvantage of not being a single transaction. The DMA
controller will get an interrupt after each memcpy() transaction, clean
up descriptors, etc.
It also has the disadvantage of not being able to change the
controller-specific features I'm using: external start. This feature
lets the "3rd device" control the DMA controller. It looks like the
atmel-mci driver has a similar feature. The DMAEngine API has no way to
expose this type of feature except through DMA_SLAVE.
If it is just the 3 helper routines that are the issue with this patch,
I have no problem dropping them and letting each user re-create them
themselves.
>> I've inlined the driver for the FPGA programmer below. I don't think it
>> is appropriate to push into mainline, since it will only work for our
>> board, and nothing else.
>
> If we find that we need to extend the dmaengine interface we will need
> an in-tree user. In my opinion, as long as it passes the Voyager test
> [1] then I do not see why it should be barred from upstream.
>
Yep, I understand the Voyager test. I just didn't think it would be
useful to anyone to try and push it upstream, especially since the
hardware is in-house only.
The virtio-over-pci patches I've posted a while back may benefit from
this as well. They look more likely to go upstream. I've been really
busy and haven't had time to work on them recently, but Grant Likely is
working on them at the moment.
> [..]
>> He also used platform data to get the register addresses. I'm unaware of
>> a way to put arbitrary platform data into the OF tree used on PowerPC.
>>
>
> Anybody else on ppc-dev know if this is possible??
>
>> I didn't want to force other users to implement the allocation routines
>> for the struct fsl_dma_hw_addr themselves, so I provided routines to do
>> so.
>
> It depends on how many users of this feature there ends up being,
> pushing this into each driver that needs it would not be too horrible
> especially if it just the three straightforward routines
> (fsl_dma_slave_append, fsl_dma_slave_free, and fsl_dma_slave_alloc).
>
Right, the routines are very simple. I wouldn't have any problem leaving
it up to users.
> So, the three options in order of preference are:
> 1/ arrange to call ->prep multiple times to handle each dma address
This doesn't seem quite right. I'd end up doing something like:
struct fsl_dma_slave slave;
slave.external_start = true;
slave.address = 0xf0003000;
slave.length = 4096;
chan->private = &slave;
for_each_sg(sgl, sg, sg_len, i) {
device_prep_slave_sg(chan, sg, 1, DMA_TO_DEVICE, 0);
}
That pretty much defeats the purpose of the scatterlist argument,
doesn't it? Also, it is no better than just calling
device_prep_dma_memcpy() lots of times. You don't get a single DMA
transaction.
It is trivial to implement a dma_addr_t to dma_addr_t memcpy function.
Here is a version I've used in the past, based very heavily on
dma_async_memcpy_buf_to_buf():
static dma_cookie_t dma_async_memcpy_raw_to_raw(struct dma_chan *chan,
dma_addr_t dst,
dma_addr_t src,
size_t len)
{
struct dma_device *dev = chan->device;
struct dma_async_tx_descriptor *tx;
enum dma_ctrl_flags flags;
dma_cookie_t cookie;
int cpu;
flags = DMA_COMPL_SKIP_SRC_UNMAP | DMA_COMPL_SKIP_DEST_UNMAP;
tx = dev->device_prep_dma_memcpy(chan, dst, src, len, flags);
if (!tx)
return -ENOMEM;
tx->callback = NULL;
cookie = tx->tx_submit(tx);
cpu = get_cpu();
per_cpu_ptr(chan->local, cpu)->bytes_transferred += len;
per_cpu_ptr(chan->local, cpu)->memcpy_count++;
put_cpu();
return cookie;
}
I've used it when copying data from another machine over PCI, and for
copying to peripherals, such as the FPGA programmer.
> 2/ push the functionality down into the individual drivers that need it
> 3/ up level the functionality into dmaengine to make it generically
> available
A single-transaction scatterlist-to-scatterlist copy would be nice.
One of the major advantages of working with the DMA controller is that
it automatically handles scatter/gather. Almost all DMA controllers have
the feature, but it is totally missing from the high-level API.
Thanks,
Ira
^ permalink raw reply
* Re: [BUILD FAILURE 02/04] Next June 04:PPC64 randconfig [drivers/usb/host/ohci-hcd.o]
From: Grant Likely @ 2009-06-17 18:15 UTC (permalink / raw)
To: subrata
Cc: Sachin P Sant, Randy Dunlap, Arnd Bergmann, Stephen Rothwell,
linux-usb, Linux-Kernel, David Brownell, Linuxppc-dev, Linux-Next,
kernel
In-Reply-To: <1245243186.4870.5.camel@subratamodak.linux.ibm.com>
On Wed, Jun 17, 2009 at 6:53 AM, Subrata
Modak<subrata@linux.vnet.ibm.com> wrote:
> On Mon, 2009-06-15 at 12:21 +0530, Subrata Modak wrote:
>> On Fri, 2009-06-12 at 15:05 +0530, Subrata Modak wrote:
>> > On Tue, 2009-06-09 at 17:38 -0700, David Brownell wrote:
>> > > On Friday 05 June 2009, Subrata Modak wrote:
>> > > > Correct, it fixes the issue. However, since few changes might have=
gone
>> > > > to the Kconfig, the patch does not apply cleanly. Below is the pat=
ch, just
>> > > > a retake of the earlier one, but on the latest code.
>> > >
>> > > And it got mangled a bit along the way. =A0Plus, the original one
>> > > goofed up Kconfig dependency displays ... both issues fixed in
>> > > this version, against current mainline GIT.
>> > >
>> > > If someone can verify all four PPC/OF/OHCI configs build on
>> > > on PPC64, I'm OK with it.
>> > >
>> > > - Dave
>> >
>> > Dave,
>> >
>> > Sorry for being late. The patch fixes the issue on the latest git for
>> > PPC64. Infact, the whole drivers/usb/host/ builds just fine:
>> >
>> > linux-2.6 # make drivers/usb/host/
>> > =A0 CHK =A0 =A0 include/linux/version.h
>> > =A0 CHK =A0 =A0 include/linux/utsrelease.h
>> > =A0 SYMLINK include/asm -> include/asm-powerpc
>> > =A0 CALL =A0 =A0scripts/checksyscalls.sh
>> > =A0 CC =A0 =A0 =A0drivers/usb/host/ohci-hcd.o
>> > =A0 CC =A0 =A0 =A0drivers/usb/host/pci-quirks.o
>> > =A0 CC =A0 =A0 =A0drivers/usb/host/uhci-hcd.o
>> > =A0 LD =A0 =A0 =A0drivers/usb/host/built-in.o
>> > =A0 CC [M] =A0drivers/usb/host/isp116x-hcd.o
>> > =A0 CC [M] =A0drivers/usb/host/u132-hcd.o
>> >
>> > You can check in the patch now.
>>
>> Dave,
>>
>> Have you checked in this patch ? Or, does it require some more
>> modification/updates from somebody=B4s side ?
>>
>
> Dave,
>
> Would you consider checking in this patch ?
Hold off please; give me a couple of hours to investigate.
g.
--=20
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: 2.6.30-rc6: Problem with an SSD disk on Freescale PowerPC mpc8315e-rdb, works fine on x86
From: Kumar Gala @ 2009-06-17 17:53 UTC (permalink / raw)
To: Leon Woestenberg; +Cc: Linux PPC, linux-ide
In-Reply-To: <c384c5ea0906170907u5a4af524m65e23b32446dd79f@mail.gmail.com>
On Jun 17, 2009, at 11:07 AM, Leon Woestenberg wrote:
> Hello Kumar, all,
>
> On Mon, Jun 8, 2009 at 4:59 PM, Leon
> Woestenberg<leon.woestenberg@gmail.com> wrote:
>> using 2.6.30-rc6, I get the following problems when I read from a SSD
>> disk, connected to the
>> 3.0 Gb SATA controller of the MPC8315E SoC rev 1.0 running Linux
>> 2.6.30-rc6.
>>
> Result on a first batch of bisects. I decided to go with the kernel
> releases rather than git-bisect (still too scary for me).
>
> All kernel releases 2.6.25 through -30 kernel gave the same error.
> 2.6.25 crashed on it, whereas 2.6.26+ recovered after each "dd" run.
>
> The BSP 2.6.24.3-rt3 kernel did not give the error.
>
> So on my todo is diff between 2.6.25 and .2.6.24.3-rt3 from the BSP.
Does kernel.org 2.6.24 work ok?
- k
^ permalink raw reply
* Re: ethernet packet drop
From: Parav Pandit @ 2009-06-17 17:35 UTC (permalink / raw)
To: linuxppc-dev, Mehul Chadha
[-- Attachment #1: Type: text/plain, Size: 2128 bytes --]
Couple of points to debug,
1. Do you see any pause frames getting generated by Router device and not honoured by Spirent test equipment?
2. Checkout the MPC8248' load if you have console connected to it, using #top command.
Parav
--- On Wed, 6/17/09, Mehul Chadha <mehulc87@gmail.com> wrote:
From: Mehul Chadha <mehulc87@gmail.com>
Subject: ethernet packet drop
To: linuxppc-dev@lists.ozlabs.org
Date: Wednesday, June 17, 2009, 8:23 PM
Hello everyone,
I am working on a project for router development.
The basic specifications of the router are as follows:
·
Supports MPC8248 - 32-bit PowerQUICC II Communication Processor running
at 400 MHz (Max) core frequency, 200 MHz (Max) CPM, and 100MHz (Max) external
bus frequency.
·
64-bit wide 256-MByte synchronous DRAM (soldered
on-board), consisting of 4 no. devices
of 8M x 16 x 4, residing on 60X bus (PBI mode), controlled by SDRAM machine.
·
256 MB
NAND Flash, organized as 256M x 8, buffered from 60X bus, controlled by UPM
machine.
·
Upto 8MB
NOR Flash, Boot sector (bottom) type, organized as 8M x 8, buffered from 60X
bus, controlled by GPCM machine.
· Linux Kernel version: linux-2.6.16.40
While testing my router with the spirent test equipment, the 2 ethernet ports of the router are connected to the testing equipment. I send data from the testing equipment through the ethernet port , the router forwards the packet to the other ethernet port again connected to the testing equipment. When I increase the throughput to 70 mbps the testing equipment starts showing packet losses which should not happen as its a 10/100 mbps link. I am not able to understand where would the problem lie. Pls if someone can list the different issues due to which this problem is occurring, it will be really helpful
Regards,Mehul
-----Inline Attachment Follows-----
_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[-- Attachment #2: Type: text/html, Size: 6242 bytes --]
^ permalink raw reply
* Re: [PATCH][Resend 2][BUILD FAILURE 04/04] Next June 04:PPC64 randconfig [drivers/net/ucc_geth.o]
From: Grant Likely @ 2009-06-17 17:29 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Sachin P Sant, netdev, Linux-Kernel, Linuxppc-dev, Linux-Next,
Nathan Lynch, Haiying Wang, Li Yang, subrata, David S. Miller,
Balbir Singh
In-Reply-To: <20090617233452.03ac78d5.sfr@canb.auug.org.au>
On Wed, Jun 17, 2009 at 7:34 AM, Stephen Rothwell<sfr@canb.auug.org.au> wro=
te:
> On Wed, 17 Jun 2009 23:23:41 +1000 Stephen Rothwell <sfr@canb.auug.org.au=
> wrote:
>>
>> Hi Kumar,
>>
>> On Wed, 17 Jun 2009 08:07:47 -0500 Kumar Gala <galak@kernel.crashing.org=
> wrote:
>> >
>> >
>> > I'm confused by the proposed fix as we already have *mdio & *ph
>> > defined in this function:
>>
>> Which tree are you looking at? =A0Linus' tree, and linux-next, do not ha=
ve
>> those local variables ...
>
> Hmmm, commit 0b9da337dca972e7a4144e298ec3adb8f244d4a4 ("net: Rework
> ucc_geth driver to use of_mdio infrastructure") removed the locals along
> with their usages, then commit 047584ce94108012288554a5f84585d792cc7f8f
> ("net/ucc_geth: Add SGMII support for UEC GETH driver") added more uses
> without adding the variables back.
>
> Here is the patch again:
>
> From: Subrata Modak <subrata@linux.vnet.ibm.com>
> Subject: [PATCH] Fix build error in ucc_geth.c
>
> 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 fu=
nction)
> drivers/net/ucc_geth.c:3822: error: (Each undeclared identifier is report=
ed 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 =A0 =A0 =A0 =A02009-06-1=
0 11:58:39.000000000 -0500
> +++ linux-2.6.30-rc8/drivers/net/ucc_geth.c =A0 =A0 2009-06-10 22:28:13.0=
00000000 -0500
> @@ -3595,6 +3595,8 @@ static const struct net_device_ops ucc_g
>
> =A0static int ucc_geth_probe(struct of_device* ofdev, const struct of_dev=
ice_id *match)
> =A0{
> + =A0 =A0 =A0 struct device_node *mdio;
> + =A0 =A0 =A0 const phandle *ph;
> =A0 =A0 =A0 =A0struct device *device =3D &ofdev->dev;
> =A0 =A0 =A0 =A0struct device_node *np =3D ofdev->node;
> =A0 =A0 =A0 =A0struct net_device *dev =3D NULL;
Ah, this might not be the right fix then. I'll look.
g.
--=20
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: [RFC PATCH] fsldma: Add DMA_SLAVE support
From: Dan Williams @ 2009-06-17 17:17 UTC (permalink / raw)
To: Ira Snyder; +Cc: linuxppc-dev@ozlabs.org, Li Yang
In-Reply-To: <20090616201256.GG15955@ovro.caltech.edu>
Ira Snyder wrote:
>> Using EXPORT_SYMBOL would defeat the purpose of conforming to the
>> dmaengine api which should allow other subsystems to generically
>> discover an fsldma resource.
>>
>
> Any driver would still use dma_request_channel(), etc. to get access to
> a DMA channel. AFAICT, DMA_SLAVE is intended for doing something
> completely hardware-specific with the DMA controller.
Yes. Specifically DMA_SLAVE operations imply a pre-established context
with a 3rd device (the other 2 devices being system memory and the dma
channel), as compared to plain memcpy. The assumption is that a dma
device with this capability may not be shared with other requesters
until the context is torn down.
[..]
> What I've implemented is this: (sorry about the poor drawing)
>
> scatterlist fsl_dma_hw_addr
> +--------+ +-------+
> | DATA | --------> | DEST1 |
> | DATA | ----+ +-------+
> | DATA | |
> | DATA | | +-------+
> | DATA | +---> | DEST2 |
> | DATA | +-------+
> +--------+
> .
> .
> .
>
> Of course, the reverse works as well. You can copy from a list of
> hardware address/length pairs to a scatterlist.
>
> So, using my implementation of the DMA_SLAVE feature, you can take a big
> chunk of data (which is organized into a scatterlist) and DMA it
> directly to a set of hardware addresses, all in a single, unbroken
> transaction.
Could the same effect be achieved by calling ->prep_slave_sg multiple
times? Once you need to add dma-driver specific helper routines you are
effectively extending the dmaengine interface in an fsldma specific
fashion. Can we reduce this to just the existing primitives? If it
turns out that this is untenable can we extend dmaengine to make this a
generic capability? My preference is the former.
> I've inlined the driver for the FPGA programmer below. I don't think it
> is appropriate to push into mainline, since it will only work for our
> board, and nothing else.
If we find that we need to extend the dmaengine interface we will need
an in-tree user. In my opinion, as long as it passes the Voyager test
[1] then I do not see why it should be barred from upstream.
[..]
> He also used platform data to get the register addresses. I'm unaware of
> a way to put arbitrary platform data into the OF tree used on PowerPC.
>
Anybody else on ppc-dev know if this is possible??
> I didn't want to force other users to implement the allocation routines
> for the struct fsl_dma_hw_addr themselves, so I provided routines to do
> so.
It depends on how many users of this feature there ends up being,
pushing this into each driver that needs it would not be too horrible
especially if it just the three straightforward routines
(fsl_dma_slave_append, fsl_dma_slave_free, and fsl_dma_slave_alloc).
So, the three options in order of preference are:
1/ arrange to call ->prep multiple times to handle each dma address
2/ push the functionality down into the individual drivers that need it
3/ up level the functionality into dmaengine to make it generically
available
Thanks,
Dan
[1]: The Voyager test refers to James Bottomley's maintenance of the
Voyager x86-sub-architecture. If at least one person cares about a
feature, is willing to maintain the code, and it does not impose a
maintenance burden on other parts of the tree then it can go upstream.
^ permalink raw reply
* Re: 2.6.30-rc6: Problem with an SSD disk on Freescale PowerPC mpc8315e-rdb, works fine on x86
From: Leon Woestenberg @ 2009-06-17 16:07 UTC (permalink / raw)
To: Linux PPC, Kumar Gala, linux-ide
In-Reply-To: <c384c5ea0906080759n24a66d21ob9076518cec41755@mail.gmail.com>
Hello Kumar, all,
On Mon, Jun 8, 2009 at 4:59 PM, Leon
Woestenberg<leon.woestenberg@gmail.com> wrote:
> using 2.6.30-rc6, I get the following problems when I read from a SSD
> disk, connected to the
> 3.0 Gb SATA controller of the MPC8315E SoC rev 1.0 running Linux 2.6.30-rc6.
>
Result on a first batch of bisects. I decided to go with the kernel
releases rather than git-bisect (still too scary for me).
All kernel releases 2.6.25 through -30 kernel gave the same error.
2.6.25 crashed on it, whereas 2.6.26+ recovered after each "dd" run.
The BSP 2.6.24.3-rt3 kernel did not give the error.
So on my todo is diff between 2.6.25 and .2.6.24.3-rt3 from the BSP.
Regards,
--
Leon
^ permalink raw reply
* ethernet packet drop
From: Mehul Chadha @ 2009-06-17 14:53 UTC (permalink / raw)
To: linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 1452 bytes --]
Hello everyone,
I am working on a project for router development.
The basic specifications of the router are as follows:
· Supports MPC8248 - 32-bit PowerQUICC II Communication Processor
running at 400 MHz (Max) core frequency, 200 MHz (Max) CPM, and 100MHz (Max)
external bus frequency.
· 64-bit wide 256-MByte synchronous DRAM (soldered on-board),
consisting
of 4 no. devices of 8M x 16 x 4, residing on 60X bus (PBI mode), controlled
by SDRAM machine.
· 256 MB NAND Flash, organized as 256M x 8, buffered from 60X bus,
controlled by UPM machine.
· Upto 8MB NOR Flash, Boot sector (bottom) type, organized as 8M x
8, buffered from 60X bus, controlled by GPCM machine.
· Linux Kernel version: linux-2.6.16.40
While testing my router with the spirent test equipment, the 2 ethernet
ports of the router are connected to the testing equipment. I send data from
the testing equipment through the ethernet port , the router forwards the
packet to the other ethernet port again connected to the testing equipment.
When I increase the throughput to 70 mbps the testing equipment starts
showing packet losses which should not happen as its a 10/100 mbps link. I
am not able to understand where would the problem lie. Pls if someone can
list the different issues due to which this problem is occurring, it will be
really helpful
Regards,
Mehul
[-- Attachment #2: Type: text/html, Size: 7896 bytes --]
^ permalink raw reply
* Re: [PATCH] Do not inline putprops function
From: Neil Horman @ 2009-06-17 14:40 UTC (permalink / raw)
To: M. Mohan Kumar; +Cc: linuxppc-dev, Simon Horman, kexec, miltonm
In-Reply-To: <20090617142652.GC4059@in.ibm.com>
On Wed, Jun 17, 2009 at 07:56:52PM +0530, M. Mohan Kumar wrote:
> On Wed, Jun 17, 2009 at 10:05:14AM -0400, Neil Horman wrote:
> > On Wed, Jun 17, 2009 at 07:04:35PM +0530, M. Mohan Kumar wrote:
> > > On Wed, Jun 17, 2009 at 09:04:13AM -0400, Neil Horman wrote:
> > > > On Wed, Jun 17, 2009 at 10:26:35PM +1000, Michael Ellerman wrote:
> > > > >
> > > > > What compiler version are you using? Does the behaviour change if you
> > > > > use a newer/older compiler? It sounds to me like there's some deeper bug
> > > > > and your patch is just papering over it.
> > > > >
> > >
> > > I tried with gcc 4.3.2. Let me try with a recent version and update.
> > >
> > > > Agreed, this doesn't make any sense. Try changing the compiler version to see if
> > > > the problem goes away or stops. It might also be worthwhile to dump the
> > > > contents of the device tree at the start and end of the kexec process. If the
> > > > changing of how a function is inlined is causing a hang, its likely changing how
> > > > the putprops function is writing information to the device tree. Understanding
> > > > what that change is will likely provide clues to how the code has changed.
> > >
> > > Neil, there was no code change in fs2dt.c
> > >
> > Sure there was, by modifying the code to tell it to not inline the putprops
> > function, you changed how the complier optimizes that code block. There may not
> > be any source level code change, but the assembly is certainly different, and it
> > must be so in a way thats causing a hang. The putpops function changes the
> > contents of the ppc64 device-tree, so if this is a compiler bug, and its causing
> > a hang, I imagine we'll see some manifestation in a change in the device tree
> > contents.
>
> As I mentioned in the patch description, when I retained the variable dt_len
> and dt_len = dt assignment, kexec/kdump kernel would work. But even if I
> comment the "dt_len = dt" assignment kernel would hang. If you need I can
Yes, and as Michael has noted, that is likey an indication of a compiler bug.
You shouldn't get differing behavior in a kdump kernel by removing an unused
variable in kexec. Which is why I'm unconvinced this patch is really fixing
anything, but rather just avoiding the real problem.
> send objdump of fs2dt.o with and without this assignment.
>
That would be a fine thing to do, and I'd be happy to compare them. My though
regarding the comparison of the device tree on a good and bad run was meant to
expidite what change in the assembly we'd be looking for. If its the kdump
kernel boot thats hanging, Its likely hanging on something in the device tree,
as thats whats being manipulated by this code. So I figure that understanding
whats changed there will point us toward what change in the assembly might be
responsible for the hang. The assmebly's going to be signficantly different
(lots of optimization might be lost from no longer inlining a function), so
anything that helps us narrow down whats changed will be good
Neil
> Regards,
> M. Mohan Kumar.
^ permalink raw reply
* Re: [PATCH 1/6] perf_counter: powerpc: Enable use of software counters on 32-bit powerpc
From: Ingo Molnar @ 2009-06-17 14:27 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev, Paul Mackerras, Peter Zijlstra, linux-kernel
In-Reply-To: <8C6954A9-BE4C-47F5-AD87-A1D0EAF43F8A@kernel.crashing.org>
* Kumar Gala <galak@kernel.crashing.org> wrote:
> On Jun 17, 2009, at 9:21 AM, Ingo Molnar wrote:
>
>> * Paul Mackerras <paulus@samba.org> wrote:
>>
>>> This depends on the generic atomic64_t patches, which are now in
>>> Linus' tree. Ingo, if you're putting these in, please pull
>>> Linus' tree in first.
>>
>> Note, i've created a new branch, tip:perfcounters/powerpc, so we
>> can keep these things separate and Ben can pull them too. I see
>> there was some review feedback - do you want to send a v2 version
>> perhaps?
>
> Out of interest, is the intent to try and get these changes into
> .31? I ask because I want to know if I should try to find time to
> add support for the FSL embedded perfmon ASAP or not.
I think it would be nice to have more platform support in .31.
Perfcounters is a brand-new feature so there's no risk of
regression. In the end it will depend on Linus to pull of course,
and BenH can veto it too if he'd like no more PowerPC changes in
this cycle. Worst-case it's all .32 material.
Ingo
^ permalink raw reply
* Re: [PATCH] Do not inline putprops function
From: M. Mohan Kumar @ 2009-06-17 14:26 UTC (permalink / raw)
To: Neil Horman; +Cc: linuxppc-dev, Simon Horman, kexec, miltonm
In-Reply-To: <20090617140514.GB31383@hmsreliant.think-freely.org>
On Wed, Jun 17, 2009 at 10:05:14AM -0400, Neil Horman wrote:
> On Wed, Jun 17, 2009 at 07:04:35PM +0530, M. Mohan Kumar wrote:
> > On Wed, Jun 17, 2009 at 09:04:13AM -0400, Neil Horman wrote:
> > > On Wed, Jun 17, 2009 at 10:26:35PM +1000, Michael Ellerman wrote:
> > > >
> > > > What compiler version are you using? Does the behaviour change if you
> > > > use a newer/older compiler? It sounds to me like there's some deeper bug
> > > > and your patch is just papering over it.
> > > >
> >
> > I tried with gcc 4.3.2. Let me try with a recent version and update.
> >
> > > Agreed, this doesn't make any sense. Try changing the compiler version to see if
> > > the problem goes away or stops. It might also be worthwhile to dump the
> > > contents of the device tree at the start and end of the kexec process. If the
> > > changing of how a function is inlined is causing a hang, its likely changing how
> > > the putprops function is writing information to the device tree. Understanding
> > > what that change is will likely provide clues to how the code has changed.
> >
> > Neil, there was no code change in fs2dt.c
> >
> Sure there was, by modifying the code to tell it to not inline the putprops
> function, you changed how the complier optimizes that code block. There may not
> be any source level code change, but the assembly is certainly different, and it
> must be so in a way thats causing a hang. The putpops function changes the
> contents of the ppc64 device-tree, so if this is a compiler bug, and its causing
> a hang, I imagine we'll see some manifestation in a change in the device tree
> contents.
As I mentioned in the patch description, when I retained the variable dt_len
and dt_len = dt assignment, kexec/kdump kernel would work. But even if I
comment the "dt_len = dt" assignment kernel would hang. If you need I can
send objdump of fs2dt.o with and without this assignment.
Regards,
M. Mohan Kumar.
^ 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