* Re: [PATCH 2/5] Add legacy devices to mpc8641_hpcn.dts
From: Wade Farnsworth @ 2007-05-16 20:17 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev
In-Reply-To: <b77c4b3dd22795a73cd32a0623722e51@kernel.crashing.org>
On Wed, 2007-05-16 at 21:55 +0200, Segher Boessenkool wrote:
> >> + isa@f0 {
>
> isa@1e
>
> >> + 8042@60 {
> >> + device_type = "8042";
>
> Drop the device_type. A number as a name isn't
> all that great, either.
Currently in order for the i8042 devices to be initialized,
check_legacy_ioport() must find a node with device_type "8042".
>
> >> + rtc@70 {
> >> + device_type = "rtc";
> >> + reg = <1 70 2>;
> >> + };
> >
> > Is "rtc" a standard OF device,
>
> Yes, it is defined in the "Device Support Extensions"
> recommended practice.
>
> > And is the plan to somehow use this entry in the future?
>
> The platform code can use it to find the device. If it
> would have a proper "compatible" property, the generic
> code could do that work, instead.
Is there a recommended "compatible" property for a standard PC-like CMOS
RTC?
--Wade
^ permalink raw reply
* [PATCH] gianfar: Add I/O barriers when touching buffer descriptor ownership.
From: Scott Wood @ 2007-05-16 20:06 UTC (permalink / raw)
To: jgarzik; +Cc: netdev, linuxppc-dev
The hardware must not see that is given ownership of a buffer until it is
completely written, and when the driver receives ownership of a buffer,
it must ensure that any other reads to the buffer reflect its final
state. Thus, I/O barriers are added where required.
Without this patch, I have observed GCC reordering the setting of
bdp->length and bdp->status in gfar_new_skb. Hardware reordering
was also theoretically possible.
Signed-off-by: Scott Wood <scottwood@freescale.com>
---
I've added the requested comments to the source code about
the use of eieio(). Jeff, please consider for 2.6.22, as it
fixes a bug that has been observed.
drivers/net/gianfar.c | 11 +++++++++++
1 files changed, 11 insertions(+), 0 deletions(-)
diff --git a/drivers/net/gianfar.c b/drivers/net/gianfar.c
index b666a0c..f5b3cba 100644
--- a/drivers/net/gianfar.c
+++ b/drivers/net/gianfar.c
@@ -1025,6 +1025,15 @@ static int gfar_start_xmit(struct sk_buff *skb, struct net_device *dev)
dev->trans_start = jiffies;
+ /* The powerpc-specific eieio() is used, as wmb() has too strong
+ * semantics (it requires synchronization between cacheable and
+ * uncacheable mappings, which eieio doesn't provide and which we
+ * don't need), thus requiring a more expensive sync instruction. At
+ * some point, the set of architecture-independent barrier functions
+ * should be expanded to include weaker barriers.
+ */
+
+ eieio();
txbdp->status = status;
/* If this was the last BD in the ring, the next one */
@@ -1301,6 +1310,7 @@ struct sk_buff * gfar_new_skb(struct net_device *dev, struct rxbd8 *bdp)
bdp->length = 0;
/* Mark the buffer empty */
+ eieio();
bdp->status |= (RXBD_EMPTY | RXBD_INTERRUPT);
return skb;
@@ -1484,6 +1494,7 @@ int gfar_clean_rx_ring(struct net_device *dev, int rx_work_limit)
bdp = priv->cur_rx;
while (!((bdp->status & RXBD_EMPTY) || (--rx_work_limit < 0))) {
+ rmb();
skb = priv->rx_skbuff[priv->skb_currx];
if (!(bdp->status &
--
1.5.0.3
^ permalink raw reply related
* Re: [PATCH 2/5] Add legacy devices to mpc8641_hpcn.dts
From: Sergei Shtylyov @ 2007-05-16 20:03 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev
In-Reply-To: <b77c4b3dd22795a73cd32a0623722e51@kernel.crashing.org>
Hello.
Segher Boessenkool wrote:
>>>+ 8042@60 {
>>>+ device_type = "8042";
> Drop the device_type. A number as a name isn't
> all that great, either.
Perhaps it should be called "keyboard" (and device_type should also be set
to it) since 8042 is in fact (mostly) a keyboard controller... although it
also "drives" PS/2 mouse...
>>>+ rtc@70 {
>>>+ device_type = "rtc";
>>>+ reg = <1 70 2>;
>>>+ };
>>Is "rtc" a standard OF device,
> Yes, it is defined in the "Device Support Extensions"
> recommended practice.
And it also defines "keyboard".
WBR, Sergei
^ permalink raw reply
* Re: [PATCH 2/5] Add legacy devices to mpc8641_hpcn.dts
From: Segher Boessenkool @ 2007-05-16 19:59 UTC (permalink / raw)
To: Wade Farnsworth; +Cc: linuxppc-dev
In-Reply-To: <1179338347.8132.200.camel@rhino>
>> Is "rtc" a standard OF device, or are we making up a
>> new thing that should be documented in booting-with-OF.txt ?
>> And is the plan to somehow use this entry in the future?
>
> It is my understanding that "rtc" is a standard OF device. Can anybody
> confirm this?
It is.
> This could be used in the platform-specific RTC code to get the ports
> from the device tree. Currently, however, I simply use RTC_PORT(x)
> from
> asm/mc146818rtc.h. Is it preferable to use the device tree here?
If you instantiate the RTC device from platform code,
and the device sits at the same address on all boards
you support, the only good thing you get from using
the device tree is that you don't have to hardcode a
number in the Linux code. Using the device tree however
the RTC device could be detected and instantiated from
more generic code, a much better situation.
Segher
^ permalink raw reply
* Re: [PATCH 2/5] Add legacy devices to mpc8641_hpcn.dts
From: Segher Boessenkool @ 2007-05-16 19:55 UTC (permalink / raw)
To: Jon Loeliger; +Cc: linuxppc-dev
In-Reply-To: <1179333421.7018.17.camel@ld0161-tx32>
>> + isa@f0 {
isa@1e
>> + 8042@60 {
>> + device_type = "8042";
Drop the device_type. A number as a name isn't
all that great, either.
>> + rtc@70 {
>> + device_type = "rtc";
>> + reg = <1 70 2>;
>> + };
>
> Is "rtc" a standard OF device,
Yes, it is defined in the "Device Support Extensions"
recommended practice.
> And is the plan to somehow use this entry in the future?
The platform code can use it to find the device. If it
would have a proper "compatible" property, the generic
code could do that work, instead.
Segher
^ permalink raw reply
* Re: [i2c] [PATCH] Make i2c-mpc driver use i2c_add_numbered_adapter
From: Scott Wood @ 2007-05-16 19:15 UTC (permalink / raw)
To: David Brownell; +Cc: rtc-linux, linuxppc-dev, i2c, Jean Delvare
In-Reply-To: <200705150828.37529.david-b@pacbell.net>
David Brownell wrote:
> On Tuesday 15 May 2007, Jean Delvare wrote:
>
>>On Mon, 14 May 2007 13:11:23 -0600, Grant Likely wrote:
>
>
>>>--- a/drivers/i2c/busses/i2c-mpc.c
>>>+++ b/drivers/i2c/busses/i2c-mpc.c
>>>@@ -327,9 +327,10 @@ static int fsl_i2c_probe(struct platform_device *pdev)
>>> platform_set_drvdata(pdev, i2c);
>>>
>>> i2c->adap = mpc_ops;
>>>+ i2c->adap.nr = pdev->id;
>
>
> By the way: mpc_ops is a static i2c_adapter, so given that
> the reason for using pdev->id that way was that there might
> be more than one such platform device ... shouldn't allocation
> of the adapter be moved into allocation of the "i2c->" object?
>
> Or at least, add a check to ensure that the static mpc_ops
> structure isn't in use before progressing this probe().
The mpc_ops struct is only used as a template; it gets copied into
i2c->adap for each adapter instance.
-Scott
^ permalink raw reply
* [PATCH 3/3] ibm_emac: fix link speed detection change
From: Eugene Surovegin @ 2007-05-16 19:01 UTC (permalink / raw)
To: netdev; +Cc: Stefan Roese, Jeff Garzik, linuxppc-embedded
Fix link speed detection change.
Thanks to Stefan Roese <sr@denx.de> for finding this bug.
CC: Stefan Roese <sr@denx.de>
Signed-off-by: Eugene Surovegin <ebs@ebshome.net>
---
drivers/net/ibm_emac/ibm_emac_core.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/ibm_emac/ibm_emac_core.c b/drivers/net/ibm_emac/ibm_emac_core.c
index 50035eb..f752e5f 100644
--- a/drivers/net/ibm_emac/ibm_emac_core.c
+++ b/drivers/net/ibm_emac/ibm_emac_core.c
@@ -926,7 +926,7 @@ static int emac_link_differs(struct ocp_enet_private *dev)
int duplex = r & EMAC_MR1_FDE ? DUPLEX_FULL : DUPLEX_HALF;
int speed, pause, asym_pause;
- if (r & (EMAC_MR1_MF_1000 | EMAC_MR1_MF_1000GPCS))
+ if (r & EMAC_MR1_MF_1000)
speed = SPEED_1000;
else if (r & EMAC_MR1_MF_100)
speed = SPEED_100;
^ permalink raw reply related
* [PATCH 2/3] ibm_emac: improved PHY support
From: Eugene Surovegin @ 2007-05-16 18:59 UTC (permalink / raw)
To: netdev; +Cc: Jeff Haran, Jeff Garzik, linuxppc-embedded
Original patch is from Jeff Haran <jharan@brocade.com> with my minor style
fixes. His comments follow:
The first problem was in the function that configures the PHY for
autonegotiation, genmii_setup_aneg(). The original code does a
read/modify/write of the autonegotiation advertizement register (reg 4),
followed by a read/modify/write of the control register (reg 0). While
the original code follows the proper procedure as per reading the IEEE
specs, what I found is that on at least one PHY model (National DP83843)
the read of the control register comes back with the soft reset bit set
(bit 15). Because of the read/modify/write operation, this causes the
write to write a 1 back to the reset bit, which initiates a software
reset of the PHY. This software reset causes the PHY to return to its
power up state which advertizes all modes of operation, thus negating
the write to the autoneg advertizement register. The modification is to
spin reading the control register until the soft reset bit is clear
before doing the modify/write.
The second problem was in the function that configures the PHY for
forced operation, genmii_setup_forced(). The original code initiates a
software reset operation via a write of a 1 to bit 15 of the control
register (reg 0), but then proceeds to do a second write to that same
register without waiting until that reset bit is cleared by the PHY
itself (which according to the IEEE specs indicates that the PHY reset
is complete). This is a violation of how one is supposed to use this
software reset feature of these PHYs and I believe was the cause of
mysterious, difficult to reproduce link failures that we've observed on
some of our systems that use this driver. The fix is to modify the
function so that it spins waiting for the reset bit to clear after doing
the soft reset and before doing the subsequent write.
Signed-off-by: Jeff Haran <jharan@brocade.com>
CC: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Eugene Surovegin <ebs@ebshome.net>
---
drivers/net/ibm_emac/ibm_emac_phy.c | 60 ++++++++++++++++++++++++++---------
1 files changed, 45 insertions(+), 15 deletions(-)
diff --git a/drivers/net/ibm_emac/ibm_emac_phy.c b/drivers/net/ibm_emac/ibm_emac_phy.c
index 9074f76..e57862b 100644
--- a/drivers/net/ibm_emac/ibm_emac_phy.c
+++ b/drivers/net/ibm_emac/ibm_emac_phy.c
@@ -22,6 +22,7 @@
#include <asm/ocp.h>
+#include "ibm_emac_core.h"
#include "ibm_emac_phy.h"
static inline int phy_read(struct mii_phy *phy, int reg)
@@ -34,11 +35,39 @@ static inline void phy_write(struct mii_phy *phy, int reg, int val)
phy->mdio_write(phy->dev, phy->address, reg, val);
}
-int mii_reset_phy(struct mii_phy *phy)
+/*
+ * polls MII_BMCR until BMCR_RESET bit clears or operation times out.
+ *
+ * returns:
+ * >= 0 => success, value in BMCR returned to caller
+ * -EBUSY => failure, RESET bit never cleared
+ * otherwise => failure, lower level PHY read failed
+ */
+static int mii_spin_reset_complete(struct mii_phy *phy)
{
int val;
int limit = 10000;
+ while (limit--) {
+ val = phy_read(phy, MII_BMCR);
+ if (val >= 0 && !(val & BMCR_RESET))
+ return val; /* success */
+ udelay(10);
+ }
+ if (val & BMCR_RESET)
+ val = -EBUSY;
+
+ if (net_ratelimit())
+ printk(KERN_ERR "emac%d: PHY reset timeout (%d)\n",
+ ((struct ocp_enet_private *)phy->dev->priv)->def->index,
+ val);
+ return val;
+}
+
+int mii_reset_phy(struct mii_phy *phy)
+{
+ int val;
+
val = phy_read(phy, MII_BMCR);
val &= ~BMCR_ISOLATE;
val |= BMCR_RESET;
@@ -46,16 +75,11 @@ int mii_reset_phy(struct mii_phy *phy)
udelay(300);
- while (limit--) {
- val = phy_read(phy, MII_BMCR);
- if (val >= 0 && (val & BMCR_RESET) == 0)
- break;
- udelay(10);
- }
- if ((val & BMCR_ISOLATE) && limit > 0)
+ val = mii_spin_reset_complete(phy);
+ if (val >= 0 && (val & BMCR_ISOLATE))
phy_write(phy, MII_BMCR, val & ~BMCR_ISOLATE);
- return limit <= 0;
+ return val < 0;
}
static int genmii_setup_aneg(struct mii_phy *phy, u32 advertise)
@@ -102,8 +126,14 @@ static int genmii_setup_aneg(struct mii_phy *phy, u32 advertise)
}
/* Start/Restart aneg */
- ctl = phy_read(phy, MII_BMCR);
- ctl |= (BMCR_ANENABLE | BMCR_ANRESTART);
+ /* on some PHYs (e.g. National DP83843) a write to MII_ADVERTISE
+ * causes BMCR_RESET to be set on the next read of MII_BMCR, which
+ * if not checked for causes the PHY to be reset below */
+ ctl = mii_spin_reset_complete(phy);
+ if (ctl < 0)
+ return ctl;
+
+ ctl |= BMCR_ANENABLE | BMCR_ANRESTART;
phy_write(phy, MII_BMCR, ctl);
return 0;
@@ -118,13 +148,13 @@ static int genmii_setup_forced(struct mii_phy *phy, int speed, int fd)
phy->duplex = fd;
phy->pause = phy->asym_pause = 0;
+ /* First reset the PHY */
+ mii_reset_phy(phy);
+
ctl = phy_read(phy, MII_BMCR);
if (ctl < 0)
return ctl;
- ctl &= ~(BMCR_FULLDPLX | BMCR_SPEED100 | BMCR_ANENABLE);
-
- /* First reset the PHY */
- phy_write(phy, MII_BMCR, ctl | BMCR_RESET);
+ ctl &= ~(BMCR_FULLDPLX | BMCR_SPEED100 | BMCR_ANENABLE | BMCR_SPEED1000);
/* Select speed & duplex */
switch (speed) {
^ permalink raw reply related
* [PATCH 1/3] ibm_emac: fix section mismatch warnings
From: Eugene Surovegin @ 2007-05-16 18:57 UTC (permalink / raw)
To: netdev; +Cc: Jeff Garzik, linuxppc-embedded
Fix "Section mismatch" warnings
Signed-off-by: Eugene Surovegin <ebs@ebshome.net>
---
drivers/net/ibm_emac/ibm_emac_mal.c | 3 +--
drivers/net/ibm_emac/ibm_emac_mal.h | 3 +--
drivers/net/ibm_emac/ibm_emac_rgmii.c | 2 +-
drivers/net/ibm_emac/ibm_emac_rgmii.h | 2 +-
drivers/net/ibm_emac/ibm_emac_tah.c | 2 +-
drivers/net/ibm_emac/ibm_emac_tah.h | 2 +-
drivers/net/ibm_emac/ibm_emac_zmii.c | 2 +-
drivers/net/ibm_emac/ibm_emac_zmii.h | 2 +-
8 files changed, 8 insertions(+), 10 deletions(-)
diff --git a/drivers/net/ibm_emac/ibm_emac_mal.c b/drivers/net/ibm_emac/ibm_emac_mal.c
index 6c0f071..cabd984 100644
--- a/drivers/net/ibm_emac/ibm_emac_mal.c
+++ b/drivers/net/ibm_emac/ibm_emac_mal.c
@@ -59,8 +59,7 @@ int __init mal_register_commac(struct ibm_ocp_mal *mal,
return 0;
}
-void __exit mal_unregister_commac(struct ibm_ocp_mal *mal,
- struct mal_commac *commac)
+void mal_unregister_commac(struct ibm_ocp_mal *mal, struct mal_commac *commac)
{
unsigned long flags;
local_irq_save(flags);
diff --git a/drivers/net/ibm_emac/ibm_emac_mal.h b/drivers/net/ibm_emac/ibm_emac_mal.h
index 407d2ac..64bc338 100644
--- a/drivers/net/ibm_emac/ibm_emac_mal.h
+++ b/drivers/net/ibm_emac/ibm_emac_mal.h
@@ -223,8 +223,7 @@ void mal_exit(void) __exit;
int mal_register_commac(struct ibm_ocp_mal *mal,
struct mal_commac *commac) __init;
-void mal_unregister_commac(struct ibm_ocp_mal *mal,
- struct mal_commac *commac) __exit;
+void mal_unregister_commac(struct ibm_ocp_mal *mal, struct mal_commac *commac);
int mal_set_rcbs(struct ibm_ocp_mal *mal, int channel, unsigned long size);
/* Returns BD ring offset for a particular channel
diff --git a/drivers/net/ibm_emac/ibm_emac_rgmii.c b/drivers/net/ibm_emac/ibm_emac_rgmii.c
index 53d281c..9dbb5e5 100644
--- a/drivers/net/ibm_emac/ibm_emac_rgmii.c
+++ b/drivers/net/ibm_emac/ibm_emac_rgmii.c
@@ -162,7 +162,7 @@ void rgmii_set_speed(struct ocp_device *ocpdev, int input, int speed)
out_be32(&dev->base->ssr, ssr);
}
-void __exit __rgmii_fini(struct ocp_device *ocpdev, int input)
+void __rgmii_fini(struct ocp_device *ocpdev, int input)
{
struct ibm_ocp_rgmii *dev = ocp_get_drvdata(ocpdev);
BUG_ON(!dev || dev->users == 0);
diff --git a/drivers/net/ibm_emac/ibm_emac_rgmii.h b/drivers/net/ibm_emac/ibm_emac_rgmii.h
index 117ea48..971e458 100644
--- a/drivers/net/ibm_emac/ibm_emac_rgmii.h
+++ b/drivers/net/ibm_emac/ibm_emac_rgmii.h
@@ -37,7 +37,7 @@ struct ibm_ocp_rgmii {
#ifdef CONFIG_IBM_EMAC_RGMII
int rgmii_attach(void *emac) __init;
-void __rgmii_fini(struct ocp_device *ocpdev, int input) __exit;
+void __rgmii_fini(struct ocp_device *ocpdev, int input);
static inline void rgmii_fini(struct ocp_device *ocpdev, int input)
{
if (ocpdev)
diff --git a/drivers/net/ibm_emac/ibm_emac_tah.c b/drivers/net/ibm_emac/ibm_emac_tah.c
index e287b45..3c2d5ba 100644
--- a/drivers/net/ibm_emac/ibm_emac_tah.c
+++ b/drivers/net/ibm_emac/ibm_emac_tah.c
@@ -63,7 +63,7 @@ int __init tah_attach(void *emac)
return 0;
}
-void __exit __tah_fini(struct ocp_device *ocpdev)
+void __tah_fini(struct ocp_device *ocpdev)
{
struct tah_regs *p = ocp_get_drvdata(ocpdev);
BUG_ON(!p);
diff --git a/drivers/net/ibm_emac/ibm_emac_tah.h b/drivers/net/ibm_emac/ibm_emac_tah.h
index 3815394..ccf6491 100644
--- a/drivers/net/ibm_emac/ibm_emac_tah.h
+++ b/drivers/net/ibm_emac/ibm_emac_tah.h
@@ -55,7 +55,7 @@ struct tah_regs {
#ifdef CONFIG_IBM_EMAC_TAH
int tah_attach(void *emac) __init;
-void __tah_fini(struct ocp_device *ocpdev) __exit;
+void __tah_fini(struct ocp_device *ocpdev);
static inline void tah_fini(struct ocp_device *ocpdev)
{
if (ocpdev)
diff --git a/drivers/net/ibm_emac/ibm_emac_zmii.c b/drivers/net/ibm_emac/ibm_emac_zmii.c
index 37dc8f3..2c0fdb0 100644
--- a/drivers/net/ibm_emac/ibm_emac_zmii.c
+++ b/drivers/net/ibm_emac/ibm_emac_zmii.c
@@ -215,7 +215,7 @@ void __zmii_set_speed(struct ocp_device *ocpdev, int input, int speed)
out_be32(&dev->base->ssr, ssr);
}
-void __exit __zmii_fini(struct ocp_device *ocpdev, int input)
+void __zmii_fini(struct ocp_device *ocpdev, int input)
{
struct ibm_ocp_zmii *dev = ocp_get_drvdata(ocpdev);
BUG_ON(!dev || dev->users == 0);
diff --git a/drivers/net/ibm_emac/ibm_emac_zmii.h b/drivers/net/ibm_emac/ibm_emac_zmii.h
index 972e3a4..fad6d8b 100644
--- a/drivers/net/ibm_emac/ibm_emac_zmii.h
+++ b/drivers/net/ibm_emac/ibm_emac_zmii.h
@@ -40,7 +40,7 @@ struct ibm_ocp_zmii {
#ifdef CONFIG_IBM_EMAC_ZMII
int zmii_attach(void *emac) __init;
-void __zmii_fini(struct ocp_device *ocpdev, int input) __exit;
+void __zmii_fini(struct ocp_device *ocpdev, int input);
static inline void zmii_fini(struct ocp_device *ocpdev, int input)
{
if (ocpdev)
^ permalink raw reply related
* [PATCH] Pass per-file CFLAGs for platform specific op codes
From: Josh Boyer @ 2007-05-16 18:51 UTC (permalink / raw)
To: linuxppc-dev
As a result of compiling all of the wrapper files for every platform
now, the kernel build can fail for toolchains that don't support various
op codes by default. An example of this building a 7xx platform with
the ELD4.0 toolchain, is below:
/tmp/ccYjhJoL.s: Assembler messages:
/tmp/ccYjhJoL.s:42: Error: Unrecognized opcode: `mtdcr'
/tmp/ccYjhJoL.s:43: Error: Unrecognized opcode: `mfdcr'
make[1]: *** [arch/powerpc/boot/44x.o] Error 1
The following patch introduces additional CFLAGS for the 4xx specific
files and fixes the kernel compile.
Signed-off-by: Josh Boyer <jwboyer@linux.vnet.ibm.com>
---
arch/powerpc/boot/Makefile | 3 +++
1 file changed, 3 insertions(+)
--- linux-2.6.orig/arch/powerpc/boot/Makefile
+++ linux-2.6/arch/powerpc/boot/Makefile
@@ -33,6 +33,9 @@ endif
BOOTCFLAGS += -I$(obj) -I$(srctree)/$(obj)
+$(obj)/44x.o: BOOTCFLAGS += -Wa,-mbooke
+$(obj)/ebony.o: BOOTCFLAGS += -Wa,-mbooke
+
zlib := inffast.c inflate.c inftrees.c
zlibheader := inffast.h inffixed.h inflate.h inftrees.h infutil.h
zliblinuxheader := zlib.h zconf.h zutil.h
^ permalink raw reply
* Re: [PATCH] ibm_emac: Correctly detect old link speed
From: Stefan Roese @ 2007-05-16 18:44 UTC (permalink / raw)
To: Eugene Surovegin; +Cc: netdev, linuxppc-dev
In-Reply-To: <20070516173002.GA22331@gate.ebshome.net>
On Wednesday 16 May 2007, Eugene Surovegin wrote:
> On Wed, May 16, 2007 at 01:00:08PM +0200, Stefan Roese wrote:
> > This patch fixes a bug where the link speed change was not
> > detected correctly. This occured on a 440SPe (EMAC4) system
> > where the old link speed was 100Mbps and the new link speed
> > is 1000Mbps.
>
> Good catch, Stefan. Unfortunately, I have to NACK your patch - you
> broke non EMAC4 builds.
Yes, you're right of course.
> Correct fix is just to remove EMAC_MR1_MF_1000GPCS from the first
> if condition.
Yep.
> I'll send correct fix shortly along with other queued patches.
Thanks.
Best regards,
Stefan
^ permalink raw reply
* [PATCH] powerpc: fix #endif comment
From: Jon Tollefson @ 2007-05-16 18:43 UTC (permalink / raw)
To: linuxppc-dev
Fix up comment on #endif to match #if.
Signed-off-by: Jon Tollefson <kniht@linux.vnet.ibm.com>
----
hash_utils_64.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/mm/hash_utils_64.c b/arch/powerpc/mm/hash_utils_64.c
index 028ba4e..4f2f453 100644
--- a/arch/powerpc/mm/hash_utils_64.c
+++ b/arch/powerpc/mm/hash_utils_64.c
@@ -430,7 +430,7 @@ static void __init htab_finish_init(void)
make_bl(ht64_call_hpte_insert2, ppc_md.hpte_insert);
make_bl(ht64_call_hpte_remove, ppc_md.hpte_remove);
make_bl(ht64_call_hpte_updatepp, ppc_md.hpte_updatepp);
-#endif /* CONFIG_PPC_64K_PAGES */
+#endif /* CONFIG_PPC_HAS_HASH_64K */
make_bl(htab_call_hpte_insert1, ppc_md.hpte_insert);
make_bl(htab_call_hpte_insert2, ppc_md.hpte_insert);
@@ -837,7 +837,7 @@ void hash_preload(struct mm_struct *mm, unsigned long ea,
if (mm->context.user_psize == MMU_PAGE_64K)
__hash_page_64K(ea, access, vsid, ptep, trap, local);
else
-#endif /* CONFIG_PPC_64K_PAGES */
+#endif /* CONFIG_PPC_HAS_HASH_64K */
__hash_page_4K(ea, access, vsid, ptep, trap, local);
local_irq_restore(flags);
^ permalink raw reply related
* [PATCH] powerpc: move common code out of if/else
From: Jon Tollefson @ 2007-05-16 18:42 UTC (permalink / raw)
To: linuxppc-dev
Move common code out of if/else.
Signed-off-by: Jon Tollefson <kniht@linux.vnet.ibm.com>
----
hash_native_64.c | 3 +--
1 files changed, 1 insertion(+), 2 deletions(-)
diff --git a/arch/powerpc/mm/hash_native_64.c b/arch/powerpc/mm/hash_native_64.c
index 4a20d89..bb76814 100644
--- a/arch/powerpc/mm/hash_native_64.c
+++ b/arch/powerpc/mm/hash_native_64.c
@@ -233,15 +233,14 @@ static long native_hpte_updatepp(unsigned long slot, unsigned long newpp,
/* Even if we miss, we need to invalidate the TLB */
if (!HPTE_V_COMPARE(hpte_v, want_v) || !(hpte_v & HPTE_V_VALID)) {
DBG_LOW(" -> miss\n");
- native_unlock_hpte(hptep);
ret = -1;
} else {
DBG_LOW(" -> hit\n");
/* Update the HPTE */
hptep->r = (hptep->r & ~(HPTE_R_PP | HPTE_R_N)) |
(newpp & (HPTE_R_PP | HPTE_R_N | HPTE_R_C));
- native_unlock_hpte(hptep);
}
+ native_unlock_hpte(hptep);
/* Ensure it is out of the tlb too. */
tlbie(va, psize, local);
^ permalink raw reply related
* Re: [i2c] [PATCH] Make i2c-mpc driver use i2c_add_numbered_adapter
From: Grant Likely @ 2007-05-16 18:38 UTC (permalink / raw)
To: Jean Delvare; +Cc: rtc-linux, James Chapman, David Brownell, linuxppc-dev, i2c
In-Reply-To: <20070516202520.3c6c5280@hyperion.delvare>
On 5/16/07, Jean Delvare <khali@linux-fr.org> wrote:
> On Tue, 15 May 2007 09:05:20 -0700, David Brownell wrote:
> > On Tuesday 15 May 2007, Grant Likely wrote:
> > >
> > > Take another look; this is a funny quirk of the driver. The
> > > assignment is 'i2c->adap = mpc_ops'; not 'i2c->adap = &mpc_ops'. And
> > > in struct mpc_i2c, the field is declared as 'struct i2c_adapter adap',
> > > not 'struct i2c_adapter *adap'. The driver instance gets a copy of
> > > the mpc_ops structure to initialize it, not a pointer to the staticly
> > > defined structure. I got bitten by the same thing when I was looking
> > > at the code.
> >
> > I see -- you're right. That "template" idiom is a good one to get
> > rid of, FWIW ... not only is it confusing, but it also wastes space.
>
> Well, maybe you can submit a patch fixing this one?
Heh, oops.
I had replied to David saying that I would do this bit; but I forgot
to cc the list.
I'll take care of this.
Cheers,
g.
--
Grant Likely, B.Sc. P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* Re: [i2c] [PATCH] Make i2c-mpc driver use i2c_add_numbered_adapter
From: Jean Delvare @ 2007-05-16 18:25 UTC (permalink / raw)
To: David Brownell; +Cc: rtc-linux, James Chapman, linuxppc-dev, i2c
In-Reply-To: <200705150905.21559.david-b@pacbell.net>
On Tue, 15 May 2007 09:05:20 -0700, David Brownell wrote:
> On Tuesday 15 May 2007, Grant Likely wrote:
> >
> > Take another look; this is a funny quirk of the driver. The
> > assignment is 'i2c->adap = mpc_ops'; not 'i2c->adap = &mpc_ops'. And
> > in struct mpc_i2c, the field is declared as 'struct i2c_adapter adap',
> > not 'struct i2c_adapter *adap'. The driver instance gets a copy of
> > the mpc_ops structure to initialize it, not a pointer to the staticly
> > defined structure. I got bitten by the same thing when I was looking
> > at the code.
>
> I see -- you're right. That "template" idiom is a good one to get
> rid of, FWIW ... not only is it confusing, but it also wastes space.
Well, maybe you can submit a patch fixing this one?
--
Jean Delvare
^ permalink raw reply
* Re: PS3 restart crash, SCSI cache sync
From: Geoff Levand @ 2007-05-16 18:07 UTC (permalink / raw)
To: Edward Strong; +Cc: linuxppc-dev
In-Reply-To: <29744.81.170.114.242.1179319943.squirrel@onkeh.net>
Hi.
Edward Strong wrote:
> I've had this problem for a while but I waited until the 1.3 release kit
> emerged before raising this, unfortunately it has not resolved my problem.
>
> When I reboot the PS3, the last thing to be displayed is:
Please send this kind of PS3 specific post to the cbe-oss-dev mailing
list next time:
cbe-oss-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/cbe-oss-dev
> Synchronizing SCSI cache for disk sda
> Synchronizing SCSI cache for disk sda
>
> Then I get a full hardware crash and have to hit the power switch at the
> back.
I guess that is not true. The polling code for the vuart wasn't working
properly so it was just spinning. Please press the power button for about 10 sec.
The HV will gain control and shutdown the lpar.
If I just do a shutdown, this works fine. This error is
> reproducible running both Gentoo and FC6. I am using a 120gb Fujitsu
> drive. Does anyone know why this might be happening?
I just added power button support to ps3-linux.git the other day. Either update
to that, or backport the fix to your kernel.
-Geoff
^ permalink raw reply
* Re: [PATCH 5/5] PCI fixes for the MPC8641 Rev 2.0 silicon and Rev 1.02 hardware
From: Wade Farnsworth @ 2007-05-16 18:06 UTC (permalink / raw)
To: Jon Loeliger; +Cc: linuxppc-dev
In-Reply-To: <1179333883.7018.20.camel@ld0161-tx32>
On Wed, 2007-05-16 at 11:44 -0500, Jon Loeliger wrote:
> On Tue, 2007-05-15 at 11:50, Wade Farnsworth wrote:
> > +static void __devinit early_mpc86xx_pcie(struct pci_dev *dev)
> > +{
> > + dev->class = PCI_CLASS_BRIDGE_PCI << 8 | 0x1;
> > +}
>
> What'd we decide on that 0x1 in there?
>
> Thanks,
> jdl
>
>
I originally thought that it the 0x1 was necessary, but it was pointed
out to me that it should not be.
If I remove the 0x1 I get some I/O resource allocation failures on the
P2P bridge and its child devices. I'm currently investigating what the
cause of this is.
--Wade
^ permalink raw reply
* Re: New version of the device tree aware EMAC driver
From: Valentine Barshak @ 2007-05-16 18:03 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <464B38A9.9000402@ru.mvista.com>
Valentine Barshak wrote:
> David Gibson wrote:
>
>> I've made a few more tiny tweaks to BenH's rewritten device-tree based
>> 4xx EMAC driver. The main change is that it now no longer requires
>> 'device_type', just 'compatible' to be set in the ZMII and MAL device
>> nodes when probing. This works better with current thinking on
>> flattened device trees which discourages creating new device_type
>> values unless there is a clear use for a new device class binding.
>>
>> The patch can be obtained from:
>>
>> http://ozlabs.org/~dgibson/home/emac/powerpc-emac-new-20070516.patch
>>
>>
>>
> In __emac_mdio_read and __emac_mdio_write functions:
>
> + if (!emac_has_feature(dev, EMAC_FTR_STACR_OC_INVERT))
> + r |= EMAC_STACR_OC;
>
> should be
>
> + if (emac_has_feature(dev, EMAC_FTR_STACR_OC_INVERT))
> + r |= EMAC_STACR_OC;
>
> Thanks.
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
>
With the above 2 fixes (and Marvell 88E1111 Ethernet PHY support added)
seems to work fine on Sequoia PPC440EPx,
thanks.
^ permalink raw reply
* Re: MPC5200B memory performance
From: Matthias Fechner @ 2007-05-16 18:03 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <DD39B5C3F4963040ADC9768BE7E430CB01EB1FEF@is-hdq-exchange.marel.net>
Hello Daniel,
* Daniel Schnell <daniel.schnell@marel.com> [15-05-07 11:22]:
> I get the following values on my board:
my result is:
Test (10000) memcpy of sizes (1024) ....
10000 memcpy. Time per memcpy: 1814 [nsec] (564 MB/sec)
finished.
Test (10000) memcpy of sizes (2048) ....
10000 memcpy. Time per memcpy: 3433 [nsec] (596 MB/sec)
finished.
Test (10000) memcpy of sizes (4096) ....
10000 memcpy. Time per memcpy: 6687 [nsec] (612 MB/sec)
finished.
Test (10000) memcpy of sizes (8192) ....
10000 memcpy. Time per memcpy: 21454 [nsec] (381 MB/sec)
finished.
Test (10000) memcpy of sizes (16384) ....
10000 memcpy. Time per memcpy: 205551 [nsec] (79 MB/sec)
finished.
Test (1000) memcpy of sizes (32768) ....
1000 memcpy. Time per memcpy: 379875 [nsec] (86 MB/sec)
finished.
Test (1000) memcpy of sizes (51200) ....
1000 memcpy. Time per memcpy: 588792 [nsec] (86 MB/sec)
finished.
Test (1000) memcpy of sizes (102400) ....
1000 memcpy. Time per memcpy: 1126511 [nsec] (90 MB/sec)
finished.
Test (100) memcpy of sizes (1048576) ....
100 memcpy. Time per memcpy: 11307890 [nsec] (92 MB/sec)
finished.
Test (10) memcpy of sizes (10485760) ....
10 memcpy. Time per memcpy: 120783600 [nsec] (86 MB/sec)
finished.
Test (5) memcpy of sizes (52428800) ....
5 memcpy. Time per memcpy: 673867800 [nsec] (77 MB/sec)
finished.
Best regards,
Matthias
--
"Programming today is a race between software engineers striving to
build bigger and better idiot-proof programs, and the universe trying to
produce bigger and better idiots. So far, the universe is winning." --
Rich Cook
^ permalink raw reply
* Re: [PATCH 2/5] Add legacy devices to mpc8641_hpcn.dts
From: Wade Farnsworth @ 2007-05-16 17:59 UTC (permalink / raw)
To: Jon Loeliger; +Cc: linuxppc-dev
In-Reply-To: <1179333421.7018.17.camel@ld0161-tx32>
On Wed, 2007-05-16 at 11:37 -0500, Jon Loeliger wrote:
> On Tue, 2007-05-15 at 11:27, Wade Farnsworth wrote:
<snip>
> > + isa@f0 {
> > + device_type = "isa";
> > #interrupt-cells = <2>;
>
> Yea, thanks. BTW, will this be sufficient to now identify the
> primary controller and not doink with the legacy IO ports now?
> Or is that being handled differently somehow?
I'm not sure what you're referring to here. Can you clarify this a
little?
>
> > + #size-cells = <1>;
> > + #address-cells = <2>;
> > + reg = <f000 0 0 0 0>;
> > + ranges = <1 0 01000000 0 0 00001000>;
> > + interrupt-parent = <4d0>;
>
> That 4d0 should likely be &i8259.
>
> > + 8042@60 {
> > + device_type = "8042";
> > + reg = <1 60 1 1 64 1>;
> > + interrupts = <1 3 c 3>;
> > + interrupt-parent = <4d0>;
> > + };
>
> Ditto.
Yes, of course. Thanks.
>
> > + rtc@70 {
> > + device_type = "rtc";
> > + reg = <1 70 2>;
> > + };
>
> Is "rtc" a standard OF device, or are we making up a
> new thing that should be documented in booting-with-OF.txt ?
> And is the plan to somehow use this entry in the future?
It is my understanding that "rtc" is a standard OF device. Can anybody
confirm this?
This could be used in the platform-specific RTC code to get the ports
from the device tree. Currently, however, I simply use RTC_PORT(x) from
asm/mc146818rtc.h. Is it preferable to use the device tree here?
--Wade
>
> Thanks,
> jdl
>
>
^ permalink raw reply
* Re: Slab allocators: Define common size limitations
From: Christoph Lameter @ 2007-05-16 17:41 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: linux-mm, Andrew Morton, Linux Kernel Development,
Linux/PPC Development
In-Reply-To: <Pine.LNX.4.62.0705160855470.24080@pademelon.sonytel.be>
On Wed, 16 May 2007, Geert Uytterhoeven wrote:
> On Tue, 15 May 2007, Christoph Lameter wrote:
> > So define a common maximum size for kmalloc. For conveniences sake
> > we use the maximum size ever supported which is 32 MB. We limit the maximum
> > size to a lower limit if MAX_ORDER does not allow such large allocations.
>
> What are the changes a large allocation will actually succeed?
> Is there an alignment rule for large allocations?
>
> E.g. for one of the PS3 drivers I need a physically contiguous 256 KiB-aligned
> block of 256 KiB. Currently I'm using __alloc_bootmem() for that, but maybe
> kmalloc() becomes a suitable alternative now?
The chance of succeeding drops with the time that the system has been
running. Typically these large allocs are used when the system is brought
up. Maybe we will be able to successfully allocate these even after
memory has gotten significant use when Mel's antifrag/defrag work has
progressed more.
^ permalink raw reply
* Re: [PATCH] ibm_emac: Correctly detect old link speed
From: Eugene Surovegin @ 2007-05-16 17:30 UTC (permalink / raw)
To: Stefan Roese; +Cc: netdev, linuxppc-dev
In-Reply-To: <200705161300.08521.sr@denx.de>
On Wed, May 16, 2007 at 01:00:08PM +0200, Stefan Roese wrote:
> This patch fixes a bug where the link speed change was not
> detected correctly. This occured on a 440SPe (EMAC4) system
> where the old link speed was 100Mbps and the new link speed
> is 1000Mbps.
Good catch, Stefan. Unfortunately, I have to NACK your patch - you
broke non EMAC4 builds.
Correct fix is just to remove EMAC_MR1_MF_1000GPCS from the first
if condition.
I'll send correct fix shortly along with other queued patches.
--
Eugene
^ permalink raw reply
* Re: your mail
From: Bob Picco @ 2007-05-16 17:24 UTC (permalink / raw)
To: Olof Johansson
Cc: linux-kernel, Bob Picco, linuxppc-dev, Andrew Morton, johnrose
In-Reply-To: <20070516171100.GA25056@lixom.net>
Olof Johansson wrote: [Wed May 16 2007, 01:11:00PM EDT]
> On Wed, May 16, 2007 at 11:43:41AM -0500, Linas Vepstas wrote:
> > On Wed, May 16, 2007 at 09:30:46AM -0400, Bob Picco wrote:
> > > Subject: Re: 2.6.22-rc1-mm1 powerpc build breakage
> > >
> > > /usr/src/linux-2.6.22-rc1-mm1/drivers/pci/hotplug/rpadlpar_sysfs.c:132: error: unknown field `subsys' specified in initializer
> > > /usr/src/linux-2.6.22-rc1-mm1/drivers/pci/hotplug/rpadlpar_sysfs.c:132: warning: initialization from incompatible pointer type
> > > make[4]: *** [drivers/pci/hotplug/rpadlpar_sysfs.o] Error 1
> > > make[3]: *** [drivers/pci/hotplug] Error 2
> > > make[2]: *** [drivers/pci] Error 2
> > > make[1]: *** [drivers] Error 2
> > > make: *** [_all] Error 2
> >
> > John Rose is working to fix this "real soon now".
>
> Do you mean the fix Al Viro posted yesterday?
>
> http://patchwork.ozlabs.org/linuxppc/patch?id=11177
>
>
> -Olof
Missed that patch.
thanks,
bob
^ permalink raw reply
* Re: your mail
From: Olof Johansson @ 2007-05-16 17:11 UTC (permalink / raw)
To: Linas Vepstas
Cc: linuxppc-dev, Andrew Morton, johnrose, linux-kernel, Bob Picco
In-Reply-To: <20070516164341.GA7008@austin.ibm.com>
On Wed, May 16, 2007 at 11:43:41AM -0500, Linas Vepstas wrote:
> On Wed, May 16, 2007 at 09:30:46AM -0400, Bob Picco wrote:
> > Subject: Re: 2.6.22-rc1-mm1 powerpc build breakage
> >
> > /usr/src/linux-2.6.22-rc1-mm1/drivers/pci/hotplug/rpadlpar_sysfs.c:132: error: unknown field `subsys' specified in initializer
> > /usr/src/linux-2.6.22-rc1-mm1/drivers/pci/hotplug/rpadlpar_sysfs.c:132: warning: initialization from incompatible pointer type
> > make[4]: *** [drivers/pci/hotplug/rpadlpar_sysfs.o] Error 1
> > make[3]: *** [drivers/pci/hotplug] Error 2
> > make[2]: *** [drivers/pci] Error 2
> > make[1]: *** [drivers] Error 2
> > make: *** [_all] Error 2
>
> John Rose is working to fix this "real soon now".
Do you mean the fix Al Viro posted yesterday?
http://patchwork.ozlabs.org/linuxppc/patch?id=11177
-Olof
^ permalink raw reply
* Re: New version of the device tree aware EMAC driver
From: Valentine Barshak @ 2007-05-16 17:00 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <20070516032630.GC19127@localhost.localdomain>
David Gibson wrote:
> I've made a few more tiny tweaks to BenH's rewritten device-tree based
> 4xx EMAC driver. The main change is that it now no longer requires
> 'device_type', just 'compatible' to be set in the ZMII and MAL device
> nodes when probing. This works better with current thinking on
> flattened device trees which discourages creating new device_type
> values unless there is a clear use for a new device class binding.
>
> The patch can be obtained from:
>
> http://ozlabs.org/~dgibson/home/emac/powerpc-emac-new-20070516.patch
>
>
In __emac_mdio_read and __emac_mdio_write functions:
+ if (!emac_has_feature(dev, EMAC_FTR_STACR_OC_INVERT))
+ r |= EMAC_STACR_OC;
should be
+ if (emac_has_feature(dev, EMAC_FTR_STACR_OC_INVERT))
+ r |= EMAC_STACR_OC;
Thanks.
^ 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