LinuxPPC-Dev Archive on lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH 2/2] ehea: Receive SKB Aggregation
From: Thomas Klein @ 2007-05-31 11:54 UTC (permalink / raw)
  To: Jeff Garzik
  Cc: Thomas Klein, Jan-Bernd Themann, netdev, linux-kernel,
	Christoph Raisch, Stefan Roscher, linux-ppc, Marcus Eder

After there were no technical concerns about this patch I'm resending it with
all whitespace issues fixed which were mentioned by Stephen Rothwell.

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.

We added a disabled module parameter to prevent disruption of normal driver
operation.
We currently consider this as "experimental" until further review and tests
have been passed.


Signed-off-by: Thomas Klein <tklein@de.ibm.com>
---


diff -Nurp -X dontdiff linux-2.6.22-rc3/drivers/net/ehea/ehea.h patched_kernel/drivers/net/ehea/ehea.h
--- linux-2.6.22-rc3/drivers/net/ehea/ehea.h	2007-05-30 13:25:43.000000000 +0200
+++ patched_kernel/drivers/net/ehea/ehea.h	2007-05-30 13:28:16.000000000 +0200
@@ -39,7 +39,7 @@
 #include <asm/io.h>
 
 #define DRV_NAME	"ehea"
-#define DRV_VERSION	"EHEA_0062"
+#define DRV_VERSION	"EHEA_0063"
 
 #define EHEA_MSG_DEFAULT (NETIF_MSG_LINK | NETIF_MSG_TIMER \
 	| NETIF_MSG_RX_ERR | NETIF_MSG_TX_ERR)
@@ -49,6 +49,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
@@ -78,6 +79,9 @@
 #define EHEA_RQ2_PKT_SIZE       1522
 #define EHEA_L_PKT_SIZE         256	/* low latency */
 
+#define MAX_LRO_DESCRIPTORS 8
+#define LRO_DESC_MASK 0xFFFFFFFF
+
 /* Send completion signaling */
 
 /* Protection Domain Identifier */
@@ -334,6 +338,29 @@ struct ehea_q_skb_arr {
 };
 
 /*
+ * Large Receive Offload (LRO) descriptor for a tcp seesion
+ */
+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 {
@@ -362,6 +389,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;
 };
 
 
@@ -411,6 +441,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 -Nurp -X dontdiff linux-2.6.22-rc3/drivers/net/ehea/ehea_main.c patched_kernel/drivers/net/ehea/ehea_main.c
--- linux-2.6.22-rc3/drivers/net/ehea/ehea_main.c	2007-05-30 13:25:43.000000000 +0200
+++ patched_kernel/drivers/net/ehea/ehea_main.c	2007-05-30 13:28:16.000000000 +0200
@@ -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_ENTRIE
 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,9 @@ MODULE_PARM_DESC(sq_entries, " Number of
 		 "[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, "1: enable, 0: disable Large Reveive Offload ");
 
 static int port_name_cnt = 0;
 
@@ -380,6 +388,282 @@ static int ehea_treat_poll_error(struct 
 	return 0;
 }
 
+static int try_get_ip_tcp_hdr(struct ehea_cqe *cqe, struct sk_buff *skb,
+			      struct iphdr **iph, struct tcphdr **tcph)
+{
+	int ip_len;
+
+	/* non tcp/udp packets */
+	if (!cqe->header_length)
+		return -1;
+
+	/* non tcp packet */
+	*iph = (struct iphdr *)(skb->data);
+	if ((*iph)->protocol != IPPROTO_TCP)
+		return -1;
+
+	ip_len = (u8)((*iph)->ihl);
+	ip_len <<= 2;
+	*tcph = (struct tcphdr *)(((u64)*iph) + ip_len);
+
+	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)
+{
+	// fixme: compare source and destination at the same time? u64 compare?
+	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)
+		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)
+		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 +710,7 @@ static struct ehea_cqe *ehea_proc_rwqes(
 					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,11 +736,7 @@ static struct ehea_cqe *ehea_proc_rwqes(
 				processed_rq3++;
 			}
 
-			if (cqe->status & EHEA_CQE_VLAN_TAG_XTRACT)
-				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,
@@ -467,6 +748,8 @@ static struct ehea_cqe *ehea_proc_rwqes(
 		cqe = ehea_poll_rq1(qp, &wqe_index);
 	}
 
+	flush_all_lro(pr);
+
 	pr->rx_packets += processed;
 	*budget -= processed;
 
@@ -1683,9 +1966,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;
 }
 
@@ -2493,6 +2782,7 @@ struct ehea_port *ehea_setup_single_port
 	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));
@@ -2567,6 +2857,12 @@ struct ehea_port *ehea_setup_single_port
 		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",

^ permalink raw reply

* Re: [PATCH 3/3] Modified quirk_mpc8641_transparent() to initializebridge resources.
From: Kumar Gala @ 2007-05-31 12:33 UTC (permalink / raw)
  To: Zang Roy-r61911; +Cc: linuxppc-dev
In-Reply-To: <7EA18FDD2DC2154AA3BD6D2F22A62A0E7EDA24@zch01exm23.fsl.freescale.net>


On May 31, 2007, at 1:48 AM, Zang Roy-r61911 wrote:

>>
>> On May 29, 2007, at 1:23 PM, Jon Loeliger wrote:
>>
>>> From: Jon Loeliger <jdl@freescale.com>
>>>
>>> The 8641 RC poses as a transparent bridge, but does not
>> implement the
>>> IO_BASE or IO_LIMIT registers in the config space.  This means that
>>> the code which initializes the bridge resources ends up setting the
>>> IO resources erroneously.
>>>
>>> This change initializes the RC bridge resources from the
>> device tree.
>>>
>>> Signed-off-by: Andy Fleming <afleming@freescale.com>
>>> Signed-off-by: Jon Loeliger <jdl@freescale.com>
>>
>> Can this be merged with Zhang's "Set RC of mpc8641 to transparent
>> bridge for transfer legacy I/O access." patch since it pretty much
>> supersedes it.
>
> I should be!
> But why apply them sperately?
> They refect differnet content and stage. For end user, they will only
> see the unified code :-).

The reason is that in the future someone may be doing a git-bisect to  
track down a bug and we like to have patches not break things if  
possible.

- k

^ permalink raw reply

* Re: [PATCH 2/2] ehea: Receive SKB Aggregation
From: Christoph Hellwig @ 2007-05-31 13:41 UTC (permalink / raw)
  To: Thomas Klein
  Cc: Thomas Klein, Jeff Garzik, Jan-Bernd Themann, netdev,
	linux-kernel, Christoph Raisch, Stefan Roscher, linux-ppc,
	Marcus Eder
In-Reply-To: <200705311354.56979.osstklei@de.ibm.com>

I'm still very unhappy with having all this in various drivers.  There's
a lot of code that can be turned into generic library functions, and even
more code that could be made generic with some amount of refactoring.

^ permalink raw reply

* Where is initial console initialized ?
From: Daniel Schnell @ 2007-05-31 13:42 UTC (permalink / raw)
  To: linuxppc-embedded

Hi,
=20
I am trying to bring up 2.6.20.3 on a MPC5200B based custom board. This
Kernel is based on the Phytec phyCore MPC5200B Mini BSP kernel and
adapted to my board.
So far I have troubles to get console output working when booting Linux.
Uboot console output is fine. Linux begins to run (I can set breakpoints
with the BDI2000 in the early initialization code) so I probably have a
misconfiguration of the console output inside the fdt.

The major difference between the Phytec phyCore 5200B mini fdt and mine
is that we use PSC1 instead of PSC3/6 for serial. Accordingly I changed
the fdt (or dts) values.

To get some more insights, I would like to know, in which Linux function
the console output is initialised ?


See the relevant outputs attached:


=3D=3D=3D=3D=3D=3D=3D=3D=3D
## Booting image at 00500000 ...
   Image Name:   Linux-2.6.20-rt3-v38c
   Created:      2007-05-30  13:10:27 UTC
   Image Type:   PowerPC Linux Kernel Image (gzip compressed)
   Data Size:    970278 Bytes =3D 947.5 kB
   Load Address: 00000000
   Entry Point:  00000000
   Verifying Checksum ... OK
   Uncompressing Kernel Image ... OK
(no further output)
=3D=3D=3D=3D=3D=3D=3D=3D=3D



If I dump the flat device tree inside uboot, I get the following
entries:=20

