* [linux kernel 2.6.19] ethernet driver for Marvell bridge GT-64260
From: joachim.bader @ 2007-08-31 15:58 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 1364 bytes --]
Hello,
I am porting linux kernel 2.6.19 on a platform based on PPC750FX together
with a Marvell GT64260.
I use a patched 643xx driver which is back ported to 64260 by Steven J.
Hill.
I have ethernet now up and running, but only if I switch debug on, which
generates a big bunch of screen messages.
As soon as I switch debug off, I get the message "Virtual device %s asks
to queue packet!" on every transmission request.
This happens on ping an other system.
Has anyone experience in such an event? Is there anything how I can speed
up performance with the 64260?
Is there a similar problem known with the 64360?
Thanks in advance.
Joachim
_______________________________________________________________________________________________________________________
Der Inhalt dieser E-Mail ist für den Absender rechtlich nicht verbindlich.
Informieren Sie uns bitte, wenn Sie diese E-Mail fälschlicherweise erhalten haben (Fax: +49-69-5805-1399). Bitte löschen Sie in diesem Fall die Nachricht. Jede Form der weiteren Benutzung ist untersagt.
The content of this e-mail is not legally binding upon the sender.
If this e-mail was transmitted to you by error, then please inform us accordingly (Fax: +49-69-5805-1399). In such case you are requested to erase the message. Any use of such e-mail message is strictly prohibited.
[-- Attachment #2: Type: text/html, Size: 2274 bytes --]
^ permalink raw reply
* Re: [PATCH 1/3] bootwrapper: In cuImage, print message for ENET devices not found in tree
From: Grant Likely @ 2007-08-31 15:29 UTC (permalink / raw)
To: Grant Likely, linuxppc-dev, Scott Wood
In-Reply-To: <20070831042536.GL19271@localhost.localdomain>
On 8/30/07, David Gibson <david@gibson.dropbear.id.au> wrote:
> Sorry, I was misleading. Scott moved the printf() into the if (devp)
> as you do, but *didn't* add the alternative warning message in the
> else.
>
> The reason for this is that Planetcore only supplies the first MAC
> address, and the bootwrapper must derive the addresses for all the
> ENETs from that. That in turn means it is much more convenient to
> call fixup_mac_addresses() with more addresses than there are
> ethernets, so we don't want a warning message when that happens.
Okay, that makes sense. I just found Scott's patch which does the
same, so I'll drop my version.
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* Re: [PATCH 1/7] Generic bitbanged MDIO library
From: Scott Wood @ 2007-08-31 15:16 UTC (permalink / raw)
To: Jeff Garzik; +Cc: netdev, Paul Mackerras, linuxppc-dev
In-Reply-To: <46D81638.6050509@pobox.com>
On Fri, Aug 31, 2007 at 09:23:04AM -0400, Jeff Garzik wrote:
> I cannot ACK this, nor do I want to see it merged, until users appear
> and have been reviewed alongside this. I do not see any fs_enet patches
> that actually use this.
The fs_enet patchset does use it in mii-bitbang.c, in patch 6/7 (or 7/8
in the revised patchset). I'll also be using it on the ep8248e board
(which is why I factored it out), which I'll attach below.
> * the delay (where you call ndelay()) is not guaranteed without a flush
> of some sort
Hmm... I'm inclined to push that into the client's implementation of set
mdc/data, primarily because there's no get mdc to do a read-back
generically.
> * how widely applicable is this "generic" library?
It implements MDIO as described in the ethernet specification; there
should be no implementation dependencies.
> have you converted any non-embedded drivers over to it?
No; most hardware doesn't need bitbanging. Sunhme does, but I don't have
hardware to test a conversion.
Here's the ep8248e user of the bitbang code:
/*
* Embedded Planet EP8248E support
*
* Copyright 2007 Freescale Semiconductor, Inc.
* Author: Scott Wood <scottwood@freescale.com>
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of version 2 of the GNU General Public License as
* published by the Free Software Foundation.
*/
#include <linux/init.h>
#include <linux/interrupt.h>
#include <linux/fsl_devices.h>
#include <linux/mdio-bitbang.h>
#include <linux/of_platform.h>
#include <asm/io.h>
#include <asm/cpm2.h>
#include <asm/udbg.h>
#include <asm/machdep.h>
#include <asm/time.h>
#include <asm/mpc8260.h>
#include <sysdev/fsl_soc.h>
#include <sysdev/cpm2_pic.h>
#include "pq2.h"
static u8 __iomem *ep8248e_bcsr;
static struct device_node *ep8248e_bcsr_node;
#define BCSR7_SCC2_ENABLE 0x10
#define BCSR8_PHY1_ENABLE 0x80
#define BCSR8_PHY1_POWER 0x40
#define BCSR8_PHY2_ENABLE 0x20
#define BCSR8_PHY2_POWER 0x10
#define BCSR8_MDIO_READ 0x04
#define BCSR8_MDIO_CLOCK 0x02
#define BCSR8_MDIO_DATA 0x01
#define BCSR9_USB_ENABLE 0x80
#define BCSR9_USB_POWER 0x40
#define BCSR9_USB_HOST 0x20
#define BCSR9_USB_FULL_SPEED_TARGET 0x10
static void __init ep8248_pic_init(void)
{
struct device_node *np = of_find_compatible_node(NULL, NULL, "fsl,pq2-pic");
if (!np) {
printk(KERN_ERR "PIC init: can not find cpm-pic node\n");
return;
}
cpm2_pic_init(np);
of_node_put(np);
}
static void ep8248e_set_mdc(struct mdio_bitbang_ctrl *ctrl, int level)
{
if (level)
setbits8(&ep8248e_bcsr[8], BCSR8_MDIO_CLOCK);
else
clrbits8(&ep8248e_bcsr[8], BCSR8_MDIO_CLOCK);
/* Flush the write before delaying. */
in_8(&ep8248e_bcsr[8]);
}
static void ep8248e_set_mdio_dir(struct mdio_bitbang_ctrl *ctrl, int output)
{
if (output)
clrbits8(&ep8248e_bcsr[8], BCSR8_MDIO_READ);
else
setbits8(&ep8248e_bcsr[8], BCSR8_MDIO_READ);
/* Flush the write before delaying. */
in_8(&ep8248e_bcsr[8]);
}
static void ep8248e_set_mdio_data(struct mdio_bitbang_ctrl *ctrl, int data)
{
if (data)
setbits8(&ep8248e_bcsr[8], BCSR8_MDIO_DATA);
else
clrbits8(&ep8248e_bcsr[8], BCSR8_MDIO_DATA);
/* Flush the write before delaying. */
in_8(&ep8248e_bcsr[8]);
}
static int ep8248e_get_mdio_data(struct mdio_bitbang_ctrl *ctrl)
{
return in_8(&ep8248e_bcsr[8]) & BCSR8_MDIO_DATA;
}
static struct mdio_bitbang_ops ep8248e_mdio_ops = {
.set_mdc = ep8248e_set_mdc,
.set_mdio_dir = ep8248e_set_mdio_dir,
.set_mdio_data = ep8248e_set_mdio_data,
.get_mdio_data = ep8248e_get_mdio_data,
.owner = THIS_MODULE,
};
static struct mdio_bitbang_ctrl ep8248e_mdio_ctrl = {
.ops = &ep8248e_mdio_ops,
};
static int __devinit ep8248e_mdio_probe(struct of_device *ofdev,
const struct of_device_id *match)
{
struct mii_bus *bus;
struct resource res;
int ret, i;
if (of_get_parent(ofdev->node) != ep8248e_bcsr_node)
return -ENODEV;
ret = of_address_to_resource(ofdev->node, 0, &res);
if (ret)
return ret;
bus = alloc_mdio_bitbang(&ep8248e_mdio_ctrl);
if (!bus)
return -ENOMEM;
bus->phy_mask = 0;
bus->irq = kmalloc(sizeof(int) * PHY_MAX_ADDR, GFP_KERNEL);
for (i = 0; i < PHY_MAX_ADDR; i++)
bus->irq[i] = -1;
bus->name = "ep8248e-mdio-bitbang";
bus->dev = &ofdev->dev;
bus->id = res.start;
return mdiobus_register(bus);
}
static int ep8248e_mdio_remove(struct of_device *ofdev)
{
BUG();
return 0;
}
static struct of_device_id ep8248e_mdio_match[] = {
{
.compatible = "fsl,ep8248e-mdio-bitbang",
},
{},
};
static struct of_platform_driver ep8248e_mdio_driver = {
.name = "ep8248e-mdio-bitbang",
.match_table = ep8248e_mdio_match,
.probe = ep8248e_mdio_probe,
.remove = ep8248e_mdio_remove,
};
struct cpm_pin {
int port, pin, flags;
};
static struct cpm_pin ep8248_pins[] = {
/* SMC1 */
{2, 4, CPM_PIN_INPUT | CPM_PIN_PRIMARY},
{2, 5, CPM_PIN_OUTPUT | CPM_PIN_PRIMARY},
/* SCC1 */
{2, 14, CPM_PIN_INPUT | CPM_PIN_PRIMARY},
{2, 15, CPM_PIN_INPUT | CPM_PIN_PRIMARY},
{3, 29, CPM_PIN_OUTPUT | CPM_PIN_PRIMARY},
{3, 30, CPM_PIN_OUTPUT | CPM_PIN_SECONDARY},
{3, 31, CPM_PIN_INPUT | CPM_PIN_PRIMARY},
/* FCC1 */
{0, 14, CPM_PIN_INPUT | CPM_PIN_PRIMARY},
{0, 15, CPM_PIN_INPUT | CPM_PIN_PRIMARY},
{0, 16, CPM_PIN_INPUT | CPM_PIN_PRIMARY},
{0, 17, CPM_PIN_INPUT | CPM_PIN_PRIMARY},
{0, 18, CPM_PIN_OUTPUT | CPM_PIN_PRIMARY},
{0, 19, CPM_PIN_OUTPUT | CPM_PIN_PRIMARY},
{0, 20, CPM_PIN_OUTPUT | CPM_PIN_PRIMARY},
{0, 21, CPM_PIN_OUTPUT | CPM_PIN_PRIMARY},
{0, 26, CPM_PIN_INPUT | CPM_PIN_SECONDARY},
{0, 27, CPM_PIN_INPUT | CPM_PIN_SECONDARY},
{0, 28, CPM_PIN_OUTPUT | CPM_PIN_SECONDARY},
{0, 29, CPM_PIN_OUTPUT | CPM_PIN_SECONDARY},
{0, 30, CPM_PIN_INPUT | CPM_PIN_SECONDARY},
{0, 31, CPM_PIN_INPUT | CPM_PIN_SECONDARY},
{2, 21, CPM_PIN_INPUT | CPM_PIN_PRIMARY},
{2, 22, CPM_PIN_INPUT | CPM_PIN_PRIMARY},
/* FCC2 */
{1, 18, CPM_PIN_INPUT | CPM_PIN_PRIMARY},
{1, 19, CPM_PIN_INPUT | CPM_PIN_PRIMARY},
{1, 20, CPM_PIN_INPUT | CPM_PIN_PRIMARY},
{1, 21, CPM_PIN_INPUT | CPM_PIN_PRIMARY},
{1, 22, CPM_PIN_OUTPUT | CPM_PIN_PRIMARY},
{1, 23, CPM_PIN_OUTPUT | CPM_PIN_PRIMARY},
{1, 24, CPM_PIN_OUTPUT | CPM_PIN_PRIMARY},
{1, 25, CPM_PIN_OUTPUT | CPM_PIN_PRIMARY},
{1, 26, CPM_PIN_INPUT | CPM_PIN_PRIMARY},
{1, 27, CPM_PIN_INPUT | CPM_PIN_PRIMARY},
{1, 28, CPM_PIN_INPUT | CPM_PIN_PRIMARY},
{1, 29, CPM_PIN_OUTPUT | CPM_PIN_SECONDARY},
{1, 30, CPM_PIN_INPUT | CPM_PIN_PRIMARY},
{1, 31, CPM_PIN_OUTPUT | CPM_PIN_PRIMARY},
{2, 18, CPM_PIN_INPUT | CPM_PIN_PRIMARY},
{2, 19, CPM_PIN_INPUT | CPM_PIN_PRIMARY},
/* I2C */
{4, 14, CPM_PIN_INPUT | CPM_PIN_SECONDARY},
{4, 15, CPM_PIN_INPUT | CPM_PIN_SECONDARY},
/* USB */
{2, 10, CPM_PIN_INPUT | CPM_PIN_PRIMARY},
{2, 11, CPM_PIN_INPUT | CPM_PIN_PRIMARY},
{2, 20, CPM_PIN_OUTPUT | CPM_PIN_PRIMARY},
{2, 24, CPM_PIN_INPUT | CPM_PIN_PRIMARY},
{3, 23, CPM_PIN_OUTPUT | CPM_PIN_PRIMARY},
{3, 24, CPM_PIN_OUTPUT | CPM_PIN_PRIMARY},
{3, 25, CPM_PIN_INPUT | CPM_PIN_PRIMARY},
};
static void __init init_ioports(void)
{
int i;
for (i = 0; i < ARRAY_SIZE(ep8248_pins); i++) {
struct cpm_pin *pin = &ep8248_pins[i];
cpm2_set_pin(pin->port, pin->pin, pin->flags);
}
cpm2_smc_clk_setup(CPM_CLK_SMC1, CPM_BRG7);
cpm2_clk_setup(CPM_CLK_SCC1, CPM_BRG1, CPM_CLK_RX);
cpm2_clk_setup(CPM_CLK_SCC1, CPM_BRG1, CPM_CLK_TX);
cpm2_clk_setup(CPM_CLK_SCC3, CPM_CLK8, CPM_CLK_TX); /* USB */
cpm2_clk_setup(CPM_CLK_FCC1, CPM_CLK11, CPM_CLK_RX);
cpm2_clk_setup(CPM_CLK_FCC1, CPM_CLK10, CPM_CLK_TX);
cpm2_clk_setup(CPM_CLK_FCC2, CPM_CLK13, CPM_CLK_RX);
cpm2_clk_setup(CPM_CLK_FCC2, CPM_CLK14, CPM_CLK_TX);
}
static void __init ep8248_setup_arch(void)
{
if (ppc_md.progress)
ppc_md.progress("ep8248_setup_arch()", 0);
cpm2_reset();
/* When this is set, snooping CPM DMA from RAM causes
* machine checks. See erratum SIU18.
*/
clrbits32(&cpm2_immr->im_siu_conf.siu_82xx.sc_bcr, MPC82XX_BCR_PLDP);
ep8248e_bcsr_node =
of_find_compatible_node(NULL, NULL, "fsl,ep8248e-bcsr");
if (!ep8248e_bcsr_node) {
printk(KERN_ERR "No bcsr in device tree\n");
return;
}
ep8248e_bcsr = of_iomap(ep8248e_bcsr_node, 0);
if (!ep8248e_bcsr) {
printk(KERN_ERR "Cannot map BCSR registers\n");
return;
}
setbits8(&ep8248e_bcsr[7], BCSR7_SCC2_ENABLE);
setbits8(&ep8248e_bcsr[8], BCSR8_PHY1_ENABLE | BCSR8_PHY1_POWER |
BCSR8_PHY2_ENABLE | BCSR8_PHY2_POWER);
init_ioports();
if (ppc_md.progress)
ppc_md.progress("ep8248_setup_arch(), finish", 0);
}
static struct of_device_id __initdata of_bus_ids[] = {
{ .name = "soc", },
{ .name = "cpm", },
{ .compatible = "fsl,pq2-chipselect", },
{ .compatible = "fsl,ep8248e-bcsr", },
{},
};
static int __init declare_of_platform_devices(void)
{
if (!machine_is(ep8248))
return 0;
of_platform_bus_probe(NULL, of_bus_ids, NULL);
of_register_platform_driver(&ep8248e_mdio_driver);
return 0;
}
device_initcall(declare_of_platform_devices);
/*
* Called very early, device-tree isn't unflattened
*/
static int __init ep8248_probe(void)
{
unsigned long root = of_get_flat_dt_root();
return of_flat_dt_is_compatible(root, "fsl,ep8248e");
}
define_machine(ep8248)
{
.name = "Embedded Planet EP8248E",
.probe = ep8248_probe,
.setup_arch = ep8248_setup_arch,
.init_IRQ = ep8248_pic_init,
.get_irq = cpm2_get_irq,
.calibrate_decr = generic_calibrate_decr,
.restart = pq2_restart,
.progress = udbg_progress,
};
^ permalink raw reply
* Re: Section mismatch in 2.6.23-rc4
From: Josh Boyer @ 2007-08-31 14:41 UTC (permalink / raw)
Cc: linuxppc-dev
In-Reply-To: <20070831093211.3ad97687@weaponx.rchland.ibm.com>
On Fri, 31 Aug 2007 09:32:11 -0500
Josh Boyer <jwboyer@linux.vnet.ibm.com> wrote:
> On Fri, 31 Aug 2007 14:25:34 +0200
> "Hommel, Thomas (GE Indust, GE Fanuc)" <Thomas.Hommel@gefanuc.com>
> wrote:
>
> >
> > When compiling a kernel, I get the warnings below.
> > I am using ARCH=powerpc and 'make mpc8641_hpcn_defconfig', 'make
> > uImage'. This didn't appear in 2.6.22, but in
> > arch/powerpc/kernel/head_32.S and setup_32.c, the section info
> > apparently didn't change.
>
> Kumar Galak has a patch series that clean these warnings up for ppc32.
Er, that would be Kumar Gala. There I go, defaulting to IRC nicks
again.
josh
^ permalink raw reply
* Re: [PATCH 2.6.23] ibmebus: Prevent bus_id collisions
From: Joachim Fenkes @ 2007-08-31 14:34 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Thomas Q Klein, Paul Mackerras, Jan-Bernd Themann, LKML,
linuxppc-dev, Christoph Raisch, Paul Mackerras, Stefan Roscher
In-Reply-To: <200708302022.24167.arnd@arndb.de>
Hi, Arnd,
> The whole logic of dynamically adding and removing device is rather
bogus,
> and it prevents autoloading of device drivers. of_platform_make_bus_id
> is the function that is responsible for creating unique names over
there.
The plaintiff makes a valid point. How about a staging approach: We put
the patch as it is now into 2.6.23 so the problem is fixed, and I'll post
a "nice" version with autoloading support and a generic of_make_bus_id
function for 2.6.24. Agree?
Regards,
Joachim
^ permalink raw reply
* Re: Section mismatch in 2.6.23-rc4
From: Josh Boyer @ 2007-08-31 14:32 UTC (permalink / raw)
To: Hommel, Thomas (GE Indust, GE Fanuc); +Cc: linuxppc-dev, paulus
In-Reply-To: <62DDBB9E5E23CC4A929EE46F9427CEAF295F6F@BUDMLVEM04.e2k.ad.ge.com>
On Fri, 31 Aug 2007 14:25:34 +0200
"Hommel, Thomas (GE Indust, GE Fanuc)" <Thomas.Hommel@gefanuc.com>
wrote:
>
> When compiling a kernel, I get the warnings below.
> I am using ARCH=powerpc and 'make mpc8641_hpcn_defconfig', 'make
> uImage'. This didn't appear in 2.6.22, but in
> arch/powerpc/kernel/head_32.S and setup_32.c, the section info
> apparently didn't change.
Kumar Galak has a patch series that clean these warnings up for ppc32.
josh
^ permalink raw reply
* [PATCH 2/2] IB/ehca: SRQ fixes to enable IPoIB CM
From: Joachim Fenkes @ 2007-08-31 14:03 UTC (permalink / raw)
To: LinuxPPC-Dev, LKML, OF-General, Roland Dreier
Cc: Stefan Roscher, Christoph Raisch
In-Reply-To: <200708311601.42220.fenkes@de.ibm.com>
a) Report max_srq > 0 if SRQ is supported
b) Report "last wqe reached" event when base QP dies
Signed-off-by: Joachim Fenkes <fenkes@de.ibm.com>
---
drivers/infiniband/hw/ehca/ehca_hca.c | 10 +++++--
drivers/infiniband/hw/ehca/ehca_irq.c | 48 +++++++++++++++++++++-----------
2 files changed, 38 insertions(+), 20 deletions(-)
diff --git a/drivers/infiniband/hw/ehca/ehca_hca.c b/drivers/infiniband/hw/ehca/ehca_hca.c
index fc19ef9..cf22472 100644
--- a/drivers/infiniband/hw/ehca/ehca_hca.c
+++ b/drivers/infiniband/hw/ehca/ehca_hca.c
@@ -93,9 +93,13 @@ int ehca_query_device(struct ib_device *ibdev, struct ib_device_attr *props)
props->max_pd = min_t(int, rblock->max_pd, INT_MAX);
props->max_ah = min_t(int, rblock->max_ah, INT_MAX);
props->max_fmr = min_t(int, rblock->max_mr, INT_MAX);
- props->max_srq = 0;
- props->max_srq_wr = 0;
- props->max_srq_sge = 0;
+
+ if (EHCA_BMASK_GET(HCA_CAP_SRQ, shca->hca_cap)) {
+ props->max_srq = props->max_qp;
+ props->max_srq_wr = props->max_qp_wr;
+ props->max_srq_sge = 3;
+ }
+
props->max_pkeys = 16;
props->local_ca_ack_delay
= rblock->local_ca_ack_delay;
diff --git a/drivers/infiniband/hw/ehca/ehca_irq.c b/drivers/infiniband/hw/ehca/ehca_irq.c
index ee06d8b..a925ea5 100644
--- a/drivers/infiniband/hw/ehca/ehca_irq.c
+++ b/drivers/infiniband/hw/ehca/ehca_irq.c
@@ -175,41 +175,55 @@ error_data1:
}
-static void qp_event_callback(struct ehca_shca *shca, u64 eqe,
- enum ib_event_type event_type, int fatal)
+static void dispatch_qp_event(struct ehca_shca *shca, struct ehca_qp *qp,
+ enum ib_event_type event_type)
{
struct ib_event event;
- struct ehca_qp *qp;
- u32 token = EHCA_BMASK_GET(EQE_QP_TOKEN, eqe);
-
- read_lock(&ehca_qp_idr_lock);
- qp = idr_find(&ehca_qp_idr, token);
- read_unlock(&ehca_qp_idr_lock);
-
-
- if (!qp)
- return;
-
- if (fatal)
- ehca_error_data(shca, qp, qp->ipz_qp_handle.handle);
event.device = &shca->ib_device;
+ event.event = event_type;
if (qp->ext_type == EQPT_SRQ) {
if (!qp->ib_srq.event_handler)
return;
- event.event = fatal ? IB_EVENT_SRQ_ERR : event_type;
event.element.srq = &qp->ib_srq;
qp->ib_srq.event_handler(&event, qp->ib_srq.srq_context);
} else {
if (!qp->ib_qp.event_handler)
return;
- event.event = event_type;
event.element.qp = &qp->ib_qp;
qp->ib_qp.event_handler(&event, qp->ib_qp.qp_context);
}
+}
+
+static void qp_event_callback(struct ehca_shca *shca, u64 eqe,
+ enum ib_event_type event_type, int fatal)
+{
+ struct ehca_qp *qp;
+ u32 token = EHCA_BMASK_GET(EQE_QP_TOKEN, eqe);
+
+ read_lock(&ehca_qp_idr_lock);
+ qp = idr_find(&ehca_qp_idr, token);
+ read_unlock(&ehca_qp_idr_lock);
+
+ if (!qp)
+ return;
+
+ if (fatal)
+ ehca_error_data(shca, qp, qp->ipz_qp_handle.handle);
+
+ dispatch_qp_event(shca, qp, fatal && qp->ext_type == EQPT_SRQ ?
+ IB_EVENT_SRQ_ERR : event_type);
+
+ /*
+ * eHCA only processes one WQE at a time for SRQ base QPs,
+ * so the last WQE has been processed as soon as the QP enters
+ * error state.
+ */
+ if (fatal && qp->ext_type == EQPT_SRQBASE)
+ dispatch_qp_event(shca, qp, IB_EVENT_QP_LAST_WQE_REACHED);
return;
}
--
1.5.2
^ permalink raw reply related
* [PATCH 1/2] IB/ehca: fix Small QP regressions
From: Joachim Fenkes @ 2007-08-31 14:02 UTC (permalink / raw)
To: LinuxPPC-Dev, LKML, OF-General, Roland Dreier
Cc: Stefan Roscher, Christoph Raisch
In-Reply-To: <200708311601.42220.fenkes@de.ibm.com>
From: Stefan Roscher <stefan.roscher@de.ibm.com>
The new Small QP code had a few bugs that would also trigger for non-Small
QPs. Fix them.
Signed-off-by: Joachim Fenkes <fenkes@de.ibm.com>
---
drivers/infiniband/hw/ehca/ehca_qp.c | 10 ++++++----
drivers/infiniband/hw/ehca/ipz_pt_fn.c | 2 +-
2 files changed, 7 insertions(+), 5 deletions(-)
diff --git a/drivers/infiniband/hw/ehca/ehca_qp.c b/drivers/infiniband/hw/ehca/ehca_qp.c
index b178cba..84d435a 100644
--- a/drivers/infiniband/hw/ehca/ehca_qp.c
+++ b/drivers/infiniband/hw/ehca/ehca_qp.c
@@ -600,10 +600,12 @@ static struct ehca_qp *internal_create_qp(
if (EHCA_BMASK_GET(HCA_CAP_MINI_QP, shca->hca_cap)
&& !(context && udata)) { /* no small QP support in userspace ATM */
- ehca_determine_small_queue(
- &parms.squeue, max_send_sge, is_llqp);
- ehca_determine_small_queue(
- &parms.rqueue, max_recv_sge, is_llqp);
+ if (HAS_SQ(my_qp))
+ ehca_determine_small_queue(
+ &parms.squeue, max_send_sge, is_llqp);
+ if (HAS_RQ(my_qp))
+ ehca_determine_small_queue(
+ &parms.rqueue, max_recv_sge, is_llqp);
parms.qp_storage =
(parms.squeue.is_small || parms.rqueue.is_small);
}
diff --git a/drivers/infiniband/hw/ehca/ipz_pt_fn.c b/drivers/infiniband/hw/ehca/ipz_pt_fn.c
index a090c67..29bd476 100644
--- a/drivers/infiniband/hw/ehca/ipz_pt_fn.c
+++ b/drivers/infiniband/hw/ehca/ipz_pt_fn.c
@@ -172,7 +172,7 @@ static void free_small_queue_page(struct ipz_queue *queue, struct ehca_pd *pd)
unsigned long bit;
int free_page = 0;
- bit = ((unsigned long)queue->queue_pages[0] & PAGE_MASK)
+ bit = ((unsigned long)queue->queue_pages[0] & ~PAGE_MASK)
>> (order + 9);
mutex_lock(&pd->lock);
--
1.5.2
^ permalink raw reply related
* [PATCH 0/2] IB/ehca: Fixes for rc5
From: Joachim Fenkes @ 2007-08-31 14:01 UTC (permalink / raw)
To: LinuxPPC-Dev, LKML, OF-General, Roland Dreier
Cc: Stefan Roscher, Christoph Raisch
These two patches fix some ehca issues that should be fixed in 2.6.23.
[1/2] fixes regressions caused by the recent addition of Small QPs.
[2/2] adds missing SRQ-related functionality that would have broken IPoIB C=
M.
The patches should apply cleanly, in order, against Roland's git. Please
review the changes and apply the patches for 2.6.23-rc5 if they are okay.
Regards,
Joachim
=2D-=20
Joachim Fenkes =A0-- =A0eHCA Linux Driver Developer and Hardware Tamer
IBM Deutschland Entwicklung GmbH =A0-- =A0Dept. 3627 (I/O Firmware Dev. 2)
Schoenaicher Strasse 220 =A0-- =A071032 Boeblingen =A0-- =A0Germany
eMail: fenkes@de.ibm.com
^ permalink raw reply
* Re: [PATCH v2] [02/10] pasemi_mac: Stop using the pci config space accessors for register read/writes
From: Jeff Garzik @ 2007-08-31 13:54 UTC (permalink / raw)
To: Olof Johansson; +Cc: netdev, linuxppc-dev
In-Reply-To: <20070823181310.GB31882@lixom.net>
Olof Johansson wrote:
> Move away from using the pci config access functions for simple register
> access. Our device has all of the registers in the config space (hey,
> from the hardware point of view it looks reasonable :-), so we need to
> somehow get to it. Newer firmwares have it in the device tree such that
> we can just get it and ioremap it there (in case it ever moves in future
> products). For now, provide a hardcoded fallback for older firmwares.
>
>
> Signed-off-by: Olof Johansson <olof@lixom.net>
applied 2-10
^ permalink raw reply
* RE: [PATCH v7 3/3] [POWERPC] MPC832x_RDB: update dts to use SPI1in QE, register mmc_spi stub
From: Li Yang-r58472 @ 2007-08-31 13:50 UTC (permalink / raw)
To: Tabi Timur-B04825, Anton Vorontsov; +Cc: linuxppc-dev
In-Reply-To: <46D73166.6080103@freescale.com>
> -----Original Message-----
> From: linuxppc-dev-bounces+leoli=3Dfreescale.com@ozlabs.org=20
> [mailto:linuxppc-dev-bounces+leoli=3Dfreescale.com@ozlabs.org]=20
> On Behalf Of Tabi Timur-B04825
> Sent: Friday, August 31, 2007 5:07 AM
> To: Anton Vorontsov
> Cc: linuxppc-dev@ozlabs.org
> Subject: Re: [PATCH v7 3/3] [POWERPC] MPC832x_RDB: update dts=20
> to use SPI1in QE, register mmc_spi stub
>=20
> Anton Vorontsov wrote:
>=20
> > +static int __init mpc832x_spi_init(void) {
> > + if (!machine_is(mpc832x_rdb))
> > + return 0;
> > +
> > + par_io_config_pin(3, 0, 3, 0, 1, 0); /* SPI1 MOSI, I/O */
> > + par_io_config_pin(3, 1, 3, 0, 1, 0); /* SPI1 MISO, I/O */
> > + par_io_config_pin(3, 2, 3, 0, 1, 0); /* SPI1 CLK, I/O */
> > + par_io_config_pin(3, 3, 2, 0, 1, 0); /* SPI1 SEL, I */
> > +
> > + par_io_config_pin(3, 13, 1, 0, 0, 0); /* !SD_CS, O */
> > + par_io_config_pin(3, 14, 2, 0, 0, 0); /* SD_INSERT, I */
> > + par_io_config_pin(3, 15, 2, 0, 0, 0); /* SD_PROTECT,I */
>=20
> Why are you doing this here, and not in the device tree?
I saw you used pio node, but later changed to make it hardcoded. What's
the reason? IMO, device tree is used to describe the hardware settings,
pio node is a perfect match. Moreover, changing the device tree is much
easier than changing the code.
- Leo
^ permalink raw reply
* Re: [PATCH] [01/10] pasemi_mac: Abstract out register access
From: Jeff Garzik @ 2007-08-31 13:50 UTC (permalink / raw)
To: Olof Johansson; +Cc: netdev, linuxppc-dev
In-Reply-To: <20070822141244.GB16830@lixom.net>
applied
^ permalink raw reply
* Re: [PATCH] bmac: add simple ethtool support for network manager
From: Jeff Garzik @ 2007-08-31 13:47 UTC (permalink / raw)
To: Olaf Hering; +Cc: linuxppc-dev, netdev
In-Reply-To: <20070825183259.GA14478@aepfle.de>
Olaf Hering wrote:
> NetworkManager will not start dhcpd on an interface unless it reports
> link-up state via ethtool.
>
> Signed-off-by: Olaf Hering <olaf@aepfle.de>
>
> ---
> drivers/net/bmac.c | 13 +++++++++++++
> 1 file changed, 13 insertions(+)
applied
^ permalink raw reply
* Re: dtc: Optimise by default, fix warnings thus uncovered
From: Jon Loeliger @ 2007-08-31 13:38 UTC (permalink / raw)
To: David Gibson; +Cc: linuxppc-dev
In-Reply-To: <20070831062123.GC29721@localhost.localdomain>
So, like, the other day David Gibson mumbled:
> This patch turns on optimisation in the Makefile by default. With the
> optimizer on, some uninitialized variable warnings (one real, two
> bogus) are now generated. This patch also squashes those again.
Applied.
Thanks,
jdl
^ permalink raw reply
* Re: dtc: Make make print a message when linking testcases
From: Jon Loeliger @ 2007-08-31 13:38 UTC (permalink / raw)
To: David Gibson; +Cc: linuxppc-dev
In-Reply-To: <20070831060427.GB29721@localhost.localdomain>
So, like, the other day David Gibson mumbled:
> Currently, dtc relies on make's implicit rule to build the testcases.
> This means that when not making verbosely (V=0, the default) there is
> no message at all while relinking the testsuites. This can be very
> confusing when updating libfdt.a (upon which the testcases depend) and
> make appears to do nothing.
>
> This patch corrects the situation, borrowing the rule used to link dtc
> itself to link all the testcases as well.
>
> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Applied.
Thanks,
jdl
^ permalink raw reply
* Re: libfdt: Fix use of uninitialized variable in fdt_get_path()
From: Jon Loeliger @ 2007-08-31 13:38 UTC (permalink / raw)
To: David Gibson; +Cc: linuxppc-dev
In-Reply-To: <20070831043016.GM19271@localhost.localdomain>
So, like, the other day David Gibson mumbled:
> My recent implemenetation of fdt_get_path() had a bug - the while loop
> tested offset which was unitialized on the first iteration. Depending
> on code surrounding the call, this could cause fdt_get_path() to
> return incorrect results.
>
> This patch corrects the problem by applying some more correct thinking
> to the loop condition.
>
> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Applied.
Thanks,
jdl
^ permalink raw reply
* Re: [PATCH 1/6] ibmveth: Enable TCP checksum offload
From: Jeff Garzik @ 2007-08-31 13:32 UTC (permalink / raw)
To: Brian King; +Cc: linuxppc-dev, rcjenn, santil, netdev
In-Reply-To: <11873601831813-patch-mail.ibm.com>
Brian King wrote:
> This patchset enables TCP checksum offload support for IPV4
> on ibmveth. This completely eliminates the generation and checking of
> the checksum for packets that are completely virtual and never
> touch a physical network. A simple TCP_STREAM netperf run on
> a virtual network with maximum mtu set yielded a ~30% increase
> in throughput. This feature is enabled by default on systems that
> support it, but can be disabled with a module option.
>
> Signed-off-by: Brian King <brking@linux.vnet.ibm.com>
applied 1-6
^ permalink raw reply
* Re: [PATCH 1/7] Generic bitbanged MDIO library
From: Jeff Garzik @ 2007-08-31 13:23 UTC (permalink / raw)
To: Scott Wood; +Cc: netdev, Paul Mackerras, linuxppc-dev
In-Reply-To: <20070817175357.GA9218@ld0162-tx32.am.freescale.net>
Scott Wood wrote:
> Previously, bitbanged MDIO was only supported in individual
> hardware-specific drivers. This code factors out the higher level
> protocol implementation, reducing the hardware-specific portion to
> functions setting direction, data, and clock.
>
> Signed-off-by: Scott Wood <scottwood@freescale.com>
> ---
> drivers/net/phy/Kconfig | 9 ++
> drivers/net/phy/Makefile | 1 +
> drivers/net/phy/mdio-bitbang.c | 187 ++++++++++++++++++++++++++++++++++++++++
> include/linux/mdio-bitbang.h | 42 +++++++++
> 4 files changed, 239 insertions(+), 0 deletions(-)
> create mode 100644 drivers/net/phy/mdio-bitbang.c
> create mode 100644 include/linux/mdio-bitbang.h
I cannot ACK this, nor do I want to see it merged, until users appear
and have been reviewed alongside this. I do not see any fs_enet patches
that actually use this.
five-second-glance comments:
* "mdio_bitbang_" is a long prefix. consider "mdiobb_" or somesuch
* the delay (where you call ndelay()) is not guaranteed without a flush
of some sort
* how widely applicable is this "generic" library? have you converted
any non-embedded drivers over to it?
^ permalink raw reply
* Re: [PATCH 2/7] fs_enet: Whitespace cleanup.
From: Jeff Garzik @ 2007-08-31 13:19 UTC (permalink / raw)
To: Scott Wood; +Cc: netdev, linuxppc-dev
In-Reply-To: <20070817175359.GB9218@ld0162-tx32.am.freescale.net>
Scott Wood wrote:
> Signed-off-by: Scott Wood <scottwood@freescale.com>
> ---
> drivers/net/fs_enet/fs_enet-main.c | 85 ++++++++++++++++-------------------
> drivers/net/fs_enet/fs_enet.h | 4 +-
> drivers/net/fs_enet/mac-fcc.c | 1 -
> drivers/net/fs_enet/mii-fec.c | 1 -
> 4 files changed, 41 insertions(+), 50 deletions(-)
ACK patches 2-7
^ permalink raw reply
* Re: [PATCH 3/6] ibmveth: Add ethtool TSO handlers
From: Jeff Garzik @ 2007-08-31 13:14 UTC (permalink / raw)
To: Brian King; +Cc: linuxppc-dev, rcjenn, santil, netdev
In-Reply-To: <200708171416.l7HEGbwx003958@d01av02.pok.ibm.com>
Brian King wrote:
> Add handlers for get_tso and get_ufo to prevent errors being printed
> by ethtool.
>
> Signed-off-by: Brian King <brking@linux.vnet.ibm.com>
> ---
>
> linux-2.6-bjking1/drivers/net/ibmveth.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff -puN drivers/net/ibmveth.c~ibmveth_ethtool_get_tso drivers/net/ibmveth.c
> --- linux-2.6/drivers/net/ibmveth.c~ibmveth_ethtool_get_tso 2007-08-08 10:46:28.000000000 -0500
> +++ linux-2.6-bjking1/drivers/net/ibmveth.c 2007-08-08 10:46:28.000000000 -0500
> @@ -767,6 +767,8 @@ static const struct ethtool_ops netdev_e
> .set_tx_csum = ibmveth_set_tx_csum,
> .get_rx_csum = ibmveth_get_rx_csum,
> .set_rx_csum = ibmveth_set_rx_csum,
> + .get_tso = ethtool_op_get_tso,
> + .get_ufo = ethtool_op_get_ufo,
This patch is fine, but I wonder if we shouldn't add some code to
net/core/ethtool.c along the lines of...
if (!netdev->ethtool_ops->get_tso)
ethtool_op_get_tso(args);
else
netdev->ethtool_ops->get_tso(args);
Because this certainly seems like desirable behavior across all devices.
^ permalink raw reply
* Section mismatch in 2.6.23-rc4
From: Hommel, Thomas (GE Indust, GE Fanuc) @ 2007-08-31 12:25 UTC (permalink / raw)
To: linuxppc-dev; +Cc: paulus
When compiling a kernel, I get the warnings below.=20
I am using ARCH=3Dpowerpc and 'make mpc8641_hpcn_defconfig', 'make
uImage'. This didn't appear in 2.6.22, but in
arch/powerpc/kernel/head_32.S and setup_32.c, the section info
apparently didn't change.=20
LD vmlinux.o
MODPOST vmlinux.o
WARNING: vmlinux.o(.text+0x18): Section mismatch: reference to
.init.text:early_init (between '__start' and '__after_mmu_off')
WARNING: vmlinux.o(.text+0x3788): Section mismatch: reference to
.init.text:machine_init (between 'start_here' and 'set_context')
WARNING: vmlinux.o(.text+0x3790): Section mismatch: reference to
.init.text:MMU_init (between 'start_here' and 'set_context')
WARNING: vmlinux.o(.text+0x37ba): Section mismatch: reference to
.init.text:start_kernel (between 'start_here' and 'set_context')
WARNING: vmlinux.o(.text+0x37be): Section mismatch: reference to
.init.text:start_kernel (between 'start_here' and 'set_context')
LD vmlinux
SYSMAP System.map
^ permalink raw reply
* U-Boot + Linux 2.6 on MPC8270
From: eha @ 2007-08-31 8:59 UTC (permalink / raw)
To: linuxppc-embedded
Hi
I need to get a rather current kernel (2.6.22.3 to be precise) to boot on a MPC8270 based embedded target.
What is the right way to adapt to the devtree approach of arch/powerpc? I have an old U-Boot (1.1.2) running on target, able to boot 2.4 kernels.
Best regards,
Esben Haabendal
^ permalink raw reply
* Re: [PATCH 2.6.23] ibmebus: Prevent bus_id collisions
From: Joachim Fenkes @ 2007-08-31 8:57 UTC (permalink / raw)
To: Linas Vepstas
Cc: Thomas Q Klein, Jan-Bernd Themann, Paul Mackerras, LKML,
LinuxPPC-Dev, Christoph Raisch, Nathan Lynch, Paul Mackerras,
Stefan Roscher
In-Reply-To: <20070830212816.GA4263@austin.ibm.com>
linas@austin.ibm.com (Linas Vepstas) wrote on 30.08.2007 23:28:16:
> On Thu, Aug 30, 2007 at 04:00:56PM +0200, Joachim Fenkes wrote:
> >
> > Plus, I rather like using
> > the full_name since it also contains a descriptive name as opposed to
> > being just nondescript numbers, helping the layman (ie user) to make
sense
> > out of a dev_id.
>
> [...]
> Location codes are nice.
I sure agree with you. Still, they're not unique, so we can't use them as
bus_id. That's why we're having this discussion at all.
What I meant was "I like using the full_name over using the device address
/ DRC index / you-name-it only". Location code is right out.
Cheers,
Joachim
^ permalink raw reply
* RE: ML403 Hard TEMAC, PLB and Linux 2.6
From: linux-ppc @ 2007-08-31 7:52 UTC (permalink / raw)
To: Mohammad Sadegh Sadri; +Cc: Rick Moleres, linuxppc-embedded
In-Reply-To: <BAY115-W3E40B1AA7056BDABCB768B2F40@phx.gbl>
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="GB2312", Size: 11686 bytes --]
Well, our board is a custom board and we have no problem on inplementing
both TEMAC.
we have
2 TEMAC with related separated hw phy.
sdram controller
can controller
2 uartlite
sysace
graphics lcd interface
and other custom peripherals
external peripheral interface
no problem to fit into FX12..
Mohammad Sadegh Sadri <mamsadegh@hotmail.com>
20/07/2007 11.27
To
Rick Moleres <rick.moleres@xilinx.com>, <linux-ppc@eurotel.it>
cc
Ming Liu <eemingliu@hotmail.com>, <linuxppc-embedded@ozlabs.org>
Subject
RE: ML403 Hard TEMAC, PLB and Linux 2.6
Dear Massimiliano
Well I do not know the solution to the problem, but just,
In your post, there is some thing interesting for me,
How could you implement such large circuit on one FX12 FPGA?
We have done many experineces with both of AVNET MM and ML403,
you have, DDR SDRAM Controller, GPIO, UART, SYSACE and two intances of
Tri-mode TEMAC GMII,
In our tests, with one instance of Tri mode TEMAC and UART and DDR
controller, the whole FPGA resource were consumed we could not even put
sysace interface.
For me, another important question is, how many PHY chips are available on
your board? Each of Tri-mode temac modules are connected to a separate phy
chip, yes?
________________________________
> Subject: RE: ML403 Hard TEMAC, PLB and Linux 2.6
> Date: Thu, 19 Jul 2007 09:00:33 -0600
> From: Rick.Moleres@xilinx.com
> To: linux-ppc@eurotel.it
> CC: eemingliu@hotmail.com; linuxppc-embedded@ozlabs.org;
mamsadegh@hotmail.com
>
> Hi,
> The first thing I would try is to make sure eth1 comes up without first
bringing up eth0. In other words, does it come up independently? If not,
there could be something wrong with its configuration in the kernel or
perhaps a hardware design issue. If both interfaces come up
independently, but not together, then there¡¯s likely a driver issue as we
have not tested dual channel TEMAC with the Linux plb_temac driver.
Perhaps others on the list have. The areas that I would look at would be:
make sure each interface is getting a unique and correct PHY address;
make sure any calls to the shared registers of the two channels are
protected with semaphores/spinlocks. For example, I¡¯m pretty sure the PHY
registers are shared, so any PHY accesses should be protected. I would
think other Xilinx driver accesses like Start/Stop/Reset/Get or
SetOptions/etc¡ should be protected as they may access shared registers.
> -Rick
> ________________________________
> From: Massimiliano.Patriarca@eurotel.it
[mailto:Massimiliano.Patriarca@eurotel.it] On Behalf Of
linux-ppc@eurotel.it
> Sent: Thursday, July 19, 2007 7:51 AM
> To: Rick Moleres
> Cc: Ming Liu; linuxppc-embedded@ozlabs.org;
linuxppc-embedded-bounces+linux-ppc=eurotel.it@ozlabs.org;
mamsadegh@hotmail.com
> Subject: RE: ML403 Hard TEMAC, PLB and Linux 2.6
> Hi, we are trying to use both side of an hard temac + 2 plb temac in a
Virtex4FX12 project.
> we succesfull implemented a single temac Montavista tree with eth0.
> when trying to use both temac, devices are correctly registered with
kernel-
> eth0 comes up and working ok-
> when manually start eth1 (/sbin/ifconfig eth1 up) kernel hang without
any error or info in the console
> # dmesg
> Linux version 2.6.10_mvl401-ml40x (massimiliano@linux-yhbz) (gcc version
3.4.3 (MontaVista 3.4.3-25.0.135.0702900 2007-04-01)) #250 Wed Jul 18
12:20:43 CEST 2007
> Eurotel motherboard init
> Port by MontaVista Software, Inc. (source@mvista.com)
> On node 0 totalpages: 7812
> DMA zone: 7812 pages, LIFO batch:1
> Normal zone: 0 pages, LIFO batch:1
> HighMem zone: 0 pages, LIFO batch:1
> Built 1 zonelists
> Kernel command line: console=ttl0 root=/dev/xsysace2 rw ip=off
> Xilinx INTC #0 at 0x41200000 mapped to 0xFDFFF000
> PID hash table entries: 128 (order: 7, 2048 bytes)
> hr_time_init: arch_to_nsec = 8192000, nsec_to_arch = 1099511627
> Console: colour dummy device 80x25
> Dentry cache hash table entries: 4096 (order: 2, 16384 bytes)
> Inode-cache hash table entries: 2048 (order: 1, 8192 bytes)
> Memory: 28420k available (1864k kernel code, 528k data, 124k init, 0k
highmem)
> Calibrating delay loop... 252.92 BogoMIPS (lpj=126464)
> Mount-cache hash table entries: 512 (order: 0, 4096 bytes)
> spawn_desched_task(00000000)
> desched cpu_callback 3/00000000
> ksoftirqd started up.
> desched cpu_callback 2/00000000
> desched thread 0 started up.
> NET: Registered protocol family 16
> Registering platform device 'xilinx_temac.0'. Parent at platform
> Registering platform device 'xilinx_temac.1'. Parent at platform
> Registering platform device 'xilinx_sysace.0'. Parent at platform
> Registering platform device 'xilinx_gpio.0'. Parent at platform
> Registering platform device 'xilinx_gpio.1'. Parent at platform
> Registering platform device 'oled_fb.0'. Parent at platform
> Generic PHY: Registered new driver
> oled_fb: 4096 video memory mapped to c2011000
> Console: switching to colour frame buffer device 16x8
> xgpio #0 at 0x40000000 mapped to 0xC2020000
> xgpio #1 at 0x40020000 mapped to 0xC2040000
> io scheduler noop registered
> io scheduler anticipatory registered
> io scheduler deadline registered
> io scheduler cfq registered
> loop: loaded (max 8 devices)
> elevator: using anticipatory as default io scheduler
> System ACE at 0x41800000 mapped to 0xC2060000, irq=4, 1000944KB
> xsysace: xsysace1 xsysace2
> Universal TUN/TAP device driver 1.5 (C)1999-2002 Maxim Krasnyansky
> XTemac: using FIFO direct interrupt driven mode.
> eth0: Xilinx TEMAC #0 at 0x20000000 mapped to 0xC2080000, irq=0
> eth0: XTemac id 1.0f, block id 5, type 8
> XTemac: using FIFO direct interrupt driven mode.
> eth1: Xilinx TEMAC #1 at 0x20010000 mapped to 0xC20A0000, irq=10
> eth1: XTemac id 1.0f, block id 5, type 8
> i2c /dev entries driver
> i2c-xil_custom: registered with I2C (0)
> i2c-xil_custom: registered with I2C (1)
> mice: PS/2 mouse device common for all mice
> NET: Registered protocol family 2
> IP: routing cache hash table of 512 buckets, 4Kbytes
> TCP: Hash tables configured (established 2048 bind 4096)
> NET: Registered protocol family 1
> NET: Registered protocol family 17
> EXT3-fs warning: maximal mount count reached, running e2fsck is
recommended
> kjournald starting. Commit interval 5 seconds
> EXT3 FS on xsysace2, internal journal
> EXT3-fs: recovery complete.
> EXT3-fs: mounted filesystem with ordered data mode.
> VFS: Mounted root (ext3 filesystem).
> Freeing unused kernel memory: 124k init
> eth0: XTemac: Options: 0xb8f2
> eth0: XTemac: speed set to 100Mb/s
> eth0: XTemac: PHY Link carrier lost.
> # /sbin/ifconfig eth1 up
> # eth1: XTemac: Options: 0xb8f2
> Any suggestion?
> "Rick Moleres"
> Sent by: linuxppc-embedded-bounces+linux-ppc=eurotel.it@ozlabs.org
> 08/02/2007 17.23
> To
> "Ming Liu" ,
> cc
> linuxppc-embedded@ozlabs.org
> Subject
> RE: ML403 Hard TEMAC, PLB and Linux 2.6
> Hi,
> As Ming says the Linux 2.6 TEMAC driver is made available in EDK 8.2.2
as part of the BSP and Libraries generation for Linux 2.6. Note that we
made a recent fix for better PHY address detection and speed negotiation.
I've attached the adapter here, and it will be available in EDK 9.1.1 when
that's released.
> Thanks,
> Rick
> -----Original Message-----
> From: linuxppc-embedded-bounces+moleres=xilinx.com@ozlabs.org
[mailto:linuxppc-embedded-bounces+moleres=xilinx.com@ozlabs.org] On Behalf
Of Ming Liu
> Sent: Thursday, February 08, 2007 2:31 AM
> To: mamsadegh@hotmail.com
> Cc: linuxppc-embedded@ozlabs.org
> Subject: RE: ML403 Hard TEMAC, PLB and Linux 2.6
> Hi,
> In xapp902, they are using the old cores for Temac. So it will be easier
to
> generate a project in EDK 8.2. Not only the cores there are new, but
also
> it can generate the driver for linux 2.6.
> BR
> Ming
> >From: Mohammad Sadegh Sadri
> >To:
> >CC: linuxppc-embedded@ozlabs.org
> >Subject: RE: ML403 Hard TEMAC, PLB and Linux 2.6
> >Date: Thu, 8 Feb 2007 07:13:47 +0000
> >
> >
> >Hi
> >Thanks for reply
> >Well, regarding xapp902, there is a very simple question, Where can I
find
> it? It seems that Xilinx has deleted all of the links to these files.
> >
> >
> >
> >
> >
> >----------------------------------------
> > > Subject: Re: ML403 Hard TEMAC, PLB and Linux 2.6
> > > From: christophe.alayrac@cresitt.com
> > > To: mamsadegh@hotmail.com
> > > CC: linuxppc-embedded@ozlabs.org
> > > Date: Thu, 8 Feb 2007 06:51:45 +0100
> > >
> > > Le mercredi 07 février 2007 ?22:30 +0000, Mohammad Sadegh Sadri a
> > > écrit :
> > > Hi Mohammad,
> > >
> > > Please find here after some answer
> > >
> > > > 1- I want to use, ML403, Hard TEMAC and PLB TEMAC cores. Is there
any
> ready to use design, or any reference design available for this?
> > > > I'm using EDK 8.1 and I understood that, when I choose the ML403
> board , EDK does not use hard temac, so , should I add it manually? (
well
> this is funny, but the wizard does not use hard temac , is it true? )
> > > > Is there any ready EDK projects for ML403, with TEMAC and PLB
TEMAC
> modules already inserted and cofigured? (I don't want to use GSRD ) ( If
> yes would you please put the link here )
> > > >
> > > You can start from XAPP 902 from Xilinx, this design demonstrate
TEMAC
> > > use in loopback mode. Some memers from that community have tried
from
> > > that design as a starting point. I did not nknow if the succeed.
> > > I would recommand to get EDK 8.2 SP2 and use the Wizard to build a
new
> > > design with TEMAC.
> > >
> > > > 2- Simply, Is there any driver available for linux 2.6 , for PLB
> TEMAC and Hard TEMAC modules? If yes , can you put the link here, so
that I
> can download it?
> > > >
> > > For the kernel you can get it from Montavista source code site using
> GIT
> > > to download it (linux-xilinx-26). This is 2.6.17.4 version (last
week!)
> > >
> > > Then you will need to pacth the Kernel with TEMAC drivers (look for
> > > TEMAC PAULUS MVISTA with google, or follow my messages in that
mailing
> > > list)
> > > NOTE: If you use that TEMAC patch do not use SGDMA on your TEMAC,
use
> > > FIFO.
> > >
> > > > thanks
> > > Regards
> > >
> > > Chris
> > > > _________________________________________________________________
> > > > Personalize your Live.com homepage with the news, weather, and
photos
> you care about.
> > > > http://www.live.com/getstarted.aspx?icid=T001MSN30A0701
> > > > _______________________________________________
> > > > Linuxppc-embedded mailing list
> > > > Linuxppc-embedded@ozlabs.org
> > > > https://ozlabs.org/mailman/listinfo/linuxppc-embedded
> > >
> >
> >_________________________________________________________________
> >Live Search: New search found
> >http://get.live.com/search/overview
> >_______________________________________________
> >Linuxppc-embedded mailing list
> >Linuxppc-embedded@ozlabs.org
> >https://ozlabs.org/mailman/listinfo/linuxppc-embedded
> _________________________________________________________________
> ÓëÁª»úµÄÅóÓѽøÐн»Á÷£¬ÇëʹÓà MSN Messenger: http://messenger.msn.com/cn
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
_________________________________________________________________
Discover the new Windows Vista
http://search.msn.com/results.aspx?q=windows+vista&mkt=en-US&form=QBRE
[-- Attachment #2: Type: text/html, Size: 14805 bytes --]
^ permalink raw reply
* dtc: Optimise by default, fix warnings thus uncovered
From: David Gibson @ 2007-08-31 6:21 UTC (permalink / raw)
To: Jon Loeliger; +Cc: linuxppc-dev
This patch turns on optimisation in the Makefile by default. With the
optimizer on, some uninitialized variable warnings (one real, two
bogus) are now generated. This patch also squashes those again.
Index: dtc/Makefile
===================================================================
--- dtc.orig/Makefile 2007-08-31 16:00:25.000000000 +1000
+++ dtc/Makefile 2007-08-31 16:00:28.000000000 +1000
@@ -45,7 +45,7 @@
CPPFLAGS = -I libfdt
-CFLAGS = -Wall -g
+CFLAGS = -Wall -g -Os
LDFLAGS = -Llibfdt
BISON = bison
Index: dtc/tests/truncated_property.c
===================================================================
--- dtc.orig/tests/truncated_property.c 2007-08-31 16:05:27.000000000 +1000
+++ dtc/tests/truncated_property.c 2007-08-31 16:05:38.000000000 +1000
@@ -33,7 +33,6 @@
{
void *fdt = &_truncated_property;
const void *prop;
- int err;
int len;
test_init(argc, argv);
@@ -43,7 +42,7 @@
FAIL("fdt_getprop() succeeded on truncated property");
if (len != -FDT_ERR_BADSTRUCTURE)
FAIL("fdt_getprop() failed with \"%s\" instead of \"%s\"",
- fdt_strerror(err), fdt_strerror(-FDT_ERR_BADSTRUCTURE));
+ fdt_strerror(len), fdt_strerror(-FDT_ERR_BADSTRUCTURE));
PASS();
}
Index: dtc/flattree.c
===================================================================
--- dtc.orig/flattree.c 2007-08-31 16:08:06.000000000 +1000
+++ dtc/flattree.c 2007-08-31 16:09:29.000000000 +1000
@@ -909,6 +909,7 @@
fprintf(stderr, "\tboot_cpuid_phys:\t0x%x\n",
be32_to_cpu(bph->boot_cpuid_phys));
+ size_str = -1;
if (version >= 3) {
size_str = be32_to_cpu(bph->size_dt_strings);
fprintf(stderr, "\tsize_dt_strings:\t%d\n", size_str);
@@ -932,10 +933,10 @@
inbuf_init(&memresvbuf,
blob + off_mem_rsvmap, blob + totalsize);
inbuf_init(&dtbuf, blob + off_dt, blob + totalsize);
- inbuf_init(&strbuf, blob + off_str, blob + totalsize);
-
- if (version >= 3)
- strbuf.limit = strbuf.base + size_str;
+ if (size_str >= 0)
+ inbuf_init(&strbuf, blob + off_str, blob + off_str + size_str);
+ else
+ inbuf_init(&strbuf, blob + off_str, blob + totalsize);
reservelist = flat_read_mem_reserve(&memresvbuf);
Index: dtc/dtc.c
===================================================================
--- dtc.orig/dtc.c 2007-08-31 16:10:23.000000000 +1000
+++ dtc/dtc.c 2007-08-31 16:12:44.000000000 +1000
@@ -71,7 +71,7 @@
fill_fullpaths(child, tree->fullpath);
}
-static void usage(void)
+static void __attribute__ ((noreturn)) usage(void)
{
fprintf(stderr, "Usage:\n");
fprintf(stderr, "\tdtc [options] <input file>\n");
Index: dtc/dtc.h
===================================================================
--- dtc.orig/dtc.h 2007-08-31 16:13:01.000000000 +1000
+++ dtc/dtc.h 2007-08-31 16:13:07.000000000 +1000
@@ -43,7 +43,7 @@
extern int reservenum; /* Number of memory reservation slots */
extern int minsize; /* Minimum blob size */
-static inline void die(char * str, ...)
+static inline void __attribute__((noreturn)) die(char * str, ...)
{
va_list ap;
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ 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