* 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 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 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: 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: 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: 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: [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: [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 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 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
* [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
* [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 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
* 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
* 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: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 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: [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
* [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
* Help linuxppc-2.4.26
From: José Luis Añamuro @ 2007-08-31 16:20 UTC (permalink / raw)
To: ammubhai; +Cc: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 2032 bytes --]
Hi
I am Jose Luis. I am compilling the kernel linuxppc-2.4.26. First I use the bitkepper to retrieve the version of kernel after I path it with Base Support Package (BSP) generated in EDK 8.2i, after I run "make oldconfig" to import the config file for the ML310, then I run "make menuconfig" when i set specifically changed from ml310, after i run "make dep", "make zImage" and .... appears a strange error that says:
make[1]: se ingresa al directorio `/home/jose/bk-client2.0/linuxppc-2.4.26/arch/ppc/4xx_io'
make all_targets
make[2]: se ingresa al directorio `/home/jose/bk-client2.0/linuxppc-2.4.26/arch/ppc/4xx_io'
make[2]: No se hace nada para `all_targets'.
make[2]: se sale del directorio `/home/jose/bk-client2.0/linuxppc-2.4.26/arch/ppc/4xx_io'
make[1]: se sale del directorio `/home/jose/bk-client2.0/linuxppc-2.4.26/arch/ppc/4xx_io'
powerpc-405-linux-gnu-ld -T arch/ppc/vmlinux.lds -Ttext 0xc0000000 -Bstatic arch/ppc/kernel/head_4xx.o init/main.o init/version.o init/do_mounts.o \
--start-group \
arch/ppc/kernel/kernel.o arch/ppc/platforms/platform.o arch/ppc/mm/mm.o arch/ppc/lib/li b.o kernel/kernel.o mm/mm.o fs/fs.o ipc/ipc.o \
drivers/char/char.o drivers/block/block.o drivers/misc/misc.o drivers/net/net.o drive rs/macintosh/macintosh.o drivers/media/media.o arch/ppc/4xx_io/4xx_io.o \
net/network.o \
/home/jose/bk-client2.0/linuxppc-2.4.26/lib/lib.a \
--end-group \
-o vmlinux
drivers/block/block.o(.text.init+0x6c8): In function `xsysace_init':
: undefined reference to `XSysAce_Initialize'
make: *** [vmlinux] Error 1
Please i hope so you can help me, I carry many days with it and I do not know how resolv it
Best Regards
José Luis
______________________________________________
Sé un Mejor Viajero
¿Quieres saber cómo? ¡Deja que otras personas te ayuden!
http://advision.webevents.yahoo.com/reto/viaje.html
[-- Attachment #2: Type: text/html, Size: 2869 bytes --]
^ permalink raw reply
* Re: [linux kernel 2.6.19] ethernet driver for Marvell bridge GT-64260
From: Dale Farnsworth @ 2007-08-31 16:43 UTC (permalink / raw)
To: joachim.bader, Linuxppc-embedded
In-Reply-To: <OF71BAC825.59CE0529-ONC1257348.0056D44E-C1257348.0057BBA0@diehl-gruppe.de>
>
> 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?
No, this does not happen on the mv64360. As I recall, that message occurs
when something attempts to queue a packet to a driver that has called
netif_stop_queue() but hasn't yet called netif_wake_queue(). I would
guess that when you turn debug on, you are changing the driver logic
in addition to the timing.
-Dale
^ permalink raw reply
* Re: [PATCH 2.6.23] ibmebus: Prevent bus_id collisions
From: Arnd Bergmann @ 2007-08-31 17:08 UTC (permalink / raw)
To: Joachim Fenkes
Cc: Thomas Q Klein, Paul Mackerras, Jan-Bernd Themann, LKML,
linuxppc-dev, Christoph Raisch, Paul Mackerras, Stefan Roscher
In-Reply-To: <OFBB1BA4B6.29175A76-ONC1257348.004DBCB3-C1257348.0050161C@de.ibm.com>
On Friday 31 August 2007, Joachim Fenkes wrote:
> > 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?
Ok, sounds fair. Can you make sure that the resulting bus_id is the same
for the final version then?
Arnd <><
^ permalink raw reply
* to post to this list
From: José Luis Añamuro @ 2007-08-31 17:22 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 307 bytes --]
to post to this list
José Luis
____________________________________________________________________________________
Sé un Mejor Amante del Cine
¿Quieres saber cómo? ¡Deja que otras personas te ayuden!
http://advision.webevents.yahoo.com/reto/entretenimiento.html
[-- Attachment #2: Type: text/html, Size: 543 bytes --]
^ permalink raw reply
* [PATCH] mpc5200: add cuimage support for mpc5200 boards
From: Grant Likely @ 2007-08-31 17:34 UTC (permalink / raw)
To: tnt, scottwood, galak, linuxppc-dev
From: Grant Likely <grant.likely@secretlab.ca>
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
---
arch/powerpc/boot/Makefile | 5 ++-
arch/powerpc/boot/cuboot-52xx.c | 59 ++++++++++++++++++++++++++++++
arch/powerpc/boot/mpc52xx-psc.c | 69 +++++++++++++++++++++++++++++++++++
arch/powerpc/boot/ops.h | 1 +
arch/powerpc/boot/serial.c | 2 +
arch/powerpc/platforms/52xx/Kconfig | 1 +
6 files changed, 135 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/boot/Makefile b/arch/powerpc/boot/Makefile
index cd7c057..45be0e5 100644
--- a/arch/powerpc/boot/Makefile
+++ b/arch/powerpc/boot/Makefile
@@ -45,8 +45,8 @@ src-wlib := string.S crt0.S stdio.c main.c flatdevtree.c flatdevtree_misc.c \
ns16550.c serial.c simple_alloc.c div64.S util.S \
gunzip_util.c elf_util.c $(zlib) devtree.c oflib.c ofconsole.c \
4xx.c ebony.c mv64x60.c mpsc.c mv64x60_i2c.c cuboot.c bamboo.c \
- cpm-serial.c
-src-plat := of.c cuboot-83xx.c cuboot-85xx.c holly.c \
+ cpm-serial.c mpc52xx-psc.c
+src-plat := of.c cuboot-52xx.c cuboot-83xx.c cuboot-85xx.c holly.c \
cuboot-ebony.c treeboot-ebony.c prpmc2800.c \
ps3-head.S ps3-hvcall.S ps3.c treeboot-bamboo.c cuboot-8xx.c cuboot-pq2.c
src-boot := $(src-wlib) $(src-plat) empty.c
@@ -142,6 +142,7 @@ image-$(CONFIG_DEFAULT_UIMAGE) += uImage
ifneq ($(CONFIG_DEVICE_TREE),"")
image-$(CONFIG_PPC_8xx) += cuImage.8xx
image-$(CONFIG_8260) += cuImage.pq2
+image-$(CONFIG_PPC_MPC52xx) += cuImage.52xx
image-$(CONFIG_PPC_83xx) += cuImage.83xx
image-$(CONFIG_PPC_85xx) += cuImage.85xx
image-$(CONFIG_EBONY) += treeImage.ebony cuImage.ebony
diff --git a/arch/powerpc/boot/cuboot-52xx.c b/arch/powerpc/boot/cuboot-52xx.c
new file mode 100644
index 0000000..9256a26
--- /dev/null
+++ b/arch/powerpc/boot/cuboot-52xx.c
@@ -0,0 +1,59 @@
+/*
+ * Old U-boot compatibility for MPC5200
+ *
+ * Author: Grant Likely <grant.likely@secretlab.ca>
+ *
+ * Copyright (c) 2007 Secret Lab Technologies Ltd.
+ * Copyright (c) 2007 Freescale Semiconductor, Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published
+ * by the Free Software Foundation.
+ */
+
+#include "ops.h"
+#include "stdio.h"
+#include "io.h"
+#include "cuboot.h"
+
+#define TARGET_PPC_MPC52xx
+#include "ppcboot.h"
+
+static bd_t bd;
+
+static void platform_fixups(void)
+{
+ void *soc, *reg;
+ int div;
+ u32 sysfreq;
+
+
+ dt_fixup_memory(bd.bi_memstart, bd.bi_memsize);
+ dt_fixup_mac_addresses(bd.bi_enetaddr);
+ dt_fixup_cpu_clocks(bd.bi_intfreq, bd.bi_busfreq / 4, bd.bi_busfreq);
+
+ /* Unfortunately, the specific model number is encoded in the
+ * soc node name in existing dts files -- once that is fixed,
+ * this can do a simple path lookup.
+ */
+ soc = find_node_by_devtype(NULL, "soc");
+ if (soc) {
+ setprop(soc, "bus-frequency", &bd.bi_ipbfreq,
+ sizeof(bd.bi_ipbfreq));
+
+ if (!dt_xlate_reg(soc, 0, (void*)®, NULL))
+ return;
+ div = in_8(reg + 0x204) & 0x0020 ? 8 : 4;
+ sysfreq = bd.bi_busfreq * div;
+ setprop(soc, "system-frequency", &sysfreq, sizeof(sysfreq));
+ }
+}
+
+void platform_init(unsigned long r3, unsigned long r4, unsigned long r5,
+ unsigned long r6, unsigned long r7)
+{
+ CUBOOT_INIT();
+ ft_init(_dtb_start, _dtb_end - _dtb_start, 32);
+ serial_console_init();
+ platform_ops.fixups = platform_fixups;
+}
diff --git a/arch/powerpc/boot/mpc52xx-psc.c b/arch/powerpc/boot/mpc52xx-psc.c
new file mode 100644
index 0000000..1074626
--- /dev/null
+++ b/arch/powerpc/boot/mpc52xx-psc.c
@@ -0,0 +1,69 @@
+/*
+ * MPC5200 PSC serial console support.
+ *
+ * Author: Grant Likely <grant.likely@secretlab.ca>
+ *
+ * Copyright (c) 2007 Secret Lab Technologies Ltd.
+ * Copyright (c) 2007 Freescale Semiconductor, Inc.
+ *
+ * It is assumed that the firmware (or the platform file) has already set
+ * up the port.
+ */
+
+#include "types.h"
+#include "io.h"
+#include "ops.h"
+
+/* Programmable Serial Controller (PSC) status register bits */
+#define MPC52xx_PSC_SR 0x04
+#define MPC52xx_PSC_SR_RXRDY 0x0100
+#define MPC52xx_PSC_SR_RXFULL 0x0200
+#define MPC52xx_PSC_SR_TXRDY 0x0400
+#define MPC52xx_PSC_SR_TXEMP 0x0800
+
+#define MPC52xx_PSC_BUFFER 0x0C
+
+static void *psc;
+
+static int psc_open(void)
+{
+ /* Assume the firmware has already configured the PSC into
+ * uart mode */
+ return 0;
+}
+
+static void psc_putc(unsigned char c)
+{
+ while (!(in_be16(psc + MPC52xx_PSC_SR) & MPC52xx_PSC_SR_TXRDY)) ;
+ out_8(psc + MPC52xx_PSC_BUFFER, c);
+}
+
+static unsigned char psc_tstc(void)
+{
+ return (in_be16(psc + MPC52xx_PSC_SR) & MPC52xx_PSC_SR_RXRDY) != 0;
+}
+
+static unsigned char psc_getc(void)
+{
+ while (!(in_be16(psc + MPC52xx_PSC_SR) & MPC52xx_PSC_SR_RXRDY)) ;
+ return in_8(psc + MPC52xx_PSC_BUFFER);
+}
+
+int mpc5200_psc_console_init(void *devp, struct serial_console_data *scdp)
+{
+ int n;
+
+ /* Get the base address of the psc registers */
+ n = getprop(devp, "virtual-reg", &psc, sizeof(psc));
+ if (n != sizeof(psc)) {
+ if (!dt_xlate_reg(devp, 0, (void *)&psc, NULL))
+ return -1;
+ }
+
+ scdp->open = psc_open;
+ scdp->putc = psc_putc;
+ scdp->getc = psc_getc;
+ scdp->tstc = psc_tstc;
+
+ return 0;
+}
diff --git a/arch/powerpc/boot/ops.h b/arch/powerpc/boot/ops.h
index 45c2268..5ab9b51 100644
--- a/arch/powerpc/boot/ops.h
+++ b/arch/powerpc/boot/ops.h
@@ -83,6 +83,7 @@ int serial_console_init(void);
int ns16550_console_init(void *devp, struct serial_console_data *scdp);
int mpsc_console_init(void *devp, struct serial_console_data *scdp);
int cpm_console_init(void *devp, struct serial_console_data *scdp);
+int mpc5200_psc_console_init(void *devp, struct serial_console_data *scdp);
void *simple_alloc_init(char *base, unsigned long heap_size,
unsigned long granularity, unsigned long max_allocs);
extern void flush_cache(void *, unsigned long);
diff --git a/arch/powerpc/boot/serial.c b/arch/powerpc/boot/serial.c
index d47f8e0..95e08e4 100644
--- a/arch/powerpc/boot/serial.c
+++ b/arch/powerpc/boot/serial.c
@@ -126,6 +126,8 @@ int serial_console_init(void)
dt_is_compatible(devp, "fsl,cpm2-scc-uart") ||
dt_is_compatible(devp, "fsl,cpm2-smc-uart"))
rc = cpm_console_init(devp, &serial_cd);
+ else if (dt_is_compatible(devp, "mpc5200-psc-uart"))
+ rc = mpc5200_psc_console_init(devp, &serial_cd);
/* Add other serial console driver calls here */
diff --git a/arch/powerpc/platforms/52xx/Kconfig b/arch/powerpc/platforms/52xx/Kconfig
index 3ffaa06..9ddf251 100644
--- a/arch/powerpc/platforms/52xx/Kconfig
+++ b/arch/powerpc/platforms/52xx/Kconfig
@@ -30,6 +30,7 @@ config PPC_EFIKA
config PPC_LITE5200
bool "Freescale Lite5200 Eval Board"
depends on PPC_MULTIPLATFORM && PPC32
+ select WANT_DEVICE_TREE
select PPC_MPC5200
default n
^ permalink raw reply related
* To post to this list
From: José Luis Añamuro @ 2007-08-31 17:44 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 307 bytes --]
To post to this list
Jose Luis
____________________________________________________________________________________
Sé un Mejor Amante del Cine
¿Quieres saber cómo? ¡Deja que otras personas te ayuden!
http://advision.webevents.yahoo.com/reto/entretenimiento.html
[-- Attachment #2: Type: text/html, Size: 528 bytes --]
^ 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