=3D=3D=3D=3D=3D=3D=3D=3D=3D
   Booting using flat device tree at 0x400000
 {
    model =3D "v38c";
    compatible =3D [76 33 38 63 00 6d 70 63 35 32 30 30 62 00 6d 70 63 =
35
32 78 78 00];
    #address-cells =3D <1>;
    #size-cells =3D <1>;
    cpus {
        #cpus =3D <1>;
        #address-cells =3D <1>;
        #size-cells =3D <0>;
        PowerPC,5200@0 {
            device_type =3D "cpu";
            reg =3D <0>;
            d-cache-line-size =3D <20>;
            i-cache-line-size =3D <20>;
            d-cache-size =3D <4000>;
            i-cache-size =3D <4000>;
            timebase-frequency =3D <1f78a40>;
            bus-frequency =3D <7de2900>;
            clock-frequency =3D <179a7b00>;
            32-bit;
        };
    };
    memory {
        device_type =3D "memory";
        reg =3D <8>;
    };
    soc5200@f0000000 {
        #interrupt-cells =3D <3>;
        device_type =3D "soc";
        ranges =3D [00 00 00 00 f0 00 00 00 f0 01 00 00];
        reg =3D <8>;
        bus-frequency =3D <3ef1480>;
        cdm@200 {
            compatible =3D [6d 70 63 35 32 30 30 62 2d 63 64 6d 00 6d 70
63 35 32 78 78 2d 63 64 6d 00];
            reg =3D <8>;
        };
        pic@500 {
            linux,phandle =3D <500>;
            interrupt-controller;
            #interrupt-cells =3D <3>;
            device_type =3D "interrupt-controller";
            compatible =3D [6d 70 63 35 32 30 30 62 2d 70 69 63 00 6d 70
63 35 32 78 78 2d 70 69 63 00];
            reg =3D <8>;
            built-in;
        };
        gpt@600 {
            compatible =3D [6d 70 63 35 32 30 30 62 2d 67 70 74 00 6d 70
63 35 32 78 78 2d 67 70 74 00];
            device_type =3D "gpt";
            reg =3D <8>;
            interrupts =3D [00 00 00 01 00 00 00 09 00 00 00 00];
            interrupt-parent =3D <500>;
        };
        gpt@610 {
            compatible =3D [6d 70 63 35 32 30 30 62 2d 67 70 74 00 6d 70
63 35 32 78 78 2d 67 70 74 00];
            device_type =3D "gpt";
            reg =3D <8>;
            interrupts =3D [00 00 00 01 00 00 00 0a 00 00 00 00];
            interrupt-parent =3D <500>;
        };
        gpt@620 {
            compatible =3D [6d 70 63 35 32 30 30 62 2d 67 70 74 00 6d 70
63 35 32 78 78 2d 67 70 74 00];
            device_type =3D "gpt";
            reg =3D <8>;
            interrupts =3D [00 00 00 01 00 00 00 0b 00 00 00 00];
            interrupt-parent =3D <500>;
        };
        gpt@630 {
            compatible =3D [6d 70 63 35 32 30 30 62 2d 67 70 74 00 6d 70
63 35 32 78 78 2d 67 70 74 00];
            device_type =3D "gpt";
            reg =3D <8>;
            interrupts =3D [00 00 00 01 00 00 00 0c 00 00 00 00];
            interrupt-parent =3D <500>;
        };
        gpt@640 {
            compatible =3D [6d 70 63 35 32 30 30 62 2d 67 70 74 00 6d 70
63 35 32 78 78 2d 67 70 74 00];
            device_type =3D "gpt";
            reg =3D <8>;
            interrupts =3D [00 00 00 01 00 00 00 0d 00 00 00 00];
            interrupt-parent =3D <500>;
        };
        gpt@650 {
            compatible =3D [6d 70 63 35 32 30 30 62 2d 67 70 74 00 6d 70
63 35 32 78 78 2d 67 70 74 00];
            device_type =3D "gpt";
            reg =3D <8>;
            interrupts =3D [00 00 00 01 00 00 00 0e 00 00 00 00];
            interrupt-parent =3D <500>;
        };
        gpt@660 {
            compatible =3D [6d 70 63 35 32 30 30 62 2d 67 70 74 00 6d 70
63 35 32 78 78 2d 67 70 74 00];
            device_type =3D "gpt";
            reg =3D <8>;
            interrupts =3D [00 00 00 01 00 00 00 0f 00 00 00 00];
            interrupt-parent =3D <500>;
        };
        gpt@670 {
            compatible =3D [6d 70 63 35 32 30 30 62 2d 67 70 74 00 6d 70
63 35 32 78 78 2d 67 70 74 00];
            device_type =3D "gpt";
            reg =3D <8>;
            interrupts =3D [00 00 00 01 00 00 00 10 00 00 00 00];
            interrupt-parent =3D <500>;
        };
        rtc@800 {
            compatible =3D [6d 70 63 35 32 30 30 62 2d 72 74 63 00 6d 70
63 35 32 78 78 2d 72 74 63 00];
            device_type =3D "rtc";
            reg =3D <8>;
            interrupts =3D [00 00 00 01 00 00 00 05 00 00 00 00 00 00 00
01 00 00 00 06 00 00 00 00];
            interrupt-parent =3D <500>;
        };
        mscan@900 {
            device_type =3D "mscan";
            compatible =3D [6d 70 63 35 32 30 30 62 2d 6d 73 63 61 6e 00
6d 70 63 35 32 78 78 2d 6d 73 63 61 6e 00];
            interrupts =3D [00 00 00 02 00 00 00 11 00 00 00 00];
            interrupt-parent =3D <500>;
            reg =3D <8>;
        };
        mscan@980 {
            device_type =3D "mscan";
            compatible =3D [6d 70 63 35 32 30 30 62 2d 6d 73 63 61 6e 00
6d 70 63 35 32 78 78 2d 6d 73 63 61 6e 00];
            interrupts =3D [00 00 00 02 00 00 00 12 00 00 00 00];
            interrupt-parent =3D <500>;
            reg =3D <8>;
        };
        gpio@b00 {
            compatible =3D [6d 70 63 35 32 30 30 62 2d 67 70 69 6f 00 6d
70 63 35 32 78 78 2d 67 70 69 6f 00];
            reg =3D <8>;
            interrupts =3D [00 00 00 01 00 00 00 07 00 00 00 00];
            interrupt-parent =3D <500>;
        };
        gpio-wkup@b00 {
            compatible =3D [6d 70 63 35 32 30 30 62 2d 67 70 69 6f 2d 77
6b 75 70 00 6d 70 63 35 32 78 78 2d 67 70 69 6f 2d 77 6b 75 70 00];
            reg =3D <8>;
            interrupts =3D [00 00 00 01 00 00 00 08 00 00 00 00 00 00 00
00 00 00 00 03 00 00 00 00];
            interrupt-parent =3D <500>;
        };
        pci@0d00 {
            #interrupt-cells =3D <1>;
            #size-cells =3D <2>;
            #address-cells =3D <3>;
            device_type =3D "pci";
            compatible =3D [6d 70 63 35 32 30 30 62 2d 70 63 69 00 6d 70
63 35 32 78 78 2d 70 63 69 00];
            reg =3D <8>;
            interrupt-map-mask =3D [00 00 f8 00 00 00 00 00 00 00 00 00 =
00
00 00 07];
            interrupt-map =3D [00 00 c0 00 00 00 00 00 00 00 00 00 00 00
00 01 00 00 05 00 00 00 00 00 00 00 00 00 00 00 00 03 00 00 c0 00 00 00
00 00 00 00 00 00 00 00 00 02 00 00 05 00 00 00 00 01 00 00 00 01 00 00
00 03 00 00 c0 00 00 00 00 00 00 00 00 00 00 00 00 03 00 00 05 00 00 00
00 01 00 00 00 02 00 00 00 03 00 00 c0 00 00 00 00 00 00 00 00 00 00 00
00 04 00 00 05 00 00 00 00 01 00 00 00 03 00 00 00 03 00 00 c8 00 00 00
00 00 00 00 00 00 00 00 00 01 00 00 05 00 00 00 00 01 00 00 00 01 00 00
00 03 00 00 c8 00 00 00 00 00 00 00 00 00 00 00 00 02 00 00 05 00 00 00
00 01 00 00 00 02 00 00 00 03 00 00 c8 00 00 00 00 00 00 00 00 00 00 00
00 03 00 00 05 00 00 00 00 01 00 00 00 03 00 00 00 03 00 00 c8 00 00 00
00 00 00 00 00 00 00 00 00 04 00 00 05 00 00 00 00 00 00 00 00 00 00 00
00 03];
            clock-frequency =3D <0>;
            interrupts =3D [00 00 00 02 00 00 00 08 00 00 00 00 00 00 00
02 00 00 00 09 00 00 00 00 00 00 00 02 00 00 00 0a 00 00 00 00];
            interrupt-parent =3D <500>;
            bus-range =3D <8>;
            ranges =3D [42 00 00 00 00 00 00 00 80 00 00 00 80 00 00 00 =
00
00 00 00 20 00 00 00 02 00 00 00 00 00 00 00 a0 00 00 00 a0 00 00 00 00
00 00 00 10 00 00 00 01 00 00 00 00 00 00 00 00 00 00 00 b0 00 00 00 00
00 00 00 01 00 00 00];
        };
        spi@f00 {
            device_type =3D "spi";
            compatible =3D [6d 70 63 35 32 30 30 62 2d 73 70 69 00 6d 70
63 35 32 78 78 2d 73 70 69 00];
            reg =3D <8>;
            interrupts =3D [00 00 00 02 00 00 00 0d 00 00 00 00 00 00 00
02 00 00 00 0e 00 00 00 00];
            interrupt-parent =3D <500>;
        };
        usb@1000 {
            device_type =3D "usb-ohci-be";
            compatible =3D [6d 70 63 35 32 30 30 62 2d 6f 68 63 69 00 6d
70 63 35 32 78 78 2d 6f 68 63 69 00 6f 68 63 69 2d 62 65 00];
            reg =3D <8>;
            interrupts =3D [00 00 00 02 00 00 00 06 00 00 00 00];
            interrupt-parent =3D <500>;
        };
        bestcomm@1200 {
            device_type =3D "dma-controller";
            compatible =3D [6d 70 63 35 32 30 30 62 2d 62 65 73 74 63 6f
6d 6d 00 6d 70 63 35 32 78 78 2d 62 65 73 74 63 6f 6d 6d 00];
            reg =3D <8>;
            interrupts =3D [00 00 00 03 00 00 00 00 00 00 00 00 00 00 00
03 00 00 00 01 00 00 00 00 00 00 00 03 00 00 00 02 00 00 00 00 00 00 00
03 00 00 00 03 00 00 00 00 00 00 00 03 00 00 00 04 00 00 00 00 00 00 00
03 00 00 00 05 00 00 00 00 00 00 00 03 00 00 00 06 00 00 00 00 00 00 00
03 00 00 00 07 00 00 00 00 00 00 00 03 00 00 00 08 00 00 00 00 00 00 00
03 00 00 00 09 00 00 00 00 00 00 00 03 00 00 00 0a 00 00 00 00 00 00 00
03 00 00 00 0b 00 00 00 00 00 00 00 03 00 00 00 0c 00 00 00 00 00 00 00
03 00 00 00 0d 00 00 00 00 00 00 00 03 00 00 00 0e 00 00 00 00 00 00 00
03 00 00 00 0f 00 00 00 00];
            interrupt-parent =3D <500>;
        };
        xlb@1f00 {
            compatible =3D [6d 70 63 35 32 30 30 62 2d 78 6c 62 00 6d 70
63 35 32 78 78 2d 78 6c 62 00];
            reg =3D <8>;
        };
        serial@2000 {
            device_type =3D "serial";
            compatible =3D [6d 70 63 35 32 30 30 62 2d 70 73 63 2d 75 61
72 74 00 6d 70 63 35 32 78 78 2d 70 73 63 2d 75 61 72 74 00];
            port-number =3D <0>;
            reg =3D <8>;
            interrupts =3D [00 00 00 02 00 00 00 01 00 00 00 00];
            interrupt-parent =3D <500>;
        };
        ethernet@3000 {
            device_type =3D "network";
            compatible =3D [6d 70 63 35 32 30 30 62 2d 66 65 63 00 6d 70
63 35 32 78 78 2d 66 65 63 00];
            reg =3D <8>;
            mac-address =3D [00 e0 ee 00 28 0d];
            interrupts =3D [00 00 00 02 00 00 00 05 00 00 00 00];
            interrupt-parent =3D <500>;
        };
        i2c@3d00 {
            device_type =3D "i2c";
            compatible =3D [6d 70 63 35 32 30 30 62 2d 69 32 63 00 6d 70
63 35 32 78 78 2d 69 32 63 00];
            reg =3D <8>;
            interrupts =3D [00 00 00 02 00 00 00 0f 00 00 00 00];
            interrupt-parent =3D <500>;
        };
        i2c@3d40 {
            device_type =3D "i2c";
            compatible =3D [6d 70 63 35 32 30 30 62 2d 69 32 63 00 6d 70
63 35 32 78 78 2d 69 32 63 00];
            reg =3D <8>;
            interrupts =3D [00 00 00 02 00 00 00 10 00 00 00 00];
            interrupt-parent =3D <500>;
        };
        sram@8000 {
            device_type =3D "sram";
            compatible =3D [6d 70 63 35 32 30 30 62 2d 73 72 61 6d 00 6d
70 63 35 32 78 78 2d 73 72 61 6d 00 73 72 61 6d 00];
            reg =3D <8>;
        };
    };
    chosen {
        name =3D "chosen";
        bootargs =3D "console=3DttyPSC0,115200 root=3D/dev/nfs ip=3Ddhcp
nfsroot=3D10.100.11.96:/home/danielsch/downloads/OSELAS.BSP-Phytec-phyCOR=
E
-MPC5200B-tiny-5/root,v3,tcp";
        linux,platform =3D <600>;
        linux,stdout-path =3D "/soc5200@f0000000/serial@2000";
    };
};
=3D=3D=3D=3D=3D=3D=3D=3D=3D

