From mrv@corecom.co.kr Thu Jun 1 03:42:09 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 01 Jun 2006 03:42:18 +0200 (CEST) Received: from [220.76.242.187] ([220.76.242.187]:60810 "EHLO localhost.localdomain") by ftp.linux-mips.org with ESMTP id S8133654AbWFABmJ (ORCPT ); Thu, 1 Jun 2006 03:42:09 +0200 Received: from mrv ([192.168.11.157]) by localhost.localdomain (8.12.8/8.12.8) with SMTP id k511hcEE017773; Thu, 1 Jun 2006 10:44:06 +0900 Message-ID: <003801c6851c$9a860250$9d0ba8c0@mrv> From: "Roman Mashak" To: "Raj Palani" Cc: References: <478F19F21671F04298A2116393EEC3D5273E4F@sjc1exm08.pmc_nt.nt.pmc-sierra.bc.ca> Subject: Re: compiling BCM5700 driver Date: Thu, 1 Jun 2006 10:41:45 +0900 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="koi8-r"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 FL-Build: Fidolook 2002 (SL) 6.0.2800.86 - 14/6/2003 22:16:25 Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11628 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: mrv@corecom.co.kr Precedence: bulk X-list: linux-mips Hello, Raj! You wrote to "Roman Mashak" ; "Ralf Baechle" on Wed, 31 May 2006 09:06:44 -0700: RP> Yes. We are currently maintaining the Titan GE driver on "Sequoia" RP> only in 2.6.x. The GE driver in Sequoia has been renamed to RP> msp85xx_ge.c. We are in the process of generating a patchset to add RP> support for Sequoia (MSP8510/MSP8520) in the Linux/MIPS 2.6 tree. RP> Our most recent Linux 2.6 tree for Sequoia is available on our ftp site RP> (ftp.pmc-sierra.com) under RP> /pub/linux/2.6.12/linux-2.6.12-rc3_L002.tar.gz. There are msp85x0_ge.[ch] in this tarball. And seems old code from titan_ge.[ch] is still in used. Nevertheless kernel gets panic: Linux version 2.6.12-rc3 (root@ecb-test32.corecom.local) (gcc version 3.3-mips64linux-031001) #1 Thu Jun 1 10:33:22 KST 2006 PMON reports memory size 256MB cpu_clock set to 900000000 CPU revision is: 000034c1 FPU revision is: 00003420 PMC-Sierra Sequoia Board Setup 32-bit support Determined physical RAM map: memory: 20000000 @ 00000000 (usable) Built 1 zonelists Kernel command line: tftp://192.168.11.43/vmlinux root=/dev/nfs nfsroot=192.168.11.43:/export/linux/mips-fs-be ip=192.168.11.42:192.168.11.1::255.255.255.0::eth0 Unknown boot option `tftp://192.168.11.43/vmlinux': ignoring Primary instruction cache 16kB, physically tagged, 4-way, linesize 32 bytes. Primary data cache 16kB, 4-way, linesize 32 bytes. Secondary cache size 256K, linesize 32 bytes. Synthesized TLB refill handler (27 instructions). Synthesized TLB load handler fastpath (39 instructions). Synthesized TLB store handler fastpath (39 instructions). Synthesized TLB modify handler fastpath (38 instructions). PID hash table entries: 4096 (order: 12, 65536 bytes) Using 450.000 MHz high precision timer. Dentry cache hash table entries: 131072 (order: 7, 524288 bytes) Inode-cache hash table entries: 65536 (order: 6, 262144 bytes) Memory: 515712k/524288k available (1623k kernel code, 8440k reserved, 372k data, 356k init, 0k highmem) CompactFlash ATA Support for PMC-Sierra Sequoia <6>Internal UART Support for PMC-Sierra Sequoia <7>Calibrating delay loop... 897.02 BogoMIPS (lpj=448512) Mount-cache hash table entries: 512 Checking for 'wait' instruction... available. NET: Registered protocol family 16 PCI: Failed to allocate mem resource #2:20000000@e0000000 for 0000:00:01.0 PCI: Failed to allocate mem resource #2:20000000@e8000000 for 0000:01:01.0 Generic RTC Driver v1.07 Serial: 8250/16550 driver $Revision: 1.1.1.1 $ 4 ports, IRQ sharing disabled ttyS0 at MMIO 0x0 (irq = 0) is a 16550A io scheduler noop registered io scheduler anticipatory registered io scheduler deadline registered io scheduler cfq registered loop: loaded (max 8 devices) PMC-Sierra MSP85x0 10/100/1000 Ethernet Driver Device Id : 206014, Version : 0 : port 0 with MAC address 00:e0:04:00:02:4e Rx NAPI supported, Tx Coalescing ON : port 1 with MAC address 00:e0:04:00:02:4f Rx NAPI supported, Tx Coalescing ON NET: Registered protocol family 2 IP: routing cache hash table of 4096 buckets, 32Kbytes TCP established hash table entries: 131072 (order: 8, 1048576 bytes) TCP bind hash table entries: 65536 (order: 6, 262144 bytes) TCP: Hash tables configured (established 131072 bind 65536) NET: Registered protocol family 1 NET: Registered protocol family 17 Data bus error, epc == 802214d8, ra == 802214ac Oops in arch/mips/kernel/traps.c::do_be, line 338[#1]: Cpu 0 $ 0 : 00000000 90008000 9fc00840 9fc00840 $ 4 : 00000001 00000000 00000000 8036b97c $ 8 : 00000000 801d8150 814df0f0 ffffffff $12 : 00200200 00100100 0000ffff 8036b974 $16 : 9fc00000 816b5920 00000840 81690220 $20 : 0000003c 00000008 ffffffc0 00200000 $24 : 8036b97c 00000001 $28 : 80380000 80381df8 81690000 802214ac Hi : 0006d7ff Lo : f8164000 epc : 802214d8 alloc_skb+0x98/0xec Not tainted ra : 802214ac alloc_skb+0x6c/0xec Status: 90008002 KERNEL EXL Cause : 0000801c PrId : 000034c1 Modules linked in: Process swapper (pid: 1, threadinfo=80380000, task=8037ab78) Stack : 8010d6b0 8026e7e4 814e4e80 80369420 8169030c c01043b0 816b59c0 8021a044 0000001c 00180c01 00000000 00000000 c0000000 00000000 81690220 81690000 8034bc14 00000000 00000000 00000000 00000000 8021a608 803eb9c0 00000000 00000001 80381e68 18230458 80232598 81690000 00000000 00000000 81690220 8021a684 00100000 8021a16c 00000000 8021aaf8 8023743c 00000000 fb004000 ... Call Trace: [<8010d6b0>] dma_map_single+0x5c/0x7c [<8026e7e4>] fib_magic+0x114/0x144 [<8021a044>] msp85x0_ge_rx_task+0x74/0x174 [<8021a608>] xdma_config+0x1cc/0x22c [<80232598>] rtnetlink_fill_ifinfo+0x474/0x57c [<8021a684>] msp85x0_ge_port_start+0x1c/0x74 [<8021a16c>] msp85x0_port_init+0x28/0x80 [<8021aaf8>] msp85x0_eth_setup_tx_ring+0x80/0xc8 [<8023743c>] netlink_broadcast+0x29c/0x478 [<8021adf0>] msp85x0_ge_eth_open+0x114/0x250 [<8021af18>] msp85x0_ge_eth_open+0x23c/0x250 [<80219f14>] msp85x0_ge_open+0x30/0xec [<80232b84>] rtmsg_ifinfo+0x80/0xf8 [<80232b58>] rtmsg_ifinfo+0x54/0xf8 [<80227d2c>] dev_open+0x64/0xd8 [<80227d98>] dev_open+0xd0/0xd8 [<8022d108>] dev_mc_upload+0x18/0x24 [<80229f28>] dev_change_flags+0x70/0x158 [<8019a84c>] proc_create+0x9c/0x100 [<80311fb8>] ic_open_devs+0x20c/0x3a4 [<8012a874>] msleep+0x48/0x5c [<80313524>] ip_auto_config+0x64/0x30c [<8030a7f8>] seqgen_init+0x10/0x20 [<8030a7f8>] seqgen_init+0x10/0x20 [<802f4828>] do_initcalls+0x50/0x100 [<802f4828>] do_initcalls+0x50/0x100 [<802f4908>] do_basic_setup+0x30/0x3c [<801004ac>] init+0x3c/0x120 [<801035d0>] kernel_thread_helper+0x10/0x18 [<801035c0>] kernel_thread_helper+0x0/0x18 Code: ae30008c ac640000 8e220094 8e230094 a4600008 8e220094 a440000a 8e230094 Kernel panic - not syncing: Attempted to kill init! With best regards, Roman Mashak. E-mail: mrv@corecom.co.kr From zzh.hust@gmail.com Thu Jun 1 08:19:35 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 01 Jun 2006 08:19:42 +0200 (CEST) Received: from nf-out-0910.google.com ([64.233.182.187]:65421 "EHLO nf-out-0910.google.com") by ftp.linux-mips.org with ESMTP id S8133350AbWFAGTf (ORCPT ); Thu, 1 Jun 2006 08:19:35 +0200 Received: by nf-out-0910.google.com with SMTP id l36so376233nfa for ; Wed, 31 May 2006 23:19:29 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=iT86CN9FTt8ZSUeEbX70Y+pQHsYbPlkYNTUlCv/A96E1SSahCsp11op/b0XXODk8NKUnGmpwRQ2N5XSKIbtXZzNKootrEWKpSYAcSc4dBTmBnpHC+4lEzA5nrmKadCTbXNipaZhFZV8SZH0Zzuw+RAAQ85xTkVxIjLqOOZjemnw= Received: by 10.49.15.6 with SMTP id s6mr78309nfi; Wed, 31 May 2006 23:19:29 -0700 (PDT) Received: by 10.66.241.4 with HTTP; Wed, 31 May 2006 23:19:25 -0700 (PDT) Message-ID: <50c9a2250605312319v7480f2el36d9c0a052c85d5f@mail.gmail.com> Date: Thu, 1 Jun 2006 14:19:29 +0800 From: zhuzhenhua To: linux-mips Subject: BFD: Warning: Writing section `.text' to huge (ie negative) file offset 0xa1ffff10 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11629 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: zzh.hust@gmail.com Precedence: bulk X-list: linux-mips i have write a code to link at 0xa2000000(uncached address) but when link i get the error as "BFD: Warning: Writing section `.text' to huge (ie negative) file offset 0xa1ffff10. BFD: Warning: Writing section `.data' to huge (ie negative) file offset 0xa200b050. BFD: Warning: Writing section `.reginfo' to huge (ie negative) file offset 0xa200c980. mipsel-linux-objcopy: /root/project/brec_flash/release/brec_flash.bin: File truncated make: *** [brec_flash] Error 1" my link.xn as follow: OUTPUT_ARCH(mips) ENTRY(brec_flash_entry) SECTIONS { .text 0xa2000000 : { release/entry.o (.text) release/*(.text) } .data : { release/*(.data) } .sbss : { release/*(.sbss) release/*(.scommon) } .bss : { release/*(.bss) release/*(COMMON) } } thanks for any hints Best Regards zhuzhenhua From hvr@gnu.org Thu Jun 1 09:54:36 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 01 Jun 2006 09:54:55 +0200 (CEST) Received: from fencepost.gnu.org ([199.232.76.164]:39842 "EHLO fencepost.gnu.org") by ftp.linux-mips.org with ESMTP id S8133350AbWFAHyg (ORCPT ); Thu, 1 Jun 2006 09:54:36 +0200 Received: from hvr by fencepost.gnu.org with local (Exim 4.34) id 1Fli0i-0006o2-Tb; Thu, 01 Jun 2006 03:54:29 -0400 From: Herbert Valerio Riedel Date: Thu, 1 Jun 2006 09:41:04 +0200 To: netdev@vger.kernel.org Cc: linux-mips@linux-mips.org, jgarzik@pobox.com, ppopov@embeddedalley.com, sshtylyov@ru.mvista.com, ralf@linux-mips.org Subject: [PATCH netdev-2.6#upstream] net: au1000_eth: PHY framework conversion Message-Id: Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11630 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: hvr@gnu.org Precedence: bulk X-list: linux-mips convert au1000_eth driver to use PHY framework and garbage collected functions and identifiers that became unused/obsolete in the process Signed-off-by: Herbert Valerio Riedel --- this is a resend of http://marc.theaimsgroup.com/?l=linux-netdev&m=114746547301867&w=2 rebased&handmerged to netdev-2.6#upstream (i.e. on top of sergei's probe code cleanup patch) drivers/net/Kconfig | 1 drivers/net/au1000_eth.c | 1602 +++++++++++----------------------------------- drivers/net/au1000_eth.h | 134 ---- 3 files changed, 378 insertions(+), 1359 deletions(-) 616e5a012a927d401befcbed37b77c3ea42da5a5 diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig index f499a3b..520765d 100644 --- a/drivers/net/Kconfig +++ b/drivers/net/Kconfig @@ -447,6 +447,7 @@ config MIPS_GT96100ETH config MIPS_AU1X00_ENET bool "MIPS AU1000 Ethernet support" depends on NET_ETHERNET && SOC_AU1X00 + select PHYLIB select CRC32 help If you have an Alchemy Semi AU1X00 based system diff --git a/drivers/net/au1000_eth.c b/drivers/net/au1000_eth.c index e1fe960..038d5fc 100644 --- a/drivers/net/au1000_eth.c +++ b/drivers/net/au1000_eth.c @@ -9,6 +9,9 @@ * Update: 2004 Bjoern Riemer, riemer@fokus.fraunhofer.de * or riemer@riemer-nt.de: fixed the link beat detection with * ioctls (SIOCGMIIPHY) + * Copyright 2006 Herbert Valerio Riedel + * converted to use linux-2.6.x's PHY framework + * * Author: MontaVista Software, Inc. * ppopov@mvista.com or source@mvista.com * @@ -53,6 +56,7 @@ #include #include #include #include +#include #include #include #include @@ -88,17 +92,15 @@ static int au1000_tx(struct sk_buff *, s static int au1000_rx(struct net_device *); static irqreturn_t au1000_interrupt(int, void *, struct pt_regs *); static void au1000_tx_timeout(struct net_device *); -static int au1000_set_config(struct net_device *dev, struct ifmap *map); static void set_rx_mode(struct net_device *); static struct net_device_stats *au1000_get_stats(struct net_device *); -static void au1000_timer(unsigned long); static int au1000_ioctl(struct net_device *, struct ifreq *, int); static int mdio_read(struct net_device *, int, int); static void mdio_write(struct net_device *, int, int, u16); -static void dump_mii(struct net_device *dev, int phy_id); +static void au1000_adjust_link(struct net_device *); +static void enable_mac(struct net_device *, int); // externs -extern void ack_rise_edge_irq(unsigned int); extern int get_ethernet_addr(char *ethernet_addr); extern void str2eaddr(unsigned char *ea, unsigned char *str); extern char * __init prom_getcmdline(void); @@ -126,705 +128,83 @@ static unsigned char au1000_mac_addr[6] 0x00, 0x50, 0xc2, 0x0c, 0x30, 0x00 }; -#define nibswap(x) ((((x) >> 4) & 0x0f) | (((x) << 4) & 0xf0)) -#define RUN_AT(x) (jiffies + (x)) - -// For reading/writing 32-bit words from/to DMA memory -#define cpu_to_dma32 cpu_to_be32 -#define dma32_to_cpu be32_to_cpu - struct au1000_private *au_macs[NUM_ETH_INTERFACES]; -/* FIXME - * All of the PHY code really should be detached from the MAC - * code. +/* + * board-specific configurations + * + * PHY detection algorithm + * + * If AU1XXX_PHY_STATIC_CONFIG is undefined, the PHY setup is + * autodetected: + * + * mii_probe() first searches the current MAC's MII bus for a PHY, + * selecting the first (or last, if AU1XXX_PHY_SEARCH_HIGHEST_ADDR is + * defined) PHY address not already claimed by another netdev. + * + * If nothing was found that way when searching for the 2nd ethernet + * controller's PHY and AU1XXX_PHY1_SEARCH_ON_MAC0 is defined, then + * the first MII bus is searched as well for an unclaimed PHY; this is + * needed in case of a dual-PHY accessible only through the MAC0's MII + * bus. + * + * Finally, if no PHY is found, then the corresponding ethernet + * controller is not registered to the network subsystem. */ -/* Default advertise */ -#define GENMII_DEFAULT_ADVERTISE \ - ADVERTISED_10baseT_Half | ADVERTISED_10baseT_Full | \ - ADVERTISED_100baseT_Half | ADVERTISED_100baseT_Full | \ - ADVERTISED_Autoneg - -#define GENMII_DEFAULT_FEATURES \ - SUPPORTED_10baseT_Half | SUPPORTED_10baseT_Full | \ - SUPPORTED_100baseT_Half | SUPPORTED_100baseT_Full | \ - SUPPORTED_Autoneg - -int bcm_5201_init(struct net_device *dev, int phy_addr) -{ - s16 data; - - /* Stop auto-negotiation */ - data = mdio_read(dev, phy_addr, MII_CONTROL); - mdio_write(dev, phy_addr, MII_CONTROL, data & ~MII_CNTL_AUTO); - - /* Set advertisement to 10/100 and Half/Full duplex - * (full capabilities) */ - data = mdio_read(dev, phy_addr, MII_ANADV); - data |= MII_NWAY_TX | MII_NWAY_TX_FDX | MII_NWAY_T_FDX | MII_NWAY_T; - mdio_write(dev, phy_addr, MII_ANADV, data); - - /* Restart auto-negotiation */ - data = mdio_read(dev, phy_addr, MII_CONTROL); - data |= MII_CNTL_RST_AUTO | MII_CNTL_AUTO; - mdio_write(dev, phy_addr, MII_CONTROL, data); - - if (au1000_debug > 4) - dump_mii(dev, phy_addr); - return 0; -} - -int bcm_5201_reset(struct net_device *dev, int phy_addr) -{ - s16 mii_control, timeout; - - mii_control = mdio_read(dev, phy_addr, MII_CONTROL); - mdio_write(dev, phy_addr, MII_CONTROL, mii_control | MII_CNTL_RESET); - mdelay(1); - for (timeout = 100; timeout > 0; --timeout) { - mii_control = mdio_read(dev, phy_addr, MII_CONTROL); - if ((mii_control & MII_CNTL_RESET) == 0) - break; - mdelay(1); - } - if (mii_control & MII_CNTL_RESET) { - printk(KERN_ERR "%s PHY reset timeout !\n", dev->name); - return -1; - } - return 0; -} - -int -bcm_5201_status(struct net_device *dev, int phy_addr, u16 *link, u16 *speed) -{ - u16 mii_data; - struct au1000_private *aup; - - if (!dev) { - printk(KERN_ERR "bcm_5201_status error: NULL dev\n"); - return -1; - } - aup = (struct au1000_private *) dev->priv; - - mii_data = mdio_read(dev, aup->phy_addr, MII_STATUS); - if (mii_data & MII_STAT_LINK) { - *link = 1; - mii_data = mdio_read(dev, aup->phy_addr, MII_AUX_CNTRL); - if (mii_data & MII_AUX_100) { - if (mii_data & MII_AUX_FDX) { - *speed = IF_PORT_100BASEFX; - dev->if_port = IF_PORT_100BASEFX; - } - else { - *speed = IF_PORT_100BASETX; - dev->if_port = IF_PORT_100BASETX; - } - } - else { - *speed = IF_PORT_10BASET; - dev->if_port = IF_PORT_10BASET; - } - - } - else { - *link = 0; - *speed = 0; - dev->if_port = IF_PORT_UNKNOWN; - } - return 0; -} - -int lsi_80227_init(struct net_device *dev, int phy_addr) -{ - if (au1000_debug > 4) - printk("lsi_80227_init\n"); - - /* restart auto-negotiation */ - mdio_write(dev, phy_addr, MII_CONTROL, - MII_CNTL_F100 | MII_CNTL_AUTO | MII_CNTL_RST_AUTO); // | MII_CNTL_FDX); - mdelay(1); - - /* set up LEDs to correct display */ -#ifdef CONFIG_MIPS_MTX1 - mdio_write(dev, phy_addr, 17, 0xff80); -#else - mdio_write(dev, phy_addr, 17, 0xffc0); -#endif - - if (au1000_debug > 4) - dump_mii(dev, phy_addr); - return 0; -} - -int lsi_80227_reset(struct net_device *dev, int phy_addr) -{ - s16 mii_control, timeout; - - if (au1000_debug > 4) { - printk("lsi_80227_reset\n"); - dump_mii(dev, phy_addr); - } - - mii_control = mdio_read(dev, phy_addr, MII_CONTROL); - mdio_write(dev, phy_addr, MII_CONTROL, mii_control | MII_CNTL_RESET); - mdelay(1); - for (timeout = 100; timeout > 0; --timeout) { - mii_control = mdio_read(dev, phy_addr, MII_CONTROL); - if ((mii_control & MII_CNTL_RESET) == 0) - break; - mdelay(1); - } - if (mii_control & MII_CNTL_RESET) { - printk(KERN_ERR "%s PHY reset timeout !\n", dev->name); - return -1; - } - return 0; -} - -int -lsi_80227_status(struct net_device *dev, int phy_addr, u16 *link, u16 *speed) -{ - u16 mii_data; - struct au1000_private *aup; - - if (!dev) { - printk(KERN_ERR "lsi_80227_status error: NULL dev\n"); - return -1; - } - aup = (struct au1000_private *) dev->priv; - - mii_data = mdio_read(dev, aup->phy_addr, MII_STATUS); - if (mii_data & MII_STAT_LINK) { - *link = 1; - mii_data = mdio_read(dev, aup->phy_addr, MII_LSI_PHY_STAT); - if (mii_data & MII_LSI_PHY_STAT_SPD) { - if (mii_data & MII_LSI_PHY_STAT_FDX) { - *speed = IF_PORT_100BASEFX; - dev->if_port = IF_PORT_100BASEFX; - } - else { - *speed = IF_PORT_100BASETX; - dev->if_port = IF_PORT_100BASETX; - } - } - else { - *speed = IF_PORT_10BASET; - dev->if_port = IF_PORT_10BASET; - } - - } - else { - *link = 0; - *speed = 0; - dev->if_port = IF_PORT_UNKNOWN; - } - return 0; -} - -int am79c901_init(struct net_device *dev, int phy_addr) -{ - printk("am79c901_init\n"); - return 0; -} - -int am79c901_reset(struct net_device *dev, int phy_addr) -{ - printk("am79c901_reset\n"); - return 0; -} - -int -am79c901_status(struct net_device *dev, int phy_addr, u16 *link, u16 *speed) -{ - return 0; -} - -int am79c874_init(struct net_device *dev, int phy_addr) -{ - s16 data; - - /* 79c874 has quit resembled bit assignments to BCM5201 */ - if (au1000_debug > 4) - printk("am79c847_init\n"); - - /* Stop auto-negotiation */ - data = mdio_read(dev, phy_addr, MII_CONTROL); - mdio_write(dev, phy_addr, MII_CONTROL, data & ~MII_CNTL_AUTO); - - /* Set advertisement to 10/100 and Half/Full duplex - * (full capabilities) */ - data = mdio_read(dev, phy_addr, MII_ANADV); - data |= MII_NWAY_TX | MII_NWAY_TX_FDX | MII_NWAY_T_FDX | MII_NWAY_T; - mdio_write(dev, phy_addr, MII_ANADV, data); - - /* Restart auto-negotiation */ - data = mdio_read(dev, phy_addr, MII_CONTROL); - data |= MII_CNTL_RST_AUTO | MII_CNTL_AUTO; - - mdio_write(dev, phy_addr, MII_CONTROL, data); - - if (au1000_debug > 4) dump_mii(dev, phy_addr); - return 0; -} - -int am79c874_reset(struct net_device *dev, int phy_addr) -{ - s16 mii_control, timeout; - - if (au1000_debug > 4) - printk("am79c874_reset\n"); - - mii_control = mdio_read(dev, phy_addr, MII_CONTROL); - mdio_write(dev, phy_addr, MII_CONTROL, mii_control | MII_CNTL_RESET); - mdelay(1); - for (timeout = 100; timeout > 0; --timeout) { - mii_control = mdio_read(dev, phy_addr, MII_CONTROL); - if ((mii_control & MII_CNTL_RESET) == 0) - break; - mdelay(1); - } - if (mii_control & MII_CNTL_RESET) { - printk(KERN_ERR "%s PHY reset timeout !\n", dev->name); - return -1; - } - return 0; -} - -int -am79c874_status(struct net_device *dev, int phy_addr, u16 *link, u16 *speed) -{ - u16 mii_data; - struct au1000_private *aup; - - // printk("am79c874_status\n"); - if (!dev) { - printk(KERN_ERR "am79c874_status error: NULL dev\n"); - return -1; - } - - aup = (struct au1000_private *) dev->priv; - mii_data = mdio_read(dev, aup->phy_addr, MII_STATUS); +/* autodetection defaults */ +#undef AU1XXX_PHY_SEARCH_HIGHEST_ADDR +#define AU1XXX_PHY1_SEARCH_ON_MAC0 - if (mii_data & MII_STAT_LINK) { - *link = 1; - mii_data = mdio_read(dev, aup->phy_addr, MII_AMD_PHY_STAT); - if (mii_data & MII_AMD_PHY_STAT_SPD) { - if (mii_data & MII_AMD_PHY_STAT_FDX) { - *speed = IF_PORT_100BASEFX; - dev->if_port = IF_PORT_100BASEFX; - } - else { - *speed = IF_PORT_100BASETX; - dev->if_port = IF_PORT_100BASETX; - } - } - else { - *speed = IF_PORT_10BASET; - dev->if_port = IF_PORT_10BASET; - } - - } - else { - *link = 0; - *speed = 0; - dev->if_port = IF_PORT_UNKNOWN; - } - return 0; -} - -int lxt971a_init(struct net_device *dev, int phy_addr) -{ - if (au1000_debug > 4) - printk("lxt971a_init\n"); - - /* restart auto-negotiation */ - mdio_write(dev, phy_addr, MII_CONTROL, - MII_CNTL_F100 | MII_CNTL_AUTO | MII_CNTL_RST_AUTO | MII_CNTL_FDX); - - /* set up LEDs to correct display */ - mdio_write(dev, phy_addr, 20, 0x0422); - - if (au1000_debug > 4) - dump_mii(dev, phy_addr); - return 0; -} - -int lxt971a_reset(struct net_device *dev, int phy_addr) -{ - s16 mii_control, timeout; - - if (au1000_debug > 4) { - printk("lxt971a_reset\n"); - dump_mii(dev, phy_addr); - } - - mii_control = mdio_read(dev, phy_addr, MII_CONTROL); - mdio_write(dev, phy_addr, MII_CONTROL, mii_control | MII_CNTL_RESET); - mdelay(1); - for (timeout = 100; timeout > 0; --timeout) { - mii_control = mdio_read(dev, phy_addr, MII_CONTROL); - if ((mii_control & MII_CNTL_RESET) == 0) - break; - mdelay(1); - } - if (mii_control & MII_CNTL_RESET) { - printk(KERN_ERR "%s PHY reset timeout !\n", dev->name); - return -1; - } - return 0; -} - -int -lxt971a_status(struct net_device *dev, int phy_addr, u16 *link, u16 *speed) -{ - u16 mii_data; - struct au1000_private *aup; - - if (!dev) { - printk(KERN_ERR "lxt971a_status error: NULL dev\n"); - return -1; - } - aup = (struct au1000_private *) dev->priv; - - mii_data = mdio_read(dev, aup->phy_addr, MII_STATUS); - if (mii_data & MII_STAT_LINK) { - *link = 1; - mii_data = mdio_read(dev, aup->phy_addr, MII_INTEL_PHY_STAT); - if (mii_data & MII_INTEL_PHY_STAT_SPD) { - if (mii_data & MII_INTEL_PHY_STAT_FDX) { - *speed = IF_PORT_100BASEFX; - dev->if_port = IF_PORT_100BASEFX; - } - else { - *speed = IF_PORT_100BASETX; - dev->if_port = IF_PORT_100BASETX; - } - } - else { - *speed = IF_PORT_10BASET; - dev->if_port = IF_PORT_10BASET; - } - - } - else { - *link = 0; - *speed = 0; - dev->if_port = IF_PORT_UNKNOWN; - } - return 0; -} - -int ks8995m_init(struct net_device *dev, int phy_addr) -{ - s16 data; - -// printk("ks8995m_init\n"); - /* Stop auto-negotiation */ - data = mdio_read(dev, phy_addr, MII_CONTROL); - mdio_write(dev, phy_addr, MII_CONTROL, data & ~MII_CNTL_AUTO); - - /* Set advertisement to 10/100 and Half/Full duplex - * (full capabilities) */ - data = mdio_read(dev, phy_addr, MII_ANADV); - data |= MII_NWAY_TX | MII_NWAY_TX_FDX | MII_NWAY_T_FDX | MII_NWAY_T; - mdio_write(dev, phy_addr, MII_ANADV, data); - - /* Restart auto-negotiation */ - data = mdio_read(dev, phy_addr, MII_CONTROL); - data |= MII_CNTL_RST_AUTO | MII_CNTL_AUTO; - mdio_write(dev, phy_addr, MII_CONTROL, data); - - if (au1000_debug > 4) dump_mii(dev, phy_addr); - - return 0; -} - -int ks8995m_reset(struct net_device *dev, int phy_addr) -{ - s16 mii_control, timeout; - -// printk("ks8995m_reset\n"); - mii_control = mdio_read(dev, phy_addr, MII_CONTROL); - mdio_write(dev, phy_addr, MII_CONTROL, mii_control | MII_CNTL_RESET); - mdelay(1); - for (timeout = 100; timeout > 0; --timeout) { - mii_control = mdio_read(dev, phy_addr, MII_CONTROL); - if ((mii_control & MII_CNTL_RESET) == 0) - break; - mdelay(1); - } - if (mii_control & MII_CNTL_RESET) { - printk(KERN_ERR "%s PHY reset timeout !\n", dev->name); - return -1; - } - return 0; -} - -int ks8995m_status(struct net_device *dev, int phy_addr, u16 *link, u16 *speed) -{ - u16 mii_data; - struct au1000_private *aup; - - if (!dev) { - printk(KERN_ERR "ks8995m_status error: NULL dev\n"); - return -1; - } - aup = (struct au1000_private *) dev->priv; - - mii_data = mdio_read(dev, aup->phy_addr, MII_STATUS); - if (mii_data & MII_STAT_LINK) { - *link = 1; - mii_data = mdio_read(dev, aup->phy_addr, MII_AUX_CNTRL); - if (mii_data & MII_AUX_100) { - if (mii_data & MII_AUX_FDX) { - *speed = IF_PORT_100BASEFX; - dev->if_port = IF_PORT_100BASEFX; - } - else { - *speed = IF_PORT_100BASETX; - dev->if_port = IF_PORT_100BASETX; - } - } - else { - *speed = IF_PORT_10BASET; - dev->if_port = IF_PORT_10BASET; - } - - } - else { - *link = 0; - *speed = 0; - dev->if_port = IF_PORT_UNKNOWN; - } - return 0; -} - -int -smsc_83C185_init (struct net_device *dev, int phy_addr) -{ - s16 data; - - if (au1000_debug > 4) - printk("smsc_83C185_init\n"); - - /* Stop auto-negotiation */ - data = mdio_read(dev, phy_addr, MII_CONTROL); - mdio_write(dev, phy_addr, MII_CONTROL, data & ~MII_CNTL_AUTO); - - /* Set advertisement to 10/100 and Half/Full duplex - * (full capabilities) */ - data = mdio_read(dev, phy_addr, MII_ANADV); - data |= MII_NWAY_TX | MII_NWAY_TX_FDX | MII_NWAY_T_FDX | MII_NWAY_T; - mdio_write(dev, phy_addr, MII_ANADV, data); - - /* Restart auto-negotiation */ - data = mdio_read(dev, phy_addr, MII_CONTROL); - data |= MII_CNTL_RST_AUTO | MII_CNTL_AUTO; - - mdio_write(dev, phy_addr, MII_CONTROL, data); - - if (au1000_debug > 4) dump_mii(dev, phy_addr); - return 0; -} - -int -smsc_83C185_reset (struct net_device *dev, int phy_addr) -{ - s16 mii_control, timeout; - - if (au1000_debug > 4) - printk("smsc_83C185_reset\n"); - - mii_control = mdio_read(dev, phy_addr, MII_CONTROL); - mdio_write(dev, phy_addr, MII_CONTROL, mii_control | MII_CNTL_RESET); - mdelay(1); - for (timeout = 100; timeout > 0; --timeout) { - mii_control = mdio_read(dev, phy_addr, MII_CONTROL); - if ((mii_control & MII_CNTL_RESET) == 0) - break; - mdelay(1); - } - if (mii_control & MII_CNTL_RESET) { - printk(KERN_ERR "%s PHY reset timeout !\n", dev->name); - return -1; - } - return 0; -} - -int -smsc_83C185_status (struct net_device *dev, int phy_addr, u16 *link, u16 *speed) -{ - u16 mii_data; - struct au1000_private *aup; - - if (!dev) { - printk(KERN_ERR "smsc_83C185_status error: NULL dev\n"); - return -1; - } - - aup = (struct au1000_private *) dev->priv; - mii_data = mdio_read(dev, aup->phy_addr, MII_STATUS); - - if (mii_data & MII_STAT_LINK) { - *link = 1; - mii_data = mdio_read(dev, aup->phy_addr, 0x1f); - if (mii_data & (1<<3)) { - if (mii_data & (1<<4)) { - *speed = IF_PORT_100BASEFX; - dev->if_port = IF_PORT_100BASEFX; - } - else { - *speed = IF_PORT_100BASETX; - dev->if_port = IF_PORT_100BASETX; - } - } - else { - *speed = IF_PORT_10BASET; - dev->if_port = IF_PORT_10BASET; - } - } - else { - *link = 0; - *speed = 0; - dev->if_port = IF_PORT_UNKNOWN; - } - return 0; -} - - -#ifdef CONFIG_MIPS_BOSPORUS -int stub_init(struct net_device *dev, int phy_addr) -{ - //printk("PHY stub_init\n"); - return 0; -} - -int stub_reset(struct net_device *dev, int phy_addr) -{ - //printk("PHY stub_reset\n"); - return 0; -} - -int -stub_status(struct net_device *dev, int phy_addr, u16 *link, u16 *speed) -{ - //printk("PHY stub_status\n"); - *link = 1; - /* hmmm, revisit */ - *speed = IF_PORT_100BASEFX; - dev->if_port = IF_PORT_100BASEFX; - return 0; -} -#endif - -struct phy_ops bcm_5201_ops = { - bcm_5201_init, - bcm_5201_reset, - bcm_5201_status, -}; - -struct phy_ops am79c874_ops = { - am79c874_init, - am79c874_reset, - am79c874_status, -}; - -struct phy_ops am79c901_ops = { - am79c901_init, - am79c901_reset, - am79c901_status, -}; - -struct phy_ops lsi_80227_ops = { - lsi_80227_init, - lsi_80227_reset, - lsi_80227_status, -}; - -struct phy_ops lxt971a_ops = { - lxt971a_init, - lxt971a_reset, - lxt971a_status, -}; +/* static PHY setup + * + * most boards PHY setup should be detectable properly with the + * autodetection algorithm in mii_probe(), but in some cases (e.g. if + * you have a switch attached, or want to use the PHY's interrupt + * notification capabilities) you can provide a static PHY + * configuration here + * + * IRQs may only be set, if a PHY address was configured + * If a PHY address is given, also a bus id is required to be set + * + * ps: make sure the used irqs are configured properly in the board + * specific irq-map + */ -struct phy_ops ks8995m_ops = { - ks8995m_init, - ks8995m_reset, - ks8995m_status, -}; +#if defined(CONFIG_MIPS_BOSPORUS) +/* + * Micrel/Kendin 5 port switch attached to MAC0, + * MAC0 is associated with PHY address 5 (== WAN port) + * MAC1 is not associated with any PHY, since it's connected directly + * to the switch. + * no interrupts are used + */ +# define AU1XXX_PHY_STATIC_CONFIG -struct phy_ops smsc_83C185_ops = { - smsc_83C185_init, - smsc_83C185_reset, - smsc_83C185_status, -}; +# define AU1XXX_PHY0_ADDR 5 +# define AU1XXX_PHY0_BUSID 0 +# undef AU1XXX_PHY0_IRQ -#ifdef CONFIG_MIPS_BOSPORUS -struct phy_ops stub_ops = { - stub_init, - stub_reset, - stub_status, -}; +# undef AU1XXX_PHY1_ADDR +# undef AU1XXX_PHY1_BUSID +# undef AU1XXX_PHY1_IRQ #endif -static struct mii_chip_info { - const char * name; - u16 phy_id0; - u16 phy_id1; - struct phy_ops *phy_ops; - int dual_phy; -} mii_chip_table[] = { - {"Broadcom BCM5201 10/100 BaseT PHY",0x0040,0x6212, &bcm_5201_ops,0}, - {"Broadcom BCM5221 10/100 BaseT PHY",0x0040,0x61e4, &bcm_5201_ops,0}, - {"Broadcom BCM5222 10/100 BaseT PHY",0x0040,0x6322, &bcm_5201_ops,1}, - {"NS DP83847 PHY", 0x2000, 0x5c30, &bcm_5201_ops ,0}, - {"AMD 79C901 HomePNA PHY",0x0000,0x35c8, &am79c901_ops,0}, - {"AMD 79C874 10/100 BaseT PHY",0x0022,0x561b, &am79c874_ops,0}, - {"LSI 80227 10/100 BaseT PHY",0x0016,0xf840, &lsi_80227_ops,0}, - {"Intel LXT971A Dual Speed PHY",0x0013,0x78e2, &lxt971a_ops,0}, - {"Kendin KS8995M 10/100 BaseT PHY",0x0022,0x1450, &ks8995m_ops,0}, - {"SMSC LAN83C185 10/100 BaseT PHY",0x0007,0xc0a3, &smsc_83C185_ops,0}, -#ifdef CONFIG_MIPS_BOSPORUS - {"Stub", 0x1234, 0x5678, &stub_ops }, +#if defined(AU1XXX_PHY0_BUSID) && (AU1XXX_PHY0_BUSID > 0) +# error MAC0-associated PHY attached 2nd MACs MII bus not supported yet #endif - {0,}, -}; -static int mdio_read(struct net_device *dev, int phy_id, int reg) +/* + * MII operations + */ +static int mdio_read(struct net_device *dev, int phy_addr, int reg) { struct au1000_private *aup = (struct au1000_private *) dev->priv; - volatile u32 *mii_control_reg; - volatile u32 *mii_data_reg; + volatile u32 *const mii_control_reg = &aup->mac->mii_control; + volatile u32 *const mii_data_reg = &aup->mac->mii_data; u32 timedout = 20; u32 mii_control; - #ifdef CONFIG_BCM5222_DUAL_PHY - /* First time we probe, it's for the mac0 phy. - * Since we haven't determined yet that we have a dual phy, - * aup->mii->mii_control_reg won't be setup and we'll - * default to the else statement. - * By the time we probe for the mac1 phy, the mii_control_reg - * will be setup to be the address of the mac0 phy control since - * both phys are controlled through mac0. - */ - if (aup->mii && aup->mii->mii_control_reg) { - mii_control_reg = aup->mii->mii_control_reg; - mii_data_reg = aup->mii->mii_data_reg; - } - else if (au_macs[0]->mii && au_macs[0]->mii->mii_control_reg) { - /* assume both phys are controlled through mac0 */ - mii_control_reg = au_macs[0]->mii->mii_control_reg; - mii_data_reg = au_macs[0]->mii->mii_data_reg; - } - else - #endif - { - /* default control and data reg addresses */ - mii_control_reg = &aup->mac->mii_control; - mii_data_reg = &aup->mac->mii_data; - } - while (*mii_control_reg & MAC_MII_BUSY) { mdelay(1); if (--timedout == 0) { @@ -835,7 +215,7 @@ static int mdio_read(struct net_device * } mii_control = MAC_SET_MII_SELECT_REG(reg) | - MAC_SET_MII_SELECT_PHY(phy_id) | MAC_MII_READ; + MAC_SET_MII_SELECT_PHY(phy_addr) | MAC_MII_READ; *mii_control_reg = mii_control; @@ -851,32 +231,14 @@ static int mdio_read(struct net_device * return (int)*mii_data_reg; } -static void mdio_write(struct net_device *dev, int phy_id, int reg, u16 value) +static void mdio_write(struct net_device *dev, int phy_addr, int reg, u16 value) { struct au1000_private *aup = (struct au1000_private *) dev->priv; - volatile u32 *mii_control_reg; - volatile u32 *mii_data_reg; + volatile u32 *const mii_control_reg = &aup->mac->mii_control; + volatile u32 *const mii_data_reg = &aup->mac->mii_data; u32 timedout = 20; u32 mii_control; - #ifdef CONFIG_BCM5222_DUAL_PHY - if (aup->mii && aup->mii->mii_control_reg) { - mii_control_reg = aup->mii->mii_control_reg; - mii_data_reg = aup->mii->mii_data_reg; - } - else if (au_macs[0]->mii && au_macs[0]->mii->mii_control_reg) { - /* assume both phys are controlled through mac0 */ - mii_control_reg = au_macs[0]->mii->mii_control_reg; - mii_data_reg = au_macs[0]->mii->mii_data_reg; - } - else - #endif - { - /* default control and data reg addresses */ - mii_control_reg = &aup->mac->mii_control; - mii_data_reg = &aup->mac->mii_data; - } - while (*mii_control_reg & MAC_MII_BUSY) { mdelay(1); if (--timedout == 0) { @@ -887,165 +249,145 @@ static void mdio_write(struct net_device } mii_control = MAC_SET_MII_SELECT_REG(reg) | - MAC_SET_MII_SELECT_PHY(phy_id) | MAC_MII_WRITE; + MAC_SET_MII_SELECT_PHY(phy_addr) | MAC_MII_WRITE; *mii_data_reg = value; *mii_control_reg = mii_control; } +static int mdiobus_read(struct mii_bus *bus, int phy_addr, int regnum) +{ + /* WARNING: bus->phy_map[phy_addr].attached_dev == dev does + * _NOT_ hold (e.g. when PHY is accessed through other MAC's MII bus) */ + struct net_device *const dev = bus->priv; + + enable_mac(dev, 0); /* make sure the MAC associated with this + * mii_bus is enabled */ + return mdio_read(dev, phy_addr, regnum); +} -static void dump_mii(struct net_device *dev, int phy_id) +static int mdiobus_write(struct mii_bus *bus, int phy_addr, int regnum, + u16 value) { - int i, val; + struct net_device *const dev = bus->priv; - for (i = 0; i < 7; i++) { - if ((val = mdio_read(dev, phy_id, i)) >= 0) - printk("%s: MII Reg %d=%x\n", dev->name, i, val); - } - for (i = 16; i < 25; i++) { - if ((val = mdio_read(dev, phy_id, i)) >= 0) - printk("%s: MII Reg %d=%x\n", dev->name, i, val); - } + enable_mac(dev, 0); /* make sure the MAC associated with this + * mii_bus is enabled */ + mdio_write(dev, phy_addr, regnum, value); + return 0; } -static int mii_probe (struct net_device * dev) +static int mdiobus_reset(struct mii_bus *bus) { - struct au1000_private *aup = (struct au1000_private *) dev->priv; - int phy_addr; -#ifdef CONFIG_MIPS_BOSPORUS - int phy_found=0; -#endif + struct net_device *const dev = bus->priv; - /* search for total of 32 possible mii phy addresses */ - for (phy_addr = 0; phy_addr < 32; phy_addr++) { - u16 mii_status; - u16 phy_id0, phy_id1; - int i; + enable_mac(dev, 0); /* make sure the MAC associated with this + * mii_bus is enabled */ + return 0; +} - #ifdef CONFIG_BCM5222_DUAL_PHY - /* Mask the already found phy, try next one */ - if (au_macs[0]->mii && au_macs[0]->mii->mii_control_reg) { - if (au_macs[0]->phy_addr == phy_addr) - continue; - } - #endif - - mii_status = mdio_read(dev, phy_addr, MII_STATUS); - if (mii_status == 0xffff || mii_status == 0x0000) - /* the mii is not accessable, try next one */ - continue; - - phy_id0 = mdio_read(dev, phy_addr, MII_PHY_ID0); - phy_id1 = mdio_read(dev, phy_addr, MII_PHY_ID1); - - /* search our mii table for the current mii */ - for (i = 0; mii_chip_table[i].phy_id1; i++) { - if (phy_id0 == mii_chip_table[i].phy_id0 && - phy_id1 == mii_chip_table[i].phy_id1) { - struct mii_phy * mii_phy = aup->mii; - - printk(KERN_INFO "%s: %s at phy address %d\n", - dev->name, mii_chip_table[i].name, - phy_addr); -#ifdef CONFIG_MIPS_BOSPORUS - phy_found = 1; -#endif - mii_phy->chip_info = mii_chip_table+i; - aup->phy_addr = phy_addr; - aup->want_autoneg = 1; - aup->phy_ops = mii_chip_table[i].phy_ops; - aup->phy_ops->phy_init(dev,phy_addr); - - // Check for dual-phy and then store required - // values and set indicators. We need to do - // this now since mdio_{read,write} need the - // control and data register addresses. - #ifdef CONFIG_BCM5222_DUAL_PHY - if ( mii_chip_table[i].dual_phy) { - - /* assume both phys are controlled - * through MAC0. Board specific? */ - - /* sanity check */ - if (!au_macs[0] || !au_macs[0]->mii) - return -1; - aup->mii->mii_control_reg = (u32 *) - &au_macs[0]->mac->mii_control; - aup->mii->mii_data_reg = (u32 *) - &au_macs[0]->mac->mii_data; - } - #endif - goto found; - } +static int mii_probe (struct net_device *dev) +{ + struct au1000_private *const aup = (struct au1000_private *) dev->priv; + struct phy_device *phydev = NULL; + +#if defined(AU1XXX_PHY_STATIC_CONFIG) + BUG_ON(aup->mac_id < 0 || aup->mac_id > 1); + + if(aup->mac_id == 0) { /* get PHY0 */ +# if defined(AU1XXX_PHY0_ADDR) + phydev = au_macs[AU1XXX_PHY0_BUSID]->mii_bus.phy_map[AU1XXX_PHY0_ADDR]; +# else + printk (KERN_INFO DRV_NAME ":%s: using PHY-less setup\n", + dev->name); + return 0; +# endif /* defined(AU1XXX_PHY0_ADDR) */ + } else if (aup->mac_id == 1) { /* get PHY1 */ +# if defined(AU1XXX_PHY1_ADDR) + phydev = au_macs[AU1XXX_PHY1_BUSID]->mii_bus.phy_map[AU1XXX_PHY1_ADDR]; +# else + printk (KERN_INFO DRV_NAME ":%s: using PHY-less setup\n", + dev->name); + return 0; +# endif /* defined(AU1XXX_PHY1_ADDR) */ + } + +#else /* defined(AU1XXX_PHY_STATIC_CONFIG) */ + int phy_addr; + + /* find the first (lowest address) PHY on the current MAC's MII bus */ + for (phy_addr = 0; phy_addr < PHY_MAX_ADDR; phy_addr++) + if (aup->mii_bus.phy_map[phy_addr]) { + phydev = aup->mii_bus.phy_map[phy_addr]; +# if !defined(AU1XXX_PHY_SEARCH_HIGHEST_ADDR) + break; /* break out with first one found */ +# endif } - } -found: - -#ifdef CONFIG_MIPS_BOSPORUS - /* This is a workaround for the Micrel/Kendin 5 port switch - The second MAC doesn't see a PHY connected... so we need to - trick it into thinking we have one. - - If this kernel is run on another Au1500 development board - the stub will be found as well as the actual PHY. However, - the last found PHY will be used... usually at Addr 31 (Db1500). - */ - if ( (!phy_found) ) - { - u16 phy_id0, phy_id1; - int i; - phy_id0 = 0x1234; - phy_id1 = 0x5678; - - /* search our mii table for the current mii */ - for (i = 0; mii_chip_table[i].phy_id1; i++) { - if (phy_id0 == mii_chip_table[i].phy_id0 && - phy_id1 == mii_chip_table[i].phy_id1) { - struct mii_phy * mii_phy; - - printk(KERN_INFO "%s: %s at phy address %d\n", - dev->name, mii_chip_table[i].name, - phy_addr); - mii_phy = kmalloc(sizeof(struct mii_phy), - GFP_KERNEL); - if (mii_phy) { - mii_phy->chip_info = mii_chip_table+i; - aup->phy_addr = phy_addr; - mii_phy->next = aup->mii; - aup->phy_ops = - mii_chip_table[i].phy_ops; - aup->mii = mii_phy; - aup->phy_ops->phy_init(dev,phy_addr); - } else { - printk(KERN_ERR "%s: out of memory\n", - dev->name); - return -1; - } - mii_phy->chip_info = mii_chip_table+i; - aup->phy_addr = phy_addr; - aup->phy_ops = mii_chip_table[i].phy_ops; - aup->phy_ops->phy_init(dev,phy_addr); - break; - } +# if defined(AU1XXX_PHY1_SEARCH_ON_MAC0) + /* try harder to find a PHY */ + if (!phydev && (aup->mac_id == 1)) { + /* no PHY found, maybe we have a dual PHY? */ + printk (KERN_INFO DRV_NAME ": no PHY found on MAC1, " + "let's see if it's attached to MAC0...\n"); + + BUG_ON(!au_macs[0]); + + /* find the first (lowest address) non-attached PHY on + * the MAC0 MII bus */ + for (phy_addr = 0; phy_addr < PHY_MAX_ADDR; phy_addr++) { + struct phy_device *const tmp_phydev = + au_macs[0]->mii_bus.phy_map[phy_addr]; + + if (!tmp_phydev) + continue; /* no PHY here... */ + + if (tmp_phydev->attached_dev) + continue; /* already claimed by MAC0 */ + + phydev = tmp_phydev; + break; /* found it */ } } - if (aup->mac_id == 0) { - /* the Bosporus phy responds to addresses 0-5 but - * 5 is the correct one. - */ - aup->phy_addr = 5; - } -#endif +# endif /* defined(AU1XXX_PHY1_SEARCH_OTHER_BUS) */ - if (aup->mii->chip_info == NULL) { - printk(KERN_ERR "%s: Au1x No known MII transceivers found!\n", - dev->name); +#endif /* defined(AU1XXX_PHY_STATIC_CONFIG) */ + if (!phydev) { + printk (KERN_ERR DRV_NAME ":%s: no PHY found\n", dev->name); return -1; } - printk(KERN_INFO "%s: Using %s as default\n", - dev->name, aup->mii->chip_info->name); + /* now we are supposed to have a proper phydev, to attach to... */ + BUG_ON(!phydev); + BUG_ON(phydev->attached_dev); + + phydev = phy_connect(dev, phydev->dev.bus_id, &au1000_adjust_link, 0); + + if (IS_ERR(phydev)) { + printk(KERN_ERR "%s: Could not attach to PHY\n", dev->name); + return PTR_ERR(phydev); + } + + /* mask with MAC supported features */ + phydev->supported &= (SUPPORTED_10baseT_Half + | SUPPORTED_10baseT_Full + | SUPPORTED_100baseT_Half + | SUPPORTED_100baseT_Full + | SUPPORTED_Autoneg + /* | SUPPORTED_Pause | SUPPORTED_Asym_Pause */ + | SUPPORTED_MII + | SUPPORTED_TP); + + phydev->advertising = phydev->supported; + + aup->old_link = 0; + aup->old_speed = 0; + aup->old_duplex = -1; + aup->phy_dev = phydev; + + printk(KERN_INFO "%s: attached PHY driver [%s] " + "(mii_bus:phy_addr=%s, irq=%d)\n", + dev->name, phydev->drv->name, phydev->dev.bus_id, phydev->irq); return 0; } @@ -1097,35 +439,38 @@ static void hard_stop(struct net_device au_sync_delay(10); } - -static void reset_mac(struct net_device *dev) +static void enable_mac(struct net_device *dev, int force_reset) { - int i; - u32 flags; + unsigned long flags; struct au1000_private *aup = (struct au1000_private *) dev->priv; - if (au1000_debug > 4) - printk(KERN_INFO "%s: reset mac, aup %x\n", - dev->name, (unsigned)aup); - spin_lock_irqsave(&aup->lock, flags); - if (aup->timer.function == &au1000_timer) {/* check if timer initted */ - del_timer(&aup->timer); - } - hard_stop(dev); - #ifdef CONFIG_BCM5222_DUAL_PHY - if (aup->mac_id != 0) { - #endif - /* If BCM5222, we can't leave MAC0 in reset because then - * we can't access the dual phy for ETH1 */ + if(force_reset || (!aup->mac_enabled)) { *aup->enable = MAC_EN_CLOCK_ENABLE; au_sync_delay(2); - *aup->enable = 0; + *aup->enable = (MAC_EN_RESET0 | MAC_EN_RESET1 | MAC_EN_RESET2 + | MAC_EN_CLOCK_ENABLE); au_sync_delay(2); - #ifdef CONFIG_BCM5222_DUAL_PHY + + aup->mac_enabled = 1; } - #endif + + spin_unlock_irqrestore(&aup->lock, flags); +} + +static void reset_mac_unlocked(struct net_device *dev) +{ + struct au1000_private *const aup = (struct au1000_private *) dev->priv; + int i; + + hard_stop(dev); + + *aup->enable = MAC_EN_CLOCK_ENABLE; + au_sync_delay(2); + *aup->enable = 0; + au_sync_delay(2); + aup->tx_full = 0; for (i = 0; i < NUM_RX_DMA; i++) { /* reset control bits */ @@ -1135,9 +480,26 @@ static void reset_mac(struct net_device /* reset control bits */ aup->tx_dma_ring[i]->buff_stat &= ~0xf; } - spin_unlock_irqrestore(&aup->lock, flags); + + aup->mac_enabled = 0; + } +static void reset_mac(struct net_device *dev) +{ + struct au1000_private *const aup = (struct au1000_private *) dev->priv; + unsigned long flags; + + if (au1000_debug > 4) + printk(KERN_INFO "%s: reset mac, aup %x\n", + dev->name, (unsigned)aup); + + spin_lock_irqsave(&aup->lock, flags); + + reset_mac_unlocked (dev); + + spin_unlock_irqrestore(&aup->lock, flags); +} /* * Setup the receive and transmit "rings". These pointers are the addresses @@ -1208,178 +570,31 @@ static int __init au1000_init_module(voi return 0; } -static int au1000_setup_aneg(struct net_device *dev, u32 advertise) -{ - struct au1000_private *aup = (struct au1000_private *)dev->priv; - u16 ctl, adv; - - /* Setup standard advertise */ - adv = mdio_read(dev, aup->phy_addr, MII_ADVERTISE); - adv &= ~(ADVERTISE_ALL | ADVERTISE_100BASE4); - if (advertise & ADVERTISED_10baseT_Half) - adv |= ADVERTISE_10HALF; - if (advertise & ADVERTISED_10baseT_Full) - adv |= ADVERTISE_10FULL; - if (advertise & ADVERTISED_100baseT_Half) - adv |= ADVERTISE_100HALF; - if (advertise & ADVERTISED_100baseT_Full) - adv |= ADVERTISE_100FULL; - mdio_write(dev, aup->phy_addr, MII_ADVERTISE, adv); - - /* Start/Restart aneg */ - ctl = mdio_read(dev, aup->phy_addr, MII_BMCR); - ctl |= (BMCR_ANENABLE | BMCR_ANRESTART); - mdio_write(dev, aup->phy_addr, MII_BMCR, ctl); - - return 0; -} +/* + * ethtool operations + */ -static int au1000_setup_forced(struct net_device *dev, int speed, int fd) +static int au1000_get_settings(struct net_device *dev, struct ethtool_cmd *cmd) { struct au1000_private *aup = (struct au1000_private *)dev->priv; - u16 ctl; - - ctl = mdio_read(dev, aup->phy_addr, MII_BMCR); - ctl &= ~(BMCR_FULLDPLX | BMCR_SPEED100 | BMCR_ANENABLE); - - /* First reset the PHY */ - mdio_write(dev, aup->phy_addr, MII_BMCR, ctl | BMCR_RESET); - - /* Select speed & duplex */ - switch (speed) { - case SPEED_10: - break; - case SPEED_100: - ctl |= BMCR_SPEED100; - break; - case SPEED_1000: - default: - return -EINVAL; - } - if (fd == DUPLEX_FULL) - ctl |= BMCR_FULLDPLX; - mdio_write(dev, aup->phy_addr, MII_BMCR, ctl); - - return 0; -} - -static void -au1000_start_link(struct net_device *dev, struct ethtool_cmd *cmd) -{ - struct au1000_private *aup = (struct au1000_private *)dev->priv; - u32 advertise; - int autoneg; - int forced_speed; - int forced_duplex; - - /* Default advertise */ - advertise = GENMII_DEFAULT_ADVERTISE; - autoneg = aup->want_autoneg; - forced_speed = SPEED_100; - forced_duplex = DUPLEX_FULL; - - /* Setup link parameters */ - if (cmd) { - if (cmd->autoneg == AUTONEG_ENABLE) { - advertise = cmd->advertising; - autoneg = 1; - } else { - autoneg = 0; - - forced_speed = cmd->speed; - forced_duplex = cmd->duplex; - } - } + if (aup->phy_dev) + return phy_ethtool_gset(aup->phy_dev, cmd); - /* Configure PHY & start aneg */ - aup->want_autoneg = autoneg; - if (autoneg) - au1000_setup_aneg(dev, advertise); - else - au1000_setup_forced(dev, forced_speed, forced_duplex); - mod_timer(&aup->timer, jiffies + HZ); + return -EINVAL; } -static int au1000_get_settings(struct net_device *dev, struct ethtool_cmd *cmd) +static int au1000_set_settings(struct net_device *dev, struct ethtool_cmd *cmd) { struct au1000_private *aup = (struct au1000_private *)dev->priv; - u16 link, speed; - - cmd->supported = GENMII_DEFAULT_FEATURES; - cmd->advertising = GENMII_DEFAULT_ADVERTISE; - cmd->port = PORT_MII; - cmd->transceiver = XCVR_EXTERNAL; - cmd->phy_address = aup->phy_addr; - spin_lock_irq(&aup->lock); - cmd->autoneg = aup->want_autoneg; - aup->phy_ops->phy_status(dev, aup->phy_addr, &link, &speed); - if ((speed == IF_PORT_100BASETX) || (speed == IF_PORT_100BASEFX)) - cmd->speed = SPEED_100; - else if (speed == IF_PORT_10BASET) - cmd->speed = SPEED_10; - if (link && (dev->if_port == IF_PORT_100BASEFX)) - cmd->duplex = DUPLEX_FULL; - else - cmd->duplex = DUPLEX_HALF; - spin_unlock_irq(&aup->lock); - return 0; -} -static int au1000_set_settings(struct net_device *dev, struct ethtool_cmd *cmd) -{ - struct au1000_private *aup = (struct au1000_private *)dev->priv; - unsigned long features = GENMII_DEFAULT_FEATURES; - - if (!capable(CAP_NET_ADMIN)) - return -EPERM; - - if (cmd->autoneg != AUTONEG_ENABLE && cmd->autoneg != AUTONEG_DISABLE) - return -EINVAL; - if (cmd->autoneg == AUTONEG_ENABLE && cmd->advertising == 0) - return -EINVAL; - if (cmd->duplex != DUPLEX_HALF && cmd->duplex != DUPLEX_FULL) - return -EINVAL; - if (cmd->autoneg == AUTONEG_DISABLE) - switch (cmd->speed) { - case SPEED_10: - if (cmd->duplex == DUPLEX_HALF && - (features & SUPPORTED_10baseT_Half) == 0) - return -EINVAL; - if (cmd->duplex == DUPLEX_FULL && - (features & SUPPORTED_10baseT_Full) == 0) - return -EINVAL; - break; - case SPEED_100: - if (cmd->duplex == DUPLEX_HALF && - (features & SUPPORTED_100baseT_Half) == 0) - return -EINVAL; - if (cmd->duplex == DUPLEX_FULL && - (features & SUPPORTED_100baseT_Full) == 0) - return -EINVAL; - break; - default: - return -EINVAL; - } - else if ((features & SUPPORTED_Autoneg) == 0) - return -EINVAL; - - spin_lock_irq(&aup->lock); - au1000_start_link(dev, cmd); - spin_unlock_irq(&aup->lock); - return 0; -} + if (!capable(CAP_NET_ADMIN)) + return -EPERM; -static int au1000_nway_reset(struct net_device *dev) -{ - struct au1000_private *aup = (struct au1000_private *)dev->priv; + if (aup->phy_dev) + return phy_ethtool_sset(aup->phy_dev, cmd); - if (!aup->want_autoneg) - return -EINVAL; - spin_lock_irq(&aup->lock); - au1000_start_link(dev, NULL); - spin_unlock_irq(&aup->lock); - return 0; + return -EINVAL; } static void @@ -1394,17 +609,11 @@ au1000_get_drvinfo(struct net_device *de info->regdump_len = 0; } -static u32 au1000_get_link(struct net_device *dev) -{ - return netif_carrier_ok(dev); -} - static struct ethtool_ops au1000_ethtool_ops = { .get_settings = au1000_get_settings, .set_settings = au1000_set_settings, .get_drvinfo = au1000_get_drvinfo, - .nway_reset = au1000_nway_reset, - .get_link = au1000_get_link + .get_link = ethtool_op_get_link, }; static struct net_device * au1000_probe(int port_num) @@ -1499,23 +708,31 @@ static struct net_device * au1000_probe( memcpy(dev->dev_addr, au1000_mac_addr, sizeof(au1000_mac_addr)); dev->dev_addr[5] += port_num; - /* Bring the device out of reset, otherwise probing the MII will hang */ - *aup->enable = MAC_EN_CLOCK_ENABLE; - au_sync_delay(2); - *aup->enable = MAC_EN_RESET0 | MAC_EN_RESET1 | MAC_EN_RESET2 | - MAC_EN_CLOCK_ENABLE; - au_sync_delay(2); - - aup->mii = kmalloc(sizeof(struct mii_phy), GFP_KERNEL); - if (!aup->mii) { - printk(KERN_ERR "%s: out of memory\n", dev->name); - goto err_out; - } - aup->mii->next = NULL; - aup->mii->chip_info = NULL; - aup->mii->status = 0; - aup->mii->mii_control_reg = 0; - aup->mii->mii_data_reg = 0; + *aup->enable = 0; + aup->mac_enabled = 0; + + aup->mii_bus.priv = dev; + aup->mii_bus.read = mdiobus_read; + aup->mii_bus.write = mdiobus_write; + aup->mii_bus.reset = mdiobus_reset; + aup->mii_bus.name = "au1000_eth_mii"; + aup->mii_bus.id = aup->mac_id; + aup->mii_bus.irq = kmalloc(sizeof(int)*PHY_MAX_ADDR, GFP_KERNEL); + for(i = 0; i < PHY_MAX_ADDR; ++i) + aup->mii_bus.irq[i] = PHY_POLL; + + /* if known, set corresponding PHY IRQs */ +#if defined(AU1XXX_PHY_STATIC_CONFIG) +# if defined(AU1XXX_PHY0_IRQ) + if (AU1XXX_PHY0_BUSID == aup->mii_bus.id) + aup->mii_bus.irq[AU1XXX_PHY0_ADDR] = AU1XXX_PHY0_IRQ; +# endif +# if defined(AU1XXX_PHY1_IRQ) + if (AU1XXX_PHY1_BUSID == aup->mii_bus.id) + aup->mii_bus.irq[AU1XXX_PHY1_ADDR] = AU1XXX_PHY1_IRQ; +# endif +#endif + mdiobus_register(&aup->mii_bus); if (mii_probe(dev) != 0) { goto err_out; @@ -1561,7 +778,6 @@ static struct net_device * au1000_probe( dev->set_multicast_list = &set_rx_mode; dev->do_ioctl = &au1000_ioctl; SET_ETHTOOL_OPS(dev, &au1000_ethtool_ops); - dev->set_config = &au1000_set_config; dev->tx_timeout = au1000_tx_timeout; dev->watchdog_timeo = ETH_TX_TIMEOUT; @@ -1577,7 +793,7 @@ err_out: /* here we should have a valid dev plus aup-> register addresses * so we can reset the mac properly.*/ reset_mac(dev); - kfree(aup->mii); + for (i = 0; i < NUM_RX_DMA; i++) { if (aup->rx_db_inuse[i]) ReleaseDB(aup, aup->rx_db_inuse[i]); @@ -1610,19 +826,14 @@ static int au1000_init(struct net_device u32 flags; int i; u32 control; - u16 link, speed; if (au1000_debug > 4) printk("%s: au1000_init\n", dev->name); - spin_lock_irqsave(&aup->lock, flags); - /* bring the device out of reset */ - *aup->enable = MAC_EN_CLOCK_ENABLE; - au_sync_delay(2); - *aup->enable = MAC_EN_RESET0 | MAC_EN_RESET1 | - MAC_EN_RESET2 | MAC_EN_CLOCK_ENABLE; - au_sync_delay(20); + enable_mac(dev, 1); + + spin_lock_irqsave(&aup->lock, flags); aup->mac->control = 0; aup->tx_head = (aup->tx_dma_ring[0]->buff_stat & 0xC) >> 2; @@ -1638,12 +849,16 @@ static int au1000_init(struct net_device } au_sync(); - aup->phy_ops->phy_status(dev, aup->phy_addr, &link, &speed); - control = MAC_DISABLE_RX_OWN | MAC_RX_ENABLE | MAC_TX_ENABLE; + control = MAC_RX_ENABLE | MAC_TX_ENABLE; #ifndef CONFIG_CPU_LITTLE_ENDIAN control |= MAC_BIG_ENDIAN; #endif - if (link && (dev->if_port == IF_PORT_100BASEFX)) { + if (aup->phy_dev) { + if (aup->phy_dev->link && (DUPLEX_FULL == aup->phy_dev->duplex)) + control |= MAC_FULL_DUPLEX; + else + control |= MAC_DISABLE_RX_OWN; + } else { /* PHY-less op, assume full-duplex */ control |= MAC_FULL_DUPLEX; } @@ -1655,57 +870,84 @@ #endif return 0; } -static void au1000_timer(unsigned long data) +static void +au1000_adjust_link(struct net_device *dev) { - struct net_device *dev = (struct net_device *)data; struct au1000_private *aup = (struct au1000_private *) dev->priv; - unsigned char if_port; - u16 link, speed; + struct phy_device *phydev = aup->phy_dev; + unsigned long flags; - if (!dev) { - /* fatal error, don't restart the timer */ - printk(KERN_ERR "au1000_timer error: NULL dev\n"); - return; - } + int status_change = 0; - if_port = dev->if_port; - if (aup->phy_ops->phy_status(dev, aup->phy_addr, &link, &speed) == 0) { - if (link) { - if (!netif_carrier_ok(dev)) { - netif_carrier_on(dev); - printk(KERN_INFO "%s: link up\n", dev->name); - } - } - else { - if (netif_carrier_ok(dev)) { - netif_carrier_off(dev); - dev->if_port = 0; - printk(KERN_INFO "%s: link down\n", dev->name); - } + BUG_ON(!aup->phy_dev); + + spin_lock_irqsave(&aup->lock, flags); + + if (phydev->link && (aup->old_speed != phydev->speed)) { + // speed changed + + switch(phydev->speed) { + case SPEED_10: + case SPEED_100: + break; + default: + printk(KERN_WARNING + "%s: Speed (%d) is not 10/100 ???\n", + dev->name, phydev->speed); + break; } + + aup->old_speed = phydev->speed; + + status_change = 1; } - if (link && (dev->if_port != if_port) && - (dev->if_port != IF_PORT_UNKNOWN)) { + if (phydev->link && (aup->old_duplex != phydev->duplex)) { + // duplex mode changed + + /* switching duplex mode requires to disable rx and tx! */ hard_stop(dev); - if (dev->if_port == IF_PORT_100BASEFX) { - printk(KERN_INFO "%s: going to full duplex\n", - dev->name); - aup->mac->control |= MAC_FULL_DUPLEX; - au_sync_delay(1); - } - else { - aup->mac->control &= ~MAC_FULL_DUPLEX; - au_sync_delay(1); - } + + if (DUPLEX_FULL == phydev->duplex) + aup->mac->control = ((aup->mac->control + | MAC_FULL_DUPLEX) + & ~MAC_DISABLE_RX_OWN); + else + aup->mac->control = ((aup->mac->control + & ~MAC_FULL_DUPLEX) + | MAC_DISABLE_RX_OWN); + au_sync_delay(1); + enable_rx_tx(dev); + aup->old_duplex = phydev->duplex; + + status_change = 1; + } + + if(phydev->link != aup->old_link) { + // link state changed + + if (phydev->link) // link went up + netif_schedule(dev); + else { // link went down + aup->old_speed = 0; + aup->old_duplex = -1; + } + + aup->old_link = phydev->link; + status_change = 1; } - aup->timer.expires = RUN_AT((1*HZ)); - aup->timer.data = (unsigned long)dev; - aup->timer.function = &au1000_timer; /* timer handler */ - add_timer(&aup->timer); + spin_unlock_irqrestore(&aup->lock, flags); + if (status_change) { + if (phydev->link) + printk(KERN_INFO "%s: link up (%d/%s)\n", + dev->name, phydev->speed, + DUPLEX_FULL == phydev->duplex ? "Full" : "Half"); + else + printk(KERN_INFO "%s: link down\n", dev->name); + } } static int au1000_open(struct net_device *dev) @@ -1716,25 +958,26 @@ static int au1000_open(struct net_device if (au1000_debug > 4) printk("%s: open: dev=%p\n", dev->name, dev); + if ((retval = request_irq(dev->irq, &au1000_interrupt, 0, + dev->name, dev))) { + printk(KERN_ERR "%s: unable to get IRQ %d\n", + dev->name, dev->irq); + return retval; + } + if ((retval = au1000_init(dev))) { printk(KERN_ERR "%s: error in au1000_init\n", dev->name); free_irq(dev->irq, dev); return retval; } - netif_start_queue(dev); - if ((retval = request_irq(dev->irq, &au1000_interrupt, 0, - dev->name, dev))) { - printk(KERN_ERR "%s: unable to get IRQ %d\n", - dev->name, dev->irq); - return retval; + if (aup->phy_dev) { + /* cause the PHY state machine to schedule a link state check */ + aup->phy_dev->state = PHY_CHANGELINK; + phy_start(aup->phy_dev); } - init_timer(&aup->timer); /* used in ioctl() */ - aup->timer.expires = RUN_AT((3*HZ)); - aup->timer.data = (unsigned long)dev; - aup->timer.function = &au1000_timer; /* timer handler */ - add_timer(&aup->timer); + netif_start_queue(dev); if (au1000_debug > 4) printk("%s: open: Initialization done.\n", dev->name); @@ -1744,16 +987,19 @@ static int au1000_open(struct net_device static int au1000_close(struct net_device *dev) { - u32 flags; - struct au1000_private *aup = (struct au1000_private *) dev->priv; + unsigned long flags; + struct au1000_private *const aup = (struct au1000_private *) dev->priv; if (au1000_debug > 4) printk("%s: close: dev=%p\n", dev->name, dev); - reset_mac(dev); + if (aup->phy_dev) + phy_stop(aup->phy_dev); spin_lock_irqsave(&aup->lock, flags); - + + reset_mac_unlocked (dev); + /* stop the device */ netif_stop_queue(dev); @@ -1775,7 +1021,6 @@ static void __exit au1000_cleanup_module if (dev) { aup = (struct au1000_private *) dev->priv; unregister_netdev(dev); - kfree(aup->mii); for (j = 0; j < NUM_RX_DMA; j++) if (aup->rx_db_inuse[j]) ReleaseDB(aup, aup->rx_db_inuse[j]); @@ -1798,7 +1043,7 @@ static void update_tx_stats(struct net_d struct net_device_stats *ps = &aup->stats; if (status & TX_FRAME_ABORTED) { - if (dev->if_port == IF_PORT_100BASEFX) { + if (!aup->phy_dev || (DUPLEX_FULL == aup->phy_dev->duplex)) { if (status & (TX_JAB_TIMEOUT | TX_UNDERRUN)) { /* any other tx errors are only valid * in half duplex mode */ @@ -2072,126 +1317,15 @@ static void set_rx_mode(struct net_devic } } - static int au1000_ioctl(struct net_device *dev, struct ifreq *rq, int cmd) { struct au1000_private *aup = (struct au1000_private *)dev->priv; - u16 *data = (u16 *)&rq->ifr_ifru; - - switch(cmd) { - case SIOCDEVPRIVATE: /* Get the address of the PHY in use. */ - case SIOCGMIIPHY: - if (!netif_running(dev)) return -EINVAL; - data[0] = aup->phy_addr; - case SIOCDEVPRIVATE+1: /* Read the specified MII register. */ - case SIOCGMIIREG: - data[3] = mdio_read(dev, data[0], data[1]); - return 0; - case SIOCDEVPRIVATE+2: /* Write the specified MII register */ - case SIOCSMIIREG: - if (!capable(CAP_NET_ADMIN)) - return -EPERM; - mdio_write(dev, data[0], data[1],data[2]); - return 0; - default: - return -EOPNOTSUPP; - } - -} - - -static int au1000_set_config(struct net_device *dev, struct ifmap *map) -{ - struct au1000_private *aup = (struct au1000_private *) dev->priv; - u16 control; - if (au1000_debug > 4) { - printk("%s: set_config called: dev->if_port %d map->port %x\n", - dev->name, dev->if_port, map->port); - } + if (!netif_running(dev)) return -EINVAL; - switch(map->port){ - case IF_PORT_UNKNOWN: /* use auto here */ - printk(KERN_INFO "%s: config phy for aneg\n", - dev->name); - dev->if_port = map->port; - /* Link Down: the timer will bring it up */ - netif_carrier_off(dev); - - /* read current control */ - control = mdio_read(dev, aup->phy_addr, MII_CONTROL); - control &= ~(MII_CNTL_FDX | MII_CNTL_F100); - - /* enable auto negotiation and reset the negotiation */ - mdio_write(dev, aup->phy_addr, MII_CONTROL, - control | MII_CNTL_AUTO | - MII_CNTL_RST_AUTO); + if (!aup->phy_dev) return -EINVAL; // PHY not controllable - break; - - case IF_PORT_10BASET: /* 10BaseT */ - printk(KERN_INFO "%s: config phy for 10BaseT\n", - dev->name); - dev->if_port = map->port; - - /* Link Down: the timer will bring it up */ - netif_carrier_off(dev); - - /* set Speed to 10Mbps, Half Duplex */ - control = mdio_read(dev, aup->phy_addr, MII_CONTROL); - control &= ~(MII_CNTL_F100 | MII_CNTL_AUTO | - MII_CNTL_FDX); - - /* disable auto negotiation and force 10M/HD mode*/ - mdio_write(dev, aup->phy_addr, MII_CONTROL, control); - break; - - case IF_PORT_100BASET: /* 100BaseT */ - case IF_PORT_100BASETX: /* 100BaseTx */ - printk(KERN_INFO "%s: config phy for 100BaseTX\n", - dev->name); - dev->if_port = map->port; - - /* Link Down: the timer will bring it up */ - netif_carrier_off(dev); - - /* set Speed to 100Mbps, Half Duplex */ - /* disable auto negotiation and enable 100MBit Mode */ - control = mdio_read(dev, aup->phy_addr, MII_CONTROL); - control &= ~(MII_CNTL_AUTO | MII_CNTL_FDX); - control |= MII_CNTL_F100; - mdio_write(dev, aup->phy_addr, MII_CONTROL, control); - break; - - case IF_PORT_100BASEFX: /* 100BaseFx */ - printk(KERN_INFO "%s: config phy for 100BaseFX\n", - dev->name); - dev->if_port = map->port; - - /* Link Down: the timer will bring it up */ - netif_carrier_off(dev); - - /* set Speed to 100Mbps, Full Duplex */ - /* disable auto negotiation and enable 100MBit Mode */ - control = mdio_read(dev, aup->phy_addr, MII_CONTROL); - control &= ~MII_CNTL_AUTO; - control |= MII_CNTL_F100 | MII_CNTL_FDX; - mdio_write(dev, aup->phy_addr, MII_CONTROL, control); - break; - case IF_PORT_10BASE2: /* 10Base2 */ - case IF_PORT_AUI: /* AUI */ - /* These Modes are not supported (are they?)*/ - printk(KERN_ERR "%s: 10Base2/AUI not supported", - dev->name); - return -EOPNOTSUPP; - break; - - default: - printk(KERN_ERR "%s: Invalid media selected", - dev->name); - return -EINVAL; - } - return 0; + return phy_mii_ioctl(aup->phy_dev, if_mii(rq), cmd); } static struct net_device_stats *au1000_get_stats(struct net_device *dev) diff --git a/drivers/net/au1000_eth.h b/drivers/net/au1000_eth.h index 7f9326e..41c2f84 100644 --- a/drivers/net/au1000_eth.h +++ b/drivers/net/au1000_eth.h @@ -40,120 +40,6 @@ #define MAC_MIN_PKT_SIZE 64 #define MULTICAST_FILTER_LIMIT 64 -/* FIXME - * The PHY defines should be in a separate file. - */ - -/* MII register offsets */ -#define MII_CONTROL 0x0000 -#define MII_STATUS 0x0001 -#define MII_PHY_ID0 0x0002 -#define MII_PHY_ID1 0x0003 -#define MII_ANADV 0x0004 -#define MII_ANLPAR 0x0005 -#define MII_AEXP 0x0006 -#define MII_ANEXT 0x0007 -#define MII_LSI_PHY_CONFIG 0x0011 -/* Status register */ -#define MII_LSI_PHY_STAT 0x0012 -#define MII_AMD_PHY_STAT MII_LSI_PHY_STAT -#define MII_INTEL_PHY_STAT 0x0011 - -#define MII_AUX_CNTRL 0x0018 -/* mii registers specific to AMD 79C901 */ -#define MII_STATUS_SUMMARY = 0x0018 - -/* MII Control register bit definitions. */ -#define MII_CNTL_FDX 0x0100 -#define MII_CNTL_RST_AUTO 0x0200 -#define MII_CNTL_ISOLATE 0x0400 -#define MII_CNTL_PWRDWN 0x0800 -#define MII_CNTL_AUTO 0x1000 -#define MII_CNTL_F100 0x2000 -#define MII_CNTL_LPBK 0x4000 -#define MII_CNTL_RESET 0x8000 - -/* MII Status register bit */ -#define MII_STAT_EXT 0x0001 -#define MII_STAT_JAB 0x0002 -#define MII_STAT_LINK 0x0004 -#define MII_STAT_CAN_AUTO 0x0008 -#define MII_STAT_FAULT 0x0010 -#define MII_STAT_AUTO_DONE 0x0020 -#define MII_STAT_CAN_T 0x0800 -#define MII_STAT_CAN_T_FDX 0x1000 -#define MII_STAT_CAN_TX 0x2000 -#define MII_STAT_CAN_TX_FDX 0x4000 -#define MII_STAT_CAN_T4 0x8000 - - -#define MII_ID1_OUI_LO 0xFC00 /* low bits of OUI mask */ -#define MII_ID1_MODEL 0x03F0 /* model number */ -#define MII_ID1_REV 0x000F /* model number */ - -/* MII NWAY Register Bits ... - valid for the ANAR (Auto-Negotiation Advertisement) and - ANLPAR (Auto-Negotiation Link Partner) registers */ -#define MII_NWAY_NODE_SEL 0x001f -#define MII_NWAY_CSMA_CD 0x0001 -#define MII_NWAY_T 0x0020 -#define MII_NWAY_T_FDX 0x0040 -#define MII_NWAY_TX 0x0080 -#define MII_NWAY_TX_FDX 0x0100 -#define MII_NWAY_T4 0x0200 -#define MII_NWAY_PAUSE 0x0400 -#define MII_NWAY_RF 0x2000 /* Remote Fault */ -#define MII_NWAY_ACK 0x4000 /* Remote Acknowledge */ -#define MII_NWAY_NP 0x8000 /* Next Page (Enable) */ - -/* mii stsout register bits */ -#define MII_STSOUT_LINK_FAIL 0x4000 -#define MII_STSOUT_SPD 0x0080 -#define MII_STSOUT_DPLX 0x0040 - -/* mii stsics register bits */ -#define MII_STSICS_SPD 0x8000 -#define MII_STSICS_DPLX 0x4000 -#define MII_STSICS_LINKSTS 0x0001 - -/* mii stssum register bits */ -#define MII_STSSUM_LINK 0x0008 -#define MII_STSSUM_DPLX 0x0004 -#define MII_STSSUM_AUTO 0x0002 -#define MII_STSSUM_SPD 0x0001 - -/* lsi phy status register */ -#define MII_LSI_PHY_STAT_FDX 0x0040 -#define MII_LSI_PHY_STAT_SPD 0x0080 - -/* amd phy status register */ -#define MII_AMD_PHY_STAT_FDX 0x0800 -#define MII_AMD_PHY_STAT_SPD 0x0400 - -/* intel phy status register */ -#define MII_INTEL_PHY_STAT_FDX 0x0200 -#define MII_INTEL_PHY_STAT_SPD 0x4000 - -/* Auxilliary Control/Status Register */ -#define MII_AUX_FDX 0x0001 -#define MII_AUX_100 0x0002 -#define MII_AUX_F100 0x0004 -#define MII_AUX_ANEG 0x0008 - -typedef struct mii_phy { - struct mii_phy * next; - struct mii_chip_info * chip_info; - u16 status; - u32 *mii_control_reg; - u32 *mii_data_reg; -} mii_phy_t; - -struct phy_ops { - int (*phy_init) (struct net_device *, int); - int (*phy_reset) (struct net_device *, int); - int (*phy_status) (struct net_device *, int, u16 *, u16 *); -}; - /* * Data Buffer Descriptor. Data buffers must be aligned on 32 byte * boundary for both, receive and transmit. @@ -200,7 +86,6 @@ typedef struct mac_reg { struct au1000_private { - db_dest_t *pDBfree; db_dest_t db[NUM_RX_BUFFS+NUM_TX_BUFFS]; volatile rx_dma_t *rx_dma_ring[NUM_RX_DMA]; @@ -213,8 +98,15 @@ struct au1000_private { u32 tx_full; int mac_id; - mii_phy_t *mii; - struct phy_ops *phy_ops; + + int mac_enabled; /* whether MAC is currently enabled and running (req. for mdio) */ + + int old_link; /* used by au1000_adjust_link */ + int old_speed; + int old_duplex; + + struct phy_device *phy_dev; + struct mii_bus mii_bus; /* These variables are just for quick access to certain regs addresses. */ volatile mac_reg_t *mac; /* mac registers */ @@ -223,14 +115,6 @@ struct au1000_private { u32 vaddr; /* virtual address of rx/tx buffers */ dma_addr_t dma_addr; /* dma address of rx/tx buffers */ - u8 *hash_table; - u32 hash_mode; - u32 intr_work_done; /* number of Rx and Tx pkts processed in the isr */ - int phy_addr; /* phy address */ - u32 options; /* User-settable misc. driver options. */ - u32 drv_flags; - int want_autoneg; struct net_device_stats stats; - struct timer_list timer; spinlock_t lock; /* Serialise access to device */ }; -- 1.3.2 From ths@networkno.de Thu Jun 1 11:24:55 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 01 Jun 2006 11:25:02 +0200 (CEST) Received: from bender.bawue.de ([193.7.176.20]:45224 "HELO bender.bawue.de") by ftp.linux-mips.org with SMTP id S8133361AbWFAJYz (ORCPT ); Thu, 1 Jun 2006 11:24:55 +0200 Received: from lagash (88-106-172-197.dynamic.dsl.as9105.com [88.106.172.197]) (using TLSv1 with cipher DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by bender.bawue.de (Postfix) with ESMTP id F013144D2E; Thu, 1 Jun 2006 11:24:52 +0200 (MEST) Received: from ths by lagash with local (Exim 4.62) (envelope-from ) id 1FljPZ-0004BJ-Ng; Thu, 01 Jun 2006 10:24:13 +0100 Date: Thu, 1 Jun 2006 10:24:13 +0100 To: zhuzhenhua Cc: linux-mips Subject: Re: BFD: Warning: Writing section `.text' to huge (ie negative) file offset 0xa1ffff10 Message-ID: <20060601092413.GL1717@networkno.de> References: <50c9a2250605312319v7480f2el36d9c0a052c85d5f@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <50c9a2250605312319v7480f2el36d9c0a052c85d5f@mail.gmail.com> User-Agent: Mutt/1.5.11+cvs20060403 From: Thiemo Seufer Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11631 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ths@networkno.de Precedence: bulk X-list: linux-mips zhuzhenhua wrote: > i have write a code to link at 0xa2000000(uncached address) > but when link i get the error as > "BFD: Warning: Writing section `.text' to huge (ie negative) file > offset 0xa1ffff10. > BFD: Warning: Writing section `.data' to huge (ie negative) file > offset 0xa200b050. > BFD: Warning: Writing section `.reginfo' to huge (ie negative) file > offset 0xa200c980. > mipsel-linux-objcopy: /root/project/brec_flash/release/brec_flash.bin: > File truncated > make: *** [brec_flash] Error 1" > > my link.xn as follow: > > OUTPUT_ARCH(mips) > ENTRY(brec_flash_entry) > SECTIONS > { > .text 0xa2000000 : Use . = 0xa2000000; .text : instead. "info ld" explains the subtle difference. Thiemo From zzh.hust@gmail.com Thu Jun 1 12:57:41 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 01 Jun 2006 12:57:49 +0200 (CEST) Received: from nf-out-0910.google.com ([64.233.182.189]:37914 "EHLO nf-out-0910.google.com") by ftp.linux-mips.org with ESMTP id S8133484AbWFAK5l (ORCPT ); Thu, 1 Jun 2006 12:57:41 +0200 Received: by nf-out-0910.google.com with SMTP id l36so470174nfa for ; Thu, 01 Jun 2006 03:57:41 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=qtmchspno369kX0KM5JZTIxkDFXbZ3BlkeDPZJwigF9bQPCNIJ71U8nixeY4wWDqD3Icf1PEFEdZdaMZT6PeyJrVXceMD9WR5o+pBPMEtvH2FtiTzZKm+pA6y2R9sAZM9WHawpOgEvz+9TrDevXqX/5I+qO19b7ykTvsCv0HDEk= Received: by 10.48.243.8 with SMTP id q8mr600850nfh; Thu, 01 Jun 2006 03:56:31 -0700 (PDT) Received: by 10.66.241.4 with HTTP; Thu, 1 Jun 2006 03:56:31 -0700 (PDT) Message-ID: <50c9a2250606010356s63f6d6e7j255c77660d6f472a@mail.gmail.com> Date: Thu, 1 Jun 2006 18:56:31 +0800 From: zhuzhenhua To: "Thiemo Seufer" Subject: Re: BFD: Warning: Writing section `.text' to huge (ie negative) file offset 0xa1ffff10 Cc: linux-mips In-Reply-To: <20060601092413.GL1717@networkno.de> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <50c9a2250605312319v7480f2el36d9c0a052c85d5f@mail.gmail.com> <20060601092413.GL1717@networkno.de> Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11632 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: zzh.hust@gmail.com Precedence: bulk X-list: linux-mips On 6/1/06, Thiemo Seufer wrote: > zhuzhenhua wrote: > > i have write a code to link at 0xa2000000(uncached address) > > but when link i get the error as > > "BFD: Warning: Writing section `.text' to huge (ie negative) file > > offset 0xa1ffff10. > > BFD: Warning: Writing section `.data' to huge (ie negative) file > > offset 0xa200b050. > > BFD: Warning: Writing section `.reginfo' to huge (ie negative) file > > offset 0xa200c980. > > mipsel-linux-objcopy: /root/project/brec_flash/release/brec_flash.bin: > > File truncated > > make: *** [brec_flash] Error 1" > > > > my link.xn as follow: > > > > OUTPUT_ARCH(mips) > > ENTRY(brec_flash_entry) > > SECTIONS > > { > > .text 0xa2000000 : > > Use > > . = 0xa2000000; > .text : > > instead. "info ld" explains the subtle difference. > > > Thiemo > do you mean use . = 0xa2000000; .text : to replace .text 0xa2000000 : ? i modify as that, and it still get the same message thanks zhuzhenhua From nigel@mips.com Thu Jun 1 14:50:18 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 01 Jun 2006 14:50:28 +0200 (CEST) Received: from 209-232-97-206.ded.pacbell.net ([209.232.97.206]:37764 "EHLO dns0.mips.com") by ftp.linux-mips.org with ESMTP id S8133555AbWFAMuS (ORCPT ); Thu, 1 Jun 2006 14:50:18 +0200 Received: from mercury.mips.com (sbcns-dmz [209.232.97.193]) by dns0.mips.com (8.12.11/8.12.11) with ESMTP id k51Co5hs013881; Thu, 1 Jun 2006 05:50:06 -0700 (PDT) Received: from ukservices1.mips.com (ukservices1 [192.168.192.240]) by mercury.mips.com (8.13.5/8.13.5) with ESMTP id k51Co4P9014062; Thu, 1 Jun 2006 05:50:05 -0700 (PDT) Received: from highbury.mips.com ([192.168.192.236]) by ukservices1.mips.com with esmtp (Exim 3.36 #1 (Debian)) id 1Flmce-0006wN-00; Thu, 01 Jun 2006 13:49:56 +0100 Message-ID: <447EE274.7060207@mips.com> Date: Thu, 01 Jun 2006 13:49:56 +0100 From: Nigel Stephens Organization: MIPS Technologies User-Agent: Mail/News 1.5 (X11/20060318) MIME-Version: 1.0 To: zhuzhenhua CC: Thiemo Seufer , linux-mips Subject: Re: BFD: Warning: Writing section `.text' to huge (ie negative) file offset 0xa1ffff10 References: <50c9a2250605312319v7480f2el36d9c0a052c85d5f@mail.gmail.com> <20060601092413.GL1717@networkno.de> <50c9a2250606010356s63f6d6e7j255c77660d6f472a@mail.gmail.com> In-Reply-To: <50c9a2250606010356s63f6d6e7j255c77660d6f472a@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-MIPS-Technologies-UK-MailScanner: Found to be clean X-MIPS-Technologies-UK-MailScanner-From: nigel@mips.com X-Scanned-By: MIMEDefang 2.39 Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11633 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: nigel@mips.com Precedence: bulk X-list: linux-mips zhuzhenhua wrote: > On 6/1/06, Thiemo Seufer wrote: >> zhuzhenhua wrote: >> > i have write a code to link at 0xa2000000(uncached address) >> > but when link i get the error as >> > "BFD: Warning: Writing section `.text' to huge (ie negative) file >> > offset 0xa1ffff10. >> > BFD: Warning: Writing section `.data' to huge (ie negative) file >> > offset 0xa200b050. >> > BFD: Warning: Writing section `.reginfo' to huge (ie negative) file >> > offset 0xa200c980. >> > mipsel-linux-objcopy: /root/project/brec_flash/release/brec_flash.bin: >> > File truncated >> > make: *** [brec_flash] Error 1" >> > >> > my link.xn as follow: >> > >> > OUTPUT_ARCH(mips) >> > ENTRY(brec_flash_entry) >> > SECTIONS >> > { >> > .text 0xa2000000 : >> >> Use >> >> . = 0xa2000000; >> .text : >> >> instead. "info ld" explains the subtle difference. >> >> >> Thiemo >> > > do you mean use > . = 0xa2000000; > .text : > to replace > .text 0xa2000000 : > ? > i modify as that, and it still get the same message > I think the problem is not with the linker, but in your use of objcopy to convert your ELF file to a raw binary file. 1) What arguments are you giving to mipsel-linux-objcopy? 2) What is the output from mipsel-linux-objdump -h run on your intermediate ELF object file? Nigel -- Nigel Stephens e. nigel@mips.com MIPS Technologies p. +44 1223 203110 Building 7200 f. +44 1223 203181 Cambridge Research Park m. +44 7976 686470 Beach Road, Waterbeach w. http://www.mips.com Cambridge CB5 9TL, UK From anemo@mba.ocn.ne.jp Thu Jun 1 18:53:15 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 01 Jun 2006 18:53:24 +0200 (CEST) Received: from mba.ocn.ne.jp ([210.190.142.172]:26335 "HELO smtp.mba.ocn.ne.jp") by ftp.linux-mips.org with SMTP id S8133713AbWFAQxP (ORCPT ); Thu, 1 Jun 2006 18:53:15 +0200 Received: from localhost (p1057-ipad212funabasi.chiba.ocn.ne.jp [58.91.165.57]) by smtp.mba.ocn.ne.jp (Postfix) with ESMTP id 49967B987; Fri, 2 Jun 2006 01:53:09 +0900 (JST) Date: Fri, 02 Jun 2006 01:54:04 +0900 (JST) Message-Id: <20060602.015404.93020143.anemo@mba.ocn.ne.jp> To: geert@linux-m68k.org Cc: linux-mips@linux-mips.org, ralf@linux-mips.org Subject: Re: [PATCH] fix some compiler warnings (field width, unused variable) From: Atsushi Nemoto In-Reply-To: References: <20060601.010003.39154219.anemo@mba.ocn.ne.jp> X-Fingerprint: 6ACA 1623 39BD 9A94 9B1A B746 CA77 FE94 2874 D52F X-Pgp-Public-Key: http://wwwkeys.pgp.net/pks/lookup?op=get&search=0x2874D52F X-Mailer: Mew version 3.3 on Emacs 21.4 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11634 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: anemo@mba.ocn.ne.jp Precedence: bulk X-list: linux-mips On Wed, 31 May 2006 18:47:54 +0200 (CEST), Geert Uytterhoeven wrote: > > printk("initrd extends beyond end of memory " > > "(0x%0*Lx > 0x%0*Lx)\ndisabling initrd\n", > > `%L' is obsolete for long long, use `%ll' instead. > > > - sizeof(long) * 2, > > + (int)(sizeof(long) * 2), > > (unsigned long long)CPHYSADDR(initrd_end), > > As CPHYSADDR() returns a ptrdiff_t, what about using `%t' instead? > Ah, that one doesn't print hex (hmm, C99 doesn't seem to tell). > > You can cast to `void *' and use `%p' to get hex, and the field width will > automagically be `2*sizeof(void *)', according to lib/vsprintf.c. Thanks. Though Ralf already committed it with slight changes, this patch will make kernel just a bit smaller. [MIPS] simplify printk format string (use %p instead of %0*Lx) Signed-off-by: Atsushi Nemoto diff --git a/arch/mips/kernel/setup.c b/arch/mips/kernel/setup.c index 397a70e..4ab4bd5 100644 --- a/arch/mips/kernel/setup.c +++ b/arch/mips/kernel/setup.c @@ -420,18 +420,15 @@ static inline void bootmem_init(void) if (initrd_start) { unsigned long initrd_size = ((unsigned char *)initrd_end) - ((unsigned char *)initrd_start); - const int width = sizeof(long) * 2; printk("Initial ramdisk at: 0x%p (%lu bytes)\n", (void *)initrd_start, initrd_size); if (CPHYSADDR(initrd_end) > PFN_PHYS(max_low_pfn)) { printk("initrd extends beyond end of memory " - "(0x%0*Lx > 0x%0*Lx)\ndisabling initrd\n", - width, - (unsigned long long) CPHYSADDR(initrd_end), - width, - (unsigned long long) PFN_PHYS(max_low_pfn)); + "(0x%p > 0x%p)\ndisabling initrd\n", + (void *)CPHYSADDR(initrd_end), + (void *)PFN_PHYS(max_low_pfn)); initrd_start = initrd_end = 0; initrd_reserve_bootmem = 0; } From dpervushin@ru.mvista.com Thu Jun 1 21:07:09 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 01 Jun 2006 21:07:16 +0200 (CEST) Received: from rtsoft3.corbina.net ([85.21.88.6]:14186 "EHLO buildserver.ru.mvista.com") by ftp.linux-mips.org with ESMTP id S8133732AbWFATHJ (ORCPT ); Thu, 1 Jun 2006 21:07:09 +0200 Received: from [192.168.5.10] ([10.150.0.9]) by buildserver.ru.mvista.com (8.11.6/8.11.6) with ESMTP id k51J77s02204 for ; Fri, 2 Jun 2006 00:07:07 +0500 Subject: [RFC] [PATCH] sys_shmat for 64-bits in 32-bit compat mode From: dmitry pervushin Reply-To: dpervushin@ru.mvista.com To: linux-mips@linux-mips.org Content-Type: text/plain Organization: montavista Date: Thu, 01 Jun 2006 23:07:04 +0400 Message-Id: <1149188824.6986.6.camel@diimka-laptop> Mime-Version: 1.0 X-Mailer: Evolution 2.4.0 Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11635 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: dpervushin@ru.mvista.com Precedence: bulk X-list: linux-mips Hello all, I would like you to comment the following patch. At the some moment, I was faced to problem with syscall sys_shmat in 32-bit mode on 64-bit platforms. I have fixed the function in the same manner as native sys_shmat had been: sys_shmat expects pointer to memory as the return value rather than put_user'ed to the memory pointed by 3rd parameter. Signed-off-by: dmitry pervushin arch/mips/kernel/linux32.c | 4 +++- 1 files changed, 3 insertions(+), 1 deletion(-) Index: linux-mips/arch/mips/kernel/linux32.c =================================================================== --- linux-mips.orig/arch/mips/kernel/linux32.c +++ linux-mips/arch/mips/kernel/linux32.c @@ -36,6 +36,7 @@ #include #include #include +#include #include #include @@ -978,7 +979,8 @@ asmlinkage long sys32_shmat(int shmid, c if (err) return err; - return put_user(raddr, addr); + force_successful_syscall_return(); + return raddr; } struct sysctl_args32 From thomas.koeller@baslerweb.com Thu Jun 1 22:46:46 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 01 Jun 2006 22:46:53 +0200 (CEST) Received: from mail01.hansenet.de ([213.191.73.61]:34715 "EHLO webmail.hansenet.de") by ftp.linux-mips.org with ESMTP id S8133759AbWFAUqq (ORCPT ); Thu, 1 Jun 2006 22:46:46 +0200 Received: from [213.39.208.223] (213.39.208.223) by webmail.hansenet.de (7.2.059) (authenticated as mbx20228207@koeller-hh.org) id 447D3FB200064FAD for linux-mips@linux-mips.org; Thu, 1 Jun 2006 22:46:40 +0200 Received: from localhost.koeller.dyndns.org (localhost.koeller.dyndns.org [127.0.0.1]) by sarkovy.koeller.dyndns.org (Postfix) with ESMTP id 8F12A10AA09 for ; Thu, 1 Jun 2006 22:46:39 +0200 (CEST) From: Thomas Koeller To: linux-mips@linux-mips.org Subject: Location of PCI setup code Date: Thu, 1 Jun 2006 22:46:17 +0200 User-Agent: KMail/1.9.1 Organization: Basler AG MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-Id: <200606012246.17864.thomas.koeller@baslerweb.com> Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11636 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: thomas.koeller@baslerweb.com Precedence: bulk X-list: linux-mips Hi, the PCI setup code for a platform is conventionally located in arch/mips/pci. I fail to see the benefits of separating this particular part of a platform's setup from the rest. The PCI setup code will in general contain references to platform-specific information, such as the overall address space layout, of which the PCI memory and I/O pages are a part. If the PCI setup code were in the platform subdirectory, sharing this information by means of a platform-local header file would be easy. But with the PCI code in arch/mips/pci, this becomes more difficult. The platform header could be located somewhere outside the platform's directory, maybe under 'include' (where?), or referenced via an ugly relative path like '../../vendor/platform/platform.h'. All this seems rather clumsy to me. No other part of a platform's initialization is separated from the rest in a similar way, so what is so special about PCI setup that it cannot be in the platform directory, thereby avoiding all these annoyances? tk -- Thomas Koeller, Software Development Basler Vision Technologies An der Strusbek 60-62 22926 Ahrensburg Germany Tel +49 (4102) 463-390 Fax +49 (4102) 463-46390 mailto:thomas.koeller@baslerweb.com http://www.baslerweb.com From Rajesh_Palani@pmc-sierra.com Fri Jun 2 01:23:07 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 02 Jun 2006 01:23:17 +0200 (CEST) Received: from mother.pmc-sierra.com ([216.241.224.12]:35024 "HELO mother.pmc-sierra.bc.ca") by ftp.linux-mips.org with SMTP id S8133794AbWFAXXH (ORCPT ); Fri, 2 Jun 2006 01:23:07 +0200 Received: (qmail 15838 invoked by uid 101); 1 Jun 2006 23:22:56 -0000 Received: from unknown (HELO ogyruan.pmc-sierra.bc.ca) (216.241.226.236) by mother.pmc-sierra.com with SMTP; 1 Jun 2006 23:22:56 -0000 Received: from bby1exi01.pmc_nt.nt.pmc-sierra.bc.ca (bby1exi01.pmc-sierra.bc.ca [216.241.231.251]) by ogyruan.pmc-sierra.bc.ca (8.13.3/8.12.7) with ESMTP id k51NMlKa021990; Thu, 1 Jun 2006 16:22:52 -0700 Received: by bby1exi01.pmc-sierra.bc.ca with Internet Mail Service (5.5.2656.59) id ; Thu, 1 Jun 2006 16:22:47 -0700 Message-ID: <478F19F21671F04298A2116393EEC3D5274017@sjc1exm08.pmc_nt.nt.pmc-sierra.bc.ca> From: Raj Palani To: Roman Mashak Cc: linux-mips@linux-mips.org Subject: RE: compiling BCM5700 driver Date: Thu, 1 Jun 2006 16:22:39 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11637 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: Rajesh_Palani@pmc-sierra.com Precedence: bulk X-list: linux-mips Hi Roman, The titan_ge.c and titan_ge.h file are still in the kernel, for the Titan chip (Yosemite). Regarding the crash you mention below, kindly use mem=256M in the boot line. The default value of the RAM size is setup to be 512MB and the Sequoia board that you are having may contain only 256MB of RAM. -Raj > -----Original Message----- > From: Roman Mashak [mailto:mrv@corecom.co.kr] > Sent: Wednesday, May 31, 2006 6:42 PM > To: Raj Palani > Cc: linux-mips@linux-mips.org > Subject: Re: compiling BCM5700 driver > > Hello, Raj! > You wrote to "Roman Mashak" ; "Ralf Baechle" > on Wed, 31 May 2006 09:06:44 -0700: > > RP> Yes. We are currently maintaining the Titan GE driver > on "Sequoia" > RP> only in 2.6.x. The GE driver in Sequoia has been > renamed to RP> msp85xx_ge.c. We are in the process of > generating a patchset to add RP> support for Sequoia > (MSP8510/MSP8520) in the Linux/MIPS 2.6 tree. > > RP> Our most recent Linux 2.6 tree for Sequoia is available > on our ftp site RP> (ftp.pmc-sierra.com) under RP> > /pub/linux/2.6.12/linux-2.6.12-rc3_L002.tar.gz. > > There are msp85x0_ge.[ch] in this tarball. And seems old code > from titan_ge.[ch] is still in used. Nevertheless kernel gets panic: > > Linux version 2.6.12-rc3 (root@ecb-test32.corecom.local) (gcc version > 3.3-mips64linux-031001) #1 Thu Jun 1 10:33:22 KST 2006 PMON > reports memory size 256MB cpu_clock set to 900000000 CPU > revision is: 000034c1 FPU revision is: 00003420 PMC-Sierra > Sequoia Board Setup 32-bit support Determined physical RAM map: > memory: 20000000 @ 00000000 (usable) > Built 1 zonelists > Kernel command line: tftp://192.168.11.43/vmlinux > root=/dev/nfs nfsroot=192.168.11.43:/export/linux/mips-fs-be > ip=192.168.11.42:192.168.11.1::255.255.255.0::eth0 > Unknown boot option `tftp://192.168.11.43/vmlinux': ignoring > Primary instruction cache 16kB, physically tagged, 4-way, > linesize 32 bytes. > Primary data cache 16kB, 4-way, linesize 32 bytes. > Secondary cache size 256K, linesize 32 bytes. > Synthesized TLB refill handler (27 instructions). > Synthesized TLB load handler fastpath (39 instructions). > Synthesized TLB store handler fastpath (39 instructions). > Synthesized TLB modify handler fastpath (38 instructions). > PID hash table entries: 4096 (order: 12, 65536 bytes) Using > 450.000 MHz high precision timer. > Dentry cache hash table entries: 131072 (order: 7, 524288 > bytes) Inode-cache hash table entries: 65536 (order: 6, 262144 bytes) > Memory: 515712k/524288k available (1623k kernel code, 8440k > reserved, 372k data, 356k init, 0k highmem) CompactFlash ATA > Support for PMC-Sierra Sequoia <6>Internal UART Support for > PMC-Sierra Sequoia <7>Calibrating delay loop... 897.02 > BogoMIPS (lpj=448512) Mount-cache hash table entries: 512 > Checking for 'wait' instruction... available. > NET: Registered protocol family 16 > PCI: Failed to allocate mem resource #2:20000000@e0000000 for > 0000:00:01.0 > PCI: Failed to allocate mem resource #2:20000000@e8000000 for > 0000:01:01.0 Generic RTC Driver v1.07 > Serial: 8250/16550 driver $Revision: 1.1.1.1 $ 4 ports, IRQ > sharing disabled ttyS0 at MMIO 0x0 (irq = 0) is a 16550A io > scheduler noop registered io scheduler anticipatory > registered io scheduler deadline registered io scheduler cfq > registered > loop: loaded (max 8 devices) > PMC-Sierra MSP85x0 10/100/1000 Ethernet Driver Device Id : > 206014, Version : 0 > : port 0 with MAC address 00:e0:04:00:02:4e Rx NAPI > supported, Tx Coalescing ON > : port 1 with MAC address 00:e0:04:00:02:4f Rx NAPI > supported, Tx Coalescing ON > NET: Registered protocol family 2 > IP: routing cache hash table of 4096 buckets, 32Kbytes TCP > established hash table entries: 131072 (order: 8, 1048576 > bytes) TCP bind hash table entries: 65536 (order: 6, 262144 bytes) > TCP: Hash tables configured (established 131072 bind 65536) > NET: Registered protocol family 1 > NET: Registered protocol family 17 > Data bus error, epc == 802214d8, ra == 802214ac Oops in > arch/mips/kernel/traps.c::do_be, line 338[#1]: > Cpu 0 > $ 0 : 00000000 90008000 9fc00840 9fc00840 > $ 4 : 00000001 00000000 00000000 8036b97c > $ 8 : 00000000 801d8150 814df0f0 ffffffff > $12 : 00200200 00100100 0000ffff 8036b974 > $16 : 9fc00000 816b5920 00000840 81690220 > $20 : 0000003c 00000008 ffffffc0 00200000 > $24 : 8036b97c 00000001 > $28 : 80380000 80381df8 81690000 802214ac > Hi : 0006d7ff > Lo : f8164000 > epc : 802214d8 alloc_skb+0x98/0xec Not tainted > ra : 802214ac alloc_skb+0x6c/0xec > Status: 90008002 KERNEL EXL > Cause : 0000801c > PrId : 000034c1 > Modules linked in: > Process swapper (pid: 1, threadinfo=80380000, task=8037ab78) > Stack : 8010d6b0 8026e7e4 814e4e80 80369420 8169030c c01043b0 816b59c0 > 8021a044 > 0000001c 00180c01 00000000 00000000 c0000000 00000000 > 81690220 81690000 > 8034bc14 00000000 00000000 00000000 00000000 8021a608 > 803eb9c0 00000000 > 00000001 80381e68 18230458 80232598 81690000 00000000 > 00000000 81690220 > 8021a684 00100000 8021a16c 00000000 8021aaf8 8023743c > 00000000 fb004000 > ... > Call Trace: > [<8010d6b0>] dma_map_single+0x5c/0x7c > [<8026e7e4>] fib_magic+0x114/0x144 > [<8021a044>] msp85x0_ge_rx_task+0x74/0x174 [<8021a608>] > xdma_config+0x1cc/0x22c [<80232598>] > rtnetlink_fill_ifinfo+0x474/0x57c [<8021a684>] > msp85x0_ge_port_start+0x1c/0x74 [<8021a16c>] > msp85x0_port_init+0x28/0x80 [<8021aaf8>] > msp85x0_eth_setup_tx_ring+0x80/0xc8 > [<8023743c>] netlink_broadcast+0x29c/0x478 [<8021adf0>] > msp85x0_ge_eth_open+0x114/0x250 [<8021af18>] > msp85x0_ge_eth_open+0x23c/0x250 [<80219f14>] > msp85x0_ge_open+0x30/0xec [<80232b84>] > rtmsg_ifinfo+0x80/0xf8 [<80232b58>] rtmsg_ifinfo+0x54/0xf8 > [<80227d2c>] dev_open+0x64/0xd8 [<80227d98>] > dev_open+0xd0/0xd8 [<8022d108>] dev_mc_upload+0x18/0x24 > [<80229f28>] dev_change_flags+0x70/0x158 [<8019a84c>] > proc_create+0x9c/0x100 [<80311fb8>] ic_open_devs+0x20c/0x3a4 > [<8012a874>] msleep+0x48/0x5c [<80313524>] > ip_auto_config+0x64/0x30c [<8030a7f8>] seqgen_init+0x10/0x20 > [<8030a7f8>] seqgen_init+0x10/0x20 [<802f4828>] > do_initcalls+0x50/0x100 [<802f4828>] do_initcalls+0x50/0x100 > [<802f4908>] do_basic_setup+0x30/0x3c [<801004ac>] > init+0x3c/0x120 [<801035d0>] kernel_thread_helper+0x10/0x18 > [<801035c0>] kernel_thread_helper+0x0/0x18 > > > Code: ae30008c ac640000 8e220094 8e230094 > a4600008 8e220094 a440000a 8e230094 Kernel panic - not > syncing: Attempted to kill init! > > > With best regards, Roman Mashak. E-mail: mrv@corecom.co.kr > > From ralf@linux-mips.org Fri Jun 2 01:44:37 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 02 Jun 2006 01:44:45 +0200 (CEST) Received: from localhost.localdomain ([127.0.0.1]:17301 "EHLO bacchus.dhis.org") by ftp.linux-mips.org with ESMTP id S8133810AbWFAXoh (ORCPT ); Fri, 2 Jun 2006 01:44:37 +0200 Received: from denk.linux-mips.net (denk.linux-mips.net [127.0.0.1]) by bacchus.dhis.org (8.13.6/8.13.4) with ESMTP id k51NiWGD018444; Fri, 2 Jun 2006 00:44:32 +0100 Received: (from ralf@localhost) by denk.linux-mips.net (8.13.6/8.13.6/Submit) id k51NiVJT018443; Fri, 2 Jun 2006 00:44:31 +0100 Date: Fri, 2 Jun 2006 00:44:31 +0100 From: Ralf Baechle To: Thomas Koeller Cc: linux-mips@linux-mips.org Subject: Re: Location of PCI setup code Message-ID: <20060601234430.GA16607@linux-mips.org> References: <200606012246.17864.thomas.koeller@baslerweb.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200606012246.17864.thomas.koeller@baslerweb.com> User-Agent: Mutt/1.4.2.1i Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11638 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ralf@linux-mips.org Precedence: bulk X-list: linux-mips On Thu, Jun 01, 2006 at 10:46:17PM +0200, Thomas Koeller wrote: > the PCI setup code for a platform is conventionally located in arch/mips/pci. > I fail to see the benefits of separating this particular part of a platform's > setup from the rest. The PCI setup code will in general contain references to > platform-specific information, such as the overall address space layout, of > which the PCI memory and I/O pages are a part. If the PCI setup code were in > the platform subdirectory, sharing this information by means of a > platform-local header file would be easy. But with the PCI code in > arch/mips/pci, this becomes more difficult. The platform header could be > located somewhere outside the platform's directory, maybe under > 'include' (where?), or referenced via an ugly relative path like > '../../vendor/platform/platform.h'. All this seems rather clumsy to me. No > other part of a platform's initialization is separated from the rest in a > similar way, so what is so special about PCI setup that it cannot be in the > platform directory, thereby avoiding all these annoyances? The per-platform PCI code used to live in the per-platform directories. It turned into a giant mess, very little code was being shared, it was hard to uniformly perform any kind of modification or fixes - and more of that kind of changes will be needed before the PCI codes really shines. Ralf From zzh.hust@gmail.com Fri Jun 2 02:49:44 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 02 Jun 2006 02:49:52 +0200 (CEST) Received: from ug-out-1314.google.com ([66.249.92.170]:62511 "EHLO ug-out-1314.google.com") by ftp.linux-mips.org with ESMTP id S8133811AbWFBAto (ORCPT ); Fri, 2 Jun 2006 02:49:44 +0200 Received: by ug-out-1314.google.com with SMTP id k3so370589ugf for ; Thu, 01 Jun 2006 17:49:43 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=YizIpB6mSBWyEsDjoa8PUzieiR+k6EdnZ52THPZ39JbdaCuWMKERzS4rie+W4J+T3w/uMLtjr0BRiOJVe/fGkGkXbAFMj7rUtYhQvv1X+Lclxesz+fkUuwwfoCBs7K9OAFE7Mk1/4IAijuQ3tOavdI4grhafllbfzlv/nhwYWX8= Received: by 10.67.101.10 with SMTP id d10mr276338ugm; Thu, 01 Jun 2006 17:49:43 -0700 (PDT) Received: by 10.66.241.4 with HTTP; Thu, 1 Jun 2006 17:49:42 -0700 (PDT) Message-ID: <50c9a2250606011749r7f89fbben2c61edd43c7ec0a6@mail.gmail.com> Date: Fri, 2 Jun 2006 08:49:42 +0800 From: zhuzhenhua To: "Nigel Stephens" Subject: Re: BFD: Warning: Writing section `.text' to huge (ie negative) file offset 0xa1ffff10 Cc: "Thiemo Seufer" , linux-mips In-Reply-To: <447EE274.7060207@mips.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <50c9a2250605312319v7480f2el36d9c0a052c85d5f@mail.gmail.com> <20060601092413.GL1717@networkno.de> <50c9a2250606010356s63f6d6e7j255c77660d6f472a@mail.gmail.com> <447EE274.7060207@mips.com> Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11639 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: zzh.hust@gmail.com Precedence: bulk X-list: linux-mips On 6/1/06, Nigel Stephens wrote: > > > zhuzhenhua wrote: > > On 6/1/06, Thiemo Seufer wrote: > >> zhuzhenhua wrote: > >> > i have write a code to link at 0xa2000000(uncached address) > >> > but when link i get the error as > >> > "BFD: Warning: Writing section `.text' to huge (ie negative) file > >> > offset 0xa1ffff10. > >> > BFD: Warning: Writing section `.data' to huge (ie negative) file > >> > offset 0xa200b050. > >> > BFD: Warning: Writing section `.reginfo' to huge (ie negative) file > >> > offset 0xa200c980. > >> > mipsel-linux-objcopy: /root/project/brec_flash/release/brec_flash.bin: > >> > File truncated > >> > make: *** [brec_flash] Error 1" > >> > > >> > my link.xn as follow: > >> > > >> > OUTPUT_ARCH(mips) > >> > ENTRY(brec_flash_entry) > >> > SECTIONS > >> > { > >> > .text 0xa2000000 : > >> > >> Use > >> > >> . = 0xa2000000; > >> .text : > >> > >> instead. "info ld" explains the subtle difference. > >> > >> > >> Thiemo > >> > > > > do you mean use > > . = 0xa2000000; > > .text : > > to replace > > .text 0xa2000000 : > > ? > > i modify as that, and it still get the same message > > > > I think the problem is not with the linker, but in your use of objcopy > to convert your ELF file to a raw binary file. > > 1) What arguments are you giving to mipsel-linux-objcopy? i use objcopy as follow(the brec_flash is elf file) mipsel-linux-objcopy -O binary brec_flash brec_flash.bin > > 2) What is the output from mipsel-linux-objdump -h run on your > intermediate ELF object file? i use mipsel-linux-objdump -h brec_flash and get messages as follow brec_flash: file format elf32-tradlittlemips Sections: Idx Name Size VMA LMA File off Algn 0 .text 0000b140 72000000 72000000 00010000 2**4 CONTENTS, ALLOC, LOAD, READONLY, CODE 1 .data 00001080 7200b140 7200b140 0001b140 2**4 CONTENTS, ALLOC, LOAD, DATA 2 .sbss 00000010 7200c1c0 7200c1c0 0001c1c0 2**2 ALLOC 3 .bss 000008a0 7200c1d0 7200c1d0 0001c1c0 2**4 ALLOC 4 .reginfo 00000018 7200ca70 7200ca70 0001ca70 2**2 CONTENTS, ALLOC, LOAD, READONLY, DATA, LINK_ONCE_SAME_SIZE 5 .pdr 000011a0 00000000 00000000 0001ca88 2**2 CONTENTS, READONLY 6 .mdebug.abi32 00000000 00000000 00000000 0001dc28 2**0 CONTENTS, READONLY 7 .comment 000000ea 00000000 00000000 0001dc28 2**0 CONTENTS, READONLY 8 .rodata 00000190 000000f0 000000f0 000000f0 2**4 CONTENTS, ALLOC, LOAD, READONLY, DATA 9 .rodata.str1.4 000005fe 00000280 00000280 00000280 2**2 CONTENTS, ALLOC, LOAD, READONLY, DATA > > > Nigel > > -- > Nigel Stephens e. nigel@mips.com > MIPS Technologies p. +44 1223 203110 > Building 7200 f. +44 1223 203181 > Cambridge Research Park m. +44 7976 686470 > Beach Road, Waterbeach w. http://www.mips.com > Cambridge CB5 9TL, UK > > From zzh.hust@gmail.com Fri Jun 2 04:50:39 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 02 Jun 2006 04:50:47 +0200 (CEST) Received: from ug-out-1314.google.com ([66.249.92.172]:61374 "EHLO ug-out-1314.google.com") by ftp.linux-mips.org with ESMTP id S8126497AbWFBCuj (ORCPT ); Fri, 2 Jun 2006 04:50:39 +0200 Received: by ug-out-1314.google.com with SMTP id k3so399964ugf for ; Thu, 01 Jun 2006 19:50:35 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=S6d731p7kceQ9eBSauhBr8lHGz2rn8yZLHwXeb4oN3wGN0NiTtMosH5jQt3W1C/IoU6Ui66lE86s+cZZAKcP21Lr1b0/u23grhI+DPEqOJ5Tz5hXZsUax3aboofT1Xl+AQT5BklzVn2WFz1w7mkRtYpPB9+mLybL0boClQfPtLA= Received: by 10.67.106.3 with SMTP id i3mr339040ugm; Thu, 01 Jun 2006 19:50:35 -0700 (PDT) Received: by 10.66.241.4 with HTTP; Thu, 1 Jun 2006 19:50:35 -0700 (PDT) Message-ID: <50c9a2250606011950h7669c9a7w375e54cf513dcee@mail.gmail.com> Date: Fri, 2 Jun 2006 10:50:35 +0800 From: zhuzhenhua To: "Nigel Stephens" Subject: Re: BFD: Warning: Writing section `.text' to huge (ie negative) file offset 0xa1ffff10 Cc: "Thiemo Seufer" , linux-mips In-Reply-To: <50c9a2250606011749r7f89fbben2c61edd43c7ec0a6@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <50c9a2250605312319v7480f2el36d9c0a052c85d5f@mail.gmail.com> <20060601092413.GL1717@networkno.de> <50c9a2250606010356s63f6d6e7j255c77660d6f472a@mail.gmail.com> <447EE274.7060207@mips.com> <50c9a2250606011749r7f89fbben2c61edd43c7ec0a6@mail.gmail.com> Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11640 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: zzh.hust@gmail.com Precedence: bulk X-list: linux-mips On 6/2/06, zhuzhenhua wrote: > On 6/1/06, Nigel Stephens wrote: > > > > > > zhuzhenhua wrote: > > > On 6/1/06, Thiemo Seufer wrote: > > >> zhuzhenhua wrote: > > >> > i have write a code to link at 0xa2000000(uncached address) > > >> > but when link i get the error as > > >> > "BFD: Warning: Writing section `.text' to huge (ie negative) file > > >> > offset 0xa1ffff10. > > >> > BFD: Warning: Writing section `.data' to huge (ie negative) file > > >> > offset 0xa200b050. > > >> > BFD: Warning: Writing section `.reginfo' to huge (ie negative) file > > >> > offset 0xa200c980. > > >> > mipsel-linux-objcopy: /root/project/brec_flash/release/brec_flash.bin: > > >> > File truncated > > >> > make: *** [brec_flash] Error 1" > > >> > > > >> > my link.xn as follow: > > >> > > > >> > OUTPUT_ARCH(mips) > > >> > ENTRY(brec_flash_entry) > > >> > SECTIONS > > >> > { > > >> > .text 0xa2000000 : > > >> > > >> Use > > >> > > >> . = 0xa2000000; > > >> .text : > > >> > > >> instead. "info ld" explains the subtle difference. > > >> > > >> > > >> Thiemo > > >> > > > > > > do you mean use > > > . = 0xa2000000; > > > .text : > > > to replace > > > .text 0xa2000000 : > > > ? > > > i modify as that, and it still get the same message > > > > > > > I think the problem is not with the linker, but in your use of objcopy > > to convert your ELF file to a raw binary file. > > > > 1) What arguments are you giving to mipsel-linux-objcopy? > i use objcopy as follow(the brec_flash is elf file) > mipsel-linux-objcopy -O binary brec_flash brec_flash.bin > > > > 2) What is the output from mipsel-linux-objdump -h run on your > > intermediate ELF object file? > i use mipsel-linux-objdump -h brec_flash and get messages as follow > > > brec_flash: file format elf32-tradlittlemips > > Sections: > Idx Name Size VMA LMA File off Algn > 0 .text 0000b140 72000000 72000000 00010000 2**4 > CONTENTS, ALLOC, LOAD, READONLY, CODE > 1 .data 00001080 7200b140 7200b140 0001b140 2**4 > CONTENTS, ALLOC, LOAD, DATA > 2 .sbss 00000010 7200c1c0 7200c1c0 0001c1c0 2**2 > ALLOC > 3 .bss 000008a0 7200c1d0 7200c1d0 0001c1c0 2**4 > ALLOC > 4 .reginfo 00000018 7200ca70 7200ca70 0001ca70 2**2 > CONTENTS, ALLOC, LOAD, READONLY, DATA, LINK_ONCE_SAME_SIZE > 5 .pdr 000011a0 00000000 00000000 0001ca88 2**2 > CONTENTS, READONLY > 6 .mdebug.abi32 00000000 00000000 00000000 0001dc28 2**0 > CONTENTS, READONLY > 7 .comment 000000ea 00000000 00000000 0001dc28 2**0 > CONTENTS, READONLY > 8 .rodata 00000190 000000f0 000000f0 000000f0 2**4 > CONTENTS, ALLOC, LOAD, READONLY, DATA > 9 .rodata.str1.4 000005fe 00000280 00000280 00000280 2**2 > CONTENTS, ALLOC, LOAD, READONLY, DATA the 0x72xxxxxx should be 0xa2xxxxxx, because i can't pass by set 0xa2000000,so i change the .text to 0x72000000, and it can get the .bin correctly. > > > > > > > Nigel > > > > -- > > Nigel Stephens e. nigel@mips.com > > MIPS Technologies p. +44 1223 203110 > > Building 7200 f. +44 1223 203181 > > Cambridge Research Park m. +44 7976 686470 > > Beach Road, Waterbeach w. http://www.mips.com > > Cambridge CB5 9TL, UK > > > > > From mrv@corecom.co.kr Fri Jun 2 08:35:16 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 02 Jun 2006 08:35:24 +0200 (CEST) Received: from [220.76.242.187] ([220.76.242.187]:3773 "EHLO localhost.localdomain") by ftp.linux-mips.org with ESMTP id S8133383AbWFBGfQ (ORCPT ); Fri, 2 Jun 2006 08:35:16 +0200 Received: from mrv ([192.168.11.157]) by localhost.localdomain (8.12.8/8.12.8) with SMTP id k526arEE015823; Fri, 2 Jun 2006 15:36:57 +0900 Message-ID: <005b01c6860e$5e99ce00$9d0ba8c0@mrv> From: "Roman Mashak" To: Cc: "Raj Palani" , Subject: booting 64bit kernel on RM9150 Date: Fri, 2 Jun 2006 15:32:47 +0900 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="koi8-r"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 FL-Build: Fidolook 2002 (SL) 6.0.2800.86 - 14/6/2003 22:16:25 Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11641 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: mrv@corecom.co.kr Precedence: bulk X-list: linux-mips Hello, I succesfully compiled 2.6.12-rc3 (patched by PMC-sierra), but failed to boot it on Sequoia evaluation board. Firmware version is: PMON2000 1.9 (SEQUOIA-EB). What I understood is PMON can't deal with 64-bit images, that's why kernel image should be "objcopy'd" into ELF32 (so, result is two images: 64bit 'vmlinux' and 32bit 'vmlinux.32'). So upon booting 'vmlinux.32' - board gets hang up: Loading file: tftp://192.168.11.43/vmlinux.32 (elf) 0x80100000/2088944 + 0x80300000/774278 + 0x803bd086/139162(z) + 4044 syms- With best regards, Roman Mashak. E-mail: mrv@corecom.co.kr From yczhao@hhcn.com Fri Jun 2 09:16:26 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 02 Jun 2006 09:16:33 +0200 (CEST) Received: from mxvip4.hichina.com ([218.244.159.34]:323 "EHLO mxvip4.hichina.com") by ftp.linux-mips.org with ESMTP id S8133424AbWFBHQ0 (ORCPT ); Fri, 2 Jun 2006 09:16:26 +0200 Received: from 60.166.48.95 (HELO work99) (envelope-from yczhao@hhcn.com) by mxvip4.hichina.com (quarkmail-1.2.1) with ESMTP id S6384198AbWFBHQR for linux-mips@linux-mips.org; Fri, 2 Jun 2006 15:16:17 +0800 Date: Fri, 2 Jun 2006 15:16:09 +0800 From: "richard" To: "linux-mips" Subject: where I can find a crosscompiler for BCM1255 X-mailer: Foxmail 5.0 [cn] Mime-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: 7bit Message-ID: <1149232577$80806$99988841@yczhao@hhcn.com> Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11642 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: yczhao@hhcn.com Precedence: bulk X-list: linux-mips Hi all, I want to compile linux-2.6.15 on BCM1255 board, I download crosscompilers(sb1-elf-,mips-linux-) from broadcom website, but error occurs when compiling Do the compilers work for linux compiling? or I should download other versions of compiler for the kernel? And where? Thanks. From Thomas.Koeller@baslerweb.com Fri Jun 2 11:16:30 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 02 Jun 2006 11:16:42 +0200 (CEST) Received: from mail.baslerweb.com ([145.253.187.130]:4207 "EHLO mail.baslerweb.com") by ftp.linux-mips.org with ESMTP id S8133569AbWFBJQW convert rfc822-to-8bit (ORCPT ); Fri, 2 Jun 2006 11:16:22 +0200 Received: (from smtpd@127.0.0.1) by mail.baslerweb.com (8.13.4/8.13.4) id k52BFEsZ004337 for ; Fri, 2 Jun 2006 13:15:14 +0200 Received: from unknown [172.16.20.75] by gateway id /processing/kwwblL39; Fri Jun 02 13:15:14 2006 MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Fri, 2 Jun 2006 11:16:18 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Location of PCI setup code Thread-Index: AcaF1VkjPtksw6SASzWpstbbqfTi7wAT7ymQ From: "Koeller, T." To: X-SecurE-Mail-Gateway: Version: 5.00.3.1 (smtpd: 6.53.8.7) Date: 20060602111514Z Subject: RE: Location of PCI setup code Content-class: urn:content-classes:message Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 8BIT Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11643 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: Thomas.Koeller@baslerweb.com Precedence: bulk X-list: linux-mips > From: Ralf Baechle [mailto:ralf@linux-mips.org] > > On Thu, Jun 01, 2006 at 10:46:17PM +0200, Thomas Koeller wrote: > > > the PCI setup code for a platform is conventionally located > in arch/mips/pci. > > I fail to see the benefits of separating this particular > part of a platform's > > setup from the rest. The PCI setup code will in general > contain references to > > platform-specific information, such as the overall address > space layout, of > > which the PCI memory and I/O pages are a part. If the PCI > setup code were in > > the platform subdirectory, sharing this information by means of a > > platform-local header file would be easy. But with the PCI code in > > arch/mips/pci, this becomes more difficult. The platform > header could be > > located somewhere outside the platform's directory, maybe under > > 'include' (where?), or referenced via an ugly relative path like > > '../../vendor/platform/platform.h'. All this seems rather > clumsy to me. No > > other part of a platform's initialization is separated from > the rest in a > > similar way, so what is so special about PCI setup that it > cannot be in the > > platform directory, thereby avoiding all these annoyances? > > The per-platform PCI code used to live in the per-platform > directories. > It turned into a giant mess, very little code was being shared, it was > hard to uniformly perform any kind of modification or fixes - and more > of that kind of changes will be needed before the PCI codes really > shines. > > Ralf > So how am I supposed to deal with the issues mentioned? Should I duplicate the PCI-related platform definitions into arch/mips/pci? Scattering related information across several places is generally regarded as poor design, as it will make maintenance more difficult. Or should I resort to one of the methods I mentioned, or is there any other preferred/recommended way of dealing with this? tk ----------------------------------------------- Thomas Koeller, Software Development Basler Vision Technologies An der Strusbek 60-62 22926 Ahrensburg Germany Tel +49 (4102) 463-390 Fax +49 (4102) 463-46390 mailto:Thomas.Koeller@baslerweb.com http://www.baslerweb.com From ths@networkno.de Fri Jun 2 11:49:15 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 02 Jun 2006 11:49:23 +0200 (CEST) Received: from bender.bawue.de ([193.7.176.20]:4253 "HELO bender.bawue.de") by ftp.linux-mips.org with SMTP id S8133488AbWFBJtO (ORCPT ); Fri, 2 Jun 2006 11:49:14 +0200 Received: from lagash (88-106-172-197.dynamic.dsl.as9105.com [88.106.172.197]) (using TLSv1 with cipher DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by bender.bawue.de (Postfix) with ESMTP id 2F6834475F; Fri, 2 Jun 2006 11:49:01 +0200 (MEST) Received: from ths by lagash with local (Exim 4.62) (envelope-from ) id 1Fm6Gl-0003iO-KW; Fri, 02 Jun 2006 10:48:39 +0100 Date: Fri, 2 Jun 2006 10:48:39 +0100 From: Thiemo Seufer To: zhuzhenhua Cc: Nigel Stephens , linux-mips Subject: Re: BFD: Warning: Writing section `.text' to huge (ie negative) file offset 0xa1ffff10 Message-ID: <20060602094839.GA32544@networkno.de> References: <50c9a2250605312319v7480f2el36d9c0a052c85d5f@mail.gmail.com> <20060601092413.GL1717@networkno.de> <50c9a2250606010356s63f6d6e7j255c77660d6f472a@mail.gmail.com> <447EE274.7060207@mips.com> <50c9a2250606011749r7f89fbben2c61edd43c7ec0a6@mail.gmail.com> <50c9a2250606011950h7669c9a7w375e54cf513dcee@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <50c9a2250606011950h7669c9a7w375e54cf513dcee@mail.gmail.com> User-Agent: Mutt/1.5.11+cvs20060403 Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11644 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ths@networkno.de Precedence: bulk X-list: linux-mips zhuzhenhua wrote: [snip] > >Idx Name Size VMA LMA File off Algn > > 0 .text 0000b140 72000000 72000000 00010000 2**4 > > CONTENTS, ALLOC, LOAD, READONLY, CODE > > 1 .data 00001080 7200b140 7200b140 0001b140 2**4 > > CONTENTS, ALLOC, LOAD, DATA > > 2 .sbss 00000010 7200c1c0 7200c1c0 0001c1c0 2**2 > > ALLOC > > 3 .bss 000008a0 7200c1d0 7200c1d0 0001c1c0 2**4 > > ALLOC > > 4 .reginfo 00000018 7200ca70 7200ca70 0001ca70 2**2 > > CONTENTS, ALLOC, LOAD, READONLY, DATA, > > LINK_ONCE_SAME_SIZE > > 5 .pdr 000011a0 00000000 00000000 0001ca88 2**2 > > CONTENTS, READONLY > > 6 .mdebug.abi32 00000000 00000000 00000000 0001dc28 2**0 > > CONTENTS, READONLY > > 7 .comment 000000ea 00000000 00000000 0001dc28 2**0 > > CONTENTS, READONLY > > 8 .rodata 00000190 000000f0 000000f0 000000f0 2**4 > > CONTENTS, ALLOC, LOAD, READONLY, DATA > > 9 .rodata.str1.4 000005fe 00000280 00000280 00000280 2**2 > > CONTENTS, ALLOC, LOAD, READONLY, DATA > > the 0x72xxxxxx should be 0xa2xxxxxx, because i can't pass by set > 0xa2000000,so i change the .text to 0x72000000, and it can get the > .bin correctly. At some version the check for sign extensions was broken for MIPS binutils, in that case the workaround was to specify the full sign extension for 64 bit, that is 0xffffffffa0000000. Thiemo From nigel@mips.com Fri Jun 2 13:00:56 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 02 Jun 2006 13:01:04 +0200 (CEST) Received: from 209-232-97-206.ded.pacbell.net ([209.232.97.206]:23188 "EHLO dns0.mips.com") by ftp.linux-mips.org with ESMTP id S8133658AbWFBLA4 (ORCPT ); Fri, 2 Jun 2006 13:00:56 +0200 Received: from mercury.mips.com (sbcns-dmz [209.232.97.193]) by dns0.mips.com (8.12.11/8.12.11) with ESMTP id k52B0hVP016965; Fri, 2 Jun 2006 04:00:44 -0700 (PDT) Received: from ukservices1.mips.com (ukservices1 [192.168.192.240]) by mercury.mips.com (8.13.5/8.13.5) with ESMTP id k52B0hM4011356; Fri, 2 Jun 2006 04:00:44 -0700 (PDT) Received: from shoreditch-home.mips-uk.com ([172.20.192.99] helo=[127.0.0.1]) by ukservices1.mips.com with esmtp (Exim 3.36 #1 (Debian)) id 1Fm7OO-0003TN-00; Fri, 02 Jun 2006 12:00:36 +0100 Message-ID: <44801A59.5080508@mips.com> Date: Fri, 02 Jun 2006 12:00:41 +0100 From: Nigel Stephens User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: zhuzhenhua CC: Thiemo Seufer , linux-mips Subject: Re: BFD: Warning: Writing section `.text' to huge (ie negative) file offset 0xa1ffff10 References: <50c9a2250605312319v7480f2el36d9c0a052c85d5f@mail.gmail.com> <20060601092413.GL1717@networkno.de> <50c9a2250606010356s63f6d6e7j255c77660d6f472a@mail.gmail.com> <447EE274.7060207@mips.com> <50c9a2250606011749r7f89fbben2c61edd43c7ec0a6@mail.gmail.com> In-Reply-To: <50c9a2250606011749r7f89fbben2c61edd43c7ec0a6@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-MIPS-Technologies-UK-MailScanner: Found to be clean X-MIPS-Technologies-UK-MailScanner-From: nigel@mips.com X-Scanned-By: MIMEDefang 2.39 Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11645 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: nigel@mips.com Precedence: bulk X-list: linux-mips zhuzhenhua wrote: > >> >> I think the problem is not with the linker, but in your use of objcopy >> to convert your ELF file to a raw binary file. >> >> 1) What arguments are you giving to mipsel-linux-objcopy? > i use objcopy as follow(the brec_flash is elf file) > mipsel-linux-objcopy -O binary brec_flash brec_flash.bin >> >> 2) What is the output from mipsel-linux-objdump -h run on your >> intermediate ELF object file? > i use mipsel-linux-objdump -h brec_flash and get messages as follow > > > brec_flash: file format elf32-tradlittlemips > > Sections: > Idx Name Size VMA LMA File off Algn > 0 .text 0000b140 72000000 72000000 00010000 2**4 > CONTENTS, ALLOC, LOAD, READONLY, CODE > 1 .data 00001080 7200b140 7200b140 0001b140 2**4 > CONTENTS, ALLOC, LOAD, DATA > 2 .sbss 00000010 7200c1c0 7200c1c0 0001c1c0 2**2 > ALLOC > 3 .bss 000008a0 7200c1d0 7200c1d0 0001c1c0 2**4 > ALLOC > 4 .reginfo 00000018 7200ca70 7200ca70 0001ca70 2**2 > CONTENTS, ALLOC, LOAD, READONLY, DATA, > LINK_ONCE_SAME_SIZE > 5 .pdr 000011a0 00000000 00000000 0001ca88 2**2 > CONTENTS, READONLY > 6 .mdebug.abi32 00000000 00000000 00000000 0001dc28 2**0 > CONTENTS, READONLY > 7 .comment 000000ea 00000000 00000000 0001dc28 2**0 > CONTENTS, READONLY > 8 .rodata 00000190 000000f0 000000f0 000000f0 2**4 > CONTENTS, ALLOC, LOAD, READONLY, DATA > 9 .rodata.str1.4 000005fe 00000280 00000280 00000280 2**2 > CONTENTS, ALLOC, LOAD, READONLY, DATA OK. I think that the final .rodata.str1.4 section is causing your problem because the offset between its load address and the other section is huge, causing "objcopy -O binary" to generate a huge file. This is a new section generated by gcc 3.x and above to hold mergeable constant data. Try changing the line in your linker script which (I'm guessing here) probably looks like this: *(.rodata) to: *(.rodata) *(.rodata.*) Nigel From nigel@mips.com Fri Jun 2 13:12:12 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 02 Jun 2006 13:12:19 +0200 (CEST) Received: from 209-232-97-206.ded.pacbell.net ([209.232.97.206]:29844 "EHLO dns0.mips.com") by ftp.linux-mips.org with ESMTP id S8133658AbWFBLMM (ORCPT ); Fri, 2 Jun 2006 13:12:12 +0200 Received: from mercury.mips.com (sbcns-dmz [209.232.97.193]) by dns0.mips.com (8.12.11/8.12.11) with ESMTP id k52BBv4O016975; Fri, 2 Jun 2006 04:11:58 -0700 (PDT) Received: from ukservices1.mips.com (ukservices1 [192.168.192.240]) by mercury.mips.com (8.13.5/8.13.5) with ESMTP id k52BBvV4011655; Fri, 2 Jun 2006 04:11:58 -0700 (PDT) Received: from shoreditch-home.mips-uk.com ([172.20.192.99] helo=[127.0.0.1]) by ukservices1.mips.com with esmtp (Exim 3.36 #1 (Debian)) id 1Fm7ZJ-0003rb-00; Fri, 02 Jun 2006 12:11:53 +0100 Message-ID: <44801CFF.1010400@mips.com> Date: Fri, 02 Jun 2006 12:11:59 +0100 From: Nigel Stephens User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: zhuzhenhua CC: Thiemo Seufer , linux-mips Subject: Re: BFD: Warning: Writing section `.text' to huge (ie negative) file offset 0xa1ffff10 References: <50c9a2250605312319v7480f2el36d9c0a052c85d5f@mail.gmail.com> <20060601092413.GL1717@networkno.de> <50c9a2250606010356s63f6d6e7j255c77660d6f472a@mail.gmail.com> <447EE274.7060207@mips.com> <50c9a2250606011749r7f89fbben2c61edd43c7ec0a6@mail.gmail.com> <44801A59.5080508@mips.com> In-Reply-To: <44801A59.5080508@mips.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-MIPS-Technologies-UK-MailScanner: Found to be clean X-MIPS-Technologies-UK-MailScanner-From: nigel@mips.com X-Scanned-By: MIMEDefang 2.39 Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11646 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: nigel@mips.com Precedence: bulk X-list: linux-mips Nigel Stephens wrote: > >> >> 8 .rodata 00000190 000000f0 000000f0 000000f0 2**4 >> CONTENTS, ALLOC, LOAD, READONLY, DATA >> 9 .rodata.str1.4 000005fe 00000280 00000280 00000280 2**2 >> CONTENTS, ALLOC, LOAD, READONLY, DATA > > OK. I think that the final .rodata.str1.4 section is causing your > problem because the offset between its load address and the other > section is huge, causing "objcopy -O binary" to generate a huge file. > This is a new section generated by gcc 3.x and above to hold mergeable > constant data. Try changing the line in your linker script which (I'm > guessing here) probably looks like this: > > *(.rodata) > > to: > > *(.rodata) *(.rodata.*) > I failed to spot that .rodata also has a "bad" load address. So it looks like .rodata also isn't correctly handled in your linker script. Nigel From art@sigrand.ru Fri Jun 2 14:58:08 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 02 Jun 2006 14:58:16 +0200 (CEST) Received: from sigrand.ru ([80.66.88.167]:15820 "HELO mail.sigrand.com") by ftp.linux-mips.org with SMTP id S8133814AbWFBM6H (ORCPT ); Fri, 2 Jun 2006 14:58:07 +0200 Received: from develop (unknown [192.168.2.238]) by mail.sigrand.com (Postfix) with ESMTP id EC41212A002C; Fri, 2 Jun 2006 19:58:04 +0700 (NOVST) Date: Fri, 2 Jun 2006 19:58:08 +0700 From: art X-Mailer: The Bat! (v1.38e) S/N A1D26E39 / Educational Reply-To: art Organization: Sigrand LLC X-Priority: 3 (Normal) Message-ID: <2832.060602@sigrand.ru> To: "Maciej W. Rozycki" Cc: linux-mips@linux-mips.org Subject: Re[4]: Problem with TLB mcheck! In-reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11647 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: art@sigrand.ru Precedence: bulk X-list: linux-mips Hello Maciej, Friday, June 02, 2006, 7:27:18 PM, you wrote: MWR> Hello Art, >> I was inattentive - you told about not my patch! Now I'am no use this! >> So DON'T tell me more about this :), sorry for my mistake. >> >> And about latest kernel version: >> 1. I think this problem is in memory management subsystem (am I >> right?) >> 2. If 1 is right - then now I have latest memory management sybsystem, >> because I apply all TLB-related patches (only one Ralfs really). MWR> Wait, wait! Please start from the beginning: if you try the kernel as of MWR> the top of the tree at www.linux-mips.org, then can you still trigger the MWR> machine check or does the kernel work fine? If the former, then please MWR> send the dump of state produced. MWR> Maciej Yes machine check was still occuring with latest kernel (2.6.16 with patched mm subsystem - how I sed - I've searched gitweb to find all changes from 20 March (when 2.6.16 was released)). Then I start watching tlbex.c, because patch which was recomended (but irrelevant as you say - and you were wright!) make mcheck occuring not so often. So I make second changes : --- /home/artpol/router/buildroot/kernels/linux-2.6.16-old/arch/mips/mm/tlbex.c 2006-03-20 11:35:39.000000000 +0000 +++ tlbex.c 2006-05-31 16:57:58.000000000 +0000 @@ -838,6 +838,7 @@ break; case CPU_R4300: + case CPU_4KC: case CPU_5KC: case CPU_TX49XX: case CPU_AU1000: @@ -852,13 +853,12 @@ case CPU_R10000: case CPU_R12000: - case CPU_4KC: case CPU_SB1: case CPU_SB1A: case CPU_4KSC: case CPU_20KC: case CPU_25KF: - tlbw(p); + tlbw(p); break; case CPU_NEVADA: @@ -1260,7 +1260,7 @@ } Till that I have no machine check at all! -- Best regards, art mailto:art@sigrand.ru From art@sigrand.ru Fri Jun 2 15:26:14 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 02 Jun 2006 15:26:21 +0200 (CEST) Received: from sigrand.ru ([80.66.88.167]:24268 "HELO mail.sigrand.com") by ftp.linux-mips.org with SMTP id S8133409AbWFBN0O (ORCPT ); Fri, 2 Jun 2006 15:26:14 +0200 Received: from develop (unknown [192.168.2.238]) by mail.sigrand.com (Postfix) with ESMTP id A0B7512A0021 for ; Fri, 2 Jun 2006 20:26:12 +0700 (NOVST) Date: Fri, 2 Jun 2006 20:26:16 +0700 From: art X-Mailer: The Bat! (v1.38e) S/N A1D26E39 / Educational Reply-To: art Organization: Sigrand LLC X-Priority: 3 (Normal) Message-ID: <6851.060602@sigrand.ru> To: linux-mips@linux-mips.org Subject: Socket buffer allocation outside DMA-able memory Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11648 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: art@sigrand.ru Precedence: bulk X-list: linux-mips Hello all! I work with ADM5120 chip. it has embedded switch. Switch descriptor has 25-bit dma addres field - so addressible only 32Mb! My system has 64Mb memory. But I have to set 32Mb to make it work! I thought that setting DMA mask can help. So in /arch/mips/adm5120/setup.c i make: static struct platform_device adm5120hcd_device = { .name = "adm5120-hcd", .id = -1, .dev = { .dma_mask = &hcd_dmamask, .coherent_dma_mask = 0x01ffffff, }, .num_resources = ARRAY_SIZE(adm5120_hcd_resources), .resource = adm5120_hcd_resources, }; But It is wrong, because dev_alloc_skb dont know to which device it allocates buffer! How to tell kernel allocate skbuffers in less then 32Mb addrspace whet system has 64Mb? -- Best regards, art mailto:art@sigrand.ru From p.boddupalli@gmail.com Fri Jun 2 20:39:53 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 02 Jun 2006 20:40:06 +0200 (CEST) Received: from wx-out-0102.google.com ([66.249.82.194]:1634 "EHLO wx-out-0102.google.com") by ftp.linux-mips.org with ESMTP id S8133869AbWFBSjx (ORCPT ); Fri, 2 Jun 2006 20:39:53 +0200 Received: by wx-out-0102.google.com with SMTP id t5so428867wxc for ; Fri, 02 Jun 2006 11:39:52 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:sender:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition:x-google-sender-auth; b=YXP9Qd7VY/PQdKOxuAF1odYWuePtS9XkI7KpA/SiWbKdasacF8nvcI5g5QW96pW2hiIkAxcDZ/0R8mSp9OhDTPr0HkejN1h3zZ4S4qLWUAbQYAAeI9w5ToYXiRizb0lI15eYVErfanenviLrH33CUHkYbSm1vK+UtM3AesvpwwY= Received: by 10.70.89.7 with SMTP id m7mr2770168wxb; Fri, 02 Jun 2006 11:39:52 -0700 (PDT) Received: by 10.70.73.1 with HTTP; Fri, 2 Jun 2006 11:39:52 -0700 (PDT) Message-ID: Date: Fri, 2 Jun 2006 11:39:52 -0700 From: "Prasad Boddupalli" To: linux-mips@linux-mips.org Subject: replacing synthesized tlb handlers with older ones MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Google-Sender-Auth: 8800841dd708f49b Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11649 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: bprasad@cs.arizona.edu Precedence: bulk X-list: linux-mips Hi, To embed some additional functionality in the tlb refill handler, I replaced the synthesized refill handlers in 2.6.16 linux with those from 2.6.6 (for example tlb-r4k.S under arch/mips/mm-32). Everything seem ok when I bring up one CPU, but causes unrecoverable exceptions in the kernel when I bring up multiple CPUs. I explored if that could be because of unflushed icaches on other CPUs. but that doesn't seem to be the case. Have anyone run into similar problem ? thank you, Prasad. From wilson@specifix.com Fri Jun 2 21:01:39 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 02 Jun 2006 21:01:53 +0200 (CEST) Received: from w099.z064220152.sjc-ca.dsl.cnc.net ([64.220.152.99]:63935 "HELO duck.specifix.com") by ftp.linux-mips.org with SMTP id S8133877AbWFBTBj (ORCPT ); Fri, 2 Jun 2006 21:01:39 +0200 Received: from [127.0.0.1] (duck.corp.specifix.com [192.168.1.1]) by duck.specifix.com (Postfix) with ESMTP id 22A75FC5E; Fri, 2 Jun 2006 12:01:24 -0700 (PDT) Subject: Re: where I can find a crosscompiler for BCM1255 From: James E Wilson To: richard Cc: linux-mips In-Reply-To: <1149232577$80806$99988841@yczhao@hhcn.com> References: <1149232577$80806$99988841@yczhao@hhcn.com> Content-Type: text/plain Message-Id: <1149274883.17016.6.camel@aretha.corp.specifix.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Fri, 02 Jun 2006 12:01:24 -0700 Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11650 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: wilson@specifix.com Precedence: bulk X-list: linux-mips On Fri, 2006-06-02 at 00:16, richard wrote: > I download crosscompilers(sb1-elf-,mips-linux-) from broadcom website, but error occurs when compiling We can't help you unless you specify exactly what the error was, and exactly what command you typed that generated the error. If this was a kernel compilation problem, you may need to specify the kernel configuration used. By the way, there is a default kernel config that you should start with, and then modify as necessary. It is in arch/mips/configs in the sb1250-swarm_defconfigs file. > Do the compilers work for linux compiling? The sb1-elf toolchain will not work for compiling linux. The mips-linux toolchain will work for compiling linux. However, because of interdependencies between the linux kernel and gcc, certain gcc versions may be required for compiling certain linux kernel versions. > or I should download other versions of compiler for the kernel? And where? There is some useful info in the wiki about this. http://www.linux-mips.org/wiki/Toolchains You can always start with FSF releases if you are willing to build the toolchains yourself. -- Jim Wilson, GNU Tools Support, http://www.specifix.com From kevink@mips.com Fri Jun 2 21:09:18 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 02 Jun 2006 21:09:29 +0200 (CEST) Received: from 209-232-97-206.ded.pacbell.net ([209.232.97.206]:63644 "EHLO dns0.mips.com") by ftp.linux-mips.org with ESMTP id S8133865AbWFBTJS (ORCPT ); Fri, 2 Jun 2006 21:09:18 +0200 Received: from mercury.mips.com (sbcns-dmz [209.232.97.193]) by dns0.mips.com (8.12.11/8.12.11) with ESMTP id k52J8ucQ018137; Fri, 2 Jun 2006 12:09:02 -0700 (PDT) Received: from grendel (grendel [192.168.236.16]) by mercury.mips.com (8.13.5/8.13.5) with SMTP id k52J8t6E020955; Fri, 2 Jun 2006 12:08:55 -0700 (PDT) Message-ID: <01b401c68678$98199a10$10eca8c0@grendel> From: "Kevin D. Kissell" To: "Prasad Boddupalli" , References: Subject: Re: replacing synthesized tlb handlers with older ones Date: Fri, 2 Jun 2006 21:13:11 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1807 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1807 X-Scanned-By: MIMEDefang 2.39 Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11651 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: kevink@mips.com Precedence: bulk X-list: linux-mips The TLB refill handler behavior for 1 CPU is fundamentally different than for SMP. In the uniprocessor case, the page table origin is implicit, whereas in SMP it needs to be indexed by some per-CPU value, typically maintained in the Context register. Pre-synthesed kernels set up up so that the Context value would be shifted left 23 bits, then right by 2 bits, to generate an offset. The newer system eliminates the right shift by ensuring that the CPU index is stored in a pre-scaled form, and that bits 23 and 24 are zero. So you can't just drop the old code into the newer kernel, unless you also change the setup of Context. A single CPU would work, because 0 == 0, otherwise... Try nuking those right shifts. Regards, Kevin K. ----- Original Message ----- From: "Prasad Boddupalli" To: Sent: Friday, June 02, 2006 8:39 PM Subject: replacing synthesized tlb handlers with older ones > Hi, > > To embed some additional functionality in the tlb refill handler, I > replaced the synthesized refill handlers in 2.6.16 linux with those > from 2.6.6 (for example tlb-r4k.S under arch/mips/mm-32). Everything > seem ok when I bring up one CPU, but causes unrecoverable exceptions > in the kernel when I bring up multiple CPUs. I explored if that could > be because of unflushed icaches on other CPUs. but that doesn't seem > to be the case. > > Have anyone run into similar problem ? > > thank you, > Prasad. > > From sshtylyov@ru.mvista.com Fri Jun 2 23:21:22 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 02 Jun 2006 23:21:37 +0200 (CEST) Received: from rtsoft2.corbina.net ([85.21.88.2]:36804 "HELO mail.dev.rtsoft.ru") by ftp.linux-mips.org with SMTP id S8133865AbWFBVVW (ORCPT ); Fri, 2 Jun 2006 23:21:22 +0200 Received: (qmail 23058 invoked from network); 3 Jun 2006 01:30:02 -0000 Received: from wasted.dev.rtsoft.ru (HELO ?192.168.1.248?) (192.168.1.248) by mail.dev.rtsoft.ru with SMTP; 3 Jun 2006 01:30:02 -0000 Message-ID: <4480AB90.8020203@ru.mvista.com> Date: Sat, 03 Jun 2006 01:20:16 +0400 From: Sergei Shtylyov Organization: MontaVista Software Inc. User-Agent: Mozilla/5.0 (X11; U; Linux i686; rv:1.7.2) Gecko/20040803 X-Accept-Language: ru, en-us, en-gb MIME-Version: 1.0 To: Linux-MIPS CC: Manish Lachwani , Ralf Baechle , Jordan Crouse Subject: [PATCH] arch/mips/au1000/common/time.c cleanup (take 2) References: <436FB625.2000302@ru.mvista.com> In-Reply-To: <436FB625.2000302@ru.mvista.com> Content-Type: multipart/mixed; boundary="------------080908020005010903040001" Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11652 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: sshtylyov@ru.mvista.com Precedence: bulk X-list: linux-mips This is a multi-part message in MIME format. --------------080908020005010903040001 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Au1xx0 CPU counter ticks at the full CPU clock speed, not at the halved one -- this is not an issue with the current kernel since Alchemy uses its own timer handler here which pays no attention to mips_hpt_frequency. Additionally, mark au1xxx_timer_setup() __init because it is, get rid of unneeded externs (note that (*do_gettimeoffset)() is already declared by ) and an unused variable, and kill some whitespace... Signed-off-by: Sergei Shtylyov --------------080908020005010903040001 Content-Type: text/plain; name="Au1xx0-fix-counter-frequency.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="Au1xx0-fix-counter-frequency.patch" Index: linux-mips/arch/mips/au1000/common/time.c =================================================================== --- linux-mips.orig/arch/mips/au1000/common/time.c +++ linux-mips/arch/mips/au1000/common/time.c @@ -50,10 +50,6 @@ #include #include -extern void do_softirq(void); -extern volatile unsigned long wall_jiffies; -unsigned long missed_heart_beats = 0; - static unsigned long r4k_offset; /* Amount to increment compare reg each time */ static unsigned long r4k_cur; /* What counter should be at next timer irq */ int no_au1xxx_32khz; @@ -287,7 +283,6 @@ unsigned long cal_r4koff(void) #else cpu_speed = (au_readl(SYS_CPUPLL) & 0x0000003f) * AU1000_SRC_CLK; - count = cpu_speed / 2; #endif } else { @@ -296,10 +291,9 @@ unsigned long cal_r4koff(void) * NOTE: some old silicon doesn't allow reading the PLL. */ cpu_speed = (au_readl(SYS_CPUPLL) & 0x0000003f) * AU1000_SRC_CLK; - count = cpu_speed / 2; no_au1xxx_32khz = 1; } - mips_hpt_frequency = count; + mips_hpt_frequency = cpu_speed; // Equation: Baudrate = CPU / (SD * 2 * CLKDIV * 16) set_au1x00_uart_baud_base(cpu_speed / (2 * ((int)(au_readl(SYS_POWERCTRL)&0x03) + 2) * 16)); spin_unlock_irqrestore(&time_lock, flags); @@ -388,10 +382,9 @@ static unsigned long do_fast_pm_gettimeo } #endif -void au1xxx_timer_setup(struct irqaction *irq) +void __init au1xxx_timer_setup(struct irqaction *irq) { - unsigned int est_freq; - extern unsigned long (*do_gettimeoffset)(void); + unsigned int est_freq; printk("calculating r4koff... "); r4k_offset = cal_r4koff(); --------------080908020005010903040001-- From Rajesh_Palani@pmc-sierra.com Sat Jun 3 01:28:42 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 03 Jun 2006 01:28:53 +0200 (CEST) Received: from father.pmc-sierra.com ([216.241.224.13]:56503 "HELO father.pmc-sierra.bc.ca") by ftp.linux-mips.org with SMTP id S8133809AbWFBX2m (ORCPT ); Sat, 3 Jun 2006 01:28:42 +0200 Received: (qmail 12393 invoked by uid 101); 2 Jun 2006 23:28:30 -0000 Received: from unknown (HELO ogmios.pmc-sierra.bc.ca) (216.241.226.59) by father.pmc-sierra.com with SMTP; 2 Jun 2006 23:28:30 -0000 Received: from bby1exi01.pmc_nt.nt.pmc-sierra.bc.ca (bby1exi01.pmc-sierra.bc.ca [216.241.231.251]) by ogmios.pmc-sierra.bc.ca (8.13.3/8.12.7) with ESMTP id k52NSPjB012580; Fri, 2 Jun 2006 16:28:25 -0700 Received: by bby1exi01.pmc-sierra.bc.ca with Internet Mail Service (5.5.2656.59) id ; Fri, 2 Jun 2006 16:28:24 -0700 Message-ID: <478F19F21671F04298A2116393EEC3D5274123@sjc1exm08.pmc_nt.nt.pmc-sierra.bc.ca> From: Raj Palani To: Roman Mashak , linux-mips@linux-mips.org Cc: Kiran Thota Subject: RE: booting 64bit kernel on RM9150 Date: Fri, 2 Jun 2006 16:28:17 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11653 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: Rajesh_Palani@pmc-sierra.com Precedence: bulk X-list: linux-mips Hi Roman, The patch for 64-bit support for Sequoia would follow the patch for the base support for Sequoia in the Linux/MIPS tree. -Raj > -----Original Message----- > From: Roman Mashak [mailto:mrv@corecom.co.kr] > Sent: Thursday, June 01, 2006 11:33 PM > To: linux-mips@linux-mips.org > Cc: Raj Palani; Kiran Thota > Subject: booting 64bit kernel on RM9150 > > Hello, > > I succesfully compiled 2.6.12-rc3 (patched by PMC-sierra), > but failed to boot it on Sequoia evaluation board. Firmware > version is: PMON2000 1.9 (SEQUOIA-EB). > > What I understood is PMON can't deal with 64-bit images, > that's why kernel image should be "objcopy'd" into ELF32 (so, > result is two images: 64bit 'vmlinux' and 32bit > 'vmlinux.32'). So upon booting 'vmlinux.32' - board gets hang up: > > Loading file: tftp://192.168.11.43/vmlinux.32 (elf) > 0x80100000/2088944 + 0x80300000/774278 + 0x803bd086/139162(z) > + 4044 syms- > > > With best regards, Roman Mashak. E-mail: mrv@corecom.co.kr > > From mrv@corecom.co.kr Sat Jun 3 02:23:40 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 03 Jun 2006 02:23:50 +0200 (CEST) Received: from [220.76.242.187] ([220.76.242.187]:33666 "EHLO localhost.localdomain") by ftp.linux-mips.org with ESMTP id S8133809AbWFCAXk (ORCPT ); Sat, 3 Jun 2006 02:23:40 +0200 Received: from mrv ([192.168.11.157]) by localhost.localdomain (8.12.8/8.12.8) with SMTP id k530PZEE026645; Sat, 3 Jun 2006 09:25:41 +0900 Message-ID: <000101c686a3$a9764710$9d0ba8c0@mrv> From: "Roman Mashak" To: Cc: "Raj Palani" References: <478F19F21671F04298A2116393EEC3D5274123@sjc1exm08.pmc_nt.nt.pmc-sierra.bc.ca> Subject: Re: booting 64bit kernel on RM9150 Date: Sat, 3 Jun 2006 09:21:29 +0900 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="koi8-r"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 FL-Build: Fidolook 2002 (SL) 6.0.2800.86 - 14/6/2003 22:16:25 Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11654 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: mrv@corecom.co.kr Precedence: bulk X-list: linux-mips Hello, Raj! You wrote to "Roman Mashak" ; on Fri, 2 Jun 2006 16:28:17 -0700 : RP> The patch for 64-bit support for Sequoia would follow the patch for RP> the base support for Sequoia in the Linux/MIPS tree. Are you saying the kernel 2.6.12-rc3_L002 located on ftp.pmc-sierra.com doesn't support 64bit properly? I used for experiments that kernel and default config file for 64bit support provided with the kernel. It boots up eventually and crashes: TCP established hash table entries: 16384 (order: 5, 131072 bytes) TCP bind hash table entries: 16384 (order: 5, 131072 bytes) TCP: Hash tables configured (established 16384 bind 16384) NET: Registered protocol family 1 CPU 0 Unable to handle kernel paging request at virtual address 00000000ff048060, epc == ffffffff802332f8, ra == ffffffff80159eb4 Oops in arch/mips/mm/fault.c::do_page_fault, line 167[#1]: Cpu 0 $ 0 : 0000000000000000 ffffffffff050000 ffffffff802332a8 00000000ff050000 $ 4 : 0000000000000005 980000000178c000 9800000001487d50 000000000000002c $ 8 : 980000000178c000 9800000001461800 0000000000100000 000000000023fc00 $12 : 0000000000002000 0000000000000000 ffffffff9400a0e0 98000000003e8e00 $16 : 980000000178c000 0000000000000000 9800000001487d50 0000000000000000 $20 : ffffffff940080e0 0000000000000000 0000000000000000 0000000000000000 $24 : 98000000003e8e10 0000000000000001 $28 : 9800000001484000 9800000001487c90 0000000000000000 ffffffff80159eb4 Hi : 000000000000348f Lo : 5c28f5c28fab0000 epc : ffffffff802332f8 msp85x0_ge_sequoia_int_handler+0x50/0x2e0 Not tainted ra : ffffffff80159eb4 handle_IRQ_event+0x6c/0xe8 Status: 940080e2 KX SX UX KERNEL EXL Cause : 00002008 BadVA : 00000000ff048060 PrId : 000034c1 Modules linked in: Process swapper (pid: 1, threadinfo=9800000001484000, task=98000000014816b8) Stack : 980000000fddc940 0000000000000000 9800000001487d50 0000000000000005 0000000000000001 0000000000000000 ffffffff80159eb4 0000000000000001 ffffffff80345140 0000000000000005 980000000fddc940 9800000001487d50 fffffffffffffffb 980000000178c000 ffffffff8015a094 ffffffff80107098 ffffffff80345140 980000000fddc940 0000000000000005 ffffffff9400a0e1 0000000000000000 ffffffff801036bc ffffffff80100e70 ffffffff803c5ae0 0000000000000000 ffffffff9400a0e0 0000000000000000 0000000000002000 0000000000000005 ffffffff9400a0e0 0000000000000000 000000000000002c 980000000178c000 9800000001461800 0000000000100000 000000000023fc00 0000000000000020 ffffffff801f911c 0000000000100100 98000000003e8e00 ... Call Trace: [] handle_IRQ_event+0x6c/0xe8 [] __do_IRQ+0x164/0x1d0 [] timer_interrupt+0x298/0x470 [] do_IRQ+0x1c/0x38 [] ll_xdma_irq+0xc/0x14 [] memset_partial+0x38/0x60 [] memset_partial+0x48/0x60 [] setup_irq+0x108/0x1a8 [] setup_irq+0x120/0x1a8 [] msp85x0_ge_sequoia_int_handler+0x0/0x2e0 [] request_irq+0xac/0xf8 [] msp85x0_ge_open+0x78/0x130 [] msp85x0_ge_open+0x4c/0x130 [] dev_open+0x68/0xf0 [] dev_change_flags+0x90/0x188 [] ic_open_devs+0x328/0x558 [] create_proc_entry+0x58/0xf8 [] ip_auto_config+0xa8/0x598 [] do_initcalls+0x90/0x198 [] do_initcalls+0x90/0x198 [] init+0x5c/0x1e0 [] kernel_thread_helper+0x10/0x18 [] kernel_thread_helper+0x0/0x18 Code: 64630001 0003183c 0061182d <8c638060> 3c040000 3c01803c 64840000 0004203c 0081202d Kernel panic - not syncing: Aiee, killing interrupt handler! With best regards, Roman Mashak. E-mail: mrv@corecom.co.kr From mrv@corecom.co.kr Sat Jun 3 05:39:12 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 03 Jun 2006 05:39:25 +0200 (CEST) Received: from [220.76.242.187] ([220.76.242.187]:57493 "EHLO localhost.localdomain") by ftp.linux-mips.org with ESMTP id S8133349AbWFCDjM (ORCPT ); Sat, 3 Jun 2006 05:39:12 +0200 Received: from mrv ([192.168.11.157]) by localhost.localdomain (8.12.8/8.12.8) with SMTP id k533f8EE029218; Sat, 3 Jun 2006 12:41:12 +0900 Message-ID: <000701c686be$fc1ac980$9d0ba8c0@mrv> From: "Roman Mashak" To: Cc: "Raj Palani" Subject: Tg3 driver problem on 2.6.12-rc3 (Sequoia) Date: Sat, 3 Jun 2006 12:37:02 +0900 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="koi8-r"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 FL-Build: Fidolook 2002 (SL) 6.0.2800.86 - 14/6/2003 22:16:25 Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11655 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: mrv@corecom.co.kr Precedence: bulk X-list: linux-mips Hello, a few days ago I was asking about bcm5700 driver problems and I got recommendations to use tg3 driver shipped with kernel. I did it and faced serious issues. Here's the story. 1) took 2.6.12-rc_L002 patched by PMC-sierra and compiled in 32bit mode 2) compiled tg3 driver as module 3) booted Sequoia board with this kernel 4) set up bridge between one of on-board interface (Titan GE) and Broadcom external NIC, get mysterious warning: bridge: can't decode speed from eth2: 0 eth2 is Broadcom interface 5) at this stage I connect Sequoia's GE interfaces to SmartBit gigabit interfaces, to measure throughput between two gigabit links in bridge mode. So, both interfaces are working well (I can ping SmartBit and vice versa). But I traffic's coming only in one direction and never through the bridge, so 'brctl showmacs br0' always show only one SmartBit MAC address learned. I configured bridge accroding to documentation (I made sure bridge is enabled in kernel): #brctl addbr br0 #brctl addif br0 eth1 #titan GE #brctl addif br0 eth2 #broadcom #ifconfig eth1 0.0.0.0 up #ifconfig eth2 0.0.0.0 up #ifconfig eth1 0.0.0.0 up #ifconfig br0 0.0.0.0 up Has anybody observed the same behavior? Thanks for any help! With best regards, Roman Mashak. E-mail: mrv@corecom.co.kr From zzh.hust@gmail.com Sat Jun 3 06:36:33 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 03 Jun 2006 06:36:42 +0200 (CEST) Received: from ug-out-1314.google.com ([66.249.92.171]:53553 "EHLO ug-out-1314.google.com") by ftp.linux-mips.org with ESMTP id S8133360AbWFCEgd (ORCPT ); Sat, 3 Jun 2006 06:36:33 +0200 Received: by ug-out-1314.google.com with SMTP id k3so813836ugf for ; Fri, 02 Jun 2006 21:36:32 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=KqsGIpi41MpzYj3AdRimPCbCrNKsad5PliPVd33BR4FuFuCrVMNBCzMUoQqKWv419BQdlHkWPO/WtxjmOOaDYT7yO5QmitsXWumtxb0j+933S72QSBUb1KmjKhveikQZGr0L85GdY9x1cZ0lEoemPVixDbB7L0ZKr3SC53ty5gY= Received: by 10.66.250.17 with SMTP id x17mr1385327ugh; Fri, 02 Jun 2006 21:36:32 -0700 (PDT) Received: by 10.66.241.4 with HTTP; Fri, 2 Jun 2006 21:36:32 -0700 (PDT) Message-ID: <50c9a2250606022136o72b979bfh8c93fc4bc0d696fa@mail.gmail.com> Date: Sat, 3 Jun 2006 12:36:32 +0800 From: zhuzhenhua To: "Nigel Stephens" Subject: Re: BFD: Warning: Writing section `.text' to huge (ie negative) file offset 0xa1ffff10 Cc: "Thiemo Seufer" , linux-mips In-Reply-To: <44801CFF.1010400@mips.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <50c9a2250605312319v7480f2el36d9c0a052c85d5f@mail.gmail.com> <20060601092413.GL1717@networkno.de> <50c9a2250606010356s63f6d6e7j255c77660d6f472a@mail.gmail.com> <447EE274.7060207@mips.com> <50c9a2250606011749r7f89fbben2c61edd43c7ec0a6@mail.gmail.com> <44801A59.5080508@mips.com> <44801CFF.1010400@mips.com> Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11656 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: zzh.hust@gmail.com Precedence: bulk X-list: linux-mips On 6/2/06, Nigel Stephens wrote: > > > Nigel Stephens wrote: > > > >> > >> 8 .rodata 00000190 000000f0 000000f0 000000f0 2**4 > >> CONTENTS, ALLOC, LOAD, READONLY, DATA > >> 9 .rodata.str1.4 000005fe 00000280 00000280 00000280 2**2 > >> CONTENTS, ALLOC, LOAD, READONLY, DATA > > > > OK. I think that the final .rodata.str1.4 section is causing your > > problem because the offset between its load address and the other > > section is huge, causing "objcopy -O binary" to generate a huge file. > > This is a new section generated by gcc 3.x and above to hold mergeable > > constant data. Try changing the line in your linker script which (I'm > > guessing here) probably looks like this: > > > > *(.rodata) > > > > to: > > > > *(.rodata) *(.rodata.*) > > > > I failed to spot that .rodata also has a "bad" load address. So it looks > like .rodata also isn't correctly handled in your linker script. you are right, i do not handle it correctly, and now i fixed it and the objcopy run with out warning. > > Nigel > > > thanks for all above Best Regards zhuzhenhua From ralf@linux-mips.org Sun Jun 4 00:58:57 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 04 Jun 2006 00:59:05 +0200 (CEST) Received: from localhost.localdomain ([127.0.0.1]:19423 "EHLO bacchus.dhis.org") by ftp.linux-mips.org with ESMTP id S8133892AbWFCW65 (ORCPT ); Sun, 4 Jun 2006 00:58:57 +0200 Received: from denk.linux-mips.net (denk.linux-mips.net [127.0.0.1]) by bacchus.dhis.org (8.13.6/8.13.4) with ESMTP id k53Mwu4x002287; Sat, 3 Jun 2006 23:58:56 +0100 Received: (from ralf@localhost) by denk.linux-mips.net (8.13.6/8.13.6/Submit) id k53MwtgN002286; Sat, 3 Jun 2006 23:58:55 +0100 Date: Sat, 3 Jun 2006 23:58:55 +0100 From: Ralf Baechle To: gregkh@suse.de, linux-usb-devel@lists.sourceforge.net, dbrownell@users.sourceforge.net, linux-usb-devel@lists.sourceforge.net, linux-mips@linux-mips.org Subject: [PATCH] EHCI on non-Au1200 build fix Message-ID: <20060603225855.GA2234@linux-mips.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.1i Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11657 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ralf@linux-mips.org Precedence: bulk X-list: linux-mips Including ehci-au1xxx.c on a non-Au1200 Alchemy only to have it throw an error is stupid. diff --git a/drivers/usb/host/ehci-au1xxx.c b/drivers/usb/host/ehci-au1xxx.c index 63eadee..9315898 100644 --- a/drivers/usb/host/ehci-au1xxx.c +++ b/drivers/usb/host/ehci-au1xxx.c @@ -16,10 +16,6 @@ #include #include -#ifndef CONFIG_SOC_AU1200 -#error "this Alchemy chip doesn't have EHCI" -#else /* Au1200 */ - #define USB_HOST_CONFIG (USB_MSR_BASE + USB_MSR_MCFG) #define USB_MCFG_PFEN (1<<31) #define USB_MCFG_RDCOMB (1<<30) diff --git a/drivers/usb/host/ehci-hcd.c b/drivers/usb/host/ehci-hcd.c index 79f2d8b..c77e527 100644 --- a/drivers/usb/host/ehci-hcd.c +++ b/drivers/usb/host/ehci-hcd.c @@ -897,7 +897,7 @@ #include "ehci-fsl.c" #define EHCI_BUS_GLUED #endif -#ifdef CONFIG_SOC_AU1X00 +#ifdef CONFIG_SOC_AU1200 #include "ehci-au1xxx.c" #define EHCI_BUS_GLUED #endif From zzh.hust@gmail.com Sun Jun 4 08:05:55 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 04 Jun 2006 08:06:03 +0200 (CEST) Received: from ug-out-1314.google.com ([66.249.92.170]:26319 "EHLO ug-out-1314.google.com") by ftp.linux-mips.org with ESMTP id S8133515AbWFDGFz (ORCPT ); Sun, 4 Jun 2006 08:05:55 +0200 Received: by ug-out-1314.google.com with SMTP id k3so1049925ugf for ; Sat, 03 Jun 2006 23:05:55 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=HqQ6d2BleEleT8Ukz/90dNRwcOSXSWCPrwUCEtlOnTx53x5u1HWUsJW+6Ns5BCgft3nikr+fpDn7umbVRJxYeHzmSZKDzX3lLpR4xMCY6j+8tCuE1UOgdEWLB5BTOcfCAy7Kxbbb0jEDwVgsubPNo7QXLL0Etyd1JBJhIJVql8w= Received: by 10.67.101.10 with SMTP id d10mr2236692ugm; Sat, 03 Jun 2006 23:05:55 -0700 (PDT) Received: by 10.66.241.4 with HTTP; Sat, 3 Jun 2006 23:05:54 -0700 (PDT) Message-ID: <50c9a2250606032305t12dd44d5y78ec28cc6067fa66@mail.gmail.com> Date: Sun, 4 Jun 2006 14:05:54 +0800 From: zhuzhenhua To: linux-mips Subject: how to reused the initrd ram? MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11658 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: zzh.hust@gmail.com Precedence: bulk X-list: linux-mips my board has 64M sdram, when i boot nfs root, it show Mem total about 62M and if i boot initrd and then switch to nfs root, it show mem total about 54M,and freeramdisk does nothing to it. my kernel commandline is root=/dev/nfs init=/linuxrc rd_start=0x80a00000 rd_size=0x260000 ramdisk_size=8192 ip=bootp and in my initrd, the linuxrc is #!/bin/nash mount -t proc /proc /proc echo Mounting root filesystem mount -o nolock,rsize=1024,wsize=1024 --ro -t nfs 10.10.10.2:/root/nfsroot/rootfs /sysroot pivot_root /sysroot /sysroot/initrd umount /initrd/proc and in my nfs root, i type $umount initrd $freeramdisk /dev/ram0 it only flushed bufferd mem, and do nothing to the mem total. i wonder how to reused the initrd mem? BTW, if i change the kernel comandline to root=/dev/ram0 ... it will show messages as "Failed to execute /linuxrc. Attempting defaults... Kernel panic - not syncing: No init found. Try passing init= option to kernel" Thanks for any hints Best Regards zhuzhenhua From trix@specifix.com Sun Jun 4 18:19:35 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 04 Jun 2006 18:19:43 +0200 (CEST) Received: from w099.z064220152.sjc-ca.dsl.cnc.net ([64.220.152.99]:10955 "HELO duck.specifix.com") by ftp.linux-mips.org with SMTP id S8133863AbWFDQTf (ORCPT ); Sun, 4 Jun 2006 18:19:35 +0200 Received: from localhost.localdomain (duck.corp.specifix.com [192.168.1.1]) by duck.specifix.com (Postfix) with ESMTP id A5E1547DC; Sun, 4 Jun 2006 09:19:16 -0700 (PDT) Date: Sun, 04 Jun 2006 11:45:21 -0500 To: tbm@cyrius.com, jgarzik@pobox.com, netdev@vger.kernel.org, linux-mips@linux-mips.org, mark.e.mason@broadcom.com, "trix@specifix.com" Subject: PATCH SB1250 NAPI support References: <20060524125512.GO12089@deprecation.cyrius.com> <20060525133505.GH8746@deprecation.cyrius.com> From: "Tom Rix" Organization: specifix Content-Type: multipart/mixed; boundary=----------A8WtTPRxevcrr7Y0YoDYjf MIME-Version: 1.0 Message-ID: In-Reply-To: <20060525133505.GH8746@deprecation.cyrius.com> User-Agent: Opera M2/8.51 (Linux, build 1462) Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11659 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: trix@specifix.com Precedence: bulk X-list: linux-mips ------------A8WtTPRxevcrr7Y0YoDYjf Content-Type: text/plain; format=flowed; delsp=yes; charset=utf-8 Content-Transfer-Encoding: quoted-printable A while ago I submitted this patch for NAPI support for SB1250 / SB1480. I have tested it again on the recent (6/3/06) linux-mips kernel. Tom Below is the original posting. This patch adds NAPI support for the Broadcom Sibyte SB1xxx family. The changes are limited to adding a new config key SBMAC_NAPI to the drivers/ net/Kconfig and by adding the poll op and interrupt support to drivers/ net/sb1250-mac.c. This patch also has a fix to drivers/net/sb1250-mac.c, the dma descriptor table ptr is allocated, aligned and the aligned ptr is freed. If the ptr was not already aligned (usually is) then the free would not work of what was returned by the kmalloc. A variable was added to store the unaligned pointer so that it could be properly freed. I have tested this patch on a BCM91250A-SWARM Pass 2 / An. Mark Mason from Broadcom was very helpful and tested this patch on at least a 1480. Tom On Thu, 25 May 2006 08:35:05 -0500, Martin Michlmayr =20 wrote: > * Tom Rix [2006-05-25 08:06]: >> I am busy now but will get to it sometime. >> It will require retesting with the latest kernel source. >> Is there a particular maintainer(s) that I should cc on this patch? > > jgarzik@pobox.com > > He just reminded people that the merge window for 2.6.18 will open > soon (and that he's collecting patches for that already) so now would > be an excellent time. > > Thanks. --=20 Using Opera's revolutionary e-mail client: http://www.opera.com/mail/ ------------A8WtTPRxevcrr7Y0YoDYjf Content-Disposition: attachment; filename=mips-sb1250-mac-NAPI-3.patch Content-Type: application/octet-stream; name=mips-sb1250-mac-NAPI-3.patch Content-Transfer-Encoding: Base64 ZGlmZiAtcnVwIGEvZHJpdmVycy9uZXQvS2NvbmZpZyBiL2RyaXZlcnMvbmV0L0tj b25maWcKLS0tIGEvZHJpdmVycy9uZXQvS2NvbmZpZwkyMDA2LTAzLTA5IDA0OjI1 OjM4LjAwMDAwMDAwMCAtMDYwMAorKysgYi9kcml2ZXJzL25ldC9LY29uZmlnCTIw MDYtMDMtMDkgMDU6MzA6NDguMDAwMDAwMDAwIC0wNjAwCkBAIC0yMDA4LDEwICsy MDA4LDYgQEAgY29uZmlnIFI4MTY5X05BUEkKIAogCSAgSWYgaW4gZG91YnQsIHNh eSBOLgogCi1jb25maWcgTkVUX1NCMTI1MF9NQUMKLQl0cmlzdGF0ZSAiU0IxMjUw IEV0aGVybmV0IHN1cHBvcnQiCi0JZGVwZW5kcyBvbiBTSUJZVEVfU0IxeHh4X1NP QwotCiBjb25maWcgUjgxNjlfVkxBTgogCWJvb2wgIlZMQU4gc3VwcG9ydCIKIAlk ZXBlbmRzIG9uIFI4MTY5ICYmIFZMQU5fODAyMVEKQEAgLTIwMjEsNiArMjAxNywy NyBAQCBjb25maWcgUjgxNjlfVkxBTgogCSAgCiAJICBJZiBpbiBkb3VidCwgc2F5 IFkuCiAKK2NvbmZpZyBORVRfU0IxMjUwX01BQworCXRyaXN0YXRlICJTQjEyNTAg RXRoZXJuZXQgc3VwcG9ydCIKKwlkZXBlbmRzIG9uIFNJQllURV9TQjF4eHhfU09D CisKK2NvbmZpZyBTQk1BQ19OQVBJCisJYm9vbCAiVXNlIFJ4IFBvbGxpbmcgKE5B UEkpIChFWFBFUklNRU5UQUwpIgorCWRlcGVuZHMgb24gTkVUX1NCMTI1MF9NQUMg JiYgRVhQRVJJTUVOVEFMCisJaGVscAorCSAgTkFQSSBpcyBhIG5ldyBkcml2ZXIg QVBJIGRlc2lnbmVkIHRvIHJlZHVjZSBDUFUgYW5kIGludGVycnVwdCBsb2FkCisJ ICB3aGVuIHRoZSBkcml2ZXIgaXMgcmVjZWl2aW5nIGxvdHMgb2YgcGFja2V0cyBm cm9tIHRoZSBjYXJkLiBJdCBpcworCSAgc3RpbGwgc29tZXdoYXQgZXhwZXJpbWVu dGFsIGFuZCB0aHVzIG5vdCB5ZXQgZW5hYmxlZCBieSBkZWZhdWx0LgorCisJICBJ ZiB5b3VyIGVzdGltYXRlZCBSeCBsb2FkIGlzIDEwa3BwcyBvciBtb3JlLCBvciBp ZiB0aGUgY2FyZCB3aWxsIGJlCisJICBkZXBsb3llZCBvbiBwb3RlbnRpYWxseSB1 bmZyaWVuZGx5IG5ldHdvcmtzIChlLmcuIGluIGEgZmlyZXdhbGwpLAorCSAgdGhl biBzYXkgWSBoZXJlLgorCisJICBTZWUgPGZpbGU6RG9jdW1lbnRhdGlvbi9uZXR3 b3JraW5nL05BUElfSE9XVE8udHh0PiBmb3IgbW9yZQorCSAgaW5mb3JtYXRpb24u CisKKwkgIElmIGluIGRvdWJ0LCBzYXkgeS4KKwogY29uZmlnIFNJUzE5MAogCXRy aXN0YXRlICJTaVMxOTAvU2lTMTkxIGdpZ2FiaXQgZXRoZXJuZXQgc3VwcG9ydCIK IAlkZXBlbmRzIG9uIFBDSQpkaWZmIC1ydXAgYS9kcml2ZXJzL25ldC9zYjEyNTAt bWFjLmMgYi9kcml2ZXJzL25ldC9zYjEyNTAtbWFjLmMKLS0tIGEvZHJpdmVycy9u ZXQvc2IxMjUwLW1hYy5jCTIwMDYtMDMtMDkgMDQ6MjU6NDEuMDAwMDAwMDAwIC0w NjAwCisrKyBiL2RyaXZlcnMvbmV0L3NiMTI1MC1tYWMuYwkyMDA2LTAzLTA5IDA1 OjMwOjUyLjAwMDAwMDAwMCAtMDYwMApAQCAtMjA5LDYgKzIwOSw3IEBAIHR5cGVk ZWYgc3RydWN0IHNibWFjZG1hX3MgewogCSAqIFRoaXMgc3R1ZmYgaXMgZm9yIG1h aW50ZW5hbmNlIG9mIHRoZSByaW5nCiAJICovCiAKKwlzYmRtYWRzY3JfdCAgICAg KnNiZG1hX2RzY3J0YWJsZV91bmFsaWduZWQ7IAogCXNiZG1hZHNjcl90ICAgICAq c2JkbWFfZHNjcnRhYmxlOwkvKiBiYXNlIG9mIGRlc2NyaXB0b3IgdGFibGUgKi8K IAlzYmRtYWRzY3JfdCAgICAgKnNiZG1hX2RzY3J0YWJsZV9lbmQ7IC8qIGVuZCBv ZiBkZXNjcmlwdG9yIHRhYmxlICovCiAKQEAgLTI5MSw4ICsyOTIsOCBAQCBzdGF0 aWMgaW50IHNiZG1hX2FkZF9yY3ZidWZmZXIoc2JtYWNkbWFfCiBzdGF0aWMgaW50 IHNiZG1hX2FkZF90eGJ1ZmZlcihzYm1hY2RtYV90ICpkLHN0cnVjdCBza19idWZm ICptKTsKIHN0YXRpYyB2b2lkIHNiZG1hX2VtcHR5cmluZyhzYm1hY2RtYV90ICpk KTsKIHN0YXRpYyB2b2lkIHNiZG1hX2ZpbGxyaW5nKHNibWFjZG1hX3QgKmQpOwot c3RhdGljIHZvaWQgc2JkbWFfcnhfcHJvY2VzcyhzdHJ1Y3Qgc2JtYWNfc29mdGMg KnNjLHNibWFjZG1hX3QgKmQpOwotc3RhdGljIHZvaWQgc2JkbWFfdHhfcHJvY2Vz cyhzdHJ1Y3Qgc2JtYWNfc29mdGMgKnNjLHNibWFjZG1hX3QgKmQpOworc3RhdGlj IGludCBzYmRtYV9yeF9wcm9jZXNzKHN0cnVjdCBzYm1hY19zb2Z0YyAqc2Msc2Jt YWNkbWFfdCAqZCwgaW50IHBvbGwpOworc3RhdGljIHZvaWQgc2JkbWFfdHhfcHJv Y2VzcyhzdHJ1Y3Qgc2JtYWNfc29mdGMgKnNjLHNibWFjZG1hX3QgKmQsIGludCBw b2xsKTsKIHN0YXRpYyBpbnQgc2JtYWNfaW5pdGN0eChzdHJ1Y3Qgc2JtYWNfc29m dGMgKnMpOwogc3RhdGljIHZvaWQgc2JtYWNfY2hhbm5lbF9zdGFydChzdHJ1Y3Qg c2JtYWNfc29mdGMgKnMpOwogc3RhdGljIHZvaWQgc2JtYWNfY2hhbm5lbF9zdG9w KHN0cnVjdCBzYm1hY19zb2Z0YyAqcyk7CkBAIC0zMTMsNiArMzE0LDEwIEBAIHN0 YXRpYyBzdHJ1Y3QgbmV0X2RldmljZV9zdGF0cyAqc2JtYWNfZ2UKIHN0YXRpYyB2 b2lkIHNibWFjX3NldF9yeF9tb2RlKHN0cnVjdCBuZXRfZGV2aWNlICpkZXYpOwog c3RhdGljIGludCBzYm1hY19taWlfaW9jdGwoc3RydWN0IG5ldF9kZXZpY2UgKmRl diwgc3RydWN0IGlmcmVxICpycSwgaW50IGNtZCk7CiBzdGF0aWMgaW50IHNibWFj X2Nsb3NlKHN0cnVjdCBuZXRfZGV2aWNlICpkZXYpOworI2lmIGRlZmluZWQgKENP TkZJR19TQk1BQ19OQVBJKQorc3RhdGljIGludCBzYm1hY19wb2xsKHN0cnVjdCBu ZXRfZGV2aWNlICpwb2xsX2RldiwgaW50ICpidWRnZXQpOworI2VuZGlmCisKIHN0 YXRpYyBpbnQgc2JtYWNfbWlpX3BvbGwoc3RydWN0IHNibWFjX3NvZnRjICpzLGlu dCBub2lzeSk7CiBzdGF0aWMgaW50IHNibWFjX21paV9wcm9iZShzdHJ1Y3QgbmV0 X2RldmljZSAqZGV2KTsKIApAQCAtNzQwLDcgKzc0NSw3IEBAIHN0YXRpYyB2b2lk IHNiZG1hX2luaXRjdHgoc2JtYWNkbWFfdCAqZCwKIAogCWQtPnNiZG1hX21heGRl c2NyID0gbWF4ZGVzY3I7CiAKLQlkLT5zYmRtYV9kc2NydGFibGUgPSAoc2JkbWFk c2NyX3QgKikKKwlkLT5zYmRtYV9kc2NydGFibGVfdW5hbGlnbmVkID0gZC0+c2Jk bWFfZHNjcnRhYmxlID0gKHNiZG1hZHNjcl90ICopCiAJCWttYWxsb2MoKGQtPnNi ZG1hX21heGRlc2NyKzEpKnNpemVvZihzYmRtYWRzY3JfdCksIEdGUF9LRVJORUwp OwogCiAJLyoKQEAgLTc4Miw3ICs3ODcsNiBAQCBzdGF0aWMgdm9pZCBzYmRtYV9p bml0Y3R4KHNibWFjZG1hX3QgKmQsCiAJCWQtPnNiZG1hX2ludF90aW1lb3V0ID0g MDsKIAl9CiAjZW5kaWYKLQogfQogCiAvKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKgpA QCAtMTE1MCwxMyArMTE1NCwxNCBAQCBzdGF0aWMgdm9pZCBzYmRtYV9maWxscmlu ZyhzYm1hY2RtYV90ICpkCiAgKiAgCSAgIG5vdGhpbmcKICAqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKiogKi8KIAotc3RhdGljIHZvaWQgc2JkbWFfcnhfcHJvY2VzcyhzdHJ1 Y3Qgc2JtYWNfc29mdGMgKnNjLHNibWFjZG1hX3QgKmQpCitzdGF0aWMgaW50IHNi ZG1hX3J4X3Byb2Nlc3Moc3RydWN0IHNibWFjX3NvZnRjICpzYyxzYm1hY2RtYV90 ICpkLCBpbnQgcG9sbCkKIHsKIAlpbnQgY3VyaWR4OwogCWludCBod2lkeDsKIAlz YmRtYWRzY3JfdCAqZHNjOwogCXN0cnVjdCBza19idWZmICpzYjsKIAlpbnQgbGVu OworCWludCB3b3JrX2RvbmUgPSAwOwogCiAJZm9yICg7OykgewogCQkvKgpAQCAt MTIzNCw4ICsxMjM5LDE1IEBAIHN0YXRpYyB2b2lkIHNiZG1hX3J4X3Byb2Nlc3Mo c3RydWN0IHNibWEKIAkJCQkJCXNiLT5pcF9zdW1tZWQgPSBDSEVDS1NVTV9OT05F OwogCQkJCQl9CiAJCQkJfQotCisJCQkJCisjaWYgZGVmaW5lZChDT05GSUdfU0JN QUNfTkFQSSkKKwkJCQlpZiAoMCA9PSBwb2xsKQorCQkJCQluZXRpZl9yeChzYik7 CisJCQkJZWxzZQorCQkJCQluZXRpZl9yZWNlaXZlX3NrYihzYik7CisjZWxzZQog CQkJCW5ldGlmX3J4KHNiKTsKKyNlbmRpZgkJCQkKIAkJCX0KIAkJfSBlbHNlIHsK IAkJCS8qCkBAIC0xMjUyLDggKzEyNjQsOSBAQCBzdGF0aWMgdm9pZCBzYmRtYV9y eF9wcm9jZXNzKHN0cnVjdCBzYm1hCiAJCSAqLwogCiAJCWQtPnNiZG1hX3JlbXB0 ciA9IFNCRE1BX05FWFRCVUYoZCxzYmRtYV9yZW1wdHIpOwotCisJCXdvcmtfZG9u ZSsrOwogCX0KKwlyZXR1cm4gd29ya19kb25lOwogfQogCiAKQEAgLTEyNzUsMTUg KzEyODgsMjIgQEAgc3RhdGljIHZvaWQgc2JkbWFfcnhfcHJvY2VzcyhzdHJ1Y3Qg c2JtYQogICogIAkgICBub3RoaW5nCiAgKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqICov CiAKLXN0YXRpYyB2b2lkIHNiZG1hX3R4X3Byb2Nlc3Moc3RydWN0IHNibWFjX3Nv ZnRjICpzYyxzYm1hY2RtYV90ICpkKQorc3RhdGljIHZvaWQgc2JkbWFfdHhfcHJv Y2VzcyhzdHJ1Y3Qgc2JtYWNfc29mdGMgKnNjLHNibWFjZG1hX3QgKmQsIGludCBw b2xsKQogewogCWludCBjdXJpZHg7CiAJaW50IGh3aWR4OwogCXNiZG1hZHNjcl90 ICpkc2M7CiAJc3RydWN0IHNrX2J1ZmYgKnNiOwogCXVuc2lnbmVkIGxvbmcgZmxh Z3M7CisJaW50IHBhY2tldHNfaGFuZGxlZCA9IDA7CiAKIAlzcGluX2xvY2tfaXJx c2F2ZSgmKHNjLT5zYm1fbG9jayksIGZsYWdzKTsKKwkKKwlpZiAoZC0+c2JkbWFf cmVtcHRyID09IGQtPnNiZG1hX2FkZHB0cikKKwkJZ290byBlbmRfdW5sb2NrOwor CisJaHdpZHggPSAoaW50KSAoKChfX3Jhd19yZWFkcShkLT5zYmRtYV9jdXJkc2Ny KSAmIE1fRE1BX0NVUkRTQ1JfQUREUikgLQorCQkJZC0+c2JkbWFfZHNjcnRhYmxl X3BoeXMpIC8gc2l6ZW9mKHNiZG1hZHNjcl90KSk7CiAKIAlmb3IgKDs7KSB7CiAJ CS8qCkBAIC0xMjk4LDE1ICsxMzE4LDEyIEBAIHN0YXRpYyB2b2lkIHNiZG1hX3R4 X3Byb2Nlc3Moc3RydWN0IHNibWEKIAkJICovCiAKIAkJY3VyaWR4ID0gZC0+c2Jk bWFfcmVtcHRyIC0gZC0+c2JkbWFfZHNjcnRhYmxlOwotCQlod2lkeCA9IChpbnQp ICgoKF9fcmF3X3JlYWRxKGQtPnNiZG1hX2N1cmRzY3IpICYgTV9ETUFfQ1VSRFND Ul9BRERSKSAtCi0JCQkJZC0+c2JkbWFfZHNjcnRhYmxlX3BoeXMpIC8gc2l6ZW9m KHNiZG1hZHNjcl90KSk7CiAKIAkJLyoKIAkJICogSWYgdGhleSdyZSB0aGUgc2Ft ZSwgdGhhdCBtZWFucyB3ZSd2ZSBwcm9jZXNzZWQgYWxsCiAJCSAqIG9mIHRoZSBk ZXNjcmlwdG9ycyB1cCB0byAoYnV0IG5vdCBpbmNsdWRpbmcpIHRoZSBvbmUgdGhh dAogCQkgKiB0aGUgaGFyZHdhcmUgaXMgd29ya2luZyBvbiByaWdodCBub3cuCiAJ CSAqLwotCiAJCWlmIChjdXJpZHggPT0gaHdpZHgpCiAJCQlicmVhazsKIApAQCAt MTMzNyw2ICsxMzU0LDcgQEAgc3RhdGljIHZvaWQgc2JkbWFfdHhfcHJvY2Vzcyhz dHJ1Y3Qgc2JtYQogCiAJCWQtPnNiZG1hX3JlbXB0ciA9IFNCRE1BX05FWFRCVUYo ZCxzYmRtYV9yZW1wdHIpOwogCisJCXBhY2tldHNfaGFuZGxlZCsrOwogCX0KIAog CS8qCkBAIC0xMzQ0LDE1ICsxMzYyLDE1IEBAIHN0YXRpYyB2b2lkIHNiZG1hX3R4 X3Byb2Nlc3Moc3RydWN0IHNibWEKIAkgKiBPdGhlciBkcml2ZXJzIHNlZW0gdG8g ZG8gdGhpcyB3aGVuIHdlIHJlYWNoIGEgbG93CiAJICogd2F0ZXJtYXJrIG9uIHRo ZSB0cmFuc21pdCBxdWV1ZS4KIAkgKi8KKwkKKwlpZiAocGFja2V0c19oYW5kbGVk KQorCQluZXRpZl93YWtlX3F1ZXVlKGQtPnNiZG1hX2V0aC0+c2JtX2Rldik7CiAK LQluZXRpZl93YWtlX3F1ZXVlKGQtPnNiZG1hX2V0aC0+c2JtX2Rldik7Ci0KKyBl bmRfdW5sb2NrOgogCXNwaW5fdW5sb2NrX2lycXJlc3RvcmUoJihzYy0+c2JtX2xv Y2spLCBmbGFncyk7CiAKIH0KIAotCi0KIC8qKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq CiAgKiAgU0JNQUNfSU5JVENUWChzKQogICoKQEAgLTEzOTYsNyArMTQxNCw2IEBA IHN0YXRpYyBpbnQgc2JtYWNfaW5pdGN0eChzdHJ1Y3Qgc2JtYWNfc28KIAkgKiBJ bml0aWFsaXplIHRoZSBETUEgY2hhbm5lbHMuICBSaWdodCBub3csIG9ubHkgb25l IHBlciBNQUMgaXMgdXNlZAogCSAqIE5vdGU6IE9ubHkgZG8gdGhpcyBfb25jZV8s IGFzIGl0IGFsbG9jYXRlcyBtZW1vcnkgZnJvbSB0aGUga2VybmVsIQogCSAqLwot CiAJc2JkbWFfaW5pdGN0eCgmKHMtPnNibV90eGRtYSkscywwLERNQV9UWCxTQk1B Q19NQVhfVFhERVNDUik7CiAJc2JkbWFfaW5pdGN0eCgmKHMtPnNibV9yeGRtYSks cywwLERNQV9SWCxTQk1BQ19NQVhfUlhERVNDUik7CiAKQEAgLTE0MjAsOSArMTQz Nyw5IEBAIHN0YXRpYyBpbnQgc2JtYWNfaW5pdGN0eChzdHJ1Y3Qgc2JtYWNfc28K IAogc3RhdGljIHZvaWQgc2JkbWFfdW5pbml0Y3R4KHN0cnVjdCBzYm1hY2RtYV9z ICpkKQogewotCWlmIChkLT5zYmRtYV9kc2NydGFibGUpIHsKLQkJa2ZyZWUoZC0+ c2JkbWFfZHNjcnRhYmxlKTsKLQkJZC0+c2JkbWFfZHNjcnRhYmxlID0gTlVMTDsK KwlpZiAoZC0+c2JkbWFfZHNjcnRhYmxlX3VuYWxpZ25lZCkgeworCQlrZnJlZShk LT5zYmRtYV9kc2NydGFibGVfdW5hbGlnbmVkKTsKKwkJZC0+c2JkbWFfZHNjcnRh YmxlX3VuYWxpZ25lZCA9IGQtPnNiZG1hX2RzY3J0YWJsZSA9IE5VTEw7CiAJfQog CiAJaWYgKGQtPnNiZG1hX2N0eHRhYmxlKSB7CkBAIC0xNjA5LDEyICsxNjI2LDEy IEBAIHN0YXRpYyB2b2lkIHNibWFjX2NoYW5uZWxfc3RhcnQoc3RydWN0IHMKIAog I2lmIGRlZmluZWQoQ09ORklHX1NJQllURV9CQ00xeDU1KSB8fCBkZWZpbmVkKENP TkZJR19TSUJZVEVfQkNNMXg4MCkKIAlfX3Jhd193cml0ZXEoTV9NQUNfUlhETUFf RU4wIHwKLQkJICAgICAgIE1fTUFDX1RYRE1BX0VOMCwgcy0+c2JtX21hY2VuYWJs ZSk7CisJCSAgICAgTV9NQUNfVFhETUFfRU4wLCBzLT5zYm1fbWFjZW5hYmxlKTsK ICNlbGlmIGRlZmluZWQoQ09ORklHX1NJQllURV9TQjEyNTApIHx8IGRlZmluZWQo Q09ORklHX1NJQllURV9CQ00xMTJYKQogCV9fcmF3X3dyaXRlcShNX01BQ19SWERN QV9FTjAgfAotCQkgICAgICAgTV9NQUNfVFhETUFfRU4wIHwKLQkJICAgICAgIE1f TUFDX1JYX0VOQUJMRSB8Ci0JCSAgICAgICBNX01BQ19UWF9FTkFCTEUsIHMtPnNi bV9tYWNlbmFibGUpOworCQkgICAgIE1fTUFDX1RYRE1BX0VOMCB8CisJCSAgICAg TV9NQUNfUlhfRU5BQkxFIHwKKwkJICAgICBNX01BQ19UWF9FTkFCTEUsIHMtPnNi bV9tYWNlbmFibGUpOwogI2Vsc2UKICNlcnJvciBpbnZhbGlkIFNpQnl0ZSBNQUMg Y29uZmlndWF0aW9uCiAjZW5kaWYKQEAgLTE2MjQsMTUgKzE2NDEsMTUgQEAgc3Rh dGljIHZvaWQgc2JtYWNfY2hhbm5lbF9zdGFydChzdHJ1Y3QgcwogCSAqIEFjY2Vw dCBhbnkgVFggaW50ZXJydXB0IGFuZCBFT1AgY291bnQvdGltZXIgUlggaW50ZXJy dXB0cyBvbiBjaCAwCiAJICovCiAJX19yYXdfd3JpdGVxKCgoTV9NQUNfSU5UX0VP UF9DT1VOVCB8IE1fTUFDX0lOVF9FT1BfVElNRVIpIDw8IFNfTUFDX1RYX0NIMCkg fAotCQkgICAgICAgKChNX01BQ19JTlRfRU9QX0NPVU5UIHwgTV9NQUNfSU5UX0VP UF9USU1FUikgPDwgU19NQUNfUlhfQ0gwKSwgcy0+c2JtX2ltcik7CisJCSAgICAg KChNX01BQ19JTlRfRU9QX0NPVU5UIHwgTV9NQUNfSU5UX0VPUF9USU1FUikgPDwg U19NQUNfUlhfQ0gwKSwgCisJCSAgICAgcy0+c2JtX2ltcik7CiAjZWxzZQogCS8q CiAJICogQWNjZXB0IGFueSBraW5kIG9mIGludGVycnVwdCBvbiBUWCBhbmQgUlgg RE1BIGNoYW5uZWwgMAogCSAqLwogCV9fcmF3X3dyaXRlcSgoTV9NQUNfSU5UX0NI QU5ORUwgPDwgU19NQUNfVFhfQ0gwKSB8Ci0JCSAgICAgICAoTV9NQUNfSU5UX0NI QU5ORUwgPDwgU19NQUNfUlhfQ0gwKSwgcy0+c2JtX2ltcik7CisJCSAgICAgKE1f TUFDX0lOVF9DSEFOTkVMIDw8IFNfTUFDX1JYX0NIMCksIHMtPnNibV9pbXIpOwog I2VuZGlmCi0KIAkvKgogCSAqIEVuYWJsZSByZWNlaXZpbmcgdW5pY2FzdHMgYW5k IGJyb2FkY2FzdHMKIAkgKi8KQEAgLTIwNjcsNyArMjA4NCw2IEBAIHN0YXRpYyBp cnFyZXR1cm5fdCBzYm1hY19pbnRyKGludCBpcnEsdm8KIAkJICogUmVhZCB0aGUg SVNSICh0aGlzIGNsZWFycyB0aGUgYml0cyBpbiB0aGUgcmVhbAogCQkgKiByZWdp c3RlciwgZXhjZXB0IGZvciBjb3VudGVyIGFkZHIpCiAJCSAqLwotCiAJCWlzciA9 IF9fcmF3X3JlYWRxKHNjLT5zYm1faXNyKSAmIH5NX01BQ19DT1VOVEVSX0FERFI7 CiAKIAkJaWYgKGlzciA9PSAwKQpAQCAtMjA3OSwxMyArMjA5NSwzMSBAQCBzdGF0 aWMgaXJxcmV0dXJuX3Qgc2JtYWNfaW50cihpbnQgaXJxLHZvCiAJCSAqIFRyYW5z bWl0cyBvbiBjaGFubmVsIDAKIAkJICovCiAKKyNpZiBkZWZpbmVkKENPTkZJR19T Qk1BQ19OQVBJKQogCQlpZiAoaXNyICYgKE1fTUFDX0lOVF9DSEFOTkVMIDw8IFNf TUFDX1RYX0NIMCkpIHsKLQkJCXNiZG1hX3R4X3Byb2Nlc3Moc2MsJihzYy0+c2Jt X3R4ZG1hKSk7CisJCQlzYmRtYV90eF9wcm9jZXNzKHNjLCYoc2MtPnNibV90eGRt YSksIDApOwogCQl9CiAKIAkJLyoKIAkJICogUmVjZWl2ZXMgb24gY2hhbm5lbCAw CiAJCSAqLworCQlpZiAoaXNyICYgKE1fTUFDX0lOVF9DSEFOTkVMIDw8IFNfTUFD X1JYX0NIMCkpIHsKKwkJCWlmIChuZXRpZl9yeF9zY2hlZHVsZV9wcmVwKGRldikp CisJCQl7CisJCQkJX19yYXdfd3JpdGVxKDAsIHNjLT5zYm1faW1yKTsKKwkJCQlf X25ldGlmX3J4X3NjaGVkdWxlKGRldik7CisJCQl9CisJCQllbHNlCisJCQl7CisJ CQkJc2JkbWFfcnhfcHJvY2VzcyhzYywmKHNjLT5zYm1fcnhkbWEpLCAwKTsKKwkJ CX0KKwkJfQorI2Vsc2UKKwkJLyogTm9uIE5BUEkgKi8KKworCQlpZiAoaXNyICYg KE1fTUFDX0lOVF9DSEFOTkVMIDw8IFNfTUFDX1RYX0NIMCkpIHsKKwkJCXNiZG1h X3R4X3Byb2Nlc3Moc2MsJihzYy0+c2JtX3R4ZG1hKSwgMCk7CisJCX0KIAogCQkv KgogCQkgKiBJdCdzIGltcG9ydGFudCB0byB0ZXN0IGFsbCB0aGUgYml0cyAob3Ig YXQgbGVhc3QgdGhlCkBAIC0yMTA1LDggKzIxMzksOSBAQCBzdGF0aWMgaXJxcmV0 dXJuX3Qgc2JtYWNfaW50cihpbnQgaXJxLHZvCiAKIAogCQlpZiAoaXNyICYgKE1f TUFDX0lOVF9DSEFOTkVMIDw8IFNfTUFDX1JYX0NIMCkpIHsKLQkJCXNiZG1hX3J4 X3Byb2Nlc3Moc2MsJihzYy0+c2JtX3J4ZG1hKSk7CisJCQlzYmRtYV9yeF9wcm9j ZXNzKHNjLCYoc2MtPnNibV9yeGRtYSksIDApOwogCQl9CisjZW5kaWYKIAl9CiAJ cmV0dXJuIElSUV9SRVRWQUwoaGFuZGxlZCk7CiB9CkBAIC0yNDA1LDcgKzI0NDAs MTAgQEAgc3RhdGljIGludCBzYm1hY19pbml0KHN0cnVjdCBuZXRfZGV2aWNlIAog CWRldi0+ZG9faW9jdGwgICAgICAgICAgID0gc2JtYWNfbWlpX2lvY3RsOwogCWRl di0+dHhfdGltZW91dCAgICAgICAgID0gc2JtYWNfdHhfdGltZW91dDsKIAlkZXYt PndhdGNoZG9nX3RpbWVvICAgICA9IFRYX1RJTUVPVVQ7Ci0KKyNpZiBkZWZpbmVk KENPTkZJR19TQk1BQ19OQVBJKQorCWRldi0+cG9sbCAgICAgICAgICAgICAgID0g c2JtYWNfcG9sbDsKKwlkZXYtPndlaWdodCAgICAgICAgICAgICA9IDE2OworI2Vu ZGlmCiAJZGV2LT5jaGFuZ2VfbXR1ICAgICAgICAgPSBzYjEyNTBfY2hhbmdlX210 dTsKIAogCS8qIFRoaXMgaXMgbmVlZGVkIGZvciBQQVNTMiBmb3IgUnggSC9XIGNo ZWNrc3VtIGZlYXR1cmUgKi8KQEAgLTI4MTgsNyArMjg1NiwzNyBAQCBzdGF0aWMg aW50IHNibWFjX2Nsb3NlKHN0cnVjdCBuZXRfZGV2aWNlCiAJcmV0dXJuIDA7CiB9 CiAKKyNpZiBkZWZpbmVkKENPTkZJR19TQk1BQ19OQVBJKQorc3RhdGljIGludCBz Ym1hY19wb2xsKHN0cnVjdCBuZXRfZGV2aWNlICpkZXYsIGludCAqYnVkZ2V0KQor eworCWludCB3b3JrX3RvX2RvOworCWludCB3b3JrX2RvbmU7CisJc3RydWN0IHNi bWFjX3NvZnRjICpzYyA9IG5ldGRldl9wcml2KGRldik7CisKKwl3b3JrX3RvX2Rv ID0gbWluKCpidWRnZXQsIGRldi0+cXVvdGEpOworCXdvcmtfZG9uZSA9IHNiZG1h X3J4X3Byb2Nlc3Moc2MsJihzYy0+c2JtX3J4ZG1hKSwgMSk7CiAKKwlzYmRtYV90 eF9wcm9jZXNzKHNjLCYoc2MtPnNibV90eGRtYSksIDEpOworCisJKmJ1ZGdldCAt PSB3b3JrX2RvbmU7CisJZGV2LT5xdW90YSAtPSB3b3JrX2RvbmU7CisKKwlpZiAo d29ya19kb25lIDwgd29ya190b19kbykgeworCQluZXRpZl9yeF9jb21wbGV0ZShk ZXYpOworCisjaWZkZWYgQ09ORklHX1NCTUFDX0NPQUxFU0NFCisJCV9fcmF3X3dy aXRlcSgoKE1fTUFDX0lOVF9FT1BfQ09VTlQgfCBNX01BQ19JTlRfRU9QX1RJTUVS KSA8PCBTX01BQ19UWF9DSDApIHwKKwkJCSAgICAgKChNX01BQ19JTlRfRU9QX0NP VU5UIHwgTV9NQUNfSU5UX0VPUF9USU1FUikgPDwgU19NQUNfUlhfQ0gwKSwgCisJ CQkgICAgIHNjLT5zYm1faW1yKTsKKyNlbHNlCisJCV9fcmF3X3dyaXRlcSgoTV9N QUNfSU5UX0NIQU5ORUwgPDwgU19NQUNfVFhfQ0gwKSB8CisJCQkgICAgIChNX01B Q19JTlRfQ0hBTk5FTCA8PCBTX01BQ19SWF9DSDApLCBzYy0+c2JtX2ltcik7Cisj ZW5kaWYKKwl9CisKKwlyZXR1cm4gKHdvcmtfZG9uZSA+PSB3b3JrX3RvX2RvKTsK K30KKyNlbmRpZgogCiAjaWYgZGVmaW5lZChTQk1BQ19FVEgwX0hXQUREUikgfHwg ZGVmaW5lZChTQk1BQ19FVEgxX0hXQUREUikgfHwgZGVmaW5lZChTQk1BQ19FVEgy X0hXQUREUikgfHwgZGVmaW5lZChTQk1BQ19FVEgzX0hXQUREUikKIHN0YXRpYyB2 b2lkCg== ------------A8WtTPRxevcrr7Y0YoDYjf-- From ralf@linux-mips.org Sun Jun 4 19:51:44 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 04 Jun 2006 19:51:51 +0200 (CEST) Received: from localhost.localdomain ([127.0.0.1]:25318 "EHLO bacchus.dhis.org") by ftp.linux-mips.org with ESMTP id S8133887AbWFDRvo (ORCPT ); Sun, 4 Jun 2006 19:51:44 +0200 Received: from denk.linux-mips.net (denk.linux-mips.net [127.0.0.1]) by bacchus.dhis.org (8.13.6/8.13.4) with ESMTP id k54HpVpw008187; Sun, 4 Jun 2006 18:51:31 +0100 Received: (from ralf@localhost) by denk.linux-mips.net (8.13.6/8.13.6/Submit) id k54HpT6I008186; Sun, 4 Jun 2006 18:51:29 +0100 Date: Sun, 4 Jun 2006 18:51:29 +0100 From: Ralf Baechle To: "Kevin D. Kissell" Cc: Prasad Boddupalli , linux-mips@linux-mips.org Subject: Re: replacing synthesized tlb handlers with older ones Message-ID: <20060604175128.GA3790@linux-mips.org> References: <01b401c68678$98199a10$10eca8c0@grendel> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <01b401c68678$98199a10$10eca8c0@grendel> User-Agent: Mutt/1.4.2.1i Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11660 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ralf@linux-mips.org Precedence: bulk X-list: linux-mips On Fri, Jun 02, 2006 at 09:13:11PM +0200, Kevin D. Kissell wrote: > The TLB refill handler behavior for 1 CPU is fundamentally > different than for SMP. In the uniprocessor case, the page > table origin is implicit, whereas in SMP it needs to be indexed > by some per-CPU value, typically maintained in the Context > register. Pre-synthesed kernels set up up so that the Context > value would be shifted left 23 bits, then right by 2 bits, to generate > an offset. The newer system eliminates the right shift by ensuring > that the CPU index is stored in a pre-scaled form, and that bits > 23 and 24 are zero. So you can't just drop the old code into > the newer kernel, unless you also change the setup of Context. > A single CPU would work, because 0 == 0, otherwise... > Try nuking those right shifts. And beyond that, the old ones hardly made any reasonable attempt at getting TLB hazard handling right, so depending on hardware they will blow up. Ralf From art@sigrand.ru Mon Jun 5 09:43:55 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 05 Jun 2006 09:44:05 +0200 (CEST) Received: from sigrand.ru ([80.66.88.167]:5595 "HELO mail.sigrand.com") by ftp.linux-mips.org with SMTP id S8133455AbWFEHnz (ORCPT ); Mon, 5 Jun 2006 09:43:55 +0200 Received: from develop (unknown [192.168.2.238]) by mail.sigrand.com (Postfix) with ESMTP id 4D96112A0011 for ; Mon, 5 Jun 2006 14:43:53 +0700 (NOVST) Date: Mon, 5 Jun 2006 14:43:47 +0700 From: art X-Mailer: The Bat! (v1.38e) S/N A1D26E39 / Educational Reply-To: art Organization: Sigrand LLC X-Priority: 3 (Normal) Message-ID: <15613.060605@sigrand.ru> To: linux-mips@linux-mips.org Subject: Perfomance problem on MIPS Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11661 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: art@sigrand.ru Precedence: bulk X-list: linux-mips Hello all! I work with processor: MIPS 4KC. I check network performance without iptables & conntrac enabled and it has near 80Mbit/s. When I enable (without adding rules) network performance was near 40Mbit/s. While testing ksoftirqd is get near 50% of cpu. And (it is so strange) top eats the same! However cpu has 100% load and perfomance is real bad. Has anybody same problem? -- Best regards, art mailto:art@sigrand.ru From art@sigrand.ru Mon Jun 5 09:49:22 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 05 Jun 2006 09:49:30 +0200 (CEST) Received: from sigrand.ru ([80.66.88.167]:5851 "HELO mail.sigrand.com") by ftp.linux-mips.org with SMTP id S8133470AbWFEHtW (ORCPT ); Mon, 5 Jun 2006 09:49:22 +0200 Received: from develop (unknown [192.168.2.238]) by mail.sigrand.com (Postfix) with ESMTP id 8A42B12A0011 for ; Mon, 5 Jun 2006 14:49:21 +0700 (NOVST) Date: Mon, 5 Jun 2006 14:49:15 +0700 From: art X-Mailer: The Bat! (v1.38e) S/N A1D26E39 / Educational Reply-To: art Organization: Sigrand LLC X-Priority: 3 (Normal) Message-ID: <3617.060605@sigrand.ru> To: linux-mips@linux-mips.org Subject: Re: Perfomance problem on MIPS In-reply-To: <15613.060605@sigrand.ru> References: <15613.060605@sigrand.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11662 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: art@sigrand.ru Precedence: bulk X-list: linux-mips Hello art, Monday, June 05, 2006, 2:43:47 PM, you wrote: a> Hello all! a> I work with processor: MIPS 4KC. a> I check network performance without iptables & conntrac enabled a> and it has near 80Mbit/s. a> When I enable (without adding rules) network performance was a> near 40Mbit/s. a> While testing ksoftirqd is get near 50% of cpu. And (it is so a> strange) top eats the same! However cpu has 100% load and a> perfomance is real bad. a> Has anybody same problem? I mistype: with iptables&conntrack perfomance only 30Mbit/s -- Best regards, art mailto:art@sigrand.ru From art@sigrand.ru Mon Jun 5 09:51:39 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 05 Jun 2006 09:51:46 +0200 (CEST) Received: from sigrand.ru ([80.66.88.167]:6107 "HELO mail.sigrand.com") by ftp.linux-mips.org with SMTP id S8133470AbWFEHvi (ORCPT ); Mon, 5 Jun 2006 09:51:38 +0200 Received: from develop (unknown [192.168.2.238]) by mail.sigrand.com (Postfix) with ESMTP id AC4B712A0011 for ; Mon, 5 Jun 2006 14:51:37 +0700 (NOVST) Date: Mon, 5 Jun 2006 14:51:31 +0700 From: art X-Mailer: The Bat! (v1.38e) S/N A1D26E39 / Educational Reply-To: art Organization: Sigrand LLC X-Priority: 3 (Normal) Message-ID: <13619.060605@sigrand.ru> To: linux-mips@linux-mips.org Subject: Re: Perfomance problem on MIPS In-reply-To: <3617.060605@sigrand.ru> References: <3617.060605@sigrand.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11663 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: art@sigrand.ru Precedence: bulk X-list: linux-mips Kernel 2.6.16 from linux-mips.org a>> Hello all! a>> I work with processor: MIPS 4KC. a>> I check network performance without iptables & conntrac enabled a>> and it has near 80Mbit/s. a>> When I enable (without adding rules) network performance was a>> near 40Mbit/s. a>> While testing ksoftirqd is get near 50% of cpu. And (it is so a>> strange) top eats the same! However cpu has 100% load and a>> perfomance is real bad. a>> Has anybody same problem? -- Best regards, art mailto:art@sigrand.ru From ralf@linux-mips.org Mon Jun 5 11:23:05 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 05 Jun 2006 11:23:13 +0200 (CEST) Received: from localhost.localdomain ([127.0.0.1]:32967 "EHLO bacchus.dhis.org") by ftp.linux-mips.org with ESMTP id S8133489AbWFEJXF (ORCPT ); Mon, 5 Jun 2006 11:23:05 +0200 Received: from denk.linux-mips.net (denk.linux-mips.net [127.0.0.1]) by bacchus.dhis.org (8.13.6/8.13.4) with ESMTP id k559N4tT003612; Mon, 5 Jun 2006 10:23:04 +0100 Received: (from ralf@localhost) by denk.linux-mips.net (8.13.6/8.13.6/Submit) id k559N4wn003611; Mon, 5 Jun 2006 10:23:04 +0100 Date: Mon, 5 Jun 2006 10:23:04 +0100 From: Ralf Baechle To: art Cc: linux-mips@linux-mips.org Subject: Re: Perfomance problem on MIPS Message-ID: <20060605092304.GA3132@linux-mips.org> References: <15613.060605@sigrand.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <15613.060605@sigrand.ru> User-Agent: Mutt/1.4.2.1i Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11664 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ralf@linux-mips.org Precedence: bulk X-list: linux-mips On Mon, Jun 05, 2006 at 02:43:47PM +0700, art wrote: > Hello all! > I work with processor: MIPS 4KC. > I check network performance without iptables & conntrac enabled > and it has near 80Mbit/s. > When I enable (without adding rules) network performance was > near 40Mbit/s. > While testing ksoftirqd is get near 50% of cpu. And (it is so > strange) top eats the same! However cpu has 100% load and > perfomance is real bad. > Has anybody same problem? Just loading the connection tracking module will pull networking performance into a deep hole, no surprise there. All your numbers are on the low side though. What clock rate is your CPU running? Ralf From giometti@enneenne.com Mon Jun 5 16:42:47 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 05 Jun 2006 16:42:58 +0100 (BST) Received: from 81-174-11-161.f5.ngi.it ([81.174.11.161]:18823 "EHLO goldrake.enneenne.com") by ftp.linux-mips.org with ESMTP id S8133862AbWFEPmr (ORCPT ); Mon, 5 Jun 2006 16:42:47 +0100 Received: from zaigor.enneenne.com ([192.168.32.1]) by goldrake.enneenne.com with esmtp (Exim 4.50) id 1FnH9u-00079y-Pd for linux-mips@linux-mips.org; Mon, 05 Jun 2006 17:38:30 +0200 Received: from giometti by zaigor.enneenne.com with local (Exim 4.60) (envelope-from ) id 1FnHEU-0000ys-Lk for linux-mips@linux-mips.org; Mon, 05 Jun 2006 17:43:10 +0200 Date: Mon, 5 Jun 2006 17:43:10 +0200 From: Rodolfo Giometti To: linux-mips@linux-mips.org Message-ID: <20060605154310.GF27426@enneenne.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="gMR3gsNFwZpnI/Ts" Content-Disposition: inline Organization: GNU/Linux Device Drivers, Embedded Systems and Courses X-PGP-Key: gpg --keyserver keyserver.linux.it --recv-keys D25A5633 User-Agent: Mutt/1.5.11+cvs20060403 X-SA-Exim-Connect-IP: 192.168.32.1 X-SA-Exim-Mail-From: giometti@enneenne.com Subject: [PATCH] APM (emu) support X-SA-Exim-Version: 4.2 (built Thu, 03 Mar 2005 10:44:12 +0100) X-SA-Exim-Scanned: Yes (on goldrake.enneenne.com) Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11665 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: giometti@linux.it Precedence: bulk X-list: linux-mips --gMR3gsNFwZpnI/Ts Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hello, here my proposal to add APM (emu) support into mips tree. It's just the one for ARM adapted... I have tested it on my au1100 based board with a battery pack. Also the command: $ apm --suspend works correctly! Ciao, Rodolfo -- GNU/Linux Solutions e-mail: giometti@enneenne.com Linux Device Driver giometti@gnudd.com Embedded Systems giometti@linux.it UNIX programming phone: +39 349 2432127 --gMR3gsNFwZpnI/Ts Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=patch-apm-emu-support diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig index df2c58a..a783803 100644 --- a/arch/mips/Kconfig +++ b/arch/mips/Kconfig @@ -1848,6 +1848,32 @@ config PM bool "Power Management support (EXPERIMENTAL)" depends on EXPERIMENTAL && SOC_AU1X00 +config APM + tristate "Advanced Power Management Emulation" + depends on PM + ---help--- + APM is a BIOS specification for saving power using several different + techniques. This is mostly useful for battery powered systems with + APM compliant BIOSes. If you say Y here, the system time will be + reset after a RESUME operation, the /proc/apm device will provide + battery status information, and user-space programs will receive + notification of APM "events" (e.g. battery status change). + + In order to use APM, you will need supporting software. For location + and more information, read and the + Battery Powered Linux mini-HOWTO, available from + . + + This driver does not spin down disk drives (see the hdparm(8) + manpage ("man 8 hdparm") for that), and it doesn't turn off + VESA-compliant "green" monitors. + + Generally, if you don't have a battery in your machine, there isn't + much point in using this driver and you should say N. If you get + random kernel OOPSes or reboots that don't seem to be related to + anything, try disabling/enabling this option (or disabling/enabling + APM in your BIOS). + endmenu source "net/Kconfig" diff --git a/arch/mips/kernel/Makefile b/arch/mips/kernel/Makefile index 34e8a25..881c467 100644 --- a/arch/mips/kernel/Makefile +++ b/arch/mips/kernel/Makefile @@ -13,6 +13,8 @@ binfmt_irix-objs := irixelf.o irixinv.o obj-$(CONFIG_MODULES) += mips_ksyms.o module.o +obj-$(CONFIG_APM) += apm.o + obj-$(CONFIG_CPU_R3000) += r2300_fpu.o r2300_switch.o obj-$(CONFIG_CPU_TX39XX) += r2300_fpu.o r2300_switch.o obj-$(CONFIG_CPU_TX49XX) += r4k_fpu.o r4k_switch.o diff --git a/arch/mips/kernel/apm.c b/arch/mips/kernel/apm.c new file mode 100644 index 0000000..5abeaf5 --- /dev/null +++ b/arch/mips/kernel/apm.c @@ -0,0 +1,605 @@ +/* + * bios-less APM driver for MIPS Linux + * Jamey Hicks + * adapted from the APM BIOS driver for Linux by Stephen Rothwell (sfr@linuxcare.com) + * + * APM 1.2 Reference: + * Intel Corporation, Microsoft Corporation. Advanced Power Management + * (APM) BIOS Interface Specification, Revision 1.2, February 1996. + * + * [This document is available from Microsoft at: + * http://www.microsoft.com/hwdev/busbios/amp_12.htm] + */ +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#include /* apm_power_info */ +#include + +/* + * The apm_bios device is one of the misc char devices. + * This is its minor number. + */ +#define APM_MINOR_DEV 134 + +/* + * See Documentation/Config.help for the configuration options. + * + * Various options can be changed at boot time as follows: + * (We allow underscores for compatibility with the modules code) + * apm=on/off enable/disable APM + */ + +/* + * Maximum number of events stored + */ +#define APM_MAX_EVENTS 16 + +struct apm_queue { + unsigned int event_head; + unsigned int event_tail; + apm_event_t events[APM_MAX_EVENTS]; +}; + +/* + * The per-file APM data + */ +struct apm_user { + struct list_head list; + + unsigned int suser: 1; + unsigned int writer: 1; + unsigned int reader: 1; + + int suspend_result; + unsigned int suspend_state; +#define SUSPEND_NONE 0 /* no suspend pending */ +#define SUSPEND_PENDING 1 /* suspend pending read */ +#define SUSPEND_READ 2 /* suspend read, pending ack */ +#define SUSPEND_ACKED 3 /* suspend acked */ +#define SUSPEND_DONE 4 /* suspend completed */ + + struct apm_queue queue; +}; + +/* + * Local variables + */ +static int suspends_pending; +static int apm_disabled; +static int mips_apm_active; + +static DECLARE_WAIT_QUEUE_HEAD(apm_waitqueue); +static DECLARE_WAIT_QUEUE_HEAD(apm_suspend_waitqueue); + +/* + * This is a list of everyone who has opened /dev/apm_bios + */ +static DECLARE_RWSEM(user_list_lock); +static LIST_HEAD(apm_user_list); + +/* + * kapmd info. kapmd provides us a process context to handle + * "APM" events within - specifically necessary if we're going + * to be suspending the system. + */ +static DECLARE_WAIT_QUEUE_HEAD(kapmd_wait); +static DECLARE_COMPLETION(kapmd_exit); +static DEFINE_SPINLOCK(kapmd_queue_lock); +static struct apm_queue kapmd_queue; + + +static const char driver_version[] = "1.13"; /* no spaces */ + + + +/* + * Compatibility cruft until the IPAQ people move over to the new + * interface. + */ +static void __apm_get_power_status(struct apm_power_info *info) +{ +} + +/* + * This allows machines to provide their own "apm get power status" function. + */ +void (*apm_get_power_status)(struct apm_power_info *) = __apm_get_power_status; +EXPORT_SYMBOL(apm_get_power_status); + + +/* + * APM event queue management. + */ +static inline int queue_empty(struct apm_queue *q) +{ + return q->event_head == q->event_tail; +} + +static inline apm_event_t queue_get_event(struct apm_queue *q) +{ + q->event_tail = (q->event_tail + 1) % APM_MAX_EVENTS; + return q->events[q->event_tail]; +} + +static void queue_add_event(struct apm_queue *q, apm_event_t event) +{ + q->event_head = (q->event_head + 1) % APM_MAX_EVENTS; + if (q->event_head == q->event_tail) { + static int notified; + + if (notified++ == 0) + printk(KERN_ERR "apm: an event queue overflowed\n"); + q->event_tail = (q->event_tail + 1) % APM_MAX_EVENTS; + } + q->events[q->event_head] = event; +} + +static void queue_event_one_user(struct apm_user *as, apm_event_t event) +{ + if (as->suser && as->writer) { + switch (event) { + case APM_SYS_SUSPEND: + case APM_USER_SUSPEND: + /* + * If this user already has a suspend pending, + * don't queue another one. + */ + if (as->suspend_state != SUSPEND_NONE) + return; + + as->suspend_state = SUSPEND_PENDING; + suspends_pending++; + break; + } + } + queue_add_event(&as->queue, event); +} + +static void queue_event(apm_event_t event, struct apm_user *sender) +{ + struct apm_user *as; + + down_read(&user_list_lock); + list_for_each_entry(as, &apm_user_list, list) { + if (as != sender && as->reader) + queue_event_one_user(as, event); + } + up_read(&user_list_lock); + wake_up_interruptible(&apm_waitqueue); +} + +static void apm_suspend(void) +{ + struct apm_user *as; + int err = pm_suspend(PM_SUSPEND_MEM); + + /* + * Anyone on the APM queues will think we're still suspended. + * Send a message so everyone knows we're now awake again. + */ + queue_event(APM_NORMAL_RESUME, NULL); + + /* + * Finally, wake up anyone who is sleeping on the suspend. + */ + down_read(&user_list_lock); + list_for_each_entry(as, &apm_user_list, list) { + as->suspend_result = err; + as->suspend_state = SUSPEND_DONE; + } + up_read(&user_list_lock); + + wake_up(&apm_suspend_waitqueue); +} + +static ssize_t apm_read(struct file *fp, char __user *buf, size_t count, loff_t *ppos) +{ + struct apm_user *as = fp->private_data; + apm_event_t event; + int i = count, ret = 0; + + if (count < sizeof(apm_event_t)) + return -EINVAL; + + if (queue_empty(&as->queue) && fp->f_flags & O_NONBLOCK) + return -EAGAIN; + + wait_event_interruptible(apm_waitqueue, !queue_empty(&as->queue)); + + while ((i >= sizeof(event)) && !queue_empty(&as->queue)) { + event = queue_get_event(&as->queue); + + ret = -EFAULT; + if (copy_to_user(buf, &event, sizeof(event))) + break; + + if (event == APM_SYS_SUSPEND || event == APM_USER_SUSPEND) + as->suspend_state = SUSPEND_READ; + + buf += sizeof(event); + i -= sizeof(event); + } + + if (i < count) + ret = count - i; + + return ret; +} + +static unsigned int apm_poll(struct file *fp, poll_table * wait) +{ + struct apm_user *as = fp->private_data; + + poll_wait(fp, &apm_waitqueue, wait); + return queue_empty(&as->queue) ? 0 : POLLIN | POLLRDNORM; +} + +/* + * apm_ioctl - handle APM ioctl + * + * APM_IOC_SUSPEND + * This IOCTL is overloaded, and performs two functions. It is used to: + * - initiate a suspend + * - acknowledge a suspend read from /dev/apm_bios. + * Only when everyone who has opened /dev/apm_bios with write permission + * has acknowledge does the actual suspend happen. + */ +static int +apm_ioctl(struct inode * inode, struct file *filp, u_int cmd, u_long arg) +{ + struct apm_user *as = filp->private_data; + unsigned long flags; + int err = -EINVAL; + + if (!as->suser || !as->writer) + return -EPERM; + + switch (cmd) { + case APM_IOC_SUSPEND: + as->suspend_result = -EINTR; + + if (as->suspend_state == SUSPEND_READ) { + /* + * If we read a suspend command from /dev/apm_bios, + * then the corresponding APM_IOC_SUSPEND ioctl is + * interpreted as an acknowledge. + */ + as->suspend_state = SUSPEND_ACKED; + suspends_pending--; + } else { + /* + * Otherwise it is a request to suspend the system. + * Queue an event for all readers, and expect an + * acknowledge from all writers who haven't already + * acknowledged. + */ + queue_event(APM_USER_SUSPEND, as); + } + + /* + * If there are no further acknowledges required, suspend + * the system. + */ + if (suspends_pending == 0) + apm_suspend(); + + /* + * Wait for the suspend/resume to complete. If there are + * pending acknowledges, we wait here for them. + * + * Note that we need to ensure that the PM subsystem does + * not kick us out of the wait when it suspends the threads. + */ + flags = current->flags; + current->flags |= PF_NOFREEZE; + + /* + * Note: do not allow a thread which is acking the suspend + * to escape until the resume is complete. + */ + if (as->suspend_state == SUSPEND_ACKED) + wait_event(apm_suspend_waitqueue, + as->suspend_state == SUSPEND_DONE); + else + wait_event_interruptible(apm_suspend_waitqueue, + as->suspend_state == SUSPEND_DONE); + + current->flags = flags; + err = as->suspend_result; + as->suspend_state = SUSPEND_NONE; + break; + } + + return err; +} + +static int apm_release(struct inode * inode, struct file * filp) +{ + struct apm_user *as = filp->private_data; + filp->private_data = NULL; + + down_write(&user_list_lock); + list_del(&as->list); + up_write(&user_list_lock); + + /* + * We are now unhooked from the chain. As far as new + * events are concerned, we no longer exist. However, we + * need to balance suspends_pending, which means the + * possibility of sleeping. + */ + if (as->suspend_state != SUSPEND_NONE) { + suspends_pending -= 1; + if (suspends_pending == 0) + apm_suspend(); + } + + kfree(as); + return 0; +} + +static int apm_open(struct inode * inode, struct file * filp) +{ + struct apm_user *as; + + as = (struct apm_user *)kzalloc(sizeof(*as), GFP_KERNEL); + if (as) { + /* + * XXX - this is a tiny bit broken, when we consider BSD + * process accounting. If the device is opened by root, we + * instantly flag that we used superuser privs. Who knows, + * we might close the device immediately without doing a + * privileged operation -- cevans + */ + as->suser = capable(CAP_SYS_ADMIN); + as->writer = (filp->f_mode & FMODE_WRITE) == FMODE_WRITE; + as->reader = (filp->f_mode & FMODE_READ) == FMODE_READ; + + down_write(&user_list_lock); + list_add(&as->list, &apm_user_list); + up_write(&user_list_lock); + + filp->private_data = as; + } + + return as ? 0 : -ENOMEM; +} + +static struct file_operations apm_bios_fops = { + .owner = THIS_MODULE, + .read = apm_read, + .poll = apm_poll, + .ioctl = apm_ioctl, + .open = apm_open, + .release = apm_release, +}; + +static struct miscdevice apm_device = { + .minor = APM_MINOR_DEV, + .name = "apm_bios", + .fops = &apm_bios_fops +}; + + +#ifdef CONFIG_PROC_FS +/* + * Arguments, with symbols from linux/apm_bios.h. + * + * 0) Linux driver version (this will change if format changes) + * 1) APM BIOS Version. Usually 1.0, 1.1 or 1.2. + * 2) APM flags from APM Installation Check (0x00): + * bit 0: APM_16_BIT_SUPPORT + * bit 1: APM_32_BIT_SUPPORT + * bit 2: APM_IDLE_SLOWS_CLOCK + * bit 3: APM_BIOS_DISABLED + * bit 4: APM_BIOS_DISENGAGED + * 3) AC line status + * 0x00: Off-line + * 0x01: On-line + * 0x02: On backup power (BIOS >= 1.1 only) + * 0xff: Unknown + * 4) Battery status + * 0x00: High + * 0x01: Low + * 0x02: Critical + * 0x03: Charging + * 0x04: Selected battery not present (BIOS >= 1.2 only) + * 0xff: Unknown + * 5) Battery flag + * bit 0: High + * bit 1: Low + * bit 2: Critical + * bit 3: Charging + * bit 7: No system battery + * 0xff: Unknown + * 6) Remaining battery life (percentage of charge): + * 0-100: valid + * -1: Unknown + * 7) Remaining battery life (time units): + * Number of remaining minutes or seconds + * -1: Unknown + * 8) min = minutes; sec = seconds + */ +static int apm_get_info(char *buf, char **start, off_t fpos, int length) +{ + struct apm_power_info info; + char *units; + int ret; + + info.ac_line_status = 0xff; + info.battery_status = 0xff; + info.battery_flag = 0xff; + info.battery_life = -1; + info.time = -1; + info.units = -1; + + if (apm_get_power_status) + apm_get_power_status(&info); + + switch (info.units) { + default: units = "?"; break; + case 0: units = "min"; break; + case 1: units = "sec"; break; + } + + ret = sprintf(buf, "%s 1.2 0x%02x 0x%02x 0x%02x 0x%02x %d%% %d %s\n", + driver_version, APM_32_BIT_SUPPORT, + info.ac_line_status, info.battery_status, + info.battery_flag, info.battery_life, + info.time, units); + + return ret; +} +#endif + +static int kapmd(void *arg) +{ + daemonize("kapmd"); + current->flags |= PF_NOFREEZE; + + do { + apm_event_t event; + + wait_event_interruptible(kapmd_wait, + !queue_empty(&kapmd_queue) || !mips_apm_active); + + if (!mips_apm_active) + break; + + spin_lock_irq(&kapmd_queue_lock); + event = 0; + if (!queue_empty(&kapmd_queue)) + event = queue_get_event(&kapmd_queue); + spin_unlock_irq(&kapmd_queue_lock); + + switch (event) { + case 0: + break; + + case APM_LOW_BATTERY: + case APM_POWER_STATUS_CHANGE: + queue_event(event, NULL); + break; + + case APM_USER_SUSPEND: + case APM_SYS_SUSPEND: + queue_event(event, NULL); + if (suspends_pending == 0) + apm_suspend(); + break; + + case APM_CRITICAL_SUSPEND: + apm_suspend(); + break; + } + } while (1); + + complete_and_exit(&kapmd_exit, 0); +} + +static int __init apm_init(void) +{ + int ret; + + if (apm_disabled) { + printk(KERN_NOTICE "apm: disabled on user request.\n"); + return -ENODEV; + } + + mips_apm_active = 1; + + ret = kernel_thread(kapmd, NULL, CLONE_KERNEL); + if (ret < 0) { + mips_apm_active = 0; + return ret; + } + +#ifdef CONFIG_PROC_FS + create_proc_info_entry("apm", 0, NULL, apm_get_info); +#endif + + ret = misc_register(&apm_device); + if (ret != 0) { + remove_proc_entry("apm", NULL); + + mips_apm_active = 0; + wake_up(&kapmd_wait); + wait_for_completion(&kapmd_exit); + } + + return ret; +} + +static void __exit apm_exit(void) +{ + misc_deregister(&apm_device); + remove_proc_entry("apm", NULL); + + mips_apm_active = 0; + wake_up(&kapmd_wait); + wait_for_completion(&kapmd_exit); +} + +module_init(apm_init); +module_exit(apm_exit); + +MODULE_AUTHOR("Stephen Rothwell"); +MODULE_DESCRIPTION("Advanced Power Management"); +MODULE_LICENSE("GPL"); + +#ifndef MODULE +static int __init apm_setup(char *str) +{ + while ((str != NULL) && (*str != '\0')) { + if (strncmp(str, "off", 3) == 0) + apm_disabled = 1; + if (strncmp(str, "on", 2) == 0) + apm_disabled = 0; + str = strchr(str, ','); + if (str != NULL) + str += strspn(str, ", \t"); + } + return 1; +} + +__setup("apm=", apm_setup); +#endif + +/** + * apm_queue_event - queue an APM event for kapmd + * @event: APM event + * + * Queue an APM event for kapmd to process and ultimately take the + * appropriate action. Only a subset of events are handled: + * %APM_LOW_BATTERY + * %APM_POWER_STATUS_CHANGE + * %APM_USER_SUSPEND + * %APM_SYS_SUSPEND + * %APM_CRITICAL_SUSPEND + */ +void apm_queue_event(apm_event_t event) +{ + unsigned long flags; + + spin_lock_irqsave(&kapmd_queue_lock, flags); + queue_add_event(&kapmd_queue, event); + spin_unlock_irqrestore(&kapmd_queue_lock, flags); + + wake_up_interruptible(&kapmd_wait); +} +EXPORT_SYMBOL(apm_queue_event); diff --git a/include/asm-mips/apm.h b/include/asm-mips/apm.h new file mode 100644 index 0000000..e8c6920 --- /dev/null +++ b/include/asm-mips/apm.h @@ -0,0 +1,65 @@ +/* -*- linux-c -*- + * + * (C) 2003 zecke@handhelds.org + * + * GPL version 2 + * + * based on arch/arm/kernel/apm.c + * factor out the information needed by architectures to provide + * apm status + * + * + */ +#ifndef MIPS_ASM_SA1100_APM_H +#define MIPS_ASM_SA1100_APM_H + +#include +#include + +/* + * This structure gets filled in by the machine specific 'get_power_status' + * implementation. Any fields which are not set default to a safe value. + */ +struct apm_power_info { + unsigned char ac_line_status; +#define APM_AC_OFFLINE 0 +#define APM_AC_ONLINE 1 +#define APM_AC_BACKUP 2 +#define APM_AC_UNKNOWN 0xff + + unsigned char battery_status; +#define APM_BATTERY_STATUS_HIGH 0 +#define APM_BATTERY_STATUS_LOW 1 +#define APM_BATTERY_STATUS_CRITICAL 2 +#define APM_BATTERY_STATUS_CHARGING 3 +#define APM_BATTERY_STATUS_NOT_PRESENT 4 +#define APM_BATTERY_STATUS_UNKNOWN 0xff + + unsigned char battery_flag; +#define APM_BATTERY_FLAG_HIGH (1 << 0) +#define APM_BATTERY_FLAG_LOW (1 << 1) +#define APM_BATTERY_FLAG_CRITICAL (1 << 2) +#define APM_BATTERY_FLAG_CHARGING (1 << 3) +#define APM_BATTERY_FLAG_NOT_PRESENT (1 << 7) +#define APM_BATTERY_FLAG_UNKNOWN 0xff + + int battery_life; + int time; + int units; +#define APM_UNITS_MINS 0 +#define APM_UNITS_SECS 1 +#define APM_UNITS_UNKNOWN -1 + +}; + +/* + * This allows machines to provide their own "apm get power status" function. + */ +extern void (*apm_get_power_status)(struct apm_power_info *); + +/* + * Queue an event (APM_SYS_SUSPEND or APM_CRITICAL_SUSPEND) + */ +void apm_queue_event(apm_event_t event); + +#endif --gMR3gsNFwZpnI/Ts-- From Rajesh_Palani@pmc-sierra.com Mon Jun 5 17:06:10 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 05 Jun 2006 17:06:19 +0100 (BST) Received: from father.pmc-sierra.com ([216.241.224.13]:49122 "HELO father.pmc-sierra.bc.ca") by ftp.linux-mips.org with SMTP id S8133862AbWFEQGK (ORCPT ); Mon, 5 Jun 2006 17:06:10 +0100 Received: (qmail 12820 invoked by uid 101); 5 Jun 2006 16:05:59 -0000 Received: from unknown (HELO ogyruan.pmc-sierra.bc.ca) (216.241.226.236) by father.pmc-sierra.com with SMTP; 5 Jun 2006 16:05:59 -0000 Received: from bby1exi01.pmc_nt.nt.pmc-sierra.bc.ca (bby1exi01.pmc-sierra.bc.ca [216.241.231.251]) by ogyruan.pmc-sierra.bc.ca (8.13.3/8.12.7) with ESMTP id k55G5xBJ001558; Mon, 5 Jun 2006 09:05:59 -0700 Received: by bby1exi01.pmc-sierra.bc.ca with Internet Mail Service (5.5.2656.59) id ; Mon, 5 Jun 2006 09:05:59 -0700 Message-ID: <478F19F21671F04298A2116393EEC3D5274178@sjc1exm08.pmc_nt.nt.pmc-sierra.bc.ca> From: Raj Palani To: Roman Mashak , linux-mips@linux-mips.org Subject: RE: booting 64bit kernel on RM9150 Date: Mon, 5 Jun 2006 09:05:54 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11666 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: Rajesh_Palani@pmc-sierra.com Precedence: bulk X-list: linux-mips Hi Roman, Yes. The current kernel on the FTP site does not have 64-bit support tested. -Raj > -----Original Message----- > From: Roman Mashak [mailto:mrv@corecom.co.kr] > Sent: Friday, June 02, 2006 5:21 PM > To: linux-mips@linux-mips.org > Cc: Raj Palani > Subject: Re: booting 64bit kernel on RM9150 > > Hello, Raj! > You wrote to "Roman Mashak" ; > on Fri, 2 Jun 2006 16:28:17 -0700 : > > RP> The patch for 64-bit support for Sequoia would follow > the patch for > RP> the base support for Sequoia in the Linux/MIPS tree. > Are you saying the kernel 2.6.12-rc3_L002 located on > ftp.pmc-sierra.com doesn't support 64bit properly? I used for > experiments that kernel and default config file for 64bit > support provided with the kernel. It boots up eventually and crashes: > > TCP established hash table entries: 16384 (order: 5, 131072 > bytes) TCP bind hash table entries: 16384 (order: 5, 131072 bytes) > TCP: Hash tables configured (established 16384 bind 16384) > NET: Registered protocol family 1 > CPU 0 Unable to handle kernel paging request at virtual > address 00000000ff048060, epc == ffffffff802332f8, ra == > ffffffff80159eb4 Oops in arch/mips/mm/fault.c::do_page_fault, > line 167[#1]: > Cpu 0 > $ 0 : 0000000000000000 ffffffffff050000 ffffffff802332a8 > 00000000ff050000 > $ 4 : 0000000000000005 980000000178c000 9800000001487d50 > 000000000000002c > $ 8 : 980000000178c000 9800000001461800 0000000000100000 > 000000000023fc00 > $12 : 0000000000002000 0000000000000000 ffffffff9400a0e0 > 98000000003e8e00 > $16 : 980000000178c000 0000000000000000 9800000001487d50 > 0000000000000000 > $20 : ffffffff940080e0 0000000000000000 0000000000000000 > 0000000000000000 > $24 : 98000000003e8e10 0000000000000001 > $28 : 9800000001484000 9800000001487c90 0000000000000000 > ffffffff80159eb4 > Hi : 000000000000348f > Lo : 5c28f5c28fab0000 > epc : ffffffff802332f8 > msp85x0_ge_sequoia_int_handler+0x50/0x2e0 Not > tainted > ra : ffffffff80159eb4 handle_IRQ_event+0x6c/0xe8 > Status: 940080e2 KX SX UX KERNEL EXL > Cause : 00002008 > BadVA : 00000000ff048060 > PrId : 000034c1 > Modules linked in: > Process swapper (pid: 1, threadinfo=9800000001484000, > task=98000000014816b8) Stack : 980000000fddc940 > 0000000000000000 9800000001487d50 0000000000000005 > 0000000000000001 0000000000000000 ffffffff80159eb4 > 0000000000000001 > ffffffff80345140 0000000000000005 980000000fddc940 > 9800000001487d50 > fffffffffffffffb 980000000178c000 ffffffff8015a094 > ffffffff80107098 > ffffffff80345140 980000000fddc940 0000000000000005 > ffffffff9400a0e1 > 0000000000000000 ffffffff801036bc ffffffff80100e70 > ffffffff803c5ae0 > 0000000000000000 ffffffff9400a0e0 0000000000000000 > 0000000000002000 > 0000000000000005 ffffffff9400a0e0 0000000000000000 > 000000000000002c > 980000000178c000 9800000001461800 0000000000100000 > 000000000023fc00 > 0000000000000020 ffffffff801f911c 0000000000100100 > 98000000003e8e00 > ... > Call Trace: > [] handle_IRQ_event+0x6c/0xe8 > [] __do_IRQ+0x164/0x1d0 > [] timer_interrupt+0x298/0x470 > [] do_IRQ+0x1c/0x38 [] > ll_xdma_irq+0xc/0x14 [] > memset_partial+0x38/0x60 [] > memset_partial+0x48/0x60 [] > setup_irq+0x108/0x1a8 [] > setup_irq+0x120/0x1a8 [] > msp85x0_ge_sequoia_int_handler+0x0/0x2e0 > [] request_irq+0xac/0xf8 > [] msp85x0_ge_open+0x78/0x130 > [] msp85x0_ge_open+0x4c/0x130 > [] dev_open+0x68/0xf0 [] > dev_change_flags+0x90/0x188 [] > ic_open_devs+0x328/0x558 [] > create_proc_entry+0x58/0xf8 [] > ip_auto_config+0xa8/0x598 [] > do_initcalls+0x90/0x198 [] > do_initcalls+0x90/0x198 [] init+0x5c/0x1e0 > [] kernel_thread_helper+0x10/0x18 > [] kernel_thread_helper+0x0/0x18 > > > Code: 64630001 0003183c 0061182d <8c638060> 3c040000 > 3c01803c 64840000 > 0004203c 0081202d > Kernel panic - not syncing: Aiee, killing interrupt handler! > > With best regards, Roman Mashak. E-mail: mrv@corecom.co.kr > > From wilson@specifix.com Mon Jun 5 20:38:03 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 05 Jun 2006 20:38:12 +0100 (BST) Received: from w099.z064220152.sjc-ca.dsl.cnc.net ([64.220.152.99]:43473 "HELO duck.specifix.com") by ftp.linux-mips.org with SMTP id S8133951AbWFETiD (ORCPT ); Mon, 5 Jun 2006 20:38:03 +0100 Received: from [127.0.0.1] (duck.corp.specifix.com [192.168.1.1]) by duck.specifix.com (Postfix) with ESMTP id CA93EFC7D; Mon, 5 Jun 2006 12:37:32 -0700 (PDT) Subject: Re: Re: where I can find a crosscompiler for BCM1255 From: James E Wilson To: richard Cc: linux-mips In-Reply-To: <1149406697$85109$64181664@yczhao@hhcn.com> References: <1149406697$85109$64181664@yczhao@hhcn.com> Content-Type: text/plain Message-Id: <1149536252.9096.11.camel@aretha.corp.specifix.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Mon, 05 Jun 2006 12:37:32 -0700 Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11667 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: wilson@specifix.com Precedence: bulk X-list: linux-mips On Sun, 2006-06-04 at 00:38, richard wrote: > /bin/sh: /opt/specifix/broadcom_2006a_410/mips-unknown-linux-gnu/bin/mips64-linux-gcc: cannot execute binary file This is a mips-linux hosted cross compiler that emits code for the mips64-linux target. What kind of machine are you using to compile the kernel? If it isn't a mips-linux machine, then you can't use a mips-linux hosted compiler binary. You could try building a compiler yourself from the sources. There are some instructions on the wiki. -- Jim Wilson, GNU Tools Support, http://www.specifix.com From wilson@specifix.com Mon Jun 5 20:39:38 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 05 Jun 2006 20:39:46 +0100 (BST) Received: from w099.z064220152.sjc-ca.dsl.cnc.net ([64.220.152.99]:44241 "HELO duck.specifix.com") by ftp.linux-mips.org with SMTP id S8133951AbWFETji (ORCPT ); Mon, 5 Jun 2006 20:39:38 +0100 Received: from [127.0.0.1] (duck.corp.specifix.com [192.168.1.1]) by duck.specifix.com (Postfix) with ESMTP id 930DBFC7D; Mon, 5 Jun 2006 12:39:27 -0700 (PDT) Subject: Re: Re: where I can find a crosscompiler for BCM1255 From: James E Wilson To: richard Cc: linux-mips In-Reply-To: <1149408124$86550$79346250@yczhao@hhcn.com> References: <1149408124$86550$79346250@yczhao@hhcn.com> Content-Type: text/plain Message-Id: <1149536367.9096.14.camel@aretha.corp.specifix.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Mon, 05 Jun 2006 12:39:27 -0700 Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11668 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: wilson@specifix.com Precedence: bulk X-list: linux-mips On Sun, 2006-06-04 at 01:01, richard wrote: > Then which versions or kernel should I use? That depends on what you are trying to do. Normally, you would pick a version for one, and then pick a compatible version for the other. However, since your problems have nothing to do with kernel/compiler versions, this isn't something you need to worry about at the moment. -- Jim Wilson, GNU Tools Support, http://www.specifix.com From giometti@enneenne.com Tue Jun 6 09:19:51 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 06 Jun 2006 09:20:02 +0100 (BST) Received: from 81-174-11-161.f5.ngi.it ([81.174.11.161]:16783 "EHLO goldrake.enneenne.com") by ftp.linux-mips.org with ESMTP id S8133649AbWFFITu (ORCPT ); Tue, 6 Jun 2006 09:19:50 +0100 Received: from hulk.enneenne.com ([192.168.32.38] helo=localhost.localdomain ident=Debian-exim) by goldrake.enneenne.com with esmtp (Exim 4.50) id 1FnWiv-0002gn-VV for linux-mips@linux-mips.org; Tue, 06 Jun 2006 10:15:38 +0200 Received: from giometti by localhost.localdomain with local (Exim 4.60) (envelope-from ) id 1FnWmx-0003eJ-9U for linux-mips@linux-mips.org; Tue, 06 Jun 2006 10:19:47 +0200 Date: Tue, 6 Jun 2006 10:19:47 +0200 From: Rodolfo Giometti To: linux-mips@linux-mips.org Message-ID: <20060606081947.GA13486@hulk.enneenne.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Organization: GNU/Linux Device Drivers, Embedded Systems and Courses X-PGP-Key: gpg --keyserver keyserver.linux.it --recv-keys D25A5633 User-Agent: Mutt/1.5.11+cvs20060126 X-SA-Exim-Connect-IP: 192.168.32.38 X-SA-Exim-Mail-From: giometti@enneenne.com Subject: USB device status on au1x00 X-SA-Exim-Version: 4.2 (built Thu, 03 Mar 2005 10:44:12 +0100) X-SA-Exim-Scanned: Yes (on goldrake.enneenne.com) Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11669 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: giometti@linux.it Precedence: bulk X-list: linux-mips Hello, I'd like to know if someone is still working on this topic in order to join efforts. I know au1x00 problems on USB device controller but maybe some gadget is usable anyway due low interrupts request... on WinCE remotesync (or something similar) works. :) Ciao, Rodolfo -- GNU/Linux Solutions e-mail: giometti@enneenne.com Linux Device Driver giometti@gnudd.com Embedded Systems giometti@linux.it UNIX programming phone: +39 349 2432127 From ashley_jones_2000@yahoo.com Tue Jun 6 13:37:42 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 06 Jun 2006 13:37:51 +0100 (BST) Received: from web38412.mail.mud.yahoo.com ([209.191.125.43]:28822 "HELO web38412.mail.mud.yahoo.com") by ftp.linux-mips.org with SMTP id S8133927AbWFFMhm (ORCPT ); Tue, 6 Jun 2006 13:37:42 +0100 Received: (qmail 19117 invoked by uid 60001); 6 Jun 2006 12:37:35 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=l0JdGT+xDR6dzpku+rbSaPcQ+NcGG31xW4nyE0nfyDPLPjhuu33S4zfE+ZjYib6XGNoeAMd/W1oGDjzBvqRAdRFNcOb6A6pa8Nh10qYEQK8RCcAyjkzRNlTMu2V/11avEFRLIha3LUMCNdPlDipVGhonUXybASVQjrRWWYh3GqA= ; Message-ID: <20060606123735.19115.qmail@web38412.mail.mud.yahoo.com> Received: from [203.92.57.132] by web38412.mail.mud.yahoo.com via HTTP; Tue, 06 Jun 2006 05:37:35 PDT Date: Tue, 6 Jun 2006 05:37:35 -0700 (PDT) From: ashley jones Subject: Re: Socket buffer allocation outside DMA-able memory To: art , linux-mips@linux-mips.org In-Reply-To: <6851.060602@sigrand.ru> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-263030290-1149597455=:14044" Content-Transfer-Encoding: 8bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11670 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ashley_jones_2000@yahoo.com Precedence: bulk X-list: linux-mips --0-263030290-1149597455=:14044 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit hi, I guess your 25 bit dma address field will be word alligned, so ur dma engine will be able to index up to 64 MB( 25+2 = 27 bits). If that is not the case then you can use one of the foll. work around, * dont give whole 64 MB to linux, give only Lower 32 MB. * Give only upper 32 MB to linux, and give memory to ur dma engine from lower 32 MB, and once you recv any data you copy to skb and submit to linux. ( ofcourse your performance will get hit in this case.) Regards, A'Jones. art wrote: Hello all! I work with ADM5120 chip. it has embedded switch. Switch descriptor has 25-bit dma addres field - so addressible only 32Mb! My system has 64Mb memory. But I have to set 32Mb to make it work! I thought that setting DMA mask can help. So in /arch/mips/adm5120/setup.c i make: static struct platform_device adm5120hcd_device = { .name = "adm5120-hcd", .id = -1, .dev = { .dma_mask = &hcd_dmamask, .coherent_dma_mask = 0x01ffffff, }, .num_resources = ARRAY_SIZE(adm5120_hcd_resources), .resource = adm5120_hcd_resources, }; But It is wrong, because dev_alloc_skb dont know to which device it allocates buffer! How to tell kernel allocate skbuffers in less then 32Mb addrspace whet system has 64Mb? -- Best regards, art mailto:art@sigrand.ru __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com --0-263030290-1149597455=:14044 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit
hi,
       I guess your 25 bit dma address field will be word alligned, so ur dma engine will be able to index up to 64 MB( 25+2 = 27 bits).
 
        If that is not the case then you can use one of the foll. work around,
 
  * dont give whole 64 MB to linux, give only Lower 32 MB.
  * Give only upper 32 MB to linux, and give memory to ur dma engine from lower 32 MB, and once you recv any data you copy to skb and submit to linux. ( ofcourse your performance will get hit in this case.)
 
 
Regards,
A'Jones.


art <art@sigrand.ru> wrote:
Hello all!
I work with ADM5120 chip. it has embedded switch.
Switch descriptor has 25-bit dma addres field - so addressible only
32Mb!
My system has 64Mb memory. But I have to set 32Mb to make it work!
I thought that setting DMA mask can help. So in
/arch/mips/adm5120/setup.c i make:

static struct platform_device adm5120hcd_device = {
.name = "adm5120-hcd",
.id = -1,
.dev = {
.dma_mask = &hcd_dmamask,
.coherent_dma_mask = 0x01ffffff,
},
.num_resources = ARRAY_SIZE(adm5120_hcd_resources),
.resource = adm5120_hcd_resources,
};
But It is wrong, because dev_alloc_skb dont know to which device it
allocates buffer!

How to tell kernel allocate skbuffers in less then 32Mb addrspace whet
system has 64Mb?

--
Best regards,
art mailto:art@sigrand.ru




__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com --0-263030290-1149597455=:14044-- From rongkai.zhan@windriver.com Tue Jun 6 14:33:46 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 06 Jun 2006 14:33:55 +0100 (BST) Received: from mail.windriver.com ([147.11.1.11]:43440 "EHLO mail.wrs.com") by ftp.linux-mips.org with ESMTP id S8133926AbWFFNdq (ORCPT ); Tue, 6 Jun 2006 14:33:46 +0100 Received: from ALA-MAIL03.corp.ad.wrs.com (ala-mail03 [147.11.57.144]) by mail.wrs.com (8.13.6/8.13.3) with ESMTP id k56DXdpX022190; Tue, 6 Jun 2006 06:33:39 -0700 (PDT) Received: from ism-mail01.corp.ad.wrs.com ([147.11.96.20]) by ALA-MAIL03.corp.ad.wrs.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 6 Jun 2006 06:33:38 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6896D.D06A1676" Subject: RE: Socket buffer allocation outside DMA-able memory Date: Tue, 6 Jun 2006 15:33:35 +0200 Message-ID: <6A3254532ACD7A42805B4E1BFD18080EEA2114@ism-mail01.corp.ad.wrs.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Socket buffer allocation outside DMA-able memory Thread-Index: AcaJZjbxp1IvfUOrSwyzJ2H7FF15GwABt95Q From: "Zhan, Rongkai" To: "ashley jones" , "art" , X-OriginalArrivalTime: 06 Jun 2006 13:33:38.0411 (UTC) FILETIME=[D1649BB0:01C6896D] Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11671 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: rongkai.zhan@windriver.com Precedence: bulk X-list: linux-mips This is a multi-part message in MIME format. ------_=_NextPart_001_01C6896D.D06A1676 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, =20 Maybe you can enable ISA bus. And then add your low 32MB memory into = ZONE_DMA, while the high 32MB memory into ZONE_NORMAL. In the case, you are required to redefine MAX_DMA_ADDRESS to = (PAGE_OFFSET + 0x00200000) in asm-mips/dma.h =20 =20 Just a noise. =20 Best Regards, Mark. Zhan ________________________________ From: linux-mips-bounce@linux-mips.org = [mailto:linux-mips-bounce@linux-mips.org] On Behalf Of ashley jones Sent: Tuesday, June 06, 2006 8:38 PM To: art; linux-mips@linux-mips.org Subject: Re: Socket buffer allocation outside DMA-able memory =20 hi, I guess your 25 bit dma address field will be word alligned, so = ur dma engine will be able to index up to 64 MB( 25+2 =3D 27 bits). =20 If that is not the case then you can use one of the foll. work = around, =20 * dont give whole 64 MB to linux, give only Lower 32 MB. * Give only upper 32 MB to linux, and give memory to ur dma engine = from lower 32 MB, and once you recv any data you copy to skb and submit = to linux. ( ofcourse your performance will get hit in this case.) =20 =20 Regards, A'Jones. art wrote: Hello all! I work with ADM5120 chip. it has embedded switch. Switch descriptor has 25-bit dma addres field - so addressible only 32Mb! My system has 64Mb memory. But I have to set 32Mb to make it work! I thought that setting DMA mask can help. So in /arch/mips/adm5120/setup.c i make: =09 static struct platform_device adm5120hcd_device =3D { .name =3D "adm5120-hcd", .id =3D -1, .dev =3D { .dma_mask =3D &hcd_dmamask, .coherent_dma_mask =3D 0x01ffffff, }, .num_resources =3D ARRAY_SIZE(adm5120_hcd_resources), .resource =3D adm5120_hcd_resources, }; But It is wrong, because dev_alloc_skb dont know to which device it allocates buffer! =09 How to tell kernel allocate skbuffers in less then 32Mb addrspace whet system has 64Mb? =09 --=20 Best regards, art mailto:art@sigrand.ru =09 =09 =09 =20 __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around=20 http://mail.yahoo.com=20 ------_=_NextPart_001_01C6896D.D06A1676 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi,

 <= /span>

Maybe you can = enable ISA bus. And then add your low 32MB memory into ZONE_DMA, while the high = 32MB memory into ZONE_NORMAL.

In the case, you = are required to redefine MAX_DMA_ADDRESS to (PAGE_OFFSET + 0x00200000) in asm-mips/dma.h

 <= /span>

 <= /span>

Just a = noise.

 <= /span>

Best Regards,
Mark. Zhan

From: linux-mips-bounce@linux-mips.org = [mailto:linux-mips-bounce@linux-mips.org] On Behalf Of ashley jones
Sent: Tuesday, June 06, = 2006 8:38 PM
To: art; = linux-mips@linux-mips.org
Subject: Re: Socket = buffer allocation outside DMA-able memory

 

hi,

       I guess = your 25 bit dma address field will be word alligned, so ur dma engine will be = able to index up to 64 MB( 25+2 =3D 27 bits).

 

        If = that is not the case then you can use one of the foll. work = around,

 

  * dont give whole 64 MB to linux, give = only Lower 32 MB.

  * Give only upper 32 MB to linux, and = give memory to ur dma engine from lower 32 MB, and once you recv any data you copy to skb = and submit to linux. ( ofcourse your performance will get hit in this = case.)

 

 

Regards,

A'Jones.



art <art@sigrand.ru> = wrote:

Hello all!
I work with ADM5120 chip. it has embedded switch.
Switch descriptor has 25-bit dma addres field - so addressible only
32Mb!
My system has 64Mb memory. But I have to set 32Mb to make it work!
I thought that setting DMA mask can help. So in
/arch/mips/adm5120/setup.c i make:

static struct platform_device adm5120hcd_device =3D {
.name =3D "adm5120-hcd",
.id =3D -1,
.dev =3D {
.dma_mask =3D &hcd_dmamask,
.coherent_dma_mask =3D 0x01ffffff,
},
.num_resources =3D ARRAY_SIZE(adm5120_hcd_resources),
.resource =3D adm5120_hcd_resources,
};
But It is wrong, because dev_alloc_skb dont know to which device it
allocates buffer!

How to tell kernel allocate skbuffers in less then 32Mb addrspace = whet
system has 64Mb?

--
Best regards,
art mailto:art@sigrand.ru


 

______________________________________________= ____
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com

------_=_NextPart_001_01C6896D.D06A1676-- From rongkai.zhan@windriver.com Tue Jun 6 15:04:20 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 06 Jun 2006 15:04:27 +0100 (BST) Received: from mail.windriver.com ([147.11.1.11]:7106 "EHLO mail.wrs.com") by ftp.linux-mips.org with ESMTP id S8133934AbWFFOET convert rfc822-to-8bit (ORCPT ); Tue, 6 Jun 2006 15:04:19 +0100 Received: from ala-mail04.corp.ad.wrs.com (ala-mail04 [147.11.57.145]) by mail.wrs.com (8.13.6/8.13.3) with ESMTP id k56E4C9R027006; Tue, 6 Jun 2006 07:04:13 -0700 (PDT) Received: from ism-mail01.corp.ad.wrs.com ([147.11.96.20]) by ala-mail04.corp.ad.wrs.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 6 Jun 2006 07:02:59 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8BIT Subject: RE: Socket buffer allocation outside DMA-able memory Date: Tue, 6 Jun 2006 16:02:55 +0200 Message-ID: <6A3254532ACD7A42805B4E1BFD18080EEA211B@ism-mail01.corp.ad.wrs.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Socket buffer allocation outside DMA-able memory Thread-Index: AcaJZjbxp1IvfUOrSwyzJ2H7FF15GwABt95QAAEMDCA= From: "Zhan, Rongkai" To: "Zhan, Rongkai" , "ashley jones" , "art" , X-OriginalArrivalTime: 06 Jun 2006 14:02:59.0850 (UTC) FILETIME=[EB4ADEA0:01C68971] Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11672 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: rongkai.zhan@windriver.com Precedence: bulk X-list: linux-mips After having a look at the latest 2.6.17-rc6 codes, __dev_alloc_skb is defined like this: #ifndef CONFIG_HAVE_ARCH_DEV_ALLOC_SKB /** * __dev_alloc_skb - allocate an skbuff for sending * @length: length to allocate * @gfp_mask: get_free_pages mask, passed to alloc_skb * * Allocate a new &sk_buff and assign it a usage count of one. The * buffer has unspecified headroom built in. Users should allocate * the headroom they think they need without accounting for the * built in space. The built in space is used for optimisations. * * %NULL is returned in there is no free memory. */ static inline struct sk_buff *__dev_alloc_skb(unsigned int length, gfp_t gfp_mask) { struct sk_buff *skb = alloc_skb(length + NET_SKB_PAD, gfp_mask); if (likely(skb)) skb_reserve(skb, NET_SKB_PAD); return skb; } #else extern struct sk_buff *__dev_alloc_skb(unsigned int length, int gfp_mask); #endif Therefore, you also can consider to implement your machine-specific __dev_alloc_skb() function, and force the skb is allocated from your low 32MB memory zone. Best Regards, Mark. Zhan ________________________________________ From: linux-mips-bounce@linux-mips.org [mailto:linux-mips-bounce@linux-mips.org] On Behalf Of Zhan, Rongkai Sent: Tuesday, June 06, 2006 9:34 PM To: ashley jones; art; linux-mips@linux-mips.org Subject: RE: Socket buffer allocation outside DMA-able memory Hi, Maybe you can enable ISA bus. And then add your low 32MB memory into ZONE_DMA, while the high 32MB memory into ZONE_NORMAL. In the case, you are required to redefine MAX_DMA_ADDRESS to (PAGE_OFFSET + 0x00200000) in asm-mips/dma.h Just a noise. Best Regards, Mark. Zhan ________________________________________ From: linux-mips-bounce@linux-mips.org [mailto:linux-mips-bounce@linux-mips.org] On Behalf Of ashley jones Sent: Tuesday, June 06, 2006 8:38 PM To: art; linux-mips@linux-mips.org Subject: Re: Socket buffer allocation outside DMA-able memory hi,        I guess your 25 bit dma address field will be word alligned, so ur dma engine will be able to index up to 64 MB( 25+2 = 27 bits).           If that is not the case then you can use one of the foll. work around,     * dont give whole 64 MB to linux, give only Lower 32 MB.   * Give only upper 32 MB to linux, and give memory to ur dma engine from lower 32 MB, and once you recv any data you copy to skb and submit to linux. ( ofcourse your performance will get hit in this case.)     Regards, A'Jones. art wrote: Hello all! I work with ADM5120 chip. it has embedded switch. Switch descriptor has 25-bit dma addres field - so addressible only 32Mb! My system has 64Mb memory. But I have to set 32Mb to make it work! I thought that setting DMA mask can help. So in /arch/mips/adm5120/setup.c i make: static struct platform_device adm5120hcd_device = { .name = "adm5120-hcd", .id = -1, .dev = { .dma_mask = &hcd_dmamask, .coherent_dma_mask = 0x01ffffff, }, .num_resources = ARRAY_SIZE(adm5120_hcd_resources), .resource = adm5120_hcd_resources, }; But It is wrong, because dev_alloc_skb dont know to which device it allocates buffer! How to tell kernel allocate skbuffers in less then 32Mb addrspace whet system has 64Mb? -- Best regards, art mailto:art@sigrand.ru __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From yoichi_yuasa@tripeaks.co.jp Wed Jun 7 01:53:44 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 07 Jun 2006 01:53:54 +0100 (BST) Received: from mo30.po.2iij.net ([210.128.50.53]:14378 "EHLO mo30.po.2iij.net") by ftp.linux-mips.org with ESMTP id S8134002AbWFGAxo (ORCPT ); Wed, 7 Jun 2006 01:53:44 +0100 Received: by mo.po.2iij.net (mo30) id k570rdI4067334; Wed, 7 Jun 2006 09:53:39 +0900 (JST) Received: from localhost.localdomain (65.126.232.202.bf.2iij.net [202.232.126.65]) by mbox.po.2iij.net (mbox30) id k570rYGY062869 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 7 Jun 2006 09:53:34 +0900 (JST) Date: Wed, 7 Jun 2006 09:53:34 +0900 From: Yoichi Yuasa To: Ralf Baechle Cc: linux-mips Subject: [PATCH] cobalt: fixed undefined reference to `disable_early_printk' Message-Id: <20060607095334.156f19a0.yoichi_yuasa@tripeaks.co.jp> Organization: TriPeaks Corporation X-Mailer: Sylpheed version 1.0.4 (GTK+ 1.2.10; i386-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11673 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: yoichi_yuasa@tripeaks.co.jp Precedence: bulk X-list: linux-mips Hi, This patch has fixed build error about cobalt. drivers/built-in.o: In function `console_init': : undefined reference to `disable_early_printk' make: *** [.tmp_vmlinux1] Error 1 Yoichi Signed-off-by: Yoichi Yuasa diff -pruN -X dontdiff rc5-orig/arch/mips/cobalt/console.c rc5/arch/mips/cobalt/console.c --- rc5-orig/arch/mips/cobalt/console.c 2006-06-06 10:29:30.278755250 +0900 +++ rc5/arch/mips/cobalt/console.c 2006-06-05 23:32:59.877242000 +0900 @@ -41,3 +41,8 @@ void __init cobalt_early_console(void) printk("Cobalt: early console registered\n"); } + +void __init disable_early_printk(void) +{ + unregister_console(&cons_info); +} From art@sigrand.ru Wed Jun 7 04:48:42 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 07 Jun 2006 04:48:51 +0100 (BST) Received: from sigrand.ru ([80.66.88.167]:62693 "HELO mail.sigrand.com") by ftp.linux-mips.org with SMTP id S8133355AbWFGDsm (ORCPT ); Wed, 7 Jun 2006 04:48:42 +0100 Received: from develop (unknown [192.168.2.238]) by mail.sigrand.com (Postfix) with ESMTP id 58F5312A0044; Wed, 7 Jun 2006 10:48:35 +0700 (NOVST) Date: Wed, 7 Jun 2006 10:48:34 +0700 From: art X-Mailer: The Bat! (v1.38e) S/N A1D26E39 / Educational Reply-To: art Organization: Sigrand LLC X-Priority: 3 (Normal) Message-ID: <15450.060607@sigrand.ru> To: ashley jones Cc: linux-mips@linux-mips.org Subject: Re[2]: Socket buffer allocation outside DMA-able memory In-reply-To: <20060606123735.19115.qmail@web38412.mail.mud.yahoo.com> References: <20060606123735.19115.qmail@web38412.mail.mud.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11674 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: art@sigrand.ru Precedence: bulk X-list: linux-mips Hello ashley, Tuesday, June 06, 2006, 7:37:35 PM, you wrote: aj> I guess your 25 bit dma address field will be word alligned, so ur dma engine will be able to index up to 64 MB( 25+2 = 27 bits). Address not aligned - if I don't do anything driver work incorrect! aj> * dont give whole 64 MB to linux, give only Lower 32 MB. You mean with command line kernel option? If so - I already did so to get all work! aj> * Give only upper 32 MB to linux, and give memory to ur dma engine from lower 32 MB, and once you recv any data you copy to skb and submit to linux. ( ofcourse your performance will get hit aj> in this case.) How can I do this? I have variant that if addres is upper than 32Mb then copy skbuffer to previously allocated memory that lower than 32Mb, but perfomance is wery Important. Maybe you mean this?? From rongkai.zhan@windriver.com Wed Jun 7 05:12:04 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 07 Jun 2006 05:12:13 +0100 (BST) Received: from mail.windriver.com ([147.11.1.11]:676 "EHLO mail.wrs.com") by ftp.linux-mips.org with ESMTP id S8126552AbWFGEME (ORCPT ); Wed, 7 Jun 2006 05:12:04 +0100 Received: from ala-mail04.corp.ad.wrs.com (ala-mail04 [147.11.57.145]) by mail.wrs.com (8.13.6/8.13.3) with ESMTP id k574Bu5t018582; Tue, 6 Jun 2006 21:11:56 -0700 (PDT) Received: from ala-mail06.corp.ad.wrs.com ([147.11.57.147]) by ala-mail04.corp.ad.wrs.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 6 Jun 2006 21:11:56 -0700 Received: from [192.168.96.27] ([192.168.96.27]) by ala-mail06.corp.ad.wrs.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 6 Jun 2006 21:11:55 -0700 Message-ID: <44865207.9080606@windriver.com> Date: Wed, 07 Jun 2006 12:11:51 +0800 From: "Mark.Zhan" User-Agent: Thunderbird 1.5.0.2 (X11/20060522) MIME-Version: 1.0 To: art CC: linux-mips@linux-mips.org Subject: Re: Socket buffer allocation outside DMA-able memory References: <6A3254532ACD7A42805B4E1BFD18080EEA211B@ism-mail01.corp.ad.wrs.com> <10452.060607@sigrand.ru> In-Reply-To: <10452.060607@sigrand.ru> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 07 Jun 2006 04:11:55.0877 (UTC) FILETIME=[8387C950:01C689E8] Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11675 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: rongkai.zhan@windriver.com Precedence: bulk X-list: linux-mips Hi art, I think maybe my first noise is more easy to go. As you know, sk_buff is made of a skb header and the packet data container. The skb header is allocated from the slab cache, while the packet data container is allocated via kmalloc(). So if you can add your low 32MB memory into ZONE_DMA, then your can call __dev_alloc_skb() with __GFP_DMA flag in your driver, which should make sure that the packet data container is in ZONE_DMA. Best Regards, Mark.Zhan art wrote: > Hello Rongkai, > > Thanks! Good idea! > > > ZR> After having a look at the latest 2.6.17-rc6 codes, __dev_alloc_skb is defined like this: > > ZR> #ifndef CONFIG_HAVE_ARCH_DEV_ALLOC_SKB > ZR> /** > ZR> * __dev_alloc_skb - allocate an skbuff for sending > ZR> * @length: length to allocate > ZR> * @gfp_mask: get_free_pages mask, passed to alloc_skb > ZR> * > ZR> * Allocate a new &sk_buff and assign it a usage count of one. The > ZR> * buffer has unspecified headroom built in. Users should allocate > ZR> * the headroom they think they need without accounting for the > ZR> * built in space. The built in space is used for optimisations. > ZR> * > ZR> * %NULL is returned in there is no free memory. > ZR> */ > ZR> static inline struct sk_buff *__dev_alloc_skb(unsigned int length, > ZR> gfp_t gfp_mask) > ZR> { > ZR> struct sk_buff *skb = alloc_skb(length + NET_SKB_PAD, gfp_mask); > ZR> if (likely(skb)) > ZR> skb_reserve(skb, NET_SKB_PAD); > ZR> return skb; > ZR> } > ZR> #else > ZR> extern struct sk_buff *__dev_alloc_skb(unsigned int length, int gfp_mask); > ZR> #endif > > > ZR> Therefore, you also can consider to implement your machine-specific __dev_alloc_skb() function, and force the skb is allocated from your low 32MB memory zone. > > > > From ashley_jones_2000@yahoo.com Wed Jun 7 06:18:03 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 07 Jun 2006 06:18:11 +0100 (BST) Received: from web38409.mail.mud.yahoo.com ([209.191.125.40]:39833 "HELO web38409.mail.mud.yahoo.com") by ftp.linux-mips.org with SMTP id S8126552AbWFGFSD (ORCPT ); Wed, 7 Jun 2006 06:18:03 +0100 Received: (qmail 66062 invoked by uid 60001); 7 Jun 2006 05:17:56 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=vtJTcNW5zdNEPrPeUhpVMMIIgmDVUXGx6G+2/KHD8q8pox9ku6MafRAEqHCN7Neq62FXjEp7S3bSGsJ6gjAXL8f0tXuHgjmpgpJB+90PzFBhOf+gPvGYVvgpHzbaTQFpvR0Oh/4H4qR1nccnN+/14QfXvbx74Mapx6fkmIrLGd8= ; Message-ID: <20060607051756.66058.qmail@web38409.mail.mud.yahoo.com> Received: from [203.92.57.132] by web38409.mail.mud.yahoo.com via HTTP; Tue, 06 Jun 2006 22:17:56 PDT Date: Tue, 6 Jun 2006 22:17:56 -0700 (PDT) From: ashley jones Subject: Re: Re[2]: Socket buffer allocation outside DMA-able memory To: art Cc: linux-mips@linux-mips.org In-Reply-To: <15450.060607@sigrand.ru> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-2105202544-1149657476=:65043" Content-Transfer-Encoding: 8bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11676 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ashley_jones_2000@yahoo.com Precedence: bulk X-list: linux-mips --0-2105202544-1149657476=:65043 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit art wrote: Hello ashley, Tuesday, June 06, 2006, 7:37:35 PM, you wrote: aj> I guess your 25 bit dma address field will be word alligned, so ur dma engine will be able to index up to 64 MB( 25+2 = 27 bits). Address not aligned - if I don't do anything driver work incorrect! *** what do you mean by Address not aligned ?? *** What address you r passing to dma ? u should pass (skb->data >> 2) (if word alligned address is required for dma engine.) aj> * dont give whole 64 MB to linux, give only Lower 32 MB. You mean with command line kernel option? If so - I already did so to get all work! *** when you do add_memory_region(), give only first 32 MB to linux, so all the skbs will be in lower 32 MB range. aj> * Give only upper 32 MB to linux, and give memory to ur dma engine from lower 32 MB, and once you recv any data you copy to skb and submit to linux. ( ofcourse your performance will get hit aj> in this case.) How can I do this? I have variant that if addres is upper than 32Mb then copy skbuffer to previously allocated memory that lower than 32Mb, but perfomance is wery Important. Maybe you mean this?? A'Jones. __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com --0-2105202544-1149657476=:65043 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit
art <art@sigrand.ru> wrote:
Hello ashley,

Tuesday, June 06, 2006, 7:37:35 PM, you wrote:


aj> I guess your 25 bit dma address field will be word alligned, so ur dma engine will be able to index up to 64 MB( 25+2 = 27 bits).
Address not aligned - if I don't do anything driver work incorrect!
 
*** what do you mean by Address not aligned ??
 
*** What address you r passing to dma ? u should pass (skb->data >> 2) (if word alligned address is required for dma engine.)

aj> * dont give whole 64 MB to linux, give only Lower 32 MB.
You mean with command line kernel option? If so - I already did so to
get all work!
*** when you do add_memory_region(), give only first 32 MB to linux, so all the skbs will be in lower 32 MB range.
 
aj> * Give only upper 32 MB to linux, and give memory to ur dma engine from lower 32 MB, and once you recv any data you copy to skb and submit to linux. ( ofcourse your performance will get hit
aj> in this case.)
How can I do this? I have variant that if addres is upper than 32Mb then copy skbuffer to
previously allocated memory that lower than 32Mb, but perfomance is wery Important. Maybe
you mean this??



A'Jones.

__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com --0-2105202544-1149657476=:65043-- From vitalywool@gmail.com Wed Jun 7 07:51:52 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 07 Jun 2006 07:51:59 +0100 (BST) Received: from rtsoft2.corbina.net ([85.21.88.2]:11209 "HELO mail.dev.rtsoft.ru") by ftp.linux-mips.org with SMTP id S8126552AbWFGGvw (ORCPT ); Wed, 7 Jun 2006 07:51:52 +0100 Received: (qmail 21798 invoked from network); 7 Jun 2006 11:01:09 -0000 Received: from laja.dev.rtsoft.ru.dev.rtsoft.ru (HELO dev.rtsoft.ru.) (192.168.1.205) by mail.dev.rtsoft.ru with SMTP; 7 Jun 2006 11:01:09 -0000 Date: Wed, 7 Jun 2006 10:52:21 +0400 From: Vitaly Wool To: linux-kernel@vger.kernel.org Cc: linux-mips@linux-mips.org Subject: PNX8550 fails to compile in 2.6.17-rc4 Message-Id: <20060607105221.7b15b243.vitalywool@gmail.com> X-Mailer: Sylpheed version 2.2.1 (GTK+ 2.8.13; i486-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11677 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: vitalywool@gmail.com Precedence: bulk X-list: linux-mips Hi folks, when I try to compile Linux kernel for pnx8550 in 2.6.17-rc4, I get the following error: CC arch/mips/philips/pnx8550/common/setup.o /home/vital/work/opensource/mtd/arch/mips/philips/pnx8550/common/setup.c: In function `plat_setup': /home/vital/work/opensource/mtd/arch/mips/philips/pnx8550/common/setup.c:133: warning: implicit declaration of function `ip3106_lcr' /home/vital/work/opensource/mtd/arch/mips/philips/pnx8550/common/setup.c:134: error: invalid lvalue in assignment /home/vital/work/opensource/mtd/arch/mips/philips/pnx8550/common/setup.c:135: warning: implicit declaration of function `ip3106_baud' /home/vital/work/opensource/mtd/arch/mips/philips/pnx8550/common/setup.c:135: error: invalid lvalue in assignment make[2]: *** [arch/mips/philips/pnx8550/common/setup.o] Error 1 make[1]: *** [arch/mips/philips/pnx8550/common] Error 2 make: *** [vmlinux] Error 2 I guess it's not what it should be ;-) Vitaly From art@sigrand.ru Wed Jun 7 08:37:33 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 07 Jun 2006 08:37:41 +0100 (BST) Received: from sigrand.ru ([80.66.88.167]:31207 "HELO mail.sigrand.com") by ftp.linux-mips.org with SMTP id S8126552AbWFGHhc (ORCPT ); Wed, 7 Jun 2006 08:37:32 +0100 Received: from develop (unknown [192.168.2.238]) by mail.sigrand.com (Postfix) with ESMTP id ADE9BE8042; Wed, 7 Jun 2006 14:37:30 +0700 (NOVST) Date: Wed, 7 Jun 2006 14:37:30 +0700 From: art X-Mailer: The Bat! (v1.38e) S/N A1D26E39 / Educational Reply-To: art Organization: Sigrand LLC X-Priority: 3 (Normal) Message-ID: <12609.060607@sigrand.ru> To: ashley jones Cc: linux-mips@linux-mips.org Subject: Re[4]: Socket buffer allocation outside DMA-able memory In-reply-To: <20060607051756.66058.qmail@web38409.mail.mud.yahoo.com> References: <20060607051756.66058.qmail@web38409.mail.mud.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11678 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: art@sigrand.ru Precedence: bulk X-list: linux-mips Hello ashley, Wednesday, June 07, 2006, 12:17:56 PM, you wrote: aj>> I guess your 25 bit dma address field will be word alligned, so ur dma engine will be able to index up to 64 MB( 25+2 = 27 bits). aj> Address not aligned - if I don't do anything driver work incorrect! aj> *** what do you mean by Address not aligned ?? aj> *** What address you r passing to dma ? u should pass (skb->data >> 2) (if word alligned address is required for dma engine.) In adm5120 switch driver to dma passed skb->data -- Best regards, art mailto:art@sigrand.ru From Eckhardt@satorlaser.com Wed Jun 7 10:02:25 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 07 Jun 2006 10:02:33 +0100 (BST) Received: from mail.domino-uk.com ([193.131.116.193]:9225 "EHLO vMimePS1.domino-printing.com") by ftp.linux-mips.org with ESMTP id S8133385AbWFGJCZ (ORCPT ); Wed, 7 Jun 2006 10:02:25 +0100 Received: from emea-exchange3.emea.dps.local (EMEA-EXCHANGE3) by vMimePS1.domino-printing.com (Clearswift SMTPRS 5.2.3) with ESMTP id for ; Wed, 7 Jun 2006 10:01:00 +0100 Received: from tuxator2.emea.dps.local ([192.168.55.75]) by emea-exchange3.emea.dps.local with Microsoft SMTPSVC(6.0.3790.1830); Wed, 7 Jun 2006 11:03:35 +0200 From: Ulrich Eckhardt Organization: Sator Laser GmbH To: linux-mips@linux-mips.org Subject: Re: [PATCH] fix some compiler warnings (field width, unused variable) Date: Wed, 7 Jun 2006 11:03:34 +0200 User-Agent: KMail/1.9.1 References: <20060601.010003.39154219.anemo@mba.ocn.ne.jp> <20060602.015404.93020143.anemo@mba.ocn.ne.jp> In-Reply-To: <20060602.015404.93020143.anemo@mba.ocn.ne.jp> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200606071103.34646.eckhardt@satorlaser.com> X-OriginalArrivalTime: 07 Jun 2006 09:03:35.0140 (UTC) FILETIME=[41E76A40:01C68A11] Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11679 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: eckhardt@satorlaser.com Precedence: bulk X-list: linux-mips On Thursday 01 June 2006 18:54, Atsushi Nemoto wrote: > printk("initrd extends beyond end of memory " > - "(0x%0*Lx > 0x%0*Lx)\ndisabling initrd\n", > - width, > - (unsigned long long) CPHYSADDR(initrd_end), > - width, > - (unsigned long long) PFN_PHYS(max_low_pfn)); > + "(0x%p > 0x%p)\ndisabling initrd\n", > + (void *)CPHYSADDR(initrd_end), > + (void *)PFN_PHYS(max_low_pfn)); I'm not so sure if this is a good idea because some systems have 36 bit physical addresses while they only have 32 bit void pointers, so long long is probably really the better solution. I'm wondering if it would be worth having a special flag in printk to indicate a physical address ("%lp" perhaps?) so that you don't get the unimportant leading zeroes for the bits 36 to 63 for above mentioned platforms. Uli **************************************************** Visit our website at **************************************************** 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 system manager. This footnote also confirms that this Email message has been swept by MailSweeper for the presence of computer viruses. **************************************************** From ralf@linux-mips.org Wed Jun 7 11:04:53 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 07 Jun 2006 11:05:00 +0100 (BST) Received: from localhost.localdomain ([127.0.0.1]:29843 "EHLO bacchus.dhis.org") by ftp.linux-mips.org with ESMTP id S8133441AbWFGKEx (ORCPT ); Wed, 7 Jun 2006 11:04:53 +0100 Received: from denk.linux-mips.net (denk.linux-mips.net [127.0.0.1]) by bacchus.dhis.org (8.13.6/8.13.4) with ESMTP id k57A4qMt024656 for ; Wed, 7 Jun 2006 11:04:52 +0100 Received: (from ralf@localhost) by denk.linux-mips.net (8.13.6/8.13.6/Submit) id k57A4q94024655 for linux-mips@linux-mips.org; Wed, 7 Jun 2006 11:04:52 +0100 Date: Wed, 7 Jun 2006 11:04:52 +0100 From: Ralf Baechle To: linux-mips@linux-mips.org Subject: Re: DDB5074 and DDB5476 eval boards Message-ID: <20060607100448.GA16791@linux-mips.org> References: <20060302161136.GA12460@linux-mips.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060302161136.GA12460@linux-mips.org> User-Agent: Mutt/1.4.2.1i Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11680 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ralf@linux-mips.org Precedence: bulk X-list: linux-mips On Thu, Mar 02, 2006 at 04:11:36PM +0000, Ralf Baechle wrote: > Both boards don't compile anymore since include/linux/kbd_ll.h was removed > and nobody did complain making them perfect candidates for somebody who > either wants to take over maintenance or alternatively, removal of the > code. Anybody still interested? No patches seen ... Just a reminder. Ralf From ralf@linux-mips.org Wed Jun 7 13:27:18 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 07 Jun 2006 13:27:25 +0100 (BST) Received: from localhost.localdomain ([127.0.0.1]:34966 "EHLO bacchus.dhis.org") by ftp.linux-mips.org with ESMTP id S8133592AbWFGM1S (ORCPT ); Wed, 7 Jun 2006 13:27:18 +0100 Received: from denk.linux-mips.net (denk.linux-mips.net [127.0.0.1]) by bacchus.dhis.org (8.13.6/8.13.4) with ESMTP id k57CRI3Y008613; Wed, 7 Jun 2006 13:27:18 +0100 Received: (from ralf@localhost) by denk.linux-mips.net (8.13.6/8.13.6/Submit) id k57CRGlu008612; Wed, 7 Jun 2006 13:27:16 +0100 Date: Wed, 7 Jun 2006 13:27:16 +0100 From: Ralf Baechle To: Yoichi Yuasa Cc: linux-mips Subject: Re: [PATCH] cobalt: fixed undefined reference to `disable_early_printk' Message-ID: <20060607122716.GA8606@linux-mips.org> References: <20060607095334.156f19a0.yoichi_yuasa@tripeaks.co.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060607095334.156f19a0.yoichi_yuasa@tripeaks.co.jp> User-Agent: Mutt/1.4.2.1i Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11681 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ralf@linux-mips.org Precedence: bulk X-list: linux-mips On Wed, Jun 07, 2006 at 09:53:34AM +0900, Yoichi Yuasa wrote: > This patch has fixed build error about cobalt. > > drivers/built-in.o: In function `console_init': > : undefined reference to `disable_early_printk' > make: *** [.tmp_vmlinux1] Error 1 Thanks, applied. Ralf From lhrkernelcoder@gmail.com Wed Jun 7 13:56:39 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 07 Jun 2006 13:56:46 +0100 (BST) Received: from qb-out-0506.google.com ([72.14.204.225]:20655 "EHLO qb-out-0506.google.com") by ftp.linux-mips.org with ESMTP id S8133677AbWFGM4j (ORCPT ); Wed, 7 Jun 2006 13:56:39 +0100 Received: by qb-out-0506.google.com with SMTP id e12so141694qbe for ; Wed, 07 Jun 2006 05:56:38 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=sTfr7sQddnf0H3rCbjTINVLpvZgcQBWV0rJ+DbGiNHbzOlTetfqF7imb52SQxnkp15G/uTs8s0Dp7p8yIOt/ez0f2yLDYoVk08eOskt6Fi7MWIZr+h95HgHeUSPHftypWy8S7JMFZfZp8TBA1YmoAdy2OUlIN2pUiHI1jji6gzA= Received: by 10.70.29.3 with SMTP id c3mr666332wxc; Wed, 07 Jun 2006 05:56:37 -0700 (PDT) Received: by 10.70.89.6 with HTTP; Wed, 7 Jun 2006 05:56:37 -0700 (PDT) Message-ID: Date: Wed, 7 Jun 2006 17:56:37 +0500 From: "kernel coder" To: linux-mips@linux-mips.org Subject: RTL explaination MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11682 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: lhrkernelcoder@gmail.com Precedence: bulk X-list: linux-mips hi, I'm trying to understand the rtl genrated by gcc for mips processor.I have read gcc internals by Richard Stallman but there are still some confusions in the rtl language. Following is a snippet of code which i'm trying to understand. (insn 9 6 10 (nil) (set (reg:SI 182) (mem/f:SI (symbol_ref:SI ("a")) [0 a+0 S4 A32])) -1 (nil) (nil)) In the above code following part is still unclear to me [0 a+0 S4 A32])) -1 (nil) (nil)) Following is the c code for which above rtl is generated : int a; main() { a=a+1; } thanks, shahzad From ralf@linux-mips.org Wed Jun 7 14:59:30 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 07 Jun 2006 14:59:37 +0100 (BST) Received: from localhost.localdomain ([127.0.0.1]:18105 "EHLO bacchus.dhis.org") by ftp.linux-mips.org with ESMTP id S8133753AbWFGN7a (ORCPT ); Wed, 7 Jun 2006 14:59:30 +0100 Received: from denk.linux-mips.net (denk.linux-mips.net [127.0.0.1]) by bacchus.dhis.org (8.13.6/8.13.4) with ESMTP id k57DxTSI027717; Wed, 7 Jun 2006 14:59:29 +0100 Received: (from ralf@localhost) by denk.linux-mips.net (8.13.6/8.13.6/Submit) id k57DxMBN027716; Wed, 7 Jun 2006 14:59:22 +0100 Date: Wed, 7 Jun 2006 14:59:22 +0100 From: Ralf Baechle To: gregkh@suse.de, linux-usb-devel@lists.sourceforge.net, dbrownell@users.sourceforge.net, linux-mips@linux-mips.org Subject: [PATCH] Fix OHCI HCD build for PNX 8550 Message-ID: <20060607135922.GA26754@linux-mips.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.1i Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11683 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ralf@linux-mips.org Precedence: bulk X-list: linux-mips The PNX8550 OHCI is a platform device so we better include the necessary headers. Signed-off-by: Ralf Baechle diff --git a/drivers/usb/host/ohci-pnx8550.c b/drivers/usb/host/ohci-pnx8550.c index db9c5db..ed242e7 100644 --- a/drivers/usb/host/ohci-pnx8550.c +++ b/drivers/usb/host/ohci-pnx8550.c @@ -23,7 +23,7 @@ * This file is licenced under the GPL. */ -#include +#include #include #include #include From ralf@linux-mips.org Wed Jun 7 15:27:04 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 07 Jun 2006 15:27:11 +0100 (BST) Received: from localhost.localdomain ([127.0.0.1]:52415 "EHLO bacchus.dhis.org") by ftp.linux-mips.org with ESMTP id S8133993AbWFGO1E (ORCPT ); Wed, 7 Jun 2006 15:27:04 +0100 Received: from denk.linux-mips.net (denk.linux-mips.net [127.0.0.1]) by bacchus.dhis.org (8.13.6/8.13.4) with ESMTP id k57ER31Y031383; Wed, 7 Jun 2006 15:27:03 +0100 Received: (from ralf@localhost) by denk.linux-mips.net (8.13.6/8.13.6/Submit) id k57ER2RW031381; Wed, 7 Jun 2006 15:27:02 +0100 Date: Wed, 7 Jun 2006 15:27:02 +0100 From: Ralf Baechle To: Vitaly Wool Cc: linux-kernel@vger.kernel.org, linux-mips@linux-mips.org Subject: Re: PNX8550 fails to compile in 2.6.17-rc4 Message-ID: <20060607142702.GA20184@linux-mips.org> References: <20060607105221.7b15b243.vitalywool@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060607105221.7b15b243.vitalywool@gmail.com> User-Agent: Mutt/1.4.2.1i Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11684 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ralf@linux-mips.org Precedence: bulk X-list: linux-mips On Wed, Jun 07, 2006 at 10:52:21AM +0400, Vitaly Wool wrote: > when I try to compile Linux kernel for pnx8550 in 2.6.17-rc4, I get the following error: > > CC arch/mips/philips/pnx8550/common/setup.o > /home/vital/work/opensource/mtd/arch/mips/philips/pnx8550/common/setup.c: In function `plat_setup': > /home/vital/work/opensource/mtd/arch/mips/philips/pnx8550/common/setup.c:133: warning: implicit declaration of function `ip3106_lcr' > /home/vital/work/opensource/mtd/arch/mips/philips/pnx8550/common/setup.c:134: error: invalid lvalue in assignment > /home/vital/work/opensource/mtd/arch/mips/philips/pnx8550/common/setup.c:135: warning: implicit declaration of function `ip3106_baud' > /home/vital/work/opensource/mtd/arch/mips/philips/pnx8550/common/setup.c:135: error: invalid lvalue in assignment > make[2]: *** [arch/mips/philips/pnx8550/common/setup.o] Error 1 > make[1]: *** [arch/mips/philips/pnx8550/common] Error 2 > make: *** [vmlinux] Error 2 > > I guess it's not what it should be ;-) This seems to be one of the serial bits for the ip3106 which must have been lost on the way to kernel.org. Unfortunately the original author does no longer take care of the code. I just took a stab at the PNX8550 code and it has a significant number of other problems. All small in the sum large enough such that I will mark PNX8550 support broken. Ralf [MIPS] Mark PNX8550 support broken. Broken in too many way for me to fix it for 2.6.17. Signed-off-by: Ralf Baechle diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig index 0e25c1d..d87177f 100644 --- a/arch/mips/Kconfig +++ b/arch/mips/Kconfig @@ -440,12 +440,12 @@ config MIPS_XXS1500 config PNX8550_V2PCI bool "Philips PNX8550 based Viper2-PCI board" - select PNX8550 + select PNX8550 && BROKEN select SYS_SUPPORTS_LITTLE_ENDIAN config PNX8550_JBS bool "Philips PNX8550 based JBS board" - select PNX8550 + select PNX8550 && BROKEN select SYS_SUPPORTS_LITTLE_ENDIAN config DDB5074 From david-b@pacbell.net Wed Jun 7 15:28:09 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 07 Jun 2006 15:28:17 +0100 (BST) Received: from smtp106.sbc.mail.mud.yahoo.com ([68.142.198.205]:29310 "HELO smtp106.sbc.mail.mud.yahoo.com") by ftp.linux-mips.org with SMTP id S8134010AbWFGO2J (ORCPT ); Wed, 7 Jun 2006 15:28:09 +0100 Received: (qmail 16499 invoked from network); 7 Jun 2006 14:27:59 -0000 Received: from unknown (HELO ascent-enet) (david-b@pacbell.net@69.226.238.181 with plain) by smtp106.sbc.mail.mud.yahoo.com with SMTP; 7 Jun 2006 14:27:58 -0000 From: David Brownell To: linux-usb-devel@lists.sourceforge.net Subject: Re: [linux-usb-devel] [PATCH] Fix OHCI HCD build for PNX 8550 Date: Wed, 7 Jun 2006 07:27:56 -0700 User-Agent: KMail/1.7.1 Cc: Ralf Baechle , gregkh@suse.de, linux-mips@linux-mips.org References: <20060607135922.GA26754@linux-mips.org> In-Reply-To: <20060607135922.GA26754@linux-mips.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200606070727.57618.david-b@pacbell.net> Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11685 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: david-b@pacbell.net Precedence: bulk X-list: linux-mips On Wednesday 07 June 2006 6:59 am, Ralf Baechle wrote: > The PNX8550 OHCI is a platform device so we better include the necessary > headers. PNX ohci support has not been submitted upstream yet... just merge this with that patch before submitting. From ralf@linux-mips.org Wed Jun 7 15:37:22 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 07 Jun 2006 15:37:29 +0100 (BST) Received: from localhost.localdomain ([127.0.0.1]:23430 "EHLO bacchus.dhis.org") by ftp.linux-mips.org with ESMTP id S8134007AbWFGOhW (ORCPT ); Wed, 7 Jun 2006 15:37:22 +0100 Received: from denk.linux-mips.net (denk.linux-mips.net [127.0.0.1]) by bacchus.dhis.org (8.13.6/8.13.4) with ESMTP id k57EbMF5031686; Wed, 7 Jun 2006 15:37:22 +0100 Received: (from ralf@localhost) by denk.linux-mips.net (8.13.6/8.13.6/Submit) id k57EbLGQ031685; Wed, 7 Jun 2006 15:37:21 +0100 Date: Wed, 7 Jun 2006 15:37:21 +0100 From: Ralf Baechle To: David Brownell Cc: linux-usb-devel@lists.sourceforge.net, gregkh@suse.de, linux-mips@linux-mips.org Subject: Re: [linux-usb-devel] [PATCH] Fix OHCI HCD build for PNX 8550 Message-ID: <20060607143721.GA31497@linux-mips.org> References: <20060607135922.GA26754@linux-mips.org> <200606070727.57618.david-b@pacbell.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200606070727.57618.david-b@pacbell.net> User-Agent: Mutt/1.4.2.1i Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11686 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ralf@linux-mips.org Precedence: bulk X-list: linux-mips On Wed, Jun 07, 2006 at 07:27:56AM -0700, David Brownell wrote: > On Wednesday 07 June 2006 6:59 am, Ralf Baechle wrote: > > The PNX8550 OHCI is a platform device so we better include the necessary > > headers. > > PNX ohci support has not been submitted upstream yet... just merge this > with that patch before submitting. Whops. Well, I discovered alot more breakage that this one so I'll abstain and leave the fixing to others that actually have hardware ... Ralf From ppopov@embeddedalley.com Wed Jun 7 15:57:00 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 07 Jun 2006 15:57:07 +0100 (BST) Received: from adsl-71-128-175-242.dsl.pltn13.pacbell.net ([71.128.175.242]:33949 "EHLO build.embeddedalley.com") by ftp.linux-mips.org with ESMTP id S8134014AbWFGO5A (ORCPT ); Wed, 7 Jun 2006 15:57:00 +0100 Received: from localhost.localdomain (build.embeddedalley.com [127.0.0.1]) by build.embeddedalley.com (8.13.1/8.13.1) with ESMTP id k57Esc9c019601; Wed, 7 Jun 2006 07:54:40 -0700 Subject: Re: [linux-usb-devel] [PATCH] Fix OHCI HCD build for PNX 8550 From: Pete Popov Reply-To: ppopov@embeddedalley.com To: Ralf Baechle Cc: David Brownell , linux-usb-devel@lists.sourceforge.net, gregkh@suse.de, linux-mips@linux-mips.org In-Reply-To: <20060607143721.GA31497@linux-mips.org> References: <20060607135922.GA26754@linux-mips.org> <200606070727.57618.david-b@pacbell.net> <20060607143721.GA31497@linux-mips.org> Content-Type: text/plain Organization: Embedded Alley Solutions, Inc Date: Wed, 07 Jun 2006 17:56:47 +0300 Message-Id: <1149692207.18925.259.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.4.1 Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11687 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ppopov@embeddedalley.com Precedence: bulk X-list: linux-mips On Wed, 2006-06-07 at 15:37 +0100, Ralf Baechle wrote: > On Wed, Jun 07, 2006 at 07:27:56AM -0700, David Brownell wrote: > > > On Wednesday 07 June 2006 6:59 am, Ralf Baechle wrote: > > > The PNX8550 OHCI is a platform device so we better include the necessary > > > headers. > > > > PNX ohci support has not been submitted upstream yet... just merge this > > with that patch before submitting. > > Whops. Well, I discovered alot more breakage that this one so I'll > abstain and leave the fixing to others that actually have hardware ... I'll talk to Philips to see how they want to handle the maintenance of the 8550. Thanks, Pete From anemo@mba.ocn.ne.jp Wed Jun 7 15:57:53 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 07 Jun 2006 15:58:01 +0100 (BST) Received: from mba.ocn.ne.jp ([210.190.142.172]:35815 "HELO smtp.mba.ocn.ne.jp") by ftp.linux-mips.org with SMTP id S8134013AbWFGO5x (ORCPT ); Wed, 7 Jun 2006 15:57:53 +0100 Received: from localhost (p3137-ipad208funabasi.chiba.ocn.ne.jp [60.43.104.137]) by smtp.mba.ocn.ne.jp (Postfix) with ESMTP id 33060A6A9; Wed, 7 Jun 2006 23:57:48 +0900 (JST) Date: Wed, 07 Jun 2006 23:58:45 +0900 (JST) Message-Id: <20060607.235845.128616718.anemo@mba.ocn.ne.jp> To: eckhardt@satorlaser.com Cc: linux-mips@linux-mips.org Subject: Re: [PATCH] fix some compiler warnings (field width, unused variable) From: Atsushi Nemoto In-Reply-To: <200606071103.34646.eckhardt@satorlaser.com> References: <20060602.015404.93020143.anemo@mba.ocn.ne.jp> <200606071103.34646.eckhardt@satorlaser.com> X-Fingerprint: 6ACA 1623 39BD 9A94 9B1A B746 CA77 FE94 2874 D52F X-Pgp-Public-Key: http://wwwkeys.pgp.net/pks/lookup?op=get&search=0x2874D52F X-Mailer: Mew version 3.3 on Emacs 21.4 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11688 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: anemo@mba.ocn.ne.jp Precedence: bulk X-list: linux-mips On Wed, 7 Jun 2006 11:03:34 +0200, Ulrich Eckhardt wrote: > I'm not so sure if this is a good idea because some systems have 36 > bit physical addresses while they only have 32 bit void pointers, so > long long is probably really the better solution. In general, it would be better to use "long long" for 32bit physical address. For this particular code, both values are "unsigned long" so casting to "void *" for printing should be safe anyway. > I'm wondering if it would be worth having a special flag in printk > to indicate a physical address ("%lp" perhaps?) so that you don't > get the unimportant leading zeroes for the bits 36 to 63 for above > mentioned platforms. It might raise some new gcc/sparse warnings about format strings :-) --- Atsushi Nemoto From reservas@morrodaspedras.com Wed Jun 7 16:29:14 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 07 Jun 2006 16:29:23 +0100 (BST) Received: from hm397.locaweb.com.br ([200.234.205.160]:41178 "HELO hm397.locaweb.com.br") by ftp.linux-mips.org with SMTP id S8133722AbWFGP3O (ORCPT ); Wed, 7 Jun 2006 16:29:14 +0100 Received: (qmail 1589 invoked from network); 7 Jun 2006 15:29:05 -0000 Received: from unknown (10.1.10.191) by hm397.locaweb.com.br with QMQP; 7 Jun 2006 15:29:05 -0000 Received: from unknown (HELO p3) (reservas@morrodaspedras.com@200.138.224.4) by hm191.locaweb.com.br with SMTP; 7 Jun 2006 15:29:15 -0000 Message-ID: <01c201c68a47$1beaed90$7d01010a@p3> From: To: "Ralf Baechle" , "Vitaly Wool" Cc: , References: <20060607105221.7b15b243.vitalywool@gmail.com> <20060607142702.GA20184@linux-mips.org> Subject: Re: PNX8550 fails to compile in 2.6.17-rc4 Date: Wed, 7 Jun 2006 12:29:03 -0300 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_01BF_01C68A2D.F621F5E0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11689 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: reservas@morrodaspedras.com Precedence: bulk X-list: linux-mips This is a multi-part message in MIME format. ------=_NextPart_000_01BF_01C68A2D.F621F5E0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Please, dont wright no more for me. Tanks. ----- Original Message -----=20 From: Ralf Baechle=20 To: Vitaly Wool=20 Cc: linux-kernel@vger.kernel.org ; linux-mips@linux-mips.org=20 Sent: Wednesday, June 07, 2006 11:27 AM Subject: Re: PNX8550 fails to compile in 2.6.17-rc4 On Wed, Jun 07, 2006 at 10:52:21AM +0400, Vitaly Wool wrote: > when I try to compile Linux kernel for pnx8550 in 2.6.17-rc4, I get = the following error: >=20 > CC arch/mips/philips/pnx8550/common/setup.o > = /home/vital/work/opensource/mtd/arch/mips/philips/pnx8550/common/setup.c:= In function `plat_setup': > = /home/vital/work/opensource/mtd/arch/mips/philips/pnx8550/common/setup.c:= 133: warning: implicit declaration of function `ip3106_lcr' > = /home/vital/work/opensource/mtd/arch/mips/philips/pnx8550/common/setup.c:= 134: error: invalid lvalue in assignment > = /home/vital/work/opensource/mtd/arch/mips/philips/pnx8550/common/setup.c:= 135: warning: implicit declaration of function `ip3106_baud' > = /home/vital/work/opensource/mtd/arch/mips/philips/pnx8550/common/setup.c:= 135: error: invalid lvalue in assignment > make[2]: *** [arch/mips/philips/pnx8550/common/setup.o] Error 1 > make[1]: *** [arch/mips/philips/pnx8550/common] Error 2 > make: *** [vmlinux] Error 2 >=20 > I guess it's not what it should be ;-) This seems to be one of the serial bits for the ip3106 which must have been lost on the way to kernel.org. Unfortunately the original author does no longer take care of the code. I just took a stab at the = PNX8550 code and it has a significant number of other problems. All small in the sum large enough such that I will mark PNX8550 support broken. Ralf [MIPS] Mark PNX8550 support broken. =20 Broken in too many way for me to fix it for 2.6.17. Signed-off-by: Ralf Baechle diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig index 0e25c1d..d87177f 100644 --- a/arch/mips/Kconfig +++ b/arch/mips/Kconfig @@ -440,12 +440,12 @@ config MIPS_XXS1500 =20 config PNX8550_V2PCI bool "Philips PNX8550 based Viper2-PCI board" - select PNX8550 + select PNX8550 && BROKEN select SYS_SUPPORTS_LITTLE_ENDIAN =20 config PNX8550_JBS bool "Philips PNX8550 based JBS board" - select PNX8550 + select PNX8550 && BROKEN select SYS_SUPPORTS_LITTLE_ENDIAN =20 config DDB5074 - To unsubscribe from this list: send the line "unsubscribe = linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ --=20 No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.1.394 / Virus Database: 268.8.2/357 - Release Date: = 6/6/2006 ------=_NextPart_000_01BF_01C68A2D.F621F5E0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Please, dont wright no more for me. = Tanks.
----- Original Message -----
From:=20 Ralf=20 Baechle
Sent: Wednesday, June 07, 2006 = 11:27=20 AM
Subject: Re: PNX8550 fails to = compile in=20 2.6.17-rc4

On Wed, Jun 07, 2006 at 10:52:21AM +0400, Vitaly Wool=20 wrote:

> when I try to compile Linux kernel for pnx8550 in=20 2.6.17-rc4, I get the following error:
>
>  =20 CC     =20 arch/mips/philips/pnx8550/common/setup.o
>=20 = /home/vital/work/opensource/mtd/arch/mips/philips/pnx8550/common/setup.c:= In=20 function `plat_setup':
>=20 = /home/vital/work/opensource/mtd/arch/mips/philips/pnx8550/common/setup.c:= 133:=20 warning: implicit declaration of function `ip3106_lcr'
>=20 = /home/vital/work/opensource/mtd/arch/mips/philips/pnx8550/common/setup.c:= 134:=20 error: invalid lvalue in assignment
>=20 = /home/vital/work/opensource/mtd/arch/mips/philips/pnx8550/common/setup.c:= 135:=20 warning: implicit declaration of function `ip3106_baud'
>=20 = /home/vital/work/opensource/mtd/arch/mips/philips/pnx8550/common/setup.c:= 135:=20 error: invalid lvalue in assignment
> make[2]: ***=20 [arch/mips/philips/pnx8550/common/setup.o] Error 1
> make[1]: = ***=20 [arch/mips/philips/pnx8550/common] Error 2
> make: *** [vmlinux] = Error=20 2
>
> I guess it's not what it should be ;-)

This = seems to=20 be one of the serial bits for the ip3106 which must have
been lost = on the=20 way to kernel.org.  Unfortunately the original author
does no = longer=20 take care of the code.  I just took a stab at the PNX8550
code = and it=20 has a significant number of other problems.  All small in
the = sum=20 large enough such that I will mark PNX8550 support = broken.

 =20 Ralf

[MIPS] Mark PNX8550 support broken.
   =20
Broken in too many way for me to fix it for = 2.6.17.

Signed-off-by:=20 Ralf Baechle <ralf@linux-mips.org>

di= ff=20 --git a/arch/mips/Kconfig b/arch/mips/Kconfig
index = 0e25c1d..d87177f=20 100644
--- a/arch/mips/Kconfig
+++ b/arch/mips/Kconfig
@@ = -440,12=20 +440,12 @@ config MIPS_XXS1500
 
 config=20 PNX8550_V2PCI
  bool "Philips PNX8550 based Viper2-PCI = board"
-=20 select PNX8550
+ select PNX8550 && BROKEN
  select=20 SYS_SUPPORTS_LITTLE_ENDIAN
 
 config = PNX8550_JBS
 =20 bool "Philips PNX8550 based JBS board"
- select PNX8550
+ select = PNX8550=20 && BROKEN
  select=20 SYS_SUPPORTS_LITTLE_ENDIAN
 
 config = DDB5074
-
To=20 unsubscribe from this list: send the line "unsubscribe linux-kernel" = in
the=20 body of a message to majordomo@vger.kernel.orgMore=20 majordomo info at  http://vger.kernel.or= g/majordomo-info.html
Please=20 read the FAQ at  http://www.tux.org/lkml/


--=20
No virus found in this incoming message.
Checked by AVG Free=20 Edition.
Version: 7.1.394 / Virus Database: 268.8.2/357 - Release = Date:=20 6/6/2006
------=_NextPart_000_01BF_01C68A2D.F621F5E0-- From ralf@linux-mips.org Wed Jun 7 16:35:21 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 07 Jun 2006 16:35:28 +0100 (BST) Received: from localhost.localdomain ([127.0.0.1]:39066 "EHLO bacchus.dhis.org") by ftp.linux-mips.org with ESMTP id S8134010AbWFGPfV (ORCPT ); Wed, 7 Jun 2006 16:35:21 +0100 Received: from denk.linux-mips.net (denk.linux-mips.net [127.0.0.1]) by bacchus.dhis.org (8.13.6/8.13.4) with ESMTP id k57FZK1V001188; Wed, 7 Jun 2006 16:35:20 +0100 Received: (from ralf@localhost) by denk.linux-mips.net (8.13.6/8.13.6/Submit) id k57FZImm001187; Wed, 7 Jun 2006 16:35:18 +0100 Date: Wed, 7 Jun 2006 16:35:18 +0100 From: Ralf Baechle To: reservas@morrodaspedras.com Cc: Vitaly Wool , linux-kernel@vger.kernel.org, linux-mips@linux-mips.org Subject: Re: PNX8550 fails to compile in 2.6.17-rc4 Message-ID: <20060607153518.GA21387@linux-mips.org> References: <20060607105221.7b15b243.vitalywool@gmail.com> <20060607142702.GA20184@linux-mips.org> <01c201c68a47$1beaed90$7d01010a@p3> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <01c201c68a47$1beaed90$7d01010a@p3> User-Agent: Mutt/1.4.2.1i Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11690 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ralf@linux-mips.org Precedence: bulk X-list: linux-mips On Wed, Jun 07, 2006 at 12:29:03PM -0300, reservas@morrodaspedras.com wrote: > > Please, dont wright no more for me. Tanks. Then don't subscribe to mailing lists or have word with the person who did. And since you don't seem to look at mail headers, we did not write to you personally. Ralf From anemo@mba.ocn.ne.jp Wed Jun 7 17:08:07 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 07 Jun 2006 17:08:18 +0100 (BST) Received: from mba.ocn.ne.jp ([210.190.142.172]:15078 "HELO smtp.mba.ocn.ne.jp") by ftp.linux-mips.org with SMTP id S8134014AbWFGQIH (ORCPT ); Wed, 7 Jun 2006 17:08:07 +0100 Received: from localhost (p3137-ipad208funabasi.chiba.ocn.ne.jp [60.43.104.137]) by smtp.mba.ocn.ne.jp (Postfix) with ESMTP id BBE13881E; Thu, 8 Jun 2006 01:08:03 +0900 (JST) Date: Thu, 08 Jun 2006 01:09:01 +0900 (JST) Message-Id: <20060608.010901.108121387.anemo@mba.ocn.ne.jp> To: ralf@linux-mips.org Cc: linux-mips@linux-mips.org Subject: Re: cpu_idle and cpu_wait From: Atsushi Nemoto In-Reply-To: <20051118.122242.07017522.nemoto@toshiba-tops.co.jp> References: <20051117.011906.25910026.anemo@mba.ocn.ne.jp> <20051116184201.GJ3229@linux-mips.org> <20051118.122242.07017522.nemoto@toshiba-tops.co.jp> X-Fingerprint: 6ACA 1623 39BD 9A94 9B1A B746 CA77 FE94 2874 D52F X-Pgp-Public-Key: http://wwwkeys.pgp.net/pks/lookup?op=get&search=0x2874D52F X-Mailer: Mew version 3.3 on Emacs 21.4 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11691 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: anemo@mba.ocn.ne.jp Precedence: bulk X-list: linux-mips On Fri, 18 Nov 2005 12:22:42 +0900 (JST), Atsushi Nemoto wrote: > By datasheets, MIPS4K?, MIPS5Kc, TX49 (and TX39 using HALT bit instead > of WAIT insn) allow us entering WAIT with interrupt disabled. Updated against current git tree. [MIPS] reduce race between cpu_wait() and need_resched() checking If a thread became runnable between need_resched() and the WAIT instruction, switching to the thread will delay until a next interrupt. Some CPUs can execute the WAIT instruction with interrupt disabled, so we can get rid of this race on them (at least UP case). Signed-off-by: Atsushi Nemoto diff --git a/arch/mips/kernel/cpu-probe.c b/arch/mips/kernel/cpu-probe.c index 66e47e7..bc79c5b 100644 --- a/arch/mips/kernel/cpu-probe.c +++ b/arch/mips/kernel/cpu-probe.c @@ -39,16 +39,33 @@ static void r3081_wait(void) static void r39xx_wait(void) { - unsigned long cfg = read_c0_conf(); - write_c0_conf(cfg | TX39_CONF_HALT); + local_irq_disable(); + if (!need_resched()) + write_c0_conf(read_c0_conf() | TX39_CONF_HALT); + local_irq_enable(); } +/* + * There is a race when WAIT instruction executed with interrupt + * enabled. + * But it is implementation-dependent wheter the pipelie restarts when + * a non-enabled interrupt is requested. + */ static void r4k_wait(void) { __asm__(".set\tmips3\n\t" "wait\n\t" ".set\tmips0"); } +static void r4k_wait_irqoff(void) +{ + local_irq_disable(); + if (!need_resched()) + __asm__(".set\tmips3\n\t" + "wait\n\t" + ".set\tmips0"); + local_irq_enable(); +} /* The Au1xxx wait is available only if using 32khz counter or * external timer source, but specifically not CP0 Counter. */ @@ -111,11 +128,6 @@ static inline void check_wait(void) case CPU_R5000: case CPU_NEVADA: case CPU_RM7000: - case CPU_TX49XX: - case CPU_4KC: - case CPU_4KEC: - case CPU_4KSC: - case CPU_5KC: /* case CPU_20KC:*/ case CPU_24K: case CPU_25KF: @@ -125,6 +137,14 @@ static inline void check_wait(void) cpu_wait = r4k_wait; printk(" available.\n"); break; + case CPU_TX49XX: + case CPU_4KC: + case CPU_4KEC: + case CPU_4KSC: + case CPU_5KC: + cpu_wait = r4k_wait_irqoff; + printk(" available.\n"); + break; case CPU_AU1000: case CPU_AU1100: case CPU_AU1500: From imipak@yahoo.com Wed Jun 7 18:22:59 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 07 Jun 2006 18:23:08 +0100 (BST) Received: from web31512.mail.mud.yahoo.com ([68.142.198.141]:33433 "HELO web31512.mail.mud.yahoo.com") by ftp.linux-mips.org with SMTP id S8134021AbWFGRW7 (ORCPT ); Wed, 7 Jun 2006 18:22:59 +0100 Received: (qmail 47983 invoked by uid 60001); 7 Jun 2006 17:22:52 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=MlgPv92hWxCOwMvaKhPd8NiHUARnfJI6sowEeoBqiU0zx458zbXnyT0xDWeLXbnOfRSk2QNKhGyNeHImJ/OYKvIC608i2aycAdGWeziXqUdwig6bgoteohtyAmPNOoUzYyGMcrmg0eQfIwtiT+eCg5pll7W2Lw/j8s/va5K70MI= ; Message-ID: <20060607172252.47981.qmail@web31512.mail.mud.yahoo.com> Received: from [208.187.37.98] by web31512.mail.mud.yahoo.com via HTTP; Wed, 07 Jun 2006 10:22:52 PDT Date: Wed, 7 Jun 2006 10:22:52 -0700 (PDT) From: Jonathan Day Subject: Performance counters and profiling on MIPS To: linux-mips@linux-mips.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11692 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: imipak@yahoo.com Precedence: bulk X-list: linux-mips hi, Two quick and semi-related questions for the Gurus of the MIPS. First off, it would appear that profiling on any of the Broadcom MIPS processors is broken. I get the following warnings when compiling the platform-specific irq.c file: CC arch/mips/sibyte/sb1250/irq.o arch/mips/sibyte/sb1250/irq.c: In function 'plat_irq_dispatch': arch/mips/sibyte/sb1250/irq.c:462: warning: implicit declaration of function 'sbprof_cpu_intr' arch/mips/sibyte/sb1250/irq.c:467: warning: implicit declaration of function 'sb1250_timer_interrupt' arch/mips/sibyte/sb1250/irq.c:471: warning: implicit declaration of function 'sb1250_mailbox_interrupt' On linking, it's revealed why the declarations are implicit: arch/mips/sibyte/sb1250/built-in.o: In function `plat_irq_dispatch': arch/mips/sibyte/sb1250/irq.c:462: undefined reference to `sbprof_cpu_intr' arch/mips/sibyte/sb1250/irq.c:462: relocation truncated to fit: R_MIPS_26 against `sbprof_cpu_intr' arch/mips/sibyte/sb1250/irq.c:462: undefined reference to `sbprof_cpu_intr' arch/mips/sibyte/sb1250/irq.c:462: relocation truncated to fit: R_MIPS_26 against `sbprof_cpu_intr' Actually, with the code as it is in the git repository, you will also get: arch/mips/sibyte/sb1250/irq.c:461: undefined reference to `exception_epc' But this can be fixed by adding the following line to irq.c in the asm block of includes: #include The primary function, sbprof_cpu_intr(), seems to be missing. It is called in the bcm1480 and sb1250 versions of irq.c. I looked but couldn't see anything comparable in any other Sibyte directories, any other MIPS architectures in general, or indeed in any other architecture in general. The ZBus profiling is also broken, showing some signs of being a little stale. This one's not quite so important to me, but it would still be very useful: arch/mips/sibyte/sb1250/bcm1250_tbprof.c: In function 'sbprof_tb_ioctl': arch/mips/sibyte/sb1250/bcm1250_tbprof.c:362: error: expected expression before 'wait_queue_t' arch/mips/sibyte/sb1250/bcm1250_tbprof.c:363: error: 'wait' undeclared (first use in this function) arch/mips/sibyte/sb1250/bcm1250_tbprof.c:363: error: (Each undeclared identifier is reported only once arch/mips/sibyte/sb1250/bcm1250_tbprof.c:363: error: for each function it appears in.) arch/mips/sibyte/sb1250/bcm1250_tbprof.c: In function 'sbprof_tb_init': arch/mips/sibyte/sb1250/bcm1250_tbprof.c:396: warning: format '%lld' expects type 'long long int', but argument 2 has type 'u_int64_t' Ok, so my first question is: who (if anyone) is working on the profiling code and are there any patches - regardless of how experimental - that will get this part of the code working? My second question is with regards to accessing the performance counters and timestamp counters from userspace. On some architectures, this is as simple as using a single macro. In the case of the ix86 architecture (yuk!), the timestamp counters can be read with nothing more than an rdtsc() call, as follows: asm volatile ("rdtsc" : "=a"(*(elg_ui4 *)&clock_value), "=d"(*(((elg_ui4 *)&clock_value)+1))); What is the closest equiv. for the MIPS processors? Jonathan __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From wilson@specifix.com Wed Jun 7 19:40:38 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 07 Jun 2006 19:40:46 +0100 (BST) Received: from w099.z064220152.sjc-ca.dsl.cnc.net ([64.220.152.99]:40162 "HELO duck.specifix.com") by ftp.linux-mips.org with SMTP id S8134026AbWFGSki (ORCPT ); Wed, 7 Jun 2006 19:40:38 +0100 Received: from [127.0.0.1] (duck.corp.specifix.com [192.168.1.1]) by duck.specifix.com (Postfix) with ESMTP id 9BAA5FC4E; Wed, 7 Jun 2006 11:40:22 -0700 (PDT) Subject: Re: RTL explaination From: James E Wilson To: kernel coder Cc: linux-mips@linux-mips.org In-Reply-To: References: Content-Type: text/plain Message-Id: <1149705622.17313.15.camel@aretha.corp.specifix.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Wed, 07 Jun 2006 11:40:22 -0700 Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11693 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: wilson@specifix.com Precedence: bulk X-list: linux-mips On Wed, 2006-06-07 at 05:56, kernel coder wrote: > [0 a+0 S4 A32])) -1 (nil) This is a relatively recent addition to the RTL. The older parts of the documentation won't refer to them. This is memory aliasing info. The a+0 is the variable+offset. The A32 is the alignment, 32-bits. The S4 is the size, 4-bytes. The "0" is the alias set. Objects are grouped into sets, where each item in the set may alias any other item in the set. Since you have only one item, it is in set 0. In the gcc sources, see the MEM_ALIAS_SET, MEM_EXPR, MEM_OFFSET, MEM_SIZE, and MEM_ALIGN attributes for mem rtx. This kind of question should probably go to the gcc@gcc.gnu.org list instead of a linux kernel list. -- Jim Wilson, GNU Tools Support, http://www.specifix.com From joseph@codesourcery.com Thu Jun 8 02:36:40 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 08 Jun 2006 02:36:49 +0100 (BST) Received: from intranet.codesourcery.com ([65.74.133.6]:44193 "EHLO mail.codesourcery.com") by ftp.linux-mips.org with ESMTP id S8134038AbWFHBgk (ORCPT ); Thu, 8 Jun 2006 02:36:40 +0100 Received: (qmail 27433 invoked from network); 8 Jun 2006 01:36:30 -0000 Received: from unknown (HELO digraph.polyomino.org.uk) (joseph@127.0.0.2) by mail.codesourcery.com with ESMTPA; 8 Jun 2006 01:36:30 -0000 Received: from jsm28 (helo=localhost) by digraph.polyomino.org.uk with local-esmtp (Exim 4.52) id 1Fo9Rl-0000os-R3 for linux-mips@linux-mips.org; Thu, 08 Jun 2006 01:36:29 +0000 Date: Thu, 8 Jun 2006 01:36:29 +0000 (UTC) From: "Joseph S. Myers" X-X-Sender: jsm28@digraph.polyomino.org.uk To: linux-mips@linux-mips.org Subject: N32 sigset and __COMPAT_ENDIAN_SWAP__ Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11694 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: joseph@codesourcery.com Precedence: bulk X-list: linux-mips I'm testing glibc on MIPS64, little-endian, N32, O32 and N64 multilibs. Among the NPTL test failures seen are some arising from sigsuspend problems for N32: it blocks the wrong signals, so SIGCANCEL (SIGRTMIN) is blocked despite glibc's carefully excluding it from sets of signals to block. Specifically, testing suggests it blocks signal N^32 instead of signal N, so (in the example tested) blocking SIGUSR1 (17) blocks signal 49 instead. glibc's sigset_t uses an array of unsigned long, as does the kernel. In both cases, signal N+1 is represented as (1UL << (N % (8 * sizeof (unsigned long)))) in word number (N / (8 * sizeof (unsigned long))). Thus the N32 glibc uses an array of 32-bit words and the N64 kernel uses an array of 64-bit words. For little-endian, the layout is the same, with signals 1-32 in the first 4 bytes, signals 33-64 in the second, etc.; for big-endian, userspace has that layout while in the kernel each 8 bytes have the two halves swapped from the userspace layout. The N32 sigsuspend syscall uses sigset_from_compat to convert the userspace sigset to kernel format. If __COMPAT_ENDIAN_SWAP__ is *not* set, this uses logic of the form set->sig[0] = compat->sig[0] | (((long)compat->sig[1]) << 32 ) to convert the userspace sigset to a kernel one. This looks correct to me for both big and little endian, given that in userspace compat->sig[1] will represent signals 33-64, and so will the high 32 bits of set->sig[0] in the kernel. If however __COMPAT_ENDIAN_SWAP__ *is* set, as it is for __MIPSEL__, it uses set->sig[0] = compat->sig[1] | (((long)compat->sig[0]) << 32 ); which seems incorrect for both big and little endian, and would explain the observed symptoms. This code is the only use of __COMPAT_ENDIAN_SWAP__, so if incorrect then that macro serves no purpose, in which case something like the following patch would seem appropriate to remove it. Signed-off-by: Joseph Myers --- diff -rupN linux-2.6.17-rc6.orig/include/asm-mips/compat.h linux-2.6.17-rc6/include/asm-mips/compat.h --- linux-2.6.17-rc6.orig/include/asm-mips/compat.h 2006-06-08 01:05:13.000000000 +0000 +++ linux-2.6.17-rc6/include/asm-mips/compat.h 2006-06-08 01:04:10.000000000 +0000 @@ -145,8 +145,5 @@ static inline void __user *compat_alloc_ return (void __user *) (regs->regs[29] - len); } -#if defined (__MIPSEL__) -#define __COMPAT_ENDIAN_SWAP__ 1 -#endif #endif /* _ASM_COMPAT_H */ diff -rupN linux-2.6.17-rc6.orig/kernel/compat.c linux-2.6.17-rc6/kernel/compat.c --- linux-2.6.17-rc6.orig/kernel/compat.c 2006-06-08 01:05:13.000000000 +0000 +++ linux-2.6.17-rc6/kernel/compat.c 2006-06-08 01:03:47.000000000 +0000 @@ -729,17 +729,10 @@ void sigset_from_compat (sigset_t *set, compat_sigset_t *compat) { switch (_NSIG_WORDS) { -#if defined (__COMPAT_ENDIAN_SWAP__) - case 4: set->sig[3] = compat->sig[7] | (((long)compat->sig[6]) << 32 ); - case 3: set->sig[2] = compat->sig[5] | (((long)compat->sig[4]) << 32 ); - case 2: set->sig[1] = compat->sig[3] | (((long)compat->sig[2]) << 32 ); - case 1: set->sig[0] = compat->sig[1] | (((long)compat->sig[0]) << 32 ); -#else case 4: set->sig[3] = compat->sig[6] | (((long)compat->sig[7]) << 32 ); case 3: set->sig[2] = compat->sig[4] | (((long)compat->sig[5]) << 32 ); case 2: set->sig[1] = compat->sig[2] | (((long)compat->sig[3]) << 32 ); case 1: set->sig[0] = compat->sig[0] | (((long)compat->sig[1]) << 32 ); -#endif } } -- Joseph S. Myers joseph@codesourcery.com From kumba@gentoo.org Thu Jun 8 03:25:52 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 08 Jun 2006 03:26:04 +0100 (BST) Received: from sccrmhc11.comcast.net ([63.240.77.81]:37279 "EHLO sccrmhc11.comcast.net") by ftp.linux-mips.org with ESMTP id S8126480AbWFHCZw (ORCPT ); Thu, 8 Jun 2006 03:25:52 +0100 Received: from [127.0.0.1] (unknown[69.140.185.142]) by comcast.net (sccrmhc11) with ESMTP id <2006060802254201100fobdde>; Thu, 8 Jun 2006 02:25:46 +0000 Message-ID: <44878AAA.20007@gentoo.org> Date: Wed, 07 Jun 2006 22:25:46 -0400 From: Kumba User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: "Joseph S. Myers" CC: linux-mips@linux-mips.org Subject: Re: N32 sigset and __COMPAT_ENDIAN_SWAP__ References: In-Reply-To: Content-Type: multipart/mixed; boundary="------------020308000807030801070508" Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11695 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: kumba@gentoo.org Precedence: bulk X-list: linux-mips This is a multi-part message in MIME format. --------------020308000807030801070508 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Joseph S. Myers wrote: > I'm testing glibc on MIPS64, little-endian, N32, O32 and N64 > multilibs. > > Among the NPTL test failures seen are some arising from sigsuspend > problems for N32: it blocks the wrong signals, so SIGCANCEL (SIGRTMIN) > is blocked despite glibc's carefully excluding it from sets of signals > to block. Specifically, testing suggests it blocks signal N^32 > instead of signal N, so (in the example tested) blocking SIGUSR1 (17) > blocks signal 49 instead. > > glibc's sigset_t uses an array of unsigned long, as does the kernel. > In both cases, signal N+1 is represented as > (1UL << (N % (8 * sizeof (unsigned long)))) in word number > (N / (8 * sizeof (unsigned long))). > > Thus the N32 glibc uses an array of 32-bit words and the N64 kernel > uses an array of 64-bit words. For little-endian, the layout is the > same, with signals 1-32 in the first 4 bytes, signals 33-64 in the > second, etc.; for big-endian, userspace has that layout while in the > kernel each 8 bytes have the two halves swapped from the userspace > layout. > > The N32 sigsuspend syscall uses sigset_from_compat to convert the > userspace sigset to kernel format. If __COMPAT_ENDIAN_SWAP__ is *not* > set, this uses logic of the form > > set->sig[0] = compat->sig[0] | (((long)compat->sig[1]) << 32 ) > > to convert the userspace sigset to a kernel one. This looks correct > to me for both big and little endian, given that in userspace > compat->sig[1] will represent signals 33-64, and so will the high 32 > bits of set->sig[0] in the kernel. If however __COMPAT_ENDIAN_SWAP__ > *is* set, as it is for __MIPSEL__, it uses > > set->sig[0] = compat->sig[1] | (((long)compat->sig[0]) << 32 ); > > which seems incorrect for both big and little endian, and would > explain the observed symptoms. > > This code is the only use of __COMPAT_ENDIAN_SWAP__, so if incorrect > then that macro serves no purpose, in which case something like the > following patch would seem appropriate to remove it. You might find the attached patch of interest. We've been using it gentoo-side for awhile now, as it allowed some N32 programs to work correctly. Namely, a configure test in glib would trigger a non-fatal oops in the kernel due to an issue this patch fixes. Daniel Jacobwitz wrote it up when he apparently stumbled across the issue (something wonky in n32's sigsuspend, as the name indicates. I forget the specifics, though), but I'm unsure if the issue is in any way connected to what you're seeing as well. --Kumba -- Gentoo/MIPS Team Lead Gentoo Foundation Board of Trustees "Such is oft the course of deeds that move the wheels of the world: small hands do them because they must, while the eyes of the great are elsewhere." --Elrond --------------020308000807030801070508 Content-Type: text/plain; name="misc-2.6.13-n32-fix-sigsuspend.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="misc-2.6.13-n32-fix-sigsuspend.patch" diff -Naurp linux-2.6.13.3.orig/arch/mips/kernel/linux32.c linux-2.6.13.3/arch/mips/kernel/linux32.c --- linux-2.6.13.3.orig/arch/mips/kernel/linux32.c 2005-10-05 22:46:31.000000000 -0400 +++ linux-2.6.13.3/arch/mips/kernel/linux32.c 2005-10-05 22:34:45.000000000 -0400 @@ -1453,25 +1453,6 @@ sys32_timer_create(u32 clock, struct sig return sys_timer_create(clock, p, timer_id); } -asmlinkage long -sysn32_rt_sigtimedwait(const sigset_t __user *uthese, - siginfo_t __user *uinfo, - const struct compat_timespec __user *uts32, - size_t sigsetsize) -{ - struct timespec __user *uts = NULL; - - if (uts32) { - struct timespec ts; - uts = compat_alloc_user_space(sizeof(struct timespec)); - if (get_user(ts.tv_sec, &uts32->tv_sec) || - get_user(ts.tv_nsec, &uts32->tv_nsec) || - copy_to_user (uts, &ts, sizeof (ts))) - return -EFAULT; - } - return sys_rt_sigtimedwait(uthese, uinfo, uts, sigsetsize); -} - save_static_function(sys32_clone); __attribute_used__ noinline static int _sys32_clone(nabi_no_regargs struct pt_regs regs) diff -Naurp linux-2.6.13.3.orig/arch/mips/kernel/scall64-n32.S linux-2.6.13.3/arch/mips/kernel/scall64-n32.S --- linux-2.6.13.3.orig/arch/mips/kernel/scall64-n32.S 2005-10-05 22:46:31.000000000 -0400 +++ linux-2.6.13.3/arch/mips/kernel/scall64-n32.S 2005-10-05 22:34:45.000000000 -0400 @@ -243,9 +243,9 @@ EXPORT(sysn32_call_table) PTR sys_capget PTR sys_capset PTR sys32_rt_sigpending /* 6125 */ - PTR sysn32_rt_sigtimedwait + PTR compat_sys_rt_sigtimedwait PTR sys_rt_sigqueueinfo - PTR sys32_rt_sigsuspend + PTR sysn32_rt_sigsuspend PTR sys32_sigaltstack PTR compat_sys_utime /* 6130 */ PTR sys_mknod diff -Naurp linux-2.6.13.3.orig/arch/mips/kernel/signal.c linux-2.6.13.3/arch/mips/kernel/signal.c --- linux-2.6.13.3.orig/arch/mips/kernel/signal.c 2005-10-05 22:46:31.000000000 -0400 +++ linux-2.6.13.3/arch/mips/kernel/signal.c 2005-10-05 22:47:07.000000000 -0400 @@ -21,6 +21,7 @@ #include #include #include +#include #include #include @@ -39,6 +40,10 @@ #define _BLOCKABLE (~(sigmask(SIGKILL) | sigmask(SIGSTOP))) +#ifdef CONFIG_MIPS32_N32 +extern void sigset_from_compat (sigset_t *set, compat_sigset_t *compat); +#endif + int do_signal(sigset_t *oldset, struct pt_regs *regs); /* @@ -109,6 +114,43 @@ _sys_rt_sigsuspend(nabi_no_regargs struc } } +#ifdef CONFIG_MIPS32_N32 +save_static_function(sysn32_rt_sigsuspend); +__attribute_used__ noinline static int +_sysn32_rt_sigsuspend(nabi_no_regargs struct pt_regs regs) +{ + sigset_t saveset, newset; + compat_sigset_t __user *unewset, uset; + size_t sigsetsize; + + /* XXX Don't preclude handling different sized sigset_t's. */ + sigsetsize = regs.regs[5]; + if (sigsetsize != sizeof(sigset_t)) + return -EINVAL; + + unewset = (compat_sigset_t __user *) regs.regs[4]; + if (copy_from_user(&uset, unewset, sizeof(uset))) + return -EFAULT; + sigset_from_compat (&newset, &uset); + sigdelsetmask(&newset, ~_BLOCKABLE); + + spin_lock_irq(¤t->sighand->siglock); + saveset = current->blocked; + current->blocked = newset; + recalc_sigpending(); + spin_unlock_irq(¤t->sighand->siglock); + + regs.regs[2] = EINTR; + regs.regs[7] = 1; + while (1) { + current->state = TASK_INTERRUPTIBLE; + schedule(); + if (do_signal(&saveset, ®s)) + return -EINTR; + } +} +#endif + #ifdef CONFIG_TRAD_SIGNALS asmlinkage int sys_sigaction(int sig, const struct sigaction *act, struct sigaction *oact) --------------020308000807030801070508-- From drow@nevyn.them.org Thu Jun 8 03:28:51 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 08 Jun 2006 03:29:00 +0100 (BST) Received: from nevyn.them.org ([66.93.172.17]:35228 "EHLO nevyn.them.org") by ftp.linux-mips.org with ESMTP id S8126480AbWFHC2v (ORCPT ); Thu, 8 Jun 2006 03:28:51 +0100 Received: from drow by nevyn.them.org with local (Exim 4.54) id 1FoAGK-0008B1-3h; Wed, 07 Jun 2006 22:28:44 -0400 Date: Wed, 7 Jun 2006 22:28:44 -0400 From: Daniel Jacobowitz To: Kumba Cc: "Joseph S. Myers" , linux-mips@linux-mips.org Subject: Re: N32 sigset and __COMPAT_ENDIAN_SWAP__ Message-ID: <20060608022844.GA31361@nevyn.them.org> References: <44878AAA.20007@gentoo.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <44878AAA.20007@gentoo.org> User-Agent: Mutt/1.5.11+cvs20060403 Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11696 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: dan@debian.org Precedence: bulk X-list: linux-mips On Wed, Jun 07, 2006 at 10:25:46PM -0400, Kumba wrote: > You might find the attached patch of interest. > > We've been using it gentoo-side for awhile now, as it allowed some N32 > programs to work correctly. Namely, a configure test in glib would trigger > a non-fatal oops in the kernel due to an issue this patch fixes. Daniel > Jacobwitz wrote it up when he apparently stumbled across the issue > (something wonky in n32's sigsuspend, as the name indicates. I forget the > specifics, though), but I'm unsure if the issue is in any way connected to > what you're seeing as well. It's already in the linux-mips.org tree, though, I believe. That was a different problem. -- Daniel Jacobowitz CodeSourcery From kumba@gentoo.org Thu Jun 8 03:39:08 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 08 Jun 2006 03:39:18 +0100 (BST) Received: from [63.240.77.82] ([63.240.77.82]:17323 "EHLO sccrmhc12.comcast.net") by ftp.linux-mips.org with ESMTP id S8126582AbWFHCjI (ORCPT ); Thu, 8 Jun 2006 03:39:08 +0100 Received: from [127.0.0.1] (unknown[69.140.185.142]) by comcast.net (sccrmhc12) with ESMTP id <2006060802384701200ss931e>; Thu, 8 Jun 2006 02:38:51 +0000 Message-ID: <44878DBB.6020405@gentoo.org> Date: Wed, 07 Jun 2006 22:38:51 -0400 From: Kumba User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Daniel Jacobowitz CC: "Joseph S. Myers" , linux-mips@linux-mips.org Subject: Re: N32 sigset and __COMPAT_ENDIAN_SWAP__ References: <44878AAA.20007@gentoo.org> <20060608022844.GA31361@nevyn.them.org> In-Reply-To: <20060608022844.GA31361@nevyn.them.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11697 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: kumba@gentoo.org Precedence: bulk X-list: linux-mips Daniel Jacobowitz wrote: > > It's already in the linux-mips.org tree, though, I believe. That > was a different problem. This patch still applies to a 2.6.17 tree, so I don't think it's gone it yet. --Kumba -- Gentoo/MIPS Team Lead Gentoo Foundation Board of Trustees "Such is oft the course of deeds that move the wheels of the world: small hands do them because they must, while the eyes of the great are elsewhere." --Elrond From kumba@gentoo.org Thu Jun 8 03:45:17 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 08 Jun 2006 03:45:24 +0100 (BST) Received: from sccrmhc12.comcast.net ([204.127.200.82]:36812 "EHLO sccrmhc12.comcast.net") by ftp.linux-mips.org with ESMTP id S8126580AbWFHCpR (ORCPT ); Thu, 8 Jun 2006 03:45:17 +0100 Received: from [127.0.0.1] (unknown[69.140.185.142]) by comcast.net (sccrmhc12) with ESMTP id <2006060802450901200srm62e>; Thu, 8 Jun 2006 02:45:09 +0000 Message-ID: <44878F39.10809@gentoo.org> Date: Wed, 07 Jun 2006 22:45:13 -0400 From: Kumba User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Kumba CC: Daniel Jacobowitz , "Joseph S. Myers" , linux-mips@linux-mips.org Subject: Re: N32 sigset and __COMPAT_ENDIAN_SWAP__ References: <44878AAA.20007@gentoo.org> <20060608022844.GA31361@nevyn.them.org> <44878DBB.6020405@gentoo.org> In-Reply-To: <44878DBB.6020405@gentoo.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11698 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: kumba@gentoo.org Precedence: bulk X-list: linux-mips Kumba wrote: > > This patch still applies to a 2.6.17 tree, so I don't think it's gone it > yet. Ignore. PEBKAC :P --Kumba -- Gentoo/MIPS Team Lead Gentoo Foundation Board of Trustees "Such is oft the course of deeds that move the wheels of the world: small hands do them because they must, while the eyes of the great are elsewhere." --Elrond From yoichi_yuasa@tripeaks.co.jp Thu Jun 8 07:09:22 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 08 Jun 2006 07:09:30 +0100 (BST) Received: from mo31.po.2iij.net ([210.128.50.54]:54585 "EHLO mo31.po.2iij.net") by ftp.linux-mips.org with ESMTP id S8127229AbWFHGJW (ORCPT ); Thu, 8 Jun 2006 07:09:22 +0100 Received: by mo.po.2iij.net (mo31) id k5869IHL010202; Thu, 8 Jun 2006 15:09:18 +0900 (JST) Received: from localhost.localdomain (65.126.232.202.bf.2iij.net [202.232.126.65]) by mbox.po.2iij.net (mbox32) id k5869EjK091995 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 8 Jun 2006 15:09:14 +0900 (JST) Date: Thu, 8 Jun 2006 15:09:14 +0900 From: Yoichi Yuasa To: Ralf Baechle Cc: linux-mips Subject: [PATCH] vr41xx: added "select SYS_HAS_CPU_VR41XX" for MACH_VR41XX Message-Id: <20060608150914.64e3eb57.yoichi_yuasa@tripeaks.co.jp> Organization: TriPeaks Corporation X-Mailer: Sylpheed version 1.0.4 (GTK+ 1.2.10; i386-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11699 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: yoichi_yuasa@tripeaks.co.jp Precedence: bulk X-list: linux-mips Hi, This patch has added "select SYS_HAS_CPU_VR41XX" for MACH_VR41XX. It's required for MACH_VR41XX. Yoichi Signed-off-by: Yoichi Yuasa diff -pruN -X mips-rc6/Documentation/dontdiff mips-rc6-orig/arch/mips/Kconfig mips-rc6/arch/mips/Kconfig --- mips-rc6-orig/arch/mips/Kconfig 2006-06-08 11:07:40.265524750 +0900 +++ mips-rc6/arch/mips/Kconfig 2006-06-08 14:04:05.973933500 +0900 @@ -509,6 +509,7 @@ config DDB5477 config MACH_VR41XX bool "NEC VR41XX-based machines" + select SYS_HAS_CPU_VR41XX config PMC_YOSEMITE bool "PMC-Sierra Yosemite eval board" From ths@networkno.de Thu Jun 8 11:14:30 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 08 Jun 2006 11:14:39 +0100 (BST) Received: from bender.bawue.de ([193.7.176.20]:27603 "HELO bender.bawue.de") by ftp.linux-mips.org with SMTP id S8133417AbWFHKOa (ORCPT ); Thu, 8 Jun 2006 11:14:30 +0100 Received: from lagash (unknown [194.74.144.146]) by bender.bawue.de (Postfix) with ESMTP id C3CA845DF1; Thu, 8 Jun 2006 12:14:03 +0200 (MEST) Received: from ths by lagash with local (Exim 4.62) (envelope-from ) id 1FoHWB-0007KK-AN; Thu, 08 Jun 2006 11:13:35 +0100 Date: Thu, 8 Jun 2006 11:13:35 +0100 To: linux-mips@linux-mips.org Cc: ralf@linux-mips.org Subject: Kernel binary size changes in dependence of the gcc version Message-ID: <20060608101335.GA22883@networkno.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.11+cvs20060403 From: Thiemo Seufer Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11700 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ths@networkno.de Precedence: bulk X-list: linux-mips Hello All, I wondered how the various gcc versions influence the size of the kernel binary, and what difference a size-optimised build makes. The appended overview is for a Broadcom/Sibyte kernel with some amount of drivers built in, so the absolute numbers aren't that relevant. The configuration was always the same except for CONFIG_64BIT and CONFIG_CC_OPTIMIZE_FOR_SIZE. Thiemo 32 bit: ------- Kernel 2.6.17-rc5 Sibyte SWARM 32 bit, default compiler options: text data bss dec hex filename 3500246 319636 172080 3991962 3ce99a vmlinux # gcc-3.3 (3.3.6-13) 3440510 291012 172080 3903602 3b9072 vmlinux # gcc-3.4 (3.4.6-1) 3482825 291140 172080 3946045 3c363d vmlinux # gcc-4.0 (4.0.3-3) 3452750 288164 172080 3912994 3bb522 vmlinux # gcc-4.1 (4.1.0-4) 3455566 288164 172080 3915810 3bc022 vmlinux # gcc-snapshot (20060530-1) Kernel 2.6.17-rc5 Sibyte SWARM 32 bit, size optimized build: text data bss dec hex filename 3423398 319636 172080 3915114 3bbd6a vmlinux # gcc-3.3 (3.3.6-13) 3224502 291012 172080 3687594 3844aa vmlinux # gcc-3.4 (3.4.6-1) Newer gcc versions fail to build the 2.6.17-rc5 32 bit kernel with -Os due to unresolved references to libgcc. With a kernel patch providing libgcc functions, and a 2.6.17-rc6 snapshot: text data bss dec hex filename 3415310 319620 172080 3907010 3b9dc2 vmlinux # gcc-3.3 (3.3.6-13) 3215829 290996 172080 3678905 3822b9 vmlinux # gcc-3.4 (3.4.6-1) 3175683 290404 172080 3638167 378397 vmlinux # gcc-4.0 (4.0.3-3) 3184250 287348 172080 3643678 37991e vmlinux # gcc-4.1 (4.1.0-4) 3198118 287348 172080 3657546 37cf4a vmlinux # gcc-snapshot (20060530-1) 64 bit: ------- The difference in size from gcc-3.4 to gcc-4.0 for 64 bit kernels is to a large part caused by the use of -msym32, which is only available since gcc-4.0. Kernel 2.6.17-rc5 Sibyte SWARM 64 bit, default compiler options: text data bss dec hex filename 4240626 506688 258096 5005410 4c6062 vmlinux # gcc-3.3 (3.3.6-13) 4183387 469024 258096 4910507 4aedab vmlinux # gcc-3.4 (3.4.6-1) 3740658 469272 258096 4468026 442d3a vmlinux # gcc-4.0 (4.0.3-3) 3701722 463904 258096 4423722 43802a vmlinux # gcc-4.1 (4.1.0-4) 3703474 463904 258096 4425474 438702 vmlinux # gcc-snapshot (20060530-1) Kernel 2.6.17-rc5 Sibyte SWARM 64 bit, size optimized build: text data bss dec hex filename 4110677 506688 258096 4875461 4a64c5 vmlinux # gcc-3.3 (3.3.6-13) 3912126 469024 258096 4639246 46ca0e vmlinux # gcc-3.4 (3.4.6-1) 3384418 468248 258096 4110762 3eb9aa vmlinux # gcc-4.0 (4.0.3-3) 3389841 462880 258096 4110817 3eb9e1 vmlinux # gcc-4.1 (4.1.0-4) 3401534 462880 258096 4122510 3ee78e vmlinux # gcc-snapshot (20060530-1) From ralf@linux-mips.org Thu Jun 8 17:51:36 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 08 Jun 2006 17:51:46 +0100 (BST) Received: from localhost.localdomain ([127.0.0.1]:2968 "EHLO bacchus.dhis.org") by ftp.linux-mips.org with ESMTP id S8133494AbWFHQvg (ORCPT ); Thu, 8 Jun 2006 17:51:36 +0100 Received: from denk.linux-mips.net (denk.linux-mips.net [127.0.0.1]) by bacchus.dhis.org (8.13.6/8.13.4) with ESMTP id k58GpahI017159; Thu, 8 Jun 2006 17:51:36 +0100 Received: (from ralf@localhost) by denk.linux-mips.net (8.13.6/8.13.6/Submit) id k58GpaAT017158; Thu, 8 Jun 2006 17:51:36 +0100 Date: Thu, 8 Jun 2006 17:51:36 +0100 From: Ralf Baechle To: "Joseph S. Myers" Cc: linux-mips@linux-mips.org Subject: Re: N32 sigset and __COMPAT_ENDIAN_SWAP__ Message-ID: <20060608165136.GA17152@linux-mips.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11701 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ralf@linux-mips.org Precedence: bulk X-list: linux-mips On Thu, Jun 08, 2006 at 01:36:29AM +0000, Joseph S. Myers wrote: Interesting that a bug of this sort manages to survive for that long. I guess it is proof that barely anybody is using 64-bit little endian, yet we're cursed to support it. Ralf From drow@nevyn.them.org Thu Jun 8 18:03:15 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 08 Jun 2006 18:03:25 +0100 (BST) Received: from nevyn.them.org ([66.93.172.17]:40404 "EHLO nevyn.them.org") by ftp.linux-mips.org with ESMTP id S8133548AbWFHRDP (ORCPT ); Thu, 8 Jun 2006 18:03:15 +0100 Received: from drow by nevyn.them.org with local (Exim 4.54) id 1FoNuY-0006Em-I0; Thu, 08 Jun 2006 13:03:10 -0400 Date: Thu, 8 Jun 2006 13:03:10 -0400 From: Daniel Jacobowitz To: Ralf Baechle Cc: "Joseph S. Myers" , linux-mips@linux-mips.org Subject: Re: N32 sigset and __COMPAT_ENDIAN_SWAP__ Message-ID: <20060608170310.GA23814@nevyn.them.org> References: <20060608165136.GA17152@linux-mips.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060608165136.GA17152@linux-mips.org> User-Agent: Mutt/1.5.11+cvs20060403 Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11702 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: dan@debian.org Precedence: bulk X-list: linux-mips On Thu, Jun 08, 2006 at 05:51:36PM +0100, Ralf Baechle wrote: > On Thu, Jun 08, 2006 at 01:36:29AM +0000, Joseph S. Myers wrote: > > Interesting that a bug of this sort manages to survive for that long. > I guess it is proof that barely anybody is using 64-bit little endian, > yet we're cursed to support it. I expect more people will be using it someday... Anyway, I was curious if you knew where this code had come from. I didn't see anything to suggest that anyone besides mipsel ever used it, but it entered linux-mips.org via a merge from kernel.org, just before git history. Oh, right, there's a historical import: http://www.kernel.org/git/?p=linux/kernel/git/torvalds/old-2.6-bkcvs.git;a=commitdiff;h=32ed691a4efbc1c43584b7b7a6d782528241bb27 It was copied from sys32_rt_sigtimedwait, which was wrong at least back to the initial revision of signal32.c. I didn't go back any further. -- Daniel Jacobowitz CodeSourcery From joseph@codesourcery.com Thu Jun 8 18:12:46 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 08 Jun 2006 18:12:54 +0100 (BST) Received: from intranet.codesourcery.com ([65.74.133.6]:52637 "EHLO mail.codesourcery.com") by ftp.linux-mips.org with ESMTP id S8133492AbWFHRMq (ORCPT ); Thu, 8 Jun 2006 18:12:46 +0100 Received: (qmail 25998 invoked from network); 8 Jun 2006 17:12:39 -0000 Received: from unknown (HELO digraph.polyomino.org.uk) (joseph@127.0.0.2) by mail.codesourcery.com with ESMTPA; 8 Jun 2006 17:12:39 -0000 Received: from jsm28 (helo=localhost) by digraph.polyomino.org.uk with local-esmtp (Exim 4.52) id 1FoO3i-0002OI-6Y; Thu, 08 Jun 2006 17:12:38 +0000 Date: Thu, 8 Jun 2006 17:12:38 +0000 (UTC) From: "Joseph S. Myers" X-X-Sender: jsm28@digraph.polyomino.org.uk To: Ralf Baechle cc: linux-mips@linux-mips.org Subject: Re: N32 sigset and __COMPAT_ENDIAN_SWAP__ In-Reply-To: <20060608165136.GA17152@linux-mips.org> Message-ID: References: <20060608165136.GA17152@linux-mips.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11703 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: joseph@codesourcery.com Precedence: bulk X-list: linux-mips On Thu, 8 Jun 2006, Ralf Baechle wrote: > Interesting that a bug of this sort manages to survive for that long. > I guess it is proof that barely anybody is using 64-bit little endian, > yet we're cursed to support it. I might conclude that barely anybody is *yet* using NPTL on 64-bit MIPS at all, for either endianness, given that most of the problems I've been finding, in glibc as well as the kernel, don't seem endian-specific and would probably show up in a glibc testsuite run for either endianness. MIPS64 NPTL is very new and seems to do a good job of showing up bugs in the three syscall interfaces. -- Joseph S. Myers joseph@codesourcery.com From ralf@linux-mips.org Thu Jun 8 18:37:05 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 08 Jun 2006 18:37:13 +0100 (BST) Received: from localhost.localdomain ([127.0.0.1]:31125 "EHLO bacchus.dhis.org") by ftp.linux-mips.org with ESMTP id S8133548AbWFHRhF (ORCPT ); Thu, 8 Jun 2006 18:37:05 +0100 Received: from denk.linux-mips.net (denk.linux-mips.net [127.0.0.1]) by bacchus.dhis.org (8.13.6/8.13.4) with ESMTP id k58Hb1NA004403; Thu, 8 Jun 2006 18:37:01 +0100 Received: (from ralf@localhost) by denk.linux-mips.net (8.13.6/8.13.6/Submit) id k58HawOS004402; Thu, 8 Jun 2006 18:36:58 +0100 Date: Thu, 8 Jun 2006 18:36:58 +0100 From: Ralf Baechle To: Daniel Jacobowitz Cc: "Joseph S. Myers" , linux-mips@linux-mips.org Subject: Re: N32 sigset and __COMPAT_ENDIAN_SWAP__ Message-ID: <20060608173658.GA4056@linux-mips.org> References: <20060608165136.GA17152@linux-mips.org> <20060608170310.GA23814@nevyn.them.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060608170310.GA23814@nevyn.them.org> User-Agent: Mutt/1.4.2.1i Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11704 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ralf@linux-mips.org Precedence: bulk X-list: linux-mips On Thu, Jun 08, 2006 at 01:03:10PM -0400, Daniel Jacobowitz wrote: > Anyway, I was curious if you knew where this code had come from. I > didn't see anything to suggest that anyone besides mipsel ever > used it, but it entered linux-mips.org via a merge from kernel.org, > just before git history. > > Oh, right, there's a historical import: > > http://www.kernel.org/git/?p=linux/kernel/git/torvalds/old-2.6-bkcvs.git;a=commitdiff;h=32ed691a4efbc1c43584b7b7a6d782528241bb27 > It was copied from sys32_rt_sigtimedwait, which was wrong at least back > to the initial revision of signal32.c. I didn't go back any further. I can further track it into 2.4 or even pre-2.4 where such __MIPSEB__ / __MIPSEL__ dependencies did exist under arch/mips64/. I think it was right until a certain point in 2.5 when get_sigset and put_sigset were implement in a clever way that automatically takes care of the endianess issue - but the swapping code outside arch/mips got forgotten. Ralf From kumba@gentoo.org Fri Jun 9 02:15:58 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 09 Jun 2006 02:16:07 +0100 (BST) Received: from rwcrmhc12.comcast.net ([216.148.227.152]:11409 "EHLO rwcrmhc12.comcast.net") by ftp.linux-mips.org with ESMTP id S8133646AbWFIBP6 (ORCPT ); Fri, 9 Jun 2006 02:15:58 +0100 Received: from [127.0.0.1] (unknown[69.140.185.142]) by comcast.net (rwcrmhc12) with ESMTP id <20060609011551m1200o6511e>; Fri, 9 Jun 2006 01:15:52 +0000 Message-ID: <4488CBCC.4090405@gentoo.org> Date: Thu, 08 Jun 2006 21:15:56 -0400 From: Kumba User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: linux-mips@linux-mips.org CC: "Joseph S. Myers" Subject: Re: N32 sigset and __COMPAT_ENDIAN_SWAP__ References: <20060608165136.GA17152@linux-mips.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11705 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: kumba@gentoo.org Precedence: bulk X-list: linux-mips Joseph S. Myers wrote: > > I might conclude that barely anybody is *yet* using NPTL on 64-bit MIPS at > all, for either endianness, given that most of the problems I've been > finding, in glibc as well as the kernel, don't seem endian-specific and > would probably show up in a glibc testsuite run for either endianness. > MIPS64 NPTL is very new and seems to do a good job of showing up bugs in > the three syscall interfaces. I'm actually going to start running some automated builds of a nptl/o32 and nptl/n32 userland over the next few days. If you have any patches that need testing to correct known oddities, I can give them a run in these builds. --Kumba -- Gentoo/MIPS Team Lead Gentoo Foundation Board of Trustees "Such is oft the course of deeds that move the wheels of the world: small hands do them because they must, while the eyes of the great are elsewhere." --Elrond From imipak@yahoo.com Fri Jun 9 18:24:56 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 09 Jun 2006 18:25:07 +0100 (BST) Received: from web31505.mail.mud.yahoo.com ([68.142.198.134]:15190 "HELO web31505.mail.mud.yahoo.com") by ftp.linux-mips.org with SMTP id S8133654AbWFIRY4 (ORCPT ); Fri, 9 Jun 2006 18:24:56 +0100 Received: (qmail 23751 invoked by uid 60001); 9 Jun 2006 17:24:43 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=6ZWLD68av36OZN6pZMvC4g3MZ/X1zb2iDNNyWtAjgvG5s2CQpSnyLtuoNotw4C3JfIMPt8ZRaXluyYrQj9i476LumgC6gv4rX6vzeXXhSruKD1pZr6KEkHnvtEvSS0ObOiSviF4g9aPCHSm3a5dvd406RE1uKekORXQGMdGRYVQ= ; Message-ID: <20060609172443.23749.qmail@web31505.mail.mud.yahoo.com> Received: from [208.187.37.98] by web31505.mail.mud.yahoo.com via HTTP; Fri, 09 Jun 2006 10:24:43 PDT Date: Fri, 9 Jun 2006 10:24:43 -0700 (PDT) From: Jonathan Day Subject: re: where I can find a crosscompiler for BCM1255 To: linux-mips@linux-mips.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11706 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: imipak@yahoo.com Precedence: bulk X-list: linux-mips I have built cross-compilers for the Broadcom BCM1250 using the instructions and patches on the "Linux From Scratch" website. You need to look for the cross-compiler version of their guide, then select "browse online" and finally "mips64" to get to the instructions/patches for building for the 64-bit MIPS platforms. Do NOT use their kernel or kernel patches - use the version in the git repository on linux-mips. I personally use the binutils from CVS, rather than the version they have on their website, but there are no guarantees that their alterations to their MIPS code has fixed bugs or added them. This is NOT a well-tested or well-supported platform, even by (or especially by, in Broadcom's case) the manufacturers. I have the C, C++ and GFortran compilers working. It would appear to be much harder to get ADA to work. I have not tried Objective C or Objective C++. (GFortran is buggy, but efforts to get G95 to compile correctly are so far proving very frustrating. It compiles natively and cross-compiles just fine, but fails to generate valid code on the Broadcom 1250. The compiler does work, as I have got it to work just fine on ix86 systems and it is the recommended Fortran 95 compiler by many organizations I've talked to. Obviously, if you don't have to worry about Fortran, this is a non-issue. For those who do, coaxing G95 to behave with GCC 4.1.x will be an interesting problem.) __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From maillist@jg555.com Sat Jun 10 01:41:51 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 10 Jun 2006 01:42:00 +0100 (BST) Received: from jg555.com ([64.30.195.78]:36500 "EHLO jg555.com") by ftp.linux-mips.org with ESMTP id S8134050AbWFJAlv (ORCPT ); Sat, 10 Jun 2006 01:41:51 +0100 Received: from [172.16.0.159] (W2RZ8L4S01.jg555.com [::ffff:172.16.0.159]) (AUTH: PLAIN root, TLS: TLSv1/SSLv3,256bits,AES256-SHA) by jg555.com with esmtp; Fri, 09 Jun 2006 17:41:46 -0700 id 000201FA.448A154A.00002764 Message-ID: <448A1497.3000909@jg555.com> Date: Fri, 09 Jun 2006 17:38:47 -0700 From: Jim Gifford User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Jonathan Day CC: linux-mips@linux-mips.org Subject: Re: where I can find a crosscompiler for BCM1255 References: <20060609172443.23749.qmail@web31505.mail.mud.yahoo.com> In-Reply-To: <20060609172443.23749.qmail@web31505.mail.mud.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11707 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: maillist@jg555.com Precedence: bulk X-list: linux-mips Jonathan Day wrote: > I have built cross-compilers for the Broadcom BCM1250 > using the instructions and patches on the "Linux From > Scratch" website. You need to look for the > cross-compiler version of their guide, then select > "browse online" and finally "mips64" to get to the > instructions/patches for building for the 64-bit MIPS > platforms. > > Do NOT use their kernel or kernel patches - use the > version in the git repository on linux-mips. > > Johnathan, I'm on of the developers of CLFS, did you run into a problem with the patches? The patch is diff kernel.org and linux-mips.org kernels. Just curious, if we missed something let me know. From anemo@mba.ocn.ne.jp Sun Jun 11 15:24:50 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 11 Jun 2006 15:25:00 +0100 (BST) Received: from mba.ocn.ne.jp ([210.190.142.172]:2282 "HELO smtp.mba.ocn.ne.jp") by ftp.linux-mips.org with SMTP id S8133783AbWFKOYu (ORCPT ); Sun, 11 Jun 2006 15:24:50 +0100 Received: from localhost (p4129-ipad28funabasi.chiba.ocn.ne.jp [220.107.203.129]) by smtp.mba.ocn.ne.jp (Postfix) with ESMTP id 6C9489472; Sun, 11 Jun 2006 23:24:44 +0900 (JST) Date: Sun, 11 Jun 2006 23:25:43 +0900 (JST) Message-Id: <20060611.232543.59465208.anemo@mba.ocn.ne.jp> To: linux-mips@linux-mips.org Cc: ralf@linux-mips.org Subject: [PATCH] fix futex_atomic_op_inuser From: Atsushi Nemoto X-Fingerprint: 6ACA 1623 39BD 9A94 9B1A B746 CA77 FE94 2874 D52F X-Pgp-Public-Key: http://wwwkeys.pgp.net/pks/lookup?op=get&search=0x2874D52F X-Mailer: Mew version 3.3 on Emacs 21.4 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11708 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: anemo@mba.ocn.ne.jp Precedence: bulk X-list: linux-mips I found that NPTL's pthread_cond_signal() does not work properly on kernels compiled by gcc 4.1.x. I suppose inline asm for __futex_atomic_op() was wrong. I suppose: 1. "=&r" constraint should be used for oldval. 2. Instead of "r" (uaddr), "=R" (*uaddr) for output and "R" (*uaddr) for input should be used. 3. "memory" should be added to the clobber list. This patch solved the problem. Signed-off-by: Atsushi Nemoto diff --git a/include/asm-mips/futex.h b/include/asm-mips/futex.h index 12d118f..1f94640 100644 --- a/include/asm-mips/futex.h +++ b/include/asm-mips/futex.h @@ -22,51 +22,53 @@ " .set push \n" \ " .set noat \n" \ " .set mips3 \n" \ - "1: ll %1, (%3) # __futex_atomic_op \n" \ + "1: ll %1, %4 # __futex_atomic_op \n" \ " .set mips0 \n" \ " " insn " \n" \ " .set mips3 \n" \ - "2: sc $1, (%3) \n" \ + "2: sc $1, %2 \n" \ " beqzl $1, 1b \n" \ __FUTEX_SMP_SYNC \ "3: \n" \ " .set pop \n" \ " .set mips0 \n" \ " .section .fixup,\"ax\" \n" \ - "4: li %0, %5 \n" \ + "4: li %0, %6 \n" \ " j 2b \n" \ " .previous \n" \ " .section __ex_table,\"a\" \n" \ " "__UA_ADDR "\t1b, 4b \n" \ " "__UA_ADDR "\t2b, 4b \n" \ " .previous \n" \ - : "=r" (ret), "=r" (oldval) \ - : "0" (0), "r" (uaddr), "Jr" (oparg), "i" (-EFAULT)); \ + : "=r" (ret), "=&r" (oldval), "=R" (*uaddr) \ + : "0" (0), "R" (*uaddr), "Jr" (oparg), "i" (-EFAULT) \ + : "memory"); \ } else if (cpu_has_llsc) { \ __asm__ __volatile__( \ " .set push \n" \ " .set noat \n" \ " .set mips3 \n" \ - "1: ll %1, (%3) # __futex_atomic_op \n" \ + "1: ll %1, %4 # __futex_atomic_op \n" \ " .set mips0 \n" \ " " insn " \n" \ " .set mips3 \n" \ - "2: sc $1, (%3) \n" \ + "2: sc $1, %2 \n" \ " beqz $1, 1b \n" \ __FUTEX_SMP_SYNC \ "3: \n" \ " .set pop \n" \ " .set mips0 \n" \ " .section .fixup,\"ax\" \n" \ - "4: li %0, %5 \n" \ + "4: li %0, %6 \n" \ " j 2b \n" \ " .previous \n" \ " .section __ex_table,\"a\" \n" \ " "__UA_ADDR "\t1b, 4b \n" \ " "__UA_ADDR "\t2b, 4b \n" \ " .previous \n" \ - : "=r" (ret), "=r" (oldval) \ - : "0" (0), "r" (uaddr), "Jr" (oparg), "i" (-EFAULT)); \ + : "=r" (ret), "=&r" (oldval), "=R" (*uaddr) \ + : "0" (0), "R" (*uaddr), "Jr" (oparg), "i" (-EFAULT) \ + : "memory"); \ } else \ ret = -ENOSYS; \ } @@ -89,23 +91,23 @@ futex_atomic_op_inuser (int encoded_op, switch (op) { case FUTEX_OP_SET: - __futex_atomic_op("move $1, %z4", ret, oldval, uaddr, oparg); + __futex_atomic_op("move $1, %z5", ret, oldval, uaddr, oparg); break; case FUTEX_OP_ADD: - __futex_atomic_op("addu $1, %1, %z4", + __futex_atomic_op("addu $1, %1, %z5", ret, oldval, uaddr, oparg); break; case FUTEX_OP_OR: - __futex_atomic_op("or $1, %1, %z4", + __futex_atomic_op("or $1, %1, %z5", ret, oldval, uaddr, oparg); break; case FUTEX_OP_ANDN: - __futex_atomic_op("and $1, %1, %z4", + __futex_atomic_op("and $1, %1, %z5", ret, oldval, uaddr, ~oparg); break; case FUTEX_OP_XOR: - __futex_atomic_op("xor $1, %1, %z4", + __futex_atomic_op("xor $1, %1, %z5", ret, oldval, uaddr, oparg); break; default: From anemo@mba.ocn.ne.jp Sun Jun 11 15:29:06 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 11 Jun 2006 15:29:16 +0100 (BST) Received: from mba.ocn.ne.jp ([210.190.142.172]:53503 "HELO smtp.mba.ocn.ne.jp") by ftp.linux-mips.org with SMTP id S8133794AbWFKO3G (ORCPT ); Sun, 11 Jun 2006 15:29:06 +0100 Received: from localhost (p4129-ipad28funabasi.chiba.ocn.ne.jp [220.107.203.129]) by smtp.mba.ocn.ne.jp (Postfix) with ESMTP id 4B13DA9F7; Sun, 11 Jun 2006 23:29:02 +0900 (JST) Date: Sun, 11 Jun 2006 23:30:01 +0900 (JST) Message-Id: <20060611.233001.126141865.anemo@mba.ocn.ne.jp> To: linux-mips@linux-mips.org Cc: ralf@linux-mips.org Subject: Re: [PATCH] fix futex_atomic_op_inuser From: Atsushi Nemoto In-Reply-To: <20060611.232543.59465208.anemo@mba.ocn.ne.jp> References: <20060611.232543.59465208.anemo@mba.ocn.ne.jp> X-Fingerprint: 6ACA 1623 39BD 9A94 9B1A B746 CA77 FE94 2874 D52F X-Pgp-Public-Key: http://wwwkeys.pgp.net/pks/lookup?op=get&search=0x2874D52F X-Mailer: Mew version 3.3 on Emacs 21.4 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11709 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: anemo@mba.ocn.ne.jp Precedence: bulk X-list: linux-mips On Sun, 11 Jun 2006 23:25:43 +0900 (JST), Atsushi Nemoto wrote: > I found that NPTL's pthread_cond_signal() does not work properly on > kernels compiled by gcc 4.1.x. I suppose inline asm for > __futex_atomic_op() was wrong. I suppose: > > 1. "=&r" constraint should be used for oldval. > 2. Instead of "r" (uaddr), "=R" (*uaddr) for output and "R" (*uaddr) > for input should be used. > 3. "memory" should be added to the clobber list. > > This patch solved the problem. And here is a patch for 2.6.16-stable tree. Signed-off-by: Atsushi Nemoto diff --git a/include/asm-mips/futex.h b/include/asm-mips/futex.h index 2454c44..e1f960d 100644 --- a/include/asm-mips/futex.h +++ b/include/asm-mips/futex.h @@ -20,26 +20,27 @@ " .set push \n" \ " .set noat \n" \ " .set mips3 \n" \ - "1: ll %1, (%3) # __futex_atomic_op1 \n" \ + "1: ll %1, %4 # __futex_atomic_op1 \n" \ " .set mips0 \n" \ " " insn " \n" \ " .set mips3 \n" \ - "2: sc $1, (%3) \n" \ + "2: sc $1, %2 \n" \ " beqzl $1, 1b \n" \ __FUTEX_SMP_SYNC \ "3: \n" \ " .set pop \n" \ " .set mips0 \n" \ " .section .fixup,\"ax\" \n" \ - "4: li %0, %5 \n" \ + "4: li %0, %6 \n" \ " j 2b \n" \ " .previous \n" \ " .section __ex_table,\"a\" \n" \ " "__UA_ADDR "\t1b, 4b \n" \ " "__UA_ADDR "\t2b, 4b \n" \ " .previous \n" \ - : "=r" (ret), "=r" (oldval) \ - : "0" (0), "r" (uaddr), "Jr" (oparg), "i" (-EFAULT)); \ + : "=r" (ret), "=&r" (oldval), "=R" (*uaddr) \ + : "0" (0), "R" (*uaddr), "Jr" (oparg), "i" (-EFAULT) \ + : "memory"); \ } static inline int @@ -60,23 +61,23 @@ futex_atomic_op_inuser (int encoded_op, switch (op) { case FUTEX_OP_SET: - __futex_atomic_op("move $1, %z4", ret, oldval, uaddr, oparg); + __futex_atomic_op("move $1, %z5", ret, oldval, uaddr, oparg); break; case FUTEX_OP_ADD: - __futex_atomic_op("addu $1, %1, %z4", + __futex_atomic_op("addu $1, %1, %z5", ret, oldval, uaddr, oparg); break; case FUTEX_OP_OR: - __futex_atomic_op("or $1, %1, %z4", + __futex_atomic_op("or $1, %1, %z5", ret, oldval, uaddr, oparg); break; case FUTEX_OP_ANDN: - __futex_atomic_op("and $1, %1, %z4", + __futex_atomic_op("and $1, %1, %z5", ret, oldval, uaddr, ~oparg); break; case FUTEX_OP_XOR: - __futex_atomic_op("xor $1, %1, %z4", + __futex_atomic_op("xor $1, %1, %z5", ret, oldval, uaddr, oparg); break; default: From vitalywool@gmail.com Sun Jun 11 21:21:59 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 11 Jun 2006 21:22:10 +0100 (BST) Received: from nz-out-0102.google.com ([64.233.162.195]:48372 "EHLO nz-out-0102.google.com") by ftp.linux-mips.org with ESMTP id S8133809AbWFKUV7 (ORCPT ); Sun, 11 Jun 2006 21:21:59 +0100 Received: by nz-out-0102.google.com with SMTP id z3so1159072nzf for ; Sun, 11 Jun 2006 13:21:57 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=W7zp/iYBqZBQmwbtrbdRoNysMtIJ1IDwYcL+Cikod0ccF8T455Tx5hponWiJPrEcHk1BLkAEOhRcdGHNQOYeMZgDAX74Rn+eHsVHGQFnYmwzzvDviTf9yzarTBzOrhFS6SSp0Ea+ZNp6txbV9bGNH8/rChjPhea/rLcnMcOjA14= Received: by 10.36.196.20 with SMTP id t20mr7553873nzf; Sun, 11 Jun 2006 13:21:57 -0700 (PDT) Received: by 10.36.128.9 with HTTP; Sun, 11 Jun 2006 13:21:57 -0700 (PDT) Message-ID: Date: Mon, 12 Jun 2006 00:21:57 +0400 From: "Vitaly Wool" To: "Ralf Baechle" Subject: Re: PNX8550 fails to compile in 2.6.17-rc4 Cc: linux-kernel@vger.kernel.org, linux-mips@linux-mips.org In-Reply-To: <20060607142702.GA20184@linux-mips.org> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_2234_20641037.1150057317747" References: <20060607105221.7b15b243.vitalywool@gmail.com> <20060607142702.GA20184@linux-mips.org> Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11710 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: vitalywool@gmail.com Precedence: bulk X-list: linux-mips ------=_Part_2234_20641037.1150057317747 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Hello Ralf, On 6/7/06, Ralf Baechle wrote: > This seems to be one of the serial bits for the ip3106 which must have > been lost on the way to kernel.org. Unfortunately the original author > does no longer take care of the code. I just took a stab at the PNX8550 > code and it has a significant number of other problems. All small in > the sum large enough such that I will mark PNX8550 support broken. I took an attempt to compile 2.6.16.20 kernel from linux-mips.org for PNX8550 and it went a little further but also failed soon: CC arch/mips/philips/pnx8550/common/platform.o /home/vital/work/opensource/linux- 2.6.16.20/arch/mips/philips/pnx8550/common/platform.c:101: error: variable `pnx8550_usb_ohci_device' has initializer but incomplete type /home/vital/work/opensource/linux- 2.6.16.20/arch/mips/philips/pnx8550/common/platform.c:102: error: unknown field `name' specified in initializer /home/vital/work/opensource/linux- 2.6.16.20/arch/mips/philips/pnx8550/common/platform.c:102: warning: excess elements in struct initializer /home/vital/work/opensource/linux- 2.6.16.20/arch/mips/philips/pnx8550/common/platform.c:102: warning: (near initialization for `pnx8550_usb_ohci_device') /home/vital/work/opensource/linux- 2.6.16.20/arch/mips/philips/pnx8550/common/platform.c:103: error: unknown field `id' specified in initializer /home/vital/work/opensource/linux- 2.6.16.20/arch/mips/philips/pnx8550/common/platform.c:103: warning: excess elements in struct initializer ... /home/vital/work/opensource/linux- 2.6.16.20/arch/mips/philips/pnx8550/common/platform.c:101: error: storage size of `pnx8550_usb_ohci_device' isn't known /home/vital/work/opensource/linux- 2.6.16.20/arch/mips/philips/pnx8550/common/platform.c:112: error: storage size of `pnx8550_uart_device' isn't known make[2]: *** [arch/mips/philips/pnx8550/common/platform.o] Error 1 make[1]: *** [arch/mips/philips/pnx8550/common] Error 2 make: *** [vmlinux] Error 2 Does it make sense to try to fix those? Or will it only result in more errore showing up next? Best regards, Vitaly ------=_Part_2234_20641037.1150057317747 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hello Ralf,

On 6/7/06, Ralf Baechle <ralf@linux-mips.org> wrote:
> This seems to be one of the serial bits for the ip3106 which must have
> been lost on the way to kernel.org.  Unfortunately the original author
> does no longer take care of the code.  I just took a stab at the PNX8550
> code and it has a significant number of other problems.  All small in
> the sum large enough such that I will mark PNX8550 support broken.
 
I took an attempt to compile 2.6.16.20 kernel from linux-mips.org for PNX8550 and it went a little further but also failed soon:
 
  CC      arch/mips/philips/pnx8550/common/platform.o
/home/vital/work/opensource/linux-2.6.16.20/arch/mips/philips/pnx8550/common/platform.c:101 : error: variable `pnx8550_usb_ohci_device' has initializer but incomplete type
/home/vital/work/opensource/linux-2.6.16.20/arch/mips/philips/pnx8550/common/platform.c:102 : error: unknown field `name' specified in initializer
/home/vital/work/opensource/linux-2.6.16.20/arch/mips/philips/pnx8550/common/platform.c:102 : warning: excess elements in struct initializer
/home/vital/work/opensource/linux-2.6.16.20/arch/mips/philips/pnx8550/common/platform.c:102 : warning: (near initialization for `pnx8550_usb_ohci_device')
/home/vital/work/opensource/linux-2.6.16.20/arch/mips/philips/pnx8550/common/platform.c:103 : error: unknown field `id' specified in initializer
/home/vital/work/opensource/linux-2.6.16.20/arch/mips/philips/pnx8550/common/platform.c:103 : warning: excess elements in struct initializer
...
/home/vital/work/opensource/linux-2.6.16.20/arch/mips/philips/pnx8550/common/platform.c:101: error: storage size of `pnx8550_usb_ohci_device' isn't known
/home/vital/work/opensource/linux-2.6.16.20/arch/mips/philips/pnx8550/common/platform.c:112: error: storage size of `pnx8550_uart_device' isn't known
make[2]: *** [arch/mips/philips/pnx8550/common/platform.o] Error 1
make[1]: *** [arch/mips/philips/pnx8550/common] Error 2
make: *** [vmlinux] Error 2
 
Does it make sense to try to fix those? Or will it only result in more errore showing up next?
 
Best regards,
   Vitaly

 
------=_Part_2234_20641037.1150057317747-- From ralf@linux-mips.org Sun Jun 11 21:54:50 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 11 Jun 2006 21:54:58 +0100 (BST) Received: from localhost.localdomain ([127.0.0.1]:25792 "EHLO bacchus.dhis.org") by ftp.linux-mips.org with ESMTP id S8133866AbWFKUyu (ORCPT ); Sun, 11 Jun 2006 21:54:50 +0100 Received: from denk.linux-mips.net (denk.linux-mips.net [127.0.0.1]) by bacchus.dhis.org (8.13.6/8.13.4) with ESMTP id k5BKsnkI027416; Sun, 11 Jun 2006 21:54:49 +0100 Received: (from ralf@localhost) by denk.linux-mips.net (8.13.6/8.13.6/Submit) id k5BKsm64027415; Sun, 11 Jun 2006 21:54:48 +0100 Date: Sun, 11 Jun 2006 21:54:48 +0100 From: Ralf Baechle To: Vitaly Wool Cc: linux-kernel@vger.kernel.org, linux-mips@linux-mips.org Subject: Re: PNX8550 fails to compile in 2.6.17-rc4 Message-ID: <20060611205448.GA27193@linux-mips.org> References: <20060607105221.7b15b243.vitalywool@gmail.com> <20060607142702.GA20184@linux-mips.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11711 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ralf@linux-mips.org Precedence: bulk X-list: linux-mips On Mon, Jun 12, 2006 at 12:21:57AM +0400, Vitaly Wool wrote: > On 6/7/06, Ralf Baechle wrote: > >This seems to be one of the serial bits for the ip3106 which must have > >been lost on the way to kernel.org. Unfortunately the original author > >does no longer take care of the code. I just took a stab at the PNX8550 > >code and it has a significant number of other problems. All small in > >the sum large enough such that I will mark PNX8550 support broken. > > I took an attempt to compile 2.6.16.20 kernel from linux-mips.org for > PNX8550 and it went a little further but also failed soon: > > CC arch/mips/philips/pnx8550/common/platform.o > /home/vital/work/opensource/linux- > 2.6.16.20/arch/mips/philips/pnx8550/common/platform.c:101: error: variable > `pnx8550_usb_ohci_device' has initializer but incomplete type > /home/vital/work/opensource/linux- > 2.6.16.20/arch/mips/philips/pnx8550/common/platform.c:102: error: unknown > field `name' specified in initializer > /home/vital/work/opensource/linux- > 2.6.16.20/arch/mips/philips/pnx8550/common/platform.c:102: warning: excess > elements in struct initializer > /home/vital/work/opensource/linux- > 2.6.16.20/arch/mips/philips/pnx8550/common/platform.c:102: warning: (near > initialization for `pnx8550_usb_ohci_device') > /home/vital/work/opensource/linux- > 2.6.16.20/arch/mips/philips/pnx8550/common/platform.c:103: error: unknown > field `id' specified in initializer > /home/vital/work/opensource/linux- > 2.6.16.20/arch/mips/philips/pnx8550/common/platform.c:103: warning: excess > elements in struct initializer > ... > /home/vital/work/opensource/linux- > 2.6.16.20/arch/mips/philips/pnx8550/common/platform.c:101: error: storage > size of `pnx8550_usb_ohci_device' isn't known > /home/vital/work/opensource/linux- > 2.6.16.20/arch/mips/philips/pnx8550/common/platform.c:112: error: storage > size of `pnx8550_uart_device' isn't known > make[2]: *** [arch/mips/philips/pnx8550/common/platform.o] Error 1 > make[1]: *** [arch/mips/philips/pnx8550/common] Error 2 > make: *** [vmlinux] Error 2 > > Does it make sense to try to fix those? Or will it only result in more > errore showing up next? There is a whole number of small problems such as this one but as far as I look at it all where only simple. Ralf From jgarzik@pobox.com Mon Jun 12 04:19:27 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 12 Jun 2006 04:19:37 +0100 (BST) Received: from srv5.dvmed.net ([207.36.208.214]:11904 "EHLO mail.dvmed.net") by ftp.linux-mips.org with ESMTP id S8126480AbWFLDT1 (ORCPT ); Mon, 12 Jun 2006 04:19:27 +0100 Received: from cpe-065-190-194-075.nc.res.rr.com ([65.190.194.75] helo=[10.10.10.99]) by mail.dvmed.net with esmtpsa (Exim 4.60 #1 (Red Hat Linux)) id 1FpcxR-0004tn-KK; Mon, 12 Jun 2006 03:19:18 +0000 Message-ID: <448CDD34.50502@pobox.com> Date: Sun, 11 Jun 2006 23:19:16 -0400 From: Jeff Garzik User-Agent: Thunderbird 1.5.0.2 (X11/20060501) MIME-Version: 1.0 To: Herbert Valerio Riedel CC: netdev@vger.kernel.org, linux-mips@linux-mips.org, ppopov@embeddedalley.com, sshtylyov@ru.mvista.com, ralf@linux-mips.org Subject: Re: [PATCH netdev-2.6#upstream] net: au1000_eth: PHY framework conversion References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11712 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: linux-mips Herbert Valerio Riedel wrote: > convert au1000_eth driver to use PHY framework and garbage collected > functions and identifiers that became unused/obsolete in the process > > Signed-off-by: Herbert Valerio Riedel applied From hvr@gnu.org Mon Jun 12 06:56:28 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 12 Jun 2006 06:56:42 +0100 (BST) Received: from fencepost.gnu.org ([199.232.76.164]:24472 "EHLO fencepost.gnu.org") by ftp.linux-mips.org with ESMTP id S8133349AbWFLF41 (ORCPT ); Mon, 12 Jun 2006 06:56:27 +0100 Received: from hvr by fencepost.gnu.org with local (Exim 4.34) id 1FpfPQ-0005lv-Ej; Mon, 12 Jun 2006 01:56:20 -0400 From: Herbert Valerio Riedel Date: Mon, 12 Jun 2006 07:52:48 +0200 To: Jeff Garzik Cc: netdev@vger.kernel.org, linux-mips@linux-mips.org, ppopov@embeddedalley.com, sshtylyov@ru.mvista.com, ralf@linux-mips.org Subject: [PATCH netdev-2.6#upstream] net: au1000_eth: netdev_priv() conversion Message-Id: Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11713 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: hvr@gnu.org Precedence: bulk X-list: linux-mips convert driver to use netdev_priv(net_device*) instead of accessing ->priv directly; where applicable, declare the resulting local pointer to be 'const' Signed-off-by: Herbert Valerio Riedel --- drivers/net/au1000_eth.c | 51 +++++++++++++++++++++++----------------------- 1 files changed, 25 insertions(+), 26 deletions(-) 505c73271046495d4948bf7b5adc7c4e3b88835d diff --git a/drivers/net/au1000_eth.c b/drivers/net/au1000_eth.c index 038d5fc..558aae3 100644 --- a/drivers/net/au1000_eth.c +++ b/drivers/net/au1000_eth.c @@ -199,7 +199,7 @@ #endif */ static int mdio_read(struct net_device *dev, int phy_addr, int reg) { - struct au1000_private *aup = (struct au1000_private *) dev->priv; + struct au1000_private *const aup = netdev_priv(dev); volatile u32 *const mii_control_reg = &aup->mac->mii_control; volatile u32 *const mii_data_reg = &aup->mac->mii_data; u32 timedout = 20; @@ -233,7 +233,7 @@ static int mdio_read(struct net_device * static void mdio_write(struct net_device *dev, int phy_addr, int reg, u16 value) { - struct au1000_private *aup = (struct au1000_private *) dev->priv; + struct au1000_private *const aup = netdev_priv(dev); volatile u32 *const mii_control_reg = &aup->mac->mii_control; volatile u32 *const mii_data_reg = &aup->mac->mii_data; u32 timedout = 20; @@ -288,7 +288,7 @@ static int mdiobus_reset(struct mii_bus static int mii_probe (struct net_device *dev) { - struct au1000_private *const aup = (struct au1000_private *) dev->priv; + struct au1000_private *const aup = netdev_priv(dev); struct phy_device *phydev = NULL; #if defined(AU1XXX_PHY_STATIC_CONFIG) @@ -419,7 +419,7 @@ void ReleaseDB(struct au1000_private *au static void enable_rx_tx(struct net_device *dev) { - struct au1000_private *aup = (struct au1000_private *) dev->priv; + struct au1000_private *const aup = netdev_priv(dev); if (au1000_debug > 4) printk(KERN_INFO "%s: enable_rx_tx\n", dev->name); @@ -430,7 +430,7 @@ static void enable_rx_tx(struct net_devi static void hard_stop(struct net_device *dev) { - struct au1000_private *aup = (struct au1000_private *) dev->priv; + struct au1000_private *const aup = netdev_priv(dev); if (au1000_debug > 4) printk(KERN_INFO "%s: hard stop\n", dev->name); @@ -442,7 +442,7 @@ static void hard_stop(struct net_device static void enable_mac(struct net_device *dev, int force_reset) { unsigned long flags; - struct au1000_private *aup = (struct au1000_private *) dev->priv; + struct au1000_private *const aup = netdev_priv(dev); spin_lock_irqsave(&aup->lock, flags); @@ -461,7 +461,7 @@ static void enable_mac(struct net_device static void reset_mac_unlocked(struct net_device *dev) { - struct au1000_private *const aup = (struct au1000_private *) dev->priv; + struct au1000_private *const aup = netdev_priv(dev); int i; hard_stop(dev); @@ -487,7 +487,7 @@ static void reset_mac_unlocked(struct ne static void reset_mac(struct net_device *dev) { - struct au1000_private *const aup = (struct au1000_private *) dev->priv; + struct au1000_private *const aup = netdev_priv(dev); unsigned long flags; if (au1000_debug > 4) @@ -576,7 +576,7 @@ static int __init au1000_init_module(voi static int au1000_get_settings(struct net_device *dev, struct ethtool_cmd *cmd) { - struct au1000_private *aup = (struct au1000_private *)dev->priv; + struct au1000_private *const aup = netdev_priv(dev); if (aup->phy_dev) return phy_ethtool_gset(aup->phy_dev, cmd); @@ -586,7 +586,7 @@ static int au1000_get_settings(struct ne static int au1000_set_settings(struct net_device *dev, struct ethtool_cmd *cmd) { - struct au1000_private *aup = (struct au1000_private *)dev->priv; + struct au1000_private *const aup = netdev_priv(dev); if (!capable(CAP_NET_ADMIN)) return -EPERM; @@ -600,7 +600,7 @@ static int au1000_set_settings(struct ne static void au1000_get_drvinfo(struct net_device *dev, struct ethtool_drvinfo *info) { - struct au1000_private *aup = (struct au1000_private *)dev->priv; + struct au1000_private *const aup = netdev_priv(dev); strcpy(info->driver, DRV_NAME); strcpy(info->version, DRV_VERSION); @@ -657,7 +657,7 @@ static struct net_device * au1000_probe( printk("%s: Au1xx0 Ethernet found at 0x%x, irq %d\n", dev->name, base, irq); - aup = dev->priv; + aup = netdev_priv(dev); /* Allocate the data buffers */ /* Snooping works fine with eth on all au1xxx */ @@ -822,7 +822,7 @@ err_out: */ static int au1000_init(struct net_device *dev) { - struct au1000_private *aup = (struct au1000_private *) dev->priv; + struct au1000_private *const aup = netdev_priv(dev); u32 flags; int i; u32 control; @@ -873,7 +873,7 @@ #endif static void au1000_adjust_link(struct net_device *dev) { - struct au1000_private *aup = (struct au1000_private *) dev->priv; + struct au1000_private *const aup = netdev_priv(dev); struct phy_device *phydev = aup->phy_dev; unsigned long flags; @@ -953,7 +953,7 @@ au1000_adjust_link(struct net_device *de static int au1000_open(struct net_device *dev) { int retval; - struct au1000_private *aup = (struct au1000_private *) dev->priv; + struct au1000_private *const aup = netdev_priv(dev); if (au1000_debug > 4) printk("%s: open: dev=%p\n", dev->name, dev); @@ -988,7 +988,7 @@ static int au1000_open(struct net_device static int au1000_close(struct net_device *dev) { unsigned long flags; - struct au1000_private *const aup = (struct au1000_private *) dev->priv; + struct au1000_private *const aup = netdev_priv(dev); if (au1000_debug > 4) printk("%s: close: dev=%p\n", dev->name, dev); @@ -1014,12 +1014,11 @@ static void __exit au1000_cleanup_module { int i, j; struct net_device *dev; - struct au1000_private *aup; for (i = 0; i < num_ifs; i++) { dev = iflist[i].dev; if (dev) { - aup = (struct au1000_private *) dev->priv; + struct au1000_private *const aup = netdev_priv(dev); unregister_netdev(dev); for (j = 0; j < NUM_RX_DMA; j++) if (aup->rx_db_inuse[j]) @@ -1039,7 +1038,7 @@ static void __exit au1000_cleanup_module static void update_tx_stats(struct net_device *dev, u32 status) { - struct au1000_private *aup = (struct au1000_private *) dev->priv; + struct au1000_private *const aup = netdev_priv(dev); struct net_device_stats *ps = &aup->stats; if (status & TX_FRAME_ABORTED) { @@ -1068,7 +1067,7 @@ static void update_tx_stats(struct net_d */ static void au1000_tx_ack(struct net_device *dev) { - struct au1000_private *aup = (struct au1000_private *) dev->priv; + struct au1000_private *const aup = netdev_priv(dev); volatile tx_dma_t *ptxd; ptxd = aup->tx_dma_ring[aup->tx_tail]; @@ -1095,7 +1094,7 @@ static void au1000_tx_ack(struct net_dev */ static int au1000_tx(struct sk_buff *skb, struct net_device *dev) { - struct au1000_private *aup = (struct au1000_private *) dev->priv; + struct au1000_private *const aup = netdev_priv(dev); struct net_device_stats *ps = &aup->stats; volatile tx_dma_t *ptxd; u32 buff_stat; @@ -1149,7 +1148,7 @@ static int au1000_tx(struct sk_buff *skb static inline void update_rx_stats(struct net_device *dev, u32 status) { - struct au1000_private *aup = (struct au1000_private *) dev->priv; + struct au1000_private *const aup = netdev_priv(dev); struct net_device_stats *ps = &aup->stats; ps->rx_packets++; @@ -1177,7 +1176,7 @@ static inline void update_rx_stats(struc */ static int au1000_rx(struct net_device *dev) { - struct au1000_private *aup = (struct au1000_private *) dev->priv; + struct au1000_private *const aup = netdev_priv(dev); struct sk_buff *skb; volatile rx_dma_t *prxd; u32 buff_stat, status; @@ -1286,7 +1285,7 @@ static void au1000_tx_timeout(struct net static void set_rx_mode(struct net_device *dev) { - struct au1000_private *aup = (struct au1000_private *) dev->priv; + struct au1000_private *const aup = netdev_priv(dev); if (au1000_debug > 4) printk("%s: set_rx_mode: flags=%x\n", dev->name, dev->flags); @@ -1319,7 +1318,7 @@ static void set_rx_mode(struct net_devic static int au1000_ioctl(struct net_device *dev, struct ifreq *rq, int cmd) { - struct au1000_private *aup = (struct au1000_private *)dev->priv; + struct au1000_private *const aup = netdev_priv(dev); if (!netif_running(dev)) return -EINVAL; @@ -1330,7 +1329,7 @@ static int au1000_ioctl(struct net_devic static struct net_device_stats *au1000_get_stats(struct net_device *dev) { - struct au1000_private *aup = (struct au1000_private *) dev->priv; + struct au1000_private *const aup = netdev_priv(dev); if (au1000_debug > 4) printk("%s: au1000_get_stats: dev=%p\n", dev->name, dev); -- 1.3.2 From juergen.sell@gmail.com Mon Jun 12 16:19:02 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 12 Jun 2006 16:19:10 +0100 (BST) Received: from ug-out-1314.google.com ([66.249.92.169]:65017 "EHLO ug-out-1314.google.com") by ftp.linux-mips.org with ESMTP id S8133400AbWFLPTC (ORCPT ); Mon, 12 Jun 2006 16:19:02 +0100 Received: by ug-out-1314.google.com with SMTP id y2so2252908uge for ; Mon, 12 Jun 2006 08:19:01 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=a79Tl2MNyzIj/1xQ5TFzHbXBSLnuAH3Hh8M65pkxYrLhtBVYpdXm//7msXvhhO/6r393c/PRY7So9uOYVG3ia+gWmr63g00t9xrwM9b3sZKOcNXgCrgMQli7XeCBSTAU7RyuI1LDDBAHACFd+/TgCZ6UPfdn+Egg2ZnXVgW32Tg= Received: by 10.67.96.14 with SMTP id y14mr5288998ugl; Mon, 12 Jun 2006 08:19:01 -0700 (PDT) Received: by 10.66.239.13 with HTTP; Mon, 12 Jun 2006 08:19:01 -0700 (PDT) Message-ID: Date: Mon, 12 Jun 2006 17:19:01 +0200 From: "Juergen Sell" To: linux-mips@linux-mips.org Subject: Support for Vadem/Clio with NEC VR4121 anyone? MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11714 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: juergen.sell@gmail.com Precedence: bulk X-list: linux-mips Hi, I did aquire such a device, by now 5 years old. From what I found searching various archives it might have had linux vr or linux mips support at one point around 2001 but this seem to be lost? (I even found a binay of a 2.3.99 linux kernel, but no docs, no config no modules, nothing else. So that seems pretty useless, right?) Anyway I would very much prefer Linux over the embedded win/ce. Now I am wondering whether any current pointers or configuration is available to get me started? A working kernel config file might be a good start (for a recent kernel perhaps?). By now I have a boot-loader that works under win/ce and loads from a cf-card (tested with the above mentioned linux kernel binary). Any and all pointers welcome. Juergen From imipak@yahoo.com Mon Jun 12 18:13:27 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 12 Jun 2006 18:13:37 +0100 (BST) Received: from web31513.mail.mud.yahoo.com ([68.142.198.142]:9876 "HELO web31513.mail.mud.yahoo.com") by ftp.linux-mips.org with SMTP id S8133494AbWFLRN1 (ORCPT ); Mon, 12 Jun 2006 18:13:27 +0100 Received: (qmail 65852 invoked by uid 60001); 12 Jun 2006 17:13:20 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=T8abjrgaIMLE5XB73mD4rhnj1uIA/0Ri+Eq7hMa7HXSddnyXajwYCuUXS1cimGK8OuQPEl7pgtSC9Kbm7M+ZuL8jz+SRSyzJY5ZMt2gTswHigRJY2Hn1DkG2DrwqXV8D6gt1WdcZR4CjOFFHkF0knQnDpkB3vLdss991NPHN58I= ; Message-ID: <20060612171320.65850.qmail@web31513.mail.mud.yahoo.com> Received: from [208.187.37.98] by web31513.mail.mud.yahoo.com via HTTP; Mon, 12 Jun 2006 10:13:20 PDT Date: Mon, 12 Jun 2006 10:13:20 -0700 (PDT) From: Jonathan Day Subject: Re: where I can find a crosscompiler for BCM1255 To: Jim Gifford Cc: linux-mips@linux-mips.org In-Reply-To: <448A1497.3000909@jg555.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11715 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: imipak@yahoo.com Precedence: bulk X-list: linux-mips --- Jim Gifford wrote: > Jonathan Day wrote: > > I have built cross-compilers for the Broadcom > BCM1250 > > using the instructions and patches on the "Linux > From > > Scratch" website. You need to look for the > > cross-compiler version of their guide, then select > > "browse online" and finally "mips64" to get to the > > instructions/patches for building for the 64-bit > MIPS > > platforms. > > > > Do NOT use their kernel or kernel patches - use > the > > version in the git repository on linux-mips. > > > > > > Johnathan, I'm on of the developers of CLFS, did you > run into a problem > with the patches? The patch is diff kernel.org and > linux-mips.org > kernels. Just curious, if we missed something let me > know. No, the patches are fine. The problem is "Rapid Development Syndrome" - no matter how fast the patches are updated, critical bugfixes will likely work their way into the git repository before the next patch update. This isn't a big issue for 99.99% of the tools - there, updates are as likely to cause problems as fix them, so the delay is actually beneficial. (Now, -configuring- the Linux kernel can be interesting, as I've yet to get dialog to function correctly...) Jonathan __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From mendoza.ricardo@gmail.com Mon Jun 12 21:03:44 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 12 Jun 2006 21:03:53 +0100 (BST) Received: from wr-out-0506.google.com ([64.233.184.226]:35023 "EHLO wr-out-0506.google.com") by ftp.linux-mips.org with ESMTP id S8133653AbWFLUDo (ORCPT ); Mon, 12 Jun 2006 21:03:44 +0100 Received: by wr-out-0506.google.com with SMTP id 71so1202775wri for ; Mon, 12 Jun 2006 13:03:43 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=TM6FX72IPnNiP3QO1bUHuiEuAzIiFpcVxR1iZkGo5Y4YYoGG5eNn4OEfXICvlYtBHLNVjwI+/JxeiCXHVjYQZ0aO3RjZzaxClXVC/JE6xBZDgVHnBuTptKmMkS1qor1dYh0qg5WehSBC16bqO+uPs62BeFpdydCGNniUqX9bWVI= Received: by 10.85.2.9 with SMTP id e9mr7245360aui; Mon, 12 Jun 2006 13:03:43 -0700 (PDT) Received: by 10.85.9.16 with HTTP; Mon, 12 Jun 2006 13:03:43 -0700 (PDT) Message-ID: <816d36d30606121303u4e6529aat24bf60cd6ae8c37c@mail.gmail.com> Date: Mon, 12 Jun 2006 16:03:43 -0400 From: "Ricardo Mendoza" To: "Juergen Sell" Subject: Re: Support for Vadem/Clio with NEC VR4121 anyone? Cc: linux-mips@linux-mips.org In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11716 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: mendoza.ricardo@gmail.com Precedence: bulk X-list: linux-mips The current 2.6 kernel has a good support base for VR41XX processors, I am working with a 2.6.15 on a VR4121 MobilePro. I had some problems booting 2.6.16, but never really looked much into it, instead im still working on pcmcia support on my device. Try booting one of these and hooking up a serial console, after that it's a matter of having the right external device drivers. Most of the vrc4171 function drivers are out there and can be found easily; although if your device uses a different set of controllers for peripherals such as LCD, PCMCIA and sound then it might need some more work on your side. Ricardo On 6/12/06, Juergen Sell wrote: > Hi, > I did aquire such a device, by now 5 years old. From what I found > searching various archives it might have had linux vr or linux mips > support at one point around 2001 but > this seem to be lost? (I even found a binay of a 2.3.99 linux kernel, > but no docs, no config no modules, nothing else. So that seems pretty > useless, right?) > > Anyway I would very much prefer Linux over the embedded win/ce. > Now I am wondering whether any current pointers or configuration is > available to get me started? A working kernel config file might be a > good start (for a recent kernel perhaps?). > By now I have a boot-loader that works under win/ce and loads from a > cf-card (tested with the above mentioned linux kernel binary). From wilson@specifix.com Mon Jun 12 21:40:47 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 12 Jun 2006 21:40:56 +0100 (BST) Received: from w099.z064220152.sjc-ca.dsl.cnc.net ([64.220.152.99]:19606 "HELO duck.specifix.com") by ftp.linux-mips.org with SMTP id S8133872AbWFLUkr (ORCPT ); Mon, 12 Jun 2006 21:40:47 +0100 Received: from [127.0.0.1] (duck.corp.specifix.com [192.168.1.1]) by duck.specifix.com (Postfix) with ESMTP id EC57FFC8B for ; Mon, 12 Jun 2006 13:40:25 -0700 (PDT) Subject: Re: bcm1480 doubled process accounting times From: James E Wilson To: linux-mips@linux-mips.org In-Reply-To: <1141081478.9097.42.camel@aretha.corp.specifix.com> References: <1141081478.9097.42.camel@aretha.corp.specifix.com> Content-Type: text/plain Message-Id: <1150144825.9243.90.camel@aretha.corp.specifix.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Mon, 12 Jun 2006 13:40:25 -0700 Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11717 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: wilson@specifix.com Precedence: bulk X-list: linux-mips On Mon, 2006-02-27 at 15:04, James E Wilson wrote: > Running a UP kernel on a bcm1480 board, I get nonsensical timing > results I'd like some info about how to get patches into the linux kernel. I sent this patch in February. http://www.linux-mips.org/archives/linux-mips/2006-02/msg00404.html I've been using it since then without apparent problem. I didn't get any comments from my earlier message, and I see the patch hasn't made it into the tree on linux-mips yet. How can I get this patch into the linux kernel tree? -- Jim Wilson, GNU Tools Support, http://www.specifix.com From ralf@linux-mips.org Mon Jun 12 22:23:18 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 12 Jun 2006 22:23:28 +0100 (BST) Received: from localhost.localdomain ([127.0.0.1]:8865 "EHLO bacchus.dhis.org") by ftp.linux-mips.org with ESMTP id S8133879AbWFLVXS (ORCPT ); Mon, 12 Jun 2006 22:23:18 +0100 Received: from denk.linux-mips.net (denk.linux-mips.net [127.0.0.1]) by bacchus.dhis.org (8.13.6/8.13.4) with ESMTP id k5CLNHKt006838; Mon, 12 Jun 2006 22:23:17 +0100 Received: (from ralf@localhost) by denk.linux-mips.net (8.13.6/8.13.6/Submit) id k5CLNHRk006837; Mon, 12 Jun 2006 22:23:17 +0100 Date: Mon, 12 Jun 2006 22:23:17 +0100 From: Ralf Baechle To: James E Wilson Cc: linux-mips@linux-mips.org Subject: Re: bcm1480 doubled process accounting times Message-ID: <20060612212317.GA6565@linux-mips.org> References: <1141081478.9097.42.camel@aretha.corp.specifix.com> <1150144825.9243.90.camel@aretha.corp.specifix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1150144825.9243.90.camel@aretha.corp.specifix.com> User-Agent: Mutt/1.4.2.1i Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11718 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ralf@linux-mips.org Precedence: bulk X-list: linux-mips On Mon, Jun 12, 2006 at 01:40:25PM -0700, James E Wilson wrote: > I'd like some info about how to get patches into the linux kernel. > > I sent this patch in February. > http://www.linux-mips.org/archives/linux-mips/2006-02/msg00404.html > I've been using it since then without apparent problem. I didn't get > any comments from my earlier message, and I see the patch hasn't made it > into the tree on linux-mips yet. > > How can I get this patch into the linux kernel tree? Blame me, things do get lost. Resending and yelling is the protocol. Will apply in a minute. Ralf From ralf@linux-mips.org Mon Jun 12 23:58:49 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 12 Jun 2006 23:58:57 +0100 (BST) Received: from localhost.localdomain ([127.0.0.1]:14556 "EHLO bacchus.dhis.org") by ftp.linux-mips.org with ESMTP id S8133885AbWFLW6t (ORCPT ); Mon, 12 Jun 2006 23:58:49 +0100 Received: from denk.linux-mips.net (denk.linux-mips.net [127.0.0.1]) by bacchus.dhis.org (8.13.6/8.13.4) with ESMTP id k5CMwnd2009189; Mon, 12 Jun 2006 23:58:49 +0100 Received: (from ralf@localhost) by denk.linux-mips.net (8.13.6/8.13.6/Submit) id k5CMwm4m009188; Mon, 12 Jun 2006 23:58:48 +0100 Date: Mon, 12 Jun 2006 23:58:48 +0100 From: Ralf Baechle To: Jonathan Day Cc: linux-mips@linux-mips.org Subject: Re: Performance counters and profiling on MIPS Message-ID: <20060612225848.GA7163@linux-mips.org> References: <20060607172252.47981.qmail@web31512.mail.mud.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060607172252.47981.qmail@web31512.mail.mud.yahoo.com> User-Agent: Mutt/1.4.2.1i Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11719 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ralf@linux-mips.org Precedence: bulk X-list: linux-mips On Wed, Jun 07, 2006 at 10:22:52AM -0700, Jonathan Day wrote: > Two quick and semi-related questions for the Gurus of > the MIPS. First off, it would appear that profiling on > any of the Broadcom MIPS processors is broken. I get > the following warnings when compiling the > platform-specific irq.c file: This is ZBus-based profiling which also isn't supported by the standard profiling tool oprofile. Oprofile is using the performance counters of the processor itself. > My second question is with regards to accessing the > performance counters and timestamp counters from > userspace. On some architectures, this is as simple as > using a single macro. > > In the case of the ix86 architecture (yuk!), the > timestamp counters can be read with nothing more than > an rdtsc() call, as follows: > > asm volatile ("rdtsc" : "=a"(*(elg_ui4 > *)&clock_value), > "=d"(*(((elg_ui4 *)&clock_value)+1))); > > What is the closest equiv. for the MIPS processors? On most R4000-style processors (that includes the SB1 core of the Sibyte chips) applications can access the cycle counter through an mfc0 $reg, $c0_count instruction. However mfc0 is a priviledged instruction, so that doesn't work for code that doesn't have kernel priviledges. For release 2 of the MISP32 / MIPS64 architecture there is a new instruction, rdhwr which an application - so the OS permits it - can use to read c0_count. Now there are two problems with that approach in your case: o SB1 implements release 0.95 of the MIPS64 architecture, SB1A release 1. Iow these cores don't have rdhwr. o In general on a multiprocessor system you don't have a guarantee that the count registers of all processors are running at the same speed or were set to the same value at any time. This is more of a general problem; in case of the BCM1250 the cores are actually running at the same speed and afair are synchronized by the reset. Ralf From vagabon.xyz@gmail.com Tue Jun 13 08:01:18 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 13 Jun 2006 08:01:27 +0100 (BST) Received: from wr-out-0506.google.com ([64.233.184.237]:46358 "EHLO wr-out-0506.google.com") by ftp.linux-mips.org with ESMTP id S8133358AbWFMHBS (ORCPT ); Tue, 13 Jun 2006 08:01:18 +0100 Received: by wr-out-0506.google.com with SMTP id 58so98125wri for ; Tue, 13 Jun 2006 00:01:17 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=sNw7ePyI5xkl+26DOs3xOsiejZCJUGamoWbHj4kZfubo2p9tipcz58num23TIk9lvIH7ZBEPS15RYXEb7D2U429Fz+NT/LrOyDUexI0B/B51YJQ3DiiX5ZcXzlWY3KjCBV+m3zlQyiFEYw49HNceV1Vf2xJsmAdhzYFoxmSzAfM= Received: by 10.54.124.15 with SMTP id w15mr520446wrc; Tue, 13 Jun 2006 00:01:17 -0700 (PDT) Received: by 10.54.156.16 with HTTP; Tue, 13 Jun 2006 00:01:17 -0700 (PDT) Message-ID: Date: Tue, 13 Jun 2006 09:01:17 +0200 From: "Franck Bui-Huu" To: "Chad Reese" Subject: Re: Any examples / docs for getting SPARSEMEM to work? Cc: linux-mips@linux-mips.org In-Reply-To: <446CB5D8.107@caviumnetworks.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <446CB5D8.107@caviumnetworks.com> Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11720 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: vagabon.xyz@gmail.com Precedence: bulk X-list: linux-mips Hi, 2006/5/18, Chad Reese : > Hello All, > > I've spent the last few days trying to get SPARSEMEM to work on a 64bit Mips > kernel. The processor I'm using has large wholes in its memory map. > > Memory layout: > 0 - 0x10000000 First 256MB > 0x410000000 - 0x420000000 Second 256MB Sorry for the delay, I didn't notice your post before... Just out of curiosity, what value for PAGE_OFFSET do you use ? In other word how do you convert a physical address into a virtual one if you use these two memories ? Could you show us the virtual address ranges for each memories ? > 0x20000000 - ? The rest of memory > > Up until now I've used the flat memory model and not mapped the 2nd 256MB. This > is rather wasteful for boards with 512MB of memory. SPARSEMEM look like what I > need, but I've been unable to get it working. My attempts to configure it always > end with sparse_index_alloc calling alloc_bootmem_node which fails to allocate > 4KB. In prom_init I've added memory using add_memory_region. > > Are there any reasonably easy to follow implementations of sparsemem? I figure > I'm missing something very basic, but perusal of Mips and the other > architectures haven't helped much. > > My baseline is linux-mips 2.6.14. > > Any help would be appreciated, > > Chad > -- Franck From freddy@dusktilldawn.nl Tue Jun 13 11:35:52 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 13 Jun 2006 11:36:03 +0100 (BST) Received: from tool.snarl.nl ([213.84.251.124]:27545 "HELO tool.snarl.nl") by ftp.linux-mips.org with SMTP id S8133412AbWFMKfw (ORCPT ); Tue, 13 Jun 2006 11:35:52 +0100 Received: from localhost (tool.local.snarl.nl [127.0.0.1]) by tool.snarl.nl (Postfix) with ESMTP id 83DC35DF5C; Tue, 13 Jun 2006 12:35:36 +0200 (CEST) Received: from tool.snarl.nl ([127.0.0.1]) by localhost (tool.local.snarl.nl [127.0.0.1]) (amavisd-new, port 10024) with LMTP id xuyrl4+DvAKL; Tue, 13 Jun 2006 12:35:34 +0200 (CEST) Received: by tool.snarl.nl (Postfix, from userid 1000) id B1D095DF45; Tue, 13 Jun 2006 12:35:34 +0200 (CEST) Date: Tue, 13 Jun 2006 12:35:34 +0200 From: Freddy Spierenburg To: Domen Puncer Cc: linux-mips@linux-mips.org Subject: Re: Fix potential bug in au1xxx_ddma_add_device() Message-ID: <20060613103534.GB5374@dusktilldawn.nl> References: <20060413131117.GP11097@dusktilldawn.nl> <20060414060640.GE29489@domen.ultra.si> <20060418092052.GZ11097@dusktilldawn.nl> <20060419062238.GF29489@domen.ultra.si> <20060419072549.GJ11097@dusktilldawn.nl> <20060613081641.GH5568@domen.ultra.si> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="uXxzq0nDebZQVNAZ" Content-Disposition: inline In-Reply-To: <20060613081641.GH5568@domen.ultra.si> X-User-Agent-Feature: All mail clients suck. This one just sucks less. X-GPG-Key: http://snarl.nl/~freddy/keys/freddyPublicKey.gpg User-Agent: Mutt/1.5.11+cvs20060403 Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11721 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: freddy@dusktilldawn.nl Precedence: bulk X-list: linux-mips --uXxzq0nDebZQVNAZ Content-Type: multipart/mixed; boundary="24zk1gE8NUlDmwG9" Content-Disposition: inline --24zk1gE8NUlDmwG9 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi Domen, On Tue, Jun 13, 2006 at 10:16:42AM +0200, Domen Puncer wrote: > First a note, that your patch [dbdma.patch] doesn't make any > difference for me. Well... at least not an obvious one. That's exactly what it should do, since it's a bug that I do not yet expect to happen. So no difference is good for now. Including the patch, so hopefully Ralf sees it again. :-) > OK. I have an IDE drive connected now. It's a bit weird, with > CONFIG_BLK_DEV_IDE_AU1XXX_PIO_DBDMA I can't enable dma with > hdparm, but if works on about 6 MB/sec. > With CONFIG_BLK_DEV_IDE_AU1XXX_MDMA2_DBDMA, I can enable DMA, > but it works slow, like 1.7 MB/sec. >=20 > Seems odd to me. Hmmmm, strange. You should at least expect the other way around. Transferring you to the mailing list, hopefully somebody over there has got a clue. --=20 $ cat ~/.signature Freddy Spierenburg http://freddy.snarl.nl/ GnuPG: 0x7941D1E1=3DC948 5851 26D2 FA5C 39F1 E588 6F17 FD5D 7941 D1E1 $ # Please read http://www.ietf.org/rfc/rfc2015.txt before complain! --24zk1gE8NUlDmwG9 Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="dbdma.patch" Content-Transfer-Encoding: quoted-printable --- linux-2.6.16-orig/include/asm-mips/mach-au1x00/au1xxx_dbdma.h 2006-03-2= 0 11:35:39.000000000 +0000 +++ linux-2.6.16/include/asm-mips/mach-au1x00/au1xxx_dbdma.h 2006-03-31 14:= 31:56.000000000 +0000 @@ -200,7 +200,10 @@ #define DSCR_CMD0_ALWAYS 31 #define DSCR_NDEV_IDS 32 /* THis macro is used to find/create custom device types */ -#define DSCR_DEV2CUSTOM_ID(x,d) (((((x)&0xFFFF)<<8)|0x32000000)|((d)&0xFF)) +#define DSCR_ID_BASE 0x32000000 +#define DSCR_ID_OFFSET 0x1000 +#define DSCR_ID_FREE DSCR_ID_BASE +#define DSCR_DEV2CUSTOM_ID(x,d) (((((x)&0xFFFF)<<8)|DSCR_ID_BASE)|((d)&0xF= F)) #define DSCR_CUSTOM2DEV_ID(x) ((x)&0xFF) =20 =20 --- linux-2.6.16-orig/arch/mips/au1000/common/dbdma.c 2006-03-20 11:35:39.0= 00000000 +0000 +++ linux-2.6.16/arch/mips/au1000/common/dbdma.c 2006-03-31 14:31:58.000000= 000 +0000 @@ -162,22 +162,22 @@ { DSCR_CMD0_ALWAYS, DEV_FLAGS_ANYUSE, 0, 0, 0x00000000, 0, 0 }, =20 /* Provide 16 user definable device types */ - { 0, 0, 0, 0, 0, 0, 0 }, - { 0, 0, 0, 0, 0, 0, 0 }, - { 0, 0, 0, 0, 0, 0, 0 }, - { 0, 0, 0, 0, 0, 0, 0 }, - { 0, 0, 0, 0, 0, 0, 0 }, - { 0, 0, 0, 0, 0, 0, 0 }, - { 0, 0, 0, 0, 0, 0, 0 }, - { 0, 0, 0, 0, 0, 0, 0 }, - { 0, 0, 0, 0, 0, 0, 0 }, - { 0, 0, 0, 0, 0, 0, 0 }, - { 0, 0, 0, 0, 0, 0, 0 }, - { 0, 0, 0, 0, 0, 0, 0 }, - { 0, 0, 0, 0, 0, 0, 0 }, - { 0, 0, 0, 0, 0, 0, 0 }, - { 0, 0, 0, 0, 0, 0, 0 }, - { 0, 0, 0, 0, 0, 0, 0 }, + { DSCR_ID_FREE, 0, 0, 0, 0, 0, 0 }, + { DSCR_ID_FREE, 0, 0, 0, 0, 0, 0 }, + { DSCR_ID_FREE, 0, 0, 0, 0, 0, 0 }, + { DSCR_ID_FREE, 0, 0, 0, 0, 0, 0 }, + { DSCR_ID_FREE, 0, 0, 0, 0, 0, 0 }, + { DSCR_ID_FREE, 0, 0, 0, 0, 0, 0 }, + { DSCR_ID_FREE, 0, 0, 0, 0, 0, 0 }, + { DSCR_ID_FREE, 0, 0, 0, 0, 0, 0 }, + { DSCR_ID_FREE, 0, 0, 0, 0, 0, 0 }, + { DSCR_ID_FREE, 0, 0, 0, 0, 0, 0 }, + { DSCR_ID_FREE, 0, 0, 0, 0, 0, 0 }, + { DSCR_ID_FREE, 0, 0, 0, 0, 0, 0 }, + { DSCR_ID_FREE, 0, 0, 0, 0, 0, 0 }, + { DSCR_ID_FREE, 0, 0, 0, 0, 0, 0 }, + { DSCR_ID_FREE, 0, 0, 0, 0, 0, 0 }, + { DSCR_ID_FREE, 0, 0, 0, 0, 0, 0 }, }; =20 #define DBDEV_TAB_SIZE (sizeof(dbdev_tab) / sizeof(dbdev_tab_t)) @@ -208,9 +208,9 @@ { u32 ret =3D 0; dbdev_tab_t *p=3DNULL; - static u16 new_id=3D0x1000; + static u16 new_id=3DDSCR_ID_OFFSET; =20 - p =3D find_dbdev_id(0); + p =3D find_dbdev_id(DSCR_ID_FREE); if ( NULL !=3D p ) { memcpy(p, dev, sizeof(dbdev_tab_t)); --24zk1gE8NUlDmwG9-- --uXxzq0nDebZQVNAZ Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (GNU/Linux) iD8DBQFEjpT2bxf9XXlB0eERAnphAKDXXubclMn+9FpMlT+zseREFXNx3wCg6bP5 GiOhw3AAK6qXMXTDOQz7JlY= =gaQK -----END PGP SIGNATURE----- --uXxzq0nDebZQVNAZ-- From ralf@linux-mips.org Tue Jun 13 14:34:38 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 13 Jun 2006 14:34:46 +0100 (BST) Received: from localhost.localdomain ([127.0.0.1]:21900 "EHLO bacchus.dhis.org") by ftp.linux-mips.org with ESMTP id S8133784AbWFMNei (ORCPT ); Tue, 13 Jun 2006 14:34:38 +0100 Received: from denk.linux-mips.net (denk.linux-mips.net [127.0.0.1]) by bacchus.dhis.org (8.13.6/8.13.4) with ESMTP id k5DDYbIi009745; Tue, 13 Jun 2006 14:34:37 +0100 Received: (from ralf@localhost) by denk.linux-mips.net (8.13.6/8.13.6/Submit) id k5DDYb8O009744; Tue, 13 Jun 2006 14:34:37 +0100 Date: Tue, 13 Jun 2006 14:34:37 +0100 From: Ralf Baechle To: Rodolfo Giometti Cc: linux-mips@linux-mips.org Subject: Re: [PATCH] APM (emu) support Message-ID: <20060613133437.GA9186@linux-mips.org> References: <20060605154310.GF27426@enneenne.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060605154310.GF27426@enneenne.com> User-Agent: Mutt/1.4.2.1i Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11722 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ralf@linux-mips.org Precedence: bulk X-list: linux-mips On Mon, Jun 05, 2006 at 05:43:10PM +0200, Rodolfo Giometti wrote: > here my proposal to add APM (emu) support into mips tree. It's just > the one for ARM adapted... > > I have tested it on my au1100 based board with a battery pack. Also > the command: > > $ apm --suspend > > works correctly! Looking good, indeed. There is a sore spot though. Your patch creates arch/mips/kernel/apm.c as an essentially unmodified copy of arch/arch/kernel/apm.c and the latter as you have found is actually portable code. So I suggest you rather move that file to drivers/char/ and use it for both architectures. Ralf From AOumanski@extremenetworks.com Tue Jun 13 18:15:00 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 13 Jun 2006 18:15:09 +0100 (BST) Received: from mail3.extremenetworks.com ([207.179.9.4]:14928 "EHLO extrgate1.extremenetworks.com") by ftp.linux-mips.org with ESMTP id S8133737AbWFMRPA (ORCPT ); Tue, 13 Jun 2006 18:15:00 +0100 Received: by extrgate1.extremenetworks.com with Internet Mail Service (5.5.2656.59) id ; Tue, 13 Jun 2006 10:14:52 -0700 Message-ID: <4C8B0EA487B9554D910B0587CD91395C042F9A1F@sc-msexch-03.extremenetworks.com> From: Alex Oumanski To: "'linux-mips@linux-mips.org'" Subject: Do I use right image? Date: Tue, 13 Jun 2006 10:06:33 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="iso-8859-1" Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11723 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: AOumanski@extremenetworks.com Precedence: bulk X-list: linux-mips I built linux 2.6 for sibyte1250 CPU, and see in the top directory image named vmlinux I try to boot this image by issuing: pboot tftp://10.211.32.100/vmlinux "root=/dev/ram0 ro init=/linuxrc pacman=1" from the boot rom prompt of my board. The board hangs and I don't see a single message ever coming out on my console. Do I use right image? From imipak@yahoo.com Tue Jun 13 22:27:52 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 13 Jun 2006 22:28:01 +0100 (BST) Received: from web31506.mail.mud.yahoo.com ([68.142.198.135]:6781 "HELO web31506.mail.mud.yahoo.com") by ftp.linux-mips.org with SMTP id S8133880AbWFMV1w (ORCPT ); Tue, 13 Jun 2006 22:27:52 +0100 Received: (qmail 64711 invoked by uid 60001); 13 Jun 2006 21:27:43 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=F9AJ5UTpcCqAdYDwLiUL9JELWEPcxtTVycgtY06xW7LFJT1NejaykLpLscvHLQFoVFQ6SVpXtXwxVwXs2E7OQ6u8DrbSxOVwF/BqTXQ40q1YbhhKBbhPeyqPNhUa9sR9mrr32+oq9YoSv+4QgQWOlxjl2aGZyNRACUR1pa9J3YA= ; Message-ID: <20060613212743.64709.qmail@web31506.mail.mud.yahoo.com> Received: from [208.187.37.98] by web31506.mail.mud.yahoo.com via HTTP; Tue, 13 Jun 2006 14:27:43 PDT Date: Tue, 13 Jun 2006 14:27:43 -0700 (PDT) From: Jonathan Day Subject: Re: Performance counters and profiling on MIPS To: Ralf Baechle Cc: linux-mips@linux-mips.org In-Reply-To: <20060612225848.GA7163@linux-mips.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11724 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: imipak@yahoo.com Precedence: bulk X-list: linux-mips Thank you for the valuable information. One thing I'd like to throw open to the list: there's one way to access the counters on the R4000-type processors, another on the version 2 MIPS64, yet another on the ix86, and so on. Would it make sense to place some standardised interface in, say, the assembly header files and hide the implementation-specific details? In the case of the R4000-type cores, this would need to involve some sort of counter device in the kernel which the macro would call to perform the priviledged instruction. (It feels a little bit of a hack, but it's the simplest way to provide access to resources that aren't made public.) What I'm thinking is that this generic interface would then be used on all other architectures, where such counters exist. That way, implementation-specific stuff can be abstracted out and programs that need access to performance counters can all be coded to a generic interface, rather than one interface for each version of every CPU API, which is inevitably going to be far more prone to error. Jonathan --- Ralf Baechle wrote: > On Wed, Jun 07, 2006 at 10:22:52AM -0700, Jonathan > Day wrote: > > > Two quick and semi-related questions for the Gurus > of > > the MIPS. First off, it would appear that > profiling on > > any of the Broadcom MIPS processors is broken. I > get > > the following warnings when compiling the > > platform-specific irq.c file: > > This is ZBus-based profiling which also isn't > supported by the standard > profiling tool oprofile. Oprofile is using the > performance counters of > the processor itself. > > > My second question is with regards to accessing > the > > performance counters and timestamp counters from > > userspace. On some architectures, this is as > simple as > > using a single macro. > > > > In the case of the ix86 architecture (yuk!), the > > timestamp counters can be read with nothing more > than > > an rdtsc() call, as follows: > > > > asm volatile ("rdtsc" : "=a"(*(elg_ui4 > > *)&clock_value), > > "=d"(*(((elg_ui4 > *)&clock_value)+1))); > > > > What is the closest equiv. for the MIPS > processors? > > On most R4000-style processors (that includes the > SB1 core of the Sibyte > chips) applications can access the cycle counter > through an > mfc0 $reg, $c0_count instruction. However mfc0 is a > priviledged > instruction, so that doesn't work for code that > doesn't have kernel > priviledges. > > For release 2 of the MISP32 / MIPS64 architecture > there is a new > instruction, rdhwr which an application - so the OS > permits it - can > use to read c0_count. > > Now there are two problems with that approach in > your case: > > o SB1 implements release 0.95 of the MIPS64 > architecture, SB1A release 1. > Iow these cores don't have rdhwr. > o In general on a multiprocessor system you don't > have a guarantee that > the count registers of all processors are running > at the same speed or > were set to the same value at any time. > This is more of a general problem; in case of > the BCM1250 the cores > are actually running at the same speed and afair > are synchronized by > the reset. > > Ralf > > __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From p.boddupalli@gmail.com Tue Jun 13 22:44:32 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 13 Jun 2006 22:44:41 +0100 (BST) Received: from wx-out-0102.google.com ([66.249.82.201]:22886 "EHLO wx-out-0102.google.com") by ftp.linux-mips.org with ESMTP id S8133865AbWFMVoc (ORCPT ); Tue, 13 Jun 2006 22:44:32 +0100 Received: by wx-out-0102.google.com with SMTP id t5so982258wxc for ; Tue, 13 Jun 2006 14:44:29 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=uT/8hinHjL++OaDcBc7vASg320Vte8RbAJ1+UNZ7y+FZZdnFLg2A1kE8RAY9fGs+88y1vTIaKhqh08EGqMgPxv/cS4QiD8/IpwDET5Cd4gXZwzsHk8x5Q26NuJhlWCyyXmJBHAnCGwXM1zU4MgBF0NBmAUeKbZzKijj6gwFPmNc= Received: by 10.70.7.5 with SMTP id 5mr7930147wxg; Tue, 13 Jun 2006 14:44:28 -0700 (PDT) Received: by 10.70.73.1 with HTTP; Tue, 13 Jun 2006 14:44:28 -0700 (PDT) Message-ID: Date: Tue, 13 Jun 2006 14:44:28 -0700 From: "Prasad Boddupalli" To: "Jonathan Day" Subject: Re: Performance counters and profiling on MIPS Cc: linux-mips@linux-mips.org In-Reply-To: <20060613212743.64709.qmail@web31506.mail.mud.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20060612225848.GA7163@linux-mips.org> <20060613212743.64709.qmail@web31506.mail.mud.yahoo.com> X-Google-Sender-Auth: fc5e28bfe1d559bd Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11725 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: bprasad@cs.arizona.edu Precedence: bulk X-list: linux-mips Perfctr (http://user.it.uu.se/~mikpe/linux/perfctr/) and PAPI (http://icl.cs.utk.edu/papi/) are precisely such attempts. Except that MIPS ports of them do not seem to be available. regards, Prasad. On 6/13/06, Jonathan Day wrote: > Thank you for the valuable information. > > One thing I'd like to throw open to the list: there's > one way to access the counters on the R4000-type > processors, another on the version 2 MIPS64, yet > another on the ix86, and so on. > > Would it make sense to place some standardised > interface in, say, the assembly header files and hide > the implementation-specific details? In the case of > the R4000-type cores, this would need to involve some > sort of counter device in the kernel which the macro > would call to perform the priviledged instruction. (It > feels a little bit of a hack, but it's the simplest > way to provide access to resources that aren't made > public.) > > What I'm thinking is that this generic interface would > then be used on all other architectures, where such > counters exist. That way, implementation-specific > stuff can be abstracted out and programs that need > access to performance counters can all be coded to a > generic interface, rather than one interface for each > version of every CPU API, which is inevitably going to > be far more prone to error. > > Jonathan From nigel@mips.com Tue Jun 13 23:57:57 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 13 Jun 2006 23:58:06 +0100 (BST) Received: from 209-232-97-206.ded.pacbell.net ([209.232.97.206]:163 "EHLO dns0.mips.com") by ftp.linux-mips.org with ESMTP id S8133835AbWFMW55 (ORCPT ); Tue, 13 Jun 2006 23:57:57 +0100 Received: from mercury.mips.com (sbcns-dmz [209.232.97.193]) by dns0.mips.com (8.12.11/8.12.11) with ESMTP id k5DMvWNr011609; Tue, 13 Jun 2006 15:57:33 -0700 (PDT) Received: from ukservices1.mips.com (ukservices1 [192.168.192.240]) by mercury.mips.com (8.13.5/8.13.5) with ESMTP id k5DMvX4p027741; Tue, 13 Jun 2006 15:57:33 -0700 (PDT) Received: from bank.mips.com ([192.168.192.132] helo=[127.0.0.1]) by ukservices1.mips.com with esmtp (Exim 3.36 #1 (Debian)) id 1FqHpA-0000el-00; Tue, 13 Jun 2006 23:57:28 +0100 Message-ID: <448F42D7.5060401@mips.com> Date: Tue, 13 Jun 2006 23:57:27 +0100 From: Nigel Stephens Organization: MIPS Technologies Inc User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Prasad Boddupalli CC: Jonathan Day , linux-mips@linux-mips.org Subject: Re: Performance counters and profiling on MIPS References: <20060612225848.GA7163@linux-mips.org> <20060613212743.64709.qmail@web31506.mail.mud.yahoo.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-MIPS-Technologies-UK-MailScanner: Found to be clean X-MIPS-Technologies-UK-MailScanner-From: nigel@mips.com X-Scanned-By: MIMEDefang 2.39 Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11726 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: nigel@mips.com Precedence: bulk X-list: linux-mips Prasad Boddupalli wrote: > Perfctr (http://user.it.uu.se/~mikpe/linux/perfctr/) and PAPI > (http://icl.cs.utk.edu/papi/) are precisely such attempts. Except that > MIPS ports of them do not seem to be available. There's also perfmon2, for which a MIPS patch is available - though no idea how up-to-date it is. See http://www.linux-mips.org/wiki/Perfmon2 Nigel From mrv@corecom.co.kr Wed Jun 14 11:50:58 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 14 Jun 2006 11:51:07 +0100 (BST) Received: from [220.76.242.187] ([220.76.242.187]:60083 "EHLO localhost.localdomain") by ftp.linux-mips.org with ESMTP id S8133478AbWFNKu6 (ORCPT ); Wed, 14 Jun 2006 11:50:58 +0100 Received: from mrv ([192.168.11.157]) by localhost.localdomain (8.12.8/8.12.8) with SMTP id k5EAqFBb029737 for ; Wed, 14 Jun 2006 19:52:18 +0900 Message-ID: <003401c68fa0$b60f4070$9d0ba8c0@mrv> From: "Roman Mashak" To: Subject: "undefined symbol" on 2.6.14 Date: Wed, 14 Jun 2006 19:53:01 +0900 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="koi8-r"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 FL-Build: Fidolook 2002 (SL) 6.0.2800.86 - 14/6/2003 22:16:25 Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11727 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: mrv@corecom.co.kr Precedence: bulk X-list: linux-mips Hello. I compiled driver as a module (for our own device) for MIPS target. At loading time get: unresolved symbol 'mips_hpt_frequency' Modules.symvers which contains symbols doesn't have reference for 'mips_hpt_frequency'. Doesn it mean it's supposed to be exported with EXPORT_SYMBOL or my problem's reason lies on another layer? Thanks! With best regards, Roman Mashak. E-mail: mrv@corecom.co.kr From ralf@linux-mips.org Wed Jun 14 12:53:48 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 14 Jun 2006 12:53:56 +0100 (BST) Received: from localhost.localdomain ([127.0.0.1]:10183 "EHLO bacchus.dhis.org") by ftp.linux-mips.org with ESMTP id S8133500AbWFNLxr (ORCPT ); Wed, 14 Jun 2006 12:53:47 +0100 Received: from denk.linux-mips.net (denk.linux-mips.net [127.0.0.1]) by bacchus.dhis.org (8.13.6/8.13.4) with ESMTP id k5EBrHP4004795; Wed, 14 Jun 2006 12:53:17 +0100 Received: (from ralf@localhost) by denk.linux-mips.net (8.13.6/8.13.6/Submit) id k5EBrGRs004794; Wed, 14 Jun 2006 12:53:16 +0100 Date: Wed, 14 Jun 2006 12:53:16 +0100 From: Ralf Baechle To: Roman Mashak Cc: linux-mips@linux-mips.org Subject: Re: "undefined symbol" on 2.6.14 Message-ID: <20060614115316.GA4515@linux-mips.org> References: <003401c68fa0$b60f4070$9d0ba8c0@mrv> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <003401c68fa0$b60f4070$9d0ba8c0@mrv> User-Agent: Mutt/1.4.2.1i Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11728 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ralf@linux-mips.org Precedence: bulk X-list: linux-mips On Wed, Jun 14, 2006 at 07:53:01PM +0900, Roman Mashak wrote: > I compiled driver as a module (for our own device) for MIPS target. At > loading time get: > > unresolved symbol 'mips_hpt_frequency' > > Modules.symvers which contains symbols doesn't have reference for > 'mips_hpt_frequency'. Doesn it mean it's supposed to be exported with > EXPORT_SYMBOL or my problem's reason lies on another layer? The symbol isn't export simply because it wasn't considered useful to export it. The expected use of mips_hpt_frequency is to initialize it in the platform code as system startup time to the counter frequency, then not look at it again. I wonder how you're using it in your module? Any export I would add - as per general policy for the kernel - an EXPORT_SYMBOL_GPL btw. Ralf From anemo@mba.ocn.ne.jp Wed Jun 14 16:11:41 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 14 Jun 2006 16:11:50 +0100 (BST) Received: from mba.ocn.ne.jp ([210.190.142.172]:63475 "HELO smtp.mba.ocn.ne.jp") by ftp.linux-mips.org with SMTP id S8133532AbWFNPLl (ORCPT ); Wed, 14 Jun 2006 16:11:41 +0100 Received: from localhost (p4237-ipad30funabasi.chiba.ocn.ne.jp [221.184.79.237]) by smtp.mba.ocn.ne.jp (Postfix) with ESMTP id 21496B63B; Thu, 15 Jun 2006 00:11:36 +0900 (JST) Date: Thu, 15 Jun 2006 00:12:38 +0900 (JST) Message-Id: <20060615.001238.65193088.anemo@mba.ocn.ne.jp> To: libc-ports@sourceware.org Cc: linux-mips@linux-mips.org Subject: mips RDHWR instruction in glibc From: Atsushi Nemoto X-Fingerprint: 6ACA 1623 39BD 9A94 9B1A B746 CA77 FE94 2874 D52F X-Pgp-Public-Key: http://wwwkeys.pgp.net/pks/lookup?op=get&search=0x2874D52F X-Mailer: Mew version 3.3 on Emacs 21.4 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11729 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: anemo@mba.ocn.ne.jp Precedence: bulk X-list: linux-mips I got many "Reserved Instruction" exceptions with gcc 4.1 + glibc 2.4 userland. They were due to RDHWR instruction to support TLS. If a system call returned an error, glibc must save the result to errno, which is thread-local, so RDHWR used. I can understand this scenario. But it seems the RDHWR is often called on non-error cases. For example, in the code below, RDHWR is placed _before_ checking the error. I suppose these instructions were reordered by gcc's optimization, but the optimization would have large negative effect in this case. 00566fc4 <_IO_file_read>: 566fc4: 3c1c0016 lui gp,0x16 566fc8: 279c87ac addiu gp,gp,-30804 566fcc: 0399e021 addu gp,gp,t9 566fd0: 8c82003c lw v0,60(a0) 566fd4: 30420002 andi v0,v0,0x2 566fd8: 14400003 bnez v0,566fe8 <_IO_file_read+0x24> 566fdc: 8f999e9c lw t9,-24932(gp) 566fe0: 03200008 jr t9 566fe4: 8c840038 lw a0,56(a0) 566fe8: 8c840038 lw a0,56(a0) 566fec: 24020fa3 li v0,4003 566ff0: 0000000c syscall 566ff4: 8f84a528 lw a0,-23256(gp) 566ff8: 7c03e83b rdhwr v1,$29 566ffc: 00832021 addu a0,a0,v1 567000: 14e00003 bnez a3,567010 <_IO_file_read+0x4c> 567004: 00401821 move v1,v0 567008: 03e00008 jr ra 56700c: 00601021 move v0,v1 567010: 2403ffff li v1,-1 567014: 1000fffc b 567008 <_IO_file_read+0x44> 567018: ac820000 sw v0,0(a0) I'm not sure where to fix, but I doubt some inline asm code in glibc lack "volatile" keyword. Does anyone have a clue on this? --- Atsushi Nemoto From beauregard.francois@addi-data.com Wed Jun 14 16:23:21 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 14 Jun 2006 16:23:36 +0100 (BST) Received: from [62.154.208.154] ([62.154.208.154]:49888 "EHLO firewall1.addi-data.de") by ftp.linux-mips.org with ESMTP id S8133544AbWFNPXV convert rfc822-to-8bit (ORCPT ); Wed, 14 Jun 2006 16:23:21 +0100 Received: from [172.16.2.26] (helo=security01.addi-data.intra) by firewall1.addi-data.de with esmtp (Exim 4.43) id 1FqXD9-0003Sf-12 for linux-mips@linux-mips.org; Wed, 14 Jun 2006 17:23:15 +0200 Received: from security1.addi-data.de (exchange01.addi-data.intra) by security01.addi-data.intra (Clearswift SMTPRS 5.2.3) with ESMTP id for ; Wed, 14 Jun 2006 17:23:13 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8BIT Subject: Bigphysarea and MIPS Date: Wed, 14 Jun 2006 17:23:13 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Bigphysarea and MIPS Thread-Index: AcaPxX63590XRhrqQtK/+I7f3/rcjA== From: "Francois Beauregard" To: Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11730 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: Beauregard.Francois@addi-data.com Precedence: bulk X-list: linux-mips Hello everybody, it's my first post on the list, so be indulgent, I'm a newbee. I'm writing a driver using a DMA transfer between on board RAM of a card and a memory ring buffer in kernel space. The processor is a Toshiba Tx49. The PCI controller is a PLX PCI9054 rev AC. It's seems to work fine. The ring buffer in kernel space is then mmap()'ed in user's space using remap_page_range(). The kernel is a 2.4.22 - bigphys version. The driver writes the pattern 0123456789 in this ring buffer (as uint32_t), and transfers those data on the on board ram thanks to the DMA (pci->local). Then I transfer those data into the same ring buffer, but 10 uint32_t further. (local->pci) So I may read 01234567890123456789. I have to use a continuous memory ring buffer (about 2MBytes) due to the speed of the card. That's why I allocated it firstly with bigphysarea patch. (I will describe it later) As I encountered a problem with this patch, I tried to use pci_alloc_consistent (arch/mips/kernel/pci-dma.c) instead (after I read the O'Reilly Linux Driver book). With this function, the DMA transfer succeeds (the pattern is ok: 01234567890123456789), but the mmap() call raised a PCI Bus error. (I have seen in the mailing list that I probably have to modify mk_pte_phys(). Am I wrong?) Now, my problem with bigphysarea. The allocation of the ring buffer is done trough bigphysarea_alloc_pages (mm/bigphysarea.c). (I add bigphysarea=[number] as described in the documentation). After boot, sometimes I read 01234567890000000000. Sometimes 01234567890000000089. Then the next DMA transfer returns: 01234567890000006789 I tried to pass different flags to bigphysarea_alloc_pages (GFP_ATOMIC|GFP_DMA, GFP_KERNEL|GFP_DMA ...) without success. I took a look at the source code of the two functions, and I tried to understand the difference, but the code is too dependent on the hardware for my knowledge))-; pci_alloc_consistent and bigphysarea patch call finally __get_free_pages, but bigphysarea uses kmalloc call whereas pci_alloc_consistent makes some operation with dma_cache_wback_inv. I know that the flag CONFIG_NONCOHERENT_IO is set. The addresses of the ring buffer are respectively 0x27820000 and 0x002FA000 with bigphysarea and pci_alloc_consistent. Are'nt bigphysarea and mips compliant? How could I solve this problem? Did anyone succeed with bigphysarea and mips in association? Thanks a lot. Regards, /*this function allocated the ring buffer,with bigphysarea or pci_alloc_consistent * bigphysarea is a global variable */ int alloc_ring_buffer(struct pci_dev *dev, uint32_t number_of_pages) { uint32_t free_mem=0; PRIVDATA (dev)->PC_ring_buffer_size=number_of_pages*PAGE_SIZE; if (bigphysarea){ printk("Using Bigphysarea\n"); bigphysarea_kinfo(&Free_Mem); /*returns the size of avialable memory*/ if (free_memPC_ring_buffer_size; /*pci_alloc_consistent seems to use the flags : GFP_ATOMIC and GFP_DMA*/ PRIVDATA (dev)->PC_ring_buffer_virt_addr= (uint32_t* ) bigphysarea_alloc_pages (number_of_pages,1,/*GFP_ATOMIC|GFP_DMA*/GFP_KERNEL); if (PRIVDATA (dev)->PC_ring_buffer_virt_addr) { unsigned long adr = (unsigned long)PRIVDATA (dev)->PC_ring_buffer_virt_addr; while (size > 0) { mem_map_reserve(virt_to_page(phys_to_virt(adr))); adr += PAGE_SIZE; size -= PAGE_SIZE; } } PRIVDATA (dev)->PC_ring_buffer_bus_addr=virt_to_bus (PRIVDATA (dev)->PC_ring_buffer_virt_addr); } }else{ printk("Using pci_alloc_consistent\n"); free_mem=free_mem;/*remove warning*/ /*allocation*/ PRIVDATA (dev)->PC_ring_buffer_virt_addr= pci_alloc_consistent(dev, PRIVDATA (dev)->PC_ring_buffer_size, &PRIVDATA (dev)->PC_ring_buffer_bus_addr); /*put a flag to all the allocated pages*/ if (PRIVDATA (dev)->PC_ring_buffer_virt_addr){ struct page *page,*end_page; /*the last page*/ end_page=virt_to_page(PRIVDATA (dev)->PC_ring_buffer_virt_addr+PRIVDATA (dev)->PC_ring_buffer_size-1); for (page=virt_to_page(PRIVDATA (dev)->PC_ring_buffer_virt_addr);page<=end_page;page++) set_bit(PG_reserved,&page->flags); } } if (!(PRIVDATA (dev)->PC_ring_buffer_virt_addr)){ printk("Can't allocated contiguous memory\n"); return -ENOMEM; } else printk("Allocation of the contiguous memory OK\nVirtual Address: %lX\n"\ "Bus physical Address: %lX\n",(unsigned long)PRIVDATA (dev)->PC_ring_buffer_virt_addr,(unsigned long)PRIVDATA (dev)->PC_ring_buffer_bus_addr); memset(PRIVDATA (dev)->PC_ring_buffer_virt_addr,0,number_of_pages*PAGE_SIZE); return 0; } /*-----------------------------------------------------------/ * pci_alloc_consistent * /*-----------------------------------------------------------*/ void *pci_alloc_consistent(struct pci_dev *hwdev, size_t size, dma_addr_t * dma_handle) { void *ret; int gfp = GFP_ATOMIC; struct pci_bus *bus = NULL; #ifdef CONFIG_ISA if (hwdev == NULL || hwdev->dma_mask != 0xffffffff) gfp |= GFP_DMA; #endif ret = (void *) __get_free_pages(gfp, get_order(size)); if (ret != NULL) { memset(ret, 0, size); if (hwdev) bus = hwdev->bus; *dma_handle = bus_to_baddr(bus, __pa(ret)); #ifdef CONFIG_NONCOHERENT_IO dma_cache_wback_inv((unsigned long) ret, size); ret = UNCAC_ADDR(ret); #endif } return ret; } /*-----------------------------------------------------------/ * bigphysarea_alloc_pages * /*-----------------------------------------------------------*/ caddr_t bigphysarea_alloc_pages(int count, int align, int priority) { range_t *range, **range_ptr, *new_range, *align_range; caddr_t aligned_base; if (init_level < 2) if (init2(priority)) return 0; new_range = NULL; align_range = NULL; if (align == 0) align = PAGE_SIZE; else align = align * PAGE_SIZE; /* * Search a free block which is large enough, even with alignment. */ range_ptr = &free_list; while (*range_ptr != NULL) { range = *range_ptr; aligned_base = (caddr_t)((((unsigned long)range->base + align - 1) / align) * align); if (aligned_base + count * PAGE_SIZE <= range->base + range->size) break; range_ptr = &range->next; } if (*range_ptr == NULL) return 0; range = *range_ptr; /* * When we have to align, the pages needed for alignment can * be put back to the free pool. * We check here if we need a second range data structure later * and allocate it now, so that we don't have to check for a * failed kmalloc later. */ if (aligned_base - range->base + count * PAGE_SIZE < range->size) { new_range = kmalloc(sizeof(range_t), priority); if (new_range == NULL) return NULL; } if (aligned_base != range->base) { align_range = kmalloc(sizeof(range_t), priority); if (align_range == NULL) { if (new_range != NULL) kfree(new_range); return NULL; } align_range->base = range->base; align_range->size = aligned_base - range->base; range->base = aligned_base; range->size -= align_range->size; align_range->next = range; *range_ptr = align_range; range_ptr = &align_range->next; } if (new_range != NULL) { /* * Range is larger than needed, create a new list element for * the used list and shrink the element in the free list. */ new_range->base = range->base; new_range->size = count * PAGE_SIZE; range->base = new_range->base + new_range->size; range->size = range->size - new_range->size; } else { /* * Range fits perfectly, remove it from free list. */ *range_ptr = range->next; new_range = range; } /* * Insert block into used list */ new_range->next = used_list; used_list = new_range; return new_range->base; } ********************************************************************** 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 system manager. This footnote confirms that this email message has been scanned for the presence of computer viruses. ********************************************************************** From drow@nevyn.them.org Wed Jun 14 17:50:45 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 14 Jun 2006 17:50:54 +0100 (BST) Received: from nevyn.them.org ([66.93.172.17]:39345 "EHLO nevyn.them.org") by ftp.linux-mips.org with ESMTP id S8133582AbWFNQup (ORCPT ); Wed, 14 Jun 2006 17:50:45 +0100 Received: from drow by nevyn.them.org with local (Exim 4.54) id 1FqYZk-000599-89; Wed, 14 Jun 2006 12:50:40 -0400 Date: Wed, 14 Jun 2006 12:50:40 -0400 From: Daniel Jacobowitz To: Atsushi Nemoto Cc: libc-ports@sourceware.org, linux-mips@linux-mips.org Subject: Re: mips RDHWR instruction in glibc Message-ID: <20060614165040.GA19480@nevyn.them.org> References: <20060615.001238.65193088.anemo@mba.ocn.ne.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060615.001238.65193088.anemo@mba.ocn.ne.jp> User-Agent: Mutt/1.5.11+cvs20060403 Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11731 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: dan@debian.org Precedence: bulk X-list: linux-mips On Thu, Jun 15, 2006 at 12:12:38AM +0900, Atsushi Nemoto wrote: > If a system call returned an error, glibc must save the result to > errno, which is thread-local, so RDHWR used. I can understand this > scenario. But it seems the RDHWR is often called on non-error cases. Libc uses TLS for many things other than just errno. The GCC port knows how to generate the agreed-upon rdhwr instruction directly. > For example, in the code below, RDHWR is placed _before_ checking the > error. I suppose these instructions were reordered by gcc's > optimization, but the optimization would have large negative effect in > this case. You'd have to figure out how to get GCC not to eagerly schedule the rdhwr. This might be quite hard. I don't know much about this part of the scheduler. -- Daniel Jacobowitz CodeSourcery From imipak@yahoo.com Wed Jun 14 19:14:39 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 14 Jun 2006 19:14:48 +0100 (BST) Received: from web31506.mail.mud.yahoo.com ([68.142.198.135]:48523 "HELO web31506.mail.mud.yahoo.com") by ftp.linux-mips.org with SMTP id S8133627AbWFNSOi (ORCPT ); Wed, 14 Jun 2006 19:14:38 +0100 Received: (qmail 38316 invoked by uid 60001); 14 Jun 2006 18:14:31 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=nP+ddtses2oi5wlM31DtmT3MEYqWCPCsTJ4SoEkAIP9Dw44wBUUHErZhhK+ntDgkRAxRaV6sV9NuekW/M0cIrm7nNAO0Z4LTHS0JCkQJ1x7bqqvZPDvmFBgp0Uqb1O2FAj26tP9nuEWdrao5TrZmiot+1BscNY7NNp1PEFznCs0= ; Message-ID: <20060614181431.38314.qmail@web31506.mail.mud.yahoo.com> Received: from [208.187.37.98] by web31506.mail.mud.yahoo.com via HTTP; Wed, 14 Jun 2006 11:14:31 PDT Date: Wed, 14 Jun 2006 11:14:31 -0700 (PDT) From: Jonathan Day Subject: Re: Performance counters and profiling on MIPS To: Nigel Stephens , Prasad Boddupalli Cc: linux-mips@linux-mips.org In-Reply-To: <448F42D7.5060401@mips.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11732 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: imipak@yahoo.com Precedence: bulk X-list: linux-mips Ok, the kernel version number listed is current to 2.6.17-rc6, and the MIPS patches -almost- go in cleanly. In the syscalls in arch/mips/kernel, there is a new syscall (sys_tee) that throws the patches off as it is not in the context. This is very easy to massage. The same is true of include/asm-mips/unistd.h, except there the count of syscalls is also off by one. Again, a very easy fix. Other than that, it looks current and looks good. I'm going to be doing some testing on it, to see whether it works as well as it looks, or whether it causes the CPU to leap three feet in the air, discharging the magic blue smoke. If other people have had success with it, though, I would definitely suggest considering it for inclusion in the linux-mips GIT tree. Those who don't need performance counters won't be adversely affected, and those of us who do would likely benefit. If the linux-mips tree would not be appropriate, then could someone take up hypnosis and get it included in the main tree? Jonathan --- Nigel Stephens wrote: > Prasad Boddupalli wrote: > > Perfctr > (http://user.it.uu.se/~mikpe/linux/perfctr/) and > PAPI > > (http://icl.cs.utk.edu/papi/) are precisely such > attempts. Except that > > MIPS ports of them do not seem to be available. > > There's also perfmon2, for which a MIPS patch is > available - though no > idea how up-to-date it is. See > http://www.linux-mips.org/wiki/Perfmon2 > > Nigel > __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From mrv@corecom.co.kr Thu Jun 15 01:38:17 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 15 Jun 2006 01:38:27 +0100 (BST) Received: from [220.76.242.187] ([220.76.242.187]:19934 "EHLO localhost.localdomain") by ftp.linux-mips.org with ESMTP id S8133906AbWFOAiR (ORCPT ); Thu, 15 Jun 2006 01:38:17 +0100 Received: from mrv ([192.168.11.157]) by localhost.localdomain (8.12.8/8.12.8) with SMTP id k5F0dYBb009479; Thu, 15 Jun 2006 09:39:39 +0900 Message-ID: <003c01c69014$4948a0c0$9d0ba8c0@mrv> From: "Roman Mashak" To: "Ralf Baechle" Cc: References: <003401c68fa0$b60f4070$9d0ba8c0@mrv> <20060614115316.GA4515@linux-mips.org> Subject: Re: "undefined symbol" on 2.6.14 Date: Thu, 15 Jun 2006 09:40:20 +0900 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="ISO-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 FL-Build: Fidolook 2002 (SL) 6.0.2800.86 - 14/6/2003 22:16:25 Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11733 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: mrv@corecom.co.kr Precedence: bulk X-list: linux-mips Hello, Ralf! You wrote to "Roman Mashak" on Wed, 14 Jun 2006 12:53:16 +0100: RB> The symbol isn't export simply because it wasn't considered useful to RB> export it. The expected use of mips_hpt_frequency is to initialize it RB> in the platform code as system startup time to the counter frequency, RB> then not look at it again. RB> I wonder how you're using it in your module? Actually it's not used anywhere in driver. Only timer functions and structures are in code. How come the linker refers to this particular function? RB> Any export I would add - as per general policy for the kernel - an RB> EXPORT_SYMBOL_GPL btw. With best regards, Roman Mashak. E-mail: mrv@corecom.co.kr From mrv@corecom.co.kr Thu Jun 15 02:07:53 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 15 Jun 2006 02:08:04 +0100 (BST) Received: from [220.76.242.187] ([220.76.242.187]:62661 "EHLO localhost.localdomain") by ftp.linux-mips.org with ESMTP id S8133862AbWFOBHx (ORCPT ); Thu, 15 Jun 2006 02:07:53 +0100 Received: from mrv ([192.168.11.157]) by localhost.localdomain (8.12.8/8.12.8) with SMTP id k5F19ABb009970; Thu, 15 Jun 2006 10:09:12 +0900 Message-ID: <003e01c69018$6bc4eb00$9d0ba8c0@mrv> From: "Roman Mashak" To: "Ralf Baechle" Cc: References: <003401c68fa0$b60f4070$9d0ba8c0@mrv> <20060614115316.GA4515@linux-mips.org> Subject: Re: "undefined symbol" on 2.6.14 Date: Thu, 15 Jun 2006 10:09:55 +0900 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="ISO-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 FL-Build: Fidolook 2002 (SL) 6.0.2800.86 - 14/6/2003 22:16:25 Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11734 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: mrv@corecom.co.kr Precedence: bulk X-list: linux-mips Hello, Ralf! You wrote to "Roman Mashak" on Wed, 14 Jun 2006 12:53:16 +0100: [skip] RB> The symbol isn't export simply because it wasn't considered useful to RB> export it. The expected use of mips_hpt_frequency is to initialize it RB> in the platform code as system startup time to the counter frequency, RB> then not look at it again. I should've been more clear here. We use MIPS-based processor from Cavium Networks and their toolchain and 64-bit mode patched kernel 2.6.14. RB> I wonder how you're using it in your module? With best regards, Roman Mashak. E-mail: mrv@corecom.co.kr From giometti@enneenne.com Thu Jun 15 09:13:10 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 15 Jun 2006 09:13:23 +0100 (BST) Received: from 81-174-11-161.f5.ngi.it ([81.174.11.161]:1153 "EHLO gundam.enneenne.com") by ftp.linux-mips.org with ESMTP id S8133975AbWFOING (ORCPT ); Thu, 15 Jun 2006 09:13:06 +0100 Received: from giometti by gundam.enneenne.com with local (Exim 3.36 #1 (Debian)) id 1FqmyL-00066p-00 for ; Thu, 15 Jun 2006 10:13:01 +0200 Date: Thu, 15 Jun 2006 10:13:01 +0200 From: Rodolfo Giometti To: linux-mips@linux-mips.org Subject: [PATCH] Invalid setting for SYS_WAKEMSK Message-ID: <20060615081301.GA22369@gundam.enneenne.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="tKW2IUtsqtDRztdT" Content-Disposition: inline Organization: GNU/Linux Device Drivers, Embedded Systems and Courses X-PGP-Key: gpg --keyserver keyserver.linux.it --recv-keys D25A5633 User-Agent: Mutt/1.5.5.1+cvs20040105i Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11735 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: giometti@linux.it Precedence: bulk X-list: linux-mips --tKW2IUtsqtDRztdT Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hello, the following patch fix setting of register SYS_WAKEMSK. Without this patch when you reset the board via hardware reset, and your bootloader supports wake up code, the board will execute wake up code instead of reset one. Ciao, Rodolfo -- GNU/Linux Solutions e-mail: giometti@enneenne.com Linux Device Driver giometti@gnudd.com Embedded Systems giometti@linux.it UNIX programming phone: +39 349 2432127 --tKW2IUtsqtDRztdT Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=patch-sys_wakesrc-on-reset-fix diff --git a/arch/mips/au1000/common/power.c b/arch/mips/au1000/common/power.c index 4175396..9b47082 100644 --- a/arch/mips/au1000/common/power.c +++ b/arch/mips/au1000/common/power.c @@ -281,8 +281,8 @@ int au_sleep(int reason, int force) DPRINTK("reason %d force %d wakeup %lX ticks %d\n", reason, force, wakeup, ticks); - au_writel(wakeup, SYS_WAKEMSK); au_writel(~0, SYS_WAKESRC); /* clear cause */ + au_writel(wakeup, SYS_WAKEMSK); au_sync(); DPRINTK("Zzz...\n"); @@ -301,6 +301,10 @@ int au_sleep(int reason, int force) if (reason&(1<<8)) /* Wake up thanks to TOY */ reason = -ticks*HZ; + au_writel(~0, SYS_WAKESRC); /* clear cause */ + au_writel(0, SYS_WAKEMSK); /* clear mask */ + au_sync(); + /* Call specific board routine */ if (board_after_sleep) board_after_sleep(reason); diff --git a/arch/mips/au1000/common/time.c b/arch/mips/au1000/common/time.c index 177606b..e807e1b 100644 --- a/arch/mips/au1000/common/time.c +++ b/arch/mips/au1000/common/time.c @@ -442,8 +442,8 @@ #ifdef CONFIG_PM au_writel(0, SYS_TOYWRITE); while (au_readl(SYS_COUNTER_CNTRL) & SYS_CNTRL_C0S); - au_writel(au_readl(SYS_WAKEMSK) | (1<<8), SYS_WAKEMSK); au_writel(~0, SYS_WAKESRC); + au_writel(0, SYS_WAKEMSK); au_sync(); while (au_readl(SYS_COUNTER_CNTRL) & SYS_CNTRL_M20); --tKW2IUtsqtDRztdT-- From yoichi_yuasa@tripeaks.co.jp Thu Jun 15 15:15:46 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 15 Jun 2006 15:15:59 +0100 (BST) Received: from mo30.po.2iij.net ([210.128.50.53]:19254 "EHLO mo30.po.2iij.net") by ftp.linux-mips.org with ESMTP id S8134052AbWFOOPq (ORCPT ); Thu, 15 Jun 2006 15:15:46 +0100 Received: by mo.po.2iij.net (mo30) id k5FEFg7C070160; Thu, 15 Jun 2006 23:15:42 +0900 (JST) Received: from localhost.localdomain (225.29.30.125.dy.iij4u.or.jp [125.30.29.225]) by mbox.po.2iij.net (mbox31) id k5FEFaCf052837 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 15 Jun 2006 23:15:37 +0900 (JST) Date: Thu, 15 Jun 2006 23:15:35 +0900 From: Yoichi Yuasa To: Ralf Baechle Cc: linux-mips@linux-mips.org Subject: [PATCH] vr41xx: conform TANBAC board name to Kconfig Message-Id: <20060615231535.68140419.yoichi_yuasa@tripeaks.co.jp> Organization: TriPeaks Corporation X-Mailer: Sylpheed version 1.0.4 (GTK+ 1.2.10; i386-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11736 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: yoichi_yuasa@tripeaks.co.jp Precedence: bulk X-list: linux-mips Hi Ralf, This patch conforms TANBAC board name to Kconfig. Please apply. Yoichi Signed-off-by: Yoichi Yuasa diff -pruN -X mips-rc6/Documentation/dontdiff mips-rc6-orig/arch/mips/Makefile mips-rc6/arch/mips/Makefile --- mips-rc6-orig/arch/mips/Makefile 2006-06-09 00:32:57.201212750 +0900 +++ mips-rc6/arch/mips/Makefile 2006-06-09 10:51:37.222981000 +0900 @@ -454,7 +454,7 @@ core-$(CONFIG_CASIO_E55) += arch/mips/vr load-$(CONFIG_CASIO_E55) += 0xffffffff80004000 # -# TANBAC TB0225 VR4131 Multi-chip module/TB0229 VR4131DIMM (VR4131) +# TANBAC VR4131 multichip module(TB0225) and TANBAC VR4131DIMM(TB0229) (VR4131) # load-$(CONFIG_TANBAC_TB022X) += 0xffffffff80000000 From yoichi_yuasa@tripeaks.co.jp Thu Jun 15 15:29:44 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 15 Jun 2006 15:29:53 +0100 (BST) Received: from mo32.po.2iij.net ([210.128.50.17]:43317 "EHLO mo32.po.2iij.net") by ftp.linux-mips.org with ESMTP id S8134062AbWFOO3o (ORCPT ); Thu, 15 Jun 2006 15:29:44 +0100 Received: by mo.po.2iij.net (mo32) id k5FETfqH029443; Thu, 15 Jun 2006 23:29:41 +0900 (JST) Received: from localhost.localdomain (225.29.30.125.dy.iij4u.or.jp [125.30.29.225]) by mbox.po.2iij.net (mbox32) id k5FETcbT088509 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 15 Jun 2006 23:29:39 +0900 (JST) Date: Thu, 15 Jun 2006 23:29:37 +0900 From: Yoichi Yuasa To: Ralf Baechle Cc: linux-mips@linux-mips.org Subject: [PATCH] vr41xx: remove unnecessay items from vr41xx/Kconfig Message-Id: <20060615232937.54908d91.yoichi_yuasa@tripeaks.co.jp> Organization: TriPeaks Corporation X-Mailer: Sylpheed version 1.0.4 (GTK+ 1.2.10; i386-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11737 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: yoichi_yuasa@tripeaks.co.jp Precedence: bulk X-list: linux-mips Hi Ralf, This patch removes unnecessary items from vr41xx/Kconfig. SYS_HA_CPU_VR41XX has already been selected by MACH_VR41XX. Yoichi Signed-off-by: Yoichi Yuasa diff -pruN -X mips-rc6/Documentation/dontdiff mips-rc6-orig/arch/mips/vr41xx/Kconfig mips-rc6/arch/mips/vr41xx/Kconfig --- mips-rc6-orig/arch/mips/vr41xx/Kconfig 2006-06-13 19:08:29.234587000 +0900 +++ mips-rc6/arch/mips/vr41xx/Kconfig 2006-06-14 09:48:08.362847750 +0900 @@ -4,7 +4,6 @@ config CASIO_E55 select DMA_NONCOHERENT select IRQ_CPU select ISA - select SYS_HAS_CPU_VR41XX select SYS_SUPPORTS_32BIT_KERNEL select SYS_SUPPORTS_LITTLE_ENDIAN @@ -14,18 +13,15 @@ config IBM_WORKPAD select DMA_NONCOHERENT select IRQ_CPU select ISA - select SYS_HAS_CPU_VR41XX select SYS_SUPPORTS_32BIT_KERNEL select SYS_SUPPORTS_LITTLE_ENDIAN config NEC_CMBVR4133 bool "Support for NEC CMB-VR4133" depends on MACH_VR41XX - select CPU_VR41XX select DMA_NONCOHERENT select IRQ_CPU select HW_HAS_PCI - select SYS_HAS_CPU_VR41XX select SYS_SUPPORTS_32BIT_KERNEL select SYS_SUPPORTS_LITTLE_ENDIAN @@ -41,7 +37,6 @@ config TANBAC_TB022X select DMA_NONCOHERENT select HW_HAS_PCI select IRQ_CPU - select SYS_HAS_CPU_VR41XX select SYS_SUPPORTS_32BIT_KERNEL select SYS_SUPPORTS_LITTLE_ENDIAN help @@ -74,7 +69,6 @@ config VICTOR_MPC30X select DMA_NONCOHERENT select HW_HAS_PCI select IRQ_CPU - select SYS_HAS_CPU_VR41XX select SYS_SUPPORTS_32BIT_KERNEL select SYS_SUPPORTS_LITTLE_ENDIAN @@ -84,7 +78,6 @@ config ZAO_CAPCELLA select DMA_NONCOHERENT select HW_HAS_PCI select IRQ_CPU - select SYS_HAS_CPU_VR41XX select SYS_SUPPORTS_32BIT_KERNEL select SYS_SUPPORTS_LITTLE_ENDIAN From anemo@mba.ocn.ne.jp Thu Jun 15 16:27:40 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 15 Jun 2006 16:27:50 +0100 (BST) Received: from mba.ocn.ne.jp ([210.190.142.172]:12788 "HELO smtp.mba.ocn.ne.jp") by ftp.linux-mips.org with SMTP id S8134067AbWFOP1k (ORCPT ); Thu, 15 Jun 2006 16:27:40 +0100 Received: from localhost (p7208-ipad209funabasi.chiba.ocn.ne.jp [58.88.118.208]) by smtp.mba.ocn.ne.jp (Postfix) with ESMTP id ECF7AFE; Fri, 16 Jun 2006 00:27:34 +0900 (JST) Date: Fri, 16 Jun 2006 00:28:37 +0900 (JST) Message-Id: <20060616.002837.59465125.anemo@mba.ocn.ne.jp> To: dan@debian.org Cc: libc-ports@sourceware.org, linux-mips@linux-mips.org Subject: Re: mips RDHWR instruction in glibc From: Atsushi Nemoto In-Reply-To: <20060614165040.GA19480@nevyn.them.org> References: <20060615.001238.65193088.anemo@mba.ocn.ne.jp> <20060614165040.GA19480@nevyn.them.org> X-Fingerprint: 6ACA 1623 39BD 9A94 9B1A B746 CA77 FE94 2874 D52F X-Pgp-Public-Key: http://wwwkeys.pgp.net/pks/lookup?op=get&search=0x2874D52F X-Mailer: Mew version 3.3 on Emacs 21.4 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11738 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: anemo@mba.ocn.ne.jp Precedence: bulk X-list: linux-mips On Wed, 14 Jun 2006 12:50:40 -0400, Daniel Jacobowitz wrote: > > For example, in the code below, RDHWR is placed _before_ checking the > > error. I suppose these instructions were reordered by gcc's > > optimization, but the optimization would have large negative effect in > > this case. > > You'd have to figure out how to get GCC not to eagerly schedule the > rdhwr. This might be quite hard. I don't know much about this part of > the scheduler. I really did not understand yet how errno is bound TLS. I found some "rdhwr" in glibc-ports source code (tls-macros.h, nptl/tls.h). The RDHWR instruction in the example code comes from one of them, no? I also found a "rdhwr" in gcc's mips.md file ("tls_get_tp_"). Is this the origin? MD is a very foreign language for me... --- Atsushi Nemoto From drow@nevyn.them.org Thu Jun 15 16:32:57 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 15 Jun 2006 16:33:06 +0100 (BST) Received: from nevyn.them.org ([66.93.172.17]:59548 "EHLO nevyn.them.org") by ftp.linux-mips.org with ESMTP id S8134067AbWFOPc5 (ORCPT ); Thu, 15 Jun 2006 16:32:57 +0100 Received: from drow by nevyn.them.org with local (Exim 4.54) id 1Fqtq0-0005cw-6P; Thu, 15 Jun 2006 11:32:52 -0400 Date: Thu, 15 Jun 2006 11:32:52 -0400 From: Daniel Jacobowitz To: Atsushi Nemoto Cc: libc-ports@sourceware.org, linux-mips@linux-mips.org Subject: Re: mips RDHWR instruction in glibc Message-ID: <20060615153252.GA21598@nevyn.them.org> References: <20060615.001238.65193088.anemo@mba.ocn.ne.jp> <20060614165040.GA19480@nevyn.them.org> <20060616.002837.59465125.anemo@mba.ocn.ne.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060616.002837.59465125.anemo@mba.ocn.ne.jp> User-Agent: Mutt/1.5.11+cvs20060403 Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11739 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: dan@debian.org Precedence: bulk X-list: linux-mips On Fri, Jun 16, 2006 at 12:28:37AM +0900, Atsushi Nemoto wrote: > On Wed, 14 Jun 2006 12:50:40 -0400, Daniel Jacobowitz wrote: > > > For example, in the code below, RDHWR is placed _before_ checking the > > > error. I suppose these instructions were reordered by gcc's > > > optimization, but the optimization would have large negative effect in > > > this case. > > > > You'd have to figure out how to get GCC not to eagerly schedule the > > rdhwr. This might be quite hard. I don't know much about this part of > > the scheduler. > > I really did not understand yet how errno is bound TLS. I found some > "rdhwr" in glibc-ports source code (tls-macros.h, nptl/tls.h). The > RDHWR instruction in the example code comes from one of them, no? No. > I also found a "rdhwr" in gcc's mips.md file ("tls_get_tp_"). > Is this the origin? MD is a very foreign language for me... Yes. Compile something like this with -O2 but without -fpic: __thread int x; int foo() { return x; } It should use the IE model, which will generate a rdhwr. -- Daniel Jacobowitz CodeSourcery From khali@linux-fr.org Thu Jun 15 21:57:20 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 15 Jun 2006 21:57:28 +0100 (BST) Received: from smtp-104-thursday.noc.nerim.net ([62.4.17.104]:26373 "HELO mallaury.nerim.net") by ftp.linux-mips.org with SMTP id S8134095AbWFOU5U (ORCPT ); Thu, 15 Jun 2006 21:57:20 +0100 Received: from arrakis.delvare (jdelvare.pck.nerim.net [62.212.121.182]) by mallaury.nerim.net (Postfix) with SMTP id 347EA4F3B0; Thu, 15 Jun 2006 22:57:04 +0200 (CEST) Date: Thu, 15 Jun 2006 22:57:23 +0200 From: Jean Delvare To: linux-mips@linux-mips.org, LKML Subject: i2c-algo-ite and i2c-ite planned for removal Message-Id: <20060615225723.012c82be.khali@linux-fr.org> X-Mailer: Sylpheed version 2.2.6 (GTK+ 2.6.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11740 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: khali@linux-fr.org Precedence: bulk X-list: linux-mips Hi all, I noticed today that we have an i2c bus driver named i2c-ite, supposedly useful on some MIPS systems which have an ITE8172 chip, which doesn't compile. It is based on an i2c algorithm driver named i2c-algo-ite, which doesn't compile either, due to some changes made to the i2c core which weren't properly reflected there. Going back trough the versions, I found that the bus driver was previously named i2c-adap-ite, and was introduced in 2.4.10. And I don't think it even compiled back then either, as it uses a structure (iic_ite) which isn't defined anywhere. So basically we have two drivers in the kernel tree for 5 years or so, which never were usable, and nobody seemed to care. It's about time to get rid of these 1296 lines of code, don't you think? So, unless someone volunteers to take care of these drivers, or otherwise has a very strong reason to object, I'm going to delete them from the tree soon. Thanks, -- Jean Delvare From ppopov@embeddedalley.com Thu Jun 15 22:23:53 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 15 Jun 2006 22:24:01 +0100 (BST) Received: from adsl-71-128-175-242.dsl.pltn13.pacbell.net ([71.128.175.242]:10157 "EHLO build.embeddedalley.com") by ftp.linux-mips.org with ESMTP id S8134095AbWFOVXx (ORCPT ); Thu, 15 Jun 2006 22:23:53 +0100 Received: from localhost.localdomain (build.embeddedalley.com [127.0.0.1]) by build.embeddedalley.com (8.13.1/8.13.1) with ESMTP id k5FLJnIG027822; Thu, 15 Jun 2006 14:19:54 -0700 Subject: Re: i2c-algo-ite and i2c-ite planned for removal From: Pete Popov Reply-To: ppopov@embeddedalley.com To: Jean Delvare Cc: linux-mips@linux-mips.org, LKML In-Reply-To: <20060615225723.012c82be.khali@linux-fr.org> References: <20060615225723.012c82be.khali@linux-fr.org> Content-Type: text/plain Organization: Embedded Alley Solutions, Inc Date: Fri, 16 Jun 2006 00:23:17 +0300 Message-Id: <1150406598.1193.73.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.4.1 Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11741 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ppopov@embeddedalley.com Precedence: bulk X-list: linux-mips On Thu, 2006-06-15 at 22:57 +0200, Jean Delvare wrote: > Hi all, > > I noticed today that we have an i2c bus driver named i2c-ite, > supposedly useful on some MIPS systems which have an ITE8172 chip, > which doesn't compile. It is based on an i2c algorithm driver named > i2c-algo-ite, which doesn't compile either, due to some changes made to > the i2c core which weren't properly reflected there. Going back trough > the versions, I found that the bus driver was previously named > i2c-adap-ite, and was introduced in 2.4.10. And I don't think it even > compiled back then either, as it uses a structure (iic_ite) which isn't > defined anywhere. > > So basically we have two drivers in the kernel tree for 5 years or so, > which never were usable, and nobody seemed to care. For historical correctness, this driver was once upon a time usable, though it was a few years ago. It was written by MV for some ref board that had the ITE chip and it did work. That ref board is no longer around so it's probably safe to nuke the driver. Pete > It's about time to > get rid of these 1296 lines of code, don't you think? So, unless someone > volunteers to take care of these drivers, or otherwise has a very > strong reason to object, I'm going to delete them from the tree soon. > > Thanks, From yoichi_yuasa@tripeaks.co.jp Fri Jun 16 07:02:21 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 16 Jun 2006 07:02:31 +0100 (BST) Received: from mo32.po.2iij.net ([210.128.50.17]:14089 "EHLO mo32.po.2iij.net") by ftp.linux-mips.org with ESMTP id S8133372AbWFPGCV (ORCPT ); Fri, 16 Jun 2006 07:02:21 +0100 Received: by mo.po.2iij.net (mo32) id k5G62HhF061584; Fri, 16 Jun 2006 15:02:17 +0900 (JST) Received: from localhost.localdomain (65.126.232.202.bf.2iij.net [202.232.126.65]) by mbox.po.2iij.net (mbox31) id k5G62FCD012496 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 16 Jun 2006 15:02:15 +0900 (JST) Message-Id: <200606160602.k5G62FCD012496@mbox31.po.2iij.net> Date: Fri, 16 Jun 2006 15:02:15 +0900 From: Yoichi Yuasa To: Ralf Baechle Cc: yoichi_yuasa@tripeaks.co.jp, linux-mips Subject: sys_tee for MIPS Organization: TriPeaks Corporation X-Mailer: Sylpheed version 1.0.4 (GTK+ 1.2.10; i386-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11742 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: yoichi_yuasa@tripeaks.co.jp Precedence: bulk X-list: linux-mips Hi Ralf, Did you push out the following commit to Linus? http://www.linux-mips.org/git?p=linux.git;a=commit;h=b302a15086885d8af325afc93679aab97730dc14 I cannot find it in Linus's git. Yoichi From lhrkernelcoder@gmail.com Fri Jun 16 13:22:39 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 16 Jun 2006 13:22:53 +0100 (BST) Received: from ug-out-1314.google.com ([66.249.92.175]:41394 "EHLO ug-out-1314.google.com") by ftp.linux-mips.org with ESMTP id S8133541AbWFPMWj (ORCPT ); Fri, 16 Jun 2006 13:22:39 +0100 Received: by ug-out-1314.google.com with SMTP id k3so1620445ugf for ; Fri, 16 Jun 2006 05:22:38 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=QJbi/RCrZZUtVdxi4XLqyp0UATH4qEKlA4MtWL/Rs9Lxoscl/L2LmT/a4JsAsq7d21HIcRA2lbOk3ykTU55KTvN1VlCk98WqkEVKGHeFwefpmUoSpE+p4nrFXfcIlqTyRBCTgDy8L4+YEPEkKNWb33TeDNNCKvVXFOPbyJbz5xY= Received: by 10.67.96.14 with SMTP id y14mr2686400ugl; Fri, 16 Jun 2006 05:22:37 -0700 (PDT) Received: by 10.67.86.14 with HTTP; Fri, 16 Jun 2006 05:22:37 -0700 (PDT) Message-ID: Date: Fri, 16 Jun 2006 17:22:37 +0500 From: "kernel coder" To: linux-mips@linux-mips.org Subject: gcc-4.1.0 cross-compile for MIPS MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11743 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: lhrkernelcoder@gmail.com Precedence: bulk X-list: linux-mips hi, I'm trying to cross compile gcc-4.1.0 for mipsel platform.Following is the sequence of commands which i'm using.My host system is i686. ../gcc-4.1.0/configure --target=mipsel --without-headres --prefix=/home/shahzad/install/ --with-newlib --enable-languages=c make But following error is generated /home/shahzad/mips_gcc/./gcc/xgcc -B/home/shahzad/mips_gcc/./gcc/ -B/home/shahzad/install//mipsel/bin/ -B/home/shahzad/install//mipsel/lib/ -isystem /home/shahzad/install//mipsel/include -isystem /home/shahzad/install//mipsel/sys-include -DHAVE_CONFIG_H -I. -I../../../gcc-4.1.0/libssp -I. -Wall -O2 -g -O2 -MT ssp.lo -MD -MP -MF .deps/ssp.Tpo -c ../../../gcc-4.1.0/libssp/ssp.c -o ssp.o ../../../gcc-4.1.0/libssp/ssp.c:46:20: error: fcntl.h: No such file or directory ../../../gcc-4.1.0/libssp/ssp.c: In function '__guard_setup': ../../../gcc-4.1.0/libssp/ssp.c:70: warning: implicit declaration of function 'open' ../../../gcc-4.1.0/libssp/ssp.c:70: error: 'O_RDONLY' undeclared (first use in this function) ../../../gcc-4.1.0/libssp/ssp.c:70: error: (Each undeclared identifier is reported only once ../../../gcc-4.1.0/libssp/ssp.c:70: error: for each function it appears in.) ../../../gcc-4.1.0/libssp/ssp.c:73: error: 'ssize_t' undeclared (first use in this function) ../../../gcc-4.1.0/libssp/ssp.c:73: error: expected ';' before 'size' ......................................... ........................................ I'm using fedora 5 as development platform and version of gcc installed on system is 4.1.0 thanks, shahzad From linux@cantastic.de Fri Jun 16 13:38:34 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 16 Jun 2006 13:38:43 +0100 (BST) Received: from moutng.kundenserver.de ([212.227.126.177]:24315 "EHLO moutng.kundenserver.de") by ftp.linux-mips.org with ESMTP id S8133593AbWFPMie (ORCPT ); Fri, 16 Jun 2006 13:38:34 +0100 Received: from [217.81.185.199] (helo=[192.168.178.44]) by mrelayeu.kundenserver.de (node=mrelayeu3) with ESMTP (Nemesis), id 0MKxQS-1FrDal2JmW-0000bp; Fri, 16 Jun 2006 14:38:28 +0200 Message-ID: <4492A642.6080808@cantastic.de> Date: Fri, 16 Jun 2006 14:38:26 +0200 From: Ralf Roesch User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: kernel coder CC: linux-mips@linux-mips.org Subject: Re: gcc-4.1.0 cross-compile for MIPS References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: kundenserver.de abuse@kundenserver.de login:fe0074b40cafaf3a4e4a4699a3836908 Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11744 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: linux@cantastic.de Precedence: bulk X-list: linux-mips I have successfully build a newlib based crosscompiler but it's gcc 4.0.3. Anyway I have some notes on your configuration: --without-headres (is it a typo?) Instead I have: --with-headers=/src/newlib/libc/include \ May be this helps. Regards Ralf kernel coder schrieb: > hi, > I'm trying to cross compile gcc-4.1.0 for mipsel platform.Following > is the sequence of commands which i'm using.My host system is i686. > > ../gcc-4.1.0/configure --target=mipsel --without-headres > --prefix=/home/shahzad/install/ --with-newlib --enable-languages=c > > make > > But following error is generated > > /home/shahzad/mips_gcc/./gcc/xgcc -B/home/shahzad/mips_gcc/./gcc/ > -B/home/shahzad/install//mipsel/bin/ > -B/home/shahzad/install//mipsel/lib/ -isystem > /home/shahzad/install//mipsel/include -isystem > /home/shahzad/install//mipsel/sys-include -DHAVE_CONFIG_H -I. > -I../../../gcc-4.1.0/libssp -I. -Wall -O2 -g -O2 -MT ssp.lo -MD -MP > -MF .deps/ssp.Tpo -c ../../../gcc-4.1.0/libssp/ssp.c -o ssp.o > ../../../gcc-4.1.0/libssp/ssp.c:46:20: error: fcntl.h: No such file or > directory > ../../../gcc-4.1.0/libssp/ssp.c: In function '__guard_setup': > ../../../gcc-4.1.0/libssp/ssp.c:70: warning: implicit declaration of > function 'open' > ../../../gcc-4.1.0/libssp/ssp.c:70: error: 'O_RDONLY' undeclared > (first use in this function) > ../../../gcc-4.1.0/libssp/ssp.c:70: error: (Each undeclared identifier > is reported only once > ../../../gcc-4.1.0/libssp/ssp.c:70: error: for each function it > appears in.) > ../../../gcc-4.1.0/libssp/ssp.c:73: error: 'ssize_t' undeclared (first > use in this function) > ../../../gcc-4.1.0/libssp/ssp.c:73: error: expected ';' before 'size' > ......................................... > ........................................ > > I'm using fedora 5 as development platform and version of gcc > installed on system is 4.1.0 > > thanks, > shahzad > From lhrkernelcoder@gmail.com Fri Jun 16 15:22:08 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 16 Jun 2006 15:22:17 +0100 (BST) Received: from ug-out-1314.google.com ([66.249.92.172]:38221 "EHLO ug-out-1314.google.com") by ftp.linux-mips.org with ESMTP id S8133774AbWFPOWI (ORCPT ); Fri, 16 Jun 2006 15:22:08 +0100 Received: by ug-out-1314.google.com with SMTP id k3so1683895ugf for ; Fri, 16 Jun 2006 07:22:05 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=WT54bM/yW6KTWpXPEcx4cnpi3a04pEP/tru3PY7L6s0J6cxX5P+En8LEid436w1ePQ8ysIFb4HWpSlSFK+LcfyTj2teTz7Bcuk7DNPp+6HPemc3oL7lyVfoPKZ1ndEA4h4k+fTydOD+krYFjxFT8IZtZ4cws6ERwTLlQqSA2iXk= Received: by 10.67.89.6 with SMTP id r6mr2793831ugl; Fri, 16 Jun 2006 07:22:05 -0700 (PDT) Received: by 10.67.86.14 with HTTP; Fri, 16 Jun 2006 07:22:05 -0700 (PDT) Message-ID: Date: Fri, 16 Jun 2006 19:22:05 +0500 From: "kernel coder" To: "Ralf Roesch" Subject: Re: gcc-4.1.0 cross-compile for MIPS Cc: linux-mips@linux-mips.org In-Reply-To: <4492A642.6080808@cantastic.de> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <4492A642.6080808@cantastic.de> Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11745 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: lhrkernelcoder@gmail.com Precedence: bulk X-list: linux-mips thanks ,i did a grep in gcc source directory for fcntl.h but there was no such file in source code. I think i should explicitly include path for fcntl.h file. For gcc-3.4.2 i used following sequence of commands. binutils ------------ ../binutils-2.16.1/configure --prefix=/home/shahzad/install --target=mipsel make make install gcc-3.4.2 ---------------------------- ../gcc-3.4.2/configure --prefix=/home/shahzad/install --target=mipsel --without-headers --with-newlib --enable-languages=c make make install glibc ----------- ../glibc-2.3.1/configure --host=mipsel --prefix="/usr" --enable-add-ons -with-headers=/home/shahzad/install/include make cross-compiling=yes --prefix="" install-headers gcc-3.4.2 -------------- ../gcc-3.4.2/configure --target=mipsel --prefix=/home/shahzad/install --disable-shared --with-headers=/home/shahzad/install/include --with-newlib --enable-languages=c make make install Should i change this sequence for gcc-4.1.0.Can someone give his sequence of commands for his successfull gcc build for mips. thanks, shahzad On 6/16/06, Ralf Roesch wrote: > I have successfully build a newlib based crosscompiler but it's gcc 4.0.3. > > Anyway I have some notes on your configuration: > > --without-headres (is it a typo?) > > Instead I have: > --with-headers=/src/newlib/libc/include \ > > May be this helps. > > Regards > Ralf > > kernel coder schrieb: > > hi, > > I'm trying to cross compile gcc-4.1.0 for mipsel platform.Following > > is the sequence of commands which i'm using.My host system is i686. > > > > ../gcc-4.1.0/configure --target=mipsel --without-headres > > --prefix=/home/shahzad/install/ --with-newlib --enable-languages=c > > > > make > > > > But following error is generated > > > > /home/shahzad/mips_gcc/./gcc/xgcc -B/home/shahzad/mips_gcc/./gcc/ > > -B/home/shahzad/install//mipsel/bin/ > > -B/home/shahzad/install//mipsel/lib/ -isystem > > /home/shahzad/install//mipsel/include -isystem > > /home/shahzad/install//mipsel/sys-include -DHAVE_CONFIG_H -I. > > -I../../../gcc-4.1.0/libssp -I. -Wall -O2 -g -O2 -MT ssp.lo -MD -MP > > -MF .deps/ssp.Tpo -c ../../../gcc-4.1.0/libssp/ssp.c -o ssp.o > > ../../../gcc-4.1.0/libssp/ssp.c:46:20: error: fcntl.h: No such file or > > directory > > ../../../gcc-4.1.0/libssp/ssp.c: In function '__guard_setup': > > ../../../gcc-4.1.0/libssp/ssp.c:70: warning: implicit declaration of > > function 'open' > > ../../../gcc-4.1.0/libssp/ssp.c:70: error: 'O_RDONLY' undeclared > > (first use in this function) > > ../../../gcc-4.1.0/libssp/ssp.c:70: error: (Each undeclared identifier > > is reported only once > > ../../../gcc-4.1.0/libssp/ssp.c:70: error: for each function it > > appears in.) > > ../../../gcc-4.1.0/libssp/ssp.c:73: error: 'ssize_t' undeclared (first > > use in this function) > > ../../../gcc-4.1.0/libssp/ssp.c:73: error: expected ';' before 'size' > > ......................................... > > ........................................ > > > > I'm using fedora 5 as development platform and version of gcc > > installed on system is 4.1.0 > > > > thanks, > > shahzad > > > From imipak@yahoo.com Fri Jun 16 16:42:05 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 16 Jun 2006 16:42:15 +0100 (BST) Received: from web31513.mail.mud.yahoo.com ([68.142.198.142]:63344 "HELO web31513.mail.mud.yahoo.com") by ftp.linux-mips.org with SMTP id S8133788AbWFPPmF (ORCPT ); Fri, 16 Jun 2006 16:42:05 +0100 Received: (qmail 74839 invoked by uid 60001); 16 Jun 2006 15:41:54 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=zIeB18by4sz1jMl/VMTheOXdD6x9OzrJmtqrDRWpiNy92Dk1t6hJFr6Xnw3GSQwoh+rSTiW52cRH66+urGmMsrjCUSiV5cwPh7WzggibOVfsdEGWhSyOY1Gk3eEj+lM9z42yzd86d1BPE4vf+Wicly9JLMwHMv1torqHaZOI94k= ; Message-ID: <20060616154154.74837.qmail@web31513.mail.mud.yahoo.com> Received: from [208.187.37.98] by web31513.mail.mud.yahoo.com via HTTP; Fri, 16 Jun 2006 08:41:54 PDT Date: Fri, 16 Jun 2006 08:41:54 -0700 (PDT) From: Jonathan Day Subject: Re: gcc-4.1.0 cross-compile for MIPS To: kernel coder , linux-mips@linux-mips.org In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11746 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: imipak@yahoo.com Precedence: bulk X-list: linux-mips Hi, Two quick questions in return! :) First, did you use the patches on the Linux From Scratch website, which fixes problems with GCC in a MIPS environment? (Although not using the MIPSEL environment myself, I'm on a big-endiam system, I learned very quickly that those patches really are essential.) The second question is why 4.1.0? 4.1.1 fixes some nasties, from what I understand, making that the better of the 4.1.x branch. On the flip-side, 4.0.3 is the last-known version of GCC that will compile G95 correctly, strongly hinting at remaining issues in 4.1.x that have the potential for generating incorrect code. (I've not been able to build 4.2.x from SVN for a while, although it adds some features I would love to use.) Jonathan Day --- kernel coder wrote: > hi, > I'm trying to cross compile gcc-4.1.0 for mipsel > platform.Following > is the sequence of commands which i'm using.My host > system is i686. > > ../gcc-4.1.0/configure --target=mipsel > --without-headres > --prefix=/home/shahzad/install/ --with-newlib > --enable-languages=c > > make > > But following error is generated > > /home/shahzad/mips_gcc/./gcc/xgcc > -B/home/shahzad/mips_gcc/./gcc/ > -B/home/shahzad/install//mipsel/bin/ > -B/home/shahzad/install//mipsel/lib/ -isystem > /home/shahzad/install//mipsel/include -isystem > /home/shahzad/install//mipsel/sys-include > -DHAVE_CONFIG_H -I. > -I../../../gcc-4.1.0/libssp -I. -Wall -O2 -g -O2 -MT > ssp.lo -MD -MP > -MF .deps/ssp.Tpo -c ../../../gcc-4.1.0/libssp/ssp.c > -o ssp.o > ../../../gcc-4.1.0/libssp/ssp.c:46:20: error: > fcntl.h: No such file or directory > ../../../gcc-4.1.0/libssp/ssp.c: In function > '__guard_setup': > ../../../gcc-4.1.0/libssp/ssp.c:70: warning: > implicit declaration of > function 'open' > ../../../gcc-4.1.0/libssp/ssp.c:70: error: > 'O_RDONLY' undeclared > (first use in this function) > ../../../gcc-4.1.0/libssp/ssp.c:70: error: (Each > undeclared identifier > is reported only once > ../../../gcc-4.1.0/libssp/ssp.c:70: error: for each > function it appears in.) > ../../../gcc-4.1.0/libssp/ssp.c:73: error: 'ssize_t' > undeclared (first > use in this function) > ../../../gcc-4.1.0/libssp/ssp.c:73: error: expected > ';' before 'size' > ......................................... > ........................................ > > I'm using fedora 5 as development platform and > version of gcc > installed on system is 4.1.0 > > thanks, > shahzad > > __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From anemo@mba.ocn.ne.jp Fri Jun 16 16:57:49 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 16 Jun 2006 16:57:57 +0100 (BST) Received: from mba.ocn.ne.jp ([210.190.142.172]:16368 "HELO smtp.mba.ocn.ne.jp") by ftp.linux-mips.org with SMTP id S8133788AbWFPP5t (ORCPT ); Fri, 16 Jun 2006 16:57:49 +0100 Received: from localhost (p7155-ipad213funabasi.chiba.ocn.ne.jp [124.85.72.155]) by smtp.mba.ocn.ne.jp (Postfix) with ESMTP id C79A6A940; Sat, 17 Jun 2006 00:57:41 +0900 (JST) Date: Sat, 17 Jun 2006 00:58:45 +0900 (JST) Message-Id: <20060617.005845.93020013.anemo@mba.ocn.ne.jp> To: dan@debian.org Cc: libc-ports@sourceware.org, linux-mips@linux-mips.org Subject: Re: mips RDHWR instruction in glibc From: Atsushi Nemoto In-Reply-To: <20060615153252.GA21598@nevyn.them.org> References: <20060614165040.GA19480@nevyn.them.org> <20060616.002837.59465125.anemo@mba.ocn.ne.jp> <20060615153252.GA21598@nevyn.them.org> X-Fingerprint: 6ACA 1623 39BD 9A94 9B1A B746 CA77 FE94 2874 D52F X-Pgp-Public-Key: http://wwwkeys.pgp.net/pks/lookup?op=get&search=0x2874D52F X-Mailer: Mew version 3.3 on Emacs 21.4 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11747 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: anemo@mba.ocn.ne.jp Precedence: bulk X-list: linux-mips On Thu, 15 Jun 2006 11:32:52 -0400, Daniel Jacobowitz wrote: > > I also found a "rdhwr" in gcc's mips.md file ("tls_get_tp_"). > > Is this the origin? MD is a very foreign language for me... > > Yes. Compile something like this with -O2 but without -fpic: > > __thread int x; > int foo() { return x; } > > It should use the IE model, which will generate a rdhwr. Thanks. So this must be a gcc issue, not glibc issue. extern __thread int x; int foo(int arg) { if (arg) return x; return 0; } If I compiled this program with -O2 I got: foo: .frame $sp,0,$31 # vars= 0, regs= 0/0, args= 0, gp= 0 .mask 0x00000000,0 .fmask 0x00000000,0 .set noreorder .cpload $25 .set nomacro lw $2,%gottprel(x)($28) .set push .set mips32r2 rdhwr $3,$29 .set pop addu $2,$2,$3 beq $4,$0,$L4 move $3,$0 lw $3,0($2) $L4: j $31 move $2,$3 It looks too bad for arg == 0 case. I should ask on gcc list. --- Atsushi Nemoto From anemo@mba.ocn.ne.jp Fri Jun 16 17:58:44 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 16 Jun 2006 17:58:53 +0100 (BST) Received: from mba.ocn.ne.jp ([210.190.142.172]:35520 "HELO smtp.mba.ocn.ne.jp") by ftp.linux-mips.org with SMTP id S8134029AbWFPQ6o (ORCPT ); Fri, 16 Jun 2006 17:58:44 +0100 Received: from localhost (p7155-ipad213funabasi.chiba.ocn.ne.jp [124.85.72.155]) by smtp.mba.ocn.ne.jp (Postfix) with ESMTP id 7BB099AB2; Sat, 17 Jun 2006 01:58:39 +0900 (JST) Date: Sat, 17 Jun 2006 01:59:42 +0900 (JST) Message-Id: <20060617.015942.63131409.anemo@mba.ocn.ne.jp> To: linux-mips@linux-mips.org Cc: dan@debian.org, macro@linux-mips.org Subject: Re: mips RDHWR instruction in glibc From: Atsushi Nemoto In-Reply-To: <20060617.005845.93020013.anemo@mba.ocn.ne.jp> References: <20060616.002837.59465125.anemo@mba.ocn.ne.jp> <20060615153252.GA21598@nevyn.them.org> <20060617.005845.93020013.anemo@mba.ocn.ne.jp> X-Fingerprint: 6ACA 1623 39BD 9A94 9B1A B746 CA77 FE94 2874 D52F X-Pgp-Public-Key: http://wwwkeys.pgp.net/pks/lookup?op=get&search=0x2874D52F X-Mailer: Mew version 3.3 on Emacs 21.4 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11748 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: anemo@mba.ocn.ne.jp Precedence: bulk X-list: linux-mips On Sat, 17 Jun 2006 00:58:45 +0900 (JST), Atsushi Nemoto wrote: > It looks too bad for arg == 0 case. I should ask on gcc list. OTOH, I think it would be better to reduce RDHWR overhead in kernel anyway. I've heard about "fastpath" approach by Maciej, but now I can not find the patch on linux-mips ML archive. Is it available on somewhere? Maciej? --- Atsushi Nemoto From Shane_McDonald@pmc-sierra.com Fri Jun 16 18:10:58 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 16 Jun 2006 18:11:07 +0100 (BST) Received: from father.pmc-sierra.com ([216.241.224.13]:1182 "HELO father.pmc-sierra.bc.ca") by ftp.linux-mips.org with SMTP id S8134029AbWFPRK6 (ORCPT ); Fri, 16 Jun 2006 18:10:58 +0100 Received: (qmail 23516 invoked by uid 101); 16 Jun 2006 17:10:45 -0000 Received: from unknown (HELO ogyruan.pmc-sierra.bc.ca) (216.241.226.236) by father.pmc-sierra.com with SMTP; 16 Jun 2006 17:10:45 -0000 Received: from bby1exi01.pmc_nt.nt.pmc-sierra.bc.ca (bby1exi01.pmc-sierra.bc.ca [216.241.231.251]) by ogyruan.pmc-sierra.bc.ca (8.13.3/8.12.7) with ESMTP id k5GHAdld019226; Fri, 16 Jun 2006 10:10:40 -0700 Received: by bby1exi01.pmc-sierra.bc.ca with Internet Mail Service (5.5.2656.59) id ; Fri, 16 Jun 2006 10:10:39 -0700 Message-ID: <9328C220997E4E448CC833AF1AB402DA0344D906@bby1exm08.pmc_nt.nt.pmc-sierra.bc.ca> From: Shane McDonald To: "'Jean Delvare'" , linux-mips@linux-mips.org, LKML Subject: RE: i2c-algo-ite and i2c-ite planned for removal Date: Fri, 16 Jun 2006 10:10:33 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11749 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: Shane_McDonald@pmc-sierra.com Precedence: bulk X-list: linux-mips Hi: PMC-Sierra has an eval board (the "Xiao Hu") that uses these files. We haven't (yet) pushed out patches to add support for this board, but we hope to at some time. The kernel we use on the board is based on 2.6.14, so I could generate a patch so that these files will compile against 2.6.14. I'm guessing the patch will also apply to 2.6.16.20, since these files haven't changed for so long. I'll put together the patch and make sure it's still correct against 2.6.16.20, then submit it. Shane > -----Original Message----- > From: linux-mips-bounce@linux-mips.org > [mailto:linux-mips-bounce@linux-mips.org] On Behalf Of Jean Delvare > Sent: Thursday, June 15, 2006 2:57 PM > To: linux-mips@linux-mips.org; LKML > Subject: i2c-algo-ite and i2c-ite planned for removal > > Hi all, > > I noticed today that we have an i2c bus driver named i2c-ite, > supposedly useful on some MIPS systems which have an ITE8172 chip, > which doesn't compile. It is based on an i2c algorithm driver named > i2c-algo-ite, which doesn't compile either, due to some > changes made to > the i2c core which weren't properly reflected there. Going back trough > the versions, I found that the bus driver was previously named > i2c-adap-ite, and was introduced in 2.4.10. And I don't think it even > compiled back then either, as it uses a structure (iic_ite) > which isn't > defined anywhere. > > So basically we have two drivers in the kernel tree for 5 years or so, > which never were usable, and nobody seemed to care. It's about time to > get rid of these 1296 lines of code, don't you think? So, > unless someone > volunteers to take care of these drivers, or otherwise has a very > strong reason to object, I'm going to delete them from the tree soon. > > Thanks, > -- > Jean Delvare > From tbm@cyrius.com Fri Jun 16 19:20:30 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 16 Jun 2006 19:20:40 +0100 (BST) Received: from sorrow.cyrius.com ([65.19.161.204]:43015 "HELO sorrow.cyrius.com") by ftp.linux-mips.org with SMTP id S8134037AbWFPSUa (ORCPT ); Fri, 16 Jun 2006 19:20:30 +0100 Received: by sorrow.cyrius.com (Postfix, from userid 10) id DB76D64D56; Fri, 16 Jun 2006 18:20:17 +0000 (UTC) Received: by deprecation.cyrius.com (Postfix, from userid 1000) id 9CDB466CB2; Fri, 16 Jun 2006 20:20:01 +0200 (CEST) Date: Fri, 16 Jun 2006 20:20:01 +0200 From: Martin Michlmayr To: Shane McDonald Cc: linux-mips@linux-mips.org Subject: Re: i2c-algo-ite and i2c-ite planned for removal Message-ID: <20060616182001.GC7145@deprecation.cyrius.com> References: <9328C220997E4E448CC833AF1AB402DA0344D906@bby1exm08.pmc_nt.nt.pmc-sierra.bc.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9328C220997E4E448CC833AF1AB402DA0344D906@bby1exm08.pmc_nt.nt.pmc-sierra.bc.ca> User-Agent: Mutt/1.5.11+cvs20060330 Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11750 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: tbm@cyrius.com Precedence: bulk X-list: linux-mips * Shane McDonald [2006-06-16 10:10]: > PMC-Sierra has an eval board (the "Xiao Hu") that uses these files. > We haven't (yet) pushed out patches to add support for this board Are you also going to put some work into Ocelot support (which is slated for removal) or is that platform officially dead? c.f. http://www.linux-mips.org/wiki/Category:Deprecated -- Martin Michlmayr http://www.cyrius.com/ From khali@linux-fr.org Fri Jun 16 21:29:03 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 16 Jun 2006 21:29:12 +0100 (BST) Received: from smtp-105-friday.nerim.net ([62.4.16.105]:2573 "HELO kraid.nerim.net") by ftp.linux-mips.org with SMTP id S8134121AbWFPU3D (ORCPT ); Fri, 16 Jun 2006 21:29:03 +0100 Received: from arrakis.delvare (jdelvare.pck.nerim.net [62.212.121.182]) by kraid.nerim.net (Postfix) with SMTP id 8178440F59; Fri, 16 Jun 2006 22:28:59 +0200 (CEST) Date: Fri, 16 Jun 2006 22:29:08 +0200 From: Jean Delvare To: Pete Popov Cc: linux-mips@linux-mips.org, linux-kernel@vger.kernel.org Subject: Re: i2c-algo-ite and i2c-ite planned for removal Message-Id: <20060616222908.f96e3691.khali@linux-fr.org> In-Reply-To: <1150406598.1193.73.camel@localhost.localdomain> References: <20060615225723.012c82be.khali@linux-fr.org> <1150406598.1193.73.camel@localhost.localdomain> X-Mailer: Sylpheed version 2.2.6 (GTK+ 2.6.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11751 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: khali@linux-fr.org Precedence: bulk X-list: linux-mips Hi Pete, > > So basically we have two drivers in the kernel tree for 5 years or so, > > which never were usable, and nobody seemed to care. > > For historical correctness, this driver was once upon a time usable, > though it was a few years ago. It was written by MV for some ref board > that had the ITE chip and it did work. That ref board is no longer > around so it's probably safe to nuke the driver. In which kernel version? In every version I checked (2.4.12, 2.4.30, 2.6.0 and 2.6.16) it wouldn't compile due to struct iic_ite being used but never defined (and possibly other errors, but I can't test-compile the driver.) -- Jean Delvare From Rajesh_Palani@pmc-sierra.com Fri Jun 16 21:32:27 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 16 Jun 2006 21:32:39 +0100 (BST) Received: from father.pmc-sierra.com ([216.241.224.13]:33468 "HELO father.pmc-sierra.bc.ca") by ftp.linux-mips.org with SMTP id S8133783AbWFPUc1 (ORCPT ); Fri, 16 Jun 2006 21:32:27 +0100 Received: (qmail 20773 invoked by uid 101); 16 Jun 2006 20:32:12 -0000 Received: from unknown (HELO ogmios.pmc-sierra.bc.ca) (216.241.226.59) by father.pmc-sierra.com with SMTP; 16 Jun 2006 20:32:12 -0000 Received: from bby1exi01.pmc_nt.nt.pmc-sierra.bc.ca (bby1exi01.pmc-sierra.bc.ca [216.241.231.251]) by ogmios.pmc-sierra.bc.ca (8.13.3/8.12.7) with ESMTP id k5GKWCBu010630; Fri, 16 Jun 2006 13:32:12 -0700 Received: by bby1exi01.pmc-sierra.bc.ca with Internet Mail Service (5.5.2656.59) id ; Fri, 16 Jun 2006 13:32:11 -0700 Message-ID: <478F19F21671F04298A2116393EEC3D531D170@sjc1exm08.pmc_nt.nt.pmc-sierra.bc.ca> From: Raj Palani To: Martin Michlmayr , Shane McDonald Cc: linux-mips@linux-mips.org Subject: RE: i2c-algo-ite and i2c-ite planned for removal Date: Fri, 16 Jun 2006 13:32:08 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11752 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: Rajesh_Palani@pmc-sierra.com Precedence: bulk X-list: linux-mips Hi Martin, We are planning on continuing the Ocelot support for our 7K/79K CPUs. We are currently focusing on getting the support for our Sequoia (MSP85x0 CPU) platforms into the Linux/MIPS tree. -Raj > -----Original Message----- > From: linux-mips-bounce@linux-mips.org > [mailto:linux-mips-bounce@linux-mips.org] On Behalf Of Martin > Michlmayr > Sent: Friday, June 16, 2006 11:20 AM > To: Shane McDonald > Cc: linux-mips@linux-mips.org > Subject: Re: i2c-algo-ite and i2c-ite planned for removal > > * Shane McDonald [2006-06-16 10:10]: > > PMC-Sierra has an eval board (the "Xiao Hu") that uses these files. > > We haven't (yet) pushed out patches to add support for this board > > Are you also going to put some work into Ocelot support > (which is slated for removal) or is that platform officially dead? > > c.f. http://www.linux-mips.org/wiki/Category:Deprecated > -- > Martin Michlmayr > http://www.cyrius.com/ > From wilson@specifix.com Fri Jun 16 23:33:41 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 16 Jun 2006 23:33:50 +0100 (BST) Received: from w099.z064220152.sjc-ca.dsl.cnc.net ([64.220.152.99]:23696 "HELO duck.specifix.com") by ftp.linux-mips.org with SMTP id S8134021AbWFPWdl (ORCPT ); Fri, 16 Jun 2006 23:33:41 +0100 Received: from [127.0.0.1] (duck.corp.specifix.com [192.168.1.1]) by duck.specifix.com (Postfix) with ESMTP id 28171FC7E; Fri, 16 Jun 2006 15:33:15 -0700 (PDT) Subject: Re: gcc-4.1.0 cross-compile for MIPS From: James E Wilson To: kernel coder Cc: linux-mips@linux-mips.org In-Reply-To: References: Content-Type: text/plain Message-Id: <1150497195.17820.4.camel@aretha.corp.specifix.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Fri, 16 Jun 2006 15:33:15 -0700 Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11753 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: wilson@specifix.com Precedence: bulk X-list: linux-mips On Fri, 2006-06-16 at 05:22, kernel coder wrote: > /home/shahzad/install//mipsel/sys-include -DHAVE_CONFIG_H -I. > -I../../../gcc-4.1.0/libssp -I. -Wall -O2 -g -O2 -MT ssp.lo -MD -MP > -MF .deps/ssp.Tpo -c ../../../gcc-4.1.0/libssp/ssp.c -o ssp.o > ../../../gcc-4.1.0/libssp/ssp.c:46:20: error: fcntl.h: No such file or directory You can't build target libraries like libssp in a --without-headers build. It was luck that this happened to work with earlier gcc releases, because previously we didn't have C language target libraries in gcc. The solution is to do make all-gcc make install-gcc instead of just make all make install Please see Dan Kegel's crosstools package, which already knows how to do this. -- Jim Wilson, GNU Tools Support, http://www.specifix.com From ralf@linux-mips.org Sun Jun 18 04:19:36 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 18 Jun 2006 04:19:45 +0100 (BST) Received: from localhost.localdomain ([127.0.0.1]:59082 "EHLO bacchus.dhis.org") by ftp.linux-mips.org with ESMTP id S8126483AbWFRDTg (ORCPT ); Sun, 18 Jun 2006 04:19:36 +0100 Received: from denk.linux-mips.net (denk.linux-mips.net [127.0.0.1]) by bacchus.dhis.org (8.13.6/8.13.4) with ESMTP id k5I3JbIR022383 for ; Sun, 18 Jun 2006 04:19:37 +0100 Received: (from ralf@localhost) by denk.linux-mips.net (8.13.6/8.13.6/Submit) id k5I3Jaup022382 for linux-mips@linux-mips.org; Sun, 18 Jun 2006 04:19:36 +0100 Date: Sun, 18 Jun 2006 04:19:36 +0100 From: Ralf Baechle To: linux-mips@linux-mips.org Subject: 2.4 fixes in git Message-ID: <20060618031936.GA21492@linux-mips.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.1i Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11754 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ralf@linux-mips.org Precedence: bulk X-list: linux-mips Contrary to earlier announcements I commited a few Linux 2.4 fixes into git. The fixes are: o Crash fixes for kernels built with gcc 3.4. This does not fix all issues with gcc 3.4. Some configuration might fail to link and there might be other, yet unknown problems so using an older compiler stays the safe bet. o Fix ordering of serial interfaces for Malta. This makes sure the onboard serial really will be the console. o Support for a few CPU cards for Atlas and Malta that are supported in Linux 2.6. Probably few people care but it's a big item for me, my usual Malta configuration didn't run 2.4 ... Ralf From ths@networkno.de Sun Jun 18 05:18:02 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 18 Jun 2006 05:18:11 +0100 (BST) Received: from bender.bawue.de ([193.7.176.20]:41608 "HELO bender.bawue.de") by ftp.linux-mips.org with SMTP id S3466132AbWFRESC (ORCPT ); Sun, 18 Jun 2006 05:18:02 +0100 Received: from lagash (88-106-172-197.dynamic.dsl.as9105.com [88.106.172.197]) (using TLSv1 with cipher DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by bender.bawue.de (Postfix) with ESMTP id 462A844156; Sun, 18 Jun 2006 06:18:01 +0200 (MEST) Received: from ths by lagash with local (Exim 4.62) (envelope-from ) id 1FrojS-00027m-1a; Sun, 18 Jun 2006 05:17:54 +0100 Date: Sun, 18 Jun 2006 05:17:54 +0100 To: linux-mips@linux-mips.org Cc: ralf@linux-mips.org Subject: [PATCH] Fix bcm1480 compile Message-ID: <20060618041753.GB4480@networkno.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.11+cvs20060403 From: Thiemo Seufer Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11755 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ths@networkno.de Precedence: bulk X-list: linux-mips Hello All, the appended patch fixes compilation for bcm1480, a hpt is only available on sb1250/bcm112x. Thiemo Signed-off-by: Thiemo Seufer diff --git a/arch/mips/sibyte/swarm/setup.c b/arch/mips/sibyte/swarm/setup.c index 4b5f74f..be229a8 100644 --- a/arch/mips/sibyte/swarm/setup.c +++ b/arch/mips/sibyte/swarm/setup.c @@ -72,8 +72,10 @@ const char *get_system_type(void) void __init swarm_time_init(void) { +#if defined(CONFIG_SIBYTE_SB1250) || defined(CONFIG_SIBYTE_BCM112X) /* Setup HPT */ sb1250_hpt_setup(); +#endif } void __init swarm_timer_setup(struct irqaction *irq) From ths@networkno.de Sun Jun 18 05:24:46 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 18 Jun 2006 05:24:55 +0100 (BST) Received: from bender.bawue.de ([193.7.176.20]:29835 "HELO bender.bawue.de") by ftp.linux-mips.org with SMTP id S3466132AbWFREYq (ORCPT ); Sun, 18 Jun 2006 05:24:46 +0100 Received: from lagash (88-106-172-197.dynamic.dsl.as9105.com [88.106.172.197]) (using TLSv1 with cipher DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by bender.bawue.de (Postfix) with ESMTP id 01122450B4; Sun, 18 Jun 2006 06:23:55 +0200 (MEST) Received: from ths by lagash with local (Exim 4.62) (envelope-from ) id 1Frop9-00028f-LG; Sun, 18 Jun 2006 05:23:47 +0100 Date: Sun, 18 Jun 2006 05:23:47 +0100 To: linux-mips@linux-mips.org Cc: ralf@linux-mips.org Subject: [PATCH] Random fixes for sb1250 Message-ID: <20060618042347.GC4480@networkno.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.11+cvs20060403 From: Thiemo Seufer Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11756 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ths@networkno.de Precedence: bulk X-list: linux-mips Hello All, some random improvements for sb1250: Silence compiler warnings, a bugfix for the profiling code, and a comment typo. Thiemo Signed-off-by: Thiemo Seufer diff --git a/arch/mips/sibyte/sb1250/irq.c b/arch/mips/sibyte/sb1250/irq.c index 0f6e54d..f853c32 100644 --- a/arch/mips/sibyte/sb1250/irq.c +++ b/arch/mips/sibyte/sb1250/irq.c @@ -435,13 +435,17 @@ static inline int dclz(unsigned long lon return lz; } +extern void sb1250_timer_interrupt(struct pt_regs *regs); +extern void sb1250_mailbox_interrupt(struct pt_regs *regs); +extern void sb1250_kgdb_interrupt(struct pt_regs *regs); + asmlinkage void plat_irq_dispatch(struct pt_regs *regs) { unsigned int pending; #ifdef CONFIG_SIBYTE_SB1250_PROF /* Set compare to count to silence count/compare timer interrupts */ - write_c0_count(read_c0_count()); + write_c0_compare(read_c0_count()); #endif /* @@ -482,7 +486,7 @@ #endif * Default...we've hit an IP[2] interrupt, which means we've * got to check the 1250 interrupt registers to figure out what * to do. Need to detect which CPU we're on, now that - ~ smp_affinity is supported. + * smp_affinity is supported. */ mask = __raw_readq(IOADDR(A_IMR_REGISTER(smp_processor_id(), R_IMR_INTERRUPT_STATUS_BASE))); From kumba@gentoo.org Sun Jun 18 07:16:59 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 18 Jun 2006 07:17:08 +0100 (BST) Received: from sccrmhc13.comcast.net ([204.127.200.83]:31879 "EHLO sccrmhc13.comcast.net") by ftp.linux-mips.org with ESMTP id S8134172AbWFRGQ7 (ORCPT ); Sun, 18 Jun 2006 07:16:59 +0100 Received: from [127.0.0.1] (unknown[69.140.185.142]) by comcast.net (sccrmhc13) with ESMTP id <2006061806165201300mcfnpe>; Sun, 18 Jun 2006 06:16:53 +0000 Message-ID: <4494EFD5.8090601@gentoo.org> Date: Sun, 18 Jun 2006 02:16:53 -0400 From: Kumba User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Linux MIPS List CC: Ralf Baechle Subject: [PATCH]: Add Missing R4K Cache Macros to IP27 & IP32 Content-Type: multipart/mixed; boundary="------------060001030903080505010700" Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11757 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: kumba@gentoo.org Precedence: bulk X-list: linux-mips This is a multi-part message in MIME format. --------------060001030903080505010700 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Keeping in accordance with other machines, IP27 and IP32 lack a few macros. IP27 lacks cpu_has_4kex & cpu_has_4k_cache macros while IP32 lacks just the cpu_has_4k_cache macro. --Kumba Signed-off-by: Joshua Kinard mach-ip27/cpu-feature-overrides.h | 3 +++ mach-ip32/cpu-feature-overrides.h | 2 ++ 2 files changed, 5 insertions(+) --------------060001030903080505010700 Content-Type: text/plain; name="add-4k-cache-macros.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="add-4k-cache-macros.patch" diff -Naurp linux-2.6.17.mips.orig/include/asm-mips/mach-ip27/cpu-feature-overrides.h linux-2.6.17.mips.p1/include/asm-mips/mach-ip27/cpu-feature-overrides.h --- linux-2.6.17.mips.orig/include/asm-mips/mach-ip27/cpu-feature-overrides.h 2006-06-17 00:45:12.000000000 -0400 +++ linux-2.6.17.mips.p1/include/asm-mips/mach-ip27/cpu-feature-overrides.h 2006-06-17 00:54:29.000000000 -0400 @@ -31,6 +31,9 @@ #define cpu_has_nofpuex 0 #define cpu_has_64bits 1 +#define cpu_has_4kex 1 +#define cpu_has_4k_cache 1 + #define cpu_has_subset_pcaches 1 #define cpu_dcache_line_size() 32 diff -Naurp linux-2.6.17.mips.orig/include/asm-mips/mach-ip32/cpu-feature-overrides.h linux-2.6.17.mips.p1/include/asm-mips/mach-ip32/cpu-feature-overrides.h --- linux-2.6.17.mips.orig/include/asm-mips/mach-ip32/cpu-feature-overrides.h 2006-06-17 00:45:12.000000000 -0400 +++ linux-2.6.17.mips.p1/include/asm-mips/mach-ip32/cpu-feature-overrides.h 2006-06-17 00:54:29.000000000 -0400 @@ -38,6 +38,8 @@ #define cpu_has_vtag_icache 0 #define cpu_has_ic_fills_f_dc 0 #define cpu_has_dsp 0 +#define cpu_has_4k_cache 1 + #define cpu_has_mips32r1 0 #define cpu_has_mips32r2 0 --------------060001030903080505010700-- From kumba@gentoo.org Sun Jun 18 07:17:34 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 18 Jun 2006 07:17:51 +0100 (BST) Received: from sccrmhc11.comcast.net ([63.240.77.81]:37004 "EHLO sccrmhc11.comcast.net") by ftp.linux-mips.org with ESMTP id S8134174AbWFRGRH (ORCPT ); Sun, 18 Jun 2006 07:17:07 +0100 Received: from [127.0.0.1] (unknown[69.140.185.142]) by comcast.net (sccrmhc11) with ESMTP id <2006061806170001100ep4cbe>; Sun, 18 Jun 2006 06:17:00 +0000 Message-ID: <4494EFDD.4000500@gentoo.org> Date: Sun, 18 Jun 2006 02:17:01 -0400 From: Kumba User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Linux MIPS List CC: Ralf Baechle Subject: [PATCH]: Fix R4K Cache Macro names Content-Type: multipart/mixed; boundary="------------010705090509090304030304" Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11758 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: kumba@gentoo.org Precedence: bulk X-list: linux-mips This is a multi-part message in MIME format. --------------010705090509090304030304 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Several machines have the R4K cache macro name spelled incorrectly. Namely, they have cpu_has_4kcache defined instead of cpu_has_4k_cache. --Kumba Signed-off-by: Joshua Kinard mach-ip22/cpu-feature-overrides.h | 2 +- mach-mips/cpu-feature-overrides.h | 4 ++-- mach-rm200/cpu-feature-overrides.h | 2 +- mach-sim/cpu-feature-overrides.h | 4 ++-- 4 files changed, 6 insertions(+), 6 deletions(-) --------------010705090509090304030304 Content-Type: text/plain; name="fix-4k-cache-macros.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="fix-4k-cache-macros.patch" diff -Naurp linux-2.6.17.mips.orig/include/asm-mips/mach-ip22/cpu-feature-overrides.h linux-2.6.17.mips.p2/include/asm-mips/mach-ip22/cpu-feature-overrides.h --- linux-2.6.17.mips.orig/include/asm-mips/mach-ip22/cpu-feature-overrides.h 2006-06-17 00:45:12.000000000 -0400 +++ linux-2.6.17.mips.p2/include/asm-mips/mach-ip22/cpu-feature-overrides.h 2006-06-17 00:54:42.000000000 -0400 @@ -13,7 +13,7 @@ */ #define cpu_has_tlb 1 #define cpu_has_4kex 1 -#define cpu_has_4kcache 1 +#define cpu_has_4k_cache 1 #define cpu_has_fpu 1 #define cpu_has_32fpr 1 #define cpu_has_counter 1 diff -Naurp linux-2.6.17.mips.orig/include/asm-mips/mach-mips/cpu-feature-overrides.h linux-2.6.17.mips.p2/include/asm-mips/mach-mips/cpu-feature-overrides.h --- linux-2.6.17.mips.orig/include/asm-mips/mach-mips/cpu-feature-overrides.h 2006-06-17 00:45:12.000000000 -0400 +++ linux-2.6.17.mips.p2/include/asm-mips/mach-mips/cpu-feature-overrides.h 2006-06-17 00:54:42.000000000 -0400 @@ -17,7 +17,7 @@ #ifdef CONFIG_CPU_MIPS32 #define cpu_has_tlb 1 #define cpu_has_4kex 1 -#define cpu_has_4kcache 1 +#define cpu_has_4k_cache 1 /* #define cpu_has_fpu ? */ /* #define cpu_has_32fpr ? */ #define cpu_has_counter 1 @@ -47,7 +47,7 @@ #ifdef CONFIG_CPU_MIPS64 #define cpu_has_tlb 1 #define cpu_has_4kex 1 -#define cpu_has_4kcache 1 +#define cpu_has_4k_cache 1 /* #define cpu_has_fpu ? */ /* #define cpu_has_32fpr ? */ #define cpu_has_counter 1 diff -Naurp linux-2.6.17.mips.orig/include/asm-mips/mach-rm200/cpu-feature-overrides.h linux-2.6.17.mips.p2/include/asm-mips/mach-rm200/cpu-feature-overrides.h --- linux-2.6.17.mips.orig/include/asm-mips/mach-rm200/cpu-feature-overrides.h 2006-06-17 00:45:12.000000000 -0400 +++ linux-2.6.17.mips.p2/include/asm-mips/mach-rm200/cpu-feature-overrides.h 2006-06-17 00:54:42.000000000 -0400 @@ -14,7 +14,7 @@ #define cpu_has_tlb 1 #define cpu_has_4kex 1 -#define cpu_has_4kcache 1 +#define cpu_has_4k_cache 1 #define cpu_has_fpu 1 #define cpu_has_32fpr 1 #define cpu_has_counter 1 diff -Naurp linux-2.6.17.mips.orig/include/asm-mips/mach-sim/cpu-feature-overrides.h linux-2.6.17.mips.p2/include/asm-mips/mach-sim/cpu-feature-overrides.h --- linux-2.6.17.mips.orig/include/asm-mips/mach-sim/cpu-feature-overrides.h 2006-06-17 00:45:12.000000000 -0400 +++ linux-2.6.17.mips.p2/include/asm-mips/mach-sim/cpu-feature-overrides.h 2006-06-17 00:54:42.000000000 -0400 @@ -16,7 +16,7 @@ #ifdef CONFIG_CPU_MIPS32 #define cpu_has_tlb 1 #define cpu_has_4kex 1 -#define cpu_has_4kcache 1 +#define cpu_has_4k_cache 1 #define cpu_has_fpu 0 /* #define cpu_has_32fpr ? */ #define cpu_has_counter 1 @@ -41,7 +41,7 @@ #ifdef CONFIG_CPU_MIPS64 #define cpu_has_tlb 1 #define cpu_has_4kex 1 -#define cpu_has_4kcache 1 +#define cpu_has_4k_cache 1 /* #define cpu_has_fpu ? */ /* #define cpu_has_32fpr ? */ #define cpu_has_counter 1 --------------010705090509090304030304-- From kumba@gentoo.org Sun Jun 18 07:18:20 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 18 Jun 2006 07:18:41 +0100 (BST) Received: from sccrmhc11.comcast.net ([63.240.77.81]:37004 "EHLO sccrmhc11.comcast.net") by ftp.linux-mips.org with ESMTP id S8134175AbWFRGRI (ORCPT ); Sun, 18 Jun 2006 07:17:08 +0100 Received: from [127.0.0.1] (unknown[69.140.185.142]) by comcast.net (sccrmhc11) with ESMTP id <2006061806170701100ep67le>; Sun, 18 Jun 2006 06:17:07 +0000 Message-ID: <4494EFE4.70708@gentoo.org> Date: Sun, 18 Jun 2006 02:17:08 -0400 From: Kumba User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Linux MIPS List CC: Ralf Baechle Subject: [PATCH]: Correct HAL2 Kconfig description Content-Type: multipart/mixed; boundary="------------070300050205050406080502" Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11759 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: kumba@gentoo.org Precedence: bulk X-list: linux-mips This is a multi-part message in MIME format. --------------070300050205050406080502 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit The current HAL2 Kconfig description indicates it is only used on SGI Indy systems, however all members of the Indigo2 Family have this sound card as well. Plus a minor grammatical fix is included. --Kumba Signed-off-by: Joshua Kinard Kconfig | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) --------------070300050205050406080502 Content-Type: text/plain; name="indigo2-has-hal2-too.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="indigo2-has-hal2-too.patch" diff -Naurp linux-2.6.17.mips.orig/sound/oss/Kconfig linux-2.6.17.mips.p3/sound/oss/Kconfig --- linux-2.6.17.mips.orig/sound/oss/Kconfig 2006-06-17 00:45:21.000000000 -0400 +++ linux-2.6.17.mips.p3/sound/oss/Kconfig 2006-06-17 00:54:50.000000000 -0400 @@ -98,8 +98,8 @@ config SOUND_HAL2 tristate "SGI HAL2 sound (EXPERIMENTAL)" depends on SOUND_PRIME && SGI_IP22 && EXPERIMENTAL help - Say Y or M if you have an SGI Indy system and want to be able to - use it's on-board A2 audio system. + Say Y or M if you have an SGI Indy or Indigo2 system and want to be able to + use its on-board A2 audio system. config SOUND_IT8172 tristate "IT8172G Sound" --------------070300050205050406080502-- From mrv@corecom.co.kr Mon Jun 19 05:24:33 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 19 Jun 2006 05:24:43 +0100 (BST) Received: from [220.76.242.187] ([220.76.242.187]:60069 "EHLO localhost.localdomain") by ftp.linux-mips.org with ESMTP id S8127208AbWFSEYd (ORCPT ); Mon, 19 Jun 2006 05:24:33 +0100 Received: from mrv ([192.168.11.157]) by localhost.localdomain (8.12.8/8.12.8) with SMTP id k5J4PrBb007255 for ; Mon, 19 Jun 2006 13:25:57 +0900 Message-ID: <002a01c69358$414cb8b0$9d0ba8c0@mrv> From: "Roman Mashak" To: Subject: PMC-sierra and 2.6.12 kernel Date: Mon, 19 Jun 2006 13:24:25 +0900 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="koi8-r"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 FL-Build: Fidolook 2002 (SL) 6.0.2800.86 - 14/6/2003 22:16:25 Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11760 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: mrv@corecom.co.kr Precedence: bulk X-list: linux-mips Hello! We have problem enabling second gigabit ethernet interface on PMC-sierra "Sequoia" board. Here's boot log: Loading file: tftp://192.168.11.43/vmlinux (elf) 0x80100000/2293894 + 0x80330086/114586(z) + 4011 syms| Linux version 2.6.12-rc3 (root@ecb-test32.corecom.local) (gcc version 3.3-mips64linux-031001) #8 Fri Jun 2 20:08:34 KST 2006 PMON reports memory size 256MB cpu_clock set to 900000000 CPU revision is: 000034c1 FPU revision is: 00003420 PMC-Sierra Sequoia Board Setup 32-bit support Determined physical RAM map: memory: 20000000 @ 00000000 (usable) User-defined physical RAM map: memory: 10000000 @ 00000000 (usable) Built 1 zonelists Kernel command line: tftp://192.168.11.43/vmlinux root=/dev/nfs nfsroot=192.168.11.43:/export/linux/mips-fs-be ip=192.168.11.42:::::eth0 mem=256M noirqdebug pci=noacpi Unknown boot option `tftp://192.168.11.43/vmlinux': ignoring IRQ lockup detection disabled PCI: Unknown option `noacpi' Primary instruction cache 16kB, physically tagged, 4-way, linesize 32 bytes. Primary data cache 16kB, 4-way, linesize 32 bytes. Secondary cache size 256K, linesize 32 bytes. Synthesized TLB refill handler (27 instructions). Synthesized TLB load handler fastpath (39 instructions). Synthesized TLB store handler fastpath (39 instructions). Synthesized TLB modify handler fastpath (38 instructions). PID hash table entries: 2048 (order: 11, 32768 bytes) Using 450.000 MHz high precision timer. Dentry cache hash table entries: 65536 (order: 6, 262144 bytes) Inode-cache hash table entries: 32768 (order: 5, 131072 bytes) Memory: 256128k/262144k available (1553k kernel code, 5860k reserved, 342k data, 344k init, 0k highmem) CompactFlash ATA Support for PMC-Sierra Sequoia <6>Internal UART Support for PMC-Sierra Sequoia <7>Calibrating delay loop... 897.02 BogoMIPS (lpj=448512) Mount-cache hash table entries: 512 Checking for 'wait' instruction... available. NET: Registered protocol family 16 PCI: Failed to allocate mem resource #2:20000000@e0000000 for 0000:00:01.0 PCI: Failed to allocate mem resource #2:20000000@e8000000 for 0000:01:01.0 Generic RTC Driver v1.07 Serial: 8250/16550 driver $Revision: 1.1.1.1 $ 4 ports, IRQ sharing disabled ttyS0 at MMIO 0x0 (irq = 0) is a 16550A io scheduler noop registered io scheduler anticipatory registered io scheduler deadline registered io scheduler cfq registered PMC-Sierra MSP85x0 10/100/1000 Ethernet Driver Device Id : 206014, Version : 0 : port 0 with MAC address 00:e0:04:00:02:4e Rx NAPI supported, Tx Coalescing ON : port 1 with MAC address 00:e0:04:00:02:4f Rx NAPI supported, Tx Coalescing ON NET: Registered protocol family 2 IP: routing cache hash table of 2048 buckets, 16Kbytes TCP established hash table entries: 16384 (order: 5, 131072 bytes) TCP bind hash table entries: 16384 (order: 4, 65536 bytes) TCP: Hash tables configured (established 16384 bind 16384) NET: Registered protocol family 1 NET: Registered protocol family 17 Assigned IRQ 5 to port 0 IP-Config: Guessing netmask 255.255.255.0 IP-Config: Complete: device=eth0, addr=192.168.11.42, mask=255.255.255.0, gw=255.255.255.255, host=192.168.11.42, domain=, nis-domain=(none), bootserver=255.255.255.255, rootserver=192.168.11.43, rootpath= Looking up port of RPC 100003/2 on 192.168.11.43 Looking up port of RPC 100005/1 on 192.168.11.43 VFS: Mounted root (nfs filesystem) readonly. Freeing unused kernel memory: 344k freed INIT: version 2.78 booting Activating swap... Checking all file systems... Parallelizing fsck version 1.22 (22-Jun-2001) Calculating module dependencies... depmod: QM_MODULES: Function not implemented done. Loading modules: modprobe: QM_MODULES: Function not implemented mkdir: cannot create directory `/dev/pts': File exists Mounting local filesystems... nothing was mounted Cleaning: /etc/network/ifstate. Setting up IP spoofing protection: rp_filter. Disable TCP/IP Explicit Congestion Notification: done. Configuring network interfaces: Don't seem to be have all the variables for eth0/inet. done. Starting portmap daemon: portmap. Cleaning: /tmp /var/lock /var/run. INIT: Entering runlevel: 3 Starting system log daemon: klogd. Starting internet superserver: inetd. Here I'm trying to enable interface: root@192.168.11.42:~# ifconfig eth1 up Assigned IRQ 6 to port 1 XDMA currently has 64 Rx descriptors eth1: Error opening interface SIOCSIFFLAGS: Device or resource busy root@192.168.11.42:~# Interrrupts: root@192.168.11.42:~# cat /proc/interrupts CPU0 5: 8985 MIPS eth0 7: 692504 MIPS timer ERR: 0 root@192.168.11.42:~# With best regards, Roman Mashak. E-mail: mrv@corecom.co.kr From lhrkernelcoder@gmail.com Mon Jun 19 07:40:52 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 19 Jun 2006 07:41:02 +0100 (BST) Received: from ug-out-1314.google.com ([66.249.92.169]:65340 "EHLO ug-out-1314.google.com") by ftp.linux-mips.org with ESMTP id S8133399AbWFSGkw (ORCPT ); Mon, 19 Jun 2006 07:40:52 +0100 Received: by ug-out-1314.google.com with SMTP id k3so2580073ugf for ; Sun, 18 Jun 2006 23:40:51 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=P46qv7SYrefw/mflQuBrfiymFQ0f01B4SYHLlQTE9PPqImhzvuriW/iJh6QYFb11MPwm4XzGWtEZPbEViEyp5AmYflv2vKzlEfuOvcy0pt+BrqTGDaubEYsPbjuKhrHzNXZYo00t+uuPVbLWG96iBduAE+YtoYSGmrRvPyG3mCg= Received: by 10.78.31.18 with SMTP id e18mr1866185hue; Sun, 18 Jun 2006 23:40:51 -0700 (PDT) Received: by 10.78.128.10 with HTTP; Sun, 18 Jun 2006 23:40:51 -0700 (PDT) Message-ID: Date: Mon, 19 Jun 2006 11:40:51 +0500 From: "kernel coder" To: "James E Wilson" Subject: Re: gcc-4.1.0 cross-compile for MIPS Cc: linux-mips@linux-mips.org In-Reply-To: <1150497195.17820.4.camel@aretha.corp.specifix.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <1150497195.17820.4.camel@aretha.corp.specifix.com> Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11761 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: lhrkernelcoder@gmail.com Precedence: bulk X-list: linux-mips yes you were right.When i did make all-gcc It just compiled smoothly. Now to compile glibc-2.3.6 ,I issued following sequence of commands ../glibc-2.3.6/configure --host=mipsel-linux --prefix="/usr" --enable-add-ons --with-headers=/home/shahzad/install/mipsel/include make cross-compiling=yes install_root=/home/shahzad/install/mipsel/include prefix="" install-headers But following error was generated make[1]: Entering directory `/home/shahzad/glibc-2.3.6' { echo '#include "posix/bits/posix1_lim.h"'; \ echo '#define _LIBC 1'; \ echo '#include "misc/sys/uio.h"'; } | \ gcc -mabi=32 -E -dM -MD -MP -MF /home/shahzad/build-glibc-headers/bits/stdio_lim.dT -MT '/home/shahzad/build-glibc-headers/bits/stdio_lim.h /home/shahzad/build-glibc-headers/bits/stdio_lim.d' \ -Iinclude -I. -I/home/shahzad/build-glibc-headers -Ilibio -Inptl -I/home/shahzad/build-glibc-headers -Isysdeps/mips/elf -Inptl/sysdeps/unix/sysv/linux -Inptl/sysdeps/pthread -Isysdeps/pthread -Inptl/sysdeps/unix/sysv -Inptl/sysdeps/unix -Isysdeps/unix/sysv/linux/mips/mips32 -Isysdeps/unix/sysv/linux/mips -Isysdeps/unix/sysv/linux -Isysdeps/gnu -Isysdeps/unix/common -Isysdeps/unix/mman -Isysdeps/unix/inet -Isysdeps/unix/sysv -Isysdeps/unix/mips/mips32 -Isysdeps/unix/mips -Isysdeps/unix -Isysdeps/posix -Isysdeps/mips/mips32 -Isysdeps/mips -Isysdeps/ieee754/flt-32 -Isysdeps/ieee754/dbl-64 -Isysdeps/wordsize-32 -Isysdeps/mips/fpu -Isysdeps/ieee754 -Isysdeps/generic/elf -Isysdeps/generic -nostdinc -isystem /usr/lib/gcc/i386-redhat-linux/4.1.0/include -isystem /home/shahzad/install/mipsel/include -xc - -o /home/shahzad/build-glibc-headers/bits/stdio_lim.hT cc1: error: unrecognized command line option "-mabi=32" I did some search on google,but on most of links "-mabi=32" option was being used with cross-compiler for mips. Would you please tell me what is causing the problem. On 6/17/06, James E Wilson wrote: > On Fri, 2006-06-16 at 05:22, kernel coder wrote: > > /home/shahzad/install//mipsel/sys-include -DHAVE_CONFIG_H -I. > > -I../../../gcc-4.1.0/libssp -I. -Wall -O2 -g -O2 -MT ssp.lo -MD -MP > > -MF .deps/ssp.Tpo -c ../../../gcc-4.1.0/libssp/ssp.c -o ssp.o > > ../../../gcc-4.1.0/libssp/ssp.c:46:20: error: fcntl.h: No such file or directory > > You can't build target libraries like libssp in a --without-headers > build. It was luck that this happened to work with earlier gcc > releases, because previously we didn't have C language target libraries > in gcc. The solution is to do > make all-gcc > make install-gcc > instead of just > make all > make install > > Please see Dan Kegel's crosstools package, which already knows how to do > this. > -- > Jim Wilson, GNU Tools Support, http://www.specifix.com > > From matej.kupljen@ultra.si Mon Jun 19 08:19:24 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 19 Jun 2006 08:19:34 +0100 (BST) Received: from deliver-1.mx.triera.net ([213.161.0.31]:64195 "HELO deliver-1.mx.triera.net") by ftp.linux-mips.org with SMTP id S8133423AbWFSHTY (ORCPT ); Mon, 19 Jun 2006 08:19:24 +0100 Received: from localhost (in-1.mx.triera.net [213.161.0.25]) by deliver-1.mx.triera.net (Postfix) with ESMTP id 4524FBFE3; Mon, 19 Jun 2006 09:19:14 +0200 (CEST) Received: from smtp.triera.net (smtp.triera.net [213.161.0.30]) by in-1.mx.triera.net (Postfix) with SMTP id 6584F1BC08D; Mon, 19 Jun 2006 09:19:14 +0200 (CEST) Received: from picohp (unknown [213.161.20.162]) by smtp.triera.net (Postfix) with ESMTP id E53991A18AF; Mon, 19 Jun 2006 09:19:13 +0200 (CEST) Subject: Re: gcc-4.1.0 cross-compile for MIPS From: Matej Kupljen To: kernel coder Cc: James E Wilson , linux-mips@linux-mips.org In-Reply-To: References: <1150497195.17820.4.camel@aretha.corp.specifix.com> Content-Type: text/plain Date: Mon, 19 Jun 2006 09:19:13 +0200 Message-Id: <1150701553.7203.9.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: Triera AV Service Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11762 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: matej.kupljen@ultra.si Precedence: bulk X-list: linux-mips Hi, See this thread: http://sourceware.org/ml/crossgcc/2005-07/msg00030.html BR,, Matej > yes you were right.When i did > make all-gcc > > It just compiled smoothly. > > Now to compile glibc-2.3.6 ,I issued following sequence of commands > > ../glibc-2.3.6/configure --host=mipsel-linux --prefix="/usr" > --enable-add-ons --with-headers=/home/shahzad/install/mipsel/include > > make cross-compiling=yes > install_root=/home/shahzad/install/mipsel/include prefix="" > install-headers > > But following error was generated > > make[1]: Entering directory `/home/shahzad/glibc-2.3.6' { echo > '#include "posix/bits/posix1_lim.h"'; \ echo '#define > _LIBC 1'; \ echo '#include > "misc/sys/uio.h"'; } | \ gcc -mabi=32 -E -dM -MD -MP > -MF /home/shahzad/build-glibc-headers/bits/stdio_lim.dT -MT > '/home/shahzad/build-glibc-headers/bits/stdio_lim.h > /home/shahzad/build-glibc-headers/bits/stdio_lim.d' \ > -Iinclude -I. -I/home/shahzad/build-glibc-headers -Ilibio > -Inptl -I/home/shahzad/build-glibc-headers -Isysdeps/mips/elf > -Inptl/sysdeps/unix/sysv/linux -Inptl/sysdeps/pthread > -Isysdeps/pthread -Inptl/sysdeps/unix/sysv -Inptl/sysdeps/unix > -Isysdeps/unix/sysv/linux/mips/mips32 -Isysdeps/unix/sysv/linux/mips > -Isysdeps/unix/sysv/linux -Isysdeps/gnu -Isysdeps/unix/common > -Isysdeps/unix/mman -Isysdeps/unix/inet -Isysdeps/unix/sysv > -Isysdeps/unix/mips/mips32 -Isysdeps/unix/mips -Isysdeps/unix > -Isysdeps/posix -Isysdeps/mips/mips32 -Isysdeps/mips > -Isysdeps/ieee754/flt-32 -Isysdeps/ieee754/dbl-64 > -Isysdeps/wordsize-32 -Isysdeps/mips/fpu -Isysdeps/ieee754 > -Isysdeps/generic/elf -Isysdeps/generic -nostdinc -isystem > /usr/lib/gcc/i386-redhat-linux/4.1.0/include -isystem > /home/shahzad/install/mipsel/include -xc - -o > /home/shahzad/build-glibc-headers/bits/stdio_lim.hT > cc1: error: unrecognized command line option "-mabi=32" > > > > I did some search on google,but on most of links "-mabi=32" option was > being used with cross-compiler for mips. > Would you please tell me what is causing the problem. > > > > > On 6/17/06, James E Wilson wrote: > > On Fri, 2006-06-16 at 05:22, kernel coder wrote: > > > /home/shahzad/install//mipsel/sys-include -DHAVE_CONFIG_H -I. > > > -I../../../gcc-4.1.0/libssp -I. -Wall -O2 -g -O2 -MT ssp.lo -MD -MP > > > -MF .deps/ssp.Tpo -c ../../../gcc-4.1.0/libssp/ssp.c -o ssp.o > > > ../../../gcc-4.1.0/libssp/ssp.c:46:20: error: fcntl.h: No such file or directory > > > > You can't build target libraries like libssp in a --without-headers > > build. It was luck that this happened to work with earlier gcc > > releases, because previously we didn't have C language target libraries > > in gcc. The solution is to do > > make all-gcc > > make install-gcc > > instead of just > > make all > > make install > > > > Please see Dan Kegel's crosstools package, which already knows how to do > > this. > > -- > > Jim Wilson, GNU Tools Support, http://www.specifix.com > > > > > From mrv@corecom.co.kr Mon Jun 19 10:02:12 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 19 Jun 2006 10:02:21 +0100 (BST) Received: from [220.76.242.187] ([220.76.242.187]:4325 "EHLO localhost.localdomain") by ftp.linux-mips.org with ESMTP id S8133475AbWFSJCM (ORCPT ); Mon, 19 Jun 2006 10:02:12 +0100 Received: from mrv ([192.168.11.157]) by localhost.localdomain (8.12.8/8.12.8) with SMTP id k5J93aBb012119 for ; Mon, 19 Jun 2006 18:03:39 +0900 Message-ID: <000601c6937f$0bed5270$9d0ba8c0@mrv> From: "Roman Mashak" To: Subject: Ethernet bridging on 2.6.12-rc3 (PMC-sierra patched) Date: Mon, 19 Jun 2006 18:02:08 +0900 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="koi8-r"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 FL-Build: Fidolook 2002 (SL) 6.0.2800.86 - 14/6/2003 22:16:25 Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11763 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: mrv@corecom.co.kr Precedence: bulk X-list: linux-mips Hello, I was observing this strange problem today while verifying performance of Sequoia board. Initial conditions: 1) 2.6.12-rc3_L002 kernel from PMCS ftp, compiled for 32bit mode 2) bridge code is compiled into kernel 3) four 100Mbps ethernet devices and one onboard Gigabit link are joined into bridge using bridge-utils-1.1 4) I connected board gigabit link to SmartBit Gb interface and four 100mbps links to SmartBit FastEthernet interfaces But 'brctl showmacs br0' shows only fast ethernet links being learned, but never gigabit. We have suspicion that Titan driver affects this somehow. Does anybody have any idea about it or ran into this before? Thanks in advance! With best regards, Roman Mashak. E-mail: mrv@corecom.co.kr From ralf@linux-mips.org Mon Jun 19 11:36:54 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 19 Jun 2006 11:37:02 +0100 (BST) Received: from localhost.localdomain ([127.0.0.1]:9357 "EHLO bacchus.dhis.org") by ftp.linux-mips.org with ESMTP id S8133526AbWFSKgy (ORCPT ); Mon, 19 Jun 2006 11:36:54 +0100 Received: from denk.linux-mips.net (denk.linux-mips.net [127.0.0.1]) by bacchus.dhis.org (8.13.6/8.13.4) with ESMTP id k5JAarYg004441 for ; Mon, 19 Jun 2006 11:36:53 +0100 Received: (from ralf@localhost) by denk.linux-mips.net (8.13.6/8.13.6/Submit) id k5JAarId004440 for linux-mips@linux-mips.org; Mon, 19 Jun 2006 11:36:53 +0100 Date: Mon, 19 Jun 2006 11:36:53 +0100 From: Ralf Baechle To: linux-mips@linux-mips.org Subject: Merge window ... Message-ID: <20060619103653.GA4257@linux-mips.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.1i Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11764 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ralf@linux-mips.org Precedence: bulk X-list: linux-mips Just a reminder that 2.6.17 is out and as usual there is now a merge window of two weeks, so try anything that you wish to see to go to Linus to me asap ... Ralf From ralf@linux-mips.org Mon Jun 19 14:52:00 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 19 Jun 2006 14:52:09 +0100 (BST) Received: from localhost.localdomain ([127.0.0.1]:33437 "EHLO bacchus.dhis.org") by ftp.linux-mips.org with ESMTP id S8133545AbWFSNwA (ORCPT ); Mon, 19 Jun 2006 14:52:00 +0100 Received: from denk.linux-mips.net (denk.linux-mips.net [127.0.0.1]) by bacchus.dhis.org (8.13.6/8.13.4) with ESMTP id k5JDpxv5009994; Mon, 19 Jun 2006 14:51:59 +0100 Received: (from ralf@localhost) by denk.linux-mips.net (8.13.6/8.13.6/Submit) id k5JDpuYq009959; Mon, 19 Jun 2006 14:51:56 +0100 Date: Mon, 19 Jun 2006 14:51:56 +0100 From: Ralf Baechle To: Roman Mashak Cc: linux-mips@linux-mips.org Subject: Re: Ethernet bridging on 2.6.12-rc3 (PMC-sierra patched) Message-ID: <20060619135156.GA9701@linux-mips.org> References: <000601c6937f$0bed5270$9d0ba8c0@mrv> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <000601c6937f$0bed5270$9d0ba8c0@mrv> User-Agent: Mutt/1.4.2.1i Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11765 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ralf@linux-mips.org Precedence: bulk X-list: linux-mips On Mon, Jun 19, 2006 at 06:02:08PM +0900, Roman Mashak wrote: > I was observing this strange problem today while verifying performance of > Sequoia board. > > Initial conditions: > 1) 2.6.12-rc3_L002 kernel from PMCS ftp, compiled for 32bit mode > 2) bridge code is compiled into kernel > 3) four 100Mbps ethernet devices and one onboard Gigabit link are joined > into bridge using bridge-utils-1.1 > 4) I connected board gigabit link to SmartBit Gb interface and four 100mbps > links to SmartBit FastEthernet interfaces > > But 'brctl showmacs br0' shows only fast ethernet links being learned, but > never gigabit. We have suspicion that Titan driver affects this somehow. The Titan driver (the version on linux-mips.org and any other version I've seen) are pretty broken and remarkably ugly pieces of code. The authors of the Basler eXcite platform have contributed their driver and I hope it will show up upstream soon. Afaik it has not been tested with any of PMC's eval boards but the necessary changes should not be hard. Ralf From lhrkernelcoder@gmail.com Mon Jun 19 14:54:40 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 19 Jun 2006 14:54:50 +0100 (BST) Received: from ug-out-1314.google.com ([66.249.92.168]:53576 "EHLO ug-out-1314.google.com") by ftp.linux-mips.org with ESMTP id S8133524AbWFSNyk (ORCPT ); Mon, 19 Jun 2006 14:54:40 +0100 Received: by ug-out-1314.google.com with SMTP id k3so2708677ugf for ; Mon, 19 Jun 2006 06:54:39 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=kPBasNYaZ9vFcihdr17a2vxqdV07zNhCjoT9Hx9naQAFS4BPNC8pe2KkFmDY4C1h2xI6qEOw3BoABJkYYdnQhs6eSgT9aoVODZj5X6TwVjhFzAjpfIYZAWBRDu3sm0LoHIX5UWYH8Ts5lVXcdU41RiDXEATmerMDnZ//4i7B3O4= Received: by 10.78.44.11 with SMTP id r11mr2001170hur; Mon, 19 Jun 2006 06:54:39 -0700 (PDT) Received: by 10.78.128.10 with HTTP; Mon, 19 Jun 2006 06:54:39 -0700 (PDT) Message-ID: Date: Mon, 19 Jun 2006 18:54:39 +0500 From: "kernel coder" To: linux-mips@linux-mips.org Subject: gcc port based on MIPS MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11766 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: lhrkernelcoder@gmail.com Precedence: bulk X-list: linux-mips hi, I'm trying to port gcc for a processor which is very similar to MIPS.Today i just tried to compile gcc-4.1.0 for this processor by changing configuration files. First i changed the config.sub file in base directory and just added the name of processor ABC. Then i changed the configure.ac file in gcc/ subdirectory and added following lines. ABC*) conftest_s=' .section .tdata,"awT",@progbits x: .word 2 .text addiu $4, $28, %tlsgd(x) addiu $4, $28, %tlsldm(x) lui $4, %dtprel_hi(x) addiu $4, $4, %dtprel_lo(x) lw $4, %gottprel(x)($28) lui $4, %tprel_hi(x) addiu $4, $4, %tprel_lo(x)' tls_first_major=2 tls_first_minor=16 tls_as_opt='-32 --fatal-warnings' ;; As you can see it was just copy paste of mips*-*-*) option. Then i did following changes to config.gcc file in gcc/ subdirectory ABC*) cpu_type=ABC ;; - - - - - - - - - - - - - - -- - - - - - -- ABC*) tm_file="dbxelf.h elfos.h svr4.h linux.h ${tm_file} ABC/linux.h" ;; Then i made a directory gcc-4.1.0/gcc/config/ABC/.I copied all files of gcc-4.1.0/gcc/config/mips to ABC directory and renamed following files. mips.h -------------- ABC.h mips.md -------------- ABC.md mips.c -------------- ABC.c mips-modes.def ------------- ABC-modes.def mips-protos.h ------------- ABC-protos.h mips.opt ------------- ABC.opt But when i issued the make all-gcc command .Following error occured ../../gcc-4.1.0/gcc/config/ABC/ABC.md: unknown mode `V2SF' Would u please explain why this error is being generated.Also a bit of explaination of 'V2SF' mode will helpful. Then i removed the 'V2SF' mode from patterns in ABC.md file.But now following error was generated. ../../gcc-4.1.0/gcc/config/ABC/ABC.md:228: unknown value `' for `mode' attribute ../../gcc-4.1.0/gcc/config/ABC/ABC.md:228: unknown value `' for `mode' attribute ../../gcc-4.1.0/gcc/config/ABC/ABC.md:228: unknown value `' for `mode' attribute ../../gcc-4.1.0/gcc/config/ABC/ABC.md:228: unknown value `' for `mode' attribute Would you please tell me why this error is being generated. thanks, shahzad From yoichi_yuasa@tripeaks.co.jp Mon Jun 19 16:03:55 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 19 Jun 2006 16:04:04 +0100 (BST) Received: from mo30.po.2iij.net ([210.128.50.53]:14374 "EHLO mo30.po.2iij.net") by ftp.linux-mips.org with ESMTP id S8133524AbWFSPDz (ORCPT ); Mon, 19 Jun 2006 16:03:55 +0100 Received: by mo.po.2iij.net (mo30) id k5JF3ptQ047104; Tue, 20 Jun 2006 00:03:51 +0900 (JST) Received: from localhost.localdomain (225.29.30.125.dy.iij4u.or.jp [125.30.29.225]) by mbox.po.2iij.net (mbox30) id k5JF3lRa035274 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 20 Jun 2006 00:03:47 +0900 (JST) Date: Tue, 20 Jun 2006 00:03:46 +0900 From: Yoichi Yuasa To: Ralf Baechle Cc: linux-mips@linux-mips.org Subject: Re: Merge window ... Message-Id: <20060620000346.2b704b9b.yoichi_yuasa@tripeaks.co.jp> In-Reply-To: <20060619103653.GA4257@linux-mips.org> References: <20060619103653.GA4257@linux-mips.org> Organization: TriPeaks Corporation X-Mailer: Sylpheed version 1.0.4 (GTK+ 1.2.10; i386-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11767 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: yoichi_yuasa@tripeaks.co.jp Precedence: bulk X-list: linux-mips Hi Ralf, On Mon, 19 Jun 2006 11:36:53 +0100 Ralf Baechle wrote: > Just a reminder that 2.6.17 is out and as usual there is now a merge > window of two weeks, so try anything that you wish to see to go to > Linus to me asap ... I think we should remove old boards support. Cannot build the following boards now. MIPS Atlas MIPS Malta MIPS SEAD EV64120 ITE 8172G Globespan IVR Momentum Jaguar Toshiba JMR-TX3927 Toshiba RBTX4938 Victor MP-C30X(I'm fixing it now) Momentum Jaguar Momentum Ocelot-3 Momentum Ocelot-C Momentum Ocelot-G MyCable XXS1500 RBHMA4500 SNI RM200 Sibyte BCM91250A-SWARM Wind River PPMC(New one, It'll be fixed) Also the folowing boards don't have config file. 4G Systems MTX-1 AMD Alchemy Bosporus AMD Alchemy Mirage Jazz family Toshiba TBTX49[23]7 These boards are candidate for removal. If there are none objection, we can add to feature-removal-schedule.txt. Yoichi From sshtylyov@ru.mvista.com Mon Jun 19 16:11:41 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 19 Jun 2006 16:11:50 +0100 (BST) Received: from rtsoft2.corbina.net ([85.21.88.2]:27044 "HELO mail.dev.rtsoft.ru") by ftp.linux-mips.org with SMTP id S8133545AbWFSPLl (ORCPT ); Mon, 19 Jun 2006 16:11:41 +0100 Received: (qmail 4757 invoked from network); 19 Jun 2006 19:22:29 -0000 Received: from wasted.dev.rtsoft.ru (HELO ?192.168.1.248?) (192.168.1.248) by mail.dev.rtsoft.ru with SMTP; 19 Jun 2006 19:22:29 -0000 Message-ID: <4496BE57.5040802@ru.mvista.com> Date: Mon, 19 Jun 2006 19:10:15 +0400 From: Sergei Shtylyov Organization: MontaVista Software Inc. User-Agent: Mozilla/5.0 (X11; U; Linux i686; rv:1.7.2) Gecko/20040803 X-Accept-Language: ru, en-us, en-gb MIME-Version: 1.0 To: Yoichi Yuasa CC: ralf@linux-mips.org, Linux-MIPS Subject: Re: Merge window ... References: <20060619103653.GA4257@linux-mips.org> <20060620000346.2b704b9b.yoichi_yuasa@tripeaks.co.jp> In-Reply-To: <20060620000346.2b704b9b.yoichi_yuasa@tripeaks.co.jp> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11768 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: sshtylyov@ru.mvista.com Precedence: bulk X-list: linux-mips Yoichi Yuasa wrote: > I think we should remove old boards support. > Cannot build the following boards now. Some boards named here can hardly be considered old. :-) > Toshiba RBTX4938 > RBHMA4500 This is the same board. I think it's too early to remove this. MV has a number of patches for it BTW, only there was/is no time to push them upstream. > Sibyte BCM91250A-SWARM It's really too early to remove this one. MV is working on the new kernel. > Also the folowing boards don't have config file. > Toshiba TBTX49[23]7 I've pushed some patches for those resently... > These boards are candidate for removal. > If there are none objection, we can add to feature-removal-schedule.txt. > Yoichi WBR, Sergei From anemo@mba.ocn.ne.jp Mon Jun 19 16:18:17 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 19 Jun 2006 16:18:34 +0100 (BST) Received: from mba.ocn.ne.jp ([210.190.142.172]:29674 "HELO smtp.mba.ocn.ne.jp") by ftp.linux-mips.org with SMTP id S8133525AbWFSPSQ (ORCPT ); Mon, 19 Jun 2006 16:18:16 +0100 Received: from localhost (p4087-ipad28funabasi.chiba.ocn.ne.jp [220.107.203.87]) by smtp.mba.ocn.ne.jp (Postfix) with ESMTP id 4F844951A; Tue, 20 Jun 2006 00:18:08 +0900 (JST) Date: Tue, 20 Jun 2006 00:19:13 +0900 (JST) Message-Id: <20060620.001913.25235581.anemo@mba.ocn.ne.jp> To: ralf@linux-mips.org Cc: macro@linux-mips.org, linux-mips@linux-mips.org Subject: Re: [PATCH] use CONFIG_HZ From: Atsushi Nemoto In-Reply-To: <20060425.233138.72708117.anemo@mba.ocn.ne.jp> References: <20060407170401.GA17163@linux-mips.org> <20060409.002929.74751620.anemo@mba.ocn.ne.jp> <20060425.233138.72708117.anemo@mba.ocn.ne.jp> X-Fingerprint: 6ACA 1623 39BD 9A94 9B1A B746 CA77 FE94 2874 D52F X-Pgp-Public-Key: http://wwwkeys.pgp.net/pks/lookup?op=get&search=0x2874D52F X-Mailer: Mew version 3.3 on Emacs 21.4 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11769 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: anemo@mba.ocn.ne.jp Precedence: bulk X-list: linux-mips On Tue, 25 Apr 2006 23:31:38 +0900 (JST), Atsushi Nemoto wrote: > On Sun, 09 Apr 2006 00:29:29 +0900 (JST), Atsushi Nemoto wrote: > > OK, Take 3. 48Hz are only available if explicitly listed in board > > definition. > > Updated for current git tree. Updated again. Make HZ configurable. DECSTATION can select 128/256/1024 HZ, JAZZ can only select 100 HZ, others can select 100/128/250/256/1000/1024 HZ if not explicitly specified). Also remove all mach-xxx/param.h files and update all defconfigs according to current HZ value. Signed-off-by: Atsushi Nemoto b/arch/mips/Kconfig | 75 ++++++++++++++++++++++++++++ b/arch/mips/configs/atlas_defconfig | 9 +++ b/arch/mips/configs/bigsur_defconfig | 9 +++ b/arch/mips/configs/capcella_defconfig | 9 +++ b/arch/mips/configs/cobalt_defconfig | 9 +++ b/arch/mips/configs/db1000_defconfig | 9 +++ b/arch/mips/configs/db1100_defconfig | 9 +++ b/arch/mips/configs/db1200_defconfig | 9 +++ b/arch/mips/configs/db1500_defconfig | 9 +++ b/arch/mips/configs/db1550_defconfig | 9 +++ b/arch/mips/configs/ddb5477_defconfig | 9 +++ b/arch/mips/configs/decstation_defconfig | 11 ++++ b/arch/mips/configs/e55_defconfig | 9 +++ b/arch/mips/configs/emma2rh_defconfig | 9 +++ b/arch/mips/configs/ev64120_defconfig | 9 +++ b/arch/mips/configs/ev96100_defconfig | 9 +++ b/arch/mips/configs/excite_defconfig | 9 +++ b/arch/mips/configs/ip22_defconfig | 9 +++ b/arch/mips/configs/ip27_defconfig | 9 +++ b/arch/mips/configs/ip32_defconfig | 9 +++ b/arch/mips/configs/it8172_defconfig | 9 +++ b/arch/mips/configs/ivr_defconfig | 9 +++ b/arch/mips/configs/jaguar-atx_defconfig | 9 +++ b/arch/mips/configs/jmr3927_defconfig | 9 +++ b/arch/mips/configs/lasat200_defconfig | 9 +++ b/arch/mips/configs/malta_defconfig | 9 +++ b/arch/mips/configs/mipssim_defconfig | 9 +++ b/arch/mips/configs/mpc30x_defconfig | 9 +++ b/arch/mips/configs/ocelot_3_defconfig | 9 +++ b/arch/mips/configs/ocelot_c_defconfig | 9 +++ b/arch/mips/configs/ocelot_defconfig | 9 +++ b/arch/mips/configs/ocelot_g_defconfig | 9 +++ b/arch/mips/configs/pb1100_defconfig | 9 +++ b/arch/mips/configs/pb1500_defconfig | 9 +++ b/arch/mips/configs/pb1550_defconfig | 9 +++ b/arch/mips/configs/pnx8550-jbs_defconfig | 9 +++ b/arch/mips/configs/pnx8550-v2pci_defconfig | 9 +++ b/arch/mips/configs/qemu_defconfig | 9 +++ b/arch/mips/configs/rbhma4500_defconfig | 9 +++ b/arch/mips/configs/rm200_defconfig | 9 +++ b/arch/mips/configs/sb1250-swarm_defconfig | 9 +++ b/arch/mips/configs/sead_defconfig | 9 +++ b/arch/mips/configs/tb0226_defconfig | 9 +++ b/arch/mips/configs/tb0229_defconfig | 9 +++ b/arch/mips/configs/tb0287_defconfig | 9 +++ b/arch/mips/configs/workpad_defconfig | 9 +++ b/arch/mips/configs/wrppmc_defconfig | 9 +++ b/arch/mips/configs/yosemite_defconfig | 9 +++ b/arch/mips/dec/time.c | 2 b/arch/mips/defconfig | 9 +++ b/include/asm-mips/param.h | 2 include/asm-mips/mach-dec/param.h | 18 ------ include/asm-mips/mach-generic/param.h | 13 ---- include/asm-mips/mach-jazz/param.h | 16 ----- include/asm-mips/mach-mips/param.h | 13 ---- include/asm-mips/mach-qemu/param.h | 13 ---- 56 files changed, 511 insertions(+), 75 deletions(-) diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig index 8dcaccc..89ec332 100644 --- a/arch/mips/Kconfig +++ b/arch/mips/Kconfig @@ -168,6 +168,9 @@ config MACH_DECSTATION select SYS_SUPPORTS_32BIT_KERNEL select SYS_SUPPORTS_64BIT_KERNEL if EXPERIMENTAL select SYS_SUPPORTS_LITTLE_ENDIAN + select SYS_SUPPORTS_128HZ + select SYS_SUPPORTS_256HZ + select SYS_SUPPORTS_1024HZ help This enables support for DEC's MIPS based workstations. For details see the Linux/MIPS FAQ on and the @@ -265,6 +268,7 @@ config MACH_JAZZ select SYS_HAS_CPU_R4X00 select SYS_SUPPORTS_32BIT_KERNEL select SYS_SUPPORTS_64BIT_KERNEL if EXPERIMENTAL + select SYS_SUPPORTS_100HZ help This a family of machines based on the MIPS R4030 chipset which was used by several vendors to build RISC/os and Windows NT workstations. @@ -1731,6 +1735,77 @@ config NR_CPUS This is purely to save memory - each supported CPU adds approximately eight kilobytes to the kernel image. +# +# Timer Interrupt Frequency Configuration +# + +choice + prompt "Timer frequency" + default HZ_250 + help + Allows the configuration of the timer frequency. + + config HZ_48 + bool "48 HZ" if SYS_SUPPORTS_48HZ + + config HZ_100 + bool "100 HZ" if SYS_SUPPORTS_100HZ || SYS_SUPPORTS_ARBIT_HZ + + config HZ_128 + bool "128 HZ" if SYS_SUPPORTS_128HZ || SYS_SUPPORTS_ARBIT_HZ + + config HZ_250 + bool "250 HZ" if SYS_SUPPORTS_250HZ || SYS_SUPPORTS_ARBIT_HZ + + config HZ_256 + bool "256 HZ" if SYS_SUPPORTS_256HZ || SYS_SUPPORTS_ARBIT_HZ + + config HZ_1000 + bool "1000 HZ" if SYS_SUPPORTS_1000HZ || SYS_SUPPORTS_ARBIT_HZ + + config HZ_1024 + bool "1024 HZ" if SYS_SUPPORTS_1024HZ || SYS_SUPPORTS_ARBIT_HZ + +endchoice + +config SYS_SUPPORTS_48HZ + bool + +config SYS_SUPPORTS_100HZ + bool + +config SYS_SUPPORTS_128HZ + bool + +config SYS_SUPPORTS_250HZ + bool + +config SYS_SUPPORTS_256HZ + bool + +config SYS_SUPPORTS_1000HZ + bool + +config SYS_SUPPORTS_1024HZ + bool + +config SYS_SUPPORTS_ARBIT_HZ + bool + default y if !SYS_SUPPORTS_48HZ && !SYS_SUPPORTS_100HZ && \ + !SYS_SUPPORTS_128HZ && !SYS_SUPPORTS_250HZ && \ + !SYS_SUPPORTS_256HZ && !SYS_SUPPORTS_1000HZ && \ + !SYS_SUPPORTS_1024HZ + +config HZ + int + default 48 if HZ_48 + default 100 if HZ_100 + default 128 if HZ_128 + default 250 if HZ_250 + default 256 if HZ_256 + default 1000 if HZ_1000 + default 1024 if HZ_1024 + source "kernel/Kconfig.preempt" config RTC_DS1742 diff --git a/arch/mips/configs/atlas_defconfig b/arch/mips/configs/atlas_defconfig index 93b5181..776dcee 100644 --- a/arch/mips/configs/atlas_defconfig +++ b/arch/mips/configs/atlas_defconfig @@ -142,6 +142,15 @@ CONFIG_FLATMEM=y CONFIG_FLAT_NODE_MEM_MAP=y # CONFIG_SPARSEMEM_STATIC is not set CONFIG_SPLIT_PTLOCK_CPUS=4 +# CONFIG_HZ_48 is not set +CONFIG_HZ_100=y +# CONFIG_HZ_128 is not set +# CONFIG_HZ_250 is not set +# CONFIG_HZ_256 is not set +# CONFIG_HZ_1000 is not set +# CONFIG_HZ_1024 is not set +CONFIG_SYS_SUPPORTS_ARBIT_HZ=y +CONFIG_HZ=100 CONFIG_PREEMPT_NONE=y # CONFIG_PREEMPT_VOLUNTARY is not set # CONFIG_PREEMPT is not set diff --git a/arch/mips/configs/bigsur_defconfig b/arch/mips/configs/bigsur_defconfig index f802d06..15884ef 100644 --- a/arch/mips/configs/bigsur_defconfig +++ b/arch/mips/configs/bigsur_defconfig @@ -144,6 +144,15 @@ CONFIG_FLATMEM=y CONFIG_FLAT_NODE_MEM_MAP=y # CONFIG_SPARSEMEM_STATIC is not set CONFIG_SPLIT_PTLOCK_CPUS=4 +# CONFIG_HZ_48 is not set +# CONFIG_HZ_100 is not set +# CONFIG_HZ_128 is not set +# CONFIG_HZ_250 is not set +# CONFIG_HZ_256 is not set +CONFIG_HZ_1000=y +# CONFIG_HZ_1024 is not set +CONFIG_SYS_SUPPORTS_ARBIT_HZ=y +CONFIG_HZ=1000 CONFIG_SMP=y CONFIG_NR_CPUS=4 CONFIG_PREEMPT_NONE=y diff --git a/arch/mips/configs/capcella_defconfig b/arch/mips/configs/capcella_defconfig index 6669df1..da9e60c 100644 --- a/arch/mips/configs/capcella_defconfig +++ b/arch/mips/configs/capcella_defconfig @@ -131,6 +131,15 @@ CONFIG_FLATMEM=y CONFIG_FLAT_NODE_MEM_MAP=y # CONFIG_SPARSEMEM_STATIC is not set CONFIG_SPLIT_PTLOCK_CPUS=4 +# CONFIG_HZ_48 is not set +# CONFIG_HZ_100 is not set +# CONFIG_HZ_128 is not set +# CONFIG_HZ_250 is not set +# CONFIG_HZ_256 is not set +CONFIG_HZ_1000=y +# CONFIG_HZ_1024 is not set +CONFIG_SYS_SUPPORTS_ARBIT_HZ=y +CONFIG_HZ=1000 CONFIG_PREEMPT_NONE=y # CONFIG_PREEMPT_VOLUNTARY is not set # CONFIG_PREEMPT is not set diff --git a/arch/mips/configs/cobalt_defconfig b/arch/mips/configs/cobalt_defconfig index 46cbed1..4923fc1 100644 --- a/arch/mips/configs/cobalt_defconfig +++ b/arch/mips/configs/cobalt_defconfig @@ -128,6 +128,15 @@ CONFIG_FLATMEM=y CONFIG_FLAT_NODE_MEM_MAP=y # CONFIG_SPARSEMEM_STATIC is not set CONFIG_SPLIT_PTLOCK_CPUS=4 +# CONFIG_HZ_48 is not set +# CONFIG_HZ_100 is not set +# CONFIG_HZ_128 is not set +# CONFIG_HZ_250 is not set +# CONFIG_HZ_256 is not set +CONFIG_HZ_1000=y +# CONFIG_HZ_1024 is not set +CONFIG_SYS_SUPPORTS_ARBIT_HZ=y +CONFIG_HZ=1000 CONFIG_PREEMPT_NONE=y # CONFIG_PREEMPT_VOLUNTARY is not set # CONFIG_PREEMPT is not set diff --git a/arch/mips/configs/db1000_defconfig b/arch/mips/configs/db1000_defconfig index 89f91ce..a640849 100644 --- a/arch/mips/configs/db1000_defconfig +++ b/arch/mips/configs/db1000_defconfig @@ -129,6 +129,15 @@ CONFIG_FLATMEM=y CONFIG_FLAT_NODE_MEM_MAP=y # CONFIG_SPARSEMEM_STATIC is not set CONFIG_SPLIT_PTLOCK_CPUS=4 +# CONFIG_HZ_48 is not set +# CONFIG_HZ_100 is not set +# CONFIG_HZ_128 is not set +# CONFIG_HZ_250 is not set +# CONFIG_HZ_256 is not set +CONFIG_HZ_1000=y +# CONFIG_HZ_1024 is not set +CONFIG_SYS_SUPPORTS_ARBIT_HZ=y +CONFIG_HZ=1000 CONFIG_PREEMPT_NONE=y # CONFIG_PREEMPT_VOLUNTARY is not set # CONFIG_PREEMPT is not set diff --git a/arch/mips/configs/db1100_defconfig b/arch/mips/configs/db1100_defconfig index 08912e1..84b7f9c 100644 --- a/arch/mips/configs/db1100_defconfig +++ b/arch/mips/configs/db1100_defconfig @@ -129,6 +129,15 @@ CONFIG_FLATMEM=y CONFIG_FLAT_NODE_MEM_MAP=y # CONFIG_SPARSEMEM_STATIC is not set CONFIG_SPLIT_PTLOCK_CPUS=4 +# CONFIG_HZ_48 is not set +# CONFIG_HZ_100 is not set +# CONFIG_HZ_128 is not set +# CONFIG_HZ_250 is not set +# CONFIG_HZ_256 is not set +CONFIG_HZ_1000=y +# CONFIG_HZ_1024 is not set +CONFIG_SYS_SUPPORTS_ARBIT_HZ=y +CONFIG_HZ=1000 CONFIG_PREEMPT_NONE=y # CONFIG_PREEMPT_VOLUNTARY is not set # CONFIG_PREEMPT is not set diff --git a/arch/mips/configs/db1200_defconfig b/arch/mips/configs/db1200_defconfig index fd9f86c..c3700d3 100644 --- a/arch/mips/configs/db1200_defconfig +++ b/arch/mips/configs/db1200_defconfig @@ -129,6 +129,15 @@ CONFIG_FLATMEM=y CONFIG_FLAT_NODE_MEM_MAP=y # CONFIG_SPARSEMEM_STATIC is not set CONFIG_SPLIT_PTLOCK_CPUS=4 +# CONFIG_HZ_48 is not set +# CONFIG_HZ_100 is not set +# CONFIG_HZ_128 is not set +# CONFIG_HZ_250 is not set +# CONFIG_HZ_256 is not set +CONFIG_HZ_1000=y +# CONFIG_HZ_1024 is not set +CONFIG_SYS_SUPPORTS_ARBIT_HZ=y +CONFIG_HZ=1000 CONFIG_PREEMPT_NONE=y # CONFIG_PREEMPT_VOLUNTARY is not set # CONFIG_PREEMPT is not set diff --git a/arch/mips/configs/db1500_defconfig b/arch/mips/configs/db1500_defconfig index 9be59eb..1539390 100644 --- a/arch/mips/configs/db1500_defconfig +++ b/arch/mips/configs/db1500_defconfig @@ -131,6 +131,15 @@ CONFIG_FLATMEM=y CONFIG_FLAT_NODE_MEM_MAP=y # CONFIG_SPARSEMEM_STATIC is not set CONFIG_SPLIT_PTLOCK_CPUS=4 +# CONFIG_HZ_48 is not set +# CONFIG_HZ_100 is not set +# CONFIG_HZ_128 is not set +# CONFIG_HZ_250 is not set +# CONFIG_HZ_256 is not set +CONFIG_HZ_1000=y +# CONFIG_HZ_1024 is not set +CONFIG_SYS_SUPPORTS_ARBIT_HZ=y +CONFIG_HZ=1000 CONFIG_PREEMPT_NONE=y # CONFIG_PREEMPT_VOLUNTARY is not set # CONFIG_PREEMPT is not set diff --git a/arch/mips/configs/db1550_defconfig b/arch/mips/configs/db1550_defconfig index 6142438..7d77561 100644 --- a/arch/mips/configs/db1550_defconfig +++ b/arch/mips/configs/db1550_defconfig @@ -130,6 +130,15 @@ CONFIG_FLATMEM=y CONFIG_FLAT_NODE_MEM_MAP=y # CONFIG_SPARSEMEM_STATIC is not set CONFIG_SPLIT_PTLOCK_CPUS=4 +# CONFIG_HZ_48 is not set +# CONFIG_HZ_100 is not set +# CONFIG_HZ_128 is not set +# CONFIG_HZ_250 is not set +# CONFIG_HZ_256 is not set +CONFIG_HZ_1000=y +# CONFIG_HZ_1024 is not set +CONFIG_SYS_SUPPORTS_ARBIT_HZ=y +CONFIG_HZ=1000 CONFIG_PREEMPT_NONE=y # CONFIG_PREEMPT_VOLUNTARY is not set # CONFIG_PREEMPT is not set diff --git a/arch/mips/configs/ddb5477_defconfig b/arch/mips/configs/ddb5477_defconfig index 1ff5780..913bc57 100644 --- a/arch/mips/configs/ddb5477_defconfig +++ b/arch/mips/configs/ddb5477_defconfig @@ -128,6 +128,15 @@ CONFIG_FLATMEM=y CONFIG_FLAT_NODE_MEM_MAP=y # CONFIG_SPARSEMEM_STATIC is not set CONFIG_SPLIT_PTLOCK_CPUS=4 +# CONFIG_HZ_48 is not set +# CONFIG_HZ_100 is not set +# CONFIG_HZ_128 is not set +# CONFIG_HZ_250 is not set +# CONFIG_HZ_256 is not set +CONFIG_HZ_1000=y +# CONFIG_HZ_1024 is not set +CONFIG_SYS_SUPPORTS_ARBIT_HZ=y +CONFIG_HZ=1000 CONFIG_PREEMPT_NONE=y # CONFIG_PREEMPT_VOLUNTARY is not set # CONFIG_PREEMPT is not set diff --git a/arch/mips/configs/decstation_defconfig b/arch/mips/configs/decstation_defconfig index c8d6c5d..ed39ded 100644 --- a/arch/mips/configs/decstation_defconfig +++ b/arch/mips/configs/decstation_defconfig @@ -127,6 +127,17 @@ CONFIG_FLATMEM=y CONFIG_FLAT_NODE_MEM_MAP=y # CONFIG_SPARSEMEM_STATIC is not set CONFIG_SPLIT_PTLOCK_CPUS=4 +# CONFIG_HZ_48 is not set +# CONFIG_HZ_100 is not set +CONFIG_HZ_128=y +# CONFIG_HZ_250 is not set +# CONFIG_HZ_256 is not set +# CONFIG_HZ_1000 is not set +# CONFIG_HZ_1024 is not set +CONFIG_SYS_SUPPORTS_128HZ=y +CONFIG_SYS_SUPPORTS_256HZ=y +CONFIG_SYS_SUPPORTS_1024HZ=y +CONFIG_HZ=128 CONFIG_PREEMPT_NONE=y # CONFIG_PREEMPT_VOLUNTARY is not set # CONFIG_PREEMPT is not set diff --git a/arch/mips/configs/e55_defconfig b/arch/mips/configs/e55_defconfig index 6eb178a..f0e46bf 100644 --- a/arch/mips/configs/e55_defconfig +++ b/arch/mips/configs/e55_defconfig @@ -129,6 +129,15 @@ CONFIG_FLATMEM=y CONFIG_FLAT_NODE_MEM_MAP=y # CONFIG_SPARSEMEM_STATIC is not set CONFIG_SPLIT_PTLOCK_CPUS=4 +# CONFIG_HZ_48 is not set +# CONFIG_HZ_100 is not set +# CONFIG_HZ_128 is not set +# CONFIG_HZ_250 is not set +# CONFIG_HZ_256 is not set +CONFIG_HZ_1000=y +# CONFIG_HZ_1024 is not set +CONFIG_SYS_SUPPORTS_ARBIT_HZ=y +CONFIG_HZ=1000 CONFIG_PREEMPT_NONE=y # CONFIG_PREEMPT_VOLUNTARY is not set # CONFIG_PREEMPT is not set diff --git a/arch/mips/configs/emma2rh_defconfig b/arch/mips/configs/emma2rh_defconfig index da1bc03..01f29f4 100644 --- a/arch/mips/configs/emma2rh_defconfig +++ b/arch/mips/configs/emma2rh_defconfig @@ -133,6 +133,15 @@ CONFIG_FLATMEM=y CONFIG_FLAT_NODE_MEM_MAP=y # CONFIG_SPARSEMEM_STATIC is not set CONFIG_SPLIT_PTLOCK_CPUS=4 +# CONFIG_HZ_48 is not set +# CONFIG_HZ_100 is not set +# CONFIG_HZ_128 is not set +# CONFIG_HZ_250 is not set +# CONFIG_HZ_256 is not set +CONFIG_HZ_1000=y +# CONFIG_HZ_1024 is not set +CONFIG_SYS_SUPPORTS_ARBIT_HZ=y +CONFIG_HZ=1000 # CONFIG_PREEMPT_NONE is not set # CONFIG_PREEMPT_VOLUNTARY is not set CONFIG_PREEMPT=y diff --git a/arch/mips/configs/ev64120_defconfig b/arch/mips/configs/ev64120_defconfig index dc7caa8..dc62fe2 100644 --- a/arch/mips/configs/ev64120_defconfig +++ b/arch/mips/configs/ev64120_defconfig @@ -130,6 +130,15 @@ CONFIG_FLATMEM=y CONFIG_FLAT_NODE_MEM_MAP=y # CONFIG_SPARSEMEM_STATIC is not set CONFIG_SPLIT_PTLOCK_CPUS=4 +# CONFIG_HZ_48 is not set +# CONFIG_HZ_100 is not set +# CONFIG_HZ_128 is not set +# CONFIG_HZ_250 is not set +# CONFIG_HZ_256 is not set +CONFIG_HZ_1000=y +# CONFIG_HZ_1024 is not set +CONFIG_SYS_SUPPORTS_ARBIT_HZ=y +CONFIG_HZ=1000 CONFIG_PREEMPT_NONE=y # CONFIG_PREEMPT_VOLUNTARY is not set # CONFIG_PREEMPT is not set diff --git a/arch/mips/configs/ev96100_defconfig b/arch/mips/configs/ev96100_defconfig index d9c1c67..fc73e4d 100644 --- a/arch/mips/configs/ev96100_defconfig +++ b/arch/mips/configs/ev96100_defconfig @@ -134,6 +134,15 @@ CONFIG_FLATMEM=y CONFIG_FLAT_NODE_MEM_MAP=y # CONFIG_SPARSEMEM_STATIC is not set CONFIG_SPLIT_PTLOCK_CPUS=4 +# CONFIG_HZ_48 is not set +# CONFIG_HZ_100 is not set +# CONFIG_HZ_128 is not set +# CONFIG_HZ_250 is not set +# CONFIG_HZ_256 is not set +CONFIG_HZ_1000=y +# CONFIG_HZ_1024 is not set +CONFIG_SYS_SUPPORTS_ARBIT_HZ=y +CONFIG_HZ=1000 CONFIG_PREEMPT_NONE=y # CONFIG_PREEMPT_VOLUNTARY is not set # CONFIG_PREEMPT is not set diff --git a/arch/mips/configs/excite_defconfig b/arch/mips/configs/excite_defconfig index 3240962..f2ce64c 100644 --- a/arch/mips/configs/excite_defconfig +++ b/arch/mips/configs/excite_defconfig @@ -132,6 +132,15 @@ CONFIG_FLATMEM=y CONFIG_FLAT_NODE_MEM_MAP=y # CONFIG_SPARSEMEM_STATIC is not set CONFIG_SPLIT_PTLOCK_CPUS=4 +# CONFIG_HZ_48 is not set +# CONFIG_HZ_100 is not set +# CONFIG_HZ_128 is not set +# CONFIG_HZ_250 is not set +# CONFIG_HZ_256 is not set +CONFIG_HZ_1000=y +# CONFIG_HZ_1024 is not set +CONFIG_SYS_SUPPORTS_ARBIT_HZ=y +CONFIG_HZ=1000 # CONFIG_SMP is not set # CONFIG_PREEMPT_NONE is not set # CONFIG_PREEMPT_VOLUNTARY is not set diff --git a/arch/mips/configs/ip22_defconfig b/arch/mips/configs/ip22_defconfig index 6d03aeb..664283c 100644 --- a/arch/mips/configs/ip22_defconfig +++ b/arch/mips/configs/ip22_defconfig @@ -135,6 +135,15 @@ CONFIG_FLATMEM=y CONFIG_FLAT_NODE_MEM_MAP=y # CONFIG_SPARSEMEM_STATIC is not set CONFIG_SPLIT_PTLOCK_CPUS=4 +# CONFIG_HZ_48 is not set +# CONFIG_HZ_100 is not set +# CONFIG_HZ_128 is not set +# CONFIG_HZ_250 is not set +# CONFIG_HZ_256 is not set +CONFIG_HZ_1000=y +# CONFIG_HZ_1024 is not set +CONFIG_SYS_SUPPORTS_ARBIT_HZ=y +CONFIG_HZ=1000 # CONFIG_PREEMPT_NONE is not set CONFIG_PREEMPT_VOLUNTARY=y # CONFIG_PREEMPT is not set diff --git a/arch/mips/configs/ip27_defconfig b/arch/mips/configs/ip27_defconfig index 749481e..969f282 100644 --- a/arch/mips/configs/ip27_defconfig +++ b/arch/mips/configs/ip27_defconfig @@ -134,6 +134,15 @@ CONFIG_FLAT_NODE_MEM_MAP=y CONFIG_NEED_MULTIPLE_NODES=y # CONFIG_SPARSEMEM_STATIC is not set CONFIG_SPLIT_PTLOCK_CPUS=4 +# CONFIG_HZ_48 is not set +# CONFIG_HZ_100 is not set +# CONFIG_HZ_128 is not set +# CONFIG_HZ_250 is not set +# CONFIG_HZ_256 is not set +CONFIG_HZ_1000=y +# CONFIG_HZ_1024 is not set +CONFIG_SYS_SUPPORTS_ARBIT_HZ=y +CONFIG_HZ=1000 CONFIG_MIGRATION=y CONFIG_SMP=y CONFIG_NR_CPUS=64 diff --git a/arch/mips/configs/ip32_defconfig b/arch/mips/configs/ip32_defconfig index 29bd0ad..1bae379 100644 --- a/arch/mips/configs/ip32_defconfig +++ b/arch/mips/configs/ip32_defconfig @@ -135,6 +135,15 @@ CONFIG_FLATMEM=y CONFIG_FLAT_NODE_MEM_MAP=y # CONFIG_SPARSEMEM_STATIC is not set CONFIG_SPLIT_PTLOCK_CPUS=4 +# CONFIG_HZ_48 is not set +# CONFIG_HZ_100 is not set +# CONFIG_HZ_128 is not set +# CONFIG_HZ_250 is not set +# CONFIG_HZ_256 is not set +CONFIG_HZ_1000=y +# CONFIG_HZ_1024 is not set +CONFIG_SYS_SUPPORTS_ARBIT_HZ=y +CONFIG_HZ=1000 # CONFIG_PREEMPT_NONE is not set CONFIG_PREEMPT_VOLUNTARY=y # CONFIG_PREEMPT is not set diff --git a/arch/mips/configs/it8172_defconfig b/arch/mips/configs/it8172_defconfig index 98a26ea..d6ea8d8 100644 --- a/arch/mips/configs/it8172_defconfig +++ b/arch/mips/configs/it8172_defconfig @@ -129,6 +129,15 @@ CONFIG_FLATMEM=y CONFIG_FLAT_NODE_MEM_MAP=y # CONFIG_SPARSEMEM_STATIC is not set CONFIG_SPLIT_PTLOCK_CPUS=4 +# CONFIG_HZ_48 is not set +# CONFIG_HZ_100 is not set +# CONFIG_HZ_128 is not set +# CONFIG_HZ_250 is not set +# CONFIG_HZ_256 is not set +CONFIG_HZ_1000=y +# CONFIG_HZ_1024 is not set +CONFIG_SYS_SUPPORTS_ARBIT_HZ=y +CONFIG_HZ=1000 CONFIG_PREEMPT_NONE=y # CONFIG_PREEMPT_VOLUNTARY is not set # CONFIG_PREEMPT is not set diff --git a/arch/mips/configs/ivr_defconfig b/arch/mips/configs/ivr_defconfig index 2a74cdd..c8579ba 100644 --- a/arch/mips/configs/ivr_defconfig +++ b/arch/mips/configs/ivr_defconfig @@ -126,6 +126,15 @@ CONFIG_FLATMEM=y CONFIG_FLAT_NODE_MEM_MAP=y # CONFIG_SPARSEMEM_STATIC is not set CONFIG_SPLIT_PTLOCK_CPUS=4 +# CONFIG_HZ_48 is not set +# CONFIG_HZ_100 is not set +# CONFIG_HZ_128 is not set +# CONFIG_HZ_250 is not set +# CONFIG_HZ_256 is not set +CONFIG_HZ_1000=y +# CONFIG_HZ_1024 is not set +CONFIG_SYS_SUPPORTS_ARBIT_HZ=y +CONFIG_HZ=1000 CONFIG_PREEMPT_NONE=y # CONFIG_PREEMPT_VOLUNTARY is not set # CONFIG_PREEMPT is not set diff --git a/arch/mips/configs/jaguar-atx_defconfig b/arch/mips/configs/jaguar-atx_defconfig index 2dd971c..59bb5b1 100644 --- a/arch/mips/configs/jaguar-atx_defconfig +++ b/arch/mips/configs/jaguar-atx_defconfig @@ -135,6 +135,15 @@ CONFIG_FLATMEM=y CONFIG_FLAT_NODE_MEM_MAP=y # CONFIG_SPARSEMEM_STATIC is not set CONFIG_SPLIT_PTLOCK_CPUS=4 +# CONFIG_HZ_48 is not set +# CONFIG_HZ_100 is not set +# CONFIG_HZ_128 is not set +# CONFIG_HZ_250 is not set +# CONFIG_HZ_256 is not set +CONFIG_HZ_1000=y +# CONFIG_HZ_1024 is not set +CONFIG_SYS_SUPPORTS_ARBIT_HZ=y +CONFIG_HZ=1000 # CONFIG_SMP is not set CONFIG_PREEMPT_NONE=y # CONFIG_PREEMPT_VOLUNTARY is not set diff --git a/arch/mips/configs/jmr3927_defconfig b/arch/mips/configs/jmr3927_defconfig index 174fac8..b04c2fb 100644 --- a/arch/mips/configs/jmr3927_defconfig +++ b/arch/mips/configs/jmr3927_defconfig @@ -124,6 +124,15 @@ CONFIG_FLATMEM=y CONFIG_FLAT_NODE_MEM_MAP=y # CONFIG_SPARSEMEM_STATIC is not set CONFIG_SPLIT_PTLOCK_CPUS=4 +# CONFIG_HZ_48 is not set +# CONFIG_HZ_100 is not set +# CONFIG_HZ_128 is not set +# CONFIG_HZ_250 is not set +# CONFIG_HZ_256 is not set +CONFIG_HZ_1000=y +# CONFIG_HZ_1024 is not set +CONFIG_SYS_SUPPORTS_ARBIT_HZ=y +CONFIG_HZ=1000 CONFIG_PREEMPT_NONE=y # CONFIG_PREEMPT_VOLUNTARY is not set # CONFIG_PREEMPT is not set diff --git a/arch/mips/configs/lasat200_defconfig b/arch/mips/configs/lasat200_defconfig index 42bbe06..4582b00 100644 --- a/arch/mips/configs/lasat200_defconfig +++ b/arch/mips/configs/lasat200_defconfig @@ -133,6 +133,15 @@ CONFIG_FLATMEM=y CONFIG_FLAT_NODE_MEM_MAP=y # CONFIG_SPARSEMEM_STATIC is not set CONFIG_SPLIT_PTLOCK_CPUS=4 +# CONFIG_HZ_48 is not set +# CONFIG_HZ_100 is not set +# CONFIG_HZ_128 is not set +# CONFIG_HZ_250 is not set +# CONFIG_HZ_256 is not set +CONFIG_HZ_1000=y +# CONFIG_HZ_1024 is not set +CONFIG_SYS_SUPPORTS_ARBIT_HZ=y +CONFIG_HZ=1000 CONFIG_PREEMPT_NONE=y # CONFIG_PREEMPT_VOLUNTARY is not set # CONFIG_PREEMPT is not set diff --git a/arch/mips/configs/malta_defconfig b/arch/mips/configs/malta_defconfig index 7411dac..85c95b9 100644 --- a/arch/mips/configs/malta_defconfig +++ b/arch/mips/configs/malta_defconfig @@ -153,6 +153,15 @@ CONFIG_FLATMEM=y CONFIG_FLAT_NODE_MEM_MAP=y # CONFIG_SPARSEMEM_STATIC is not set CONFIG_SPLIT_PTLOCK_CPUS=4 +# CONFIG_HZ_48 is not set +CONFIG_HZ_100=y +# CONFIG_HZ_128 is not set +# CONFIG_HZ_250 is not set +# CONFIG_HZ_256 is not set +# CONFIG_HZ_1000 is not set +# CONFIG_HZ_1024 is not set +CONFIG_SYS_SUPPORTS_ARBIT_HZ=y +CONFIG_HZ=100 CONFIG_PREEMPT_NONE=y # CONFIG_PREEMPT_VOLUNTARY is not set # CONFIG_PREEMPT is not set diff --git a/arch/mips/configs/mipssim_defconfig b/arch/mips/configs/mipssim_defconfig index d5bfb68..632ea35 100644 --- a/arch/mips/configs/mipssim_defconfig +++ b/arch/mips/configs/mipssim_defconfig @@ -137,6 +137,15 @@ CONFIG_FLATMEM=y CONFIG_FLAT_NODE_MEM_MAP=y # CONFIG_SPARSEMEM_STATIC is not set CONFIG_SPLIT_PTLOCK_CPUS=4 +# CONFIG_HZ_48 is not set +# CONFIG_HZ_100 is not set +# CONFIG_HZ_128 is not set +# CONFIG_HZ_250 is not set +# CONFIG_HZ_256 is not set +CONFIG_HZ_1000=y +# CONFIG_HZ_1024 is not set +CONFIG_SYS_SUPPORTS_ARBIT_HZ=y +CONFIG_HZ=1000 CONFIG_PREEMPT_NONE=y # CONFIG_PREEMPT_VOLUNTARY is not set # CONFIG_PREEMPT is not set diff --git a/arch/mips/configs/mpc30x_defconfig b/arch/mips/configs/mpc30x_defconfig index 3bcfb9a..fd588fd 100644 --- a/arch/mips/configs/mpc30x_defconfig +++ b/arch/mips/configs/mpc30x_defconfig @@ -131,6 +131,15 @@ CONFIG_FLATMEM=y CONFIG_FLAT_NODE_MEM_MAP=y # CONFIG_SPARSEMEM_STATIC is not set CONFIG_SPLIT_PTLOCK_CPUS=4 +# CONFIG_HZ_48 is not set +# CONFIG_HZ_100 is not set +# CONFIG_HZ_128 is not set +# CONFIG_HZ_250 is not set +# CONFIG_HZ_256 is not set +CONFIG_HZ_1000=y +# CONFIG_HZ_1024 is not set +CONFIG_SYS_SUPPORTS_ARBIT_HZ=y +CONFIG_HZ=1000 CONFIG_PREEMPT_NONE=y # CONFIG_PREEMPT_VOLUNTARY is not set # CONFIG_PREEMPT is not set diff --git a/arch/mips/configs/ocelot_3_defconfig b/arch/mips/configs/ocelot_3_defconfig index 3e81a40..9f02e0f 100644 --- a/arch/mips/configs/ocelot_3_defconfig +++ b/arch/mips/configs/ocelot_3_defconfig @@ -135,6 +135,15 @@ CONFIG_FLATMEM=y CONFIG_FLAT_NODE_MEM_MAP=y # CONFIG_SPARSEMEM_STATIC is not set CONFIG_SPLIT_PTLOCK_CPUS=4 +# CONFIG_HZ_48 is not set +# CONFIG_HZ_100 is not set +# CONFIG_HZ_128 is not set +# CONFIG_HZ_250 is not set +# CONFIG_HZ_256 is not set +CONFIG_HZ_1000=y +# CONFIG_HZ_1024 is not set +CONFIG_SYS_SUPPORTS_ARBIT_HZ=y +CONFIG_HZ=1000 # CONFIG_SMP is not set CONFIG_PREEMPT_NONE=y # CONFIG_PREEMPT_VOLUNTARY is not set diff --git a/arch/mips/configs/ocelot_c_defconfig b/arch/mips/configs/ocelot_c_defconfig index 3e3858a..be34918 100644 --- a/arch/mips/configs/ocelot_c_defconfig +++ b/arch/mips/configs/ocelot_c_defconfig @@ -132,6 +132,15 @@ CONFIG_FLATMEM=y CONFIG_FLAT_NODE_MEM_MAP=y # CONFIG_SPARSEMEM_STATIC is not set CONFIG_SPLIT_PTLOCK_CPUS=4 +# CONFIG_HZ_48 is not set +# CONFIG_HZ_100 is not set +# CONFIG_HZ_128 is not set +# CONFIG_HZ_250 is not set +# CONFIG_HZ_256 is not set +CONFIG_HZ_1000=y +# CONFIG_HZ_1024 is not set +CONFIG_SYS_SUPPORTS_ARBIT_HZ=y +CONFIG_HZ=1000 CONFIG_PREEMPT_NONE=y # CONFIG_PREEMPT_VOLUNTARY is not set # CONFIG_PREEMPT is not set diff --git a/arch/mips/configs/ocelot_defconfig b/arch/mips/configs/ocelot_defconfig index 2c9bdad..b5a4984 100644 --- a/arch/mips/configs/ocelot_defconfig +++ b/arch/mips/configs/ocelot_defconfig @@ -136,6 +136,15 @@ CONFIG_FLATMEM=y CONFIG_FLAT_NODE_MEM_MAP=y # CONFIG_SPARSEMEM_STATIC is not set CONFIG_SPLIT_PTLOCK_CPUS=4 +# CONFIG_HZ_48 is not set +# CONFIG_HZ_100 is not set +# CONFIG_HZ_128 is not set +# CONFIG_HZ_250 is not set +# CONFIG_HZ_256 is not set +CONFIG_HZ_1000=y +# CONFIG_HZ_1024 is not set +CONFIG_SYS_SUPPORTS_ARBIT_HZ=y +CONFIG_HZ=1000 CONFIG_PREEMPT_NONE=y # CONFIG_PREEMPT_VOLUNTARY is not set # CONFIG_PREEMPT is not set diff --git a/arch/mips/configs/ocelot_g_defconfig b/arch/mips/configs/ocelot_g_defconfig index 9368336..5b364ae 100644 --- a/arch/mips/configs/ocelot_g_defconfig +++ b/arch/mips/configs/ocelot_g_defconfig @@ -135,6 +135,15 @@ CONFIG_FLATMEM=y CONFIG_FLAT_NODE_MEM_MAP=y # CONFIG_SPARSEMEM_STATIC is not set CONFIG_SPLIT_PTLOCK_CPUS=4 +# CONFIG_HZ_48 is not set +# CONFIG_HZ_100 is not set +# CONFIG_HZ_128 is not set +# CONFIG_HZ_250 is not set +# CONFIG_HZ_256 is not set +CONFIG_HZ_1000=y +# CONFIG_HZ_1024 is not set +CONFIG_SYS_SUPPORTS_ARBIT_HZ=y +CONFIG_HZ=1000 CONFIG_PREEMPT_NONE=y # CONFIG_PREEMPT_VOLUNTARY is not set # CONFIG_PREEMPT is not set diff --git a/arch/mips/configs/pb1100_defconfig b/arch/mips/configs/pb1100_defconfig index 48edee2..e7ae00a 100644 --- a/arch/mips/configs/pb1100_defconfig +++ b/arch/mips/configs/pb1100_defconfig @@ -131,6 +131,15 @@ CONFIG_FLATMEM=y CONFIG_FLAT_NODE_MEM_MAP=y # CONFIG_SPARSEMEM_STATIC is not set CONFIG_SPLIT_PTLOCK_CPUS=4 +# CONFIG_HZ_48 is not set +# CONFIG_HZ_100 is not set +# CONFIG_HZ_128 is not set +# CONFIG_HZ_250 is not set +# CONFIG_HZ_256 is not set +CONFIG_HZ_1000=y +# CONFIG_HZ_1024 is not set +CONFIG_SYS_SUPPORTS_ARBIT_HZ=y +CONFIG_HZ=1000 CONFIG_PREEMPT_NONE=y # CONFIG_PREEMPT_VOLUNTARY is not set # CONFIG_PREEMPT is not set diff --git a/arch/mips/configs/pb1500_defconfig b/arch/mips/configs/pb1500_defconfig index 94fe7d8..2718879 100644 --- a/arch/mips/configs/pb1500_defconfig +++ b/arch/mips/configs/pb1500_defconfig @@ -130,6 +130,15 @@ CONFIG_FLATMEM=y CONFIG_FLAT_NODE_MEM_MAP=y # CONFIG_SPARSEMEM_STATIC is not set CONFIG_SPLIT_PTLOCK_CPUS=4 +# CONFIG_HZ_48 is not set +# CONFIG_HZ_100 is not set +# CONFIG_HZ_128 is not set +# CONFIG_HZ_250 is not set +# CONFIG_HZ_256 is not set +CONFIG_HZ_1000=y +# CONFIG_HZ_1024 is not set +CONFIG_SYS_SUPPORTS_ARBIT_HZ=y +CONFIG_HZ=1000 CONFIG_PREEMPT_NONE=y # CONFIG_PREEMPT_VOLUNTARY is not set # CONFIG_PREEMPT is not set diff --git a/arch/mips/configs/pb1550_defconfig b/arch/mips/configs/pb1550_defconfig index dc754ec..f52d085 100644 --- a/arch/mips/configs/pb1550_defconfig +++ b/arch/mips/configs/pb1550_defconfig @@ -130,6 +130,15 @@ CONFIG_FLATMEM=y CONFIG_FLAT_NODE_MEM_MAP=y # CONFIG_SPARSEMEM_STATIC is not set CONFIG_SPLIT_PTLOCK_CPUS=4 +# CONFIG_HZ_48 is not set +# CONFIG_HZ_100 is not set +# CONFIG_HZ_128 is not set +# CONFIG_HZ_250 is not set +# CONFIG_HZ_256 is not set +CONFIG_HZ_1000=y +# CONFIG_HZ_1024 is not set +CONFIG_SYS_SUPPORTS_ARBIT_HZ=y +CONFIG_HZ=1000 CONFIG_PREEMPT_NONE=y # CONFIG_PREEMPT_VOLUNTARY is not set # CONFIG_PREEMPT is not set diff --git a/arch/mips/configs/pnx8550-jbs_defconfig b/arch/mips/configs/pnx8550-jbs_defconfig index 3851133..3448156 100644 --- a/arch/mips/configs/pnx8550-jbs_defconfig +++ b/arch/mips/configs/pnx8550-jbs_defconfig @@ -129,6 +129,15 @@ CONFIG_FLATMEM=y CONFIG_FLAT_NODE_MEM_MAP=y # CONFIG_SPARSEMEM_STATIC is not set CONFIG_SPLIT_PTLOCK_CPUS=4 +# CONFIG_HZ_48 is not set +# CONFIG_HZ_100 is not set +# CONFIG_HZ_128 is not set +# CONFIG_HZ_250 is not set +# CONFIG_HZ_256 is not set +CONFIG_HZ_1000=y +# CONFIG_HZ_1024 is not set +CONFIG_SYS_SUPPORTS_ARBIT_HZ=y +CONFIG_HZ=1000 CONFIG_PREEMPT_NONE=y # CONFIG_PREEMPT_VOLUNTARY is not set # CONFIG_PREEMPT is not set diff --git a/arch/mips/configs/pnx8550-v2pci_defconfig b/arch/mips/configs/pnx8550-v2pci_defconfig index 43d7048..e9228f0 100644 --- a/arch/mips/configs/pnx8550-v2pci_defconfig +++ b/arch/mips/configs/pnx8550-v2pci_defconfig @@ -129,6 +129,15 @@ CONFIG_FLATMEM=y CONFIG_FLAT_NODE_MEM_MAP=y # CONFIG_SPARSEMEM_STATIC is not set CONFIG_SPLIT_PTLOCK_CPUS=4 +# CONFIG_HZ_48 is not set +# CONFIG_HZ_100 is not set +# CONFIG_HZ_128 is not set +# CONFIG_HZ_250 is not set +# CONFIG_HZ_256 is not set +CONFIG_HZ_1000=y +# CONFIG_HZ_1024 is not set +CONFIG_SYS_SUPPORTS_ARBIT_HZ=y +CONFIG_HZ=1000 CONFIG_PREEMPT_NONE=y # CONFIG_PREEMPT_VOLUNTARY is not set # CONFIG_PREEMPT is not set diff --git a/arch/mips/configs/qemu_defconfig b/arch/mips/configs/qemu_defconfig index 7acb72d..f76a1ee 100644 --- a/arch/mips/configs/qemu_defconfig +++ b/arch/mips/configs/qemu_defconfig @@ -127,6 +127,15 @@ CONFIG_FLAT_NODE_MEM_MAP=y # CONFIG_SPARSEMEM_STATIC is not set CONFIG_SPLIT_PTLOCK_CPUS=4 # CONFIG_SMP is not set +# CONFIG_HZ_48 is not set +CONFIG_HZ_100=y +# CONFIG_HZ_128 is not set +# CONFIG_HZ_250 is not set +# CONFIG_HZ_256 is not set +# CONFIG_HZ_1000 is not set +# CONFIG_HZ_1024 is not set +CONFIG_SYS_SUPPORTS_ARBIT_HZ=y +CONFIG_HZ=100 CONFIG_PREEMPT_NONE=y # CONFIG_PREEMPT_VOLUNTARY is not set # CONFIG_PREEMPT is not set diff --git a/arch/mips/configs/rbhma4500_defconfig b/arch/mips/configs/rbhma4500_defconfig index 1156c0a..7796cc1 100644 --- a/arch/mips/configs/rbhma4500_defconfig +++ b/arch/mips/configs/rbhma4500_defconfig @@ -137,6 +137,15 @@ CONFIG_FLATMEM=y CONFIG_FLAT_NODE_MEM_MAP=y # CONFIG_SPARSEMEM_STATIC is not set CONFIG_SPLIT_PTLOCK_CPUS=4 +# CONFIG_HZ_48 is not set +# CONFIG_HZ_100 is not set +# CONFIG_HZ_128 is not set +# CONFIG_HZ_250 is not set +# CONFIG_HZ_256 is not set +CONFIG_HZ_1000=y +# CONFIG_HZ_1024 is not set +CONFIG_SYS_SUPPORTS_ARBIT_HZ=y +CONFIG_HZ=1000 CONFIG_PREEMPT_NONE=y # CONFIG_PREEMPT_VOLUNTARY is not set # CONFIG_PREEMPT is not set diff --git a/arch/mips/configs/rm200_defconfig b/arch/mips/configs/rm200_defconfig index 1b214e4..3635f9a 100644 --- a/arch/mips/configs/rm200_defconfig +++ b/arch/mips/configs/rm200_defconfig @@ -137,6 +137,15 @@ CONFIG_FLATMEM=y CONFIG_FLAT_NODE_MEM_MAP=y # CONFIG_SPARSEMEM_STATIC is not set CONFIG_SPLIT_PTLOCK_CPUS=4 +# CONFIG_HZ_48 is not set +# CONFIG_HZ_100 is not set +# CONFIG_HZ_128 is not set +# CONFIG_HZ_250 is not set +# CONFIG_HZ_256 is not set +CONFIG_HZ_1000=y +# CONFIG_HZ_1024 is not set +CONFIG_SYS_SUPPORTS_ARBIT_HZ=y +CONFIG_HZ=1000 # CONFIG_PREEMPT_NONE is not set CONFIG_PREEMPT_VOLUNTARY=y # CONFIG_PREEMPT is not set diff --git a/arch/mips/configs/sb1250-swarm_defconfig b/arch/mips/configs/sb1250-swarm_defconfig index c611401..2f51758 100644 --- a/arch/mips/configs/sb1250-swarm_defconfig +++ b/arch/mips/configs/sb1250-swarm_defconfig @@ -148,6 +148,15 @@ CONFIG_FLATMEM=y CONFIG_FLAT_NODE_MEM_MAP=y # CONFIG_SPARSEMEM_STATIC is not set CONFIG_SPLIT_PTLOCK_CPUS=4 +# CONFIG_HZ_48 is not set +# CONFIG_HZ_100 is not set +# CONFIG_HZ_128 is not set +# CONFIG_HZ_250 is not set +# CONFIG_HZ_256 is not set +CONFIG_HZ_1000=y +# CONFIG_HZ_1024 is not set +CONFIG_SYS_SUPPORTS_ARBIT_HZ=y +CONFIG_HZ=1000 CONFIG_SMP=y CONFIG_NR_CPUS=2 CONFIG_PREEMPT_NONE=y diff --git a/arch/mips/configs/sead_defconfig b/arch/mips/configs/sead_defconfig index c3be587..a228934 100644 --- a/arch/mips/configs/sead_defconfig +++ b/arch/mips/configs/sead_defconfig @@ -133,6 +133,15 @@ CONFIG_FLATMEM=y CONFIG_FLAT_NODE_MEM_MAP=y # CONFIG_SPARSEMEM_STATIC is not set CONFIG_SPLIT_PTLOCK_CPUS=4 +# CONFIG_HZ_48 is not set +# CONFIG_HZ_100 is not set +# CONFIG_HZ_128 is not set +# CONFIG_HZ_250 is not set +# CONFIG_HZ_256 is not set +CONFIG_HZ_1000=y +# CONFIG_HZ_1024 is not set +CONFIG_SYS_SUPPORTS_ARBIT_HZ=y +CONFIG_HZ=1000 CONFIG_PREEMPT_NONE=y # CONFIG_PREEMPT_VOLUNTARY is not set # CONFIG_PREEMPT is not set diff --git a/arch/mips/configs/tb0226_defconfig b/arch/mips/configs/tb0226_defconfig index 2d46ccb..6574c25 100644 --- a/arch/mips/configs/tb0226_defconfig +++ b/arch/mips/configs/tb0226_defconfig @@ -133,6 +133,15 @@ CONFIG_FLATMEM=y CONFIG_FLAT_NODE_MEM_MAP=y # CONFIG_SPARSEMEM_STATIC is not set CONFIG_SPLIT_PTLOCK_CPUS=4 +# CONFIG_HZ_48 is not set +# CONFIG_HZ_100 is not set +# CONFIG_HZ_128 is not set +# CONFIG_HZ_250 is not set +# CONFIG_HZ_256 is not set +CONFIG_HZ_1000=y +# CONFIG_HZ_1024 is not set +CONFIG_SYS_SUPPORTS_ARBIT_HZ=y +CONFIG_HZ=1000 CONFIG_PREEMPT_NONE=y # CONFIG_PREEMPT_VOLUNTARY is not set # CONFIG_PREEMPT is not set diff --git a/arch/mips/configs/tb0229_defconfig b/arch/mips/configs/tb0229_defconfig index 930940e..523c8b3 100644 --- a/arch/mips/configs/tb0229_defconfig +++ b/arch/mips/configs/tb0229_defconfig @@ -133,6 +133,15 @@ CONFIG_FLATMEM=y CONFIG_FLAT_NODE_MEM_MAP=y # CONFIG_SPARSEMEM_STATIC is not set CONFIG_SPLIT_PTLOCK_CPUS=4 +# CONFIG_HZ_48 is not set +# CONFIG_HZ_100 is not set +# CONFIG_HZ_128 is not set +# CONFIG_HZ_250 is not set +# CONFIG_HZ_256 is not set +CONFIG_HZ_1000=y +# CONFIG_HZ_1024 is not set +CONFIG_SYS_SUPPORTS_ARBIT_HZ=y +CONFIG_HZ=1000 CONFIG_PREEMPT_NONE=y # CONFIG_PREEMPT_VOLUNTARY is not set # CONFIG_PREEMPT is not set diff --git a/arch/mips/configs/tb0287_defconfig b/arch/mips/configs/tb0287_defconfig index 70392d5..258457f 100644 --- a/arch/mips/configs/tb0287_defconfig +++ b/arch/mips/configs/tb0287_defconfig @@ -133,6 +133,15 @@ CONFIG_FLATMEM=y CONFIG_FLAT_NODE_MEM_MAP=y # CONFIG_SPARSEMEM_STATIC is not set CONFIG_SPLIT_PTLOCK_CPUS=4 +# CONFIG_HZ_48 is not set +# CONFIG_HZ_100 is not set +# CONFIG_HZ_128 is not set +# CONFIG_HZ_250 is not set +# CONFIG_HZ_256 is not set +CONFIG_HZ_1000=y +# CONFIG_HZ_1024 is not set +CONFIG_SYS_SUPPORTS_ARBIT_HZ=y +CONFIG_HZ=1000 CONFIG_PREEMPT_NONE=y # CONFIG_PREEMPT_VOLUNTARY is not set # CONFIG_PREEMPT is not set diff --git a/arch/mips/configs/workpad_defconfig b/arch/mips/configs/workpad_defconfig index 6376441..bc45bfa 100644 --- a/arch/mips/configs/workpad_defconfig +++ b/arch/mips/configs/workpad_defconfig @@ -129,6 +129,15 @@ CONFIG_FLATMEM=y CONFIG_FLAT_NODE_MEM_MAP=y # CONFIG_SPARSEMEM_STATIC is not set CONFIG_SPLIT_PTLOCK_CPUS=4 +# CONFIG_HZ_48 is not set +# CONFIG_HZ_100 is not set +# CONFIG_HZ_128 is not set +# CONFIG_HZ_250 is not set +# CONFIG_HZ_256 is not set +CONFIG_HZ_1000=y +# CONFIG_HZ_1024 is not set +CONFIG_SYS_SUPPORTS_ARBIT_HZ=y +CONFIG_HZ=1000 CONFIG_PREEMPT_NONE=y # CONFIG_PREEMPT_VOLUNTARY is not set # CONFIG_PREEMPT is not set diff --git a/arch/mips/configs/wrppmc_defconfig b/arch/mips/configs/wrppmc_defconfig index 8c0e636..40572a3 100644 --- a/arch/mips/configs/wrppmc_defconfig +++ b/arch/mips/configs/wrppmc_defconfig @@ -136,6 +136,15 @@ CONFIG_FLATMEM=y CONFIG_FLAT_NODE_MEM_MAP=y # CONFIG_SPARSEMEM_STATIC is not set CONFIG_SPLIT_PTLOCK_CPUS=4 +# CONFIG_HZ_48 is not set +# CONFIG_HZ_100 is not set +# CONFIG_HZ_128 is not set +# CONFIG_HZ_250 is not set +# CONFIG_HZ_256 is not set +CONFIG_HZ_1000=y +# CONFIG_HZ_1024 is not set +CONFIG_SYS_SUPPORTS_ARBIT_HZ=y +CONFIG_HZ=1000 CONFIG_PREEMPT_NONE=y # CONFIG_PREEMPT_VOLUNTARY is not set # CONFIG_PREEMPT is not set diff --git a/arch/mips/configs/yosemite_defconfig b/arch/mips/configs/yosemite_defconfig index a96a50d..8779bfa 100644 --- a/arch/mips/configs/yosemite_defconfig +++ b/arch/mips/configs/yosemite_defconfig @@ -129,6 +129,15 @@ CONFIG_FLATMEM=y CONFIG_FLAT_NODE_MEM_MAP=y # CONFIG_SPARSEMEM_STATIC is not set CONFIG_SPLIT_PTLOCK_CPUS=4 +# CONFIG_HZ_48 is not set +# CONFIG_HZ_100 is not set +# CONFIG_HZ_128 is not set +# CONFIG_HZ_250 is not set +# CONFIG_HZ_256 is not set +CONFIG_HZ_1000=y +# CONFIG_HZ_1024 is not set +CONFIG_SYS_SUPPORTS_ARBIT_HZ=y +CONFIG_HZ=1000 CONFIG_SMP=y CONFIG_NR_CPUS=2 CONFIG_PREEMPT_NONE=y diff --git a/arch/mips/dec/time.c b/arch/mips/dec/time.c index 74cb055..76e4d09 100644 --- a/arch/mips/dec/time.c +++ b/arch/mips/dec/time.c @@ -181,7 +181,7 @@ void __init dec_time_init(void) } /* Set up the rate of periodic DS1287 interrupts. */ - CMOS_WRITE(RTC_REF_CLCK_32KHZ | (16 - LOG_2_HZ), RTC_REG_A); + CMOS_WRITE(RTC_REF_CLCK_32KHZ | (16 - __ffs(HZ)), RTC_REG_A); } EXPORT_SYMBOL(do_settimeofday); diff --git a/arch/mips/defconfig b/arch/mips/defconfig index 6d03aeb..664283c 100644 --- a/arch/mips/defconfig +++ b/arch/mips/defconfig @@ -135,6 +135,15 @@ CONFIG_FLATMEM=y CONFIG_FLAT_NODE_MEM_MAP=y # CONFIG_SPARSEMEM_STATIC is not set CONFIG_SPLIT_PTLOCK_CPUS=4 +# CONFIG_HZ_48 is not set +# CONFIG_HZ_100 is not set +# CONFIG_HZ_128 is not set +# CONFIG_HZ_250 is not set +# CONFIG_HZ_256 is not set +CONFIG_HZ_1000=y +# CONFIG_HZ_1024 is not set +CONFIG_SYS_SUPPORTS_ARBIT_HZ=y +CONFIG_HZ=1000 # CONFIG_PREEMPT_NONE is not set CONFIG_PREEMPT_VOLUNTARY=y # CONFIG_PREEMPT is not set diff --git a/arch/mips/math-emu/kernel_linkage.c b/arch/mips/math-emu/kernel_linkage.c diff --git a/include/asm-mips/mach-dec/param.h b/include/asm-mips/mach-dec/param.h deleted file mode 100644 index 3e4f0e3..0000000 --- a/include/asm-mips/mach-dec/param.h +++ /dev/null @@ -1,18 +0,0 @@ -/* - * This file is subject to the terms and conditions of the GNU General Public - * License. See the file "COPYING" in the main directory of this archive - * for more details. - * - * Copyright (C) 2003 by Ralf Baechle - */ -#ifndef __ASM_MACH_DEC_PARAM_H -#define __ASM_MACH_DEC_PARAM_H - -/* - * log2(HZ), change this here if you want another HZ value. This is also - * used in dec_time_init. Minimum is 1, Maximum is 15. - */ -#define LOG_2_HZ 7 -#define HZ (1 << LOG_2_HZ) - -#endif /* __ASM_MACH_DEC_PARAM_H */ diff --git a/include/asm-mips/mach-generic/param.h b/include/asm-mips/mach-generic/param.h deleted file mode 100644 index a0d12f9..0000000 --- a/include/asm-mips/mach-generic/param.h +++ /dev/null @@ -1,13 +0,0 @@ -/* - * This file is subject to the terms and conditions of the GNU General Public - * License. See the file "COPYING" in the main directory of this archive - * for more details. - * - * Copyright (C) 2003 by Ralf Baechle - */ -#ifndef __ASM_MACH_GENERIC_PARAM_H -#define __ASM_MACH_GENERIC_PARAM_H - -#define HZ 1000 /* Internal kernel timer frequency */ - -#endif /* __ASM_MACH_GENERIC_PARAM_H */ diff --git a/include/asm-mips/mach-jazz/param.h b/include/asm-mips/mach-jazz/param.h deleted file mode 100644 index 639763a..0000000 --- a/include/asm-mips/mach-jazz/param.h +++ /dev/null @@ -1,16 +0,0 @@ -/* - * This file is subject to the terms and conditions of the GNU General Public - * License. See the file "COPYING" in the main directory of this archive - * for more details. - * - * Copyright (C) 2003 by Ralf Baechle - */ -#ifndef __ASM_MACH_JAZZ_PARAM_H -#define __ASM_MACH_JAZZ_PARAM_H - -/* - * Jazz is currently using the internal 100Hz timer of the R4030 - */ -#define HZ 100 /* Internal kernel timer frequency */ - -#endif /* __ASM_MACH_JAZZ_PARAM_H */ diff --git a/include/asm-mips/mach-mips/param.h b/include/asm-mips/mach-mips/param.h deleted file mode 100644 index 805ef6d..0000000 --- a/include/asm-mips/mach-mips/param.h +++ /dev/null @@ -1,13 +0,0 @@ -/* - * This file is subject to the terms and conditions of the GNU General Public - * License. See the file "COPYING" in the main directory of this archive - * for more details. - * - * Copyright (C) 2003 by Ralf Baechle - */ -#ifndef __ASM_MACH_MIPS_PARAM_H -#define __ASM_MACH_MIPS_PARAM_H - -#define HZ 100 /* Internal kernel timer frequency */ - -#endif /* __ASM_MACH_MIPS_PARAM_H */ diff --git a/include/asm-mips/mach-qemu/param.h b/include/asm-mips/mach-qemu/param.h deleted file mode 100644 index cb30ee4..0000000 --- a/include/asm-mips/mach-qemu/param.h +++ /dev/null @@ -1,13 +0,0 @@ -/* - * This file is subject to the terms and conditions of the GNU General Public - * License. See the file "COPYING" in the main directory of this archive - * for more details. - * - * Copyright (C) 2005 by Ralf Baechle - */ -#ifndef __ASM_MACH_QEMU_PARAM_H -#define __ASM_MACH_QEMU_PARAM_H - -#define HZ 100 /* Internal kernel timer frequency */ - -#endif /* __ASM_MACH_QEMU_PARAM_H */ diff --git a/include/asm-mips/param.h b/include/asm-mips/param.h index 2bead82..1d9bb8c 100644 --- a/include/asm-mips/param.h +++ b/include/asm-mips/param.h @@ -11,7 +11,7 @@ #ifdef __KERNEL__ -# include /* Internal kernel timer frequency */ +# define HZ CONFIG_HZ /* Internal kernel timer frequency */ # define USER_HZ 100 /* .. some user interfaces are in "ticks" */ # define CLOCKS_PER_SEC (USER_HZ) /* like times() */ #endif From anemo@mba.ocn.ne.jp Mon Jun 19 16:36:47 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 19 Jun 2006 16:37:05 +0100 (BST) Received: from mba.ocn.ne.jp ([210.190.142.172]:2552 "HELO smtp.mba.ocn.ne.jp") by ftp.linux-mips.org with SMTP id S8133524AbWFSPgq (ORCPT ); Mon, 19 Jun 2006 16:36:46 +0100 Received: from localhost (p4087-ipad28funabasi.chiba.ocn.ne.jp [220.107.203.87]) by smtp.mba.ocn.ne.jp (Postfix) with ESMTP id 08359BAB1; Tue, 20 Jun 2006 00:36:41 +0900 (JST) Date: Tue, 20 Jun 2006 00:37:46 +0900 (JST) Message-Id: <20060620.003746.78731943.anemo@mba.ocn.ne.jp> To: linux-mips@linux-mips.org Cc: ralf@linux-mips.org Subject: Re: [PATCH] rewrite restore_fp_context/save_fp_context From: Atsushi Nemoto In-Reply-To: <20060411.185449.126141341.nemoto@toshiba-tops.co.jp> References: <20060208.015250.130239257.anemo@mba.ocn.ne.jp> <20060411.185449.126141341.nemoto@toshiba-tops.co.jp> X-Fingerprint: 6ACA 1623 39BD 9A94 9B1A B746 CA77 FE94 2874 D52F X-Pgp-Public-Key: http://wwwkeys.pgp.net/pks/lookup?op=get&search=0x2874D52F X-Mailer: Mew version 3.3 on Emacs 21.4 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11770 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: anemo@mba.ocn.ne.jp Precedence: bulk X-list: linux-mips Revised for current git tree. The setup_sigcontect()/restore_sigcontext() might sleep on put_user()/get_user() with preemption disabled (i.e. atomic context). Sleeping in atomic context is not allowed. This patch fixes this problem by rewriting restore_fp_context()/save_fp_context(). A path to save fp context was: (current.thread.fpu -> ) real FPU -> sigcontext on userstack And with this patch it is: (real FPU -> ) current.thread.fpu -> sigcontext on userstack While transfer between real FPU and current.thread.fpu can be done by usual context save/restore routines, all arch/mips/kernel/*_fpu.S, SMP-variant of {save,restore}_fp_context and SC_ symbols in asm-offset.h can be removed. Signed-off-by: Atsushi Nemoto arch/mips/kernel/r2300_fpu.S | 126 ---------------------- arch/mips/kernel/r4k_fpu.S | 188 ---------------------------------- arch/mips/kernel/r6000_fpu.S | 87 --------------- b/arch/mips/kernel/Makefile | 36 +++--- b/arch/mips/kernel/asm-offsets.c | 47 -------- b/arch/mips/kernel/signal-common.h | 54 +++++++-- b/arch/mips/kernel/signal32.c | 52 +++++++-- b/arch/mips/kernel/traps.c | 76 ------------- b/arch/mips/math-emu/kernel_linkage.c | 69 ------------ b/include/asm-mips/fpu.h | 9 - 10 files changed, 100 insertions(+), 644 deletions(-) diff --git a/arch/mips/kernel/Makefile b/arch/mips/kernel/Makefile index 881c467..1da1ebb 100644 --- a/arch/mips/kernel/Makefile +++ b/arch/mips/kernel/Makefile @@ -15,24 +15,24 @@ obj-$(CONFIG_MODULES) += mips_ksyms.o m obj-$(CONFIG_APM) += apm.o -obj-$(CONFIG_CPU_R3000) += r2300_fpu.o r2300_switch.o -obj-$(CONFIG_CPU_TX39XX) += r2300_fpu.o r2300_switch.o -obj-$(CONFIG_CPU_TX49XX) += r4k_fpu.o r4k_switch.o -obj-$(CONFIG_CPU_R4000) += r4k_fpu.o r4k_switch.o -obj-$(CONFIG_CPU_VR41XX) += r4k_fpu.o r4k_switch.o -obj-$(CONFIG_CPU_R4300) += r4k_fpu.o r4k_switch.o -obj-$(CONFIG_CPU_R4X00) += r4k_fpu.o r4k_switch.o -obj-$(CONFIG_CPU_R5000) += r4k_fpu.o r4k_switch.o -obj-$(CONFIG_CPU_R5432) += r4k_fpu.o r4k_switch.o -obj-$(CONFIG_CPU_R8000) += r4k_fpu.o r4k_switch.o -obj-$(CONFIG_CPU_RM7000) += r4k_fpu.o r4k_switch.o -obj-$(CONFIG_CPU_RM9000) += r4k_fpu.o r4k_switch.o -obj-$(CONFIG_CPU_NEVADA) += r4k_fpu.o r4k_switch.o -obj-$(CONFIG_CPU_R10000) += r4k_fpu.o r4k_switch.o -obj-$(CONFIG_CPU_SB1) += r4k_fpu.o r4k_switch.o -obj-$(CONFIG_CPU_MIPS32) += r4k_fpu.o r4k_switch.o -obj-$(CONFIG_CPU_MIPS64) += r4k_fpu.o r4k_switch.o -obj-$(CONFIG_CPU_R6000) += r6000_fpu.o r4k_switch.o +obj-$(CONFIG_CPU_R3000) += r2300_switch.o +obj-$(CONFIG_CPU_TX39XX) += r2300_switch.o +obj-$(CONFIG_CPU_TX49XX) += r4k_switch.o +obj-$(CONFIG_CPU_R4000) += r4k_switch.o +obj-$(CONFIG_CPU_VR41XX) += r4k_switch.o +obj-$(CONFIG_CPU_R4300) += r4k_switch.o +obj-$(CONFIG_CPU_R4X00) += r4k_switch.o +obj-$(CONFIG_CPU_R5000) += r4k_switch.o +obj-$(CONFIG_CPU_R5432) += r4k_switch.o +obj-$(CONFIG_CPU_R8000) += r4k_switch.o +obj-$(CONFIG_CPU_RM7000) += r4k_switch.o +obj-$(CONFIG_CPU_RM9000) += r4k_switch.o +obj-$(CONFIG_CPU_NEVADA) += r4k_switch.o +obj-$(CONFIG_CPU_R10000) += r4k_switch.o +obj-$(CONFIG_CPU_SB1) += r4k_switch.o +obj-$(CONFIG_CPU_MIPS32) += r4k_switch.o +obj-$(CONFIG_CPU_MIPS64) += r4k_switch.o +obj-$(CONFIG_CPU_R6000) += r4k_switch.o obj-$(CONFIG_SMP) += smp.o diff --git a/arch/mips/kernel/asm-offsets.c b/arch/mips/kernel/asm-offsets.c index f1bb6a2..c1762ea 100644 --- a/arch/mips/kernel/asm-offsets.c +++ b/arch/mips/kernel/asm-offsets.c @@ -244,53 +244,6 @@ void output_mm_defines(void) linefeed; } -#ifdef CONFIG_32BIT -void output_sc_defines(void) -{ - text("/* Linux sigcontext offsets. */"); - offset("#define SC_REGS ", struct sigcontext, sc_regs); - offset("#define SC_FPREGS ", struct sigcontext, sc_fpregs); - offset("#define SC_MDHI ", struct sigcontext, sc_mdhi); - offset("#define SC_MDLO ", struct sigcontext, sc_mdlo); - offset("#define SC_PC ", struct sigcontext, sc_pc); - offset("#define SC_STATUS ", struct sigcontext, sc_status); - offset("#define SC_FPC_CSR ", struct sigcontext, sc_fpc_csr); - offset("#define SC_FPC_EIR ", struct sigcontext, sc_fpc_eir); - offset("#define SC_HI1 ", struct sigcontext, sc_hi1); - offset("#define SC_LO1 ", struct sigcontext, sc_lo1); - offset("#define SC_HI2 ", struct sigcontext, sc_hi2); - offset("#define SC_LO2 ", struct sigcontext, sc_lo2); - offset("#define SC_HI3 ", struct sigcontext, sc_hi3); - offset("#define SC_LO3 ", struct sigcontext, sc_lo3); - linefeed; -} -#endif - -#ifdef CONFIG_64BIT -void output_sc_defines(void) -{ - text("/* Linux sigcontext offsets. */"); - offset("#define SC_REGS ", struct sigcontext, sc_regs); - offset("#define SC_FPREGS ", struct sigcontext, sc_fpregs); - offset("#define SC_MDHI ", struct sigcontext, sc_mdhi); - offset("#define SC_MDLO ", struct sigcontext, sc_mdlo); - offset("#define SC_PC ", struct sigcontext, sc_pc); - offset("#define SC_FPC_CSR ", struct sigcontext, sc_fpc_csr); - linefeed; -} -#endif - -#ifdef CONFIG_MIPS32_COMPAT -void output_sc32_defines(void) -{ - text("/* Linux 32-bit sigcontext offsets. */"); - offset("#define SC32_FPREGS ", struct sigcontext32, sc_fpregs); - offset("#define SC32_FPC_CSR ", struct sigcontext32, sc_fpc_csr); - offset("#define SC32_FPC_EIR ", struct sigcontext32, sc_fpc_eir); - linefeed; -} -#endif - void output_signal_defined(void) { text("/* Linux signal numbers. */"); diff --git a/arch/mips/kernel/r2300_fpu.S b/arch/mips/kernel/r2300_fpu.S deleted file mode 100644 index ac68e68..0000000 --- a/arch/mips/kernel/r2300_fpu.S +++ /dev/null @@ -1,126 +0,0 @@ -/* - * This file is subject to the terms and conditions of the GNU General Public - * License. See the file "COPYING" in the main directory of this archive - * for more details. - * - * Copyright (C) 1996, 1998 by Ralf Baechle - * - * Multi-arch abstraction and asm macros for easier reading: - * Copyright (C) 1996 David S. Miller (dm@engr.sgi.com) - * - * Further modifications to make this work: - * Copyright (c) 1998 Harald Koerfgen - */ -#include -#include -#include -#include -#include -#include - -#define EX(a,b) \ -9: a,##b; \ - .section __ex_table,"a"; \ - PTR 9b,bad_stack; \ - .previous - - .set noreorder - .set mips1 - /* Save floating point context */ -LEAF(_save_fp_context) - li v0, 0 # assume success - cfc1 t1,fcr31 - EX(swc1 $f0,(SC_FPREGS+0)(a0)) - EX(swc1 $f1,(SC_FPREGS+8)(a0)) - EX(swc1 $f2,(SC_FPREGS+16)(a0)) - EX(swc1 $f3,(SC_FPREGS+24)(a0)) - EX(swc1 $f4,(SC_FPREGS+32)(a0)) - EX(swc1 $f5,(SC_FPREGS+40)(a0)) - EX(swc1 $f6,(SC_FPREGS+48)(a0)) - EX(swc1 $f7,(SC_FPREGS+56)(a0)) - EX(swc1 $f8,(SC_FPREGS+64)(a0)) - EX(swc1 $f9,(SC_FPREGS+72)(a0)) - EX(swc1 $f10,(SC_FPREGS+80)(a0)) - EX(swc1 $f11,(SC_FPREGS+88)(a0)) - EX(swc1 $f12,(SC_FPREGS+96)(a0)) - EX(swc1 $f13,(SC_FPREGS+104)(a0)) - EX(swc1 $f14,(SC_FPREGS+112)(a0)) - EX(swc1 $f15,(SC_FPREGS+120)(a0)) - EX(swc1 $f16,(SC_FPREGS+128)(a0)) - EX(swc1 $f17,(SC_FPREGS+136)(a0)) - EX(swc1 $f18,(SC_FPREGS+144)(a0)) - EX(swc1 $f19,(SC_FPREGS+152)(a0)) - EX(swc1 $f20,(SC_FPREGS+160)(a0)) - EX(swc1 $f21,(SC_FPREGS+168)(a0)) - EX(swc1 $f22,(SC_FPREGS+176)(a0)) - EX(swc1 $f23,(SC_FPREGS+184)(a0)) - EX(swc1 $f24,(SC_FPREGS+192)(a0)) - EX(swc1 $f25,(SC_FPREGS+200)(a0)) - EX(swc1 $f26,(SC_FPREGS+208)(a0)) - EX(swc1 $f27,(SC_FPREGS+216)(a0)) - EX(swc1 $f28,(SC_FPREGS+224)(a0)) - EX(swc1 $f29,(SC_FPREGS+232)(a0)) - EX(swc1 $f30,(SC_FPREGS+240)(a0)) - EX(swc1 $f31,(SC_FPREGS+248)(a0)) - EX(sw t1,(SC_FPC_CSR)(a0)) - cfc1 t0,$0 # implementation/version - jr ra - .set nomacro - EX(sw t0,(SC_FPC_EIR)(a0)) - .set macro - END(_save_fp_context) - -/* - * Restore FPU state: - * - fp gp registers - * - cp1 status/control register - * - * We base the decision which registers to restore from the signal stack - * frame on the current content of c0_status, not on the content of the - * stack frame which might have been changed by the user. - */ -LEAF(_restore_fp_context) - li v0, 0 # assume success - EX(lw t0,(SC_FPC_CSR)(a0)) - EX(lwc1 $f0,(SC_FPREGS+0)(a0)) - EX(lwc1 $f1,(SC_FPREGS+8)(a0)) - EX(lwc1 $f2,(SC_FPREGS+16)(a0)) - EX(lwc1 $f3,(SC_FPREGS+24)(a0)) - EX(lwc1 $f4,(SC_FPREGS+32)(a0)) - EX(lwc1 $f5,(SC_FPREGS+40)(a0)) - EX(lwc1 $f6,(SC_FPREGS+48)(a0)) - EX(lwc1 $f7,(SC_FPREGS+56)(a0)) - EX(lwc1 $f8,(SC_FPREGS+64)(a0)) - EX(lwc1 $f9,(SC_FPREGS+72)(a0)) - EX(lwc1 $f10,(SC_FPREGS+80)(a0)) - EX(lwc1 $f11,(SC_FPREGS+88)(a0)) - EX(lwc1 $f12,(SC_FPREGS+96)(a0)) - EX(lwc1 $f13,(SC_FPREGS+104)(a0)) - EX(lwc1 $f14,(SC_FPREGS+112)(a0)) - EX(lwc1 $f15,(SC_FPREGS+120)(a0)) - EX(lwc1 $f16,(SC_FPREGS+128)(a0)) - EX(lwc1 $f17,(SC_FPREGS+136)(a0)) - EX(lwc1 $f18,(SC_FPREGS+144)(a0)) - EX(lwc1 $f19,(SC_FPREGS+152)(a0)) - EX(lwc1 $f20,(SC_FPREGS+160)(a0)) - EX(lwc1 $f21,(SC_FPREGS+168)(a0)) - EX(lwc1 $f22,(SC_FPREGS+176)(a0)) - EX(lwc1 $f23,(SC_FPREGS+184)(a0)) - EX(lwc1 $f24,(SC_FPREGS+192)(a0)) - EX(lwc1 $f25,(SC_FPREGS+200)(a0)) - EX(lwc1 $f26,(SC_FPREGS+208)(a0)) - EX(lwc1 $f27,(SC_FPREGS+216)(a0)) - EX(lwc1 $f28,(SC_FPREGS+224)(a0)) - EX(lwc1 $f29,(SC_FPREGS+232)(a0)) - EX(lwc1 $f30,(SC_FPREGS+240)(a0)) - EX(lwc1 $f31,(SC_FPREGS+248)(a0)) - jr ra - ctc1 t0,fcr31 - END(_restore_fp_context) - .set reorder - - .type fault@function - .ent fault -fault: li v0, -EFAULT - jr ra - .end fault diff --git a/arch/mips/kernel/r4k_fpu.S b/arch/mips/kernel/r4k_fpu.S deleted file mode 100644 index 283a985..0000000 --- a/arch/mips/kernel/r4k_fpu.S +++ /dev/null @@ -1,188 +0,0 @@ -/* - * This file is subject to the terms and conditions of the GNU General Public - * License. See the file "COPYING" in the main directory of this archive - * for more details. - * - * Copyright (C) 1996, 98, 99, 2000, 01 Ralf Baechle - * - * Multi-arch abstraction and asm macros for easier reading: - * Copyright (C) 1996 David S. Miller (dm@engr.sgi.com) - * - * Carsten Langgaard, carstenl@mips.com - * Copyright (C) 2000 MIPS Technologies, Inc. - * Copyright (C) 1999, 2001 Silicon Graphics, Inc. - */ -#include -#include -#include -#include -#include -#include -#include - - .macro EX insn, reg, src - .set push - .set nomacro -.ex\@: \insn \reg, \src - .set pop - .section __ex_table,"a" - PTR .ex\@, fault - .previous - .endm - - .set noreorder - .set mips3 - -LEAF(_save_fp_context) - cfc1 t1, fcr31 - -#ifdef CONFIG_64BIT - /* Store the 16 odd double precision registers */ - EX sdc1 $f1, SC_FPREGS+8(a0) - EX sdc1 $f3, SC_FPREGS+24(a0) - EX sdc1 $f5, SC_FPREGS+40(a0) - EX sdc1 $f7, SC_FPREGS+56(a0) - EX sdc1 $f9, SC_FPREGS+72(a0) - EX sdc1 $f11, SC_FPREGS+88(a0) - EX sdc1 $f13, SC_FPREGS+104(a0) - EX sdc1 $f15, SC_FPREGS+120(a0) - EX sdc1 $f17, SC_FPREGS+136(a0) - EX sdc1 $f19, SC_FPREGS+152(a0) - EX sdc1 $f21, SC_FPREGS+168(a0) - EX sdc1 $f23, SC_FPREGS+184(a0) - EX sdc1 $f25, SC_FPREGS+200(a0) - EX sdc1 $f27, SC_FPREGS+216(a0) - EX sdc1 $f29, SC_FPREGS+232(a0) - EX sdc1 $f31, SC_FPREGS+248(a0) -#endif - - /* Store the 16 even double precision registers */ - EX sdc1 $f0, SC_FPREGS+0(a0) - EX sdc1 $f2, SC_FPREGS+16(a0) - EX sdc1 $f4, SC_FPREGS+32(a0) - EX sdc1 $f6, SC_FPREGS+48(a0) - EX sdc1 $f8, SC_FPREGS+64(a0) - EX sdc1 $f10, SC_FPREGS+80(a0) - EX sdc1 $f12, SC_FPREGS+96(a0) - EX sdc1 $f14, SC_FPREGS+112(a0) - EX sdc1 $f16, SC_FPREGS+128(a0) - EX sdc1 $f18, SC_FPREGS+144(a0) - EX sdc1 $f20, SC_FPREGS+160(a0) - EX sdc1 $f22, SC_FPREGS+176(a0) - EX sdc1 $f24, SC_FPREGS+192(a0) - EX sdc1 $f26, SC_FPREGS+208(a0) - EX sdc1 $f28, SC_FPREGS+224(a0) - EX sdc1 $f30, SC_FPREGS+240(a0) - EX sw t1, SC_FPC_CSR(a0) - jr ra - li v0, 0 # success - END(_save_fp_context) - -#ifdef CONFIG_MIPS32_COMPAT - /* Save 32-bit process floating point context */ -LEAF(_save_fp_context32) - cfc1 t1, fcr31 - - EX sdc1 $f0, SC32_FPREGS+0(a0) - EX sdc1 $f2, SC32_FPREGS+16(a0) - EX sdc1 $f4, SC32_FPREGS+32(a0) - EX sdc1 $f6, SC32_FPREGS+48(a0) - EX sdc1 $f8, SC32_FPREGS+64(a0) - EX sdc1 $f10, SC32_FPREGS+80(a0) - EX sdc1 $f12, SC32_FPREGS+96(a0) - EX sdc1 $f14, SC32_FPREGS+112(a0) - EX sdc1 $f16, SC32_FPREGS+128(a0) - EX sdc1 $f18, SC32_FPREGS+144(a0) - EX sdc1 $f20, SC32_FPREGS+160(a0) - EX sdc1 $f22, SC32_FPREGS+176(a0) - EX sdc1 $f24, SC32_FPREGS+192(a0) - EX sdc1 $f26, SC32_FPREGS+208(a0) - EX sdc1 $f28, SC32_FPREGS+224(a0) - EX sdc1 $f30, SC32_FPREGS+240(a0) - EX sw t1, SC32_FPC_CSR(a0) - cfc1 t0, $0 # implementation/version - EX sw t0, SC32_FPC_EIR(a0) - - jr ra - li v0, 0 # success - END(_save_fp_context32) -#endif - -/* - * Restore FPU state: - * - fp gp registers - * - cp1 status/control register - */ -LEAF(_restore_fp_context) - EX lw t0, SC_FPC_CSR(a0) -#ifdef CONFIG_64BIT - EX ldc1 $f1, SC_FPREGS+8(a0) - EX ldc1 $f3, SC_FPREGS+24(a0) - EX ldc1 $f5, SC_FPREGS+40(a0) - EX ldc1 $f7, SC_FPREGS+56(a0) - EX ldc1 $f9, SC_FPREGS+72(a0) - EX ldc1 $f11, SC_FPREGS+88(a0) - EX ldc1 $f13, SC_FPREGS+104(a0) - EX ldc1 $f15, SC_FPREGS+120(a0) - EX ldc1 $f17, SC_FPREGS+136(a0) - EX ldc1 $f19, SC_FPREGS+152(a0) - EX ldc1 $f21, SC_FPREGS+168(a0) - EX ldc1 $f23, SC_FPREGS+184(a0) - EX ldc1 $f25, SC_FPREGS+200(a0) - EX ldc1 $f27, SC_FPREGS+216(a0) - EX ldc1 $f29, SC_FPREGS+232(a0) - EX ldc1 $f31, SC_FPREGS+248(a0) -#endif - EX ldc1 $f0, SC_FPREGS+0(a0) - EX ldc1 $f2, SC_FPREGS+16(a0) - EX ldc1 $f4, SC_FPREGS+32(a0) - EX ldc1 $f6, SC_FPREGS+48(a0) - EX ldc1 $f8, SC_FPREGS+64(a0) - EX ldc1 $f10, SC_FPREGS+80(a0) - EX ldc1 $f12, SC_FPREGS+96(a0) - EX ldc1 $f14, SC_FPREGS+112(a0) - EX ldc1 $f16, SC_FPREGS+128(a0) - EX ldc1 $f18, SC_FPREGS+144(a0) - EX ldc1 $f20, SC_FPREGS+160(a0) - EX ldc1 $f22, SC_FPREGS+176(a0) - EX ldc1 $f24, SC_FPREGS+192(a0) - EX ldc1 $f26, SC_FPREGS+208(a0) - EX ldc1 $f28, SC_FPREGS+224(a0) - EX ldc1 $f30, SC_FPREGS+240(a0) - ctc1 t0, fcr31 - jr ra - li v0, 0 # success - END(_restore_fp_context) - -#ifdef CONFIG_MIPS32_COMPAT -LEAF(_restore_fp_context32) - /* Restore an o32 sigcontext. */ - EX lw t0, SC32_FPC_CSR(a0) - EX ldc1 $f0, SC32_FPREGS+0(a0) - EX ldc1 $f2, SC32_FPREGS+16(a0) - EX ldc1 $f4, SC32_FPREGS+32(a0) - EX ldc1 $f6, SC32_FPREGS+48(a0) - EX ldc1 $f8, SC32_FPREGS+64(a0) - EX ldc1 $f10, SC32_FPREGS+80(a0) - EX ldc1 $f12, SC32_FPREGS+96(a0) - EX ldc1 $f14, SC32_FPREGS+112(a0) - EX ldc1 $f16, SC32_FPREGS+128(a0) - EX ldc1 $f18, SC32_FPREGS+144(a0) - EX ldc1 $f20, SC32_FPREGS+160(a0) - EX ldc1 $f22, SC32_FPREGS+176(a0) - EX ldc1 $f24, SC32_FPREGS+192(a0) - EX ldc1 $f26, SC32_FPREGS+208(a0) - EX ldc1 $f28, SC32_FPREGS+224(a0) - EX ldc1 $f30, SC32_FPREGS+240(a0) - ctc1 t0, fcr31 - jr ra - li v0, 0 # success - END(_restore_fp_context32) - .set reorder -#endif - - .type fault@function - .ent fault -fault: li v0, -EFAULT # failure - jr ra - .end fault diff --git a/arch/mips/kernel/r6000_fpu.S b/arch/mips/kernel/r6000_fpu.S deleted file mode 100644 index 43cda53..0000000 --- a/arch/mips/kernel/r6000_fpu.S +++ /dev/null @@ -1,87 +0,0 @@ -/* - * r6000_fpu.S: Save/restore floating point context for signal handlers. - * - * This file is subject to the terms and conditions of the GNU General Public - * License. See the file "COPYING" in the main directory of this archive - * for more details. - * - * Copyright (C) 1996 by Ralf Baechle - * - * Multi-arch abstraction and asm macros for easier reading: - * Copyright (C) 1996 David S. Miller (dm@engr.sgi.com) - */ -#include -#include -#include -#include -#include - - .set noreorder - .set mips2 - /* Save floating point context */ - LEAF(_save_fp_context) - mfc0 t0,CP0_STATUS - sll t0,t0,2 - bgez t0,1f - nop - - cfc1 t1,fcr31 - /* Store the 16 double precision registers */ - sdc1 $f0,(SC_FPREGS+0)(a0) - sdc1 $f2,(SC_FPREGS+16)(a0) - sdc1 $f4,(SC_FPREGS+32)(a0) - sdc1 $f6,(SC_FPREGS+48)(a0) - sdc1 $f8,(SC_FPREGS+64)(a0) - sdc1 $f10,(SC_FPREGS+80)(a0) - sdc1 $f12,(SC_FPREGS+96)(a0) - sdc1 $f14,(SC_FPREGS+112)(a0) - sdc1 $f16,(SC_FPREGS+128)(a0) - sdc1 $f18,(SC_FPREGS+144)(a0) - sdc1 $f20,(SC_FPREGS+160)(a0) - sdc1 $f22,(SC_FPREGS+176)(a0) - sdc1 $f24,(SC_FPREGS+192)(a0) - sdc1 $f26,(SC_FPREGS+208)(a0) - sdc1 $f28,(SC_FPREGS+224)(a0) - sdc1 $f30,(SC_FPREGS+240)(a0) - jr ra - sw t0,SC_FPC_CSR(a0) -1: jr ra - nop - END(_save_fp_context) - -/* Restore FPU state: - * - fp gp registers - * - cp1 status/control register - * - * We base the decision which registers to restore from the signal stack - * frame on the current content of c0_status, not on the content of the - * stack frame which might have been changed by the user. - */ - LEAF(_restore_fp_context) - mfc0 t0,CP0_STATUS - sll t0,t0,2 - - bgez t0,1f - lw t0,SC_FPC_CSR(a0) - /* Restore the 16 double precision registers */ - ldc1 $f0,(SC_FPREGS+0)(a0) - ldc1 $f2,(SC_FPREGS+16)(a0) - ldc1 $f4,(SC_FPREGS+32)(a0) - ldc1 $f6,(SC_FPREGS+48)(a0) - ldc1 $f8,(SC_FPREGS+64)(a0) - ldc1 $f10,(SC_FPREGS+80)(a0) - ldc1 $f12,(SC_FPREGS+96)(a0) - ldc1 $f14,(SC_FPREGS+112)(a0) - ldc1 $f16,(SC_FPREGS+128)(a0) - ldc1 $f18,(SC_FPREGS+144)(a0) - ldc1 $f20,(SC_FPREGS+160)(a0) - ldc1 $f22,(SC_FPREGS+176)(a0) - ldc1 $f24,(SC_FPREGS+192)(a0) - ldc1 $f26,(SC_FPREGS+208)(a0) - ldc1 $f28,(SC_FPREGS+224)(a0) - ldc1 $f30,(SC_FPREGS+240)(a0) - jr ra - ctc1 t0,fcr31 -1: jr ra - nop - END(_restore_fp_context) diff --git a/arch/mips/kernel/signal-common.h b/arch/mips/kernel/signal-common.h index ce6cb91..78e1fe3 100644 --- a/arch/mips/kernel/signal-common.h +++ b/arch/mips/kernel/signal-common.h @@ -10,6 +10,40 @@ #include +/* + * Emulator context save/restore to/from a signal context + * presumed to be on the user stack, and therefore accessed + * with appropriate macros from uaccess.h + */ + +static inline int save_fp_context(struct sigcontext __user *sc) +{ + int i; + int err = 0; + + for (i = 0; i < 32; i++) { + err |= + __put_user(current->thread.fpu.fpr[i], &sc->sc_fpregs[i]); + } + err |= __put_user(current->thread.fpu.fcr31, &sc->sc_fpc_csr); + + return err; +} + +static inline int restore_fp_context(struct sigcontext __user *sc) +{ + int i; + int err = 0; + + for (i = 0; i < 32; i++) { + err |= + __get_user(current->thread.fpu.fpr[i], &sc->sc_fpregs[i]); + } + err |= __get_user(current->thread.fpu.fcr31, &sc->sc_fpc_csr); + + return err; +} + static inline int setup_sigcontext(struct pt_regs *regs, struct sigcontext __user *sc) { @@ -53,15 +87,14 @@ setup_sigcontext(struct pt_regs *regs, s * current FPU state. */ preempt_disable(); - - if (!is_fpu_owner()) { - own_fpu(); - restore_fp(current); + if (is_fpu_owner()) { + /* save current context to task_struct */ + save_fp(current); + lose_fpu(); } - err |= save_fp_context(sc); - preempt_enable(); + err |= save_fp_context(sc); out: return err; } @@ -108,19 +141,16 @@ restore_sigcontext(struct pt_regs *regs, err |= __get_user(used_math, &sc->sc_used_math); conditional_used_math(used_math); + /* signal handler may have used FPU. Give it up. */ preempt_disable(); + lose_fpu(); + preempt_enable(); if (used_math()) { /* restore fpu context if we have used it before */ - own_fpu(); err |= restore_fp_context(sc); - } else { - /* signal handler may have used FPU. Give it up. */ - lose_fpu(); } - preempt_enable(); - return err; } diff --git a/arch/mips/kernel/signal32.c b/arch/mips/kernel/signal32.c index f32a229..409ea50 100644 --- a/arch/mips/kernel/signal32.c +++ b/arch/mips/kernel/signal32.c @@ -326,6 +326,38 @@ asmlinkage int sys32_sigaltstack(nabi_no return ret; } +/* + * This is the o32 version + */ + +static inline int save_fp_context32(struct sigcontext32 __user *sc) +{ + int i; + int err = 0; + + for (i = 0; i < 32; i+=2) { + err |= + __put_user(current->thread.fpu.fpr[i], &sc->sc_fpregs[i]); + } + err |= __put_user(current->thread.fpu.fcr31, &sc->sc_fpc_csr); + + return err; +} + +static inline int restore_fp_context32(struct sigcontext32 __user *sc) +{ + int i; + int err = 0; + + for (i = 0; i < 32; i+=2) { + err |= + __get_user(current->thread.fpu.fpr[i], &sc->sc_fpregs[i]); + } + err |= __get_user(current->thread.fpu.fcr31, &sc->sc_fpc_csr); + + return err; +} + static int restore_sigcontext32(struct pt_regs *regs, struct sigcontext32 __user *sc) { u32 used_math; @@ -367,19 +399,16 @@ static int restore_sigcontext32(struct p err |= __get_user(used_math, &sc->sc_used_math); conditional_used_math(used_math); + /* signal handler may have used FPU. Give it up. */ preempt_disable(); + lose_fpu(); + preempt_enable(); if (used_math()) { /* restore fpu context if we have used it before */ - own_fpu(); err |= restore_fp_context32(sc); - } else { - /* signal handler may have used FPU. Give it up. */ - lose_fpu(); } - preempt_enable(); - return err; } @@ -598,15 +627,14 @@ static inline int setup_sigcontext32(str * current FPU state. */ preempt_disable(); - - if (!is_fpu_owner()) { - own_fpu(); - restore_fp(current); + if (is_fpu_owner()) { + /* save current context to task_struct */ + save_fp(current); + lose_fpu(); } - err |= save_fp_context32(sc); - preempt_enable(); + err |= save_fp_context32(sc); out: return err; } diff --git a/arch/mips/kernel/traps.c b/arch/mips/kernel/traps.c index 6797193..532125f 100644 --- a/arch/mips/kernel/traps.c +++ b/arch/mips/kernel/traps.c @@ -1205,77 +1205,6 @@ static inline void mips_srs_init(void) #endif /* CONFIG_CPU_MIPSR2_SRS */ -/* - * This is used by native signal handling - */ -asmlinkage int (*save_fp_context)(struct sigcontext *sc); -asmlinkage int (*restore_fp_context)(struct sigcontext *sc); - -extern asmlinkage int _save_fp_context(struct sigcontext *sc); -extern asmlinkage int _restore_fp_context(struct sigcontext *sc); - -extern asmlinkage int fpu_emulator_save_context(struct sigcontext *sc); -extern asmlinkage int fpu_emulator_restore_context(struct sigcontext *sc); - -#ifdef CONFIG_SMP -static int smp_save_fp_context(struct sigcontext *sc) -{ - return cpu_has_fpu - ? _save_fp_context(sc) - : fpu_emulator_save_context(sc); -} - -static int smp_restore_fp_context(struct sigcontext *sc) -{ - return cpu_has_fpu - ? _restore_fp_context(sc) - : fpu_emulator_restore_context(sc); -} -#endif - -static inline void signal_init(void) -{ -#ifdef CONFIG_SMP - /* For now just do the cpu_has_fpu check when the functions are invoked */ - save_fp_context = smp_save_fp_context; - restore_fp_context = smp_restore_fp_context; -#else - if (cpu_has_fpu) { - save_fp_context = _save_fp_context; - restore_fp_context = _restore_fp_context; - } else { - save_fp_context = fpu_emulator_save_context; - restore_fp_context = fpu_emulator_restore_context; - } -#endif -} - -#ifdef CONFIG_MIPS32_COMPAT - -/* - * This is used by 32-bit signal stuff on the 64-bit kernel - */ -asmlinkage int (*save_fp_context32)(struct sigcontext32 *sc); -asmlinkage int (*restore_fp_context32)(struct sigcontext32 *sc); - -extern asmlinkage int _save_fp_context32(struct sigcontext32 *sc); -extern asmlinkage int _restore_fp_context32(struct sigcontext32 *sc); - -extern asmlinkage int fpu_emulator_save_context32(struct sigcontext32 *sc); -extern asmlinkage int fpu_emulator_restore_context32(struct sigcontext32 *sc); - -static inline void signal32_init(void) -{ - if (cpu_has_fpu) { - save_fp_context32 = _save_fp_context32; - restore_fp_context32 = _restore_fp_context32; - } else { - save_fp_context32 = fpu_emulator_save_context32; - restore_fp_context32 = fpu_emulator_restore_context32; - } -} -#endif - extern void cpu_cache_init(void); extern void tlb_init(void); extern void flush_tlb_handlers(void); @@ -1506,11 +1435,6 @@ void __init trap_init(void) else memcpy((void *)(CAC_BASE + 0x080), &except_vec3_generic, 0x80); - signal_init(); -#ifdef CONFIG_MIPS32_COMPAT - signal32_init(); -#endif - flush_icache_range(ebase, ebase + 0x400); flush_tlb_handlers(); } diff --git a/arch/mips/math-emu/kernel_linkage.c b/arch/mips/math-emu/kernel_linkage.c index 56ca0c6..685735e 100644 --- a/arch/mips/math-emu/kernel_linkage.c +++ b/arch/mips/math-emu/kernel_linkage.c @@ -44,72 +44,3 @@ void fpu_emulator_init_fpu(void) current->thread.fpu.fpr[i] = SIGNALLING_NAN; } } - - -/* - * Emulator context save/restore to/from a signal context - * presumed to be on the user stack, and therefore accessed - * with appropriate macros from uaccess.h - */ - -int fpu_emulator_save_context(struct sigcontext *sc) -{ - int i; - int err = 0; - - for (i = 0; i < 32; i++) { - err |= - __put_user(current->thread.fpu.fpr[i], &sc->sc_fpregs[i]); - } - err |= __put_user(current->thread.fpu.fcr31, &sc->sc_fpc_csr); - - return err; -} - -int fpu_emulator_restore_context(struct sigcontext *sc) -{ - int i; - int err = 0; - - for (i = 0; i < 32; i++) { - err |= - __get_user(current->thread.fpu.fpr[i], &sc->sc_fpregs[i]); - } - err |= __get_user(current->thread.fpu.fcr31, &sc->sc_fpc_csr); - - return err; -} - -#ifdef CONFIG_64BIT -/* - * This is the o32 version - */ - -int fpu_emulator_save_context32(struct sigcontext32 *sc) -{ - int i; - int err = 0; - - for (i = 0; i < 32; i+=2) { - err |= - __put_user(current->thread.fpu.fpr[i], &sc->sc_fpregs[i]); - } - err |= __put_user(current->thread.fpu.fcr31, &sc->sc_fpc_csr); - - return err; -} - -int fpu_emulator_restore_context32(struct sigcontext32 *sc) -{ - int i; - int err = 0; - - for (i = 0; i < 32; i+=2) { - err |= - __get_user(current->thread.fpu.fpr[i], &sc->sc_fpregs[i]); - } - err |= __get_user(current->thread.fpu.fcr31, &sc->sc_fpc_csr); - - return err; -} -#endif diff --git a/include/asm-mips/fpu.h b/include/asm-mips/fpu.h index 8bf510a..b0187a9 100644 --- a/include/asm-mips/fpu.h +++ b/include/asm-mips/fpu.h @@ -25,15 +25,6 @@ #include #endif -struct sigcontext; -struct sigcontext32; - -extern asmlinkage int (*save_fp_context)(struct sigcontext *sc); -extern asmlinkage int (*restore_fp_context)(struct sigcontext *sc); - -extern asmlinkage int (*save_fp_context32)(struct sigcontext32 *sc); -extern asmlinkage int (*restore_fp_context32)(struct sigcontext32 *sc); - extern void fpu_emulator_init_fpu(void); extern void _init_fpu(void); extern void _save_fp(struct task_struct *); From ralf@linux-mips.org Mon Jun 19 16:50:04 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 19 Jun 2006 16:50:14 +0100 (BST) Received: from localhost.localdomain ([127.0.0.1]:59847 "EHLO bacchus.dhis.org") by ftp.linux-mips.org with ESMTP id S8133555AbWFSPuE (ORCPT ); Mon, 19 Jun 2006 16:50:04 +0100 Received: from denk.linux-mips.net (denk.linux-mips.net [127.0.0.1]) by bacchus.dhis.org (8.13.6/8.13.4) with ESMTP id k5JFo2we014004; Mon, 19 Jun 2006 16:50:02 +0100 Received: (from ralf@localhost) by denk.linux-mips.net (8.13.6/8.13.6/Submit) id k5JFo140013977; Mon, 19 Jun 2006 16:50:01 +0100 Date: Mon, 19 Jun 2006 16:50:01 +0100 From: Ralf Baechle To: Yoichi Yuasa Cc: linux-mips@linux-mips.org Subject: Re: Merge window ... Message-ID: <20060619155001.GA12123@linux-mips.org> References: <20060619103653.GA4257@linux-mips.org> <20060620000346.2b704b9b.yoichi_yuasa@tripeaks.co.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060620000346.2b704b9b.yoichi_yuasa@tripeaks.co.jp> User-Agent: Mutt/1.4.2.1i Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11771 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ralf@linux-mips.org Precedence: bulk X-list: linux-mips On Tue, Jun 20, 2006 at 12:03:46AM +0900, Yoichi Yuasa wrote: > > 4G Systems MTX-1 > AMD Alchemy Bosporus > AMD Alchemy Mirage > Jazz family > Toshiba TBTX49[23]7 > > These boards are candidate for removal. > If there are none objection, we can add to feature-removal-schedule.txt. A little too much. Malta for example works and I'm running top of tree. Jazz is happy, SNI was doing ok and received a major upgrade just on the weekend and the Broadcom stuff - aside of slight bitrot is crucially important for many projects as the provider of horsepower for native builds. My candidates for nuking are marked with a big red box in the wiki in the hope somebody will fix the code: http://www.linux-mips.org/wiki/Category:Deprecated Many eval boards tend to have a short livespan unlike vintage workstation and server hardware, so I tend to be trigger happier for eval board type of stuff. Ralf From karsten@excalibur.cologne.de Mon Jun 19 17:37:10 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 19 Jun 2006 17:37:19 +0100 (BST) Received: from natreg.rzone.de ([81.169.145.183]:40861 "EHLO natreg.rzone.de") by ftp.linux-mips.org with ESMTP id S8133525AbWFSQhK (ORCPT ); Mon, 19 Jun 2006 17:37:10 +0100 Received: from excalibur.cologne.de (cable-84-44-248-98.netcologne.de [84.44.248.98]) by post.webmailer.de (8.13.6/8.13.6) with ESMTP id k5JGat03027671 for ; Mon, 19 Jun 2006 18:36:55 +0200 (MEST) Received: from karsten by excalibur.cologne.de with local (Exim 3.36 #1 (Debian)) id 1FsMk8-0001FN-00 for ; Mon, 19 Jun 2006 18:36:52 +0200 Date: Mon, 19 Jun 2006 18:36:52 +0200 From: Karsten Merker To: linux-mips@linux-mips.org Subject: Re: Merge window ... Message-ID: <20060619163652.GA4219@excalibur.cologne.de> References: <20060619103653.GA4257@linux-mips.org> <20060620000346.2b704b9b.yoichi_yuasa@tripeaks.co.jp> <20060619155001.GA12123@linux-mips.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060619155001.GA12123@linux-mips.org> X-No-Archive: yes User-Agent: Mutt/1.5.9i Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11772 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: karsten@excalibur.cologne.de Precedence: bulk X-list: linux-mips On Mon, Jun 19, 2006 at 04:50:01PM +0100, Ralf Baechle wrote: > On Tue, Jun 20, 2006 at 12:03:46AM +0900, Yoichi Yuasa wrote: [board list] > > These boards are candidate for removal. > > If there are none objection, we can add to feature-removal-schedule.txt. > > A little too much. Malta for example works and I'm running top of tree. > Jazz is happy, SNI was doing ok and received a major upgrade just on > the weekend and the Broadcom stuff - aside of slight bitrot is crucially > important for many projects as the provider of horsepower for native > builds. Indeed - if you kick out the Broadcom Swarm support, you would effectively kill the Debian/mips(el) build farm, which relies heavily on this type of system. Regards, Karsten -- #include Nach Paragraph 28 Abs. 3 Bundesdatenschutzgesetz widerspreche ich der Nutzung oder Uebermittlung meiner Daten fuer Werbezwecke oder fuer die Markt- oder Meinungsforschung. From ppopov@embeddedalley.com Mon Jun 19 17:46:12 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 19 Jun 2006 17:46:22 +0100 (BST) Received: from adsl-71-128-175-242.dsl.pltn13.pacbell.net ([71.128.175.242]:16327 "EHLO build.embeddedalley.com") by ftp.linux-mips.org with ESMTP id S8133657AbWFSQqM (ORCPT ); Mon, 19 Jun 2006 17:46:12 +0100 Received: from localhost.localdomain (build.embeddedalley.com [127.0.0.1]) by build.embeddedalley.com (8.13.1/8.13.1) with ESMTP id k5JGfhTK009745; Mon, 19 Jun 2006 09:41:45 -0700 Subject: Re: i2c-algo-ite and i2c-ite planned for removal From: Pete Popov Reply-To: ppopov@embeddedalley.com To: Jean Delvare Cc: linux-mips@linux-mips.org, linux-kernel@vger.kernel.org In-Reply-To: <20060616222908.f96e3691.khali@linux-fr.org> References: <20060615225723.012c82be.khali@linux-fr.org> <1150406598.1193.73.camel@localhost.localdomain> <20060616222908.f96e3691.khali@linux-fr.org> Content-Type: text/plain Organization: Embedded Alley Solutions, Inc Date: Mon, 19 Jun 2006 19:45:58 +0300 Message-Id: <1150735558.8413.7.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.4.1 Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11773 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ppopov@embeddedalley.com Precedence: bulk X-list: linux-mips On Fri, 2006-06-16 at 22:29 +0200, Jean Delvare wrote: > Hi Pete, > > > > So basically we have two drivers in the kernel tree for 5 years or so, > > > which never were usable, and nobody seemed to care. > > > > For historical correctness, this driver was once upon a time usable, > > though it was a few years ago. It was written by MV for some ref board > > that had the ITE chip and it did work. That ref board is no longer > > around so it's probably safe to nuke the driver. > > In which kernel version? In every version I checked (2.4.12, 2.4.30, > 2.6.0 and 2.6.16) it wouldn't compile due to struct iic_ite being used > but never defined (and possibly other errors, but I can't test-compile > the driver.) Honestly, I don't remember. I think it was one of the very first 2.6 kernels because when MV first released a 2.6 product, 2.6 was still 'experimental'. It's quite possible of course that the driver was never properly merged upstream in the community tree(s). But I do know that it worked in the internal MV tree and an effort was made to get the driver accepted upstream. Pete From mrv@corecom.co.kr Tue Jun 20 01:36:50 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 20 Jun 2006 01:36:59 +0100 (BST) Received: from [220.76.242.187] ([220.76.242.187]:26515 "EHLO localhost.localdomain") by ftp.linux-mips.org with ESMTP id S8133715AbWFTAgt (ORCPT ); Tue, 20 Jun 2006 01:36:49 +0100 Received: from mrv ([192.168.11.157]) by localhost.localdomain (8.12.8/8.12.8) with SMTP id k5K0cFBb031870; Tue, 20 Jun 2006 09:38:18 +0900 Message-ID: <001901c69401$9d005280$9d0ba8c0@mrv> From: "Roman Mashak" To: "Ralf Baechle" Cc: References: <000601c6937f$0bed5270$9d0ba8c0@mrv> <20060619135156.GA9701@linux-mips.org> Subject: Re: Ethernet bridging on 2.6.12-rc3 (PMC-sierra patched) Date: Tue, 20 Jun 2006 09:36:46 +0900 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="ISO-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 FL-Build: Fidolook 2002 (SL) 6.0.2800.86 - 14/6/2003 22:16:25 Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11774 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: mrv@corecom.co.kr Precedence: bulk X-list: linux-mips Hello, Ralf! You wrote to "Roman Mashak" on Mon, 19 Jun 2006 14:51:56 +0100: RB> The Titan driver (the version on linux-mips.org and any other version RB> I've seen) are pretty broken and remarkably ugly pieces of code. The On the other hand, bridge works fine on 2.4.26 kernel on PMC board with Titan driver, which is much more broken AFAIK rather then in 2.6.X. RB> authors of the Basler eXcite platform have contributed their driver and RB> I hope it will show up upstream soon. Afaik it has not been tested When is it supposed to be merged into CVS ? RB> with any of PMC's eval boards but the necessary changes should not be RB> hard. With best regards, Roman Mashak. E-mail: mrv@corecom.co.kr From rongkai.zhan@windriver.com Tue Jun 20 10:54:48 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 20 Jun 2006 10:54:57 +0100 (BST) Received: from mail.windriver.com ([147.11.1.11]:58306 "EHLO mail.wrs.com") by ftp.linux-mips.org with ESMTP id S8133409AbWFTJys (ORCPT ); Tue, 20 Jun 2006 10:54:48 +0100 Received: from ala-mail04.corp.ad.wrs.com (ala-mail04 [147.11.57.145]) by mail.wrs.com (8.13.6/8.13.3) with ESMTP id k5K9se71015709; Tue, 20 Jun 2006 02:54:40 -0700 (PDT) Received: from ala-mail06.corp.ad.wrs.com ([147.11.57.147]) by ala-mail04.corp.ad.wrs.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 20 Jun 2006 02:54:40 -0700 Received: from [192.168.96.27] ([192.168.96.27]) by ala-mail06.corp.ad.wrs.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 20 Jun 2006 02:54:39 -0700 Message-ID: <4497C5DC.8060108@windriver.com> Date: Tue, 20 Jun 2006 17:54:36 +0800 From: "Mark.Zhan" User-Agent: Thunderbird 1.5.0.4 (X11/20060615) MIME-Version: 1.0 To: linux-mips@linux-mips.org CC: yoichi_yuasa@tripeaks.co.jp Subject: Re: Merge window ... Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 20 Jun 2006 09:54:40.0267 (UTC) FILETIME=[8C3B6DB0:01C6944F] Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11775 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: rongkai.zhan@windriver.com Precedence: bulk X-list: linux-mips > RBHMA4500 > SNI RM200 > Sibyte BCM91250A-SWARM > Wind River PPMC(New one, It'll be fixed) I just submitted the patch of the base support to Wind River PPMC Board a few weeks ago. So please don't remove this board. And I will submit another patch against the current Linux/MIPS git repository, to fix the build error for this board. Best Regards, Mark.Zhan From khali@linux-fr.org Tue Jun 20 11:08:42 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 20 Jun 2006 11:08:52 +0100 (BST) Received: from smtp-102-tuesday.noc.nerim.net ([62.4.17.102]:12039 "HELO mallaury.nerim.net") by ftp.linux-mips.org with SMTP id S8133456AbWFTKIm (ORCPT ); Tue, 20 Jun 2006 11:08:42 +0100 Received: from arrakis.delvare (jdelvare.pck.nerim.net [62.212.121.182]) by mallaury.nerim.net (Postfix) with SMTP id 91C924F3E1; Tue, 20 Jun 2006 12:08:26 +0200 (CEST) Date: Tue, 20 Jun 2006 12:08:36 +0200 From: Jean Delvare To: Pete Popov Cc: linux-mips@linux-mips.org, linux-kernel@vger.kernel.org Subject: Re: i2c-algo-ite and i2c-ite planned for removal Message-Id: <20060620120836.628ddc79.khali@linux-fr.org> In-Reply-To: <1150735558.8413.7.camel@localhost.localdomain> References: <20060615225723.012c82be.khali@linux-fr.org> <1150406598.1193.73.camel@localhost.localdomain> <20060616222908.f96e3691.khali@linux-fr.org> <1150735558.8413.7.camel@localhost.localdomain> X-Mailer: Sylpheed version 2.2.6 (GTK+ 2.6.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11776 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: khali@linux-fr.org Precedence: bulk X-list: linux-mips Hi Pete, > > > For historical correctness, this driver was once upon a time usable, > > > though it was a few years ago. It was written by MV for some ref board > > > that had the ITE chip and it did work. That ref board is no longer > > > around so it's probably safe to nuke the driver. > > > > In which kernel version? In every version I checked (2.4.12, 2.4.30, > > 2.6.0 and 2.6.16) it wouldn't compile due to struct iic_ite being used > > but never defined (and possibly other errors, but I can't test-compile > > the driver.) > > Honestly, I don't remember. I think it was one of the very first 2.6 > kernels because when MV first released a 2.6 product, 2.6 was still > 'experimental'. It's quite possible of course that the driver was never > properly merged upstream in the community tree(s). But I do know that it > worked in the internal MV tree and an effort was made to get the driver > accepted upstream. I couldn't find any evidence of this effort. Whatever, past is past, if someone fixes the i2c-ite and i2c-algo-ite drivers soon, fine with me, if not, the drivers will be deleted (which doesn't mean they can't be resurrected later if there is interest and someone takes over maintenance.) I'm setting the deadline to September 2006. -- Jean Delvare From rongkai.zhan@windriver.com Tue Jun 20 11:15:12 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 20 Jun 2006 11:15:23 +0100 (BST) Received: from mail.windriver.com ([147.11.1.11]:50381 "EHLO mail.wrs.com") by ftp.linux-mips.org with ESMTP id S8133534AbWFTKPM (ORCPT ); Tue, 20 Jun 2006 11:15:12 +0100 Received: from ALA-MAIL03.corp.ad.wrs.com (ala-mail03 [147.11.57.144]) by mail.wrs.com (8.13.6/8.13.3) with ESMTP id k5KAF6gV018955; Tue, 20 Jun 2006 03:15:06 -0700 (PDT) Received: from ala-mail06.corp.ad.wrs.com ([147.11.57.147]) by ALA-MAIL03.corp.ad.wrs.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 20 Jun 2006 03:15:05 -0700 Received: from [192.168.96.27] ([192.168.96.27]) by ala-mail06.corp.ad.wrs.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 20 Jun 2006 03:15:04 -0700 Message-ID: <4497CAA6.1010809@windriver.com> Date: Tue, 20 Jun 2006 18:15:02 +0800 From: "Mark.Zhan" User-Agent: Thunderbird 1.5.0.4 (X11/20060615) MIME-Version: 1.0 To: linux-mips@linux-mips.org CC: ralf@linux-mips.org Subject: [PATCH] Fix the build error of Wind River PPMC board Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 20 Jun 2006 10:15:05.0056 (UTC) FILETIME=[66436600:01C69452] Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11777 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: rongkai.zhan@windriver.com Precedence: bulk X-list: linux-mips Hi, This patch will fix the build error of building wind river ppmc board, which is caused by the change of plat_setup hook interface. And because Ralf has introduced the new interrupt handling framework in 2.6.17-rc2, so the assembly interrupt handling codes in "int-handler.S" should be removed and replaced by the new plat_irq_dispatch() hook. Signed-off-by: Rongkai.Zhan ----- diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig index 89ec332..e38f0cd 100644 --- a/arch/mips/Kconfig +++ b/arch/mips/Kconfig @@ -360,7 +360,7 @@ config MIPS_SEAD board. config WR_PPMC - bool "Support for Wind River PPMC board" + bool "Wind River PPMC board" select IRQ_CPU select BOOT_ELF32 select DMA_NONCOHERENT diff --git a/arch/mips/gt64120/wrppmc/Makefile b/arch/mips/gt64120/wrppmc/Makefile index 72606b9..7cf5220 100644 --- a/arch/mips/gt64120/wrppmc/Makefile +++ b/arch/mips/gt64120/wrppmc/Makefile @@ -9,6 +9,6 @@ # Makefile for the Wind River MIPS 4KC PPMC Eval Board # -obj-y += int-handler.o irq.o reset.o setup.o time.o pci.o +obj-y += irq.o reset.o setup.o time.o pci.o EXTRA_AFLAGS := $(CFLAGS) diff --git a/arch/mips/gt64120/wrppmc/int-handler.S b/arch/mips/gt64120/wrppmc/int-handler.S deleted file mode 100644 index edee7b3..0000000 --- a/arch/mips/gt64120/wrppmc/int-handler.S +++ /dev/null @@ -1,59 +0,0 @@ -/* - * This file is subject to the terms and conditions of the GNU General Public - * License. See the file "COPYING" in the main directory of this archive - * for more details. - * - * Copyright (C) 1995, 1996, 1997, 2003 by Ralf Baechle - * Copyright (C) Wind River System Inc. Rongkai.Zhan - */ -#include -#include -#include -#include -#include -#include - - .align 5 - .set noat -NESTED(handle_IRQ, PT_SIZE, sp) - SAVE_ALL - CLI # Important: mark KERNEL mode ! - .set at - - mfc0 t0, CP0_CAUSE # get pending interrupts - mfc0 t1, CP0_STATUS # get enabled interrupts - and t0, t0, t1 # get allowed interrupts - andi t0, t0, 0xFF00 - beqz t0, 1f - move a1, sp # Prepare 'struct pt_regs *regs' pointer - - andi t1, t0, CAUSEF_IP7 # CPU Compare/Count internal timer - bnez t1, handle_cputimer_irq - andi t1, t0, CAUSEF_IP6 # UART 16550 port - bnez t1, handle_uart_irq - andi t1, t0, CAUSEF_IP3 # PCI INT_A - bnez t1, handle_pci_intA_irq - - /* wrong alarm or masked ... */ -1: j spurious_interrupt - nop -END(handle_IRQ) - - .align 5 -handle_cputimer_irq: - li a0, WRPPMC_MIPS_TIMER_IRQ - jal do_IRQ - j ret_from_irq - - .align 5 -handle_uart_irq: - li a0, WRPPMC_UART16550_IRQ - jal do_IRQ - j ret_from_irq - - .align 5 -handle_pci_intA_irq: - li a0, WRPPMC_PCI_INTA_IRQ - jal do_IRQ - j ret_from_irq - diff --git a/arch/mips/gt64120/wrppmc/irq.c b/arch/mips/gt64120/wrppmc/irq.c index 8605687..80d6b79 100644 --- a/arch/mips/gt64120/wrppmc/irq.c +++ b/arch/mips/gt64120/wrppmc/irq.c @@ -30,7 +30,19 @@ #include #include -extern asmlinkage void handle_IRQ(void); +asmlinkage void plat_irq_dispatch(struct pt_regs *regs) +{ + unsigned int pending = read_c0_status() & read_c0_cause(); + + if (pending & STATUSF_IP7) + do_IRQ(WRPPMC_MIPS_TIMER_IRQ, regs); /* CPU Compare/Count internal timer */ + else if (pending & STATUSF_IP6) + do_IRQ(WRPPMC_UART16550_IRQ, regs); /* UART 16550 port */ + else if (pending & STATUSF_IP3) + do_IRQ(WRPPMC_PCI_INTA_IRQ, regs); /* PCI INT_A */ + else + spurious_interrupt(regs); +} /** * Initialize GT64120 Interrupt Controller @@ -53,9 +65,6 @@ void __init arch_init_irq(void) /* enable all CPU interrupt bits. */ set_c0_status(ST0_IM); /* IE bit is still 0 */ - /* Install MIPS Interrupt Trap Vector */ - set_except_vector(0, handle_IRQ); - /* IRQ 0 - 7 are for MIPS common irq_cpu controller */ mips_cpu_irq_init(0); diff --git a/arch/mips/gt64120/wrppmc/setup.c b/arch/mips/gt64120/wrppmc/setup.c index 20c591e..2db6375 100644 --- a/arch/mips/gt64120/wrppmc/setup.c +++ b/arch/mips/gt64120/wrppmc/setup.c @@ -125,7 +125,7 @@ static void wrppmc_setup_serial(void) } #endif -void __init plat_setup(void) +void __init plat_mem_setup(void) { extern void wrppmc_time_init(void); extern void wrppmc_timer_setup(struct irqaction *); From rongkai.zhan@windriver.com Tue Jun 20 11:40:39 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 20 Jun 2006 11:40:54 +0100 (BST) Received: from mail.windriver.com ([147.11.1.11]:6362 "EHLO mail.wrs.com") by ftp.linux-mips.org with ESMTP id S8133545AbWFTKkj (ORCPT ); Tue, 20 Jun 2006 11:40:39 +0100 Received: from ala-mail04.corp.ad.wrs.com (ala-mail04 [147.11.57.145]) by mail.wrs.com (8.13.6/8.13.3) with ESMTP id k5KAeWit022596; Tue, 20 Jun 2006 03:40:32 -0700 (PDT) Received: from ala-mail06.corp.ad.wrs.com ([147.11.57.147]) by ala-mail04.corp.ad.wrs.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 20 Jun 2006 03:40:32 -0700 Received: from [192.168.96.27] ([192.168.96.27]) by ala-mail06.corp.ad.wrs.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 20 Jun 2006 03:40:31 -0700 Message-ID: <4497D09D.1040205@windriver.com> Date: Tue, 20 Jun 2006 18:40:29 +0800 From: "Mark.Zhan" User-Agent: Thunderbird 1.5.0.4 (X11/20060615) MIME-Version: 1.0 To: "Mark.Zhan" CC: linux-mips@linux-mips.org, ralf@linux-mips.org Subject: Re: [PATCH] Fix the build error of Wind River PPMC board References: <4497CAA6.1010809@windriver.com> In-Reply-To: <4497CAA6.1010809@windriver.com> Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 20 Jun 2006 10:40:32.0007 (UTC) FILETIME=[F465A170:01C69455] Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11778 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: rongkai.zhan@windriver.com Precedence: bulk X-list: linux-mips Hi, Sorry for the stupid line wrap problem, again. It is re-posted. Signed-off-by: Rongkai.Zhan ------ diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig index 89ec332..e38f0cd 100644 --- a/arch/mips/Kconfig +++ b/arch/mips/Kconfig @@ -360,7 +360,7 @@ config MIPS_SEAD board. config WR_PPMC - bool "Support for Wind River PPMC board" + bool "Wind River PPMC board" select IRQ_CPU select BOOT_ELF32 select DMA_NONCOHERENT diff --git a/arch/mips/gt64120/wrppmc/Makefile b/arch/mips/gt64120/wrppmc/Makefile index 72606b9..7cf5220 100644 --- a/arch/mips/gt64120/wrppmc/Makefile +++ b/arch/mips/gt64120/wrppmc/Makefile @@ -9,6 +9,6 @@ # Makefile for the Wind River MIPS 4KC PPMC Eval Board # -obj-y += int-handler.o irq.o reset.o setup.o time.o pci.o +obj-y += irq.o reset.o setup.o time.o pci.o EXTRA_AFLAGS := $(CFLAGS) diff --git a/arch/mips/gt64120/wrppmc/int-handler.S b/arch/mips/gt64120/wrppmc/int-handler.S deleted file mode 100644 index edee7b3..0000000 --- a/arch/mips/gt64120/wrppmc/int-handler.S +++ /dev/null @@ -1,59 +0,0 @@ -/* - * This file is subject to the terms and conditions of the GNU General Public - * License. See the file "COPYING" in the main directory of this archive - * for more details. - * - * Copyright (C) 1995, 1996, 1997, 2003 by Ralf Baechle - * Copyright (C) Wind River System Inc. Rongkai.Zhan - */ -#include -#include -#include -#include -#include -#include - - .align 5 - .set noat -NESTED(handle_IRQ, PT_SIZE, sp) - SAVE_ALL - CLI # Important: mark KERNEL mode ! - .set at - - mfc0 t0, CP0_CAUSE # get pending interrupts - mfc0 t1, CP0_STATUS # get enabled interrupts - and t0, t0, t1 # get allowed interrupts - andi t0, t0, 0xFF00 - beqz t0, 1f - move a1, sp # Prepare 'struct pt_regs *regs' pointer - - andi t1, t0, CAUSEF_IP7 # CPU Compare/Count internal timer - bnez t1, handle_cputimer_irq - andi t1, t0, CAUSEF_IP6 # UART 16550 port - bnez t1, handle_uart_irq - andi t1, t0, CAUSEF_IP3 # PCI INT_A - bnez t1, handle_pci_intA_irq - - /* wrong alarm or masked ... */ -1: j spurious_interrupt - nop -END(handle_IRQ) - - .align 5 -handle_cputimer_irq: - li a0, WRPPMC_MIPS_TIMER_IRQ - jal do_IRQ - j ret_from_irq - - .align 5 -handle_uart_irq: - li a0, WRPPMC_UART16550_IRQ - jal do_IRQ - j ret_from_irq - - .align 5 -handle_pci_intA_irq: - li a0, WRPPMC_PCI_INTA_IRQ - jal do_IRQ - j ret_from_irq - diff --git a/arch/mips/gt64120/wrppmc/irq.c b/arch/mips/gt64120/wrppmc/irq.c index 8605687..80d6b79 100644 --- a/arch/mips/gt64120/wrppmc/irq.c +++ b/arch/mips/gt64120/wrppmc/irq.c @@ -30,7 +30,19 @@ #include #include -extern asmlinkage void handle_IRQ(void); +asmlinkage void plat_irq_dispatch(struct pt_regs *regs) +{ + unsigned int pending = read_c0_status() & read_c0_cause(); + + if (pending & STATUSF_IP7) + do_IRQ(WRPPMC_MIPS_TIMER_IRQ, regs); /* CPU Compare/Count internal timer */ + else if (pending & STATUSF_IP6) + do_IRQ(WRPPMC_UART16550_IRQ, regs); /* UART 16550 port */ + else if (pending & STATUSF_IP3) + do_IRQ(WRPPMC_PCI_INTA_IRQ, regs); /* PCI INT_A */ + else + spurious_interrupt(regs); +} /** * Initialize GT64120 Interrupt Controller @@ -53,9 +65,6 @@ void __init arch_init_irq(void) /* enable all CPU interrupt bits. */ set_c0_status(ST0_IM); /* IE bit is still 0 */ - /* Install MIPS Interrupt Trap Vector */ - set_except_vector(0, handle_IRQ); - /* IRQ 0 - 7 are for MIPS common irq_cpu controller */ mips_cpu_irq_init(0); diff --git a/arch/mips/gt64120/wrppmc/setup.c b/arch/mips/gt64120/wrppmc/setup.c index 20c591e..2db6375 100644 --- a/arch/mips/gt64120/wrppmc/setup.c +++ b/arch/mips/gt64120/wrppmc/setup.c @@ -125,7 +125,7 @@ static void wrppmc_setup_serial(void) } #endif -void __init plat_setup(void) +void __init plat_mem_setup(void) { extern void wrppmc_time_init(void); extern void wrppmc_timer_setup(struct irqaction *); From ralf@linux-mips.org Tue Jun 20 12:09:45 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 20 Jun 2006 12:09:53 +0100 (BST) Received: from localhost.localdomain ([127.0.0.1]:5827 "EHLO bacchus.dhis.org") by ftp.linux-mips.org with ESMTP id S8133488AbWFTLJp (ORCPT ); Tue, 20 Jun 2006 12:09:45 +0100 Received: from denk.linux-mips.net (denk.linux-mips.net [127.0.0.1]) by bacchus.dhis.org (8.13.6/8.13.4) with ESMTP id k5KB9ip4024842; Tue, 20 Jun 2006 12:09:44 +0100 Received: (from ralf@localhost) by denk.linux-mips.net (8.13.6/8.13.6/Submit) id k5KB9hVS024841; Tue, 20 Jun 2006 12:09:43 +0100 Date: Tue, 20 Jun 2006 12:09:43 +0100 From: Ralf Baechle To: "Mark.Zhan" Cc: linux-mips@linux-mips.org Subject: Re: [PATCH] Fix the build error of Wind River PPMC board Message-ID: <20060620110943.GA24834@linux-mips.org> References: <4497CAA6.1010809@windriver.com> <4497D09D.1040205@windriver.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4497D09D.1040205@windriver.com> User-Agent: Mutt/1.4.2.1i Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11779 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ralf@linux-mips.org Precedence: bulk X-list: linux-mips On Tue, Jun 20, 2006 at 06:40:29PM +0800, Mark.Zhan wrote: > Sorry for the stupid line wrap problem, again. git didn't moan about the first patch being corrupt, so I applied it. Ralf From yoichi_yuasa@tripeaks.co.jp Tue Jun 20 13:33:10 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 20 Jun 2006 13:33:20 +0100 (BST) Received: from mo32.po.2iij.net ([210.128.50.17]:6215 "EHLO mo32.po.2iij.net") by ftp.linux-mips.org with ESMTP id S8133545AbWFTMdK (ORCPT ); Tue, 20 Jun 2006 13:33:10 +0100 Received: by mo.po.2iij.net (mo32) id k5KCX5me079817; Tue, 20 Jun 2006 21:33:06 +0900 (JST) Received: from localhost.localdomain (225.29.30.125.dy.iij4u.or.jp [125.30.29.225]) by mbox.po.2iij.net (mbox30) id k5KCX3oh086843 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 20 Jun 2006 21:33:04 +0900 (JST) Date: Tue, 20 Jun 2006 21:33:02 +0900 From: Yoichi Yuasa To: Ralf Baechle Cc: linux-mips@linux-mips.org Subject: [PATCH] removes unused functions for GT64120 Message-Id: <20060620213302.450050bf.yoichi_yuasa@tripeaks.co.jp> Organization: TriPeaks Corporation X-Mailer: Sylpheed version 1.0.4 (GTK+ 1.2.10; i386-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11780 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: yoichi_yuasa@tripeaks.co.jp Precedence: bulk X-list: linux-mips Hi Ralf, This patch removes unused functions for GT64120. Please apply. Yoichi Signed-off-by: Yoichi Yuasa diff -pruN -X mips/Documentation/dontdiff mips-orig/arch/mips/gt64120/common/Makefile mips/arch/mips/gt64120/common/Makefile --- mips-orig/arch/mips/gt64120/common/Makefile 2006-06-20 14:14:56.915586750 +0900 +++ mips/arch/mips/gt64120/common/Makefile 2006-06-20 15:15:01.158879000 +0900 @@ -3,4 +3,3 @@ # obj-y += time.o -obj-$(CONFIG_PCI) += pci.o diff -pruN -X mips/Documentation/dontdiff mips-orig/arch/mips/gt64120/common/pci.c mips/arch/mips/gt64120/common/pci.c --- mips-orig/arch/mips/gt64120/common/pci.c 2006-06-20 14:14:56.915586750 +0900 +++ mips/arch/mips/gt64120/common/pci.c 1970-01-01 09:00:00.000000000 +0900 @@ -1,147 +0,0 @@ -/* - * BRIEF MODULE DESCRIPTION - * Galileo Evaluation Boards PCI support. - * - * The general-purpose functions to read/write and configure the GT64120A's - * PCI registers (function names start with pci0 or pci1) are either direct - * copies of functions written by Galileo Technology, or are modifications - * of their functions to work with Linux 2.4 vs Linux 2.2. These functions - * are Copyright - Galileo Technology. - * - * Other functions are derived from other MIPS PCI implementations, or were - * written by RidgeRun, Inc, Copyright (C) 2000 RidgeRun, Inc. - * glonnon@ridgerun.com, skranz@ridgerun.com, stevej@ridgerun.com - * - * This program is free software; you can redistribute it and/or modify it - * under the terms of the GNU General Public License as published by the - * Free Software Foundation; either version 2 of the License, or (at your - * option) any later version. - * - * THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESS OR IMPLIED - * WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF - * MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN - * NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT, - * INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT - * NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF - * USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON - * ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT - * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF - * THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. - * - * You should have received a copy of the GNU General Public License along - * with this program; if not, write to the Free Software Foundation, Inc., - * 675 Mass Ave, Cambridge, MA 02139, USA. - */ -#include -#include -#include -#include -#include - -#define SELF 0 - -/* - * pciXReadConfigReg - Read from a PCI configuration register - * - Make sure the GT is configured as a master before - * reading from another device on the PCI. - * - The function takes care of Big/Little endian conversion. - * INPUTS: regOffset: The register offset as it apears in the GT spec (or PCI - * spec) - * pciDevNum: The device number needs to be addressed. - * RETURNS: data , if the data == 0xffffffff check the master abort bit in the - * cause register to make sure the data is valid - * - * Configuration Address 0xCF8: - * - * 31 30 24 23 16 15 11 10 8 7 2 0 <=bit Number - * |congif|Reserved| Bus |Device|Function|Register|00| - * |Enable| |Number|Number| Number | Number | | <=field Name - * - */ -static unsigned int pci0ReadConfigReg(int offset, struct pci_dev *device) -{ - unsigned int DataForRegCf8; - unsigned int data; - - DataForRegCf8 = ((PCI_SLOT(device->devfn) << 11) | - (PCI_FUNC(device->devfn) << 8) | - (offset & ~0x3)) | 0x80000000; - GT_WRITE(GT_PCI0_CFGADDR_OFS, DataForRegCf8); - - /* - * The casual observer might wonder why the READ is duplicated here, - * rather than immediately following the WRITE, and just have the swap - * in the "if". That's because there is a latency problem with trying - * to read immediately after setting up the address register. The "if" - * check gives enough time for the address to stabilize, so the READ - * can work. - */ - if (PCI_SLOT(device->devfn) == SELF) /* This board */ - return GT_READ(GT_PCI0_CFGDATA_OFS); - else /* PCI is little endian so swap the Data. */ - return __GT_READ(GT_PCI0_CFGDATA_OFS); -} - -/* - * pciXWriteConfigReg - Write to a PCI configuration register - * - Make sure the GT is configured as a master before - * writingto another device on the PCI. - * - The function takes care of Big/Little endian conversion. - * Inputs: unsigned int regOffset: The register offset as it apears in the - * GT spec - * (or any other PCI device spec) - * pciDevNum: The device number needs to be addressed. - * - * Configuration Address 0xCF8: - * - * 31 30 24 23 16 15 11 10 8 7 2 0 <=bit Number - * |congif|Reserved| Bus |Device|Function|Register|00| - * |Enable| |Number|Number| Number | Number | | <=field Name - * - */ -static void pci0WriteConfigReg(unsigned int offset, - struct pci_dev *device, unsigned int data) -{ - unsigned int DataForRegCf8; - - DataForRegCf8 = ((PCI_SLOT(device->devfn) << 11) | - (PCI_FUNC(device->devfn) << 8) | - (offset & ~0x3)) | 0x80000000; - GT_WRITE(GT_PCI0_CFGADDR_OFS, DataForRegCf8); - - if (PCI_SLOT(device->devfn) == SELF) /* This board */ - GT_WRITE(GT_PCI0_CFGDATA_OFS, data); - else /* configuration Transaction over the pci. */ - __GT_WRITE(GT_PCI0_CFGDATA_OFS, data); -} - -extern struct pci_ops gt64120_pci_ops; - -void __init pcibios_init(void) -{ - u32 tmp; - struct pci_dev controller; - - controller.devfn = SELF; - - tmp = GT_READ(GT_PCI0_CMD_OFS); /* Huh??? -- Ralf */ - tmp = GT_READ(GT_PCI0_BARE_OFS); - - /* - * You have to enable bus mastering to configure any other - * card on the bus. - */ - tmp = pci0ReadConfigReg(PCI_COMMAND, &controller); - tmp |= PCI_COMMAND_MEMORY | PCI_COMMAND_MASTER | PCI_COMMAND_SERR; - pci0WriteConfigReg(PCI_COMMAND, &controller, tmp); - - /* - * Reset PCI I/O and PCI MEM values to ones supported by EVM. - */ - ioport_resource.start = GT_PCI_IO_BASE; - ioport_resource.end = GT_PCI_IO_BASE + GT_PCI_IO_SIZE - 1; - iomem_resource.start = GT_PCI_MEM_BASE; - iomem_resource.end = GT_PCI_MEM_BASE + GT_PCI_MEM_SIZE - 1; - - pci_scan_bus(0, >64120_pci_ops, NULL); -} From yoichi_yuasa@tripeaks.co.jp Tue Jun 20 13:54:37 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 20 Jun 2006 13:54:46 +0100 (BST) Received: from mo30.po.2iij.net ([210.128.50.53]:9733 "EHLO mo30.po.2iij.net") by ftp.linux-mips.org with ESMTP id S8133545AbWFTMyh (ORCPT ); Tue, 20 Jun 2006 13:54:37 +0100 Received: by mo.po.2iij.net (mo30) id k5KCsWwu034113; Tue, 20 Jun 2006 21:54:32 +0900 (JST) Received: from localhost.localdomain (225.29.30.125.dy.iij4u.or.jp [125.30.29.225]) by mbox.po.2iij.net (mbox32) id k5KCsOYp089485 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 20 Jun 2006 21:54:24 +0900 (JST) Date: Tue, 20 Jun 2006 21:54:23 +0900 From: Yoichi Yuasa To: Sergei Shtylyov Cc: yoichi_yuasa@tripeaks.co.jp, linux-mips@linux-mips.org Subject: Re: Merge window ... Message-Id: <20060620215423.2d66bf2e.yoichi_yuasa@tripeaks.co.jp> In-Reply-To: <4496BE57.5040802@ru.mvista.com> References: <20060619103653.GA4257@linux-mips.org> <20060620000346.2b704b9b.yoichi_yuasa@tripeaks.co.jp> <4496BE57.5040802@ru.mvista.com> Organization: TriPeaks Corporation X-Mailer: Sylpheed version 1.0.4 (GTK+ 1.2.10; i386-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11781 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: yoichi_yuasa@tripeaks.co.jp Precedence: bulk X-list: linux-mips Hello, On Mon, 19 Jun 2006 19:10:15 +0400 Sergei Shtylyov wrote: > > Toshiba RBTX4938 > > RBHMA4500 > > This is the same board. I think it's too early to remove this. MV has a > number of patches for it BTW, only there was/is no time to push them upstream. > > > Sibyte BCM91250A-SWARM > > It's really too early to remove this one. MV is working on the new kernel. > > > Also the folowing boards don't have config file. > > > Toshiba TBTX49[23]7 > > I've pushed some patches for those resently... Can you provide config file for TBTX49[23]7 ? How about JMR-TX3927? Yoichi From yoichi_yuasa@tripeaks.co.jp Tue Jun 20 14:56:04 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 20 Jun 2006 14:56:13 +0100 (BST) Received: from mo32.po.2iij.net ([210.128.50.17]:26437 "EHLO mo32.po.2iij.net") by ftp.linux-mips.org with ESMTP id S8133732AbWFTN4E (ORCPT ); Tue, 20 Jun 2006 14:56:04 +0100 Received: by mo.po.2iij.net (mo32) id k5KDu1qD097602; Tue, 20 Jun 2006 22:56:01 +0900 (JST) Received: from localhost.localdomain (225.29.30.125.dy.iij4u.or.jp [125.30.29.225]) by mbox.po.2iij.net (mbox33) id k5KDtvw0000417 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 20 Jun 2006 22:55:57 +0900 (JST) Date: Tue, 20 Jun 2006 22:55:55 +0900 From: Yoichi Yuasa To: Ralf Baechle Cc: yoichi_yuasa@tripeaks.co.jp, linux-mips@linux-mips.org Subject: Re: Merge window ... Message-Id: <20060620225555.42f0246f.yoichi_yuasa@tripeaks.co.jp> In-Reply-To: <20060619155001.GA12123@linux-mips.org> References: <20060619103653.GA4257@linux-mips.org> <20060620000346.2b704b9b.yoichi_yuasa@tripeaks.co.jp> <20060619155001.GA12123@linux-mips.org> Organization: TriPeaks Corporation X-Mailer: Sylpheed version 1.0.4 (GTK+ 1.2.10; i386-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11782 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: yoichi_yuasa@tripeaks.co.jp Precedence: bulk X-list: linux-mips Hello Ralf, On Mon, 19 Jun 2006 16:50:01 +0100 Ralf Baechle wrote: > On Tue, Jun 20, 2006 at 12:03:46AM +0900, Yoichi Yuasa wrote: > > > > > 4G Systems MTX-1 > > AMD Alchemy Bosporus > > AMD Alchemy Mirage > > Jazz family > > Toshiba TBTX49[23]7 > > > > These boards are candidate for removal. > > If there are none objection, we can add to feature-removal-schedule.txt. > > A little too much. Malta for example works and I'm running top of tree. > Jazz is happy, SNI was doing ok and received a major upgrade just on > the weekend and the Broadcom stuff - aside of slight bitrot is crucially > important for many projects as the provider of horsepower for native > builds. Thank you for your comment. > My candidates for nuking are marked with a big red box in the wiki in > the hope somebody will fix the code: > > http://www.linux-mips.org/wiki/Category:Deprecated > > Many eval boards tend to have a short livespan unlike vintage workstation > and server hardware, so I tend to be trigger happier for eval board > type of stuff. How about EV64120 and Momentum Ocelot-G ? Yoichi From yoichi_yuasa@tripeaks.co.jp Tue Jun 20 15:07:48 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 20 Jun 2006 15:07:57 +0100 (BST) Received: from mo31.po.2iij.net ([210.128.50.54]:28698 "EHLO mo31.po.2iij.net") by ftp.linux-mips.org with ESMTP id S8133759AbWFTOHs (ORCPT ); Tue, 20 Jun 2006 15:07:48 +0100 Received: by mo.po.2iij.net (mo31) id k5KE7kWb008623; Tue, 20 Jun 2006 23:07:46 +0900 (JST) Received: from localhost.localdomain (225.29.30.125.dy.iij4u.or.jp [125.30.29.225]) by mbox.po.2iij.net (mbox30) id k5KE7iVG039709 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 20 Jun 2006 23:07:44 +0900 (JST) Date: Tue, 20 Jun 2006 23:07:43 +0900 From: Yoichi Yuasa To: Ralf Baechle Cc: linux-mips@linux-mips.org Subject: [PATCH] remove unused timex.h for vr41xx Message-Id: <20060620230743.1fe60be5.yoichi_yuasa@tripeaks.co.jp> Organization: TriPeaks Corporation X-Mailer: Sylpheed version 1.0.4 (GTK+ 1.2.10; i386-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11783 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: yoichi_yuasa@tripeaks.co.jp Precedence: bulk X-list: linux-mips Hi Ralf, This patch removes unused timex.h for vr41xx. Please apply. Yoichi Signed-off-by: Yoichi Yuasa diff -pruN -X mips-rc6/Documentation/dontdiff mips-rc6-orig/include/asm-mips/mach-vr41xx/timex.h mips-rc6/include/asm-mips/mach-vr41xx/timex.h --- mips-rc6-orig/include/asm-mips/mach-vr41xx/timex.h 2006-06-09 00:33:01.005450500 +0900 +++ mips-rc6/include/asm-mips/mach-vr41xx/timex.h 1970-01-01 09:00:00.000000000 +0900 @@ -1,18 +0,0 @@ -/* - * This file is subject to the terms and conditions of the GNU General Public - * License. See the file "COPYING" in the main directory of this archive - * for more details. - * - * Copyright (C) 2003 by Ralf Baechle - */ -/* - * Changes: - * Yoichi Yuasa - * - CLOCK_TICK_RATE is changed into 32768 from 6144000. - */ -#ifndef __ASM_MACH_VR41XX_TIMEX_H -#define __ASM_MACH_VR41XX_TIMEX_H - -#define CLOCK_TICK_RATE 32768 - -#endif /* __ASM_MACH_VR41XX_TIMEX_H */ From yoichi_yuasa@tripeaks.co.jp Tue Jun 20 15:17:25 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 20 Jun 2006 15:17:35 +0100 (BST) Received: from mo31.po.2iij.net ([210.128.50.54]:46151 "EHLO mo31.po.2iij.net") by ftp.linux-mips.org with ESMTP id S8133761AbWFTORZ (ORCPT ); Tue, 20 Jun 2006 15:17:25 +0100 Received: by mo.po.2iij.net (mo31) id k5KEHNNG010243; Tue, 20 Jun 2006 23:17:23 +0900 (JST) Received: from localhost.localdomain (225.29.30.125.dy.iij4u.or.jp [125.30.29.225]) by mbox.po.2iij.net (mbox30) id k5KEHJCe043975 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 20 Jun 2006 23:17:19 +0900 (JST) Date: Tue, 20 Jun 2006 23:17:18 +0900 From: Yoichi Yuasa To: Ralf Baechle Cc: linux-mips@linux-mips.org Subject: [PATCH] remove unused system type name(DDB5074 and DDB5476) Message-Id: <20060620231718.75dac51a.yoichi_yuasa@tripeaks.co.jp> Organization: TriPeaks Corporation X-Mailer: Sylpheed version 1.0.4 (GTK+ 1.2.10; i386-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11784 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: yoichi_yuasa@tripeaks.co.jp Precedence: bulk X-list: linux-mips Hi Ralf, This patch removes unused system type name. DDB5074 and DDB5476 were already removed. Yoichi Signed-off-by: Yoichi Yuasa diff -pruN -X mips/Documentation/dontdiff mips-orig/arch/mips/ddb5xxx/common/prom.c mips/arch/mips/ddb5xxx/common/prom.c --- mips-orig/arch/mips/ddb5xxx/common/prom.c 2006-06-20 14:14:56.891585250 +0900 +++ mips/arch/mips/ddb5xxx/common/prom.c 2006-06-19 10:12:28.198331000 +0900 @@ -21,8 +21,6 @@ const char *get_system_type(void) { switch (mips_machtype) { - case MACH_NEC_DDB5074: return "NEC DDB Vrc-5074"; - case MACH_NEC_DDB5476: return "NEC DDB Vrc-5476"; case MACH_NEC_DDB5477: return "NEC DDB Vrc-5477"; case MACH_NEC_ROCKHOPPER: return "NEC Rockhopper"; case MACH_NEC_ROCKHOPPERII: return "NEC RockhopperII"; From yoichi_yuasa@tripeaks.co.jp Tue Jun 20 15:26:40 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 20 Jun 2006 15:26:51 +0100 (BST) Received: from mo30.po.2iij.net ([210.128.50.53]:15127 "EHLO mo30.po.2iij.net") by ftp.linux-mips.org with ESMTP id S8133761AbWFTO0k (ORCPT ); Tue, 20 Jun 2006 15:26:40 +0100 Received: by mo.po.2iij.net (mo30) id k5KEQcTa050445; Tue, 20 Jun 2006 23:26:38 +0900 (JST) Received: from localhost.localdomain (225.29.30.125.dy.iij4u.or.jp [125.30.29.225]) by mbox.po.2iij.net (mbox30) id k5KEQVF7047931 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 20 Jun 2006 23:26:32 +0900 (JST) Date: Tue, 20 Jun 2006 23:26:30 +0900 From: Yoichi Yuasa To: Ralf Baechle Cc: linux-mips@linux-mips.org Subject: [PATCH] remove set_c0_status(ST0_IM) form wrppmc's irq.c Message-Id: <20060620232630.3f2bc491.yoichi_yuasa@tripeaks.co.jp> Organization: TriPeaks Corporation X-Mailer: Sylpheed version 1.0.4 (GTK+ 1.2.10; i386-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11785 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: yoichi_yuasa@tripeaks.co.jp Precedence: bulk X-list: linux-mips Hi, mips_cpu_irq_init() does clear_c0_status(ST0_IM) first. I think that set_c0_status(ST0_IM) isn't necessary. Yoichi Signed-off-by: Yoichi Yuasa diff -pruN -X mips/Documentation/dontdiff mips-orig/arch/mips/gt64120/wrppmc/irq.c mips/arch/mips/gt64120/wrppmc/irq.c --- mips-orig/arch/mips/gt64120/wrppmc/irq.c 2006-06-20 21:17:36.853537000 +0900 +++ mips/arch/mips/gt64120/wrppmc/irq.c 2006-06-20 21:36:41.949101000 +0900 @@ -62,9 +62,6 @@ void gt64120_init_pic(void) void __init arch_init_irq(void) { - /* enable all CPU interrupt bits. */ - set_c0_status(ST0_IM); /* IE bit is still 0 */ - /* IRQ 0 - 7 are for MIPS common irq_cpu controller */ mips_cpu_irq_init(0); From ralf@linux-mips.org Tue Jun 20 15:36:22 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 20 Jun 2006 15:36:30 +0100 (BST) Received: from localhost.localdomain ([127.0.0.1]:4501 "EHLO bacchus.dhis.org") by ftp.linux-mips.org with ESMTP id S8133761AbWFTOgW (ORCPT ); Tue, 20 Jun 2006 15:36:22 +0100 Received: from denk.linux-mips.net (denk.linux-mips.net [127.0.0.1]) by bacchus.dhis.org (8.13.6/8.13.4) with ESMTP id k5KEaL4G013072; Tue, 20 Jun 2006 15:36:21 +0100 Received: (from ralf@localhost) by denk.linux-mips.net (8.13.6/8.13.6/Submit) id k5KEaHOe013071; Tue, 20 Jun 2006 15:36:17 +0100 Date: Tue, 20 Jun 2006 15:36:17 +0100 From: Ralf Baechle To: Yoichi Yuasa Cc: linux-mips@linux-mips.org Subject: Re: Merge window ... Message-ID: <20060620143617.GA11651@linux-mips.org> References: <20060619103653.GA4257@linux-mips.org> <20060620000346.2b704b9b.yoichi_yuasa@tripeaks.co.jp> <20060619155001.GA12123@linux-mips.org> <20060620225555.42f0246f.yoichi_yuasa@tripeaks.co.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060620225555.42f0246f.yoichi_yuasa@tripeaks.co.jp> User-Agent: Mutt/1.4.2.1i Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11786 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ralf@linux-mips.org Precedence: bulk X-list: linux-mips On Tue, Jun 20, 2006 at 10:55:55PM +0900, Yoichi Yuasa wrote: > > the hope somebody will fix the code: > > > > http://www.linux-mips.org/wiki/Category:Deprecated > > > > Many eval boards tend to have a short livespan unlike vintage workstation > > and server hardware, so I tend to be trigger happier for eval board > > type of stuff. > > How about EV64120 and Momentum Ocelot-G ? Ocelot G was on my to be grilled list as posted a while ago I think. I just created a wiki page for it, so it's now widely visible as death candidate. I'd do the same for the EV64120 - but I know nothing about that board, I haven't heared of anybody trying to use, so it's a candidate as well. Could anybody out there who knows enough to write a quick description of the EV64120 write a quick wiki page? Thanks :-) Ralf From sshtylyov@ru.mvista.com Tue Jun 20 15:42:01 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 20 Jun 2006 15:42:09 +0100 (BST) Received: from rtsoft2.corbina.net ([85.21.88.2]:45188 "HELO mail.dev.rtsoft.ru") by ftp.linux-mips.org with SMTP id S8133769AbWFTOmB (ORCPT ); Tue, 20 Jun 2006 15:42:01 +0100 Received: (qmail 20953 invoked from network); 20 Jun 2006 18:53:07 -0000 Received: from wasted.dev.rtsoft.ru (HELO ?192.168.1.248?) (192.168.1.248) by mail.dev.rtsoft.ru with SMTP; 20 Jun 2006 18:53:07 -0000 Message-ID: <449808F6.2000206@ru.mvista.com> Date: Tue, 20 Jun 2006 18:40:54 +0400 From: Sergei Shtylyov Organization: MontaVista Software Inc. User-Agent: Mozilla/5.0 (X11; U; Linux i686; rv:1.7.2) Gecko/20040803 X-Accept-Language: ru, en-us, en-gb MIME-Version: 1.0 To: Yoichi Yuasa CC: linux-mips@linux-mips.org Subject: Re: Merge window ... References: <20060619103653.GA4257@linux-mips.org> <20060620000346.2b704b9b.yoichi_yuasa@tripeaks.co.jp> <4496BE57.5040802@ru.mvista.com> <20060620215423.2d66bf2e.yoichi_yuasa@tripeaks.co.jp> In-Reply-To: <20060620215423.2d66bf2e.yoichi_yuasa@tripeaks.co.jp> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11787 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: sshtylyov@ru.mvista.com Precedence: bulk X-list: linux-mips Hello. Yoichi Yuasa wrote: >>>Also the folowing boards don't have config file. >>>Toshiba TBTX49[23]7 >> I've pushed some patches for those resently... > Can you provide config file for TBTX49[23]7 ? Maybe later -- I'M SWAMPED... :-( > How about JMR-TX3927? Well, I've sent a patch for it last autumn but it looks like this is a candidate for removal indeed. MV is not going to support that kernel anymore... > Yoichi WBR, Sergei From yoichi_yuasa@tripeaks.co.jp Tue Jun 20 15:55:23 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 20 Jun 2006 15:55:32 +0100 (BST) Received: from mo31.po.2iij.net ([210.128.50.54]:52792 "EHLO mo31.po.2iij.net") by ftp.linux-mips.org with ESMTP id S8133775AbWFTOzX (ORCPT ); Tue, 20 Jun 2006 15:55:23 +0100 Received: by mo.po.2iij.net (mo31) id k5KEtLdV016324; Tue, 20 Jun 2006 23:55:21 +0900 (JST) Received: from localhost.localdomain (225.29.30.125.dy.iij4u.or.jp [125.30.29.225]) by mbox.po.2iij.net (mbox32) id k5KEtJV2039635 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 20 Jun 2006 23:55:19 +0900 (JST) Date: Tue, 20 Jun 2006 23:55:17 +0900 From: Yoichi Yuasa To: Ralf Baechle Cc: linux-mips@linux-mips.org Subject: [PATCH] remove first timer interrupt setup in wrppmc_timer_setup() Message-Id: <20060620235517.504d31a1.yoichi_yuasa@tripeaks.co.jp> Organization: TriPeaks Corporation X-Mailer: Sylpheed version 1.0.4 (GTK+ 1.2.10; i386-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11788 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: yoichi_yuasa@tripeaks.co.jp Precedence: bulk X-list: linux-mips Hi, This patch removes first timer interrupt setup in wrppmc_timer_setup(). The first timer interrupt setup already includes in time_init(). Yoichi Signed-off-by: Yoichi Yuasa diff -pruN -X mips/Documentation/dontdiff mips-orig/arch/mips/gt64120/wrppmc/time.c mips/arch/mips/gt64120/wrppmc/time.c --- mips-orig/arch/mips/gt64120/wrppmc/time.c 2006-06-20 21:17:36.853537000 +0900 +++ mips/arch/mips/gt64120/wrppmc/time.c 2006-06-20 23:29:16.157391500 +0900 @@ -31,10 +31,6 @@ void __init wrppmc_timer_setup(struct ir { /* Install ISR for timer interrupt */ setup_irq(WRPPMC_MIPS_TIMER_IRQ, irq); - - /* to generate the first timer interrupt */ - write_c0_compare(mips_hpt_frequency/HZ); - write_c0_count(0); } /* From yoichi_yuasa@tripeaks.co.jp Tue Jun 20 15:55:58 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 20 Jun 2006 15:56:20 +0100 (BST) Received: from mo32.po.2iij.net ([210.128.50.17]:20007 "EHLO mo32.po.2iij.net") by ftp.linux-mips.org with ESMTP id S8133785AbWFTOza (ORCPT ); Tue, 20 Jun 2006 15:55:30 +0100 Received: by mo.po.2iij.net (mo32) id k5KEtSQG007476; Tue, 20 Jun 2006 23:55:28 +0900 (JST) Received: from localhost.localdomain (225.29.30.125.dy.iij4u.or.jp [125.30.29.225]) by mbox.po.2iij.net (mbox32) id k5KEtPB6039661 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 20 Jun 2006 23:55:26 +0900 (JST) Date: Tue, 20 Jun 2006 23:55:24 +0900 From: Yoichi Yuasa To: Ralf Baechle Cc: linux-mips@linux-mips.org Subject: [PATCH] remove CONFIG_VR4181 Message-Id: <20060620235524.4734ebb9.yoichi_yuasa@tripeaks.co.jp> Organization: TriPeaks Corporation X-Mailer: Sylpheed version 1.0.4 (GTK+ 1.2.10; i386-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11789 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: yoichi_yuasa@tripeaks.co.jp Precedence: bulk X-list: linux-mips Hi, This patch removes CONFIG_VR4181. VR4181 support was already removed. Yoichi Signed-off-by: Yoichi Yuasa diff -pruN -X mips-rc6/Documentation/dontdiff mips-rc6-orig/arch/mips/Kconfig mips-rc6/arch/mips/Kconfig --- mips-rc6-orig/arch/mips/Kconfig 2006-06-09 00:32:57.197212500 +0900 +++ mips-rc6/arch/mips/Kconfig 2006-06-09 00:40:07.424100000 +0900 @@ -1040,9 +1040,6 @@ config MIPS_L1_CACHE_SHIFT config HAVE_STD_PC_SERIAL_PORT bool -config VR4181 - bool - config ARC_CONSOLE bool "ARC console support" depends on SGI_IP22 || SNI_RM200_PCI diff -pruN -X mips-rc6/Documentation/dontdiff mips-rc6-orig/arch/mips/kernel/cpu-probe.c mips-rc6/arch/mips/kernel/cpu-probe.c --- mips-rc6-orig/arch/mips/kernel/cpu-probe.c 2006-06-09 00:32:57.257216250 +0900 +++ mips-rc6/arch/mips/kernel/cpu-probe.c 2006-06-09 00:41:06.347782500 +0900 @@ -250,15 +250,9 @@ static inline void cpu_probe_legacy(stru break; case PRID_IMP_VR41XX: switch (c->processor_id & 0xf0) { -#ifndef CONFIG_VR4181 case PRID_REV_VR4111: c->cputype = CPU_VR4111; break; -#else - case PRID_REV_VR4181: - c->cputype = CPU_VR4181; - break; -#endif case PRID_REV_VR4121: c->cputype = CPU_VR4121; break; From anemo@mba.ocn.ne.jp Tue Jun 20 15:58:09 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 20 Jun 2006 15:58:19 +0100 (BST) Received: from mba.ocn.ne.jp ([210.190.142.172]:48600 "HELO smtp.mba.ocn.ne.jp") by ftp.linux-mips.org with SMTP id S8133798AbWFTO6J (ORCPT ); Tue, 20 Jun 2006 15:58:09 +0100 Received: from localhost (p6234-ipad209funabasi.chiba.ocn.ne.jp [58.88.117.234]) by smtp.mba.ocn.ne.jp (Postfix) with ESMTP id 3D6ACB9A7; Tue, 20 Jun 2006 23:58:05 +0900 (JST) Date: Tue, 20 Jun 2006 23:59:11 +0900 (JST) Message-Id: <20060620.235911.132303870.anemo@mba.ocn.ne.jp> To: linux-mips@linux-mips.org Cc: ralf@linux-mips.org Subject: Re: fix FIXADDR_TOP for TX39/TX49 From: Atsushi Nemoto In-Reply-To: <20030517.214555.74756802.anemo@mba.ocn.ne.jp> References: <20030517.214555.74756802.anemo@mba.ocn.ne.jp> X-Fingerprint: 6ACA 1623 39BD 9A94 9B1A B746 CA77 FE94 2874 D52F X-Pgp-Public-Key: http://wwwkeys.pgp.net/pks/lookup?op=get&search=0x2874D52F X-Mailer: Mew version 3.3 on Emacs 21.4 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11790 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: anemo@mba.ocn.ne.jp Precedence: bulk X-list: linux-mips On Sat, 17 May 2003 21:45:55 +0900 (JST), Atsushi Nemoto wrote: > This patch fixes FIXADDR_TOP for TX39/TX49. FIXADDR_TOP is used not > only if CONFIG_HIGHMEM is enabled. It is also used for high limit > address for vmalloc. Now this patch is 3 years old :-) Updated. FIXADDR_TOP is used for HIGHMEM and for upper limit of vmalloc area on 32bit kernel. TX39XX and TX49XX have "reserved" segment in CKSEG3 area. 0xff000000-0xff3fffff on TX49XX and 0xff000000-0xfffeffff on TX39XX are reserved (unmapped, uncached) therefore can not be used as mapped area. Signed-off-by: Atsushi Nemoto diff --git a/include/asm-mips/fixmap.h b/include/asm-mips/fixmap.h index 73a3028..c7f4ee1 100644 --- a/include/asm-mips/fixmap.h +++ b/include/asm-mips/fixmap.h @@ -70,7 +70,11 @@ #define set_fixmap_nocache(idx, phys) \ * the start of the fixmap, and leave one page empty * at the top of mem.. */ +#if defined(CONFIG_CPU_TX39XX) || defined(CONFIG_CPU_TX49XX) +#define FIXADDR_TOP (0xff000000UL - 0x2000) +#else #define FIXADDR_TOP (0xffffe000UL) +#endif #define FIXADDR_SIZE (__end_of_fixed_addresses << PAGE_SHIFT) #define FIXADDR_START (FIXADDR_TOP - FIXADDR_SIZE) From ivan.korzakow@gmail.com Tue Jun 20 16:14:06 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 20 Jun 2006 16:14:17 +0100 (BST) Received: from ug-out-1314.google.com ([66.249.92.170]:46574 "EHLO ug-out-1314.google.com") by ftp.linux-mips.org with ESMTP id S8134001AbWFTPOG (ORCPT ); Tue, 20 Jun 2006 16:14:06 +0100 Received: by ug-out-1314.google.com with SMTP id k3so3213992ugf for ; Tue, 20 Jun 2006 08:14:03 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=joWs+YBjs1nG4sASRcfMyO8p1D794wybsr0uAgG5Jev+PRVuWwfsewKv0XPB1kGrPBDOHf6Uje+IGAlKoZJiJwYDlkbEjSZpIkrXhyP4aUG5mqj5G1GHZzTM4LfQW+Sjt0MO2K5sbArcohNoyxSohnLsMhKI4etFwY/07XzjhIA= Received: by 10.67.89.5 with SMTP id r5mr2499361ugl; Tue, 20 Jun 2006 08:14:03 -0700 (PDT) Received: by 10.67.24.1 with HTTP; Tue, 20 Jun 2006 08:14:02 -0700 (PDT) Message-ID: Date: Tue, 20 Jun 2006 17:14:02 +0200 From: "Ivan Korzakow" To: "Ralf Baechle" Subject: Re: Merge window ... Cc: linux-mips@linux-mips.org In-Reply-To: <20060619103653.GA4257@linux-mips.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20060619103653.GA4257@linux-mips.org> Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11791 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ivan.korzakow@gmail.com Precedence: bulk X-list: linux-mips 2006/6/19, Ralf Baechle : > Just a reminder that 2.6.17 is out and as usual there is now a merge > window of two weeks, so try anything that you wish to see to go to > Linus to me asap ... Does that mean that MIPS, eventually, is doing like others arch for releasing ? If so does that mean that we can get a MIPS kernel from Linus tree without pulling from the (huge) mips repo ? Ivan. From ralf@linux-mips.org Tue Jun 20 16:29:27 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 20 Jun 2006 16:29:35 +0100 (BST) Received: from localhost.localdomain ([127.0.0.1]:46033 "EHLO bacchus.dhis.org") by ftp.linux-mips.org with ESMTP id S8133789AbWFTP31 (ORCPT ); Tue, 20 Jun 2006 16:29:27 +0100 Received: from denk.linux-mips.net (denk.linux-mips.net [127.0.0.1]) by bacchus.dhis.org (8.13.6/8.13.4) with ESMTP id k5KFTRtF019345; Tue, 20 Jun 2006 16:29:27 +0100 Received: (from ralf@localhost) by denk.linux-mips.net (8.13.6/8.13.6/Submit) id k5KFTQg8019344; Tue, 20 Jun 2006 16:29:26 +0100 Date: Tue, 20 Jun 2006 16:29:26 +0100 From: Ralf Baechle To: Ivan Korzakow Cc: linux-mips@linux-mips.org Subject: Re: Merge window ... Message-ID: <20060620152926.GA19154@linux-mips.org> References: <20060619103653.GA4257@linux-mips.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11792 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ralf@linux-mips.org Precedence: bulk X-list: linux-mips On Tue, Jun 20, 2006 at 05:14:02PM +0200, Ivan Korzakow wrote: > Does that mean that MIPS, eventually, is doing like others arch for > releasing ? If so does that mean that we can get a MIPS kernel from > Linus tree without pulling from the (huge) mips repo ? For some systems that is working since quite a while already. For some of the other platforms (Alchemy, Sibyte to name the biggest offenders) kernel.org won't have a chance of working until somebody rewrites the bloddy drivers for those things into something that actually can be merged. Ralf From Rajesh_Palani@pmc-sierra.com Tue Jun 20 17:16:23 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 20 Jun 2006 17:16:35 +0100 (BST) Received: from mother.pmc-sierra.com ([216.241.224.12]:27539 "HELO mother.pmc-sierra.bc.ca") by ftp.linux-mips.org with SMTP id S8133792AbWFTQQX (ORCPT ); Tue, 20 Jun 2006 17:16:23 +0100 Received: (qmail 18696 invoked by uid 101); 20 Jun 2006 16:16:11 -0000 Received: from unknown (HELO ogmios.pmc-sierra.bc.ca) (216.241.226.59) by mother.pmc-sierra.com with SMTP; 20 Jun 2006 16:16:11 -0000 Received: from bby1exi01.pmc_nt.nt.pmc-sierra.bc.ca (bby1exi01.pmc-sierra.bc.ca [216.241.231.251]) by ogmios.pmc-sierra.bc.ca (8.13.3/8.12.7) with ESMTP id k5KGG5Os023067; Tue, 20 Jun 2006 09:16:10 -0700 Received: by bby1exi01.pmc-sierra.bc.ca with Internet Mail Service (5.5.2656.59) id ; Tue, 20 Jun 2006 09:16:05 -0700 Message-ID: <478F19F21671F04298A2116393EEC3D531D2D4@sjc1exm08.pmc_nt.nt.pmc-sierra.bc.ca> From: Raj Palani To: Ralf Baechle , Roman Mashak Cc: linux-mips@linux-mips.org Subject: RE: Ethernet bridging on 2.6.12-rc3 (PMC-sierra patched) Date: Tue, 20 Jun 2006 09:15:56 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11793 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: Rajesh_Palani@pmc-sierra.com Precedence: bulk X-list: linux-mips Hi Ralf and Roman, > > The Titan driver (the version on linux-mips.org and any other > version I've > seen) are pretty broken and remarkably ugly pieces of code. > The authors of the Basler eXcite platform have contributed > their driver and I hope it will show up upstream soon. Afaik > it has not been tested with any of PMC's eval boards but the > necessary changes should not be hard. I would request that you take a look at our current GE driver (msp85x0_ge.c) for the Sequoia platform and send us your feedback. This is currently available on our ftp site ftp.pmc-sierra.com under /pub/linux/2.6.12/linux-2.6.12-rc3_L002.tar.gz. The driver has been completely re-written and we welcome any feedback on the same. The patches that have been generated for fixes that were made after this release are available under /pub/linux/2.6.12/patches-2.6.12-rc3_L002. We are in the process of generating a patch for the Sequoia platform (for the MSP85x0) to be submitted to Linux/MIPS. Note that we will be having a separate GE driver for the MSP85x0, while the old Titan GE driver (titan_ge.c) would support the Titan (RM912x) chip on the Yosemite platform. FYI, the MSP85x0 is the new name for the RM915x device. -Raj From ralf@linux-mips.org Tue Jun 20 17:45:45 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 20 Jun 2006 17:45:54 +0100 (BST) Received: from localhost.localdomain ([127.0.0.1]:36243 "EHLO bacchus.dhis.org") by ftp.linux-mips.org with ESMTP id S8133474AbWFTQpp (ORCPT ); Tue, 20 Jun 2006 17:45:45 +0100 Received: from denk.linux-mips.net (denk.linux-mips.net [127.0.0.1]) by bacchus.dhis.org (8.13.6/8.13.4) with ESMTP id k5KGjesV027069; Tue, 20 Jun 2006 17:45:40 +0100 Received: (from ralf@localhost) by denk.linux-mips.net (8.13.6/8.13.6/Submit) id k5KGjZJo027066; Tue, 20 Jun 2006 17:45:35 +0100 Date: Tue, 20 Jun 2006 17:45:35 +0100 From: Ralf Baechle To: Raj Palani Cc: Roman Mashak , linux-mips@linux-mips.org Subject: Re: Ethernet bridging on 2.6.12-rc3 (PMC-sierra patched) Message-ID: <20060620164535.GA25120@linux-mips.org> References: <478F19F21671F04298A2116393EEC3D531D2D4@sjc1exm08.pmc_nt.nt.pmc-sierra.bc.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <478F19F21671F04298A2116393EEC3D531D2D4@sjc1exm08.pmc_nt.nt.pmc-sierra.bc.ca> User-Agent: Mutt/1.4.2.1i Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11794 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ralf@linux-mips.org Precedence: bulk X-list: linux-mips On Tue, Jun 20, 2006 at 09:15:56AM -0700, Raj Palani wrote: > > The Titan driver (the version on linux-mips.org and any other > > version I've > > seen) are pretty broken and remarkably ugly pieces of code. > > The authors of the Basler eXcite platform have contributed > > their driver and I hope it will show up upstream soon. Afaik > > it has not been tested with any of PMC's eval boards but the > > necessary changes should not be hard. > > I would request that you take a look at our current GE driver (msp85x0_ge.c) for the Sequoia platform and send us your feedback. This is currently available on our ftp site ftp.pmc-sierra.com under /pub/linux/2.6.12/linux-2.6.12-rc3_L002.tar.gz. The driver has been completely re-written and we welcome any feedback on the same. > > The patches that have been generated for fixes that were made after this release are available under /pub/linux/2.6.12/patches-2.6.12-rc3_L002. > > We are in the process of generating a patch for the Sequoia platform (for the MSP85x0) to be submitted to Linux/MIPS. Note that we will be having a separate GE driver for the MSP85x0, while the old Titan GE driver (titan_ge.c) would support the Titan (RM912x) chip on the Yosemite platform. FYI, the MSP85x0 is the new name for the RM915x device. Unless my memory is wrong Seqoia and Yosemite have the same ethernet controller, so why two drivers? Ralf From Rajesh_Palani@pmc-sierra.com Tue Jun 20 18:08:10 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 20 Jun 2006 18:08:20 +0100 (BST) Received: from mother.pmc-sierra.com ([216.241.224.12]:7581 "HELO mother.pmc-sierra.bc.ca") by ftp.linux-mips.org with SMTP id S8133474AbWFTRIK (ORCPT ); Tue, 20 Jun 2006 18:08:10 +0100 Received: (qmail 2664 invoked by uid 101); 20 Jun 2006 17:08:03 -0000 Received: from unknown (HELO ogyruan.pmc-sierra.bc.ca) (216.241.226.236) by mother.pmc-sierra.com with SMTP; 20 Jun 2006 17:08:03 -0000 Received: from bby1exi01.pmc_nt.nt.pmc-sierra.bc.ca (bby1exi01.pmc-sierra.bc.ca [216.241.231.251]) by ogyruan.pmc-sierra.bc.ca (8.13.3/8.12.7) with ESMTP id k5KH82j4022376; Tue, 20 Jun 2006 10:08:02 -0700 Received: by bby1exi01.pmc-sierra.bc.ca with Internet Mail Service (5.5.2656.59) id ; Tue, 20 Jun 2006 10:08:02 -0700 Message-ID: <478F19F21671F04298A2116393EEC3D531D2F8@sjc1exm08.pmc_nt.nt.pmc-sierra.bc.ca> From: Raj Palani To: Ralf Baechle Cc: Roman Mashak , linux-mips@linux-mips.org Subject: RE: Ethernet bridging on 2.6.12-rc3 (PMC-sierra patched) Date: Tue, 20 Jun 2006 10:07:59 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11795 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: Rajesh_Palani@pmc-sierra.com Precedence: bulk X-list: linux-mips Hi Ralf, > Unless my memory is wrong Seqoia and Yosemite have the same > ethernet controller, so why two drivers? They have similar, but not the same ethernet controller and they are different enough to qualify having separate drivers. We found that maintaining both of them with #ifdef's all over the code, was simply not the right way to go about. -Raj From mrv@corecom.co.kr Wed Jun 21 01:35:07 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 21 Jun 2006 01:35:16 +0100 (BST) Received: from [220.76.242.187] ([220.76.242.187]:20146 "EHLO localhost.localdomain") by ftp.linux-mips.org with ESMTP id S8133814AbWFUAfH (ORCPT ); Wed, 21 Jun 2006 01:35:07 +0100 Received: from mrv ([192.168.11.157]) by localhost.localdomain (8.12.8/8.12.8) with SMTP id k5L0a0YV002194; Wed, 21 Jun 2006 09:36:18 +0900 Message-ID: <001401c694ca$8cb8e530$9d0ba8c0@mrv> From: "Roman Mashak" To: "Raj Palani" , "Ralf Baechle" Cc: References: <478F19F21671F04298A2116393EEC3D531D2D4@sjc1exm08.pmc_nt.nt.pmc-sierra.bc.ca> Subject: Re: Ethernet bridging on 2.6.12-rc3 (PMC-sierra patched) Date: Wed, 21 Jun 2006 09:34:52 +0900 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="koi8-r"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 FL-Build: Fidolook 2002 (SL) 6.0.2800.86 - 14/6/2003 22:16:25 Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11796 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: mrv@corecom.co.kr Precedence: bulk X-list: linux-mips Hello, Raj! You wrote to "Ralf Baechle" ; "Roman Mashak" on Tue, 20 Jun 2006 09:15:56 -0700: RP> I would request that you take a look at our current GE driver RP> (msp85x0_ge.c) for the Sequoia platform and send us your feedback. RP> This is currently available on our ftp site ftp.pmc-sierra.com under RP> /pub/linux/2.6.12/linux-2.6.12-rc3_L002.tar.gz. The driver has been RP> completely re-written and we welcome any feedback on the same. As you could notice in my first message in this thread I reffered to 2.6.12-rc3_L002 from PMC ftp site. And Ethernet bridging behavior I described is occurring at that particular kernel. RP> The patches that have been generated for fixes that were made after RP> this release are available under RP> /pub/linux/2.6.12/patches-2.6.12-rc3_L002. With best regards, Roman Mashak. E-mail: mrv@corecom.co.kr From rongkai.zhan@windriver.com Wed Jun 21 04:33:43 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 21 Jun 2006 04:33:54 +0100 (BST) Received: from mail.windriver.com ([147.11.1.11]:44450 "EHLO mail.wrs.com") by ftp.linux-mips.org with ESMTP id S8126578AbWFUDdn convert rfc822-to-8bit (ORCPT ); Wed, 21 Jun 2006 04:33:43 +0100 Received: from ALA-MAIL03.corp.ad.wrs.com (ala-mail03 [147.11.57.144]) by mail.wrs.com (8.13.6/8.13.3) with ESMTP id k5L3XRUa013024; Tue, 20 Jun 2006 20:33:27 -0700 (PDT) Received: from ism-mail01.corp.ad.wrs.com ([147.11.96.20]) by ALA-MAIL03.corp.ad.wrs.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 20 Jun 2006 20:33:27 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8BIT Subject: RE: [PATCH] remove set_c0_status(ST0_IM) form wrppmc's irq.c Date: Wed, 21 Jun 2006 05:33:24 +0200 Message-ID: <6A3254532ACD7A42805B4E1BFD18080E01039084@ism-mail01.corp.ad.wrs.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PATCH] remove set_c0_status(ST0_IM) form wrppmc's irq.c Thread-Index: AcaUdbEr7xyLSp30RouA4twIDn3CfgAbU+rQ From: "Zhan, Rongkai" To: "Yoichi Yuasa" Cc: "Ralf Baechle" , X-OriginalArrivalTime: 21 Jun 2006 03:33:27.0814 (UTC) FILETIME=[7599D260:01C694E3] Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11797 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: rongkai.zhan@windriver.com Precedence: bulk X-list: linux-mips Hi Yiochi, Yes. You are right. To Ralf: Please consider the codes for wrppmc board go into the current merge window. Thanks. Best Regards, Mark. Zhan -----Original Message----- From: linux-mips-bounce@linux-mips.org [mailto:linux-mips-bounce@linux-mips.org] On Behalf Of Yoichi Yuasa Sent: Tuesday, June 20, 2006 10:27 PM To: Ralf Baechle Cc: linux-mips@linux-mips.org Subject: [PATCH] remove set_c0_status(ST0_IM) form wrppmc's irq.c Hi, mips_cpu_irq_init() does clear_c0_status(ST0_IM) first. I think that set_c0_status(ST0_IM) isn't necessary. Yoichi Signed-off-by: Yoichi Yuasa diff -pruN -X mips/Documentation/dontdiff mips-orig/arch/mips/gt64120/wrppmc/irq.c mips/arch/mips/gt64120/wrppmc/irq.c --- mips-orig/arch/mips/gt64120/wrppmc/irq.c 2006-06-20 21:17:36.853537000 +0900 +++ mips/arch/mips/gt64120/wrppmc/irq.c 2006-06-20 21:36:41.949101000 +0900 @@ -62,9 +62,6 @@ void gt64120_init_pic(void) void __init arch_init_irq(void) { - /* enable all CPU interrupt bits. */ - set_c0_status(ST0_IM); /* IE bit is still 0 */ - /* IRQ 0 - 7 are for MIPS common irq_cpu controller */ mips_cpu_irq_init(0); From ankur_maheshwari@procsys.com Wed Jun 21 06:36:32 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 21 Jun 2006 06:36:41 +0100 (BST) Received: from dsl-KK-static-026.199.95.61.touchtelindia.net ([61.95.199.26]:17118 "EHLO mailsvr.procsys.com") by ftp.linux-mips.org with ESMTP id S8133364AbWFUFgc (ORCPT ); Wed, 21 Jun 2006 06:36:32 +0100 Received: from ankurmaheshwari ([192.168.1.243]) by mailsvr.procsys.com (8.12.10/8.12.10) with SMTP id k5L59hJ7030011; Wed, 21 Jun 2006 10:39:44 +0530 Message-ID: <110701c694f4$f1412fb0$f301a8c0@procsys> From: "ankur maheshwari" To: "Jean Delvare" , "Pete Popov" Cc: , References: <20060615225723.012c82be.khali@linux-fr.org><1150406598.1193.73.camel@localhost.localdomain><20060616222908.f96e3691.khali@linux-fr.org><1150735558.8413.7.camel@localhost.localdomain> <20060620120836.628ddc79.khali@linux-fr.org> Subject: Re: i2c-algo-ite and i2c-ite planned for removal Date: Wed, 21 Jun 2006 11:08:34 +0530 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-ProcSys-Com-Anti-Virus-Mail-Filter-Virus-Found: no Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11798 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ankur_maheshwari@procsys.com Precedence: bulk X-list: linux-mips hi all, I have used once i2c-adap-ite and i2c-algo-ite for ite-8712 chip and it worked fine for me in MV 2.4.25. Its been an year ago, I asked on same forum if some one has used it before but I didn't got any reply. I added this struct definition in a .h (i2c-adap-ite.h) file which we need to include in i2c-adap-ite.c also program ite-8712 controller pins for i2c use. struct iic_ite { int iic_base; int iic_irq; int iic_clock; int iic_own; }; It worked perfectly fine for me. It's just an info on ite-chip works, to remove it from kernel tree ..... decision is up to you : ). thanks, Ankur ----- Original Message ----- From: "Jean Delvare" To: "Pete Popov" Cc: ; Sent: Tuesday, June 20, 2006 3:38 PM Subject: Re: i2c-algo-ite and i2c-ite planned for removal > Hi Pete, > > > > > For historical correctness, this driver was once upon a time usable, > > > > though it was a few years ago. It was written by MV for some ref board > > > > that had the ITE chip and it did work. That ref board is no longer > > > > around so it's probably safe to nuke the driver. > > > > > > In which kernel version? In every version I checked (2.4.12, 2.4.30, > > > 2.6.0 and 2.6.16) it wouldn't compile due to struct iic_ite being used > > > but never defined (and possibly other errors, but I can't test-compile > > > the driver.) > > > > Honestly, I don't remember. I think it was one of the very first 2.6 > > kernels because when MV first released a 2.6 product, 2.6 was still > > 'experimental'. It's quite possible of course that the driver was never > > properly merged upstream in the community tree(s). But I do know that it > > worked in the internal MV tree and an effort was made to get the driver > > accepted upstream. > > I couldn't find any evidence of this effort. Whatever, past is past, if > someone fixes the i2c-ite and i2c-algo-ite drivers soon, fine with me, > if not, the drivers will be deleted (which doesn't mean they can't be > resurrected later if there is interest and someone takes over > maintenance.) I'm setting the deadline to September 2006. > > -- > Jean Delvare From Rajesh_Palani@pmc-sierra.com Wed Jun 21 08:01:15 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 21 Jun 2006 08:01:25 +0100 (BST) Received: from father.pmc-sierra.com ([216.241.224.13]:37513 "HELO father.pmc-sierra.bc.ca") by ftp.linux-mips.org with SMTP id S8126482AbWFUHBP (ORCPT ); Wed, 21 Jun 2006 08:01:15 +0100 Received: (qmail 256 invoked by uid 101); 21 Jun 2006 07:01:04 -0000 Received: from unknown (HELO ogyruan.pmc-sierra.bc.ca) (216.241.226.236) by father.pmc-sierra.com with SMTP; 21 Jun 2006 07:01:04 -0000 Received: from bby1exi01.pmc_nt.nt.pmc-sierra.bc.ca (bby1exi01.pmc-sierra.bc.ca [216.241.231.251]) by ogyruan.pmc-sierra.bc.ca (8.13.3/8.12.7) with ESMTP id k5L714is023925; Wed, 21 Jun 2006 00:01:04 -0700 Received: by bby1exi01.pmc-sierra.bc.ca with Internet Mail Service (5.5.2656.59) id ; Wed, 21 Jun 2006 00:01:03 -0700 Message-ID: <478F19F21671F04298A2116393EEC3D51C29CF@sjc1exm08.pmc_nt.nt.pmc-sierra.bc.ca> From: Raj Palani To: "'Roman Mashak'" , Ralf Baechle Cc: linux-mips@linux-mips.org Subject: RE: Ethernet bridging on 2.6.12-rc3 (PMC-sierra patched) Date: Wed, 21 Jun 2006 00:01:01 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11799 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: Rajesh_Palani@pmc-sierra.com Precedence: bulk X-list: linux-mips Hi Roman, Just wanted to make sure that you had applied the patch mentioned in my earlier e-mail on top of the linux-2.6.12-rc3_L002.tar.gz release. -Raj -----Original Message----- From: Roman Mashak [mailto:mrv@corecom.co.kr] Sent: Tuesday, June 20, 2006 5:35 PM To: Raj Palani; Ralf Baechle Cc: linux-mips@linux-mips.org Subject: Re: Ethernet bridging on 2.6.12-rc3 (PMC-sierra patched) Hello, Raj! You wrote to "Ralf Baechle" ; "Roman Mashak" on Tue, 20 Jun 2006 09:15:56 -0700: RP> I would request that you take a look at our current GE driver RP> (msp85x0_ge.c) for the Sequoia platform and send us your feedback. RP> This is currently available on our ftp site ftp.pmc-sierra.com under RP> /pub/linux/2.6.12/linux-2.6.12-rc3_L002.tar.gz. The driver has been RP> completely re-written and we welcome any feedback on the same. As you could notice in my first message in this thread I reffered to 2.6.12-rc3_L002 from PMC ftp site. And Ethernet bridging behavior I described is occurring at that particular kernel. RP> The patches that have been generated for fixes that were made after RP> this release are available under RP> /pub/linux/2.6.12/patches-2.6.12-rc3_L002. With best regards, Roman Mashak. E-mail: mrv@corecom.co.kr From domen.puncer@ultra.si Wed Jun 21 10:52:01 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 21 Jun 2006 10:52:14 +0100 (BST) Received: from deliver-1.mx.triera.net ([213.161.0.31]:48611 "HELO deliver-1.mx.triera.net") by ftp.linux-mips.org with SMTP id S8133419AbWFUJwB (ORCPT ); Wed, 21 Jun 2006 10:52:01 +0100 Received: from localhost (in-2.mx.triera.net [213.161.0.26]) by deliver-1.mx.triera.net (Postfix) with ESMTP id BB4D6C0FB; Wed, 21 Jun 2006 11:51:46 +0200 (CEST) Received: from smtp.triera.net (smtp.triera.net [213.161.0.30]) by in-2.mx.triera.net (Postfix) with SMTP id DB8831BC08F; Wed, 21 Jun 2006 11:51:47 +0200 (CEST) Received: from localhost (unknown [213.161.20.162]) by smtp.triera.net (Postfix) with ESMTP id D403F1A18AB; Wed, 21 Jun 2006 11:51:48 +0200 (CEST) Date: Wed, 21 Jun 2006 11:51:50 +0200 From: Domen Puncer To: Ralf Baechle Cc: Kumba , linux-mips@linux-mips.org Subject: Re: Commit 78eef01b0fae087c5fadbd85dd4fe2918c3a015f (on_each_cpu(): disable local interrupts) Breaks SGI IP32 Message-ID: <20060621095150.GO5568@domen.ultra.si> References: <4478C0F1.8000006@gentoo.org> <20060528010603.GA24997@linux-mips.org> <20060527194243.a8157338.akpm@osdl.org> <4479250E.3080604@gentoo.org> <20060528105014.GA28621@linux-mips.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060528105014.GA28621@linux-mips.org> User-Agent: Mutt/1.5.11+cvs20060126 X-Virus-Scanned: Triera AV Service Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11800 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: domen.puncer@ultra.si Precedence: bulk X-list: linux-mips Hi! (removed akpm from CC, as he's probably no longer interested) On 28/05/06 11:50 +0100, Ralf Baechle wrote: > On Sun, May 28, 2006 at 12:20:30AM -0400, Kumba wrote: > > It also seems this was affecting AMD Alchemy-based systems too. Other SGI > > machines are known to work fine, except Indy and Indigo2, as I haven't > > tested those yet. > > IP27 is fine but it's SMP but I've already cleaned out all the early > calls to smp_call_function there were shown by the WARN() ages ago. > > You can do it the same way, use this debugging version of on_each_cpu: > > #define on_each_cpu(func,info,retry,wait) \ > ({ \ > WARN_ON(irqs_disabled()); \ > func(info); \ > 0; \ > }) On Alchemy au1200 this produces: [4294667.296000] Synthesized TLB modify handler fastpath (33 instructions). [4294667.296000] Badness in r4k_flush_icache_range at /home/domen/tmp/linux-2.6.bisecting/linux-mips.git/arch/mips/mm/c-r4k.c:516 [4294667.296000] Call Trace: [4294667.296000] [<80113434>] r4k_flush_icache_range+0x144/0x150 [4294667.296000] [<803f0000>] inflate_dynamic+0x634/0x70c [4294667.296000] [<803f3630>] trap_init+0x3c/0x440 [4294667.296000] [<803f3630>] trap_init+0x3c/0x440 [4294667.296000] [<8025f3dc>] sort_extable+0x24/0x30 [4294667.296000] [<803ed6d4>] start_kernel+0xc8/0x20c [4294667.296000] [<803ed6c4>] start_kernel+0xb8/0x20c [4294667.296000] [<803ed12c>] unknown_bootoption+0x0/0x310 [4294667.296000] [4294667.296000] Badness in r4k_flush_icache_range at /home/domen/tmp/linux-2.6.bisecting/linux-mips.git/arch/mips/mm/c-r4k.c:516 [4294667.296000] Call Trace: [4294667.296000] [<8010b16c>] dump_stack+0x14/0x20 [4294667.296000] [<80113434>] r4k_flush_icache_range+0x144/0x150 [4294667.296000] [<803f0000>] inflate_dynamic+0x634/0x70c [4294667.296000] [<8010cb78>] set_except_vector+0x88/0xa0 [4294667.296000] [<803f0000>] inflate_dynamic+0x634/0x70c [4294667.296000] [<803f3648>] trap_init+0x54/0x440 [4294667.296000] [<8025f3dc>] sort_extable+0x24/0x30 [4294667.296000] [<803ed6d4>] start_kernel+0xc8/0x20c [4294667.296000] [<803ed6c4>] start_kernel+0xb8/0x20c [4294667.296000] [<803ed12c>] unknown_bootoption+0x0/0x310 [4294667.296000] [4294667.296000] Badness in r4k_flush_icache_range at /home/domen/tmp/linux-2.6.bisecting/linux-mips.git/arch/mips/mm/c-r4k.c:516 [4294667.296000] Call Trace: [4294667.296000] [<80113434>] r4k_flush_icache_range+0x144/0x150 [4294667.296000] [<803f0000>] inflate_dynamic+0x634/0x70c [4294667.296000] [<803f395c>] trap_init+0x368/0x440 [4294667.296000] [<803f395c>] trap_init+0x368/0x440 [4294667.296000] [<8025f3dc>] sort_extable+0x24/0x30 [4294667.296000] [<803ed6d4>] start_kernel+0xc8/0x20c [4294667.296000] [<803ed6c4>] start_kernel+0xb8/0x20c [4294667.296000] [<803ed12c>] unknown_bootoption+0x0/0x310 [4294667.296000] [4294667.296000] Badness in r4k_flush_icache_range at /home/domen/tmp/linux-2.6.bisecting/linux-mips.git/arch/mips/mm/c-r4k.c:516 [4294667.296000] Call Trace: [4294667.296000] [<80113434>] r4k_flush_icache_range+0x144/0x150 [4294667.296000] [<803f0000>] inflate_dynamic+0x634/0x70c [4294667.296000] [<803f38c8>] trap_init+0x2d4/0x440 [4294667.296000] [<803f39dc>] trap_init+0x3e8/0x440 [4294667.296000] [<8025f3dc>] sort_extable+0x24/0x30 [4294667.296000] [<803ed6d4>] start_kernel+0xc8/0x20c [4294667.296000] [<803ed6c4>] start_kernel+0xb8/0x20c [4294667.296000] [<803ed12c>] unknown_bootoption+0x0/0x310 [4294667.296000] [4294667.296000] Badness in r4k_flush_icache_range at /home/domen/tmp/linux-2.6.bisecting/linux-mips.git/arch/mips/mm/c-r4k.c:516 [4294667.296000] Call Trace: [4294667.296000] [<80113434>] r4k_flush_icache_range+0x144/0x150 [4294667.296000] [<803f5edc>] flush_tlb_handlers+0x28/0x64 [4294667.296000] [<803ed6d4>] start_kernel+0xc8/0x20c [4294667.296000] [<803ed12c>] unknown_bootoption+0x0/0x310 [4294667.296000] [4294667.296000] Badness in r4k_flush_icache_range at /home/domen/tmp/linux-2.6.bisecting/linux-mips.git/arch/mips/mm/c-r4k.c:516 [4294667.296000] Call Trace: [4294667.296000] [<80113434>] r4k_flush_icache_range+0x144/0x150 [4294667.296000] [<803f5ef4>] flush_tlb_handlers+0x40/0x64 [4294667.296000] [<803ed6d4>] start_kernel+0xc8/0x20c [4294667.296000] [<803ed12c>] unknown_bootoption+0x0/0x310 [4294667.296000] [4294667.296000] Badness in r4k_flush_icache_range at /home/domen/tmp/linux-2.6.bisecting/linux-mips.git/arch/mips/mm/c-r4k.c:516 [4294667.296000] Call Trace: [4294667.296000] [<80113434>] r4k_flush_icache_range+0x144/0x150 [4294667.296000] [<803ed6d4>] start_kernel+0xc8/0x20c [4294667.296000] [<803ed6d4>] start_kernel+0xc8/0x20c [4294667.296000] [<803ed12c>] unknown_bootoption+0x0/0x310 [4294667.296000] [4294667.296000] Badness in r4k_flush_icache_range at /home/domen/tmp/linux-2.6.bisecting/linux-mips.git/arch/mips/mm/c-r4k.c:516 [4294667.296000] Call Trace: [4294667.296000] [<80113434>] r4k_flush_icache_range+0x144/0x150 [4294667.296000] [<80105580>] handle_reserved+0x0/0xc8 [4294667.296000] [<8010cb78>] set_except_vector+0x88/0xa0 [4294667.296000] [<8010b0f4>] show_trace+0x98/0xfc [4294667.296000] [<803f0c18>] arch_init_irq+0x44/0x1e0 [4294667.296000] [<8010b16c>] dump_stack+0x14/0x20 [4294667.296000] [<803f2620>] init_IRQ+0x90/0x9c [4294667.296000] [<803ed6e4>] start_kernel+0xd8/0x20c [4294667.296000] [<803ed6d4>] start_kernel+0xc8/0x20c [4294667.296000] [<803ed12c>] unknown_bootoption+0x0/0x310 [4294667.296000] [4294667.296000] PID hash table entries: 2048 (order: 11, 32768 bytes) Domen From khali@linux-fr.org Wed Jun 21 11:25:55 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 21 Jun 2006 11:26:05 +0100 (BST) Received: from smtp-103-wednesday.nerim.net ([62.4.16.103]:22030 "HELO kraid.nerim.net") by ftp.linux-mips.org with SMTP id S8133459AbWFUKZz (ORCPT ); Wed, 21 Jun 2006 11:25:55 +0100 Received: from arrakis.delvare (jdelvare.pck.nerim.net [62.212.121.182]) by kraid.nerim.net (Postfix) with SMTP id 56CD541053; Wed, 21 Jun 2006 12:25:54 +0200 (CEST) Date: Wed, 21 Jun 2006 12:25:59 +0200 From: Jean Delvare To: linux-mips@linux-mips.org Cc: Linux I2C Subject: [PATCH] i2c-algo-sibyte: Cleanups Message-Id: <20060621122559.8dbff204.khali@linux-fr.org> X-Mailer: Sylpheed version 2.2.6 (GTK+ 2.6.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11801 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: khali@linux-fr.org Precedence: bulk X-list: linux-mips Hi all, Could someone please test this patch? I can't. Also note that I plan to merge i2c-algo-sibyte into i2c-sibyte as it is hardware dependent and not a reusable implementation as i2c algorithms are supposed to be. Thanks. Cleanups to the i2c-algo-sibyte driver: * Delete empty algo_control implementation. * Simplify i2c_sibyte_del_bus. * Delete empty module init and cleanup functions. * Drop useless #ifdef MODULE construct. Signed-off-by: Jean Delvare --- drivers/i2c/algos/i2c-algo-sibyte.c | 32 +------------------------------- 1 file changed, 1 insertion(+), 31 deletions(-) --- linux-2.6.17-git.orig/drivers/i2c/algos/i2c-algo-sibyte.c 2006-06-18 15:56:15.000000000 +0200 +++ linux-2.6.17-git/drivers/i2c/algos/i2c-algo-sibyte.c 2006-06-21 12:10:07.000000000 +0200 @@ -119,12 +119,6 @@ return 0; } -static int algo_control(struct i2c_adapter *adapter, - unsigned int cmd, unsigned long arg) -{ - return 0; -} - static u32 bit_func(struct i2c_adapter *adap) { return (I2C_FUNC_SMBUS_QUICK | I2C_FUNC_SMBUS_BYTE | @@ -136,7 +130,6 @@ static struct i2c_algorithm i2c_sibyte_algo = { .smbus_xfer = smbus_xfer, - .algo_control = algo_control, /* ioctl */ .functionality = bit_func, }; @@ -181,37 +174,14 @@ int i2c_sibyte_del_bus(struct i2c_adapter *adap) { - int res; - - if ((res = i2c_del_adapter(adap)) < 0) - return res; - - return 0; -} - -int __init i2c_algo_sibyte_init (void) -{ - printk("i2c-algo-sibyte.o: i2c SiByte algorithm module\n"); - return 0; + return i2c_del_adapter(adap); } - EXPORT_SYMBOL(i2c_sibyte_add_bus); EXPORT_SYMBOL(i2c_sibyte_del_bus); -#ifdef MODULE MODULE_AUTHOR("Kip Walker, Broadcom Corp."); MODULE_DESCRIPTION("SiByte I2C-Bus algorithm"); module_param(bit_scan, int, 0); MODULE_PARM_DESC(bit_scan, "Scan for active chips on the bus"); MODULE_LICENSE("GPL"); - -int init_module(void) -{ - return i2c_algo_sibyte_init(); -} - -void cleanup_module(void) -{ -} -#endif -- Jean Delvare From ralf@linux-mips.org Wed Jun 21 13:11:14 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 21 Jun 2006 13:11:26 +0100 (BST) Received: from localhost.localdomain ([127.0.0.1]:14007 "EHLO bacchus.dhis.org") by ftp.linux-mips.org with ESMTP id S8133653AbWFUMLO (ORCPT ); Wed, 21 Jun 2006 13:11:14 +0100 Received: from denk.linux-mips.net (denk.linux-mips.net [127.0.0.1]) by bacchus.dhis.org (8.13.6/8.13.4) with ESMTP id k5LCBBI8013148; Wed, 21 Jun 2006 13:11:11 +0100 Received: (from ralf@localhost) by denk.linux-mips.net (8.13.6/8.13.6/Submit) id k5LCBAWG013146; Wed, 21 Jun 2006 13:11:10 +0100 Date: Wed, 21 Jun 2006 13:11:10 +0100 From: Ralf Baechle To: Domen Puncer Cc: Kumba , linux-mips@linux-mips.org Subject: Re: Commit 78eef01b0fae087c5fadbd85dd4fe2918c3a015f (on_each_cpu(): disable local interrupts) Breaks SGI IP32 Message-ID: <20060621121110.GA12545@linux-mips.org> References: <4478C0F1.8000006@gentoo.org> <20060528010603.GA24997@linux-mips.org> <20060527194243.a8157338.akpm@osdl.org> <4479250E.3080604@gentoo.org> <20060528105014.GA28621@linux-mips.org> <20060621095150.GO5568@domen.ultra.si> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060621095150.GO5568@domen.ultra.si> User-Agent: Mutt/1.4.2.1i Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11802 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ralf@linux-mips.org Precedence: bulk X-list: linux-mips On Wed, Jun 21, 2006 at 11:51:50AM +0200, Domen Puncer wrote: > > #define on_each_cpu(func,info,retry,wait) \ > > ({ \ > > WARN_ON(irqs_disabled()); \ > > func(info); \ > > 0; \ > > }) > > On Alchemy au1200 this produces: > [4294667.296000] Synthesized TLB modify handler fastpath (33 instructions). > [4294667.296000] Badness in r4k_flush_icache_range at /home/domen/tmp/linux-2.6.bisecting/linux-mips.git/arch/mips/mm/c-r4k.c:516 > [4294667.296000] Call Trace: > [4294667.296000] [<80113434>] r4k_flush_icache_range+0x144/0x150 > [4294667.296000] [<803f0000>] inflate_dynamic+0x634/0x70c > [4294667.296000] [<803f3630>] trap_init+0x3c/0x440 Pretty much as expected, thanks! Ralf From anemo@mba.ocn.ne.jp Thu Jun 22 02:22:08 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 22 Jun 2006 02:22:19 +0100 (BST) Received: from topsns2.toshiba-tops.co.jp ([202.230.225.126]:18606 "EHLO topsns2.toshiba-tops.co.jp") by ftp.linux-mips.org with ESMTP id S8133901AbWFVBWI (ORCPT ); Thu, 22 Jun 2006 02:22:08 +0100 Received: from topsms.toshiba-tops.co.jp by topsns2.toshiba-tops.co.jp via smtpd (for ftp.linux-mips.org [194.74.144.162]) with ESMTP; Thu, 22 Jun 2006 10:22:02 +0900 Received: from topsms.toshiba-tops.co.jp (localhost.localdomain [127.0.0.1]) by localhost.toshiba-tops.co.jp (Postfix) with ESMTP id F2C63203DD; Thu, 22 Jun 2006 10:21:51 +0900 (JST) Received: from srd2sd.toshiba-tops.co.jp (srd2sd.toshiba-tops.co.jp [172.17.28.2]) by topsms.toshiba-tops.co.jp (Postfix) with ESMTP id DFC152028B; Thu, 22 Jun 2006 10:21:51 +0900 (JST) Received: from localhost (fragile [172.17.28.65]) by srd2sd.toshiba-tops.co.jp (8.12.10/8.12.10) with ESMTP id k5M1LpW0037430; Thu, 22 Jun 2006 10:21:51 +0900 (JST) (envelope-from anemo@mba.ocn.ne.jp) Date: Thu, 22 Jun 2006 10:21:51 +0900 (JST) Message-Id: <20060622.102151.126573974.nemoto@toshiba-tops.co.jp> To: linux-mips@linux-mips.org Cc: libc-ports@sourceware.org Subject: Re: mips RDHWR instruction in glibc From: Atsushi Nemoto In-Reply-To: <20060617.005845.93020013.anemo@mba.ocn.ne.jp> References: <20060616.002837.59465125.anemo@mba.ocn.ne.jp> <20060615153252.GA21598@nevyn.them.org> <20060617.005845.93020013.anemo@mba.ocn.ne.jp> X-Fingerprint: 6ACA 1623 39BD 9A94 9B1A B746 CA77 FE94 2874 D52F X-Pgp-Public-Key: http://wwwkeys.pgp.net/pks/lookup?op=get&search=0x2874D52F X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11803 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: anemo@mba.ocn.ne.jp Precedence: bulk X-list: linux-mips On Sat, 17 Jun 2006 00:58:45 +0900 (JST), Atsushi Nemoto wrote: > It looks too bad for arg == 0 case. I should ask on gcc list. Filed to gcc bugzilla. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28126 --- Atsushi Nemoto From domen.puncer@ultra.si Thu Jun 22 07:49:38 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 22 Jun 2006 07:49:47 +0100 (BST) Received: from deliver-1.mx.triera.net ([213.161.0.31]:34216 "HELO deliver-1.mx.triera.net") by ftp.linux-mips.org with SMTP id S8133451AbWFVGti (ORCPT ); Thu, 22 Jun 2006 07:49:38 +0100 Received: from localhost (in-1.mx.triera.net [213.161.0.25]) by deliver-1.mx.triera.net (Postfix) with ESMTP id 91365BFD5; Thu, 22 Jun 2006 08:49:27 +0200 (CEST) Received: from smtp.triera.net (smtp.triera.net [213.161.0.30]) by in-1.mx.triera.net (Postfix) with SMTP id 060151BC095; Thu, 22 Jun 2006 08:49:28 +0200 (CEST) Received: from localhost (unknown [213.161.20.162]) by smtp.triera.net (Postfix) with ESMTP id A2D5B1A18AB; Thu, 22 Jun 2006 08:49:28 +0200 (CEST) Date: Thu, 22 Jun 2006 08:49:30 +0200 From: Domen Puncer To: Ralf Baechle Cc: Kumba , linux-mips@linux-mips.org Subject: Re: Commit 78eef01b0fae087c5fadbd85dd4fe2918c3a015f (on_each_cpu(): disable local interrupts) Breaks SGI IP32 Message-ID: <20060622064930.GP5568@domen.ultra.si> References: <4478C0F1.8000006@gentoo.org> <20060528010603.GA24997@linux-mips.org> <20060527194243.a8157338.akpm@osdl.org> <4479250E.3080604@gentoo.org> <20060528105014.GA28621@linux-mips.org> <20060621095150.GO5568@domen.ultra.si> <20060621121110.GA12545@linux-mips.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060621121110.GA12545@linux-mips.org> User-Agent: Mutt/1.5.11+cvs20060126 X-Virus-Scanned: Triera AV Service Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11804 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: domen.puncer@ultra.si Precedence: bulk X-list: linux-mips On 21/06/06 13:11 +0100, Ralf Baechle wrote: > On Wed, Jun 21, 2006 at 11:51:50AM +0200, Domen Puncer wrote: > > > > #define on_each_cpu(func,info,retry,wait) \ > > > ({ \ > > > WARN_ON(irqs_disabled()); \ > > > func(info); \ > > > 0; \ > > > }) > > > > On Alchemy au1200 this produces: > > [4294667.296000] Synthesized TLB modify handler fastpath (33 instructions). > > [4294667.296000] Badness in r4k_flush_icache_range at /home/domen/tmp/linux-2.6.bisecting/linux-mips.git/arch/mips/mm/c-r4k.c:516 > > [4294667.296000] Call Trace: > > [4294667.296000] [<80113434>] r4k_flush_icache_range+0x144/0x150 > > [4294667.296000] [<803f0000>] inflate_dynamic+0x634/0x70c > > [4294667.296000] [<803f3630>] trap_init+0x3c/0x440 > > Pretty much as expected, thanks! Guess I forgot to state my simptoms... they don't seem so expected to me :-) set_c0_status(ALLINTS) causes in_interrupt to be non-zero, which in time causes a hang via kernel/printk.c:acquire_console_sem->BUG(). set_c0_status call trace: start_kernel->init_IRQ->arch_init_irq->set_c0_status I'm a bit lost in mipsregs.h, and I can't figure out why it sets preempt_count() to 0x100 (that being HARD_IRQ). Ideas? Domen From domen.puncer@ultra.si Thu Jun 22 10:29:20 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 22 Jun 2006 10:29:34 +0100 (BST) Received: from deliver-1.mx.triera.net ([213.161.0.31]:12739 "HELO deliver-1.mx.triera.net") by ftp.linux-mips.org with SMTP id S8133816AbWFVJ3U (ORCPT ); Thu, 22 Jun 2006 10:29:20 +0100 Received: from localhost (in-2.mx.triera.net [213.161.0.26]) by deliver-1.mx.triera.net (Postfix) with ESMTP id 6F4F9BFE9 for ; Thu, 22 Jun 2006 11:29:09 +0200 (CEST) Received: from smtp.triera.net (smtp.triera.net [213.161.0.30]) by in-2.mx.triera.net (Postfix) with SMTP id C354D1BC07E for ; Thu, 22 Jun 2006 11:29:11 +0200 (CEST) Received: from localhost (unknown [213.161.20.162]) by smtp.triera.net (Postfix) with ESMTP id CB70F1A18BA for ; Thu, 22 Jun 2006 11:29:11 +0200 (CEST) Date: Thu, 22 Jun 2006 11:29:13 +0200 From: Domen Puncer To: linux-mips@linux-mips.org Subject: [patch] au1550_ac97: spin_unlock in error path Message-ID: <20060622092913.GA18607@domen.ultra.si> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.11+cvs20060126 X-Virus-Scanned: Triera AV Service Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11805 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: domen.puncer@ultra.si Precedence: bulk X-list: linux-mips Error paths didn't spin_unlock. Signed-off-by: Domen Puncer Index: linux/sound/oss/au1550_ac97.c =================================================================== --- linux.orig/sound/oss/au1550_ac97.c +++ linux/sound/oss/au1550_ac97.c @@ -214,7 +214,8 @@ rdcodec(struct ac97_codec *codec, u8 add } if (i == POLL_COUNT) { err("rdcodec: read poll expired!"); - return 0; + data = 0; + goto out; } /* wait for command done? @@ -227,7 +228,8 @@ rdcodec(struct ac97_codec *codec, u8 add } if (i == POLL_COUNT) { err("rdcodec: read cmdwait expired!"); - return 0; + data = 0; + goto out; } data = au_readl(PSC_AC97CDC) & 0xffff; @@ -238,6 +240,7 @@ rdcodec(struct ac97_codec *codec, u8 add au_writel(PSC_AC97EVNT_CD, PSC_AC97EVNT); au_sync(); + out: spin_unlock_irqrestore(&s->lock, flags); return data; From anemo@mba.ocn.ne.jp Thu Jun 22 11:42:51 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 22 Jun 2006 11:43:00 +0100 (BST) Received: from topsns2.toshiba-tops.co.jp ([202.230.225.126]:48769 "EHLO topsns2.toshiba-tops.co.jp") by ftp.linux-mips.org with ESMTP id S8133781AbWFVKmv (ORCPT ); Thu, 22 Jun 2006 11:42:51 +0100 Received: from topsms.toshiba-tops.co.jp by topsns2.toshiba-tops.co.jp via smtpd (for ftp.linux-mips.org [194.74.144.162]) with ESMTP; Thu, 22 Jun 2006 19:42:49 +0900 Received: from topsms.toshiba-tops.co.jp (localhost.localdomain [127.0.0.1]) by localhost.toshiba-tops.co.jp (Postfix) with ESMTP id 2BAE0203CA; Thu, 22 Jun 2006 19:42:44 +0900 (JST) Received: from srd2sd.toshiba-tops.co.jp (srd2sd.toshiba-tops.co.jp [172.17.28.2]) by topsms.toshiba-tops.co.jp (Postfix) with ESMTP id 181A220408; Thu, 22 Jun 2006 19:42:44 +0900 (JST) Received: from localhost (fragile [172.17.28.65]) by srd2sd.toshiba-tops.co.jp (8.12.10/8.12.10) with ESMTP id k5MAghW0039574; Thu, 22 Jun 2006 19:42:43 +0900 (JST) (envelope-from anemo@mba.ocn.ne.jp) Date: Thu, 22 Jun 2006 19:42:43 +0900 (JST) Message-Id: <20060622.194243.122255229.nemoto@toshiba-tops.co.jp> To: linux-mips@linux-mips.org Cc: ralf@linux-mips.org Subject: [PATCH] mips32/mips64 scache fix and cleanup From: Atsushi Nemoto X-Fingerprint: 6ACA 1623 39BD 9A94 9B1A B746 CA77 FE94 2874 D52F X-Pgp-Public-Key: http://wwwkeys.pgp.net/pks/lookup?op=get&search=0x2874D52F X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11806 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: anemo@mba.ocn.ne.jp Precedence: bulk X-list: linux-mips Use blast_scache_range, blast_inv_scache_range for mips32/mips64 scache routine. Also initialize waybit for mips32/mips64 scache. Signed-off-by: Atsushi Nemoto diff --git a/arch/mips/mm/sc-mips.c b/arch/mips/mm/sc-mips.c index d3f92a9..42b5096 100644 --- a/arch/mips/mm/sc-mips.c +++ b/arch/mips/mm/sc-mips.c @@ -24,22 +24,7 @@ #include */ static void mips_sc_wback_inv(unsigned long addr, unsigned long size) { - unsigned long sc_lsize = cpu_scache_line_size(); - unsigned long end, a; - - pr_debug("mips_sc_wback_inv[%08lx,%08lx]", addr, size); - - /* Catch bad driver code */ - BUG_ON(size == 0); - - a = addr & ~(sc_lsize - 1); - end = (addr + size - 1) & ~(sc_lsize - 1); - while (1) { - flush_scache_line(a); /* Hit_Writeback_Inv_SD */ - if (a == end) - break; - a += sc_lsize; - } + blast_scache_range(addr, addr + size); } /* @@ -47,22 +32,7 @@ static void mips_sc_wback_inv(unsigned l */ static void mips_sc_inv(unsigned long addr, unsigned long size) { - unsigned long sc_lsize = cpu_scache_line_size(); - unsigned long end, a; - - pr_debug("mips_sc_inv[%08lx,%08lx]", addr, size); - - /* Catch bad driver code */ - BUG_ON(size == 0); - - a = addr & ~(sc_lsize - 1); - end = (addr + size - 1) & ~(sc_lsize - 1); - while (1) { - invalidate_scache_line(a); /* Hit_Invalidate_SD */ - if (a == end) - break; - a += sc_lsize; - } + blast_inv_scache_range(addr, addr + size); } static void mips_sc_enable(void) @@ -123,6 +93,7 @@ static inline int __init mips_sc_probe(v return 0; c->scache.waysize = c->scache.sets * c->scache.linesz; + c->scache.waybit = __ffs(c->scache.waysize); c->scache.flags &= ~MIPS_CACHE_NOT_PRESENT; From ralf@linux-mips.org Thu Jun 22 11:59:40 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 22 Jun 2006 11:59:49 +0100 (BST) Received: from localhost.localdomain ([127.0.0.1]:7360 "EHLO bacchus.dhis.org") by ftp.linux-mips.org with ESMTP id S8133833AbWFVK7k (ORCPT ); Thu, 22 Jun 2006 11:59:40 +0100 Received: from denk.linux-mips.net (denk.linux-mips.net [127.0.0.1]) by bacchus.dhis.org (8.13.6/8.13.4) with ESMTP id k5MAxTZj006018; Thu, 22 Jun 2006 11:59:29 +0100 Received: (from ralf@localhost) by denk.linux-mips.net (8.13.6/8.13.6/Submit) id k5MAxSRf006017; Thu, 22 Jun 2006 11:59:28 +0100 Date: Thu, 22 Jun 2006 11:59:28 +0100 From: Ralf Baechle To: Pete Popov Cc: Jean Delvare , linux-mips@linux-mips.org, LKML Subject: Re: i2c-algo-ite and i2c-ite planned for removal Message-ID: <20060622105928.GA4032@linux-mips.org> References: <20060615225723.012c82be.khali@linux-fr.org> <1150406598.1193.73.camel@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1150406598.1193.73.camel@localhost.localdomain> User-Agent: Mutt/1.4.2.1i Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11807 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ralf@linux-mips.org Precedence: bulk X-list: linux-mips On Fri, Jun 16, 2006 at 12:23:17AM +0300, Pete Popov wrote: > For historical correctness, this driver was once upon a time usable, > though it was a few years ago. It was written by MV for some ref board > that had the ITE chip and it did work. That ref board is no longer > around so it's probably safe to nuke the driver. Not quite true; the board support for that board is still around and it's on my to-be-nuked list for after 2.6.18. Ralf From ralf@linux-mips.org Thu Jun 22 12:22:47 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 22 Jun 2006 12:22:56 +0100 (BST) Received: from localhost.localdomain ([127.0.0.1]:60119 "EHLO bacchus.dhis.org") by ftp.linux-mips.org with ESMTP id S8133833AbWFVLWr (ORCPT ); Thu, 22 Jun 2006 12:22:47 +0100 Received: from denk.linux-mips.net (denk.linux-mips.net [127.0.0.1]) by bacchus.dhis.org (8.13.6/8.13.4) with ESMTP id k5MBMllv006758; Thu, 22 Jun 2006 12:22:47 +0100 Received: (from ralf@localhost) by denk.linux-mips.net (8.13.6/8.13.6/Submit) id k5MBMkgZ006757; Thu, 22 Jun 2006 12:22:46 +0100 Date: Thu, 22 Jun 2006 12:22:46 +0100 From: Ralf Baechle To: ankur maheshwari Cc: Jean Delvare , Pete Popov , linux-mips@linux-mips.org, linux-kernel@vger.kernel.org Subject: Re: i2c-algo-ite and i2c-ite planned for removal Message-ID: <20060622112246.GB4032@linux-mips.org> References: <20060620120836.628ddc79.khali@linux-fr.org> <110701c694f4$f1412fb0$f301a8c0@procsys> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <110701c694f4$f1412fb0$f301a8c0@procsys> User-Agent: Mutt/1.4.2.1i Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11808 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ralf@linux-mips.org Precedence: bulk X-list: linux-mips On Wed, Jun 21, 2006 at 11:08:34AM +0530, ankur maheshwari wrote: > I have used once i2c-adap-ite and i2c-algo-ite for ite-8712 chip and it > worked fine for me in MV 2.4.25. The fact that is used to work in some vendor kernel is irrelevant. And 2.4 hardly indicates anyway. > Its been an year ago, I asked on same forum if some one has used it > before but I didn't got any reply. You see how amazingly popular the board was. On April 2 just after 2.6.16 was out I announced my intension to remove the board in http://www.linux-mips.org/cgi-bin/mesg.cgi?a=linux-mips&i=20060402194822.GA26358%40linux-mips.org Nobody raised hand to take care of the maintenance of any of these boards, thus http://www.linux-mips.org/wiki/ITE-8172G also marks the board as to be deleted. > It's just an info on ite-chip works, to remove it from kernel tree ..... > decision is up to you : ). There is more that just that wrong with the board support. And if the fact that it is was broken does not even result bug reports this is another indicator the board a board should go. The usual reminder: patches to fix the issues will be accepted. Ralf From sshtylyov@ru.mvista.com Thu Jun 22 16:30:31 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 22 Jun 2006 16:30:40 +0100 (BST) Received: from rtsoft2.corbina.net ([85.21.88.2]:39070 "HELO mail.dev.rtsoft.ru") by ftp.linux-mips.org with SMTP id S8133898AbWFVPab (ORCPT ); Thu, 22 Jun 2006 16:30:31 +0100 Received: (qmail 21203 invoked from network); 22 Jun 2006 19:41:44 -0000 Received: from wasted.dev.rtsoft.ru (HELO ?192.168.1.248?) (192.168.1.248) by mail.dev.rtsoft.ru with SMTP; 22 Jun 2006 19:41:44 -0000 Message-ID: <449AB731.40301@ru.mvista.com> Date: Thu, 22 Jun 2006 19:28:49 +0400 From: Sergei Shtylyov Organization: MontaVista Software Inc. User-Agent: Mozilla/5.0 (X11; U; Linux i686; rv:1.7.2) Gecko/20040803 X-Accept-Language: ru, en-us, en-gb MIME-Version: 1.0 To: Domen Puncer CC: linux-mips@linux-mips.org Subject: Re: [patch] au1550_ac97: spin_unlock in error path References: <20060622092913.GA18607@domen.ultra.si> In-Reply-To: <20060622092913.GA18607@domen.ultra.si> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11809 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: sshtylyov@ru.mvista.com Precedence: bulk X-list: linux-mips Hello. Domen Puncer wrote: > Error paths didn't spin_unlock. Dang, we missed it while fixing the spinlocks in that driver. Thank you for noticing. Not sure if Ralf would be eaegr to apply though. :-) WBR, Sergei From ralf@linux-mips.org Thu Jun 22 17:53:41 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 22 Jun 2006 17:53:52 +0100 (BST) Received: from localhost.localdomain ([127.0.0.1]:65468 "EHLO bacchus.dhis.org") by ftp.linux-mips.org with ESMTP id S8133903AbWFVQxb (ORCPT ); Thu, 22 Jun 2006 17:53:31 +0100 Received: from denk.linux-mips.net (denk.linux-mips.net [127.0.0.1]) by bacchus.dhis.org (8.13.6/8.13.4) with ESMTP id k5MGrQCp003471; Thu, 22 Jun 2006 17:53:26 +0100 Received: (from ralf@localhost) by denk.linux-mips.net (8.13.6/8.13.6/Submit) id k5MGrKdU003470; Thu, 22 Jun 2006 17:53:20 +0100 Date: Thu, 22 Jun 2006 17:53:20 +0100 From: Ralf Baechle To: Sergei Shtylyov Cc: Domen Puncer , linux-mips@linux-mips.org Subject: Re: [patch] au1550_ac97: spin_unlock in error path Message-ID: <20060622165320.GA3415@linux-mips.org> References: <20060622092913.GA18607@domen.ultra.si> <449AB731.40301@ru.mvista.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <449AB731.40301@ru.mvista.com> User-Agent: Mutt/1.4.2.1i Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11810 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ralf@linux-mips.org Precedence: bulk X-list: linux-mips On Thu, Jun 22, 2006 at 07:28:49PM +0400, Sergei Shtylyov wrote: > Dang, we missed it while fixing the spinlocks in that driver. Thank you > for noticing. Not sure if Ralf would be eaegr to apply though. :-) I feed it to upstream, so it will eventually show up in the tree on the indirect path. Ralf From domen.puncer@ultra.si Fri Jun 23 09:23:56 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 23 Jun 2006 09:24:05 +0100 (BST) Received: from deliver-1.mx.triera.net ([213.161.0.31]:38098 "HELO deliver-1.mx.triera.net") by ftp.linux-mips.org with SMTP id S8133443AbWFWIX4 (ORCPT ); Fri, 23 Jun 2006 09:23:56 +0100 Received: from localhost (in-1.mx.triera.net [213.161.0.25]) by deliver-1.mx.triera.net (Postfix) with ESMTP id 1075EC03A; Fri, 23 Jun 2006 10:23:46 +0200 (CEST) Received: from smtp.triera.net (smtp.triera.net [213.161.0.30]) by in-1.mx.triera.net (Postfix) with SMTP id 980261BC09B; Fri, 23 Jun 2006 10:23:47 +0200 (CEST) Received: from localhost (unknown [213.161.20.162]) by smtp.triera.net (Postfix) with ESMTP id 3D3CD1A18BF; Fri, 23 Jun 2006 10:23:46 +0200 (CEST) Date: Fri, 23 Jun 2006 10:23:48 +0200 From: Domen Puncer To: Sergei Shtylyov Cc: linux-mips@linux-mips.org Subject: u-boot problem: Au1xx0: fix prom_getenv() to handle YAMON style environment Message-ID: <20060623082348.GB18607@domen.ultra.si> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.11+cvs20060126 X-Virus-Scanned: Triera AV Service Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11811 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: domen.puncer@ultra.si Precedence: bulk X-list: linux-mips Hi. I need to revert $SUBJECT patch for kernel to boot on au1200, u-boot 1.1.3. And I could swear it worked booted yesterday without reverting (??) Could we support yamon and u-boot style environment? Domen From domen.puncer@ultra.si Fri Jun 23 10:57:09 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 23 Jun 2006 10:57:19 +0100 (BST) Received: from deliver-1.mx.triera.net ([213.161.0.31]:2529 "HELO deliver-1.mx.triera.net") by ftp.linux-mips.org with SMTP id S8133455AbWFWJ5J (ORCPT ); Fri, 23 Jun 2006 10:57:09 +0100 Received: from localhost (in-2.mx.triera.net [213.161.0.26]) by deliver-1.mx.triera.net (Postfix) with ESMTP id E9587C03E; Fri, 23 Jun 2006 11:56:58 +0200 (CEST) Received: from smtp.triera.net (smtp.triera.net [213.161.0.30]) by in-2.mx.triera.net (Postfix) with SMTP id C2ECB1BC07E; Fri, 23 Jun 2006 11:57:00 +0200 (CEST) Received: from localhost (unknown [213.161.20.162]) by smtp.triera.net (Postfix) with ESMTP id 2045A1A18AE; Fri, 23 Jun 2006 11:57:01 +0200 (CEST) Date: Fri, 23 Jun 2006 11:57:03 +0200 From: Domen Puncer To: Ralf Baechle Cc: linux-mips@linux-mips.org Subject: [patch 0/8] au1xxx: make linux-mips more useful for au1200 users Message-ID: <20060623095703.GA30980@domen.ultra.si> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.11+cvs20060126 X-Virus-Scanned: Triera AV Service Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11812 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: domen.puncer@ultra.si Precedence: bulk X-list: linux-mips Hi Ralf, list! I would like the following patches merged: [patch 1/8] au1xxx: psc fixes + add au1200 adresses [patch 2/8] au1xxx: I2C fixes [patch 3/8] au1xxx: I2C support for au1200 [patch 4/8] au1xxx: dbdma, no sleeping under spin_lock [patch 5/8] au1xxx: export dbdma functions [patch 6/8] au1xxx: oss sound support for au1200 [patch 7/8] au1xxx: compile fixes for OHCI for au1200 [patch 8/8] au1xxx: pcmcia: fix __init called from non-init You might have a problem with 7/8, others should be fine. Oh... and the diffstat: arch/mips/au1000/common/dbdma.c | 6 +++++- drivers/i2c/busses/Kconfig | 6 +++--- drivers/i2c/busses/i2c-au1550.c | 18 ++++++++++++------ drivers/pcmcia/au1000_db1x00.c | 2 +- drivers/usb/host/ohci-au1xxx.c | 6 ++++-- include/asm-mips/mach-au1x00/au1xxx_psc.h | 9 +++++++-- sound/oss/Kconfig | 5 +++-- sound/oss/au1550_ac97.c | 2 ++ 8 files changed, 37 insertions(+), 17 deletions(-) Comments, flames? Domen From domen.puncer@ultra.si Fri Jun 23 10:58:38 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 23 Jun 2006 10:58:52 +0100 (BST) Received: from deliver-1.mx.triera.net ([213.161.0.31]:13793 "HELO deliver-1.mx.triera.net") by ftp.linux-mips.org with SMTP id S8133455AbWFWJ6i (ORCPT ); Fri, 23 Jun 2006 10:58:38 +0100 Received: from localhost (in-2.mx.triera.net [213.161.0.26]) by deliver-1.mx.triera.net (Postfix) with ESMTP id AB9A6C05F; Fri, 23 Jun 2006 11:58:27 +0200 (CEST) Received: from smtp.triera.net (smtp.triera.net [213.161.0.30]) by in-2.mx.triera.net (Postfix) with SMTP id 9FC2C1BC086; Fri, 23 Jun 2006 11:58:29 +0200 (CEST) Received: from localhost (unknown [213.161.20.162]) by smtp.triera.net (Postfix) with ESMTP id 949D31A18AF; Fri, 23 Jun 2006 11:58:29 +0200 (CEST) Date: Fri, 23 Jun 2006 11:58:31 +0200 From: Domen Puncer To: Ralf Baechle Cc: linux-mips@linux-mips.org Subject: [patch 1/8] au1xxx: psc fixes + add au1200 adresses Message-ID: <20060623095831.GA31017@domen.ultra.si> References: <20060623095703.GA30980@domen.ultra.si> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060623095703.GA30980@domen.ultra.si> User-Agent: Mutt/1.5.11+cvs20060126 X-Virus-Scanned: Triera AV Service Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11813 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: domen.puncer@ultra.si Precedence: bulk X-list: linux-mips Based on Jordan Crusoe's i2c patch: - fix PSC3_BASE_ADDR to match au1550 databook - fix PSC_SMBTXRX_RSR - add PSC addresses for au1200 Signed-off-by: Domen Puncer Index: linux-mailed/include/asm-mips/mach-au1x00/au1xxx_psc.h =================================================================== --- linux-mailed.orig/include/asm-mips/mach-au1x00/au1xxx_psc.h +++ linux-mailed/include/asm-mips/mach-au1x00/au1xxx_psc.h @@ -40,7 +40,12 @@ #define PSC0_BASE_ADDR 0xb1a00000 #define PSC1_BASE_ADDR 0xb1b00000 #define PSC2_BASE_ADDR 0xb0a00000 -#define PSC3_BASE_ADDR 0xb0d00000 +#define PSC3_BASE_ADDR 0xb0b00000 +#endif + +#ifdef CONFIG_SOC_AU1200 +#define PSC0_BASE_ADDR 0xb1a00000 +#define PSC1_BASE_ADDR 0xb1b00000 #endif /* The PSC select and control registers are common to @@ -506,7 +511,7 @@ typedef struct psc_smb { /* Transmit register control. */ -#define PSC_SMBTXRX_RSR (1 << 30) +#define PSC_SMBTXRX_RSR (1 << 28) #define PSC_SMBTXRX_STP (1 << 29) #define PSC_SMBTXRX_DATAMASK (0xff) From domen.puncer@ultra.si Fri Jun 23 10:59:24 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 23 Jun 2006 10:59:44 +0100 (BST) Received: from deliver-1.mx.triera.net ([213.161.0.31]:15585 "HELO deliver-1.mx.triera.net") by ftp.linux-mips.org with SMTP id S8133504AbWFWJ7E (ORCPT ); Fri, 23 Jun 2006 10:59:04 +0100 Received: from localhost (in-1.mx.triera.net [213.161.0.25]) by deliver-1.mx.triera.net (Postfix) with ESMTP id 3BE2AC03E; Fri, 23 Jun 2006 11:58:54 +0200 (CEST) Received: from smtp.triera.net (smtp.triera.net [213.161.0.30]) by in-1.mx.triera.net (Postfix) with SMTP id 882911BC08C; Fri, 23 Jun 2006 11:58:56 +0200 (CEST) Received: from localhost (unknown [213.161.20.162]) by smtp.triera.net (Postfix) with ESMTP id 8398D1A18A8; Fri, 23 Jun 2006 11:58:56 +0200 (CEST) Date: Fri, 23 Jun 2006 11:58:58 +0200 From: Domen Puncer To: Ralf Baechle Cc: linux-mips@linux-mips.org Subject: [patch 2/8] au1xxx: I2C fixes Message-ID: <20060623095858.GB31017@domen.ultra.si> References: <20060623095703.GA30980@domen.ultra.si> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060623095703.GA30980@domen.ultra.si> User-Agent: Mutt/1.5.11+cvs20060126 X-Virus-Scanned: Triera AV Service Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11814 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: domen.puncer@ultra.si Precedence: bulk X-list: linux-mips - I2C fixes from Jordan Crusoe - add SMBUS functionality flags Signed-off-by: Domen Puncer Index: linux-mailed/drivers/i2c/busses/i2c-au1550.c =================================================================== --- linux-mailed.orig/drivers/i2c/busses/i2c-au1550.c +++ linux-mailed/drivers/i2c/busses/i2c-au1550.c @@ -35,7 +35,7 @@ #include #include -#include +#include #include #include "i2c-au1550.h" @@ -118,13 +118,19 @@ do_address(struct i2c_au1550_data *adap, /* Reset the FIFOs, clear events. */ - sp->psc_smbpcr = PSC_SMBPCR_DC; + stat = sp->psc_smbstat; sp->psc_smbevnt = PSC_SMBEVNT_ALLCLR; au_sync(); - do { - stat = sp->psc_smbpcr; + + if (!(stat & PSC_SMBSTAT_TE) || !(stat & PSC_SMBSTAT_RE)) { + sp->psc_smbpcr = PSC_SMBPCR_DC; au_sync(); - } while ((stat & PSC_SMBPCR_DC) != 0); + do { + stat = sp->psc_smbpcr; + au_sync(); + } while ((stat & PSC_SMBPCR_DC) != 0); + udelay(50); + } /* Write out the i2c chip address and specify operation */ @@ -279,7 +285,7 @@ au1550_xfer(struct i2c_adapter *i2c_adap static u32 au1550_func(struct i2c_adapter *adap) { - return I2C_FUNC_I2C; + return I2C_FUNC_I2C | I2C_FUNC_SMBUS_EMUL; } static struct i2c_algorithm au1550_algo = { From domen.puncer@ultra.si Fri Jun 23 11:00:20 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 23 Jun 2006 11:00:46 +0100 (BST) Received: from deliver-1.mx.triera.net ([213.161.0.31]:19937 "HELO deliver-1.mx.triera.net") by ftp.linux-mips.org with SMTP id S8133455AbWFWJ7j (ORCPT ); Fri, 23 Jun 2006 10:59:39 +0100 Received: from localhost (in-3.mx.triera.net [213.161.0.27]) by deliver-1.mx.triera.net (Postfix) with ESMTP id D0CCDC026; Fri, 23 Jun 2006 11:59:25 +0200 (CEST) Received: from smtp.triera.net (smtp.triera.net [213.161.0.30]) by in-3.mx.triera.net (Postfix) with SMTP id 61E491BC094; Fri, 23 Jun 2006 11:59:26 +0200 (CEST) Received: from localhost (unknown [213.161.20.162]) by smtp.triera.net (Postfix) with ESMTP id 6C5AE1A18B7; Fri, 23 Jun 2006 11:59:26 +0200 (CEST) Date: Fri, 23 Jun 2006 11:59:28 +0200 From: Domen Puncer To: Ralf Baechle Cc: linux-mips@linux-mips.org Subject: [patch 3/8] au1xxx: I2C support for au1200 Message-ID: <20060623095928.GC31017@domen.ultra.si> References: <20060623095703.GA30980@domen.ultra.si> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060623095703.GA30980@domen.ultra.si> User-Agent: Mutt/1.5.11+cvs20060126 X-Virus-Scanned: Triera AV Service Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11815 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: domen.puncer@ultra.si Precedence: bulk X-list: linux-mips Add I2C support for au1200. Signed-off-by: Domen Puncer Index: linux-mailed/drivers/i2c/busses/Kconfig =================================================================== --- linux-mailed.orig/drivers/i2c/busses/Kconfig +++ linux-mailed/drivers/i2c/busses/Kconfig @@ -75,11 +75,11 @@ config I2C_AMD8111 will be called i2c-amd8111. config I2C_AU1550 - tristate "Au1550 SMBus interface" - depends on I2C && SOC_AU1550 + tristate "Au1550/Au1200 SMBus interface" + depends on I2C && (SOC_AU1550 || SOC_AU1200) help If you say yes to this option, support will be included for the - Au1550 SMBus interface. + Au1550 and Au1200 SMBus interface. This driver can also be built as a module. If so, the module will be called i2c-au1550. From domen.puncer@ultra.si Fri Jun 23 11:01:24 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 23 Jun 2006 11:01:48 +0100 (BST) Received: from deliver-1.mx.triera.net ([213.161.0.31]:21985 "HELO deliver-1.mx.triera.net") by ftp.linux-mips.org with SMTP id S8133512AbWFWJ74 (ORCPT ); Fri, 23 Jun 2006 10:59:56 +0100 Received: from localhost (in-1.mx.triera.net [213.161.0.25]) by deliver-1.mx.triera.net (Postfix) with ESMTP id 61697C051; Fri, 23 Jun 2006 11:59:45 +0200 (CEST) Received: from smtp.triera.net (smtp.triera.net [213.161.0.30]) by in-1.mx.triera.net (Postfix) with SMTP id 039221BC093; Fri, 23 Jun 2006 11:59:47 +0200 (CEST) Received: from localhost (unknown [213.161.20.162]) by smtp.triera.net (Postfix) with ESMTP id E5F0B1A18B9; Fri, 23 Jun 2006 11:59:47 +0200 (CEST) Date: Fri, 23 Jun 2006 11:59:50 +0200 From: Domen Puncer To: Ralf Baechle Cc: linux-mips@linux-mips.org Subject: [patch 4/8] au1xxx: dbdma, no sleeping under spin_lock Message-ID: <20060623095950.GD31017@domen.ultra.si> References: <20060623095703.GA30980@domen.ultra.si> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060623095703.GA30980@domen.ultra.si> User-Agent: Mutt/1.5.11+cvs20060126 X-Virus-Scanned: Triera AV Service Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11816 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: domen.puncer@ultra.si Precedence: bulk X-list: linux-mips kmalloc under spin_lock can't sleep. Signed-off-by: Domen Puncer Index: linux-mailed/arch/mips/au1000/common/dbdma.c =================================================================== --- linux-mailed.orig/arch/mips/au1000/common/dbdma.c +++ linux-mailed/arch/mips/au1000/common/dbdma.c @@ -290,7 +290,7 @@ au1xxx_dbdma_chan_alloc(u32 srcid, u32 d /* If kmalloc fails, it is caught below same * as a channel not available. */ - ctp = kmalloc(sizeof(chan_tab_t), GFP_KERNEL); + ctp = kmalloc(sizeof(chan_tab_t), GFP_ATOMIC); chan_tab_ptr[i] = ctp; break; } From domen.puncer@ultra.si Fri Jun 23 11:02:26 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 23 Jun 2006 11:02:45 +0100 (BST) Received: from deliver-1.mx.triera.net ([213.161.0.31]:27873 "HELO deliver-1.mx.triera.net") by ftp.linux-mips.org with SMTP id S8133504AbWFWKAa (ORCPT ); Fri, 23 Jun 2006 11:00:30 +0100 Received: from localhost (in-2.mx.triera.net [213.161.0.26]) by deliver-1.mx.triera.net (Postfix) with ESMTP id F20EEC05F; Fri, 23 Jun 2006 12:00:17 +0200 (CEST) Received: from smtp.triera.net (smtp.triera.net [213.161.0.30]) by in-2.mx.triera.net (Postfix) with SMTP id 1045D1BC087; Fri, 23 Jun 2006 12:00:19 +0200 (CEST) Received: from localhost (unknown [213.161.20.162]) by smtp.triera.net (Postfix) with ESMTP id 59DDC1A18B2; Fri, 23 Jun 2006 12:00:19 +0200 (CEST) Date: Fri, 23 Jun 2006 12:00:21 +0200 From: Domen Puncer To: Ralf Baechle Cc: linux-mips@linux-mips.org Subject: [patch 5/8] au1xxx: export dbdma functions Message-ID: <20060623100021.GE31017@domen.ultra.si> References: <20060623095703.GA30980@domen.ultra.si> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060623095703.GA30980@domen.ultra.si> User-Agent: Mutt/1.5.11+cvs20060126 X-Virus-Scanned: Triera AV Service Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11817 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: domen.puncer@ultra.si Precedence: bulk X-list: linux-mips These are needed for au1550_ac97 module. Signed-off-by: Domen Puncer arch/mips/au1000/common/dbdma.c | 4 ++++ 1 file changed, 4 insertions(+) Index: linux-mailed/arch/mips/au1000/common/dbdma.c =================================================================== --- linux-mailed.orig/arch/mips/au1000/common/dbdma.c +++ linux-mailed/arch/mips/au1000/common/dbdma.c @@ -730,6 +730,8 @@ au1xxx_dbdma_get_dest(u32 chanid, void * return rv; } +EXPORT_SYMBOL(au1xxx_dbdma_get_dest); + void au1xxx_dbdma_stop(u32 chanid) { @@ -821,6 +823,8 @@ au1xxx_get_dma_residue(u32 chanid) return rv; } +EXPORT_SYMBOL(au1xxx_get_dma_residue); + void au1xxx_dbdma_chan_free(u32 chanid) { From domen.puncer@ultra.si Fri Jun 23 11:03:28 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 23 Jun 2006 11:03:48 +0100 (BST) Received: from deliver-1.mx.triera.net ([213.161.0.31]:30433 "HELO deliver-1.mx.triera.net") by ftp.linux-mips.org with SMTP id S8133501AbWFWKBA (ORCPT ); Fri, 23 Jun 2006 11:01:00 +0100 Received: from localhost (in-1.mx.triera.net [213.161.0.25]) by deliver-1.mx.triera.net (Postfix) with ESMTP id 5FBCDC051; Fri, 23 Jun 2006 12:00:49 +0200 (CEST) Received: from smtp.triera.net (smtp.triera.net [213.161.0.30]) by in-1.mx.triera.net (Postfix) with SMTP id 78B9F1BC092; Fri, 23 Jun 2006 12:00:51 +0200 (CEST) Received: from localhost (unknown [213.161.20.162]) by smtp.triera.net (Postfix) with ESMTP id 70D8E1A18A8; Fri, 23 Jun 2006 12:00:51 +0200 (CEST) Date: Fri, 23 Jun 2006 12:00:53 +0200 From: Domen Puncer To: Ralf Baechle Cc: linux-mips@linux-mips.org Subject: [patch 6/8] au1xxx: oss sound support for au1200 Message-ID: <20060623100053.GF31017@domen.ultra.si> References: <20060623095703.GA30980@domen.ultra.si> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060623095703.GA30980@domen.ultra.si> User-Agent: Mutt/1.5.11+cvs20060126 X-Virus-Scanned: Triera AV Service Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11818 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: domen.puncer@ultra.si Precedence: bulk X-list: linux-mips au1550 ac97 driver works fine on au1200 too. Comments at the top of file state this code is GPL, so lets mark it as GPL too. Signed-off-by: Domen Puncer Index: linux-mailed/sound/oss/Kconfig =================================================================== --- linux-mailed.orig/sound/oss/Kconfig +++ linux-mailed/sound/oss/Kconfig @@ -114,8 +114,9 @@ config SOUND_VRC5477 with the AC97 codec. config SOUND_AU1550_AC97 - tristate "Au1550 AC97 Sound" - depends on SOUND_PRIME && SOC_AU1550 + tristate "Au1550/Au1200 AC97 Sound" + select SND_AC97_CODEC + depends on SOUND_PRIME && (SOC_AU1550 || SOC_AU1200) config SOUND_AU1550_I2S tristate "Au1550 I2S Sound" Index: linux-mailed/sound/oss/au1550_ac97.c =================================================================== --- linux-mailed.orig/sound/oss/au1550_ac97.c +++ linux-mailed/sound/oss/au1550_ac97.c @@ -1893,6 +1893,8 @@ static /*const */ struct file_operations MODULE_AUTHOR("Advanced Micro Devices (AMD), dan@embeddededge.com"); MODULE_DESCRIPTION("Au1550 AC97 Audio Driver"); +MODULE_LICENSE("GPL"); + static int __devinit au1550_probe(void) From domen.puncer@ultra.si Fri Jun 23 11:04:31 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 23 Jun 2006 11:04:55 +0100 (BST) Received: from deliver-1.mx.triera.net ([213.161.0.31]:35041 "HELO deliver-1.mx.triera.net") by ftp.linux-mips.org with SMTP id S8133619AbWFWKB2 (ORCPT ); Fri, 23 Jun 2006 11:01:28 +0100 Received: from localhost (in-3.mx.triera.net [213.161.0.27]) by deliver-1.mx.triera.net (Postfix) with ESMTP id BA6F9C05F; Fri, 23 Jun 2006 12:01:17 +0200 (CEST) Received: from smtp.triera.net (smtp.triera.net [213.161.0.30]) by in-3.mx.triera.net (Postfix) with SMTP id AF04C1BC084; Fri, 23 Jun 2006 12:01:18 +0200 (CEST) Received: from localhost (unknown [213.161.20.162]) by smtp.triera.net (Postfix) with ESMTP id C23631A18AE; Fri, 23 Jun 2006 12:01:18 +0200 (CEST) Date: Fri, 23 Jun 2006 12:01:21 +0200 From: Domen Puncer To: Ralf Baechle Cc: linux-mips@linux-mips.org Subject: [patch 7/8] au1xxx: compile fixes for OHCI for au1200 Message-ID: <20060623100121.GG31017@domen.ultra.si> References: <20060623095703.GA30980@domen.ultra.si> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060623095703.GA30980@domen.ultra.si> User-Agent: Mutt/1.5.11+cvs20060126 X-Virus-Scanned: Triera AV Service Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11819 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: domen.puncer@ultra.si Precedence: bulk X-list: linux-mips Compile fixes for au1200 ohci. First part looks a bit hackish... but it works for me. Signed-off-by: Domen Puncer Index: linux-mailed/drivers/usb/host/ohci-au1xxx.c =================================================================== --- linux-mailed.orig/drivers/usb/host/ohci-au1xxx.c +++ linux-mailed/drivers/usb/host/ohci-au1xxx.c @@ -101,9 +101,11 @@ static void au1xxx_start_ohc(struct plat #endif /* Au1200 */ +#ifndef CONFIG_SOC_AU1200 /* wait for reset complete (read register twice; see au1500 errata) */ while (au_readl(USB_HOST_CONFIG), !(au_readl(USB_HOST_CONFIG) & USBH_ENABLE_RD)) +#endif udelay(1000); printk(KERN_DEBUG __FILE__ @@ -157,9 +159,9 @@ static int usb_ohci_au1xxx_probe(const s /* Au1200 AB USB does not support coherent memory */ if (!(read_c0_prid() & 0xff)) { pr_info("%s: this is chip revision AB !!\n", - dev->dev.name); + dev->name); pr_info("%s: update your board or re-configure the kernel\n", - dev->dev.name); + dev->name); return -ENODEV; } #endif From domen.puncer@ultra.si Fri Jun 23 11:05:35 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 23 Jun 2006 11:05:58 +0100 (BST) Received: from deliver-1.mx.triera.net ([213.161.0.31]:39393 "HELO deliver-1.mx.triera.net") by ftp.linux-mips.org with SMTP id S8133643AbWFWKBz (ORCPT ); Fri, 23 Jun 2006 11:01:55 +0100 Received: from localhost (in-3.mx.triera.net [213.161.0.27]) by deliver-1.mx.triera.net (Postfix) with ESMTP id B84F1C05F; Fri, 23 Jun 2006 12:01:44 +0200 (CEST) Received: from smtp.triera.net (smtp.triera.net [213.161.0.30]) by in-3.mx.triera.net (Postfix) with SMTP id 92D5D1BC084; Fri, 23 Jun 2006 12:01:46 +0200 (CEST) Received: from localhost (unknown [213.161.20.162]) by smtp.triera.net (Postfix) with ESMTP id 936E31A18AE; Fri, 23 Jun 2006 12:01:46 +0200 (CEST) Date: Fri, 23 Jun 2006 12:01:49 +0200 From: Domen Puncer To: Ralf Baechle Cc: linux-mips@linux-mips.org Subject: [patch 8/8] au1xxx: pcmcia: fix __init called from non-init Message-ID: <20060623100148.GH31017@domen.ultra.si> References: <20060623095703.GA30980@domen.ultra.si> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060623095703.GA30980@domen.ultra.si> User-Agent: Mutt/1.5.11+cvs20060126 X-Virus-Scanned: Triera AV Service Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11820 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: domen.puncer@ultra.si Precedence: bulk X-list: linux-mips This must not be marked __init, as it is called from au1x00_drv_pcmcia_probe. Signed-off-by: Domen Puncer Index: linux-mailed/drivers/pcmcia/au1000_db1x00.c =================================================================== --- linux-mailed.orig/drivers/pcmcia/au1000_db1x00.c +++ linux-mailed/drivers/pcmcia/au1000_db1x00.c @@ -296,7 +296,7 @@ struct pcmcia_low_level db1x00_pcmcia_op .socket_suspend = db1x00_socket_suspend }; -int __init au1x_board_init(struct device *dev) +int au1x_board_init(struct device *dev) { int ret = -ENODEV; bcsr->pcmcia = 0; /* turn off power, if it's not already off */ From ralf@linux-mips.org Fri Jun 23 11:26:04 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 23 Jun 2006 11:26:14 +0100 (BST) Received: from localhost.localdomain ([127.0.0.1]:29853 "EHLO bacchus.dhis.org") by ftp.linux-mips.org with ESMTP id S8133532AbWFWK0E (ORCPT ); Fri, 23 Jun 2006 11:26:04 +0100 Received: from denk.linux-mips.net (denk.linux-mips.net [127.0.0.1]) by bacchus.dhis.org (8.13.6/8.13.4) with ESMTP id k5NAQ4gj006082; Fri, 23 Jun 2006 11:26:04 +0100 Received: (from ralf@localhost) by denk.linux-mips.net (8.13.6/8.13.6/Submit) id k5NAQ4Da006081; Fri, 23 Jun 2006 11:26:04 +0100 Date: Fri, 23 Jun 2006 11:26:04 +0100 From: Ralf Baechle To: Domen Puncer Cc: linux-mips@linux-mips.org Subject: Re: [patch 2/8] au1xxx: I2C fixes Message-ID: <20060623102604.GC5896@linux-mips.org> References: <20060623095703.GA30980@domen.ultra.si> <20060623095858.GB31017@domen.ultra.si> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060623095858.GB31017@domen.ultra.si> User-Agent: Mutt/1.4.2.1i Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11821 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ralf@linux-mips.org Precedence: bulk X-list: linux-mips Forwarded to the I2C maintainer. Ralf From ralf@linux-mips.org Fri Jun 23 11:26:49 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 23 Jun 2006 11:27:11 +0100 (BST) Received: from localhost.localdomain ([127.0.0.1]:32669 "EHLO bacchus.dhis.org") by ftp.linux-mips.org with ESMTP id S8133716AbWFWK0Y (ORCPT ); Fri, 23 Jun 2006 11:26:24 +0100 Received: from denk.linux-mips.net (denk.linux-mips.net [127.0.0.1]) by bacchus.dhis.org (8.13.6/8.13.4) with ESMTP id k5NAQOP6006088; Fri, 23 Jun 2006 11:26:24 +0100 Received: (from ralf@localhost) by denk.linux-mips.net (8.13.6/8.13.6/Submit) id k5NAQOdE006087; Fri, 23 Jun 2006 11:26:24 +0100 Date: Fri, 23 Jun 2006 11:26:24 +0100 From: Ralf Baechle To: Domen Puncer Cc: linux-mips@linux-mips.org Subject: Re: [patch 3/8] au1xxx: I2C support for au1200 Message-ID: <20060623102624.GD5896@linux-mips.org> References: <20060623095703.GA30980@domen.ultra.si> <20060623095928.GC31017@domen.ultra.si> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060623095928.GC31017@domen.ultra.si> User-Agent: Mutt/1.4.2.1i Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11822 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ralf@linux-mips.org Precedence: bulk X-list: linux-mips Forwarded to the I2C maintainer. Ralf From ralf@linux-mips.org Fri Jun 23 11:33:43 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 23 Jun 2006 11:33:54 +0100 (BST) Received: from localhost.localdomain ([127.0.0.1]:47584 "EHLO bacchus.dhis.org") by ftp.linux-mips.org with ESMTP id S8133627AbWFWKdn (ORCPT ); Fri, 23 Jun 2006 11:33:43 +0100 Received: from denk.linux-mips.net (denk.linux-mips.net [127.0.0.1]) by bacchus.dhis.org (8.13.6/8.13.4) with ESMTP id k5NAXhIS006365; Fri, 23 Jun 2006 11:33:43 +0100 Received: (from ralf@localhost) by denk.linux-mips.net (8.13.6/8.13.6/Submit) id k5NAXhKT006364; Fri, 23 Jun 2006 11:33:43 +0100 Date: Fri, 23 Jun 2006 11:33:43 +0100 From: Ralf Baechle To: Domen Puncer Cc: linux-mips@linux-mips.org Subject: Re: [patch 5/8] au1xxx: export dbdma functions Message-ID: <20060623103343.GE5896@linux-mips.org> References: <20060623095703.GA30980@domen.ultra.si> <20060623100021.GE31017@domen.ultra.si> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060623100021.GE31017@domen.ultra.si> User-Agent: Mutt/1.4.2.1i Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11823 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ralf@linux-mips.org Precedence: bulk X-list: linux-mips On Fri, Jun 23, 2006 at 12:00:21PM +0200, Domen Puncer wrote: > These are needed for au1550_ac97 module. > > Signed-off-by: Domen Puncer Will apply but change that to EXPORT_SYMBOL_GPL. Ralf From ralf@linux-mips.org Fri Jun 23 11:56:52 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 23 Jun 2006 11:57:01 +0100 (BST) Received: from localhost.localdomain ([127.0.0.1]:21485 "EHLO bacchus.dhis.org") by ftp.linux-mips.org with ESMTP id S8133508AbWFWK4w (ORCPT ); Fri, 23 Jun 2006 11:56:52 +0100 Received: from denk.linux-mips.net (denk.linux-mips.net [127.0.0.1]) by bacchus.dhis.org (8.13.6/8.13.4) with ESMTP id k5NAuqtJ007105; Fri, 23 Jun 2006 11:56:52 +0100 Received: (from ralf@localhost) by denk.linux-mips.net (8.13.6/8.13.6/Submit) id k5NAuqt1007104; Fri, 23 Jun 2006 11:56:52 +0100 Date: Fri, 23 Jun 2006 11:56:51 +0100 From: Ralf Baechle To: Domen Puncer Cc: linux-mips@linux-mips.org Subject: Re: [patch 7/8] au1xxx: compile fixes for OHCI for au1200 Message-ID: <20060623105651.GI5896@linux-mips.org> References: <20060623095703.GA30980@domen.ultra.si> <20060623100121.GG31017@domen.ultra.si> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060623100121.GG31017@domen.ultra.si> User-Agent: Mutt/1.4.2.1i Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11824 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ralf@linux-mips.org Precedence: bulk X-list: linux-mips On Fri, Jun 23, 2006 at 12:01:21PM +0200, Domen Puncer wrote: > Compile fixes for au1200 ohci. > > First part looks a bit hackish... but it works for me. That very much represents the character of the Alchemy code, I'm afaird. Which in turn probably is the result of a few too many hardware variants. Forwarded to the USB maintainer & list. Ralf From ralf@linux-mips.org Fri Jun 23 12:07:19 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 23 Jun 2006 12:07:28 +0100 (BST) Received: from localhost.localdomain ([127.0.0.1]:37821 "EHLO bacchus.dhis.org") by ftp.linux-mips.org with ESMTP id S8133512AbWFWLHT (ORCPT ); Fri, 23 Jun 2006 12:07:19 +0100 Received: from denk.linux-mips.net (denk.linux-mips.net [127.0.0.1]) by bacchus.dhis.org (8.13.6/8.13.4) with ESMTP id k5NB7JO8007479; Fri, 23 Jun 2006 12:07:19 +0100 Received: (from ralf@localhost) by denk.linux-mips.net (8.13.6/8.13.6/Submit) id k5NB7Jg4007478; Fri, 23 Jun 2006 12:07:19 +0100 Date: Fri, 23 Jun 2006 12:07:19 +0100 From: Ralf Baechle To: Domen Puncer Cc: linux-mips@linux-mips.org Subject: Re: [patch 8/8] au1xxx: pcmcia: fix __init called from non-init Message-ID: <20060623110719.GK5896@linux-mips.org> References: <20060623095703.GA30980@domen.ultra.si> <20060623100148.GH31017@domen.ultra.si> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060623100148.GH31017@domen.ultra.si> User-Agent: Mutt/1.4.2.1i Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11825 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ralf@linux-mips.org Precedence: bulk X-list: linux-mips Forwarded to the PCMCIA list. Ralf From ralf@linux-mips.org Fri Jun 23 12:15:24 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 23 Jun 2006 12:15:35 +0100 (BST) Received: from localhost.localdomain ([127.0.0.1]:64206 "EHLO bacchus.dhis.org") by ftp.linux-mips.org with ESMTP id S8133563AbWFWLPY (ORCPT ); Fri, 23 Jun 2006 12:15:24 +0100 Received: from denk.linux-mips.net (denk.linux-mips.net [127.0.0.1]) by bacchus.dhis.org (8.13.6/8.13.4) with ESMTP id k5NBFNvX007935; Fri, 23 Jun 2006 12:15:23 +0100 Received: (from ralf@localhost) by denk.linux-mips.net (8.13.6/8.13.6/Submit) id k5NBFNK1007934; Fri, 23 Jun 2006 12:15:23 +0100 Date: Fri, 23 Jun 2006 12:15:23 +0100 From: Ralf Baechle To: Domen Puncer Cc: linux-mips@linux-mips.org Subject: Re: [patch 1/8] au1xxx: psc fixes + add au1200 adresses Message-ID: <20060623111523.GM5896@linux-mips.org> References: <20060623095703.GA30980@domen.ultra.si> <20060623095831.GA31017@domen.ultra.si> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060623095831.GA31017@domen.ultra.si> User-Agent: Mutt/1.4.2.1i Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11826 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ralf@linux-mips.org Precedence: bulk X-list: linux-mips On Fri, Jun 23, 2006 at 11:58:31AM +0200, Domen Puncer wrote: Applied. Ralf From ralf@linux-mips.org Fri Jun 23 12:16:12 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 23 Jun 2006 12:16:27 +0100 (BST) Received: from localhost.localdomain ([127.0.0.1]:17616 "EHLO bacchus.dhis.org") by ftp.linux-mips.org with ESMTP id S8133563AbWFWLQM (ORCPT ); Fri, 23 Jun 2006 12:16:12 +0100 Received: from denk.linux-mips.net (denk.linux-mips.net [127.0.0.1]) by bacchus.dhis.org (8.13.6/8.13.4) with ESMTP id k5NBGBiG007955; Fri, 23 Jun 2006 12:16:11 +0100 Received: (from ralf@localhost) by denk.linux-mips.net (8.13.6/8.13.6/Submit) id k5NBGBxM007954; Fri, 23 Jun 2006 12:16:11 +0100 Date: Fri, 23 Jun 2006 12:16:11 +0100 From: Ralf Baechle To: Domen Puncer Cc: linux-mips@linux-mips.org Subject: Re: [patch 4/8] au1xxx: dbdma, no sleeping under spin_lock Message-ID: <20060623111611.GN5896@linux-mips.org> References: <20060623095703.GA30980@domen.ultra.si> <20060623095950.GD31017@domen.ultra.si> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060623095950.GD31017@domen.ultra.si> User-Agent: Mutt/1.4.2.1i Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11827 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ralf@linux-mips.org Precedence: bulk X-list: linux-mips On Fri, Jun 23, 2006 at 11:59:50AM +0200, Domen Puncer wrote: > kmalloc under spin_lock can't sleep. Applied. Ralf From sshtylyov@ru.mvista.com Fri Jun 23 13:58:32 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 23 Jun 2006 13:58:41 +0100 (BST) Received: from rtsoft2.corbina.net ([85.21.88.2]:23732 "HELO mail.dev.rtsoft.ru") by ftp.linux-mips.org with SMTP id S8133571AbWFWM6c (ORCPT ); Fri, 23 Jun 2006 13:58:32 +0100 Received: (qmail 5976 invoked from network); 23 Jun 2006 17:10:04 -0000 Received: from wasted.dev.rtsoft.ru (HELO ?192.168.1.248?) (192.168.1.248) by mail.dev.rtsoft.ru with SMTP; 23 Jun 2006 17:10:04 -0000 Message-ID: <449BE538.5030203@ru.mvista.com> Date: Fri, 23 Jun 2006 16:57:28 +0400 From: Sergei Shtylyov Organization: MontaVista Software Inc. User-Agent: Mozilla/5.0 (X11; U; Linux i686; rv:1.7.2) Gecko/20040803 X-Accept-Language: ru, en-us, en-gb MIME-Version: 1.0 To: Domen Puncer , Ralf Baechle CC: linux-mips@linux-mips.org Subject: Re: [patch 1/8] au1xxx: psc fixes + add au1200 adresses References: <20060623095703.GA30980@domen.ultra.si> <20060623095831.GA31017@domen.ultra.si> In-Reply-To: <20060623095831.GA31017@domen.ultra.si> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11828 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: sshtylyov@ru.mvista.com Precedence: bulk X-list: linux-mips Hello. Domen Puncer wrote: > Based on Jordan Crusoe's i2c patch: > - fix PSC3_BASE_ADDR to match au1550 databook > - fix PSC_SMBTXRX_RSR > - add PSC addresses for au1200 That was my patch, originally. And (surprise!) it just went from the -mm tree to Linus. Congrats, now we're going to have a patch conflict. :-) > Signed-off-by: Domen Puncer > Index: linux-mailed/include/asm-mips/mach-au1x00/au1xxx_psc.h > =================================================================== > --- linux-mailed.orig/include/asm-mips/mach-au1x00/au1xxx_psc.h > +++ linux-mailed/include/asm-mips/mach-au1x00/au1xxx_psc.h > @@ -40,7 +40,12 @@ > #define PSC0_BASE_ADDR 0xb1a00000 > #define PSC1_BASE_ADDR 0xb1b00000 > #define PSC2_BASE_ADDR 0xb0a00000 > -#define PSC3_BASE_ADDR 0xb0d00000 > +#define PSC3_BASE_ADDR 0xb0b00000 > +#endif > + > +#ifdef CONFIG_SOC_AU1200 > +#define PSC0_BASE_ADDR 0xb1a00000 > +#define PSC1_BASE_ADDR 0xb1b00000 > #endif > > /* The PSC select and control registers are common to > @@ -506,7 +511,7 @@ typedef struct psc_smb { > > /* Transmit register control. > */ > -#define PSC_SMBTXRX_RSR (1 << 30) > +#define PSC_SMBTXRX_RSR (1 << 28) > #define PSC_SMBTXRX_STP (1 << 29) > #define PSC_SMBTXRX_DATAMASK (0xff) WBR, Sergei From domen@coderock.org Fri Jun 23 14:52:09 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 23 Jun 2006 14:52:21 +0100 (BST) Received: from coderock.org ([193.77.147.115]:33987 "EHLO trashy.coderock.org") by ftp.linux-mips.org with ESMTP id S8133500AbWFWNwJ (ORCPT ); Fri, 23 Jun 2006 14:52:09 +0100 Received: by trashy.coderock.org (Postfix, from userid 780) id 7F1F31470; Fri, 23 Jun 2006 15:52:06 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by trashy.coderock.org (Postfix) with ESMTP id DEDE8146F; Fri, 23 Jun 2006 15:52:05 +0200 (CEST) Received: from localhost (coderock.org [193.77.147.115]) by trashy.coderock.org (Postfix) with ESMTP id 5B36513E; Fri, 23 Jun 2006 15:52:03 +0200 (CEST) Date: Fri, 23 Jun 2006 15:52:02 +0200 From: Domen Puncer To: Ralf Baechle Cc: Domen Puncer , linux-mips@linux-mips.org Subject: Re: [patch 5/8] au1xxx: export dbdma functions Message-ID: <20060623135202.GA9098@nd47.coderock.org> References: <20060623095703.GA30980@domen.ultra.si> <20060623100021.GE31017@domen.ultra.si> <20060623103343.GE5896@linux-mips.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060623103343.GE5896@linux-mips.org> User-Agent: Mutt/1.4.2.1i Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11829 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: domen@coderock.org Precedence: bulk X-list: linux-mips These are needed for au1550_ac97 module. Signed-off-by: Domen Puncer Index: linux-mailed/arch/mips/au1000/common/dbdma.c =================================================================== --- linux-mailed.orig/arch/mips/au1000/common/dbdma.c +++ linux-mailed/arch/mips/au1000/common/dbdma.c @@ -730,6 +730,8 @@ au1xxx_dbdma_get_dest(u32 chanid, void * return rv; } +EXPORT_SYMBOL_GPL(au1xxx_dbdma_get_dest); + void au1xxx_dbdma_stop(u32 chanid) { @@ -821,6 +823,8 @@ au1xxx_get_dma_residue(u32 chanid) return rv; } +EXPORT_SYMBOL_GPL(au1xxx_get_dma_residue); + void au1xxx_dbdma_chan_free(u32 chanid) { From domen@coderock.org Fri Jun 23 14:54:42 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 23 Jun 2006 14:54:51 +0100 (BST) Received: from coderock.org ([193.77.147.115]:35267 "EHLO trashy.coderock.org") by ftp.linux-mips.org with ESMTP id S8133511AbWFWNym (ORCPT ); Fri, 23 Jun 2006 14:54:42 +0100 Received: by trashy.coderock.org (Postfix, from userid 780) id 6DC8D1470; Fri, 23 Jun 2006 15:54:40 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by trashy.coderock.org (Postfix) with ESMTP id DE968146F; Fri, 23 Jun 2006 15:54:39 +0200 (CEST) Received: from localhost (coderock.org [193.77.147.115]) by trashy.coderock.org (Postfix) with ESMTP id 442EC13E; Fri, 23 Jun 2006 15:54:37 +0200 (CEST) Date: Fri, 23 Jun 2006 15:54:36 +0200 From: Domen Puncer To: Sergei Shtylyov Cc: Domen Puncer , Ralf Baechle , linux-mips@linux-mips.org Subject: Re: [patch 1/8] au1xxx: psc fixes + add au1200 adresses Message-ID: <20060623135436.GB9098@nd47.coderock.org> References: <20060623095703.GA30980@domen.ultra.si> <20060623095831.GA31017@domen.ultra.si> <449BE538.5030203@ru.mvista.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <449BE538.5030203@ru.mvista.com> User-Agent: Mutt/1.4.2.1i Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11830 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: domen@coderock.org Precedence: bulk X-list: linux-mips On 23/06/06 16:57 +0400, Sergei Shtylyov wrote: > Hello. > > Domen Puncer wrote: > >Based on Jordan Crusoe's i2c patch: > >- fix PSC3_BASE_ADDR to match au1550 databook > >- fix PSC_SMBTXRX_RSR > >- add PSC addresses for au1200 > > That was my patch, originally. And (surprise!) it just went from the -mm > tree to Linus. Congrats, now we're going to have a patch conflict. :-) Oh... sorry. I guess waiting sometimes does solve the problem :-) Domen From ralf@linux-mips.org Fri Jun 23 16:37:11 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 23 Jun 2006 16:37:26 +0100 (BST) Received: from localhost.localdomain ([127.0.0.1]:59579 "EHLO bacchus.dhis.org") by ftp.linux-mips.org with ESMTP id S8133941AbWFWPhL (ORCPT ); Fri, 23 Jun 2006 16:37:11 +0100 Received: from denk.linux-mips.net (denk.linux-mips.net [127.0.0.1]) by bacchus.dhis.org (8.13.6/8.13.4) with ESMTP id k5NFbBa2023348; Fri, 23 Jun 2006 16:37:11 +0100 Received: (from ralf@localhost) by denk.linux-mips.net (8.13.6/8.13.6/Submit) id k5NFb9Aj023347; Fri, 23 Jun 2006 16:37:09 +0100 Date: Fri, 23 Jun 2006 16:37:09 +0100 From: Ralf Baechle To: Sergei Shtylyov Cc: Domen Puncer , linux-mips@linux-mips.org Subject: Re: [patch 1/8] au1xxx: psc fixes + add au1200 adresses Message-ID: <20060623153709.GA23267@linux-mips.org> References: <20060623095703.GA30980@domen.ultra.si> <20060623095831.GA31017@domen.ultra.si> <449BE538.5030203@ru.mvista.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <449BE538.5030203@ru.mvista.com> User-Agent: Mutt/1.4.2.1i Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11831 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ralf@linux-mips.org Precedence: bulk X-list: linux-mips On Fri, Jun 23, 2006 at 04:57:28PM +0400, Sergei Shtylyov wrote: > That was my patch, originally. And (surprise!) it just went from the -mm > tree to Linus. Congrats, now we're going to have a patch conflict. :-) Shit happens - but it's annoying have to sort that out so better be avoided ... Ralf From sshtylyov@ru.mvista.com Fri Jun 23 17:14:28 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 23 Jun 2006 17:14:39 +0100 (BST) Received: from rtsoft2.corbina.net ([85.21.88.2]:10375 "HELO mail.dev.rtsoft.ru") by ftp.linux-mips.org with SMTP id S8133547AbWFWQO2 (ORCPT ); Fri, 23 Jun 2006 17:14:28 +0100 Received: (qmail 8096 invoked from network); 23 Jun 2006 20:25:53 -0000 Received: from wasted.dev.rtsoft.ru (HELO ?192.168.1.248?) (192.168.1.248) by mail.dev.rtsoft.ru with SMTP; 23 Jun 2006 20:25:53 -0000 Message-ID: <449C131B.5090406@ru.mvista.com> Date: Fri, 23 Jun 2006 20:13:15 +0400 From: Sergei Shtylyov Organization: MontaVista Software Inc. User-Agent: Mozilla/5.0 (X11; U; Linux i686; rv:1.7.2) Gecko/20040803 X-Accept-Language: ru, en-us, en-gb MIME-Version: 1.0 To: Domen Puncer CC: linux-mips@linux-mips.org Subject: Re: [patch 2/8] au1xxx: I2C fixes References: <20060623095703.GA30980@domen.ultra.si> <20060623095858.GB31017@domen.ultra.si> In-Reply-To: <20060623095858.GB31017@domen.ultra.si> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11832 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: sshtylyov@ru.mvista.com Precedence: bulk X-list: linux-mips Hello. Domen Puncer wrote: > - I2C fixes from Jordan Crusoe > - add SMBUS functionality flags > > Signed-off-by: Domen Puncer > > Index: linux-mailed/drivers/i2c/busses/i2c-au1550.c > =================================================================== > --- linux-mailed.orig/drivers/i2c/busses/i2c-au1550.c > +++ linux-mailed/drivers/i2c/busses/i2c-au1550.c > @@ -35,7 +35,7 @@ > #include > > #include also #include's that file, BTW. So, could be omitted here... > -#include > +#include > #include > > #include "i2c-au1550.h" WBR, Sergei From daniel@caiaq.de Fri Jun 23 17:52:19 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 23 Jun 2006 17:52:28 +0100 (BST) Received: from buzzloop.caiaq.de ([212.112.241.133]:34062 "EHLO buzzloop.caiaq.de") by ftp.linux-mips.org with ESMTP id S8133506AbWFWQwS (ORCPT ); Fri, 23 Jun 2006 17:52:18 +0100 Received: from localhost (localhost [127.0.0.1]) by buzzloop.caiaq.de (Postfix) with ESMTP id 8E6867F4028 for ; Fri, 23 Jun 2006 18:52:15 +0200 (CEST) Received: from buzzloop.caiaq.de ([127.0.0.1]) by localhost (buzzloop [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 31929-02 for ; Fri, 23 Jun 2006 18:52:15 +0200 (CEST) Received: from [192.168.1.140] (port-83-236-238-37.static.qsc.de [83.236.238.37]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by buzzloop.caiaq.de (Postfix) with ESMTP id 0A32A7F4022 for ; Fri, 23 Jun 2006 18:52:14 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v750) Content-Transfer-Encoding: 7bit Message-Id: <5798565C-F3E1-4EB5-8886-51D65BEFEF02@caiaq.de> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: linux-mips@linux-mips.org From: Daniel Mack Subject: [PATCH] au1200 USB - EHCI and OHCI fixes Date: Fri, 23 Jun 2006 18:52:09 +0200 X-Mailer: Apple Mail (2.750) Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11833 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: daniel@caiaq.de Precedence: bulk X-list: linux-mips Dear mips list, I received an DBAU1200 eval kit from AMD a few days ago and tried to enable the USB2 port, but the current linux-2.6 GIT did not even compile with CONFIG_SOC_1200, CONFIG_SOC_AU1X00, CONFIG_USB_EHCI and CONFIG_USB_OHCI set. Furthermore, in ehci-hcd.c, platform_driver_register() was called with an improper argument of type 'struct device_driver *' which of course ended up in a kernel oops. How could that ever have worked on your machines? Anyway, here's a trivial patch that makes the USB subsystem working on my board for both OHCI and EHCI. It also removes the /* FIXME use "struct platform_driver" */. Cheers, Daniel Signed-off-by: Daniel Mack diff --git a/drivers/usb/host/ehci-au1xxx.c b/drivers/usb/host/ehci- au1xxx.c index 9b4697a..aed6ada 100644 --- a/drivers/usb/host/ehci-au1xxx.c +++ b/drivers/usb/host/ehci-au1xxx.c @@ -41,8 +41,6 @@ #endif #define USBH_DISABLE (USB_MCFG_EBMEN | USB_MCFG_EMEMEN) -#endif /* Au1200 */ - extern int usb_disabled(void); / *----------------------------------------------------------------------- --*/ @@ -107,9 +105,9 @@ int usb_ehci_au1xxx_probe(const struct h /* Au1200 AB USB does not support coherent memory */ if (!(read_c0_prid() & 0xff)) { - pr_info("%s: this is chip revision AB!\n", dev->dev.name); + pr_info("%s: this is chip revision AB!\n", dev->name); pr_info("%s: update your board or re-configure the kernel\n", - dev->dev.name); + dev->name); return -ENODEV; } #endif @@ -228,9 +226,8 @@ static const struct hc_driver ehci_au1xx / *----------------------------------------------------------------------- --*/ -static int ehci_hcd_au1xxx_drv_probe(struct device *dev) +static int ehci_hcd_au1xxx_drv_probe(struct platform_device *pdev) { - struct platform_device *pdev = to_platform_device(dev); struct usb_hcd *hcd = NULL; int ret; @@ -243,10 +240,9 @@ static int ehci_hcd_au1xxx_drv_probe(str return ret; } -static int ehci_hcd_au1xxx_drv_remove(struct device *dev) +static int ehci_hcd_au1xxx_drv_remove(struct platform_device *pdev) { - struct platform_device *pdev = to_platform_device(dev); - struct usb_hcd *hcd = dev_get_drvdata(dev); + struct usb_hcd *hcd = platform_get_drvdata(pdev); usb_ehci_au1xxx_remove(hcd, pdev); return 0; @@ -269,12 +265,13 @@ static int ehci_hcd_au1xxx_drv_resume(st } */ MODULE_ALIAS("au1xxx-ehci"); -/* FIXME use "struct platform_driver" */ -static struct device_driver ehci_hcd_au1xxx_driver = { - .name = "au1xxx-ehci", - .bus = &platform_bus_type, +static struct platform_driver ehci_hcd_au1xxx_driver = { .probe = ehci_hcd_au1xxx_drv_probe, .remove = ehci_hcd_au1xxx_drv_remove, /*.suspend = ehci_hcd_au1xxx_drv_suspend, */ /*.resume = ehci_hcd_au1xxx_drv_resume, */ + .driver = { + .name = "au1xxx-ehci", + .bus = &platform_bus_type + } }; diff --git a/drivers/usb/host/ohci-au1xxx.c b/drivers/usb/host/ohci- au1xxx.c index a1c8b3b..64c2fb2 100644 --- a/drivers/usb/host/ohci-au1xxx.c +++ b/drivers/usb/host/ohci-au1xxx.c @@ -101,6 +101,7 @@ static void au1xxx_start_ohc(struct plat #endif /* Au1200 */ +#ifndef CONFIG_SOC_AU1200 /* wait for reset complete (read register twice; see au1500 errata) */ while (au_readl(USB_HOST_CONFIG), !(au_readl(USB_HOST_CONFIG) & USBH_ENABLE_RD)) @@ -108,6 +109,7 @@ static void au1xxx_start_ohc(struct plat printk(KERN_DEBUG __FILE__ ": Clock to USB host has been enabled \n"); +#endif } static void au1xxx_stop_ohc(struct platform_device *dev) @@ -157,9 +159,9 @@ static int usb_ohci_au1xxx_probe(const s /* Au1200 AB USB does not support coherent memory */ if (!(read_c0_prid() & 0xff)) { pr_info("%s: this is chip revision AB !!\n", - dev->dev.name); + dev->name); pr_info("%s: update your board or re-configure the kernel\n", - dev->dev.name); + dev->name); return -ENODEV; } #endif From sshtylyov@ru.mvista.com Fri Jun 23 17:59:20 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 23 Jun 2006 17:59:28 +0100 (BST) Received: from rtsoft2.corbina.net ([85.21.88.2]:21906 "HELO mail.dev.rtsoft.ru") by ftp.linux-mips.org with SMTP id S8133553AbWFWQ7T (ORCPT ); Fri, 23 Jun 2006 17:59:19 +0100 Received: (qmail 8331 invoked from network); 23 Jun 2006 21:10:54 -0000 Received: from wasted.dev.rtsoft.ru (HELO ?192.168.1.248?) (192.168.1.248) by mail.dev.rtsoft.ru with SMTP; 23 Jun 2006 21:10:54 -0000 Message-ID: <449C1DA8.9090800@ru.mvista.com> Date: Fri, 23 Jun 2006 20:58:16 +0400 From: Sergei Shtylyov Organization: MontaVista Software Inc. User-Agent: Mozilla/5.0 (X11; U; Linux i686; rv:1.7.2) Gecko/20040803 X-Accept-Language: ru, en-us, en-gb MIME-Version: 1.0 To: Domen Puncer CC: linux-mips@linux-mips.org Subject: Re: u-boot problem: Au1xx0: fix prom_getenv() to handle YAMON style environment References: <20060623082348.GB18607@domen.ultra.si> In-Reply-To: <20060623082348.GB18607@domen.ultra.si> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11834 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: sshtylyov@ru.mvista.com Precedence: bulk X-list: linux-mips Hello. Domen Puncer wrote: > I need to revert $SUBJECT patch for kernel to boot on au1200, > u-boot 1.1.3. > And I could swear it worked booted yesterday without reverting (??) Hm, it sort of worked with YAMON before that patch (just not quite correctly) due to the fact the name strings seem to be followed by the value strings (just not '='but '\0' being between them). But obviously, the variable values could be taken for the names the way it was written. If the purpose was to support both YAMON and U-Boot, that should've been marked in the comments I think... > Could we support yamon and u-boot style environment? Is there a way to distinguish them? > Domen WBR, Sergei From daniel@caiaq.de Fri Jun 23 18:20:26 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 23 Jun 2006 18:20:36 +0100 (BST) Received: from buzzloop.caiaq.de ([212.112.241.133]:63241 "EHLO buzzloop.caiaq.de") by ftp.linux-mips.org with ESMTP id S8133506AbWFWRU0 (ORCPT ); Fri, 23 Jun 2006 18:20:26 +0100 Received: from localhost (localhost [127.0.0.1]) by buzzloop.caiaq.de (Postfix) with ESMTP id 944AA7F4028 for ; Fri, 23 Jun 2006 19:20:23 +0200 (CEST) Received: from buzzloop.caiaq.de ([127.0.0.1]) by localhost (buzzloop [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 31929-06 for ; Fri, 23 Jun 2006 19:20:23 +0200 (CEST) Received: from [192.168.1.140] (port-83-236-238-37.static.qsc.de [83.236.238.37]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by buzzloop.caiaq.de (Postfix) with ESMTP id 465C27F4022 for ; Fri, 23 Jun 2006 19:20:23 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v750) Content-Transfer-Encoding: 7bit Message-Id: <5B414347-B938-4E68-812E-627AED1A38B0@caiaq.de> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: linux-mips@linux-mips.org From: Daniel Mack Subject: smc91x ethernet an DBAU1200 Date: Fri, 23 Jun 2006 19:20:19 +0200 X-Mailer: Apple Mail (2.750) Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11835 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: daniel@caiaq.de Precedence: bulk X-list: linux-mips Hi list, is there anyone out there successfully using the SMC 91C111 ethernet chip on AMD's DBAU1200 eval kit? In my setup here, it's working fine from within the YAMON boot loader so I can use it to download a kernel image via TFTP. The kernel (bleeding edge linux-2.6 mips-GIT) detects the device as well smc91x.c: v1.1, sep 22 2004 by Nicolas Pitre eth0: SMC91C11xFD (rev 1) at b9000300 IRQ 65 [nowait] eth0: Ethernet addr: 00:00:1a:19:11:8c and is able to mount its root filesystem via NFS. However, the communication does not seem to be sufficiently stable, messages like this occur regularily: nfs: server 192.168.1.200 not responding, still trying nfs: server 192.168.1.200 not responding, still trying As the machine acts as NFS server for several other linux embedded systems, I don't suspect it to be the problem. Also, things like cables etc have been properly checked. Before I'm starting research, I'd like to know whether this is a known issue or whether there are any mandatory settings I missed. Thanks for any hint, Daniel From sshtylyov@ru.mvista.com Fri Jun 23 18:36:34 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 23 Jun 2006 18:36:43 +0100 (BST) Received: from rtsoft2.corbina.net ([85.21.88.2]:51098 "HELO mail.dev.rtsoft.ru") by ftp.linux-mips.org with SMTP id S8133506AbWFWRge (ORCPT ); Fri, 23 Jun 2006 18:36:34 +0100 Received: (qmail 8563 invoked from network); 23 Jun 2006 21:48:09 -0000 Received: from wasted.dev.rtsoft.ru (HELO ?192.168.1.248?) (192.168.1.248) by mail.dev.rtsoft.ru with SMTP; 23 Jun 2006 21:48:09 -0000 Message-ID: <449C2663.4060501@ru.mvista.com> Date: Fri, 23 Jun 2006 21:35:31 +0400 From: Sergei Shtylyov Organization: MontaVista Software Inc. User-Agent: Mozilla/5.0 (X11; U; Linux i686; rv:1.7.2) Gecko/20040803 X-Accept-Language: ru, en-us, en-gb MIME-Version: 1.0 To: Domen Puncer CC: linux-mips@linux-mips.org Subject: Re: u-boot problem: Au1xx0: fix prom_getenv() to handle YAMON style environment References: <20060623082348.GB18607@domen.ultra.si> <449C1DA8.9090800@ru.mvista.com> In-Reply-To: <449C1DA8.9090800@ru.mvista.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11836 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: sshtylyov@ru.mvista.com Precedence: bulk X-list: linux-mips Hello, I wrote: >> I need to revert $SUBJECT patch for kernel to boot on au1200, >> u-boot 1.1.3. >> And I could swear it worked booted yesterday without reverting (??) > Hm, it sort of worked with YAMON before that patch (just not quite > correctly) due to the fact the name strings seem to be followed by the > value strings (just not '='but '\0' being between them). But obviously, > the variable values could be taken for the names the way it was written. > If the purpose was to support both YAMON and U-Boot, that should've been > marked in the comments I think... >> Could we support yamon and u-boot style environment? > Is there a way to distinguish them? Well, I think some adaptive alogrithm using strchr(env, '=') should be possible... >> Domen WBR, Sergei From wilson@specifix.com Fri Jun 23 20:01:41 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 23 Jun 2006 20:01:51 +0100 (BST) Received: from w099.z064220152.sjc-ca.dsl.cnc.net ([64.220.152.99]:28852 "EHLO duck.specifix.com") by ftp.linux-mips.org with ESMTP id S8133591AbWFWTBl (ORCPT ); Fri, 23 Jun 2006 20:01:41 +0100 Received: from [127.0.0.1] (duck.corp.specifix.com [192.168.1.1]) by duck.specifix.com (Postfix) with ESMTP id DFEFDFC50; Fri, 23 Jun 2006 12:01:21 -0700 (PDT) Subject: Re: gcc-4.1.0 cross-compile for MIPS From: James E Wilson To: kernel coder Cc: linux-mips@linux-mips.org In-Reply-To: References: <1150497195.17820.4.camel@aretha.corp.specifix.com> Content-Type: text/plain Message-Id: <1151089281.25695.11.camel@aretha.corp.specifix.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Fri, 23 Jun 2006 12:01:21 -0700 Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11837 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: wilson@specifix.com Precedence: bulk X-list: linux-mips On Sun, 2006-06-18 at 23:40, kernel coder wrote: > ../glibc-2.3.6/configure --host=mipsel-linux --prefix="/usr" > --enable-add-ons --with-headers=/home/shahzad/install/mipsel/include > "misc/sys/uio.h"'; } | \ gcc -mabi=32 -E -dM -MD -MP > cc1: error: unrecognized command line option "-mabi=32" It failed, because it tries to give mips compiler options to the native (x86?) compiler, which obviously won't work. And you got this failure because you configured glibc wrong. As always, the answer to this problem can be found in Dan Kegel's crosstools package, which knows how to correctly configure glibc. Since you apparently haven't taken my previous hints, instead of giving you the answer, I'm just going to point you at the crosstools package, and ask you to look it up yourself. -- Jim Wilson, GNU Tools Support, http://www.specifix.com From ralf@linux-mips.org Fri Jun 23 21:07:26 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 23 Jun 2006 21:07:34 +0100 (BST) Received: from localhost.localdomain ([127.0.0.1]:39911 "EHLO bacchus.dhis.org") by ftp.linux-mips.org with ESMTP id S8133645AbWFWUH0 (ORCPT ); Fri, 23 Jun 2006 21:07:26 +0100 Received: from denk.linux-mips.net (denk.linux-mips.net [127.0.0.1]) by bacchus.dhis.org (8.13.6/8.13.4) with ESMTP id k5NK7PWi004161; Fri, 23 Jun 2006 21:07:25 +0100 Received: (from ralf@localhost) by denk.linux-mips.net (8.13.6/8.13.6/Submit) id k5NK7Mkc004150; Fri, 23 Jun 2006 21:07:22 +0100 Date: Fri, 23 Jun 2006 21:07:22 +0100 From: Ralf Baechle To: Daniel Mack Cc: linux-mips@linux-mips.org Subject: Re: [PATCH] au1200 USB - EHCI and OHCI fixes Message-ID: <20060623200722.GA4021@linux-mips.org> References: <5798565C-F3E1-4EB5-8886-51D65BEFEF02@caiaq.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5798565C-F3E1-4EB5-8886-51D65BEFEF02@caiaq.de> User-Agent: Mutt/1.4.2.1i Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11838 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ralf@linux-mips.org Precedence: bulk X-list: linux-mips On Fri, Jun 23, 2006 at 06:52:09PM +0200, Daniel Mack wrote: > I received an DBAU1200 eval kit from AMD a few days ago and tried to > enable the USB2 port, but the current linux-2.6 GIT did not even > compile with CONFIG_SOC_1200, CONFIG_SOC_AU1X00, CONFIG_USB_EHCI and > CONFIG_USB_OHCI set. > Furthermore, in ehci-hcd.c, platform_driver_register() was called with > an improper argument of type 'struct device_driver *' which of course > ended up in a kernel oops. How could that ever have worked on your > machines? > > Anyway, here's a trivial patch that makes the USB subsystem working > on my board for both OHCI and EHCI. > It also removes the /* FIXME use "struct platform_driver" */. Patch is looking good but has been linewrapped, can you resend? Ralf From daniel@caiaq.de Fri Jun 23 21:09:54 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 23 Jun 2006 21:10:04 +0100 (BST) Received: from buzzloop.caiaq.de ([212.112.241.133]:43015 "EHLO buzzloop.caiaq.de") by ftp.linux-mips.org with ESMTP id S8133645AbWFWUJy (ORCPT ); Fri, 23 Jun 2006 21:09:54 +0100 Received: from localhost (localhost [127.0.0.1]) by buzzloop.caiaq.de (Postfix) with ESMTP id C45E47F4028; Fri, 23 Jun 2006 22:09:51 +0200 (CEST) Received: from buzzloop.caiaq.de ([127.0.0.1]) by localhost (buzzloop [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 00971-06; Fri, 23 Jun 2006 22:09:51 +0200 (CEST) Received: from [192.168.1.140] (port-83-236-238-37.static.qsc.de [83.236.238.37]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by buzzloop.caiaq.de (Postfix) with ESMTP id 1FC037F4022; Fri, 23 Jun 2006 22:09:50 +0200 (CEST) In-Reply-To: <20060623200722.GA4021@linux-mips.org> References: <5798565C-F3E1-4EB5-8886-51D65BEFEF02@caiaq.de> <20060623200722.GA4021@linux-mips.org> Mime-Version: 1.0 (Apple Message framework v750) Content-Type: multipart/mixed; boundary=Apple-Mail-1-987493802 Message-Id: <683C25AE-D891-4460-99DF-FE91891DC0F8@caiaq.de> Cc: linux-mips@linux-mips.org From: Daniel Mack Subject: Re: [PATCH] au1200 USB - EHCI and OHCI fixes Date: Fri, 23 Jun 2006 22:09:45 +0200 To: Ralf Baechle X-Mailer: Apple Mail (2.750) Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11839 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: daniel@caiaq.de Precedence: bulk X-list: linux-mips --Apple-Mail-1-987493802 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; format=flowed Hi, On Jun 23, 2006, at 10:07 PM, Ralf Baechle wrote: >> Anyway, here's a trivial patch that makes the USB subsystem working >> on my board for both OHCI and EHCI. >> It also removes the /* FIXME use "struct platform_driver" */. > > Patch is looking good but has been linewrapped, can you resend? attached. Daniel --Apple-Mail-1-987493802 Content-Transfer-Encoding: 7bit Content-Type: application/octet-stream; x-unix-mode=0644; name="au1200-usb.patch" Content-Disposition: attachment; filename=au1200-usb.patch diff --git a/drivers/usb/host/ehci-au1xxx.c b/drivers/usb/host/ehci-au1xxx.c index 9b4697a..aed6ada 100644 --- a/drivers/usb/host/ehci-au1xxx.c +++ b/drivers/usb/host/ehci-au1xxx.c @@ -41,8 +41,6 @@ #endif #define USBH_DISABLE (USB_MCFG_EBMEN | USB_MCFG_EMEMEN) -#endif /* Au1200 */ - extern int usb_disabled(void); /*-------------------------------------------------------------------------*/ @@ -107,9 +105,9 @@ int usb_ehci_au1xxx_probe(const struct h /* Au1200 AB USB does not support coherent memory */ if (!(read_c0_prid() & 0xff)) { - pr_info("%s: this is chip revision AB!\n", dev->dev.name); + pr_info("%s: this is chip revision AB!\n", dev->name); pr_info("%s: update your board or re-configure the kernel\n", - dev->dev.name); + dev->name); return -ENODEV; } #endif @@ -228,9 +226,8 @@ static const struct hc_driver ehci_au1xx /*-------------------------------------------------------------------------*/ -static int ehci_hcd_au1xxx_drv_probe(struct device *dev) +static int ehci_hcd_au1xxx_drv_probe(struct platform_device *pdev) { - struct platform_device *pdev = to_platform_device(dev); struct usb_hcd *hcd = NULL; int ret; @@ -243,10 +240,9 @@ static int ehci_hcd_au1xxx_drv_probe(str return ret; } -static int ehci_hcd_au1xxx_drv_remove(struct device *dev) +static int ehci_hcd_au1xxx_drv_remove(struct platform_device *pdev) { - struct platform_device *pdev = to_platform_device(dev); - struct usb_hcd *hcd = dev_get_drvdata(dev); + struct usb_hcd *hcd = platform_get_drvdata(pdev); usb_ehci_au1xxx_remove(hcd, pdev); return 0; @@ -269,12 +265,13 @@ static int ehci_hcd_au1xxx_drv_resume(st } */ MODULE_ALIAS("au1xxx-ehci"); -/* FIXME use "struct platform_driver" */ -static struct device_driver ehci_hcd_au1xxx_driver = { - .name = "au1xxx-ehci", - .bus = &platform_bus_type, +static struct platform_driver ehci_hcd_au1xxx_driver = { .probe = ehci_hcd_au1xxx_drv_probe, .remove = ehci_hcd_au1xxx_drv_remove, /*.suspend = ehci_hcd_au1xxx_drv_suspend, */ /*.resume = ehci_hcd_au1xxx_drv_resume, */ + .driver = { + .name = "au1xxx-ehci", + .bus = &platform_bus_type + } }; diff --git a/drivers/usb/host/ohci-au1xxx.c b/drivers/usb/host/ohci-au1xxx.c index a1c8b3b..64c2fb2 100644 --- a/drivers/usb/host/ohci-au1xxx.c +++ b/drivers/usb/host/ohci-au1xxx.c @@ -101,6 +101,7 @@ static void au1xxx_start_ohc(struct plat #endif /* Au1200 */ +#ifndef CONFIG_SOC_AU1200 /* wait for reset complete (read register twice; see au1500 errata) */ while (au_readl(USB_HOST_CONFIG), !(au_readl(USB_HOST_CONFIG) & USBH_ENABLE_RD)) @@ -108,6 +109,7 @@ static void au1xxx_start_ohc(struct plat printk(KERN_DEBUG __FILE__ ": Clock to USB host has been enabled \n"); +#endif } static void au1xxx_stop_ohc(struct platform_device *dev) @@ -157,9 +159,9 @@ static int usb_ohci_au1xxx_probe(const s /* Au1200 AB USB does not support coherent memory */ if (!(read_c0_prid() & 0xff)) { pr_info("%s: this is chip revision AB !!\n", - dev->dev.name); + dev->name); pr_info("%s: update your board or re-configure the kernel\n", - dev->dev.name); + dev->name); return -ENODEV; } #endif --Apple-Mail-1-987493802-- From ralf@linux-mips.org Fri Jun 23 21:38:49 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 23 Jun 2006 21:38:57 +0100 (BST) Received: from localhost.localdomain ([127.0.0.1]:12673 "EHLO bacchus.dhis.org") by ftp.linux-mips.org with ESMTP id S8133709AbWFWUit (ORCPT ); Fri, 23 Jun 2006 21:38:49 +0100 Received: from denk.linux-mips.net (denk.linux-mips.net [127.0.0.1]) by bacchus.dhis.org (8.13.6/8.13.4) with ESMTP id k5NKcnnR004965; Fri, 23 Jun 2006 21:38:49 +0100 Received: (from ralf@localhost) by denk.linux-mips.net (8.13.6/8.13.6/Submit) id k5NKcn7g004964; Fri, 23 Jun 2006 21:38:49 +0100 Date: Fri, 23 Jun 2006 21:38:49 +0100 From: Ralf Baechle To: Daniel Mack Cc: linux-mips@linux-mips.org Subject: Re: [PATCH] au1200 USB - EHCI and OHCI fixes Message-ID: <20060623203849.GB4653@linux-mips.org> References: <5798565C-F3E1-4EB5-8886-51D65BEFEF02@caiaq.de> <20060623200722.GA4021@linux-mips.org> <683C25AE-D891-4460-99DF-FE91891DC0F8@caiaq.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <683C25AE-D891-4460-99DF-FE91891DC0F8@caiaq.de> User-Agent: Mutt/1.4.2.1i Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11840 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ralf@linux-mips.org Precedence: bulk X-list: linux-mips On Fri, Jun 23, 2006 at 10:09:45PM +0200, Daniel Mack wrote: > >Patch is looking good but has been linewrapped, can you resend? > > attached. Thanks, converted to a useful non-MIME format and forwarded to the USB maintainers. Ralf From js@linuxtv.org Fri Jun 23 21:48:53 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 23 Jun 2006 21:49:01 +0100 (BST) Received: from allen.werkleitz.de ([80.190.251.108]:36236 "EHLO allen.werkleitz.de") by ftp.linux-mips.org with ESMTP id S8133709AbWFWUsx (ORCPT ); Fri, 23 Jun 2006 21:48:53 +0100 Received: from p54bde340.dip.t-dialin.net ([84.189.227.64] helo=void.local) by allen.werkleitz.de with esmtpsa (TLS-1.0:DHE_RSA_3DES_EDE_CBC_SHA1:24) (Exim 4.62) (envelope-from ) id 1FtsZu-0003dd-MA; Fri, 23 Jun 2006 22:48:43 +0200 Received: from js by void.local with local (Exim 3.35 #1 (Debian)) id 1FtsZv-0000kJ-00; Fri, 23 Jun 2006 22:48:35 +0200 Date: Fri, 23 Jun 2006 22:48:35 +0200 From: Johannes Stezenbach To: Daniel Mack Cc: linux-mips@linux-mips.org Message-ID: <20060623204835.GA2548@linuxtv.org> References: <5B414347-B938-4E68-812E-627AED1A38B0@caiaq.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: <5B414347-B938-4E68-812E-627AED1A38B0@caiaq.de> User-Agent: Mutt/1.5.11+cvs20060403 X-SA-Exim-Connect-IP: 84.189.227.64 Subject: Re: smc91x ethernet an DBAU1200 X-SA-Exim-Version: 4.2.1 (built Mon, 27 Mar 2006 13:42:28 +0200) X-SA-Exim-Scanned: Yes (on allen.werkleitz.de) Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11841 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: js@linuxtv.org Precedence: bulk X-list: linux-mips Hi Daniel, On Fri, Jun 23, 2006, Daniel Mack wrote: >is there anyone out there successfully using the SMC 91C111 ethernet >chip >on AMD's DBAU1200 eval kit? In my setup here, it's working fine from >within >the YAMON boot loader so I can use it to download a kernel image via >TFTP. >The kernel (bleeding edge linux-2.6 mips-GIT) detects the device as well > > smc91x.c: v1.1, sep 22 2004 by Nicolas Pitre > eth0: SMC91C11xFD (rev 1) at b9000300 IRQ 65 [nowait] > eth0: Ethernet addr: 00:00:1a:19:11:8c > >and is able to mount its root filesystem via NFS. However, the >communication >does not seem to be sufficiently stable, messages like this occur >regularily: > > nfs: server 192.168.1.200 not responding, still trying > nfs: server 192.168.1.200 not responding, still trying I had similar issues with smc91x.c on a different platform, where the bus it is connected to was rather slow (and no DMA) -> dropped packets. Try to use NFS via TCP, or force a 10Mbit connection with ethtool or by hacking the driver (ctl_rspeed). (For me tcp works.) HTH, Johannes From Kiran_Thota@pmc-sierra.com Sat Jun 24 02:29:24 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 24 Jun 2006 02:29:38 +0100 (BST) Received: from mother.pmc-sierra.com ([216.241.224.12]:63152 "HELO mother.pmc-sierra.bc.ca") by ftp.linux-mips.org with SMTP id S8133800AbWFXB3Y (ORCPT ); Sat, 24 Jun 2006 02:29:24 +0100 Received: (qmail 1233 invoked by uid 101); 24 Jun 2006 01:29:12 -0000 Received: from unknown (HELO ogyruan.pmc-sierra.bc.ca) (216.241.226.236) by mother.pmc-sierra.com with SMTP; 24 Jun 2006 01:29:12 -0000 Received: from bby1exi01.pmc_nt.nt.pmc-sierra.bc.ca (bby1exi01.pmc-sierra.bc.ca [216.241.231.251]) by ogyruan.pmc-sierra.bc.ca (8.13.3/8.12.7) with ESMTP id k5O1TB5w028455; Fri, 23 Jun 2006 18:29:12 -0700 Received: by bby1exi01.pmc-sierra.bc.ca with Internet Mail Service (5.5.2656.59) id ; Fri, 23 Jun 2006 18:29:11 -0700 Message-ID: From: Kiran Thota To: ralf@linux-mips.org, linux-mips@linux-mips.org Subject: [PATCH 0/6] Sequoia Patches Date: Fri, 23 Jun 2006 18:29:03 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11842 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: Kiran_Thota@pmc-sierra.com Precedence: bulk X-list: linux-mips Hi Ralf and list, Please merge the following patches for PMC-Sierra Sequoia platform for linux-2.6.12. http://www.linux-mips.org/pub/linux/mips/kernel/v2.6/linux-2.6.12.tar.gz Patch [1/6] - Sequoia Configs Patch [2/6] - Sequoia PCI Patch [3/6] - Sequoia Platform Patch [4/6] - Sequoia Serial Patch [5/6] - RM9000 arch Patch [6/6] - MSP85x0 gige Driver (also submitting to netdev mailing list) And the diffstat is - arch/mips/Kconfig | 22 arch/mips/Makefile | 4 arch/mips/configs/sequoia_defconfig | 701 +++++ arch/mips/mm/c-r4k.c | 11 arch/mips/mm/sc-rm7k.c | 9 arch/mips/mm/tlbex.c | 50 arch/mips/pci/Makefile | 2 arch/mips/pci/fixup-sequoia.c | 43 arch/mips/pci/ops-sequoia.c | 187 + arch/mips/pci/pci-sequoia.c | 78 arch/mips/pmc-sierra/sequoia/Makefile | 7 arch/mips/pmc-sierra/sequoia/irq-handler.S | 99 arch/mips/pmc-sierra/sequoia/irq.c | 224 + arch/mips/pmc-sierra/sequoia/prom.c | 140 + arch/mips/pmc-sierra/sequoia/py-console.c | 123 + arch/mips/pmc-sierra/sequoia/setup.c | 258 ++ arch/mips/pmc-sierra/sequoia/setup.h | 17 drivers/net/Kconfig | 2 drivers/net/Makefile | 3 drivers/net/msp85x0_ge.c | 2142 ++++++++++++++++++ drivers/net/msp85x0_ge.h | 452 +++ drivers/net/titan_mdio.c | 21 drivers/net/titan_mdio.h | 5 drivers/serial/8250.c | 18 include/asm-mips/bootinfo.h | 2 include/asm-mips/mach-sequoia/cpu-feature-overrides.h | 45 include/asm-mips/pmc_sequoia.h | 296 ++ include/asm-mips/serial.h | 5 include/asm-mips/war.h | 11 include/linux/serial_reg.h | 63 30 files changed, 5036 insertions(+), 4 deletions(-) Comments? Kiran From Kiran_Thota@pmc-sierra.com Sat Jun 24 02:42:22 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 24 Jun 2006 02:42:35 +0100 (BST) Received: from mother.pmc-sierra.com ([216.241.224.12]:57268 "HELO mother.pmc-sierra.bc.ca") by ftp.linux-mips.org with SMTP id S8133862AbWFXBmW (ORCPT ); Sat, 24 Jun 2006 02:42:22 +0100 Received: (qmail 4674 invoked by uid 101); 24 Jun 2006 01:42:16 -0000 Received: from unknown (HELO ogyruan.pmc-sierra.bc.ca) (216.241.226.236) by mother.pmc-sierra.com with SMTP; 24 Jun 2006 01:42:16 -0000 Received: from bby1exi01.pmc_nt.nt.pmc-sierra.bc.ca (bby1exi01.pmc-sierra.bc.ca [216.241.231.251]) by ogyruan.pmc-sierra.bc.ca (8.13.3/8.12.7) with ESMTP id k5O1gFOZ000434; Fri, 23 Jun 2006 18:42:15 -0700 Received: by bby1exi01.pmc-sierra.bc.ca with Internet Mail Service (5.5.2656.59) id ; Fri, 23 Jun 2006 18:42:15 -0700 Message-ID: From: Kiran Thota To: ralf@linux-mips.org, linux-mips@linux-mips.org Subject: [PATCH 1/6] - Sequoia Patch for Config and compile Date: Fri, 23 Jun 2006 18:42:01 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11843 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: Kiran_Thota@pmc-sierra.com Precedence: bulk X-list: linux-mips - Config file sequoia_defconfig - Add Sequoia definitions to Kconfig - Add Sequoia compile to Makefile Signed-off-by: Kiran Kumar Thota diff -Naur a/arch/mips/configs/sequoia_defconfig b/arch/mips/configs/sequoia_defconfig --- a/arch/mips/configs/sequoia_defconfig 1969-12-31 16:00:00.000000000 -0800 +++ b/arch/mips/configs/sequoia_defconfig 2006-06-23 14:55:57.000000000 -0700 @@ -0,0 +1,701 @@ +# +# Automatically generated make config: don't edit +# Linux kernel version: 2.6.12-rc3 +# Tue May 3 17:52:08 2005 +# +CONFIG_MIPS=y + +# +# Code maturity level options +# +# CONFIG_EXPERIMENTAL is not set +CONFIG_CLEAN_COMPILE=y +CONFIG_BROKEN_ON_SMP=y +CONFIG_INIT_ENV_ARG_LIMIT=32 + +# +# General setup +# +CONFIG_LOCALVERSION="" +CONFIG_SWAP=y +CONFIG_SYSVIPC=y +# CONFIG_BSD_PROCESS_ACCT is not set +CONFIG_SYSCTL=y +# CONFIG_AUDIT is not set +# CONFIG_HOTPLUG is not set +CONFIG_KOBJECT_UEVENT=y +CONFIG_IKCONFIG=y +CONFIG_IKCONFIG_PROC=y +CONFIG_EMBEDDED=y +CONFIG_KALLSYMS=y +# CONFIG_KALLSYMS_ALL is not set +# CONFIG_KALLSYMS_EXTRA_PASS is not set +CONFIG_BASE_FULL=y +CONFIG_FUTEX=y +CONFIG_EPOLL=y +# CONFIG_CC_OPTIMIZE_FOR_SIZE is not set +CONFIG_SHMEM=y +CONFIG_CC_ALIGN_FUNCTIONS=0 +CONFIG_CC_ALIGN_LABELS=0 +CONFIG_CC_ALIGN_LOOPS=0 +CONFIG_CC_ALIGN_JUMPS=0 +# CONFIG_TINY_SHMEM is not set +CONFIG_BASE_SMALL=0 + +# +# Loadable module support +# +CONFIG_MODULES=y +CONFIG_MODULE_UNLOAD=y +CONFIG_OBSOLETE_MODPARM=y +# CONFIG_MODULE_SRCVERSION_ALL is not set +CONFIG_KMOD=y + +# +# Machine selection +# +# CONFIG_MIPS_MTX1 is not set +# CONFIG_MIPS_BOSPORUS is not set +# CONFIG_MIPS_PB1000 is not set +# CONFIG_MIPS_PB1100 is not set +# CONFIG_MIPS_PB1500 is not set +# CONFIG_MIPS_PB1550 is not set +# CONFIG_MIPS_PB1200 is not set +# CONFIG_MIPS_DB1000 is not set +# CONFIG_MIPS_DB1100 is not set +# CONFIG_MIPS_DB1500 is not set +# CONFIG_MIPS_DB1550 is not set +# CONFIG_MIPS_DB1200 is not set +# CONFIG_MIPS_MIRAGE is not set +# CONFIG_MIPS_COBALT is not set +# CONFIG_MACH_DECSTATION is not set +# CONFIG_MIPS_EV64120 is not set +# CONFIG_MIPS_EV96100 is not set +# CONFIG_MIPS_IVR is not set +# CONFIG_MIPS_ITE8172 is not set +# CONFIG_MACH_JAZZ is not set +# CONFIG_LASAT is not set +# CONFIG_MIPS_ATLAS is not set +# CONFIG_MIPS_MALTA is not set +# CONFIG_MIPS_SEAD is not set +# CONFIG_MOMENCO_JAGUAR_ATX is not set +# CONFIG_MOMENCO_OCELOT is not set +# CONFIG_MOMENCO_OCELOT_3 is not set +# CONFIG_MOMENCO_OCELOT_C is not set +# CONFIG_MOMENCO_OCELOT_G is not set +# CONFIG_MIPS_XXS1500 is not set +# CONFIG_DDB5074 is not set +# CONFIG_DDB5476 is not set +# CONFIG_DDB5477 is not set +# CONFIG_NEC_OSPREY is not set +# CONFIG_MACH_VR41XX is not set +# CONFIG_PMC_YOSEMITE is not set +CONFIG_PMC_SEQUOIA=y +CONFIG_PMC_INTERNAL_UART=y +# CONFIG_SGI_IP22 is not set +# CONFIG_SGI_IP27 is not set +# CONFIG_SGI_IP32 is not set +# CONFIG_SIBYTE_SWARM is not set +# CONFIG_SIBYTE_SENTOSA is not set +# CONFIG_SIBYTE_RHONE is not set +# CONFIG_SIBYTE_CARMEL is not set +# CONFIG_SIBYTE_PTSWARM is not set +# CONFIG_SIBYTE_LITTLESUR is not set +# CONFIG_SIBYTE_CRHINE is not set +# CONFIG_SIBYTE_CRHONE is not set +# CONFIG_SNI_RM200_PCI is not set +# CONFIG_TOSHIBA_JMR3927 is not set +# CONFIG_TOSHIBA_RBTX4927 is not set +CONFIG_RWSEM_GENERIC_SPINLOCK=y +CONFIG_GENERIC_CALIBRATE_DELAY=y +CONFIG_HAVE_DEC_LOCK=y +CONFIG_DMA_NONCOHERENT=y +CONFIG_CPU_BIG_ENDIAN=y +# CONFIG_CPU_LITTLE_ENDIAN is not set +CONFIG_SYS_SUPPORTS_BIG_ENDIAN=y +CONFIG_IRQ_CPU=y +CONFIG_IRQ_CPU_RM7K=y +CONFIG_SWAP_IO_SPACE=y +CONFIG_MIPS_L1_CACHE_SHIFT=5 + +# +# CPU selection +# +# CONFIG_CPU_MIPS32 is not set +# CONFIG_CPU_MIPS64 is not set +# CONFIG_CPU_R3000 is not set +# CONFIG_CPU_TX39XX is not set +# CONFIG_CPU_VR41XX is not set +# CONFIG_CPU_R4300 is not set +# CONFIG_CPU_R4X00 is not set +# CONFIG_CPU_TX49XX is not set +# CONFIG_CPU_R5000 is not set +# CONFIG_CPU_R5432 is not set +# CONFIG_CPU_R6000 is not set +# CONFIG_CPU_NEVADA is not set +# CONFIG_CPU_R8000 is not set +# CONFIG_CPU_R10000 is not set +# CONFIG_CPU_RM7000 is not set +CONFIG_CPU_RM9000=y +# CONFIG_CPU_SB1 is not set +CONFIG_SYS_SUPPORTS_32BIT_KERNEL=y +CONFIG_SYS_SUPPORTS_64BIT_KERNEL=y +CONFIG_CPU_SUPPORTS_32BIT_KERNEL=y +CONFIG_CPU_SUPPORTS_64BIT_KERNEL=y + +# +# Kernel type +# +CONFIG_MIPS32=y +# CONFIG_MIPS64 is not set +# CONFIG_64BIT is not set +CONFIG_PAGE_SIZE_4KB=y +# CONFIG_PAGE_SIZE_8KB is not set +# CONFIG_PAGE_SIZE_16KB is not set +# CONFIG_PAGE_SIZE_64KB is not set +CONFIG_BOARD_SCACHE=y +CONFIG_RM7000_CPU_SCACHE=y +CONFIG_CPU_HAS_PREFETCH=y +# CONFIG_64BIT_PHYS_ADDR is not set +# CONFIG_CPU_ADVANCED is not set +CONFIG_CPU_HAS_LLSC=y +CONFIG_CPU_HAS_LLDSCD=y +CONFIG_CPU_HAS_SYNC=y +CONFIG_HIGHMEM=y +# CONFIG_SMP is not set +# CONFIG_PREEMPT is not set + +# +# Bus options (PCI, PCMCIA, EISA, ISA, TC) +# +CONFIG_HW_HAS_PCI=y +CONFIG_PCI=y +CONFIG_PCI_LEGACY_PROC=y +CONFIG_PCI_NAMES=y +# CONFIG_PCI_DEBUG is not set +CONFIG_MMU=y + +# +# PCCARD (PCMCIA/CardBus) support +# +# CONFIG_PCCARD is not set + +# +# PCI Hotplug Support +# + +# +# Executable file formats +# +CONFIG_BINFMT_ELF=y +# CONFIG_BINFMT_MISC is not set +CONFIG_TRAD_SIGNALS=y + +# +# Device Drivers +# + +# +# Generic Driver Options +# +CONFIG_STANDALONE=y +CONFIG_PREVENT_FIRMWARE_BUILD=y +# CONFIG_FW_LOADER is not set +# CONFIG_DEBUG_DRIVER is not set + +# +# Memory Technology Devices (MTD) +# +# CONFIG_MTD is not set + +# +# Parallel port support +# +# CONFIG_PARPORT is not set + +# +# Plug and Play support +# + +# +# Block devices +# +# CONFIG_BLK_DEV_FD is not set +# CONFIG_BLK_CPQ_DA is not set +# CONFIG_BLK_CPQ_CISS_DA is not set +# CONFIG_BLK_DEV_DAC960 is not set +# CONFIG_BLK_DEV_COW_COMMON is not set +# CONFIG_BLK_DEV_LOOP is not set +# CONFIG_BLK_DEV_NBD is not set +# CONFIG_BLK_DEV_SX8 is not set +# CONFIG_BLK_DEV_RAM is not set +CONFIG_BLK_DEV_RAM_COUNT=16 +CONFIG_INITRAMFS_SOURCE="" +# CONFIG_LBD is not set +CONFIG_CDROM_PKTCDVD=m +CONFIG_CDROM_PKTCDVD_BUFFERS=8 +# CONFIG_CDROM_PKTCDVD_WCACHE is not set + +# +# IO Schedulers +# +CONFIG_IOSCHED_NOOP=y +CONFIG_IOSCHED_AS=y +CONFIG_IOSCHED_DEADLINE=y +CONFIG_IOSCHED_CFQ=y +CONFIG_ATA_OVER_ETH=m + +# +# ATA/ATAPI/MFM/RLL support +# +# CONFIG_IDE is not set + +# +# SCSI device support +# +# CONFIG_SCSI is not set + +# +# Multi-device support (RAID and LVM) +# +# CONFIG_MD is not set + +# +# Fusion MPT device support +# + +# +# IEEE 1394 (FireWire) support +# +# CONFIG_IEEE1394 is not set + +# +# I2O device support +# +# CONFIG_I2O is not set + +# +# Networking support +# +CONFIG_NET=y + +# +# Networking options +# +CONFIG_PACKET=m +CONFIG_PACKET_MMAP=y +CONFIG_UNIX=y +# CONFIG_NET_KEY is not set +CONFIG_INET=y +# CONFIG_IP_MULTICAST is not set +# CONFIG_IP_ADVANCED_ROUTER is not set +CONFIG_IP_PNP=y +# CONFIG_IP_PNP_DHCP is not set +CONFIG_IP_PNP_BOOTP=y +# CONFIG_IP_PNP_RARP is not set +# CONFIG_NET_IPIP is not set +# CONFIG_NET_IPGRE is not set +# CONFIG_SYN_COOKIES is not set +# CONFIG_INET_AH is not set +# CONFIG_INET_ESP is not set +# CONFIG_INET_IPCOMP is not set +CONFIG_INET_TUNNEL=m +CONFIG_IP_TCPDIAG=m +CONFIG_IP_TCPDIAG_IPV6=y +CONFIG_IPV6=m +CONFIG_IPV6_PRIVACY=y +CONFIG_INET6_AH=m +CONFIG_INET6_ESP=m +CONFIG_INET6_IPCOMP=m +CONFIG_INET6_TUNNEL=m +CONFIG_IPV6_TUNNEL=m +# CONFIG_NETFILTER is not set +CONFIG_XFRM=y +CONFIG_XFRM_USER=m +# CONFIG_BRIDGE is not set +# CONFIG_VLAN_8021Q is not set +# CONFIG_DECNET is not set +# CONFIG_LLC2 is not set +# CONFIG_IPX is not set +# CONFIG_ATALK is not set + +# +# QoS and/or fair queueing +# +# CONFIG_NET_SCHED is not set +# CONFIG_NET_CLS_ROUTE is not set + +# +# Network testing +# +# CONFIG_NET_PKTGEN is not set +# CONFIG_NETPOLL is not set +# CONFIG_NET_POLL_CONTROLLER is not set +# CONFIG_HAMRADIO is not set +# CONFIG_IRDA is not set +# CONFIG_BT is not set +CONFIG_NETDEVICES=y +# CONFIG_DUMMY is not set +# CONFIG_BONDING is not set +# CONFIG_EQUALIZER is not set +# CONFIG_TUN is not set + +# +# ARCnet devices +# +# CONFIG_ARCNET is not set + +# +# Ethernet (10 or 100Mbit) +# +CONFIG_NET_ETHERNET=y +CONFIG_MII=y +# CONFIG_HAPPYMEAL is not set +# CONFIG_SUNGEM is not set +# CONFIG_NET_VENDOR_3COM is not set + +# +# Tulip family network device support +# +# CONFIG_NET_TULIP is not set +# CONFIG_HP100 is not set +CONFIG_NET_PCI=y +# CONFIG_PCNET32 is not set +# CONFIG_AMD8111_ETH is not set +# CONFIG_ADAPTEC_STARFIRE is not set +# CONFIG_DGRS is not set +# CONFIG_EEPRO100 is not set +# CONFIG_E100 is not set +# CONFIG_FEALNX is not set +# CONFIG_NATSEMI is not set +# CONFIG_NE2K_PCI is not set +CONFIG_8139TOO=y +# CONFIG_8139TOO_PIO is not set +# CONFIG_8139TOO_TUNE_TWISTER is not set +# CONFIG_8139TOO_8129 is not set +# CONFIG_8139_OLD_RX_RESET is not set +# CONFIG_SIS900 is not set +# CONFIG_EPIC100 is not set +# CONFIG_SUNDANCE is not set +# CONFIG_TLAN is not set +# CONFIG_VIA_RHINE is not set + +# +# Ethernet (1000 Mbit) +# +# CONFIG_ACENIC is not set +# CONFIG_DL2K is not set +# CONFIG_E1000 is not set +# CONFIG_NS83820 is not set +# CONFIG_HAMACHI is not set +# CONFIG_R8169 is not set +# CONFIG_SK98LIN is not set +# CONFIG_VIA_VELOCITY is not set +# CONFIG_TIGON3 is not set +CONFIG_TITAN_GE=y + +# +# Ethernet (10000 Mbit) +# +# CONFIG_IXGB is not set +# CONFIG_S2IO is not set + +# +# Token Ring devices +# +# CONFIG_TR is not set + +# +# Wireless LAN (non-hamradio) +# +# CONFIG_NET_RADIO is not set + +# +# Wan interfaces +# +# CONFIG_WAN is not set +# CONFIG_FDDI is not set +# CONFIG_PPP is not set +# CONFIG_SLIP is not set + +# +# ISDN subsystem +# +# CONFIG_ISDN is not set + +# +# Telephony Support +# +# CONFIG_PHONE is not set + +# +# Input device support +# +# CONFIG_INPUT is not set + +# +# Hardware I/O ports +# +# CONFIG_SERIO is not set +# CONFIG_GAMEPORT is not set +CONFIG_SOUND_GAMEPORT=y + +# +# Character devices +# +# CONFIG_VT is not set +# CONFIG_SERIAL_NONSTANDARD is not set + +# +# Serial drivers +# +CONFIG_SERIAL_8250=y +CONFIG_SERIAL_8250_CONSOLE=y +CONFIG_SERIAL_8250_NR_UARTS=4 +# CONFIG_SERIAL_8250_EXTENDED is not set + +# +# Non-8250 serial port support +# +CONFIG_SERIAL_CORE=y +CONFIG_SERIAL_CORE_CONSOLE=y +# CONFIG_SERIAL_JSM is not set +CONFIG_UNIX98_PTYS=y +CONFIG_LEGACY_PTYS=y +CONFIG_LEGACY_PTY_COUNT=256 + +# +# IPMI +# +# CONFIG_IPMI_HANDLER is not set + +# +# Watchdog Cards +# +# CONFIG_WATCHDOG is not set +# CONFIG_RTC is not set +CONFIG_GEN_RTC=y +CONFIG_GEN_RTC_X=y +# CONFIG_DTLK is not set +# CONFIG_R3964 is not set +# CONFIG_APPLICOM is not set + +# +# Ftape, the floppy tape device driver +# +# CONFIG_DRM is not set +# CONFIG_RAW_DRIVER is not set + +# +# TPM devices +# + +# +# I2C support +# +# CONFIG_I2C is not set + +# +# Dallas's 1-wire bus +# +# CONFIG_W1 is not set + +# +# Misc devices +# + +# +# Multimedia devices +# +# CONFIG_VIDEO_DEV is not set + +# +# Digital Video Broadcasting Devices +# +# CONFIG_DVB is not set + +# +# Graphics support +# +# CONFIG_FB is not set + +# +# Sound +# +# CONFIG_SOUND is not set + +# +# USB support +# +CONFIG_USB_ARCH_HAS_HCD=y +CONFIG_USB_ARCH_HAS_OHCI=y +# CONFIG_USB is not set + +# +# USB Gadget Support +# +# CONFIG_USB_GADGET is not set + +# +# MMC/SD Card support +# +# CONFIG_MMC is not set + +# +# InfiniBand support +# +# CONFIG_INFINIBAND is not set + +# +# File systems +# +# CONFIG_EXT2_FS is not set +# CONFIG_EXT3_FS is not set +# CONFIG_JBD is not set +# CONFIG_REISERFS_FS is not set +# CONFIG_JFS_FS is not set + +# +# XFS support +# +# CONFIG_XFS_FS is not set +# CONFIG_MINIX_FS is not set +# CONFIG_ROMFS_FS is not set +# CONFIG_QUOTA is not set +CONFIG_DNOTIFY=y +# CONFIG_AUTOFS_FS is not set +# CONFIG_AUTOFS4_FS is not set + +# +# CD-ROM/DVD Filesystems +# +# CONFIG_ISO9660_FS is not set +# CONFIG_UDF_FS is not set + +# +# DOS/FAT/NT Filesystems +# +# CONFIG_MSDOS_FS is not set +# CONFIG_VFAT_FS is not set +# CONFIG_NTFS_FS is not set + +# +# Pseudo filesystems +# +CONFIG_PROC_FS=y +CONFIG_PROC_KCORE=y +CONFIG_SYSFS=y +# CONFIG_DEVPTS_FS_XATTR is not set +CONFIG_TMPFS=y +# CONFIG_TMPFS_XATTR is not set +# CONFIG_HUGETLB_PAGE is not set +CONFIG_RAMFS=y + +# +# Miscellaneous filesystems +# +# CONFIG_HFSPLUS_FS is not set +# CONFIG_CRAMFS is not set +# CONFIG_VXFS_FS is not set +# CONFIG_HPFS_FS is not set +# CONFIG_QNX4FS_FS is not set +# CONFIG_SYSV_FS is not set +# CONFIG_UFS_FS is not set + +# +# Network File Systems +# +CONFIG_NFS_FS=y +# CONFIG_NFS_V3 is not set +# CONFIG_NFSD is not set +CONFIG_ROOT_NFS=y +CONFIG_LOCKD=y +CONFIG_SUNRPC=y +# CONFIG_SMB_FS is not set +# CONFIG_CIFS is not set +# CONFIG_NCP_FS is not set +# CONFIG_CODA_FS is not set + +# +# Partition Types +# +# CONFIG_PARTITION_ADVANCED is not set +CONFIG_MSDOS_PARTITION=y + +# +# Native Language Support +# +# CONFIG_NLS is not set + +# +# Kernel hacking +# +# CONFIG_PRINTK_TIME is not set +CONFIG_DEBUG_KERNEL=y +# CONFIG_MAGIC_SYSRQ is not set +CONFIG_LOG_BUF_SHIFT=14 +# CONFIG_SCHEDSTATS is not set +# CONFIG_DEBUG_SLAB is not set +# CONFIG_DEBUG_SPINLOCK is not set +# CONFIG_DEBUG_SPINLOCK_SLEEP is not set +# CONFIG_DEBUG_KOBJECT is not set +# CONFIG_DEBUG_HIGHMEM is not set +# CONFIG_DEBUG_INFO is not set +# CONFIG_DEBUG_FS is not set +CONFIG_CROSSCOMPILE=y +CONFIG_CMDLINE="" +# CONFIG_DEBUG_STACK_USAGE is not set +# CONFIG_KGDB is not set +# CONFIG_RUNTIME_DEBUG is not set +# CONFIG_MIPS_UNCACHED is not set + +# +# Security options +# +CONFIG_KEYS=y +CONFIG_KEYS_DEBUG_PROC_KEYS=y +# CONFIG_SECURITY is not set + +# +# Cryptographic options +# +CONFIG_CRYPTO=y +CONFIG_CRYPTO_HMAC=y +CONFIG_CRYPTO_NULL=m +CONFIG_CRYPTO_MD4=m +CONFIG_CRYPTO_MD5=m +CONFIG_CRYPTO_SHA1=m +CONFIG_CRYPTO_SHA256=m +CONFIG_CRYPTO_SHA512=m +CONFIG_CRYPTO_WP512=m +CONFIG_CRYPTO_TGR192=m +CONFIG_CRYPTO_DES=m +CONFIG_CRYPTO_BLOWFISH=m +CONFIG_CRYPTO_TWOFISH=m +CONFIG_CRYPTO_SERPENT=m +CONFIG_CRYPTO_AES=m +CONFIG_CRYPTO_CAST5=m +CONFIG_CRYPTO_CAST6=m +CONFIG_CRYPTO_TEA=m +CONFIG_CRYPTO_ARC4=m +CONFIG_CRYPTO_KHAZAD=m +CONFIG_CRYPTO_ANUBIS=m +CONFIG_CRYPTO_DEFLATE=m +CONFIG_CRYPTO_MICHAEL_MIC=m +CONFIG_CRYPTO_CRC32C=m +CONFIG_CRYPTO_TEST=m + +# +# Hardware crypto devices +# + +# +# Library routines +# +# CONFIG_CRC_CCITT is not set +CONFIG_CRC32=y +CONFIG_LIBCRC32C=m +CONFIG_ZLIB_INFLATE=m +CONFIG_ZLIB_DEFLATE=m +CONFIG_GENERIC_HARDIRQS=y +CONFIG_GENERIC_IRQ_PROBE=y diff -Naur a/arch/mips/Kconfig b/arch/mips/Kconfig --- a/arch/mips/Kconfig 2005-07-11 11:28:10.000000000 -0700 +++ b/arch/mips/Kconfig 2006-06-23 14:16:48.000000000 -0700 @@ -450,6 +450,28 @@ Yosemite is an evaluation board for the RM9000x2 processor manufactured by PMC-Sierra. +config PMC_SEQUOIA + bool "Support for PMC-Sierra Sequoia eval board" + select BOOT_ELF32 + select PMC_INTERNAL_UART + select DMA_NONCOHERENT + select HW_HAS_PCI + select IRQ_CPU + select IRQ_CPU_RM7K + select SWAP_IO_SPACE + select SYS_SUPPORTS_32BIT_KERNEL + select SYS_SUPPORTS_64BIT_KERNEL + select SYS_SUPPORTS_BIG_ENDIAN + select BOARD_SCACHE + select RM7000_CPU_SCACHE + help + Sequoia is an evaluation board for the MSP85x0/RM915x processor + manufactured by PMC-Sierra. + +config PMC_INTERNAL_UART + bool "Internal UART Support for PMC-Sierra Yosemite or Sequoia" + depends on PMC_YOSEMITE || PMC_SEQUOIA + config QEMU bool "Support for Qemu" select DMA_COHERENT diff -Naur a/arch/mips/Makefile b/arch/mips/Makefile --- a/arch/mips/Makefile 2005-07-11 11:28:10.000000000 -0700 +++ b/arch/mips/Makefile 2006-06-22 11:48:21.000000000 -0700 @@ -458,6 +458,10 @@ cflags-$(CONFIG_PMC_YOSEMITE) += -Iinclude/asm-mips/mach-yosemite load-$(CONFIG_PMC_YOSEMITE) += 0xffffffff80100000 +core-$(CONFIG_PMC_SEQUOIA) += arch/mips/pmc-sierra/sequoia/ +cflags-$(CONFIG_PMC_SEQUOIA) += -Iinclude/asm-mips/mach-sequoia +load-$(CONFIG_PMC_SEQUOIA) += 0xffffffff80100000 + # # Qemu simulating MIPS32 4Kc # From Kiran_Thota@pmc-sierra.com Sat Jun 24 02:46:43 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 24 Jun 2006 02:46:54 +0100 (BST) Received: from mother.pmc-sierra.com ([216.241.224.12]:33205 "HELO mother.pmc-sierra.bc.ca") by ftp.linux-mips.org with SMTP id S8133862AbWFXBqn (ORCPT ); Sat, 24 Jun 2006 02:46:43 +0100 Received: (qmail 5675 invoked by uid 101); 24 Jun 2006 01:46:37 -0000 Received: from unknown (HELO ogyruan.pmc-sierra.bc.ca) (216.241.226.236) by mother.pmc-sierra.com with SMTP; 24 Jun 2006 01:46:37 -0000 Received: from bby1exi01.pmc_nt.nt.pmc-sierra.bc.ca (bby1exi01.pmc-sierra.bc.ca [216.241.231.251]) by ogyruan.pmc-sierra.bc.ca (8.13.3/8.12.7) with ESMTP id k5O1kauf001843; Fri, 23 Jun 2006 18:46:36 -0700 Received: by bby1exi01.pmc-sierra.bc.ca with Internet Mail Service (5.5.2656.59) id ; Fri, 23 Jun 2006 18:46:36 -0700 Message-ID: From: Kiran Thota To: ralf@linux-mips.org, linux-mips@linux-mips.org Cc: Raj Palani Subject: [PATCH 2/6] Sequoia PCI Date: Fri, 23 Jun 2006 18:46:27 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11844 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: Kiran_Thota@pmc-sierra.com Precedence: bulk X-list: linux-mips - Add irq mapping for PCI - Add PCI for Sequoia in Makefile - Add PCI ops - Add PCI setup and functions Signed-Off-By: Kiran Kumar Thota diff -Naur a/arch/mips/pci/fixup-sequoia.c b/arch/mips/pci/fixup-sequoia.c --- a/arch/mips/pci/fixup-sequoia.c 1969-12-31 16:00:00.000000000 -0800 +++ b/arch/mips/pci/fixup-sequoia.c 2006-06-22 11:48:21.000000000 -0700 @@ -0,0 +1,43 @@ +/* + * Copyright 2006 PMC-Sierra + * Author: PMC Sierra Inc (thotakir@pmc-sierra.com) + * + */ + +#include +#include +#include +#include +#include + + +int __init pcibios_map_irq(struct pci_dev *dev, u8 slot, u8 pin) +{ + if (pin == 0) + return -1; + + if ((dev->bus->number == 0) && + (slot== 2)) { + /* bus 0, slot 0 */ + return 11; + } else if ((dev->bus->number == 0) && + (slot == 3)) { + /* bus 0, slot 1 */ + return 12; + } else if ((dev->bus->number == 1) && + (slot == 2)) { + /* bus 1, slot 0 */ + return 13; + } else if ((dev->bus->number == 1) && + (slot == 3)) { + /* bus 1, slot 1 */ + return 14; + } +} + +/* Do platform specific device initialization at pci_enable_device() time */ +int pcibios_plat_dev_init(struct pci_dev *dev) +{ + return 0; +} + diff -Naur a/arch/mips/pci/Makefile b/arch/mips/pci/Makefile --- a/arch/mips/pci/Makefile 2005-07-11 11:28:10.000000000 -0700 +++ b/arch/mips/pci/Makefile 2006-06-22 11:48:21.000000000 -0700 @@ -42,6 +42,8 @@ obj-$(CONFIG_MOMENCO_OCELOT_G) += fixup-ocelot-g.o pci-ocelot-g.o obj-$(CONFIG_PMC_YOSEMITE) += fixup-yosemite.o ops-titan.o ops-titan-ht.o \ pci-yosemite.o +obj-$(CONFIG_PMC_SEQUOIA) += fixup-sequoia.o ops-sequoia.o pci-sequoia.o + obj-$(CONFIG_SGI_IP27) += pci-ip27.o obj-$(CONFIG_SGI_IP32) += fixup-ip32.o ops-mace.o pci-ip32.o obj-$(CONFIG_SIBYTE_SB1250) += fixup-sb1250.o pci-sb1250.o diff -Naur a/arch/mips/pci/ops-sequoia.c b/arch/mips/pci/ops-sequoia.c --- a/arch/mips/pci/ops-sequoia.c 1969-12-31 16:00:00.000000000 -0800 +++ b/arch/mips/pci/ops-sequoia.c 2006-06-22 14:51:08.000000000 -0700 @@ -0,0 +1,187 @@ +/* + * Copyright 2006 PMC-Sierra + * Author: PMC Sierra Inc (thotakir@pmc-sierra.com) + * + */ + +#include +#include +#include +#include +#include +#include +#include +#include + +#include +#include + + +void sequoia_pcibios_fixup_bus(struct pci_bus* c); + + +/* + * Sequoia PCI Config Read Byte + */ +static int sequoia_pci_read_config(struct pci_bus *bus, + unsigned int devfn, int offset, int size, u32* val) +{ + int dev, busno, func; + uint32_t address_reg, data_reg; + uint32_t address, data = 0; + + int local_busno = 0; + + busno = bus->number; + dev = PCI_SLOT(devfn); + func = PCI_FUNC(devfn); + + address_reg = RM9150_PCI_CONFIG_ADDR; + data_reg = RM9150_PCI_CONFIG_DATA; + + address = (local_busno << 16) | (dev << 11) | (func << 8) | + (offset & 0xfc) | 0x80000000; + + /* start the configuration cycle */ + if (busno == 0) + SEQUOIA_PCI0_WRITE(address_reg, address); + else + SEQUOIA_PCI1_WRITE(address_reg, address); + + /* read the data */ + switch (size) { + case 1: + + if (busno == 0) + { + data = SEQUOIA_PCI0_READ(data_reg); + *val = (data >> ((offset & 3) << 3)) & 0xff; + } + else + { + data = SEQUOIA_PCI1_READ(data_reg); + *val = (data >> ((offset & 3) << 3)) & 0xff; + } + break; + + case 2: + + if (busno == 0) + { + data = SEQUOIA_PCI0_READ(data_reg); + *val = (data >> ((offset & 3) << 3)) & 0xffff; + } + else + { + data = SEQUOIA_PCI1_READ(data_reg); + *val = (data >> ((offset & 3) << 3)) & 0xffff; + } + break; + + case 4: + if (busno == 0) + *val = SEQUOIA_PCI0_READ(data_reg); + else + *val = SEQUOIA_PCI1_READ(data_reg); + break; + } + + return PCIBIOS_SUCCESSFUL; +} + +/* + * Sequoia PCI Config Byte Write + */ +static int sequoia_pci_write_config(struct pci_bus *bus, + unsigned int devfn, int offset, int size, u32 val) +{ + int dev, busno, func; + uint32_t address_reg, data_reg; + uint32_t address, data = 0; + + int local_busno = 0; + + busno = bus->number; + dev = PCI_SLOT(devfn); + func = PCI_FUNC(devfn); + + address_reg = RM9150_PCI_CONFIG_ADDR; + data_reg = RM9150_PCI_CONFIG_DATA; + + address = (local_busno << 16) | (dev << 11) | (func << 8) | + (offset & 0xfc) | 0x80000000; + + /* start the configuration cycle */ + if (busno == 0) + SEQUOIA_PCI0_WRITE(address_reg, address); + else + SEQUOIA_PCI1_WRITE(address_reg, address); + + /* write the data */ + switch (size) { + case 1: + if (busno == 0) + { + /* read the data first */ + data = SEQUOIA_PCI0_READ(data_reg); + data = (data & ~(0xff << ((offset & 3) << 3))) | + (val << ((offset & 3) << 3)); + + /* write the data */ + SEQUOIA_PCI0_WRITE(data_reg, data); + } + else + { + /* read the data first */ + data = SEQUOIA_PCI1_READ(data_reg); + data = (data & ~(0xff << ((offset & 3) << 3))) | + (val << ((offset & 3) << 3)); + + /* write the data */ + SEQUOIA_PCI1_WRITE(data_reg, data); + } + break; + case 2: + if (busno == 0) + { + /* read the data first */ + data = SEQUOIA_PCI0_READ(data_reg); + data = (data & ~(0xffff << ((offset & 3) << 3))) | + (val << ((offset & 3) << 3)); + + /* write the data */ + SEQUOIA_PCI0_WRITE(data_reg, data); + } + else + { + /* read the data first */ + data = SEQUOIA_PCI1_READ(data_reg); + data = (data & ~(0xffff << ((offset & 3) << 3))) | + (val << ((offset & 3) << 3)); + + /* write the data */ + SEQUOIA_PCI1_WRITE(data_reg, data); + } + break; + case 4: + if (busno == 0) + SEQUOIA_PCI0_WRITE(data_reg, val); + else + SEQUOIA_PCI1_WRITE(data_reg, val); + break; + } + + return PCIBIOS_SUCCESSFUL; +} + +/* + * Sequoia PCI structure + */ +struct pci_ops sequoia_pci_ops = { + sequoia_pci_read_config, + sequoia_pci_write_config, +}; + +struct pci_fixup pcibios_fixups[] = { + {0} +}; diff -Naur a/arch/mips/pci/pci-sequoia.c b/arch/mips/pci/pci-sequoia.c --- a/arch/mips/pci/pci-sequoia.c 1969-12-31 16:00:00.000000000 -0800 +++ b/arch/mips/pci/pci-sequoia.c 2006-06-22 11:48:21.000000000 -0700 @@ -0,0 +1,78 @@ +/* + * This file is subject to the terms and conditions of the GNU General Public + * License. See the file "COPYING" in the main directory of this archive + * for more details. + * + * Copyright (C) 2004 by Ralf Baechle (ralf@linux-mips.org) + */ +#include +#include +#include +#include +#include +#include + + +extern struct pci_ops sequoia_pci_ops; + +static struct resource py_mem_resource0 = { + "Sequoia PCI MEM", SEQUOIA_PCI0_MEM_BASE, + SEQUOIA_PCI0_MEM_BASE+SEQUOIA_PCI0_MEM_SIZE-1, IORESOURCE_MEM +}; + +static struct resource py_mem_resource1 = { + "Sequoia PCI MEM", SEQUOIA_PCI1_MEM_BASE, + SEQUOIA_PCI1_MEM_BASE+SEQUOIA_PCI1_MEM_SIZE-1, IORESOURCE_MEM +}; + +/* + * PMON really reserves 16MB of I/O port space but that's stupid, nothing + * needs that much since allocations are limited to 256 bytes per device + * anyway. So we just claim 64kB here. + */ +#define SEQUOIA_IO_SIZE 0x0000ffffUL + +static struct resource py_io_resource0 = { + "Sequoia IO MEM", SEQUOIA_PCI0_IO_BASE, + SEQUOIA_PCI0_IO_BASE + SEQUOIA_PCI0_IO_SIZE - 1, IORESOURCE_IO, +}; + +static struct resource py_io_resource1 = { + "Sequoia IO MEM", SEQUOIA_PCI1_IO_BASE, + SEQUOIA_PCI1_IO_BASE + SEQUOIA_PCI1_IO_SIZE - 1, IORESOURCE_IO, +}; + +static struct pci_controller py_controller0 = { + .pci_ops = &sequoia_pci_ops, + .mem_resource = &py_mem_resource0, + .mem_offset = 0x00000000UL, + .io_resource = &py_io_resource0, + .io_offset = 0x00000000UL +}; + +static struct pci_controller py_controller1 = { + .pci_ops = &sequoia_pci_ops, + .mem_resource = &py_mem_resource1, + .mem_offset = 0x00000000UL, + .io_resource = &py_io_resource1, + .io_offset = 0x00000000UL +}; + +static char ioremap_failed[] __initdata = "Could not ioremap I/O port range"; + +static int __init pmc_sequoia_setup(void) +{ + unsigned long io_v_base; + + set_io_port_base(0); + + ioport_resource.end = SEQUOIA_PCI1_IO_BASE + SEQUOIA_PCI1_IO_SIZE - 1; + + register_pci_controller(&py_controller0); + register_pci_controller(&py_controller1); + + return 0; +} + +arch_initcall(pmc_sequoia_setup); + From Kiran_Thota@pmc-sierra.com Sat Jun 24 02:57:15 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 24 Jun 2006 02:57:33 +0100 (BST) Received: from mother.pmc-sierra.com ([216.241.224.12]:56246 "HELO mother.pmc-sierra.bc.ca") by ftp.linux-mips.org with SMTP id S8133862AbWFXB5P (ORCPT ); Sat, 24 Jun 2006 02:57:15 +0100 Received: (qmail 8288 invoked by uid 101); 24 Jun 2006 01:57:08 -0000 Received: from unknown (HELO ogyruan.pmc-sierra.bc.ca) (216.241.226.236) by mother.pmc-sierra.com with SMTP; 24 Jun 2006 01:57:08 -0000 Received: from bby1exi01.pmc_nt.nt.pmc-sierra.bc.ca (bby1exi01.pmc-sierra.bc.ca [216.241.231.251]) by ogyruan.pmc-sierra.bc.ca (8.13.3/8.12.7) with ESMTP id k5O1v7nt005477; Fri, 23 Jun 2006 18:57:08 -0700 Received: by bby1exi01.pmc-sierra.bc.ca with Internet Mail Service (5.5.2656.59) id ; Fri, 23 Jun 2006 18:57:07 -0700 Message-ID: From: Kiran Thota To: ralf@linux-mips.org, linux-mips@linux-mips.org Cc: Raj Palani Subject: [Patch 3/6] Sequoia Platform Date: Fri, 23 Jun 2006 18:56:54 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11845 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: Kiran_Thota@pmc-sierra.com Precedence: bulk X-list: linux-mips - Add IRQ controller (hacked from irq-rm9000.c) - Add Interrupt handlers - Add Sequoia platform compile to Makefile - Add PMON2000 (boot loader) hand-over code - Add Sequoia setup code - Add flags for platform - Add reg defns and macros for RM915x/MSP85x0 Signed-off-by: Kiran Kumar Thota diff -Naur a/arch/mips/pmc-sierra/sequoia/irq.c b/arch/mips/pmc-sierra/sequoia/irq.c --- a/arch/mips/pmc-sierra/sequoia/irq.c 1969-12-31 16:00:00.000000000 -0800 +++ b/arch/mips/pmc-sierra/sequoia/irq.c 2006-06-23 14:35:21.000000000 -0700 @@ -0,0 +1,224 @@ +/* + * Copyright (C) 2003 Ralf Baechle + * + * This program is free software; you can redistribute it and/or modify it + * under the terms of the GNU General Public License as published by the + * Free Software Foundation; either version 2 of the License, or (at your + * option) any later version. + * + * Handler for RM9000 extended interrupts. These are a non-standard + * feature so we handle them separately from standard interrupts. + */ +#include +#include +#include +#include + +#include +#include +#include +#include + +static int irq_base; + +static inline void unmask_rm9k_irq(unsigned int irq) +{ + set_c0_intcontrol(0x1000 << (irq - irq_base)); +} + +static inline void mask_rm9k_irq(unsigned int irq) +{ + clear_c0_intcontrol(0x1000 << (irq - irq_base)); +} + +static inline void rm9k_cpu_irq_enable(unsigned int irq) +{ + unsigned long flags; + + /* convert PCI irq numbers to cp0_intmask bit */ + irq = (10 < irq < 15)? 11 : irq; + local_irq_save(flags); + if (irq == 11) + set_c0_intcontrol(0x100 << 3); + else + unmask_rm9k_irq(irq); + + local_irq_restore(flags); +} + +static void rm9k_cpu_irq_disable(unsigned int irq) +{ + unsigned long flags; + + /* convert PCI irq numbers to cp0_intmask bit */ + irq = (10 < irq < 15)? 11 : irq; + local_irq_save(flags); + if (irq == 11) + clear_c0_intcontrol(0x100 << 3); + else + mask_rm9k_irq(irq); + + local_irq_restore(flags); +} + +static unsigned int rm9k_cpu_irq_startup(unsigned int irq) +{ + rm9k_cpu_irq_enable(irq); + + return 0; +} + +#define rm9k_cpu_irq_shutdown rm9k_cpu_irq_disable + +/* + * Performance counter interrupts are global on all processors. + */ +static void local_rm9k_perfcounter_irq_startup(void *args) +{ + unsigned int irq = (unsigned int) args; + + rm9k_cpu_irq_enable(irq); +} + +static unsigned int rm9k_perfcounter_irq_startup(unsigned int irq) +{ + on_each_cpu(local_rm9k_perfcounter_irq_startup, (void *) irq, 0, 1); + + return 0; +} + +static void local_rm9k_perfcounter_irq_shutdown(void *args) +{ + unsigned int irq = (unsigned int) args; + unsigned long flags; + + local_irq_save(flags); + mask_rm9k_irq(irq); + local_irq_restore(flags); +} + +static void rm9k_perfcounter_irq_shutdown(unsigned int irq) +{ + on_each_cpu(local_rm9k_perfcounter_irq_shutdown, (void *) irq, 0, 1); +} + + +/* + * While we ack the interrupt interrupts are disabled and thus we don't need + * to deal with concurrency issues. Same for rm9k_cpu_irq_end. + */ +static void rm9k_cpu_irq_ack(unsigned int irq) +{ + /* convert PCI irq numbers to cp0_intmask bit */ + irq = (10 < irq < 15)? 11 : irq; + if (irq == 11) + clear_c0_intcontrol(0x100 << 3); + else + mask_rm9k_irq(irq); +} + +static void rm9k_cpu_irq_end(unsigned int irq) +{ + if (!(irq_desc[irq].status & (IRQ_DISABLED | IRQ_INPROGRESS))) { + /* convert PCI irq numbers to cp0_intmask bit */ + irq = (10 < irq < 15)? 11 : irq; + if (irq == 11) + set_c0_intcontrol(0x100 << 3); + else + unmask_rm9k_irq(irq); + } +} + +static hw_irq_controller rm9k_irq_controller = { + .typename = "RM9000", + .startup = rm9k_cpu_irq_startup, + .shutdown = rm9k_cpu_irq_shutdown, + .enable = rm9k_cpu_irq_enable, + .disable = rm9k_cpu_irq_disable, + .ack = rm9k_cpu_irq_ack, + .end = rm9k_cpu_irq_end, +}; + +static hw_irq_controller rm9k_perfcounter_irq = { + .typename = "RM9000", + .startup = rm9k_perfcounter_irq_startup, + .shutdown = rm9k_perfcounter_irq_shutdown, + .enable = rm9k_cpu_irq_enable, + .disable = rm9k_cpu_irq_disable, + .ack = rm9k_cpu_irq_ack, + .end = rm9k_cpu_irq_end, +}; + +unsigned int rm9000_perfcount_irq; + +EXPORT_SYMBOL(rm9000_perfcount_irq); + +void __init rm9k_cpu_irq_init(int base) +{ + int i; + + clear_c0_intcontrol(0x0000f000); /* Mask all */ + + for (i = base; i < base + 4; i++) { + irq_desc[i].status = IRQ_DISABLED; + irq_desc[i].action = NULL; + irq_desc[i].depth = 1; + irq_desc[i].handler = &rm9k_irq_controller; + } + + rm9000_perfcount_irq = base + 1; + irq_desc[rm9000_perfcount_irq].handler = &rm9k_perfcounter_irq; + + irq_base = base; +} + + +extern asmlinkage void sequoia_handle_int(void); + +/* + * Handle PCI interrupts. + */ +asmlinkage void pmc_sequoia_pci_isr(int irq, struct pt_regs *regs) +{ + u_int8_t status; + + /* check FPGA intr status register to determine the intr source */ + status = SEQUOIA_FPGA_READ(SEQUOIA_FPGA_INTR_STATUS); + + if (~status & (0x3 << 0)) { /* bus 0, slot 0 */ + do_IRQ(11, regs); + } + if (~status & (0x3 << 2)) { /* bus 0, slot 1 */ + do_IRQ(12, regs); + } + + if (~status & (0x3 << 4)) { /* bus 1, slot 0 */ + do_IRQ(13, regs); + } + if (~status & (0x3 << 6)) { /* bus 1, slot 1 */ + do_IRQ(14, regs); + } +} + +static struct irqaction unused_irq = + { no_action, SA_INTERRUPT, 0, "unused", NULL, NULL }; + +extern unsigned long exception_handlers[32]; + +/* + * Initialize the next level interrupt handler + */ +void __init arch_init_irq(void) +{ + int i; + + clear_c0_status(ST0_IM); + set_c0_status(ST0_IM); + + set_except_vector(0, sequoia_handle_int); + mips_cpu_irq_init(0); + rm7k_cpu_irq_init(8); + rm9k_cpu_irq_init(12); +} + + diff -Naur a/arch/mips/pmc-sierra/sequoia/irq-handler.S b/arch/mips/pmc-sierra/sequoia/irq-handler.S --- a/arch/mips/pmc-sierra/sequoia/irq-handler.S 1969-12-31 16:00:00.000000000 -0800 +++ b/arch/mips/pmc-sierra/sequoia/irq-handler.S 2006-06-22 14:55:16.000000000 -0700 @@ -0,0 +1,99 @@ +/* + * Copyright 2006 PMC-Sierra Inc. + * Author: PMC SIerra Inc (thotakir@pmc-sierra.com) + * + * First-level interrupt router for the PMC-Sierra Sequoia board + * + */ + +#define __ASSEMBLY__ +#include +#include +#include +#include +#include +#include + + .align 5 + NESTED(sequoia_handle_int, PT_SIZE, sp) + SAVE_ALL + CLI + .set at + .set noreorder + mfc0 t0, CP0_CAUSE + mfc0 t2, CP0_STATUS + + and t0, t2 + + andi t1, t0, STATUSF_IP0 /* sw0 software interrupt */ + bnez t1, ll_sw0_irq + andi t1, t0, STATUSF_IP1 /* sw1 software interrupt */ + bnez t1, ll_sw1_irq + /* IP4 reserved for DUART */ + andi t1, t0, STATUSF_IP5 /* XDMA interrupts */ + bnez t1, ll_xdma_irq + /* IP6 reserved for HyperTransport, not supported */ + andi t1, t0, STATUSF_IP7 /* INTB5 hardware line */ + bnez t1, ll_timer_irq /* Timer */ + + nop + nop + + /* Extended interrupts */ + mfc0 t0, CP0_CAUSE + cfc0 t1, CP0_S1_INTCONTROL + + sll t2, t1, 8 + + and t0, t2 + srl t0, t0, 16 + + andi t1, t0, STATUSF_IP10 /* Local Bus */ + bnez t1, ll_lb_irq + andi t1, t0, STATUSF_IP11 /* PCI0 and PCI1 */ + bnez t1, ll_pci_irq + nop /* delay slot */ + .set reorder + + j spurious_interrupt + nop + END(sequoia_handle_int) + + .align 5 + +ll_sw0_irq: + li a0, 0 + move a1, sp + jal do_IRQ + j ret_from_irq + +ll_sw1_irq: + li a0, 1 + move a1, sp + jal do_IRQ + j ret_from_irq + +ll_lb_irq: + li a0, 10 + move a1, sp + jal do_IRQ + j ret_from_irq + +ll_pci_irq: + li a0, 11 + move a1, sp + jal pmc_sequoia_pci_isr + j ret_from_irq + +ll_xdma_irq: + li a0, 5 + move a1, sp + jal do_IRQ + j ret_from_irq + +ll_timer_irq: + li a0, 7 + move a1, sp + jal do_IRQ + j ret_from_irq + diff -Naur a/arch/mips/pmc-sierra/sequoia/Makefile b/arch/mips/pmc-sierra/sequoia/Makefile --- a/arch/mips/pmc-sierra/sequoia/Makefile 1969-12-31 16:00:00.000000000 -0800 +++ b/arch/mips/pmc-sierra/sequoia/Makefile 2006-06-22 11:55:42.000000000 -0700 @@ -0,0 +1,7 @@ +# +# Makefile for the PMC-Sierra Sequoia +# + +obj-y += irq-handler.o irq.o prom.o py-console.o setup.o + + diff -Naur a/arch/mips/pmc-sierra/sequoia/prom.c b/arch/mips/pmc-sierra/sequoia/prom.c --- a/arch/mips/pmc-sierra/sequoia/prom.c 1969-12-31 16:00:00.000000000 -0800 +++ b/arch/mips/pmc-sierra/sequoia/prom.c 2006-06-22 14:57:08.000000000 -0700 @@ -0,0 +1,140 @@ +/* + * Copyright (C) 2006 PMC-Sierra Inc. + * Author: PMC Sierra Inc (thotakir@pmc-sierra.com) + */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#include + +/* Call Vectors */ +struct callvectors { + int (*open) (char*, int, int); + int (*close) (int); + int (*read) (int, void*, int); + int (*write) (int, void*, int); + off_t (*lseek) (int, off_t, int); + int (*printf) (const char*, ...); + void (*cacheflush) (void); + char* (*gets) (char*); + int (*cpustart) (int, int, int, int); +}; + +struct callvectors* debug_vectors; + +extern unsigned long sequoia_memsize; +extern unsigned long cpu_clock; + +unsigned char titan_ge_mac_addr_base[6] = { + 0x30, 0x30, 0x3a, 0x31, 0x31, 0x31 +}; + +const char *get_system_type(void) +{ + return "PMC-Sierra Sequoia"; +} + +static void prom_cpu0_exit(void) +{ + printk(KERN_NOTICE "SW reset not implemented yet\n"); +} + +/* + * Reset the NVRAM over the local bus + */ +static void prom_exit(void) +{ + prom_cpu0_exit(); +} + +/* + * Get the MAC address from the EEPROM using the I2C protocol + */ +void get_mac_address(char dest[6]) +{ + /* Use the I2C command code in the i2c-sequoia */ +} + +/* + * Halt the system + */ +void prom_halt(void) +{ + printk(KERN_NOTICE "\n** You can safely turn off the power\n"); + while (1) + __asm__(".set\tmips3\n\t" + "wait\n\t" + ".set\tmips0"); +} + +/* + * Init routine which accepts the variables from PMON + */ +void __init prom_init(void) +{ + int i = 0; + int argc = fw_arg0; + char **arg = (char **) fw_arg1; + char **env = (char **) fw_arg2; + struct callvectors *cv = (struct callvectors *) fw_arg3; + + /* Callbacks for halt, restart */ + _machine_restart = (void (*)(char *))prom_exit; + _machine_halt = prom_halt; + _machine_power_off = prom_halt; + + debug_vectors = cv; + arcs_cmdline[0] = '\0'; + + /* Get the boot parameters */ + for (i = 1; i < argc; i++) { + if (strlen(arcs_cmdline) + strlen(arg[i] + 1) >= sizeof(arcs_cmdline)) + break; + + strcat(arcs_cmdline, arg[i]); + strcat(arcs_cmdline, " "); + } + + while (*env) { + if (strncmp("memsize", *env, strlen("memsize")) == 0) { + sequoia_memsize = simple_strtol(*env + strlen("memsize="), + NULL, 10); + + printk("PMON reports memory size %dMB\n", sequoia_memsize); + } + if (strncmp("cpuclock", *env, strlen("cpuclock")) == 0) { + cpu_clock = simple_strtol(*env + strlen("cpuclock="), + NULL, 10); + + printk("cpu_clock set to %d\n", cpu_clock); + } + + env++; + } + + + mips_machgroup = MACH_GROUP_TITAN; + mips_machtype = MACH_TITAN_SEQUOIA; + + get_mac_address(titan_ge_mac_addr_base); + +} + +void __init prom_free_prom_memory(void) +{ +} + +void __init prom_fixup_mem_map(unsigned long start, unsigned long end) +{ +} diff -Naur a/arch/mips/pmc-sierra/sequoia/py-console.c b/arch/mips/pmc-sierra/sequoia/py-console.c --- a/arch/mips/pmc-sierra/sequoia/py-console.c 1969-12-31 16:00:00.000000000 -0800 +++ b/arch/mips/pmc-sierra/sequoia/py-console.c 2006-06-22 11:48:21.000000000 -0700 @@ -0,0 +1,123 @@ +/* + * This file is subject to the terms and conditions of the GNU General Public + * License. See the file "COPYING" in the main directory of this archive + * for more details. + * + * Copyright (C) 2001, 2002, 2004 Ralf Baechle + */ +#include +#include +#include +#include +#include +#include +#include + +#include +#include +#include +#include + +/* SUPERIO uart register map */ +struct se_uartregs { + union { + volatile u8 rbr; /* read only, DLAB == 0 */ + volatile u8 thr; /* write only, DLAB == 0 */ + volatile u8 dll; /* DLAB == 1 */ + } u1; + union { + volatile u8 ier; /* DLAB == 0 */ + volatile u8 dlm; /* DLAB == 1 */ + } u2; + union { + volatile u8 iir; /* read only */ + volatile u8 fcr; /* write only */ + } u3; + volatile u8 iu_lcr; + volatile u8 iu_mcr; + volatile u8 iu_lsr; + volatile u8 iu_msr; + volatile u8 iu_scr; +} se_uregs_t; + +#define iu_rbr u1.rbr +#define iu_thr u1.thr +#define iu_dll u1.dll +#define iu_ier u2.ier +#define iu_dlm u2.dlm +#define iu_iir u3.iir +#define iu_fcr u3.fcr + +#define IO_BASE_64 0x9000000000000000ULL + +static unsigned char readb_outer_space(unsigned long phys) +{ + unsigned long long vaddr = IO_BASE_64 | phys; + unsigned char res; + unsigned int sr; + + sr = read_c0_status(); + write_c0_status((sr | ST0_KX) & ~ ST0_IE); + __asm__("sll $0, $0, 2\n"); + __asm__("sll $0, $0, 2\n"); + __asm__("sll $0, $0, 2\n"); + __asm__("sll $0, $0, 2\n"); + + __asm__ __volatile__ ( + " .set mips3 \n" + " ld %0, (%0) \n" + " lbu %0, (%0) \n" + " .set mips0 \n" + : "=r" (res) + : "0" (&vaddr)); + + write_c0_status(sr); + __asm__("sll $0, $0, 2\n"); + __asm__("sll $0, $0, 2\n"); + __asm__("sll $0, $0, 2\n"); + __asm__("sll $0, $0, 2\n"); + + return res; +} + +static void writeb_outer_space(unsigned long phys, unsigned char c) +{ + unsigned long long vaddr = IO_BASE_64 | phys; + unsigned long tmp; + unsigned int sr; + + sr = read_c0_status(); + write_c0_status((sr | ST0_KX) & ~ ST0_IE); + __asm__("sll $0, $0, 2\n"); + __asm__("sll $0, $0, 2\n"); + __asm__("sll $0, $0, 2\n"); + __asm__("sll $0, $0, 2\n"); + + __asm__ __volatile__ ( + " .set mips3 \n" + " ld %0, (%1) \n" + " sb %2, (%0) \n" + " .set mips0 \n" + : "=r" (tmp) + : "r" (&vaddr), "r" (c)); + + write_c0_status(sr); + __asm__("sll $0, $0, 2\n"); + __asm__("sll $0, $0, 2\n"); + __asm__("sll $0, $0, 2\n"); + __asm__("sll $0, $0, 2\n"); +} + +void prom_putchar(char c) +{ + unsigned long lsr = 0xfd000008UL + offsetof(struct se_uartregs, iu_lsr); + unsigned long thr = 0xfd000008UL + offsetof(struct se_uartregs, iu_thr); + + while ((readb_outer_space(lsr) & 0x20) == 0); + writeb_outer_space(thr, c); +} + +char __init prom_getchar(void) +{ + return 0; +} diff -Naur a/arch/mips/pmc-sierra/sequoia/setup.c b/arch/mips/pmc-sierra/sequoia/setup.c --- a/arch/mips/pmc-sierra/sequoia/setup.c 1969-12-31 16:00:00.000000000 -0800 +++ b/arch/mips/pmc-sierra/sequoia/setup.c 2006-06-22 14:57:38.000000000 -0700 @@ -0,0 +1,258 @@ +/* + * arch/mip/pmc-sierra/sequoia/setup.c + * + * Copyright (C) 2006 PMC-Sierra Inc. + * Author: PMC Sierra Inc (thotakir@pmc-sierra.com) + * + */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#include +#include +#include +#include +#include + +#include + +#include + +#include "setup.h" + +unsigned long titan_ge_base; +unsigned long cpu_clock; +unsigned long sequoia_memsize; + +/* Real Time Clock base */ +#define CONV_BCD_TO_BIN(val) (((val) & 0xf) + (((val) >> 4) * 10)) +#define CONV_BIN_TO_BCD(val) (((val) % 10) + (((val) / 10) << 4)) + +static unsigned long ENTRYLO(unsigned long paddr) +{ + return ((paddr & PAGE_MASK) | + (_PAGE_PRESENT | __READABLE | __WRITEABLE | _PAGE_GLOBAL | + _CACHE_UNCACHED)) >> 6; +} + + +void __init bus_error_init(void) +{ + /* Do nothing */ +} + +unsigned long m48t37y_get_time(void) +{ + unsigned char *rtc_base = SEQUOIA_RTC_BASE_ADDR; + unsigned int year, month, day, hour, min, sec; + + /* Stop the update to the time */ + rtc_base[0x7ff8] = 0x40; + + year = CONV_BCD_TO_BIN(rtc_base[0x7fff]); + year += CONV_BCD_TO_BIN(rtc_base[0x7ff1]) * 100; + + month = CONV_BCD_TO_BIN(rtc_base[0x7ffe]); + day = CONV_BCD_TO_BIN(rtc_base[0x7ffd]); + hour = CONV_BCD_TO_BIN(rtc_base[0x7ffb]); + min = CONV_BCD_TO_BIN(rtc_base[0x7ffa]); + sec = CONV_BCD_TO_BIN(rtc_base[0x7ff9]); + + /* Start the update to the time again */ + rtc_base[0x7ff8] = 0x00; + + return mktime(year, month, day, hour, min, sec); +} + +int m48t37y_set_time(unsigned long sec) +{ + unsigned char *rtc_base = SEQUOIA_RTC_BASE_ADDR; + struct rtc_time tm; + + /* convert to a more useful format -- note months count from 0 */ + to_tm(sec, &tm); + tm.tm_mon += 1; + + /* enable writing */ + rtc_base[0x7ff8] = 0x80; + + /* year */ + rtc_base[0x7fff] = CONV_BIN_TO_BCD(tm.tm_year % 100); + rtc_base[0x7ff1] = CONV_BIN_TO_BCD(tm.tm_year / 100); + + /* month */ + rtc_base[0x7ffe] = CONV_BIN_TO_BCD(tm.tm_mon); + + /* day */ + rtc_base[0x7ffd] = CONV_BIN_TO_BCD(tm.tm_mday); + + /* hour/min/sec */ + rtc_base[0x7ffb] = CONV_BIN_TO_BCD(tm.tm_hour); + rtc_base[0x7ffa] = CONV_BIN_TO_BCD(tm.tm_min); + rtc_base[0x7ff9] = CONV_BIN_TO_BCD(tm.tm_sec); + + /* day of week -- not really used, but let's keep it up-to-date */ + rtc_base[0x7ffc] = CONV_BIN_TO_BCD(tm.tm_wday + 1); + + /* disable writing */ + rtc_base[0x7ff8] = 0x00; + + return 0; +} + +void sequoia_timer_setup(struct irqaction *irq) +{ + setup_irq(7, irq); +} + +void sequoia_time_init(void) +{ + mips_hpt_frequency = cpu_clock / 2; + board_timer_setup = sequoia_timer_setup; +} + +/* workaround for PCI, need to return MIPS_BE_DISCARD */ +int sequoia_be_handler(struct pt_regs *regs, int is_fixup) +{ + int data = regs->cp0_cause & 4; + + /* check for data bus error */ + if ((regs->cp0_cause & 0x7c) == 0x1c) { + unsigned long badvaddr; + unsigned long instruction; + int reg; + + instruction = *(u32 *)regs->cp0_epc; + reg = (instruction >> 21)& 0x1f; + badvaddr = regs->regs[reg] + (instruction & 0xffff); + if (((badvaddr & ~0x3) == SEQUOIA_PCI_0_CONFIG_DATA) + || ((badvaddr & ~0x3) == SEQUOIA_PCI_1_CONFIG_DATA)) { + + /* skip the PCI load instruction */ + regs->cp0_epc += 4; + + /* + * Return all 1's for disallowed accesses + * for a kludgy but adequate simulation of + * master aborts. + */ + reg = (instruction >> 16)& 0x1f; + regs->regs[reg] = 0xffffffff; + return MIPS_BE_DISCARD; + } + } + return MIPS_BE_FATAL; +} + +extern void sequoia_serial_init(void); + +/* No other usable initialization hook than this ... */ +extern void (*late_time_init)(void); + +unsigned long rm9150_pci0_base, rm9150_pci1_base, rm9150_dma_base, sequoia_fpga_base; + +/* + * Common setup before any secondaries are started + */ +#define SEQUOIA_UART_CLK 125000000 + +static void __init py_map_ocd(void) +{ + struct uart_port up; + + unsigned long val = 0; + + add_wired_entry(ENTRYLO(0xff000000), ENTRYLO(0xff000000), 0xff000000, PM_4M); + add_wired_entry(ENTRYLO(0xf8000000), ENTRYLO(0xf8000000), 0xf8000000, PM_4M); + add_wired_entry(ENTRYLO(0xf9000000), ENTRYLO(0xf9000000), 0xf9000000, PM_4M); + titan_ge_base = (unsigned long) ioremap(TITAN_GE_BASE, TITAN_GE_SIZE); + + rm9150_pci0_base = (unsigned long) ioremap(RM9150_PCI0_DCR, RM9150_PCI0_SIZE); + rm9150_pci1_base = (unsigned long) ioremap(RM9150_PCI1_DCR, RM9150_PCI1_SIZE ); + + rm9150_dma_base = (unsigned long) ioremap(RM9150_DMA_DCR, RM9150_DMA_SIZE ); + + sequoia_fpga_base = (unsigned long) ioremap(FPGA_BASE, FPGA_SIZE); + + printk(KERN_INFO "%08x = %08x\n", titan_ge_base, (unsigned long)*(unsigned long*)titan_ge_base); + printk(KERN_INFO "%08x\n", rm9150_pci0_base); + printk(KERN_INFO "%08x\n", rm9150_pci1_base); + printk(KERN_INFO "%08x\n", rm9150_dma_base); + printk(KERN_INFO "%08x\n", sequoia_fpga_base); + dump_tlb_all(); + + /* enable the internal UART */ + printk(KERN_INFO "Internal UART Support for PMC-Sierra Sequoia\n "); + + /* initialize the UART */ + /* Take UART out of reset */ + SEQUOIA_GELA_WRITE(RM9150_UACFG, 3); + + /* UART interrupt disable */ + val = SEQUOIA_GELA_READ(RM9150_CPGIG0ER); + val &= 0; + SEQUOIA_GELA_WRITE(RM9150_CPGIG0ER, val); + + /* + * Register to interrupt zero because we share the interrupt with + * the serial driver which we don't properly support yet. + */ + memset(&up, 0, sizeof(up)); + + up.membase = (unsigned long *) titan_ge_base; + up.irq = SEQUOIA_SERIAL_IRQ; + up.uartclk = SEQUOIA_UART_CLK; + up.regshift = 0; + up.iotype = UPIO_MEM; + up.flags = ASYNC_BOOT_AUTOCONF | ASYNC_SKIP_TEST; + up.line = 0; + + if (early_serial_setup(&up)) + printk(KERN_ERR "Early serial init of port 0 failed\n"); +} + +void __init plat_setup(void) +{ + + unsigned long val = 0; + + printk("PMC-Sierra Sequoia Board Setup \n"); + + +#ifdef CONFIG_MIPS64 + printk("64-bit support \n"); +#else + printk("32-bit support \n"); +#endif + + board_time_init = sequoia_time_init; + late_time_init = py_map_ocd; + board_be_handler = sequoia_be_handler; + + add_memory_region(0x00000000, 0x08000000, BOOT_MEM_RAM); +} + diff -Naur a/arch/mips/pmc-sierra/sequoia/setup.h b/arch/mips/pmc-sierra/sequoia/setup.h --- a/arch/mips/pmc-sierra/sequoia/setup.h 1969-12-31 16:00:00.000000000 -0800 +++ b/arch/mips/pmc-sierra/sequoia/setup.h 2006-06-22 11:48:21.000000000 -0700 @@ -0,0 +1,17 @@ +/* + * Copyright 2006 PMC-Sierra + * Author: PMC Sierra Inc (thotakir@pmc-sierra.com) + * + * Board specific definititions for the PMC-Sierra Sequoia + * + */ + +#ifndef __SETUP_H__ +#define __SETUP_H__ + +/* Real Time Clock base */ +#define CONV_BCD_TO_BIN(val) (((val) & 0xf) + (((val) >> 4) * 10)) +#define CONV_BIN_TO_BCD(val) (((val) % 10) + (((val) / 10) << 4)) + +#endif /* __SETUP_H__ */ + diff -Naur a/include/asm-mips/bootinfo.h b/include/asm-mips/bootinfo.h --- a/include/asm-mips/bootinfo.h 2005-07-11 11:28:10.000000000 -0700 +++ b/include/asm-mips/bootinfo.h 2006-06-22 11:48:21.000000000 -0700 @@ -215,6 +215,8 @@ */ #define MACH_GROUP_TITAN 22 /* PMC-Sierra Titan */ #define MACH_TITAN_YOSEMITE 1 /* PMC-Sierra Yosemite */ +#define MACH_TITAN_SEQUOIA 2 /* PMC-Sierra Sequoia */ + #define CL_SIZE COMMAND_LINE_SIZE diff -Naur a/include/asm-mips/mach-sequoia/cpu-feature-overrides.h b/include/asm-mips/mach-sequoia/cpu-feature-overrides.h --- a/include/asm-mips/mach-sequoia/cpu-feature-overrides.h 1969-12-31 16:00:00.000000000 -0800 +++ b/include/asm-mips/mach-sequoia/cpu-feature-overrides.h 2006-06-22 11:48:21.000000000 -0700 @@ -0,0 +1,45 @@ +/* + * This file is subject to the terms and conditions of the GNU General Public + * License. See the file "COPYING" in the main directory of this archive + * for more details. + * + * Copyright (C) 2003, 2004 Ralf Baechle + */ +#ifndef __ASM_MACH_SEQUOIA_CPU_FEATURE_OVERRIDES_H +#define __ASM_MACH_SEQUOIA_CPU_FEATURE_OVERRIDES_H + +/* + * Momentum Jaguar ATX always has the RM9000 processor. + */ +#define cpu_has_watch 1 +#define cpu_has_mips16 0 +#define cpu_has_divec 0 +#define cpu_has_vce 0 +#define cpu_has_cache_cdex_p 0 +#define cpu_has_cache_cdex_s 0 +#define cpu_has_prefetch 1 +#define cpu_has_mcheck 0 +#define cpu_has_ejtag 0 + +#define cpu_has_llsc 1 +#define cpu_has_vtag_icache 0 +#define cpu_has_dc_aliases 0 +#define cpu_has_ic_fills_f_dc 0 +#define cpu_icache_snoops_remote_store 0 + +#define cpu_has_nofpuex 0 +#define cpu_has_64bits 1 + +#define cpu_has_subset_pcaches 0 + +#define cpu_dcache_line_size() 32 +#define cpu_icache_line_size() 32 +#define cpu_scache_line_size() 32 + +/* + * On the RM9000 we need to ensure that I-cache lines being fetches only + * contain valid instructions are funny things will happen. + */ +#define PLAT_TRAMPOLINE_STUFF_LINE 32UL + +#endif /* __ASM_MACH_SEQUOIA_CPU_FEATURE_OVERRIDES_H */ diff -Naur a/include/asm-mips/pmc_sequoia.h b/include/asm-mips/pmc_sequoia.h --- a/include/asm-mips/pmc_sequoia.h 1969-12-31 16:00:00.000000000 -0800 +++ b/include/asm-mips/pmc_sequoia.h 2006-06-22 14:58:46.000000000 -0700 @@ -0,0 +1,296 @@ +/* + * Copyright 2006 PMC-Sierra + * Author: PMC Sierra Inc (thotakir@pmc-sierra.com) + * + * Board specific definititions for the PMC-Sierra Sequoia (MSP85x0) + * + */ + +#ifndef __PMC_SEQUOIA_H__ +#define __PMC_SEQUOIA_H__ + +#include +#include /* for KSEG1ADDR() */ +#include /* for cpu_to_le32() */ +#include /* for ioswab */ + +/* The base address of the system */ +extern unsigned long sequoia_base; + +extern unsigned long rm9150_pci0_base; +extern unsigned long rm9150_pci1_base; +extern unsigned long rm9150_dma_base; +extern unsigned long titan_ge_base; +extern unsigned long sequoia_fpga_base; + +/* FDB ports base addresses , from PMON */ +#define BOOT_BASE 0xfc000000 +#define FLASH_BASE 0xfc000000 +#define RTC_BASE 0xfc200000 +#define FPGA_BASE (RTC_BASE + 0x10000) +#define FPGA_SIZE 0x10000 +#define RM9150_PCI0_DCR 0xff000000 +#define RM9150_PCI1_DCR 0xff010000 +#define RM9150_DDR_DCR 0xff020000 +#define RM9150_FDB_DCR 0xff030000 +#define RM9150_DMA_DCR 0xff040000 +#define RM9150_OCM_DCR 0xff050000 +#define RM9150_LOCALBUS_DCR 0xff070000 +#define RM9150_GE_DCR 0xff080000 + +#define RM9150_PCI0_SIZE 0x10000 +#define RM9150_PCI1_SIZE 0x10000 +#define RM9150_DMA_SIZE 0x10000 +#define RM9150_LOCALBUS_SIZE 0x10000 + +/* FPGA interrupt status and mask registers */ +#define SEQUOIA_FPGA_INTR_STATUS (0x6) +#define SEQUOIA_FPGA_INTR_MASK (0x8) + +#define SEQUOIA_FPGA_READ(reg) (*(volatile u8 *)(sequoia_fpga_base + (reg))) +#define SEQUOIA_FPGA_WRITE(reg, val) \ + do { *(volatile u8 *)(sequoia_fpga_base + (reg)) = (val); } while (0) + +/* RTC and NVRAM Base */ +#define SEQUOIA_RTC_BASE_ADDR RTC_BASE +#define SEQUOIA_NVRAM_BASE_ADDR RTC_BASE + +/* + * RM9150 on-chip RAM + */ +#define RM9150_SRAM_BASE 0xfb000000 +#define RM9150_SRAM_SIZE 0x00008000 /* 32 KB */ + +/* low-speed I/O registers base */ +#define SEQUOIA_GELA_BASE RM9150_GE_DCR + + + +#define TITAN_GE_BASE (RM9150_GE_DCR) +#define TITAN_GE_SIZE 0x10000UL + +#define TITAN_GE_WRITE(offset, data) \ + *(volatile u32 *)(titan_ge_base + (offset)) = (data) + +#define TITAN_GE_READ(offset) *(volatile u32 *)(titan_ge_base + (offset)) + +/* UART definitions, offset from GELA */ +#define RM9150_UACFG (0x500) +#define RM9150_UAINTS (0x504) + +/* CPGIG0SR: UART interrupt status register, p. 334 */ +#define RM9150_CPGIG0SR (0x0024) +#define RM9150_CPGIG0SR_UINT 0x18000000 + +/* CPGIG0SR: UART interrupt enable register, p. 346 */ +#define RM9150_CPGIG0ER (0x0034) +#define RM9150_CPGIG0ER_UINTE 0x18000000 + +/* UART Interrupt Vector Message register, p. 355 */ +#define RM9150_UART_INTVEC (0x0054) +#define RM9150_UART0_INTVEC 0x40 +#define RM9150_UART1_INTVEC 0x41 + +/* Interrupt Set Message Resend register, p. 364 */ +#define RM9150_CPINTSMR1R (0x0078) +#define RM9150_CPINTSMR1R_UART0 0x0400 +#define RM9150_CPINTSMR1R_UART1 0x0800 + +/* CPIF2 Interrupt Set Message Resend Mode register, p. 368 */ +#define RM9150_CPINTSMR (0x007c) +#define RM9150_CPINTSMR_SWEOIACK_MODE 0x01 +#define RM9150_CPINTSMR_TX_ACK_MOD 0x08 +#define RM9150_CPINTSMR_RX_ACK_MOD 0x10 + +/* GPIO registers for CF/PCMCIA */ +#define RM9150_CPGPISR1 0xA4 +#define RM9150_CPGPIMR1 0xA8 + +#define SEQUOIA_GELA_READ(reg) (*(volatile unsigned int *)(titan_ge_base + (reg))) +#define SEQUOIA_GELA_WRITE(reg, val) \ + do { *(volatile unsigned int *)(titan_ge_base + (reg)) = (val); } while (0) + +#define RM9150_GDMA_BASE RM9150_DMA_DCR +#define RM9150_GCIC_BASE (RM9150_GDMA_BASE + 0x8000) + +#define RM9150_GCIC_INTMSG (0x10) +#define RM9150_GCIC_INT0_STATUS (0x30) +#define RM9150_GCIC_INT0_MASK (0x34) +#define RM9150_GCIC_INT0_SET (0x38) +#define RM9150_GCIC_INT0_CLEAR (0x3c) +#define RM9150_GCIC_INT1_STATUS (0x40) +#define RM9150_GCIC_INT1_MASK (0x44) +#define RM9150_GCIC_INT1_SET (0x48) +#define RM9150_GCIC_INT1_CLEAR (0x4c) +#define RM9150_GCIC_INT2_STATUS (0x50) +#define RM9150_GCIC_INT2_MASK (0x54) +#define RM9150_GCIC_INT2_SET (0x58) +#define RM9150_GCIC_INT2_CLEAR (0x5c) +#define RM9150_GCIC_INT3_STATUS (0x60) +#define RM9150_GCIC_INT3_MASK (0x64) +#define RM9150_GCIC_INT3_SET (0x68) +#define RM9150_GCIC_INT3_CLEAR (0x6c) +#define RM9150_GCIC_INT4_STATUS (0x70) +#define RM9150_GCIC_INT4_MASK (0x74) +#define RM9150_GCIC_INT4_SET (0x78) +#define RM9150_GCIC_INT4_CLEAR (0x7c) +#define RM9150_GCIC_INT5_STATUS (0x80) +#define RM9150_GCIC_INT5_MASK (0x84) +#define RM9150_GCIC_INT5_SET (0x88) +#define RM9150_GCIC_INT5_CLEAR (0x8c) +#define RM9150_GCIC_INT6_STATUS (0x90) +#define RM9150_GCIC_INT6_MASK (0x94) +#define RM9150_GCIC_INT6_SET (0x98) +#define RM9150_GCIC_INT6_CLEAR (0x9c) +#define RM9150_GCIC_INT7_STATUS (0xa0) +#define RM9150_GCIC_INT7_MASK (0xa4) +#define RM9150_GCIC_INT7_SET (0xa8) +#define RM9150_GCIC_INT7_CLEAR (0xac) + +#define SEQUOIA_CICA_READ(reg) (*(volatile unsigned int *)(rm9150_dma_base + 0x8000 + (reg))) +#define SEQUOIA_CICA_WRITE(reg, val) \ + do { *(volatile unsigned int *)(rm9150_dma_base + 0x8000 + (reg)) = (val); } while (0) + + +/* PCI */ + +/* + * PCI configuration registers + * pmon2000/src/Targets/Sequoia/compile/SEQUOIA-EB/machine/rm9150_pci.h + */ +#define RM9150_PCI_GDI_IDENT 0x0000 +#define RM9150_PCI_IAM_CONFIG_STATUS 0x0004 +#define RM9150_PCI_CONFIG_ADDR 0x0010 +#define RM9150_PCI_CONFIG_DATA 0x0014 +#define RM9150_PCI_CONFIG_STATUS 0x0018 +#define RM9150_PCI_GDI_BAR0 0x001c +#define RM9150_PCI_GDI_BAR0_ATTRIBUTES 0x0020 +#define RM9150_PCI_GDI_BAR1 0x0024 +#define RM9150_PCI_GDI_BAR1_ATTRIBUTES 0x0028 +#define RM9150_PCI_GDI_BAR2 0x002c +#define RM9150_PCI_GDI_BAR2_ATTRIBUTES 0x0030 +#define RM9150_PCI_GDI_BAR3 0x0034 +#define RM9150_PCI_GDI_BAR3_ATTRIBUTES 0x0038 +#define RM9150_PCI_GDI_BAR4 0x003c +#define RM9150_PCI_GDI_BAR4_ATTRIBUTES 0x0040 +#define RM9150_PCI_GDI_BAR5 0x0044 +#define RM9150_PCI_GDI_BAR5_ATTRIBUTES 0x0048 +#define RM9150_PCI_MASTER_GDI_VIRT_IOBASE 0x004c +#define RM9150_PCI_MASTER_GDI_VIRT_IOMASK 0x0050 +#define RM9150_PCI_MASTER_GDI_VIRT_PREFETCH_BASE 0x0054 +#define RM9150_PCI_MASTER_GDI_VIRT_PREFETCH_SIZE 0x0058 +#define RM9150_PCI_MASTER_WRITE_REQ_DATA_SWAP 0x0080 +#define RM9150_PCI_MASTER_READ_RESP_DATA_SWAP 0x0084 +#define RM9150_PCI_RESET 0x008c +#define RM9150_PCI_RESPONSE_ERROR_MASK 0x0090 +#define RM9150_PCI_TRANSACTION_COMBINING 0x0094 +#define RM9150_PCI_ECC_STATUS 0x00a8 +#define RM9150_PCI_ECC_ERROR_INJECTION 0x00ac +#define RM9150_PCI_DEVICE_VENDOR_ID 0x0100 +#define RM9150_PCI_COMMAND_STATUS 0x0104 +#define RM9150_PCI_CLASS_CODE_REV_ID 0x0108 +#define RM9150_PCI_BIST_HEADER_TYPE 0x010c +#define RM9150_PCI_TARGET_BAR0 0x0110 +#define RM9150_PCI_TARGET_BAR1 0x0114 +#define RM9150_PCI_TARGET_BAR2 0x0118 +#define RM9150_PCI_TARGET_BAR3 0x011c +#define RM9150_PCI_TARGET_BAR4 0x0120 +#define RM9150_PCI_TARGET_BAR5 0x0124 +#define RM9150_PCI_SUBSYSTEM_DEVICE_VENDOR_ID 0x012c +#define RM9150_PCI_EXPANSION_ROM_BASE_ADDR 0x0130 +#define RM9150_PCI_CAPABILITIES_POINTER 0x0134 +#define RM9150_PCI_INTERRUPT_LINE 0x013c +#define RM9150_PCI_CONFIG_STATUS_1 0x0140 +#define RM9150_PCI_TARGET_DELAYED_TRANSACTIONS 0x0148 +#define RM9150_PCI_CONFIG_STATUS_2 0x014c +#define RM9150_PCI_MASTER_DEFERRED_TRANSACTIONS 0x0148 +#define RM9150_PCI_CONFIG_STATUS_3 0x0158 +#define RM9150_PCI_CONFIGURATION_HOLD_0 0x0200 +#define RM9150_PCI_CONFIGURATION_HOLD_1 0x0204 +#define RM9150_PCI_CONFIGURATION_HOLD_2 0x0208 +#define RM9150_PCI_CONFIGURATION_HOLD_3 0x020c +#define RM9150_PCI_CONFIGURATION_HOLD_4 0x0210 +#define RM9150_PCI_CONFIGURATION_HOLD_5 0x0214 +#define RM9150_PCI_CONFIGURATION_HOLD_6 0x0218 +#define RM9150_PCI_CONFIGURATION_HOLD_7 0x021c +#define RM9150_PCI_CONFIGURATION_HOLD_8 0x0220 +#define RM9150_PCI_CONFIGURATION_HOLD_9 0x0224 +#define RM9150_PCI_CONFIGURATION_HOLD_10 0x0228 +#define RM9150_PCI_CONFIGURATION_HOLD_11 0x022c +#define RM9150_PCI_CONFIGURATION_HOLD_12 0x0230 +#define RM9150_PCI_CONFIGURATION_HOLD_13 0x0234 +#define RM9150_PCI_INTERRUPT_MSG_HANDSHAKE 0x0238 +#define RM9150_PCI_ERROR_STATUS_FAULT_INTERRUPT 0x0254 +#define RM9150_PCI_SERR_CAUSE_ENABLE 0x0258 +#define RM9150_PCI_FAULT_INTERRUPT_ENABLE 0x025c +#define RM9150_PCI_ERROR_ADDRESS_EVENT 0x0260 +#define RM9150_PCI_ERROR_ADDRESS 0x0264 +#define RM9150_PCI_GDI_DIAGNOSTIC_ERRORS 0x0268 + +/* + * PCI Bus 0 + */ +#define SEQUOIA_PCI0_MEM_BASE 0xe0000000 +#define SEQUOIA_PCI0_MEM_SIZE 0x08000000 +#define SEQUOIA_PCI0_IO_BASE 0xf8000000 +#define SEQUOIA_PCI0_IO_SIZE 0x01000000 + +/* + * PCI Bus 1 + */ +#define SEQUOIA_PCI1_MEM_BASE 0xe8000000 +#define SEQUOIA_PCI1_MEM_SIZE 0x08000000 +#define SEQUOIA_PCI1_IO_BASE 0xf9000000 +#define SEQUOIA_PCI1_IO_SIZE 0x01000000 + +#define SEQUOIA_PCI_MEM_BASE 0xe0000000 +#define SEQUOIA_PCI_MEM_SIZE 0x18000000 +#define SEQUOIA_PCI_IO_BASE 0xf8000000 +#define SEQUOIA_PCI_IO_SIZE 0x02000000 + +/* + * PCI 0 specific defines + */ +#define SEQUOIA_PCI0_BASE RM9150_PCI0_DCR +#define SEQUOIA_PCI_0_CONFIG_ADDRESS (RM9150_PCI0_DCR + RM9150_PCI_CONFIG_ADDR) +#define SEQUOIA_PCI_0_CONFIG_DATA (rm9150_pci0_base + RM9150_PCI_CONFIG_DATA) + +/* + * PCI 1 specific defines + */ +#define SEQUOIA_PCI1_BASE RM9150_PCI1_DCR +#define SEQUOIA_PCI_1_CONFIG_ADDRESS (RM9150_PCI1_DCR + RM9150_PCI_CONFIG_ADDR) +#define SEQUOIA_PCI_1_CONFIG_DATA (rm9150_pci1_base + RM9150_PCI_CONFIG_DATA) + +#define SEQUOIA_PCI0_WRITE(ofs, data) \ + do { *(volatile u32 *)( rm9150_pci0_base + (ofs)) = (data); } while(0) +#define SEQUOIA_PCI0_READ(ofs) \ + *(volatile u32 *)(rm9150_pci0_base +(ofs)) + +#define SEQUOIA_PCI0_WRITE_16(ofs, data) \ + do { *(volatile u16 *)(rm9150_pci0_base + (ofs)) = (data); } while(0) +#define SEQUOIA_PCI0_READ_16(ofs) \ + *(volatile u16 *)(rm9150_pci0_base +(ofs)) + +#define SEQUOIA_PCI0_WRITE_8(ofs, data) \ + do { *(volatile u8 *)(rm9150_pci0_base + (ofs)) = (data); } while(0) +#define SEQUOIA_PCI0_READ_8(ofs) \ + *(volatile u8 *)(rm9150_pci0_base +(ofs)) + + +#define SEQUOIA_PCI1_WRITE(ofs, data) \ + do { *(volatile u32 *)(rm9150_pci1_base + (ofs)) = (data); } while(0) +#define SEQUOIA_PCI1_READ(ofs) \ + *(volatile u32 *)(rm9150_pci1_base +(ofs)) + +#define SEQUOIA_PCI1_WRITE_16(ofs, data) \ + do { *(volatile u16 *)(rm9150_pci1_base + (ofs)) = (data); } while(0) +#define SEQUOIA_PCI1_READ_16(ofs) \ + *(volatile u16 *)(rm9150_pci1_base +(ofs)) + +#define SEQUOIA_PCI1_WRITE_8(ofs, data) \ + do { *(volatile u8 *)(rm9150_pci1_base + (ofs)) = (data); } while(0) +#define SEQUOIA_PCI1_READ_8(ofs) \ + *(volatile u8 *)(rm9150_pci1_base +(ofs)) + +#endif From Kiran_Thota@pmc-sierra.com Sat Jun 24 03:02:16 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 24 Jun 2006 03:02:27 +0100 (BST) Received: from father.pmc-sierra.com ([216.241.224.13]:48551 "HELO father.pmc-sierra.bc.ca") by ftp.linux-mips.org with SMTP id S8133862AbWFXCCP (ORCPT ); Sat, 24 Jun 2006 03:02:15 +0100 Received: (qmail 18180 invoked by uid 101); 24 Jun 2006 02:02:09 -0000 Received: from unknown (HELO ogmios.pmc-sierra.bc.ca) (216.241.226.59) by father.pmc-sierra.com with SMTP; 24 Jun 2006 02:02:09 -0000 Received: from bby1exi01.pmc_nt.nt.pmc-sierra.bc.ca (bby1exi01.pmc-sierra.bc.ca [216.241.231.251]) by ogmios.pmc-sierra.bc.ca (8.13.3/8.12.7) with ESMTP id k5O228ie019579; Fri, 23 Jun 2006 19:02:08 -0700 Received: by bby1exi01.pmc-sierra.bc.ca with Internet Mail Service (5.5.2656.59) id ; Fri, 23 Jun 2006 19:02:07 -0700 Message-ID: From: Kiran Thota To: ralf@linux-mips.org, linux-mips@linux-mips.org Cc: Raj Palani Subject: [PATCH 4/6] Sequoia Serial driver Date: Fri, 23 Jun 2006 19:02:00 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11846 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: Kiran_Thota@pmc-sierra.com Precedence: bulk X-list: linux-mips - Add specific code for PMC Internal uart - Add IRQ defns for PMC Internal uart - Add definitions for PMC Internal uart reg defns (AFAIK, Basler sent similar patch) Signed-off-by: Kiran Kumar Thota diff -Naur a/drivers/serial/8250.c b/drivers/serial/8250.c --- a/drivers/serial/8250.c 2005-07-11 11:28:10.000000000 -0700 +++ b/drivers/serial/8250.c 2006-06-22 11:48:21.000000000 -0700 @@ -275,7 +275,11 @@ return inb(up->port.iobase + 1); case UPIO_MEM: +#if defined(CONFIG_PMC_INTERNAL_UART) + return (__raw_readl(up->port.membase + offset) & 0xff); +#else return readb(up->port.membase + offset); +#endif case UPIO_MEM32: return readl(up->port.membase + offset); @@ -297,7 +301,11 @@ break; case UPIO_MEM: +#if defined(CONFIG_PMC_INTERNAL_UART) + __raw_writel(value, up->port.membase + offset); +#else writeb(value, up->port.membase + offset); +#endif break; case UPIO_MEM32: @@ -1036,6 +1044,12 @@ up->acr &= ~UART_ACR_TXDIS; serial_icr_write(up, UART_ACR, up->acr); } + +#if defined(CONFIG_PMC_INTERNAL_UART) + /* kick it! */ + serial_out(up, UART_TX, 0); +#endif + } static void serial8250_stop_rx(struct uart_port *port) @@ -2158,6 +2172,10 @@ int parity = 'n'; int flow = 'n'; +#ifdef CONFIG_PMC_SEQUOIA + baud=115200; +#endif + /* * Check whether an invalid uart number has been specified, and * if so, search for the first available port that does have diff -Naur a/include/asm-mips/serial.h b/include/asm-mips/serial.h --- a/include/asm-mips/serial.h 2005-07-11 11:28:10.000000000 -0700 +++ b/include/asm-mips/serial.h 2006-06-22 11:48:21.000000000 -0700 @@ -298,6 +298,11 @@ #define MOMENCO_JAGUAR_ATX_SERIAL_PORT_DEFNS #endif +#ifdef CONFIG_PMC_SEQUOIA +#define SEQUOIA_SERIAL_IRQ 0 +#define SEQUOIA_SERIAL_IRQ_1 0 +#endif + #ifdef CONFIG_MOMENCO_OCELOT_3 #define OCELOT_3_BASE_BAUD ( 20000000 / 16 ) #define OCELOT_3_SERIAL_IRQ 6 diff -Naur a/include/linux/serial_reg.h b/include/linux/serial_reg.h --- a/include/linux/serial_reg.h 2005-07-11 11:28:10.000000000 -0700 +++ b/include/linux/serial_reg.h 2006-06-22 11:48:21.000000000 -0700 @@ -17,10 +17,17 @@ /* * DLAB=0 */ +#if defined(CONFIG_PMC_INTERNAL_UART) && defined(CONFIG_PMC_SEQUOIA) +#define UART_RX 0x508 /* In: Receive buffer (DLAB=0) */ +#define UART_TX 0x50C /* Out: Transmit buffer (DLAB=0) */ + +#define UART_IER 0x514 /* Out: Interrupt Enable Register */ +#else #define UART_RX 0 /* In: Receive buffer */ #define UART_TX 0 /* Out: Transmit buffer */ #define UART_IER 1 /* Out: Interrupt Enable Register */ +#endif /* CONFIG_PMC_INTERNAL_UART && CONFIG_PMC_SEQUOIA */ #define UART_IER_MSI 0x08 /* Enable Modem status interrupt */ #define UART_IER_RLSI 0x04 /* Enable receiver line status interrupt */ #define UART_IER_THRI 0x02 /* Enable Transmitter holding register int. */ @@ -30,7 +37,11 @@ */ #define UART_IERX_SLEEP 0x10 /* Enable sleep mode */ +#if defined(CONFIG_PMC_INTERNAL_UART) && defined(CONFIG_PMC_SEQUOIA) +#define UART_IIR 0x51C /* In: Interrupt ID Register */ +#else #define UART_IIR 2 /* In: Interrupt ID Register */ +#endif /* CONFIG_PMC_INTERNAL_UART && CONFIG_PMC_SEQUOIA */ #define UART_IIR_NO_INT 0x01 /* No interrupts pending */ #define UART_IIR_ID 0x06 /* Mask for the interrupt ID */ #define UART_IIR_MSI 0x00 /* Modem status interrupt */ @@ -38,7 +49,11 @@ #define UART_IIR_RDI 0x04 /* Receiver data interrupt */ #define UART_IIR_RLSI 0x06 /* Receiver line status interrupt */ +#if defined(CONFIG_PMC_INTERNAL_UART) && defined(CONFIG_PMC_SEQUOIA) +#define UART_FCR 0x520 /* Out: FIFO Control Register */ +#else #define UART_FCR 2 /* Out: FIFO Control Register */ +#endif /* CONFIG_PMC_INTERNAL_UART && CONFIG_PMC_SEQUOIA */ #define UART_FCR_ENABLE_FIFO 0x01 /* Enable the FIFO */ #define UART_FCR_CLEAR_RCVR 0x02 /* Clear the RCVR FIFO */ #define UART_FCR_CLEAR_XMIT 0x04 /* Clear the XMIT FIFO */ @@ -81,7 +96,11 @@ #define UART_FCR6_T_TRIGGER_30 0x30 /* Mask for transmit trigger set at 30 */ #define UART_FCR7_64BYTE 0x20 /* Go into 64 byte mode (TI16C750) */ +#if defined(CONFIG_PMC_INTERNAL_UART) && defined(CONFIG_PMC_SEQUOIA) +#define UART_LCR 0x524 /* Out: Line Control Register */ +#else #define UART_LCR 3 /* Out: Line Control Register */ +#endif /* CONFIG_PMC_INTERNAL_UART && CONFIG_PMC_SEQUOIA */ /* * Note: if the word length is 5 bits (UART_LCR_WLEN5), then setting * UART_LCR_STOP will select 1.5 stop bits, not 2 stop bits. @@ -97,7 +116,11 @@ #define UART_LCR_WLEN7 0x02 /* Wordlength: 7 bits */ #define UART_LCR_WLEN8 0x03 /* Wordlength: 8 bits */ +#if defined(CONFIG_PMC_INTERNAL_UART) && defined(CONFIG_PMC_SEQUOIA) +#define UART_MCR 0x528 /* Out: Modem Control Register */ +#else #define UART_MCR 4 /* Out: Modem Control Register */ +#endif /* CONFIG_PMC_INTERNAL_UART && CONFIG_PMC_SEQUOIA */ #define UART_MCR_CLKSEL 0x80 /* Divide clock by 4 (TI16C752, EFR[4]=1) */ #define UART_MCR_TCRTLR 0x40 /* Access TCR/TLR (TI16C752, EFR[4]=1) */ #define UART_MCR_XONANY 0x20 /* Enable Xon Any (TI16C752, EFR[4]=1) */ @@ -108,7 +131,11 @@ #define UART_MCR_RTS 0x02 /* RTS complement */ #define UART_MCR_DTR 0x01 /* DTR complement */ +#if defined(CONFIG_PMC_INTERNAL_UART) && defined(CONFIG_PMC_SEQUOIA) +#define UART_LSR 0x52C /* In: Line Status Register */ +#else #define UART_LSR 5 /* In: Line Status Register */ +#endif /* CONFIG_PMC_INTERNAL_UART && CONFIG_PMC_SEQUOIA */ #define UART_LSR_TEMT 0x40 /* Transmitter empty */ #define UART_LSR_THRE 0x20 /* Transmit-hold-register empty */ #define UART_LSR_BI 0x10 /* Break interrupt indicator */ @@ -117,7 +144,11 @@ #define UART_LSR_OE 0x02 /* Overrun error indicator */ #define UART_LSR_DR 0x01 /* Receiver data ready */ +#if defined(CONFIG_PMC_INTERNAL_UART) && defined(CONFIG_PMC_SEQUOIA) +#define UART_MSR 0x530 /* In: Modem Status Register */ +#else #define UART_MSR 6 /* In: Modem Status Register */ +#endif /* CONFIG_PMC_INTERNAL_UART && CONFIG_PMC_SEQUOIA */ #define UART_MSR_DCD 0x80 /* Data Carrier Detect */ #define UART_MSR_RI 0x40 /* Ring Indicator */ #define UART_MSR_DSR 0x20 /* Data Set Ready */ @@ -128,18 +159,34 @@ #define UART_MSR_DCTS 0x01 /* Delta CTS */ #define UART_MSR_ANY_DELTA 0x0F /* Any of the delta bits! */ +#if defined(CONFIG_PMC_INTERNAL_UART) && defined(CONFIG_PMC_SEQUOIA) +#define UART_SCR 0x534 /* I/O: Scratch Register */ +#else #define UART_SCR 7 /* I/O: Scratch Register */ +#endif /* CONFIG_PMC_INTERNAL_UART && CONFIG_PMC_SEQUOIA */ /* * DLAB=1 */ +#if defined(CONFIG_PMC_INTERNAL_UART) && defined(CONFIG_PMC_SEQUOIA) +#define UART_DLL 0x510 /* Out: Divisor Latch Low */ +#define UART_DLM 0x518 /* Out: Divisor Latch High */ +#else #define UART_DLL 0 /* Out: Divisor Latch Low */ #define UART_DLM 1 /* Out: Divisor Latch High */ +#endif /* CONFIG_PMC_INTERNAL_UART && CONFIG_PMC_SEQUOIA */ + /* * LCR=0xBF (or DLAB=1 for 16C660) */ +#if defined(CONFIG_PMC_INTERNAL_UART) && defined(CONFIG_PMC_SEQUOIA) +#define UART_EFR 0x520 /* N/A + * (DLAB=1, 16C660 only) */ + +#else #define UART_EFR 2 /* I/O: Extended Features Register */ +#endif /* CONFIG_PMC_INTERNAL_UART && CONFIG_PMC_SEQUOIA */ #define UART_EFR_CTS 0x80 /* CTS flow control */ #define UART_EFR_RTS 0x40 /* RTS flow control */ #define UART_EFR_SCD 0x20 /* Special character detect */ @@ -165,9 +212,15 @@ /* * LCR=0xBF, XR16C85x */ +#if defined(CONFIG_PMC_INTERNAL_UART) && defined(CONFIG_PMC_SEQUOIA) +#define UART_TRG 0x510 /* N/A, make comiler happy + * XR16C85x only */ + +#else #define UART_TRG 0 /* FCTR bit 7 selects Rx or Tx * In: Fifo count * Out: Fifo custom trigger levels */ +#endif /* CONFIG_PMC_INTERNAL_UART && CONFIG_PMC_SEQUOIA */ /* * These are the definitions for the Programmable Trigger Register */ @@ -181,7 +234,12 @@ #define UART_TRG_120 0x78 #define UART_TRG_128 0x80 +#if defined(CONFIG_PMC_INTERNAL_UART) && defined(CONFIG_PMC_SEQUOIA) +#define UART_FCTR 0x518 /* N/A + * XR16C85x only */ +#else #define UART_FCTR 1 /* Feature Control Register */ +#endif /* CONFIG_PMC_INTERNAL_UART && CONFIG_PMC_SEQUOIA */ #define UART_FCTR_RTS_NODELAY 0x00 /* RTS flow control delay */ #define UART_FCTR_RTS_4DELAY 0x01 #define UART_FCTR_RTS_6DELAY 0x02 @@ -199,7 +257,12 @@ /* * LCR=0xBF, FCTR[6]=1 */ +#if defined(CONFIG_PMC_INTERNAL_UART) && defined(CONFIG_PMC_SEQUOIA) +#define UART_EMSR 0x534 /* N/A + * XR16c85x only */ +#else #define UART_EMSR 7 /* Extended Mode Select Register */ +#endif /* CONFIG_PMC_INTERNAL_UART && CONFIG_PMC_SEQUOIA */ #define UART_EMSR_FIFO_COUNT 0x01 /* Rx/Tx select */ #define UART_EMSR_ALT_COUNT 0x02 /* Alternating count select */ From Kiran_Thota@pmc-sierra.com Sat Jun 24 03:07:15 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 24 Jun 2006 03:07:26 +0100 (BST) Received: from mother.pmc-sierra.com ([216.241.224.12]:40888 "HELO mother.pmc-sierra.bc.ca") by ftp.linux-mips.org with SMTP id S8133929AbWFXCHP (ORCPT ); Sat, 24 Jun 2006 03:07:15 +0100 Received: (qmail 10822 invoked by uid 101); 24 Jun 2006 02:07:08 -0000 Received: from unknown (HELO ogyruan.pmc-sierra.bc.ca) (216.241.226.236) by mother.pmc-sierra.com with SMTP; 24 Jun 2006 02:07:08 -0000 Received: from bby1exi01.pmc_nt.nt.pmc-sierra.bc.ca (bby1exi01.pmc-sierra.bc.ca [216.241.231.251]) by ogyruan.pmc-sierra.bc.ca (8.13.3/8.12.7) with ESMTP id k5O278AW008558; Fri, 23 Jun 2006 19:07:08 -0700 Received: by bby1exi01.pmc-sierra.bc.ca with Internet Mail Service (5.5.2656.59) id ; Fri, 23 Jun 2006 19:07:08 -0700 Message-ID: From: Kiran Thota To: ralf@linux-mips.org, linux-mips@linux-mips.org Cc: Raj Palani Subject: [PATCH 5/6] RM9000 arch, WAR Date: Fri, 23 Jun 2006 19:06:57 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11847 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: Kiran_Thota@pmc-sierra.com Precedence: bulk X-list: linux-mips - Add code to flush scache also (need to revisit if any missing) - Add init code for scache - Add WAR for E9000 ENTRYHI bug, aha! And this brings back OPCODE for "or" Signed-off-by: Kiran Kumar Thota diff -Naur a/arch/mips/mm/c-r4k.c b/arch/mips/mm/c-r4k.c --- a/arch/mips/mm/c-r4k.c 2005-07-11 11:28:10.000000000 -0700 +++ b/arch/mips/mm/c-r4k.c 2006-06-22 11:48:21.000000000 -0700 @@ -649,7 +649,11 @@ a = addr & ~(dc_lsize - 1); end = (addr + size - 1) & ~(dc_lsize - 1); while (1) { +#ifdef CONFIG_CPU_RM9000 + flush_scache_line(a); /* Hit_Writeback_Inv_SD */ +#else flush_dcache_line(a); /* Hit_Writeback_Inv_D */ +#endif if (a == end) break; a += dc_lsize; @@ -694,7 +698,11 @@ a = addr & ~(dc_lsize - 1); end = (addr + size - 1) & ~(dc_lsize - 1); while (1) { +#ifdef CONFIG_CPU_RM9000 + flush_scache_line(a); /* Hit_Writeback_Inv_SD */ +#else flush_dcache_line(a); /* Hit_Writeback_Inv_D */ +#endif if (a == end) break; a += dc_lsize; @@ -1164,6 +1172,9 @@ case CPU_RM9000: #ifdef CONFIG_RM7000_CPU_SCACHE rm7k_sc_init(); +#ifdef CONFIG_CPU_RM9000 + sc_present = 1; +#endif #endif return; diff -Naur a/arch/mips/mm/sc-rm7k.c b/arch/mips/mm/sc-rm7k.c --- a/arch/mips/mm/sc-rm7k.c 2005-07-11 11:28:10.000000000 -0700 +++ b/arch/mips/mm/sc-rm7k.c 2006-06-22 11:48:21.000000000 -0700 @@ -144,6 +144,9 @@ void __init rm7k_sc_init(void) { unsigned int config = read_c0_config(); +#ifdef CONFIG_CPU_RM9000 + struct cpuinfo_mips *c = ¤t_cpu_data; +#endif if ((config & RM7K_CONF_SC)) return; @@ -154,6 +157,12 @@ if (!(config & RM7K_CONF_SE)) rm7k_sc_enable(); +#ifdef CONFIG_CPU_RM9000 + c->scache.linesz = 16<<((config & R4K_CONF_SB) >> 22); + c->scache.ways = 4; + c->scache.waybit = 5; + c->options |= MIPS_CPU_CACHE_CDEX_S; +#endif /* * While we're at it let's deal with the tertiary cache. */ diff -Naur a/arch/mips/mm/tlbex.c b/arch/mips/mm/tlbex.c --- a/arch/mips/mm/tlbex.c 2005-07-11 11:28:10.000000000 -0700 +++ b/arch/mips/mm/tlbex.c 2006-06-22 12:24:19.000000000 -0700 @@ -50,6 +50,12 @@ return R10000_LLSC_WAR; } +static __init int __attribute__((unused)) e9000_llsc_war(void) +{ + return E9000_ENTRYHI_WAR; +} + + /* * A little micro-assembler, intended for TLB refill handler * synthesizing. It is intentionally kept simple, does only support @@ -95,7 +101,7 @@ insn_dsll, insn_dsll32, insn_dsra, insn_dsrl, insn_dsubu, insn_eret, insn_j, insn_jal, insn_jr, insn_ld, insn_ll, insn_lld, insn_lui, insn_lw, insn_mfc0, insn_mtc0, - insn_ori, insn_rfe, insn_sc, insn_scd, insn_sd, insn_sll, + insn_or, insn_ori, insn_rfe, insn_sc, insn_scd, insn_sd, insn_sll, insn_sra, insn_srl, insn_subu, insn_sw, insn_tlbp, insn_tlbwi, insn_tlbwr, insn_xor, insn_xori }; @@ -147,6 +153,7 @@ { insn_lw, M(lw_op,0,0,0,0,0), RS | RT | SIMM }, { insn_mfc0, M(cop0_op,mfc_op,0,0,0,0), RT | RD }, { insn_mtc0, M(cop0_op,mtc_op,0,0,0,0), RT | RD }, + { insn_or, M(spec_op,0,0,0,0,or_op), RS | RT | RD }, { insn_ori, M(ori_op,0,0,0,0,0), RS | RT | UIMM }, { insn_rfe, M(cop0_op,cop_op,0,0,0,rfe_op), 0 }, { insn_sc, M(sc_op,0,0,0,0,0), RS | RT | SIMM }, @@ -378,6 +385,7 @@ I_u2s3u1(_lw); I_u1u2(_mfc0); I_u1u2(_mtc0); +I_u3u1u2(_or); I_u2u1u3(_ori); I_0(_rfe); I_u2s3u1(_sc); @@ -1157,6 +1165,16 @@ /* No need for i_nop */ } + if (e9000_llsc_war()) { + i_MFC0(&p, K0, C0_BADVADDR); + i_MFC0(&p, K1, C0_ENTRYHI); + i_ori(&p, K0, K0, 0x1fff); + i_xori(&p, K0, K0, 0x1fff); + i_andi(&p, K1, K1, 0x0fff); + i_or(&p, K0, K0, K1); + i_MTC0(&p, K0, C0_ENTRYHI); + } + #ifdef CONFIG_MIPS64 build_get_pmde64(&p, &l, &r, K0, K1); /* get pmd in K1 */ #else @@ -1665,6 +1683,16 @@ /* No need for i_nop */ } + if (e9000_llsc_war()) { + i_MFC0(&p, K0, C0_BADVADDR); + i_MFC0(&p, K1, C0_ENTRYHI); + i_ori(&p, K0, K0, 0x1fff); + i_xori(&p, K0, K0, 0x1fff); + i_andi(&p, K1, K1, 0x0fff); + i_or(&p, K0, K0, K1); + i_MTC0(&p, K0, C0_ENTRYHI); + } + build_r4000_tlbchange_handler_head(&p, &l, &r, K0, K1); build_pte_present(&p, &l, &r, K0, K1, label_nopage_tlbl); build_make_valid(&p, &r, K0, K1); @@ -1704,6 +1732,16 @@ memset(labels, 0, sizeof(labels)); memset(relocs, 0, sizeof(relocs)); + if (e9000_llsc_war()) { + i_MFC0(&p, K0, C0_BADVADDR); + i_MFC0(&p, K1, C0_ENTRYHI); + i_ori(&p, K0, K0, 0x1fff); + i_xori(&p, K0, K0, 0x1fff); + i_andi(&p, K1, K1, 0x0fff); + i_or(&p, K0, K0, K1); + i_MTC0(&p, K0, C0_ENTRYHI); + } + build_r4000_tlbchange_handler_head(&p, &l, &r, K0, K1); build_pte_writable(&p, &l, &r, K0, K1, label_nopage_tlbs); build_make_write(&p, &r, K0, K1); @@ -1743,6 +1781,16 @@ memset(labels, 0, sizeof(labels)); memset(relocs, 0, sizeof(relocs)); + if (e9000_llsc_war()) { + i_MFC0(&p, K0, C0_BADVADDR); + i_MFC0(&p, K1, C0_ENTRYHI); + i_ori(&p, K0, K0, 0x1fff); + i_xori(&p, K0, K0, 0x1fff); + i_andi(&p, K1, K1, 0x0fff); + i_or(&p, K0, K0, K1); + i_MTC0(&p, K0, C0_ENTRYHI); + } + build_r4000_tlbchange_handler_head(&p, &l, &r, K0, K1); build_pte_modifiable(&p, &l, &r, K0, K1, label_nopage_tlbm); /* Present and writable bits set, set accessed and dirty bits. */ diff -Naur a/include/asm-mips/war.h b/include/asm-mips/war.h --- a/include/asm-mips/war.h 2005-07-11 11:28:10.000000000 -0700 +++ b/include/asm-mips/war.h 2006-06-22 11:48:21.000000000 -0700 @@ -182,10 +182,16 @@ * being fetched may case spurious exceptions. */ #if defined(CONFIG_MOMENCO_JAGUAR_ATX) || defined(CONFIG_MOMENCO_OCELOT_3) || \ - defined(CONFIG_PMC_YOSEMITE) + defined(CONFIG_PMC_YOSEMITE) || defined(CONFIG_PMC_SEQUOIA) #define ICACHE_REFILLS_WORKAROUND_WAR 1 #endif +/* E9000 has a bug - The EntryHi register gets corrupt in some exceptional cases */ +#if defined(CONFIG_MOMENCO_JAGUAR_ATX) || defined(CONFIG_MOMENCO_OCELOT_3) || \ + defined(CONFIG_PMC_YOSEMITE) || defined(CONFIG_PMC_SEQUOIA) +#define E9000_ENTRYHI_WAR 1 +#endif + /* * ON the R10000 upto version 2.6 (not sure about 2.7) there is a bug that @@ -198,6 +204,9 @@ /* * Workarounds default to off */ +#ifndef E9000_ENTRYHI_WAR +#define E9000_ENTRYHI_WAR 0 +#endif #ifndef ICACHE_REFILLS_WORKAROUND_WAR #define ICACHE_REFILLS_WORKAROUND_WAR 0 #endif From Kiran_Thota@pmc-sierra.com Sat Jun 24 03:19:20 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 24 Jun 2006 03:19:48 +0100 (BST) Received: from father.pmc-sierra.com ([216.241.224.13]:28585 "HELO father.pmc-sierra.bc.ca") by ftp.linux-mips.org with SMTP id S8133862AbWFXCTU (ORCPT ); Sat, 24 Jun 2006 03:19:20 +0100 Received: (qmail 22716 invoked by uid 101); 24 Jun 2006 02:19:10 -0000 Received: from unknown (HELO ogyruan.pmc-sierra.bc.ca) (216.241.226.236) by father.pmc-sierra.com with SMTP; 24 Jun 2006 02:19:10 -0000 Received: from bby1exi01.pmc_nt.nt.pmc-sierra.bc.ca (bby1exi01.pmc-sierra.bc.ca [216.241.231.251]) by ogyruan.pmc-sierra.bc.ca (8.13.3/8.12.7) with ESMTP id k5O2JAo9012559; Fri, 23 Jun 2006 19:19:10 -0700 Received: by bby1exi01.pmc-sierra.bc.ca with Internet Mail Service (5.5.2656.59) id ; Fri, 23 Jun 2006 19:19:09 -0700 Message-ID: From: Kiran Thota To: linux-mips@linux-mips.org, netdev@vger.kernel.org Cc: Raj Palani , ralf@linux-mips.org Subject: [PATCH 6/6] PMC MSP85x0 gigabit ethernet driver Date: Fri, 23 Jun 2006 19:19:00 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11848 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: Kiran_Thota@pmc-sierra.com Precedence: bulk X-list: linux-mips - Based on linux-2.6.12 from http://www.linux-mips.org/pub/linux/mips/kernel/v2.6/linux-2.6.12.tar.gz - Rewritten clean driver for PMC MSP85x0 gigabit ethernet driver (planning a rewritten titan driver) \ source, Kconfig and makefile. Will remove dependency on TITAN_GE flag with future titan driver. Signed-off-by: Kiran Kumar Thota diff -Naur a/drivers/net/Kconfig b/drivers/net/Kconfig --- a/drivers/net/Kconfig 2005-07-11 11:28:10.000000000 -0700 +++ b/drivers/net/Kconfig 2006-06-22 11:48:21.000000000 -0700 @@ -2098,7 +2098,7 @@ config TITAN_GE bool "PMC-Sierra TITAN Gigabit Ethernet Support" - depends on PMC_YOSEMITE + depends on PMC_YOSEMITE || PMC_SEQUOIA help This enables support for the the integrated ethernet of PMC-Sierra's Titan SoC. diff -Naur a/drivers/net/Makefile b/drivers/net/Makefile --- a/drivers/net/Makefile 2005-07-11 11:28:10.000000000 -0700 +++ b/drivers/net/Makefile 2006-06-22 11:48:21.000000000 -0700 @@ -103,7 +103,8 @@ obj-$(CONFIG_GALILEO_64240_ETH) += gt64240eth.o obj-$(CONFIG_MV64340_ETH) += mv64340_eth.o obj-$(CONFIG_BIG_SUR_FE) += big_sur_ge.o -obj-$(CONFIG_TITAN_GE) += titan_mdio.o titan_ge.o +obj-$(CONFIG_PMC_SEQUOIA) += titan_mdio.o msp85x0_ge.o +#obj-$(CONFIG_TITAN_GE) += titan_mdio.o titan_ge.o obj-$(CONFIG_PPP) += ppp_generic.o slhc.o obj-$(CONFIG_PPP_ASYNC) += ppp_async.o diff -Naur a/drivers/net/msp85x0_ge.c b/drivers/net/msp85x0_ge.c --- a/drivers/net/msp85x0_ge.c 1969-12-31 16:00:00.000000000 -0800 +++ b/drivers/net/msp85x0_ge.c 2006-06-23 15:26:00.000000000 -0700 @@ -0,0 +1,2142 @@ +/* + * drivers/net/msp85x0_ge.c - Driver for MSP85x0 ethernet ports + * + * Copyright (C) 2006 PMC-Sierra Inc. + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License + * as published by the Free Software Foundation; either version 2 + * of the License, or (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA. + */ + +/* + * The MAC unit of the MSP85x0 consists of the following: + * + * -> XDMA Engine to move data to from the memory to the MAC packet FIFO + * -> FIFO is where the incoming and outgoing data is placed + * -> TRTG is the unit that pulls the data from the FIFO for Tx and pushes + * the data into the FIFO for Rx + * -> TMAC is the outgoing MAC interface and RMAC is the incoming. + * -> AFX is the address filtering block + * -> GMII block to communicate with the PHY + * + * Rx will look like the following: + * GMII --> RMAC --> AFX --> TRTG --> Rx FIFO --> XDMA --> CPU memory + * + * Tx will look like the following: + * CPU memory --> XDMA --> Tx FIFO --> TRTG --> TMAC --> GMII + * + * The MSP85x0 driver has support for the following performance features: + * -> Rx side checksumming + * -> Jumbo Frames + * -> Interrupt Coalscing + * -> Rx NAPI + * -> SKB Recycling + * -> Transmit/Receive descriptors in SRAM + * -> Fast routing for IP forwarding + * + * 19Apr2006 - Rewritten the code with functions modularized, + * hardcoding registers values removed, cleaned up the code + * to support only the msp85x0. The interrupt handler, + * poll function, descriptor freeing routine and close + * routines are modified. + * + */ + + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#include +#include +#include +#include +#include +#include +#include + +/* For MII specifc registers, msp85x0_mdio.h should be included */ +#include + +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#include "msp85x0_ge.h" +#include "titan_mdio.h" + +#ifdef MSP85x0_GE_DEBUG +#define GE_DBG(x,y) printk(KERN_DBG x , y) +#define DUMP_SKB_DATA(x) dump_skb_data(x) +#define DUMP_SKB_FRAME(x) dump_skb_frame(x) +#else +#define DUMP_SKB_DATA(x) +#define DUMP_SKB_FRAME(x) +#define GE_DBG(x,y) +#endif + +#define GET_GE_VERSION(x) (x & 0x0f000000) >> 16 +#define GET_GE_ID(x) (x & 0x00ffffff) +#define XDMA_PORT_OFFSET 9 +#define SQDPF_RX_PORT_OFFSET 0x60 +#define SQDPF_TX_PORT_OFFSET 0x0C +#define XDMA_CHANNEL_OFFSET 16 +#define NO_ADDRESS_FILTERS 16 +#define NO_PORTS 2 +#define INTERRUPT_HANDLER msp85x0_ge_sequoia_int_handler + +#define PKT_PAD_BYTES(x) ((x) | (x << 8) | ( x << 16) | (x << 24)) +#define TX_THRESHOLD 8 +#define RX_THRESHOLD 32 +#define TRTG2_PORT_OFFSET 12 +#define MAC_PORT_OFFSET 12 +#define MII_PORT_OFFSET 12 + + +#define TX_INT 2 +#define RX_INT 1 + +#define MSP85x0_GE_WRITE TITAN_GE_WRITE +#define MSP85x0_GE_READ TITAN_GE_READ + +#define ETHERNET_FCS_SIZE 4 + +#define DMA_CACHE_WBACK_INV(x,y) +#define IOMAP(x,y) ioremap_nocache((x),(y)) + +// Function declared in arch/mips/pmc-sierra/sequoia/setup.c +extern unsigned long titan_ge_base; + +extern unsigned long rm9150_dma_base; + +static spinlock_t msp85x0_lock; + +static unsigned int port0_pkt_count=0, port1_pkt_count=0; + +/* Static Function Declarations */ +static int msp85x0_ge_eth_open(struct net_device *); +static int msp85x0_ge_eth_reopen(struct net_device *netdev); +static void msp85x0_ge_eth_stop(struct net_device *); +static struct net_device_stats *msp85x0_ge_get_stats(struct net_device *); +static int msp85x0_ge_init_rx_desc_ring(msp85x0_ge_port_info *, int, int, + unsigned long, unsigned long, + unsigned long); +static int msp85x0_ge_init_tx_desc_ring(msp85x0_ge_port_info *, int, + unsigned long, unsigned long); + +static int msp85x0_ge_open(struct net_device *); +static int msp85x0_ge_start_xmit(struct sk_buff *, struct net_device *); +static int msp85x0_ge_stop(struct net_device *); + +static unsigned int msp85x0_ge_tx_coal(int); + +static void msp85x0_ge_port_reset(unsigned int); +static int msp85x0_ge_free_tx_queue(struct net_device *); +static int msp85x0_ge_rx_task(struct net_device *, msp85x0_ge_port_info *); +static int msp85x0_ge_port_start(struct net_device *); +static int msp85x0_eth_setup_tx_rx_fifo(struct net_device *dev); +static int msp85x0_ge_xdma_reset(void); + +/* + * Some configuration for the FIFO and the XDMA channel needs + * to be done only once for all the ports. This flag controls + * that + */ +static unsigned long config_done; + +/* + * One time out of memory flag + */ +static unsigned int oom_flag; + +static int msp85x0_ge_poll(struct net_device *netdev, int *budget); +static int msp85x0_ge_receive_queue(struct net_device *); + +static struct platform_device *msp85x0_ge_device[NO_PORTS]; +static struct net_device *msp85x0_eth[NO_PORTS]; +static unsigned int msp85x0_ge_sram; +static unsigned int port_number; + +/* + * The MSP85x0 GE has two alignment requirements: + * -> skb->data to be cacheline aligned (32 byte) + * -> IP header alignment to 16 bytes + * + * The latter is not implemented. So, that results in an extra copy on + * the Rx. This is a big performance hog. For the former case, the + * dev_alloc_skb() has been replaced with msp85x0_ge_alloc_skb(). The size + * requested is calculated: + * + * Ethernet Frame Size : 1518 + * Ethernet Header : 14 + * Future MSP85x0 change for IP header alignment : 2 + * + * Hence, we allocate (1518 + 14 + 2+ 64) = 1580 bytes. For IP header + * alignment, we use skb_reserve(). + */ +#define ALIGNED_RX_SKB_ADDR(addr) \ + ((((unsigned long)(addr) + (32UL - 1UL)) \ + & ~(32UL - 1UL)) - (unsigned long)(addr)) +#define msp85x0_ge_alloc_skb(__length, __gfp_flags) \ +({ struct sk_buff *__skb; \ + __skb = alloc_skb((__length),(__gfp_flags)); \ + if(__skb){ \ + int __offset = (int) ALIGNED_RX_SKB_ADDR(__skb->data); \ + if(__offset) \ + skb_reserve(__skb, __offset); \ + } \ + __skb; \ +}) + +int increment_tx_pkt_count(unsigned int port) +{ + unsigned int flags; + spin_lock_irqsave(&msp85x0_lock,flags); + if(port==0){ + port0_pkt_count++; + } + else{ + port1_pkt_count++; + } + spin_unlock_irqrestore(&msp85x0_lock,flags); + return 0; +} + +unsigned int get_tx_pkt_count(unsigned int port) +{ + unsigned int flags,pktCount,tx_pending_pkt; + spin_lock_irqsave(&msp85x0_lock,flags); + tx_pending_pkt=MSP85x0_GE_READ(MSP85x0_GE_CHANNEL0_TX_DMA_STS + (port << XDMA_PORT_OFFSET)); + if(port==0){ + pktCount=port0_pkt_count - tx_pending_pkt; + } + else{ + pktCount=port1_pkt_count - tx_pending_pkt; + } + spin_unlock_irqrestore(&msp85x0_lock,flags); + return pktCount; +} + +unsigned int decrement_tx_pkt_count(unsigned int port) +{ + unsigned int flags; + spin_lock_irqsave(&msp85x0_lock,flags); + if(port==0){ + port0_pkt_count--; + } + else{ + port1_pkt_count--; + } + spin_unlock_irqrestore(&msp85x0_lock,flags); + return 0; +} +void msp85x0_bringup_sequence(int port) +{ + unsigned int reg_data; + + /* SDQPF */ + reg_data=MSP85x0_GE_READ(MSP85x0_GE_SDQPF_RXFIFO_CTL + (port << 8)); + reg_data &=~(0x1); + MSP85x0_GE_WRITE(MSP85x0_GE_SDQPF_RXFIFO_CTL + (port << 8),reg_data); + /* TRTG */ + reg_data=MSP85x0_GE_READ(MSP85x0_GE_TRTG_CONFIG + (port << TRTG2_PORT_OFFSET)); + reg_data |=(0x1); + MSP85x0_GE_WRITE(MSP85x0_GE_TRTG_CONFIG + (port << TRTG2_PORT_OFFSET),reg_data); + /* GMII TX/RX DISABLE PORT 0 */ + reg_data=MSP85x0_GE_READ(MSP85x0_GE_GMII_CONFIG_GENERAL + (port << MAC_PORT_OFFSET)); + reg_data |=(0x3); + MSP85x0_GE_WRITE(MSP85x0_GE_GMII_CONFIG_GENERAL + (port << MAC_PORT_OFFSET),reg_data); + /* TMAC */ + reg_data=MSP85x0_GE_READ(MSP85x0_GE_TMAC_CONFIG_1 + (port << MAC_PORT_OFFSET)); + reg_data |=(0x1); + MSP85x0_GE_WRITE(MSP85x0_GE_TMAC_CONFIG_1 + (port << MAC_PORT_OFFSET),reg_data); + /* L1TPP */ + reg_data=MSP85x0_GE_READ(MSP85x0_GE_L1TPP_CONFIG + (port << MAC_PORT_OFFSET)); + reg_data &=~(0x1); + MSP85x0_GE_WRITE(MSP85x0_GE_L1TPP_CONFIG + (port << MAC_PORT_OFFSET),reg_data); + /* L1RPP */ + reg_data=MSP85x0_GE_READ(MSP85x0_GE_L1RPP_CONFIG_STS+ (port << MAC_PORT_OFFSET)); + reg_data &=~(0x1); + MSP85x0_GE_WRITE(MSP85x0_GE_L1RPP_CONFIG_STS + (port << MAC_PORT_OFFSET),reg_data); + /* RTIF */ + reg_data=MSP85x0_GE_READ(MSP85x0_GE_RTIF_CONFIG + (port << MAC_PORT_OFFSET)); + reg_data |=(0x4000); + MSP85x0_GE_WRITE(MSP85x0_GE_RTIF_CONFIG + (port << MAC_PORT_OFFSET),reg_data); + /* RMAC */ + reg_data=MSP85x0_GE_READ(MSP85x0_GE_RMAC_CONFIG_1+ (port << MAC_PORT_OFFSET)); + reg_data |=(0x1); + MSP85x0_GE_WRITE(MSP85x0_GE_RMAC_CONFIG_1+ (port << MAC_PORT_OFFSET),reg_data); +} + +void msp85x0_reset_sequence(int port) +{ + unsigned int reg_data; + /* RMAC */ + reg_data=MSP85x0_GE_READ(MSP85x0_GE_RMAC_CONFIG_1+ (port << MAC_PORT_OFFSET)); + reg_data &=~(0x1); + MSP85x0_GE_WRITE(MSP85x0_GE_RMAC_CONFIG_1+ (port << MAC_PORT_OFFSET),reg_data); + /* RTIF */ + reg_data=MSP85x0_GE_READ(MSP85x0_GE_RTIF_CONFIG + (port << MAC_PORT_OFFSET)); + reg_data &=~(0x4000); + MSP85x0_GE_WRITE(MSP85x0_GE_RTIF_CONFIG + (port << MAC_PORT_OFFSET),reg_data); + /* L1RPP */ + reg_data=MSP85x0_GE_READ(MSP85x0_GE_L1RPP_CONFIG_STS+ (port << MAC_PORT_OFFSET)); + reg_data &=~(0x1); + MSP85x0_GE_WRITE(MSP85x0_GE_L1RPP_CONFIG_STS + (port << MAC_PORT_OFFSET),reg_data); + /* L1TPP */ + reg_data=MSP85x0_GE_READ(MSP85x0_GE_L1TPP_CONFIG + (port << MAC_PORT_OFFSET)); + reg_data &=~(0x1); + MSP85x0_GE_WRITE(MSP85x0_GE_L1TPP_CONFIG + (port << MAC_PORT_OFFSET),reg_data); + /* TMAC */ + reg_data=MSP85x0_GE_READ(MSP85x0_GE_TMAC_CONFIG_1 + (port << MAC_PORT_OFFSET)); + reg_data &=~(0x1); + MSP85x0_GE_WRITE(MSP85x0_GE_TMAC_CONFIG_1 + (port << MAC_PORT_OFFSET),reg_data); + /* GMII TX/RX DISABLE PORT 0 */ + reg_data=MSP85x0_GE_READ(MSP85x0_GE_GMII_CONFIG_GENERAL + (port << MAC_PORT_OFFSET)); + reg_data &=~(0x3); + MSP85x0_GE_WRITE(MSP85x0_GE_GMII_CONFIG_GENERAL + (port << MAC_PORT_OFFSET),reg_data); + /* TRTG */ + reg_data=MSP85x0_GE_READ(MSP85x0_GE_TRTG_CONFIG + (port << TRTG2_PORT_OFFSET)); + reg_data &=~(0x1); + MSP85x0_GE_WRITE(MSP85x0_GE_TRTG_CONFIG + (port << TRTG2_PORT_OFFSET),reg_data); + /* SDQPF */ + reg_data=MSP85x0_GE_READ(MSP85x0_GE_SDQPF_RXFIFO_CTL + (port << 8)); + reg_data |=0x1; + MSP85x0_GE_WRITE(MSP85x0_GE_SDQPF_RXFIFO_CTL + (port << 8),reg_data); + reg_data &=~(0x1); + MSP85x0_GE_WRITE(MSP85x0_GE_SDQPF_RXFIFO_CTL + (port << 8),reg_data); +} + +static int msp85x0_ge_xdma_reset() +{ + unsigned int reg_data; + + reg_data = MSP85x0_GE_READ(MSP85x0_GE_RESET); + reg_data |= 1 << (8); + MSP85x0_GE_WRITE(MSP85x0_GE_RESET,reg_data); + mdelay(50); + reg_data &= ~(1 << 8); + MSP85x0_GE_WRITE(MSP85x0_GE_RESET,reg_data); + return 0; +} + +/* + * Configure the GMII block of the MSP85x0 based on what the PHY tells us + */ +static void msp85x0_ge_gmii_config(int port_num) +{ + unsigned int reg_data = 0, phy_reg; + int err; + + err = titan_ge_mdio_read(port_num, TITAN_GE_MDIO_PHY_STATUS, &phy_reg); + + if (err == TITAN_GE_MDIO_ERROR) { + printk(KERN_ERR + "Could not read PHY control register 0x11 \n"); + + printk(KERN_ERR + "Setting speed to 1000 Mbps and Duplex to Full \n"); + + return; + } + + err = titan_ge_mdio_write(port_num, TITAN_GE_MDIO_PHY_IE, 0); + + if (phy_reg & 0x8000) { + if (phy_reg & 0x2000) { + /* Full Duplex and 1000 Mbps */ + MSP85x0_GE_WRITE((MSP85x0_GE_GMII_CONFIG_MODE + + (port_num << MII_PORT_OFFSET)), 0x201); + } else { + /* Half Duplex and 1000 Mbps */ + MSP85x0_GE_WRITE((MSP85x0_GE_GMII_CONFIG_MODE + + (port_num << MII_PORT_OFFSET)), 0x2201); + } + } + if (phy_reg & 0x4000) { + if (phy_reg & 0x2000) { + /* Full Duplex and 100 Mbps */ + MSP85x0_GE_WRITE((MSP85x0_GE_GMII_CONFIG_MODE + + (port_num << MII_PORT_OFFSET)), 0x100); + } else { + /* Half Duplex and 100 Mbps */ + MSP85x0_GE_WRITE((MSP85x0_GE_GMII_CONFIG_MODE + + (port_num << MII_PORT_OFFSET)), 0x2100); + } + } + reg_data = MSP85x0_GE_READ(MSP85x0_GE_GMII_CONFIG_GENERAL + + (port_num << MII_PORT_OFFSET)); + reg_data |= 0x3; + MSP85x0_GE_WRITE((MSP85x0_GE_GMII_CONFIG_GENERAL + + (port_num << MII_PORT_OFFSET)), reg_data); +} + +/* + * Enable the TMAC if it is not + */ +static void msp85x0_ge_enable_tx(unsigned int port_num) +{ + unsigned long reg_data; + + reg_data = MSP85x0_GE_READ(MSP85x0_GE_TMAC_CONFIG_1 + (port_num << MAC_PORT_OFFSET)); + if (!(reg_data & 0x8000)) { + printk("TMAC disabled for port %d!! \n", port_num); + + reg_data |= 0x0001; /* Enable TMAC */ + reg_data |= 0x4000; /* CRC Check Enable */ + reg_data |= 0x2000; /* Padding enable */ + reg_data |= 0x0800; /* CRC Add enable */ + //reg_data |= 0x0080; /* PAUSE frame */ + + MSP85x0_GE_WRITE((MSP85x0_GE_TMAC_CONFIG_1 + + (port_num << MAC_PORT_OFFSET)), reg_data); + } +} + +/* + * Tx Timeout function + */ +static void msp85x0_ge_tx_timeout(struct net_device *netdev) +{ + msp85x0_ge_port_info *msp85x0_ge_eth = netdev_priv(netdev); + + printk(KERN_INFO "%s: TX timeout ", netdev->name); + printk(KERN_INFO "Resetting card \n"); + + /* Do the reset outside of interrupt context */ + schedule_work(&msp85x0_ge_eth->tx_timeout_task); +} + +/* + * Update the AFX tables for UC and MC for slice 0 only + */ +static void msp85x0_ge_update_afx(msp85x0_ge_port_info * msp85x0_ge_eth) +{ + int port = msp85x0_ge_eth->port_num; + unsigned int i; + volatile unsigned long reg_data = 0; + u8 p_addr[6]; + + memcpy(p_addr, msp85x0_ge_eth->port_mac_addr, 6); + + /* Set the MAC address here for TMAC and RMAC */ + MSP85x0_GE_WRITE((MSP85x0_GE_TMAC_STATION_HI + (port << MAC_PORT_OFFSET)), + ((p_addr[5] << 8) | p_addr[4])); + MSP85x0_GE_WRITE((MSP85x0_GE_TMAC_STATION_MID + (port << MAC_PORT_OFFSET)), + ((p_addr[3] << 8) | p_addr[2])); + MSP85x0_GE_WRITE((MSP85x0_GE_TMAC_STATION_LOW + (port << MAC_PORT_OFFSET)), + ((p_addr[1] << 8) | p_addr[0])); + + MSP85x0_GE_WRITE((MSP85x0_GE_RMAC_STATION_HI + (port << MAC_PORT_OFFSET)), + ((p_addr[5] << 8) | p_addr[4])); + MSP85x0_GE_WRITE((MSP85x0_GE_RMAC_STATION_MID + (port << MAC_PORT_OFFSET)), + ((p_addr[3] << 8) | p_addr[2])); + MSP85x0_GE_WRITE((MSP85x0_GE_RMAC_STATION_LOW + (port << MAC_PORT_OFFSET)), + ((p_addr[1] << 8) | p_addr[0])); + + /* Configure the eight address filters */ + + /* Select first filter to match our address */ + MSP85x0_GE_WRITE((MSP85x0_GE_AFX_ADDRS_FILTER_CTRL_2 + + (port << MAC_PORT_OFFSET)), 0); + wmb(); + /* Configure the match */ + reg_data = 0x9; /* Forward Enable Bit */ + MSP85x0_GE_WRITE((MSP85x0_GE_AFX_ADDRS_FILTER_CTRL_0 + + (port << MAC_PORT_OFFSET)), reg_data); + + /* Finally, AFX Exact Match Address Registers */ + MSP85x0_GE_WRITE((MSP85x0_GE_AFX_EXACT_MATCH_LOW + (port << MAC_PORT_OFFSET)), + ((p_addr[1] << 8) | p_addr[0])); + MSP85x0_GE_WRITE((MSP85x0_GE_AFX_EXACT_MATCH_MID + (port << MAC_PORT_OFFSET)), + ((p_addr[3] << 8) | p_addr[2])); + MSP85x0_GE_WRITE((MSP85x0_GE_AFX_EXACT_MATCH_HIGH + (port << MAC_PORT_OFFSET)), + ((p_addr[5] << 8) | p_addr[4])); + + /* VLAN id set to 0 */ + MSP85x0_GE_WRITE((MSP85x0_GE_AFX_EXACT_MATCH_VID + + (port << MAC_PORT_OFFSET)), 0); + wmb(); + + MSP85x0_GE_WRITE((MSP85x0_GE_AFX_ADDRS_FILTER_CTRL_3 | (port << MAC_PORT_OFFSET)), 0x1); + + for (i = 1; i < NO_ADDRESS_FILTERS; i++) { + /* Select each of the eight filters */ + MSP85x0_GE_WRITE((MSP85x0_GE_AFX_ADDRS_FILTER_CTRL_2 + + (port << MAC_PORT_OFFSET)), i); + + /* Configure the match */ + reg_data = 0x0; /* Disable filter */ + MSP85x0_GE_WRITE((MSP85x0_GE_AFX_ADDRS_FILTER_CTRL_0 + + (port << MAC_PORT_OFFSET)), reg_data); + + MSP85x0_GE_WRITE((MSP85x0_GE_AFX_ADDRS_FILTER_CTRL_3 | (port << MAC_PORT_OFFSET)), 0); + + } +} + +/* + * Actual Routine to reset the adapter when the timeout occurred + */ + +static void msp85x0_ge_tx_timeout_task(struct net_device *netdev) +{ + msp85x0_ge_port_info *msp85x0_ge_eth = netdev_priv(netdev); + int port = msp85x0_ge_eth->port_num; + + printk("MSP85x0 GE: Transmit timed out. Resetting ... \n"); + + /* Dump debug info */ + printk(KERN_ERR "TRTG cause : %x \n", + MSP85x0_GE_READ(MSP85x0_GE_TRTG2_INTERRUPT_IND + (port << TRTG2_PORT_OFFSET))); + + /* Fix this for the other ports */ + printk(KERN_ERR "FIFO cause : %x \n", MSP85x0_GE_READ(MSP85x0_GE_SDQPF_RXFIFO_INTR)); + printk(KERN_ERR "IE cause : %x \n", MSP85x0_GE_READ(MSP85x0_GE_INTR_GRP0_STATUS)); + printk(KERN_ERR "XDMA GDI ERROR : %x \n", + MSP85x0_GE_READ(MSP85x0_GE_GXDMA_INT_STS + (port << XDMA_PORT_OFFSET))); + printk(KERN_ERR "CHANNEL ERROR: %x \n",MSP85x0_GE_READ(MSP85x0_GE_CHANNEL0_INTERRUPT + + (port << XDMA_PORT_OFFSET))); + + netif_device_detach(netdev); + msp85x0_ge_port_reset(msp85x0_ge_eth->port_num); + msp85x0_ge_port_start(netdev); + netif_device_attach(netdev); +} + +/* + * Change the MTU of the Ethernet Device + */ +static int msp85x0_ge_change_mtu(struct net_device *netdev, int new_mtu) +{ + msp85x0_ge_port_info *msp85x0_ge_eth = netdev_priv(netdev); + unsigned long flags; +#ifdef MSP85x0_GE_JUMBO_FRAMES + if ((new_mtu > 9500) || (new_mtu < 64)) + return -EINVAL; +#else + if ((new_mtu > 1518) || (new_mtu < 64)) + return -EINVAL; +#endif + spin_lock_irqsave(&msp85x0_ge_eth->lock, flags); + + netdev->mtu = new_mtu; + /* Now we have to reopen the interface so that SKBs with the new + * size will be allocated */ + if (netif_running(netdev)) { + msp85x0_ge_eth_stop(netdev); + MSP85x0_GE_WRITE((MSP85x0_GE_RMAC_MAX_FRAME_LEN + (msp85x0_ge_eth->port_num << MAC_PORT_OFFSET)), new_mtu + 2); // for the padded bytes + + if (msp85x0_ge_eth_reopen(netdev) != 0) { + printk(KERN_ERR + "%s: Fatal error on opening device\n", + netdev->name); + spin_unlock_irqrestore(&msp85x0_ge_eth->lock, flags); + return -1; + } + } + spin_unlock_irqrestore(&msp85x0_ge_eth->lock, flags); + return 0; +} + +static int handle_phy_interrupt(struct net_device *netdev) +{ + msp85x0_ge_port_info *msp85x0_ge_eth = netdev_priv(netdev); + unsigned int port_num = msp85x0_ge_eth->port_num; + unsigned int err,reg_data; + + err =titan_ge_mdio_read(port_num,TITAN_GE_MDIO_PHY_IS, ®_data); + if (reg_data & 0x0400) { + /* Link status change */ + titan_ge_mdio_read(port_num,TITAN_GE_MDIO_PHY_STATUS, ®_data); + if (!(reg_data & 0x0400)) { + /* Link is down */ + netif_carrier_off(netdev); + netif_stop_queue(netdev); + } else { + /* Link is up */ + netif_carrier_on(netdev); + netif_wake_queue(netdev); + /* Enable the queue */ + msp85x0_ge_enable_tx(port_num); + } + } + return 0; +} + +static int handle_error_interrupts(unsigned int cause,unsigned char shift,unsigned int port_num) +{ + /* Handle error interrupts */ + if (cause && (cause != 0x2)) { + printk(KERN_ERR"XDMA Channel Error : %x on port %d\n", + cause, port_num); + printk(KERN_ERR"XDMA GDI Hardware error : %x on port %d\n", + MSP85x0_GE_READ(MSP85x0_GE_GXDMA_INT_STS + (port_num << shift)), port_num); + printk(KERN_ERR"XDMA currently has %d Rx descriptors \n", + MSP85x0_GE_READ(MSP85x0_GE_CHANNEL0_RX_DMA_STS + (port_num << shift))); + printk(KERN_ERR + "XDMA currently has prefetcted %d Rx descriptors \n", + MSP85x0_GE_READ(MSP85x0_GE_GXDMA0_DESC_PREFETCH_CNT + (port_num << shift))); + MSP85x0_GE_WRITE((MSP85x0_GE_CHANNEL0_INTERRUPT + + (port_num << shift)), cause); + } + return 0; +} + + +/* + * Enable the Tx & Rx side interrupts + */ +static void msp85x0_ge_enable_rx_int(unsigned int port) +{ + unsigned long reg_data = MSP85x0_GE_READ(MSP85x0_GE_INTR_XDMA_IE); + reg_data |=(RX_INT << (XDMA_CHANNEL_OFFSET * port)); + MSP85x0_GE_WRITE(MSP85x0_GE_INTR_XDMA_IE, reg_data); +} +/* + * Disable the Tx & Rx side interrupts + */ +static void msp85x0_ge_disable_rx_int(unsigned int port) +{ + unsigned long reg_data = MSP85x0_GE_READ(MSP85x0_GE_INTR_XDMA_IE); + reg_data &=~(RX_INT << (XDMA_CHANNEL_OFFSET * port)); + MSP85x0_GE_WRITE(MSP85x0_GE_INTR_XDMA_IE, reg_data); +} + +static void clear_xdma_interrupts(unsigned int port,unsigned int tx_rx) +{ + MSP85x0_GE_WRITE(MSP85x0_GE_INTR_XDMA_CORE_A,tx_rx << (XDMA_CHANNEL_OFFSET * port)); +} +/* + * MSP85x0 Gbe Interrupt Handler. All the three ports send interrupt to one line + * only. Once an interrupt is triggered, figure out the port and then check + * the Interrupt channel. + */ +static irqreturn_t msp85x0_ge_sequoia_int_handler(int irq, void *dev_id, + struct pt_regs *regs) +{ + struct net_device *netdev = (struct net_device *) dev_id; + msp85x0_ge_port_info *msp85x0_ge_eth = netdev_priv(netdev); + unsigned int port_num = msp85x0_ge_eth->port_num; + unsigned int eth_int_cause_error = 0, is; + unsigned long eth_int_cause1,eth_rx_ood_error; + unsigned long flags; + + spin_lock_irqsave(&msp85x0_ge_eth->lock, flags); + /* Ack the CPU interrupt */ + is=*(volatile unsigned int *)(RM9150_DMA_DCR + 0x8000 + RM9150_GCIC_INT3_STATUS); + *(volatile unsigned int *)(RM9150_DMA_DCR + 0x8000 + RM9150_GCIC_INT3_CLEAR)=is; + + eth_int_cause1 = MSP85x0_GE_READ(MSP85x0_GE_INTR_XDMA_CORE_A); + if (eth_int_cause1 == 0) { + eth_int_cause_error = MSP85x0_GE_READ(MSP85x0_GE_CHANNEL0_INTERRUPT + + (port_num << 9)); + if (eth_int_cause_error == 0) + { + spin_unlock_irqrestore(&msp85x0_ge_eth->lock, flags); + return IRQ_NONE; + } + + } + /* Handle the Rx next */ + if (eth_int_cause1 & (RX_INT << (port_num * 16))) { + clear_xdma_interrupts(port_num,RX_INT); + if (netif_rx_schedule_prep(netdev)) { + msp85x0_ge_disable_rx_int(port_num); + __netif_rx_schedule(netdev); + + } + } + /* Handle error interrupts */ + handle_error_interrupts(eth_int_cause_error,9,port_num); + + /* Handle Rx OOD */ + eth_rx_ood_error = MSP85x0_GE_READ(MSP85x0_GE_CHANNEL0_INTERRUPT + (port_num << 9)); + if(eth_rx_ood_error & 0x2) + { + if (netif_rx_schedule_prep(netdev)){ + msp85x0_ge_disable_rx_int(port_num); + __netif_rx_schedule(netdev); + } + } + + /* + * PHY interrupt to inform abt the changes. Reading the + * PHY Status register will clear the interrupt + */ + if ((!(eth_int_cause1 & (0x3 << (port_num * 16)))) && + (eth_int_cause_error == 0)) { + handle_phy_interrupt(netdev); + } + spin_unlock_irqrestore(&msp85x0_ge_eth->lock, flags); + return IRQ_HANDLED; +} +/* + * Multicast and Promiscuous mode set. The + * set_multi entry point is called whenever the + * multicast address list or the network interface + * flags are updated. + */ +static void msp85x0_ge_set_multi(struct net_device *netdev) +{ + msp85x0_ge_port_info *msp85x0_ge_eth = netdev_priv(netdev); + unsigned int port_num = msp85x0_ge_eth->port_num; + unsigned long reg_data; + + reg_data = MSP85x0_GE_READ(MSP85x0_GE_AFX_ADDRS_FILTER_CTRL_1 + + (port_num << MAC_PORT_OFFSET)); + + if (netdev->flags & IFF_PROMISC) { + reg_data |= 0x2; + } + else if (netdev->flags & IFF_ALLMULTI) { + reg_data |= 0x01; + reg_data |= 0x400; /* Use the 64-bit Multicast Hash bin */ + } + else { + reg_data = 0x2; + } + + MSP85x0_GE_WRITE((MSP85x0_GE_AFX_ADDRS_FILTER_CTRL_1 + + (port_num << MAC_PORT_OFFSET)), reg_data); + if (reg_data & 0x01) { + MSP85x0_GE_WRITE((MSP85x0_GE_AFX_MULTICAST_HASH_LOW + + (port_num << MAC_PORT_OFFSET)), 0xffff); + MSP85x0_GE_WRITE((MSP85x0_GE_AFX_MULTICAST_HASH_MIDLOW + + (port_num << MAC_PORT_OFFSET)), 0xffff); + MSP85x0_GE_WRITE((MSP85x0_GE_AFX_MULTICAST_HASH_MIDHI + + (port_num << MAC_PORT_OFFSET)), 0xffff); + MSP85x0_GE_WRITE((MSP85x0_GE_AFX_MULTICAST_HASH_HI + + (port_num << MAC_PORT_OFFSET)), 0xffff); + } +} + +/* + * Open the network device + */ +static int msp85x0_ge_open(struct net_device *netdev) +{ + msp85x0_ge_port_info *msp85x0_ge_eth = netdev_priv(netdev); + unsigned int port_num = msp85x0_ge_eth->port_num; + unsigned int irq; + int retval; + + spin_lock_irq(&(msp85x0_ge_eth->lock)); + + if (msp85x0_ge_eth_open(netdev) != MSP85x0_OK) { + spin_unlock_irq(&(msp85x0_ge_eth->lock)); + printk("%s: Error opening interface \n", netdev->name); + free_irq(netdev->irq, netdev); + return -EBUSY; + } + + spin_unlock_irq(&(msp85x0_ge_eth->lock)); + + irq = MSP85x0_ETH_PORT_IRQ; + + retval = request_irq(irq, INTERRUPT_HANDLER, + SA_SAMPLE_RANDOM | SA_SHIRQ, netdev->name, netdev); + + if (retval != 0) { + printk(KERN_ERR "Cannot assign IRQ number to MSP85x0 GE \n"); + return -1; + } + + netdev->irq = irq; + printk(KERN_INFO "Assigned IRQ %d to port %d\n", irq, port_num); + + return 0; +} + +/* + * Allocate the SKBs for the Rx ring. Also used + * for refilling the queue + */ + +static int msp85x0_ge_rx_task(struct net_device *netdev, + msp85x0_ge_port_info *msp85x0_ge_eth) +{ + struct device *device = &msp85x0_ge_device[msp85x0_ge_eth->port_num]->dev; + volatile msp85x0_ge_rx_desc *rx_desc; + struct sk_buff *skb; + int rx_used_desc; + int count = 0; + oom_flag=0; + while (msp85x0_ge_eth->rx_ring_skbs < msp85x0_ge_eth->rx_ring_size) { + /* First try to get the skb from the recycler */ + skb = msp85x0_ge_alloc_skb(MSP85x0_GE_RX_BUFSIZE, GFP_ATOMIC); + if (unlikely(!skb)) { + /* OOM, set the flag */ + oom_flag = 1; + break; + } + count++; + skb->dev = netdev; + msp85x0_ge_eth->rx_ring_skbs++; + rx_used_desc = msp85x0_ge_eth->rx_used_desc_q; + rx_desc = &(msp85x0_ge_eth->rx_desc_area[rx_used_desc]); + rx_desc->buffer_addr = dma_map_single(device, skb->data, + MSP85x0_GE_RX_BUFSIZE - 2, DMA_FROM_DEVICE); + msp85x0_ge_eth->rx_skb[rx_used_desc] = skb; + rx_desc->cmd_sts = MSP85x0_GE_RX_BUFFER_OWNED; + DMA_CACHE_WBACK_INV((unsigned long)rx_desc,sizeof(msp85x0_ge_rx_desc)); + if((rx_used_desc + 1) == MSP85x0_GE_RX_QUEUE) + msp85x0_ge_eth->rx_used_desc_q =0; + else + msp85x0_ge_eth->rx_used_desc_q = (rx_used_desc + 1); + } + return count; +} + +/* + * Actual init of the Tital GE port. There is one register for + * the channel configuration + */ +static void msp85x0_port_init(struct net_device *netdev, + msp85x0_ge_port_info * msp85x0_ge_eth) +{ + unsigned long reg_data; + unsigned int port_num; + + port_num = msp85x0_ge_eth->port_num; + for (port_num = 0; port_num < NO_PORTS; port_num++) + { + msp85x0_ge_port_reset(port_num); + + /* First reset the TMAC */ + reg_data = MSP85x0_GE_READ(MSP85x0_GE_CHANNEL0_CONFIG + (port_num << XDMA_PORT_OFFSET)); + reg_data |= XDMA_TMAC_RESET; + MSP85x0_GE_WRITE(MSP85x0_GE_CHANNEL0_CONFIG + (port_num << XDMA_PORT_OFFSET), reg_data); + /* RMAC */ + reg_data = MSP85x0_GE_READ(MSP85x0_GE_CHANNEL0_CONFIG + (port_num << XDMA_PORT_OFFSET)); + reg_data |= XDMA_RMAC_RESET; + MSP85x0_GE_WRITE(MSP85x0_GE_CHANNEL0_CONFIG + (port_num << XDMA_PORT_OFFSET), reg_data); + } +} + +static int start_tx_and_rx_activity(struct net_device *netdev) +{ + msp85x0_ge_port_info *msp85x0_ge_eth = netdev_priv(netdev); + unsigned int port_num = msp85x0_ge_eth->port_num; + unsigned int reg_data; + + MSP85x0_GE_WRITE((MSP85x0_GE_TMAC_CONFIG_2 + (port_num << MAC_PORT_OFFSET)), 0xe1b7); +#ifdef MSP85x0_GE_JUMBO_FRAMES + MSP85x0_GE_WRITE((MSP85x0_GE_TMAC_MAX_FRAME_LEN + (port_num << MAC_PORT_OFFSET)), 0x4000); +#endif + reg_data = MSP85x0_GE_READ(MSP85x0_GE_TMAC_CONFIG_1 + (port_num << MAC_PORT_OFFSET)); + reg_data |= (0x0001 << 14); /* CRC Check Enable */ + reg_data |= (0x0002 << 12); /* Padding enable */ + reg_data |= (0x0001 << 11); /* CRC Add enable */ + reg_data |= (0x0001 << 10); /* Min. frame length check */ + reg_data |= (0x0001 << 6); /* Pause, if FIFO full */ + reg_data &=~(0x0001 << 6); /* Disable pause frame */ + reg_data |= (0x0001 << 5); /* Send XON */ + reg_data |= (0x0001 << 4); /* Stop on XOFF */ + reg_data |= (0x0001 << 0); /* Enable TMAC */ + + MSP85x0_GE_WRITE((MSP85x0_GE_TMAC_CONFIG_1 + (port_num << MAC_PORT_OFFSET)), reg_data); + udelay(30); + + /* Destination Address drop bit */ + reg_data = MSP85x0_GE_READ(MSP85x0_GE_RMAC_CONFIG_2 + (port_num << MAC_PORT_OFFSET)); + reg_data |= 0x109; /* DA_DROP bit and pause */ + MSP85x0_GE_WRITE((MSP85x0_GE_RMAC_CONFIG_2 + (port_num << MAC_PORT_OFFSET)), reg_data); + MSP85x0_GE_WRITE((MSP85x0_GE_RMAC_LINK_CONFIG + (port_num << MAC_PORT_OFFSET)), 0x3); +#ifdef MSP85x0_GE_JUMBO_FRAMES + MSP85x0_GE_WRITE((MSP85x0_GE_RMAC_MAX_FRAME_LEN + (port_num << MAC_PORT_OFFSET)), 0x4000); +#endif + /* Start the Rx activity */ + reg_data = MSP85x0_GE_READ(MSP85x0_GE_RMAC_CONFIG_1 + (port_num << MAC_PORT_OFFSET)); + reg_data |= (0x0001 << 14); /* Preamble check enable */ + reg_data |= (0x0001 << 13); /* VLAN tag aware */ + reg_data |= (0x0003 << 10); /* in-range length checking */ + reg_data |= (0x0001 << 8); /* Max frame discard */ + reg_data |= (0x0001 << 7); /* Max frame check enable */ + reg_data |= (0x0001 << 6); /* Min frame discard */ + reg_data |= (0x0001 << 5); /* Min frame check enable */ + reg_data |= (0x0001 << 4); /* CRC discard */ + reg_data |= (0x0001 << 3); /* CRC check enable */ + reg_data |= (0x0001 << 1); /* reserved */ + reg_data |= (0x0001 << 0); /* RMAC Enable */ + MSP85x0_GE_WRITE((MSP85x0_GE_RMAC_CONFIG_1 + (port_num << MAC_PORT_OFFSET)), reg_data); + udelay(30); + return 0; +} + +static int trtg_block_enable(struct net_device *netdev) +{ + msp85x0_ge_port_info *msp85x0_ge_eth = netdev_priv(netdev); + unsigned int port_num = msp85x0_ge_eth->port_num; + unsigned int reg_data; + + /* + * Step 3: TRTG block enable + */ + reg_data = MSP85x0_GE_READ(MSP85x0_GE_TRTG_CONFIG + (port_num << TRTG2_PORT_OFFSET)); + reg_data &= ~1; + MSP85x0_GE_WRITE((MSP85x0_GE_TRTG_CONFIG + (port_num << TRTG2_PORT_OFFSET)), reg_data); + + reg_data = PKT_PAD_BYTES(2); + MSP85x0_GE_WRITE((MSP85x0_GE_TRTG_BYTE_OFFSET_0 + (port_num << TRTG2_PORT_OFFSET)), reg_data); + MSP85x0_GE_WRITE((MSP85x0_GE_TRTG_BYTE_OFFSET_1 + (port_num << TRTG2_PORT_OFFSET)), reg_data); + mdelay(5); + + /* Priority */ + reg_data = MSP85x0_GE_READ(MSP85x0_GE_TRTG_PRIORITY_CHKSUM + (port_num << TRTG2_PORT_OFFSET)); + reg_data &= ~(0x00f00000); + reg_data |= (14 << 8); + MSP85x0_GE_WRITE((MSP85x0_GE_TRTG_PRIORITY_CHKSUM + (port_num << TRTG2_PORT_OFFSET)), reg_data); + + reg_data = MSP85x0_GE_READ(MSP85x0_GE_TRTG_CONFIG + (port_num << TRTG2_PORT_OFFSET)); + reg_data |= 0x0001; + MSP85x0_GE_WRITE((MSP85x0_GE_TRTG_CONFIG + (port_num << TRTG2_PORT_OFFSET)), reg_data); + return 0; +} + + +static int enable_tx_and_rx_interrupts(struct net_device *netdev) +{ + msp85x0_ge_port_info *msp85x0_ge_eth = netdev_priv(netdev); + unsigned int port_num = msp85x0_ge_eth->port_num; + unsigned int reg_data; + + if (config_done == 0) { + /* XD_OOD_INTSMSG = 0x61, XD_INTSMSG = 0x62 + XD_RX_INTSMSG = 0x60, XD_TX_INTSMSG = 0x60 */ + MSP85x0_GE_WRITE(MSP85x0_GE_CPIF2_INT_MSG_ADDR0,(RM9150_GCIC_BASE + RM9150_GCIC_INTMSG) >> 4); + reg_data = 0x61626060; + MSP85x0_GE_WRITE(MSP85x0_GE_CPIF2_SET_VECTOR_MSG0, reg_data); + reg_data = MSP85x0_GE_READ(MSP85x0_GE_CPIF2_INT_VECOTR_MODE0); + reg_data |= 0x1; + MSP85x0_GE_WRITE(MSP85x0_GE_CPIF2_INT_VECOTR_MODE0, reg_data); + } + + /* + * Enable the Interrupts for Rx + */ + reg_data = MSP85x0_GE_READ(MSP85x0_GE_INTR_XDMA_IE); + reg_data |= (RX_INT << (port_num * XDMA_CHANNEL_OFFSET)); + MSP85x0_GE_WRITE(MSP85x0_GE_INTR_XDMA_IE, reg_data); + + return 0; +} + + +static int get_ring_count(unsigned int count) +{ + unsigned int ring_size; + switch(count) + { + case 1: + ring_size=0;break; + case 2: + ring_size=1;break; + case 4: + ring_size=2;break; + case 8: + ring_size=3;break; + case 16: + ring_size=4;break; + default: + ring_size=0;break; + } + return ring_size; +} + +static int get_rx_buff_size(unsigned int size) +{ + unsigned int buff_size; + switch(size) + { + case 1: + buff_size=0;break; + case 2: + buff_size=1;break; + case 4: + buff_size=2;break; + case 8: + buff_size=3;break; + case 16: + buff_size=4;break; + case 32: + buff_size=5;break; + default: + buff_size=0;break; + } + return buff_size; +} + +static int xdma_config(struct net_device *netdev) +{ + volatile unsigned long reg_data; + msp85x0_ge_port_info *msp85x0_ge_eth = netdev_priv(netdev); + int port_num = msp85x0_ge_eth->port_num; + unsigned int count = 0,rx_ring,tx_ring; + + if (config_done == 0) { + reg_data = MSP85x0_GE_READ(MSP85x0_GE_XDMA_CONFIG); + reg_data &= ~(0x80000000); /* clear reset */ + reg_data |= (0x1 << 29); /* sparse tx descriptor spacing */ + reg_data |= (0x1 << 28); /* sparse rx descriptor spacing */ + /* No support for coherency. Has to be cleared */ + reg_data &= ~(0x8000); /* Disable the write back */ + reg_data &=~(0x1E00000); + MSP85x0_GE_WRITE(MSP85x0_GE_XDMA_CONFIG, reg_data); + } + + msp85x0_ge_eth->tx_threshold = 0; + msp85x0_ge_eth->rx_threshold = 0; + + /* We need to write the descriptors for Tx and Rx */ + MSP85x0_GE_WRITE((MSP85x0_GE_CHANNEL0_TX_DESC + (port_num << XDMA_PORT_OFFSET)), + (unsigned long) msp85x0_ge_eth->tx_dma); + MSP85x0_GE_WRITE((MSP85x0_GE_CHANNEL0_RX_DESC + (port_num << XDMA_PORT_OFFSET)), + (unsigned long) msp85x0_ge_eth->rx_dma); + + /* IR register for the XDMA */ + reg_data = MSP85x0_GE_READ(MSP85x0_GE_GDI_INTERRUPT_ENABLE + (port_num << XDMA_PORT_OFFSET)); + reg_data |= 0xF006C000; /* No Rx_OOD */ + MSP85x0_GE_WRITE((MSP85x0_GE_GDI_INTERRUPT_ENABLE + (port_num << XDMA_PORT_OFFSET)), reg_data); + + tx_ring = get_ring_count(MSP85x0_GE_TX_QUEUE/64); + tx_ring = tx_ring << 27; + rx_ring = get_ring_count(MSP85x0_GE_RX_QUEUE/64); + rx_ring = rx_ring << 16; + + // Should be written while XDMA in the reset + reg_data = MSP85x0_GE_READ(MSP85x0_GE_CHANNEL0_CONFIG + (port_num << XDMA_PORT_OFFSET)); + reg_data &=~(7 << 27); // Clear Tx descriptor ring size + reg_data &=~(7 << 16); // Clear Rx descriptor ring size + reg_data |=(tx_ring | rx_ring); + reg_data |= 0x400; // Rx TCP Checksum + if(MSP85x0_GE_RX_BUFSIZE % 512) + { + printk(KERN_ERR"\n\r ERROR!! Invalid Rx buffer size. "); + printk(KERN_ERR"\n\r should be mulitple of 512."); + printk(KERN_ERR"\n\r Current size=0x%x",MSP85x0_GE_RX_BUFSIZE) ; + } + reg_data |= (get_rx_buff_size(MSP85x0_GE_RX_BUFSIZE/512) << 5); + MSP85x0_GE_WRITE((MSP85x0_GE_CHANNEL0_CONFIG + (port_num << XDMA_PORT_OFFSET)), reg_data); + // Rx desc iTH thershold for packet drop + reg_data=2; // 0 ->4 , 1 -> 8, 2 -> 16, 3 -> 32 + MSP85x0_GE_WRITE((MSP85x0_GE_CHANNEL0_RX_DESC_PKT_DRP_THR + (port_num << XDMA_PORT_OFFSET)), reg_data); + MSP85x0_GE_WRITE((MSP85x0_GE_GDI_PASSPW_CONFIG + (port_num << XDMA_PORT_OFFSET)),0x101); + + /* Start the Tx and Rx XDMA controller */ + reg_data = MSP85x0_GE_READ(MSP85x0_GE_CHANNEL0_CONFIG + (port_num << XDMA_PORT_OFFSET)); + reg_data &= ~(1 << 31); /* Clear tx reset */ + reg_data &= ~(1 << 20); /* Clear rx reset */ + MSP85x0_GE_WRITE((MSP85x0_GE_CHANNEL0_CONFIG + (port_num << XDMA_PORT_OFFSET)), reg_data); + + /* Rx desc count */ + count=msp85x0_ge_rx_task(netdev, msp85x0_ge_eth); + MSP85x0_GE_WRITE((MSP85x0_GE_CHANNEL0_RX_DMA_STS + (msp85x0_ge_eth->port_num << 9)),count); + msp85x0_ge_eth->rx_local_desc_count=count; + udelay(30); + return 0; +} + + +/* + * Start the port. All the hardware specific configuration + * for the XDMA, Tx FIFO, Rx FIFO, TMAC, RMAC, TRTG and AFX + * go here + */ +static int msp85x0_ge_port_start(struct net_device *netdev) +{ + msp85x0_ge_port_info *msp85x0_ge_eth = netdev_priv(netdev); + int port_num = msp85x0_ge_eth->port_num; + + xdma_config(netdev); + msp85x0_eth_setup_tx_rx_fifo(netdev); + trtg_block_enable(netdev); + start_tx_and_rx_activity(netdev); + + msp85x0_ge_gmii_config(port_num); + enable_tx_and_rx_interrupts(netdev); + + if (config_done == 0) { + config_done = 1; + } + + return MSP85x0_OK; +} +/* + * Function to queue the packet for the Ethernet device + */ +static void msp85x0_ge_tx_queue(msp85x0_ge_port_info * msp85x0_ge_eth, + struct sk_buff * skb) +{ + struct device *device = &msp85x0_ge_device[msp85x0_ge_eth->port_num]->dev; + unsigned int curr_desc = msp85x0_ge_eth->tx_curr_desc_q; + volatile msp85x0_ge_tx_desc *tx_curr; + int port_num = msp85x0_ge_eth->port_num; + unsigned int pkts; + + tx_curr = &(msp85x0_ge_eth->tx_desc_area[curr_desc]); + + pkts=MSP85x0_GE_READ(MSP85x0_GE_CHANNEL0_TX_DMA_STS+ (port_num << XDMA_PORT_OFFSET)) & 0x3FF; + if(pkts < 1023) + { + tx_curr->buffer_addr =dma_map_single(device, skb->data, skb_headlen(skb), + DMA_TO_DEVICE); + + msp85x0_ge_eth->tx_skb[curr_desc] = (struct sk_buff *) skb; + tx_curr->buffer_len = skb_headlen(skb); + + /* Last descriptor enables interrupt and changes ownership */ + tx_curr->cmd_sts = 0x1 | (1 << 15) | (1 << 5); + + DMA_CACHE_WBACK_INV((unsigned long)tx_curr,sizeof(msp85x0_ge_tx_desc)); + + /* Kick the XDMA to start the transfer from memory to the FIFO */ + MSP85x0_GE_WRITE((MSP85x0_GE_CHANNEL0_TX_DMA_STS + (port_num << XDMA_PORT_OFFSET)), 0x1); + /* Have the packet count updated */ + increment_tx_pkt_count(port_num); + /* Current descriptor updated */ + msp85x0_ge_eth->tx_curr_desc_q = (curr_desc + 1) % MSP85x0_GE_TX_QUEUE; + + /* Prefetch the next descriptor */ + prefetch((const void *)&msp85x0_ge_eth->tx_desc_area[msp85x0_ge_eth->tx_curr_desc_q]); + } + +} + +static int msp85x0_eth_set_mac_addr(struct net_device *dev) +{ + msp85x0_ge_port_info *msp85x0_ge_eth = netdev_priv(dev); + unsigned int port = msp85x0_ge_eth->port_num; + unsigned char addr[6]; + unsigned int i,retries=1000; + + + memcpy(addr, dev->dev_addr, 6); + + /* TMAC address */ + MSP85x0_GE_WRITE(MSP85x0_GE_TMAC_STATION_HI + (port<<12), + (addr[5] << 8) | addr[4]); + MSP85x0_GE_WRITE(MSP85x0_GE_TMAC_STATION_MID + (port<<12), + (addr[3] << 8) | addr[2]); + MSP85x0_GE_WRITE(MSP85x0_GE_TMAC_STATION_LOW + (port<<12), + (addr[1] << 8) | addr[0]); + + /* RMAC address */ + MSP85x0_GE_WRITE(MSP85x0_GE_RMAC_STATION_HI + (port<<12), + (addr[5] << 8) | addr[4]); + MSP85x0_GE_WRITE(MSP85x0_GE_RMAC_STATION_MID + (port<<12), + (addr[3] << 8) | addr[2]); + MSP85x0_GE_WRITE(MSP85x0_GE_RMAC_STATION_LOW + (port<<12), + (addr[1] << 8) | addr[0]); + + for (i=0; i<8; i++) + { + /* select address filter */ + MSP85x0_GE_WRITE(MSP85x0_GE_AFX_ADDRS_FILTER_CTRL_2 + (port<<12), i); + + /* accept on match */ + MSP85x0_GE_WRITE(MSP85x0_GE_AFX_ADDRS_FILTER_CTRL_0 + (port<<12), 0x9); + + /* exact match */ + MSP85x0_GE_WRITE(MSP85x0_GE_AFX_EXACT_MATCH_LOW + (port<<12), + (addr[1] << 8) | addr[0]); + MSP85x0_GE_WRITE(MSP85x0_GE_AFX_EXACT_MATCH_MID + (port<<12), + (addr[3] << 8) | addr[2]); + MSP85x0_GE_WRITE(MSP85x0_GE_AFX_EXACT_MATCH_HIGH + (port<<12), + (addr[5] << 8) | addr[4]); + + /* set VLAN id to 0 */ + MSP85x0_GE_WRITE(MSP85x0_GE_AFX_EXACT_MATCH_VID + (port<<12), 0); + + /* update address filter */ + MSP85x0_GE_WRITE(MSP85x0_GE_AFX_ADDRS_FILTER_CTRL_3 + (port<<12), 1); + while (retries) + { + if(!(MSP85x0_GE_READ(MSP85x0_GE_AFX_ADDRS_FILTER_CTRL_3 + (port<<12)) & 1)) + { + break; + } + mdelay(1); + retries--; + } + if(!retries) + { + printk("\n\r Unable to update the filters "); + return MSP85x0_ERROR; + } + } + return MSP85x0_OK; +} +static int msp85x0_eth_setup_tx_ring(struct net_device *dev) +{ + msp85x0_ge_port_info *msp85x0_ge_eth = netdev_priv(dev); + unsigned int port_num = msp85x0_ge_eth->port_num,retval; + + /* Allocate the Tx ring now */ + msp85x0_ge_eth->tx_ring_skbs = 0; + msp85x0_ge_eth->tx_ring_size = MSP85x0_GE_TX_QUEUE; + + /* Allocate space in the SRAM for the descriptors */ + + msp85x0_ge_eth->tx_desc_area = (msp85x0_ge_tx_desc *) + (msp85x0_ge_sram + MSP85x0_TX_RING_BYTES * port_num); + msp85x0_ge_eth->tx_desc_area_size = + msp85x0_ge_eth->tx_ring_size * sizeof(msp85x0_ge_tx_desc); + + msp85x0_ge_eth->tx_dma = MSP85x0_SRAM_BASE + MSP85x0_TX_RING_BYTES * port_num; + GE_DBG("tx_dma=0x%x\n",(unsigned int)msp85x0_ge_eth->tx_dma); + GE_DBG("tx_desc_area=0x%x\n",(unsigned int )msp85x0_ge_eth->tx_desc_area); + + if (!msp85x0_ge_eth->tx_desc_area) + { + printk(KERN_ERR"%s: Cannot allocate Tx Ring (size %d bytes) for port %d \n",dev->name, MSP85x0_TX_RING_BYTES, port_num); + return MSP85x0_ERROR; + } + + memset((void *)msp85x0_ge_eth->tx_desc_area, 0, msp85x0_ge_eth->tx_desc_area_size); + + /* Now initialize the Tx descriptor ring */ + retval=msp85x0_ge_init_tx_desc_ring(msp85x0_ge_eth,msp85x0_ge_eth->tx_ring_size, + (unsigned long) msp85x0_ge_eth->tx_desc_area, + (unsigned long) msp85x0_ge_eth->tx_dma); + + DMA_CACHE_WBACK_INV((unsigned long)msp85x0_ge_eth->tx_desc_area,msp85x0_ge_eth->tx_desc_area_size); + + if(retval!=MSP85x0_OK) + { + printk("\n\r Error initializing descriptor ..."); + return MSP85x0_ERROR; + } + return retval; +} + +static int msp85x0_eth_setup_rx_ring(struct net_device *dev) +{ + msp85x0_ge_port_info *msp85x0_ge_eth = netdev_priv(dev); + unsigned int port_num = msp85x0_ge_eth->port_num; + + + /* Allocate the Rx ring now */ + msp85x0_ge_eth->rx_ring_size = MSP85x0_GE_RX_QUEUE; + msp85x0_ge_eth->rx_ring_skbs = 0; + + msp85x0_ge_eth->rx_desc_area = + (msp85x0_ge_rx_desc *)(msp85x0_ge_sram + 0x4000 + MSP85x0_RX_RING_BYTES * port_num); + msp85x0_ge_eth->rx_dma = MSP85x0_SRAM_BASE + 0x4000 + MSP85x0_RX_RING_BYTES * port_num; + + msp85x0_ge_eth->rx_desc_area_size = + msp85x0_ge_eth->rx_ring_size * sizeof(msp85x0_ge_rx_desc); + + GE_DBG("rx_dma=0x%p\n", (void *)msp85x0_ge_eth->rx_dma); + GE_DBG("rx_desc_area=0x%p\n",(void *)msp85x0_ge_eth->rx_desc_area); + + if (!msp85x0_ge_eth->rx_desc_area) { + printk(KERN_ERR "%s: Cannot allocate Rx Ring (size %d bytes)\n", + dev->name, MSP85x0_RX_RING_BYTES); + printk(KERN_ERR "%s: Freeing previously allocated TX queues...", + dev->name); + return MSP85x0_ERROR; + } + memset((void *)msp85x0_ge_eth->rx_desc_area, 0, msp85x0_ge_eth->rx_desc_area_size); + + /* Now initialize the Rx ring */ + if ((msp85x0_ge_init_rx_desc_ring + (msp85x0_ge_eth, msp85x0_ge_eth->rx_ring_size, MSP85x0_GE_RX_BUFSIZE, + (unsigned long) msp85x0_ge_eth->rx_desc_area, 0, + (unsigned long) msp85x0_ge_eth->rx_dma)) == 0) + { + panic("%s: Error initializing RX Ring\n", dev->name); + return MSP85x0_ERROR; + } + DMA_CACHE_WBACK_INV((unsigned long)msp85x0_ge_eth->rx_desc_area,msp85x0_ge_eth->rx_desc_area_size); + + return MSP85x0_OK; +} + +static int msp85x0_eth_setup_tx_rx_fifo(struct net_device *dev) +{ + msp85x0_ge_port_info *msp85x0_ge_eth = netdev_priv(dev); + unsigned int port = msp85x0_ge_eth->port_num; + + unsigned int reg_data,reg_data1; + + /* Enable RX FIFO 0 and 8 */ + // RX FIFO + reg_data = MSP85x0_GE_READ(MSP85x0_GE_SDQPF_RXFIFO_0 + (port * SQDPF_RX_PORT_OFFSET)); + reg_data |= 0x100000; + MSP85x0_GE_WRITE(MSP85x0_GE_SDQPF_RXFIFO_0 + (port * SQDPF_RX_PORT_OFFSET), reg_data); + /* + * BAV2,BAV and DAV settings for the Rx FIFO + * + * The recommendation for RxFIFO is to minimize DAV_TH, minimize BAV_TH, and set BAV2_TH to its min. + * DAV_TH min = 2. + * BAV_TH min = 2. + * BAV2_TH min = BAV_TH min + 3 = 2+3 = 5. + */ + reg_data = 0x00500802; + MSP85x0_GE_WRITE(MSP85x0_GE_SDQPF_RX_THRLD_0 + (port * SQDPF_RX_PORT_OFFSET), reg_data); + + reg_data = MSP85x0_GE_READ(MSP85x0_GE_SDQPF_RXFIFO_0 + (port * SQDPF_RX_PORT_OFFSET)); + reg_data = 0x00260000; + reg_data |=(port << 7); + reg_data |=(port << 8); + MSP85x0_GE_WRITE(MSP85x0_GE_SDQPF_RXFIFO_0 + (port * SQDPF_RX_PORT_OFFSET), reg_data); + + // TX FIFO + reg_data = MSP85x0_GE_READ(MSP85x0_GE_SDQPF_TXFIFO_0 + (port * SQDPF_TX_PORT_OFFSET)); + reg_data |= 0x100000; + MSP85x0_GE_WRITE(MSP85x0_GE_SDQPF_TXFIFO_0 + (port * SQDPF_TX_PORT_OFFSET), reg_data); + /* + * BAV2, BAV and DAV settings for the Tx FIFO + * + * The recommendation for TxFIFO is to maximize DAV_TH, minimize BAV_TH, + * and set BAV2_TH to its min. + * DAV_TH max = SIZE-3. So for 4KB physical buffer this is (128 - 3) = 125. + * BAV_TH min = 2. + * BAV2_TH min = BAV_TH min + 3 = 2+3 = 5. + */ + + reg_data1 = 0x0050087D; + MSP85x0_GE_WRITE(MSP85x0_GE_SDQPF_TX_THRLD_0 + (port * SQDPF_TX_PORT_OFFSET), reg_data1); + + reg_data = MSP85x0_GE_READ(MSP85x0_GE_SDQPF_TXFIFO_0 + (port * SQDPF_TX_PORT_OFFSET)); + reg_data = 0x220000; + reg_data |=(port << 7); + MSP85x0_GE_WRITE(MSP85x0_GE_SDQPF_TXFIFO_0 + (port * SQDPF_TX_PORT_OFFSET), reg_data); + return MSP85x0_OK; +} + + +static int msp85x0_ge_eth_open(struct net_device *netdev) +{ + msp85x0_ge_port_info *msp85x0_ge_eth = netdev_priv(netdev); + unsigned int port_num = msp85x0_ge_eth->port_num; + unsigned long reg_data; + unsigned int phy_reg; + int err = 0; + + int tbi_mode; + if(config_done == 0){ + reg_data = MSP85x0_GE_READ(MSP85x0_GE_TSB_CTRL_0); + tbi_mode =(reg_data & 0x700) >> 8; + + if(!tbi_mode) + { + reg_data &=~(0x700); + MSP85x0_GE_WRITE(MSP85x0_GE_TSB_CTRL_0,reg_data); + } + } + + /* Stop the Rx activity */ + reg_data = MSP85x0_GE_READ(MSP85x0_GE_RMAC_CONFIG_1 + (port_num << MAC_PORT_OFFSET)); + reg_data &= ~(0x00000001); + MSP85x0_GE_WRITE((MSP85x0_GE_RMAC_CONFIG_1 + (port_num << MAC_PORT_OFFSET)), reg_data); + + /* Clear the port interrupts */ + MSP85x0_GE_WRITE((MSP85x0_GE_CHANNEL0_INTERRUPT + + (port_num << 9)), 0xf006c002); + MSP85x0_GE_WRITE((MSP85x0_GE_CHANNEL0_INTERRUPT + + (port_num << 9)), 0); + if (config_done == 0) { + MSP85x0_GE_WRITE(MSP85x0_GE_INTR_XDMA_CORE_A, 0xffffffff); + } + /* Set MAC address */ + if(msp85x0_eth_set_mac_addr(netdev)==MSP85x0_ERROR) + { + printk(KERN_ERR"\n\r Unable to update the AFX filters"); + return MSP85x0_ERROR; + } + /* Setup Tx Ring */ + if(msp85x0_eth_setup_tx_ring(netdev)==MSP85x0_ERROR) + { + printk(KERN_ERR"\n\r Unable to setup tx ring "); + return MSP85x0_ERROR; + } + /* Setup Rx Ring */ + if(msp85x0_eth_setup_rx_ring(netdev)==MSP85x0_ERROR) + { + printk(KERN_ERR"\n\r Unable to setup rx ring "); + return MSP85x0_ERROR; + } + /* Port Init - (Stop Tx and Rx XDMA Channels for the port)*/ + if (config_done == 0) + msp85x0_port_init(netdev, msp85x0_ge_eth); + + /* Fill the Rx ring with the SKBs */ + msp85x0_ge_port_start(netdev); + + /* + * Check if Interrupt Coalescing needs to be turned on. The + * values specified in the register is multiplied by + * (8 x 64 nanoseconds) to determine when an interrupt should + * be sent to the CPU. + */ + if (MSP85x0_GE_TX_COAL) { + msp85x0_ge_eth->tx_int_coal = + msp85x0_ge_tx_coal(port_num); + } + + err = titan_ge_mdio_read(port_num,TITAN_GE_MDIO_PHY_STATUS, &phy_reg); + if (err == TITAN_GE_MDIO_ERROR) { + printk(KERN_ERR + "Could not read PHY control register 0x11 \n"); + return MSP85x0_ERROR; + } + if (!(phy_reg & 0x0400)) { + netif_carrier_off(netdev); + netif_stop_queue(netdev); + return MSP85x0_ERROR; + } else { + netif_carrier_on(netdev); + netif_start_queue(netdev); + } + + return MSP85x0_OK; +} + + +/* + * Queue the packet for Tx. Currently no support for zero copy, + * checksum offload and Scatter Gather. The chip does support + * Scatter Gather only. But, that wont help here since zero copy + * requires support for Tx checksumming also. + */ +int msp85x0_ge_start_xmit(struct sk_buff *skb, struct net_device *netdev) +{ + msp85x0_ge_port_info *msp85x0_ge_eth = netdev_priv(netdev); + unsigned long flags; + struct net_device_stats *stats; + + stats = &msp85x0_ge_eth->stats; + spin_lock_irqsave(&msp85x0_ge_eth->lock, flags); + + if (msp85x0_ge_eth->tx_threshold > TX_THRESHOLD) { + msp85x0_ge_eth->tx_threshold = 0; + msp85x0_ge_free_tx_queue(netdev); + } + else + msp85x0_ge_eth->tx_threshold++; + + + if ((MSP85x0_GE_TX_QUEUE - msp85x0_ge_eth->tx_ring_skbs) <= + (skb_shinfo(skb)->nr_frags + 1)) { + printk("\n\r tx fragments = %d",skb_shinfo(skb)->nr_frags); + netif_stop_queue(netdev); + spin_unlock_irqrestore(&msp85x0_ge_eth->lock, flags); + printk(KERN_ERR "Tx OOD \n"); + return 1; + } + + msp85x0_ge_tx_queue(msp85x0_ge_eth, skb); + msp85x0_ge_eth->tx_ring_skbs++; + + stats->tx_bytes += skb->len; + stats->tx_packets++; + + spin_unlock_irqrestore(&msp85x0_ge_eth->lock, flags); + netdev->trans_start = jiffies; + return 0; +} + +/* + * Actually does the Rx. Rx side checksumming supported. + */ +static int msp85x0_ge_rx(struct net_device *netdev, int port_num, + msp85x0_ge_port_info * msp85x0_ge_eth, + msp85x0_ge_packet * packet) +{ + int rx_curr_desc, rx_used_desc; + volatile msp85x0_ge_rx_desc *rx_desc; + + rx_curr_desc = msp85x0_ge_eth->rx_curr_desc_q; + rx_used_desc = msp85x0_ge_eth->rx_used_desc_q; + port_num = msp85x0_ge_eth->port_num; + + rx_desc = &(msp85x0_ge_eth->rx_desc_area[rx_curr_desc]); + + packet->skb = msp85x0_ge_eth->rx_skb[rx_curr_desc]; + packet->len = (rx_desc->cmd_sts & 0x7fff); + + /* + * At this point, we dont know if the checksumming + * actually helps relieve CPU. So, keep it for + * port 0 only + */ + packet->checksum = ntohs((rx_desc->buffer & 0xffff0000) >> 16); + packet->cmd_sts = rx_desc->cmd_sts; + + if((rx_curr_desc + 1) == MSP85x0_GE_RX_QUEUE) + msp85x0_ge_eth->rx_curr_desc_q =0; + else + msp85x0_ge_eth->rx_curr_desc_q = (rx_curr_desc + 1); + msp85x0_ge_eth->rx_ring_skbs--; + msp85x0_ge_eth->rx_local_desc_count--; + + /* Prefetch the next descriptor */ + prefetch((const void *) + &msp85x0_ge_eth->rx_desc_area[msp85x0_ge_eth->rx_curr_desc_q]); + + return MSP85x0_OK; +} + +/* + * Free the Tx queue of the used SKBs + */ +static int msp85x0_ge_free_tx_queue(struct net_device *netdev) +{ + msp85x0_ge_port_info *msp85x0_ge_eth = netdev_priv(netdev); + int pkts,port_num = msp85x0_ge_eth->port_num; + int tx_desc_used; + struct sk_buff *skb; + + /* Take the lock */ + pkts=get_tx_pkt_count(port_num); + while(pkts) + { + pkts--; + tx_desc_used = msp85x0_ge_eth->tx_used_desc_q; + + /* return right away */ + if (tx_desc_used == msp85x0_ge_eth->tx_curr_desc_q) + break; + + skb = msp85x0_ge_eth->tx_skb[tx_desc_used]; + dev_kfree_skb_irq(skb); + msp85x0_ge_eth->tx_skb[tx_desc_used] = NULL; + + if((tx_desc_used + 1) == MSP85x0_GE_TX_QUEUE) + msp85x0_ge_eth->tx_used_desc_q=0; + else + msp85x0_ge_eth->tx_used_desc_q=tx_desc_used + 1; + + if (msp85x0_ge_eth->tx_ring_skbs > 0) + { + msp85x0_ge_eth->tx_ring_skbs--; + decrement_tx_pkt_count(port_num); + } + } + return MSP85x0_OK; +} + +/* + * Threshold beyond which we do the cleaning of + * Tx queue and new allocation for the Rx + * queue + */ +/* + * Receive the packets and send it to the kernel. + */ + + +static int msp85x0_ge_receive_queue(struct net_device *netdev) +{ + msp85x0_ge_port_info *msp85x0_ge_eth = netdev_priv(netdev); + unsigned int port_num = msp85x0_ge_eth->port_num; + msp85x0_ge_packet packet; + struct net_device_stats *stats; + struct sk_buff *skb; + unsigned long received_packets = 0; + unsigned int ack; + int max=-1; + + unsigned int rx_dma_desc_count; + unsigned int total_desc_recvd; + + rx_dma_desc_count=MSP85x0_GE_READ(MSP85x0_GE_CHANNEL0_RX_DMA_STS + (port_num << 9)); + if(msp85x0_ge_eth->rx_local_desc_count == rx_dma_desc_count) + { + return MSP85x0_ERROR; + } + if(rx_dma_desc_count > msp85x0_ge_eth->rx_local_desc_count) + { + printk(KERN_ERR"\n\r The DMA and S/W counter are not in SYNC !!"); + return MSP85x0_ERROR; + } + total_desc_recvd=msp85x0_ge_eth->rx_local_desc_count - rx_dma_desc_count; + max=total_desc_recvd; + + oom_flag=0; + stats = &msp85x0_ge_eth->stats; + while ((max--) && + (msp85x0_ge_rx(netdev, port_num, msp85x0_ge_eth, &packet) == MSP85x0_OK)) + { + skb = (struct sk_buff *) packet.skb; + if(!skb) + { + printk(KERN_ERR"\n\r Null SKB !!! "); + break; + } + + msp85x0_ge_eth->rx_work_limit--; + + received_packets++; + + if (msp85x0_ge_eth->rx_threshold > RX_THRESHOLD) { + ack=msp85x0_ge_rx_task(netdev, msp85x0_ge_eth); + MSP85x0_GE_WRITE((MSP85x0_GE_CHANNEL0_RX_DMA_STS + (msp85x0_ge_eth->port_num << 9)),ack); + msp85x0_ge_eth->rx_local_desc_count +=ack; + if(!oom_flag){ + msp85x0_ge_eth->rx_threshold = 0; + } + } else + msp85x0_ge_eth->rx_threshold++; + + if (packet.cmd_sts & (MSP85x0_GE_RX_PERR | MSP85x0_GE_RX_OVERFLOW_ERROR | MSP85x0_GE_RX_TRUNC | MSP85x0_GE_RX_CRC_ERROR)) + { + if(packet.cmd_sts & MSP85x0_GE_RX_OVERFLOW_ERROR) + stats->rx_over_errors++; + else if(packet.cmd_sts & MSP85x0_GE_RX_TRUNC) + stats->rx_frame_errors++; + else + stats->rx_errors++; + dev_kfree_skb_any(skb); + continue; + } + + if(!(packet.cmd_sts & MSP85x0_GE_RX_STP)) + { + stats->rx_dropped++; + dev_kfree_skb_any(skb); + continue; + } + + + /* + * Increment data pointer by two since thats where + * the MAC starts + */ + skb_reserve(skb, 2); + /* + * Either support fast path or slow path. Decision + * making can really slow down the performance. The + * idea is to cut down the number of checks and improve + * the fastpath. + */ + skb_put(skb, packet.len - 2); + + skb->protocol = eth_type_trans(skb, netdev); + + if(netif_receive_skb(skb)==NET_RX_DROP) + { + stats->rx_dropped++; + } + else + { + stats->rx_packets++; + stats->rx_bytes += packet.len; + } + if (!msp85x0_ge_eth->rx_work_limit || (oom_flag==1)) + { + break; + } + } + return received_packets; +} + +/* + * Main function to handle the polling for Rx side NAPI. + * Receive interrupts have been disabled at this point. + * The poll schedules the transmit followed by receive. + */ +static int msp85x0_ge_poll(struct net_device *netdev, int *budget) +{ + msp85x0_ge_port_info *msp85x0_ge_eth = netdev_priv(netdev); + int port_num = msp85x0_ge_eth->port_num; + int work_done = 0; + unsigned long flags, status; + + msp85x0_ge_eth->rx_work_limit = *budget; + if ((int)msp85x0_ge_eth->rx_work_limit > netdev->quota) + msp85x0_ge_eth->rx_work_limit = netdev->quota; + + do { + /* Ack the Rx interrupts */ + clear_xdma_interrupts(port_num,RX_INT); + work_done += msp85x0_ge_receive_queue(netdev); + /* Out of quota and there is work to be done */ + if((oom_flag == 1) || (msp85x0_ge_eth->rx_work_limit <= 0)) + { + *budget -= work_done; + netdev->quota -= work_done; + return 1; + } + status = MSP85x0_GE_READ(MSP85x0_GE_INTR_XDMA_CORE_A); + } + while (status & (RX_INT << (XDMA_CHANNEL_OFFSET * port_num))); + + /* If we are here, then no more interrupts to process */ + /* + * No more packets on the poll list. Turn the interrupts + * back on and we should be able to catch the new + * packets in the interrupt handler + */ + spin_lock_irqsave(&msp85x0_ge_eth->lock,flags); + if (!work_done) + work_done = 1; + + *budget -= work_done; + netdev->quota -= work_done; + + /* Remove us from the poll list */ + netif_rx_complete(netdev); + + /* Re-enable interrupts */ + msp85x0_ge_enable_rx_int(port_num); + spin_unlock_irqrestore(&msp85x0_ge_eth->lock,flags); + return 0; +} + +/* + * Close the network device + */ +int msp85x0_ge_stop(struct net_device *netdev) +{ + msp85x0_ge_port_info *msp85x0_ge_eth = netdev_priv(netdev); + + spin_lock_irq(&(msp85x0_ge_eth->lock)); + msp85x0_ge_eth_stop(netdev); + free_irq(netdev->irq, netdev); + spin_unlock_irq(&msp85x0_ge_eth->lock); + return MSP85x0_OK; +} + +/* Don't Re-Initialize the port, Just start from where it stops */ +static int msp85x0_ge_eth_reopen(struct net_device *netdev) +{ + msp85x0_ge_port_info *msp85x0_ge_eth = netdev_priv(netdev); + unsigned int reg_data,irq; + int retval; + + irq = MSP85x0_ETH_PORT_IRQ; + + retval = request_irq(irq, INTERRUPT_HANDLER, + SA_INTERRUPT | SA_SAMPLE_RANDOM | SA_SHIRQ, netdev->name, netdev); + + if (retval != 0) { + printk(KERN_ERR "Cannot assign IRQ number to MSP85x0 GE \n"); + return -1; + } + + netdev->irq = irq; + printk(KERN_INFO "Assigned IRQ %d to port %d\n", irq, msp85x0_ge_eth->port_num); + + reg_data=MSP85x0_GE_READ(MSP85x0_GE_INTR_XDMA_IE); + reg_data |=(RX_INT << (msp85x0_ge_eth->port_num * 16)); + MSP85x0_GE_WRITE(MSP85x0_GE_INTR_XDMA_IE,reg_data); + + netif_start_queue(netdev); + msp85x0_bringup_sequence(msp85x0_ge_eth->port_num); + return 0; +} + +/* + * Actually does the stop of the Ethernet device + */ +static void msp85x0_ge_eth_stop(struct net_device *netdev) +{ + msp85x0_ge_port_info *msp85x0_ge_eth = netdev_priv(netdev); + unsigned int reg_data; + + /* Tell Kernel to release this interface */ + netif_stop_queue(netdev); + /* Disable the Tx and Rx Interrupts for the port*/ + reg_data=MSP85x0_GE_READ(MSP85x0_GE_INTR_XDMA_IE); + reg_data &=~(0x3 << (msp85x0_ge_eth->port_num * 16)); + MSP85x0_GE_WRITE(MSP85x0_GE_INTR_XDMA_IE,reg_data); + /* set the open function to re-open */ + /* This to work around to solve the msp85x0 shutdown and bringup sequence */ + netdev->open=msp85x0_ge_eth_reopen; + msp85x0_reset_sequence(msp85x0_ge_eth->port_num); +} + +/* + * Update the MAC address. Note that we have to write the + * address in three station registers, 16 bits each. And this + * has to be done for TMAC and RMAC + */ +static void msp85x0_ge_update_mac_address(struct net_device *netdev) +{ + msp85x0_ge_port_info *msp85x0_ge_eth = netdev_priv(netdev); + unsigned int port_num = msp85x0_ge_eth->port_num; + u8 p_addr[6]; + + memcpy(msp85x0_ge_eth->port_mac_addr, netdev->dev_addr, 6); + memcpy(p_addr, netdev->dev_addr, 6); + + /* Update the Address Filtering Match tables */ + msp85x0_ge_update_afx(msp85x0_ge_eth); + + printk("Station MAC : %d %d %d %d %d %d \n", + p_addr[5], p_addr[4], p_addr[3], + p_addr[2], p_addr[1], p_addr[0]); + + /* Set the MAC address here for TMAC and RMAC */ + MSP85x0_GE_WRITE((MSP85x0_GE_TMAC_STATION_HI + (port_num << MAC_PORT_OFFSET)), + ((p_addr[5] << 8) | p_addr[4])); + MSP85x0_GE_WRITE((MSP85x0_GE_TMAC_STATION_MID + (port_num << MAC_PORT_OFFSET)), + ((p_addr[3] << 8) | p_addr[2])); + MSP85x0_GE_WRITE((MSP85x0_GE_TMAC_STATION_LOW + (port_num << MAC_PORT_OFFSET)), + ((p_addr[1] << 8) | p_addr[0])); + + MSP85x0_GE_WRITE((MSP85x0_GE_RMAC_STATION_HI + (port_num << MAC_PORT_OFFSET)), + ((p_addr[5] << 8) | p_addr[4])); + MSP85x0_GE_WRITE((MSP85x0_GE_RMAC_STATION_MID + (port_num << MAC_PORT_OFFSET)), + ((p_addr[3] << 8) | p_addr[2])); + MSP85x0_GE_WRITE((MSP85x0_GE_RMAC_STATION_LOW + (port_num << MAC_PORT_OFFSET)), + ((p_addr[1] << 8) | p_addr[0])); +} + +/* + * Set the MAC address of the Ethernet device + */ +static int msp85x0_ge_set_mac_address(struct net_device *dev, void *addr) +{ + msp85x0_ge_port_info *tp = netdev_priv(dev); + struct sockaddr *sa = addr; + + memcpy(dev->dev_addr, sa->sa_data, dev->addr_len); + + spin_lock_irq(&tp->lock); + msp85x0_ge_update_mac_address(dev); + spin_unlock_irq(&tp->lock); + + return 0; +} + +/* + * Get the Ethernet device stats + */ +static struct net_device_stats *msp85x0_ge_get_stats(struct net_device *netdev) +{ + msp85x0_ge_port_info *msp85x0_ge_eth = netdev_priv(netdev); + + return &msp85x0_ge_eth->stats; +} + +/* + * Initialize the Rx descriptor ring for the MSP85x0 Ge + */ +static int msp85x0_ge_init_rx_desc_ring(msp85x0_ge_port_info * msp85x0_eth_port, + int rx_desc_num, + int rx_buff_size, + unsigned long rx_desc_base_addr, + unsigned long rx_buff_base_addr, + unsigned long rx_dma) +{ + volatile msp85x0_ge_rx_desc *rx_desc; + unsigned long buffer_addr; + int index; + unsigned long msp85x0_ge_rx_desc_bus = rx_dma; + + buffer_addr = rx_buff_base_addr; + rx_desc = (msp85x0_ge_rx_desc *) rx_desc_base_addr; + + /* Check alignment */ + if (rx_buff_base_addr & 0xF) + return 0; + + /* Check Rx buffer size */ + if ((rx_buff_size < 8) || (rx_buff_size > MSP85x0_GE_MAX_RX_BUFFER)) + return 0; + + /* Initialize the Rx desc ring */ + for (index = 0; index < rx_desc_num; index++) { + msp85x0_ge_rx_desc_bus += sizeof(msp85x0_ge_rx_desc); + rx_desc[index].cmd_sts = 0; + rx_desc[index].buffer_addr = 0; + msp85x0_eth_port->rx_skb[index] = NULL; + buffer_addr += rx_buff_size; + } + + msp85x0_eth_port->rx_curr_desc_q = 0; + msp85x0_eth_port->rx_used_desc_q = 0; + + msp85x0_eth_port->rx_desc_area = (msp85x0_ge_rx_desc *) rx_desc_base_addr; + msp85x0_eth_port->rx_desc_area_size = + rx_desc_num * sizeof(msp85x0_ge_rx_desc); + + msp85x0_eth_port->rx_dma = rx_dma; + + return MSP85x0_OK; +} + +/* + * Initialize the Tx descriptor ring. Descriptors in the SRAM + */ +static int msp85x0_ge_init_tx_desc_ring(msp85x0_ge_port_info * msp85x0_ge_eth, + int tx_desc_num, + unsigned long tx_desc_base_addr, + unsigned long tx_dma) +{ + msp85x0_ge_tx_desc *tx_desc; + int index; + unsigned long msp85x0_ge_tx_desc_bus = tx_dma; + + if (tx_desc_base_addr & 0xF) + { + printk(KERN_ERR"\n\r Descriptor Base is not 16 byte aligned !!=0x%lx",tx_desc_base_addr); + return 0; + } + + tx_desc = (msp85x0_ge_tx_desc *) tx_desc_base_addr; + + for (index = 0; index < tx_desc_num; index++) { + msp85x0_ge_eth->tx_dma_array[index] = + (dma_addr_t) msp85x0_ge_tx_desc_bus; + msp85x0_ge_tx_desc_bus += sizeof(msp85x0_ge_tx_desc); + tx_desc[index].cmd_sts = 0x0000; + tx_desc[index].buffer_len = 0; + tx_desc[index].buffer_addr = 0x00000000; + msp85x0_ge_eth->tx_skb[index] = NULL; + } + + msp85x0_ge_eth->tx_curr_desc_q = 0; + msp85x0_ge_eth->tx_used_desc_q = 0; + + msp85x0_ge_eth->tx_desc_area = (msp85x0_ge_tx_desc *) tx_desc_base_addr; + msp85x0_ge_eth->tx_desc_area_size = + tx_desc_num * sizeof(msp85x0_ge_tx_desc); + + msp85x0_ge_eth->tx_dma = tx_dma; + return MSP85x0_OK; +} + +/* + * Initialize the device as an Ethernet device + */ +static void __init msp85x0_ge_probe(struct net_device *netdev) +{ + msp85x0_ge_port_info *msp85x0_ge_eth; + unsigned int port = port_number; + + ether_setup(netdev); + + netdev->open = msp85x0_ge_open; + netdev->stop = msp85x0_ge_stop; + netdev->hard_start_xmit = msp85x0_ge_start_xmit; + netdev->get_stats = msp85x0_ge_get_stats; + netdev->set_multicast_list = msp85x0_ge_set_multi; + netdev->set_mac_address = msp85x0_ge_set_mac_address; + + /* Tx timeout */ + netdev->tx_timeout = msp85x0_ge_tx_timeout; + netdev->watchdog_timeo = 2 * HZ; + + /* Set these to very high values */ + netdev->poll = msp85x0_ge_poll; + netdev->weight = 64; + + netdev->tx_queue_len = MSP85x0_GE_TX_QUEUE; + netdev->base_addr = 0; + + netdev->change_mtu = msp85x0_ge_change_mtu; + + msp85x0_ge_eth = netdev_priv(netdev); + /* Allocation of memory for the driver structures */ + + msp85x0_ge_eth->port_num = port; + + /* Configure the Tx timeout handler */ + INIT_WORK(&msp85x0_ge_eth->tx_timeout_task, + (void (*)(void *)) msp85x0_ge_tx_timeout_task, netdev); + /* we're going to reset, so assume we have no link for now */ + netif_carrier_off(netdev); + netif_stop_queue(netdev); + spin_lock_init(&msp85x0_ge_eth->lock); + + /* + * Set MAC addresses: we assume that PMON correctly sets + * up MAC addresses + */ + netdev->dev_addr[0] = + MSP85x0_GE_READ((MSP85x0_GE_TMAC_STATION_LOW + + (port << MAC_PORT_OFFSET))) & 0xff; + netdev->dev_addr[1] = + MSP85x0_GE_READ((MSP85x0_GE_TMAC_STATION_LOW + + (port << MAC_PORT_OFFSET))) >> 8; + netdev->dev_addr[2] = + MSP85x0_GE_READ((MSP85x0_GE_TMAC_STATION_MID + + (port << MAC_PORT_OFFSET))) & 0xff; + netdev->dev_addr[3] = + MSP85x0_GE_READ((MSP85x0_GE_TMAC_STATION_MID + + (port << MAC_PORT_OFFSET))) >> 8; + netdev->dev_addr[4] = + MSP85x0_GE_READ((MSP85x0_GE_TMAC_STATION_HI + + (port << MAC_PORT_OFFSET))) & 0xff; + netdev->dev_addr[5] = + MSP85x0_GE_READ((MSP85x0_GE_TMAC_STATION_HI + + (port << MAC_PORT_OFFSET))) >> 8; + + printk(KERN_NOTICE + "%s: port %d with MAC address %02x:%02x:%02x:%02x:%02x:%02x\n", + netdev->name, port, netdev->dev_addr[0], + netdev->dev_addr[1], netdev->dev_addr[2], + netdev->dev_addr[3], netdev->dev_addr[4], + netdev->dev_addr[5]); + + printk(KERN_NOTICE "Rx NAPI supported, Tx Coalescing ON \n"); + + return; +} + +/* + * Reset the Ethernet port + */ +static void msp85x0_ge_port_reset(unsigned int port_num) +{ + unsigned int reg_data; + unsigned int retries=1000; + /* Stop the Tx port activity */ + reg_data = MSP85x0_GE_READ(MSP85x0_GE_TMAC_CONFIG_1 + + (port_num << MAC_PORT_OFFSET)); + reg_data &= ~(0x0001); + MSP85x0_GE_WRITE((MSP85x0_GE_TMAC_CONFIG_1 + + (port_num << MAC_PORT_OFFSET)), reg_data); + + /* Wait till TMAC is brought down. */ + reg_data = MSP85x0_GE_READ(MSP85x0_GE_TMAC_CONFIG_1 + + (port_num << MAC_PORT_OFFSET)); + while((reg_data & 0x8000) && retries){ + retries--; + udelay(30); + reg_data = MSP85x0_GE_READ(MSP85x0_GE_TMAC_CONFIG_1 + + (port_num << MAC_PORT_OFFSET)); + } + if(!retries) + { + printk(KERN_ERR "Unable to stop the Tx MAC for Port %d",port_num); + } + /* Stop the Rx port activity */ + retries=1000; + reg_data = MSP85x0_GE_READ(MSP85x0_GE_RMAC_CONFIG_1 + + (port_num << MAC_PORT_OFFSET)); + reg_data &= ~(0x0001); + MSP85x0_GE_WRITE((MSP85x0_GE_RMAC_CONFIG_1 + + (port_num << MAC_PORT_OFFSET)), reg_data); + + /* Wait till all packets received and RMAC brought down. */ + reg_data = MSP85x0_GE_READ(MSP85x0_GE_RMAC_CONFIG_1 + + (port_num << MAC_PORT_OFFSET)); + while((reg_data & 0x8000) && retries){ + retries--; + udelay(30); + reg_data = MSP85x0_GE_READ(MSP85x0_GE_RMAC_CONFIG_1 + + (port_num << MAC_PORT_OFFSET)); + } + if(!retries) + { + printk(KERN_ERR "Unable to stop the Rx MAC for Port %d",port_num); + } + return; +} + +/* + * Coalescing for the Tx path + */ +static unsigned int msp85x0_ge_tx_coal(int port) +{ + unsigned int delay; + delay = (MSP85x0_GE_TX_COAL << 16) | MSP85x0_GE_RX_COAL; + + MSP85x0_GE_WRITE(MSP85x0_GE_INT_COALESCING + (port * 4), delay); + MSP85x0_GE_WRITE(MSP85x0_GE_INT_COALESCING + (port * 4), delay); + return delay; +} + +/* + * Register the MSP85x0 GE with the kernel + */ +static int __init msp85x0_ge_init_module(void) +{ + unsigned int version, device,regval; + int i,rc; + + printk(KERN_NOTICE"PMC-Sierra MSP85x0 10/100/1000 Ethernet Driver \n"); + + msp85x0_ge_sram=(unsigned int)IOMAP(MSP85x0_SRAM_BASE,MSP85x0_SRAM_SIZE); + if (!msp85x0_ge_sram) { + printk(KERN_ERR"Mapping MSP85x0 SRAM failed\n"); + return -ENOMEM; + } + + regval = MSP85x0_GE_READ(MSP85x0_GE_DEVICE_ID); + version= GET_GE_VERSION(regval); + device = GET_GE_ID(regval); + + printk(KERN_NOTICE "Device Id : %x, Version : %x \n", device, version); + + for (port_number = 0; port_number < NO_PORTS; port_number++) { + i=port_number; + msp85x0_eth[i] = alloc_netdev(sizeof(struct _eth_port_ctrl),"eth%d",msp85x0_ge_probe); + if(!msp85x0_eth[i]) + return -ENOMEM; + + if((rc = register_netdev(msp85x0_eth[i]))) + { + printk(KERN_ERR "msp85x0_eth: error %i registering device \"%s\"\n", + rc, msp85x0_eth[i]->name); + free_netdev(msp85x0_eth[i]); + return -ENODEV; + + } + + } + msp85x0_reset_sequence(0); + msp85x0_reset_sequence(1); + msp85x0_ge_xdma_reset(); + spin_lock_init(&msp85x0_lock); + return 0; +} + +/* + * Unregister the MSP85x0 GE from the kernel + */ +static void __exit msp85x0_ge_cleanup_module(void) +{ + int i; + + for (i = 0; i < NO_PORTS; i++) + { + if (msp85x0_eth[i]) + { + unregister_netdev(msp85x0_eth[i]); + free_netdev(msp85x0_eth[i]); + } + } + + iounmap((void *)msp85x0_ge_sram); +} + +MODULE_AUTHOR("PMC Sierra Inc "); +MODULE_DESCRIPTION("MSP85x0 GE Ethernet driver"); +MODULE_LICENSE("GPL"); + +module_init(msp85x0_ge_init_module); +module_exit(msp85x0_ge_cleanup_module); + diff -Naur a/drivers/net/msp85x0_ge.h b/drivers/net/msp85x0_ge.h --- a/drivers/net/msp85x0_ge.h 1969-12-31 16:00:00.000000000 -0800 +++ b/drivers/net/msp85x0_ge.h 2006-06-23 15:26:10.000000000 -0700 @@ -0,0 +1,452 @@ +#ifndef _MSP85x0_GE_H_ +#define _MSP85x0_GE_H_ + +#include +#include +#include +#include +#include +#include +#include + +#include + +/* + * These functions should be later moved to a more generic location since there + * will be others accessing it also + */ + +// MSP85x0_GE_BASE and MSP85x0_GE_SIZE are defined in asm/pmc_sequoia.h + +#ifndef msec_delay +#define msec_delay(x) do { if(in_interrupt()) { \ + /* Don't mdelay in interrupt context! */ \ + BUG(); \ + } else { \ + set_current_state(TASK_UNINTERRUPTIBLE); \ + schedule_timeout((x * HZ)/1000); \ + } } while(0) +#endif +#define MSP85x0_GE_PORT_0 + +#define MSP85x0_SRAM_BASE RM9150_SRAM_BASE +#define MSP85x0_SRAM_SIZE RM9150_SRAM_SIZE + +extern unsigned long titan_ge_sram; + +/* + * We may need these constants + */ +#define MSP85x0_BIT0 0x00000001 +#define MSP85x0_BIT1 0x00000002 +#define MSP85x0_BIT2 0x00000004 +#define MSP85x0_BIT3 0x00000008 +#define MSP85x0_BIT4 0x00000010 +#define MSP85x0_BIT5 0x00000020 +#define MSP85x0_BIT6 0x00000040 +#define MSP85x0_BIT7 0x00000080 +#define MSP85x0_BIT8 0x00000100 +#define MSP85x0_BIT9 0x00000200 +#define MSP85x0_BIT10 0x00000400 +#define MSP85x0_BIT11 0x00000800 +#define MSP85x0_BIT12 0x00001000 +#define MSP85x0_BIT13 0x00002000 +#define MSP85x0_BIT14 0x00004000 +#define MSP85x0_BIT15 0x00008000 +#define MSP85x0_BIT16 0x00010000 +#define MSP85x0_BIT17 0x00020000 +#define MSP85x0_BIT18 0x00040000 +#define MSP85x0_BIT19 0x00080000 +#define MSP85x0_BIT20 0x00100000 +#define MSP85x0_BIT21 0x00200000 +#define MSP85x0_BIT22 0x00400000 +#define MSP85x0_BIT23 0x00800000 +#define MSP85x0_BIT24 0x01000000 +#define MSP85x0_BIT25 0x02000000 +#define MSP85x0_BIT26 0x04000000 +#define MSP85x0_BIT27 0x08000000 +#define MSP85x0_BIT28 0x10000000 +#define MSP85x0_BIT29 0x20000000 +#define MSP85x0_BIT30 0x40000000 +#define MSP85x0_BIT31 0x80000000 + +/* Flow Control */ +#define MSP85x0_GE_FC_NONE 0x0 +#define MSP85x0_GE_FC_FULL 0x1 +#define MSP85x0_GE_FC_TX_PAUSE 0x2 +#define MSP85x0_GE_FC_RX_PAUSE 0x3 + +/* Duplex Settings */ +#define MSP85x0_GE_FULL_DUPLEX 0x1 +#define MSP85x0_GE_HALF_DUPLEX 0x2 + +/* Speed settings */ +#define MSP85x0_GE_SPEED_1000 0x1 +#define MSP85x0_GE_SPEED_100 0x2 +#define MSP85x0_GE_SPEED_10 0x3 + +/* Debugging info only */ +#undef MSP85x0_DEBUG + +/* Keep the rings in the Titan's SSRAM */ +#define MSP85x0_RX_RING_IN_SRAM + +#ifdef CONFIG_MIPS64 +#define MSP85x0_GE_IE_MASK 0xfffffffffb001b64 +#define MSP85x0_GE_IE_STATUS 0xfffffffffb001b60 +#else +#define MSP85x0_GE_IE_MASK 0xfb001b64 +#define MSP85x0_GE_IE_STATUS 0xfb001b60 +#endif + +/* Support for Jumbo Frames */ +#undef MSP85x0_GE_JUMBO_FRAMES +//#define MSP85x0_GE_JUMBO_FRAMES + +/* Rx buffer size */ +#ifdef MSP85x0_GE_JUMBO_FRAMES +#define MSP85x0_GE_RX_BUFSIZE (16 * 1024) +#else +#define MSP85x0_GE_RX_BUFSIZE 2048 +#endif + +/* + * Tx and Rx Interrupt Coalescing parameter. These values are + * for 1 Ghz processor. Rx coalescing can be taken care of + * by NAPI. NAPI is adaptive and hence useful. Tx coalescing + * is not adaptive. Hence, these values need to be adjusted + * based on load, CPU speed etc. + */ +#define MSP85x0_GE_RX_COAL 10 +#define MSP85x0_GE_TX_COAL 200 + +#if defined(__BIG_ENDIAN) + +/* Define the Rx descriptor */ + +typedef struct eth_rx_desc { + u32 reserved; /* Unused */ + u32 buffer_addr; /* CPU buffer address */ + u32 cmd_sts; /* Command and Status */ + u32 buffer; /* XDMA buffer address */ +} msp85x0_ge_rx_desc; + +/* Define the Tx descriptor */ +typedef struct eth_tx_desc { + u16 cmd_sts; /* Command, Status and Buffer count */ + u16 buffer_len; /* Length of the buffer */ + u32 buffer_addr; /* Physical address of the buffer */ +} msp85x0_ge_tx_desc; + +#elif defined(__LITTLE_ENDIAN) + +/* Define the Rx descriptor */ +typedef struct eth_rx_desc { + u32 buffer_addr; /* CPU buffer address */ + u32 reserved; /* Unused */ + u32 buffer; /* XDMA buffer address */ + u32 cmd_sts; /* Command and Status */ +} msp85x0_ge_rx_desc; + +/* Define the Tx descriptor */ +typedef struct eth_tx_desc { + u32 buffer_addr; /* Physical address of the buffer */ + u16 buffer_len; /* Length of the buffer */ + u16 cmd_sts; /* Command, Status and Buffer count */ +} msp85x0_ge_tx_desc; +#endif + +/* Default Tx Queue Size */ +#define MSP85x0_GE_TX_QUEUE 256 +#define MSP85x0_TX_RING_BYTES (MSP85x0_GE_TX_QUEUE * sizeof(struct eth_tx_desc)) + +/* Default Rx Queue Size */ +#define MSP85x0_GE_RX_QUEUE 256 +#define MSP85x0_RX_RING_BYTES (MSP85x0_GE_RX_QUEUE * sizeof(struct eth_rx_desc)) + +/* Packet Structure */ +typedef struct _pkt_info { + unsigned int len; + unsigned int cmd_sts; + unsigned int buffer; + struct sk_buff *skb; + unsigned int checksum; +} msp85x0_ge_packet; + + +#define PHYS_CNT 3 + +/* Titan Port specific data structure */ +typedef struct _eth_port_ctrl { + unsigned int port_num; + u8 port_mac_addr[6]; + + /* Rx descriptor pointers */ + int rx_curr_desc_q, rx_used_desc_q; + + /* Tx descriptor pointers */ + int tx_curr_desc_q, tx_used_desc_q; + + /* Rx descriptor area */ + volatile msp85x0_ge_rx_desc *rx_desc_area; + unsigned int rx_desc_area_size; + struct sk_buff* rx_skb[MSP85x0_GE_RX_QUEUE]; + + /* Tx Descriptor area */ + volatile msp85x0_ge_tx_desc *tx_desc_area; + unsigned int tx_desc_area_size; + struct sk_buff* tx_skb[MSP85x0_GE_TX_QUEUE]; + + /* Timeout task */ + struct work_struct tx_timeout_task; + + /* DMA structures and handles */ + dma_addr_t tx_dma; + dma_addr_t rx_dma; + dma_addr_t tx_dma_array[MSP85x0_GE_TX_QUEUE]; + + /* Device lock */ + spinlock_t lock; + + unsigned int tx_ring_skbs; + unsigned int rx_ring_size; + unsigned int tx_ring_size; + unsigned int rx_ring_skbs; + + struct net_device_stats stats; + + /* Tx and Rx coalescing */ + unsigned long rx_int_coal; + unsigned long tx_int_coal; + + /* Threshold for replenishing the Rx and Tx rings */ + unsigned int tx_threshold; + unsigned int rx_threshold; + + /* NAPI work limit */ + int rx_work_limit; + unsigned int rx_local_desc_count; + +} msp85x0_ge_port_info; + +/* Titan specific constants */ +#define MSP85x0_ETH_PORT_IRQ 5 + +/* Max Rx buffer */ +#define MSP85x0_GE_MAX_RX_BUFFER 65536 + +/* Tx and Rx Error */ +#define MSP85x0_GE_ERROR + +/* Rx Descriptor Command and Status */ + +#define MSP85x0_GE_RX_CRC_ERROR MSP85x0_BIT27 /* crc error */ +#define MSP85x0_GE_RX_OVERFLOW_ERROR MSP85x0_BIT15 /* overflow */ +#define MSP85x0_GE_RX_BUFFER_OWNED MSP85x0_BIT21 /* buffer ownership */ +#define MSP85x0_GE_RX_STP MSP85x0_BIT31 /* start of packet */ +#define MSP85x0_GE_RX_BAM MSP85x0_BIT30 /* broadcast address match */ +#define MSP85x0_GE_RX_PAM MSP85x0_BIT28 /* physical address match */ +#define MSP85x0_GE_RX_LAFM MSP85x0_BIT29 /* logical address filter match */ +#define MSP85x0_GE_RX_VLAN MSP85x0_BIT26 /* virtual lans */ +#define MSP85x0_GE_RX_PERR MSP85x0_BIT19 /* packet error */ +#define MSP85x0_GE_RX_TRUNC MSP85x0_BIT20 /* packet size greater than 32 buffers */ + +/* Tx Descriptor Command */ +#define MSP85x0_GE_TX_BUFFER_OWNED MSP85x0_BIT5 /* buffer ownership */ +#define MSP85x0_GE_TX_ENABLE_INTERRUPT MSP85x0_BIT15 /* Interrupt Enable */ + +/* Return Status */ +#define MSP85x0_OK 0x1 /* Good Status */ +#define MSP85x0_ERROR 0x2 /* Error Status */ + +/* MIB specific register offset */ +#define MSP85x0_GE_MSTATX_STATS_BASE_LOW 0x0800 /* MSTATX COUNTL[15:0] */ +#define MSP85x0_GE_MSTATX_STATS_BASE_MID 0x0804 /* MSTATX COUNTM[15:0] */ +#define MSP85x0_GE_MSTATX_STATS_BASE_HI 0x0808 /* MSTATX COUNTH[7:0] */ +#define MSP85x0_GE_MSTATX_CONTROL 0x0828 /* MSTATX Control */ +#define MSP85x0_GE_MSTATX_VARIABLE_SELECT 0x082C /* MSTATX Variable Select */ + +/* MIB counter offsets, add to the MSP85x0_GE_MSTATX_STATS_BASE_XXX */ +#define MSP85x0_GE_MSTATX_RXFRAMESOK 0x0040 +#define MSP85x0_GE_MSTATX_RXOCTETSOK 0x0050 +#define MSP85x0_GE_MSTATX_RXFRAMES 0x0060 +#define MSP85x0_GE_MSTATX_RXOCTETS 0x0070 +#define MSP85x0_GE_MSTATX_RXUNICASTFRAMESOK 0x0080 +#define MSP85x0_GE_MSTATX_RXBROADCASTFRAMESOK 0x0090 +#define MSP85x0_GE_MSTATX_RXMULTICASTFRAMESOK 0x00A0 +#define MSP85x0_GE_MSTATX_RXTAGGEDFRAMESOK 0x00B0 +#define MSP85x0_GE_MSTATX_RXMACPAUSECONTROLFRAMESOK 0x00C0 +#define MSP85x0_GE_MSTATX_RXMACCONTROLFRAMESOK 0x00D0 +#define MSP85x0_GE_MSTATX_RXFCSERROR 0x00E0 +#define MSP85x0_GE_MSTATX_RXALIGNMENTERROR 0x00F0 +#define MSP85x0_GE_MSTATX_RXSYMBOLERROR 0x0100 +#define MSP85x0_GE_MSTATX_RXLAYER1ERROR 0x0110 +#define MSP85x0_GE_MSTATX_RXINRANGELENGTHERROR 0x0120 +#define MSP85x0_GE_MSTATX_RXLONGLENGTHERROR 0x0130 +#define MSP85x0_GE_MSTATX_RXLONGLENGTHCRCERROR 0x0140 +#define MSP85x0_GE_MSTATX_RXSHORTLENGTHERROR 0x0150 +#define MSP85x0_GE_MSTATX_RXSHORTLLENGTHCRCERROR 0x0160 +#define MSP85x0_GE_MSTATX_RXFRAMES64OCTETS 0x0170 +#define MSP85x0_GE_MSTATX_RXFRAMES65TO127OCTETS 0x0180 +#define MSP85x0_GE_MSTATX_RXFRAMES128TO255OCTETS 0x0190 +#define MSP85x0_GE_MSTATX_RXFRAMES256TO511OCTETS 0x01A0 +#define MSP85x0_GE_MSTATX_RXFRAMES512TO1023OCTETS 0x01B0 +#define MSP85x0_GE_MSTATX_RXFRAMES1024TO1518OCTETS 0x01C0 +#define MSP85x0_GE_MSTATX_RXFRAMES1519TOMAXSIZE 0x01D0 +#define MSP85x0_GE_MSTATX_RXSTATIONADDRESSFILTERED 0x01E0 +#define MSP85x0_GE_MSTATX_RXVARIABLE 0x01F0 +#define MSP85x0_GE_MSTATX_GENERICADDRESSFILTERED 0x0200 +#define MSP85x0_GE_MSTATX_UNICASTFILTERED 0x0210 +#define MSP85x0_GE_MSTATX_MULTICASTFILTERED 0x0220 +#define MSP85x0_GE_MSTATX_BROADCASTFILTERED 0x0230 +#define MSP85x0_GE_MSTATX_HASHFILTERED 0x0240 +#define MSP85x0_GE_MSTATX_TXFRAMESOK 0x0250 +#define MSP85x0_GE_MSTATX_TXOCTETSOK 0x0260 +#define MSP85x0_GE_MSTATX_TXOCTETS 0x0270 +#define MSP85x0_GE_MSTATX_TXTAGGEDFRAMESOK 0x0280 +#define MSP85x0_GE_MSTATX_TXMACPAUSECONTROLFRAMESOK 0x0290 +#define MSP85x0_GE_MSTATX_TXFCSERROR 0x02A0 +#define MSP85x0_GE_MSTATX_TXSHORTLENGTHERROR 0x02B0 +#define MSP85x0_GE_MSTATX_TXLONGLENGTHERROR 0x02C0 +#define MSP85x0_GE_MSTATX_TXSYSTEMERROR 0x02D0 +#define MSP85x0_GE_MSTATX_TXMACERROR 0x02E0 +#define MSP85x0_GE_MSTATX_TXCARRIERSENSEERROR 0x02F0 +#define MSP85x0_GE_MSTATX_TXSQETESTERROR 0x0300 +#define MSP85x0_GE_MSTATX_TXUNICASTFRAMESOK 0x0310 +#define MSP85x0_GE_MSTATX_TXBROADCASTFRAMESOK 0x0320 +#define MSP85x0_GE_MSTATX_TXMULTICASTFRAMESOK 0x0330 +#define MSP85x0_GE_MSTATX_TXUNICASTFRAMESATTEMPTED 0x0340 +#define MSP85x0_GE_MSTATX_TXBROADCASTFRAMESATTEMPTED 0x0350 +#define MSP85x0_GE_MSTATX_TXMULTICASTFRAMESATTEMPTED 0x0360 +#define MSP85x0_GE_MSTATX_TXFRAMES64OCTETS 0x0370 +#define MSP85x0_GE_MSTATX_TXFRAMES65TO127OCTETS 0x0380 +#define MSP85x0_GE_MSTATX_TXFRAMES128TO255OCTETS 0x0390 +#define MSP85x0_GE_MSTATX_TXFRAMES256TO511OCTETS 0x03A0 +#define MSP85x0_GE_MSTATX_TXFRAMES512TO1023OCTETS 0x03B0 +#define MSP85x0_GE_MSTATX_TXFRAMES1024TO1518OCTETS 0x03C0 +#define MSP85x0_GE_MSTATX_TXFRAMES1519TOMAXSIZE 0x03D0 +#define MSP85x0_GE_MSTATX_TXVARIABLE 0x03E0 +#define MSP85x0_GE_MSTATX_RXSYSTEMERROR 0x03F0 +#define MSP85x0_GE_MSTATX_SINGLECOLLISION 0x0400 +#define MSP85x0_GE_MSTATX_MULTIPLECOLLISION 0x0410 +#define MSP85x0_GE_MSTATX_DEFERREDXMISSIONS 0x0420 +#define MSP85x0_GE_MSTATX_LATECOLLISIONS 0x0430 +#define MSP85x0_GE_MSTATX_ABORTEDDUETOXSCOLLS 0x0440 + + +/* Interrupt specific defines */ +#define MSP85x0_GE_DEVICE_ID 0x0000 /* Device ID */ +#define MSP85x0_GE_RESET 0x0008 /* Reset reg */ +#define MSP85x0_GE_TSB_CTRL_0 0x0010 /* TSB Control reg 0 */ +#define MSP85x0_GE_CPIF2_GU0 0x0014 /* CPIF2 General Use 0 */ +#define MSP85x0_GE_CPIF2_GENERAL_USE3 0x0020 +#define MSP85x0_GE_INTR_GRP0_STATUS 0x0024 /* General Interrupt Group 0 Status */ +#define MSP85x0_GE_INTR_XDMA_CORE_A 0x002C /* XDMA Channel Interrupt Status, Core A*/ +#define MSP85x0_GE_CPIF2_SET_VECTOR_MSG0 0x0044 +#define MSP85x0_GE_CPIF2_INT_MSG_ADDR0 0x0060 +#define MSP85x0_GE_CPIF2_INT_VECOTR_MODE0 0x0080 +#define MSP85x0_GE_INTR_XDMA_IE 0x0084 /* XDMA Channel Interrupt Enable */ +#define MSP85x0_GE_SDQPF_ECC_INTR 0x280C /* SDQPF ECC Interrupt Status */ + +#define MSP85x0_GE_SDQPF_RXFIFO_CTL 0x2828 /* SDQPF RxFifo Control and Interrupt Enb*/ +#define MSP85x0_GE_SDQPF_RXFIFO_INTR 0x282C /* SDQPF RxFifo Interrupt Status */ +#define MSP85x0_GE_SDQPF_RXFIFO_0 0x2840 /* SDQPF RxFIFO Config */ +#define MSP85x0_GE_SDQPF_RX_THRLD_0 0x2844 +#define MSP85x0_GE_SDQPF_RXFIFO_8 0x28A0 /* SDQPF RxFIFO Config */ +#define MSP85x0_GE_SDQPF_RX_THRLD_8 0x28A4 + +#define MSP85x0_GE_SDQPF_TXFIFO_CTL 0x2928 /* SDQPF TxFifo Control and Interrupt Enb*/ +#define MSP85x0_GE_SDQPF_TXFIFO_INTR 0x292C /* SDQPF TxFifo Interrupt Status */ +#define MSP85x0_GE_SDQPF_TXFIFO_0 0x2940 /* SDQPF TxFIFO Enable */ +#define MSP85x0_GE_SDQPF_TX_THRLD_0 0x2944 /* SDQPF TxFIFO Enable */ +#define MSP85x0_GE_SDQPF_TXFIFO_1 0x294C /* SDQPF TxFIFO Enable */ +#define MSP85x0_GE_SDQPF_TX_THRLD_1 0x2950 /* SDQPF TxFIFO Enable */ + +#define MSP85x0_GE_XDMA_CONFIG 0x3000 /* XDMA Global Configuration */ +#define MSP85x0_GE_XDMA_INTR_SUMMARY 0x3010 /* XDMA Interrupt Summary */ +#define MSP85x0_GE_XDMA_BUFADDRPRE 0x3018 /* XDMA Buffer Address Prefix */ +#define MSP85x0_GE_XDMA_DESCADDRPRE 0x301C /* XDMA Descriptor Address Prefix */ +#define MSP85x0_GE_XDMA_PORTWEIGHT 0x302C /* XDMA Port Weight Configuration */ + +#define MSP85x0_GE_CPIF2_CPXCISR 0x002C +#define MSP85x0_GE_CPIF2_CPGIG0SR 0x0024 +#define MSP85x0_GE_INTR_GRP0_STATUS 0x0024 + +/* Rx MAC defines */ +#define MSP85x0_GE_RMAC_CONFIG_1 0x1200 /* RMAC Configuration 1 */ +#define MSP85x0_GE_RMAC_CONFIG_2 0x1204 /* RMAC Configuration 2 */ +#define MSP85x0_GE_RMAC_MAX_FRAME_LEN 0x1208 /* RMAC Max Frame Length */ +#define MSP85x0_GE_RMAC_STATION_HI 0x120C /* Rx Station Address High */ +#define MSP85x0_GE_RMAC_STATION_MID 0x1210 /* Rx Station Address Middle */ +#define MSP85x0_GE_RMAC_STATION_LOW 0x1214 /* Rx Station Address Low */ +#define MSP85x0_GE_RMAC_LINK_CONFIG 0x1218 /* RMAC Link Configuration */ + +/* Tx MAC defines */ +#define MSP85x0_GE_TMAC_CONFIG_1 0x1240 /* TMAC Configuration 1 */ +#define MSP85x0_GE_TMAC_CONFIG_2 0x1244 /* TMAC Configuration 2 */ +#define MSP85x0_GE_TMAC_IPG 0x1248 /* TMAC Inter-Packet Gap */ +#define MSP85x0_GE_TMAC_STATION_HI 0x124C /* Tx Station Address High */ +#define MSP85x0_GE_TMAC_STATION_MID 0x1250 /* Tx Station Address Middle */ +#define MSP85x0_GE_TMAC_STATION_LOW 0x1254 /* Tx Station Address Low */ +#define MSP85x0_GE_TMAC_MAX_FRAME_LEN 0x1258 /* TMAC Max Frame Length */ +#define MSP85x0_GE_TMAC_MIN_FRAME_LEN 0x125C /* TMAC Min Frame Length */ +#define MSP85x0_GE_TMAC_PAUSE_FRAME_TIME 0x1260 /* TMAC Pause Frame Time */ +#define MSP85x0_GE_TMAC_PAUSE_FRAME_INTERVAL 0x1264 /* TMAC Pause Frame Interval */ + +#define MSP85x0_GE_L1RPP_CONFIG_STS 0x128C +#define MSP85x0_GE_RTIF_CONFIG 0x12CC + +#define MSP85x0_GE_L1TPP_CONFIG 0x1300 +/* GMII register */ +#define MSP85x0_GE_GMII_INTERRUPT_STATUS 0x1348 /* GMII Interrupt Status */ +#define MSP85x0_GE_GMII_CONFIG_GENERAL 0x134C /* GMII Configuration General */ +#define MSP85x0_GE_GMII_CONFIG_MODE 0x1350 /* GMII Configuration Mode */ + +/* Tx and Rx XDMA defines */ + +#define MSP85x0_GE_GXDMA_INT_STS 0x3008 +#define MSP85x0_GE_GXDMA0_DESC_PREFETCH_CNT 0x305C + +#define MSP85x0_GE_INT_COALESCING 0x3030 /* Interrupt Coalescing */ +#define MSP85x0_GE_GDI_PASSPW_CONFIG 0x303C /* Channel 0 XDMA config */ +#define MSP85x0_GE_CHANNEL0_CONFIG 0x3040 /* Channel 0 XDMA config */ +#define MSP85x0_GE_CHANNEL0_TX_DMA_STS 0x3044 /* Channel 0 Tx DMA Status */ +#define MSP85x0_GE_CHANNEL0_RX_DMA_STS 0x3048 /* Channel 0 Rx DMA Status */ +#define MSP85x0_GE_CHANNEL0_INTERRUPT 0x304c /* Channel 0 Interrupt Status */ +#define MSP85x0_GE_GDI_INTERRUPT_ENABLE 0x3050 /* IE for the GDI Errors */ +#define MSP85x0_GE_CHANNEL0_PACKET 0x3060 /* Channel 0 Packet count */ +#define MSP85x0_GE_CHANNEL0_BYTE 0x3064 /* Channel 0 Byte count */ +#define MSP85x0_GE_CHANNEL0_TX_DESC 0x3054 /* Channel 0 Tx first desc */ +#define MSP85x0_GE_CHANNEL0_RX_DESC 0x3058 /* Channel 0 Rx first desc */ +#define MSP85x0_GE_CHANNEL0_RX_DESC_PKT_DRP_THR 0x3074 + +#define MSP85x0_GE_TRTG2_INTERRUPT_IND 0x100C +#define MSP85x0_GE_TRTG_PRIORITY_CHKSUM 0x1038 +#define MSP85x0_GE_TRTG_BYTE_OFFSET_0 0x103C +#define MSP85x0_GE_TRTG_BYTE_OFFSET_1 0x1040 + +/* AFX (Address Filter Exact) register offsets for Slice 0 */ +#define MSP85x0_GE_AFX_EXACT_MATCH_LOW 0x1100 /* AFX Exact Match Address Low*/ +#define MSP85x0_GE_AFX_EXACT_MATCH_MID 0x1104 /* AFX Exact Match Address Mid*/ +#define MSP85x0_GE_AFX_EXACT_MATCH_HIGH 0x1108 /* AFX Exact Match Address Hi */ +#define MSP85x0_GE_AFX_EXACT_MATCH_VID 0x110C /* AFX Exact Match VID */ + +#define MSP85x0_GE_AFX_MULTICAST_HASH_LOW 0x1118 /* AFX Multicast HASH Low */ +#define MSP85x0_GE_AFX_MULTICAST_HASH_MIDLOW 0x111c /* AFX Multicast HASH MidLow */ +#define MSP85x0_GE_AFX_MULTICAST_HASH_MIDHI 0x1120 /* AFX Multicast HASH MidHi*/ +#define MSP85x0_GE_AFX_MULTICAST_HASH_HI 0x1124 /* AFX Multicast HASH Hi */ +#define MSP85x0_GE_AFX_ADDRS_FILTER_CTRL_0 0x1158 /* AFX Address Filter Ctrl 0 */ +#define MSP85x0_GE_AFX_ADDRS_FILTER_CTRL_1 0x115C /* AFX Address Filter Ctrl 1 */ +#define MSP85x0_GE_AFX_ADDRS_FILTER_CTRL_2 0x1160 /* AFX Address Filter Ctrl 2 */ +#define MSP85x0_GE_AFX_ADDRS_FILTER_CTRL_3 0x1164 /* AFX Address Filter Ctrl 2 */ +/* Traffic Groomer block */ +#define MSP85x0_GE_TRTG_CONFIG 0x1000 /* TRTG Config */ + + +#define XDMA_TMAC_RESET 0x80000000 +#define XDMA_TMAC_ENABLE (~(0xC0000000)) + +#define XDMA_RMAC_RESET 0x00100000 +#define XDMA_RMAC_ENABLE (~(0x00180000)) +#endif /* _MSP85x0_GE_H_ */ + diff -Naur a/drivers/net/titan_mdio.c b/drivers/net/titan_mdio.c --- a/drivers/net/titan_mdio.c 2005-07-11 11:28:10.000000000 -0700 +++ b/drivers/net/titan_mdio.c 2006-06-22 11:48:21.000000000 -0700 @@ -41,6 +41,17 @@ /* * Titan MDIO and SCMB registers */ +#ifdef CONFIG_PMC_SEQUOIA + +#define TITAN_GE_SCMB_CONTROL 0x0400 /* SCMB Control */ +#define TITAN_GE_SCMB_CLKA 0x0404 /* SCMB Clock A */ +#define TITAN_GE_MDIO_COMMAND 0x0410 /* MDIO Command */ +#define TITAN_GE_MDIO_DEVICE_PORT_ADDRESS 0x0414 /* MDIO Device and Port addrs */ +#define TITAN_GE_MDIO_DATA 0x0418 /* MDIO Data */ +#define TITAN_GE_MDIO_INTERRUPTS 0x041C /* MDIO Interrupts */ + +#else // CONFIG_PMC_SEQUOIA + #define TITAN_GE_SCMB_CONTROL 0x01c0 /* SCMB Control */ #define TITAN_GE_SCMB_CLKA 0x01c4 /* SCMB Clock A */ #define TITAN_GE_MDIO_COMMAND 0x01d0 /* MDIO Command */ @@ -48,6 +59,8 @@ #define TITAN_GE_MDIO_DATA 0x01d8 /* MDIO Data */ #define TITAN_GE_MDIO_INTERRUPTS 0x01dC /* MDIO Interrupts */ +#endif //CONFIG_PMC_SEQUOIA + /* * Function to poll the MDIO */ @@ -132,6 +145,10 @@ volatile unsigned long val; int retries = 0; +#ifdef CONFIG_PMC_SEQUOIA + dev_addr++; +#endif + /* Setup the PHY device */ again: @@ -181,6 +198,10 @@ { volatile unsigned long val; +#ifdef CONFIG_PMC_SEQUOIA + dev_addr++; +#endif + if (titan_ge_mdio_poll() != TITAN_GE_MDIO_GOOD) return TITAN_GE_MDIO_ERROR; diff -Naur a/drivers/net/titan_mdio.h b/drivers/net/titan_mdio.h --- a/drivers/net/titan_mdio.h 2005-07-11 11:28:10.000000000 -0700 +++ b/drivers/net/titan_mdio.h 2006-06-22 11:48:21.000000000 -0700 @@ -7,8 +7,13 @@ #include #include #include +#ifdef CONFIG_PMC_YOSEMITE #include "titan_ge.h" +#else +#include "msp85x0_ge.h" +#endif +extern unsigned long titan_ge_base; #define TITAN_GE_MDIO_ERROR (-9000) #define TITAN_GE_MDIO_GOOD 0 From zzh.hust@gmail.com Sat Jun 24 09:47:58 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 24 Jun 2006 09:48:07 +0100 (BST) Received: from ug-out-1314.google.com ([66.249.92.168]:39869 "EHLO ug-out-1314.google.com") by ftp.linux-mips.org with ESMTP id S8133466AbWFXIr6 (ORCPT ); Sat, 24 Jun 2006 09:47:58 +0100 Received: by ug-out-1314.google.com with SMTP id k3so1374501ugf for ; Sat, 24 Jun 2006 01:47:58 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=fuHxoNM5WV8gnkCYg1+pAI8dAgLkQBSoNOy48tuIPuGxwV+6AZdU//pfGugw0l27X+r76C2UCukbS02/E9wgFF+m6RkE8ZxKJpDqvXB70s1odh57iGk5ZA2vo0PZSdsXMq3U4LOzh7XqjqRLkWRZ/+xrTh5NKRU3SSAO17i808M= Received: by 10.67.101.8 with SMTP id d8mr3093480ugm; Sat, 24 Jun 2006 01:47:58 -0700 (PDT) Received: by 10.66.242.15 with HTTP; Sat, 24 Jun 2006 01:47:58 -0700 (PDT) Message-ID: <50c9a2250606240147j7011cc21ke96f0ab42fd770d5@mail.gmail.com> Date: Sat, 24 Jun 2006 16:47:58 +0800 From: zhuzhenhua To: linux-mips Subject: does anyone use the ks8841 ethenet card for mips? MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-2022-JP; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11849 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: zzh.hust@gmail.com Precedence: bulk X-list: linux-mips is there any drivers for linux 2.6$B!)(B thanks for any hints Best Regards zhuzhenhua From daniel@caiaq.de Sat Jun 24 14:57:35 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 24 Jun 2006 14:57:43 +0100 (BST) Received: from buzzloop.caiaq.de ([212.112.241.133]:51471 "EHLO buzzloop.caiaq.de") by ftp.linux-mips.org with ESMTP id S8133565AbWFXN5e (ORCPT ); Sat, 24 Jun 2006 14:57:34 +0100 Received: from localhost (localhost [127.0.0.1]) by buzzloop.caiaq.de (Postfix) with ESMTP id C08E77F4028 for ; Sat, 24 Jun 2006 15:57:28 +0200 (CEST) Received: from buzzloop.caiaq.de ([127.0.0.1]) by localhost (buzzloop [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 17798-01 for ; Sat, 24 Jun 2006 15:57:28 +0200 (CEST) Received: from [192.168.1.140] (port-83-236-238-37.static.qsc.de [83.236.238.37]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by buzzloop.caiaq.de (Postfix) with ESMTP id 5A14F7F4024 for ; Sat, 24 Jun 2006 15:57:28 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v750) In-Reply-To: <20060623204835.GA2548@linuxtv.org> References: <5B414347-B938-4E68-812E-627AED1A38B0@caiaq.de> <20060623204835.GA2548@linuxtv.org> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <03F81313-6053-4704-83F5-DF73BC6D1CEC@caiaq.de> Content-Transfer-Encoding: 7bit From: Daniel Mack Subject: Re: smc91x ethernet an DBAU1200 Date: Sat, 24 Jun 2006 15:57:23 +0200 To: linux-mips@linux-mips.org X-Mailer: Apple Mail (2.750) Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11850 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: daniel@caiaq.de Precedence: bulk X-list: linux-mips On Jun 23, 2006, at 10:48 PM, Johannes Stezenbach wrote: >> nfs: server 192.168.1.200 not responding, still trying >> nfs: server 192.168.1.200 not responding, still trying > > I had similar issues with smc91x.c on a different platform, > where the bus it is connected to was rather slow (and no DMA) > -> dropped packets. > > Try to use NFS via TCP, or force a 10Mbit connection > with ethtool or by hacking the driver (ctl_rspeed). > (For me tcp works.) Thanks Johannes, using TCP works fine here, too. Daniel From daniel@caiaq.de Sat Jun 24 15:02:27 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 24 Jun 2006 15:02:36 +0100 (BST) Received: from buzzloop.caiaq.de ([212.112.241.133]:37644 "EHLO buzzloop.caiaq.de") by ftp.linux-mips.org with ESMTP id S8133565AbWFXOC1 (ORCPT ); Sat, 24 Jun 2006 15:02:27 +0100 Received: from localhost (localhost [127.0.0.1]) by buzzloop.caiaq.de (Postfix) with ESMTP id C68307F4028 for ; Sat, 24 Jun 2006 16:02:23 +0200 (CEST) Received: from buzzloop.caiaq.de ([127.0.0.1]) by localhost (buzzloop [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 17274-06 for ; Sat, 24 Jun 2006 16:02:23 +0200 (CEST) Received: from [192.168.1.140] (port-83-236-238-37.static.qsc.de [83.236.238.37]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by buzzloop.caiaq.de (Postfix) with ESMTP id 7DF5A7F4024 for ; Sat, 24 Jun 2006 16:02:23 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v750) Content-Transfer-Encoding: 7bit Message-Id: <4C89D389-49A7-4233-BD55-0315AD423274@caiaq.de> Content-Type: text/plain; charset=US-ASCII; format=flowed To: linux-mips@linux-mips.org From: Daniel Mack Subject: Au1200 SD/MMC again Date: Sat, 24 Jun 2006 16:02:19 +0200 X-Mailer: Apple Mail (2.750) Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11851 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: daniel@caiaq.de Precedence: bulk X-list: linux-mips Hi there, is there any progress on the work of SD/MMC support for Au1200? I followed the thread at http://www.linux-mips.org/archives/linux-mips/2006-05/msg00007.html and wondered whether anyone silently got it to work since then. On my board here, I have the very same effects. Thanks, Daniel From sshtylyov@ru.mvista.com Sat Jun 24 16:23:56 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 24 Jun 2006 16:24:05 +0100 (BST) Received: from rtsoft2.corbina.net ([85.21.88.2]:42642 "HELO mail.dev.rtsoft.ru") by ftp.linux-mips.org with SMTP id S8133565AbWFXPX4 (ORCPT ); Sat, 24 Jun 2006 16:23:56 +0100 Received: (qmail 14170 invoked from network); 24 Jun 2006 19:35:34 -0000 Received: from wasted.dev.rtsoft.ru (HELO ?192.168.1.248?) (192.168.1.248) by mail.dev.rtsoft.ru with SMTP; 24 Jun 2006 19:35:34 -0000 Message-ID: <449D58B2.4060802@ru.mvista.com> Date: Sat, 24 Jun 2006 19:22:26 +0400 From: Sergei Shtylyov Organization: MontaVista Software Inc. User-Agent: Mozilla/5.0 (X11; U; Linux i686; rv:1.7.2) Gecko/20040803 X-Accept-Language: ru, en-us, en-gb MIME-Version: 1.0 To: Linux-MIPS CC: Ralf Baechle Subject: [PATCH] Alchemy counter runs at full CPU speed References: <436FB625.2000302@ru.mvista.com> In-Reply-To: <436FB625.2000302@ru.mvista.com> Content-Type: multipart/mixed; boundary="------------010001020504040509060708" Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11852 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: sshtylyov@ru.mvista.com Precedence: bulk X-list: linux-mips This is a multi-part message in MIME format. --------------010001020504040509060708 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Au1xx0 CPU counter ticks at the full CPU clock speed, not at the halved one. This is not an issue with the current kernel since Alchemy uses its own timer handler here which pays no attention to mips_hpt_frequency, so this is a cleanup type patch (though our kernel had its clock ticking at double speed because of this :-). Signed-off-by: Sergei Shtylyov --------------010001020504040509060708 Content-Type: text/plain; name="Au1xx0-fix-counter-frequency.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="Au1xx0-fix-counter-frequency.patch" Index: linux-mips/arch/mips/au1000/common/time.c =================================================================== --- linux-mips.orig/arch/mips/au1000/common/time.c +++ linux-mips/arch/mips/au1000/common/time.c @@ -287,7 +287,6 @@ unsigned long cal_r4koff(void) #else cpu_speed = (au_readl(SYS_CPUPLL) & 0x0000003f) * AU1000_SRC_CLK; - count = cpu_speed / 2; #endif } else { @@ -296,10 +295,9 @@ unsigned long cal_r4koff(void) * NOTE: some old silicon doesn't allow reading the PLL. */ cpu_speed = (au_readl(SYS_CPUPLL) & 0x0000003f) * AU1000_SRC_CLK; - count = cpu_speed / 2; no_au1xxx_32khz = 1; } - mips_hpt_frequency = count; + mips_hpt_frequency = cpu_speed; // Equation: Baudrate = CPU / (SD * 2 * CLKDIV * 16) set_au1x00_uart_baud_base(cpu_speed / (2 * ((int)(au_readl(SYS_POWERCTRL)&0x03) + 2) * 16)); spin_unlock_irqrestore(&time_lock, flags); --------------010001020504040509060708-- From sshtylyov@ru.mvista.com Sat Jun 24 20:08:16 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 24 Jun 2006 20:08:25 +0100 (BST) Received: from rtsoft2.corbina.net ([85.21.88.2]:47264 "HELO mail.dev.rtsoft.ru") by ftp.linux-mips.org with SMTP id S8133637AbWFXTIQ (ORCPT ); Sat, 24 Jun 2006 20:08:16 +0100 Received: (qmail 14907 invoked from network); 24 Jun 2006 23:19:48 -0000 Received: from wasted.dev.rtsoft.ru (HELO ?192.168.1.248?) (192.168.1.248) by mail.dev.rtsoft.ru with SMTP; 24 Jun 2006 23:19:48 -0000 Message-ID: <449D8D44.70900@ru.mvista.com> Date: Sat, 24 Jun 2006 23:06:44 +0400 From: Sergei Shtylyov Organization: MontaVista Software Inc. User-Agent: Mozilla/5.0 (X11; U; Linux i686; rv:1.7.2) Gecko/20040803 X-Accept-Language: ru, en-us, en-gb MIME-Version: 1.0 To: Domen Puncer CC: Ralf Baechle , linux-mips@linux-mips.org Subject: Re: [patch 5/8] au1xxx: export dbdma functions References: <20060623095703.GA30980@domen.ultra.si> <20060623100021.GE31017@domen.ultra.si> <20060623103343.GE5896@linux-mips.org> <20060623135202.GA9098@nd47.coderock.org> In-Reply-To: <20060623135202.GA9098@nd47.coderock.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11853 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: sshtylyov@ru.mvista.com Precedence: bulk X-list: linux-mips Hello. Domen Puncer wrote: > These are needed for au1550_ac97 module. > Signed-off-by: Domen Puncer > Index: linux-mailed/arch/mips/au1000/common/dbdma.c > =================================================================== > --- linux-mailed.orig/arch/mips/au1000/common/dbdma.c > +++ linux-mailed/arch/mips/au1000/common/dbdma.c > @@ -730,6 +730,8 @@ au1xxx_dbdma_get_dest(u32 chanid, void * > return rv; > } > > +EXPORT_SYMBOL_GPL(au1xxx_dbdma_get_dest); > + > void > au1xxx_dbdma_stop(u32 chanid) > { > @@ -821,6 +823,8 @@ au1xxx_get_dma_residue(u32 chanid) > return rv; > } > > +EXPORT_SYMBOL_GPL(au1xxx_get_dma_residue); > + > void > au1xxx_dbdma_chan_free(u32 chanid) > { I should note that without patch 6 applied (which marks the module as GPL), this patch doesn't help. BTW, the other exports in this module are not GPL only... WBR, Sergei From jcrouse@cosmic.amd.com Sat Jun 24 23:54:50 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 24 Jun 2006 23:55:01 +0100 (BST) Received: from outbound-res.frontbridge.com ([63.161.60.49]:49820 "EHLO outbound1-res-R.bigfish.com") by ftp.linux-mips.org with ESMTP id S8133719AbWFXWyu (ORCPT ); Sat, 24 Jun 2006 23:54:50 +0100 Received: from outbound1-res.bigfish.com (localhost.localdomain [127.0.0.1]) by outbound1-res-R.bigfish.com (Postfix) with ESMTP id 5F7E273439F; Sat, 24 Jun 2006 22:54:43 +0000 (UTC) Received: from mail41-res-R.bigfish.com (unknown [172.18.16.1]) by outbound1-res.bigfish.com (Postfix) with ESMTP id 576C173439D; Sat, 24 Jun 2006 22:54:43 +0000 (UTC) Received: from mail41-res.bigfish.com (localhost.localdomain [127.0.0.1]) by mail41-res-R.bigfish.com (Postfix) with ESMTP id 4C036B92F4B; Sat, 24 Jun 2006 22:54:43 +0000 (UTC) X-BigFish: V Received: by mail41-res (MessageSwitch) id 1151189683219473_17845; Sat, 24 Jun 2006 22:54:43 +0000 (UCT) Received: from amdext4.amd.com (amdext4.amd.com [163.181.251.6]) by mail41-res.bigfish.com (Postfix) with ESMTP id 1CB06B92CFF; Sat, 24 Jun 2006 22:54:42 +0000 (UTC) Received: from SAUSGW01.amd.com (sausgw01.amd.com [163.181.250.21]) by amdext4.amd.com (8.12.11/8.12.11/AMD) with ESMTP id k5OLt8fW004478; Sat, 24 Jun 2006 16:55:23 -0500 Received: from 163.181.22.101 by SAUSGW01.amd.com with ESMTP (AMD SMTP Relay (Email Firewall v6.1.0)); Sat, 24 Jun 2006 17:54:30 -0500 X-Server-Uuid: 8C3DB987-180B-4465-9446-45C15473FD3E Received: from ldcmail.amd.com ([147.5.200.40]) by sausexbh1.amd.com with Microsoft SMTPSVC(6.0.3790.2499); Sat, 24 Jun 2006 17:54:30 -0500 Received: from cosmic.amd.com (cosmic.amd.com [147.5.201.206]) by ldcmail.amd.com (Postfix) with ESMTP id 6077F2028; Sat, 24 Jun 2006 16:54:30 -0600 (MDT) Received: from cosmic.amd.com (localhost [127.0.0.1]) by cosmic.amd.com (8.13.4/8.13.4) with ESMTP id k5ON02wG008370; Sat, 24 Jun 2006 17:00:02 -0600 Received: (from jcrouse@localhost) by cosmic.amd.com ( 8.13.4/8.13.4/Submit) id k5ON02Jj008369; Sat, 24 Jun 2006 17:00:02 -0600 Date: Sat, 24 Jun 2006 17:00:02 -0600 From: "Jordan Crouse" To: "Daniel Mack" cc: linux-mips@linux-mips.org Subject: Re: Au1200 SD/MMC again Message-ID: <20060624230002.GA8277@cosmic.amd.com> References: <4C89D389-49A7-4233-BD55-0315AD423274@caiaq.de> MIME-Version: 1.0 In-Reply-To: <4C89D389-49A7-4233-BD55-0315AD423274@caiaq.de> User-Agent: Mutt/1.5.11 X-OriginalArrivalTime: 24 Jun 2006 22:54:31.0145 (UTC) FILETIME=[276BCD90:01C697E1] X-WSS-ID: 68831D2C40W13781164-01-01 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11854 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: jordan.crouse@amd.com Precedence: bulk X-list: linux-mips On 24/06/06 16:02 +0200, Daniel Mack wrote: > Hi there, > > is there any progress on the work of SD/MMC support for Au1200? > I followed the thread at > > http://www.linux-mips.org/archives/linux-mips/2006-05/msg00007.html > > and wondered whether anyone silently got it to work since then. > On my board here, I have the very same effects. Make sure you try different cards - I have been unable to recreate this problem with the cards I have laying around the office. Jordan -- Jordan Crouse Senior Linux Engineer Advanced Micro Devices, Inc. From yoichi_yuasa@tripeaks.co.jp Mon Jun 26 07:18:51 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 26 Jun 2006 07:19:03 +0100 (BST) Received: from mo31.po.2iij.net ([210.128.50.54]:1863 "EHLO mo31.po.2iij.net") by ftp.linux-mips.org with ESMTP id S8126579AbWFZGSv (ORCPT ); Mon, 26 Jun 2006 07:18:51 +0100 Received: by mo.po.2iij.net (mo31) id k5Q6ImJT045288; Mon, 26 Jun 2006 15:18:48 +0900 (JST) Received: from localhost.localdomain (65.126.232.202.bf.2iij.net [202.232.126.65]) by mbox.po.2iij.net (mbox31) id k5Q6IkLr065883 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 26 Jun 2006 15:18:46 +0900 (JST) Date: Mon, 26 Jun 2006 15:18:46 +0900 From: Yoichi Yuasa To: Kiran Thota Cc: linux-mips@linux-mips.org, netdev@vger.kernel.org, Rajesh_Palani@pmc-sierra.com, ralf@linux-mips.org Subject: Re: [PATCH 6/6] PMC MSP85x0 gigabit ethernet driver Message-Id: <20060626151846.39281449.yoichi_yuasa@tripeaks.co.jp> In-Reply-To: References: Organization: TriPeaks Corporation X-Mailer: Sylpheed version 1.0.4 (GTK+ 1.2.10; i386-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain;