* Re: [PATCH] powerpc: Add of_register_i2c_devices()
From: Segher Boessenkool @ 2007-07-04 12:19 UTC (permalink / raw)
To: Guennadi Liakhovetski; +Cc: linuxppc-dev, Paul Mackerras, i2c
In-Reply-To: <Pine.LNX.4.60.0707040707010.4300@poirot.grange>
>> Now some OF I2C code goes looking for IIC devices in the
>> device tree. It finds this thing, and from a table or
>> something it derives that it has to tell the kernel I2C
>> layer this is an "rtc-rs5c372".
>
> (I2C ML cc'ed.)
>
> This is where I WOULD disagree. These tables would rather live
> inside the
> i2c layer,
Physical location doesn't matter, logical location is
a separate layer.
> be filled by respective drivers themselves.
That would be nicer yes, but a bigger change.
> Noone except the
> rs5c372 driver can know which devices it can handle.
I don't really agree but that's more a philosophical than
a technical argument.
> Using the very same
> your argument - what if in a future version this driver disappears and
> another one will be used for these devices? Then that driver will
> have to
> register support for this device.
And it's all in the same kernel source tree so it would be
a trivial fixup -- quite different from keeping OF device
trees and Linux kernels in synch (which is pretty much
impossible).
> For this to work i2c would need something similar to what pci, usb
> do -
> register supported device ids. The only difference is that instead of
> numerical IDs we have to use plain text names for i2c devices...
Yeah, that would be nice. Are you suggesting the Linux I2C
layer should use "OF-style" names as its "native" naming
scheme? I'd rather keep the namespaces separate, coupling
them always seems like a great idea and always turns out a
disaster.
>> [It would be nicer if it
>> could just instantiate the correct driver directly, but
>> if that's how the Linux I2C layer works, so be it].
>>
>> No change in the I2C "core" needed, just an OF "compatible"
>> matching thing like is needed *everywhere else* too.
>
> Yes, this is why I put "would". Looks like this is the common powerpc
> practice ATM - to make such a glue to map arbitrary "OF names" to what
> respective drivers react to. Like in the case of the serial driver.
Yes. This is the most flexible scheme possible and allows
for all kinds of fixups/workarounds in case of broken device
trees (or broken kernel code, for that matter).
> But -
> i2c is much more diverse and dynamic than serial, so, maybe it is
> worth
> thinking about "fixing" i2c?
Be my guest :-) I care more about the OF side of things, but
let me ask anyway -- what do you see as "broken" in the Linux
IIC "core" that needs fixing here?
Segher
^ permalink raw reply
* Re: [PATCH v2] Schedule removal of arch/ppc
From: Segher Boessenkool @ 2007-07-04 12:10 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
In-Reply-To: <18059.8592.518737.343337@cargo.ozlabs.ibm.com>
> Given that we started this process (or at least made the decision to
> start it) in July 2005, June 2008 sounds quite reasonable as an end
> date.
Is that a signed-off-by? Hurray!
Segher
^ permalink raw reply
* Re: Should of_device_is_compatible() use strcmp() rather than strncasecmp()?
From: Segher Boessenkool @ 2007-07-04 12:09 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
In-Reply-To: <18059.5083.741194.497123@cargo.ozlabs.ibm.com>
>> Does anything actually rely on this behavior?
>
> Things did in the past rely on the case-insensitive comparison but
> probably don't any more. I recall an issue with "ata" vs. "ATA" on
> the powerbook 3400.
Yes, and there are some AAPL, vs. aapl, things too; and an
i2c thing as well. Probably more. Nothing unfixable of course,
but...
> As for the "n" part, I don't recall exactly why that was done. I
> think we should change it to use strcmp and fix any drivers that
> break.
...we first need to find the problem spots. If we switch early
in the .23 series, will that be enough time to find all (important)
issues?
Segher
^ permalink raw reply
* RE: OF devices and non OF devices
From: Kári Davíðsson @ 2007-07-04 12:00 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <4b73d43f0707030931v42aefc72x2598546e48ae87e8@mail.gmail.com>
John, thank you for your answare.
Enabling CONFIG_FSL_SOC only enabled the execution of the init function =
(fsl_i2c_init())
of the fsl-i2c driver (i2c-mpc.c). The .probe function of the driver was =
never called
until I converted the driver to the OF model and added the .match_table =
to the driver structure.
Then I get the .probe function (fsl_i2c_probe()) called and the i2c bus =
set up.
Similar thing happens for the i2c device PCF8563 i.e., the init functin =
of the driver (pcf8563_init())
is called the driver is registered with the kernel, but the .probe =
(pcf8563_probe()) is never called.
The driver pcf8563 has _NO_ exported structures or functions so I =
basically have no handle on it
that I can utilize in board specific setup.
The way I suspect this is supposed to work is that from the board settup =
files I would do
rtc_dev =3D platform_device_register_simple("pcf8563", -1, NULL, 0);
which should later trigger the calling of the pcf8563_probe() function.
This is doing things in the same way as the fsl i2c code, i.e.
i2c_dev =3D platform_device_register_simple("i2c", i, r, 2);
which by the way does not work untill I have converted the fsl_i2c =
(i2c-mpc.c) driver to the OF structure.
So still the method of gluing together the OF drivers and non OF drivers =
eludes me.
rg
kd
P.S. I did check the 2.6.21-RC7-git3 and found that the i2c-mpc.c and =
the rtc-pcf85763.c are basically the same
as what I am working with in 2.6.20+=20
________________________________
From: John Rigby [mailto:jcrigby@gmail.com]=20
Sent: 3. j=FAl=ED 2007 16:31
To: K=E1ri Dav=ED=F0sson
Cc: linuxppc-embedded@ozlabs.org
Subject: Re: OF devices and non OF devices
One place to find binding between OF devices and non OF devices is in =
arch/powerpc/sysdev/fsl_soc.c
The typical pattern is:
if of_find_compatible_node "of-device-name"
platform_device_register_simple ""platform-device-name"=20
platform_device_add_data ...
=20
On 7/3/07, K=E1ri Dav=ED=F0sson <kari.davidsson@marel.is> wrote:=20
Hi,
=09
I am attempting to get some non OF devices working for an mpc 5200 =
board, in particular=20
PCF8563 RTC.
=09
This device has an non OF device interface which I believe is correct. =
After all it should work
on non OF platforms.
=09
I have managed to get the board to run the i2c initialization (and =
probe) for the fsl-mpc i2c driver by=20
converting the fsl-mpc i2c driver to OF driver (I found some patch here =
that I based this work on).
fsl-i2c is one of the devices handled by fsl_soc.c so you shouldn't need =
to change anything to=20
make it work in the latest kernel. CONFIG_FSL_SOC was only added to =
lite5200_defconfig recently so=20
that may explain why it's not on in your kernel.
Since the PCF8563 driver is not OF driver only its initaliziation code =
is run but the .probe function
of the driver is never run. Basically (as far as I can understand) the =
.probe is never run because the
driver is not an OF driver.=20
=09
I could convert the PCF8563 driver to OF driver and make it work for =
our puposes but I feel this is
1) Wrong
2) therefore wasted work.
Since the driver must run on non OF platforms then it should not be =
converted. You just need to add a platform_device_register somewhere.=20
I don't think fsl_soc.c is the right place since it is not part of an =
freescale SOC.
You could probably put it in a board specific startup routine.
What seems to elude me is some glue that glues together the OF part of =
the driver space to the non OF part
of the driver space.
=09
Any hints or pointers on where to find this glue?
=09
Regards,
kd
=09
P.S. Kernel is post 2.6.20.
=09
--
K=E1ri Dav=ED=F0sson | kari.davidsson@marel.is
Hugb=FAna=F0arger=F0 | www.marel.com
Tel: 563-8156 Fax: +354 563 8001=20
Iceland
_______________________________________________
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
=09
^ permalink raw reply
* Re: [PATCH] powermac i2c: use mutex
From: Benjamin Herrenschmidt @ 2007-07-04 11:47 UTC (permalink / raw)
To: Johannes Berg; +Cc: linuxppc-dev list, Paul Mackerras
In-Reply-To: <1183503714.4021.25.camel@johannes.berg>
On Wed, 2007-07-04 at 01:01 +0200, Johannes Berg wrote:
> Convert the semaphores in low_i2c that are used as mutexes to real
> mutexes.
>
> Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
Looks ok
Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> ---
> arch/powerpc/platforms/powermac/low_i2c.c | 23 ++++++++++++-----------
> 1 file changed, 12 insertions(+), 11 deletions(-)
>
> --- wireless-dev.orig/arch/powerpc/platforms/powermac/low_i2c.c 2007-07-04 00:42:08.267749881 +0200
> +++ wireless-dev/arch/powerpc/platforms/powermac/low_i2c.c 2007-07-04 00:42:48.667749881 +0200
> @@ -42,6 +42,7 @@
> #include <linux/interrupt.h>
> #include <linux/completion.h>
> #include <linux/timer.h>
> +#include <linux/mutex.h>
> #include <asm/keylargo.h>
> #include <asm/uninorth.h>
> #include <asm/io.h>
> @@ -84,7 +85,7 @@ struct pmac_i2c_bus
> void *hostdata;
> int channel; /* some hosts have multiple */
> int mode; /* current mode */
> - struct semaphore sem;
> + struct mutex mutex;
> int opened;
> int polled; /* open mode */
> struct platform_device *platform_dev;
> @@ -104,7 +105,7 @@ static LIST_HEAD(pmac_i2c_busses);
>
> struct pmac_i2c_host_kw
> {
> - struct semaphore mutex; /* Access mutex for use by
> + struct mutex mutex; /* Access mutex for use by
> * i2c-keywest */
> void __iomem *base; /* register base address */
> int bsteps; /* register stepping */
> @@ -375,14 +376,14 @@ static void kw_i2c_timeout(unsigned long
> static int kw_i2c_open(struct pmac_i2c_bus *bus)
> {
> struct pmac_i2c_host_kw *host = bus->hostdata;
> - down(&host->mutex);
> + mutex_lock(&host->mutex);
> return 0;
> }
>
> static void kw_i2c_close(struct pmac_i2c_bus *bus)
> {
> struct pmac_i2c_host_kw *host = bus->hostdata;
> - up(&host->mutex);
> + mutex_unlock(&host->mutex);
> }
>
> static int kw_i2c_xfer(struct pmac_i2c_bus *bus, u8 addrdir, int subsize,
> @@ -498,7 +499,7 @@ static struct pmac_i2c_host_kw *__init k
> kfree(host);
> return NULL;
> }
> - init_MUTEX(&host->mutex);
> + mutex_init(&host->mutex);
> init_completion(&host->complete);
> spin_lock_init(&host->lock);
> init_timer(&host->timeout_timer);
> @@ -571,7 +572,7 @@ static void __init kw_i2c_add(struct pma
> bus->open = kw_i2c_open;
> bus->close = kw_i2c_close;
> bus->xfer = kw_i2c_xfer;
> - init_MUTEX(&bus->sem);
> + mutex_init(&bus->mutex);
> if (controller == busnode)
> bus->flags = pmac_i2c_multibus;
> list_add(&bus->link, &pmac_i2c_busses);
> @@ -798,7 +799,7 @@ static void __init pmu_i2c_probe(void)
> bus->mode = pmac_i2c_mode_std;
> bus->hostdata = bus + 1;
> bus->xfer = pmu_i2c_xfer;
> - init_MUTEX(&bus->sem);
> + mutex_init(&bus->mutex);
> bus->flags = pmac_i2c_multibus;
> list_add(&bus->link, &pmac_i2c_busses);
>
> @@ -921,7 +922,7 @@ static void __init smu_i2c_probe(void)
> bus->mode = pmac_i2c_mode_std;
> bus->hostdata = bus + 1;
> bus->xfer = smu_i2c_xfer;
> - init_MUTEX(&bus->sem);
> + mutex_init(&bus->mutex);
> bus->flags = 0;
> list_add(&bus->link, &pmac_i2c_busses);
>
> @@ -1093,13 +1094,13 @@ int pmac_i2c_open(struct pmac_i2c_bus *b
> {
> int rc;
>
> - down(&bus->sem);
> + mutex_lock(&bus->mutex);
> bus->polled = polled || pmac_i2c_force_poll;
> bus->opened = 1;
> bus->mode = pmac_i2c_mode_std;
> if (bus->open && (rc = bus->open(bus)) != 0) {
> bus->opened = 0;
> - up(&bus->sem);
> + mutex_unlock(&bus->mutex);
> return rc;
> }
> return 0;
> @@ -1112,7 +1113,7 @@ void pmac_i2c_close(struct pmac_i2c_bus
> if (bus->close)
> bus->close(bus);
> bus->opened = 0;
> - up(&bus->sem);
> + mutex_unlock(&bus->mutex);
> }
> EXPORT_SYMBOL_GPL(pmac_i2c_close);
>
>
^ permalink raw reply
* [PATCH] powermac i2c: use mutex
From: Johannes Berg @ 2007-07-03 23:01 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev list, Paul Mackerras
Convert the semaphores in low_i2c that are used as mutexes to real
mutexes.
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
---
arch/powerpc/platforms/powermac/low_i2c.c | 23 ++++++++++++-----------
1 file changed, 12 insertions(+), 11 deletions(-)
--- wireless-dev.orig/arch/powerpc/platforms/powermac/low_i2c.c 2007-07-04 00:42:08.267749881 +0200
+++ wireless-dev/arch/powerpc/platforms/powermac/low_i2c.c 2007-07-04 00:42:48.667749881 +0200
@@ -42,6 +42,7 @@
#include <linux/interrupt.h>
#include <linux/completion.h>
#include <linux/timer.h>
+#include <linux/mutex.h>
#include <asm/keylargo.h>
#include <asm/uninorth.h>
#include <asm/io.h>
@@ -84,7 +85,7 @@ struct pmac_i2c_bus
void *hostdata;
int channel; /* some hosts have multiple */
int mode; /* current mode */
- struct semaphore sem;
+ struct mutex mutex;
int opened;
int polled; /* open mode */
struct platform_device *platform_dev;
@@ -104,7 +105,7 @@ static LIST_HEAD(pmac_i2c_busses);
struct pmac_i2c_host_kw
{
- struct semaphore mutex; /* Access mutex for use by
+ struct mutex mutex; /* Access mutex for use by
* i2c-keywest */
void __iomem *base; /* register base address */
int bsteps; /* register stepping */
@@ -375,14 +376,14 @@ static void kw_i2c_timeout(unsigned long
static int kw_i2c_open(struct pmac_i2c_bus *bus)
{
struct pmac_i2c_host_kw *host = bus->hostdata;
- down(&host->mutex);
+ mutex_lock(&host->mutex);
return 0;
}
static void kw_i2c_close(struct pmac_i2c_bus *bus)
{
struct pmac_i2c_host_kw *host = bus->hostdata;
- up(&host->mutex);
+ mutex_unlock(&host->mutex);
}
static int kw_i2c_xfer(struct pmac_i2c_bus *bus, u8 addrdir, int subsize,
@@ -498,7 +499,7 @@ static struct pmac_i2c_host_kw *__init k
kfree(host);
return NULL;
}
- init_MUTEX(&host->mutex);
+ mutex_init(&host->mutex);
init_completion(&host->complete);
spin_lock_init(&host->lock);
init_timer(&host->timeout_timer);
@@ -571,7 +572,7 @@ static void __init kw_i2c_add(struct pma
bus->open = kw_i2c_open;
bus->close = kw_i2c_close;
bus->xfer = kw_i2c_xfer;
- init_MUTEX(&bus->sem);
+ mutex_init(&bus->mutex);
if (controller == busnode)
bus->flags = pmac_i2c_multibus;
list_add(&bus->link, &pmac_i2c_busses);
@@ -798,7 +799,7 @@ static void __init pmu_i2c_probe(void)
bus->mode = pmac_i2c_mode_std;
bus->hostdata = bus + 1;
bus->xfer = pmu_i2c_xfer;
- init_MUTEX(&bus->sem);
+ mutex_init(&bus->mutex);
bus->flags = pmac_i2c_multibus;
list_add(&bus->link, &pmac_i2c_busses);
@@ -921,7 +922,7 @@ static void __init smu_i2c_probe(void)
bus->mode = pmac_i2c_mode_std;
bus->hostdata = bus + 1;
bus->xfer = smu_i2c_xfer;
- init_MUTEX(&bus->sem);
+ mutex_init(&bus->mutex);
bus->flags = 0;
list_add(&bus->link, &pmac_i2c_busses);
@@ -1093,13 +1094,13 @@ int pmac_i2c_open(struct pmac_i2c_bus *b
{
int rc;
- down(&bus->sem);
+ mutex_lock(&bus->mutex);
bus->polled = polled || pmac_i2c_force_poll;
bus->opened = 1;
bus->mode = pmac_i2c_mode_std;
if (bus->open && (rc = bus->open(bus)) != 0) {
bus->opened = 0;
- up(&bus->sem);
+ mutex_unlock(&bus->mutex);
return rc;
}
return 0;
@@ -1112,7 +1113,7 @@ void pmac_i2c_close(struct pmac_i2c_bus
if (bus->close)
bus->close(bus);
bus->opened = 0;
- up(&bus->sem);
+ mutex_unlock(&bus->mutex);
}
EXPORT_SYMBOL_GPL(pmac_i2c_close);
^ permalink raw reply
* [PATCH 2/2] eHEA: Receive SKB Aggregation
From: Jan-Bernd Themann @ 2007-07-04 10:09 UTC (permalink / raw)
To: Jeff Garzik
Cc: Thomas Klein, Jan-Bernd Themann, netdev, linux-kernel, linux-ppc,
Christoph Raisch, Marcus Eder, Stefan Roscher
This patch enables the receive side processing to aggregate TCP packets within
the HEA device driver. It analyses the packets already received after an
interrupt arrived and forwards these as chains of SKBs for the same TCP
connection with modified header field. We have seen a lower CPU load and
improved throughput for small numbers of parallel TCP connections.
As this feature is considered as experimental it is switched off by default
and can be activated via a module parameter.
Some additional security checks have been added since the last posting.
Signed-off-by: Jan-Bernd Themann <themann@de.ibm.com>
---
drivers/net/ehea/ehea.h | 30 ++++
drivers/net/ehea/ehea_main.c | 324 +++++++++++++++++++++++++++++++++++++++++-
2 files changed, 348 insertions(+), 6 deletions(-)
diff --git a/drivers/net/ehea/ehea.h b/drivers/net/ehea/ehea.h
index 809e3f2..5a53b79 100644
--- a/drivers/net/ehea/ehea.h
+++ b/drivers/net/ehea/ehea.h
@@ -55,6 +55,7 @@
#define EHEA_MAX_ENTRIES_RQ3 16383
#define EHEA_MAX_ENTRIES_SQ 32767
#define EHEA_MIN_ENTRIES_QP 127
+#define EHEA_LRO_MAX_PKTS 60
#define EHEA_SMALL_QUEUES
#define EHEA_NUM_TX_QP 1
@@ -84,6 +85,8 @@
#define EHEA_RQ2_PKT_SIZE 1522
#define EHEA_L_PKT_SIZE 256 /* low latency */
+#define MAX_LRO_DESCRIPTORS 8
+
/* Send completion signaling */
/* Protection Domain Identifier */
@@ -340,6 +343,29 @@ struct ehea_q_skb_arr {
};
/*
+ * Large Receive Offload (LRO) descriptor for a tcp session
+ */
+struct ehea_lro {
+ struct sk_buff *parent;
+ struct sk_buff *last_skb;
+ struct iphdr *iph;
+ struct tcphdr *tcph;
+
+ u32 tcp_rcv_tsecr;
+ u32 tcp_rcv_tsval;
+ u32 tcp_ack;
+ u32 tcp_next_seq;
+ u32 skb_tot_frags_len;
+ u16 ip_tot_len;
+ u16 tcp_saw_tstamp; /* timestamps enabled */
+ u16 tcp_window;
+ u16 vlan_tag;
+ int skb_sg_cnt; /* counts aggregated skbs */
+ int vlan_packet;
+ int active;
+};
+
+/*
* Port resources
*/
struct ehea_port_res {
@@ -368,6 +394,9 @@ struct ehea_port_res {
u64 tx_packets;
u64 rx_packets;
u32 poll_counter;
+ struct ehea_lro lro[MAX_LRO_DESCRIPTORS];
+ u64 lro_desc;
+ struct port_stats p_state;
};
@@ -417,6 +446,7 @@ struct ehea_port {
u32 msg_enable;
u32 sig_comp_iv;
u32 state;
+ u32 lro_max_aggr;
u8 full_duplex;
u8 autoneg;
u8 num_def_qps;
diff --git a/drivers/net/ehea/ehea_main.c b/drivers/net/ehea/ehea_main.c
index f8c0908..5f889af 100644
--- a/drivers/net/ehea/ehea_main.c
+++ b/drivers/net/ehea/ehea_main.c
@@ -34,6 +34,7 @@
#include <linux/list.h>
#include <linux/if_ether.h>
#include <net/ip.h>
+#include <net/tcp.h>
#include "ehea.h"
#include "ehea_qmr.h"
@@ -52,6 +53,8 @@ static int rq2_entries = EHEA_DEF_ENTRIES_RQ2;
static int rq3_entries = EHEA_DEF_ENTRIES_RQ3;
static int sq_entries = EHEA_DEF_ENTRIES_SQ;
static int use_mcs = 0;
+static int use_lro = 0;
+static int lro_max_pkts = EHEA_LRO_MAX_PKTS;
static int num_tx_qps = EHEA_NUM_TX_QP;
module_param(msg_level, int, 0);
@@ -60,6 +63,8 @@ module_param(rq2_entries, int, 0);
module_param(rq3_entries, int, 0);
module_param(sq_entries, int, 0);
module_param(use_mcs, int, 0);
+module_param(use_lro, int, 0);
+module_param(lro_max_pkts, int, 0);
module_param(num_tx_qps, int, 0);
MODULE_PARM_DESC(num_tx_qps, "Number of TX-QPS");
@@ -77,6 +82,10 @@ MODULE_PARM_DESC(sq_entries, " Number of entries for the Send Queue "
"[2^x - 1], x = [6..14]. Default = "
__MODULE_STRING(EHEA_DEF_ENTRIES_SQ) ")");
MODULE_PARM_DESC(use_mcs, " 0:NAPI, 1:Multiple receive queues, Default = 1 ");
+MODULE_PARM_DESC(lro_max_pkts, " LRO: Max packets to be aggregated. Default = "
+ __MODULE_STRING(EHEA_LRO_MAX_PKTS));
+MODULE_PARM_DESC(use_lro, " Large Receive Offload, 1: enable, 0: disable, "
+ "Default = 0");
static int port_name_cnt = 0;
@@ -380,6 +389,297 @@ static int ehea_treat_poll_error(struct ehea_port_res *pr, int rq,
return 0;
}
+static int try_get_ip_tcp_hdr(struct ehea_cqe *cqe, struct sk_buff *skb,
+ struct iphdr **iphdr, struct tcphdr **tcph)
+{
+ unsigned int ip_hdrlength;
+ struct iphdr *iph;
+
+ /* non tcp/udp packets */
+ if (!cqe->header_length)
+ return -1;
+
+ /* non tcp packet */
+ skb_reset_network_header(skb);
+ iph = ip_hdr(skb);
+ if (iph->protocol != IPPROTO_TCP)
+ return -1;
+
+ ip_hdrlength = ip_hdrlen(skb);
+
+ /* check ip header: packet length */
+ if (iph->tot_len > cqe->num_bytes_transfered - ETH_HLEN)
+ return -1;
+
+ /* check ip header: minimal ip header received */
+ if (ip_hdrlength > iph->tot_len - 20)
+ return -1;
+
+ skb_set_transport_header(skb, ip_hdrlength);
+ *tcph = tcp_hdr(skb);
+
+ /* check if ip header and tcp header are complete */
+ if (iph->tot_len < ip_hdrlength + tcp_hdrlen(skb))
+ return -1;
+
+ *iphdr = iph;
+ return 0;
+}
+
+#define TCP_PAYLOAD_LENGTH(iph, tcph) \
+(ntohs(iph->tot_len) - (iph->ihl << 2) - (tcph->doff << 2))
+
+#define IPH_LEN_WO_OPTIONS 5
+#define TCPH_LEN_WO_OPTIONS 5
+#define TCPH_LEN_W_TIMESTAMP 8
+
+static int lro_tcp_check(struct iphdr *iph, struct tcphdr *tcph,
+ int tcp_data_len, struct ehea_lro *lro)
+{
+ if (tcp_data_len == 0)
+ return -1;
+
+ if (iph->ihl != IPH_LEN_WO_OPTIONS)
+ return -1;
+
+ if (tcph->cwr || tcph->ece || tcph->urg || !tcph->ack || tcph->psh
+ || tcph->rst || tcph->syn || tcph->fin)
+ return -1;
+
+ if (INET_ECN_is_ce(ipv4_get_dsfield(iph)))
+ return -1;
+
+ if (tcph->doff != TCPH_LEN_WO_OPTIONS
+ && tcph->doff != TCPH_LEN_W_TIMESTAMP)
+ return -1;
+
+ /* check tcp options (only timestamp allowed) */
+ if (tcph->doff == TCPH_LEN_W_TIMESTAMP) {
+ u32 *topt = (u32 *)(tcph + 1);
+
+ if (*topt != htonl((TCPOPT_NOP << 24) | (TCPOPT_NOP << 16)
+ | (TCPOPT_TIMESTAMP << 8) | TCPOLEN_TIMESTAMP))
+ return -1;
+
+ /* timestamp should be in right order */
+ topt++;
+ if (lro && (ntohl(lro->tcp_rcv_tsval) > ntohl(*topt)))
+ return -1;
+
+ /* timestamp reply should not be zero */
+ topt++;
+ if (*topt == 0)
+ return -1;
+ }
+
+ return 0;
+}
+
+static void update_tcp_ip_header(struct ehea_lro *lro)
+{
+ struct iphdr *iph = lro->iph;
+ struct tcphdr *tcph = lro->tcph;
+ u32 *p;
+
+ tcph->ack_seq = lro->tcp_ack;
+ tcph->window = lro->tcp_window;
+
+ if (lro->tcp_saw_tstamp) {
+ p = (u32 *)(tcph + 1);
+ *(p+2) = lro->tcp_rcv_tsecr;
+ }
+
+ iph->tot_len = htons(lro->ip_tot_len);
+ iph->check = 0;
+ iph->check = ip_fast_csum((u8 *)lro->iph, iph->ihl);
+}
+
+static void init_lro_desc(struct ehea_lro *lro, struct ehea_cqe *cqe,
+ struct sk_buff *skb, struct iphdr *iph,
+ struct tcphdr *tcph, u32 tcp_data_len)
+{
+ u32 *ptr;
+
+ lro->parent = skb;
+ lro->iph = iph;
+ lro->tcph = tcph;
+ lro->tcp_next_seq = ntohl(tcph->seq) + tcp_data_len;
+ lro->tcp_ack = ntohl(tcph->ack_seq);
+
+ lro->skb_sg_cnt = 1;
+ lro->ip_tot_len = ntohs(iph->tot_len);
+
+ if (tcph->doff == 8) {
+ ptr = (u32 *)(tcph+1);
+ lro->tcp_saw_tstamp = 1;
+ lro->tcp_rcv_tsval = *(ptr+1);
+ lro->tcp_rcv_tsecr = *(ptr+2);
+ }
+
+ if (cqe->status & EHEA_CQE_VLAN_TAG_XTRACT) {
+ lro->vlan_packet = 1;
+ lro->vlan_tag = cqe->vlan_tag;
+ }
+
+ lro->active = 1;
+}
+
+static inline void clear_lro_desc(struct ehea_lro *lro)
+{
+ memset(lro, 0, sizeof(struct ehea_lro));
+}
+
+static void lro_add_packet(struct ehea_lro *lro, struct sk_buff *skb,
+ struct tcphdr *tcph, u32 tcp_len)
+{
+ struct sk_buff *parent = lro->parent;
+ u32 *topt;
+
+ lro->skb_sg_cnt++;
+
+ lro->ip_tot_len += tcp_len;
+ lro->tcp_next_seq += tcp_len;
+ lro->tcp_window = lro->tcph->window;
+ lro->tcp_ack = lro->tcph->ack_seq;
+
+ if (lro->tcp_saw_tstamp) {
+ topt = (u32 *) (tcph + 1);
+ lro->tcp_rcv_tsval = *(topt + 1);
+ lro->tcp_rcv_tsecr = *(topt + 2);
+ }
+
+ parent->len += tcp_len;
+ parent->data_len += tcp_len;
+
+ skb_pull(skb, (skb->len - tcp_len));
+ parent->truesize += skb->truesize;
+
+ if (lro->last_skb)
+ lro->last_skb->next = skb;
+ else
+ skb_shinfo(parent)->frag_list = skb;
+
+ lro->last_skb = skb;
+
+ return;
+}
+
+static int check_tcp_conn(struct ehea_lro *lro, struct iphdr *iph,
+ struct tcphdr *tcph)
+{
+ if ((lro->iph->saddr != iph->saddr) || (lro->iph->daddr != iph->daddr) ||
+ (lro->tcph->source != tcph->source) || (lro->tcph->dest != tcph->dest))
+ return -1;
+ return 0;
+}
+
+static void flush_lro(struct ehea_port_res *pr, struct ehea_lro *lro)
+{
+ update_tcp_ip_header(lro);
+
+ if (lro->vlan_packet && pr->port->vgrp)
+ vlan_hwaccel_receive_skb(lro->parent, pr->port->vgrp,
+ lro->vlan_tag);
+ else
+ netif_receive_skb(lro->parent);
+
+ clear_lro_desc(lro);
+}
+
+static void flush_all_lro(struct ehea_port_res *pr)
+{
+ int i;
+ struct ehea_lro *lro;
+
+ for (i = 0; i < MAX_LRO_DESCRIPTORS; i++) {
+ lro = &pr->lro[i];
+ if (lro->active)
+ flush_lro(pr, lro);
+ }
+}
+
+static struct ehea_lro *ehea_get_lro(struct ehea_port_res *pr,
+ struct iphdr *iph, struct tcphdr *tcph)
+{
+ struct ehea_lro *lro = NULL;
+ struct ehea_lro *tmp;
+ int i;
+
+ for (i = 0; i < MAX_LRO_DESCRIPTORS; i++) {
+ tmp = &pr->lro[i];
+ if (tmp->active)
+ if (!check_tcp_conn(tmp, iph, tcph)) {
+ lro = tmp;
+ goto out;
+ }
+ }
+
+ for (i = 0; i < MAX_LRO_DESCRIPTORS; i++) {
+ if(!pr->lro[i].active) {
+ lro = &pr->lro[i];
+ goto out;
+ }
+ }
+
+out:
+ return lro;
+}
+
+static void ehea_proc_skb(struct ehea_port_res *pr, struct ehea_cqe *cqe,
+ struct sk_buff *skb)
+{
+ struct iphdr *iph;
+ struct tcphdr *tcph;
+ struct ehea_lro *lro;
+ int tcp_data_len;
+ int skip_orig_skb = 0;
+
+ if (use_lro) {
+ if (try_get_ip_tcp_hdr(cqe, skb, &iph, &tcph))
+ goto out;
+
+ lro = ehea_get_lro(pr, iph, tcph);
+ if (!lro)
+ goto out;
+
+ tcp_data_len = TCP_PAYLOAD_LENGTH(iph, tcph);
+
+ if (!lro->active) {
+ if (lro_tcp_check(iph, tcph, tcp_data_len, NULL))
+ goto out;
+
+ init_lro_desc(lro, cqe, skb, iph, tcph, tcp_data_len);
+ return;
+ }
+
+ if (lro->tcp_next_seq != ntohl(tcph->seq)) {
+ flush_lro(pr, lro);
+ goto out;
+ }
+
+ if (lro_tcp_check(iph, tcph, tcp_data_len, lro)) {
+ flush_lro(pr, lro);
+ goto out;
+ }
+
+ lro_add_packet(lro, skb, tcph, tcp_data_len);
+
+ if (lro->skb_sg_cnt > pr->port->lro_max_aggr)
+ flush_lro(pr, lro);
+
+ skip_orig_skb = 1;
+ }
+
+out:
+ if (skip_orig_skb)
+ return;
+
+ if ((cqe->status & EHEA_CQE_VLAN_TAG_XTRACT) && pr->port->vgrp)
+ vlan_hwaccel_receive_skb(skb, pr->port->vgrp, cqe->vlan_tag);
+ else
+ netif_receive_skb(skb);
+}
+
static struct ehea_cqe *ehea_proc_rwqes(struct net_device *dev,
struct ehea_port_res *pr,
int *budget)
@@ -426,6 +726,7 @@ static struct ehea_cqe *ehea_proc_rwqes(struct net_device *dev,
if (!skb)
break;
}
+ skb_reserve(skb, NET_IP_ALIGN);
skb_copy_to_linear_data(skb, ((char*)cqe) + 64,
cqe->num_bytes_transfered - 4);
ehea_fill_skb(port->netdev, skb, cqe);
@@ -451,12 +752,7 @@ static struct ehea_cqe *ehea_proc_rwqes(struct net_device *dev,
processed_rq3++;
}
- if ((cqe->status & EHEA_CQE_VLAN_TAG_XTRACT)
- && port->vgrp)
- vlan_hwaccel_receive_skb(skb, port->vgrp,
- cqe->vlan_tag);
- else
- netif_receive_skb(skb);
+ ehea_proc_skb(pr, cqe, skb);
} else {
pr->p_stats.poll_receive_errors++;
port_reset = ehea_treat_poll_error(pr, rq, cqe,
@@ -468,6 +764,9 @@ static struct ehea_cqe *ehea_proc_rwqes(struct net_device *dev,
cqe = ehea_poll_rq1(qp, &wqe_index);
}
+ if (use_lro)
+ flush_all_lro(pr);
+
pr->rx_packets += processed;
*budget -= processed;
@@ -1684,9 +1983,15 @@ out:
static int ehea_change_mtu(struct net_device *dev, int new_mtu)
{
+ struct ehea_port *port = netdev_priv(dev);
+
if ((new_mtu < 68) || (new_mtu > EHEA_MAX_PACKET_SIZE))
return -EINVAL;
dev->mtu = new_mtu;
+
+ if (use_lro)
+ port->lro_max_aggr = (0xFFFF / new_mtu);
+
return 0;
}
@@ -2491,6 +2796,7 @@ struct ehea_port *ehea_setup_single_port(struct ehea_adapter *adapter,
struct ehea_port *port;
struct device *port_dev;
int jumbo;
+ int lro_pkts;
/* allocate memory for the port structures */
dev = alloc_etherdev(sizeof(struct ehea_port));
@@ -2565,6 +2871,12 @@ struct ehea_port *ehea_setup_single_port(struct ehea_adapter *adapter,
goto out_unreg_port;
}
+ lro_pkts = (0xFFFF / dev->mtu);
+ if (lro_pkts < lro_max_pkts)
+ port->lro_max_aggr = lro_pkts;
+ else
+ port->lro_max_aggr = lro_max_pkts;
+
ret = ehea_get_jumboframe_status(port, &jumbo);
if (ret)
ehea_error("failed determining jumbo frame status for %s",
--
1.5.2
^ permalink raw reply related
* [PATCH 1/2] eHEA: Capability flag for DLPAR support
From: Jan-Bernd Themann @ 2007-07-04 10:09 UTC (permalink / raw)
To: Jeff Garzik
Cc: Thomas Klein, Jan-Bernd Themann, netdev, linux-kernel, linux-ppc,
Christoph Raisch, Marcus Eder, Stefan Roscher
This patch introduces a capability flag that is used by the DLPAR userspace
tool to check which DLPAR features are supported by the eHEA driver.
Signed-off-by: Jan-Bernd Themann <themann@de.ibm.com>
---
drivers/net/ehea/ehea.h | 8 +++++++-
drivers/net/ehea/ehea_main.c | 17 +++++++++++++++++
2 files changed, 24 insertions(+), 1 deletions(-)
diff --git a/drivers/net/ehea/ehea.h b/drivers/net/ehea/ehea.h
index abaf3ac..809e3f2 100644
--- a/drivers/net/ehea/ehea.h
+++ b/drivers/net/ehea/ehea.h
@@ -39,7 +39,13 @@
#include <asm/io.h>
#define DRV_NAME "ehea"
-#define DRV_VERSION "EHEA_0065"
+#define DRV_VERSION "EHEA_0066"
+
+/* EHEA capability flags */
+#define DLPAR_PORT_ADD_REM 1
+#define DLPAR_MEM_ADD 2
+#define DLPAR_MEM_REM 4
+#define EHEA_CAPABILITIES (DLPAR_PORT_ADD_REM)
#define EHEA_MSG_DEFAULT (NETIF_MSG_LINK | NETIF_MSG_TIMER \
| NETIF_MSG_RX_ERR | NETIF_MSG_TX_ERR)
diff --git a/drivers/net/ehea/ehea_main.c b/drivers/net/ehea/ehea_main.c
index bdb5241..f8c0908 100644
--- a/drivers/net/ehea/ehea_main.c
+++ b/drivers/net/ehea/ehea_main.c
@@ -2923,6 +2923,15 @@ static int check_module_parm(void)
return ret;
}
+static ssize_t ehea_show_capabilities(struct device_driver *drv,
+ char *buf)
+{
+ return sprintf(buf, "%d", EHEA_CAPABILITIES);
+}
+
+static DRIVER_ATTR(capabilities, S_IRUSR | S_IRGRP | S_IROTH,
+ ehea_show_capabilities, NULL);
+
int __init ehea_module_init(void)
{
int ret;
@@ -2937,12 +2946,20 @@ int __init ehea_module_init(void)
if (ret)
ehea_error("failed registering eHEA device driver on ebus");
+ ret = driver_create_file(&ehea_driver.driver, &driver_attr_capabilities);
+ if (ret) {
+ ehea_error("failed to register capabilities attribute, ret=%d", ret);
+ ibmebus_unregister_driver(&ehea_driver);
+ goto out;
+ }
+
out:
return ret;
}
static void __exit ehea_module_exit(void)
{
+ driver_remove_file(&ehea_driver.driver, &driver_attr_capabilities);
ibmebus_unregister_driver(&ehea_driver);
}
--
1.5.2
^ permalink raw reply related
* Re: Mem-2-Mem DMA - Generalized API
From: Clemens Koller @ 2007-07-04 10:11 UTC (permalink / raw)
To: Clifford Wolf; +Cc: linuxppc-embedded
In-Reply-To: <20070704090554.GA30693@clifford.at>
Clifford Wolf schrieb:
> On Mon, Jun 25, 2007 at 08:01:10PM +0200, Clifford Wolf wrote:
>> I've put a 'draft header file' of an api as I would have expected it
>> online: [...]
>
> Ok, so here comes the first implementation:
> (I also have other projects, so it took a while.. ;-)
>
> http://www.clifford.at/priv/dmatransfer-20070704.diff
>
> This is just for the MPC8349 DMA now, registers are still hardcoded in the
> driver instead of beeing taken from the platform files and support for
> scatter-gather is still missing and the Kconfig integration isn't checking
> if we are building for the mpc8349 (or even ppc) yet. But I think the
> direction of the API is pretty clear.
That looks good. It should be useful on other PowerQUICC's DMA engines
and maybe even for the MPC5200 BestComm, too, with some changes.
> The patch also contains a hackish demo client (dma_demo_client.ko) which is
> performing some dma transfers in the 256th MB of physical memory. So it
> should only be used on a machine with 256MB of memory bootet with mem=255M
> (but changing that should be trivial). The demo client shows well how the
> API works and how much overhead the API adds.
>
> Any feedback this time?
Sorry, I'm currently busy with some hardware design work.
But if you want to test some code, I can get you an SSH account on my
MPC8540 platform.
Best regards,
--
Clemens Koller
__________________________________
R&D Imaging Devices
Anagramm GmbH
Rupert-Mayer-Straße 45/1
Linhof Werksgelände
D-81379 München
Tel.089-741518-50
Fax 089-741518-19
http://www.anagramm-technology.com
^ permalink raw reply
* Re: Mem-2-Mem DMA - Generalized API
From: Clifford Wolf @ 2007-07-04 9:05 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <20070625180110.GH20463@clifford.at>
Hi,
On Mon, Jun 25, 2007 at 08:01:10PM +0200, Clifford Wolf wrote:
> I've put a 'draft header file' of an api as I would have expected it
> online: [...]
Ok, so here comes the first implementation:
(I also have other projects, so it took a while.. ;-)
http://www.clifford.at/priv/dmatransfer-20070704.diff
This is just for the MPC8349 DMA now, registers are still hardcoded in the
driver instead of beeing taken from the platform files and support for
scatter-gather is still missing and the Kconfig integration isn't checking
if we are building for the mpc8349 (or even ppc) yet. But I think the
direction of the API is pretty clear.
The patch also contains a hackish demo client (dma_demo_client.ko) which is
performing some dma transfers in the 256th MB of physical memory. So it
should only be used on a machine with 256MB of memory bootet with mem=255M
(but changing that should be trivial). The demo client shows well how the
API works and how much overhead the API adds.
Any feedback this time?
yours,
- clifford
--
#!/usr/bin/perl
$p="1"x1002;for$c(2..1000){if($p=~/^.{$c}0/){next;};printf"%3d\%s",
$c,++$x%14?" ":"\n";while($p=~s/^((.{$c})+)1/${1}0/){}}$_="lPSFZQ".
"SJNFTZBUZ<IUUQ:;;XXX.DMJGGPSE.BU;QSJNF;>\n";y:B-Zl;:a-x M/:;print;
^ permalink raw reply
* RE: [PATCH] ucc_geth.c, make PHY device optional.
From: Joakim Tjernlund @ 2007-07-04 8:50 UTC (permalink / raw)
To: Li Yang-r58472; +Cc: linuxppc-dev Development, Netdev
In-Reply-To: <989B956029373F45A0B8AF0297081890D8385E@zch01exm26.fsl.freescale.net>
On Tue, 2007-07-03 at 19:38 +0800, Li Yang-r58472 wrote:
> > -----Original Message-----
> > From: Joakim Tjernlund [mailto:joakim.tjernlund@transmode.se]
> > Sent: Tuesday, July 03, 2007 7:20 PM
> > To: Li Yang-r58472
> > Cc: linuxppc-dev Development; Netdev; Fleming Andy-afleming
> > Subject: RE: [PATCH] ucc_geth.c, make PHY device optional.
> >
> > On Tue, 2007-07-03 at 16:22 +0800, Li Yang-r58472 wrote:
> > > > -----Original Message-----
> > > > From: Joakim Tjernlund [mailto:joakim.tjernlund@transmode.se]
> > > > Sent: Tuesday, July 03, 2007 3:21 PM
> > > > To: Li Yang-r58472
> > > > Cc: linuxppc-dev Development; Netdev; Fleming Andy-afleming
> > > > Subject: RE: [PATCH] ucc_geth.c, make PHY device optional.
> > > >
> > > > On Tue, 2007-07-03 at 11:42 +0800, Li Yang-r58472 wrote:
> > > > > > -----Original Message-----
> > > > > > From: netdev-owner@vger.kernel.org
> > > > > [mailto:netdev-owner@vger.kernel.org] On
> > > > > > Behalf Of Joakim Tjernlund
> > > > > > Sent: Tuesday, July 03, 2007 8:52 AM
> > > > > > To: 'linuxppc-dev Development'; 'Netdev'; Li Yang-r58472
> > > > > > Subject: [PATCH] ucc_geth.c, make PHY device optional.
> > > > > >
> > > > > > > This patch makes the PHY optional for ucc_geth.c ethernet
> > > driver.
> > > > > > > This is useful to support a direct mii to mii connection to,
> for
> > > > > example,
> > > > > > > a onboard swicth.
> > > > > > >
> > > > > > > Signed-off-by: Joakim Tjernlund
> <joakim.tjernlund@transmode.se>
> > > > > > ----
> > > > > Hi Joakim,
> > > > >
> > > > > I'm wondering if we really need to have the option to disable
> > > phylib.
> > > >
> > > > maybe, but it has to be dynamic too. I need to use PHY on UCC2 and
> mii
> > > > on UCC3 and UCC4.
> > > >
> > > > > Actually we have made phylib selected by default for ucc_geth.
> Many
> > > L2
> > > > > switch chips have the capacity to be controlled. Therefore they
> can
> > > be
> > > > > managed as a phy device.
> > > >
> > > > Yes, they can be but why force a PHY impl. when its is of no use?
> The
> > > > only thing the eth driver needs from the it is speed and duplex.
> If
> > > > these are fixed, you don't need to talk with a PHY.
> > >
> > > The driver needs to get and set the link speed/status on runtime
> (such
> > > as for ethtool interface). Currently this is implementation through
> > > phydev interface. IMHO, it will be easier to maintain if we only
> use
> > > this standard interface, rather than use different interfaces for
> > > different cases.
> >
> > hmm maybe, but there is no need to much around with speed/status
> > from user space. The speed and duplex must be set before user space
> > is up.
> >
> > >
> > > >
> > > > > For the MII interface which is not
> > > > > configurable, shouldn't we use the fixed phy support from
> Vitaly?
> > > >
> > > > Well, I think the the fixed phy is great when your eth driver
> requires
> > > a
> > > > PHY, but it is a workaround with extra processing overhead. IMHO
> the
> > > > best impl. is to make the PHY optional in the eth driver and as
> you
> > > can
> > > > see from the patch, that was really simple.
> > >
> > > I agree there is overhead. However, it will have the advantage of
> > > abstracting all the PHY related stuff out of controller driver.
> > >
> > > >
> > > > An useful extension would be to add a new propety in the DTS to
> hold
> > > > initial speed and duplex(perhaps extend phy-connection-type). This
> > > > would be useful for the fixed driver too as one could derive speed
> and
> > > > duplex for the fixed phy from that property instead of creating a
> > > fixed
> > > > phy for each speed and duplex one want to support.
> > >
> > > I agree that there should be a device node to configure it. The
> current
> > > fixed phy driver is a little bit too complex to emulate the register
> > > access. Maybe it's better to have a null phy driver which just
> reads
> > > PHY capacity and status from device node.
> >
> > A null phy driver is better than the current fixed phy, I agree.
> > Where would you like to put initial speed and duplex? In a fake phy
> node
> > or in the ethernet node?
>
> I think a fake phy node is better.
>
> - Leo
OK, but then a new property in PHY node is needed which holds
the initial speed and duplex.
initial-phy-capacity = <speed duplex> ?
This should be useful for real PHYs too if, for instance, autoneg isn't
working/supported/wanted.
Maybe it should be:
initial-phy-capacity = <speed duplex autoneg>
or
initial-phy-capability = <speed duplex autoneg>
Jocke
^ permalink raw reply
* Re: about FCC of MPC8270
From: li.chunlin @ 2007-07-04 7:50 UTC (permalink / raw)
To: matvejchikov; +Cc: linuxppc-embedded
In-Reply-To: <8496f91a0707040002w6e036024i7c22fdd01c0c21d8@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2017 bytes --]
Not ok with 0x3000
"Matvejchikov Ilya" <matvejchikov@gmail.com>
收件人： "li.chunlin@zte.com.cn" <li.chunlin@zte.com.cn>
抄送： linuxppc-embedded@ozlabs.org
主题： Re: about FCC of MPC8270
Try 0x3000
2007/7/4, li.chunlin@zte.com.cn <li.chunlin@zte.com.cn>:
>
> I use it. And it is: #define CPM_FCC_SPECIAL_BASE ((uint)0x0000b000)
>
>
>
>
> Hi!
>
> Do you use CPM_FCC_SPECIAL_BASE constant? (include/asm-ppc/cpm2.h)
> In my case (8250, 8260) FCCs only works when it is set to 0x3000...
>
>
> 2007/7/4, li.chunlin@zte.com.cn <li.chunlin@zte.com.cn>:
> >
> > hello, every one
> >
> > I have a board with mpc8270. And there are two ethernet interface
by
> fcc1
> > and fcc2. Now in linux kernel 2.6.14 fcc1 is ok, but fcc2 is some
wrong.
> I
> > set loopback of fcc2 or rmii. that's ok. But i set loopback in phy,
it is
> > wrong. But fcc2 is ok in u-boot.
> >
> > I take a look with oscillograph. i find that there is signal from
fcc2 to
> > phy and there is signal from phy to fcc2 in data pins. But fcc2
cannot
> > receive data and fcc2 can send data.
> >
> > who know the reason? Can you tell me?
> >
> > thanks.
> > lichunlin
> >
--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.
[-- Attachment #2: Type: text/html, Size: 3572 bytes --]
^ permalink raw reply
* Re: about FCC of MPC8270
From: Matvejchikov Ilya @ 2007-07-04 7:02 UTC (permalink / raw)
To: li.chunlin@zte.com.cn; +Cc: linuxppc-embedded
In-Reply-To: <OF0D7C4044.9BAD3D4B-ON4825730E.0025DB9D-4825730E.002615DC@zte.com.cn>
Try 0x3000
2007/7/4, li.chunlin@zte.com.cn <li.chunlin@zte.com.cn>:
>
> I use it. And it is: #define CPM_FCC_SPECIAL_BASE ((uint)0x0000b000)
>
>
>
>
> Hi!
>
> Do you use CPM_FCC_SPECIAL_BASE constant? (include/asm-ppc/cpm2.h)
> In my case (8250, 8260) FCCs only works when it is set to 0x3000...
>
>
> 2007/7/4, li.chunlin@zte.com.cn <li.chunlin@zte.com.cn>:
> >
> > hello, every one
> >
> > I have a board with mpc8270. And there are two ethernet interface by
> fcc1
> > and fcc2. Now in linux kernel 2.6.14 fcc1 is ok, but fcc2 is some wrong.
> I
> > set loopback of fcc2 or rmii. that's ok. But i set loopback in phy, it is
> > wrong. But fcc2 is ok in u-boot.
> >
> > I take a look with oscillograph. i find that there is signal from fcc2 to
> > phy and there is signal from phy to fcc2 in data pins. But fcc2 cannot
> > receive data and fcc2 can send data.
> >
> > who know the reason? Can you tell me?
> >
> > thanks.
> > lichunlin
> >
^ permalink raw reply
* Re: about FCC of MPC8270
From: li.chunlin @ 2007-07-04 6:55 UTC (permalink / raw)
To: matvejchikov; +Cc: linuxppc-embedded
In-Reply-To: <8496f91a0707032242w40c0f398s87ab5a9249c0e902@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1573 bytes --]
I use it. And it is: #define CPM_FCC_SPECIAL_BASE ((uint)0x0000b000)
Hi!
Do you use CPM_FCC_SPECIAL_BASE constant? (include/asm-ppc/cpm2.h)
In my case (8250, 8260) FCCs only works when it is set to 0x3000...
2007/7/4, li.chunlin@zte.com.cn <li.chunlin@zte.com.cn>:
>
> hello, every one
>
> I have a board with mpc8270. And there are two ethernet interface by
fcc1
> and fcc2. Now in linux kernel 2.6.14 fcc1 is ok, but fcc2 is some wrong.
I
> set loopback of fcc2 or rmii. that's ok. But i set loopback in phy, it
is
> wrong. But fcc2 is ok in u-boot.
>
> I take a look with oscillograph. i find that there is signal from fcc2
to
> phy and there is signal from phy to fcc2 in data pins. But fcc2 cannot
> receive data and fcc2 can send data.
>
> who know the reason? Can you tell me?
>
> thanks.
> lichunlin
>
--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.
[-- Attachment #2: Type: text/html, Size: 2393 bytes --]
^ permalink raw reply
* Too many spurious interrupts on mpc82xx with linux-2.4.35.5
From: Matvejchikov Ilya @ 2007-07-04 5:51 UTC (permalink / raw)
To: linuxppc-embedded
Hi all!
If you still have this problem, try this patch. It helps :)
Signed-off-by : Matvejchikov Ilya <matvejchikov@gmail.com>
---
diff -purN linux-2.4.34.5-vanilla/arch/ppc/kernel/cpm2_pic.c
linux-2.4.34.5/arch/ppc/kernel/cpm2_pic.c
--- linux-2.4.34.5-vanilla/arch/ppc/kernel/cpm2_pic.c 2007-06-06
23:20:53.000000000 +0400
+++ linux-2.4.34.5/arch/ppc/kernel/cpm2_pic.c 2007-06-28
12:17:42.000000000 +0400
@@ -79,6 +79,12 @@ static void cpm2_mask_and_ack(unsigned i
ppc_cached_irq_mask[word] &= ~(1 << (31 - bit));
simr[word] = ppc_cached_irq_mask[word];
sipnr[word] = 1 << (31 - bit);
+
+ /*
+ * Work around large numbers of spurious IRQs on PowerPC 82xx
+ * systems.
+ */
+ mb();
}
static void cpm2_end_irq(unsigned int irq_nr)
^ permalink raw reply
* Re: about FCC of MPC8270
From: Matvejchikov Ilya @ 2007-07-04 5:42 UTC (permalink / raw)
To: li.chunlin@zte.com.cn; +Cc: linuxppc-embedded
In-Reply-To: <OF067D5541.23C80493-ON4825730E.001766FC-4825730E.00183FCF@zte.com.cn>
Hi!
Do you use CPM_FCC_SPECIAL_BASE constant? (include/asm-ppc/cpm2.h)
In my case (8250, 8260) FCCs only works when it is set to 0x3000...
2007/7/4, li.chunlin@zte.com.cn <li.chunlin@zte.com.cn>:
>
> hello, every one
>
> I have a board with mpc8270. And there are two ethernet interface by fcc1
> and fcc2. Now in linux kernel 2.6.14 fcc1 is ok, but fcc2 is some wrong. I
> set loopback of fcc2 or rmii. that's ok. But i set loopback in phy, it is
> wrong. But fcc2 is ok in u-boot.
>
> I take a look with oscillograph. i find that there is signal from fcc2 to
> phy and there is signal from phy to fcc2 in data pins. But fcc2 cannot
> receive data and fcc2 can send data.
>
> who know the reason? Can you tell me?
>
> thanks.
> lichunlin
>
^ permalink raw reply
* RE: [PATCH 2.6.23] 83xx USB platform code rework
From: Li Yang-r58472 @ 2007-07-04 5:35 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: linuxppc-dev, paulus
In-Reply-To: <20070704141514.cc77369f.sfr@canb.auug.org.au>
> -----Original Message-----
> From: Stephen Rothwell [mailto:sfr@canb.auug.org.au]
> Sent: Wednesday, July 04, 2007 12:15 PM
> To: Li Yang-r58472
> Cc: paulus@samba.org; galak@kernel.crashing.org;
linuxppc-dev@ozlabs.org
> Subject: Re: [PATCH 2.6.23] 83xx USB platform code rework
>=20
> Hi Li,
>=20
> On Tue, 3 Jul 2007 17:43:16 +0800 Li Yang <leoli@freescale.com>
wrote:
> >
> > Add 831x USB platform setup code and rework 834x USB
> > platform setup code. Move USB platform code to usb.c
> > for different boards with CPU of the same series to share
> > the USB initialization code.
>=20
> If there really is a part of this that is just code movement, then
that
> should be split out into a separate patch. It makes the reviewers job
so
> much easier.
Actually, it is not pure code movement. The code has been re-written.
- Leo
^ permalink raw reply
* Re: [PATCH] powerpc: Add of_register_i2c_devices()
From: Guennadi Liakhovetski @ 2007-07-04 5:28 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev, Paul Mackerras, i2c
In-Reply-To: <E0E696F1-2F9E-4D6B-A194-EB42BA826BCD@kernel.crashing.org>
On Wed, 4 Jul 2007, Segher Boessenkool wrote:
> Your device is an rs5c372b. So, that's what you put in
> your device tree. Simple so far, right?
Yep.
> Now some OF I2C code goes looking for IIC devices in the
> device tree. It finds this thing, and from a table or
> something it derives that it has to tell the kernel I2C
> layer this is an "rtc-rs5c372".
(I2C ML cc'ed.)
This is where I WOULD disagree. These tables would rather live inside the
i2c layer, be filled by respective drivers themselves. Noone except the
rs5c372 driver can know which devices it can handle. Using the very same
your argument - what if in a future version this driver disappears and
another one will be used for these devices? Then that driver will have to
register support for this device.
For this to work i2c would need something similar to what pci, usb do -
register supported device ids. The only difference is that instead of
numerical IDs we have to use plain text names for i2c devices...
> [It would be nicer if it
> could just instantiate the correct driver directly, but
> if that's how the Linux I2C layer works, so be it].
>
> No change in the I2C "core" needed, just an OF "compatible"
> matching thing like is needed *everywhere else* too.
Yes, this is why I put "would". Looks like this is the common powerpc
practice ATM - to make such a glue to map arbitrary "OF names" to what
respective drivers react to. Like in the case of the serial driver. But -
i2c is much more diverse and dynamic than serial, so, maybe it is worth
thinking about "fixing" i2c? Once again my offer for the i2c folks - I
could try to think about a design for this, but I would happily accept
anybody else more proficient with i2c do it.
Thanks
Guennadi
---
Guennadi Liakhovetski
^ permalink raw reply
* Re: [PATCH 2/3] Modify sched_clock() to make CONFIG_PRINTK_TIME more sane.
From: Tony Breeds @ 2007-07-04 4:40 UTC (permalink / raw)
To: Michael Ellerman; +Cc: linuxppc-dev
In-Reply-To: <1183523268.26479.0.camel@concordia.ozlabs.ibm.com>
On Wed, Jul 04, 2007 at 02:27:48PM +1000, Michael Ellerman wrote:
> Is this what other archs do?
They either use jiffies, or AFAICT an external counter that is
initialised to 0 at system powerup.
Yours Tony
linux.conf.au http://linux.conf.au/ || http://lca2008.linux.org.au/
Jan 28 - Feb 02 2008 The Australian Linux Technical Conference!
^ permalink raw reply
* about FCC of MPC8270
From: li.chunlin @ 2007-07-04 4:24 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <4b73d43f0707030931v42aefc72x2598546e48ae87e8@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1266 bytes --]
hello, every one
I have a board with mpc8270. And there are two ethernet interface by
fcc1 and fcc2. Now in linux kernel 2.6.14 fcc1 is ok, but fcc2 is some
wrong. I set loopback of fcc2 or rmii. that's ok. But i set loopback in
phy, it is wrong. But fcc2 is ok in u-boot.
I take a look with oscillograph. i find that there is signal from fcc2 to
phy and there is signal from phy to fcc2 in data pins. But fcc2 cannot
receive data and fcc2 can send data.
who know the reason? Can you tell me?
thanks.
lichunlin
--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.
[-- Attachment #2: Type: text/html, Size: 2088 bytes --]
^ permalink raw reply
* Re: [PATCH 2/3] Modify sched_clock() to make CONFIG_PRINTK_TIME more sane.
From: Michael Ellerman @ 2007-07-04 4:27 UTC (permalink / raw)
To: Tony Breeds; +Cc: linuxppc-dev
In-Reply-To: <20070704040431.1A13432C46D@thor>
[-- Attachment #1: Type: text/plain, Size: 1153 bytes --]
On Wed, 2007-07-04 at 14:04 +1000, Tony Breeds wrote:
> When booting a current kernel with CONFIG_PRINTK_TIME enabled you'll
> see messages like:
>
> [ 0.000000] time_init: decrementer frequency = 188.044000 MHz
> [ 0.000000] time_init: processor frequency = 1504.352000 MHz
> [3712914.436297] Console: colour dummy device 80x25
>
> This cause by the initialisation of tb_to_ns_scale in time_init(), suddenly the
> multiplication in sched_clock() now does something :). This patch modifies
> sched_clock() to report the offset since the machine booted so the same
> printk's now look like:
>
> [ 0.000000] time_init: decrementer frequency = 188.044000 MHz
> [ 0.000000] time_init: processor frequency = 1504.352000 MHz
> [ 0.000135] Console: colour dummy device 80x25
>
> Effectivly including the uptime in printk()s.
Is this what other archs do?
cheers
--
Michael Ellerman
OzLabs, IBM Australia Development Lab
wwweb: http://michael.ellerman.id.au
phone: +61 2 6212 1183 (tie line 70 21183)
We do not inherit the earth from our ancestors,
we borrow it from our children. - S.M.A.R.T Person
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH v2] Schedule removal of arch/ppc
From: Paul Mackerras @ 2007-07-04 4:26 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-dev
In-Reply-To: <1183486153.3590.24.camel@weaponx.rchland.ibm.com>
Josh Boyer writes:
> Selfishly, that's why I listed it as June 2008 to begin with. We've got
> base 440 support in arch/powerpc now, but it needs more work. And I
> just started 405 this morning.
>
> However, I definitely want some date present when arch/ppc will go away.
> Otherwise it will languish on indefinitely, more so than it already has.
Given that we started this process (or at least made the decision to
start it) in July 2005, June 2008 sounds quite reasonable as an end
date.
Paul.
^ permalink raw reply
* Re: [PATCH 2.6.23] 83xx USB platform code rework
From: Stephen Rothwell @ 2007-07-04 4:15 UTC (permalink / raw)
To: Li Yang; +Cc: linuxppc-dev, paulus
In-Reply-To: <11834557963629-git-send-email-leoli@freescale.com>
[-- Attachment #1: Type: text/plain, Size: 565 bytes --]
Hi Li,
On Tue, 3 Jul 2007 17:43:16 +0800 Li Yang <leoli@freescale.com> wrote:
>
> Add 831x USB platform setup code and rework 834x USB
> platform setup code. Move USB platform code to usb.c
> for different boards with CPU of the same series to share
> the USB initialization code.
If there really is a part of this that is just code movement, then that
should be split out into a separate patch. It makes the reviewers job so
much easier.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* [PATCH 3/3] Initial cut to add __read_mostly support for powerpc.
From: Tony Breeds @ 2007-07-04 4:04 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <1183521871.36329.499255149967.qpush@thor>
Signed-off-by: Tony Breeds <tony@bakeyournoodle.com>
---
This didn't get musch feedback the first time I posted it, so it's either
perfect ;P or it got missed.
arch/powerpc/kernel/vmlinux.lds.S | 6 ++++++
include/asm-powerpc/cache.h | 2 ++
2 files changed, 8 insertions(+)
Index: working/arch/powerpc/kernel/vmlinux.lds.S
===================================================================
--- working.orig/arch/powerpc/kernel/vmlinux.lds.S
+++ working/arch/powerpc/kernel/vmlinux.lds.S
@@ -7,6 +7,7 @@
#define PROVIDE32(x) PROVIDE(x)
#endif
#include <asm-generic/vmlinux.lds.h>
+#include <asm/cache.h>
ENTRY(_stext)
@@ -211,6 +212,11 @@ SECTIONS
*(.data.cacheline_aligned)
}
+ . = ALIGN(L1_CACHE_BYTES);
+ .data.read_mostly : {
+ *(.data.read_mostly)
+ }
+
. = ALIGN(PAGE_SIZE);
__data_nosave : {
__nosave_begin = .;
Index: working/include/asm-powerpc/cache.h
===================================================================
--- working.orig/include/asm-powerpc/cache.h
+++ working/include/asm-powerpc/cache.h
@@ -34,5 +34,9 @@ struct ppc64_caches {
extern struct ppc64_caches ppc64_caches;
#endif /* __powerpc64__ && ! __ASSEMBLY__ */
+#if !defined(__ASSEMBLY__)
+#define __read_mostly __attribute__((__section__(".data.read_mostly")))
+#endif
+
#endif /* __KERNEL__ */
#endif /* _ASM_POWERPC_CACHE_H */
^ permalink raw reply
* [PATCH 1/3] Create a dummy zImage if no valid platform has been selected.
From: Tony Breeds @ 2007-07-04 4:04 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <1183521871.36329.499255149967.qpush@thor>
Signed-off-by: Tony Breeds <tony@bakeyournoodle.com>
---
arch/powerpc/boot/Makefile | 10 ++++++++++
1 file changed, 10 insertions(+)
Index: working/arch/powerpc/boot/Makefile
===================================================================
--- working.orig/arch/powerpc/boot/Makefile
+++ working/arch/powerpc/boot/Makefile
@@ -184,6 +184,11 @@ $(obj)/zImage.initrd.%: vmlinux $(wrappe
$(obj)/zImage.%: vmlinux $(wrapperbits)
$(call if_changed,wrap,$*)
+# This cannot be in the root of $(src) as the zImage rule always adds a $(obj)
+# prefix
+$(obj)/vmlinux.strip: vmlinux
+ $(STRIP) -s -R .comment $< -o $@
+
$(obj)/zImage.iseries: vmlinux
$(STRIP) -s -R .comment $< -o $@
@@ -215,6 +220,11 @@ $(obj)/treeImage.initrd.%: vmlinux $(dts
$(obj)/treeImage.%: vmlinux $(dts) $(wrapperbits)
$(call if_changed,wrap,treeboot-$*,$(dts))
+# If there isn't a platform selected then just strip the vmlinux.
+ifeq (,$(image-y))
+image-y := vmlinux.strip
+endif
+
$(obj)/zImage: $(addprefix $(obj)/, $(image-y))
@rm -f $@; ln $< $@
$(obj)/zImage.initrd: $(addprefix $(obj)/, $(initrd-y))
^ 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