^ permalink raw reply

* Re: [PATCH 3/5] Float the pci bus number on MPC8641HPCN board.
From: Kumar Gala @ 2007-05-31 13:43 UTC (permalink / raw)
  To: Zhang Wei-r63237; +Cc: linuxppc-dev, paulus
In-Reply-To: <46B96294322F7D458F9648B60E15112C234A2D@zch01exm26.fsl.freescale.net>


On May 22, 2007, at 10:35 PM, Zhang Wei-r63237 wrote:

> Hi, Wade,
>
> That's a good question.
>
> The ppc_md.exclude_device() function will be called before PCI config
> access in indirect_read/write_config() of the file
> arch/powerpc/sysdev/indirect_pci.c. If the hose->bus_offset value  
> is 0,
> the primary bus number register of the host must be hose->first_busno.
> Otherwise, if the host primary bus number register is 0, the
> hose->bus_offset must be the same value of hose->first_buseno.
>
> When the pci scan bus, the bridge will be scaned twice. When the  
> second
> scan is finished, the host primary bus number register will be  
> write to
> hose->first_busno. The PCI bus(not the first PCI host) access will be
> wrong in the later access. I'll check it and correct the
> hose->bus_offset value in these codes.

Can this be fixed by just setting hose->bus_offset in add_bridge?

Doing this in exclude is very bad.

- k

>> -----Original Message-----
>> From: Wade Farnsworth [mailto:wfarnsworth@mvista.com]
>> Subject: Re: [PATCH 3/5] Float the pci bus number on
>> MPC8641HPCN board.
>>
>> On Tue, 2007-05-22 at 11:38 +0800, Zhang Wei wrote:
>>>  int mpc86xx_exclude_device(u_char bus, u_char devfn)
>>>  {
>>> +	struct pci_controller *hose;
>>> +
>>> +	hose = pci_bus_to_hose(bus);
>>> +	if (unlikely(!hose))
>>> +		return PCIBIOS_DEVICE_NOT_FOUND;
>>> +
>>> +	/* Correcting the hose->bus_offset value. */
>>> +	out_be32(hose->cfg_addr, 0x80000000 | ((hose->first_busno
>>> +					- hose->bus_offset) << 16));
>>> +	if (unlikely(in_le32(hose->cfg_data) == 0xffffffff))
>>> +		hose->bus_offset = hose->bus_offset ? 0 :
>> hose->first_busno;
>>> +
>>>  	return PCIBIOS_SUCCESSFUL;
>>>  }
>>
>> What is the purpose of this code and why put it in
>> mpc86xx_exclude_device?
>>
>> --Wade
>>
>>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev

^ permalink raw reply

* RE: [PATCH 3/3] Modified quirk_mpc8641_transparent() to initializebridge resources.
From: Jon Loeliger @ 2007-05-31 14:10 UTC (permalink / raw)
  To: Roy Zang; +Cc: linuxppc-dev@ozlabs.org
In-Reply-To: <7EA18FDD2DC2154AA3BD6D2F22A62A0E7EDA24@zch01exm23.fsl.freescale.net>

On Thu, 2007-05-31 at 01:48, Zang Roy-r61911 wrote:

> > Can this be merged with Zhang's "Set RC of mpc8641 to transparent  
> > bridge for transfer legacy I/O access." patch since it pretty much  
> > supersedes it.
> 
> I should be! 
> But why apply them sperately? 
> They refect differnet content and stage. For end user, they will only
> see the unified code :-).
> Roy

I have respun these two PCI-E patch sets into one and will post
them again.

jdl

^ permalink raw reply

* Re: Xilinx ethernet EMAC and bad checksum?
From: Guillaume Berthelom @ 2007-05-31 14:40 UTC (permalink / raw)
  To: linuxppc-embedded
In-Reply-To: <10890962.post@talk.nabble.com>


I found the answer just after send my post!
I had  NETIF_F_IP_CSUM in my ndev->feature 

-- 
View this message in context: http://www.nabble.com/Xilinx-ethernet-EMAC-and-bad-checksum--tf3845670.html#a10895279
Sent from the linuxppc-embedded mailing list archive at Nabble.com.

^ permalink raw reply

* Miniature OpenGL development Linux
From: zeAtShuttle @ 2007-05-31 15:14 UTC (permalink / raw)
  To: linuxppc-dev

[-- Attachment #1: Type: text/plain, Size: 2417 bytes --]

hello,


is anyone interested in this "kind of distro" running on PowerPC?

------------------------------------------------------------
http://one.xthost.info/zelko/opengl.html

Minimalistic GNU/Linux system, stripped down of everything, but core necessary files to compile and run OpenGL/C code. It has simplified directory structure and cleaned up internal cross referencing. Programs compiled in myOS will run on any Linux with or without X. 
------------------------------------------------------------



as you can see there, im trying to find the place where to upload it, but, meanwhile, to SEE what im talking about you can try myOS x86 version...

OR, 
better yet - try these PowerPC binaries 
http://www.scitechsoft.com/ftp/devel/demos/ppclinux/

there is 6.7Mb zip with LOTS of COOL OpenGL and other demos... game DOOM !
(drivers and everything included, just unpack & run)





--- about "myOS-ppc" -------------------------------------------------------------

in new version we use *initramfs* so the whole distro can load in ONLY 64MB of RAM,
that means some very old G3 Macs, however i still can NOT make the demos run on my test platform G3/64MB/333Mhz ...maybe because there is not enough *free* memory, and is hard to find that kind of RAM today and upgrade that Mac... 

so, we would very much appreciate if you can let us know if the above OpenGL demos work on your  ppc-Linux, what is your PowerPC machine, what graphic card and how much RAM/VRAM it has?


...we're basically trying to work out minimum possible PowerPC platform, 
so, if you have some embedded hardware we wonder if some of the demos would work...

but also,
some "game-station" ...well whatever is running PowerPC and Linux we would like to know if those Scitech drivers and OpenGL demos work on that platform...


list of video cards supported:
http://www.scitechsoft.com/ftp/snap/linux/readme-x86.txt



even, if your hardware can not "play" OpenGL or
if you are not interested in 3D, there is still the whole
miniature development platform that can be used for... whatever

main point to make it really teensy was just so it can run from "RAMDISK" 
and be quick & responsive... it turned out that embedded devices of 
today are more powerful than desktop computers of yesterday, so this 
"kind of distro" fits easily on embedded platform...



cheers,
zelko


 

[-- Attachment #2: Type: text/html, Size: 3810 bytes --]

^ permalink raw reply

* Miniature OpenGL development Linux
From: zeAtShuttle @ 2007-05-31 15:14 UTC (permalink / raw)
  To: linuxppc-embedded

[-- Attachment #1: Type: text/plain, Size: 2417 bytes --]

hello,


is anyone interested in this "kind of distro" running on PowerPC?

------------------------------------------------------------
http://one.xthost.info/zelko/opengl.html

Minimalistic GNU/Linux system, stripped down of everything, but core necessary files to compile and run OpenGL/C code. It has simplified directory structure and cleaned up internal cross referencing. Programs compiled in myOS will run on any Linux with or without X. 
------------------------------------------------------------



as you can see there, im trying to find the place where to upload it, but, meanwhile, to SEE what im talking about you can try myOS x86 version...

OR, 
better yet - try these PowerPC binaries 
http://www.scitechsoft.com/ftp/devel/demos/ppclinux/

there is 6.7Mb zip with LOTS of COOL OpenGL and other demos... game DOOM !
(drivers and everything included, just unpack & run)





--- about "myOS-ppc" -------------------------------------------------------------

in new version we use *initramfs* so the whole distro can load in ONLY 64MB of RAM,
that means some very old G3 Macs, however i still can NOT make the demos run on my test platform G3/64MB/333Mhz ...maybe because there is not enough *free* memory, and is hard to find that kind of RAM today and upgrade that Mac... 

so, we would very much appreciate if you can let us know if the above OpenGL demos work on your  ppc-Linux, what is your PowerPC machine, what graphic card and how much RAM/VRAM it has?


...we're basically trying to work out minimum possible PowerPC platform, 
so, if you have some embedded hardware we wonder if some of the demos would work...

but also,
some "game-station" ...well whatever is running PowerPC and Linux we would like to know if those Scitech drivers and OpenGL demos work on that platform...


list of video cards supported:
http://www.scitechsoft.com/ftp/snap/linux/readme-x86.txt



even, if your hardware can not "play" OpenGL or
if you are not interested in 3D, there is still the whole
miniature development platform that can be used for... whatever

main point to make it really teensy was just so it can run from "RAMDISK" 
and be quick & responsive... it turned out that embedded devices of 
today are more powerful than desktop computers of yesterday, so this 
"kind of distro" fits easily on embedded platform...



cheers,
zelko


 

[-- Attachment #2: Type: text/html, Size: 3901 bytes --]

^ permalink raw reply

* Re: [PATCH 2/2] ehea: Receive SKB Aggregation
From: Stephen Hemminger @ 2007-05-31 16:37 UTC (permalink / raw)
  To: Thomas Klein
  Cc: Thomas Klein, Jeff Garzik, Jan-Bernd Themann, netdev, Stefan,
	linux-kernel, Christoph Raisch, Roscher, linux-ppc, Marcus Eder
In-Reply-To: <200705311354.56979.osstklei@de.ibm.com>


> 
>  
> +static int try_get_ip_tcp_hdr(struct ehea_cqe *cqe, struct sk_buff *skb,
> +			      struct iphdr **iph, struct tcphdr **tcph)
> +{
> +	int ip_len;
> +
> +	/* non tcp/udp packets */
> +	if (!cqe->header_length)
> +		return -1;
> +
> +	/* non tcp packet */
> +	*iph = (struct iphdr *)(skb->data);

Why the indirection, copying of headers..

> +	if ((*iph)->protocol != IPPROTO_TCP)
> +		return -1;
> +
> +	ip_len = (u8)((*iph)->ihl);
> +	ip_len <<= 2;
> +	*tcph = (struct tcphdr *)(((u64)*iph) + ip_len);
> +
> +	return 0;
> +}
> +
> 

This code seems to be duplicating a lot  (but not all) of the TCP/IP
input path validation checks. This is a security problem if nothing else...

Also, how do you prevent DoS attacks from hostile TCP senders that send
huge number of back to back frames?

-- 
Stephen Hemminger <shemminger@linux-foundation.org>

^ permalink raw reply

* RE: Kernel 2.6, ML403, rootfs on nfs, gigabit ethernet link, nfs mount problems
From: Mohammad Sadegh Sadri @ 2007-05-31 18:54 UTC (permalink / raw)
  To: bwarren; +Cc: Linux PPC Linux PPC


Hi all,

thanks for suggestions
I added rsize=3D1024,wsize=3D1024 to CMD LINE. INIT can now be executed fro=
m nfs, but I think that the problem still exists,
during the start up process ( from when the rootfs is mounted until user ge=
t a command prompt ) some times ML403 stops working completely, and generat=
es "Segmentation Fault" and similar messages. some other times the system c=
omes up with no problem.=20

I had the same problem when mounting rootfs using nfs via 100mbits link , b=
ut for gigabit link the probability of reaching this unstable state is much=
 higher.

any ideas?

thanks




----------------------------------------
> Subject: Re: Kernel 2.6, ML403, rootfs on nfs, gigabit ethernet link, nfs=
	mount problems
> From: bwarren@qstreams.com
> To: mamsadegh@hotmail.com
> CC: linuxppc-embedded@ozlabs.org
> Date: Tue, 29 May 2007 10:52:21 -0400
>=20
> Hi Mohammad,
>=20
> On Tue, 2007-05-29 at 14:41 +0000, Mohammad Sadegh Sadri wrote:
> > Hi all,
> >=20
> > well I could bring up the grant's kernel on ml403 completely. the root =
file system was over nfs.=20
> >=20
> > when I use a 100mbits link for connection to ml403 , every thing is wor=
king suitably.
> > but when I use a 1000mbits link, I see that ml403 gets ip address from =
dhcp and mounts the root file system but can not go further , it stops with=
 a message: "nfs server not responding ...." some thing like this.
> >=20
> > when pinging to ml403 with 64 bytes packets, ping works fine for both o=
f 100 and 1000mbits links
> > but when I try to ping the board with 4000 bytes packets I notice that =
ml403 on gigabit link can not answer to ping packets, however on 100mbit li=
nk every thing works just fine.
> >=20
> > any ideas?
>=20
> NFS is notorious for sending lots of big packets one right after
> another.  This can easily overwhelm an Ethernet receiver.  Until you're
> able to figure out why the 1000M link can't keep up, limit the NFS
> receive packet sizes by passing the following NFS option in your kernel
> command line:
>=20
> rsize=3D1024
>=20
> You can experiment with the value.  I believe the NFS default size is
> typically 8kB or greater.
>=20
> regards,
> Ben
>=20

_________________________________________________________________
Invite your mail contacts to join your friends list with Windows Live Space=
s. It's easy!
http://spaces.live.com/spacesapi.aspx?wx_action=3Dcreate&wx_url=3D/friends.=
aspx&mkt=3Den-us=

^ permalink raw reply

* Re: Audio Dirver for the 403/405?
From: bert_maxel @ 2007-05-31 19:10 UTC (permalink / raw)
  To: linuxppc-embedded
In-Reply-To: <fa686aa40705301610q6ba8f2abq482f43a89f44d1bc@mail.gmail.com>




Grant Likely-2 wrote:
> 
> On 5/30/07, bert_maxel <bonlutin@hotmail.com> wrote:
>>
>> Hi all,
>>
>> Has anybody got some working audio driver (linux) for the  ML403/405 ?
>> I know it's an ac97 codec, but I can't find anything related to the
>> xilinx
>> boards?
>> If nobody has worked on this yet, I'm in trouble. I don't know where to
>> start, or from what ac97 driver should I base my initial development?
> 
> IIRC, the old mvista 2.4 tree has an audio driver.
> 
> g.
> 
> -- 
> Grant Likely, B.Sc., P.Eng.
> Secret Lab Technologies Ltd.
> grant.likely@secretlab.ca
> (403) 399-0195
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
> 
> 

There are plenty of boards with an ac97 codec, but what's missing is the
glue for the ML403 board, there's no pci bus in this case,  opb cores
instead.
I hope somebody can point me to a link of interest.

thanks
-- 
View this message in context: http://www.nabble.com/Audio-Dirver-for-the-403-405--tf3843165.html#a10900170
Sent from the linuxppc-embedded mailing list archive at Nabble.com.

^ permalink raw reply

* [PATCH] Donate dedicated CPU cycles
From: Jake Moilanen @ 2007-05-31 19:14 UTC (permalink / raw)
  To: Paul Mackerras; +Cc: linuxppc-dev

A Power6 can give up CPU cycles on a dedicated CPU (as opposed to a
shared CPU) to other shared processors if the administrator asks for it
(via the HMC).

This patch enables that to work properly on P6.

This just involves setting a bit in the CAS structure as well as the
VPA.  To donate cycles, a CPU has to have all SMT threads idle and w/
donate bit set in the VPA.  Then call H_CEDE.

Signed-off-by: Jake Moilanen <moilanen@austin.ibm.com>

--
 arch/powerpc/kernel/prom_init.c        |    4 +++-
 arch/powerpc/platforms/pseries/setup.c |    2 ++
 2 files changed, 5 insertions(+), 1 deletion(-)

Index: powerpc/arch/powerpc/kernel/prom_init.c
===================================================================
--- powerpc.orig/arch/powerpc/kernel/prom_init.c
+++ powerpc/arch/powerpc/kernel/prom_init.c
@@ -635,6 +635,7 @@ static void __init early_cmdline_parse(v
 /* ibm,dynamic-reconfiguration-memory property supported */
 #define OV5_DRCONF_MEMORY	0x20
 #define OV5_LARGE_PAGES		0x10	/* large pages supported */
+#define OV5_DONATE_DEDICATE_CPU 0x02	/* donate dedicated CPU support */
 /* PCIe/MSI support.  Without MSI full PCIe is not supported */
 #ifdef CONFIG_PCI_MSI
 #define OV5_MSI			0x01	/* PCIe/MSI support */
@@ -685,7 +686,8 @@ static unsigned char ibm_architecture_ve
 	/* option vector 5: PAPR/OF options */
 	3 - 2,				/* length */
 	0,				/* don't ignore, don't halt */
-	OV5_LPAR | OV5_SPLPAR | OV5_LARGE_PAGES | OV5_DRCONF_MEMORY | OV5_MSI,
+	OV5_LPAR | OV5_SPLPAR | OV5_LARGE_PAGES | OV5_DRCONF_MEMORY |
+	OV5_DONATE_DEDICATE_CPU | OV5_MSI,
 };
 
 /* Old method - ELF header with PT_NOTE sections */
Index: powerpc/arch/powerpc/platforms/pseries/setup.c
===================================================================
--- powerpc.orig/arch/powerpc/platforms/pseries/setup.c
+++ powerpc/arch/powerpc/platforms/pseries/setup.c
@@ -399,6 +399,7 @@ static void pseries_dedicated_idle_sleep
 	 * a good time to find other work to dispatch.
 	 */
 	get_lppaca()->idle = 1;
+	get_lppaca()->cpuctls_task_attrs = 1;
 
 	/*
 	 * We come in with interrupts disabled, and need_resched()
@@ -431,6 +432,7 @@ static void pseries_dedicated_idle_sleep
 
 out:
 	HMT_medium();
+	get_lppaca()->cpuctls_task_attrs = 0;
 	get_lppaca()->idle = 0;
 }
 

^ permalink raw reply

* RE: Kernel 2.6, ML403, rootfs on nfs, gigabit ethernet link, nfsmount problems
From: Gary Kenaley @ 2007-05-31 19:36 UTC (permalink / raw)
  To: Mohammad Sadegh Sadri, bwarren; +Cc: Linux PPC Linux PPC
In-Reply-To: <BAY115-W17F1AB35DDD5B358CAC89B22D0@phx.gbl>

This can be caused by problems with your host Ethernet driver. For
instance, the e1000 driver running on the Intel 82573L controller must
have ~ the following line added to /etc/modprobe.conf:
	options e1000 RxIntDelay=3D32
Another symptom is occasional erratic ping times to and from the host.

The quickest way to test this theory is to put the rootfs on a
different-hardware, known-good host and see if the problem goes away.

On an 8349, we have also see Phy chip problems which required a reset
after every write to the Phy, and problems setting up the Phy when
stepping through the debugger.


> -----Original Message-----
> From: linuxppc-embedded-bounces+gkenaley=3Dechelon.com@ozlabs.org
> [mailto:linuxppc-embedded-bounces+gkenaley=3Dechelon.com@ozlabs.org] =
On
> Behalf Of Mohammad Sadegh Sadri
> Sent: Thursday, May 31, 2007 11:55 AM
> To: bwarren@qstreams.com
> Cc: Linux PPC Linux PPC
> Subject: RE: Kernel 2.6, ML403, rootfs on nfs, gigabit ethernet link,
> nfsmount problems
>=20
>=20
> Hi all,
>=20
> thanks for suggestions
> I added rsize=3D1024,wsize=3D1024 to CMD LINE. INIT can now be =
executed
from
> nfs, but I think that the problem still exists,
> during the start up process ( from when the rootfs is mounted until
user
> get a command prompt ) some times ML403 stops working completely, and
> generates "Segmentation Fault" and similar messages. some other times
the
> system comes up with no problem.
>=20
> I had the same problem when mounting rootfs using nfs via 100mbits
link ,
> but for gigabit link the probability of reaching this unstable state
is
> much higher.
>=20
> any ideas?
>=20
> thanks
>=20
>=20
>=20
>=20
> ----------------------------------------
> > Subject: Re: Kernel 2.6, ML403, rootfs on nfs, gigabit ethernet
link,
> nfs	mount problems
> > From: bwarren@qstreams.com
> > To: mamsadegh@hotmail.com
> > CC: linuxppc-embedded@ozlabs.org
> > Date: Tue, 29 May 2007 10:52:21 -0400
> >
> > Hi Mohammad,
> >
> > On Tue, 2007-05-29 at 14:41 +0000, Mohammad Sadegh Sadri wrote:
> > > Hi all,
> > >
> > > well I could bring up the grant's kernel on ml403 completely. the
root
> file system was over nfs.
> > >
> > > when I use a 100mbits link for connection to ml403 , every thing
is
> working suitably.
> > > but when I use a 1000mbits link, I see that ml403 gets ip address
from
> dhcp and mounts the root file system but can not go further , it stops
> with a message: "nfs server not responding ...." some thing like this.
> > >
> > > when pinging to ml403 with 64 bytes packets, ping works fine for
both
> of 100 and 1000mbits links
> > > but when I try to ping the board with 4000 bytes packets I notice
that
> ml403 on gigabit link can not answer to ping packets, however on
100mbit
> link every thing works just fine.
> > >
> > > any ideas?
> >
> > NFS is notorious for sending lots of big packets one right after
> > another.  This can easily overwhelm an Ethernet receiver.  Until
you're
> > able to figure out why the 1000M link can't keep up, limit the NFS
> > receive packet sizes by passing the following NFS option in your
kernel
> > command line:
> >
> > rsize=3D1024
> >
> > You can experiment with the value.  I believe the NFS default size
is
> > typically 8kB or greater.
> >
> > regards,
> > Ben
> >
>=20
> _________________________________________________________________
> Invite your mail contacts to join your friends list with Windows Live
> Spaces. It's easy!
>
http://spaces.live.com/spacesapi.aspx?wx_action=3Dcreate&wx_url=3D/friend=
s.a
sp
> x&mkt=3Den-us
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded

^ permalink raw reply

* [PATCH 0/3] powerpc: Clean up some boot/Makefile rules
From: Mark A. Greer @ 2007-05-31 19:51 UTC (permalink / raw)
  To: linuxppc-dev; +Cc: David Gibson


This patch series removes the 'make zImage.dts' feature that was recently
added.  Its been replaced by some logic that will automaticaly wrap a dts
with the zImage when CONFIG_WANT_DEVICE_TREE is 'y' and CONFIG_DEVICE_TREE
isn't an empty string.  Otherwise, things will work as they always have.
A patch to update the holly to use this support (i.e., remove the extra
Makefile rules) is included as well.

Please let me know if you have any issues with these patches.

Thanks,

Mark

^ permalink raw reply

* RE: Audio Dirver for the 403/405?
From: Stephen Neuendorffer @ 2007-05-31 19:37 UTC (permalink / raw)
  To: bert_maxel, linuxppc-embedded
In-Reply-To: <10900170.post@talk.nabble.com>


There is an opb core developed for the Xilinx University Program board,
which
has a similar hardware interface to the ML403 (i.e. no PCI bridge)
The XUPV2P web page with the opb_ac97 core is here:
http://www.xilinx.com/univ/xupv2p.html=20

I have a /dev/dsp driver (which I'll send to Bert directly) which limps
along in 2.6.
This core has a relatively small buffer and no master access to memory,
which
results in relatively poor performance, but it is a starting point.

Steve

> -----Original Message-----
> From:=20
> linuxppc-embedded-bounces+stephen=3Dneuendorffer.name@ozlabs.org
> =20
> [mailto:linuxppc-embedded-bounces+stephen=3Dneuendorffer.name@oz
labs.org] On Behalf Of bert_maxel
> Sent: Thursday, May 31, 2007 12:10 PM
> To: linuxppc-embedded@ozlabs.org
> Subject: Re: Audio Dirver for the 403/405?
>=20
>=20
>=20
>=20
> Grant Likely-2 wrote:
> >=20
> > On 5/30/07, bert_maxel <bonlutin@hotmail.com> wrote:
> >>
> >> Hi all,
> >>
> >> Has anybody got some working audio driver (linux) for the =20
> ML403/405 ?
> >> I know it's an ac97 codec, but I can't find anything=20
> related to the=20
> >> xilinx boards?
> >> If nobody has worked on this yet, I'm in trouble. I don't=20
> know where=20
> >> to start, or from what ac97 driver should I base my=20
> initial development?
> >=20
> > IIRC, the old mvista 2.4 tree has an audio driver.
> >=20
> > g.
> >=20
> > --
> > Grant Likely, B.Sc., P.Eng.
> > Secret Lab Technologies Ltd.
> > grant.likely@secretlab.ca
> > (403) 399-0195
> > _______________________________________________
> > Linuxppc-embedded mailing list
> > Linuxppc-embedded@ozlabs.org
> > https://ozlabs.org/mailman/listinfo/linuxppc-embedded
> >=20
> >=20
>=20
> There are plenty of boards with an ac97 codec, but what's=20
> missing is the glue for the ML403 board, there's no pci bus=20
> in this case,  opb cores instead.
> I hope somebody can point me to a link of interest.
>=20
> thanks
> --
> View this message in context:=20
> http://www.nabble.com/Audio-Dirver-for-the-403-405--tf3843165.
html#a10900170
> Sent from the linuxppc-embedded mailing list archive at Nabble.com.
>=20
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>=20
>=20

^ permalink raw reply

* [PATCH 1/3] powerpc: Remove 'make zImage.dts' feature
From: Mark A. Greer @ 2007-05-31 19:54 UTC (permalink / raw)
  To: linuxppc-dev; +Cc: David Gibson
In-Reply-To: <20070531195136.GA3699@mag.az.mvista.com>


Being able to selectively wrap a device tree with the zIimage at build
time has deemed unnecessary so remove Makefile support for that feature.

Signed-off-by: Mark A. Greer <mgreer@mvista.com>

---
 arch/powerpc/Makefile      |    2 +-
 arch/powerpc/boot/Makefile |   26 +-------------------------
 2 files changed, 2 insertions(+), 26 deletions(-)

diff --git a/arch/powerpc/Makefile b/arch/powerpc/Makefile
index 6238b58..24e1217 100644
--- a/arch/powerpc/Makefile
+++ b/arch/powerpc/Makefile
@@ -149,7 +149,7 @@ all: $(KBUILD_IMAGE)
 
 CPPFLAGS_vmlinux.lds	:= -Upowerpc
 
-BOOT_TARGETS = zImage zImage.initrd zImage.dts zImage.dts_initrd uImage
+BOOT_TARGETS = zImage zImage.initrd uImage
 
 PHONY += $(BOOT_TARGETS)
 
diff --git a/arch/powerpc/boot/Makefile b/arch/powerpc/boot/Makefile
index 8378898..aef95bd 100644
--- a/arch/powerpc/boot/Makefile
+++ b/arch/powerpc/boot/Makefile
@@ -158,27 +158,9 @@ targets	+= $(image-y) $(initrd-y)
 
 $(addprefix $(obj)/, $(initrd-y)): $(obj)/ramdisk.image.gz
 
-dts-  := $(patsubst zImage%, zImage.dts%, $(image-n) $(image-))
-dts-y := $(patsubst zImage%, zImage.dts%, $(image-y))
-dts-y := $(filter-out $(image-y), $(dts-y))
-targets	+= $(image-y) $(dts-y)
-
-dts_initrd-  := $(patsubst zImage%, zImage.dts_initrd%, $(image-n) $(image-))
-dts_initrd-y := $(patsubst zImage%, zImage.dts_initrd%, $(image-y))
-dts_initrd-y := $(filter-out $(image-y), $(dts_initrd-y))
-targets	+= $(image-y) $(dts_initrd-y)
-
-$(addprefix $(obj)/, $(dts_initrd-y)): $(obj)/ramdisk.image.gz
-
 # Don't put the ramdisk on the pattern rule; when its missing make will try
 # the pattern rule with less dependencies that also matches (even with the
 # hard dependency listed).
-$(obj)/zImage.dts_initrd.%: vmlinux $(wrapperbits) $(dts) $(obj)/ramdisk.image.gz
-	$(call if_changed,wrap,$*,$(dts),,$(obj)/ramdisk.image.gz)
-
-$(obj)/zImage.dts.%: vmlinux $(wrapperbits) $(dts)
-	$(call if_changed,wrap,$*,$(dts))
-
 $(obj)/zImage.initrd.%: vmlinux $(wrapperbits)
 	$(call if_changed,wrap,$*,,,$(obj)/ramdisk.image.gz)
 
@@ -217,18 +199,12 @@ $(obj)/zImage:		$(addprefix $(obj)/, $(image-y))
 	@rm -f $@; ln $< $@
 $(obj)/zImage.initrd:	$(addprefix $(obj)/, $(initrd-y))
 	@rm -f $@; ln $< $@
-$(obj)/zImage.dts:	$(addprefix $(obj)/, $(dts-y))
-	@rm -f $@; ln $< $@
-$(obj)/zImage.dts_initrd:	$(addprefix $(obj)/, $(dts_initrd-y))
-	@rm -f $@; ln $< $@
-
 
 install: $(CONFIGURE) $(addprefix $(obj)/, $(image-y))
 	sh -x $(srctree)/$(src)/install.sh "$(KERNELRELEASE)" vmlinux System.map "$(INSTALL_PATH)" $<
 
 # anything not in $(targets)
-clean-files += $(image-) $(initrd-) zImage zImage.initrd cuImage.* \
-	treeImage.* zImage.dts zImage.dts_initrd
+clean-files += $(image-) $(initrd-) zImage zImage.initrd cuImage.* treeImage.*
 
 # clean up files cached by wrapper
 clean-kernel := vmlinux.strip vmlinux.bin

^ permalink raw reply related

* [PATCH 2/3] powerpc: When appropriate, wrap device tree with zImage
From: Mark A. Greer @ 2007-05-31 19:55 UTC (permalink / raw)
  To: linuxppc-dev; +Cc: David Gibson
In-Reply-To: <20070531195136.GA3699@mag.az.mvista.com>


There are 2 config options that indicate whether the platform being built
has a device tree source file associated with it.  Namely,
CONFIG_WANT_DEVICE_TREE and CONFIG_DEVICE_TREE.  When CONFIG_WANT_DEVICE_TREE
is 'y' and CONFIG_DEVICE_TREE isn't an empty string, automatically wrap
the specified device tree with the zImage being built.

To achieve this, the 'dts' variable will only be set when the conditions
above are true.  The changes to the zImage.initrd.% and zImage.% rules
cause the device tree to be wrapped when 'dts' is set; otherwise, they
will work as they previosly did (i.e., build a zImage with no device tree).

Signed-off-by: Mark A. Greer <mgreer@mvista.com>

---
 arch/powerpc/boot/Makefile |   22 ++++++++++++++--------
 1 file changed, 14 insertions(+), 8 deletions(-)

diff --git a/arch/powerpc/boot/Makefile b/arch/powerpc/boot/Makefile
index aef95bd..c6f8a0c 100644
--- a/arch/powerpc/boot/Makefile
+++ b/arch/powerpc/boot/Makefile
@@ -158,14 +158,24 @@ targets	+= $(image-y) $(initrd-y)
 
 $(addprefix $(obj)/, $(initrd-y)): $(obj)/ramdisk.image.gz
 
+# If CONFIG_WANT_DEVICE_TREE is set and CONFIG_DEVICE_TREE isn't an
+# empty string, define 'dts' to be path to the dts
+# CONFIG_DEVICE_TREE will have "" around it, make sure to strip them
+ifeq ($(CONFIG_WANT_DEVICE_TREE),y)
+ifneq ($(CONFIG_DEVICE_TREE),"")
+dts = $(if $(shell echo $(CONFIG_DEVICE_TREE) | grep '^/'),\
+	,$(srctree)/$(src)/dts/)$(CONFIG_DEVICE_TREE:"%"=%)
+endif
+endif
+
 # Don't put the ramdisk on the pattern rule; when its missing make will try
 # the pattern rule with less dependencies that also matches (even with the
 # hard dependency listed).
-$(obj)/zImage.initrd.%: vmlinux $(wrapperbits)
-	$(call if_changed,wrap,$*,,,$(obj)/ramdisk.image.gz)
+$(obj)/zImage.initrd.%: vmlinux $(wrapperbits) $(dts)
+	$(call if_changed,wrap,$*,$(dts),,$(obj)/ramdisk.image.gz)
 
-$(obj)/zImage.%: vmlinux $(wrapperbits)
-	$(call if_changed,wrap,$*)
+$(obj)/zImage.%: vmlinux $(wrapperbits) $(dts)
+	$(call if_changed,wrap,$*,$(dts))
 
 $(obj)/zImage.ps3: vmlinux
 	$(STRIP) -s -R .comment $< -o $@
@@ -182,10 +192,6 @@ $(obj)/zImage.initrd.holly-elf: vmlinux $(wrapperbits) $(obj)/ramdisk.image.gz
 $(obj)/uImage: vmlinux $(wrapperbits)
 	$(call if_changed,wrap,uboot)
 
-# CONFIG_DEVICE_TREE will have "" around it, make sure to strip them
-dts = $(if $(shell echo $(CONFIG_DEVICE_TREE) | grep '^/'),\
-	,$(srctree)/$(src)/dts/)$(CONFIG_DEVICE_TREE:"%"=%)
-
 $(obj)/cuImage.%: vmlinux $(dts) $(wrapperbits)
 	$(call if_changed,wrap,cuboot-$*,$(dts))
 

^ permalink raw reply related

* [PATCH 3/3] powerpc: Update holly to use new dts wrapping feature
From: Mark A. Greer @ 2007-05-31 19:56 UTC (permalink / raw)
  To: linuxppc-dev; +Cc: David Gibson
In-Reply-To: <20070531195136.GA3699@mag.az.mvista.com>


The holly support currently has separate rules to wrap its device tree
with its zImage.  This can now be done automatically without the extra
rules so update holly support to use the automatic feature.

Signed-off-by: Mark A. Greer <mgreer@mista.com>

---

Josh, please take a look at this patch and if you approve, give me an
Acked-by: line (thanks).  Note that 'zImage.holly-elf' was changed to
'zImage.holly'.

 arch/powerpc/boot/Makefile                 |    8 -
 arch/powerpc/configs/holly_defconfig       |  104 +++++++------------
 arch/powerpc/platforms/embedded6xx/Kconfig |    1 
 3 files changed, 43 insertions(+), 70 deletions(-)

diff --git a/arch/powerpc/boot/Makefile b/arch/powerpc/boot/Makefile
index 06f0a5d..b8011e9 100644
--- a/arch/powerpc/boot/Makefile
+++ b/arch/powerpc/boot/Makefile
@@ -134,7 +134,7 @@ image-$(CONFIG_PPC_CELLEB)		+= zImage.pseries
 image-$(CONFIG_PPC_CHRP)		+= zImage.chrp
 image-$(CONFIG_PPC_EFIKA)		+= zImage.chrp
 image-$(CONFIG_PPC_PMAC)		+= zImage.pmac
-image-$(CONFIG_PPC_HOLLY)		+= zImage.holly-elf
+image-$(CONFIG_PPC_HOLLY)		+= zImage.holly
 image-$(CONFIG_PPC_PRPMC2800)		+= zImage.prpmc2800
 image-$(CONFIG_DEFAULT_UIMAGE)		+= uImage
 
@@ -183,12 +183,6 @@ $(obj)/zImage.ps3: vmlinux
 $(obj)/zImage.initrd.ps3: vmlinux
 	@echo "  WARNING zImage.initrd.ps3 not supported (yet)"
 
-$(obj)/zImage.holly-elf: vmlinux $(wrapperbits)
-	$(call if_changed,wrap,holly,$(obj)/dts/holly.dts,,)
-
-$(obj)/zImage.initrd.holly-elf: vmlinux $(wrapperbits) $(obj)/ramdisk.image.gz
-	$(call if_changed,wrap,holly,$(obj)/dts/holly.dts,,$(obj)/ramdisk.image.gz)
-
 $(obj)/uImage: vmlinux $(wrapperbits)
 	$(call if_changed,wrap,uboot)
 
diff --git a/arch/powerpc/configs/holly_defconfig b/arch/powerpc/configs/holly_defconfig
index be633b9..423bdd2 100644
--- a/arch/powerpc/configs/holly_defconfig
+++ b/arch/powerpc/configs/holly_defconfig
@@ -1,7 +1,7 @@
 #
 # Automatically generated make config: don't edit
-# Linux kernel version: 2.6.21
-# Sat May  5 11:02:35 2007
+# Linux kernel version: 2.6.22-rc2
+# Thu May 31 11:25:44 2007
 #
 # CONFIG_PPC64 is not set
 CONFIG_PPC32=y
@@ -45,6 +45,7 @@ CONFIG_PPC_FPU=y
 # CONFIG_ALTIVEC is not set
 CONFIG_PPC_STD_MMU=y
 CONFIG_PPC_STD_MMU_32=y
+# CONFIG_PPC_MM_SLICES is not set
 # CONFIG_SMP is not set
 CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"
 
@@ -70,6 +71,7 @@ CONFIG_SYSVIPC_SYSCTL=y
 # CONFIG_UTS_NS is not set
 # CONFIG_AUDIT is not set
 # CONFIG_IKCONFIG is not set
+CONFIG_LOG_BUF_SHIFT=14
 CONFIG_SYSFS_DEPRECATED=y
 # CONFIG_RELAY is not set
 CONFIG_BLK_DEV_INITRD=y
@@ -87,14 +89,19 @@ CONFIG_BUG=y
 CONFIG_ELF_CORE=y
 CONFIG_BASE_FULL=y
 CONFIG_FUTEX=y
+CONFIG_ANON_INODES=y
 CONFIG_EPOLL=y
+CONFIG_SIGNALFD=y
+CONFIG_TIMERFD=y
+CONFIG_EVENTFD=y
 CONFIG_SHMEM=y
-CONFIG_SLAB=y
 CONFIG_VM_EVENT_COUNTERS=y
+CONFIG_SLAB=y
+# CONFIG_SLUB is not set
+# CONFIG_SLOB is not set
 CONFIG_RT_MUTEXES=y
 # CONFIG_TINY_SHMEM is not set
 CONFIG_BASE_SMALL=0
-# CONFIG_SLOB is not set
 
 #
 # Loadable module support
@@ -140,6 +147,7 @@ CONFIG_EMBEDDED6xx=y
 # CONFIG_LINKSTATION is not set
 # CONFIG_MPC7448HPC2 is not set
 CONFIG_PPC_HOLLY=y
+# CONFIG_PPC_PRPMC2800 is not set
 CONFIG_TSI108_BRIDGE=y
 CONFIG_MPIC=y
 CONFIG_MPIC_WEIRD=y
@@ -185,7 +193,8 @@ CONFIG_PROC_DEVICETREE=y
 # CONFIG_CMDLINE_BOOL is not set
 # CONFIG_PM is not set
 # CONFIG_SECCOMP is not set
-# CONFIG_WANT_DEVICE_TREE is not set
+CONFIG_WANT_DEVICE_TREE=y
+CONFIG_DEVICE_TREE="holly.dts"
 CONFIG_ISA_DMA_API=y
 
 #
@@ -197,16 +206,14 @@ CONFIG_GENERIC_ISA_DMA=y
 CONFIG_PCI=y
 CONFIG_PCI_DOMAINS=y
 # CONFIG_PCIEPORTBUS is not set
+CONFIG_ARCH_SUPPORTS_MSI=y
+# CONFIG_PCI_MSI is not set
 # CONFIG_PCI_DEBUG is not set
 
 #
 # PCCARD (PCMCIA/CardBus) support
 #
 # CONFIG_PCCARD is not set
-
-#
-# PCI Hotplug Support
-#
 # CONFIG_HOTPLUG_PCI is not set
 
 #
@@ -317,7 +324,9 @@ CONFIG_DEFAULT_TCP_CONG="cubic"
 #
 # CONFIG_CFG80211 is not set
 # CONFIG_WIRELESS_EXT is not set
+# CONFIG_MAC80211 is not set
 # CONFIG_IEEE80211 is not set
+# CONFIG_RFKILL is not set
 
 #
 # Device Drivers
@@ -372,12 +381,10 @@ CONFIG_BLK_DEV_RAM_BLOCKSIZE=1024
 #
 # Misc devices
 #
+# CONFIG_PHANTOM is not set
 # CONFIG_SGI_IOC4 is not set
 # CONFIG_TIFM_CORE is not set
-
-#
-# ATA/ATAPI/MFM/RLL support
-#
+# CONFIG_BLINK is not set
 # CONFIG_IDE is not set
 
 #
@@ -406,6 +413,7 @@ CONFIG_BLK_DEV_SD=y
 # CONFIG_SCSI_CONSTANTS is not set
 # CONFIG_SCSI_LOGGING is not set
 # CONFIG_SCSI_SCAN_ASYNC is not set
+CONFIG_SCSI_WAIT_SCAN=m
 
 #
 # SCSI Transports
@@ -455,10 +463,6 @@ CONFIG_BLK_DEV_SD=y
 # CONFIG_SCSI_DEBUG is not set
 # CONFIG_SCSI_ESP_CORE is not set
 # CONFIG_SCSI_SRP is not set
-
-#
-# Serial ATA (prod) and Parallel ATA (experimental) drivers
-#
 CONFIG_ATA=y
 # CONFIG_ATA_NONSTANDARD is not set
 # CONFIG_SATA_AHCI is not set
@@ -531,6 +535,7 @@ CONFIG_ATA=y
 #
 # IEEE 1394 (FireWire) support
 #
+# CONFIG_FIREWIRE is not set
 # CONFIG_IEEE1394 is not set
 
 #
@@ -552,10 +557,6 @@ CONFIG_NETDEVICES=y
 # ARCnet devices
 #
 # CONFIG_ARCNET is not set
-
-#
-# PHY device support
-#
 CONFIG_PHYLIB=y
 
 #
@@ -589,10 +590,7 @@ CONFIG_VORTEX=y
 # CONFIG_NET_TULIP is not set
 # CONFIG_HP100 is not set
 # CONFIG_NET_PCI is not set
-
-#
-# Ethernet (1000 Mbit)
-#
+CONFIG_NETDEV_1000=y
 # CONFIG_ACENIC is not set
 # CONFIG_DL2K is not set
 # CONFIG_E1000 is not set
@@ -609,16 +607,14 @@ CONFIG_VORTEX=y
 CONFIG_TSI108_ETH=y
 # CONFIG_QLA3XXX is not set
 # CONFIG_ATL1 is not set
-
-#
-# Ethernet (10000 Mbit)
-#
+CONFIG_NETDEV_10000=y
 # CONFIG_CHELSIO_T1 is not set
 # CONFIG_CHELSIO_T3 is not set
 # CONFIG_IXGB is not set
 # CONFIG_S2IO is not set
 # CONFIG_MYRI10GE is not set
 # CONFIG_NETXEN_NIC is not set
+# CONFIG_MLX4_CORE is not set
 
 #
 # Token Ring devices
@@ -630,10 +626,6 @@ CONFIG_TSI108_ETH=y
 #
 # CONFIG_WLAN_PRE80211 is not set
 # CONFIG_WLAN_80211 is not set
-
-#
-# Wan interfaces
-#
 # CONFIG_WAN is not set
 # CONFIG_FDDI is not set
 # CONFIG_HIPPI is not set
@@ -676,6 +668,7 @@ CONFIG_INPUT=y
 # CONFIG_INPUT_KEYBOARD is not set
 # CONFIG_INPUT_MOUSE is not set
 # CONFIG_INPUT_JOYSTICK is not set
+# CONFIG_INPUT_TABLET is not set
 # CONFIG_INPUT_TOUCHSCREEN is not set
 # CONFIG_INPUT_MISC is not set
 
@@ -721,16 +714,11 @@ CONFIG_LEGACY_PTY_COUNT=256
 # IPMI
 #
 # CONFIG_IPMI_HANDLER is not set
-
-#
-# Watchdog Cards
-#
 # CONFIG_WATCHDOG is not set
 # CONFIG_HW_RANDOM is not set
 # CONFIG_NVRAM is not set
 CONFIG_GEN_RTC=y
 # CONFIG_GEN_RTC_X is not set
-# CONFIG_DTLK is not set
 # CONFIG_R3964 is not set
 # CONFIG_APPLICOM is not set
 # CONFIG_AGP is not set
@@ -741,10 +729,7 @@ CONFIG_GEN_RTC=y
 # TPM devices
 #
 # CONFIG_TCG_TPM is not set
-
-#
-# I2C support
-#
+CONFIG_DEVPORT=y
 # CONFIG_I2C is not set
 
 #
@@ -757,16 +742,15 @@ CONFIG_GEN_RTC=y
 # Dallas's 1-wire bus
 #
 # CONFIG_W1 is not set
-
-#
-# Hardware Monitoring support
-#
 CONFIG_HWMON=y
 # CONFIG_HWMON_VID is not set
 # CONFIG_SENSORS_ABITUGURU is not set
 # CONFIG_SENSORS_F71805F is not set
 # CONFIG_SENSORS_PC87427 is not set
+# CONFIG_SENSORS_SMSC47M1 is not set
+# CONFIG_SENSORS_SMSC47B397 is not set
 # CONFIG_SENSORS_VT1211 is not set
+# CONFIG_SENSORS_W83627HF is not set
 # CONFIG_HWMON_DEBUG_CHIP is not set
 
 #
@@ -778,16 +762,19 @@ CONFIG_HWMON=y
 # Multimedia devices
 #
 # CONFIG_VIDEO_DEV is not set
+# CONFIG_DVB_CORE is not set
+CONFIG_DAB=y
 
 #
-# Digital Video Broadcasting Devices
+# Graphics support
 #
-# CONFIG_DVB is not set
+# CONFIG_BACKLIGHT_LCD_SUPPORT is not set
 
 #
-# Graphics support
+# Display device support
 #
-# CONFIG_BACKLIGHT_LCD_SUPPORT is not set
+# CONFIG_DISPLAY_SUPPORT is not set
+# CONFIG_VGASTATE is not set
 # CONFIG_FB is not set
 # CONFIG_FB_IBM_GXT4500 is not set
 
@@ -818,10 +805,6 @@ CONFIG_USB_ARCH_HAS_EHCI=y
 # USB Gadget Support
 #
 # CONFIG_USB_GADGET is not set
-
-#
-# MMC/SD Card support
-#
 # CONFIG_MMC is not set
 
 #
@@ -865,14 +848,6 @@ CONFIG_USB_ARCH_HAS_EHCI=y
 #
 
 #
-# Auxiliary Display support
-#
-
-#
-# Virtualization
-#
-
-#
 # File systems
 #
 CONFIG_EXT2_FS=y
@@ -957,6 +932,7 @@ CONFIG_ROOT_NFS=y
 CONFIG_LOCKD=y
 CONFIG_NFS_COMMON=y
 CONFIG_SUNRPC=y
+# CONFIG_SUNRPC_BIND34 is not set
 # CONFIG_RPCSEC_GSS_KRB5 is not set
 # CONFIG_RPCSEC_GSS_SPKM3 is not set
 # CONFIG_SMB_FS is not set
@@ -986,6 +962,7 @@ CONFIG_MSDOS_PARTITION=y
 # CONFIG_SUN_PARTITION is not set
 # CONFIG_KARMA_PARTITION is not set
 # CONFIG_EFI_PARTITION is not set
+# CONFIG_SYSV68_PARTITION is not set
 
 #
 # Native Language Support
@@ -1005,11 +982,13 @@ CONFIG_MSDOS_PARTITION=y
 CONFIG_BITREVERSE=y
 # CONFIG_CRC_CCITT is not set
 # CONFIG_CRC16 is not set
+# CONFIG_CRC_ITU_T is not set
 CONFIG_CRC32=y
 # CONFIG_LIBCRC32C is not set
 CONFIG_PLIST=y
 CONFIG_HAS_IOMEM=y
 CONFIG_HAS_IOPORT=y
+CONFIG_HAS_DMA=y
 
 #
 # Instrumentation Support
@@ -1028,7 +1007,6 @@ CONFIG_MAGIC_SYSRQ=y
 # CONFIG_HEADERS_CHECK is not set
 CONFIG_DEBUG_KERNEL=y
 # CONFIG_DEBUG_SHIRQ is not set
-CONFIG_LOG_BUF_SHIFT=14
 CONFIG_DETECT_SOFTLOCKUP=y
 # CONFIG_SCHEDSTATS is not set
 # CONFIG_TIMER_STATS is not set
diff --git a/arch/powerpc/platforms/embedded6xx/Kconfig b/arch/powerpc/platforms/embedded6xx/Kconfig
index f2d2626..91a1652 100644
--- a/arch/powerpc/platforms/embedded6xx/Kconfig
+++ b/arch/powerpc/platforms/embedded6xx/Kconfig
@@ -28,6 +28,7 @@ config PPC_HOLLY
 	bool "PPC750GX/CL with TSI10x bridge (Hickory/Holly)"
 	select TSI108_BRIDGE
 	select PPC_UDBG_16550
+	select WANT_DEVICE_TREE
 	help
 	  Select PPC_HOLLY if configuring for an IBM 750GX/CL Eval
 	  Board with TSI108/9 bridge (Hickory/Holly)

^ permalink raw reply related

* Re: [PATCH] Donate dedicated CPU cycles
From: Olof Johansson @ 2007-05-31 20:14 UTC (permalink / raw)
  To: Jake Moilanen; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <1180638885.5756.11.camel@goblue>

Hi,

On Thu, May 31, 2007 at 02:14:45PM -0500, Jake Moilanen wrote:
> A Power6 can give up CPU cycles on a dedicated CPU (as opposed to a
> shared CPU) to other shared processors if the administrator asks for it
> (via the HMC).
> 
> This patch enables that to work properly on P6.
> 
> This just involves setting a bit in the CAS structure as well as the
> VPA.  To donate cycles, a CPU has to have all SMT threads idle and w/
> donate bit set in the VPA.  Then call H_CEDE.

[...]

> Index: powerpc/arch/powerpc/platforms/pseries/setup.c
> ===================================================================
> --- powerpc.orig/arch/powerpc/platforms/pseries/setup.c
> +++ powerpc/arch/powerpc/platforms/pseries/setup.c
> @@ -399,6 +399,7 @@ static void pseries_dedicated_idle_sleep
>  	 * a good time to find other work to dispatch.
>  	 */
>  	get_lppaca()->idle = 1;
> +	get_lppaca()->cpuctls_task_attrs = 1;
>  
>  	/*
>  	 * We come in with interrupts disabled, and need_resched()
> @@ -431,6 +432,7 @@ static void pseries_dedicated_idle_sleep
>  
>  out:
>  	HMT_medium();
> +	get_lppaca()->cpuctls_task_attrs = 0;
>  	get_lppaca()->idle = 0;
>  }

Is this really the cpu controls task attribute field any more?  If this
is not just a flag (stored in a byte), the variable should be renamed
accordingly. If it is truly an attribute bitfield, then the attributes
should be named and constants used instead.


-Olof

^ permalink raw reply

* Re: 2.6.22-rc3-mm1
From: Mariusz Kozlowski @ 2007-05-31 20:43 UTC (permalink / raw)
  To: Andrew Morton, linuxppc-dev, paulus, Arnd Bergmann; +Cc: linux-kernel
In-Reply-To: <20070530235823.793f00d9.akpm@linux-foundation.org>

Hello

	This is from iMac G3. The spufs_mem_mmap_fault() code looks bad
in arch/powerpc/platforms/cell/spufs/file.c but somehow I'm unable to find
the patch to blame hmm.

arch/powerpc/platforms/cell/spufs/file.c: In function 'spufs_mem_mmap_fault':
arch/powerpc/platforms/cell/spufs/file.c:122: error: 'address' undeclared (first use in this function)
arch/powerpc/platforms/cell/spufs/file.c:122: error: (Each undeclared identifier is reported only once
arch/powerpc/platforms/cell/spufs/file.c:122: error: for each function it appears in.)
arch/powerpc/platforms/cell/spufs/file.c:141: error: expected ';' before 'if'
arch/powerpc/platforms/cell/spufs/file.c:122: warning: unused variable 'addr0'
make[3]: *** [arch/powerpc/platforms/cell/spufs/file.o] Blad 1
make[2]: *** [arch/powerpc/platforms/cell/spufs] Blad 2
make[1]: *** [arch/powerpc/platforms/cell] Blad 2

Regards,

	Mariusz

^ permalink raw reply

* Re: 2.6.22-rc3-mm1
From: Andrew Morton @ 2007-05-31 21:19 UTC (permalink / raw)
  To: Mariusz Kozlowski
  Cc: linuxppc-dev, paulus, Arnd Bergmann, Nick Piggin, linux-kernel
In-Reply-To: <200705312243.18724.m.kozlowski@tuxland.pl>

On Thu, 31 May 2007 22:43:18 +0200
Mariusz Kozlowski <m.kozlowski@tuxland.pl> wrote:

> Hello
> 
> 	This is from iMac G3. The spufs_mem_mmap_fault() code looks bad
> in arch/powerpc/platforms/cell/spufs/file.c but somehow I'm unable to find
> the patch to blame hmm.
> 
> arch/powerpc/platforms/cell/spufs/file.c: In function 'spufs_mem_mmap_fault':
> arch/powerpc/platforms/cell/spufs/file.c:122: error: 'address' undeclared (first use in this function)
> arch/powerpc/platforms/cell/spufs/file.c:122: error: (Each undeclared identifier is reported only once
> arch/powerpc/platforms/cell/spufs/file.c:122: error: for each function it appears in.)
> arch/powerpc/platforms/cell/spufs/file.c:141: error: expected ';' before 'if'
> arch/powerpc/platforms/cell/spufs/file.c:122: warning: unused variable 'addr0'
> make[3]: *** [arch/powerpc/platforms/cell/spufs/file.o] Blad 1
> make[2]: *** [arch/powerpc/platforms/cell/spufs] Blad 2
> make[1]: *** [arch/powerpc/platforms/cell] Blad 2
> 

Yeah, that's the fix-fault-vs-invalidate-race patches, or my poor attempt
to fix them when spufs changed.  I suppose I'll have a poke at it next time
I get the powerpc machine fired up.

^ permalink raw reply

* Re: [PATCH 3/3] powerpc: Update holly to use new dts wrapping feature
From: Josh Boyer @ 2007-05-31 21:25 UTC (permalink / raw)
  To: Mark A. Greer; +Cc: linuxppc-dev, David Gibson
In-Reply-To: <20070531195615.GC3818@mag.az.mvista.com>

On Thu, 2007-05-31 at 12:56 -0700, Mark A. Greer wrote:
> The holly support currently has separate rules to wrap its device tree
> with its zImage.  This can now be done automatically without the extra
> rules so update holly support to use the automatic feature.

Oh good.  I like that idea already.

> Signed-off-by: Mark A. Greer <mgreer@mista.com>
> 
> ---
> 
> Josh, please take a look at this patch and if you approve, give me an
> Acked-by: line (thanks).  

I'll test this on Monday first thing.

> Note that 'zImage.holly-elf' was changed to
> 'zImage.holly'.

That part is fine either way.

josh

^ permalink raw reply

* RE: [PATCH 3/5] Float the pci bus number on MPC8641HPCN board.
From: Zhang Wei-r63237 @ 2007-06-01  2:01 UTC (permalink / raw)
  To: Kumar Gala; +Cc: linuxppc-dev, paulus
In-Reply-To: <F1C4E37E-FF0F-4A5F-AC49-860B4AAC4E28@kernel.crashing.org>

Hi, Kumar,=20

>=20
> Can this be fixed by just setting hose->bus_offset in add_bridge?
>=20
> Doing this in exclude is very bad.

That's my original doing. If there a PCI bridge card be pluged into PCI
slot of hose0, I can not ensue the bus_offset number of hose1.

Wei.

>=20
> - k
>=20
> >> -----Original Message-----
> >> From: Wade Farnsworth [mailto:wfarnsworth@mvista.com]
> >> Subject: Re: [PATCH 3/5] Float the pci bus number on
> >> MPC8641HPCN board.
> >>
> >> On Tue, 2007-05-22 at 11:38 +0800, Zhang Wei wrote:
> >>>  int mpc86xx_exclude_device(u_char bus, u_char devfn)
> >>>  {
> >>> +	struct pci_controller *hose;
> >>> +
> >>> +	hose =3D pci_bus_to_hose(bus);
> >>> +	if (unlikely(!hose))
> >>> +		return PCIBIOS_DEVICE_NOT_FOUND;
> >>> +
> >>> +	/* Correcting the hose->bus_offset value. */
> >>> +	out_be32(hose->cfg_addr, 0x80000000 | ((hose->first_busno
> >>> +					- hose->bus_offset) << 16));
> >>> +	if (unlikely(in_le32(hose->cfg_data) =3D=3D 0xffffffff))
> >>> +		hose->bus_offset =3D hose->bus_offset ? 0 :
> >> hose->first_busno;
> >>> +
> >>>  	return PCIBIOS_SUCCESSFUL;
> >>>  }
> >>
> >> What is the purpose of this code and why put it in
> >> mpc86xx_exclude_device?
> >>
> >> --Wade
> >>
> >>
> > _______________________________________________
> > Linuxppc-dev mailing list
> > Linuxppc-dev@ozlabs.org
> > https://ozlabs.org/mailman/listinfo/linuxppc-dev
>=20
>=20

^ permalink raw reply

* Re: [PATCH 3/5] Float the pci bus number on MPC8641HPCN board.
From: Kumar Gala @ 2007-06-01  5:08 UTC (permalink / raw)
  To: Zhang Wei-r63237; +Cc: linuxppc-dev, paulus
In-Reply-To: <46B96294322F7D458F9648B60E15112C30777C@zch01exm26.fsl.freescale.net>


On May 31, 2007, at 9:01 PM, Zhang Wei-r63237 wrote:

> Hi, Kumar,
>
>>
>> Can this be fixed by just setting hose->bus_offset in add_bridge?
>>
>> Doing this in exclude is very bad.
>
> That's my original doing. If there a PCI bridge card be pluged into  
> PCI
> slot of hose0, I can not ensue the bus_offset number of hose1.

Ok, but can't we use hose0's last_busno and use that set hose1- 
 >first_busno & hose1->bus_offset?

- k

^ permalink raw reply


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox