From cw@f00f.org Thu Dec 1 03:51:40 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 01 Dec 2005 03:51:59 +0000 (GMT) Received: from ylpvm12-ext.prodigy.net ([207.115.57.43]:48609 "EHLO ylpvm12.prodigy.net") by ftp.linux-mips.org with ESMTP id S8133917AbVLADvk (ORCPT ); Thu, 1 Dec 2005 03:51:40 +0000 Received: from ylpvm01.prodigy.net (ylpvm01-int.prodigy.net [207.115.5.207]) by ylpvm12.prodigy.net (8.12.10 outbound/8.12.10) with ESMTP id jB13tTv4030788; Wed, 30 Nov 2005 22:55:30 -0500 X-ORBL: [70.132.51.62] Received: from stupidest.org ([70.132.51.62]) by ylpvm01.prodigy.net (8.13.4 dk-milter linux/8.13.4) with ESMTP id jB13xGZv028324; Wed, 30 Nov 2005 22:59:17 -0500 Received: by taniwha.stupidest.org (Postfix, from userid 38689) id 2CE0B4FE060; Wed, 30 Nov 2005 19:55:07 -0800 (PST) Date: Wed, 30 Nov 2005 19:55:07 -0800 From: Chris Wedgwood To: Ralf Baechle Cc: Matej Kupljen , linux-mips@linux-mips.org, Jordan Crouse Subject: Re: MIPS no FP patch Message-ID: <20051201035507.GA32133@taniwha.stupidest.org> References: <1133348852.24526.31.camel@localhost.localdomain> <20051130112821.GB2694@linux-mips.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20051130112821.GB2694@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: 9571 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: cw@f00f.org Precedence: bulk X-list: linux-mips On Wed, Nov 30, 2005 at 11:28:21AM +0000, Ralf Baechle wrote: > We used to have this option but I eventually got rid of it because > people just don't grok that they must enable it in precense of an > FPU. For cores that have FPUs you could have Kconfig "select" it automatically. From david.sanchez@lexbox.fr Thu Dec 1 13:10:23 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 01 Dec 2005 13:10:40 +0000 (GMT) Received: from laf31-5-82-235-130-100.fbx.proxad.net ([82.235.130.100]:4086 "EHLO lexbox.fr") by ftp.linux-mips.org with ESMTP id S8133932AbVLANKW convert rfc822-to-8bit (ORCPT ); Thu, 1 Dec 2005 13:10:22 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8BIT Subject: RE: DbAu1550 copy file corruption X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Date: Thu, 1 Dec 2005 14:10:12 +0100 Message-ID: <17AB476A04B7C842887E0EB1F268111E0271AB@xpserver.intra.lexbox.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: DbAu1550 copy file corruption thread-index: AcX11en5L2oG8EKjREunsxH0TidH0QAj0nAg From: "David Sanchez" To: "Sergei Shtylylov" , 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: 9572 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.sanchez@lexbox.fr Precedence: bulk X-list: linux-mips Hi, As all my pci sata controllers operate up to 66Mhz, I add a divider to the pci clock in the board_setup.c of the au1550 to obtain 32 Mhz pci clock. But the problem still appear... (More the bus is slow, less the problem appear: maybe because it is a timing issue ?) I try the HPT371B (which works for us). I try several PCI sata controllers (Promise PDC20779, PDC 20579, SiliconImage Sil3112, etc...). More I try the drivers provided by Promise instead of the libata. But the problem still appear... Sergei, is the PCI clock frequency issue only for the HPT371N or even for PCI sata controller ? Do you mean that all the users of the dbau1550 needs to set the PCI clock to 32Mhz? Have you try my script on your board? Thanks. David -----Message d'origine----- De : Sergei Shtylylov [mailto:sshtylyov@ru.mvista.com] Envoyé : mercredi 30 novembre 2005 18:46 À : Dan Malek Cc : David Sanchez Objet : Re: DbAu1550 copy file corruption Hello. Dan Malek wrote: > Have you tested this on an NFS partition? Does > the on-board HPT371 work? I know the latter two > used to work, but I don't remember testing a 2.6.10 > kernel, I've been using newer ones. Do you mean HPT371N? It shouldn't work (and does not work for us) since the current driver has severe clocking problems with anything but HPT370/374 on a 66 MHz PCI. So with the default 64 MHz Au1550 PCI clock the driver just locks up; it can only work if you plug in a 33 MHz PCI card to get Au1550 PCI clocked at 32 MHz. I was in the process of fixing this but this work is currently preempted by more urgent stuff... :-( WBR, Sergei From conil.christophe@addi-data.com Thu Dec 1 15:03:45 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 01 Dec 2005 15:04:12 +0000 (GMT) Received: from [62.154.208.154] ([62.154.208.154]:63899 "EHLO firewall1.addi-data.de") by ftp.linux-mips.org with ESMTP id S8134039AbVLAPDp convert rfc822-to-8bit (ORCPT ); Thu, 1 Dec 2005 15:03:45 +0000 Received: from [172.16.2.26] (helo=security01.addi-data.intra) by firewall1.addi-data.de with esmtp (Exim 4.43) id 1Ehq1a-0006oU-9I for linux-mips@linux-mips.org; Thu, 01 Dec 2005 16:07:07 +0100 Received: from security1.addi-data.de (exchange01.addi-data.intra) by security01.addi-data.intra (Clearswift SMTPRS 5.0.9) with ESMTP id for ; Thu, 1 Dec 2005 16:07:06 +0100 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8BIT Subject: get an usleep() with less than 20ms on 2.4.27 X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Thu, 1 Dec 2005 16:07:05 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: get an usleep() with less than 20ms on 2.4.27 Thread-Index: AcX2epQlVpuToN9OS3CENEPXxjXM+QADR/4g From: "Conil.Christophe" 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: 9573 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: Conil.Christophe@addi-data.com Precedence: bulk X-list: linux-mips Hi, I'm using a 2.4.27 Kernel on MIPS. I'm actually programming a USR-Space software which needs high-precision sleep() functions. Actually, by using them, I can't get a sleep time lower than 20 ms. (even with a usleep(1) which should sleep for 1 microsecond) I thought it may came from the Linux default scheduler, so I increased its resolution by modifying HZ and CLOCKS_PER_SEC (I set them to 1000 instead of 100) in the /linux/include/asm-mips/param.h file. I'm now having a minimum usleep time of 2ms, which is better, but still not perfect (since I need at least 1ms) If I continue increasing these 2 values, my kernel doesn't compile because of /linux/include/linux/timex.h. Do you have a clue what could I do to have a non-active (without a while) sleeping time fewer than 2ms? (A sleeping time of 0.5 ms would be perfect) Please excuse my newbieness if I said something not relevant... Thank you very much, Christophe CONIL Content of /linux/include/linux/timex.h -------------------------------------------------------------------------------- #if HZ >= 12 && HZ < 24 # define SHIFT_HZ 4 [...] #elif HZ >= 768 && HZ < 1536 # define SHIFT_HZ 10 #else # error You lose. < #endif -------------------------------------------------------------------------------- Content of /linux/include/asm-mips/param.h -------------------------------------------------------------------------------- #ifndef _ASM_PARAM_H #define _ASM_PARAM_H #ifndef HZ #ifdef __KERNEL__ /* Safeguard against user stupidity  */ #ifdef _SYS_PARAM_H #error Do not include with __KERNEL__ defined! #endif #include /* This is the internal value of HZ, that is the rate at which the jiffies    counter is increasing.  This value is independent from the external value    and can be changed in order to suit the hardware and application    requirements.  */ #  define HZ 1000 /* CC : Previous value was 100 */ #  define hz_to_std(a) (a) #else /* defined(__KERNEL__)  */ /* This is the external value of HZ as seen by user programs.  Don't change    unless you know what you're doing - changing breaks binary compatibility.  */ #define HZ 100  #endif /* defined(__KERNEL__)  */ #endif /* defined(HZ)  */ [...] #ifdef __KERNEL__ # define CLOCKS_PER_SEC     1000     /* frequency at which times() counts */ /* CC : Previous value was 100 */ #endif #endif /* _ASM_PARAM_H */ -------------------------------------------------------------------------------- ********************************************************************** 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 zzh.hust@gmail.com Fri Dec 2 07:09:01 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 02 Dec 2005 07:09:20 +0000 (GMT) Received: from wproxy.gmail.com ([64.233.184.203]:58473 "EHLO wproxy.gmail.com") by ftp.linux-mips.org with ESMTP id S8133536AbVLBHJB convert rfc822-to-8bit (ORCPT ); Fri, 2 Dec 2005 07:09:01 +0000 Received: by wproxy.gmail.com with SMTP id i11so6275wra for ; Thu, 01 Dec 2005 23:12:35 -0800 (PST) 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=d0ntXKGDNs96c1K3P3C3NbsChfQz9FhL2+3NW+RihgoBL3X85Tqg/7QsSpWSsBG1CtdsnmalRj65+M2kFyanWNh5miud16Rz9WPT3s/wFF9dkbe+4m8/CvAiqGsQAM07Gt0cS5JJqCCoC6kfS/QP+VPXEXzKswbqINhglA3Afdo= Received: by 10.54.63.18 with SMTP id l18mr167495wra; Thu, 01 Dec 2005 23:12:35 -0800 (PST) Received: by 10.54.129.5 with HTTP; Thu, 1 Dec 2005 23:12:35 -0800 (PST) Message-ID: <50c9a2250512012312u47bbe09eh9e4f6b8edb0d0d9d@mail.gmail.com> Date: Fri, 2 Dec 2005 15:12:35 +0800 From: zhuzhenhua To: linux-mips@linux-mips.org Subject: where to set the BEV to normal of status in kernel source? MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT 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: 9574 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 don't find it in load_mmu(), who can point out for me? thanks! is that must be set in bootloader? Best regards zhuzhenhua From florian.delizy@sagem.com Fri Dec 2 13:38:58 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 02 Dec 2005 13:39:16 +0000 (GMT) Received: from ns1.sagem.com ([62.160.59.65]:43170 "EHLO mx1.sagem.com") by ftp.linux-mips.org with ESMTP id S8133590AbVLBNi6 (ORCPT ); Fri, 2 Dec 2005 13:38:58 +0000 To: linux-mips@linux-mips.org Subject: Re : where to set the BEV to normal of status in kernel source? MIME-Version: 1.0 Message-ID: From: Florian DELIZY Date: Fri, 2 Dec 2005 14:42:28 +0100 Content-Type: multipart/alternative; boundary="=_alternative 004B4D69C12570CB_=" 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: 9575 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: florian.delizy@sagem.com Precedence: bulk X-list: linux-mips Message en plusieurs parties au format MIME --=_alternative 004B4D69C12570CB_= Content-Type: text/plain; charset="us-ascii" Subject : where to set the BEV to normal of status in kernel source? > i don't find it in load_mmu(), who can point out for me? > thanks! Well, if you are speaking about the BEV flag from the Status (SR) register (CP0_STATUS aka $12 of the 1st coprocessor) then it controls the interruption/exception handler place, I don't see the relation with mmu ... > is that must be set in bootloader? OK, I see, it should be set to 0 by the boot loader so that the TLB exceptions (related to the MMU) goes in RAM. So the kernel does not change it actually and hope the boot loader did. -- Florian Delizy --=_alternative 004B4D69C12570CB_= Content-Type: text/html; charset="us-ascii"


Subject : where to set the BEV to normal of status in kernel source?
> i don't find it in load_mmu(), who can point out for me?
> thanks!

Well, if you are speaking about the BEV flag from the Status (SR) register (CP0_STATUS aka $12 of the 1st coprocessor)
then it controls the interruption/exception handler place, I don't see the relation with mmu ...

> is that must be set in bootloader?

OK, I see, it should be set to 0 by the boot loader so that the TLB exceptions (related to the MMU) goes in RAM. So
the kernel does not change it actually and hope the boot loader did.

-- Florian Delizy





--=_alternative 004B4D69C12570CB_=-- From kevink@mips.com Fri Dec 2 13:48:09 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 02 Dec 2005 13:48:26 +0000 (GMT) Received: from 209-232-97-206.ded.pacbell.net ([209.232.97.206]:65462 "EHLO dns0.mips.com") by ftp.linux-mips.org with ESMTP id S8133594AbVLBNsJ (ORCPT ); Fri, 2 Dec 2005 13:48:09 +0000 Received: from mercury.mips.com (sbcns-dmz [209.232.97.193]) by dns0.mips.com (8.12.11/8.12.11) with ESMTP id jB2Dpd55011699; Fri, 2 Dec 2005 05:51:40 -0800 (PST) Received: from [192.168.236.16] (grendel [192.168.236.16]) by mercury.mips.com (8.12.9/8.12.11) with ESMTP id jB2Dpblk008895; Fri, 2 Dec 2005 05:51:38 -0800 (PST) Message-ID: <439051B5.9060500@mips.com> Date: Fri, 02 Dec 2005 14:52:53 +0100 From: "Kevin D. Kissell" User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Florian DELIZY CC: linux-mips@linux-mips.org Subject: Re: Re : where to set the BEV to normal of status in kernel source? References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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: 9576 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 BEV bit of Status is cleared by the macro setup_c0_status_pri which is invoked in kernel_entry. See arch/mips/kernel/head.S. It's of course possible that a bootloader will already have cleared it, but it should not be necessary. grep is your friend. ;o) Regards, Kevin K. Florian DELIZY wrote: > Subject : where to set the BEV to normal of status in kernel source? > >>i don't find it in load_mmu(), who can point out for me? >>thanks! > > > Well, if you are speaking about the BEV flag from the Status (SR) register > (CP0_STATUS aka $12 of the 1st coprocessor) > then it controls the interruption/exception handler place, I don't see the > relation with mmu ... > > >>is that must be set in bootloader? > > > OK, I see, it should be set to 0 by the boot loader so that the TLB > exceptions (related to the MMU) goes in RAM. So > the kernel does not change it actually and hope the boot loader did. > > -- Florian Delizy > > > > > > From jcrouse@cosmic.amd.com Fri Dec 2 18:50:01 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 02 Dec 2005 18:50:21 +0000 (GMT) Received: from amdext4.amd.com ([163.181.251.6]:38566 "EHLO amdext4.amd.com") by ftp.linux-mips.org with ESMTP id S8133864AbVLBSuB (ORCPT ); Fri, 2 Dec 2005 18:50:01 +0000 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 jB2IrSYC030656; Fri, 2 Dec 2005 12:53:28 -0600 Received: from 163.181.250.1 by SAUSGW01.amd.com with ESMTP (AMD SMTP Relay (Email Firewall v6.1.0)); Fri, 02 Dec 2005 12:53:22 -0600 X-Server-Uuid: 8C3DB987-180B-4465-9446-45C15473FD3E Received: from ldcmail.amd.com (ldcmail.amd.com [147.5.200.40]) by amdint2.amd.com (8.12.8/8.12.8/AMD) with ESMTP id jB2IrLTw003922; Fri, 2 Dec 2005 12:53:21 -0600 (CST) Received: from cosmic.amd.com (cosmic.amd.com [147.5.201.206]) by ldcmail.amd.com (Postfix) with ESMTP id 6FAD92026; Fri, 2 Dec 2005 11:53:21 -0700 (MST) Received: from cosmic.amd.com (localhost [127.0.0.1]) by cosmic.amd.com (8.13.4/8.13.4) with ESMTP id jB2J18LJ031378; Fri, 2 Dec 2005 12:01:08 -0700 Received: (from jcrouse@localhost) by cosmic.amd.com ( 8.13.4/8.13.4/Submit) id jB2J188A031377; Fri, 2 Dec 2005 12:01:08 -0700 Date: Fri, 2 Dec 2005 12:01:08 -0700 From: "Jordan Crouse" To: linux-mips@linux-mips.org cc: ralf@linux-mips.org, drzeus-wbsd@drzeus.cx Subject: [PATCH] ALCHEMY: Add SD support to AU1200 MMC/SD driver Message-ID: <20051202190108.GF28227@cosmic.amd.com> MIME-Version: 1.0 User-Agent: Mutt/1.5.11 X-WSS-ID: 6F8E47A840G499976-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: 9577 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 Add SD support to the AU1200 MMC driver. This can be added post 2.6.15, I'm just sending them out today so the various maintainers can get them queued up. Signed-off-by: Jordan Crouse --- drivers/mmc/au1xmmc.c | 124 ++++++++++++++++++++++++++++--------------------- 1 files changed, 71 insertions(+), 53 deletions(-) diff --git a/drivers/mmc/au1xmmc.c b/drivers/mmc/au1xmmc.c index cb32a08..c8c8f29 100644 --- a/drivers/mmc/au1xmmc.c +++ b/drivers/mmc/au1xmmc.c @@ -99,16 +99,24 @@ static inline void IRQ_ON(struct au1xmmc au_sync(); } -static inline void FLUSH_FIFO(struct au1xmmc_host *host) +/* Turn on the FIFO flush - the fifo will be returned to active right + * before data transfer + */ + +static inline void FLUSH_FIFO_ON(struct au1xmmc_host *host) { u32 val = au_readl(HOST_CONFIG2(host)); + val |= SD_CONFIG2_FF; + au_writel(val, HOST_CONFIG2(host)); + au_sync(); +} - au_writel(val | SD_CONFIG2_FF, HOST_CONFIG2(host)); - au_sync_delay(1); - - /* SEND_STOP will turn off clock control - this re-enables it */ - val &= ~SD_CONFIG2_DF; +static inline void FIFO_ACTIVE(struct au1xmmc_host *host) +{ + u32 val = au_readl(HOST_CONFIG2(host)); + /* SEND_STOP will turn off clock control - this re-enables it */ + val &= ~(SD_CONFIG2_DF | SD_CONFIG2_FF); au_writel(val, HOST_CONFIG2(host)); au_sync(); } @@ -124,8 +132,8 @@ static inline void IRQ_OFF(struct au1xmm static inline void SEND_STOP(struct au1xmmc_host *host) { - /* We know the value of CONFIG2, so avoid a read we don't need */ - u32 mask = SD_CONFIG2_EN; + /* Penalty box for Jordan - NEVER ASSUME! */ + u32 mask = au_readl(HOST_CONFIG2(host)); WARN_ON(host->status != HOST_S_DATA); host->status = HOST_S_STOP; @@ -169,7 +177,7 @@ static void au1xmmc_finish_request(struc host->flags &= HOST_F_ACTIVE; host->dma.len = 0; - host->dma.dir = 0; + host->dma.dir = DMA_BIDIRECTIONAL; host->pio.index = 0; host->pio.offset = 0; @@ -179,6 +187,9 @@ static void au1xmmc_finish_request(struc bcsr->disk_leds |= (1 << 8); + /* Flush the FIFO until our next request */ + FLUSH_FIFO_ON(host); + mmc_request_done(host->mmc, mrq); } @@ -196,7 +207,11 @@ static int au1xmmc_send_command(struct a switch(cmd->flags) { case MMC_RSP_R1: - mmccmd |= SD_CMD_RT_1; + if (cmd->opcode == 0x03 && host->mmc->mode == MMC_MODE_SD) + mmccmd |= SD_CMD_RT_6; + else + mmccmd |= SD_CMD_RT_1; + break; case MMC_RSP_R1B: mmccmd |= SD_CMD_RT_1B; @@ -504,8 +519,8 @@ static void au1xmmc_cmd_complete(struct r[3] = au_readl(host->iobase + SD_RESP0); /* The CRC is omitted from the response, so really we only got - * 120 bytes, but the engine expects 128 bits, so we have to shift - * things up + * 120 bytes, but the engine expects 128 bits, so we have to + * shift things up */ for(i = 0; i < 4; i++) { @@ -576,9 +591,8 @@ au1xmmc_prepare_data(struct au1xmmc_host { int datalen = data->blocks * (1 << data->blksz_bits); - - if (dma != 0) - host->flags |= HOST_F_DMA; + int i = 0; + u32 channel; if (data->flags & MMC_DATA_READ) host->flags |= HOST_F_RECV; @@ -588,8 +602,6 @@ au1xmmc_prepare_data(struct au1xmmc_host if (host->mrq->stop) host->flags |= HOST_F_STOP; - host->dma.dir = DMA_BIDIRECTIONAL; - host->dma.len = dma_map_sg(mmc_dev(host->mmc), data->sg, data->sg_len, host->dma.dir); @@ -598,9 +610,21 @@ au1xmmc_prepare_data(struct au1xmmc_host au_writel((1 << data->blksz_bits) - 1, HOST_BLKSIZE(host)); - if (host->flags & HOST_F_DMA) { - int i; - u32 channel = DMA_CHANNEL(host); + if (dma == 0) { + host->pio.index = 0; + host->pio.offset = 0; + host->pio.len = datalen; + + if (host->flags & HOST_F_XMIT) + IRQ_ON(host, SD_CONFIG_TH); + else + IRQ_ON(host, SD_CONFIG_NE); + + return MMC_ERR_NONE; + } + + host->flags |= HOST_F_DMA; + channel = DMA_CHANNEL(host); au1xxx_dbdma_stop(channel); @@ -611,7 +635,7 @@ au1xmmc_prepare_data(struct au1xmmc_host int len = (datalen > sg_len) ? sg_len : datalen; - if (i == host->dma.len - 1) + if (i == (host->dma.len - 1)) flags = DDMA_FLAGS_IE; if (host->flags & HOST_F_XMIT){ @@ -627,23 +651,11 @@ au1xmmc_prepare_data(struct au1xmmc_host len, flags); } - if (!ret) + if (ret == 0) goto dataerr; datalen -= len; } - } - else { - host->pio.index = 0; - host->pio.offset = 0; - host->pio.len = datalen; - - if (host->flags & HOST_F_XMIT) - IRQ_ON(host, SD_CONFIG_TH); - else - IRQ_ON(host, SD_CONFIG_NE); - //IRQ_ON(host, SD_CONFIG_RA|SD_CONFIG_RF); - } return MMC_ERR_NONE; @@ -671,7 +683,7 @@ static void au1xmmc_request(struct mmc_h bcsr->disk_leds &= ~(1 << 8); if (mrq->data) { - FLUSH_FIFO(host); + FIFO_ACTIVE(host); ret = au1xmmc_prepare_data(host, mrq->data); } @@ -734,6 +746,20 @@ static void au1xmmc_set_ios(struct mmc_h au1xmmc_set_clock(host, ios->clock); host->clock = ios->clock; } + + /* Set the bus width for SD */ + + if (ios->bus_width != host->bus_width) { + u32 val; + val = au_readl(HOST_CONFIG2(host)); + val &= ~(SD_CONFIG2_WB); + val |= (ios->bus_width == MMC_BUS_WIDTH_4) ? SD_CONFIG2_WB : 0; + + au_writel(val, HOST_CONFIG2(host)); + au_sync(); + + host->bus_width = ios->bus_width; + } } static void au1xmmc_dma_callback(int irq, void *dev_id, struct pt_regs *regs) @@ -778,24 +804,8 @@ static irqreturn_t au1xmmc_irq(int irq, /* In PIO mode, interrupts might still be enabled */ IRQ_OFF(host, SD_CONFIG_NE | SD_CONFIG_TH); - - //IRQ_OFF(host, SD_CONFIG_TH|SD_CONFIG_RA|SD_CONFIG_RF); tasklet_schedule(&host->finish_task); } -#if 0 - else if (status & SD_STATUS_DD) { - - /* Sometimes we get a DD before a NE in PIO mode */ - - if (!(host->flags & HOST_F_DMA) && - (status & SD_STATUS_NE)) - au1xmmc_receive_pio(host); - else { - au1xmmc_data_complete(host, status); - //tasklet_schedule(&host->data_task); - } - } -#endif else if (status & (SD_STATUS_CR)) { if (host->status == HOST_S_CMD) au1xmmc_cmd_complete(host,status); @@ -875,9 +885,15 @@ static void au1xmmc_init_dma(struct au1x host->rx_chan = rxchan; } +static int au1xmmc_get_ro(struct mmc_host *mmc) { + struct au1xmmc_host *host = mmc_priv(mmc); + return au1xmmc_card_readonly(host); +} + struct mmc_host_ops au1xmmc_ops = { .request = au1xmmc_request, .set_ios = au1xmmc_set_ios, + .get_ro = au1xmmc_get_ro, }; static int au1xmmc_probe(struct device *dev) @@ -914,6 +930,7 @@ static int au1xmmc_probe(struct device * mmc->max_seg_size = AU1XMMC_DESCRIPTOR_SIZE; mmc->max_phys_segs = AU1XMMC_DESCRIPTOR_COUNT; + mmc->caps = MMC_CAP_4_BIT_DATA; mmc->ocr_avail = AU1XMMC_OCR; host = mmc_priv(mmc); @@ -923,7 +940,9 @@ static int au1xmmc_probe(struct device * host->iobase = au1xmmc_card_table[host->id].iobase; host->clock = 0; host->power_mode = MMC_POWER_OFF; - + + host->bus_width = MMC_BUS_WIDTH_1; + host->flags = au1xmmc_card_inserted(host) ? HOST_F_ACTIVE : 0; host->status = HOST_S_IDLE; @@ -1017,4 +1036,3 @@ MODULE_AUTHOR("Advanced Micro Devices, I MODULE_DESCRIPTION("MMC/SD driver for the Alchemy Au1XXX"); MODULE_LICENSE("GPL"); #endif - From jcrouse@cosmic.amd.com Fri Dec 2 18:51:12 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 02 Dec 2005 18:51:34 +0000 (GMT) Received: from amdext4.amd.com ([163.181.251.6]:54182 "EHLO amdext4.amd.com") by ftp.linux-mips.org with ESMTP id S8133864AbVLBSvL (ORCPT ); Fri, 2 Dec 2005 18:51:11 +0000 Received: from SAUSGW02.amd.com (sausgw02.amd.com [163.181.250.22]) by amdext4.amd.com (8.12.11/8.12.11/AMD) with ESMTP id jB2Ishmh031036; Fri, 2 Dec 2005 12:54:43 -0600 Received: from 163.181.250.1 by SAUSGW01.amd.com with ESMTP (AMD SMTP Relay (Email Firewall v6.1.0)); Fri, 02 Dec 2005 12:54:37 -0600 X-Server-Uuid: 8C3DB987-180B-4465-9446-45C15473FD3E Received: from ldcmail.amd.com (ldcmail.amd.com [147.5.200.40]) by amdint2.amd.com (8.12.8/8.12.8/AMD) with ESMTP id jB2IsaTw004122; Fri, 2 Dec 2005 12:54:36 -0600 (CST) Received: from cosmic.amd.com (cosmic.amd.com [147.5.201.206]) by ldcmail.amd.com (Postfix) with ESMTP id 75138202D; Fri, 2 Dec 2005 11:54:36 -0700 (MST) Received: from cosmic.amd.com (localhost [127.0.0.1]) by cosmic.amd.com (8.13.4/8.13.4) with ESMTP id jB2J2NDU031398; Fri, 2 Dec 2005 12:02:23 -0700 Received: (from jcrouse@localhost) by cosmic.amd.com ( 8.13.4/8.13.4/Submit) id jB2J2NEF031397; Fri, 2 Dec 2005 12:02:23 -0700 Date: Fri, 2 Dec 2005 12:02:23 -0700 From: "Jordan Crouse" To: linux-mips@linux-mips.org cc: ralf@linux-mips.org Subject: [PATCH] ALCHEMY: SPI driver for Au1200 Message-ID: <20051202190223.GG28227@cosmic.amd.com> MIME-Version: 1.0 User-Agent: Mutt/1.5.11 X-WSS-ID: 6F8E47E740G500239-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: 9578 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 A SPI driver for the Au1200 processor. Sending now so it can be queued for the post 2.6.15 rush. Signed-off-by: Jordan Crouse --- arch/mips/au1000/common/clocks.c | 2 drivers/char/Kconfig | 4 drivers/char/Makefile | 1 drivers/char/au1xxx_psc_spi.c | 492 +++++++++++++++++++++++++++++ include/asm-mips/mach-au1x00/au1550_spi.h | 38 ++ 5 files changed, 536 insertions(+), 1 deletions(-) diff --git a/arch/mips/au1000/common/clocks.c b/arch/mips/au1000/common/clocks.c index 3ce6cac..6dbc87a 100644 --- a/arch/mips/au1000/common/clocks.c +++ b/arch/mips/au1000/common/clocks.c @@ -46,7 +46,7 @@ unsigned int get_au1x00_speed(void) { return au1x00_clock; } - +EXPORT_SYMBOL(get_au1x00_speed); /* diff --git a/drivers/char/Kconfig b/drivers/char/Kconfig index 2b0cf62..5501b12 100644 --- a/drivers/char/Kconfig +++ b/drivers/char/Kconfig @@ -351,6 +351,10 @@ config AU1XXX_CIM tristate "Au1200 Camera Interface Module (CIM)" depends on MIPS && SOC_AU1X00 && I2C_AU1550 +config AU1XXX_PSC_SPI + tristate ' Alchemy Au1550/Au1200 PSC SPI support' + depends on MIPS && SOC_AU1X00 && !I2C_AU1550 + config SIBYTE_SB1250_DUART bool "Support for BCM1xxx onchip DUART" depends on MIPS && SIBYTE_SB1xxx_SOC=y diff --git a/drivers/char/Makefile b/drivers/char/Makefile index 6629394..b8bcfeb 100644 --- a/drivers/char/Makefile +++ b/drivers/char/Makefile @@ -83,6 +83,7 @@ obj-$(CONFIG_AU1000_GPIO) += au1000_gpio obj-$(CONFIG_AU1000_USB_TTY) += au1000_usbtty.o obj-$(CONFIG_AU1000_USB_RAW) += au1000_usbraw.o obj-$(CONFIG_AU1XXX_CIM) += au1xxx_cim.o +obj-$(CONFIG_AU1XXX_PSC_SPI) += au1xxx_psc_spi.o obj-$(CONFIG_PPDEV) += ppdev.o obj-$(CONFIG_NWBUTTON) += nwbutton.o obj-$(CONFIG_NWFLASH) += nwflash.o diff --git a/drivers/char/au1xxx_psc_spi.c b/drivers/char/au1xxx_psc_spi.c new file mode 100644 index 0000000..66d99e0 --- /dev/null +++ b/drivers/char/au1xxx_psc_spi.c @@ -0,0 +1,492 @@ +/* + * Driver for Alchemy Au1550 SPI on the PSC. + * + * Copyright 2004 Embedded Edge, LLC. + * dan@embeddededge.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 +#include +#include +#include +#include +#include +#include +#include + +#ifdef CONFIG_MIPS_PB1550 +#include +#endif + +#ifdef CONFIG_MIPS_DB1550 +#include +#endif + +#ifdef CONFIG_MIPS_PB1200 +#include +#endif + +#ifdef CONFIG_MIPS_DB1200 +#include +#endif + +/* This is just a simple programmed I/O SPI interface on the PSC of the 1550. + * We support open, close, write, and ioctl. The SPI is a full duplex + * interface, you can't read without writing. So, the write system call + * copies the bytes out to the SPI, and whatever is returned is placed + * in the same buffer. Kinda weird, maybe we'll change it, but for now + * it works OK. + * I didn't implement any DMA yet, and it's a debate about the necessity. + * The SPI clocks are usually quite fast, so data is sent/received as + * quickly as you can stuff the FIFO. The overhead of DMA and interrupts + * are usually far greater than the data transfer itself. If, however, + * we find applications that move large amounts of data, we may choose + * use the overhead of buffering and DMA to do the work. + */ + +/* The maximum clock rate specified in the manual is 2mHz. +*/ +#define MAX_BAUD_RATE (2 * 1000000) +#define PSC_INTCLK_RATE (32 * 1000000) + +static int inuse; + +/* We have to know what the user requested for the data length + * so we know how to stuff the fifo. The FIFO is 32 bits wide, + * and we have to load it with the bits to go in a single transfer. + */ +static uint spi_datalen; + +static int +au1550spi_master_done( int ms ) +{ + int timeout=ms; + volatile psc_spi_t *sp; + + sp = (volatile psc_spi_t *)SPI_PSC_BASE; + + /* Loop until MD is set or timeout has expired */ + while(!(sp->psc_spievent & PSC_SPIEVNT_MD) && timeout--) udelay(1000); + + if ( !timeout ) + return 0; + else + sp->psc_spievent |= PSC_SPIEVNT_MD; + + return 1; +} + +static int +au1550spi_open(struct inode *inode, struct file *file) +{ + if (inuse) + return -EBUSY; + + inuse = 1; + + + return 0; +} + +static ssize_t +au1550spi_write(struct file *fp, const char *bp, size_t count, loff_t *ppos) +{ + int bytelen, i; + size_t rcount, retval; + unsigned char sb, *rp, *wp; + uint fifoword, pcr, stat; + volatile psc_spi_t *sp; + + /* Get the number of bytes per transfer. + */ + bytelen = ((spi_datalen - 1) / 8) + 1; + + /* User needs to send us multiple of this count. + */ + if ((count % bytelen) != 0) + return -EINVAL; + + rp = wp = (unsigned char *)bp; + retval = rcount = count; + + /* Reset the FIFO. + */ + sp = (volatile psc_spi_t *)SPI_PSC_BASE; + sp->psc_spipcr = (PSC_SPIPCR_RC | PSC_SPIPCR_TC); + au_sync(); + do { + pcr = sp->psc_spipcr; + au_sync(); + } while (pcr != 0); + + /* Prime the transmit FIFO. + */ + while (count > 0) { + fifoword = 0; + for (i=0; ipsc_spitxrx = fifoword; + au_sync(); + stat = sp->psc_spistat; + au_sync(); + if (stat & PSC_SPISTAT_TF) + break; + } + + /* Start the transfer. + */ + sp->psc_spipcr = PSC_SPIPCR_MS; + au_sync(); + + /* Now, just keep the transmit fifo full and empty the receive. + */ + while (count > 0) { + stat = sp->psc_spistat; + au_sync(); + while ((stat & PSC_SPISTAT_RE) == 0) { + fifoword = sp->psc_spitxrx; + au_sync(); + for (i=0; i>= 8; + rp++; + } + rcount -= bytelen; + stat = sp->psc_spistat; + au_sync(); + } + if ((stat & PSC_SPISTAT_TF) == 0) { + fifoword = 0; + for (i=0; ipsc_spitxrx = fifoword; + au_sync(); + } + } + + /* All of the bytes for transmit have been written. Hang + * out waiting for any residual bytes that are yet to be + * read from the fifo. + */ + while (rcount > 0) { + stat = sp->psc_spistat; + au_sync(); + if ((stat & PSC_SPISTAT_RE) == 0) { + fifoword = sp->psc_spitxrx; + au_sync(); + for (i=0; i>= 8; + rp++; + } + rcount -= bytelen; + } + } + + /* Wait for MasterDone event. 30ms timeout */ + if (!au1550spi_master_done(30) ) retval = -EFAULT; + return retval; +} + +static int +au1550spi_release(struct inode *inode, struct file *file) +{ + + inuse = 0; + + return 0; +} + +/* Set the baud rate closest to the request, then return the actual + * value we are using. + */ +static uint +set_baud_rate(uint baud) +{ + uint rate, tmpclk, brg, ctl, stat; + volatile psc_spi_t *sp; + + /* For starters, the input clock is divided by two. + */ + tmpclk = PSC_INTCLK_RATE/2; + + rate = tmpclk / baud; + + /* The dividers work as follows: + * baud = tmpclk / (2 * (brg + 1)) + */ + brg = (rate/2) - 1; + + /* Test BRG to ensure it will fit into the 6 bits allocated. + */ + + /* Make sure the device is disabled while we make the change. + */ + sp = (volatile psc_spi_t *)SPI_PSC_BASE; + ctl = sp->psc_spicfg; + au_sync(); + sp->psc_spicfg = ctl & ~PSC_SPICFG_DE_ENABLE; + au_sync(); + ctl = PSC_SPICFG_CLR_BAUD(ctl); + ctl |= PSC_SPICFG_SET_BAUD(brg); + sp->psc_spicfg = ctl; + au_sync(); + + /* If the device was running prior to getting here, wait for + * it to restart. + */ + if (ctl & PSC_SPICFG_DE_ENABLE) { + do { + stat = sp->psc_spistat; + au_sync(); + } while ((stat & PSC_SPISTAT_DR) == 0); + } + + /* Return the actual value. + */ + rate = tmpclk / (2 * (brg + 1)); + + return(rate); +} + +static uint +set_word_len(uint len) +{ + uint ctl, stat; + volatile psc_spi_t *sp; + + if ((len < 4) || (len > 24)) + return -EINVAL; + + /* Make sure the device is disabled while we make the change. + */ + sp = (volatile psc_spi_t *)SPI_PSC_BASE; + ctl = sp->psc_spicfg; + au_sync(); + sp->psc_spicfg = ctl & ~PSC_SPICFG_DE_ENABLE; + au_sync(); + ctl = PSC_SPICFG_CLR_LEN(ctl); + ctl |= PSC_SPICFG_SET_LEN(len); + sp->psc_spicfg = ctl; + au_sync(); + + /* If the device was running prior to getting here, wait for + * it to restart. + */ + if (ctl & PSC_SPICFG_DE_ENABLE) { + do { + stat = sp->psc_spistat; + au_sync(); + } while ((stat & PSC_SPISTAT_DR) == 0); + } + + return 0; +} + +static uint +set_clk_src(void) +{ + uint clk, rate; + +/* Wire up Freq3 as a clock for the SPI. The PSC does + * factor of 2 divisor, so run a higher rate so we can + * get some granularity to the clock speeds. + * We can't do this in board set up because the frequency + * is computed too late. + */ + rate = get_au1x00_speed(); + rate /= PSC_INTCLK_RATE; + + + + /* The FRDIV in the frequency control is (FRDIV + 1) * 2 + */ + rate /=2; + rate--; + clk = au_readl(SYS_FREQCTRL1); + + au_sync(); + clk &= ~SYS_FC_FRDIV3_MASK; + clk |= (rate << SYS_FC_FRDIV3_BIT); + clk |= SYS_FC_FE3; + au_writel(clk, SYS_FREQCTRL1); + au_sync(); + + /* Set up the clock source routing to get Freq3 to PSC0_intclk. + */ + clk = au_readl(SYS_CLKSRC); + au_sync(); +#if defined(CONFIG_SOC_AU1200) + clk &= ~SYS_CS_ME0_MASK; + clk |= (5 << 22); +#elif defined (CONFIG_SOC_AU1550) + clk &= ~0x03e0; + clk |= (5 << 7); +#endif + au_writel(clk, SYS_CLKSRC); + au_sync(); + + /* Set up GPIO pin function to drive PSC0_SYNC1, which is + * the SPI Select. + */ + clk = au_readl(SYS_PINFUNC); + au_sync(); +#if defined(CONFIG_SOC_AU1200) + clk |= (0x1 <<17); + clk &= ~SYS_PINFUNC_P0B; +#elif defined (CONFIG_SOC_AU1550) + clk |= 1; +#endif + au_writel(clk, SYS_PINFUNC); + au_sync(); + + return 0; +} + +static int +au1550spi_ioctl(struct inode *inode, struct file *file, + unsigned int cmd, unsigned long arg) +{ + int status; + u32 val; + + status = 0; + + switch(cmd) { + case AU1550SPI_WORD_LEN: + status = set_word_len(arg); + break; + + case AU1550SPI_SET_BAUD: + if (get_user(val, (u32 *)arg)) + return -EFAULT; + + val = set_baud_rate(val); + if (put_user(val, (u32 *)arg)) + return -EFAULT; + break; + + default: + status = -ENOIOCTLCMD; + + } + + return status; +} + +static struct file_operations au1550spi_fops = +{ .owner = THIS_MODULE, + .write = au1550spi_write, + .ioctl = au1550spi_ioctl, + .open = au1550spi_open, + .release = au1550spi_release, +}; + + +static struct miscdevice au1550spi_miscdev = +{ + .minor = MISC_DYNAMIC_MINOR, + .name = "au1550_spi", + .fops = &au1550spi_fops, +}; + + +int __init +au1550spi_init(void) +{ + uint stat; + volatile psc_spi_t *sp; + + /* Set clock Source*/ + set_clk_src(); + + /* Now, set up the PSC for SPI PIO mode. + */ + sp = (volatile psc_spi_t *)SPI_PSC_BASE; + sp->psc_ctrl = PSC_CTRL_DISABLE; + au_sync(); + sp->psc_sel = PSC_SEL_PS_SPIMODE; + sp->psc_spicfg = 0; + au_sync(); + sp->psc_ctrl = PSC_CTRL_ENABLE; + au_sync(); + + do { + stat = sp->psc_spistat; + au_sync(); + } while ((stat & PSC_SPISTAT_SR) == 0); + + + sp->psc_spicfg = (PSC_SPICFG_RT_FIFO8 | PSC_SPICFG_TT_FIFO8 | + PSC_SPICFG_DD_DISABLE | PSC_SPICFG_MO); + sp->psc_spicfg |= PSC_SPICFG_SET_LEN(8); + spi_datalen = 8; + sp->psc_spimsk = PSC_SPIMSK_ALLMASK; + au_sync(); + + set_baud_rate(1000000); + + sp->psc_spicfg |= PSC_SPICFG_DE_ENABLE; + + do { + stat = sp->psc_spistat; + au_sync(); + } while ((stat & PSC_SPISTAT_DR) == 0); + + + misc_register(&au1550spi_miscdev); + return 0; +} + +void __exit +au1550spi_exit(void) +{ + misc_deregister(&au1550spi_miscdev); +} + +module_init(au1550spi_init); +module_exit(au1550spi_exit); diff --git a/include/asm-mips/mach-au1x00/au1550_spi.h b/include/asm-mips/mach-au1x00/au1550_spi.h new file mode 100644 index 0000000..d956145 --- /dev/null +++ b/include/asm-mips/mach-au1x00/au1550_spi.h @@ -0,0 +1,38 @@ +/* + * API to Alchemy Au1550 SPI device. + * + * Copyright 2004 Embedded Edge, LLC. + * dan@embeddededge.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. + */ + +#ifndef __AU1550_SPI_H +#define __AU1550_SPI_H + +#include + +#define AU1550SPI_IOC_MAGIC 'S' + +#define AU1550SPI_SET_BAUD _IOW(AU1550SPI_IOC_MAGIC, 0, int *) +#define AU1550SPI_WORD_LEN _IOW(AU1550SPI_IOC_MAGIC, 1, int) + +#endif /* __AU1000_SPI_H */ From jcrouse@cosmic.amd.com Fri Dec 2 18:52:20 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 02 Dec 2005 18:52:40 +0000 (GMT) Received: from amdext4.amd.com ([163.181.251.6]:11687 "EHLO amdext4.amd.com") by ftp.linux-mips.org with ESMTP id S8133484AbVLBSwU (ORCPT ); Fri, 2 Dec 2005 18:52:20 +0000 Received: from SAUSGW02.amd.com (sausgw02.amd.com [163.181.250.22]) by amdext4.amd.com (8.12.11/8.12.11/AMD) with ESMTP id jB2Itsmw031880; Fri, 2 Dec 2005 12:55:54 -0600 Received: from 163.181.250.1 by SAUSGW02.amd.com with ESMTP (AMD SMTP Relay (Email Firewall v6.1.0)); Fri, 02 Dec 2005 12:55:49 -0600 X-Server-Uuid: 5FC0E2DF-CD44-48CD-883A-0ED95B391E89 Received: from ldcmail.amd.com (ldcmail.amd.com [147.5.200.40]) by amdint2.amd.com (8.12.8/8.12.8/AMD) with ESMTP id jB2ItmTw004426; Fri, 2 Dec 2005 12:55:48 -0600 (CST) Received: from cosmic.amd.com (cosmic.amd.com [147.5.201.206]) by ldcmail.amd.com (Postfix) with ESMTP id 0C7782026; Fri, 2 Dec 2005 11:55:48 -0700 (MST) Received: from cosmic.amd.com (localhost [127.0.0.1]) by cosmic.amd.com (8.13.4/8.13.4) with ESMTP id jB2J3Z0P031409; Fri, 2 Dec 2005 12:03:35 -0700 Received: (from jcrouse@localhost) by cosmic.amd.com ( 8.13.4/8.13.4/Submit) id jB2J3ZVS031408; Fri, 2 Dec 2005 12:03:35 -0700 Date: Fri, 2 Dec 2005 12:03:35 -0700 From: "Jordan Crouse" To: linux-mips@linux-mips.org cc: ralf@linux-mips.org Subject: [PATCH] ALCHEMY: AU1200 I2C modifications Message-ID: <20051202190335.GH28227@cosmic.amd.com> MIME-Version: 1.0 User-Agent: Mutt/1.5.11 X-WSS-ID: 6F8E473F2MW515595-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: 9579 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 Modifications to the existing AU1XXX I2C controller for the Au1200. Sending now to be included in the post 2.6.15 rush. Signed-off-by: Jordan Crouse --- arch/mips/au1000/db1x00/board_setup.c | 37 +++++++++++++++++++++++++++++ drivers/i2c/busses/Kconfig | 2 +- drivers/i2c/busses/i2c-au1550.c | 29 ++++++++++++++++++----- include/asm-mips/mach-au1x00/au1xxx_psc.h | 7 +++++ 4 files changed, 67 insertions(+), 8 deletions(-) diff --git a/arch/mips/au1000/db1x00/board_setup.c b/arch/mips/au1000/db1x00/board_setup.c index f00ec3b..a2638c8 100644 --- a/arch/mips/au1000/db1x00/board_setup.c +++ b/arch/mips/au1000/db1x00/board_setup.c @@ -76,6 +76,43 @@ void __init board_setup(void) #endif bcsr->pcmcia = 0x0000; /* turn off PCMCIA power */ +#if defined(CONFIG_I2C_AU1550) && defined(CONFIG_MIPS_DB1200) + { + u32 freq0, clksrc; + + /* Select SMBUS in CPLD */ + bcsr->resets &= ~(BCSR_RESETS_PCS0MUX); + + pin_func = au_readl(SYS_PINFUNC); + au_sync(); + pin_func &= ~(3<<17 | 1<<4); + /* Set GPIOs correctly */ + pin_func |= 2<<17; + au_writel(pin_func, SYS_PINFUNC); + au_sync(); + + /* The i2c driver depends on 50Mhz clock */ + freq0 = au_readl(SYS_FREQCTRL0); + au_sync(); + freq0 &= ~(SYS_FC_FRDIV1_MASK | SYS_FC_FS1 | SYS_FC_FE1); + freq0 |= (3< #include -#include +#if defined(CONFIG_MIPS_PB1550) + #include +#endif +#if defined(CONFIG_MIPS_PB1200) + #include +#endif +#if defined(CONFIG_MIPS_DB1200) + #include +#endif #include #include "i2c-au1550.h" @@ -118,13 +126,20 @@ 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 */ @@ -367,7 +382,7 @@ static struct i2c_au1550_data pb1550_i2c SMBUS_PSC_BASE, 200, 200 }; -static struct i2c_adapter pb1550_board_adapter = { +struct i2c_adapter pb1550_board_adapter = { name: "pb1550 adapter", id: I2C_HW_AU1550_PSC, algo: NULL, @@ -376,6 +391,8 @@ static struct i2c_adapter pb1550_board_a client_unregister: pb1550_unreg, }; +EXPORT_SYMBOL(pb1550_board_adapter); + /* BIG hack to support the control interface on the Wolfson WM8731 * audio codec on the Pb1550 board. We get an address and two data * bytes to write, create an i2c message, and send it across the diff --git a/include/asm-mips/mach-au1x00/au1xxx_psc.h b/include/asm-mips/mach-au1x00/au1xxx_psc.h index 8e5fb3c..45a05c8 100644 --- a/include/asm-mips/mach-au1x00/au1xxx_psc.h +++ b/include/asm-mips/mach-au1x00/au1xxx_psc.h @@ -43,6 +43,11 @@ #define PSC3_BASE_ADDR 0xb0d00000 #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 * all protocols. */ @@ -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 jcrouse@cosmic.amd.com Fri Dec 2 18:55:32 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 02 Dec 2005 18:55:59 +0000 (GMT) Received: from amdext3.amd.com ([139.95.251.6]:49116 "EHLO amdext3.amd.com") by ftp.linux-mips.org with ESMTP id S8133871AbVLBSzc (ORCPT ); Fri, 2 Dec 2005 18:55:32 +0000 Received: from SSVLGW02.amd.com (ssvlgw02.amd.com [139.95.250.170]) by amdext3.amd.com (8.12.11/8.12.11/AMD) with ESMTP id jB2Iwl12009988; Fri, 2 Dec 2005 10:59:07 -0800 Received: from 139.95.250.1 by SSVLGW02.amd.com with ESMTP (AMD SMTP Relay (Email Firewall v6.1.0)); Fri, 02 Dec 2005 10:58:50 -0800 X-Server-Uuid: 519AC16A-9632-469E-B354-112C592D09E8 Received: from ldcmail.amd.com (ldcmail.amd.com [147.5.200.40]) by amdint.amd.com (8.12.8/8.12.8/AMD) with ESMTP id jB2IwnQe022259; Fri, 2 Dec 2005 10:58:49 -0800 (PST) Received: from cosmic.amd.com (cosmic.amd.com [147.5.201.206]) by ldcmail.amd.com (Postfix) with ESMTP id DAF6B2026; Fri, 2 Dec 2005 11:58:48 -0700 (MST) Received: from cosmic.amd.com (localhost [127.0.0.1]) by cosmic.amd.com (8.13.4/8.13.4) with ESMTP id jB2J6aZW031451; Fri, 2 Dec 2005 12:06:36 -0700 Received: (from jcrouse@localhost) by cosmic.amd.com ( 8.13.4/8.13.4/Submit) id jB2J6Zl5031450; Fri, 2 Dec 2005 12:06:35 -0700 Date: Fri, 2 Dec 2005 12:06:35 -0700 From: "Jordan Crouse" To: linux-mips@linux-mips.org cc: ralf@linux-mips.org Subject: [PATCH] ALCHEMY: Alchemy Camera Interface (CIM) driver Message-ID: <20051202190635.GI28227@cosmic.amd.com> MIME-Version: 1.0 User-Agent: Mutt/1.5.11 X-WSS-ID: 6F8E46E01IW1436034-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: 9580 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 A driver for the AU1200 Camera Interface (CIM). Definately should be postponed post 2.6.15. This is the most complex one I'm sending up right now, so comments and flames are definately welcome. Signed-off-by: Jordan Crouse --- drivers/Makefile | 2 drivers/char/Kconfig | 4 drivers/char/Makefile | 1 drivers/char/au1xxx_cameras.h | 572 ++++++++++++++++++++++++++ drivers/char/au1xxx_cim.c | 647 +++++++++++++++++++++++++++++ include/asm-mips/mach-au1x00/au1xxx_cim.h | 190 +++++++++ 6 files changed, 1415 insertions(+), 1 deletions(-) diff --git a/drivers/Makefile b/drivers/Makefile index fac1e16..7ab1608 100644 --- a/drivers/Makefile +++ b/drivers/Makefile @@ -16,6 +16,7 @@ obj-$(CONFIG_PNP) += pnp/ # char/ comes before serial/ etc so that the VT console is the boot-time # default. +obj-$(CONFIG_I2C) += i2c/ obj-y += char/ obj-$(CONFIG_CONNECTOR) += connector/ @@ -53,7 +54,6 @@ obj-$(CONFIG_USB_GADGET) += usb/gadget/ obj-$(CONFIG_GAMEPORT) += input/gameport/ obj-$(CONFIG_INPUT) += input/ obj-$(CONFIG_I2O) += message/ -obj-$(CONFIG_I2C) += i2c/ obj-$(CONFIG_W1) += w1/ obj-$(CONFIG_HWMON) += hwmon/ obj-$(CONFIG_PHONE) += telephony/ diff --git a/drivers/char/Kconfig b/drivers/char/Kconfig index 9424f62..2b0cf62 100644 --- a/drivers/char/Kconfig +++ b/drivers/char/Kconfig @@ -347,6 +347,10 @@ config AU1X00_USB_RAW tristate "Au1000 USB Raw Device support" depends on MIPS && MIPS_AU1000 && AU1000_USB_DEVICE=y && AU1000_USB_TTY!=y && AU1X00_USB_DEVICE +config AU1XXX_CIM + tristate "Au1200 Camera Interface Module (CIM)" + depends on MIPS && SOC_AU1X00 && I2C_AU1550 + config SIBYTE_SB1250_DUART bool "Support for BCM1xxx onchip DUART" depends on MIPS && SIBYTE_SB1xxx_SOC=y diff --git a/drivers/char/Makefile b/drivers/char/Makefile index ecc5670..6629394 100644 --- a/drivers/char/Makefile +++ b/drivers/char/Makefile @@ -82,6 +82,7 @@ obj-$(CONFIG_ITE_GPIO) += ite_gpio.o obj-$(CONFIG_AU1000_GPIO) += au1000_gpio.o obj-$(CONFIG_AU1000_USB_TTY) += au1000_usbtty.o obj-$(CONFIG_AU1000_USB_RAW) += au1000_usbraw.o +obj-$(CONFIG_AU1XXX_CIM) += au1xxx_cim.o obj-$(CONFIG_PPDEV) += ppdev.o obj-$(CONFIG_NWBUTTON) += nwbutton.o obj-$(CONFIG_NWFLASH) += nwflash.o diff --git a/drivers/char/au1xxx_cameras.h b/drivers/char/au1xxx_cameras.h new file mode 100644 index 0000000..3ecfa30 --- /dev/null +++ b/drivers/char/au1xxx_cameras.h @@ -0,0 +1,572 @@ +#ifndef AU1XXX_CAMERAS_H_ +#define AU1XXX_CAMERAS_H_ + +/* List of cameras to be used with the AU1XXX Camera interface + Copyright 2005, Advanced Micro Devices, Inc. + + This software may be used and distributed according to the terms + of the GNU General Public License, incorporated herein by reference. +*/ + + +typedef struct cim_cmos_camera_config { + uint32_t frame_width; /* Frame Width (Pixel per Line) */ + uint32_t frame_height; /* Frame Height */ + unsigned char camera_name[32]; /* Camera Name (Display/Debug) */ + unsigned char camera_mode[32]; /* Camera Mode(Display/Debug) */ + uint32_t cmos_output_format; /* CMOS Camera output */ + uint32_t camera_resformat; /* Camera Mode(Display/Debug) */ + uint32_t au1200_dpsmode; /* Data Pattern Select */ + uint32_t au1200_baymode; /* Mode within BAYER mode */ + uint32_t dbdma_channel; /* Number of channels to be used */ + u8 device_addr; /* Camera Device address */ + uint32_t cmd_size; /* Number of device sub register */ + u8 config_cmd[MAX_DEVICE_CMD][2]; /* Sub device address and values */ +} CAMERA; + + + +static CAMERA au1xxx_cameras[] = { + /* Omnivision OV9640 Camera 1280x960 Mode (SXGA) in "Pass Thru Mode" + 1.3 MP at 15 Fps + */ + + { 1280, 960, "omnivision", "raw_SXGA", CMOS_RAW, + RAW_SXGA, CIM_CONFIG_RAW, CIM_CONFIG_BGGR, + 1, 0x30, 50, + { + {0x12, 0x80}, {0x12, 0x05}, {0x11, 0x80}, + {0x3b, 0x00}, {0x33, 0x02}, + {0x37, 0x02}, {0x38, 0x13}, {0x39, 0xf0}, + {0x6c, 0x40}, {0x6d, 0x30}, + {0x6e, 0x4b}, {0x6f, 0x60}, {0x70, 0x70}, + {0x71, 0x70}, {0x74, 0x60}, + {0x75, 0x60}, {0x76, 0x50}, {0x77, 0x48}, + {0x78, 0x3a}, {0x79, 0x2e}, + {0x7a, 0x2a}, {0x7b, 0x22}, {0x7c, 0x04}, + {0x7d, 0x07}, {0x7e, 0x10}, + {0x7f, 0x28}, {0x80, 0x36}, {0x81, 0x44}, + {0x82, 0x52}, {0x83, 0x60}, + {0x84, 0x6c}, {0x85, 0x78}, {0x86, 0x8c}, + {0x87, 0x9e}, {0x88, 0xbb}, + {0x89, 0xd2}, {0x8a, 0xe6}, {0x0f, 0x4f}, + {0x3c, 0x40}, {0x14, 0xca}, + {0x42, 0x89}, {0x24, 0x78}, {0x25, 0x68}, + {0x26, 0xd4}, {0x27, 0x90}, + {0x2a, 0x00}, {0x2b, 0x00}, {0x3d, 0x80}, + {0x41, 0x00}, {0x60, 0x8d}, + } + }, + + /* Omnivision OV9640 Camera 640x480 Mode (VGA) in "Pass Through Mode" */ + { 640, 480, "omnivision", "raw_VGA", CMOS_RAW, + RAW_VGA,CIM_CONFIG_RAW,CIM_CONFIG_BGGR, + 1, 0x30, 54, + { + {0x12, 0x80}, {0x12, 0x45}, {0x11, 0x81}, + {0x0c, 0x04}, {0x0d, 0x40}, {0x3b, 0x00}, + {0x33, 0x02}, + {0x37, 0x02}, {0x38, 0x13}, {0x39, 0xf0}, + {0x6c, 0x40}, {0x6d, 0x30}, + {0x6e, 0x4b}, {0x6f, 0x60}, {0x70, 0x70}, + {0x71, 0x70}, {0x72, 0x70}, {0x73, 0x70}, + {0x74, 0x60}, + {0x75, 0x60}, {0x76, 0x50}, {0x77, 0x48}, + {0x78, 0x3a}, {0x79, 0x2e}, + {0x7a, 0x28}, {0x7b, 0x22}, {0x7c, 0x04}, + {0x7d, 0x07}, {0x7e, 0x2e}, + {0x7f, 0x28}, {0x80, 0x36}, {0x81, 0x44}, + {0x82, 0x52}, {0x83, 0x60}, + {0x84, 0x6c}, {0x85, 0x78}, {0x86, 0x8c}, + {0x87, 0x9e}, {0x88, 0xbb}, + {0x89, 0xd2}, {0x8a, 0xe6}, {0x0f, 0x4f}, + {0x3c, 0x40}, {0x14, 0xca}, + {0x42, 0x89}, {0x24, 0x78}, {0x25, 0x68}, + {0x26, 0xd4}, {0x27, 0x90}, + {0x2a, 0x00}, {0x2b, 0x00}, {0x3d, 0x80}, + {0x41, 0x00}, {0x60, 0x8d}, + } + }, + + /* Omnivision OV9640 Camera 352x288 Mode CIF "Pass Through Mode" */ + { 352, 288, "omnivision", "raw_CIF", CMOS_RAW, + RAW_CIF, CIM_CONFIG_RAW, CIM_CONFIG_BGGR, + 1, 0x30, 54, + { + {0x12, 0x80}, {0x12, 0x25}, {0x11, 0x80}, + {0x0c, 0x04}, {0x0d, 0x40}, {0x3b, 0x00}, + {0x33, 0x02}, + {0x37, 0x02}, {0x38, 0x13}, {0x39, 0xf0}, + {0x6c, 0x40}, {0x6d, 0x30}, + {0x6e, 0x4b}, {0x6f, 0x60}, {0x70, 0x70}, + {0x71, 0x70}, {0x72, 0x70}, {0x73, 0x70}, + {0x74, 0x60}, + {0x75, 0x60}, {0x76, 0x50}, {0x77, 0x48}, + {0x78, 0x3a}, {0x79, 0x2e}, + {0x7a, 0x28}, {0x7b, 0x22}, {0x7c, 0x04}, + {0x7d, 0x07}, {0x7e, 0x10}, + {0x7f, 0x28}, {0x80, 0x36}, {0x81, 0x44}, + {0x82, 0x52}, {0x83, 0x60}, + {0x84, 0x6c}, {0x85, 0x78}, {0x86, 0x8c}, + {0x87, 0x9e}, {0x88, 0xbb}, + {0x89, 0xd2}, {0x8a, 0xe6}, {0x0f, 0x4f}, + {0x3c, 0x40}, {0x14, 0xca}, + {0x42, 0x89}, {0x24, 0x78}, {0x25, 0x68}, + {0x26, 0xd4}, {0x27, 0x90}, + {0x2a, 0x00}, {0x2b, 0x00}, {0x3d, 0x80}, + {0x41, 0x00}, {0x60, 0x8d}, + } + + }, + + /* Omnivision OV9640 Camera 320x240 Mode (QVGA) in "Pass Through Mode" */ + { 320, 240, "omnivision", "raw_QVGA", CMOS_RAW, + RAW_QVGA, CIM_CONFIG_RAW, CIM_CONFIG_BGGR, + 1, 0x30, 54, + { + {0x12, 0x80}, {0x12, 0x15}, {0x11, 0x83}, + {0x0c, 0x04}, {0x0d, 0xc0}, {0x3b, 0x00}, + {0x33, 0x02}, + {0x37, 0x02}, {0x38, 0x13}, {0x39, 0xf0}, + {0x6c, 0x40}, {0x6d, 0x30}, + {0x6e, 0x4b}, {0x6f, 0x60}, {0x70, 0x70}, + {0x71, 0x70}, {0x72, 0x70}, {0x73, 0x70}, + {0x74, 0x60}, + {0x75, 0x60}, {0x76, 0x50}, {0x77, 0x48}, + {0x78, 0x3a}, {0x79, 0x2e}, + {0x7a, 0x28}, {0x7b, 0x22}, {0x7c, 0x04}, + {0x7d, 0x07}, {0x7e, 0x10}, + {0x7f, 0x28}, {0x80, 0x36}, {0x81, 0x44}, + {0x82, 0x52}, {0x83, 0x60}, + {0x84, 0x6c}, {0x85, 0x78}, {0x86, 0x8c}, + {0x87, 0x9e}, {0x88, 0xbb}, + {0x89, 0xd2}, {0x8a, 0xe6}, {0x0f, 0x4f}, + {0x3c, 0x40}, {0x14, 0xca}, + {0x42, 0x89}, {0x24, 0x78}, {0x25, 0x68}, + {0x26, 0xd4}, {0x27, 0x90}, + {0x2a, 0x00}, {0x2b, 0x00}, {0x3d, 0x80}, + {0x41, 0x00}, {0x60, 0x8d}, + } + }, + + /* Omnivision OV9640 Camera 176x144 QCIF Mode "Pass Through Mode" */ + { 176, 144, "omnivision", "raw_QCIF", CMOS_RAW, + RAW_QCIF, CIM_CONFIG_RAW, CIM_CONFIG_BGGR, + 1, 0x30, 54, + { + {0x12, 0x80}, {0x12, 0x0D}, {0x11, 0x80}, + {0x0c, 0x04}, {0x0d, 0xc0}, {0x3b, 0x00}, + {0x33, 0x02}, + {0x37, 0x02}, {0x38, 0x13}, {0x39, 0xf0}, + {0x6c, 0x40}, {0x6d, 0x30}, + {0x6e, 0x4b}, {0x6f, 0x60}, {0x70, 0x70}, + {0x71, 0x70}, {0x72, 0x70}, {0x73, 0x70}, + {0x74, 0x60}, + {0x75, 0x60}, {0x76, 0x50}, {0x77, 0x48}, + {0x78, 0x3a}, {0x79, 0x2e}, + {0x7a, 0x28}, {0x7b, 0x22}, {0x7c, 0x04}, + {0x7d, 0x07}, {0x7e, 0x10}, + {0x7f, 0x28}, {0x80, 0x36}, {0x81, 0x44}, + {0x82, 0x52}, {0x83, 0x60}, + {0x84, 0x6c}, {0x85, 0x78}, {0x86, 0x8c}, + {0x87, 0x9e}, {0x88, 0xbb}, + {0x89, 0xd2}, {0x8a, 0xe6}, {0x0f, 0x6f}, + {0x3c, 0x60}, {0x14, 0xca}, + {0x42, 0x89}, {0x24, 0x78}, {0x25, 0x68}, + {0x26, 0xd4}, {0x27, 0x90}, + {0x2a, 0x00}, {0x2b, 0x00}, {0x3d, 0x80}, + {0x41, 0x00}, {0x60, 0x8d}, + } + }, + + + /* Omnivision OV9640 Camera 1280x960 Mode (SXGA) in BAYER Mode (Planar) */ + { 1280, 960, "omnivision", "bayer_SXGA", CMOS_RAW, + BAYER_SXGA, CIM_CONFIG_BAYER, CIM_CONFIG_BGGR, + 3, 0x30, 50, + { + {0x12, 0x80}, {0x12, 0x05}, {0x11, 0x80}, + {0x3b, 0x00}, {0x33, 0x02}, + {0x37, 0x02}, {0x38, 0x13}, {0x39, 0xf0}, + {0x6c, 0x40}, {0x6d, 0x30}, + {0x6e, 0x4b}, {0x6f, 0x60}, {0x70, 0x70}, + {0x71, 0x70}, {0x74, 0x60}, + {0x75, 0x60}, {0x76, 0x50}, {0x77, 0x48}, + {0x78, 0x3a}, {0x79, 0x2e}, + {0x7a, 0x2a}, {0x7b, 0x22}, {0x7c, 0x04}, + {0x7d, 0x07}, {0x7e, 0x10}, + {0x7f, 0x28}, {0x80, 0x36}, {0x81, 0x44}, + {0x82, 0x52}, {0x83, 0x60}, + {0x84, 0x6c}, {0x85, 0x78}, {0x86, 0x8c}, + {0x87, 0x9e}, {0x88, 0xbb}, + {0x89, 0xd2}, {0x8a, 0xe6}, {0x0f, 0x4f}, + {0x3c, 0x40}, {0x14, 0xca}, + {0x42, 0x89}, {0x24, 0x78}, {0x25, 0x68}, + {0x26, 0xd4}, {0x27, 0x90}, + {0x2a, 0x00}, {0x2b, 0x00}, {0x3d, 0x80}, + {0x41, 0x00}, {0x60, 0x8d}, + } + }, + + /* Omnivision OV9640 Camera 640x480 Mode (VGA) in BAYER Mode (Planar) */ + { 640, 480, "omnivision", "bayer_VGA", CMOS_RAW, + BAYER_VGA, CIM_CONFIG_BAYER, CIM_CONFIG_BGGR, + 3, 0x30, 54, + { + {0x12, 0x80}, {0x12, 0x45}, {0x11, 0x81}, + {0x0c, 0x04}, {0x0d, 0x40}, {0x3b, 0x00}, + {0x33, 0x02}, + {0x37, 0x02}, {0x38, 0x13}, {0x39, 0xf0}, + {0x6c, 0x40}, {0x6d, 0x30}, + {0x6e, 0x4b}, {0x6f, 0x60}, {0x70, 0x70}, + {0x71, 0x70}, {0x72, 0x70}, {0x73, 0x70}, + {0x74, 0x60}, + {0x75, 0x60}, {0x76, 0x50}, {0x77, 0x48}, + {0x78, 0x3a}, {0x79, 0x2e}, + {0x7a, 0x28}, {0x7b, 0x22}, {0x7c, 0x04}, + {0x7d, 0x07}, {0x7e, 0x2e}, + {0x7f, 0x28}, {0x80, 0x36}, {0x81, 0x44}, + {0x82, 0x52}, {0x83, 0x60}, + {0x84, 0x6c}, {0x85, 0x78}, {0x86, 0x8c}, + {0x87, 0x9e}, {0x88, 0xbb}, + {0x89, 0xd2}, {0x8a, 0xe6}, {0x0f, 0x4f}, + {0x3c, 0x40}, {0x14, 0xca}, + {0x42, 0x89}, {0x24, 0x78}, {0x25, 0x68}, + {0x26, 0xd4}, {0x27, 0x90}, + {0x2a, 0x00}, {0x2b, 0x00}, {0x3d, 0x80}, + {0x41, 0x00}, {0x60, 0x8d}, + } + }, + + /* Omnivision OV9640 Camera 352x288 CIF Mode in BAYER Mode (Planar) */ + { 352, 288, "omnivision", "bayer_CIF", CMOS_RAW, + BAYER_CIF, CIM_CONFIG_BAYER, CIM_CONFIG_BGGR, + 3, 0x30, 54, + { + {0x12, 0x80}, {0x12, 0x25}, {0x11, 0x80}, + {0x0c, 0x04}, {0x0d, 0x40}, {0x3b, 0x00}, + {0x33, 0x02}, + {0x37, 0x02}, {0x38, 0x13}, {0x39, 0xf0}, + {0x6c, 0x40}, {0x6d, 0x30}, + {0x6e, 0x4b}, {0x6f, 0x60}, {0x70, 0x70}, + {0x71, 0x70}, {0x72, 0x70}, {0x73, 0x70}, + {0x74, 0x60}, + {0x75, 0x60}, {0x76, 0x50}, {0x77, 0x48}, + {0x78, 0x3a}, {0x79, 0x2e}, + {0x7a, 0x28}, {0x7b, 0x22}, {0x7c, 0x04}, + {0x7d, 0x07}, {0x7e, 0x10}, + {0x7f, 0x28}, {0x80, 0x36}, {0x81, 0x44}, + {0x82, 0x52}, {0x83, 0x60}, + {0x84, 0x6c}, {0x85, 0x78}, {0x86, 0x8c}, + {0x87, 0x9e}, {0x88, 0xbb}, + {0x89, 0xd2}, {0x8a, 0xe6}, {0x0f, 0x4f}, + {0x3c, 0x40}, {0x14, 0xca}, + {0x42, 0x89}, {0x24, 0x78}, {0x25, 0x68}, + {0x26, 0xd4}, {0x27, 0x90}, + {0x2a, 0x00}, {0x2b, 0x00}, {0x3d, 0x80}, + {0x41, 0x00}, {0x60, 0x8d}, + } + }, + + /* Omnivision OV9640 Camera 320x240 Mode (QVGA) in BAYER Mode (Planar) */ + { 320, 240, "omnivision", "bayer_QVGA", CMOS_RAW, + BAYER_QVGA, CIM_CONFIG_BAYER, CIM_CONFIG_BGGR, + 3, 0x30, 54, + { + {0x12, 0x80}, {0x12, 0x15}, {0x11, 0x83}, + {0x0c, 0x04}, {0x0d, 0xc0}, {0x3b, 0x00}, + {0x33, 0x02}, + {0x37, 0x02}, {0x38, 0x13}, {0x39, 0xf0}, + {0x6c, 0x40}, {0x6d, 0x30}, + {0x6e, 0x4b}, {0x6f, 0x60}, {0x70, 0x70}, + {0x71, 0x70}, {0x72, 0x70}, {0x73, 0x70}, + {0x74, 0x60}, + {0x75, 0x60}, {0x76, 0x50}, {0x77, 0x48}, + {0x78, 0x3a}, {0x79, 0x2e}, + {0x7a, 0x28}, {0x7b, 0x22}, {0x7c, 0x04}, + {0x7d, 0x07}, {0x7e, 0x10}, + {0x7f, 0x28}, {0x80, 0x36}, {0x81, 0x44}, + {0x82, 0x52}, {0x83, 0x60}, + {0x84, 0x6c}, {0x85, 0x78}, {0x86, 0x8c}, + {0x87, 0x9e}, {0x88, 0xbb}, + {0x89, 0xd2}, {0x8a, 0xe6}, {0x0f, 0x4f}, + {0x3c, 0x40}, {0x14, 0xca}, + {0x42, 0x89}, {0x24, 0x78}, {0x25, 0x68}, + {0x26, 0xd4}, {0x27, 0x90}, + {0x2a, 0x00}, {0x2b, 0x00}, {0x3d, 0x80}, + {0x41, 0x00}, {0x60, 0x8d}, + } + }, + + /* Omnivision OV9640 Camera 640x480 Mode (QCIF) in BAYER Mode (Planar) */ + { 176, 144, "omnivision", "bayer_QCIF", CMOS_RAW, + BAYER_QCIF, CIM_CONFIG_BAYER, CIM_CONFIG_BGGR, + 3, 0x30, 54, + { + {0x12, 0x80}, {0x12, 0x0D}, {0x11, 0x80}, + {0x0c, 0x04}, {0x0d, 0xc0}, {0x3b, 0x00}, + {0x33, 0x02}, + {0x37, 0x02}, {0x38, 0x13}, {0x39, 0xf0}, + {0x6c, 0x40}, {0x6d, 0x30}, + {0x6e, 0x4b}, {0x6f, 0x60}, {0x70, 0x70}, + {0x71, 0x70}, {0x72, 0x70}, {0x73, 0x70}, + {0x74, 0x60}, + {0x75, 0x60}, {0x76, 0x50}, {0x77, 0x48}, + {0x78, 0x3a}, {0x79, 0x2e}, + {0x7a, 0x28}, {0x7b, 0x22}, {0x7c, 0x04}, + {0x7d, 0x07}, {0x7e, 0x10}, + {0x7f, 0x28}, {0x80, 0x36}, {0x81, 0x44}, + {0x82, 0x52}, {0x83, 0x60}, + {0x84, 0x6c}, {0x85, 0x78}, {0x86, 0x8c}, + {0x87, 0x9e}, {0x88, 0xbb}, + {0x89, 0xd2}, {0x8a, 0xe6}, {0x0f, 0x6f}, + {0x3c, 0x60}, {0x14, 0xca}, + {0x42, 0x89}, {0x24, 0x78}, {0x25, 0x68}, + {0x26, 0xd4}, {0x27, 0x90}, + {0x2a, 0x00}, {0x2b, 0x00}, {0x3d, 0x80}, + {0x41, 0x00}, {0x60, 0x8d}, + } + }, + + /* Omnivision OV9640 Camera 1280x960 Mode (SXGA) in YCbCr Camera pass Thru Mode */ + { 1280, 960, "omnivision", "YCbCr_SXGA", CMOS_CCIR656, + YCbCr_SXGA_RAW, CIM_CONFIG_RAW, CIM_CONFIG_BGGR, + 1, 0x30, 115, + { + {0x12, 0x80}, {0x11, 0x80}, {0x12, 0x00}, + {0x13, 0xA8}, {0x01, 0x80}, + {0x02, 0x80}, {0x04, 0x40}, {0x0C, 0x04}, + {0x0D, 0xC0}, {0x0E, 0x81}, + {0x0f, 0x4F}, {0x14, 0x4A}, {0x16, 0x02}, + {0x1B, 0x01}, {0x24, 0x70}, + {0x25, 0x68}, {0x26, 0xD3}, {0x27, 0x90}, + {0x2A, 0x00}, {0x2B, 0x00}, + {0x33, 0x28}, {0x37, 0x02}, {0x38, 0x13}, + {0x39, 0xF0}, {0x3A, 0x00}, + {0x3B, 0x01}, {0x3C, 0x46}, {0x3D, 0x90}, + {0x3E, 0x02}, {0x3F, 0xF2}, + {0x41, 0x02}, {0x42, 0xC9}, {0x43, 0xF0}, + {0x44, 0x10}, {0x45, 0x6C}, + {0x46, 0x6C}, {0x47, 0x44}, {0x48, 0x44}, + {0x49, 0x03}, {0x4F, 0x50}, + {0x50, 0x43}, {0x51, 0x0D}, {0x52, 0x19}, + {0x53, 0x4C}, {0x54, 0x65}, + {0x59, 0x49}, {0x5A, 0x94}, {0x5B, 0x46}, + {0x5C, 0x84}, {0x5D, 0x5C}, + {0x5E, 0x08}, {0x5F, 0x00}, {0x60, 0x14}, + {0x61, 0xCE}, {0x62, 0x70}, + {0x63, 0x00}, {0x64, 0x04}, {0x65, 0x00}, + {0x66, 0x00}, {0x69, 0x00}, + {0x6A, 0x3E}, {0x6B, 0x3F}, {0x6C, 0x40}, + {0x6D, 0x30}, {0x6E, 0x4B}, + {0x6F, 0x60}, {0x70, 0x70}, {0x71, 0x70}, + {0x72, 0x70}, {0x73, 0x70}, + {0x74, 0x70}, {0x75, 0x60}, {0x76, 0x50}, + {0x77, 0x48}, {0x78, 0x3A}, + {0x79, 0x2E}, {0x7A, 0x28}, {0x7B, 0x22}, + {0x7C, 0x04}, {0x7D, 0x07}, + {0x7E, 0x10}, {0x7F, 0x28}, {0x80, 0x36}, + {0x81, 0x44}, {0x82, 0x52}, + {0x83, 0x60}, {0x84, 0x6C}, {0x85, 0x78}, + {0x86, 0x8C}, {0x87, 0x9E}, + {0x88, 0xBB}, {0x89, 0xD2}, {0x8A, 0xE6}, + {0x13, 0xAF}, {0x13, 0x8D}, + {0x01, 0x80}, {0x02, 0x80}, {0x42, 0xC9}, + {0x16, 0x02}, {0x43, 0xF0}, + {0x44, 0x10}, {0x45, 0x20}, {0x46, 0x20}, + {0x47, 0x20}, {0x48, 0x20}, + {0x59, 0x17}, {0x5A, 0x71}, {0x5B, 0x56}, + {0x5C, 0x74}, {0x5D, 0x68}, + {0x5e, 0x10}, {0x5f, 0x00}, {0x60, 0x14}, + {0x61, 0xCE}, {0x13, 0x8F}, + } + }, + + /* Omnivision OV9640 Camera 640x480 Mode (SXGA) in YCbCr Camera pass Thru Mode */ + { 640, 480, "omnivision", "YCbCr_VGA_raw", CMOS_CCIR656, + YCbCr_VGA_RAW, CIM_CONFIG_RAW, CIM_CONFIG_BGGR, + 1, 0x30, 94, + { + {0x12, 0x80}, {0x11, 0x81}, {0x12, 0x40}, + {0x13, 0xA8}, {0x01, 0x80}, + {0x02, 0x80}, {0x04, 0x40}, {0x0C, 0x04}, + {0x0D, 0xC0}, {0x0E, 0x81}, + {0x0f, 0x4F}, {0x14, 0x4A}, {0x16, 0x02}, + {0x1B, 0x01}, {0x24, 0x70}, + {0x25, 0x68}, {0x26, 0xD3}, {0x27, 0x90}, + {0x2A, 0x00}, {0x2B, 0x00}, + {0x33, 0x02}, {0x37, 0x02}, {0x38, 0x13}, + {0x39, 0xF0}, {0x3A, 0x00}, + {0x3B, 0x01}, {0x3C, 0x46}, {0x3D, 0x90}, + {0x3E, 0x02}, {0x3F, 0xF2}, + {0x41, 0x02}, {0x42, 0xC9}, {0x43, 0xF0}, + {0x44, 0x10}, {0x45, 0x6C}, + {0x46, 0x6C}, {0x47, 0x44}, {0x48, 0x44}, + {0x49, 0x03}, {0x4F, 0x50}, + {0x50, 0x43}, {0x51, 0x0D}, {0x52, 0x19}, + {0x53, 0x4C}, {0x54, 0x65}, + {0x59, 0x49}, {0x5A, 0x94}, {0x5B, 0x46}, + {0x5C, 0x84}, {0x5D, 0x5C}, + {0x5E, 0x08}, {0x5F, 0x00}, {0x60, 0x14}, + {0x61, 0xCE}, {0x62, 0x70}, + {0x63, 0x00}, {0x64, 0x04}, {0x65, 0x00}, + {0x66, 0x00}, {0x69, 0x00}, + {0x6A, 0x3E}, {0x6B, 0x3F}, {0x6C, 0x40}, + {0x6D, 0x30}, {0x6E, 0x4B}, + {0x6F, 0x60}, {0x70, 0x70}, {0x71, 0x70}, + {0x72, 0x70}, {0x73, 0x70}, + {0x74, 0x60}, {0x75, 0x60}, {0x76, 0x50}, + {0x77, 0x48}, {0x78, 0x3A}, + {0x79, 0x2E}, {0x7A, 0x28}, {0x7B, 0x22}, + {0x7C, 0x04}, {0x7D, 0x07}, + {0x7E, 0x10}, {0x7F, 0x28}, {0x80, 0x36}, + {0x81, 0x44}, {0x82, 0x52}, + {0x83, 0x60}, {0x84, 0x6C}, {0x85, 0x78}, + {0x86, 0x8C}, {0x87, 0x9E}, + {0x88, 0xBB}, {0x89, 0xD2}, {0x8A, 0xE6}, + {0x13, 0xAF}, + } + }, + + /* Omnivision OV9640 Camera 352x288 Mode (CIF) in YCbCr Camera pass Thru Mode */ + { 352, 288, "omnivision", "YCbCr_CIF_raw", CMOS_CCIR656, + YCbCr_CIF_RAW, CIM_CONFIG_RAW, CIM_CONFIG_BGGR, + 1, 0x30, 94, + { + {0x12, 0x80}, {0x11, 0x81}, {0x12, 0x20}, + {0x13, 0xA8}, {0x01, 0x80}, + {0x02, 0x80}, {0x04, 0x40}, {0x0C, 0x04}, + {0x0D, 0xC0}, {0x0E, 0x81}, + {0x0f, 0x4F}, {0x14, 0x4A}, {0x16, 0x02}, + {0x1B, 0x01}, {0x24, 0x70}, + {0x25, 0x68}, {0x26, 0xD3}, {0x27, 0x90}, + {0x2A, 0x00}, {0x2B, 0x00}, + {0x33, 0x02}, {0x37, 0x02}, {0x38, 0x13}, + {0x39, 0xF0}, {0x3A, 0x00}, + {0x3B, 0x01}, {0x3C, 0x46}, {0x3D, 0x90}, + {0x3E, 0x02}, {0x3F, 0xF2}, + {0x41, 0x02}, {0x42, 0xC9}, {0x43, 0xF0}, + {0x44, 0x10}, {0x45, 0x6C}, + {0x46, 0x6C}, {0x47, 0x44}, {0x48, 0x44}, + {0x49, 0x03}, {0x4F, 0x50}, + {0x50, 0x43}, {0x51, 0x0D}, {0x52, 0x19}, + {0x53, 0x4C}, {0x54, 0x65}, + {0x59, 0x49}, {0x5A, 0x94}, {0x5B, 0x46}, + {0x5C, 0x84}, {0x5D, 0x5C}, + {0x5E, 0x08}, {0x5F, 0x00}, {0x60, 0x14}, + {0x61, 0xCE}, {0x62, 0x70}, + {0x63, 0x00}, {0x64, 0x04}, {0x65, 0x00}, + {0x66, 0x00}, {0x69, 0x00}, + {0x6A, 0x3E}, {0x6B, 0x3F}, {0x6C, 0x40}, + {0x6D, 0x30}, {0x6E, 0x4B}, + {0x6F, 0x60}, {0x70, 0x70}, {0x71, 0x70}, + {0x72, 0x70}, {0x73, 0x70}, + {0x74, 0x60}, {0x75, 0x60}, {0x76, 0x50}, + {0x77, 0x48}, {0x78, 0x3A}, + {0x79, 0x2E}, {0x7A, 0x28}, {0x7B, 0x22}, + {0x7C, 0x04}, {0x7D, 0x07}, + {0x7E, 0x10}, {0x7F, 0x28}, {0x80, 0x36}, + {0x81, 0x44}, {0x82, 0x52}, + {0x83, 0x60}, {0x84, 0x6C}, {0x85, 0x78}, + {0x86, 0x8C}, {0x87, 0x9E}, + {0x88, 0xBB}, {0x89, 0xD2}, {0x8A, 0xE6}, + {0x13, 0xAF}, + } + }, + + /* Omnivision OV9640 Camera 320x240 Mode QVGA in YCbCr Camera pass Thru Mode */ + { 320, 240, "omnivision", "YCbCr_QVGA_raw", CMOS_CCIR656, + YCbCr_QVGA_RAW, CIM_CONFIG_RAW, CIM_CONFIG_BGGR, + 1, 0x30, 94, + { + {0x12, 0x80}, {0x11, 0x81}, {0x12, 0x10}, + {0x13, 0xA8}, {0x01, 0x80}, + {0x02, 0x80}, {0x04, 0x40}, {0x0C, 0x04}, + {0x0D, 0xC0}, {0x0E, 0x81}, + {0x0f, 0x4F}, {0x14, 0x4A}, {0x16, 0x02}, + {0x1B, 0x01}, {0x24, 0x70}, + {0x25, 0x68}, {0x26, 0xD3}, {0x27, 0x90}, + {0x2A, 0x00}, {0x2B, 0x00}, + {0x33, 0x02}, {0x37, 0x02}, {0x38, 0x13}, + {0x39, 0xF0}, {0x3A, 0x00}, + {0x3B, 0x01}, {0x3C, 0x46}, {0x3D, 0x90}, + {0x3E, 0x02}, {0x3F, 0xF2}, + {0x41, 0x02}, {0x42, 0xC9}, {0x43, 0xF0}, + {0x44, 0x10}, {0x45, 0x6C}, + {0x46, 0x6C}, {0x47, 0x44}, {0x48, 0x44}, + {0x49, 0x03}, {0x4F, 0x50}, + {0x50, 0x43}, {0x51, 0x0D}, {0x52, 0x19}, + {0x53, 0x4C}, {0x54, 0x65}, + {0x59, 0x49}, {0x5A, 0x94}, {0x5B, 0x46}, + {0x5C, 0x84}, {0x5D, 0x5C}, + {0x5E, 0x08}, {0x5F, 0x00}, {0x60, 0x14}, + {0x61, 0xCE}, {0x62, 0x70}, + {0x63, 0x00}, {0x64, 0x04}, {0x65, 0x00}, + {0x66, 0x00}, {0x69, 0x00}, + {0x6A, 0x3E}, {0x6B, 0x3F}, {0x6C, 0x40}, + {0x6D, 0x30}, {0x6E, 0x4B}, + {0x6F, 0x60}, {0x70, 0x70}, {0x71, 0x70}, + {0x72, 0x70}, {0x73, 0x70}, + {0x74, 0x60}, {0x75, 0x60}, {0x76, 0x50}, + {0x77, 0x48}, {0x78, 0x3A}, + {0x79, 0x2E}, {0x7A, 0x28}, {0x7B, 0x22}, + {0x7C, 0x04}, {0x7D, 0x07}, + {0x7E, 0x10}, {0x7F, 0x28}, {0x80, 0x36}, + {0x81, 0x44}, {0x82, 0x52}, + {0x83, 0x60}, {0x84, 0x6C}, {0x85, 0x78}, + {0x86, 0x8C}, {0x87, 0x9E}, + {0x88, 0xBB}, {0x89, 0xD2}, {0x8A, 0xE6}, + {0x13, 0xAF}, + } + }, + + /* Omnivision OV9640 Camera 176x144 Mode (QCIF) in YCbCr Camera pass Thru Mode */ + { 176, 144, "omnivision", "YCbCr_QCIF_raw", CMOS_CCIR656, + YCbCr_QCIF_RAW, CIM_CONFIG_RAW, CIM_CONFIG_BGGR, + 1, 0x30, 94, + { + {0x12, 0x80}, {0x11, 0x81}, {0x12, 0x08}, + {0x13, 0xA8}, {0x01, 0x80}, + {0x02, 0x80}, {0x04, 0x40}, {0x0C, 0x04}, + {0x0D, 0xC0}, {0x0E, 0x81}, + {0x0f, 0x4F}, {0x14, 0x4A}, {0x16, 0x02}, + {0x1B, 0x01}, {0x24, 0x70}, + {0x25, 0x68}, {0x26, 0xD3}, {0x27, 0x90}, + {0x2A, 0x00}, {0x2B, 0x00}, + {0x33, 0x02}, {0x37, 0x02}, {0x38, 0x13}, + {0x39, 0xF0}, {0x3A, 0x00}, + {0x3B, 0x01}, {0x3C, 0x46}, {0x3D, 0x90}, + {0x3E, 0x02}, {0x3F, 0xF2}, + {0x41, 0x02}, {0x42, 0xC9}, {0x43, 0xF0}, + {0x44, 0x10}, {0x45, 0x6C}, + {0x46, 0x6C}, {0x47, 0x44}, {0x48, 0x44}, + {0x49, 0x03}, {0x4F, 0x50}, + {0x50, 0x43}, {0x51, 0x0D}, {0x52, 0x19}, + {0x53, 0x4C}, {0x54, 0x65}, + {0x59, 0x49}, {0x5A, 0x94}, {0x5B, 0x46}, + {0x5C, 0x84}, {0x5D, 0x5C}, + {0x5E, 0x08}, {0x5F, 0x00}, {0x60, 0x14}, + {0x61, 0xCE}, {0x62, 0x70}, + {0x63, 0x00}, {0x64, 0x04}, {0x65, 0x00}, + {0x66, 0x00}, {0x69, 0x00}, + {0x6A, 0x3E}, {0x6B, 0x3F}, {0x6C, 0x40}, + {0x6D, 0x30}, {0x6E, 0x4B}, + {0x6F, 0x60}, {0x70, 0x70}, {0x71, 0x70}, + {0x72, 0x70}, {0x73, 0x70}, + {0x74, 0x60}, {0x75, 0x60}, {0x76, 0x50}, + {0x77, 0x48}, {0x78, 0x3A}, + {0x79, 0x2E}, {0x7A, 0x28}, {0x7B, 0x22}, + {0x7C, 0x04}, {0x7D, 0x07}, + {0x7E, 0x10}, {0x7F, 0x28}, {0x80, 0x36}, + {0x81, 0x44}, {0x82, 0x52}, + {0x83, 0x60}, {0x84, 0x6C}, {0x85, 0x78}, + {0x86, 0x8C}, {0x87, 0x9E}, + {0x88, 0xBB}, {0x89, 0xD2}, {0x8A, 0xE6}, + {0x13, 0xAF}, + } + } +}; + +#define CAMERA_COUNT (sizeof(au1xxx_cameras) / sizeof(au1xxx_cameras[0])) + +#endif diff --git a/drivers/char/au1xxx_cim.c b/drivers/char/au1xxx_cim.c new file mode 100644 index 0000000..0890986 --- /dev/null +++ b/drivers/char/au1xxx_cim.c @@ -0,0 +1,647 @@ +/* + * Alchemy Camera Interface (CIM) driver + * + * Copyright 2004 Advanced Micro Devices, 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 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 +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#ifdef CONFIG_MIPS_PB1200 +#include +#endif + +#ifdef CONFIG_MIPS_DB1200 +#include +#endif + +/* + Camera Interface Driver will always work in DBDMA Mode. + PIO Mode will result in OverFlow Error +*/ + +/* + * Global Variables + */ + +#define CIM_NAME "au1xxx_cim" +#define CIM_MAJOR 238 +#define VERSION "1.2" + +/* Number of DMA channel used by CIM interface */ +#define MAX_DBDMA_CHANNEL 3 + +/*Max Command Send over SMbus to configure external camera */ +#define MAX_DEVICE_CMD 115 + +/* Number of descriptor used */ +#define NUM_DBDMA_DESCRIPTORS 1 +#define MAX_FRAME_SIZE (1280*960) + +#undef DEBUG + +#ifdef DEBUG +#define DPRINTK(fmt,args...) \ +printk(KERN_DEBUG "%s: " fmt,__FUNCTION__, ## args) +#else +#define DPRINTK(fmt, args...) +#endif + +static uint32_t nInterruptDoneNumber; +static uint32_t ciminterruptcheck; +static uint32_t prev_mode; +static uint32_t DBDMA_SourceID[] = + { DSCR_CMD0_CIM_RXA, DSCR_CMD0_CIM_RXB, DSCR_CMD0_CIM_RXC }; +static void *mem_buf; + +extern int pb1550_wm_codec_write(u8, u8, u8); + +static volatile AU1200_CIM *au1200_cim = (AU1200_CIM *) CIM_BASE_ADDRESS; + +/* Get the array of camera modes */ +#include "au1xxx_cameras.h" + +typedef struct cim_camera_runtime { + chan_tab_t **ChannelArray[MAX_DBDMA_CHANNEL]; + void *memory[MAX_DBDMA_CHANNEL] ; + uint32_t nTransferSize[MAX_DBDMA_CHANNEL]; + CAMERA *cmos_camera; +} CAMERA_RUNTIME; + +static CAMERA_RUNTIME cam_base; +static CAMERA *OrigCimArryPtr = au1xxx_cameras; + +static int +find_mode_index(uint32_t res_format) +{ + int i; + CAMERA_RUNTIME *findex; + + findex = &cam_base; + findex->cmos_camera = OrigCimArryPtr; + + for (i = 0; i < CAMERA_COUNT; i++) { + if (res_format == (findex->cmos_camera->camera_resformat)) { + + return i; + } + (findex->cmos_camera)++; + } + printk(KERN_ERR " Au1xxx_CIM: ERROR: Camera Index Failed \n"); + return -1; +} + +static void +Cim_DDMA_Done_Interrupt(int irq, void *param, struct pt_regs *regs) +{ + nInterruptDoneNumber++; +} + +static int +Capture_Image(void) +{ + au1200_cim->capture = 0; + au1200_cim->capture = CIM_CAPTURE_CLR; + au1200_cim->capture = CIM_CAPTURE_SCE; + return 1; +} + +static void +Camera_pwr_down(void) +{ + /* Power shut to Camera */ + bcsr->board |= BCSR_BOARD_CAMPWR; +} + +static void +Camera_pwr_up(void) +{ + bcsr->board &= ~BCSR_BOARD_CAMPWR; +} + +static void +CIM_Cleanup(CAMERA_RUNTIME * cim_cleanup) +{ + CAMERA *cim_ptr; + uint32_t frame_size; + int i; + cim_ptr = cim_cleanup->cmos_camera; + frame_size = (cim_ptr->frame_width) * (cim_ptr->frame_height); + + for (i = 0; i < cim_ptr->dbdma_channel; i++) { + if (cim_cleanup->ChannelArray[i]) { + + au1xxx_dbdma_stop((u32) (cim_cleanup->ChannelArray[i])); + au1xxx_dbdma_reset((u32) + (cim_cleanup->ChannelArray[i])); + au1xxx_dbdma_chan_free((u32) + (cim_cleanup->ChannelArray[i])); + } + + if ((cim_cleanup->memory[i]) != NULL) { + free_pages((unsigned long)cim_cleanup->memory[i], + get_order(frame_size)); + } + } + +} + +static int +Camera_Config(CAMERA_RUNTIME * cim_config) +{ + uint32_t nAckCount = 0; + int i, ErrorCheck; + ErrorCheck = 0; + uint32_t nCameraModeConfig = 0; + uint32_t nClearSetInterrupt = 0; + CAMERA *cim_config_ptr; + + cim_config_ptr = cim_config->cmos_camera; + + /* To get rid of hard coded number from Transfer Size */ + /* Now transfer size will be calulated on the on the fly */ + /******************************************************************* + In YCbCr 4:2:2 data size is twice the frame size + Y=Frame Size + Cb=Frame Size/2 + Cr=Frame Size/2 + Total size of Frame: Y+Cb+Cr effectively 2*FrameSize + *********************************************************************/ + + if ((cim_config_ptr->au1200_dpsmode) == CIM_CONFIG_RAW) { + if (cim_config_ptr->cmos_output_format == CMOS_CCIR656) { + + cim_config->nTransferSize[0] = + 2 * (cim_config_ptr->frame_width) * + (cim_config_ptr->frame_height); + DPRINTK("FIFO-A YCbCR Transfer Size in Raw mode %d \n", + cim_config->nTransferSize[0]); + } else { + cim_config->nTransferSize[0] = + (cim_config_ptr->frame_width) * + (cim_config_ptr->frame_height); + DPRINTK("FIFO-A Transfer Size in Raw mode %d \n", + cim_config->nTransferSize[0]); + } + cim_config->memory[0] = mem_buf; + } else if ((cim_config_ptr->au1200_dpsmode) == CIM_CONFIG_BAYER) { + /* FIFO A Hold Red Pixels which is Total Pixels/4 */ + cim_config->nTransferSize[0] = + ((cim_config_ptr->frame_width) * + (cim_config_ptr->frame_height)) / 4; + cim_config->nTransferSize[1] = + ((cim_config_ptr->frame_width) * + (cim_config_ptr->frame_height)) / 2; + cim_config->nTransferSize[2] = + ((cim_config_ptr->frame_width) * + (cim_config_ptr->frame_height)) / 4; + + cim_config->memory[0] = mem_buf; + cim_config->memory[1] = mem_buf + cim_config->nTransferSize[0]; + cim_config->memory[2] = mem_buf + cim_config->nTransferSize[0] + + cim_config->nTransferSize[1]; + } else { + cim_config->nTransferSize[0] = + ((cim_config_ptr->frame_width) * + (cim_config_ptr->frame_height)); + cim_config->nTransferSize[1] = + ((cim_config_ptr->frame_width) * + (cim_config_ptr->frame_height)) / 2; + cim_config->nTransferSize[2] = + ((cim_config_ptr->frame_width) * + (cim_config_ptr->frame_height)) / 2; + + cim_config->memory[0] = mem_buf; + cim_config->memory[1] = mem_buf + cim_config->nTransferSize[0]; + cim_config->memory[2] = mem_buf + cim_config->nTransferSize[0] + + cim_config->nTransferSize[1]; + + } + + for (i = 0; i < cim_config->cmos_camera->dbdma_channel; i++) { + /* Allocate Channel */ + cim_config->ChannelArray[i] = + (chan_tab_t **) au1xxx_dbdma_chan_alloc(DBDMA_SourceID[i], + DSCR_CMD0_ALWAYS, + Cim_DDMA_Done_Interrupt, + (void *)NULL); + + if (cim_config->ChannelArray[i] != NULL) { + au1xxx_dbdma_set_devwidth((u32) + (cim_config->ChannelArray[i]), + 32); + if (au1xxx_dbdma_ring_alloc + ((u32) (cim_config->ChannelArray[i]), 16) == 0) { + printk(KERN_ERR \ + "Failed to allocate a DDMA channel\n"); + + ErrorCheck++; + goto error_ch_alloc; + } + au1xxx_dbdma_start((u32) (cim_config->ChannelArray[i])); + int j = 0; + for (j = 0; j < NUM_DBDMA_DESCRIPTORS; j++) { + + if (!au1xxx_dbdma_put_dest + ((u32) (cim_config->ChannelArray[i]), + cim_config->memory[i], + cim_config->nTransferSize[i])) { + printk(KERN_ERR \ + "Error while putting descriptor on DBDMA channnel.\n"); + } + } + + } else { + ErrorCheck++; + goto error_ch_alloc; + } + + } + + for (i = 0; i < cim_config_ptr->cmd_size; i++) { + while ((pb1550_wm_codec_write(cim_config_ptr->device_addr, + cim_config_ptr->config_cmd[i][0], + cim_config_ptr-> + config_cmd[i][1]) != 1) + && (nAckCount < 50)) { + nAckCount++; + } + if (i == 0) { + mdelay(1); + } + + } + if (nAckCount == 50) { + printk(KERN_ERR "External CMOS Camera Not Present or not properly connected !!!! !\n"); + goto error_ch_alloc; + } + + au1200_cim->enable = CIM_ENABLE_EN; + au1200_cim->capture = CIM_CAPTURE_CLR; + + if (cim_config_ptr->au1200_dpsmode == 1) { + nCameraModeConfig = + CIM_CONFIG_DPS_N(cim_config_ptr-> + au1200_dpsmode) | CIM_CONFIG_FS | + CIM_CONFIG_BAY_N(cim_config_ptr-> + au1200_baymode) | CIM_CONFIG_BYT | + CIM_CONFIG_LEN(CIM_CONFIG_LEN_10BIT); + } else if (cim_config_ptr->au1200_dpsmode == 0) { + nCameraModeConfig = + CIM_CONFIG_DPS_N(cim_config_ptr-> + au1200_dpsmode) | CIM_CONFIG_FS | + CIM_CONFIG_BYT | CIM_CONFIG_LEN(CIM_CONFIG_LEN_10BIT) | + CIM_CONFIG_BAY_N(cim_config_ptr-> + au1200_baymode) | CIM_CONFIG_PM; + } else { + /* Need to re check........ */ + nCameraModeConfig = + CIM_CONFIG_DPS_N(cim_config_ptr-> + au1200_dpsmode) | CIM_CONFIG_FS | + CIM_CONFIG_BYT | CIM_CONFIG_LEN(CIM_CONFIG_LEN_10BIT) | + CIM_CONFIG_FSEL_N(CIM_CONFIG_FIELD12); + } + + au1200_cim->config = nCameraModeConfig; + nClearSetInterrupt = CIM_INSTAT_CD | CIM_INSTAT_FD | + CIM_INSTAT_UFA | CIM_INSTAT_OFA | + CIM_INSTAT_UFB | CIM_INSTAT_OFB | CIM_INSTAT_UFB | CIM_INSTAT_OFC; + + au1200_cim->instat = nClearSetInterrupt; + au1200_cim->inten = nClearSetInterrupt; + + for (i = 0; i < 6; i++) { + mdelay(1); + } + + error_ch_alloc: + if (ErrorCheck) { + CIM_Cleanup(cim_config); + return -1; + } + return 0; +} + +#define MAX_GFP 0x00200000 + +/* To get contigious Memroy location using GetFree pages*/ + +static unsigned long +Camera_mem_alloc(unsigned long size) +{ + /* __get_free_pages() fulfills a max request of 2MB */ + /* do multiple requests to obtain large contigous mem */ + + unsigned long mem, amem, alloced = 0, allocsize; + + size += 0x1000; + allocsize = (size < MAX_GFP) ? size : MAX_GFP; + + /* Get first chunk */ + mem = (unsigned long) + __get_free_pages(GFP_ATOMIC | GFP_DMA, get_order(allocsize)); + if (mem != 0) + alloced = allocsize; + + /* Get remaining, contiguous chunks */ + while (alloced < size) { + amem = (unsigned long) + __get_free_pages(GFP_ATOMIC | GFP_DMA, + get_order(allocsize)); + if (amem != 0) + alloced += allocsize; + + /* check for contiguous mem alloced */ + if ((amem == 0) || (amem + allocsize) != mem) + break; + else + mem = amem; + } + return mem; +} + +static irqreturn_t +Cim_Interrupt_Handler(int irq, void *dev_id,struct pt_regs *regs) +{ + + uint32_t nStatus; + + disable_irq(AU1200_CAMERA_INT); + nStatus = au1200_cim->instat; + + if (nStatus & CIM_INSTAT_CD) { + au1200_cim->instat = CIM_INSTAT_CD; + } else if (nStatus & CIM_INSTAT_FD) { + au1200_cim->instat = CIM_INSTAT_FD; + } else if (nStatus & CIM_INSTAT_UFA) { + au1200_cim->instat = CIM_INSTAT_UFA; + ciminterruptcheck = 1; + } else if (nStatus & CIM_INSTAT_OFA) { + au1200_cim->instat = CIM_INSTAT_OFA; + ciminterruptcheck = 1; + } else if (nStatus & CIM_INSTAT_UFB) { + au1200_cim->instat = CIM_INSTAT_UFB; + ciminterruptcheck = 1; + } else if (nStatus & CIM_INSTAT_OFB) { + au1200_cim->instat = CIM_INSTAT_OFB; + ciminterruptcheck = 1; + } else if (nStatus & CIM_INSTAT_UFC) { + au1200_cim->instat = CIM_INSTAT_UFC; + ciminterruptcheck = 1; + } else if (nStatus & CIM_INSTAT_OFC) { + au1200_cim->instat = CIM_INSTAT_OFC; + ciminterruptcheck = 1; + } else if (nStatus & CIM_INSTAT_ERR) { + au1200_cim->instat = CIM_INSTAT_ERR; + } + + enable_irq(AU1200_CAMERA_INT); + return IRQ_HANDLED; +} + +static int +au1xxxcim_ioctl(struct inode *inode, struct file *file, + unsigned int cmd, unsigned long arg) +{ + nInterruptDoneNumber = 0; + uint32_t mode_index, i; + CAMERA_RUNTIME *capture; + CAMERA *capture_ptr; + + capture = &cam_base; + + switch (cmd) { + + case AU1XXXCIM_QUERY:{ + /*returing previous mode */ + DPRINTK + ("QUERY Mode- Return Camera Index to Application is %d \n", + prev_mode); + return prev_mode; + } + case AU1XXXCIM_CONFIGURE:{ + DPRINTK(" CONFIGURE Mode\n"); + mode_index = find_mode_index(arg); + capture->cmos_camera = OrigCimArryPtr + prev_mode; + capture_ptr = capture->cmos_camera; + DPRINTK + ("CONFIGURE Mode: Calling CleanUP as Camera needs to be re-configured \n"); + CIM_Cleanup(capture); + DPRINTK("CONFIGURE:Camera Array Index value is %d \n", + mode_index); + capture->cmos_camera = OrigCimArryPtr + mode_index; + capture_ptr = capture->cmos_camera; + DPRINTK + (" CONFIGURE: Camera configured in ** %s ** Mode \n", + capture_ptr->camera_mode); + au1200_cim->enable &= ~CIM_ENABLE_EN; + Camera_Config(capture); + Camera_pwr_down(); + mdelay(1); + Camera_pwr_up(); + mdelay(6); + prev_mode = mode_index; + return mode_index; + } + case AU1XXXCIM_CAPTURE:{ + capture->cmos_camera = OrigCimArryPtr + prev_mode; + capture_ptr = capture->cmos_camera; + DPRINTK("CAPTURE: Camera Array Index # %d \n", + prev_mode); + DPRINTK("CAPTURE:Picture taken in **%s** Mode \n", + capture_ptr->camera_mode); + Capture_Image(); + DPRINTK("CAPTURE:Status Reg %x Capture Reg %x \n", + au1200_cim->stat, au1200_cim->capture); + DPRINTK("Waiting for %d DMA Interrupt \n", + capture_ptr->dbdma_channel); + while ((nInterruptDoneNumber != + (capture_ptr->dbdma_channel)) + && (!ciminterruptcheck)) ; + + if (ciminterruptcheck) { + printk(" !! ERROR: DMA Transfer Error \n"); + ciminterruptcheck = 0; + return 0; + } + + DPRINTK + ("CAPTURE:Putting back descriptor back to ring\n"); + for (i = 0; i < capture_ptr->dbdma_channel; i++) { + if (!au1xxx_dbdma_put_dest + ((u32) (capture->ChannelArray[i]), + capture->memory[i], + capture->nTransferSize[i])) { + printk + ("DBDMA Error..Putting Descriptor on Buffer Ring Channel A in Single Channel \n"); + } + } + DPRINTK(" CAPTURE: Exiting Capture \n"); + + return 1; + break; + } + + } + + return -EINVAL; +} + +static int +au1xxxcim_mmap(struct file *file, struct vm_area_struct *vma) +{ + unsigned int len; + unsigned long start = 0, off; + + if (vma->vm_pgoff > (~0UL >> PAGE_SHIFT)) { + printk(" Error vma->vm_pgoff > !OUL PAGE_SHIFT \n"); + return -EINVAL; + } + + start = virt_to_phys(mem_buf) & PAGE_MASK; + len = PAGE_ALIGN((start & ~PAGE_MASK) + 2 * MAX_FRAME_SIZE); + off = vma->vm_pgoff << PAGE_SHIFT; + + if ((vma->vm_end - vma->vm_start + off) > len) { + printk(" Error vma->vm_end-vma->vm_start\n"); + return -EINVAL; + } + + off += start; + vma->vm_pgoff = off >> PAGE_SHIFT; + pgprot_val(vma->vm_page_prot) &= ~_CACHE_MASK; + pgprot_val(vma->vm_page_prot) |= PAGE_CACHABLE_DEFAULT; + + /* This is an IO map - tell maydump to skip this VMA */ + vma->vm_flags |= VM_IO; + + return io_remap_pfn_range(vma, vma->vm_start, off, + vma->vm_end - vma->vm_start, + vma->vm_page_prot); +} + +static struct file_operations au1xxxcim_fops = { + owner:THIS_MODULE, + ioctl:au1xxxcim_ioctl, + mmap:au1xxxcim_mmap +}; + +int __init +au1xxxcim_init(void) +{ + int retval, error; + unsigned long page; + CAMERA_RUNTIME *cam_init; + CAMERA *cim_ptr; + + cam_init = &cam_base; + cam_init->cmos_camera = OrigCimArryPtr + prev_mode; + cim_ptr = cam_init->cmos_camera; + + /*Allocating memory for MMAP */ + mem_buf = (unsigned long *)Camera_mem_alloc(2 * MAX_FRAME_SIZE); + if (mem_buf == NULL) { + printk(KERN_ERR "MMAP unable to allocate memory \n"); + } + + for (page = (unsigned long)mem_buf; + page < PAGE_ALIGN((unsigned long)mem_buf + MAX_FRAME_SIZE); + page += PAGE_SIZE) { + SetPageReserved(virt_to_page(page)); + } + Camera_pwr_up(); + error = Camera_Config(cam_init); + if (error == -1) { + DPRINTK + ("Camera Config Un-Sucessful: Calling Clean Up function \n"); + CIM_Cleanup(cam_init); + } + + Camera_pwr_down(); + mdelay(1); + Camera_pwr_up(); + + /* Register Device */ + retval = register_chrdev(CIM_MAJOR, CIM_NAME, &au1xxxcim_fops); + if (retval < 0) { + printk(KERN_ERR "Could not register CIM device\n"); + return 0; + } + printk(KERN_INFO "Au1XXX CIM driver registered Sucessfully v%s\n", + VERSION); + if ((retval = + request_irq(AU1200_CAMERA_INT, Cim_Interrupt_Handler, + SA_SHIRQ | SA_INTERRUPT, CIM_NAME, + (void *)au1200_cim))) { + printk(KERN_ERR "CIM: Could not get IRQ %d.\n", + AU1200_CAMERA_INT); + CIM_Cleanup(cam_init); + return retval; + } + + return 0; + +} + +void __exit +au1xxxcim_exit(void) +{ + int retval; + CAMERA_RUNTIME *cam_exit; + CAMERA *cam_exit_ptr; + + cam_exit = &cam_base; + cam_exit->cmos_camera = OrigCimArryPtr + prev_mode; + cam_exit_ptr = cam_exit->cmos_camera; + + /* Cleanup funtion will clean allocated memory, free DMA channels */ + CIM_Cleanup(cam_exit); + + /*Unregister Device */ + retval = unregister_chrdev(CIM_MAJOR, CIM_NAME); + if (retval != -EINVAL) { + printk(KERN_INFO "CIM driver unregistered Sucessfully \n"); + } +} + +module_init(au1xxxcim_init); +module_exit(au1xxxcim_exit); + +MODULE_AUTHOR("AMD"); +MODULE_DESCRIPTION("AMD CIM Interface Driver"); +MODULE_LICENSE("GPL"); diff --git a/include/asm-mips/mach-au1x00/au1xxx_cim.h b/include/asm-mips/mach-au1x00/au1xxx_cim.h new file mode 100644 index 0000000..50fe557 --- /dev/null +++ b/include/asm-mips/mach-au1x00/au1xxx_cim.h @@ -0,0 +1,190 @@ + /* Defines for using the Camera Interfaces on the + * Alchemy Au1100 mips processor. + * + * 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. + * + */ +#ifndef AUXXX_CIM_H +#define AUXXX_CIM_H + +#include + +#define AU1XXXCIM_IOC_MAGIC 'C' + +#define RAW_SXGA _IOW(AU1XXXCIM_IOC_MAGIC,1, int *) +#define RAW_VGA _IOW(AU1XXXCIM_IOC_MAGIC,2, int *) +#define RAW_CIF _IOW(AU1XXXCIM_IOC_MAGIC,3, int *) +#define RAW_QVGA _IOW(AU1XXXCIM_IOC_MAGIC,4, int *) +#define RAW_QCIF _IOW(AU1XXXCIM_IOC_MAGIC,5, int *) +#define RAW_QQVGA _IOW(AU1XXXCIM_IOC_MAGIC,6, int *) +#define RAW_QQCIF _IOW(AU1XXXCIM_IOC_MAGIC,7, int *) +#define BAYER_SXGA _IOW(AU1XXXCIM_IOC_MAGIC,8, int *) +#define BAYER_VGA _IOW(AU1XXXCIM_IOC_MAGIC,9, int *) +#define BAYER_CIF _IOW(AU1XXXCIM_IOC_MAGIC,10, int *) +#define BAYER_QVGA _IOW(AU1XXXCIM_IOC_MAGIC,11, int *) +#define BAYER_QCIF _IOW(AU1XXXCIM_IOC_MAGIC,12, int *) +#define BAYER_QQVG _IOW(AU1XXXCIM_IOC_MAGIC,13, int *) +#define BAYER_QQCI _IOW(AU1XXXCIM_IOC_MAGIC,14, int *) +#define YCbCr_SXGA_RAW _IOW(AU1XXXCIM_IOC_MAGIC,18, int *) +#define YCbCr_VGA_RAW _IOW(AU1XXXCIM_IOC_MAGIC,19, int *) +#define YCbCr_CIF_RAW _IOW(AU1XXXCIM_IOC_MAGIC,20, int *) +#define YCbCr_QVGA_RAW _IOW(AU1XXXCIM_IOC_MAGIC,21, int *) +#define YCbCr_QCIF_RAW _IOW(AU1XXXCIM_IOC_MAGIC,22, int *) +#define YCbCr_SXGA _IOW(AU1XXXCIM_IOC_MAGIC,23, int *) +#define YCbCr_VGA _IOW(AU1XXXCIM_IOC_MAGIC,24, int *) +#define YCbCr_CIF _IOW(AU1XXXCIM_IOC_MAGIC,25, int *) +#define YCbCr_QVGA _IOW(AU1XXXCIM_IOC_MAGIC,26, int *) +#define YCbCr_QCIF _IOW(AU1XXXCIM_IOC_MAGIC,27, int *) +#define AU1XXXCIM_CAPTURE _IOW(AU1XXXCIM_IOC_MAGIC, 100, int *) +#define AU1XXXCIM_QUERY _IOW(AU1XXXCIM_IOC_MAGIC, 50, int *) +#define AU1XXXCIM_CONFIGURE _IOW(AU1XXXCIM_IOC_MAGIC, 75, int *) + +#define CMOS_RAW 0 +#define CMOS_CCIR656 1 + +#define CIM_BASE_ADDRESS 0xB4004000 + +#define CIM_FIFOA 0xB4004020 +#define CIM_FIFOB 0xB4004040 +#define CIM_FIFOC 0xB4004060 + +typedef struct +{ + unsigned long enable; /* 00 */ + unsigned long config; /* 04 */ + unsigned long reserve0; /* 08 */ + unsigned long reserve1; /* 0C */ + unsigned long capture; /* 10 */ + unsigned long stat; /* 14 */ + unsigned long inten; /* 18 */ + unsigned long instat; /* 1C */ + unsigned long fifoa; /* 20 */ + unsigned long reserve2; /* 24 */ + unsigned long reserve3; /* 28 */ + unsigned long reserve4; /* 2C */ + unsigned long reserve5; /* 30 */ + unsigned long reserve6; /* 34 */ + unsigned long reserve7; /* 38 */ + unsigned long reserve8; /* 3C */ + unsigned long fifob; /* 40 */ + unsigned long reserve9; /* 44 */ + unsigned long reserve10; /* 48 */ + unsigned long reserve11; /* 4C */ + unsigned long reserve12; /* 50 */ + unsigned long reserve13; /* 54 */ + unsigned long reserve14; /* 58 */ + unsigned long reserve15; /* 5C */ + unsigned long fifoc; /* 60 */ +}AU1200_CIM; + + +#define CIM_ENABLE 0x00000000 +#define CIM_CONFIG 0x00000004 +#define CIM_CAPTURE 0x00000010 +#define CIM_STAT 0x00000014 +#define CIM_INTEN 0x00000018 +#define CIM_INSTAT 0x0000001C + +#define CIM_ENABLE_EN (1<<0) /* enable/disable/reset the block*/ + +/* CIM Configuration Register */ + +#define CIM_CONFIG_PM (1<<0) +#define CIM_CONFIG_CLK (1<<1) /* Rising Edge of the Clock */ +#define CIM_CONFIG_LS (1<<2) /* Line Sync Active Low */ +#define CIM_CONFIG_FS (1<<3) /* Frame Sync is Active Low */ + +#define CIM_CONFIG_RAW 0 /* RAW MODE */ +#define CIM_CONFIG_BAYER 1 /*Bayer Mode*/ +#define CIM_CONFIG_656 2 /* 656 YCbCr Mode*/ + +#define CIM_CONFIG_DPS_N(n) (((n) & 0x03)<<6) + + +#define CIM_CONFIG_RGGB 0 +#define CIM_CONFIG_GRBG 1 +#define CIM_CONFIG_BGGR 2 +#define CIM_CONFIG_GBRG 3 + +#define CIM_CONFIG_BAY_N(n) (((n) & 0x03)<<8) + +#define CIM_CONFIG_LEN_8BIT 0 +#define CIM_CONFIG_LEN_9BIT 1 +#define CIM_CONFIG_LEN_10BIT 2 + + +#define CIM_CONFIG_LEN(n) (((n) & 0x0f)<<10) +#define CIM_CONFIG_BYT (1<<14) +#define CIM_CONFIG_SF (1<<15) + +#define CIM_CONFIG_FIELD1 0 /* Capture from Field 1*/ +#define CIM_CONFIG_FIELD2 1 /*Capture from Field 2*/ +#define CIM_CONFIG_FIELD12 2 /*Capture from Either Field*/ + +#define CIM_CONFIG_FSEL_N(n) (((n) & 0x03)<<16) + +#define CIM_CONFIG_SI (1<<18) + +/* CIM Capture Control Register */ + +#define CIM_CAPTURE_VCE (1<<0) +#define CIM_CAPTURE_SCE (1<<1) +#define CIM_CAPTURE_CLR (1<<2) + +/* CIM Status Register */ + +#define CIM_STATUS_VC (1<<0) +#define CIM_STATUS_SC (1<<1) +#define CIM_STATUS_AF (1<<2) +#define CIM_STATUS_AE (1<<3) +#define CIM_STATUS_AR (1<<4) +#define CIM_STATUS_BF (1<<5) +#define CIM_STATUS_BE (1<<6) +#define CIM_STATUS_BR (1<<7) +#define CIM_STATUS_CF (1<<8) +#define CIM_STATUS_CE (1<<9) +#define CIM_STATUS_CR (1<<10) + + +/* Interrupt Rgister */ +#define CIM_INTEN_CD (1<<0) +#define CIM_INTEN_FD (1<<1) +#define CIM_INTEN_UFA (1<<2) +#define CIM_INTEN_OFA (1<<3) +#define CIM_INTEN_UFB (1<<4) +#define CIM_INTEN_OFB (1<<5) +#define CIM_INTEN_UFC (1<<6) +#define CIM_INTEN_OFC (1<<7) +#define CIM_INTEN_ERR (1<<8) + + +/* Interrupt Status Rgister */ + +#define CIM_INSTAT_CD (1<<0) +#define CIM_INSTAT_FD (1<<1) +#define CIM_INSTAT_UFA (1<<2) +#define CIM_INSTAT_OFA (1<<3) +#define CIM_INSTAT_UFB (1<<4) +#define CIM_INSTAT_OFB (1<<5) +#define CIM_INSTAT_UFC (1<<6) +#define CIM_INSTAT_OFC (1<<7) +#define CIM_INSTAT_ERR (1<<8) + +#endif From drzeus@drzeus.cx Fri Dec 2 19:38:33 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 02 Dec 2005 19:38:51 +0000 (GMT) Received: from [85.8.13.51] ([85.8.13.51]:9896 "EHLO smtp.drzeus.cx") by ftp.linux-mips.org with ESMTP id S8133868AbVLBTid (ORCPT ); Fri, 2 Dec 2005 19:38:33 +0000 Received: from [10.100.1.247] ([::ffff:213.115.244.31]) (AUTH: PLAIN drzeus, TLS: TLSv1/SSLv3,256bits,AES256-SHA) by smtp.drzeus.cx with esmtp; Fri, 02 Dec 2005 20:42:07 +0100 id 0006271A.4390A390.00006C1A Message-ID: <4390A38A.1010907@drzeus.cx> Date: Fri, 02 Dec 2005 20:42:02 +0100 From: Pierre Ossman User-Agent: Mail/News 1.5 (X11/20051129) MIME-Version: 1.0 To: Jordan Crouse CC: linux-mips@linux-mips.org, ralf@linux-mips.org, Russell King Subject: Re: [PATCH] ALCHEMY: Add SD support to AU1200 MMC/SD driver References: <20051202190108.GF28227@cosmic.amd.com> In-Reply-To: <20051202190108.GF28227@cosmic.amd.com> X-Enigmail-Version: 0.93.0.0 Content-Type: text/plain; charset=ISO-8859-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: 9581 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: drzeus@drzeus.cx Precedence: bulk X-list: linux-mips Jordan Crouse wrote: > Add SD support to the AU1200 MMC driver. This can > be added post 2.6.15, I'm just sending them out today so the various > maintainers can get them queued up. > > Signed-off-by: Jordan Crouse > --- > > drivers/mmc/au1xmmc.c | 124 ++++++++++++++++++++++++++++--------------------- > 1 files changed, 71 insertions(+), 53 deletions(-) > Russell is still the maintainer of the MMC layer. :) I still have some comments though. > @@ -124,8 +132,8 @@ static inline void IRQ_OFF(struct au1xmm > static inline void SEND_STOP(struct au1xmmc_host *host) > { > > - /* We know the value of CONFIG2, so avoid a read we don't need */ > - u32 mask = SD_CONFIG2_EN; > + /* Penalty box for Jordan - NEVER ASSUME! */ > + u32 mask = au_readl(HOST_CONFIG2(host)); > > WARN_ON(host->status != HOST_S_DATA); > host->status = HOST_S_STOP; This comment will be terribly confusing to anyone reading your code. > @@ -196,7 +207,11 @@ static int au1xmmc_send_command(struct a > > switch(cmd->flags) { > case MMC_RSP_R1: > - mmccmd |= SD_CMD_RT_1; > + if (cmd->opcode == 0x03 && host->mmc->mode == MMC_MODE_SD) > + mmccmd |= SD_CMD_RT_6; > + else > + mmccmd |= SD_CMD_RT_1; > + > break; > case MMC_RSP_R1B: > mmccmd |= SD_CMD_RT_1B; No, no, no! Even if this wasn't already fixed in the current kernel you never hack around bugs in other parts of the kernel, you fix them! > @@ -504,8 +519,8 @@ static void au1xmmc_cmd_complete(struct > r[3] = au_readl(host->iobase + SD_RESP0); > > /* The CRC is omitted from the response, so really we only got > - * 120 bytes, but the engine expects 128 bits, so we have to shift > - * things up > + * 120 bytes, but the engine expects 128 bits, so we have to > + * shift things up > */ > > for(i = 0; i < 4; i++) { s/bytes/bits/ > @@ -611,7 +635,7 @@ au1xmmc_prepare_data(struct au1xmmc_host > > int len = (datalen > sg_len) ? sg_len : datalen; > > - if (i == host->dma.len - 1) > + if (i == (host->dma.len - 1)) > flags = DDMA_FLAGS_IE; > > if (host->flags & HOST_F_XMIT){ broken indentation. > @@ -627,23 +651,11 @@ au1xmmc_prepare_data(struct au1xmmc_host > len, flags); > } > > - if (!ret) > + if (ret == 0) > goto dataerr; > > datalen -= len; > } > - } > - else { > - host->pio.index = 0; > - host->pio.offset = 0; > - host->pio.len = datalen; > - > - if (host->flags & HOST_F_XMIT) > - IRQ_ON(host, SD_CONFIG_TH); > - else > - IRQ_ON(host, SD_CONFIG_NE); > - //IRQ_ON(host, SD_CONFIG_RA|SD_CONFIG_RF); > - } > > return MMC_ERR_NONE; > Here aswell. And it seems the block above will get the wrong indentation. Rgds Pierre From rmk+linux-mips=linux-mips.org@arm.linux.org.uk Fri Dec 2 19:42:10 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 02 Dec 2005 19:42:29 +0000 (GMT) Received: from caramon.arm.linux.org.uk ([212.18.232.186]:18187 "EHLO caramon.arm.linux.org.uk") by ftp.linux-mips.org with ESMTP id S8133874AbVLBTmK (ORCPT ); Fri, 2 Dec 2005 19:42:10 +0000 Received: from flint.arm.linux.org.uk ([2002:d412:e8ba:1:201:2ff:fe14:8fad]) by caramon.arm.linux.org.uk with esmtpsa (TLSv1:DES-CBC3-SHA:168) (Exim 4.52) id 1EiGqn-0007Up-6j; Fri, 02 Dec 2005 19:45:45 +0000 Received: from rmk by flint.arm.linux.org.uk with local (Exim 4.52) id 1EiGqd-00036l-VQ; Fri, 02 Dec 2005 19:45:36 +0000 Date: Fri, 2 Dec 2005 19:45:35 +0000 From: Russell King To: Pierre Ossman Cc: Jordan Crouse , linux-mips@linux-mips.org, ralf@linux-mips.org Subject: Re: [PATCH] ALCHEMY: Add SD support to AU1200 MMC/SD driver Message-ID: <20051202194534.GB3780@flint.arm.linux.org.uk> References: <20051202190108.GF28227@cosmic.amd.com> <4390A38A.1010907@drzeus.cx> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4390A38A.1010907@drzeus.cx> User-Agent: Mutt/1.4.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: 9582 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: rmk@arm.linux.org.uk Precedence: bulk X-list: linux-mips On Fri, Dec 02, 2005 at 08:42:02PM +0100, Pierre Ossman wrote: > Jordan Crouse wrote: > > Add SD support to the AU1200 MMC driver. This can > > be added post 2.6.15, I'm just sending them out today so the various > > maintainers can get them queued up. > > > > Signed-off-by: Jordan Crouse > > --- > > > > drivers/mmc/au1xmmc.c | 124 ++++++++++++++++++++++++++++--------------------- > > 1 files changed, 71 insertions(+), 53 deletions(-) > > > > Russell is still the maintainer of the MMC layer. :) Indeed. Jordan - please send me a copy of the patch. Thanks. Note that I agree with Pierre's comments. -- Russell King Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of: 2.6 Serial core From jcrouse@cosmic.amd.com Fri Dec 2 21:07:59 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 02 Dec 2005 21:08:21 +0000 (GMT) Received: from amdext3.amd.com ([139.95.251.6]:21658 "EHLO amdext3.amd.com") by ftp.linux-mips.org with ESMTP id S8133539AbVLBVH7 (ORCPT ); Fri, 2 Dec 2005 21:07:59 +0000 Received: from SSVLGW01.amd.com (ssvlgw01.amd.com [139.95.250.169]) by amdext3.amd.com (8.12.11/8.12.11/AMD) with ESMTP id jB2LBCqU017942; Fri, 2 Dec 2005 13:11:13 -0800 Received: from 139.95.250.1 by SSVLGW02.amd.com with ESMTP (AMD SMTP Relay (Email Firewall v6.1.0)); Fri, 02 Dec 2005 13:09:22 -0800 X-Server-Uuid: 519AC16A-9632-469E-B354-112C592D09E8 Received: from ldcmail.amd.com (ldcmail.amd.com [147.5.200.40]) by amdint.amd.com (8.12.8/8.12.8/AMD) with ESMTP id jB2L9LQe028963; Fri, 2 Dec 2005 13:09:21 -0800 (PST) Received: from cosmic.amd.com (cosmic.amd.com [147.5.201.206]) by ldcmail.amd.com (Postfix) with ESMTP id 106FC2026; Fri, 2 Dec 2005 14:09:21 -0700 (MST) Received: from cosmic.amd.com (localhost [127.0.0.1]) by cosmic.amd.com (8.13.4/8.13.4) with ESMTP id jB2LH96p000345; Fri, 2 Dec 2005 14:17:09 -0700 Received: (from jcrouse@localhost) by cosmic.amd.com ( 8.13.4/8.13.4/Submit) id jB2LH9Uo000344; Fri, 2 Dec 2005 14:17:09 -0700 Date: Fri, 2 Dec 2005 14:17:09 -0700 From: "Jordan Crouse" To: "Pierre Ossman" cc: linux-mips@linux-mips.org, ralf@linux-mips.org, "Russell King" Subject: Re: ALCHEMY: Add SD support to AU1200 MMC/SD driver Message-ID: <20051202211709.GL28227@cosmic.amd.com> References: <20051202190108.GF28227@cosmic.amd.com> <4390A38A.1010907@drzeus.cx> MIME-Version: 1.0 In-Reply-To: <4390A38A.1010907@drzeus.cx> User-Agent: Mutt/1.5.11 X-WSS-ID: 6F8E67881IW1481965-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: 9583 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 02/12/05 20:42 +0100, Pierre Ossman wrote: > Jordan Crouse wrote: > > @@ -196,7 +207,11 @@ static int au1xmmc_send_command(struct a > > > > switch(cmd->flags) { > > case MMC_RSP_R1: > > - mmccmd |= SD_CMD_RT_1; > > + if (cmd->opcode == 0x03 && host->mmc->mode == MMC_MODE_SD) > > + mmccmd |= SD_CMD_RT_6; > > + else > > + mmccmd |= SD_CMD_RT_1; > > + > > break; > > case MMC_RSP_R1B: > > mmccmd |= SD_CMD_RT_1B; > > No, no, no! Even if this wasn't already fixed in the current kernel you > never hack around bugs in other parts of the kernel, you fix them! As of a git pull about 30 minutes ago, both MMC_RSP_R1 and MMC_RSP_R6 resolve to (MMC_RSP_SHORT|MMC_RSP_CRC). Now, I really wouldn't call that a bug in the subsystem, because it is technically correct, but the Au1200 needs us to specifically specify if the required response is an R1 or an R6, thus the specified logic. Jordan -- Jordan Crouse Senior Linux Engineer AMD - Personal Connectivity Solutions Group From drzeus@drzeus.cx Fri Dec 2 22:02:08 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 02 Dec 2005 22:02:26 +0000 (GMT) Received: from [85.8.13.51] ([85.8.13.51]:13736 "EHLO smtp.drzeus.cx") by ftp.linux-mips.org with ESMTP id S8133598AbVLBWCI (ORCPT ); Fri, 2 Dec 2005 22:02:08 +0000 Received: from [10.100.1.247] ([::ffff:213.115.244.31]) (AUTH: PLAIN drzeus, TLS: TLSv1/SSLv3,256bits,AES256-SHA) by smtp.drzeus.cx with esmtp; Fri, 02 Dec 2005 23:05:48 +0100 id 00062717.4390C53C.00007287 Message-ID: <4390C53A.70606@drzeus.cx> Date: Fri, 02 Dec 2005 23:05:46 +0100 From: Pierre Ossman User-Agent: Mail/News 1.5 (X11/20051129) MIME-Version: 1.0 To: Jordan Crouse CC: linux-mips@linux-mips.org, ralf@linux-mips.org, Russell King Subject: Re: ALCHEMY: Add SD support to AU1200 MMC/SD driver References: <20051202190108.GF28227@cosmic.amd.com> <4390A38A.1010907@drzeus.cx> <20051202211709.GL28227@cosmic.amd.com> In-Reply-To: <20051202211709.GL28227@cosmic.amd.com> X-Enigmail-Version: 0.93.0.0 Content-Type: text/plain; charset=ISO-8859-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: 9584 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: drzeus@drzeus.cx Precedence: bulk X-list: linux-mips Jordan Crouse wrote: > On 02/12/05 20:42 +0100, Pierre Ossman wrote: >> Jordan Crouse wrote: >>> @@ -196,7 +207,11 @@ static int au1xmmc_send_command(struct a >>> >>> switch(cmd->flags) { >>> case MMC_RSP_R1: >>> - mmccmd |= SD_CMD_RT_1; >>> + if (cmd->opcode == 0x03 && host->mmc->mode == MMC_MODE_SD) >>> + mmccmd |= SD_CMD_RT_6; >>> + else >>> + mmccmd |= SD_CMD_RT_1; >>> + >>> break; >>> case MMC_RSP_R1B: >>> mmccmd |= SD_CMD_RT_1B; >> No, no, no! Even if this wasn't already fixed in the current kernel you >> never hack around bugs in other parts of the kernel, you fix them! > > As of a git pull about 30 minutes ago, both MMC_RSP_R1 and MMC_RSP_R6 resolve > to (MMC_RSP_SHORT|MMC_RSP_CRC). Now, I really wouldn't call that a > bug in the subsystem, because it is technically correct, but the Au1200 > needs us to specifically specify if the required response is an R1 or > an R6, thus the specified logic. > Point, but then you should figure out the distinction and why the controller requires it (I assume you have tried giving the controller "incorrect" settings). At that point the MMC layer can be extended to handle this in a general manner instead of hacks in every other driver. Judging from your email address you seem to be at a good position to find out what the problem is. Rgds Pierre From Philippedeswert@scarlet.be Sun Dec 4 23:28:08 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 04 Dec 2005 23:28:36 +0000 (GMT) Received: from p549F6917.dip.t-dialin.net ([84.159.105.23]:27880 "EHLO p549F6917.dip.t-dialin.net") by ftp.linux-mips.org with ESMTP id S8133543AbVLDX2I (ORCPT ); Sun, 4 Dec 2005 23:28:08 +0000 Received: from fep32-0.kolumbus.fi ([IPv6:::ffff:193.229.0.63]:36303 "EHLO fep32-app.kolumbus.fi") by linux-mips.net with ESMTP id ; Sun, 4 Dec 2005 19:25:55 +0100 Received: from [192.168.0.102] (really [81.197.102.144]) by fep32-app.kolumbus.fi with ESMTP id <20051204182210.DYIF18068.fep32-app.kolumbus.fi@[192.168.0.102]> for ; Sun, 4 Dec 2005 20:22:10 +0200 Subject: SOT: Looking for Free Software developers willing to give a talk at the Fosdem embedded devroom From: Philippe De Swert To: linux-mips@linux-mips.org Content-Type: text/plain Date: Sun, 04 Dec 2005 20:21:56 +0200 Message-Id: <1133720516.6478.39.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.0.4 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: 9585 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: Philippedeswert@scarlet.be Precedence: bulk X-list: linux-mips Hello all, I hope you will all forgive me for posting this slightly off-topic request. In february it will be time for another embedded track at Fosdem (www.fosdem.org) and to fill this we are looking for people willing to present their embedded projects or talk about their experiences. Before you all flame me (preferably off-list) know that Fosdem is non-profit and organized for and by the community. See it as a chance to present the work done by the embedded (and MIPS in this case) community. Thanks, Philippe PS: Call for papers with more info for the ones that are interested. CALL FOR PAPERS for the 4th EMBEDDED track at FOSDEM 2005 ========================================================== sat 25 - sun 26 February 2006, Brussels Call for papers ---------------- The 2006 edition of FOSDEM (Free and Open Source Developers' European Meeting; http://www.fosdem.org) will take place in Brussels, Belgium on 25 and 26 February 2006. For the fourth time, a track on Embedded Systems and Operating Systems will be organized. The third edition was quite succesful and attracted up to 150 attendants for certain topics. For last years program see: http://www.embedded-kernel-track.org/2005/papers.html The use of Free Software in the infrastructure of Embedded Systems is booming, e.g. by the use of Linux, uClinux, eCos, RedBoot, RTEMS and many other Free Software components. More companies are supporting Embedded Free Software each day because of the reliability and cheap licensing. This can be confirmed from looking at some high profile releases of embedded GNU/Linux systems. Some examples are the Nokia 770, some models of Motorola's smartphones, Archos players and the move from palmsource to build on a Linux subsystem Operating System development has always been a very important topic in Free Software. As embedded and real-time systems typically have special OS requirements, we organise this Free Embedded and OS development track at FOSDEM to give people the opportunity to present their (or their teams) achievements. This track at FOSDEM provides a remarkable opportunity to present and discuss the ongoing work in these areas, and we invite developers to present their current projects. Technical topics of the conference include but are not limited to : * OS Development : kernel architecture and implementation, libraries (e.g. Linux, BSD, uClinux, uClibc, newlib, ...) * Practical experiences in implementing Free Software in embedded systems (e.g. reverse engineering, porting too (and adapting of) commercial devices like the Ipaq, linksys WRT54G, nlsu2 .... ) * Toolchain, performance testing and build environment (e.g. crosstool, emdebian, openembedded, PTX dist, packaging, scratchbox, Eclipse, Valgrind,...) * GUI's for embedded systems (Gtk, Qt-(embedded), GPE, Qtopia, UI design with touchscreen, ...) * Multimedia applications for embedded systems (e.g. integer only decoders, Opieplayer, gstreamer... ) * Real-time extensions, nanokernels and hardware virtualization software (e.g. RTAI, Adeos, KURT, L4, Qemu, User Mode Linux, ...) * Hard real-time OS's (eCos, RTEMS, ...) * Open hardware, DSP, softcores and general hardware management (e.g opencores.org, OpenRISC, leonSparc, FPGA's, specific design restrictions for free systems, DSP, Power management...) * Safety and security certifications applied to Free software (e.g. security measures in Embedded systems, SSL libraries, ...) * Free software licenses and embedded systems Authors that wish to present a topic are requested to submit their abstracts online to embedded@fosdem.org before 31/12/2005. Notification of receipt will be sent within 48 hours. Authors wishing to submit a full paper (between 6 and 12 A4 pages), can do so in PS or PDF format. The Program Committee will evaluate the abstracts and consists of: * Geert Uytterhoeven, Sony NSCE, Belgium * Peter De Schrijver (p2), Mind, Belgium * Philippe De Swert, Nokia (OSSO), Finland -- | Philippe De Swert | | GPE developer: http://gpe.handhelds.org | Emdebian developer: http://www.emdebian.org | | Please do not send me documents in a closed | format.(*.doc,*.xls,*.ppt) | Use the open alternatives. (*.pdf,*.ps,*.html,*.txt) | http://www.gnu.org/philosophy/no-word-attachments.html From maillist@jg555.com Mon Dec 5 05:16:12 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 05 Dec 2005 05:16:38 +0000 (GMT) Received: from Jg555.com ([64.30.195.78]:56792 "EHLO jg555.com") by ftp.linux-mips.org with ESMTP id S8133428AbVLEFQM (ORCPT ); Mon, 5 Dec 2005 05:16:12 +0000 Received: from [172.16.0.55] ([::ffff:172.16.0.55]) (AUTH: PLAIN root, TLS: TLSv1/SSLv3,256bits,AES256-SHA) by jg555.com with esmtp; Sun, 04 Dec 2005 21:15:44 -0800 id 00098008.4393CD00.00006FED Message-ID: <4393CCEE.2080107@jg555.com> Date: Sun, 04 Dec 2005 21:15:26 -0800 From: Jim Gifford User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=_server-28653-1133759744-0001-2" To: Linux MIPS List Subject: Patch for RaQ2 - cpu features.h 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: 9586 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 This is a MIME-formatted message. If you see this text it means that your E-mail software does not support MIME-formatted messages. --=_server-28653-1133759744-0001-2 Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: 7bit This replaces the cpu-probe.c hack we had before, which disabled ll_sc.. I followed the format of theother cpu-feature-overrides.h. -- ---- Jim Gifford maillist@jg555.com --=_server-28653-1133759744-0001-2 Content-Type: text/x-diff; name="cobalt_override.patch"; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="cobalt_override.patch" diff -Naur linux-2.6.14.orig/include/asm-mips/cobalt/cpu-feature-overrides.h linux-2.6.14/include/asm-mips/cobalt/cpu-feature-overrides.h --- linux-2.6.14.orig/include/asm-mips/cobalt/cpu-feature-overrides.h 1970-01-01 00:00:00.000000000 +0000 +++ linux-2.6.14/include/asm-mips/cobalt/cpu-feature-overrides.h 2005-11-29 23:02:33.000000000 +0000 @@ -0,0 +1,24 @@ +/* + * 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 Chris Dearman + * Copyright (C) 2005 Ralf Baechle (ralf@linux-mips.org) + */ +#ifndef __ASM_COBALT_MIPS_CPU_FEATURE_OVERRIDES_H +#define __ASM_COBALT_MIPS_CPU_FEATURE_OVERRIDES_H + +#include + +/* + * CPU feature overrides for Cobalt Servers + */ + +#ifdef CONFIG_64BIT +#define cpu_has_llsc 0 +#else +#define cpu_has_llsc 1 +#endif + +#endif /* __ASM_COBALT_MIPS_CPU_FEATURE_OVERRIDES_H */ --=_server-28653-1133759744-0001-2-- From maillist@jg555.com Mon Dec 5 05:19:09 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 05 Dec 2005 05:19:41 +0000 (GMT) Received: from Jg555.com ([64.30.195.78]:57560 "EHLO jg555.com") by ftp.linux-mips.org with ESMTP id S8133576AbVLEFTJ (ORCPT ); Mon, 5 Dec 2005 05:19:09 +0000 Received: from [172.16.0.55] ([::ffff:172.16.0.55]) (AUTH: PLAIN root, TLS: TLSv1/SSLv3,256bits,AES256-SHA) by jg555.com with esmtp; Sun, 04 Dec 2005 21:18:40 -0800 id 00098008.4393CDB1.00007037 Message-ID: <4393CD9F.3090305@jg555.com> Date: Sun, 04 Dec 2005 21:18:23 -0800 From: Jim Gifford User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=_server-28727-1133759921-0001-2" To: Linux MIPS List Subject: Tulip RaQ2 64 Bit Fix 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: 9587 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 This is a MIME-formatted message. If you see this text it means that your E-mail software does not support MIME-formatted messages. --=_server-28727-1133759921-0001-2 Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: 7bit The attached patch allows the tulip driver to work with the RaQ2's network adapter. Without the patch under a 64 bit build, it will never negotiate and will drop packets. This driver is part of Linux Parisc, by Grant Grundler. It's currently in -mm, but Jeff Garzick will not apply it to the main tree. When Grant modified this driver, he used the manufactures specs on the tulip chip. -- ---- Jim Gifford maillist@jg555.com --=_server-28727-1133759921-0001-2 Content-Type: text/x-diff; name="tulip.patch"; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="tulip.patch" diff -Naur linux-mips-2.6.14.orig/drivers/net/tulip/21142.c linux-mips-2.6.14/drivers/net/tulip/21142.c --- linux-mips-2.6.14.orig/drivers/net/tulip/21142.c 2005-11-17 11:43:12.000000000 -0800 +++ linux-mips-2.6.14/drivers/net/tulip/21142.c 2005-11-17 21:52:47.000000000 -0800 @@ -172,7 +172,7 @@ int i; for (i = 0; i < tp->mtable->leafcount; i++) if (tp->mtable->mleaf[i].media == dev->if_port) { - int startup = ! ((tp->chip_id == DC21143 && (tp->revision == 48 || tp->revision == 65))); + int startup = ! ((tp->chip_id == DC21143 && tp->revision == 65)); tp->cur_index = i; tulip_select_media(dev, startup); setup_done = 1; diff -Naur linux-mips-2.6.14.orig/drivers/net/tulip/media.c linux-mips-2.6.14/drivers/net/tulip/media.c --- linux-mips-2.6.14.orig/drivers/net/tulip/media.c 2005-11-17 11:43:13.000000000 -0800 +++ linux-mips-2.6.14/drivers/net/tulip/media.c 2005-11-17 21:52:47.000000000 -0800 @@ -44,8 +44,10 @@ /* MII transceiver control section. Read and write the MII registers using software-generated serial - MDIO protocol. See the MII specifications or DP83840A data sheet - for details. */ + MDIO protocol. + See IEEE 802.3-2002.pdf (Section 2, Chapter "22.2.4 Management functions") + or DP83840A data sheet for more details. + */ int tulip_mdio_read(struct net_device *dev, int phy_id, int location) { @@ -261,24 +263,56 @@ u16 *reset_sequence = &((u16*)(p+3))[init_length]; int reset_length = p[2 + init_length*2]; misc_info = reset_sequence + reset_length; - if (startup) + if (startup) { + int timeout = 10; /* max 1 ms */ for (i = 0; i < reset_length; i++) iowrite32(get_u16(&reset_sequence[i]) << 16, ioaddr + CSR15); + + /* flush posted writes */ + ioread32(ioaddr + CSR15); + + /* Sect 3.10.3 in DP83840A.pdf (p39) */ + udelay(500); + + /* Section 4.2 in DP83840A.pdf (p43) */ + /* and IEEE 802.3 "22.2.4.1.1 Reset" */ + while (timeout-- && + (tulip_mdio_read (dev, phy_num, MII_BMCR) & BMCR_RESET)) + udelay(100); + } for (i = 0; i < init_length; i++) iowrite32(get_u16(&init_sequence[i]) << 16, ioaddr + CSR15); + + ioread32(ioaddr + CSR15); /* flush posted writes */ } else { u8 *init_sequence = p + 2; u8 *reset_sequence = p + 3 + init_length; int reset_length = p[2 + init_length]; misc_info = (u16*)(reset_sequence + reset_length); if (startup) { + int timeout = 10; /* max 1 ms */ iowrite32(mtable->csr12dir | 0x100, ioaddr + CSR12); for (i = 0; i < reset_length; i++) iowrite32(reset_sequence[i], ioaddr + CSR12); + + /* flush posted writes */ + ioread32(ioaddr + CSR12); + + /* Sect 3.10.3 in DP83840A.pdf (p39) */ + udelay(500); + + /* Section 4.2 in DP83840A.pdf (p43) */ + /* and IEEE 802.3 "22.2.4.1.1 Reset" */ + while (timeout-- && + (tulip_mdio_read (dev, phy_num, MII_BMCR) & BMCR_RESET)) + udelay(100); } for (i = 0; i < init_length; i++) iowrite32(init_sequence[i], ioaddr + CSR12); + + ioread32(ioaddr + CSR12); /* flush posted writes */ } + tmp_info = get_u16(&misc_info[1]); if (tmp_info) tp->advertising[phy_num] = tmp_info | 1; diff -Naur linux-mips-2.6.14.orig/drivers/net/tulip/tulip_core.c linux-mips-2.6.14/drivers/net/tulip/tulip_core.c --- linux-mips-2.6.14.orig/drivers/net/tulip/tulip_core.c 2005-11-17 11:43:13.000000000 -0800 +++ linux-mips-2.6.14/drivers/net/tulip/tulip_core.c 2005-11-17 21:52:47.000000000 -0800 @@ -22,7 +22,7 @@ #else #define DRV_VERSION "1.1.13" #endif -#define DRV_RELDATE "May 11, 2002" +#define DRV_RELDATE "December 15, 2004" #include @@ -148,7 +148,7 @@ HAS_MII | HAS_MEDIA_TABLE | CSR12_IN_SROM | HAS_PCI_MWI, tulip_timer }, /* DC21142, DC21143 */ - { "Digital DS21143 Tulip", 128, 0x0801fbff, + { "Digital DS21142/DS21143 Tulip", 128, 0x0801fbff, HAS_MII | HAS_MEDIA_TABLE | ALWAYS_CHECK_MII | HAS_ACPI | HAS_NWAY | HAS_INTR_MITIGATION | HAS_PCI_MWI, t21142_timer }, diff -Naur linux-mips-2.6.14.orig/drivers/net/tulip/tulip.h linux-mips-2.6.14/drivers/net/tulip/tulip.h --- linux-mips-2.6.14.orig/drivers/net/tulip/tulip.h 2005-11-17 11:43:13.000000000 -0800 +++ linux-mips-2.6.14/drivers/net/tulip/tulip.h 2005-11-17 21:52:47.000000000 -0800 @@ -474,8 +474,11 @@ udelay(10); if (!i) - printk(KERN_DEBUG "%s: tulip_stop_rxtx() failed\n", - pci_name(tp->pdev)); + printk(KERN_DEBUG "%s: tulip_stop_rxtx() failed" + " (CSR5 0x%x CSR6 0x%x)\n", + pci_name(tp->pdev), + ioread32(ioaddr + CSR5), + ioread32(ioaddr + CSR6)); } } --=_server-28727-1133759921-0001-2-- From maillist@jg555.com Mon Dec 5 05:21:45 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 05 Dec 2005 05:22:23 +0000 (GMT) Received: from Jg555.com ([64.30.195.78]:58328 "EHLO jg555.com") by ftp.linux-mips.org with ESMTP id S8133528AbVLEFVp (ORCPT ); Mon, 5 Dec 2005 05:21:45 +0000 Received: from [172.16.0.55] ([::ffff:172.16.0.55]) (AUTH: PLAIN root, TLS: TLSv1/SSLv3,256bits,AES256-SHA) by jg555.com with esmtp; Sun, 04 Dec 2005 21:21:17 -0800 id 00098009.4393CE4D.0000708B Message-ID: <4393CE3B.20303@jg555.com> Date: Sun, 04 Dec 2005 21:20:59 -0800 From: Jim Gifford User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=_server-28811-1133760077-0001-2" To: Linux MIPS List Subject: Cobalt IDE Patch 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: 9588 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 This is a MIME-formatted message. If you see this text it means that your E-mail software does not support MIME-formatted messages. --=_server-28811-1133760077-0001-2 Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: 7bit This is Peter Horton's IDE patch for the Cobalt. From the notes in Peter's file. PIO "in" transfers can cause D-cache lines to be allocated to the data being read. If the target is the page cache then the kernel can create a user space mapping of the same page without flushing it from the D-cache. This has large potential to create cache aliases. The Cobalts seem to trigger this problem easily. -- ---- Jim Gifford maillist@jg555.com --=_server-28811-1133760077-0001-2 Content-Type: text/x-diff; name="cobalt_ide.patch"; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="cobalt_ide.patch" diff -Naur linux-mips-2.6.14.orig/include/asm-mips/cobalt/ide.h linux-mips-2.6.14/include/asm-mips/cobalt/ide.h --- linux-mips-2.6.14.orig/include/asm-mips/cobalt/ide.h 1969-12-31 16:00:00.000000000 -0800 +++ linux-mips-2.6.14/include/asm-mips/cobalt/ide.h 2005-11-17 14:58:19.000000000 -0800 @@ -0,0 +1,83 @@ + +/* + * PIO "in" transfers can cause D-cache lines to be allocated + * to the data being read. If the target is the page cache then + * the kernel can create a user space mapping of the same page + * without flushing it from the D-cache. This has large potential + * to create cache aliases. The Cobalts seem to trigger this + * problem easily. + * + * MIPs doesn't have a flush_dcache_range() so we roll + * our own. + * + * -- pdh + */ + +#define MAX_HWIFS 2 + +#include + +static inline void __flush_dcache(void) +{ + unsigned long dc_size, dc_line, addr, end; + + dc_size = current_cpu_data.dcache.ways << current_cpu_data.dcache.waybit; + dc_line = current_cpu_data.dcache.linesz; + + addr = CKSEG0; + end = addr + dc_size; + + for (; addr < end; addr += dc_line) + flush_dcache_line_indexed(addr); +} + +static inline void __flush_dcache_range(unsigned long start, unsigned long end) +{ + unsigned long dc_size, dc_line, addr; + + dc_size = current_cpu_data.dcache.ways << current_cpu_data.dcache.waybit; + dc_line = current_cpu_data.dcache.linesz; + + addr = start & ~(dc_line - 1); + end += dc_line - 1; + + if (end - addr < dc_size) + for (; addr < end; addr += dc_line) + flush_dcache_line(addr); + else + __flush_dcache(); +} + +static inline void __ide_insw(unsigned long port, void *addr, unsigned int count) +{ + insw(port, addr, count); + + __flush_dcache_range((unsigned long) addr, (unsigned long) addr + count * 2); +} + +static inline void __ide_insl(unsigned long port, void *addr, unsigned int count) +{ + insl(port, addr, count); + + __flush_dcache_range((unsigned long) addr, (unsigned long) addr + count * 4); +} + +static inline void __ide_mm_insw(volatile void __iomem *port, void *addr, unsigned int count) +{ + readsw(port, addr, count); + + __flush_dcache_range((unsigned long) addr, (unsigned long) addr + count * 2); +} + +static inline void __ide_mm_insl(volatile void __iomem *port, void *addr, unsigned int count) +{ + readsl(port, addr, count); + + __flush_dcache_range((unsigned long) addr, (unsigned long) addr + count * 4); +} + +#define insw __ide_insw +#define insl __ide_insl + +#define __ide_mm_outsw writesw +#define __ide_mm_outsl writesl --=_server-28811-1133760077-0001-2-- From anemo@mba.ocn.ne.jp Mon Dec 5 05:42:41 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 05 Dec 2005 05:43:08 +0000 (GMT) Received: from topsns.toshiba-tops.co.jp ([202.230.225.5]:6950 "HELO topsns.toshiba-tops.co.jp") by ftp.linux-mips.org with SMTP id S8133441AbVLEFml (ORCPT ); Mon, 5 Dec 2005 05:42:41 +0000 Received: from inside-ms1.toshiba-tops.co.jp by topsns.toshiba-tops.co.jp via smtpd (for mail.linux-mips.org [62.254.210.162]) with SMTP; 5 Dec 2005 05:43:23 UT Received: from topsms.toshiba-tops.co.jp (localhost.localdomain [127.0.0.1]) by localhost.toshiba-tops.co.jp (Postfix) with ESMTP id D80851F70C; Mon, 5 Dec 2005 14:43:19 +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 C36BA1F1AB; Mon, 5 Dec 2005 14:43:19 +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 jB55hJ4D035220; Mon, 5 Dec 2005 14:43:19 +0900 (JST) (envelope-from anemo@mba.ocn.ne.jp) Date: Mon, 05 Dec 2005 14:43:19 +0900 (JST) Message-Id: <20051205.144319.126575575.nemoto@toshiba-tops.co.jp> To: maillist@jg555.com Cc: linux-mips@linux-mips.org Subject: Re: Cobalt IDE Patch From: Atsushi Nemoto In-Reply-To: <4393CE3B.20303@jg555.com> References: <4393CE3B.20303@jg555.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.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: 9589 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, 04 Dec 2005 21:20:59 -0800, Jim Gifford said: jim> This is Peter Horton's IDE patch for the Cobalt. From the notes jim> in Peter's file. I suppose this patch is not required anymore since current asm-mips/mach-generic/ide.h takes care of dcache aliases. If Cobalt's IDE did not work with with the generic ide.h, it should be fixed instead of adding one more ide.h. --- Atsushi Nemoto From david.sanchez@lexbox.fr Mon Dec 5 08:22:59 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 05 Dec 2005 08:23:19 +0000 (GMT) Received: from laf31-5-82-235-130-100.fbx.proxad.net ([82.235.130.100]:47077 "EHLO lexbox.fr") by ftp.linux-mips.org with ESMTP id S8133575AbVLEIW7 convert rfc822-to-8bit (ORCPT ); Mon, 5 Dec 2005 08:22:59 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 8BIT Subject: Au1550 system bus masters issue X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Date: Mon, 5 Dec 2005 09:18:50 +0100 Message-ID: <17AB476A04B7C842887E0EB1F268111E0271B7@xpserver.intra.lexbox.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Au1550 system bus masters issue thread-index: AcX5dIW+i6XFajUZSkKtR8AR8cRveQ== From: "David Sanchez" 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: 9590 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.sanchez@lexbox.fr Precedence: bulk X-list: linux-mips Hi, I notice the following issue in the specification update (v31420) of the au1550: "System bus masters (USB host, PCI, MAC0, MAC1, DDMA) may receive stale data. Description ----------- System bus masters (USB host controller, PCI controller, MAC0, MAC1, DDMA controller), when performing coherent reads, may incorrectly receive stale data from memory instead of valid modified data from the Au1 data cache. If the request for data arrives within a 3-clock window prior to the cache line castout to memory, the cache snoop response is incorrect and stale data is retrieved from memory instead of the correct data from the cache. The cache line castout then completes, and memory is updated. Cache/memory data is not corrupted, but the specific bus read in not valid. Affected Step ------------- AA Workaround ---------- Do not enable cacheable master reads if the core modifies data in cache. Status ------ Not Fixed" Does somebody known if the linux kernel 2.6.10 integrates this workaround ? Thanks From matej.kupljen@ultra.si Mon Dec 5 08:50:45 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 05 Dec 2005 08:51:08 +0000 (GMT) Received: from deliver-1.mx.triera.net ([213.161.0.31]:65480 "HELO deliver-1.mx.triera.net") by ftp.linux-mips.org with SMTP id S8133600AbVLEIup (ORCPT ); Mon, 5 Dec 2005 08:50:45 +0000 Received: from localhost (in-2.mx.triera.net [213.161.0.26]) by deliver-1.mx.triera.net (Postfix) with ESMTP id 6267DC018; Mon, 5 Dec 2005 09:50:14 +0100 (CET) Received: from smtp.triera.net (smtp.triera.net [213.161.0.30]) by in-2.mx.triera.net (Postfix) with SMTP id 2FFF81BC08A; Mon, 5 Dec 2005 09:50:16 +0100 (CET) Received: from [172.18.1.53] (unknown [213.161.20.162]) by smtp.triera.net (Postfix) with ESMTP id 319021A18A7; Mon, 5 Dec 2005 09:50:16 +0100 (CET) Subject: Re: [PATCH] ALCHEMY: Alchemy Camera Interface (CIM) driver From: Matej Kupljen To: Jordan Crouse Cc: linux-mips@linux-mips.org, ralf@linux-mips.org In-Reply-To: <20051202190635.GI28227@cosmic.amd.com> References: <20051202190635.GI28227@cosmic.amd.com> Content-Type: text/plain Date: Mon, 05 Dec 2005 09:49:27 +0100 Message-Id: <1133772567.2377.11.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.2.3 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: 9591 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 > A driver for the AU1200 Camera Interface (CIM). Great news! > I'm sending up right now, so comments and flames are definately > welcome. Wouldn't it be wise to support V4L2? This way, many existing application could use AU1200s camera interface. > +int __init > +au1xxxcim_init(void) > +{ > + int retval, error; > + unsigned long page; > + CAMERA_RUNTIME *cam_init; > + CAMERA *cim_ptr; > + > + cam_init = &cam_base; > + cam_init->cmos_camera = OrigCimArryPtr + prev_mode; > + cim_ptr = cam_init->cmos_camera; > + > + /*Allocating memory for MMAP */ > + mem_buf = (unsigned long *)Camera_mem_alloc(2 * MAX_FRAME_SIZE); > + if (mem_buf == NULL) { > + printk(KERN_ERR "MMAP unable to allocate memory \n"); > + } IMHO this is a waste of memory, because if the user is going to use the camera in 320x240 mode and this allocates memory for the biggest size. Wouldn't it be better to set some default configuration and allocate memory for this? Later if the user changes the mode those pages are freed and new (for requested size) are allocated. Or even allocate memory AFTER the configuration has been set? BR, Matej From komal_shah802003@yahoo.com Mon Dec 5 09:29:26 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 05 Dec 2005 09:29:52 +0000 (GMT) Received: from web32906.mail.mud.yahoo.com ([68.142.206.53]:50832 "HELO web32906.mail.mud.yahoo.com") by ftp.linux-mips.org with SMTP id S8133600AbVLEJ30 (ORCPT ); Mon, 5 Dec 2005 09:29:26 +0000 Received: (qmail 36426 invoked by uid 60001); 5 Dec 2005 09:28:55 -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=5cP+BWazWuSF6ZB4Xd/h+KgcADANXMgaS9uy2VOd0eWmzLULr1JLW8eYD8DGJkGQHOGVpCcTbQmYzgQiWcmyEeVSGY1WtQWGaZPUkOr+BirsNiCJ2v/IhL/RZqzSm5s8pH6+DzY1CCZ8uqJvSe+P/fpbMqomUEIs/NbgkSpM7Co= ; Message-ID: <20051205092855.36424.qmail@web32906.mail.mud.yahoo.com> Received: from [203.145.155.11] by web32906.mail.mud.yahoo.com via HTTP; Mon, 05 Dec 2005 01:28:55 PST Date: Mon, 5 Dec 2005 01:28:55 -0800 (PST) From: Komal Shah Subject: Re: [PATCH] ALCHEMY: Alchemy Camera Interface (CIM) driver To: Jordan Crouse , linux-mips@linux-mips.org Cc: ralf@linux-mips.org In-Reply-To: <20051202190635.GI28227@cosmic.amd.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: 9592 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: komal_shah802003@yahoo.com Precedence: bulk X-list: linux-mips --- Jordan Crouse wrote: and values > */ > +} CAMERA; > + > + > + > +static CAMERA au1xxx_cameras[] = { > + /* Omnivision OV9640 Camera 1280x960 Mode (SXGA) in "Pass Thru > Mode" > + 1.3 MP at 15 Fps > + */ There is already nice way to separate sensor interface from the camera core and ov9640 camera sensor driver is available at OMAP tree. Could you please look at that and see if that can be re-used? http://source.mvista.com/git/gitweb.cgi?p=linux-omap-2.6.git;a=blob;h=c7691d19356f9c5d8cb724a924e8bdebaed7fc65;hb=279a7045accc927dbb2b1d41691424c4d345489c;f=drivers/media/video/omap/sensor_ov9640.c ---Komal Shah http://komalshah.blogspot.com/ __________________________________________ Yahoo! DSL – Something to write home about. Just $16.99/mo. or less. dsl.yahoo.com From sshtylyov@ru.mvista.com Mon Dec 5 11:34:18 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 05 Dec 2005 11:35:13 +0000 (GMT) Received: from rtsoft2.corbina.net ([85.21.88.2]:25239 "HELO mail.dev.rtsoft.ru") by ftp.linux-mips.org with SMTP id S8133648AbVLELeS (ORCPT ); Mon, 5 Dec 2005 11:34:18 +0000 Received: (qmail 16327 invoked from network); 5 Dec 2005 11:33:45 -0000 Received: from wasted.dev.rtsoft.ru (HELO ?192.168.1.248?) (192.168.1.248) by mail.dev.rtsoft.ru with SMTP; 5 Dec 2005 11:33:45 -0000 Message-ID: <43942625.2070609@ru.mvista.com> Date: Mon, 05 Dec 2005 14:36:05 +0300 From: Sergei Shtylylov Organization: MostaVista 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: David Sanchez , Linux MIPS Development Subject: Re: Au1550 system bus masters issue References: <17AB476A04B7C842887E0EB1F268111E0271B7@xpserver.intra.lexbox.org> In-Reply-To: <17AB476A04B7C842887E0EB1F268111E0271B7@xpserver.intra.lexbox.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: 9593 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. David Sanchez wrote: > I notice the following issue in the specification update (v31420) of the > au1550: > > "System bus masters (USB host, PCI, MAC0, MAC1, DDMA) may receive stale > data. > > Description > ----------- > System bus masters (USB host controller, PCI controller, MAC0, MAC1, > DDMA controller), when performing > coherent reads, may incorrectly receive stale data from memory instead > of valid modified data from the Au1 > data cache. If the request for data arrives within a 3-clock window > prior to the cache line castout to memory, > the cache snoop response is incorrect and stale data is retrieved from > memory instead of the correct data from > the cache. The cache line castout then completes, and memory is updated. > Cache/memory data is not corrupted, but the specific bus read in not > valid. > > Affected Step > ------------- > AA > > Workaround > ---------- > Do not enable cacheable master reads if the core modifies data in cache. > > Status > ------ > Not Fixed" > > Does somebody known if the linux kernel 2.6.10 integrates this > workaround ? Mainly as CONFIG_DMA_NONCOHERENT defined. USB OHCI and PCI still have coherency enabled but as the cache hits prone to errata shouldn't happen due to the CONFIG_DMA_NONCOHERENT, it's probably not a problem (enabling coherency in Ethernet driver however makes the kernel non-bootable. USB host controller (and probably not only it, I'm too lazy to re-check ;-) is still prone to other errata on stepping AB though, see this thread: http://www.linux-mips.org/archives/linux-mips/2005-11/msg00137.html I'm gonna rework the patch and resubmit. > Thanks WBR, Sergei From komal_shah802003@yahoo.com Mon Dec 5 11:43:05 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 05 Dec 2005 11:43:45 +0000 (GMT) Received: from web32903.mail.mud.yahoo.com ([68.142.206.50]:35961 "HELO web32903.mail.mud.yahoo.com") by ftp.linux-mips.org with SMTP id S8133657AbVLELnE (ORCPT ); Mon, 5 Dec 2005 11:43:04 +0000 Received: (qmail 54234 invoked by uid 60001); 5 Dec 2005 11:42:33 -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=QO75+iR0ZcxS06nZe4vpa1UG2a8ncaQpDUUMJ9rpRb8Y5eUEm2jDmk8++/ifabJcxDC226lzNW6Ual/b+m3mH1AzFuk2xju9fsHnh0D4pCkSWD10nLxONGRD002TLpM2ZgAacQ0rp0fDqLpTbS5qkuvMWHFOCrA1Ehg1uaEempY= ; Message-ID: <20051205114233.54232.qmail@web32903.mail.mud.yahoo.com> Received: from [203.145.155.11] by web32903.mail.mud.yahoo.com via HTTP; Mon, 05 Dec 2005 03:42:33 PST Date: Mon, 5 Dec 2005 03:42:33 -0800 (PST) From: Komal Shah Subject: Re: [PATCH] ALCHEMY: SPI driver for Au1200 To: Jordan Crouse , linux-mips@linux-mips.org Cc: ralf@linux-mips.org In-Reply-To: <20051202190223.GG28227@cosmic.amd.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: 9594 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: komal_shah802003@yahoo.com Precedence: bulk X-list: linux-mips --- Jordan Crouse wrote: > A SPI driver for the Au1200 processor. Sending now so it > can be queued for the post 2.6.15 rush. Good. As there is long discussion going on which SPI framework to accept in mainline, I would suggest you to implement the same master controller and protocol driver using either David Brownell's framework (right now in 2.6.15-rc3-mm1) or Dmitry/Wool framework. ---Komal Shah http://komalshah.blogspot.com/ __________________________________ Start your day with Yahoo! - Make it your home page! http://www.yahoo.com/r/hs From ralf@linux-mips.org Mon Dec 5 11:46:03 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 05 Dec 2005 11:46:43 +0000 (GMT) Received: from extgw-uk.mips.com ([62.254.210.129]:54809 "EHLO bacchus.net.dhis.org") by ftp.linux-mips.org with ESMTP id S8133713AbVLELqC (ORCPT ); Mon, 5 Dec 2005 11:46:02 +0000 Received: from dea.linux-mips.net (localhost.localdomain [127.0.0.1]) by bacchus.net.dhis.org (8.13.4/8.13.1) with ESMTP id jB5Bix8S007381; Mon, 5 Dec 2005 11:44:59 GMT Received: (from ralf@localhost) by dea.linux-mips.net (8.13.4/8.13.4/Submit) id jB5BivKY007380; Mon, 5 Dec 2005 11:44:57 GMT Date: Mon, 5 Dec 2005 11:44:56 +0000 From: Ralf Baechle To: Jim Gifford Cc: Linux MIPS List Subject: Re: Tulip RaQ2 64 Bit Fix Message-ID: <20051205114456.GA2728@linux-mips.org> References: <4393CD9F.3090305@jg555.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4393CD9F.3090305@jg555.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: 9595 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 Sun, Dec 04, 2005 at 09:18:23PM -0800, Jim Gifford wrote: > The attached patch allows the tulip driver to work with the RaQ2's > network adapter. Without the patch under a 64 bit build, it will never > negotiate and will drop packets. This driver is part of Linux Parisc, by > Grant Grundler. It's currently in -mm, but Jeff Garzick will not apply > it to the main tree. Why? Ralf From sshtylyov@ru.mvista.com Mon Dec 5 11:49:46 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 05 Dec 2005 11:50:28 +0000 (GMT) Received: from rtsoft2.corbina.net ([85.21.88.2]:55197 "HELO mail.dev.rtsoft.ru") by ftp.linux-mips.org with SMTP id S8133653AbVLELtq (ORCPT ); Mon, 5 Dec 2005 11:49:46 +0000 Received: (qmail 16586 invoked from network); 5 Dec 2005 11:49:16 -0000 Received: from wasted.dev.rtsoft.ru (HELO ?192.168.1.248?) (192.168.1.248) by mail.dev.rtsoft.ru with SMTP; 5 Dec 2005 11:49:16 -0000 Message-ID: <439429C8.1000402@ru.mvista.com> Date: Mon, 05 Dec 2005 14:51:36 +0300 From: Sergei Shtylylov Organization: MostaVista 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: David Sanchez , Linux MIPS Development Subject: Re: Au1550 system bus masters issue References: <17AB476A04B7C842887E0EB1F268111E0271B7@xpserver.intra.lexbox.org> <43942625.2070609@ru.mvista.com> In-Reply-To: <43942625.2070609@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: 9596 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. Sergei Shtylylov wrote: > coherency in Ethernet driver however makes the kernel non-bootable. USB > host controller (and probably not only it, I'm too lazy to re-check ;-) > is still prone to other errata on stepping AB though, see this thread: > > http://www.linux-mips.org/archives/linux-mips/2005-11/msg00137.html > > I'm gonna rework the patch and resubmit. Oops, I was talking of Au1500 step AB, Au1550 doesn't have CONFIG.OD bit errata... WBR, Sergei From ralf@linux-mips.org Mon Dec 5 12:02:30 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 05 Dec 2005 12:03:22 +0000 (GMT) Received: from extgw-uk.mips.com ([62.254.210.129]:53519 "EHLO bacchus.net.dhis.org") by ftp.linux-mips.org with ESMTP id S8133713AbVLEMCa (ORCPT ); Mon, 5 Dec 2005 12:02:30 +0000 Received: from dea.linux-mips.net (localhost.localdomain [127.0.0.1]) by bacchus.net.dhis.org (8.13.4/8.13.1) with ESMTP id jB5C1RT2008013; Mon, 5 Dec 2005 12:01:27 GMT Received: (from ralf@localhost) by dea.linux-mips.net (8.13.4/8.13.4/Submit) id jB5C1PXd008012; Mon, 5 Dec 2005 12:01:25 GMT Date: Mon, 5 Dec 2005 12:01:25 +0000 From: Ralf Baechle To: Atsushi Nemoto Cc: maillist@jg555.com, linux-mips@linux-mips.org Subject: Re: Cobalt IDE Patch Message-ID: <20051205120125.GB2728@linux-mips.org> References: <4393CE3B.20303@jg555.com> <20051205.144319.126575575.nemoto@toshiba-tops.co.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20051205.144319.126575575.nemoto@toshiba-tops.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: 9597 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, Dec 05, 2005 at 02:43:19PM +0900, Atsushi Nemoto wrote: > jim> This is Peter Horton's IDE patch for the Cobalt. From the notes > jim> in Peter's file. > > I suppose this patch is not required anymore since current > asm-mips/mach-generic/ide.h takes care of dcache aliases. > > If Cobalt's IDE did not work with with the generic ide.h, it should be > fixed instead of adding one more ide.h. Amen. Ralf From anemo@mba.ocn.ne.jp Mon Dec 5 12:21:59 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 05 Dec 2005 12:22:35 +0000 (GMT) Received: from topsns.toshiba-tops.co.jp ([202.230.225.5]:6691 "HELO topsns.toshiba-tops.co.jp") by ftp.linux-mips.org with SMTP id S8133644AbVLEMV7 (ORCPT ); Mon, 5 Dec 2005 12:21:59 +0000 Received: from inside-ms1.toshiba-tops.co.jp by topsns.toshiba-tops.co.jp via smtpd (for mail.linux-mips.org [62.254.210.162]) with SMTP; 5 Dec 2005 12:22:43 UT Received: from topsms.toshiba-tops.co.jp (localhost.localdomain [127.0.0.1]) by localhost.toshiba-tops.co.jp (Postfix) with ESMTP id 7F5041FE9C; Mon, 5 Dec 2005 21:22:40 +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 693D91FE45; Mon, 5 Dec 2005 21:22:40 +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 jB5CMd4D036843; Mon, 5 Dec 2005 21:22:39 +0900 (JST) (envelope-from anemo@mba.ocn.ne.jp) Date: Mon, 05 Dec 2005 21:22:39 +0900 (JST) Message-Id: <20051205.212239.85414794.nemoto@toshiba-tops.co.jp> To: maillist@jg555.com Cc: linux-mips@linux-mips.org, ralf@linux-mips.org Subject: Re: Cobalt IDE Patch From: Atsushi Nemoto In-Reply-To: <20051205.144319.126575575.nemoto@toshiba-tops.co.jp> References: <4393CE3B.20303@jg555.com> <20051205.144319.126575575.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.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: 9598 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 Mon, 05 Dec 2005 14:43:19 +0900 (JST), Atsushi Nemoto said: anemo> If Cobalt's IDE did not work with with the generic ide.h, it anemo> should be fixed instead of adding one more ide.h. If you are trying with 64bit kernel, please note that it might fail to probe IDE device while mdelay(1) returns too early. Please refer a patch I posted few days ago. (30 Nov) Ralf, could you consider applying my delay.h fix? --- Atsushi Nemoto From ralf@linux-mips.org Mon Dec 5 14:35:59 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 05 Dec 2005 14:36:22 +0000 (GMT) Received: from extgw-uk.mips.com ([62.254.210.129]:41486 "EHLO bacchus.net.dhis.org") by ftp.linux-mips.org with ESMTP id S8133647AbVLEOf7 (ORCPT ); Mon, 5 Dec 2005 14:35:59 +0000 Received: from dea.linux-mips.net (localhost.localdomain [127.0.0.1]) by bacchus.net.dhis.org (8.13.4/8.13.1) with ESMTP id jB5EZUhx014125; Mon, 5 Dec 2005 14:35:30 GMT Received: (from ralf@localhost) by dea.linux-mips.net (8.13.4/8.13.4/Submit) id jB5EZUUL014124; Mon, 5 Dec 2005 14:35:30 GMT Date: Mon, 5 Dec 2005 14:35:30 +0000 From: Ralf Baechle To: Atsushi Nemoto Cc: linux-mips@linux-mips.org Subject: Re: [PATCH] fix mdelay(1) for 64bit kernel with HZ == 1000 Message-ID: <20051205143530.GD2728@linux-mips.org> References: <20051130.133326.126937941.nemoto@toshiba-tops.co.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20051130.133326.126937941.nemoto@toshiba-tops.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: 9599 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, Nov 30, 2005 at 01:33:26PM +0900, Atsushi Nemoto wrote: > mdelay(1) (i.e. udelay(1000)) does not work correctly due to overflow. > > 1000 * 0x004189374BC6A7f0 = 0x10000000000000180 (>= 2**64) > > 0x004189374BC6A7ef (0x004189374BC6A7f0 - 1) is OK and it is exactly > same as catchall case (0x8000000000000000UL / (500000 / HZ)). > > Signed-off-by: Atsushi Nemoto Applied. From jcrouse@cosmic.amd.com Mon Dec 5 14:58:30 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 05 Dec 2005 14:58:57 +0000 (GMT) Received: from amdext3.amd.com ([139.95.251.6]:44777 "EHLO amdext3.amd.com") by ftp.linux-mips.org with ESMTP id S8133644AbVLEO63 (ORCPT ); Mon, 5 Dec 2005 14:58:29 +0000 Received: from SSVLGW01.amd.com (ssvlgw01.amd.com [139.95.250.169]) by amdext3.amd.com (8.12.11/8.12.11/AMD) with ESMTP id jB5Evx2s015007; Mon, 5 Dec 2005 06:58:00 -0800 Received: from 139.95.250.1 by SSVLGW01.amd.com with ESMTP (AMD SMTP Relay (Email Firewall v6.1.0)); Mon, 05 Dec 2005 06:57:49 -0800 X-Server-Uuid: 89466532-923C-4A88-82C1-66ACAA0041DF Received: from ldcmail.amd.com (ldcmail.amd.com [147.5.200.40]) by amdint.amd.com (8.12.8/8.12.8/AMD) with ESMTP id jB5EvlQe005905; Mon, 5 Dec 2005 06:57:47 -0800 (PST) Received: from cosmic.amd.com (cosmic.amd.com [147.5.201.206]) by ldcmail.amd.com (Postfix) with ESMTP id E683B2026; Mon, 5 Dec 2005 07:57:46 -0700 (MST) Received: from cosmic.amd.com (localhost [127.0.0.1]) by cosmic.amd.com (8.13.4/8.13.4) with ESMTP id jB5F6IHi014896; Mon, 5 Dec 2005 08:06:18 -0700 Received: (from jcrouse@localhost) by cosmic.amd.com ( 8.13.4/8.13.4/Submit) id jB5F6Iu0014895; Mon, 5 Dec 2005 08:06:18 -0700 Date: Mon, 5 Dec 2005 08:06:18 -0700 From: "Jordan Crouse" To: "Matej Kupljen" cc: linux-mips@linux-mips.org, ralf@linux-mips.org Subject: Re: ALCHEMY: Alchemy Camera Interface (CIM) driver Message-ID: <20051205150617.GQ28227@cosmic.amd.com> References: <20051202190635.GI28227@cosmic.amd.com> <1133772567.2377.11.camel@localhost.localdomain> MIME-Version: 1.0 In-Reply-To: <1133772567.2377.11.camel@localhost.localdomain> User-Agent: Mutt/1.5.11 X-WSS-ID: 6F8A8AE71K82502146-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: 9600 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 05/12/05 09:49 +0100, Matej Kupljen wrote: > Wouldn't it be wise to support V4L2? > This way, many existing application could use AU1200s camera interface. Thats possible, but for now this solution has been reasonable enough for us to send it upstream. I'm sure that somebody more familiar with V4L2 could make short work of adapting it to the existing infrastructure. > > +int __init > > +au1xxxcim_init(void) > > +{ > > + int retval, error; > > + unsigned long page; > > + CAMERA_RUNTIME *cam_init; > > + CAMERA *cim_ptr; > > + > > + cam_init = &cam_base; > > + cam_init->cmos_camera = OrigCimArryPtr + prev_mode; > > + cim_ptr = cam_init->cmos_camera; > > + > > + /*Allocating memory for MMAP */ > > + mem_buf = (unsigned long *)Camera_mem_alloc(2 * MAX_FRAME_SIZE); > > + if (mem_buf == NULL) { > > + printk(KERN_ERR "MMAP unable to allocate memory \n"); > > + } > > IMHO this is a waste of memory, because if the user is going to use > the camera in 320x240 mode and this allocates memory for the biggest > size. Wouldn't it be better to set some default configuration and > allocate memory for this? Later if the user changes the mode those > pages are freed and new (for requested size) are allocated. > Or even allocate memory AFTER the configuration has been set? I agree, that could be handled better. Thanks, Jordan -- Jordan Crouse Senior Linux Engineer AMD - Personal Connectivity Solutions Group From leonardosilv@yahoo.com.br Mon Dec 5 15:06:05 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 05 Dec 2005 15:06:37 +0000 (GMT) Received: from smtp200.mail.sc5.yahoo.com ([216.136.130.125]:40371 "HELO smtp200.mail.sc5.yahoo.com") by ftp.linux-mips.org with SMTP id S8133653AbVLEPGF (ORCPT ); Mon, 5 Dec 2005 15:06:05 +0000 Received: (qmail 24445 invoked from network); 5 Dec 2005 15:05:18 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com.br; h=Received:Message-ID:Date:From:User-Agent:X-Accept-Language:MIME-Version:To:Subject:X-Enigmail-Version:OpenPGP:Content-Type; b=LnKRmMsqGMVVKZWUJ/9rHww9p/AF3dKMrHNypgY2pu3Vu/iVUcpRXt1TqfpGOx43kD9zWPrQOZDx6MMRYZLB1aANh6QrGfNXogG8vk8oXftmzgWBMtBRk5vamtY16311Uf3quyzU/iBFRZF1esBQx8cMLogedO5FA79BBksVf2I= ; Received: from unknown (HELO ?192.168.0.3?) (leonardosilv@200.139.137.68 with plain) by smtp200.mail.sc5.yahoo.com with SMTP; 5 Dec 2005 15:05:10 -0000 Message-ID: <4394570E.7040702@yahoo.com.br> Date: Mon, 05 Dec 2005 13:04:46 -0200 From: Leonardo Silva Amaral User-Agent: Mozilla Thunderbird 1.0.7 (X11/20051017) X-Accept-Language: pt-br, pt MIME-Version: 1.0 To: linux-mips@linux-mips.org Subject: Linux on handheld X-Enigmail-Version: 0.93.0.0 OpenPGP: id=C6E3CB51 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigF4AD2E00495DEF16EC58AE41" 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: 9601 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: leonardosilv@yahoo.com.br Precedence: bulk X-list: linux-mips This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigF4AD2E00495DEF16EC58AE41 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hello! I Want to run linux on my handheld NEC700, but using linux from linux-mips.org and from kernel.org i give problems on compilation. Thet does matter, linux-mips, give a parse error on vmlinux.ld. Some onde have fixed it? Thanks ------------------------------------------------------------ .,p**"*=b. ?P" .__ `*b |P .d?'`&, 9| Leonardo Silva Amaral M: |} |- H' MSN: leleobhzdiscovery@hotmail.com &| `#?_._oH' JABBER: leleobhz@astolfonet.no-ip.org `H. "`"`' Site: http://blogdoleleo.no-ip.org `#?. Mail: leonardosilv@yahoo.com.br `^~. ------------------------------------------------------------ --------------enigF4AD2E00495DEF16EC58AE41 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDlFcWNpwRGcbjy1ERAv4cAKCtyVK52slKM8tX03BmS4xzZ07H3wCfSCLc Srtn5q+GdHM0dF7b8oWf+Ho= =Knh8 -----END PGP SIGNATURE----- --------------enigF4AD2E00495DEF16EC58AE41-- _______________________________________________________ Yahoo! doce lar. Faça do Yahoo! sua homepage. http://br.yahoo.com/homepageset.html From jcrouse@cosmic.amd.com Mon Dec 5 15:07:02 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 05 Dec 2005 15:07:34 +0000 (GMT) Received: from amdext3.amd.com ([139.95.251.6]:12012 "EHLO amdext3.amd.com") by ftp.linux-mips.org with ESMTP id S8133659AbVLEPG0 (ORCPT ); Mon, 5 Dec 2005 15:06:26 +0000 Received: from SSVLGW02.amd.com (ssvlgw02.amd.com [139.95.250.170]) by amdext3.amd.com (8.12.11/8.12.11/AMD) with ESMTP id jB5F5vxY018804; Mon, 5 Dec 2005 07:05:57 -0800 Received: from 139.95.250.1 by SSVLGW01.amd.com with ESMTP (AMD SMTP Relay (Email Firewall v6.1.0)); Mon, 05 Dec 2005 07:04:48 -0800 X-Server-Uuid: 89466532-923C-4A88-82C1-66ACAA0041DF Received: from ldcmail.amd.com (ldcmail.amd.com [147.5.200.40]) by amdint.amd.com (8.12.8/8.12.8/AMD) with ESMTP id jB5F4hQe007486; Mon, 5 Dec 2005 07:04:43 -0800 (PST) Received: from cosmic.amd.com (cosmic.amd.com [147.5.201.206]) by ldcmail.amd.com (Postfix) with ESMTP id 5EFC02026; Mon, 5 Dec 2005 08:04:43 -0700 (MST) Received: from cosmic.amd.com (localhost [127.0.0.1]) by cosmic.amd.com (8.13.4/8.13.4) with ESMTP id jB5FDEtV014945; Mon, 5 Dec 2005 08:13:14 -0700 Received: (from jcrouse@localhost) by cosmic.amd.com ( 8.13.4/8.13.4/Submit) id jB5FDE0E014944; Mon, 5 Dec 2005 08:13:14 -0700 Date: Mon, 5 Dec 2005 08:13:14 -0700 From: "Jordan Crouse" To: "Komal Shah" cc: linux-mips@linux-mips.org, ralf@linux-mips.org Subject: Re: ALCHEMY: SPI driver for Au1200 Message-ID: <20051205151314.GR28227@cosmic.amd.com> References: <20051202190223.GG28227@cosmic.amd.com> <20051205114233.54232.qmail@web32903.mail.mud.yahoo.com> MIME-Version: 1.0 In-Reply-To: <20051205114233.54232.qmail@web32903.mail.mud.yahoo.com> User-Agent: Mutt/1.5.11 X-WSS-ID: 6F8A889A1K82504283-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: 9602 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 05/12/05 03:42 -0800, Komal Shah wrote: > --- Jordan Crouse wrote: > > > A SPI driver for the Au1200 processor. Sending now so it > > can be queued for the post 2.6.15 rush. > > Good. As there is long discussion going on which SPI framework to > accept in mainline, I would suggest you to implement the same master > controller and protocol driver using either David Brownell's framework > (right now in 2.6.15-rc3-mm1) or Dmitry/Wool framework. Since the issue is very much in doubt, I would prefer to wait until a winner has emerged before rewriting the driver again. If the argument resolves itself before 2.6.16, then all is good. But if its going to drag out another 6 months, then I would prefer to have this in the mips tree at least, so that its available to folks who need it. Jordan -- Jordan Crouse Senior Linux Engineer AMD - Personal Connectivity Solutions Group From david.sanchez@lexbox.fr Mon Dec 5 15:15:32 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 05 Dec 2005 15:15:52 +0000 (GMT) Received: from laf31-5-82-235-130-100.fbx.proxad.net ([82.235.130.100]:9715 "EHLO lexbox.fr") by ftp.linux-mips.org with ESMTP id S8133603AbVLEPPc convert rfc822-to-8bit (ORCPT ); Mon, 5 Dec 2005 15:15:32 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8BIT Subject: RE: Au1550 system bus masters issue X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Date: Mon, 5 Dec 2005 16:11:25 +0100 Message-ID: <17AB476A04B7C842887E0EB1F268111E0271C6@xpserver.intra.lexbox.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Au1550 system bus masters issue thread-index: AcX5k3gaJ/PHEpjwQI2K4a3cr63YYAAGYZbw From: "David Sanchez" To: "Sergei Shtylylov" , 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: 9603 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.sanchez@lexbox.fr Precedence: bulk X-list: linux-mips Hi, This question is for all the users of the AMD alchemy db1550: What is the frequency you use for the triplet (CPU core / System bus / SDRAM bus)? Since the version 2.25 of YAMON the freq is based on the rotary switch S4: HEX Rotary Switch S4 (# = CPU_CORE / SYS_BUS / SDRAM_BUS in MHz): 0 = 192/ 96/ 96 , 1 = 336/168/168 , 2 = 396/198/ 99 , 3 = 396/198/198 4 = 492/123/123 , 5 = 492/164/164 , 6 = 492/246/123 Thanks, David SANCHEZ -----Message d'origine----- De : Sergei Shtylylov [mailto:sshtylyov@ru.mvista.com] Envoyé : lundi 5 décembre 2005 13:00 À : David Sanchez; Linux MIPS Development Objet : Re: Au1550 system bus masters issue Hello. Sergei Shtylylov wrote: > coherency in Ethernet driver however makes the kernel non-bootable. USB > host controller (and probably not only it, I'm too lazy to re-check ;-) > is still prone to other errata on stepping AB though, see this thread: > > http://www.linux-mips.org/archives/linux-mips/2005-11/msg00137.html > > I'm gonna rework the patch and resubmit. Oops, I was talking of Au1500 step AB, Au1550 doesn't have CONFIG.OD bit errata... WBR, Sergei From scott.ashcroft@talk21.com Tue Dec 6 00:23:39 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 06 Dec 2005 00:23:58 +0000 (GMT) Received: from web86303.mail.ukl.yahoo.com ([217.12.12.62]:25955 "HELO web86303.mail.ukl.yahoo.com") by ftp.linux-mips.org with SMTP id S8133730AbVLFAXi (ORCPT ); Tue, 6 Dec 2005 00:23:38 +0000 Received: (qmail 60359 invoked by uid 60001); 6 Dec 2005 00:23:12 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=talk21.com; h=Message-ID:Received:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=EgIW6LWrQGJWCrMHUvcTQDDrLD4DqHVr/b86DzBTYI+8lZB2rzaVg29DovTgcPaN8Et/G76brqm1LjGcVQvfqjTHaiIHQL49vC/lLjQM36e4xUyvc7uDXdiAkDliq7BmeJEQpIWWZo7GiLRL2oQmyDJF6ZUnjsNzDDCW/qL+G1Y= ; Message-ID: <20051206002312.60357.qmail@web86303.mail.ukl.yahoo.com> Received: from [62.190.246.49] by web86303.mail.ukl.yahoo.com via HTTP; Tue, 06 Dec 2005 00:23:12 GMT Date: Tue, 6 Dec 2005 00:23:12 +0000 (GMT) From: Scott Ashcroft Subject: pci_iomap issues? 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: 9604 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: scott.ashcroft@talk21.com Precedence: bulk X-list: linux-mips What will it take to get a pci_iomap implementation into the kernel. Looking back in the list archives I've seen comments that the patches posted to the list don't support multiple PCI busses. I can't see any difference between the patches and the support in other archs. Are the other archs broken or am I missing something? Cheers, Scott From maillist@jg555.com Tue Dec 6 01:48:35 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 06 Dec 2005 01:48:54 +0000 (GMT) Received: from Jg555.com ([64.30.195.78]:41089 "EHLO jg555.com") by ftp.linux-mips.org with ESMTP id S8133793AbVLFBse (ORCPT ); Tue, 6 Dec 2005 01:48:34 +0000 Received: from [172.16.0.55] ([::ffff:172.16.0.55]) (AUTH: PLAIN root, TLS: TLSv1/SSLv3,256bits,AES256-SHA) by jg555.com with esmtp; Mon, 05 Dec 2005 17:48:11 -0800 id 00098009.4394EDDB.00005B6D Message-ID: <4394EDC8.9080301@jg555.com> Date: Mon, 05 Dec 2005 17:47:52 -0800 From: Jim Gifford User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Scott Ashcroft CC: linux-mips@linux-mips.org Subject: Re: pci_iomap issues? References: <20051206002312.60357.qmail@web86303.mail.ukl.yahoo.com> In-Reply-To: <20051206002312.60357.qmail@web86303.mail.ukl.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: 9605 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 How many machines are affected by multiple pci busses. I can only thing of the Origin systems. Couldn't we get a base iomap.c in and add one's specific to the multiple bus machines? -- ---- Jim Gifford maillist@jg555.com From david.sanchez@lexbox.fr Tue Dec 6 08:56:08 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 06 Dec 2005 08:56:28 +0000 (GMT) Received: from laf31-5-82-235-130-100.fbx.proxad.net ([82.235.130.100]:35312 "EHLO lexbox.fr") by ftp.linux-mips.org with ESMTP id S8133376AbVLFI4I convert rfc822-to-8bit (ORCPT ); Tue, 6 Dec 2005 08:56:08 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 8BIT Subject: Au1550 SDRAM bus frequency & data corruption X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Date: Tue, 6 Dec 2005 09:52:06 +0100 Message-ID: <17AB476A04B7C842887E0EB1F268111E0271C8@xpserver.intra.lexbox.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Au1550 SDRAM bus frequency & data corruption thread-index: AcX6QlXBMKznyyKoSR2s/eQjZlpPWA== From: "David Sanchez" To: , "Sergei Shtylylov" 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: 9606 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.sanchez@lexbox.fr Precedence: bulk X-list: linux-mips Hi, I found a solution to my problem of data corruption on my AMD alchemy Db1550: I divided the SDRAM bus frequency by 2. So I get the following set of freq: CPU core = 396 Mhz System bus = 198 Mhz SDRAM bus = 99 Mhz instead of 198 Mhz The PCI clock is 64 Mhz. To do this I simply use the boot monitor YAMON v2.25 provided by AMD (downloaded from their website). And set the position of the rotary switch to 2. I don't really know if the SDRAM bus frequency was the root issue or if it simply slows down the transfer and thus the problem has not enough time to appear...but I test the copy during all the night and the test doesn't report any error :) Sergei, could you tell me your frequency configuration that you use on you au1550 board, please ? Thanks David Sanchez From ralf@linux-mips.org Tue Dec 6 10:20:15 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 06 Dec 2005 10:20:36 +0000 (GMT) Received: from extgw-uk.mips.com ([62.254.210.129]:14607 "EHLO bacchus.net.dhis.org") by ftp.linux-mips.org with ESMTP id S8133389AbVLFKUP (ORCPT ); Tue, 6 Dec 2005 10:20:15 +0000 Received: from dea.linux-mips.net (localhost.localdomain [127.0.0.1]) by bacchus.net.dhis.org (8.13.4/8.13.1) with ESMTP id jB6AJpp8014806; Tue, 6 Dec 2005 10:19:51 GMT Received: (from ralf@localhost) by dea.linux-mips.net (8.13.4/8.13.4/Submit) id jB6AJoca014805; Tue, 6 Dec 2005 10:19:50 GMT Date: Tue, 6 Dec 2005 10:19:50 +0000 From: Ralf Baechle To: Leonardo Silva Amaral Cc: linux-mips@linux-mips.org Subject: Re: Linux on handheld Message-ID: <20051206101950.GB2698@linux-mips.org> References: <4394570E.7040702@yahoo.com.br> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4394570E.7040702@yahoo.com.br> 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: 9607 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 Oi, On Mon, Dec 05, 2005 at 01:04:46PM -0200, Leonardo Silva Amaral wrote: > I Want to run linux on my handheld NEC700, but using linux from > linux-mips.org and from kernel.org i give problems on compilation. > > Thet does matter, linux-mips, give a parse error on vmlinux.ld. Some > onde have fixed it? I don't think we support the NEC700. The error you're seeing is probably a result of having chosen by a kernel configuration for a broken target, which system did you configure for? Ralf From leonardosilv@yahoo.com.br Tue Dec 6 11:20:29 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 06 Dec 2005 11:20:54 +0000 (GMT) Received: from smtp203.mail.sc5.yahoo.com ([216.136.129.93]:47807 "HELO smtp203.mail.sc5.yahoo.com") by ftp.linux-mips.org with SMTP id S8133389AbVLFLU3 (ORCPT ); Tue, 6 Dec 2005 11:20:29 +0000 Received: (qmail 66695 invoked from network); 6 Dec 2005 11:19:22 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com.br; h=Received:Message-ID:Date:From:User-Agent:X-Accept-Language:MIME-Version:To:Subject:References:In-Reply-To:X-Enigmail-Version:OpenPGP:Content-Type; b=TdNlQc1JUTfjVnyWpO+9Kpsexf0g0KoM0+W/+4ts4NnsYX9yIUJc/fHHfM6YZMEPuOl5rLZ6TfrENf4zy39QVIM6DbWmr2IN1vjwmpbwCq0Xu6NjAATsOze4d1sD13bYqrvS0F6VuwLD6qoxaPfwiE/IUvHsC3VEu1Pnufl7OTE= ; Received: from unknown (HELO ?192.168.0.3?) (leonardosilv@200.139.137.68 with plain) by smtp203.mail.sc5.yahoo.com with SMTP; 6 Dec 2005 11:19:19 -0000 Message-ID: <4395739C.6030308@yahoo.com.br> Date: Tue, 06 Dec 2005 09:18:52 -0200 From: Leonardo Silva Amaral User-Agent: Mozilla Thunderbird 1.0.7 (X11/20051017) X-Accept-Language: pt-br, pt MIME-Version: 1.0 To: linux-mips@linux-mips.org Subject: Re: Linux on handheld References: <4394570E.7040702@yahoo.com.br> <20051206101950.GB2698@linux-mips.org> In-Reply-To: <20051206101950.GB2698@linux-mips.org> X-Enigmail-Version: 0.93.0.0 OpenPGP: id=C6E3CB51 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig7E59479CF886113724505719" 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: 9608 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: leonardosilv@yahoo.com.br Precedence: bulk X-list: linux-mips This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig7E59479CF886113724505719 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi! Im building for VR4120, that is my nec... Thanks Ralf Baechle escreveu: > Oi, > > On Mon, Dec 05, 2005 at 01:04:46PM -0200, Leonardo Silva Amaral wrote: > > >>I Want to run linux on my handheld NEC700, but using linux from >>linux-mips.org and from kernel.org i give problems on compilation. >> >>Thet does matter, linux-mips, give a parse error on vmlinux.ld. Some >>onde have fixed it? > > > I don't think we support the NEC700. The error you're seeing is probably > a result of having chosen by a kernel configuration for a broken target, > which system did you configure for? > > Ralf > > -- ------------------------------------------------------------ .,p**"*=b. ?P" .__ `*b |P .d?'`&, 9| Leonardo Silva Amaral M: |} |- H' MSN: leleobhzdiscovery@hotmail.com &| `#?_._oH' JABBER: leleobhz@astolfonet.no-ip.org `H. "`"`' Site: http://blogdoleleo.no-ip.org `#?. Mail: leonardosilv@yahoo.com.br `^~. ------------------------------------------------------------ --------------enig7E59479CF886113724505719 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDlXOjNpwRGcbjy1ERAtmqAJ9OvQ/S1sWhKdJQ+/gbBAzcVgd4bwCglqKs lZgCKMINVVHe7tcB44d7Ayk= =Iz+k -----END PGP SIGNATURE----- --------------enig7E59479CF886113724505719-- _______________________________________________________ Yahoo! doce lar. Faça do Yahoo! sua homepage. http://br.yahoo.com/homepageset.html From lhrkernelcoder@gmail.com Tue Dec 6 12:06:26 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 06 Dec 2005 12:06:45 +0000 (GMT) Received: from wproxy.gmail.com ([64.233.184.192]:9660 "EHLO wproxy.gmail.com") by ftp.linux-mips.org with ESMTP id S8133453AbVLFMGZ convert rfc822-to-8bit (ORCPT ); Tue, 6 Dec 2005 12:06:25 +0000 Received: by wproxy.gmail.com with SMTP id i14so345923wra for ; Tue, 06 Dec 2005 04:06:06 -0800 (PST) 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=bjrjNwd0cG3eDCDtBC8Jh2ZYZo3yVmfUd1WimlYOZB8GW2hhuuUsRslJLGkN71puDe0IDjJG/dxvz7grGw7zGk8rKVbFUE2KMxbiTBN3++yRH9ByBStd7plN5rEU2/pNi9OmHES9bAljYhrGMQeILib9IAPuo1csG6DN4dNw/v0= Received: by 10.54.154.17 with SMTP id b17mr1674047wre; Tue, 06 Dec 2005 04:06:06 -0800 (PST) Received: by 10.54.146.1 with HTTP; Tue, 6 Dec 2005 04:06:06 -0800 (PST) Message-ID: Date: Tue, 6 Dec 2005 04:06:06 -0800 From: kernel coder To: linux-mips@linux-mips.org Subject: zero copy MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT 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: 9609 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 track the code flow of sendfile system call.Mine ethernet card doesn't have scatter gather and checksum calculation features.So stack should be making a copy of data. Please tell me where in sendfile code flow,check for scatter gather and cecksum features is made so that stack can decide whether to copy data from user space or not. lhrkernelcoder From mmporter@cox.net Tue Dec 6 15:54:12 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 06 Dec 2005 15:54:32 +0000 (GMT) Received: from fed1rmmtao09.cox.net ([68.230.241.30]:1429 "EHLO fed1rmmtao09.cox.net") by ftp.linux-mips.org with ESMTP id S8133511AbVLFPyM (ORCPT ); Tue, 6 Dec 2005 15:54:12 +0000 Received: from liberty.homelinux.org ([70.190.160.125]) by fed1rmmtao09.cox.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with ESMTP id <20051206155349.FECG25099.fed1rmmtao09.cox.net@liberty.homelinux.org>; Tue, 6 Dec 2005 10:53:49 -0500 Received: (from mmporter@localhost) by liberty.homelinux.org (8.9.3/8.9.3/Debian 8.9.3-21) id IAA06907; Tue, 6 Dec 2005 08:53:47 -0700 Date: Tue, 6 Dec 2005 08:53:47 -0700 From: Matt Porter To: kernel coder Cc: linux-mips@linux-mips.org Subject: Re: zero copy Message-ID: <20051206085347.A32501@cox.net> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from lhrkernelcoder@gmail.com on Tue, Dec 06, 2005 at 04:06:06AM -0800 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: 9610 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: mporter@kernel.crashing.org Precedence: bulk X-list: linux-mips On Tue, Dec 06, 2005 at 04:06:06AM -0800, kernel coder wrote: > hi, > i'm trying to track the code flow of sendfile system call.Mine > ethernet card doesn't have scatter gather and checksum calculation > features.So stack should be making a copy of data. > > Please tell me where in sendfile code flow,check for scatter gather > and cecksum features is made so that stack can decide whether to copy > data from user space or not. Is your grep really that broken? :) net/ipv4/tcp.c:tcp_sendpage() is where you find the check and fallback to sendmsg if you follow it through. -Matt From vbarinov@ru.mvista.com Tue Dec 6 17:54:56 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 06 Dec 2005 17:55:16 +0000 (GMT) Received: from rtsoft3.corbina.net ([85.21.88.6]:12343 "EHLO buildserver.ru.mvista.com") by ftp.linux-mips.org with ESMTP id S8133676AbVLFRy4 (ORCPT ); Tue, 6 Dec 2005 17:54:56 +0000 Received: from [192.168.12.17] ([10.149.0.1]) by buildserver.ru.mvista.com (8.11.6/8.11.6) with ESMTP id jB6Hsat18141; Tue, 6 Dec 2005 21:54:36 +0400 Message-ID: <4395D05C.9060408@ru.mvista.com> Date: Tue, 06 Dec 2005 20:54:36 +0300 From: "Vladimir A. Barinov" User-Agent: Mozilla Thunderbird 1.0.2-6 (X11/20050513) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ralf@linux-mips.org CC: linux-mips@linux-mips.org, ppopov@embeddedalley.com Subject: [PATCH] Philips PNX8550 ip3106 driver deadlock fix Content-Type: multipart/mixed; boundary="------------060108000006010507080008" 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: 9611 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: vbarinov@ru.mvista.com Precedence: bulk X-list: linux-mips This is a multi-part message in MIME format. --------------060108000006010507080008 Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit Hello Ralf, This is a patch that fixes spin_lock deadlock in serial ip3106 driver. The spin_lock_irq(&port->lock,flags) is already called in generic driver serial_core.c before port->ops->start_tx(). So the second call of spin_lock_irq(&port->lock, flags) leads to deadlock. This could be verified in PREEMPT_DESCTOP case when these options are enabled: CONFIG_DEBUG_PREEMPT=y CONFIG_DEBUG_SPINLOCK=y Vladimir --------------060108000006010507080008 Content-Type: text/plain; name="ip3106_uart.diff" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="ip3106_uart.diff" --- linux-2.6.15/drivers/serial/ip3106_uart.c 2005-12-02 16:37:59.000000000 +0300 +++ linux-2.6.15/drivers/serial/ip3106_uart.c 2005-12-06 20:40:15.000000000 +0300 @@ -149,19 +149,14 @@ static void ip3106_stop_tx(struct uart_p static void ip3106_start_tx(struct uart_port *port, unsigned int tty_start) { struct ip3106_port *sport = (struct ip3106_port *)port; - unsigned long flags; u32 ien; - spin_lock_irqsave(&sport->port.lock, flags); - /* Clear all pending TX intr */ serial_out(sport, IP3106_ICLR, IP3106_UART_INT_ALLTX); /* Enable TX intr */ ien = serial_in(sport, IP3106_IEN); serial_out(sport, IP3106_IEN, ien | IP3106_UART_INT_ALLTX); - - spin_unlock_irqrestore(&sport->port.lock, flags); } /* --------------060108000006010507080008-- From bora.sahin@ttnet.net.tr Tue Dec 6 17:56:22 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 06 Dec 2005 17:56:41 +0000 (GMT) Received: from [212.175.13.129] ([212.175.13.129]:63742 "EHLO fep03.ttnet.net.tr") by ftp.linux-mips.org with ESMTP id S8133718AbVLFR4V (ORCPT ); Tue, 6 Dec 2005 17:56:21 +0000 Received: from zenon ([81.213.120.225]) by fep03.ttnet.net.tr with ESMTP id <20051206175233.TAHO5148.fep03.ttnet.net.tr@zenon> for ; Tue, 6 Dec 2005 19:52:33 +0200 Date: Tue, 6 Dec 2005 19:55:39 +0200 From: Bora Sahin Reply-To: =?ISO-8859-9?B?Qm9yYSDeYWhpbg==?= X-Priority: 3 (Normal) Message-ID: <1631352046.20051206195539@ttnet.net.tr> To: linux-mips@linux-mips.org Subject: DBAu1200 & Alchemy MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-9 Content-Transfer-Encoding: 8bit X-NAI-Spam-Rules: 1 Rules triggered BAYES_00=-2.5 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: 9612 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: bora.sahin@ttnet.net.tr Precedence: bulk X-list: linux-mips Hi, While I was working on the graphic console support of DbAu1200, I realized that USB controller of it is a bit different from the other Alchemy family members. As far as I understood, only OHCI support is matter(Perhaps OTG but because I am not interested in now, didnt include; EHCI depends on PCI stuff etc.) and in order to work needs a bus glue logic different from e.g. Au1550. If I compile it as is, kernel gives an error message saying that USB_HOST_CONFIG is undefined in au1xxx_start_hc()... I am totaly new to USB stuff bus as far as I understood, if I correct this function accordingly, I can enable USB stuff. So I examined the databook and did the following change and ifdefing the change to CONFIG_SOC_AU1200... au1xxx_start_hc() { ... au_writel(au_readl(USB_MSR_BASE + USB_MSR_MCFG) | 1 << USBMSRMCFG_OHCCLKEN, USB_MSR_BASE + USB_MSR_MCFG); au_writel(au_readl(USB_MSR_BASE + USB_MSR_MCFG) | 1 << USBMSRMCFG_OMEMEN, USB_MSR_BASE + USB_MSR_MCFG); au_writel(au_readl(USB_MSR_BASE + USB_MSR_MCFG) | 1 << USBMSRMCFG_OBMEN, USB_MSR_BASE + USB_MSR_MCFG); ... } So it seemed to work a bit. Firstly, I get the following messages and the kernel goes on after a bit time passed... u1xxx-ohci au1xxx-ohci.0: Au1xxx OHCI au1xxx-ohci au1xxx-ohci.0: new USB bus registered, assigned bus number 1 au1xxx-ohci au1xxx-ohci.0: irq 29, io mem 0x14020100 usb usb1: Product: Au1xxx OHCI usb usb1: Manufacturer: Linux 2.6.15-rc4-g2b269cc6 ohci_hcd usb usb1: SerialNumber: Au1xxx hub 1-0:1.0: USB hub found hub 1-0:1.0: 2 ports detected usb 1-1: new low speed USB device using au1xxx-ohci and address 2 au1xxx-ohci au1xxx-ohci.0: Unlink after no-IRQ? Controller is probably using the wrong IRQ. Then rootfs is mounted and I continue to receive the following error messages: au1xxx-ohci au1xxx-ohci.0: GetStatus roothub.portstatus [0] = 0x00100303 PRSC LSDA PPS PES CCS Dec 31 19:33:20 off kernel: usb 1-1: new low speed USB device using au1xxx-ohci and address 12 Dec 31 19:33:27 off kernel: usb 1-1: khubd timed out on ep0out len=0/0 usb 1-1: device not accepting address 12, error -145 Dec 31 19:33:35 off kernel: usb 1-1: khubd timed out on ep0out len=0/0 Dec 31 19:33:35 off kernel: usb 1-1: device not accepting address 12, error -145 Dec 31 19:33:35 off kernel: kobject : cleaning up Before digging through much, I want to get your points. In the meanwhile, in the include/asm-mips/mach-au1x00/au1000.h file there are two defines named #define USBMSRMCFG_RDCOMB 30 #define USBMSRMCFG_PFEN 31 but these are not showed in the Au1200 databook. What is this? I tried enabling them one-to-one, both; but didnt get a result... -- Bora SAHIN From ralf@linux-mips.org Tue Dec 6 18:01:03 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 06 Dec 2005 18:01:22 +0000 (GMT) Received: from extgw-uk.mips.com ([62.254.210.129]:50457 "EHLO bacchus.net.dhis.org") by ftp.linux-mips.org with ESMTP id S8133676AbVLFSBD (ORCPT ); Tue, 6 Dec 2005 18:01:03 +0000 Received: from dea.linux-mips.net (localhost.localdomain [127.0.0.1]) by bacchus.net.dhis.org (8.13.4/8.13.1) with ESMTP id jB6I0bXr031682; Tue, 6 Dec 2005 18:00:37 GMT Received: (from ralf@localhost) by dea.linux-mips.net (8.13.4/8.13.4/Submit) id jB6I0ZpX031681; Tue, 6 Dec 2005 18:00:35 GMT Date: Tue, 6 Dec 2005 18:00:35 +0000 From: Ralf Baechle To: "Vladimir A. Barinov" Cc: linux-mips@linux-mips.org, ppopov@embeddedalley.com Subject: Re: [PATCH] Philips PNX8550 ip3106 driver deadlock fix Message-ID: <20051206180035.GG2698@linux-mips.org> References: <4395D05C.9060408@ru.mvista.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4395D05C.9060408@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: 9613 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, Dec 06, 2005 at 08:54:36PM +0300, Vladimir A. Barinov wrote: > This is a patch that fixes spin_lock deadlock in serial ip3106 driver. > The spin_lock_irq(&port->lock,flags) is already called in generic driver > serial_core.c before > port->ops->start_tx(). > So the second call of spin_lock_irq(&port->lock, flags) leads to > deadlock. This could be verified in PREEMPT_DESCTOP case when > these options are enabled: > CONFIG_DEBUG_PREEMPT=y > CONFIG_DEBUG_SPINLOCK=y Serial drivers are maintained by rmk+serial@arm.linux.org.uk, please send to him. Ralf From vbarinov@ru.mvista.com Tue Dec 6 18:02:33 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 06 Dec 2005 18:02:51 +0000 (GMT) Received: from rtsoft3.corbina.net ([85.21.88.6]:17719 "EHLO buildserver.ru.mvista.com") by ftp.linux-mips.org with ESMTP id S8133676AbVLFSCd (ORCPT ); Tue, 6 Dec 2005 18:02:33 +0000 Received: from [192.168.12.17] ([10.149.0.1]) by buildserver.ru.mvista.com (8.11.6/8.11.6) with ESMTP id jB6I2Et18499; Tue, 6 Dec 2005 22:02:14 +0400 Message-ID: <4395D226.9070807@ru.mvista.com> Date: Tue, 06 Dec 2005 21:02:14 +0300 From: "Vladimir A. Barinov" User-Agent: Mozilla Thunderbird 1.0.2-6 (X11/20050513) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ralf@linux-mips.org CC: linux-mips@linux-mips.org, ppopov@embeddedalley.com Subject: [PATCH] Philips PNX8550 command line patch Content-Type: multipart/mixed; boundary="------------050303010409080505070605" 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: 9614 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: vbarinov@ru.mvista.com Precedence: bulk X-list: linux-mips This is a multi-part message in MIME format. --------------050303010409080505070605 Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit Hello Ralf, This patch makes passing command line from bootloader for Philips PNX8550 platform. Does it makes sense to commit this patch? Vladimir --------------050303010409080505070605 Content-Type: text/plain; name="cmdline.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="cmdline.patch" --- linux-2.6.15/arch/mips/philips/pnx8550/jbs/init.c 2005-12-02 16:37:59.000000000 +0300 +++ linux-2.6.15/arch/mips/philips/pnx8550/jbs/init.c 2005-12-06 13:12:22.000000000 +0300 @@ -47,6 +47,11 @@ void __init prom_init(void) { unsigned long memsize; + prom_argc = (int) fw_arg0; + prom_argv = (char **) fw_arg1; + prom_envp = (char **) fw_arg2; + + prom_init_cmdline(); mips_machgroup = MACH_GROUP_PHILIPS; mips_machtype = MACH_PHILIPS_JBS; --- linux-2.6.15/arch/mips/philips/pnx8550/common/prom.c 2005-12-02 16:37:59.000000000 +0300 +++ linux-2.6.15/arch/mips/philips/pnx8550/common/prom.c 2005-12-06 13:48:10.000000000 +0300 @@ -35,23 +35,15 @@ char * prom_getcmdline(void) return &(arcs_cmdline[0]); } -void prom_init_cmdline(void) +void __init prom_init_cmdline(void) { - char *cp; - int actr; - - actr = 1; /* Always ignore argv[0] */ + int i; - cp = &(arcs_cmdline[0]); - while(actr < prom_argc) { - strcpy(cp, prom_argv[actr]); - cp += strlen(prom_argv[actr]); - *cp++ = ' '; - actr++; + arcs_cmdline[0] = '\0'; + for (i = 0; i < prom_argc; i++) { + strcat(arcs_cmdline, prom_argv[i]); + strcat(arcs_cmdline, " "); } - if (cp != &(arcs_cmdline[0])) /* get rid of trailing space */ - --cp; - *cp = '\0'; } char *prom_getenv(char *envname) --------------050303010409080505070605-- From vbarinov@ru.mvista.com Tue Dec 6 18:03:19 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 06 Dec 2005 18:03:45 +0000 (GMT) Received: from rtsoft3.corbina.net ([85.21.88.6]:18231 "EHLO buildserver.ru.mvista.com") by ftp.linux-mips.org with ESMTP id S8133676AbVLFSDT (ORCPT ); Tue, 6 Dec 2005 18:03:19 +0000 Received: from [192.168.12.17] ([10.149.0.1]) by buildserver.ru.mvista.com (8.11.6/8.11.6) with ESMTP id jB6I30t18507; Tue, 6 Dec 2005 22:03:01 +0400 Message-ID: <4395D254.9060203@ru.mvista.com> Date: Tue, 06 Dec 2005 21:03:00 +0300 From: "Vladimir A. Barinov" User-Agent: Mozilla Thunderbird 1.0.2-6 (X11/20050513) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ralf Baechle CC: linux-mips@linux-mips.org, ppopov@embeddedalley.com Subject: Re: [PATCH] Philips PNX8550 ip3106 driver deadlock fix References: <4395D05C.9060408@ru.mvista.com> <20051206180035.GG2698@linux-mips.org> In-Reply-To: <20051206180035.GG2698@linux-mips.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: 9615 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: vbarinov@ru.mvista.com Precedence: bulk X-list: linux-mips Ralf Baechle wrote: >On Tue, Dec 06, 2005 at 08:54:36PM +0300, Vladimir A. Barinov wrote: > > > >>This is a patch that fixes spin_lock deadlock in serial ip3106 driver. >>The spin_lock_irq(&port->lock,flags) is already called in generic driver >>serial_core.c before >>port->ops->start_tx(). >>So the second call of spin_lock_irq(&port->lock, flags) leads to >>deadlock. This could be verified in PREEMPT_DESCTOP case when >>these options are enabled: >>CONFIG_DEBUG_PREEMPT=y >>CONFIG_DEBUG_SPINLOCK=y >> >> > >Serial drivers are maintained by rmk+serial@arm.linux.org.uk, please send >to him. > > Ok, thank you. > Ralf > > > > From ralf@linux-mips.org Tue Dec 6 18:05:18 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 06 Dec 2005 18:05:36 +0000 (GMT) Received: from extgw-uk.mips.com ([62.254.210.129]:60173 "EHLO bacchus.net.dhis.org") by ftp.linux-mips.org with ESMTP id S8133725AbVLFSFS (ORCPT ); Tue, 6 Dec 2005 18:05:18 +0000 Received: from dea.linux-mips.net (localhost.localdomain [127.0.0.1]) by bacchus.net.dhis.org (8.13.4/8.13.1) with ESMTP id jB6I4sQg031836; Tue, 6 Dec 2005 18:04:54 GMT Received: (from ralf@localhost) by dea.linux-mips.net (8.13.4/8.13.4/Submit) id jB6I4sAR031835; Tue, 6 Dec 2005 18:04:54 GMT Date: Tue, 6 Dec 2005 18:04:54 +0000 From: Ralf Baechle To: "Vladimir A. Barinov" Cc: linux-mips@linux-mips.org, ppopov@embeddedalley.com Subject: Re: [PATCH] Philips PNX8550 command line patch Message-ID: <20051206180454.GH2698@linux-mips.org> References: <4395D226.9070807@ru.mvista.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4395D226.9070807@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: 9616 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, Dec 06, 2005 at 09:02:14PM +0300, Vladimir A. Barinov wrote: > This patch makes passing command line from bootloader for Philips > PNX8550 platform. > Does it makes sense to commit this patch? Looks ok at a quick glance. I'll wait a bit so Pete has a chance to comment. Ralf From vbarinov@ru.mvista.com Tue Dec 6 18:22:37 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 06 Dec 2005 18:22:54 +0000 (GMT) Received: from rtsoft3.corbina.net ([85.21.88.6]:31031 "EHLO buildserver.ru.mvista.com") by ftp.linux-mips.org with ESMTP id S8133583AbVLFSWh (ORCPT ); Tue, 6 Dec 2005 18:22:37 +0000 Received: from [192.168.12.17] ([10.149.0.1]) by buildserver.ru.mvista.com (8.11.6/8.11.6) with ESMTP id jB6IMIt19511; Tue, 6 Dec 2005 22:22:18 +0400 Message-ID: <4395D6D9.2020105@ru.mvista.com> Date: Tue, 06 Dec 2005 21:22:17 +0300 From: "Vladimir A. Barinov" User-Agent: Mozilla Thunderbird 1.0.2-6 (X11/20050513) X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-mips@linux-mips.org CC: ralf@linux-mips.org, ppopov@embeddedalley.com Subject: [PATCH] Philips PNX8550 USB Host driver compile fix Content-Type: text/plain; charset=KOI8-R; 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: 9617 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: vbarinov@ru.mvista.com Precedence: bulk X-list: linux-mips Hello, Ralf, Pete, The current ohci-hcd driver is a littel defective. It's unable to use usb-ohci as modules in the case when PCI and on-chip USB are enabled. It just willn't be compiled since there are two calls if module_init in ohci-hcd. Please look at the patch attached. I 'm not sure is this patch well for this situation. Any suggestions are very appretiated. TIA, Vladimir From vbarinov@ru.mvista.com Tue Dec 6 18:24:10 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 06 Dec 2005 18:24:28 +0000 (GMT) Received: from rtsoft3.corbina.net ([85.21.88.6]:31543 "EHLO buildserver.ru.mvista.com") by ftp.linux-mips.org with ESMTP id S8133726AbVLFSYK (ORCPT ); Tue, 6 Dec 2005 18:24:10 +0000 Received: from [192.168.12.17] ([10.149.0.1]) by buildserver.ru.mvista.com (8.11.6/8.11.6) with ESMTP id jB6INqt19576; Tue, 6 Dec 2005 22:23:52 +0400 Message-ID: <4395D738.3080800@ru.mvista.com> Date: Tue, 06 Dec 2005 21:23:52 +0300 From: "Vladimir A. Barinov" User-Agent: Mozilla Thunderbird 1.0.2-6 (X11/20050513) X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-mips@linux-mips.org CC: ralf@linux-mips.org, ppopov@embeddedalley.com Subject: [PATCH] Philips PNX8550 USB Host driver compile fix Content-Type: multipart/mixed; boundary="------------020604080105030507040509" 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: 9618 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: vbarinov@ru.mvista.com Precedence: bulk X-list: linux-mips This is a multi-part message in MIME format. --------------020604080105030507040509 Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit Hello, Ralf, Pete, The current ohci-hcd driver is a little defective. It's unable to use usb-ohci as modules in the case when PCI and on-chip USB are enabled. It just will not be compiled since there are two calls if module_init in ohci-hcd. Please look at the patch attached. I 'm not sure is this patch well for this situation. Any suggestions are very appreciated. TIA, Vladimir --------------020604080105030507040509 Content-Type: text/plain; name="usb_modules.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="usb_modules.patch" --- linux-2.6.10.orig/drivers/usb/host/ohci-hcd.c 2005-12-02 16:37:59.000000000 +0300 +++ linux-2.6.10/drivers/usb/host/ohci-hcd.c 2005-12-02 19:34:21.000000000 +0300 @@ -906,8 +906,12 @@ MODULE_LICENSE ("GPL"); #endif #ifdef CONFIG_PNX8550 +#if defined(CONFIG_PCI) && defined(CONFIG_USB_OHCI_HCD_MODULE) +#error "unable to compile PNX8550 USB and PCI USB as modules simultaneously until usb hcd stack is rewritten" +#else #include "ohci-pnx8550.c" #endif +#endif #ifdef CONFIG_USB_OHCI_HCD_PPC_SOC #include "ohci-ppc-soc.c" @@ -919,6 +923,7 @@ MODULE_LICENSE ("GPL"); || defined (CONFIG_ARCH_LH7A404) \ || defined (CONFIG_PXA27x) \ || defined (CONFIG_SOC_AU1X00) \ + || defined (CONFIG_PNX8550) \ || defined (CONFIG_USB_OHCI_HCD_PPC_SOC) \ ) #error "missing bus glue for ohci-hcd" --------------020604080105030507040509-- From ppopov@embeddedalley.com Tue Dec 6 19:21:34 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 06 Dec 2005 19:21:55 +0000 (GMT) Received: from web403.biz.mail.mud.yahoo.com ([68.142.201.34]:34904 "HELO web403.biz.mail.mud.yahoo.com") by ftp.linux-mips.org with SMTP id S8133726AbVLFTVe (ORCPT ); Tue, 6 Dec 2005 19:21:34 +0000 Received: (qmail 32327 invoked by uid 60001); 6 Dec 2005 19:21:05 -0000 Message-ID: <20051206192105.32325.qmail@web403.biz.mail.mud.yahoo.com> Received: from [63.194.214.47] by web403.biz.mail.mud.yahoo.com via HTTP; Tue, 06 Dec 2005 11:21:05 PST Date: Tue, 6 Dec 2005 11:21:05 -0800 (PST) From: Peter Popov Subject: Re: [PATCH] Philips PNX8550 command line patch To: Ralf Baechle , "Vladimir A. Barinov" Cc: "'linux-mips@linux-mips.org'" In-Reply-To: <20051206180454.GH2698@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: 9619 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 --- Ralf Baechle wrote: > On Tue, Dec 06, 2005 at 09:02:14PM +0300, Vladimir > A. Barinov wrote: > > > This patch makes passing command line from > bootloader for Philips > > PNX8550 platform. > > Does it makes sense to commit this patch? > > Looks ok at a quick glance. I'll wait a bit so Pete > has a chance to comment. Looks fine to me. Pete From ppopov@embeddedalley.com Tue Dec 6 19:35:45 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 06 Dec 2005 19:36:03 +0000 (GMT) Received: from web411.biz.mail.mud.yahoo.com ([68.142.201.42]:1937 "HELO web411.biz.mail.mud.yahoo.com") by ftp.linux-mips.org with SMTP id S8133728AbVLFTfp (ORCPT ); Tue, 6 Dec 2005 19:35:45 +0000 Received: (qmail 2584 invoked by uid 60001); 6 Dec 2005 19:35:22 -0000 Message-ID: <20051206193522.2582.qmail@web411.biz.mail.mud.yahoo.com> Received: from [63.194.214.47] by web411.biz.mail.mud.yahoo.com via HTTP; Tue, 06 Dec 2005 11:35:22 PST Date: Tue, 6 Dec 2005 11:35:22 -0800 (PST) From: Peter Popov Subject: Re: [PATCH] Philips PNX8550 USB Host driver compile fix To: "Vladimir A. Barinov" , linux-mips@linux-mips.org Cc: ralf@linux-mips.org In-Reply-To: <4395D738.3080800@ru.mvista.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: 9620 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 I suppose the right solution is to be able to use the on-chip usb controller as well as an external pci controller. I don't think anyone will do that though. I have one board with an external USB controller but that was done in order to add usb 2.0 support, so the on-chip usb controller is not used. So the simple fix below works fine for me, but Ralf and David B. may have higher standards ;) Pete --- "Vladimir A. Barinov" wrote: > Hello, Ralf, Pete, > > The current ohci-hcd driver is a little defective. > It's unable to use usb-ohci as modules in the case > when PCI and on-chip > USB are enabled. > It just will not be compiled since there are two > calls if module_init in > ohci-hcd. > > Please look at the patch attached. > I 'm not sure is this patch well for this situation. > Any suggestions are very appreciated. > > TIA, > Vladimir > > > > --- linux-2.6.10.orig/drivers/usb/host/ohci-hcd.c > 2005-12-02 16:37:59.000000000 +0300 > +++ linux-2.6.10/drivers/usb/host/ohci-hcd.c > 2005-12-02 19:34:21.000000000 +0300 > @@ -906,8 +906,12 @@ MODULE_LICENSE ("GPL"); > #endif > > #ifdef CONFIG_PNX8550 > +#if defined(CONFIG_PCI) && > defined(CONFIG_USB_OHCI_HCD_MODULE) > +#error "unable to compile PNX8550 USB and PCI USB > as modules simultaneously until usb hcd stack is > rewritten" > +#else > #include "ohci-pnx8550.c" > #endif > +#endif > > #ifdef CONFIG_USB_OHCI_HCD_PPC_SOC > #include "ohci-ppc-soc.c" > @@ -919,6 +923,7 @@ MODULE_LICENSE ("GPL"); > || defined (CONFIG_ARCH_LH7A404) \ > || defined (CONFIG_PXA27x) \ > || defined (CONFIG_SOC_AU1X00) \ > + || defined (CONFIG_PNX8550) \ > || defined (CONFIG_USB_OHCI_HCD_PPC_SOC) \ > ) > #error "missing bus glue for ohci-hcd" > From vbarinov@ru.mvista.com Tue Dec 6 19:52:50 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 06 Dec 2005 19:53:11 +0000 (GMT) Received: from rtsoft3.corbina.net ([85.21.88.6]:19000 "EHLO buildserver.ru.mvista.com") by ftp.linux-mips.org with ESMTP id S8133734AbVLFTwu (ORCPT ); Tue, 6 Dec 2005 19:52:50 +0000 Received: from [192.168.12.17] ([10.149.0.1]) by buildserver.ru.mvista.com (8.11.6/8.11.6) with ESMTP id jB6JqVt23980; Tue, 6 Dec 2005 23:52:31 +0400 Message-ID: <4395EBFF.9080408@ru.mvista.com> Date: Tue, 06 Dec 2005 22:52:31 +0300 From: "Vladimir A. Barinov" User-Agent: Mozilla Thunderbird 1.0.2-6 (X11/20050513) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ralf@linux-mips.org CC: linux-mips@linux-mips.org, ppopov@embeddedalley.com Subject: [PATCH] Philips PNX8550 Content-Type: multipart/mixed; boundary="------------090808000209070800000002" 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: 9621 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: vbarinov@ru.mvista.com Precedence: bulk X-list: linux-mips This is a multi-part message in MIME format. --------------090808000209070800000002 Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit Hi Ralf, Pete, This patch enables NATSEMI eth driver to be used on pci bus. Does it make sense to push this patch? Vladimir --------------090808000209070800000002 Content-Type: text/plain; name="natsemi.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="natsemi.patch" --- linux-2.6.15.orig/arch/mips/philips/pnx8550/jbs/irqmap.c 2005-12-02 16:37:59.000000000 +0300 +++ linux-2.6.15/arch/mips/philips/pnx8550/jbs/irqmap.c 2005-12-02 17:33:05.000000000 +0300 @@ -31,6 +31,7 @@ char irq_tab_jbs[][5] __initdata = { [8] = { -1, PNX8550_INT_PCI_INTA, 0xff, 0xff, 0xff}, [9] = { -1, PNX8550_INT_PCI_INTA, 0xff, 0xff, 0xff}, + [10] = { -1, PNX8550_INT_PCI_INTA, 0xff, 0xff, 0xff}, [17] = { -1, PNX8550_INT_PCI_INTA, 0xff, 0xff, 0xff}, }; --------------090808000209070800000002-- From ppopov@embeddedalley.com Tue Dec 6 20:26:48 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 06 Dec 2005 20:27:06 +0000 (GMT) Received: from web405.biz.mail.mud.yahoo.com ([68.142.201.36]:1455 "HELO web405.biz.mail.mud.yahoo.com") by ftp.linux-mips.org with SMTP id S8133728AbVLFU0s (ORCPT ); Tue, 6 Dec 2005 20:26:48 +0000 Received: (qmail 77201 invoked by uid 60001); 6 Dec 2005 20:26:25 -0000 Message-ID: <20051206202625.77199.qmail@web405.biz.mail.mud.yahoo.com> Received: from [64.163.129.139] by web405.biz.mail.mud.yahoo.com via HTTP; Tue, 06 Dec 2005 12:26:25 PST Date: Tue, 6 Dec 2005 12:26:25 -0800 (PST) From: Peter Popov Subject: Re: [PATCH] Philips PNX8550 To: "Vladimir A. Barinov" , ralf@linux-mips.org Cc: linux-mips@linux-mips.org, ppopov@embeddedalley.com In-Reply-To: <4395EBFF.9080408@ru.mvista.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: 9622 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 Hi Vladimir, Is this really for the JBS board or for a different board? Pete --- "Vladimir A. Barinov" wrote: > Hi Ralf, Pete, > > This patch enables NATSEMI eth driver to be used on > pci bus. > > Does it make sense to push this patch? > > Vladimir > > --- > linux-2.6.15.orig/arch/mips/philips/pnx8550/jbs/irqmap.c > 2005-12-02 16:37:59.000000000 +0300 > +++ > linux-2.6.15/arch/mips/philips/pnx8550/jbs/irqmap.c > 2005-12-02 17:33:05.000000000 +0300 > @@ -31,6 +31,7 @@ > char irq_tab_jbs[][5] __initdata = { > [8] = { -1, PNX8550_INT_PCI_INTA, 0xff, 0xff, > 0xff}, > [9] = { -1, PNX8550_INT_PCI_INTA, 0xff, 0xff, > 0xff}, > + [10] = { -1, PNX8550_INT_PCI_INTA, 0xff, 0xff, > 0xff}, > [17] = { -1, PNX8550_INT_PCI_INTA, 0xff, 0xff, > 0xff}, > }; > > From mark.e.mason@broadcom.com Tue Dec 6 23:25:37 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 06 Dec 2005 23:25:58 +0000 (GMT) Received: from mms1.broadcom.com ([216.31.210.17]:26897 "EHLO mms1.broadcom.com") by ftp.linux-mips.org with ESMTP id S8133802AbVLFXZh (ORCPT ); Tue, 6 Dec 2005 23:25:37 +0000 Received: from 10.10.64.121 by mms1.broadcom.com with SMTP (Broadcom SMTP Relay (Email Firewall v6.2.0)); Tue, 06 Dec 2005 15:25:03 -0800 X-Server-Uuid: F962EFE0-448C-40EE-8100-87DF498ED0EA Received: from mail-irva-8.broadcom.com ([10.10.64.221]) by mail-irva-1.broadcom.com (Post.Office MTA v3.5.3 release 223 ID# 0-72233U7200L2200S0V35) with ESMTP id com; Tue, 6 Dec 2005 15:25:03 -0800 Received: from mail-sj1-12.sj.broadcom.com (mail-sj1-12.sj.broadcom.com [10.16.128.215]) by mail-irva-8.broadcom.com (MOS 3.5.6-GR) with ESMTP id CHO74822; Tue, 6 Dec 2005 15:24:54 -0800 (PST) Received: from NT-SJCA-0750.brcm.ad.broadcom.com (nt-sjca-0750 [10.16.192.220]) by mail-sj1-12.sj.broadcom.com (Postfix) with ESMTP id 0BB1A20501; Tue, 6 Dec 2005 15:24:54 -0800 (PST) Received: from [127.0.0.1] ([10.240.253.113]) by NT-SJCA-0750.brcm.ad.broadcom.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 6 Dec 2005 15:24:53 -0800 Message-ID: <43961DC1.80405@broadcom.com> Date: Tue, 06 Dec 2005 15:24:49 -0800 From: "Mark Mason" User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Jim Gifford" cc: "Scott Ashcroft" , linux-mips@linux-mips.org Subject: Re: pci_iomap issues? References: <20051206002312.60357.qmail@web86303.mail.ukl.yahoo.com> <4394EDC8.9080301@jg555.com> In-Reply-To: <4394EDC8.9080301@jg555.com> X-Enigmail-Version: 0.93.0.0 OpenPGP: id=E9620E57; url= X-OriginalArrivalTime: 06 Dec 2005 23:24:53.0782 (UTC) FILETIME=[432E2360:01C5FABC] X-WSS-ID: 6F88C24548G9308121-01-01 Content-Type: text/plain; charset=iso-8859-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: 9623 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: mason@broadcom.com Precedence: bulk X-list: linux-mips Hello, Jim Gifford wrote: > How many machines are affected by multiple pci busses. I can only > thing of the Origin systems. Couldn't we get a base iomap.c in and add > one's specific to the multiple bus machines? Any system based on BCM1480s could have multiple pci busses (one PCI-X directly, and additional busses through HT/PCI-X bridges). For the BCM91480B board, we had to turn on PCI_DOMAINS to get this to work correctly. /Mark From Mile.Davidovic@micronasnit.com Wed Dec 7 11:11:26 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 07 Dec 2005 11:13:47 +0000 (GMT) Received: from krt.tmd.ns.ac.yu ([147.91.177.65]:16267 "EHLO krt.neobee.net") by ftp.linux-mips.org with ESMTP id S8133413AbVLGLL0 (ORCPT ); Wed, 7 Dec 2005 11:11:26 +0000 Received: from localhost (localhost [127.0.0.1]) by krt.neobee.net (8.12.7/8.12.7/SuSE Linux 0.6) with ESMTP id jB7CSfuI003385 for ; Wed, 7 Dec 2005 13:28:41 +0100 Received: from krt.neobee.net ([127.0.0.1]) by localhost (krt.neobee.net [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 03262-01 for ; Wed, 7 Dec 2005 13:28:41 +0100 (CET) Received: from had ([192.168.0.89]) by krt.neobee.net (8.12.7/8.12.7/SuSE Linux 0.6) with ESMTP id jB7CSdti003380 for ; Wed, 7 Dec 2005 13:28:40 +0100 Reply-To: From: "Mile Davidovic" To: Subject: List symbols from object files Date: Wed, 7 Dec 2005 12:11:04 +0100 Organization: MicronasNIT Message-ID: <001701c5fb1e$ea5e33c0$5900a8c0@niit.micronasnit.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 Thread-Index: AcX7HugZYIpsBZpnQ+ClTHjv6CrQ5Q== X-Virus-Scanned: by amavisd-new at krt.neobee.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: 9624 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: Mile.Davidovic@micronasnit.com Precedence: bulk X-list: linux-mips Hello all I am not shure that this question is for this list, if I made mistake, I am so sorry. My question is about usage of mips-linux-nm on Linux kernel with debugging information. mips-linux-nm -la vmlinux does not show line number information. Is this expected bahavioure or I am missing something? This is part of my .config file: 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_PREEMPT=y # CONFIG_DEBUG_SPINLOCK is not set # CONFIG_DEBUG_SPINLOCK_SLEEP is not set # CONFIG_DEBUG_KOBJECT is not set CONFIG_DEBUG_INFO=y # 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=y # CONFIG_MIPS_UNCACHED is not set Best regards Mile From scott.ashcroft@talk21.com Wed Dec 7 17:46:16 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 07 Dec 2005 17:46:34 +0000 (GMT) Received: from web86306.mail.ukl.yahoo.com ([217.12.12.65]:26015 "HELO web86306.mail.ukl.yahoo.com") by ftp.linux-mips.org with SMTP id S8133530AbVLGRqQ (ORCPT ); Wed, 7 Dec 2005 17:46:16 +0000 Received: (qmail 32142 invoked by uid 60001); 7 Dec 2005 17:45:59 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=talk21.com; h=Message-ID:Received:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=f8w8oUgJ1MajttCnuZg+zwt+IDANK9gKrn6VMmPuS8CAINAfP6yRf7peqX4SZ0VSpMw4L90BCx9eg3C1ZIPcaPe4Mc/DHS8fTFs2VqDTnf5xdTRkX3PihJyZk9z3K8CaVEhLVMr/kNurE7KoltvUYgT3V/AYH144yAk+dxJLyxY= ; Message-ID: <20051207174559.32140.qmail@web86306.mail.ukl.yahoo.com> Received: from [132.146.82.240] by web86306.mail.ukl.yahoo.com via HTTP; Wed, 07 Dec 2005 17:45:59 GMT Date: Wed, 7 Dec 2005 17:45:59 +0000 (GMT) From: Scott Ashcroft Subject: Re: pci_iomap issues? To: Mark Mason Cc: Scott Ashcroft , linux-mips@linux-mips.org In-Reply-To: <43961DC1.80405@broadcom.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: 9625 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: scott.ashcroft@talk21.com Precedence: bulk X-list: linux-mips --- Mark Mason wrote: > > Any system based on BCM1480s could have multiple pci > busses (one PCI-X > directly, and additional busses through HT/PCI-X > bridges). For the > BCM91480B board, we had to turn on PCI_DOMAINS to > get this to work > correctly. I understand that there are machines with multiple PCI busses out there but comparing the ppc64 code with the proposed mips patches I don't see much difference. Are the ppc64 people just breaking multiple PCI bus machines, did something happen in the generic PCI code which fixed the issue or is there just a difference I can't see? Cheers, Scott From vbarinov@ru.mvista.com Wed Dec 7 19:05:48 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 07 Dec 2005 19:06:05 +0000 (GMT) Received: from rtsoft3.corbina.net ([85.21.88.6]:40256 "EHLO buildserver.ru.mvista.com") by ftp.linux-mips.org with ESMTP id S8133544AbVLGTFs (ORCPT ); Wed, 7 Dec 2005 19:05:48 +0000 Received: from [192.168.12.17] ([10.149.0.1]) by buildserver.ru.mvista.com (8.11.6/8.11.6) with ESMTP id jB7J5Rt25833; Wed, 7 Dec 2005 23:05:28 +0400 Message-ID: <43973277.6070301@ru.mvista.com> Date: Wed, 07 Dec 2005 22:05:27 +0300 From: "Vladimir A. Barinov" User-Agent: Mozilla Thunderbird 1.0.2-6 (X11/20050513) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Peter Popov CC: ralf@linux-mips.org, linux-mips@linux-mips.org Subject: Re: [PATCH] Philips PNX8550 References: <20051206202625.77199.qmail@web405.biz.mail.mud.yahoo.com> In-Reply-To: <20051206202625.77199.qmail@web405.biz.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: 9626 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: vbarinov@ru.mvista.com Precedence: bulk X-list: linux-mips Hi Pete, Peter Popov wrote: >Hi Vladimir, > >Is this really for the JBS board or for a different >board? > > Thank you for the response. I used a quite different board (STB810), but it's based on the same board dependent code as JBS (i.e arch/mips/philips/pnx8550/jbs). I haven't worked with JBS board and I'm not sure if slot=10 is needed for that, but it's really necessary for STB810. I also has another question - Could you please advice: shall I create a different arch/mips/philips/pnx8550/stb810 and add MACH_PHILIPS_STB810 ID and defconfig or I can use exiting JBS one? TIA, Vladimir >Pete > >--- "Vladimir A. Barinov" >wrote: > > > >>Hi Ralf, Pete, >> >>This patch enables NATSEMI eth driver to be used on >>pci bus. >> >>Does it make sense to push this patch? >> >>Vladimir >> >> >>>--- >>> >>> >linux-2.6.15.orig/arch/mips/philips/pnx8550/jbs/irqmap.c > > >>2005-12-02 16:37:59.000000000 +0300 >>+++ >>linux-2.6.15/arch/mips/philips/pnx8550/jbs/irqmap.c >>2005-12-02 17:33:05.000000000 +0300 >>@@ -31,6 +31,7 @@ >> char irq_tab_jbs[][5] __initdata = { >> [8] = { -1, PNX8550_INT_PCI_INTA, 0xff, 0xff, >>0xff}, >> [9] = { -1, PNX8550_INT_PCI_INTA, 0xff, 0xff, >>0xff}, >>+ [10] = { -1, PNX8550_INT_PCI_INTA, 0xff, 0xff, >>0xff}, >> [17] = { -1, PNX8550_INT_PCI_INTA, 0xff, 0xff, >>0xff}, >> }; >> >> >> >> > > > > From ppopov@embeddedalley.com Wed Dec 7 19:11:18 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 07 Dec 2005 19:11:38 +0000 (GMT) Received: from web410.biz.mail.mud.yahoo.com ([68.142.201.41]:48047 "HELO web410.biz.mail.mud.yahoo.com") by ftp.linux-mips.org with SMTP id S8133560AbVLGTLS (ORCPT ); Wed, 7 Dec 2005 19:11:18 +0000 Received: (qmail 20650 invoked by uid 60001); 7 Dec 2005 19:11:00 -0000 Message-ID: <20051207191100.20648.qmail@web410.biz.mail.mud.yahoo.com> Received: from [64.163.129.139] by web410.biz.mail.mud.yahoo.com via HTTP; Wed, 07 Dec 2005 11:11:00 PST Date: Wed, 7 Dec 2005 11:11:00 -0800 (PST) From: Peter Popov Subject: Re: [PATCH] Philips PNX8550 To: "Vladimir A. Barinov" Cc: ralf@linux-mips.org, linux-mips@linux-mips.org In-Reply-To: <43973277.6070301@ru.mvista.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: 9627 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 > I used a quite different board (STB810), but it's > based on the same board dependent code as JBS (i.e > arch/mips/philips/pnx8550/jbs). I haven't > worked with > JBS board and I'm not sure if slot=10 is needed for > that, but it's really necessary for STB810. The JBS has only 3 pci slots and I tested all three. So the fourth one you added won't do any damage but it's not quite right either. > I also has another question - Could you please > advice: shall I create a different > arch/mips/philips/pnx8550/stb810 > and add MACH_PHILIPS_STB810 ID and defconfig > or I can use exiting JBS one? Is anything else different that would justify the new directory? If not, perhaps we just need an STB board selection in arch/mips/Kconfig, a defconfig, and an ifdef around that pci slot you sent. BTW, regarding your serial driver patch ... I have one outstanding change (small) I still have to make, as requested by rmk. Mind if I forward that email to you so you can take care of it :)? Pete Pete From vbarinov@ru.mvista.com Wed Dec 7 19:40:14 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 07 Dec 2005 19:40:34 +0000 (GMT) Received: from rtsoft3.corbina.net ([85.21.88.6]:62016 "EHLO buildserver.ru.mvista.com") by ftp.linux-mips.org with ESMTP id S8133554AbVLGTkO (ORCPT ); Wed, 7 Dec 2005 19:40:14 +0000 Received: from [192.168.12.17] ([10.149.0.1]) by buildserver.ru.mvista.com (8.11.6/8.11.6) with ESMTP id jB7Jdnt27284; Wed, 7 Dec 2005 23:39:50 +0400 Message-ID: <43973A84.3090306@ru.mvista.com> Date: Wed, 07 Dec 2005 22:39:48 +0300 From: "Vladimir A. Barinov" User-Agent: Mozilla Thunderbird 1.0.2-6 (X11/20050513) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Peter Popov CC: ralf@linux-mips.org, linux-mips@linux-mips.org Subject: Re: [PATCH] Philips PNX8550 References: <20051207191100.20648.qmail@web410.biz.mail.mud.yahoo.com> In-Reply-To: <20051207191100.20648.qmail@web410.biz.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: 9628 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: vbarinov@ru.mvista.com Precedence: bulk X-list: linux-mips Hi Pete, > > >>I used a quite different board (STB810), but it's >>based on the same board dependent code as JBS (i.e >>arch/mips/philips/pnx8550/jbs). I haven't >>worked with >>JBS board and I'm not sure if slot=10 is needed for >>that, but it's really necessary for STB810. >> >> > >The JBS has only 3 pci slots and I tested all three. >So the fourth one you added won't do any damage but >it's not quite right either. > > > >>I also has another question - Could you please >>advice: shall I create a different >>arch/mips/philips/pnx8550/stb810 >>and add MACH_PHILIPS_STB810 ID and defconfig >>or I can use exiting JBS one? >> >> > >Is anything else different that would justify the new >directory? If not, perhaps we just need an STB board >selection in arch/mips/Kconfig, a defconfig, and an >ifdef around that pci slot you sent. > > The are only 3 small file in the arch/mips/philips/pnx8550/jbs directory: 1) board_setup.c is the same for STB810 2) init.c may be needs cosmetic changes to identify the board: "Philips PNX8550/JBS" -> "Philips PNX8550/STB810" MACH_PHILIPS_JBS -> MACH_PHILIPS_STB810 I'm not sure are they really needed? 3) irq.map needs change to add slot 10 and remove slot 17 for STB810 board. That's all :) >BTW, regarding your serial driver patch ... I have one >outstanding change (small) I still have to make, as >requested by rmk. Mind if I forward that email to you >so you can take care of it :)? > > Yes, please. Vladimir From vbarinov@ru.mvista.com Wed Dec 7 19:44:57 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 07 Dec 2005 19:45:14 +0000 (GMT) Received: from rtsoft3.corbina.net ([85.21.88.6]:63552 "EHLO buildserver.ru.mvista.com") by ftp.linux-mips.org with ESMTP id S8133554AbVLGTo4 (ORCPT ); Wed, 7 Dec 2005 19:44:56 +0000 Received: from [192.168.12.17] ([10.149.0.1]) by buildserver.ru.mvista.com (8.11.6/8.11.6) with ESMTP id jB7JiYt27362; Wed, 7 Dec 2005 23:44:34 +0400 Message-ID: <43973BA2.1030607@ru.mvista.com> Date: Wed, 07 Dec 2005 22:44:34 +0300 From: "Vladimir A. Barinov" User-Agent: Mozilla Thunderbird 1.0.2-6 (X11/20050513) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Vladimir A. Barinov" CC: Peter Popov , ralf@linux-mips.org, linux-mips@linux-mips.org Subject: Re: [PATCH] Philips PNX8550 References: <20051207191100.20648.qmail@web410.biz.mail.mud.yahoo.com> <43973A84.3090306@ru.mvista.com> In-Reply-To: <43973A84.3090306@ru.mvista.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: 9629 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: vbarinov@ru.mvista.com Precedence: bulk X-list: linux-mips >> BTW, regarding your serial driver patch ... I have one >> outstanding change (small) I still have to make, as >> requested by rmk. Mind if I forward that email to you >> so you can take care of it :)? >> >> > Yes, please. i.e.: please forward it to me :) From marck@ivivity.com Wed Dec 7 21:49:28 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 07 Dec 2005 21:49:47 +0000 (GMT) Received: from mail.ivivity.com ([64.238.111.98]:53219 "EHLO thoth.ivivity.com") by ftp.linux-mips.org with ESMTP id S8133723AbVLGVt2 convert rfc822-to-8bit (ORCPT ); Wed, 7 Dec 2005 21:49:28 +0000 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: pci_iomap issues? Date: Wed, 7 Dec 2005 16:49:09 -0500 Message-ID: <0F31272A2BCBBE4FA01344C6E69DBF501EAACE@thoth.ivivity.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: pci_iomap issues? Thread-Index: AcX7Vj52JPN4FMGVTq69MT//Y0p1EAAIJlxQ From: "Marc Karasek" To: "Scott Ashcroft" , "Mark Mason" Cc: 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: 9630 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: marck@ivivity.com Precedence: bulk X-list: linux-mips By multiple buses do you mean physical buses off of the CPU/companion chip or one PCI bus then a bridge chip then next PCI Bus, and so on.. If it is the latter, then the code should be able to automatically take care of it. The boot code should have already scanned the bus and annotated all of the buses. The basic procedure is to start at bus 0, find the first bridge, look past this bridge, find next one, until you find the last bridge. At this point you backtrack and setup each bridge (primary, secondary #'s, etc.). Thne you go out and do config cycles to find out what devices are available and map them into the address space. When Linux comes up it should do something similar, minus the setup to find out how many buses it has, and then how many devices it has. The difference would be if linux finds a device it just reads the BARs to find out where it is mapped. If it is the former, then this should be a chip specific operation where Linux would scan again but needs to know to scan on multiple interfaces/PCI buses. The boot code should also be aware of this situation and map things appropriately. Any content within this email is provided "AS IS" for informational purposes only. No contract will be formed between the parties by virtue of this email. <**************************> Marc Karasek System Lead Technical Engineer iVivity Inc. PH: 678-990-1550 x238 Fax: 678-990-1551 <**************************> -----Original Message----- From: linux-mips-bounce@linux-mips.org [mailto:linux-mips-bounce@linux-mips.org]On Behalf Of Scott Ashcroft Sent: Wednesday, December 07, 2005 12:46 PM To: Mark Mason Cc: Scott Ashcroft; linux-mips@linux-mips.org Subject: Re: pci_iomap issues? --- Mark Mason wrote: > > Any system based on BCM1480s could have multiple pci > busses (one PCI-X > directly, and additional busses through HT/PCI-X > bridges). For the > BCM91480B board, we had to turn on PCI_DOMAINS to > get this to work > correctly. I understand that there are machines with multiple PCI busses out there but comparing the ppc64 code with the proposed mips patches I don't see much difference. Are the ppc64 people just breaking multiple PCI bus machines, did something happen in the generic PCI code which fixed the issue or is there just a difference I can't see? Cheers, Scott From clem.taylor@gmail.com Wed Dec 7 21:51:35 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 07 Dec 2005 21:51:53 +0000 (GMT) Received: from xproxy.gmail.com ([66.249.82.205]:12899 "EHLO xproxy.gmail.com") by ftp.linux-mips.org with ESMTP id S8133595AbVLGVvf (ORCPT ); Wed, 7 Dec 2005 21:51:35 +0000 Received: by xproxy.gmail.com with SMTP id s18so317582wxc for ; Wed, 07 Dec 2005 13:51:24 -0800 (PST) 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; b=kJUT7fgy6QL+o0K/uSR0FNLHMlmT3Mfvsmfc41BwUGSfypLzPZgmgZ8rB8Mc65c7Pz4urbVQRe0bnNuJVOW3HshhI7dYw4fUJ2ezq/QKALLnfdH+4l6anJ+lRMTc3eE8M6ONcd2IpjPnD6falo8atHEdGO9AyfeX5p9ViNs0lwo= Received: by 10.70.33.1 with SMTP id g1mr2763615wxg; Wed, 07 Dec 2005 13:51:23 -0800 (PST) Received: by 10.70.30.10 with HTTP; Wed, 7 Dec 2005 13:51:23 -0800 (PST) Message-ID: Date: Wed, 7 Dec 2005 16:51:23 -0500 From: Clem Taylor To: linux-mips Subject: can read/write to mprotect(PROT_NONE) region with 2.6.14 on au1550 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_5886_18805544.1133992283905" 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: 9631 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: clem.taylor@gmail.com Precedence: bulk X-list: linux-mips ------=_Part_5886_18805544.1133992283905 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi, I was trying to use mprotect(PROT_NONE) to help debug a problem, and it seems that mprotect() isn't actually doing anything with my 2.6.14 linux-mips kernel on an au1550. Attached is a simple test program that segfaults as expected on x86 (2.6.12), but does not segfault on mips (2.6.14). I can both read and write PROT_NONE memory without problem, which should result in a segfault. Originally, I was trying to mprotect() a mmaped GFP_DMA region which wasn't working and then I tried a simpler test that also wasn't working. Shouldn't mprotect() work? Could I be missing a config option, or is this just broken? Thanks, Clem Taylor ------=_Part_5886_18805544.1133992283905 Content-Type: text/x-csrc; name=mprotectTest.c; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="mprotectTest.c" #include #include #include #include #include #include int main ( int argc, char *argv [ ] ) { int size = 65536, i, ret; unsigned char *buffer; buffer = memalign ( size, size ); if ( buffer == NULL ) { fprintf ( stderr, "memalign() failed.\n" ); return 1; } fprintf ( stderr, "buffer=%p size=%d\n", buffer, size ); /* write and read buffer */ memset ( buffer, 0xAA, size ); for ( i = 0; i < 2; i++ ) fprintf ( stderr, "buffer [ %d ] = 0x%02X\n", i, buffer [ i ] ); /* disable reading and writing */ ret = mprotect ( buffer, size, PROT_NONE ); if ( ret != 0 ) { fprintf ( stderr, "mprotect(%p,%d,PROT_NONE) failed: %s\n", buffer, size, strerror ( errno ) ); return 1; } /* write and read buffer, should segfault */ memset ( buffer, 0x55, size ); for ( i = 0; i < 2; i++ ) fprintf ( stderr, "buffer [ %d ] = 0x%02X\n", i, buffer [ i ] ); return 0; } ------=_Part_5886_18805544.1133992283905-- From vbarinov@ru.mvista.com Thu Dec 8 16:52:19 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 08 Dec 2005 16:52:39 +0000 (GMT) Received: from rtsoft3.corbina.net ([85.21.88.6]:13640 "EHLO buildserver.ru.mvista.com") by ftp.linux-mips.org with ESMTP id S8133900AbVLHQwT (ORCPT ); Thu, 8 Dec 2005 16:52:19 +0000 Received: from [192.168.12.17] ([10.149.0.1]) by buildserver.ru.mvista.com (8.11.6/8.11.6) with ESMTP id jB8Gpot26925; Thu, 8 Dec 2005 20:51:51 +0400 Message-ID: <439864A6.9070104@ru.mvista.com> Date: Thu, 08 Dec 2005 19:51:50 +0300 From: "Vladimir A. Barinov" User-Agent: Mozilla Thunderbird 1.0.2-6 (X11/20050513) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Peter Popov , David Brownell CC: linux-mips@linux-mips.org, ralf@linux-mips.org, linux-usb-devel@lists.sourceforge.net Subject: Re: [PATCH] Philips PNX8550 USB Host driver compile fix References: <20051206193522.2582.qmail@web411.biz.mail.mud.yahoo.com> In-Reply-To: <20051206193522.2582.qmail@web411.biz.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: 9632 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: vbarinov@ru.mvista.com Precedence: bulk X-list: linux-mips Hello Ralf, David, Could you please advise. What is the right solution in the situation when USB PCI and on-chip USB used in the situation when we want ohci-hcd to be a module? Vladimir Peter Popov wrote: >I suppose the right solution is to be able to use the >on-chip usb controller as well as an external pci >controller. I don't think anyone will do that though. >I have one board with an external USB controller but >that was done in order to add usb 2.0 support, so the >on-chip usb controller is not used. So the simple fix >below works fine for me, but Ralf and David B. may >have higher standards ;) > >Pete > >--- "Vladimir A. Barinov" >wrote: > > > >>Hello, Ralf, Pete, >> >>The current ohci-hcd driver is a little defective. >>It's unable to use usb-ohci as modules in the case >>when PCI and on-chip >>USB are enabled. >>It just will not be compiled since there are two >>calls if module_init in >>ohci-hcd. >> >>Please look at the patch attached. >>I 'm not sure is this patch well for this situation. >>Any suggestions are very appreciated. >> >>TIA, >>Vladimir >> >> >> >> >>>--- linux-2.6.10.orig/drivers/usb/host/ohci-hcd.c >>> >>> >>2005-12-02 16:37:59.000000000 +0300 >>+++ linux-2.6.10/drivers/usb/host/ohci-hcd.c >>2005-12-02 19:34:21.000000000 +0300 >>@@ -906,8 +906,12 @@ MODULE_LICENSE ("GPL"); >> #endif >> >> #ifdef CONFIG_PNX8550 >>+#if defined(CONFIG_PCI) && >>defined(CONFIG_USB_OHCI_HCD_MODULE) >>+#error "unable to compile PNX8550 USB and PCI USB >>as modules simultaneously until usb hcd stack is >>rewritten" >>+#else >> #include "ohci-pnx8550.c" >> #endif >>+#endif >> >> #ifdef CONFIG_USB_OHCI_HCD_PPC_SOC >> #include "ohci-ppc-soc.c" >>@@ -919,6 +923,7 @@ MODULE_LICENSE ("GPL"); >> || defined (CONFIG_ARCH_LH7A404) \ >> || defined (CONFIG_PXA27x) \ >> || defined (CONFIG_SOC_AU1X00) \ >>+ || defined (CONFIG_PNX8550) \ >> || defined (CONFIG_USB_OHCI_HCD_PPC_SOC) \ >> ) >> #error "missing bus glue for ohci-hcd" >> >> >> > > > > From vbarinov@ru.mvista.com Thu Dec 8 17:02:34 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 08 Dec 2005 17:02:54 +0000 (GMT) Received: from rtsoft3.corbina.net ([85.21.88.6]:22088 "EHLO buildserver.ru.mvista.com") by ftp.linux-mips.org with ESMTP id S8133964AbVLHRCe (ORCPT ); Thu, 8 Dec 2005 17:02:34 +0000 Received: from [192.168.12.17] ([10.149.0.1]) by buildserver.ru.mvista.com (8.11.6/8.11.6) with ESMTP id jB8H2Ct27576; Thu, 8 Dec 2005 21:02:13 +0400 Message-ID: <43986714.2020806@ru.mvista.com> Date: Thu, 08 Dec 2005 20:02:12 +0300 From: "Vladimir A. Barinov" User-Agent: Mozilla Thunderbird 1.0.2-6 (X11/20050513) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Peter Popov CC: Ralf Baechle , "'linux-mips@linux-mips.org'" Subject: Re: [PATCH] Philips PNX8550 command line patch References: <20051206192105.32325.qmail@web403.biz.mail.mud.yahoo.com> In-Reply-To: <20051206192105.32325.qmail@web403.biz.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: 9633 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: vbarinov@ru.mvista.com Precedence: bulk X-list: linux-mips Hello Pete, Ralf, Peter Popov wrote: >--- Ralf Baechle wrote: > > > >>On Tue, Dec 06, 2005 at 09:02:14PM +0300, Vladimir >>A. Barinov wrote: >> >> >> >>>This patch makes passing command line from >>> >>> >>bootloader for Philips >> >> >>>PNX8550 platform. >>>Does it makes sense to commit this patch? >>> >>> >>Looks ok at a quick glance. I'll wait a bit so Pete >>has a chance to comment. >> >> > >Looks fine to me. > > Sorry for my misunderstood but I suppose that this patch should be ignored since it used JBS board dependent code and I have STB810 that based on the code of JBS. But JBS board could have firmware that differs from that STB810 uses. So the command line could be parsed incorrectly for JBS, it's needed to check by somebody who has JBS board. I prepared STB810 board dependent patch that include this fix for command-line parsing for STB810 board only. So Ralf please ignore this patch though it was approved by you and Pete. Vladimir From vbarinov@ru.mvista.com Thu Dec 8 17:20:59 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 08 Dec 2005 17:21:28 +0000 (GMT) Received: from rtsoft3.corbina.net ([85.21.88.6]:30024 "EHLO buildserver.ru.mvista.com") by ftp.linux-mips.org with ESMTP id S8133969AbVLHRU7 (ORCPT ); Thu, 8 Dec 2005 17:20:59 +0000 Received: from [192.168.12.17] ([10.149.0.1]) by buildserver.ru.mvista.com (8.11.6/8.11.6) with ESMTP id jB8HKft27987; Thu, 8 Dec 2005 21:20:41 +0400 Message-ID: <43986B68.4000309@ru.mvista.com> Date: Thu, 08 Dec 2005 20:20:40 +0300 From: "Vladimir A. Barinov" User-Agent: Mozilla Thunderbird 1.0.2-6 (X11/20050513) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Peter Popov , ralf@linux-mips.org CC: "Vladimir A. Barinov" , linux-mips@linux-mips.org Subject: Re: [PATCH] Philips PNX8550 References: <20051207191100.20648.qmail@web410.biz.mail.mud.yahoo.com> <43973A84.3090306@ru.mvista.com> In-Reply-To: <43973A84.3090306@ru.mvista.com> Content-Type: multipart/mixed; boundary="------------090706010406070506020107" 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: 9634 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: vbarinov@ru.mvista.com Precedence: bulk X-list: linux-mips This is a multi-part message in MIME format. --------------090706010406070506020107 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hello Pete, Ralf, This patch adds support for STB810 board based on Philips PNX8550 processor. 1) added arch/mips/philips/pnx8550/stb810/* files based on the arch/mips/philips/pnx8550/jbs/* 2) modified Kconfig and Makefile in arch/mips/ 3) added new board ID in bootinfo.h to identify STB810 board 4) added pnx8550-stb810_defconfig 5) STB810 platform has a special bootloader "PNX8550 bootlader" that does not have ELF loader, so it's needed to point to the kernel_entry. (modified arch_mips/kernel/head.S) 6) arch/mips/philips/pnx8550/common/platform.c - compile fix 7) arch/mips/philips/pnx8550/common/prom.c - fix for proper parsing bootloader command-line. Pete could you please review? TIA, Vladimir Vladimir A. Barinov wrote: > Hi Pete, > >> >> >>> I used a quite different board (STB810), but it's >>> based on the same board dependent code as JBS (i.e >>> arch/mips/philips/pnx8550/jbs). I haven't worked with >>> JBS board and I'm not sure if slot=10 is needed for >>> that, but it's really necessary for STB810. >>> >> >> >> The JBS has only 3 pci slots and I tested all three. >> So the fourth one you added won't do any damage but >> it's not quite right either. >> >> >>> I also has another question - Could you please >>> advice: shall I create a different >>> arch/mips/philips/pnx8550/stb810 >>> and add MACH_PHILIPS_STB810 ID and defconfig >>> or I can use exiting JBS one? >>> >> >> >> Is anything else different that would justify the new >> directory? If not, perhaps we just need an STB board >> selection in arch/mips/Kconfig, a defconfig, and an >> ifdef around that pci slot you sent. >> >> > The are only 3 small file in the arch/mips/philips/pnx8550/jbs > directory: > 1) board_setup.c is the same for STB810 > 2) init.c may be needs cosmetic changes to identify the board: > "Philips PNX8550/JBS" -> "Philips PNX8550/STB810" > MACH_PHILIPS_JBS -> MACH_PHILIPS_STB810 > > I'm not sure are they really needed? > 3) irq.map needs change to add slot 10 and remove slot 17 for STB810 > board. > > That's all :) > > --------------090706010406070506020107 Content-Type: text/plain; name="stb810.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="stb810.patch" arch/mips/Kconfig | 5 arch/mips/Makefile | 5 arch/mips/configs/pnx8550-stb810_defconfig | 1117 +++++++++++++++++++++++++ arch/mips/kernel/head.S | 2 arch/mips/philips/pnx8550/common/platform.c | 1 arch/mips/philips/pnx8550/common/prom.c | 20 arch/mips/philips/pnx8550/stb810/Makefile | 4 arch/mips/philips/pnx8550/stb810/board_setup.c | 56 + arch/mips/philips/pnx8550/stb810/irqmap.c | 23 arch/mips/philips/pnx8550/stb810/prom_init.c | 49 + include/asm-mips/bootinfo.h | 1 11 files changed, 1268 insertions(+), 15 deletions(-) Index: linux-2.6.15_0/arch/mips/Kconfig =================================================================== --- linux-2.6.15_0.orig/arch/mips/Kconfig +++ linux-2.6.15_0/arch/mips/Kconfig @@ -445,6 +445,11 @@ config PNX8550_JBS select PNX8550 select SYS_SUPPORTS_LITTLE_ENDIAN +config PNX8550_STB810 + bool "Support for Philips PNX8550 based STB810 board" + select PNX8550 + select SYS_SUPPORTS_LITTLE_ENDIAN + config DDB5074 bool "Support for NEC DDB Vrc-5074 (EXPERIMENTAL)" depends on EXPERIMENTAL Index: linux-2.6.15_0/arch/mips/Makefile =================================================================== --- linux-2.6.15_0.orig/arch/mips/Makefile +++ linux-2.6.15_0/arch/mips/Makefile @@ -583,6 +583,11 @@ libs-$(CONFIG_PNX8550_JBS) += arch/mips/ #cflags-$(CONFIG_PNX8550_JBS) += -Iinclude/asm-mips/mach-pnx8550 load-$(CONFIG_PNX8550_JBS) += 0xffffffff80060000 +# Philips PNX8550 STB810 board +# +libs-$(CONFIG_PNX8550_STB810) += arch/mips/philips/pnx8550/stb810/ +load-$(CONFIG_PNX8550_STB810) += 0xffffffff80060000 + # # SGI IP22 (Indy/Indigo2) # Index: linux-2.6.15_0/arch/mips/philips/pnx8550/stb810/Makefile =================================================================== --- /dev/null +++ linux-2.6.15_0/arch/mips/philips/pnx8550/stb810/Makefile @@ -0,0 +1,4 @@ + +# Makefile for the Philips STB810 Board. + +lib-y := prom_init.o board_setup.o irqmap.o Index: linux-2.6.15_0/arch/mips/philips/pnx8550/stb810/board_setup.c =================================================================== --- /dev/null +++ linux-2.6.15_0/arch/mips/philips/pnx8550/stb810/board_setup.c @@ -0,0 +1,56 @@ +/* + * STB810 specific board startup routines. + * + * Based on the arch/mips/philips/pnx8550/jbs/board_setup.c + * + * Author: MontaVista Software, Inc. + * source@mvista.com + * + * Copyright 2005 MontaVista Software 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. + */ + +#include +#include +#include +#include +#include +#include +#include + +#include +#include +#include +#include +#include +#include + +#include + +/* CP0 hazard avoidance. */ +#define BARRIER __asm__ __volatile__(".set noreorder\n\t" \ + "nop; nop; nop; nop; nop; nop;\n\t" \ + ".set reorder\n\t") + +void __init board_setup(void) +{ + unsigned long config0, configpr; + + config0 = read_c0_config(); + + /* clear all three cache coherency fields */ + config0 &= ~(0x7 | (7<<25) | (7<<28)); + config0 |= (CONF_CM_DEFAULT | (CONF_CM_DEFAULT<<25) | + (CONF_CM_DEFAULT<<28)); + write_c0_config(config0); + BARRIER; + + configpr = read_c0_config7(); + configpr |= (1<<19); /* enable tlb */ + write_c0_config7(configpr); + BARRIER; +} Index: linux-2.6.15_0/arch/mips/philips/pnx8550/stb810/irqmap.c =================================================================== --- /dev/null +++ linux-2.6.15_0/arch/mips/philips/pnx8550/stb810/irqmap.c @@ -0,0 +1,23 @@ +/* + * Philips STB810 board irqmap. + * + * Author: MontaVista Software, Inc. + * source@mvista.com + * + * Copyright 2005 MontaVista Software 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. + */ + +#include +#include + +char irq_tab_jbs[][5] __initdata = { + [8] = { -1, PNX8550_INT_PCI_INTA, 0xff, 0xff, 0xff}, + [9] = { -1, PNX8550_INT_PCI_INTA, 0xff, 0xff, 0xff}, + [10] = { -1, PNX8550_INT_PCI_INTA, 0xff, 0xff, 0xff}, +}; + Index: linux-2.6.15_0/arch/mips/philips/pnx8550/stb810/prom_init.c =================================================================== --- /dev/null +++ linux-2.6.15_0/arch/mips/philips/pnx8550/stb810/prom_init.c @@ -0,0 +1,49 @@ +/* + * STB810 specific prom routines + * + * Author: MontaVista Software, Inc. + * source@mvista.com + * + * Copyright 2005 MontaVista Software 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. + */ + +#include +#include +#include +#include +#include +#include +#include +#include + +int prom_argc; +char **prom_argv, **prom_envp; +extern void __init prom_init_cmdline(void); +extern char *prom_getenv(char *envname); + +const char *get_system_type(void) +{ + return "Philips PNX8550/STB810"; +} + +void __init prom_init(void) +{ + + unsigned long memsize; + prom_argc = (int) fw_arg0; + prom_argv = (char **) fw_arg1; + prom_envp = (char **) fw_arg2; + + prom_init_cmdline(); + + mips_machgroup = MACH_GROUP_PHILIPS; + mips_machtype = MACH_PHILIPS_STB810; + + memsize = 0x08000000; /* Trimedia uses memory above */ + add_memory_region(0, memsize, BOOT_MEM_RAM); +} Index: linux-2.6.15_0/include/asm-mips/bootinfo.h =================================================================== --- linux-2.6.15_0.orig/include/asm-mips/bootinfo.h +++ linux-2.6.15_0/include/asm-mips/bootinfo.h @@ -138,6 +138,7 @@ #define MACH_PHILIPS_NINO 0 /* Nino */ #define MACH_PHILIPS_VELO 1 /* Velo */ #define MACH_PHILIPS_JBS 2 /* JBS */ +#define MACH_PHILIPS_STB810 3 /* STB810 */ /* * Valid machtype for group Globespan Index: linux-2.6.15_0/arch/mips/philips/pnx8550/common/platform.c =================================================================== --- linux-2.6.15_0.orig/arch/mips/philips/pnx8550/common/platform.c +++ linux-2.6.15_0/arch/mips/philips/pnx8550/common/platform.c @@ -18,6 +18,7 @@ #include #include #include +#include #include #include Index: linux-2.6.15_0/arch/mips/philips/pnx8550/common/prom.c =================================================================== --- linux-2.6.15_0.orig/arch/mips/philips/pnx8550/common/prom.c +++ linux-2.6.15_0/arch/mips/philips/pnx8550/common/prom.c @@ -35,23 +35,15 @@ char * prom_getcmdline(void) return &(arcs_cmdline[0]); } -void prom_init_cmdline(void) +void __init prom_init_cmdline(void) { - char *cp; - int actr; - - actr = 1; /* Always ignore argv[0] */ + int i; - cp = &(arcs_cmdline[0]); - while(actr < prom_argc) { - strcpy(cp, prom_argv[actr]); - cp += strlen(prom_argv[actr]); - *cp++ = ' '; - actr++; + arcs_cmdline[0] = '\0'; + for (i = 0; i < prom_argc; i++) { + strcat(arcs_cmdline, prom_argv[i]); + strcat(arcs_cmdline, " "); } - if (cp != &(arcs_cmdline[0])) /* get rid of trailing space */ - --cp; - *cp = '\0'; } char *prom_getenv(char *envname) Index: linux-2.6.15_0/arch/mips/kernel/head.S =================================================================== --- linux-2.6.15_0.orig/arch/mips/kernel/head.S +++ linux-2.6.15_0/arch/mips/kernel/head.S @@ -116,7 +116,7 @@ EXPORT(stext) # used for profiling EXPORT(_stext) -#if defined(CONFIG_QEMU) || defined(CONFIG_MIPS_SIM) +#if defined(CONFIG_QEMU) || defined(CONFIG_MIPS_SIM) || defined(CONFIG_PNX8550_STB810) /* * Give us a fighting chance of running if execution beings at the * kernel load address. This is needed because this platform does Index: linux-2.6.15_0/arch/mips/configs/pnx8550-stb810_defconfig =================================================================== --- /dev/null +++ linux-2.6.15_0/arch/mips/configs/pnx8550-stb810_defconfig @@ -0,0 +1,1117 @@ +# +# Automatically generated make config: don't edit +# Linux kernel version: 2.6.15-rc4 +# Thu Dec 8 19:10:40 2005 +# +CONFIG_MIPS=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_MIPS_SIM 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_PNX8550_V2PCI is not set +# CONFIG_PNX8550_JBS is not set +CONFIG_PNX8550_STB810=y +# CONFIG_DDB5074 is not set +# CONFIG_DDB5476 is not set +# CONFIG_DDB5477 is not set +# CONFIG_MACH_VR41XX is not set +# CONFIG_PMC_YOSEMITE is not set +# CONFIG_QEMU is not set +# CONFIG_SGI_IP22 is not set +# CONFIG_SGI_IP27 is not set +# CONFIG_SGI_IP32 is not set +# CONFIG_SIBYTE_BIGSUR 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_TOSHIBA_RBTX4938 is not set +CONFIG_RWSEM_GENERIC_SPINLOCK=y +CONFIG_GENERIC_CALIBRATE_DELAY=y +CONFIG_DMA_NONCOHERENT=y +CONFIG_DMA_NEED_PCI_MAP_STATE=y +# CONFIG_CPU_BIG_ENDIAN is not set +CONFIG_CPU_LITTLE_ENDIAN=y +CONFIG_SYS_SUPPORTS_LITTLE_ENDIAN=y +CONFIG_PNX8550=y +CONFIG_SOC_PNX8550=y +CONFIG_MIPS_L1_CACHE_SHIFT=5 + +# +# CPU selection +# +CONFIG_CPU_MIPS32_R1=y +# CONFIG_CPU_MIPS32_R2 is not set +# CONFIG_CPU_MIPS64_R1 is not set +# CONFIG_CPU_MIPS64_R2 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 is not set +# CONFIG_CPU_SB1 is not set +CONFIG_SYS_HAS_CPU_MIPS32_R1=y +CONFIG_CPU_MIPS32=y +CONFIG_CPU_MIPSR1=y +CONFIG_SYS_SUPPORTS_32BIT_KERNEL=y +CONFIG_CPU_SUPPORTS_32BIT_KERNEL=y + +# +# Kernel type +# +CONFIG_32BIT=y +# 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_CPU_HAS_PREFETCH=y +# CONFIG_MIPS_MT is not set +# CONFIG_64BIT_PHYS_ADDR is not set +# CONFIG_CPU_ADVANCED is not set +CONFIG_CPU_HAS_LLSC=y +CONFIG_CPU_HAS_SYNC=y +CONFIG_GENERIC_HARDIRQS=y +CONFIG_GENERIC_IRQ_PROBE=y +CONFIG_ARCH_FLATMEM_ENABLE=y +CONFIG_SELECT_MEMORY_MODEL=y +CONFIG_FLATMEM_MANUAL=y +# CONFIG_DISCONTIGMEM_MANUAL is not set +# CONFIG_SPARSEMEM_MANUAL is not set +CONFIG_FLATMEM=y +CONFIG_FLAT_NODE_MEM_MAP=y +# CONFIG_SPARSEMEM_STATIC is not set +CONFIG_SPLIT_PTLOCK_CPUS=4 +CONFIG_PREEMPT_NONE=y +# CONFIG_PREEMPT_VOLUNTARY is not set +# CONFIG_PREEMPT is not set + +# +# Code maturity level options +# +CONFIG_EXPERIMENTAL=y +CONFIG_CLEAN_COMPILE=y +CONFIG_BROKEN_ON_SMP=y +CONFIG_INIT_ENV_ARG_LIMIT=32 + +# +# General setup +# +CONFIG_LOCALVERSION="" +CONFIG_LOCALVERSION_AUTO=y +CONFIG_SWAP=y +CONFIG_SYSVIPC=y +# CONFIG_POSIX_MQUEUE is not set +# 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_INITRAMFS_SOURCE="" +CONFIG_EMBEDDED=y +CONFIG_KALLSYMS=y +# CONFIG_KALLSYMS_ALL is not set +# CONFIG_KALLSYMS_EXTRA_PASS is not set +CONFIG_PRINTK=y +CONFIG_BUG=y +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 is not set +CONFIG_OBSOLETE_MODPARM=y +# CONFIG_MODVERSIONS is not set +# CONFIG_MODULE_SRCVERSION_ALL is not set +CONFIG_KMOD=y + +# +# Block layer +# +# CONFIG_LBD is not set + +# +# IO Schedulers +# +CONFIG_IOSCHED_NOOP=y +CONFIG_IOSCHED_AS=y +CONFIG_IOSCHED_DEADLINE=y +CONFIG_IOSCHED_CFQ=y +CONFIG_DEFAULT_AS=y +# CONFIG_DEFAULT_DEADLINE is not set +# CONFIG_DEFAULT_CFQ is not set +# CONFIG_DEFAULT_NOOP is not set +CONFIG_DEFAULT_IOSCHED="anticipatory" + +# +# Bus options (PCI, PCMCIA, EISA, ISA, TC) +# +CONFIG_HW_HAS_PCI=y +CONFIG_PCI=y +# CONFIG_PCI_LEGACY_PROC is not set +# CONFIG_PCI_DEBUG is not set +CONFIG_MMU=y + +# +# PCCARD (PCMCIA/CardBus) support +# +# CONFIG_PCCARD is not set + +# +# PCI Hotplug Support +# +# CONFIG_HOTPLUG_PCI is not set + +# +# Executable file formats +# +CONFIG_BINFMT_ELF=y +# CONFIG_BINFMT_MISC is not set +CONFIG_TRAD_SIGNALS=y + +# +# Networking +# +CONFIG_NET=y + +# +# Networking options +# +CONFIG_PACKET=y +# CONFIG_PACKET_MMAP is not set +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_FIB_HASH=y +CONFIG_IP_PNP=y +CONFIG_IP_PNP_DHCP=y +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_ARPD 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 is not set +CONFIG_INET_DIAG=y +CONFIG_INET_TCP_DIAG=y +# CONFIG_TCP_CONG_ADVANCED is not set +CONFIG_TCP_CONG_BIC=y +# CONFIG_IPV6 is not set +# CONFIG_NETFILTER is not set + +# +# DCCP Configuration (EXPERIMENTAL) +# +# CONFIG_IP_DCCP is not set + +# +# SCTP Configuration (EXPERIMENTAL) +# +# CONFIG_IP_SCTP is not set +# CONFIG_ATM is not set +# 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 +# CONFIG_X25 is not set +# CONFIG_LAPB is not set +# CONFIG_NET_DIVERT is not set +# CONFIG_ECONET is not set +# CONFIG_WAN_ROUTER is not set + +# +# QoS and/or fair queueing +# +# CONFIG_NET_SCHED is not set + +# +# Network testing +# +# CONFIG_NET_PKTGEN is not set +# CONFIG_HAMRADIO is not set +# CONFIG_IRDA is not set +# CONFIG_BT is not set +# CONFIG_IEEE80211 is not set + +# +# 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 + +# +# Connector - unified userspace <-> kernelspace linker +# +# CONFIG_CONNECTOR 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_CPQ_DA is not set +# CONFIG_BLK_CPQ_CISS_DA is not set +# CONFIG_BLK_DEV_DAC960 is not set +# CONFIG_BLK_DEV_UMEM is not set +# CONFIG_BLK_DEV_COW_COMMON is not set +CONFIG_BLK_DEV_LOOP=y +# CONFIG_BLK_DEV_CRYPTOLOOP is not set +# CONFIG_BLK_DEV_NBD is not set +# CONFIG_BLK_DEV_SX8 is not set +# CONFIG_BLK_DEV_UB is not set +CONFIG_BLK_DEV_RAM=y +CONFIG_BLK_DEV_RAM_COUNT=16 +CONFIG_BLK_DEV_RAM_SIZE=8192 +CONFIG_BLK_DEV_INITRD=y +# CONFIG_CDROM_PKTCDVD is not set +# CONFIG_ATA_OVER_ETH is not set + +# +# ATA/ATAPI/MFM/RLL support +# +CONFIG_IDE=y +CONFIG_BLK_DEV_IDE=y + +# +# Please see Documentation/ide.txt for help/info on IDE drives +# +# CONFIG_BLK_DEV_IDE_SATA is not set +CONFIG_BLK_DEV_IDEDISK=y +# CONFIG_IDEDISK_MULTI_MODE is not set +CONFIG_BLK_DEV_IDECD=m +# CONFIG_BLK_DEV_IDETAPE is not set +# CONFIG_BLK_DEV_IDEFLOPPY is not set +CONFIG_BLK_DEV_IDESCSI=y +# CONFIG_IDE_TASK_IOCTL is not set + +# +# IDE chipset support/bugfixes +# +CONFIG_IDE_GENERIC=y +CONFIG_BLK_DEV_IDEPCI=y +CONFIG_IDEPCI_SHARE_IRQ=y +CONFIG_BLK_DEV_OFFBOARD=y +CONFIG_BLK_DEV_GENERIC=y +# CONFIG_BLK_DEV_OPTI621 is not set +CONFIG_BLK_DEV_IDEDMA_PCI=y +# CONFIG_BLK_DEV_IDEDMA_FORCED is not set +# CONFIG_IDEDMA_PCI_AUTO is not set +# CONFIG_BLK_DEV_AEC62XX is not set +# CONFIG_BLK_DEV_ALI15X3 is not set +# CONFIG_BLK_DEV_AMD74XX is not set +# CONFIG_BLK_DEV_CMD64X is not set +# CONFIG_BLK_DEV_TRIFLEX is not set +# CONFIG_BLK_DEV_CY82C693 is not set +# CONFIG_BLK_DEV_CS5520 is not set +# CONFIG_BLK_DEV_CS5530 is not set +# CONFIG_BLK_DEV_HPT34X is not set +CONFIG_BLK_DEV_HPT366=y +# CONFIG_BLK_DEV_SC1200 is not set +# CONFIG_BLK_DEV_PIIX is not set +# CONFIG_BLK_DEV_IT821X is not set +# CONFIG_BLK_DEV_NS87415 is not set +# CONFIG_BLK_DEV_PDC202XX_OLD is not set +# CONFIG_BLK_DEV_PDC202XX_NEW is not set +# CONFIG_BLK_DEV_SVWKS is not set +# CONFIG_BLK_DEV_SIIMAGE is not set +# CONFIG_BLK_DEV_SLC90E66 is not set +# CONFIG_BLK_DEV_TRM290 is not set +# CONFIG_BLK_DEV_VIA82CXXX is not set +# CONFIG_IDE_ARM is not set +CONFIG_BLK_DEV_IDEDMA=y +# CONFIG_IDEDMA_IVB is not set +# CONFIG_IDEDMA_AUTO is not set +# CONFIG_BLK_DEV_HD is not set + +# +# SCSI device support +# +# CONFIG_RAID_ATTRS is not set +CONFIG_SCSI=y +CONFIG_SCSI_PROC_FS=y + +# +# SCSI support type (disk, tape, CD-ROM) +# +CONFIG_BLK_DEV_SD=y +# CONFIG_CHR_DEV_ST is not set +# CONFIG_CHR_DEV_OSST is not set +# CONFIG_BLK_DEV_SR is not set +# CONFIG_CHR_DEV_SG is not set +# CONFIG_CHR_DEV_SCH is not set + +# +# Some SCSI devices (e.g. CD jukebox) support multiple LUNs +# +# CONFIG_SCSI_MULTI_LUN is not set +CONFIG_SCSI_CONSTANTS=y +# CONFIG_SCSI_LOGGING is not set + +# +# SCSI Transport Attributes +# +# CONFIG_SCSI_SPI_ATTRS is not set +# CONFIG_SCSI_FC_ATTRS is not set +CONFIG_SCSI_ISCSI_ATTRS=m +# CONFIG_SCSI_SAS_ATTRS is not set + +# +# SCSI low-level drivers +# +CONFIG_ISCSI_TCP=m +# CONFIG_BLK_DEV_3W_XXXX_RAID is not set +# CONFIG_SCSI_3W_9XXX is not set +# CONFIG_SCSI_ACARD is not set +# CONFIG_SCSI_AACRAID is not set +# CONFIG_SCSI_AIC7XXX is not set +# CONFIG_SCSI_AIC7XXX_OLD is not set +# CONFIG_SCSI_AIC79XX is not set +# CONFIG_SCSI_DPT_I2O is not set +# CONFIG_MEGARAID_NEWGEN is not set +# CONFIG_MEGARAID_LEGACY is not set +# CONFIG_MEGARAID_SAS is not set +# CONFIG_SCSI_SATA is not set +# CONFIG_SCSI_DMX3191D is not set +# CONFIG_SCSI_FUTURE_DOMAIN is not set +# CONFIG_SCSI_IPS is not set +# CONFIG_SCSI_INITIO is not set +# CONFIG_SCSI_INIA100 is not set +# CONFIG_SCSI_SYM53C8XX_2 is not set +# CONFIG_SCSI_IPR is not set +# CONFIG_SCSI_QLOGIC_FC is not set +# CONFIG_SCSI_QLOGIC_1280 is not set +CONFIG_SCSI_QLA2XXX=y +# CONFIG_SCSI_QLA21XX is not set +# CONFIG_SCSI_QLA22XX is not set +# CONFIG_SCSI_QLA2300 is not set +# CONFIG_SCSI_QLA2322 is not set +# CONFIG_SCSI_QLA6312 is not set +# CONFIG_SCSI_QLA24XX is not set +# CONFIG_SCSI_LPFC is not set +# CONFIG_SCSI_DC395x is not set +# CONFIG_SCSI_DC390T is not set +# CONFIG_SCSI_NSP32 is not set +# CONFIG_SCSI_DEBUG is not set + +# +# Multi-device support (RAID and LVM) +# +# CONFIG_MD is not set + +# +# Fusion MPT device support +# +# CONFIG_FUSION is not set +# CONFIG_FUSION_SPI is not set +# CONFIG_FUSION_FC is not set +# CONFIG_FUSION_SAS is not set + +# +# IEEE 1394 (FireWire) support +# +# CONFIG_IEEE1394 is not set + +# +# I2O device support +# +# CONFIG_I2O is not set + +# +# Network device support +# +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 + +# +# PHY device support +# +# CONFIG_PHYLIB 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_CASSINI 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_B44 is not set +# CONFIG_FORCEDETH 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=y +# CONFIG_NE2K_PCI is not set +# CONFIG_8139CP is not set +# CONFIG_8139TOO 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 +# CONFIG_LAN_SAA9730 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_YELLOWFIN is not set +# CONFIG_R8169 is not set +# CONFIG_SIS190 is not set +# CONFIG_SKGE is not set +# CONFIG_SK98LIN is not set +# CONFIG_VIA_VELOCITY is not set +# CONFIG_TIGON3 is not set +# CONFIG_BNX2 is not set + +# +# Ethernet (10000 Mbit) +# +# CONFIG_CHELSIO_T1 is not set +# 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_HIPPI is not set +# CONFIG_PPP is not set +# CONFIG_SLIP is not set +# CONFIG_NET_FC is not set +# CONFIG_SHAPER is not set +# CONFIG_NETCONSOLE is not set +# CONFIG_NETPOLL is not set +# CONFIG_NET_POLL_CONTROLLER is not set + +# +# ISDN subsystem +# +# CONFIG_ISDN is not set + +# +# Telephony Support +# +# CONFIG_PHONE is not set + +# +# Input device support +# +CONFIG_INPUT=y + +# +# Userland interfaces +# +# CONFIG_INPUT_MOUSEDEV is not set +# CONFIG_INPUT_JOYDEV is not set +# CONFIG_INPUT_TSDEV is not set +# CONFIG_INPUT_EVDEV is not set +# CONFIG_INPUT_EVBUG is not set + +# +# Input Device Drivers +# +# CONFIG_INPUT_KEYBOARD is not set +# CONFIG_INPUT_MOUSE is not set +# CONFIG_INPUT_JOYSTICK is not set +# CONFIG_INPUT_TOUCHSCREEN is not set +# CONFIG_INPUT_MISC is not set + +# +# Hardware I/O ports +# +CONFIG_SERIO=y +# CONFIG_SERIO_I8042 is not set +# CONFIG_SERIO_SERPORT is not set +# CONFIG_SERIO_PCIPS2 is not set +CONFIG_SERIO_LIBPS2=y +# CONFIG_SERIO_RAW is not set +# CONFIG_GAMEPORT is not set + +# +# Character devices +# +CONFIG_VT=y +CONFIG_VT_CONSOLE=y +CONFIG_HW_CONSOLE=y +# CONFIG_SERIAL_NONSTANDARD is not set + +# +# Serial drivers +# +# CONFIG_SERIAL_8250 is not set + +# +# Non-8250 serial port support +# +CONFIG_SERIAL_IP3106=y +CONFIG_SERIAL_IP3106_CONSOLE=y +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 is not set +# 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 +# +# CONFIG_TCG_TPM is not set +# CONFIG_TELCLOCK is not set + +# +# I2C support +# +# CONFIG_I2C is not set + +# +# Dallas's 1-wire bus +# +# CONFIG_W1 is not set + +# +# Hardware Monitoring support +# +CONFIG_HWMON=y +# CONFIG_HWMON_VID is not set +# CONFIG_HWMON_DEBUG_CHIP is not set + +# +# Misc devices +# + +# +# Multimedia Capabilities Port drivers +# + +# +# Multimedia devices +# +# CONFIG_VIDEO_DEV is not set + +# +# Digital Video Broadcasting Devices +# +# CONFIG_DVB is not set + +# +# Graphics support +# +# CONFIG_FB is not set + +# +# Console display driver support +# +# CONFIG_VGA_CONSOLE is not set +CONFIG_DUMMY_CONSOLE=y + +# +# Sound +# +# CONFIG_SOUND is not set + +# +# USB support +# +CONFIG_USB_ARCH_HAS_HCD=y +CONFIG_USB_ARCH_HAS_OHCI=y +CONFIG_USB=y +# CONFIG_USB_DEBUG is not set + +# +# Miscellaneous USB options +# +# CONFIG_USB_DEVICEFS is not set +# CONFIG_USB_BANDWIDTH is not set +# CONFIG_USB_DYNAMIC_MINORS is not set +# CONFIG_USB_OTG is not set + +# +# USB Host Controller Drivers +# +# CONFIG_USB_EHCI_HCD is not set +# CONFIG_USB_ISP116X_HCD is not set +CONFIG_USB_OHCI_HCD=y +# CONFIG_USB_OHCI_BIG_ENDIAN is not set +CONFIG_USB_OHCI_LITTLE_ENDIAN=y +# CONFIG_USB_UHCI_HCD is not set +# CONFIG_USB_SL811_HCD is not set + +# +# USB Device Class drivers +# +# CONFIG_USB_ACM is not set +# CONFIG_USB_PRINTER is not set + +# +# NOTE: USB_STORAGE enables SCSI, and 'SCSI disk support' +# + +# +# may also be needed; see USB_STORAGE Help for more information +# +CONFIG_USB_STORAGE=y +# CONFIG_USB_STORAGE_DEBUG is not set +CONFIG_USB_STORAGE_DATAFAB=y +CONFIG_USB_STORAGE_FREECOM=y +CONFIG_USB_STORAGE_ISD200=y +CONFIG_USB_STORAGE_DPCM=y +CONFIG_USB_STORAGE_USBAT=y +CONFIG_USB_STORAGE_SDDR09=y +CONFIG_USB_STORAGE_SDDR55=y +CONFIG_USB_STORAGE_JUMPSHOT=y + +# +# USB Input Devices +# +# CONFIG_USB_HID is not set + +# +# USB HID Boot Protocol drivers +# +# CONFIG_USB_KBD is not set +# CONFIG_USB_MOUSE is not set +# CONFIG_USB_AIPTEK is not set +# CONFIG_USB_WACOM is not set +# CONFIG_USB_ACECAD is not set +# CONFIG_USB_KBTAB is not set +# CONFIG_USB_POWERMATE is not set +# CONFIG_USB_MTOUCH is not set +# CONFIG_USB_ITMTOUCH is not set +# CONFIG_USB_EGALAX is not set +# CONFIG_USB_YEALINK is not set +# CONFIG_USB_XPAD is not set +# CONFIG_USB_ATI_REMOTE is not set +# CONFIG_USB_KEYSPAN_REMOTE is not set +# CONFIG_USB_APPLETOUCH is not set + +# +# USB Imaging devices +# +# CONFIG_USB_MDC800 is not set +# CONFIG_USB_MICROTEK is not set + +# +# USB Multimedia devices +# +# CONFIG_USB_DABUSB is not set + +# +# Video4Linux support is needed for USB Multimedia device support +# + +# +# USB Network Adapters +# +# CONFIG_USB_CATC is not set +# CONFIG_USB_KAWETH is not set +# CONFIG_USB_PEGASUS is not set +# CONFIG_USB_RTL8150 is not set +# CONFIG_USB_USBNET is not set +CONFIG_USB_MON=y + +# +# USB port drivers +# + +# +# USB Serial Converter support +# +# CONFIG_USB_SERIAL is not set + +# +# USB Miscellaneous drivers +# +# CONFIG_USB_EMI62 is not set +# CONFIG_USB_EMI26 is not set +# CONFIG_USB_AUERSWALD is not set +# CONFIG_USB_RIO500 is not set +# CONFIG_USB_LEGOTOWER is not set +# CONFIG_USB_LCD is not set +# CONFIG_USB_LED is not set +# CONFIG_USB_CYTHERM is not set +# CONFIG_USB_PHIDGETKIT is not set +# CONFIG_USB_PHIDGETSERVO is not set +# CONFIG_USB_IDMOUSE is not set +# CONFIG_USB_LD is not set + +# +# USB DSL modem support +# + +# +# 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 + +# +# SN Devices +# + +# +# File systems +# +CONFIG_EXT2_FS=y +# CONFIG_EXT2_FS_XATTR is not set +# CONFIG_EXT2_FS_XIP 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 +# CONFIG_FS_POSIX_ACL is not set +# CONFIG_XFS_FS is not set +# CONFIG_MINIX_FS is not set +# CONFIG_ROMFS_FS is not set +CONFIG_INOTIFY=y +# CONFIG_QUOTA is not set +# CONFIG_DNOTIFY is not set +# CONFIG_AUTOFS_FS is not set +# CONFIG_AUTOFS4_FS is not set +# CONFIG_FUSE_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_FAT_FS=y +CONFIG_MSDOS_FS=y +CONFIG_VFAT_FS=y +CONFIG_FAT_DEFAULT_CODEPAGE=437 +CONFIG_FAT_DEFAULT_IOCHARSET="iso8859-1" +# CONFIG_NTFS_FS is not set + +# +# Pseudo filesystems +# +CONFIG_PROC_FS=y +# CONFIG_PROC_KCORE is not set +CONFIG_SYSFS=y +CONFIG_TMPFS=y +# CONFIG_HUGETLB_PAGE is not set +CONFIG_RAMFS=y +# CONFIG_RELAYFS_FS is not set + +# +# Miscellaneous filesystems +# +# CONFIG_ADFS_FS is not set +# CONFIG_AFFS_FS is not set +# CONFIG_HFS_FS is not set +# CONFIG_HFSPLUS_FS is not set +# CONFIG_BEFS_FS is not set +# CONFIG_BFS_FS is not set +# CONFIG_EFS_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=y +# CONFIG_NFS_V3_ACL is not set +# CONFIG_NFS_V4 is not set +# CONFIG_NFS_DIRECTIO is not set +CONFIG_NFSD=m +# CONFIG_NFSD_V3 is not set +# CONFIG_NFSD_TCP is not set +CONFIG_ROOT_NFS=y +CONFIG_LOCKD=y +CONFIG_LOCKD_V4=y +CONFIG_EXPORTFS=m +CONFIG_NFS_COMMON=y +CONFIG_SUNRPC=y +# CONFIG_RPCSEC_GSS_KRB5 is not set +# CONFIG_RPCSEC_GSS_SPKM3 is not set +# CONFIG_SMB_FS is not set +# CONFIG_CIFS is not set +# CONFIG_NCP_FS is not set +# CONFIG_CODA_FS is not set +# CONFIG_AFS_FS is not set +# CONFIG_9P_FS is not set + +# +# Partition Types +# +# CONFIG_PARTITION_ADVANCED is not set +CONFIG_MSDOS_PARTITION=y + +# +# Native Language Support +# +CONFIG_NLS=y +CONFIG_NLS_DEFAULT="iso8859-1" +# CONFIG_NLS_CODEPAGE_437 is not set +# CONFIG_NLS_CODEPAGE_737 is not set +# CONFIG_NLS_CODEPAGE_775 is not set +# CONFIG_NLS_CODEPAGE_850 is not set +# CONFIG_NLS_CODEPAGE_852 is not set +# CONFIG_NLS_CODEPAGE_855 is not set +# CONFIG_NLS_CODEPAGE_857 is not set +# CONFIG_NLS_CODEPAGE_860 is not set +# CONFIG_NLS_CODEPAGE_861 is not set +# CONFIG_NLS_CODEPAGE_862 is not set +# CONFIG_NLS_CODEPAGE_863 is not set +# CONFIG_NLS_CODEPAGE_864 is not set +# CONFIG_NLS_CODEPAGE_865 is not set +# CONFIG_NLS_CODEPAGE_866 is not set +# CONFIG_NLS_CODEPAGE_869 is not set +# CONFIG_NLS_CODEPAGE_936 is not set +# CONFIG_NLS_CODEPAGE_950 is not set +# CONFIG_NLS_CODEPAGE_932 is not set +# CONFIG_NLS_CODEPAGE_949 is not set +# CONFIG_NLS_CODEPAGE_874 is not set +# CONFIG_NLS_ISO8859_8 is not set +# CONFIG_NLS_CODEPAGE_1250 is not set +# CONFIG_NLS_CODEPAGE_1251 is not set +# CONFIG_NLS_ASCII is not set +# CONFIG_NLS_ISO8859_1 is not set +# CONFIG_NLS_ISO8859_2 is not set +# CONFIG_NLS_ISO8859_3 is not set +# CONFIG_NLS_ISO8859_4 is not set +# CONFIG_NLS_ISO8859_5 is not set +# CONFIG_NLS_ISO8859_6 is not set +# CONFIG_NLS_ISO8859_7 is not set +# CONFIG_NLS_ISO8859_9 is not set +# CONFIG_NLS_ISO8859_13 is not set +# CONFIG_NLS_ISO8859_14 is not set +# CONFIG_NLS_ISO8859_15 is not set +# CONFIG_NLS_KOI8_R is not set +# CONFIG_NLS_KOI8_U is not set +# CONFIG_NLS_UTF8 is not set + +# +# Profiling support +# +# CONFIG_PROFILING is not set + +# +# Kernel hacking +# +# CONFIG_PRINTK_TIME is not set +CONFIG_DEBUG_KERNEL=y +CONFIG_MAGIC_SYSRQ=y +CONFIG_LOG_BUF_SHIFT=14 +CONFIG_DETECT_SOFTLOCKUP=y +# CONFIG_SCHEDSTATS is not set +CONFIG_DEBUG_SLAB=y +# CONFIG_DEBUG_SPINLOCK is not set +# CONFIG_DEBUG_SPINLOCK_SLEEP is not set +# CONFIG_DEBUG_KOBJECT is not set +# CONFIG_DEBUG_INFO is not set +# CONFIG_DEBUG_FS is not set +# CONFIG_DEBUG_VM is not set +# CONFIG_RCU_TORTURE_TEST is not set +CONFIG_CROSSCOMPILE=y +CONFIG_CMDLINE="console=ttyS1,38400n8 kgdb=ttyS0 root=/dev/nfs ip=bootp" +# 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 is not set +# CONFIG_SECURITY is not set + +# +# Cryptographic options +# +CONFIG_CRYPTO=y +# CONFIG_CRYPTO_HMAC is not set +# CONFIG_CRYPTO_NULL is not set +# CONFIG_CRYPTO_MD4 is not set +CONFIG_CRYPTO_MD5=m +# CONFIG_CRYPTO_SHA1 is not set +# CONFIG_CRYPTO_SHA256 is not set +# CONFIG_CRYPTO_SHA512 is not set +# CONFIG_CRYPTO_WP512 is not set +# CONFIG_CRYPTO_TGR192 is not set +# CONFIG_CRYPTO_DES is not set +# CONFIG_CRYPTO_BLOWFISH is not set +# CONFIG_CRYPTO_TWOFISH is not set +# CONFIG_CRYPTO_SERPENT is not set +# CONFIG_CRYPTO_AES is not set +# CONFIG_CRYPTO_CAST5 is not set +# CONFIG_CRYPTO_CAST6 is not set +# CONFIG_CRYPTO_TEA is not set +# CONFIG_CRYPTO_ARC4 is not set +# CONFIG_CRYPTO_KHAZAD is not set +# CONFIG_CRYPTO_ANUBIS is not set +# CONFIG_CRYPTO_DEFLATE is not set +# CONFIG_CRYPTO_MICHAEL_MIC is not set +CONFIG_CRYPTO_CRC32C=m +# CONFIG_CRYPTO_TEST is not set + +# +# Hardware crypto devices +# + +# +# Library routines +# +CONFIG_CRC_CCITT=m +# CONFIG_CRC16 is not set +CONFIG_CRC32=y +CONFIG_LIBCRC32C=m --------------090706010406070506020107-- From vbarinov@ru.mvista.com Thu Dec 8 17:26:24 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 08 Dec 2005 17:26:46 +0000 (GMT) Received: from rtsoft3.corbina.net ([85.21.88.6]:32584 "EHLO buildserver.ru.mvista.com") by ftp.linux-mips.org with ESMTP id S8133480AbVLHR0Y (ORCPT ); Thu, 8 Dec 2005 17:26:24 +0000 Received: from [192.168.12.17] ([10.149.0.1]) by buildserver.ru.mvista.com (8.11.6/8.11.6) with ESMTP id jB8HQHt28073; Thu, 8 Dec 2005 21:26:17 +0400 Message-ID: <43986CB8.9000000@ru.mvista.com> Date: Thu, 08 Dec 2005 20:26:16 +0300 From: "Vladimir A. Barinov" User-Agent: Mozilla Thunderbird 1.0.2-6 (X11/20050513) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ralf@linux-mips.org, ppopov@embeddedalley.com CC: linux-mips@linux-mips.org Subject: [Fwd: Re: [PATCH] Philips PNX8550 command line patch] Content-Type: multipart/mixed; boundary="------------050707090104000905020304" 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: 9635 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: vbarinov@ru.mvista.com Precedence: bulk X-list: linux-mips This is a multi-part message in MIME format. --------------050707090104000905020304 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sorry, but it seems that this mail was lost :( resending... --------------050707090104000905020304 Content-Type: message/rfc822; name="Re: [PATCH] Philips PNX8550 command line patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="Re: [PATCH] Philips PNX8550 command line patch" Message-ID: <43986714.2020806@ru.mvista.com> Date: Thu, 08 Dec 2005 20:02:12 +0300 From: "Vladimir A. Barinov" User-Agent: Mozilla Thunderbird 1.0.2-6 (X11/20050513) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Peter Popov CC: Ralf Baechle , "'linux-mips@linux-mips.org'" Subject: Re: [PATCH] Philips PNX8550 command line patch References: <20051206192105.32325.qmail@web403.biz.mail.mud.yahoo.com> In-Reply-To: <20051206192105.32325.qmail@web403.biz.mail.mud.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hello Pete, Ralf, Peter Popov wrote: >--- Ralf Baechle wrote: > > > >>On Tue, Dec 06, 2005 at 09:02:14PM +0300, Vladimir >>A. Barinov wrote: >> >> >> >>>This patch makes passing command line from >>> >>> >>bootloader for Philips >> >> >>>PNX8550 platform. >>>Does it makes sense to commit this patch? >>> >>> >>Looks ok at a quick glance. I'll wait a bit so Pete >>has a chance to comment. >> >> > >Looks fine to me. > > Sorry for my misunderstood but I suppose that this patch should be ignored since it used JBS board dependent code and I have STB810 that based on the code of JBS. But JBS board could have firmware that differs from that STB810 uses. So the command line could be parsed incorrectly for JBS, it's needed to check by somebody who has JBS board. I prepared STB810 board dependent patch that include this fix for command-line parsing for STB810 board only. So Ralf please ignore this patch though it was approved by you and Pete. Vladimir --------------050707090104000905020304-- From sshtylyov@ru.mvista.com Thu Dec 8 19:38:40 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 08 Dec 2005 19:38:59 +0000 (GMT) Received: from rtsoft2.corbina.net ([85.21.88.2]:54478 "HELO mail.dev.rtsoft.ru") by ftp.linux-mips.org with SMTP id S3457351AbVLHTik (ORCPT ); Thu, 8 Dec 2005 19:38:40 +0000 Received: (qmail 19197 invoked from network); 8 Dec 2005 19:38:30 -0000 Received: from wasted.dev.rtsoft.ru (HELO ?192.168.1.248?) (192.168.1.248) by mail.dev.rtsoft.ru with SMTP; 8 Dec 2005 19:38:30 -0000 Message-ID: <43988C42.2060904@ru.mvista.com> Date: Thu, 08 Dec 2005 22:40:50 +0300 From: Sergei Shtylylov Organization: MostaVista 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@linux-mips.org CC: dan@embeddededge.com, Jordan Crouse , Manish Lachwani , Konstantin Baidarov Subject: Re: [Alsa-devel] Au1550 OSS driver issues References: <43452054.2090305@ru.mvista.com> <436FB1DE.6010405@ru.mvista.com> In-Reply-To: <436FB1DE.6010405@ru.mvista.com> Content-Type: multipart/mixed; boundary="------------090107080901060406070409" 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: 9636 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. --------------090107080901060406070409 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hello, I wrote: >> We have found some issues with Au1550 AC'97 OSS driver in 2.6 >> (sound/oss/au1550_ac97.c), though it also should concern 2.4 driver >> (drivers/sound/au1550_psc.c). [au_readl() issue skipped] >> Second, start_dac() grabs a spinlock already held by its caller, >> au1550_write(). This doesn't show up with the standard UP spinlock >> impelmentation but when the different one (mutex based) is in use, a >> lockup happens. The second patch demonstates a possible solution but >> here's a question: why there's no "symmetric" spinlock logic in >> start_adc(), may be here exits another potential issue? Unfortunately, the proposed solution was incorrect for that mutex case because it was breaking the "critical section" by temporarily dropping the spinlock to call start_dac(). So, here's the updated version of that patch in which start_dac() and start_adc() don't grab the spinlocks anymore but their callers do instead. > After having a look at sound/oss/au1000.c, Now I don't think that this trick is always correct but since that driver is obsoleted by ALSA one I don't care that much. ;-) > here's an updated > patch that deals with "nested" spinlocks the same way that driver does, > and adds spinlock to start_adc() as well. And the interrupt handlers also didn't grab the spinlock -- that's OK in the usual kernel but not when the IRQ handlers are threaded. So, they're grabbing the spinlock now (as every correct interrupt handler should do). WBR, Sergei --------------090107080901060406070409 Content-Type: text/plain; name="Au1550-AC97-OSS-spinlocks.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="Au1550-AC97-OSS-spinlocks.patch" diff --git a/sound/oss/au1550_ac97.c b/sound/oss/au1550_ac97.c index cdce915..f70effd 100644 --- a/sound/oss/au1550_ac97.c +++ b/sound/oss/au1550_ac97.c @@ -579,17 +579,15 @@ set_recv_slots(int num_channels) } while ((stat & PSC_AC97STAT_DR) == 0); } +/* Hold spinlock for both start_dac() and start_adc() calls */ static void start_dac(struct au1550_state *s) { struct dmabuf *db = &s->dma_dac; - unsigned long flags; if (!db->stopped) return; - spin_lock_irqsave(&s->lock, flags); - set_xmit_slots(db->num_channels); au_writel(PSC_AC97PCR_TC, PSC_AC97PCR); au_sync(); @@ -599,8 +597,6 @@ start_dac(struct au1550_state *s) au1xxx_dbdma_start(db->dmanr); db->stopped = 0; - - spin_unlock_irqrestore(&s->lock, flags); } static void @@ -719,7 +715,6 @@ prog_dmabuf_dac(struct au1550_state *s) } -/* hold spinlock for the following */ static void dac_dma_interrupt(int irq, void *dev_id, struct pt_regs *regs) { @@ -727,6 +722,8 @@ dac_dma_interrupt(int irq, void *dev_id, struct dmabuf *db = &s->dma_dac; u32 ac97c_stat; + spin_lock(&s->lock); + ac97c_stat = au_readl(PSC_AC97STAT); if (ac97c_stat & (AC97C_XU | AC97C_XO | AC97C_TE)) pr_debug("AC97C status = 0x%08x\n", ac97c_stat); @@ -748,6 +745,8 @@ dac_dma_interrupt(int irq, void *dev_id, /* wake up anybody listening */ if (waitqueue_active(&db->wait)) wake_up(&db->wait); + + spin_unlock(&s->lock); } @@ -759,6 +758,8 @@ adc_dma_interrupt(int irq, void *dev_id, u32 obytes; char *obuf; + spin_lock(&s->lock); + /* Pull the buffer from the dma queue. */ au1xxx_dbdma_get_dest(dp->dmanr, (void *)(&obuf), &obytes); @@ -766,6 +767,7 @@ adc_dma_interrupt(int irq, void *dev_id, if ((dp->count + obytes) > dp->dmasize) { /* Overrun. Stop ADC and log the error */ + spin_unlock(&s->lock); stop_adc(s); dp->error++; err("adc overrun"); @@ -788,6 +790,7 @@ adc_dma_interrupt(int irq, void *dev_id, if (waitqueue_active(&dp->wait)) wake_up(&dp->wait); + spin_unlock(&s->lock); } static loff_t @@ -1049,9 +1052,9 @@ au1550_read(struct file *file, char *buf /* wait for samples in ADC dma buffer */ do { + spin_lock_irqsave(&s->lock, flags); if (db->stopped) start_adc(s); - spin_lock_irqsave(&s->lock, flags); avail = db->count; if (avail <= 0) __set_current_state(TASK_INTERRUPTIBLE); @@ -1571,15 +1574,19 @@ au1550_ioctl(struct inode *inode, struct if (get_user(val, (int *) arg)) return -EFAULT; if (file->f_mode & FMODE_READ) { - if (val & PCM_ENABLE_INPUT) + if (val & PCM_ENABLE_INPUT) { + spin_lock_irqsave(&s->lock, flags); start_adc(s); - else + spin_unlock_irqrestore(&s->lock, flags); + } else stop_adc(s); } if (file->f_mode & FMODE_WRITE) { - if (val & PCM_ENABLE_OUTPUT) + if (val & PCM_ENABLE_OUTPUT) { + spin_lock_irqsave(&s->lock, flags); start_dac(s); - else + spin_unlock_irqrestore(&s->lock, flags); + } else stop_dac(s); } return 0; --------------090107080901060406070409-- From sshtylyov@ru.mvista.com Thu Dec 8 19:53:09 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 08 Dec 2005 19:53:27 +0000 (GMT) Received: from rtsoft2.corbina.net ([85.21.88.2]:47312 "HELO mail.dev.rtsoft.ru") by ftp.linux-mips.org with SMTP id S8133980AbVLHTxJ (ORCPT ); Thu, 8 Dec 2005 19:53:09 +0000 Received: (qmail 19381 invoked from network); 8 Dec 2005 19:52:59 -0000 Received: from wasted.dev.rtsoft.ru (HELO ?192.168.1.248?) (192.168.1.248) by mail.dev.rtsoft.ru with SMTP; 8 Dec 2005 19:52:59 -0000 Message-ID: <43988FA6.5080209@ru.mvista.com> Date: Thu, 08 Dec 2005 22:55:18 +0300 From: Sergei Shtylylov Organization: MostaVista 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@linux-mips.org CC: Jordan Crouse Subject: [PATCH] Simple patch to power off DBAU1200 References: <1133342401.24526.25.camel@localhost.localdomain> In-Reply-To: <1133342401.24526.25.camel@localhost.localdomain> Content-Type: multipart/mixed; boundary="------------010608020005030108010604" 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: 9637 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. --------------010608020005030108010604 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hello. Matej Kupljen wrote: > Hi > > Please, find the attached patch which enables > powering off the DBAU1200 board. As a follow up to this one, here's the patch which does the same thing for DBAu1550 by just reusing Pb1550 code. I added #else because #if renders the rest of the au1000_halt() code unreachable on DBAu1550/PB1550 anyway. > BR, > Matej WBR, Sergei > ------------------------------------------------------------------------ > > Patch to enable powering off DBAU1200 > > Signed-off-by: Matej Kupljen > > --- a/arch/mips/au1000/common/reset.c 2005-10-24 13:36:24.000000000 +0200 > +++ b/arch/mips/au1000/common/reset.c 2005-08-24 14:39:58.000000000 +0200 > @@ -175,6 +175,9 @@ > #ifdef CONFIG_MIPS_MIRAGE > au_writel((1 << 26) | (1 << 10), GPIO2_OUTPUT); > #endif > +#ifdef CONFIG_MIPS_DB1200 > + au_writew(au_readw(0xB980001C) | (1<<14), 0xB980001C); > +#endif > #ifdef CONFIG_PM > au_sleep(); > --------------010608020005030108010604 Content-Type: text/plain; name="DBAu1550-soft-off.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="DBAu1550-soft-off.patch" diff --git a/arch/mips/au1000/common/reset.c b/arch/mips/au1000/common/reset.c index 65b84db..8a4afdc 100644 --- a/arch/mips/au1000/common/reset.c +++ b/arch/mips/au1000/common/reset.c @@ -164,13 +164,13 @@ void au1000_restart(char *command) void au1000_halt(void) { -#if defined(CONFIG_MIPS_PB1550) +#if defined(CONFIG_MIPS_PB1550) || defined(CONFIG_MIPS_DB1550) /* power off system */ - printk("\n** Powering off Pb1550\n"); + printk("\n** Powering off...\n"); au_writew(au_readw(0xAF00001C) | (3<<14), 0xAF00001C); au_sync(); while(1); /* should not get here */ -#endif +#else printk(KERN_NOTICE "\n** You can safely turn off the power\n"); #ifdef CONFIG_MIPS_MIRAGE au_writel((1 << 26) | (1 << 10), GPIO2_OUTPUT); @@ -187,6 +187,7 @@ void au1000_halt(void) "wait\n\t" ".set\tmips0"); #endif +#endif /* defined(CONFIG_MIPS_PB1550) || defined(CONFIG_MIPS_DB1550) */ } void au1000_power_off(void) --------------010608020005030108010604-- From sshtylyov@ru.mvista.com Thu Dec 8 20:28:40 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 08 Dec 2005 20:28:58 +0000 (GMT) Received: from rtsoft2.corbina.net ([85.21.88.2]:2516 "HELO mail.dev.rtsoft.ru") by ftp.linux-mips.org with SMTP id S3457351AbVLHU2k (ORCPT ); Thu, 8 Dec 2005 20:28:40 +0000 Received: (qmail 19845 invoked from network); 8 Dec 2005 20:28:32 -0000 Received: from wasted.dev.rtsoft.ru (HELO ?192.168.1.248?) (192.168.1.248) by mail.dev.rtsoft.ru with SMTP; 8 Dec 2005 20:28:32 -0000 Message-ID: <439897FC.5050008@ru.mvista.com> Date: Thu, 08 Dec 2005 23:30:52 +0300 From: Sergei Shtylylov Organization: MostaVista 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@linux-mips.org CC: Jordan Crouse Subject: [PATCH] Enable DBAu1550 soft-off References: <1133342401.24526.25.camel@localhost.localdomain> <43988FA6.5080209@ru.mvista.com> In-Reply-To: <43988FA6.5080209@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: 9638 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. > Matej Kupljen wrote: > >> Hi >> >> Please, find the attached patch which enables >> powering off the DBAU1200 board. > > > As a follow up to this one, here's the patch which does the same > thing for > DBAu1550 by just reusing Pb1550 code. I added #else because #if renders the > rest of the au1000_halt() code unreachable on DBAu1550/PB1550 anyway. Failed to chenge the subject to a proper one. :-/ WBR, Sergei From sshtylyov@ru.mvista.com Thu Dec 8 20:38:03 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 08 Dec 2005 20:38:28 +0000 (GMT) Received: from rtsoft2.corbina.net ([85.21.88.2]:59860 "HELO mail.dev.rtsoft.ru") by ftp.linux-mips.org with SMTP id S3458260AbVLHUiC (ORCPT ); Thu, 8 Dec 2005 20:38:02 +0000 Received: (qmail 19969 invoked from network); 8 Dec 2005 20:37:53 -0000 Received: from wasted.dev.rtsoft.ru (HELO ?192.168.1.248?) (192.168.1.248) by mail.dev.rtsoft.ru with SMTP; 8 Dec 2005 20:37:53 -0000 Message-ID: <43989A2C.9020006@ru.mvista.com> Date: Thu, 08 Dec 2005 23:40:12 +0300 From: Sergei Shtylylov Organization: MostaVista 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@linux-mips.org CC: Jordan Crouse Subject: Re: [PATCH] Enable DBAu1550 soft-off References: <1133342401.24526.25.camel@localhost.localdomain> <43988FA6.5080209@ru.mvista.com> <439897FC.5050008@ru.mvista.com> In-Reply-To: <439897FC.5050008@ru.mvista.com> Content-Type: multipart/mixed; boundary="------------070202070007000808060508" 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: 9639 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. --------------070202070007000808060508 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hello, I wrote. >> Matej Kupljen wrote: >> >>> Hi >>> >>> Please, find the attached patch which enables >>> powering off the DBAU1200 board. >> >> >> >> As a follow up to this one, here's the patch which does the same >> thing for >> DBAu1550 by just reusing Pb1550 code. I added #else because #if >> renders the >> rest of the au1000_halt() code unreachable on DBAu1550/PB1550 anyway. > > Failed to chenge the subject to a proper one. :-/ And forgot about sign-off line. :-( > WBR, Sergei Signed-off-by: Sergei Shtylyov --------------070202070007000808060508 Content-Type: text/plain; name="DBAu1550-soft-off.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="DBAu1550-soft-off.patch" diff --git a/arch/mips/au1000/common/reset.c b/arch/mips/au1000/common/reset.c index 65b84db..8a4afdc 100644 --- a/arch/mips/au1000/common/reset.c +++ b/arch/mips/au1000/common/reset.c @@ -164,13 +164,13 @@ void au1000_restart(char *command) void au1000_halt(void) { -#if defined(CONFIG_MIPS_PB1550) +#if defined(CONFIG_MIPS_PB1550) || defined(CONFIG_MIPS_DB1550) /* power off system */ - printk("\n** Powering off Pb1550\n"); + printk("\n** Powering off...\n"); au_writew(au_readw(0xAF00001C) | (3<<14), 0xAF00001C); au_sync(); while(1); /* should not get here */ -#endif +#else printk(KERN_NOTICE "\n** You can safely turn off the power\n"); #ifdef CONFIG_MIPS_MIRAGE au_writel((1 << 26) | (1 << 10), GPIO2_OUTPUT); @@ -187,6 +187,7 @@ void au1000_halt(void) "wait\n\t" ".set\tmips0"); #endif +#endif /* defined(CONFIG_MIPS_PB1550) || defined(CONFIG_MIPS_DB1550) */ } void au1000_power_off(void) --------------070202070007000808060508-- From sshtylyov@ru.mvista.com Thu Dec 8 20:43:59 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 08 Dec 2005 20:44:17 +0000 (GMT) Received: from rtsoft2.corbina.net ([85.21.88.2]:26069 "HELO mail.dev.rtsoft.ru") by ftp.linux-mips.org with SMTP id S3458260AbVLHUn7 (ORCPT ); Thu, 8 Dec 2005 20:43:59 +0000 Received: (qmail 20039 invoked from network); 8 Dec 2005 20:43:45 -0000 Received: from wasted.dev.rtsoft.ru (HELO ?192.168.1.248?) (192.168.1.248) by mail.dev.rtsoft.ru with SMTP; 8 Dec 2005 20:43:45 -0000 Message-ID: <43989B8D.7050009@ru.mvista.com> Date: Thu, 08 Dec 2005 23:46:05 +0300 From: Sergei Shtylylov Organization: MostaVista 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@linux-mips.org CC: Jordan Crouse Subject: Re: [Alsa-devel] Au1550 OSS driver issues References: <43452054.2090305@ru.mvista.com> <436FB1DE.6010405@ru.mvista.com> <43988C42.2060904@ru.mvista.com> In-Reply-To: <43988C42.2060904@ru.mvista.com> Content-Type: multipart/mixed; boundary="------------010200040403030206040902" 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: 9640 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. --------------010200040403030206040902 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sergei Shtylylov wrote: > Hello, I wrote: > >>> We have found some issues with Au1550 AC'97 OSS driver in 2.6 >>> (sound/oss/au1550_ac97.c), though it also should concern 2.4 driver >>> (drivers/sound/au1550_psc.c). > [au_readl() issue skipped] >>> Second, start_dac() grabs a spinlock already held by its caller, >>> au1550_write(). This doesn't show up with the standard UP spinlock >>> impelmentation but when the different one (mutex based) is in use, a >>> lockup happens. The second patch demonstates a possible solution but >>> here's a question: why there's no "symmetric" spinlock logic in >>> start_adc(), may be here exits another potential issue? > > > Unfortunately, the proposed solution was incorrect for that mutex case > because it was breaking the "critical section" by temporarily dropping the > spinlock to call start_dac(). So, here's the updated version of that > patch in > which start_dac() and start_adc() don't grab the spinlocks anymore but > their > callers do instead. > >> After having a look at sound/oss/au1000.c, > > > Now I don't think that this trick is always correct but since that > driver > is obsoleted by ALSA one I don't care that much. ;-) > >> here's an updated patch that deals with "nested" spinlocks the same >> way that driver does, and adds spinlock to start_adc() as well. > > > And the interrupt handlers also didn't grab the spinlock -- that's OK > in the usual kernel but not when the IRQ handlers are threaded. So, they're > grabbing the spinlock now (as every correct interrupt handler should do). Failed to change the the subject and forgot about the sign-off, silly me... :-( WBR, Sergei Signed-off-by: Konstantin Baidarov Signed-off-by: Sergei Shtylyov --------------010200040403030206040902 Content-Type: text/plain; name="Au1550-AC97-OSS-spinlocks.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="Au1550-AC97-OSS-spinlocks.patch" diff --git a/sound/oss/au1550_ac97.c b/sound/oss/au1550_ac97.c index cdce915..f70effd 100644 --- a/sound/oss/au1550_ac97.c +++ b/sound/oss/au1550_ac97.c @@ -579,17 +579,15 @@ set_recv_slots(int num_channels) } while ((stat & PSC_AC97STAT_DR) == 0); } +/* Hold spinlock for both start_dac() and start_adc() calls */ static void start_dac(struct au1550_state *s) { struct dmabuf *db = &s->dma_dac; - unsigned long flags; if (!db->stopped) return; - spin_lock_irqsave(&s->lock, flags); - set_xmit_slots(db->num_channels); au_writel(PSC_AC97PCR_TC, PSC_AC97PCR); au_sync(); @@ -599,8 +597,6 @@ start_dac(struct au1550_state *s) au1xxx_dbdma_start(db->dmanr); db->stopped = 0; - - spin_unlock_irqrestore(&s->lock, flags); } static void @@ -719,7 +715,6 @@ prog_dmabuf_dac(struct au1550_state *s) } -/* hold spinlock for the following */ static void dac_dma_interrupt(int irq, void *dev_id, struct pt_regs *regs) { @@ -727,6 +722,8 @@ dac_dma_interrupt(int irq, void *dev_id, struct dmabuf *db = &s->dma_dac; u32 ac97c_stat; + spin_lock(&s->lock); + ac97c_stat = au_readl(PSC_AC97STAT); if (ac97c_stat & (AC97C_XU | AC97C_XO | AC97C_TE)) pr_debug("AC97C status = 0x%08x\n", ac97c_stat); @@ -748,6 +745,8 @@ dac_dma_interrupt(int irq, void *dev_id, /* wake up anybody listening */ if (waitqueue_active(&db->wait)) wake_up(&db->wait); + + spin_unlock(&s->lock); } @@ -759,6 +758,8 @@ adc_dma_interrupt(int irq, void *dev_id, u32 obytes; char *obuf; + spin_lock(&s->lock); + /* Pull the buffer from the dma queue. */ au1xxx_dbdma_get_dest(dp->dmanr, (void *)(&obuf), &obytes); @@ -766,6 +767,7 @@ adc_dma_interrupt(int irq, void *dev_id, if ((dp->count + obytes) > dp->dmasize) { /* Overrun. Stop ADC and log the error */ + spin_unlock(&s->lock); stop_adc(s); dp->error++; err("adc overrun"); @@ -788,6 +790,7 @@ adc_dma_interrupt(int irq, void *dev_id, if (waitqueue_active(&dp->wait)) wake_up(&dp->wait); + spin_unlock(&s->lock); } static loff_t @@ -1049,9 +1052,9 @@ au1550_read(struct file *file, char *buf /* wait for samples in ADC dma buffer */ do { + spin_lock_irqsave(&s->lock, flags); if (db->stopped) start_adc(s); - spin_lock_irqsave(&s->lock, flags); avail = db->count; if (avail <= 0) __set_current_state(TASK_INTERRUPTIBLE); @@ -1571,15 +1574,19 @@ au1550_ioctl(struct inode *inode, struct if (get_user(val, (int *) arg)) return -EFAULT; if (file->f_mode & FMODE_READ) { - if (val & PCM_ENABLE_INPUT) + if (val & PCM_ENABLE_INPUT) { + spin_lock_irqsave(&s->lock, flags); start_adc(s); - else + spin_unlock_irqrestore(&s->lock, flags); + } else stop_adc(s); } if (file->f_mode & FMODE_WRITE) { - if (val & PCM_ENABLE_OUTPUT) + if (val & PCM_ENABLE_OUTPUT) { + spin_lock_irqsave(&s->lock, flags); start_dac(s); - else + spin_unlock_irqrestore(&s->lock, flags); + } else stop_dac(s); } return 0; --------------010200040403030206040902-- From jcrouse@cosmic.amd.com Thu Dec 8 21:00:50 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 08 Dec 2005 21:01:16 +0000 (GMT) Received: from amdext3.amd.com ([139.95.251.6]:32706 "EHLO amdext3.amd.com") by ftp.linux-mips.org with ESMTP id S3458391AbVLHVAu (ORCPT ); Thu, 8 Dec 2005 21:00:50 +0000 Received: from SSVLGW01.amd.com (ssvlgw01.amd.com [139.95.250.169]) by amdext3.amd.com (8.12.11/8.12.11/AMD) with ESMTP id jB8L0MSP029272; Thu, 8 Dec 2005 13:00:37 -0800 Received: from 139.95.250.1 by SSVLGW01.amd.com with ESMTP (AMD SMTP Relay (Email Firewall v6.1.0)); Thu, 08 Dec 2005 13:00:26 -0800 X-Server-Uuid: 89466532-923C-4A88-82C1-66ACAA0041DF Received: from ldcmail.amd.com (ldcmail.amd.com [147.5.200.40]) by amdint.amd.com (8.12.8/8.12.8/AMD) with ESMTP id jB8L0PGF011039; Thu, 8 Dec 2005 13:00:25 -0800 (PST) Received: from cosmic.amd.com (cosmic.amd.com [147.5.201.206]) by ldcmail.amd.com (Postfix) with ESMTP id 549FE201E; Thu, 8 Dec 2005 14:00:25 -0700 (MST) Received: from cosmic.amd.com (localhost [127.0.0.1]) by cosmic.amd.com (8.13.4/8.13.4) with ESMTP id jB8L0gov018376; Thu, 8 Dec 2005 14:00:42 -0700 Received: (from jcrouse@localhost) by cosmic.amd.com ( 8.13.4/8.13.4/Submit) id jB8L0gLV018375; Thu, 8 Dec 2005 14:00:42 -0700 Date: Thu, 8 Dec 2005 14:00:42 -0700 From: "Jordan Crouse" To: linux-mips@linux-mips.org cc: linux-usb-devel@lists.sourceforge.net, matthias.lenk@amd.com Subject: ALCHEMY: AU1200 USB Host Controller (OHCI/EHCI) Message-ID: <20051208210042.GB17458@cosmic.amd.com> MIME-Version: 1.0 User-Agent: Mutt/1.5.11 X-WSS-ID: 6F8641601FS785599-01-01 Content-Type: multipart/mixed; boundary="ikeVEW9yuYc//A+q" 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: 9641 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 --ikeVEW9yuYc//A+q Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: 7bit Ok, here we go. I give you the OHCI/EHCI host controller support for the Alchemy AU1200 processor. I'm sending this up, partly because I have it ready to go, but also because it seems that enough folks are getting their hands on AU1200 parts to make this a hot topic. Special thanks to Pete Popov and his merry band of kernel hackers for paving the way by pushing to seperate EHCI and PCI in the USB subsystem. Note that the AU1200 does support UDC/OTG as well, but thats another patch for another day. :) Jordan --ikeVEW9yuYc//A+q Content-Type: text/plain; charset=us-ascii Content-Disposition: inline; filename=usb_host.patch Content-Transfer-Encoding: 7bit ALCHEMY: Add Au1200 support for OHCI and EHCI Add the Au1200 platform to the alchemy OHCI and EHCI drivers. Signed-off-by: Jordan Crouse --- arch/mips/au1000/common/cputable.c | 2 arch/mips/au1000/common/platform.c | 4 drivers/usb/Kconfig | 8 - drivers/usb/Makefile | 7 drivers/usb/core/Kconfig | 5 drivers/usb/core/hcd.c | 13 + drivers/usb/core/hcd.h | 4 drivers/usb/core/hub.c | 76 ++++- drivers/usb/core/usb.c | 63 ++++ drivers/usb/host/Kconfig | 2 drivers/usb/host/ehci-au1xxx.c | 304 ++++++++++++++++++++ drivers/usb/host/ehci-hcd.c | 81 +++++ drivers/usb/host/ehci-hub.c | 74 +++++ drivers/usb/host/ehci.h | 8 + drivers/usb/host/ohci-au1xxx.c | 109 ++++++- drivers/usb/host/ohci-hcd.c | 73 +++++ drivers/usb/host/ohci-hub.c | 56 ++++ drivers/usb/host/ohci-pci.c | 4 drivers/usb/host/ohci.h | 1 include/asm-mips/mach-mips/cpu-feature-overrides.h | 4 include/linux/usb.h | 7 21 files changed, 861 insertions(+), 44 deletions(-) diff --git a/arch/mips/au1000/common/cputable.c b/arch/mips/au1000/common/cputable.c index 4dbde82..d8df5fd 100644 --- a/arch/mips/au1000/common/cputable.c +++ b/arch/mips/au1000/common/cputable.c @@ -38,7 +38,7 @@ struct cpu_spec cpu_specs[] = { { 0xffffffff, 0x02030204, "Au1100 BE", 0, 1 }, { 0xffffffff, 0x03030200, "Au1550 AA", 0, 1 }, { 0xffffffff, 0x04030200, "Au1200 AB", 0, 0 }, - { 0xffffffff, 0x04030201, "Au1200 AC", 0, 1 }, + { 0xffffffff, 0x04030201, "Au1200 AC", 1, 0 }, { 0x00000000, 0x00000000, "Unknown Au1xxx", 1, 0 }, }; diff --git a/arch/mips/au1000/common/platform.c b/arch/mips/au1000/common/platform.c index 48d3f54..dbb4ee7 100644 --- a/arch/mips/au1000/common/platform.c +++ b/arch/mips/au1000/common/platform.c @@ -20,7 +20,7 @@ static struct resource au1xxx_usb_ohci_resources[] = { [0] = { .start = USB_OHCI_BASE, - .end = USB_OHCI_BASE + USB_OHCI_LEN, + .end = USB_OHCI_BASE + USB_OHCI_LEN - 1, .flags = IORESOURCE_MEM, }, [1] = { @@ -278,9 +278,7 @@ static struct platform_device *au1xxx_pl &au1100_lcd_device, #endif #ifdef CONFIG_SOC_AU1200 -#if 0 /* fixme */ &au1xxx_usb_ehci_device, -#endif &au1xxx_usb_gdt_device, &au1xxx_usb_otg_device, &au1200_lcd_device, diff --git a/drivers/usb/Kconfig b/drivers/usb/Kconfig index 85dacc9..bff1258 100644 --- a/drivers/usb/Kconfig +++ b/drivers/usb/Kconfig @@ -9,10 +9,16 @@ menu "USB support" # NOTE: SL-811 option should be board-specific ... config USB_ARCH_HAS_HCD boolean - default y if USB_ARCH_HAS_OHCI + default y if USB_ARCH_HAS_OHCI || USB_ARCH_HAS_EHCI default y if ARM # SL-811 default PCI +# some non-PCI hcds implement EHCI +config USB_ARCH_HAS_EHCI + boolean + default y if SOC_AU1200 + default PCI + # many non-PCI SOC chips embed OHCI config USB_ARCH_HAS_OHCI boolean diff --git a/drivers/usb/Makefile b/drivers/usb/Makefile index a50c2bc..f9642e8 100644 --- a/drivers/usb/Makefile +++ b/drivers/usb/Makefile @@ -76,3 +76,10 @@ obj-$(CONFIG_USB_SISUSBVGA) += misc/ obj-$(CONFIG_USB_ATM) += atm/ obj-$(CONFIG_USB_SPEEDTOUCH) += atm/ + + +ifneq ($(CONFIG_USB_GADGET_AMD5536UDC),y) +ifeq ($(CONFIG_USB_PORT_AMD5536OTG),y) +obj-$(CONFIG_USB) += gadget/ +endif +endif diff --git a/drivers/usb/core/Kconfig b/drivers/usb/core/Kconfig index ff03184..7293161 100644 --- a/drivers/usb/core/Kconfig +++ b/drivers/usb/core/Kconfig @@ -82,6 +82,11 @@ config USB_OTG select USB_SUSPEND default n +config USB_OTG_HIGHSPEED + bool + depends on USB_OTG + default n + config USB_OTG_WHITELIST bool "Rely on OTG Targeted Peripherals List" diff --git a/drivers/usb/core/hcd.c b/drivers/usb/core/hcd.c index da24c31..031147c 100644 --- a/drivers/usb/core/hcd.c +++ b/drivers/usb/core/hcd.c @@ -714,6 +714,7 @@ static void usb_bus_init (struct usb_bus bus->root_hub = NULL; bus->hcpriv = NULL; bus->busnum = -1; + bus->otg_port = 0; bus->bandwidth_allocated = 0; bus->bandwidth_int_reqs = 0; bus->bandwidth_isoc_reqs = 0; @@ -1830,6 +1831,12 @@ int usb_add_hcd(struct usb_hcd *hcd, rhdev->speed = (hcd->driver->flags & HCD_USB2) ? USB_SPEED_HIGH : USB_SPEED_FULL; +#if defined(CONFIG_USB_OTG) && defined(CONFIG_USB_PORT_AMD5536OTG) + if ((retval = hcd->driver->start_otg (hcd)) < 0) { + dev_warn (hcd->self.controller, "OTG init error %d\n", retval); + goto err_hcd_driver_start; + } +#endif /* Although in principle hcd->driver->start() might need to use rhdev, * none of the current drivers do. */ @@ -1855,6 +1862,9 @@ int usb_add_hcd(struct usb_hcd *hcd, err_register_root_hub: hcd->driver->stop(hcd); +#if defined(CONFIG_USB_OTG) && defined(CONFIG_USB_PORT_AMD5536OTG) + hcd->driver->stop_otg (hcd); +#endif err_hcd_driver_start: usb_put_dev(rhdev); @@ -1897,6 +1907,9 @@ void usb_remove_hcd(struct usb_hcd *hcd) del_timer_sync(&hcd->rh_timer); hcd->driver->stop(hcd); +#if defined(CONFIG_USB_OTG) && defined(CONFIG_USB_PORT_AMD5536OTG) + hcd->driver->stop_otg(hcd); +#endif hcd->state = HC_STATE_HALT; if (hcd->irq >= 0) diff --git a/drivers/usb/core/hcd.h b/drivers/usb/core/hcd.h index c8a1b35..48c6dd6 100644 --- a/drivers/usb/core/hcd.h +++ b/drivers/usb/core/hcd.h @@ -216,6 +216,10 @@ struct hc_driver { int (*bus_suspend)(struct usb_hcd *); int (*bus_resume)(struct usb_hcd *); int (*start_port_reset)(struct usb_hcd *, unsigned port_num); +#if defined(CONFIG_USB_OTG) && defined(CONFIG_USB_PORT_AMD5536OTG) + int (*start_otg)(struct usb_hcd *); + void (*stop_otg)(struct usb_hcd *); +#endif void (*hub_irq_enable)(struct usb_hcd *); /* Needed only if port-change IRQs are level-triggered */ }; diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c index f78bd12..629124e 100644 --- a/drivers/usb/core/hub.c +++ b/drivers/usb/core/hub.c @@ -1228,6 +1228,10 @@ int usb_new_device(struct usb_device *ud { int err; int c; +#ifdef CONFIG_USB_OTG_WHITELIST_RELAXED + unsigned port1 = 0; + struct usb_device *root = udev->bus->root_hub; +#endif err = usb_get_configuration(udev); if (err < 0) { @@ -1253,14 +1257,29 @@ int usb_new_device(struct usb_device *ud show_string(udev, "SerialNumber", udev->serial); #ifdef CONFIG_USB_OTG + +#ifdef CONFIG_USB_OTG_WHITELIST_RELAXED + + if (udev->parent) { + + struct usb_device *tdev = udev; + + while (tdev->parent != root) + tdev = tdev->parent; + for (port1 = 1; port1 <= root->maxchild; port1++) { + if (root->children[port1-1] == tdev) + break; + } + } + root = udev->parent; +#endif /* * OTG-aware devices on OTG-capable root hubs may be able to use SRP, * to wake us after we've powered off VBUS; and HNP, switching roles * "host" to "peripheral". The OTG descriptor helps figure this out. */ if (!udev->bus->is_b_host - && udev->config - && udev->parent == udev->bus->root_hub) { + && udev->config) { struct usb_otg_descriptor *desc = 0; struct usb_bus *bus = udev->bus; @@ -1269,6 +1288,7 @@ int usb_new_device(struct usb_device *ud le16_to_cpu(udev->config[0].desc.wTotalLength), USB_DT_OTG, (void **) &desc) == 0) { if (desc->bmAttributes & USB_OTG_HNP) { +#ifndef CONFIG_USB_OTG_WHITELIST_RELAXED unsigned port1; struct usb_device *root = udev->parent; @@ -1277,15 +1297,23 @@ int usb_new_device(struct usb_device *ud if (root->children[port1-1] == udev) break; } - - dev_info(&udev->dev, - "Dual-Role OTG device on %sHNP port\n", - (port1 == bus->otg_port) - ? "" : "non-"); - - /* enable HNP before suspend, it's simpler */ - if (port1 == bus->otg_port) +#endif + if (udev->parent != bus->root_hub) { + dev_info(&udev->dev, + "Dual-Role OTG device connected through hub(s)\n"); + bus->b_hnp_enable = 0; + } + else if (port1 == bus->otg_port) { + dev_info(&udev->dev, + "Dual-Role OTG device on HNP port\n"); bus->b_hnp_enable = 1; + } + else { + dev_info(&udev->dev, + "Dual-Role OTG device on non-HNP port\n"); + bus->b_hnp_enable = 0; + } + /* enable HNP before suspend, it's simpler */ err = usb_control_msg(udev, usb_sndctrlpipe(udev, 0), USB_REQ_SET_FEATURE, 0, @@ -1298,16 +1326,22 @@ int usb_new_device(struct usb_device *ud * customize to match your product. */ dev_info(&udev->dev, - "can't set HNP mode; %d\n", + "Device Not Responding (trying to set HNP mode: %d)\n", err); bus->b_hnp_enable = 0; + goto fail; } } } } - if (!is_targeted(udev)) { - +#ifdef CONFIG_USB_OTG_WHITELIST_RELAXED + if (port1 && (port1 == udev->bus->otg_port) \ + && !is_targeted(udev)) +#else + if (!is_targeted(udev)) +#endif + { /* Maybe it can talk to us, though we can't talk to it. * (Includes HNP test device.) */ @@ -1315,10 +1349,12 @@ int usb_new_device(struct usb_device *ud static int __usb_suspend_device(struct usb_device *, int port1); err = __usb_suspend_device(udev, udev->bus->otg_port); - if (err < 0) + if (err < 0) { dev_dbg(&udev->dev, "HNP fail, %d\n", err); + goto fail; + } } - err = -ENODEV; + err = -ENOTCONN; goto fail; } #endif @@ -2565,6 +2601,16 @@ static void hub_port_connect_change(stru } up (&udev->serialize); + +#ifdef CONFIG_USB_OTG + + /* don't want to disturb HNP: no retry */ + if ((udev->bus->is_b_host || udev->bus->b_hnp_enable) + && (status == -ENOTCONN)) + /* FIXME: rather keep the port enabled until */ + /* disconnect, but it works this way */ + goto loop; +#endif if (status) goto loop_disable; diff --git a/drivers/usb/core/usb.c b/drivers/usb/core/usb.c index e197ce9..13113b3 100644 --- a/drivers/usb/core/usb.c +++ b/drivers/usb/core/usb.c @@ -81,6 +81,11 @@ static struct device_driver usb_generic_ static int usb_generic_driver_data; +#if defined(CONFIG_USB_OTG) && defined(CONFIG_USB_PORT_AMD5536OTG) + +struct otg_transceiver * (*usb_otg_get_transceiver)(void) = NULL; +#endif + /* called from driver core with usb_bus_type.subsys writelock */ static int usb_probe_interface(struct device *dev) { @@ -1485,6 +1490,58 @@ static int usb_generic_resume(struct dev return 0; } +#if defined(CONFIG_USB_OTG) && defined(CONFIG_USB_PORT_AMD5536OTG) +/* + * To be called from OTG controller driver + */ +int usb_host_register_otg(struct otg_transceiver * (*get_transceiver)(void)) +{ + struct list_head *tmp; + struct usb_bus *bus; + struct usb_hcd *hcd; + + if (get_transceiver) { + usb_otg_get_transceiver = get_transceiver; + down (&usb_bus_list_lock); + tmp = usb_bus_list.next; + while (tmp != &usb_bus_list) { + bus = list_entry(tmp, struct usb_bus, bus_list); + tmp = tmp->next; + hcd = container_of (bus, struct usb_hcd, self); + hcd->driver->start_otg (hcd); + } + up (&usb_bus_list_lock); + pr_info("USB OTG driver registered\n"); + return 0; + } + else { + printk(KERN_ERR "can't register OTG, no device\n"); + return -ENODEV; + } +} + +void usb_host_deregister_otg(void) +{ + struct list_head *tmp; + struct usb_bus *bus; + struct usb_hcd *hcd; + + down (&usb_bus_list_lock); + tmp = usb_bus_list.next; + while (tmp != &usb_bus_list) { + bus = list_entry(tmp, struct usb_bus, bus_list); + tmp = tmp->next; + if (bus->otg_port) { + hcd = container_of (bus, struct usb_hcd, self); + hcd->driver->stop_otg (hcd); + } + } + up (&usb_bus_list_lock); + usb_otg_get_transceiver = NULL; + pr_info("USB OTG driver deregistered\n"); +} +#endif + struct bus_type usb_bus_type = { .name = "usb", .match = usb_device_match, @@ -1642,4 +1699,10 @@ EXPORT_SYMBOL (usb_buffer_dmasync_sg); #endif EXPORT_SYMBOL (usb_buffer_unmap_sg); +#if defined(CONFIG_USB_OTG) && defined(CONFIG_USB_PORT_AMD5536OTG) +EXPORT_SYMBOL(usb_host_register_otg); +EXPORT_SYMBOL(usb_host_deregister_otg); +EXPORT_SYMBOL(usb_otg_get_transceiver); +#endif + MODULE_LICENSE("GPL"); diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig index ed1899d..4a4db1a 100644 --- a/drivers/usb/host/Kconfig +++ b/drivers/usb/host/Kconfig @@ -6,7 +6,7 @@ comment "USB Host Controller Drivers" config USB_EHCI_HCD tristate "EHCI HCD (USB 2.0) support" - depends on USB && PCI + depends on USB && USB_ARCH_HAS_EHCI ---help--- The Enhanced Host Controller Interface (EHCI) is standard for USB 2.0 "high speed" (480 Mbit/sec, 60 Mbyte/sec) host controller hardware. diff --git a/drivers/usb/host/ehci-au1xxx.c b/drivers/usb/host/ehci-au1xxx.c new file mode 100644 index 0000000..32cf6e6 --- /dev/null +++ b/drivers/usb/host/ehci-au1xxx.c @@ -0,0 +1,304 @@ +/* + * EHCI HCD (Host Controller Driver) for USB. + * + * (C) Copyright 2000-2004 David Brownell + * + * Bus Glue for AMD Alchemy Au1xxx + * + * Based on "ohci-au1xxx.c" by Matt Porter + * + * Modified for AMD Alchemy Au1200 EHC + * by K.Boge + * + * This file is licenced under the GPL. + */ + +#include +#include + +#ifndef CONFIG_SOC_AU1200 +#error "Alchemy chip doesn't have EHC" +#else /* Au1200 */ + +#define USB_HOST_CONFIG (USB_MSR_BASE + USB_MSR_MCFG) +#define USB_MCFG_PFEN (1<<31) +#define USB_MCFG_RDCOMB (1<<30) +#define USB_MCFG_SSDEN (1<<23) +#define USB_MCFG_PHYPLLEN (1<<19) +#define USB_MCFG_EHCCLKEN (1<<17) +#define USB_MCFG_UCAM (1<<7) +#define USB_MCFG_EBMEN (1<<3) +#define USB_MCFG_EMEMEN (1<<2) + +#define USBH_ENABLE_CE (USB_MCFG_PHYPLLEN | USB_MCFG_EHCCLKEN) +#ifdef CONFIG_DMA_COHERENT +#define USBH_ENABLE_INIT (USBH_ENABLE_CE \ + | USB_MCFG_PFEN | USB_MCFG_RDCOMB \ + | USB_MCFG_SSDEN | USB_MCFG_UCAM \ + | USB_MCFG_EBMEN | USB_MCFG_EMEMEN) +#else +#define USBH_ENABLE_INIT (USBH_ENABLE_CE \ + | USB_MCFG_PFEN | USB_MCFG_RDCOMB \ + | USB_MCFG_SSDEN \ + | USB_MCFG_EBMEN | USB_MCFG_EMEMEN) +#endif +#define USBH_DISABLE (USB_MCFG_EBMEN | USB_MCFG_EMEMEN) + +#endif /* Au1200 */ + +extern int usb_disabled(void); + +/*-------------------------------------------------------------------------*/ + +static void au1xxx_start_ehc(struct platform_device *dev) +{ + pr_debug(__FILE__ ": starting Au1xxx EHCI USB Controller\n"); + + /* write HW defaults again in case Yamon cleared them */ + if (au_readl(USB_HOST_CONFIG) == 0) { + au_writel(0x00d02000, USB_HOST_CONFIG); + au_readl(USB_HOST_CONFIG); + udelay(1000); + } + /* enable host controller */ + au_writel(USBH_ENABLE_CE | au_readl(USB_HOST_CONFIG), USB_HOST_CONFIG); + au_readl(USB_HOST_CONFIG); + udelay(1000); + au_writel(USBH_ENABLE_INIT | au_readl(USB_HOST_CONFIG), USB_HOST_CONFIG); + au_readl(USB_HOST_CONFIG); + udelay(1000); + + pr_debug(__FILE__ ": Clock to USB host has been enabled\n"); +} + +static void au1xxx_stop_ehc(struct platform_device *dev) +{ + pr_debug(__FILE__ ": stopping Au1xxx EHCI USB Controller\n"); + + /* Disable mem */ + au_writel(~USBH_DISABLE & au_readl(USB_HOST_CONFIG), USB_HOST_CONFIG); + udelay(1000); + /* Disable clock */ + au_writel(~USB_MCFG_EHCCLKEN & au_readl(USB_HOST_CONFIG), USB_HOST_CONFIG); + au_readl(USB_HOST_CONFIG); +} + +/*-------------------------------------------------------------------------*/ + +/* configure so an HC device and id are always provided */ +/* always called with process context; sleeping is OK */ + + +/** + * usb_ehci_au1xxx_probe - initialize Au1xxx-based HCDs + * Context: !in_interrupt() + * + * Allocates basic resources for this USB host controller, and + * then invokes the start() method for the HCD associated with it + * through the hotplug entry's driver_data. + * + */ +int usb_ehci_au1xxx_probe (const struct hc_driver *driver, + struct usb_hcd **hcd_out, + struct platform_device *dev) +{ + int retval; + struct usb_hcd *hcd; + +#if defined(CONFIG_SOC_AU1200) && defined(CONFIG_DMA_COHERENT) + + /* Au1200 AB USB does not support coherent memory */ + if (!(read_c0_prid() & 0xff)) { + pr_info ("Au1200 ohci: !!! This is chip revision AB !!!\n"); + pr_info (" !!! update your board or re-configure the kernel !!!\n"); + return -ENODEV; + } +#endif + + if (dev->resource[1].flags != IORESOURCE_IRQ) { + pr_debug ("resource[1] is not IORESOURCE_IRQ"); + retval = -ENOMEM; + } + + hcd = usb_create_hcd(driver, &dev->dev, "Au1xxx"); + if (!hcd) + return -ENOMEM; + hcd->rsrc_start = dev->resource[0].start; + hcd->rsrc_len = dev->resource[0].end - dev->resource[0].start + 1; + + if (!request_mem_region(hcd->rsrc_start, hcd->rsrc_len, hcd_name)) { + pr_debug("request_mem_region failed"); + retval = -EBUSY; + goto err1; + } + + hcd->regs = ioremap(hcd->rsrc_start, hcd->rsrc_len); + if (!hcd->regs) { + pr_debug("ioremap failed"); + retval = -ENOMEM; + goto err2; + } + + au1xxx_start_ehc(dev); + + if ((retval = driver->reset (hcd)) < 0) { + pr_debug ("can't reset hc\n"); + goto err3; + } + + /* ehci_hcd_init(hcd_to_ehci(hcd)); */ + + retval = usb_add_hcd(hcd, dev->resource[1].start, SA_INTERRUPT | SA_SHIRQ); + if (retval == 0) + return retval; + + err3: + au1xxx_stop_ehc(dev); + iounmap(hcd->regs); + err2: + release_mem_region(hcd->rsrc_start, hcd->rsrc_len); + err1: + usb_put_hcd(hcd); + return retval; +} + + +/* may be called without controller electrically present */ +/* may be called with controller, bus, and devices active */ + +/** + * usb_ehci_hcd_au1xxx_remove - shutdown processing for Au1xxx-based HCDs + * @dev: USB Host Controller being removed + * Context: !in_interrupt() + * + * Reverses the effect of usb_ehci_hcd_au1xxx_probe(), first invoking + * the HCD's stop() method. It is always called from a thread + * context, normally "rmmod", "apmd", or something similar. + * + */ +void usb_ehci_au1xxx_remove (struct usb_hcd *hcd, struct platform_device *dev) +{ + usb_remove_hcd(hcd); + au1xxx_stop_ehc(dev); + iounmap(hcd->regs); + release_mem_region(hcd->rsrc_start, hcd->rsrc_len); + usb_put_hcd(hcd); +} + +/*-------------------------------------------------------------------------*/ + +static const struct hc_driver ehci_au1xxx_hc_driver = { + .description = hcd_name, + .product_desc = "Au1xxx EHCI", + .hcd_priv_size = sizeof(struct ehci_hcd), + + /* + * generic hardware linkage + */ + .irq = ehci_irq, + .flags = HCD_MEMORY | HCD_USB2, + + /* + * basic lifecycle operations + */ + .reset = ehci_init, + .start = ehci_run, +#ifdef CONFIG_PM + /* suspend: ehci_au1xxx_suspend, -- tbd */ + /* resume: ehci_au1xxx_resume, -- tbd */ +#endif /*CONFIG_PM*/ + .stop = ehci_stop, + + /* + * managing i/o requests and associated device resources + */ + .urb_enqueue = ehci_urb_enqueue, + .urb_dequeue = ehci_urb_dequeue, + .endpoint_disable = ehci_endpoint_disable, + + /* + * scheduling support + */ + .get_frame_number = ehci_get_frame, + + /* + * root hub support + */ + .hub_status_data = ehci_hub_status_data, + .hub_control = ehci_hub_control, +#ifdef CONFIG_USB_SUSPEND + .hub_suspend = ehci_hub_suspend, + .hub_resume = ehci_hub_resume, +#endif + .start_port_reset = ehci_start_port_reset, +#ifdef CONFIG_USB_OTG_HIGHSPEED + .start_otg = ehci_start_otg, + .stop_otg = ehci_stop_otg, +#endif +}; + +/*-------------------------------------------------------------------------*/ + +static int ehci_hcd_au1xxx_drv_probe(struct device *dev) +{ + struct platform_device *pdev = to_platform_device(dev); + struct usb_hcd *hcd = NULL; + int ret; + + pr_debug ("In ehci_hcd_au1xxx_drv_probe\n"); + + if (usb_disabled()) + return -ENODEV; + + ret = usb_ehci_au1xxx_probe(&ehci_au1xxx_hc_driver, &hcd, pdev); + return ret; +} + +static int ehci_hcd_au1xxx_drv_remove(struct device *dev) +{ + struct platform_device *pdev = to_platform_device(dev); + struct usb_hcd *hcd = dev_get_drvdata(dev); + + usb_ehci_au1xxx_remove(hcd, pdev); + return 0; +} + /*TBD*/ +/*static int ehci_hcd_au1xxx_drv_suspend(struct device *dev) +{ + struct platform_device *pdev = to_platform_device(dev); + struct usb_hcd *hcd = dev_get_drvdata(dev); + + return 0; +} +static int ehci_hcd_au1xxx_drv_resume(struct device *dev) +{ + struct platform_device *pdev = to_platform_device(dev); + struct usb_hcd *hcd = dev_get_drvdata(dev); + + return 0; +} +*/ + +static struct device_driver ehci_hcd_au1xxx_driver = { + .name = "au1xxx-ehci", + .bus = &platform_bus_type, + .probe = ehci_hcd_au1xxx_drv_probe, + .remove = ehci_hcd_au1xxx_drv_remove, + /*.suspend = ehci_hcd_au1xxx_drv_suspend, */ + /*.resume = ehci_hcd_au1xxx_drv_resume, */ +}; + +static int __init ehci_hcd_au1xxx_init (void) +{ + pr_debug (DRIVER_INFO " (Au1xxx)\n"); + + return driver_register(&ehci_hcd_au1xxx_driver); +} + +static void __exit ehci_hcd_au1xxx_cleanup (void) +{ + driver_unregister(&ehci_hcd_au1xxx_driver); +} + +module_init (ehci_hcd_au1xxx_init); +module_exit (ehci_hcd_au1xxx_cleanup); diff --git a/drivers/usb/host/ehci-hcd.c b/drivers/usb/host/ehci-hcd.c index 29f52a4..2b431ef 100644 --- a/drivers/usb/host/ehci-hcd.c +++ b/drivers/usb/host/ehci-hcd.c @@ -40,6 +40,7 @@ #include #include #include +#include #include #include @@ -124,6 +125,11 @@ static const char hcd_name [] = "ehci_hc #define EHCI_ASYNC_JIFFIES (HZ/20) /* async idle timeout */ #define EHCI_SHRINK_JIFFIES (HZ/200) /* async qh unlink delay */ +#if (EHCI_SHRINK_JIFFIES < 1) +#undef EHCI_SHRINK_JIFFIES +#define EHCI_SHRINK_JIFFIES 1 +#endif + /* Initial IRQ latency: faster than hw default */ static int log2_irq_thresh = 0; // 0 to 6 module_param (log2_irq_thresh, int, S_IRUGO); @@ -418,7 +424,7 @@ static int ehci_init(struct usb_hcd *hcd u32 temp; int retval; u32 hcc_params; - + spin_lock_init(&ehci->lock); init_timer(&ehci->watchdog); @@ -573,6 +579,66 @@ static int ehci_run (struct usb_hcd *hcd /*-------------------------------------------------------------------------*/ +#if defined(CONFIG_USB_OTG_HIGHSPEED) && defined(CONFIG_USB_PORT_AMD5536OTG) + +static int ehci_start_otg (struct usb_hcd *hcd) +{ + struct ehci_hcd *ehci = hcd_to_ehci (hcd); + + if (!hcd->self.otg_port) { + hcd->self.otg_port = USB_OTG_PORT; + ehci->power_budget = OTG_PWR_BUDGET; + } + if (usb_otg_get_transceiver) { + ehci->transceiver = usb_otg_get_transceiver(); + if (ehci->transceiver) { + int status; + + if (ehci->transceiver->host) { + ehci_err (ehci, "OTG already registered\n"); + return -EBUSY; + } + ehci->transceiver->host = &hcd->self; + hcd->self.hand_over = 0; + status = ehci->transceiver->set_host( + ehci->transceiver, &hcd->self); + + ehci_dbg (ehci, "init %s transceiver, status %d\n", + ehci->transceiver->label, status); + + /* if (status) + put_device(ehci->transceiver->dev); */ + return status; + } + else { + ehci_err (ehci, "can't find transceiver\n"); + return -ENODEV; + } + } + else { + ehci_info (ehci, "OTG driver not loaded\n"); + return 0; + } +} + +static void ehci_stop_otg (struct usb_hcd *hcd) +{ + struct ehci_hcd *ehci = hcd_to_ehci (hcd); + + ehci_dbg (ehci, "clean up %s transceiver\n", + ehci->transceiver->label); + if (ehci->transceiver) { + ehci->transceiver->host = NULL; + ehci->transceiver->set_host(ehci->transceiver, NULL); + } + ehci->transceiver = NULL; + ehci->power_budget = 0; + hcd->self.otg_port = 0; +} +#endif + +/*-------------------------------------------------------------------------*/ + static irqreturn_t ehci_irq (struct usb_hcd *hcd, struct pt_regs *regs) { struct ehci_hcd *ehci = hcd_to_ehci (hcd); @@ -884,20 +950,23 @@ static int ehci_get_frame (struct usb_hc { struct ehci_hcd *ehci = hcd_to_ehci (hcd); return (readl (&ehci->regs->frame_index) >> 3) % ehci->periodic_size; +#if defined(CONFIG_USB_OTG_HIGHSPEED) && defined(CONFIG_USB_PORT_AMD5536OTG) + .start_otg = ehci_start_otg, + .stop_otg = ehci_stop_otg, +#endif } /*-------------------------------------------------------------------------*/ #define DRIVER_INFO DRIVER_VERSION " " DRIVER_DESC - MODULE_DESCRIPTION (DRIVER_INFO); MODULE_AUTHOR (DRIVER_AUTHOR); MODULE_LICENSE ("GPL"); -#ifdef CONFIG_PCI +#if defined(CONFIG_SOC_AU1X00) +#include "ehci-au1xxx.c" +#elif defined(CONFIG_PCI) #include "ehci-pci.c" -#endif - -#if !defined(CONFIG_PCI) +#else #error "missing bus glue for ehci-hcd" #endif diff --git a/drivers/usb/host/ehci-hub.c b/drivers/usb/host/ehci-hub.c index 82caf33..26e070d 100644 --- a/drivers/usb/host/ehci-hub.c +++ b/drivers/usb/host/ehci-hub.c @@ -201,6 +201,17 @@ static int check_reset_complete ( port_status |= PORT_OWNER; port_status &= ~PORT_RWC_BITS; writel (port_status, &ehci->regs->port_status [index]); + +#if defined(CONFIG_USB_OTG_HIGHSPEED) && defined(CONFIG_USB_PORT_AMD5536OTG) + + if (ehci->transceiver && + ((index + 1) == ehci_to_hcd(ehci)->self.otg_port) && + (ehci->transceiver->companion)) { + ehci->transceiver->companion->hand_over = 1; + usb_bus_start_enum (ehci->transceiver->companion, + ehci->transceiver->companion->otg_port); + } +#endif } else ehci_dbg (ehci, "port %d high speed\n", index + 1); @@ -304,6 +315,59 @@ ehci_hub_descriptor ( /*-------------------------------------------------------------------------*/ +#ifdef CONFIG_USB_OTG_HIGHSPEED + +static int ehci_start_port_reset (struct usb_hcd *hcd, unsigned port) +{ + struct ehci_hcd *ehci = hcd_to_ehci (hcd); + u32 status; + + if (!port) + return -EINVAL; + port--; + + /* start port reset before HNP protocol times out */ + status = readl (&ehci->regs->port_status [port]); + if (status & PORT_RESUME) + return -EINVAL; + + if (!(status & PORT_CONNECT)) + return -ENODEV; + + status |= PORT_RESET; + status &= ~(PORT_PE | PORT_CSC); /* PORT_CSC for khubd notification */ + ehci->reset_done [port] = jiffies + msecs_to_jiffies (50); + writel (status, &ehci->regs->port_status [port]); + return 0; +} + +#ifdef CONFIG_USB_PORT_AMD5536OTG + +static void start_hnp (struct ehci_hcd *ehci) +{ + const unsigned port = ehci_to_hcd(ehci)->self.otg_port - 1; + unsigned long flags; + u32 status; + + otg_start_hnp (ehci->transceiver); + local_irq_save (flags); + status = readl (&ehci->regs->port_status [port]); + if (!(status & PORT_OWNER) && (status & PORT_PE)) + writel (status | PORT_SUSPEND, &ehci->regs->port_status [port]); + local_irq_restore (flags); +} +#endif + +static void start_hnp (struct ehci_hcd *ehci); + +#else + +#define ehci_start_port_reset NULL + +#endif + +/*-------------------------------------------------------------------------*/ + #define PORT_WAKE_BITS (PORT_WKOC_E|PORT_WKDISC_E|PORT_WKCONN_E) static int ehci_hub_control ( @@ -517,10 +581,20 @@ static int ehci_hub_control ( if ((temp & PORT_PE) == 0 || (temp & PORT_RESET) != 0) goto error; +#ifdef CONFIG_USB_OTG_HIGHSPEED + if (hcd->self.otg_port == (wIndex + 1) + && hcd->self.b_hnp_enable) + start_hnp(ehci); + else { +#endif + if (hcd->remote_wakeup) temp |= PORT_WAKE_BITS; writel (temp | PORT_SUSPEND, &ehci->regs->port_status [wIndex]); +#ifdef CONFIG_USB_OTG_HIGHSPEED + } +#endif break; case USB_PORT_FEAT_POWER: if (HCS_PPC (ehci->hcs_params)) diff --git a/drivers/usb/host/ehci.h b/drivers/usb/host/ehci.h index 18e257c..d762443 100644 --- a/drivers/usb/host/ehci.h +++ b/drivers/usb/host/ehci.h @@ -75,6 +75,14 @@ struct ehci_hcd { /* one per controlle /* per root hub port */ unsigned long reset_done [EHCI_MAX_ROOT_PORTS]; +#ifdef CONFIG_USB_OTG_HIGHSPEED + /* + * OTG controller needs software interaction + */ + struct otg_transceiver *transceiver; + unsigned power_budget; +#endif + /* per-HC memory pools (could be per-bus, but ...) */ struct dma_pool *qh_pool; /* qh per active urb */ struct dma_pool *qtd_pool; /* one or more per qh */ diff --git a/drivers/usb/host/ohci-au1xxx.c b/drivers/usb/host/ohci-au1xxx.c index 486202d..a5f2dfe 100644 --- a/drivers/usb/host/ohci-au1xxx.c +++ b/drivers/usb/host/ohci-au1xxx.c @@ -19,9 +19,10 @@ */ #include - #include +#ifndef CONFIG_SOC_AU1200 + #define USBH_ENABLE_BE (1<<0) #define USBH_ENABLE_C (1<<1) #define USBH_ENABLE_E (1<<2) @@ -36,16 +37,46 @@ #error not byte order defined #endif +#else /* Au1200 */ + +#define USB_HOST_CONFIG (USB_MSR_BASE + USB_MSR_MCFG) +#define USB_MCFG_PFEN (1<<31) +#define USB_MCFG_RDCOMB (1<<30) +#define USB_MCFG_SSDEN (1<<23) +#define USB_MCFG_OHCCLKEN (1<<16) +#define USB_MCFG_UCAM (1<<7) +#define USB_MCFG_OBMEN (1<<1) +#define USB_MCFG_OMEMEN (1<<0) + +#define USBH_ENABLE_CE USB_MCFG_OHCCLKEN +#ifdef CONFIG_DMA_COHERENT +#define USBH_ENABLE_INIT (USB_MCFG_OHCCLKEN \ + | USB_MCFG_PFEN | USB_MCFG_RDCOMB \ + | USB_MCFG_SSDEN | USB_MCFG_UCAM \ + | USB_MCFG_OBMEN | USB_MCFG_OMEMEN) +#else +#define USBH_ENABLE_INIT (USB_MCFG_OHCCLKEN \ + | USB_MCFG_PFEN | USB_MCFG_RDCOMB \ + | USB_MCFG_SSDEN \ + | USB_MCFG_OBMEN | USB_MCFG_OMEMEN) +#endif +#define USBH_DISABLE (USB_MCFG_OBMEN | USB_MCFG_OMEMEN) + +#endif /* Au1200 */ + extern int usb_disabled(void); /*-------------------------------------------------------------------------*/ -static void au1xxx_start_hc(struct platform_device *dev) +static void au1xxx_start_ohc(struct platform_device *dev) { printk(KERN_DEBUG __FILE__ ": starting Au1xxx OHCI USB Controller\n"); /* enable host controller */ + +#ifndef CONFIG_SOC_AU1200 + au_writel(USBH_ENABLE_CE, USB_HOST_CONFIG); udelay(1000); au_writel(USBH_ENABLE_INIT, USB_HOST_CONFIG); @@ -56,17 +87,46 @@ static void au1xxx_start_hc(struct platf !(au_readl(USB_HOST_CONFIG) & USBH_ENABLE_RD)) udelay(1000); +#else /* Au1200 */ + + /* write HW defaults again in case Yamon cleared them */ + if (au_readl(USB_HOST_CONFIG) == 0) { + au_writel(0x00d02000, USB_HOST_CONFIG); + au_readl(USB_HOST_CONFIG); + udelay(1000); + } + au_writel(USBH_ENABLE_CE | au_readl(USB_HOST_CONFIG), USB_HOST_CONFIG); + au_readl(USB_HOST_CONFIG); + udelay(1000); + au_writel(USBH_ENABLE_INIT | au_readl(USB_HOST_CONFIG), USB_HOST_CONFIG); + au_readl(USB_HOST_CONFIG); + udelay(1000); + +#endif /* Au1200 */ + printk(KERN_DEBUG __FILE__ ": Clock to USB host has been enabled \n"); } -static void au1xxx_stop_hc(struct platform_device *dev) +static void au1xxx_stop_ohc(struct platform_device *dev) { printk(KERN_DEBUG __FILE__ ": stopping Au1xxx OHCI USB Controller\n"); +#ifndef CONFIG_SOC_AU1200 + /* Disable clock */ au_writel(readl((void *)USB_HOST_CONFIG) & ~USBH_ENABLE_CE, USB_HOST_CONFIG); + +#else /* Au1200 */ + + /* Disable mem */ + au_writel(~USBH_DISABLE & au_readl(USB_HOST_CONFIG), USB_HOST_CONFIG); + udelay(1000); + /* Disable clock */ + au_writel(~USBH_ENABLE_CE & au_readl(USB_HOST_CONFIG), USB_HOST_CONFIG); + au_readl(USB_HOST_CONFIG); +#endif /* Au1200 */ } @@ -85,14 +145,24 @@ static void au1xxx_stop_hc(struct platfo * through the hotplug entry's driver_data. * */ -int usb_hcd_au1xxx_probe (const struct hc_driver *driver, +int usb_ohci_au1xxx_probe (const struct hc_driver *driver, struct platform_device *dev) { int retval; struct usb_hcd *hcd; +#if defined(CONFIG_SOC_AU1200) && defined(CONFIG_DMA_COHERENT) + + /* Au1200 AB USB does not support coherent memory */ + if (!(read_c0_prid() & 0xff)) { + pr_info ("Au1200 ohci: !!! This is chip revision AB !!!\n"); + pr_info (" !!! update your board or re-configure the kernel !!!\n"); + return -ENODEV; + } +#endif + if (dev->resource[1].flags != IORESOURCE_IRQ) { - pr_debug ("resource[1] is not IORESOURCE_IRQ"); + pr_debug ("resource[1] is not IORESOURCE_IRQ\n"); retval = -ENOMEM; } @@ -103,26 +173,26 @@ int usb_hcd_au1xxx_probe (const struct h hcd->rsrc_len = dev->resource[0].end - dev->resource[0].start + 1; if (!request_mem_region(hcd->rsrc_start, hcd->rsrc_len, hcd_name)) { - pr_debug("request_mem_region failed"); + pr_debug("request_mem_region failed\n"); retval = -EBUSY; goto err1; } hcd->regs = ioremap(hcd->rsrc_start, hcd->rsrc_len); if (!hcd->regs) { - pr_debug("ioremap failed"); + pr_debug("ioremap failed\n"); retval = -ENOMEM; goto err2; } - au1xxx_start_hc(dev); + au1xxx_start_ohc(dev); ohci_hcd_init(hcd_to_ohci(hcd)); - retval = usb_add_hcd(hcd, dev->resource[1].start, SA_INTERRUPT); + retval = usb_add_hcd(hcd, dev->resource[1].start, SA_INTERRUPT | SA_SHIRQ); if (retval == 0) return retval; - au1xxx_stop_hc(dev); + au1xxx_stop_ohc(dev); iounmap(hcd->regs); err2: release_mem_region(hcd->rsrc_start, hcd->rsrc_len); @@ -145,10 +215,10 @@ int usb_hcd_au1xxx_probe (const struct h * context, normally "rmmod", "apmd", or something similar. * */ -void usb_hcd_au1xxx_remove (struct usb_hcd *hcd, struct platform_device *dev) +void usb_ohci_au1xxx_remove (struct usb_hcd *hcd, struct platform_device *dev) { usb_remove_hcd(hcd); - au1xxx_stop_hc(dev); + au1xxx_stop_ohc(dev); iounmap(hcd->regs); release_mem_region(hcd->rsrc_start, hcd->rsrc_len); usb_put_hcd(hcd); @@ -216,11 +286,15 @@ static const struct hc_driver ohci_au1xx */ .hub_status_data = ohci_hub_status_data, .hub_control = ohci_hub_control, -#ifdef CONFIG_PM - .bus_suspend = ohci_bus_suspend, - .bus_resume = ohci_bus_resume, +#ifdef CONFIG_USB_SUSPEND + .hub_suspend = ohci_hub_suspend, + .hub_resume = ohci_hub_resume, #endif .start_port_reset = ohci_start_port_reset, +#ifdef CONFIG_USB_OTG + .start_otg = ohci_start_otg, + .stop_otg = ohci_stop_otg, +#endif }; /*-------------------------------------------------------------------------*/ @@ -234,7 +308,7 @@ static int ohci_hcd_au1xxx_drv_probe(str if (usb_disabled()) return -ENODEV; - ret = usb_hcd_au1xxx_probe(&ohci_au1xxx_hc_driver, pdev); + ret = usb_ohci_au1xxx_probe(&ohci_au1xxx_hc_driver, pdev); return ret; } @@ -242,7 +316,7 @@ static int ohci_hcd_au1xxx_drv_remove(st { struct usb_hcd *hcd = platform_get_drvdata(pdev); - usb_hcd_au1xxx_remove(hcd, pdev); + usb_ohci_au1xxx_remove(hcd, pdev); return 0; } /*TBD*/ @@ -287,3 +361,4 @@ static void __exit ohci_hcd_au1xxx_clean module_init (ohci_hcd_au1xxx_init); module_exit (ohci_hcd_au1xxx_cleanup); + diff --git a/drivers/usb/host/ohci-hcd.c b/drivers/usb/host/ohci-hcd.c index b8efc6e..b610ea5 100644 --- a/drivers/usb/host/ohci-hcd.c +++ b/drivers/usb/host/ohci-hcd.c @@ -879,6 +879,79 @@ static int ohci_restart (struct ohci_hcd /*-------------------------------------------------------------------------*/ +#if defined(CONFIG_USB_OTG) && (CONFIG_USB_PORT_AMD5536OTG) + +static int ohci_start_otg (struct usb_hcd *hcd) +{ + struct ohci_hcd *ohci = hcd_to_ohci (hcd); + + if (!hcd->self.otg_port) { + hcd->self.otg_port = USB_OTG_PORT; + ohci->power_budget = OTG_PWR_BUDGET; + } + if (usb_otg_get_transceiver) { + ohci->transceiver = usb_otg_get_transceiver(); + if (ohci->transceiver) { + int status; + +#ifdef CONFIG_USB_OTG_HIGHSPEED + if (ohci->transceiver->companion) { + ohci_err (ohci, "OTG already registered\n"); + return -EBUSY; + } + ohci->transceiver->companion = &hcd->self; + hcd->self.hand_over = 0; +#else + if (ohci->transceiver->host) { + ohci_err (ohci, "OTG already registered\n"); + return -EBUSY; + } + ohci->transceiver->host = &hcd->self; +#endif + status = ohci->transceiver->set_host( + ohci->transceiver, &hcd->self); + + ohci_dbg(ohci, "init %s transceiver, status %d\n", + ohci->transceiver->label, status); + + /* if (status) + put_device(ohci->transceiver->dev); */ + return status; + } + else { + ohci_err (ohci, "can't find transceiver\n"); + return -ENODEV; + } + } + else { + ohci_info (ohci, "OTG driver not loaded\n"); + return 0; + } +} + +static void ohci_stop_otg (struct usb_hcd *hcd) +{ + struct ohci_hcd *ohci = hcd_to_ohci (hcd); + + if (ohci->transceiver) { + ohci_dbg (ohci, "clean up %s transceiver\n", + ohci->transceiver->label); +#ifdef CONFIG_USB_OTG_HIGHSPEED + ohci->transceiver->companion = NULL; +#else + ohci->transceiver->host = NULL; +#endif + ohci->transceiver->set_host(ohci->transceiver, NULL); + ohci->transceiver = NULL; + ohci->power_budget = 0; + hcd->self.otg_port = 0; + } +} + +#endif + +/*-------------------------------------------------------------------------*/ + #define DRIVER_INFO DRIVER_VERSION " " DRIVER_DESC MODULE_AUTHOR (DRIVER_AUTHOR); diff --git a/drivers/usb/host/ohci-hub.c b/drivers/usb/host/ohci-hub.c index 72e3b12..31a8a0d 100644 --- a/drivers/usb/host/ohci-hub.c +++ b/drivers/usb/host/ohci-hub.c @@ -431,13 +431,31 @@ static int ohci_start_port_reset (struct { struct ohci_hcd *ohci = hcd_to_ohci (hcd); u32 status; + int usec = 500; /* 500 usec handshake time */ if (!port) return -EINVAL; port--; /* start port reset before HNP protocol times out */ +#ifdef CONFIG_USB_OTG_HIGHSPEED + + if (hcd->self.hand_over && (port + 1 == hcd->self.otg_port)) { + udelay (usec); + usec = 0; + status = ohci_readl (ohci, &ohci->regs->roothub.portstatus [port]); + } + else { +#endif status = ohci_readl(ohci, &ohci->regs->roothub.portstatus [port]); + while (usec && !(status & RH_PS_CCS)) { + status = ohci_readl (ohci, &ohci->regs->roothub.portstatus [port]); + usec--; + udelay(1); + } +#ifdef CONFIG_USB_OTG_HIGHSPEED + } +#endif if (!(status & RH_PS_CCS)) return -ENODEV; @@ -446,8 +464,29 @@ static int ohci_start_port_reset (struct return 0; } +#ifdef CONFIG_USB_PORT_AMD5536OTG + +static void start_hnp (struct ohci_hcd *ohci) +{ + const unsigned port = ohci_to_hcd(ohci)->self.otg_port - 1; + unsigned long flags; + u32 status; + + otg_start_hnp (ohci->transceiver); + + local_irq_save (flags); + status = ohci_readl (ohci, &ohci->regs->roothub.portstatus [port]); + if (status & RH_PS_PES) + ohci_writel (ohci, RH_PS_PSS, + &ohci->regs->roothub.portstatus [port]); + local_irq_restore (flags); +} +#else + static void start_hnp(struct ohci_hcd *ohci); +#endif + #else #define ohci_start_port_reset NULL @@ -482,10 +521,27 @@ static inline void root_port_reset (stru u16 now = ohci_readl(ohci, &ohci->regs->fmnumber); u16 reset_done = now + PORT_RESET_MSEC; +#ifdef CONFIG_USB_OTG + struct usb_hcd *hcd = ohci_to_hcd (ohci); +#endif + /* build a "continuous enough" reset signal, with up to * 3msec gap between pulses. scheduler HZ==100 must work; * this might need to be deadline-scheduled. */ + +#ifdef CONFIG_USB_OTG +#ifdef CONFIG_USB_OTG_HIGHSPEED + if (hcd->self.hand_over && (port + 1 == hcd->self.otg_port)) { + hcd->self.hand_over = 0; + reset_done = now + PORT_RESET_HW_MSEC - 1; + } + else +#else + if (hcd->self.is_b_host) + reset_done = now + PORT_RESET_HW_MSEC - 1; +#endif +#endif do { /* spin until any current reset finishes */ for (;;) { diff --git a/drivers/usb/host/ohci-pci.c b/drivers/usb/host/ohci-pci.c index 1b09dde..54d3afa 100644 --- a/drivers/usb/host/ohci-pci.c +++ b/drivers/usb/host/ohci-pci.c @@ -188,6 +188,10 @@ static const struct hc_driver ohci_pci_h .bus_resume = ohci_bus_resume, #endif .start_port_reset = ohci_start_port_reset, +#if defined(CONFIG_USB_OTG) && defined(CONFIG_USB_PORT_AMD5536OTG) + .start_otg = ohci_start_otg, + .stop_otg = ohci_stop_otg, +#endif }; /*-------------------------------------------------------------------------*/ diff --git a/drivers/usb/host/ohci.h b/drivers/usb/host/ohci.h index caacf14..b94717a 100644 --- a/drivers/usb/host/ohci.h +++ b/drivers/usb/host/ohci.h @@ -371,6 +371,7 @@ struct ohci_hcd { * other external transceivers should be software-transparent */ struct otg_transceiver *transceiver; + unsigned power_budget; /* * memory management for queue data structures diff --git a/include/asm-mips/mach-mips/cpu-feature-overrides.h b/include/asm-mips/mach-mips/cpu-feature-overrides.h index 9f92aed..e06af6c 100644 --- a/include/asm-mips/mach-mips/cpu-feature-overrides.h +++ b/include/asm-mips/mach-mips/cpu-feature-overrides.h @@ -29,7 +29,11 @@ /* #define cpu_has_prefetch ? */ #define cpu_has_mcheck 1 /* #define cpu_has_ejtag ? */ +#ifdef CONFIG_CPU_HAS_LLSC #define cpu_has_llsc 1 +#else +#define cpu_has_llsc 0 +#endif /* #define cpu_has_vtag_icache ? */ /* #define cpu_has_dc_aliases ? */ /* #define cpu_has_ic_fills_f_dc ? */ diff --git a/include/linux/usb.h b/include/linux/usb.h index d81b050..e71b584 100644 --- a/include/linux/usb.h +++ b/include/linux/usb.h @@ -270,6 +270,7 @@ struct usb_bus { u8 otg_port; /* 0, or number of OTG/HNP port */ unsigned is_b_host:1; /* true during some HNP roleswitches */ unsigned b_hnp_enable:1; /* OTG: did A-Host enable HNP? */ + unsigned hand_over:1; /* HS controller detected FS device */ int devnum_next; /* Next open device number in * round-robin allocation */ @@ -1015,6 +1016,12 @@ extern int usb_clear_halt(struct usb_dev extern int usb_reset_configuration(struct usb_device *dev); extern int usb_set_interface(struct usb_device *dev, int ifnum, int alternate); +#if defined(CONFIG_USB_OTG) && defined(CONFIG_USB_PORT_AMD5536OTG) +extern struct otg_transceiver * (*usb_otg_get_transceiver)(void); +extern int usb_host_register_otg (struct otg_transceiver * (*get_transceiver)(void)); +extern void usb_host_deregister_otg(void); +#endif + /* * timeouts, in milliseconds, used for sending/receiving control messages * they typically complete within a few frames (msec) after they're issued --ikeVEW9yuYc//A+q-- From redhatter@gentoo.org Fri Dec 9 14:41:25 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 09 Dec 2005 14:41:44 +0000 (GMT) Received: from 202-47-55-78.adsl.gil.com.au ([202.47.55.78]:27839 "EHLO longlandclan.hopto.org") by ftp.linux-mips.org with ESMTP id S3458514AbVLIOlZ (ORCPT ); Fri, 9 Dec 2005 14:41:25 +0000 Received: (qmail 15609 invoked from network); 10 Dec 2005 00:40:28 +1000 Received: from unknown (HELO ?10.0.0.251?) (10.0.0.251) by 192.168.5.1 with SMTP; 10 Dec 2005 00:40:28 +1000 Message-ID: <4399972C.5060604@gentoo.org> Date: Sat, 10 Dec 2005 00:39:40 +1000 From: Stuart Longland Organization: Gentoo Foundation User-Agent: Mozilla Thunderbird 1.0.7 (X11/20051029) X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-mips@linux-mips.org Subject: SGI IP28 Kernels... anyone had any luck lately? X-Enigmail-Version: 0.93.0.0 OpenPGP: id=63264AB9; url=http://dev.gentoo.org/~redhatter/gpgkey.asc Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigD35CB61B2F0F50F9AE9323E8" 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: 9642 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: redhatter@gentoo.org Precedence: bulk X-list: linux-mips This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigD35CB61B2F0F50F9AE9323E8 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Hi all, I'm not sure what's causing this error, could very well be PEBKAC, but anyways. I've been striking issues getting kernels for my IP28 to compile. So far, I've tried both the 2.6.14 and 2.6.14-rc2 tags, the IP28 patches[1] apply successfully, but the subsequent compile fails with these messages: http://pastebin.com/455158 Incidentally, the tarball you download containing the patches, apparently has a README and .config file included. Well, there's symlinks to the files, but it seems the actual files themselves got missed in the archive. I used the /proc/config.gz from my currently running kernel (2.6.12-rc2, also works with 2.6.13.4). I was hoping to try out Impact support, in console and X, as well as HAL2 support (which was b0rked last time I tried it). Has anyone had any luck, and if so, any ideas what I'm doing wrong? Regards, -- Stuart Longland (aka Redhatter) .'''. Gentoo Linux/MIPS Cobalt and Docs Developer '.'` : . . . . . . . . . . . . . . . . . . . . . . .'.' http://dev.gentoo.org/~redhatter :.' 1. http://home.alphastar.de/fuerst/download.html --------------enigD35CB61B2F0F50F9AE9323E8 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDmZcvuarJ1mMmSrkRAk0xAJ0T0Gc0tpbHi/E8CpE/2y0t6x1Y1wCdHZUA 33NwUeaST0CvGjSTEnJXEvM= =nWMF -----END PGP SIGNATURE----- --------------enigD35CB61B2F0F50F9AE9323E8-- From sshtylyov@ru.mvista.com Fri Dec 9 18:08:40 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 09 Dec 2005 18:08:58 +0000 (GMT) Received: from rtsoft2.corbina.net ([85.21.88.2]:21426 "HELO mail.dev.rtsoft.ru") by ftp.linux-mips.org with SMTP id S3458525AbVLISIk (ORCPT ); Fri, 9 Dec 2005 18:08:40 +0000 Received: (qmail 4219 invoked from network); 9 Dec 2005 18:08:31 -0000 Received: from wasted.dev.rtsoft.ru (HELO ?192.168.1.248?) (192.168.1.248) by mail.dev.rtsoft.ru with SMTP; 9 Dec 2005 18:08:31 -0000 Message-ID: <4399C8AB.4080403@ru.mvista.com> Date: Fri, 09 Dec 2005 21:10:51 +0300 From: Sergei Shtylylov Organization: MostaVista 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 , Konstantin Baidarov Subject: [PATCH] SiMotion VoyagerGX framebuffer: blue stripped background Content-Type: multipart/mixed; boundary="------------050205090103050403070109" 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: 9643 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. --------------050205090103050403070109 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hello. This driver was using an incorrect typecast when setting pseudopalette, hence were the blue strips on the black char background. As this driver happens to be maintaned by Linux/MIPS, here's the patch (I've also noticed a typo in the head comment, hence comes another hunk)... WBR, Sergei Signed-off-by: Konstantin Baydarov Signed-off-by: Sergei Shtylyov --------------050205090103050403070109 Content-Type: text/plain; name="VoyagerGX-blue-strips.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="VoyagerGX-blue-strips.patch" diff --git a/drivers/video/smivgxfb.c b/drivers/video/smivgxfb.c index d5755c5..c521069 100644 --- a/drivers/video/smivgxfb.c +++ b/drivers/video/smivgxfb.c @@ -1,5 +1,5 @@ /*************************************************************************** - * Silicon Motion VoyaagerGX framebuffer driver + * Silicon Motion VoyagerGX framebuffer driver * * ported to 2.6 by Embedded Alley Solutions, Inc * Copyright (C) 2005 Embedded Alley Solutions, Inc @@ -162,7 +162,7 @@ smi_setcolreg(unsigned regno, unsigned r if (regno > 255) return 1; - ((u16 *)(info->pseudo_palette))[regno] = + ((u32 *)(info->pseudo_palette))[regno] = ((red & 0xf800) >> 0) | ((green & 0xfc00) >> 5) | ((blue & 0xf800) >> 11); --------------050205090103050403070109-- From pf@net.alphadv.de Fri Dec 9 18:24:43 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 09 Dec 2005 18:25:03 +0000 (GMT) Received: from mail.alphastar.de ([194.59.236.179]:38927 "EHLO mail.alphastar.de") by ftp.linux-mips.org with ESMTP id S3458520AbVLISYn (ORCPT ); Fri, 9 Dec 2005 18:24:43 +0000 Received: from Snailmail (217.249.204.171) by mail.alphastar.de with MERCUR Mailserver (v4.02.28 MTIxLTIxODAtNjY2OA==) for ; Fri, 9 Dec 2005 19:21:37 +0100 Received: from Opal.Peter (Opal.Peter [192.168.1.1]) by SNaIlmail.Peter (8.12.6/8.12.6/Sendmail/Linux 2.0.32) with ESMTP id jB9IMPbf002565; Fri, 9 Dec 2005 19:22:26 +0100 Received: from Opal.Peter (localhost [127.0.0.1]) by Opal.Peter (8.12.11.Beta0/8.12.11.Beta0/Sendmail/Linux 2.4.24-1-386) with ESMTP id jB9IMHp2001605; Fri, 9 Dec 2005 19:22:17 +0100 Received: from localhost (pf@localhost) by Opal.Peter (8.12.11.Beta0/8.12.11.Beta0/Debian-1) with ESMTP id jB9IMGH4001601; Fri, 9 Dec 2005 19:22:16 +0100 Date: Fri, 9 Dec 2005 18:22:14 +0100 (CET) From: peter fuerst To: linux-mips@linux-mips.org cc: Stuart Longland Subject: Re: SGI IP28 Kernels... anyone had any luck lately? In-Reply-To: <4399972C.5060604@gentoo.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII ReSent-Date: Fri, 9 Dec 2005 19:21:52 +0100 (CET) ReSent-From: peter fuerst ReSent-To: Stuart Longland , linux-mips@linux-mips.org ReSent-Subject: Re: SGI IP28 Kernels... anyone had any luck lately? ReSent-Message-ID: Reply-To: pf@net.alphadv.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: 9644 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: pf@net.alphadv.de Precedence: bulk X-list: linux-mips Hi all, sorry, obviously forgot to "tar" with the "-h" option. The kernel patch-set is now repackaged with README and .config (same location). I wonder, why no one noticed their missing since Oct 17... For exactness' sake: the patches are based on linux-2.6.14-rc2-mipscvs-20050925 Maybe .config will enable compiling, the error-messages seem to point to a misconfiguration, since the compiler didn't touch any of the patched files yet. There's still a problem with the Xserver: often, when starting up the Xserver first after a cold boot, it likes to hang (in a loop, waiting for "dmabusy" to settle down, either in the kernel-driver or the Xserver itself, when re-mmapping the dma-buffer). Usually, after a reset the Xserver works okay. I couldn't find a solution for this yet, but otherwise (;-) i easily (can) use the machine for regular work (no more hangs after the Xserver started up once). kind regards pf On Sat, 10 Dec 2005, Stuart Longland wrote: > Date: Sat, 10 Dec 2005 00:39:40 +1000 > From: Stuart Longland > Reply-To: linux-mips-bounce@linux-mips.org > To: linux-mips@linux-mips.org > Subject: SGI IP28 Kernels... anyone had any luck lately? > > Hi all, > I'm not sure what's causing this error, could very well be PEBKAC, but > anyways. > > I've been striking issues getting kernels for my IP28 to compile. So > far, I've tried both the 2.6.14 and 2.6.14-rc2 tags, the IP28 patches[1] > apply successfully, but the subsequent compile fails with these > messages: http://pastebin.com/455158 > > Incidentally, the tarball you download containing the patches, > apparently has a README and .config file included. Well, there's > symlinks to the files, but it seems the actual files themselves got > missed in the archive. I used the /proc/config.gz from my currently > running kernel (2.6.12-rc2, also works with 2.6.13.4). > > I was hoping to try out Impact support, in console and X, as well as > HAL2 support (which was b0rked last time I tried it). > > Has anyone had any luck, and if so, any ideas what I'm doing wrong? > Regards, > -- > Stuart Longland (aka Redhatter) .'''. > Gentoo Linux/MIPS Cobalt and Docs Developer '.'` : > . . . . . . . . . . . . . . . . . . . . . . .'.' > http://dev.gentoo.org/~redhatter :.' > > 1. http://home.alphastar.de/fuerst/download.html > From joost@c-lab.de Fri Dec 9 18:29:34 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 09 Dec 2005 18:29:51 +0000 (GMT) Received: from mailserver.c-lab.de ([131.234.80.230]:30339 "EHLO mailserver.c-lab.de") by ftp.linux-mips.org with ESMTP id S3458520AbVLIS3e (ORCPT ); Fri, 9 Dec 2005 18:29:34 +0000 Received: from tintin.c-lab.de (tintin.c-lab.de [131.234.80.96]) by mailserver.c-lab.de (8.13.4/8.13.4/Debian-3) with SMTP id jB9ITOiQ017634; Fri, 9 Dec 2005 19:29:24 +0100 Message-ID: <4399CD04.2781@c-lab.de> Date: Fri, 09 Dec 2005 19:29:24 +0100 From: Michael Joosten Organization: Badlab Construction Services, Inc X-Mailer: Mozilla 3.04Gold [en] (X11; I; IRIX 6.5 IP32) MIME-Version: 1.0 To: linux-mips@linux-mips.org CC: michael.joosten@c-lab.de Subject: SGI O2: working framebuffer/X11 modes? Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.51 on 131.234.80.230 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: 9645 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: joost@c-lab.de Precedence: bulk X-list: linux-mips Hello, this actually not really a SGI MIPS question, but a rather one about the SGI 320 VisWS, which is a dual PIII thing, but it shares a lot of the framebuffer code (sgivwfb.c) with the O2 one (gbefb.c) - and I'm writing this on an O2 with IRIX. We've still have such a beast here, and I'm trying to set up a baseline of required patches for current kernels in order to get a running configuration out of the box. Because gbefb was derived from sgivwfb somewhen back in 2002, it is therefore quite interesting to see how things are going on the MIPS side, as both gfx hardware implementations are supposed to be very similar (the visws one using hardware from O2 GBE). Currently, the only VisWS mode that works under X11 is Depth 15bit, using the 2 byte/16bit ARGB5 mode in sgivwfb.c, with 1280x1024 or higher with the 1600sw LCD panel. Surprisingly, Depth 16 in /etc/X11/xorg.conf is not completely OK anymore, perhaps due to problems with the transparency bit. Anything else like 24 or 8 bit looks decidedly odd, and hard to read at all. Namely 24/32bit is completely broken, the width of the display is only 2/3 of the screen, though timing is still OK. Back to the question: What mode(s) are usable on a Linux O2? Did 24bit work at ANY time on the O2? Kind regards, Michael -- Michael Joosten, SBS C-LAB, joost@c-lab.de Fuerstenallee 11, 33094 Paderborn, Germany Phone: +49 5251 606127, Fax: +49 5251 606065 C-LAB is a cooperation of University Paderborn & SIEMENS From geoman@gentoo.org Fri Dec 9 18:51:49 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 09 Dec 2005 18:52:10 +0000 (GMT) Received: from lennier.cc.vt.edu ([198.82.162.213]:5770 "EHLO lennier.cc.vt.edu") by ftp.linux-mips.org with ESMTP id S3458528AbVLISvt (ORCPT ); Fri, 9 Dec 2005 18:51:49 +0000 Received: from zidane.cc.vt.edu (IDENT:mirapoint@evil-zidane.cc.vt.edu [10.1.1.13]) by lennier.cc.vt.edu (8.12.11/8.12.11) with ESMTP id jB9IpfWS003355; Fri, 9 Dec 2005 13:51:41 -0500 Received: from [128.173.184.73] (gs4073.geos.vt.edu [128.173.184.73]) by zidane.cc.vt.edu (MOS 3.6.4-CR) with ESMTP id ERG81100; Fri, 9 Dec 2005 13:50:59 -0500 (EST) Message-ID: <4399D209.1060301@gentoo.org> Date: Fri, 09 Dec 2005 13:50:49 -0500 From: "Stephen P. Becker" User-Agent: Mozilla Thunderbird 1.0.7 (X11/20051208) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Michael Joosten CC: linux-mips@linux-mips.org Subject: Re: SGI O2: working framebuffer/X11 modes? References: <4399CD04.2781@c-lab.de> In-Reply-To: <4399CD04.2781@c-lab.de> Content-Type: text/plain; charset=UTF-8; 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: 9646 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: geoman@gentoo.org Precedence: bulk X-list: linux-mips > We've still have such a beast here, and I'm trying to set up a baseline > of required patches for current kernels in order to get a running > configuration out of the box. Prior to the 2.6.15-rc1 import into linux-mips git, X was only useable if some variant of the gbefb patch at http://home.tal.org/~milang/o2/patches/ was used. The symptom was that the X server would start and appear to be running, but you would only have a black screen as the output. There was the additional oddity that even with this patch applied, X would do the old black screen thing for anybody with greater than 256mb, but less than 768mb of RAM (introduced by the ip32 full memory patch which went into the linux-mips tree in the past year or so). In 2.6.15, now we only need the following change for X to work, and there seems to be no restrictions on the amount of RAM under which X will run: --- drivers/video/gbefb.c.orig 2005-11-22 09:26:05 -0500 +++ drivers/video/gbefb.c 2005-11-22 08:16:58 -0500 @@ -1244,7 +1244,7 @@ (void *)gbe_tiles.cpu, gbe_tiles.dma); release_mem_region(GBE_BASE, sizeof(struct sgi_gbe)); iounmap(gbe); - gbefb_remove_sysfs(dev); + gbefb_remove_sysfs(&p_dev->dev); framebuffer_release(info); return 0; Another oddity which has plagued gbefb on O2 is that allocating more than 4mb of memory to gbefb causes it to fail outright. The kernel will boot and userland comes up, but the framebuffer never initializes. > Currently, the only VisWS mode that works under X11 is Depth 15bit, > using the 2 byte/16bit ARGB5 mode in sgivwfb.c, with 1280x1024 > or higher with the 1600sw LCD panel. Interesting, because everything I have heard from folks who have tried to use 1600sw with their O2s say that it doesn't work at all. In any case, X runs just fine at every single resolution I have tried, including 640x480, 800x600, 1024x768, and 1280x1024. Basically, if you have a working framebuffer at any particular resolution (I usually pass it at boot time via something like video=gbefb:1280x1024-16@85), X will run at that resolution, no problem, since we are just using the fbdev X driver. > Surprisingly, Depth 16 in > /etc/X11/xorg.conf is not completely OK anymore, perhaps due > to problems with the transparency bit. Anything else like 24 > or 8 bit looks decidedly odd, and hard to read at all. > Namely 24/32bit is completely broken, the width of the > display is only 2/3 of the screen, though timing is still OK. To my knowledge, running X in anything but 15bit depth has never worked on O2. I have attempted to start my O2 up with gbefb running at various depths other than 16, and they always fail, defaulting back to 640x480 at 16bpp (or occasionally even hanging the kernel). Attempting to force some depth in the X config file always screwed things up whenever I attempted this. Furthermore, it seems like the new modular X.org is smarter about probing the framebuffer capabilities, and totally ignores the depth you specify in xorg.conf, defaulting straight to 15. > Back to the question: What mode(s) are usable on a Linux O2? > Did 24bit work at ANY time on the O2? Not as far as I can tell. -Steve From sshtylyov@ru.mvista.com Fri Dec 9 20:27:13 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 09 Dec 2005 20:27:30 +0000 (GMT) Received: from rtsoft2.corbina.net ([85.21.88.2]:196 "HELO mail.dev.rtsoft.ru") by ftp.linux-mips.org with SMTP id S3458535AbVLIU1N (ORCPT ); Fri, 9 Dec 2005 20:27:13 +0000 Received: (qmail 5682 invoked from network); 9 Dec 2005 20:27:13 -0000 Received: from wasted.dev.rtsoft.ru (HELO ?192.168.1.248?) (192.168.1.248) by mail.dev.rtsoft.ru with SMTP; 9 Dec 2005 20:27:13 -0000 Message-ID: <4399E92C.6010408@ru.mvista.com> Date: Fri, 09 Dec 2005 23:29:32 +0300 From: Sergei Shtylylov Organization: MostaVista 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 , Konstantin Baidarov Subject: Re: [PATCH] SiMotion VoyagerGX framebuffer: blue stripped background References: <4399C8AB.4080403@ru.mvista.com> In-Reply-To: <4399C8AB.4080403@ru.mvista.com> Content-Type: multipart/mixed; boundary="------------080605090102030609060704" 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: 9647 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. --------------080605090102030609060704 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hello. Sergei Shtylylov wrote: > This driver was using an incorrect typecast when setting pseudopalette, > hence were the blue strips on the black char background. As this driver > happens to be maintaned by Linux/MIPS, here's the patch (I've also > noticed a > typo in the head comment, hence comes another hunk)... Have noticed that regno check in smi_setcolreg() is too relaxed as pseudo-palette has only 16 entries. So, had to update the patch. WBR, Sergei Signed-off-by: Konstantin Baydarov Signed-off-by: Sergei Shtylyov --------------080605090102030609060704 Content-Type: text/plain; name="VoyagerGX-blue-strips.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="VoyagerGX-blue-strips.patch" diff --git a/drivers/video/smivgxfb.c b/drivers/video/smivgxfb.c index d5755c5..944ff4a 100644 --- a/drivers/video/smivgxfb.c +++ b/drivers/video/smivgxfb.c @@ -1,5 +1,5 @@ /*************************************************************************** - * Silicon Motion VoyaagerGX framebuffer driver + * Silicon Motion VoyagerGX framebuffer driver * * ported to 2.6 by Embedded Alley Solutions, Inc * Copyright (C) 2005 Embedded Alley Solutions, Inc @@ -159,10 +159,10 @@ smi_setcolreg(unsigned regno, unsigned r unsigned blue, unsigned transp, struct fb_info *info) { - if (regno > 255) + if (regno > 15) return 1; - ((u16 *)(info->pseudo_palette))[regno] = + ((u32 *)(info->pseudo_palette))[regno] = ((red & 0xf800) >> 0) | ((green & 0xfc00) >> 5) | ((blue & 0xf800) >> 11); @@ -318,9 +318,9 @@ static int __devinit vgx_pci_probe(struc if (!info.pseudo_palette) { return -ENOMEM; } - memset(info.pseudo_palette, 0, sizeof(u32) *16); + memset(info.pseudo_palette, 0, sizeof(u32) * 16); - fb_alloc_cmap(&info.cmap,256,0); + fb_alloc_cmap(&info.cmap, 256, 0); smi_setmode(); --------------080605090102030609060704-- From michael.joosten@c-lab.de Fri Dec 9 20:35:17 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 09 Dec 2005 20:35:36 +0000 (GMT) Received: from mailserver.c-lab.de ([131.234.80.230]:29366 "EHLO mailserver.c-lab.de") by ftp.linux-mips.org with ESMTP id S3458533AbVLIUfR (ORCPT ); Fri, 9 Dec 2005 20:35:17 +0000 Received: from [131.234.81.18] (warstein.c-lab.de [131.234.81.18]) by mailserver.c-lab.de (8.13.4/8.13.4/Debian-3) with ESMTP id jB9KZ4fS010198; Fri, 9 Dec 2005 21:35:04 +0100 Message-ID: <4399E92C.6000709@c-lab.de> Date: Fri, 09 Dec 2005 21:29:32 +0100 From: Michael Joosten Organization: Siemens C-LAB User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Stephen P. Becker" CC: linux-mips@linux-mips.org Subject: Re: SGI O2: working framebuffer/X11 modes? References: <4399CD04.2781@c-lab.de> <4399D209.1060301@gentoo.org> In-Reply-To: <4399D209.1060301@gentoo.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.51 on 131.234.80.230 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: 9648 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: michael.joosten@c-lab.de Precedence: bulk X-list: linux-mips Ups, that was fast... Stephen P. Becker wrote: > > Prior to the 2.6.15-rc1 import into linux-mips git, X was only useable > if some variant of the gbefb patch at > http://home.tal.org/~milang/o2/patches/ was used. The symptom was > that the X server would start and appear to be running, but you would > only have a black screen as the output. There was the additional > oddity that even with this patch applied, X would do the old black > screen thing for anybody with greater than 256mb, but less than 768mb > of RAM (introduced by the ip32 full memory patch which went into the > linux-mips tree in the past year or so). In 2.6.15, now we only need > the following change for X to work, and there seems to be no > restrictions on the amount of RAM under which X will run: > Another oddity which has plagued gbefb on O2 is that allocating more > than 4mb of memory to gbefb causes it to fail outright. The kernel > will boot and userland comes up, but the framebuffer never initializes. > As just today another old O2 materialized on the trash heap around here, I actually might try my luck - but it's a R10K O2, IP32. The sgivwfb driver uses by default 8MB at the highest end of phys memory, and increasing it to 16MB hasn't harmed yet. > >> Currently, the only VisWS mode that works under X11 is Depth 15bit, >> using the 2 byte/16bit ARGB5 mode in sgivwfb.c, with 1280x1024 or >> higher with the 1600sw LCD panel. > > > Interesting, because everything I have heard from folks who have tried > to use 1600sw with their O2s say that it doesn't work at all. Well, I don't have a 1600sw, and there are some internal patches in the visws mailing list of Florian Boor who added a I2C self configuration to the driver, such that entereing the monitor type by kernel cmd line argument is not necessary anymore. > In any case, X runs just fine at every single resolution I have tried, > including 640x480, 800x600, 1024x768, and 1280x1024. Basically, if > you have a working framebuffer at any particular resolution (I usually > pass it at boot time via something like video=gbefb:1280x1024-16@85), > X will run at that resolution, no problem, since we are just using the > fbdev X driver. > > OK, resolution also seems less a problem with the sgivwfb driver (though I remember a weirdness with 1024x768), but... >> Surprisingly, Depth 16 in >> /etc/X11/xorg.conf is not completely OK anymore, perhaps due to >> problems with the transparency bit. Anything else like 24 or 8 bit >> looks decidedly odd, and hard to read at all. Namely 24/32bit is >> completely broken, the width of the >> display is only 2/3 of the screen, though timing is still OK. > > > To my knowledge, running X in anything but 15bit depth has never > worked on O2. I have attempted to start my O2 up with gbefb running > at various depths other than 16, and they always fail, defaulting back > to 640x480 at 16bpp (or occasionally even hanging the kernel). > Attempting to force some depth in the X config file always screwed > things up whenever I attempted this. Furthermore, it seems like the > new modular X.org is smarter about probing the framebuffer > capabilities, and totally ignores the depth you specify in xorg.conf, > defaulting straight to 15. > ...different depths produce funny results. Haven't tried 8bit, but 24 is definitely broken. You can still see something, but barely. So, we can probably deduce that the other-than-15bit modes were never actually tested by the original author (some intern then a SGI?). Recent info about the chances to get some hardware docs about the VisWS from SGI were simply turned down by the astonishing fact that they really dumped the whole product line: hardware, contracts, subcontractors (developed the gfx drivers for Win NT) and even documentation. Speak about a deed (x86 graphics workstations) so awful that nobody at SGI wanted be remembered about it ? Thanks a bunch, Michael From geoman@gentoo.org Fri Dec 9 21:23:40 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 09 Dec 2005 21:23:58 +0000 (GMT) Received: from lennier.cc.vt.edu ([198.82.162.213]:27556 "EHLO lennier.cc.vt.edu") by ftp.linux-mips.org with ESMTP id S3458540AbVLIVXk (ORCPT ); Fri, 9 Dec 2005 21:23:40 +0000 Received: from dagger.cc.vt.edu (IDENT:mirapoint@evil-dagger.cc.vt.edu [10.1.1.11]) by lennier.cc.vt.edu (8.12.11/8.12.11) with ESMTP id jB9LNYXr013970; Fri, 9 Dec 2005 16:23:34 -0500 Received: from [128.173.184.73] (gs4073.geos.vt.edu [128.173.184.73]) by dagger.cc.vt.edu (MOS 3.6.4-CR) with ESMTP id EUJ28926; Fri, 9 Dec 2005 16:23:25 -0500 (EST) Message-ID: <4399F5C3.1050706@gentoo.org> Date: Fri, 09 Dec 2005 16:23:15 -0500 From: "Stephen P. Becker" User-Agent: Mozilla Thunderbird 1.0.7 (X11/20051208) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Michael Joosten CC: linux-mips@linux-mips.org Subject: Re: SGI O2: working framebuffer/X11 modes? References: <4399CD04.2781@c-lab.de> <4399D209.1060301@gentoo.org> <4399E92C.6000709@c-lab.de> In-Reply-To: <4399E92C.6000709@c-lab.de> Content-Type: text/plain; charset=UTF-8; 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: 9649 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: geoman@gentoo.org Precedence: bulk X-list: linux-mips > As just today another old O2 materialized on the trash heap around here, > I actually might try my luck - but it's a R10K O2, IP32. No luck there, as r10k ip32 still has the cache coherency problem, and won't run linux. > The sgivwfb driver uses by default 8MB at the highest end of phys > memory, and increasing it to 16MB hasn't harmed yet. The gbefb driver won't even let you choose more than 8mb, and I think 2mb is the default. > Well, I don't have a 1600sw, and there are some internal patches in the > visws mailing list of Florian Boor who added a I2C self configuration to > the driver, such that entereing the monitor type by kernel cmd line > argument is not necessary anymore. It would be nice to know if these help out on mips, and if so, they should probably be contributed to the linux-mips tree. I wish I had a 1600sw with which to tinker. > ...different depths produce funny results. Haven't tried 8bit, but 24 is > definitely broken. You can still see something, but barely. So, we can > probably deduce that the other-than-15bit modes were never actually > tested by the original author (some intern then a SGI?). There was actually a patch for Xfree by the original author of the sgio2fb driver (Vivien, aka glaurung, wasn't it?) which allowed X to run properly in 16bpp. However, this patch was lost in a hard drive crash if I recall. > Recent info > about the chances to get some hardware docs about the VisWS from SGI > were simply turned down by the astonishing fact that they really dumped > the whole product line: hardware, contracts, subcontractors (developed > the gfx drivers for Win NT) and even documentation. Speak about a deed > (x86 graphics workstations) so awful that nobody at SGI wanted be > remembered about it ? There are at least a couple of folks on this mailing list who I'm pretty sure know more about the specifics of this hardware. The only question is, are they allowed to talk to you about it? -Steve From david-b@pacbell.net Fri Dec 9 23:20:33 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 09 Dec 2005 23:20:51 +0000 (GMT) Received: from smtp106.sbc.mail.mud.yahoo.com ([68.142.198.205]:23178 "HELO smtp106.sbc.mail.mud.yahoo.com") by ftp.linux-mips.org with SMTP id S3458549AbVLIXUd (ORCPT ); Fri, 9 Dec 2005 23:20:33 +0000 Received: (qmail 98849 invoked from network); 9 Dec 2005 23:20:28 -0000 Received: from unknown (HELO ?10.0.0.130?) (david-b@pacbell.net@69.226.248.13 with plain) by smtp106.sbc.mail.mud.yahoo.com with SMTP; 9 Dec 2005 23:20:27 -0000 From: David Brownell To: "Vladimir A. Barinov" Subject: Re: [PATCH] Philips PNX8550 USB Host driver compile fix Date: Fri, 9 Dec 2005 15:20:26 -0800 User-Agent: KMail/1.7.1 Cc: Peter Popov , linux-mips@linux-mips.org, ralf@linux-mips.org, linux-usb-devel@lists.sourceforge.net References: <20051206193522.2582.qmail@web411.biz.mail.mud.yahoo.com> <439864A6.9070104@ru.mvista.com> In-Reply-To: <439864A6.9070104@ru.mvista.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200512091520.26719.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: 9650 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 Thursday 08 December 2005 8:51 am, Vladimir A. Barinov wrote: > Hello Ralf, David, > > Could you please advise. > What is the right solution in the situation when USB PCI and on-chip USB > used in the situation when we want ohci-hcd to be a module? > > Vladimir > > Peter Popov wrote: > > >I suppose the right solution is to be able to use the > >on-chip usb controller as well as an external pci > >controller. I don't think anyone will do that though. I'm not sure why they wouldn't. Full speed controllers have limited bandwidth, people sometimes want more than one just to get enough bandwidth to do whatever it is they need USB to help with. > >>The current ohci-hcd driver is a little defective. > >>It's unable to use usb-ohci as modules in the case > >>when PCI and on-chip USB are enabled. > >>It just will not be compiled since there are two > >>calls if module_init in ohci-hcd. I think it'd be reasonable to expect that the two options be (a) PCI version and/or (b) some SOC version. Since I've never heard of a discrete OHCI part, I'll suspect the posibillity of having several of them on some external parallel bus is low... Suggesting that what's needed is more at the level of having the module_init code call a pair of #definable routnes -- call them 'register_platform_ohci()' and 'register_pci_ohci() -- to handle either or both cases. Then #ifndef register_platform_ohci, #define it as NOP; likewise for the PCI version. And for the unregisters. I'd certainly OK merging that; it'd be general enough to work on non-PNX hardware too. - Dave From david-b@pacbell.net Sat Dec 10 05:24:06 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 10 Dec 2005 05:24:24 +0000 (GMT) Received: from smtp114.sbc.mail.mud.yahoo.com ([68.142.198.213]:12398 "HELO smtp114.sbc.mail.mud.yahoo.com") by ftp.linux-mips.org with SMTP id S8133415AbVLJFYG (ORCPT ); Sat, 10 Dec 2005 05:24:06 +0000 Received: (qmail 404 invoked from network); 10 Dec 2005 05:24:02 -0000 Received: from unknown (HELO ?10.0.0.130?) (david-b@pacbell.net@69.226.248.13 with plain) by smtp114.sbc.mail.mud.yahoo.com with SMTP; 10 Dec 2005 05:24:02 -0000 From: David Brownell To: linux-usb-devel@lists.sourceforge.net Subject: Re: [linux-usb-devel] ALCHEMY: AU1200 USB Host Controller (OHCI/EHCI) Date: Fri, 9 Dec 2005 21:13:42 -0800 User-Agent: KMail/1.7.1 Cc: "Jordan Crouse" , linux-mips@linux-mips.org, matthias.lenk@amd.com References: <20051208210042.GB17458@cosmic.amd.com> In-Reply-To: <20051208210042.GB17458@cosmic.amd.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200512092113.43536.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: 9651 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 Thursday 08 December 2005 1:00 pm, Jordan Crouse wrote: > Ok, here we go. I give you the OHCI/EHCI host controller support for > the Alchemy AU1200 processor. I'm sending this up, partly because I have > it ready to go, but also because it seems that enough folks are getting their > hands on AU1200 parts to make this a hot topic. Interesting. This is actually a couple different things ... the OTG related bits would IMO be good to split out from the EHCI ones, and from the OHCI ones. Maybe once 2.6.15 gets out you'd split these out a bit? > Special thanks to Pete Popov and his merry band of kernel hackers for > paving the way by pushing to seperate EHCI and PCI in the USB subsystem. Actually that patch started with Matt Porter, although some earlier non-mergeable versions came from ARC (now TDI). And splitting it out turned up a bunch of problems, mostly now fixed. > Note that the AU1200 does support UDC/OTG as well, but thats another patch > for another day. :) Actually you included a preview in this patch. Interesting ... that makes three OTG implementations I've seen on Linux ... the second highspeed one, too. I think you shouldn't need that OTG_HIGHSPEED symbol, given there's already USB_OTG and USB_GADGET_DUALSPEED, that's implicit. And in fact, it'd be implicit inside EHCI given just USB_OTG! That OTG stuff needs work yet. No changes should be needed, and I'm not sure what this "relaxed whitelist" is for. But by the time those answers are apparent, I expect you'll have give us mergeable patches for OHCI, EHCI, and the UDC. ;) - Dave From ppopov@embeddedalley.com Sat Dec 10 06:42:31 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 10 Dec 2005 06:42:50 +0000 (GMT) Received: from smtp103.biz.mail.mud.yahoo.com ([68.142.200.238]:65124 "HELO smtp103.biz.mail.mud.yahoo.com") by ftp.linux-mips.org with SMTP id S8133556AbVLJGmb (ORCPT ); Sat, 10 Dec 2005 06:42:31 +0000 Received: (qmail 47297 invoked from network); 10 Dec 2005 06:42:28 -0000 Received: from unknown (HELO ?192.168.1.110?) (ppopov@embeddedalley.com@63.194.214.47 with plain) by smtp103.biz.mail.mud.yahoo.com with SMTP; 10 Dec 2005 06:42:28 -0000 Subject: Re: [linux-usb-devel] ALCHEMY: AU1200 USB Host Controller (OHCI/EHCI) From: Pete Popov Reply-To: ppopov@embeddedalley.com To: David Brownell Cc: linux-usb-devel@lists.sourceforge.net, Jordan Crouse , "'linux-mips@linux-mips.org'" , matthias.lenk@amd.com In-Reply-To: <200512092113.43536.david-b@pacbell.net> References: <20051208210042.GB17458@cosmic.amd.com> <200512092113.43536.david-b@pacbell.net> Content-Type: text/plain Organization: Embedded Alley Solutions, Inc Date: Fri, 09 Dec 2005 22:42:34 -0800 Message-Id: <1134196954.4930.5.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.0.4 (2.0.4-4) 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: 9652 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 > > Special thanks to Pete Popov and his merry band of kernel hackers for > > paving the way by pushing to seperate EHCI and PCI in the USB subsystem. > > Actually that patch started with Matt Porter, although some earlier > non-mergeable versions came from ARC (now TDI). And splitting it out > turned up a bunch of problems, mostly now fixed. Matt Porter is included in the 'merry band' :) He's a partner at Embedded Alley. Pete From redhatter@gentoo.org Sat Dec 10 11:52:15 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 10 Dec 2005 11:52:34 +0000 (GMT) Received: from 202-47-55-78.adsl.gil.com.au ([202.47.55.78]:62692 "EHLO longlandclan.hopto.org") by ftp.linux-mips.org with ESMTP id S8133714AbVLJLwP (ORCPT ); Sat, 10 Dec 2005 11:52:15 +0000 Received: (qmail 1026 invoked from network); 10 Dec 2005 21:51:22 +1000 Received: from unknown (HELO ?10.0.0.251?) (10.0.0.251) by 192.168.5.1 with SMTP; 10 Dec 2005 21:51:22 +1000 Message-ID: <439AC10C.7060308@gentoo.org> Date: Sat, 10 Dec 2005 21:50:36 +1000 From: Stuart Longland Organization: Gentoo Foundation User-Agent: Mozilla Thunderbird 1.0.7 (X11/20051029) X-Accept-Language: en-us, en MIME-Version: 1.0 To: pf@net.alphadv.de CC: linux-mips@linux-mips.org Subject: Re: SGI IP28 Kernels... anyone had any luck lately? References: In-Reply-To: X-Enigmail-Version: 0.93.0.0 OpenPGP: id=63264AB9; url=http://dev.gentoo.org/~redhatter/gpgkey.asc Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig398EF8F0A927FFF921AD8C44" 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: 9653 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: redhatter@gentoo.org Precedence: bulk X-list: linux-mips This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig398EF8F0A927FFF921AD8C44 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Hi, peter fuerst wrote: > sorry, obviously forgot to "tar" with the "-h" option. The kernel patch-set > is now repackaged with README and .config (same location). I wonder, why no > one noticed their missing since Oct 17... Heh, I wondered that myself... Anyways, it's fixed now. :-) > For exactness' sake: the patches are based on linux-2.6.14-rc2-mipscvs-20050925 > Maybe .config will enable compiling, the error-messages seem to point > to a misconfiguration, since the compiler didn't touch any of the patched > files yet. I did try using the linux-2.6.14-rc2 tag out of git (repository as of 20051204; I didn't bother going to bleeding edge), but found I got the same errors. The problems disappeared, however, when I tried 2.6.14-rc1... this seems to work just fine. > indigo ~ # uname -a > Linux indigo 2.6.14-rc1-ip28 #4 Sat Dec 10 18:26:46 EST 2005 mips64 R10000 V2.5 FPU V0.0 SGI Indigo2 GNU/Linux > indigo ~ # uptime > 21:49:13 up 3:21, 3 users, load average: 2.63, 1.38, 0.71 The only glitch I've hit so far, is that booting via the local framebuffer (okay, I know it isn't a true "framebuffer") causes a fatal oops. However, if I specify console=ttyS0,9600, I see a flashing cursor on the framebuffer, and the bootup proceeds to completion on the serial console. Which is good news... it wasn't long ago when I recall merely sneezing in front of the machine was enough to send it spiralling into a fatal oops. > There's still a problem with the Xserver: often, when starting up the Xserver > first after a cold boot, it likes to hang (in a loop, waiting for "dmabusy" > to settle down, either in the kernel-driver or the Xserver itself, when > re-mmapping the dma-buffer). Usually, after a reset the Xserver works okay. > I couldn't find a solution for this yet, but otherwise (;-) i easily (can) use > the machine for regular work (no more hangs after the Xserver started up once). As I say... this Linux port has really bounded ahead in the time I've had this IP28 of mine... considering the hardware issues that have to be worked around. :-) X is my next step... for the moment though, I'm happy to be able to use a real monitor, and not a serial console. :-) -- Stuart Longland (aka Redhatter) .'''. Gentoo Linux/MIPS Cobalt and Docs Developer '.'` : . . . . . . . . . . . . . . . . . . . . . . .'.' http://dev.gentoo.org/~redhatter :.' --------------enig398EF8F0A927FFF921AD8C44 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDmsEPuarJ1mMmSrkRArWRAJ4kSLth9j/A/RV4iCWgcGvFm+n1WwCeNqsE yEd9vGwN4uv68gD1zLXc/rQ= =L5aZ -----END PGP SIGNATURE----- --------------enig398EF8F0A927FFF921AD8C44-- From ralf@linux-mips.org Sun Dec 11 16:53:26 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 11 Dec 2005 16:53:43 +0000 (GMT) Received: from extgw-uk.mips.com ([62.254.210.129]:32775 "EHLO bacchus.net.dhis.org") by ftp.linux-mips.org with ESMTP id S8133553AbVLKQx0 (ORCPT ); Sun, 11 Dec 2005 16:53:26 +0000 Received: from dea.linux-mips.net (localhost.localdomain [127.0.0.1]) by bacchus.net.dhis.org (8.13.4/8.13.1) with ESMTP id jBBGrWX2006370; Sun, 11 Dec 2005 16:53:32 GMT Received: (from ralf@localhost) by dea.linux-mips.net (8.13.4/8.13.4/Submit) id jBBGrVrS006369; Sun, 11 Dec 2005 16:53:31 GMT Date: Sun, 11 Dec 2005 16:53:31 +0000 From: Ralf Baechle To: Sergei Shtylylov Cc: Linux MIPS , Manish Lachwani , Konstantin Baidarov Subject: Re: [PATCH] SiMotion VoyagerGX framebuffer: blue stripped background Message-ID: <20051211165331.GB3164@linux-mips.org> References: <4399C8AB.4080403@ru.mvista.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4399C8AB.4080403@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: 9654 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, Dec 09, 2005 at 09:10:51PM +0300, Sergei Shtylylov wrote: > This driver was using an incorrect typecast when setting pseudopalette, > hence were the blue strips on the black char background. As this driver > happens to be maintaned by Linux/MIPS, here's the patch (I've also noticed a Framebuffer stuff to it's maintainer "Antonino A. Daplas" and linux-fbdev-devel@lists.sourceforge.net, please. Ralf From kaos@sgi.com Mon Dec 12 04:56:05 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 12 Dec 2005 04:56:24 +0000 (GMT) Received: from omx2-ext.sgi.com ([192.48.171.19]:55492 "EHLO omx2.sgi.com") by ftp.linux-mips.org with ESMTP id S8133354AbVLLE4F (ORCPT ); Mon, 12 Dec 2005 04:56:05 +0000 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by omx2.sgi.com (8.12.11/8.12.9/linux-outbound_gateway-1.1) with SMTP id jBC71EEO015846; Sun, 11 Dec 2005 23:01:15 -0800 Received: from kao2.melbourne.sgi.com (kao2.melbourne.sgi.com [134.14.55.180]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id PAA14165; Mon, 12 Dec 2005 15:55:38 +1100 X-Mailer: exmh version 2.6.3_20040314 03/14/2004 with nmh-1.1 From: Keith Owens To: linux-kernel@vger.kernel.org Cc: linux-arm-kernel@lists.arm.linux.org.uk, rmk@arm.linux.org.uk, takata@linux-m32r.org, linux-mips@linux-mips.org, parisc-linux@lists.parisc-linux.org, linux-sh@m17n.org, lethal@linux-sh.org, davem@davemloft.net, sparclinux@vger.kernel.org Subject: generic read_trylock() never tries, it always waits Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 12 Dec 2005 15:55:38 +1100 Message-ID: <9942.1134363338@kao2.melbourne.sgi.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: 9655 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: kaos@sgi.com Precedence: bulk X-list: linux-mips Copied to assorted architecture maintainers and mailing lists, please trim cc: list back to lkml plus arch if you reply. The generic version of read_trylock() never tests if the lock is in use, it always spins waiting for the lock to be free. IOW, it behaves like read_lock(). Given the different implementations of rwlock_t, it is hard for generic__raw_read_trylock() to do anything else. I strongly recommend that the architectures below define their own version of __raw_read_trylock() that really test the lock first, then we can ditch generic__raw_read_trylock(). I have already sent an ia64 patch to that mailing list. include/asm-arm/spinlock.h:#define __raw_read_trylock(lock) generic__raw_read_trylock(lock) include/asm-ia64/spinlock.h:#define __raw_read_trylock(lock) generic__raw_read_trylock(lock) include/asm-m32r/spinlock.h:#define __raw_read_trylock(lock) generic__raw_read_trylock(lock) include/asm-mips/spinlock.h:#define __raw_read_trylock(lock) generic__raw_read_trylock(lock) include/asm-parisc/spinlock.h:#define __raw_read_trylock(lock) generic__raw_read_trylock(lock) include/asm-sh/spinlock.h:#define __raw_read_trylock(lock) generic__raw_read_trylock(lock) include/asm-sparc64/spinlock.h:#define __raw_read_trylock(lock) generic__raw_read_trylock(lock) From bora.sahin@ttnet.net.tr Mon Dec 12 10:52:07 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 12 Dec 2005 10:52:27 +0000 (GMT) Received: from mail.ttnet.net.tr ([212.175.13.129]:60842 "EHLO fep01.ttnet.net.tr") by ftp.linux-mips.org with ESMTP id S3466997AbVLLKwH (ORCPT ); Mon, 12 Dec 2005 10:52:07 +0000 Received: from zenon ([85.100.59.84]) by fep01.ttnet.net.tr with ESMTP id <20051212104755.EFHG17443.fep01.ttnet.net.tr@zenon>; Mon, 12 Dec 2005 12:47:55 +0200 Date: Mon, 12 Dec 2005 12:51:25 +0200 From: Bora Sahin Reply-To: =?ISO-8859-9?B?Qm9yYSDeYWhpbg==?= X-Priority: 3 (Normal) Message-ID: <965523406.20051212125125@ttnet.net.tr> To: "Jordan Crouse" CC: linux-mips@linux-mips.org Subject: Re: ALCHEMY: AU1200 USB Host Controller (OHCI/EHCI) In-Reply-To: <20051208210042.GB17458@cosmic.amd.com> References: <20051208210042.GB17458@cosmic.amd.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-9 Content-Transfer-Encoding: 8bit X-NAI-Spam-Rules: 1 Rules triggered BAYES_00=-2.5 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: 9656 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: bora.sahin@ttnet.net.tr Precedence: bulk X-list: linux-mips Hi, Thursday, December 8, 2005, 11:00:42 PM, you wrote: Jordan> Ok, here we go. I give you the OHCI/EHCI host controller support for Jordan> the Alchemy AU1200 processor. I'm sending this up, partly because I Jordan> have it ready to go, but also because it seems that enough folks are Jordan> getting their hands on AU1200 parts to make this a hot topic. Especially, it's high time to me... :-) Jordan> Special thanks to Pete Popov and his merry band of kernel hackers for Jordan> paving the way by pushing to seperate EHCI and PCI in the USB subsystem. Me to... I have a few comments related to the OHCI part of it... diff --git a/drivers/usb/host/ohci-au1xxx.c b/drivers/usb/host/ohci-au1xxx.c +#else /* Au1200 */ + +#define USB_HOST_CONFIG (USB_MSR_BASE + USB_MSR_MCFG) +#define USB_MCFG_PFEN (1<<31) +#define USB_MCFG_RDCOMB (1<<30) +#define USB_MCFG_SSDEN (1<<23) +#define USB_MCFG_OHCCLKEN (1<<16) +#define USB_MCFG_UCAM (1<<7) +#define USB_MCFG_OBMEN (1<<1) +#define USB_MCFG_OMEMEN (1<<0) Maybe, the place where to put those defines is include/asm-mips/mach-au1x00/au1000.h? Because there are some similar defines in that file, actually shift values. For consistency, are they used?.. +#define USBH_ENABLE_CE USB_MCFG_OHCCLKEN +#ifdef CONFIG_DMA_COHERENT +#define USBH_ENABLE_INIT (USB_MCFG_OHCCLKEN \ + | USB_MCFG_PFEN | USB_MCFG_RDCOMB \ + | USB_MCFG_SSDEN | USB_MCFG_UCAM \ Aha! What I was lacking in my patch was USB_MCFG_UCAM! For test, I added it to my patch, and it worked! Reserved in the doc. So do USB_MCFG_PFEN and USB_MCFG_RDCOMB. What's the meaning of that fields? +#else /* Au1200 */ + + /* write HW defaults again in case Yamon cleared them */ + if (au_readl(USB_HOST_CONFIG) == 0) { + au_writel(0x00d02000, USB_HOST_CONFIG); + au_readl(USB_HOST_CONFIG); + udelay(1000); + } + au_writel(USBH_ENABLE_CE | au_readl(USB_HOST_CONFIG), USB_HOST_CONFIG); + au_readl(USB_HOST_CONFIG); + udelay(1000); + au_writel(USBH_ENABLE_INIT | au_readl(USB_HOST_CONFIG), USB_HOST_CONFIG); + au_readl(USB_HOST_CONFIG); + udelay(1000); Are au_readl() and udelay() necessary between the two au_writel()? Just for curiosity, I tried it without them and as it seems, it worked! -- Bora SAHIN From giometti@enneenne.com Mon Dec 12 20:41:01 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 12 Dec 2005 20:41:19 +0000 (GMT) Received: from 81-174-11-161.f5.ngi.it ([81.174.11.161]:46525 "EHLO goldrake.enneenne.com") by ftp.linux-mips.org with ESMTP id S8134336AbVLLUlB (ORCPT ); Mon, 12 Dec 2005 20:41:01 +0000 Received: from hulk.enneenne.com ([192.168.32.38] helo=localhost.localdomain ident=Debian-exim) by goldrake.enneenne.com with esmtp (Exim 4.54) id 1EluBf-0001kX-2v for linux-mips@linux-mips.org; Mon, 12 Dec 2005 21:22:21 +0100 Received: from giometti by localhost.localdomain with local (Exim 4.54) id 1EluTL-0004oE-Iz for linux-mips@linux-mips.org; Mon, 12 Dec 2005 21:40:35 +0100 Date: Mon, 12 Dec 2005 21:40:35 +0100 From: Rodolfo Giometti To: linux-mips@linux-mips.org Message-ID: <20051212204035.GL5132@hulk.enneenne.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Organization: Programmi e soluzioni GNU/Linux X-PGP-Key: gpg --keyserver keyserver.penguin.de --recv-keys D25A5633 User-Agent: Mutt/1.5.9i X-SA-Exim-Connect-IP: 192.168.32.38 X-SA-Exim-Mail-From: giometti@enneenne.com Subject: advice on JTAG 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: 9657 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'm looking for a good JTAG system to debug a MIPS AU1100 based board. I'd like to have the possibility to put hardware and software break points in u-boot and linux source code. Also I prefere a system who completely supports the GNU/Linux system as host. Can you please suggest me some links? :) Thanks in advance, 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 wd@denx.de Mon Dec 12 20:47:50 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 12 Dec 2005 20:48:09 +0000 (GMT) Received: from mail-out.m-online.net ([212.18.0.9]:28623 "EHLO mail-out.m-online.net") by ftp.linux-mips.org with ESMTP id S8133561AbVLLUru (ORCPT ); Mon, 12 Dec 2005 20:47:50 +0000 Received: from mail01.m-online.net (svr21.m-online.net [192.168.3.149]) by mail-out.m-online.net (Postfix) with ESMTP id 29DED707DB; Mon, 12 Dec 2005 21:48:09 +0100 (CET) X-Auth-Info: RZkLzvwwc5bJR3JRqsRUpwhQeQj5KkzHbuuowkI1cNs= X-Auth-Info: RZkLzvwwc5bJR3JRqsRUpwhQeQj5KkzHbuuowkI1cNs= Received: from mail.denx.de (p549661B8.dip.t-dialin.net [84.150.97.184]) by smtp-auth.mnet-online.de (Postfix) with ESMTP id 1058E93E01; Mon, 12 Dec 2005 21:48:09 +0100 (CET) Received: from atlas.denx.de (atlas.denx.de [10.0.0.14]) by mail.denx.de (Postfix) with ESMTP id 64D55180019; Mon, 12 Dec 2005 21:48:08 +0100 (MET) Received: from atlas.denx.de (localhost.localdomain [127.0.0.1]) by atlas.denx.de (Postfix) with ESMTP id 4A664353A44; Mon, 12 Dec 2005 21:48:08 +0100 (MET) To: Rodolfo Giometti cc: linux-mips@linux-mips.org From: Wolfgang Denk Subject: Re: advice on JTAG Mime-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 8bit In-reply-to: Your message of "Mon, 12 Dec 2005 21:40:35 +0100." <20051212204035.GL5132@hulk.enneenne.com> Date: Mon, 12 Dec 2005 21:48:08 +0100 Message-Id: <20051212204808.4A664353A44@atlas.denx.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: 9658 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: wd@denx.de Precedence: bulk X-list: linux-mips In message <20051212204035.GL5132@hulk.enneenne.com> you wrote: > > I'm looking for a good JTAG system to debug a MIPS AU1100 based > board. Abatron BDI2000... > I'd like to have the possibility to put hardware and software break > points in u-boot and linux source code. Also I prefere a system who > completely supports the GNU/Linux system as host. ...with firmware "bdiGDB". > Can you please suggest me some links? :) http://www.abatron.ch/products/xr/aspx/r.1/Sv.63713d7b43526570313d7b693d394f54565743484b33513244474b394a594556537d7d/rx/products_detail.htm Best regards, Wolfgang Denk -- Software Engineering: Embedded and Realtime Systems, Embedded Linux Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de Faith may be defined briefly as an illogical belief in the occurence of the improbable. - H. L. Mencken From ed@okerson.com Mon Dec 12 21:11:47 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 12 Dec 2005 21:12:07 +0000 (GMT) Received: from 69-149-250-3.ded.swbell.net ([69.149.250.3]:31403 "EHLO optic.calpha.com") by ftp.linux-mips.org with ESMTP id S8133566AbVLLVLr (ORCPT ); Mon, 12 Dec 2005 21:11:47 +0000 Received: from mail.okerson.com (optic [127.0.0.1]) by optic.calpha.com (8.12.11/8.12.11) with ESMTP id jBCLIFi5016032 for ; Mon, 12 Dec 2005 15:18:16 -0600 Received: from 85.156.192.79 (proxying for 127.0.0.1) (SquirrelMail authenticated user ed) by mail.okerson.com with HTTP; Mon, 12 Dec 2005 23:18:16 +0200 (EET) Message-ID: <53743.85.156.192.79.1134422296.squirrel@mail.okerson.com> In-Reply-To: <20051212204808.4A664353A44@atlas.denx.de> References: Your message of "Mon, 12 Dec 2005 21:40:35 +0100." <20051212204035.GL5132@hulk.enneenne.com> <20051212204808.4A664353A44@atlas.denx.de> Date: Mon, 12 Dec 2005 23:18:16 +0200 (EET) Subject: Re: advice on JTAG From: "Ed Okerson" To: linux-mips@linux-mips.org User-Agent: SquirrelMail/1.4.4 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal 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: 9659 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: ed@okerson.com Precedence: bulk X-list: linux-mips I'll second that. I own at least 6 different JTAG adapters for different processors, and the BDI2000 is the best hands down. Ed Okerson > In message <20051212204035.GL5132@hulk.enneenne.com> you wrote: >> >> I'm looking for a good JTAG system to debug a MIPS AU1100 based >> board. > > Abatron BDI2000... > >> I'd like to have the possibility to put hardware and software break >> points in u-boot and linux source code. Also I prefere a system who >> completely supports the GNU/Linux system as host. > > ...with firmware "bdiGDB". > >> Can you please suggest me some links? :) > > http://www.abatron.ch/products/xr/aspx/r.1/Sv.63713d7b43526570313d7b693d394f54565743484b33513244474b394a594556537d7d/rx/products_detail.htm > > Best regards, > > Wolfgang Denk > > -- > Software Engineering: Embedded and Realtime Systems, Embedded Linux > Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de > Faith may be defined briefly as an illogical belief in the occurence > of the improbable. - H. L. Mencken > From clem.taylor@gmail.com Mon Dec 12 21:33:48 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 12 Dec 2005 21:34:05 +0000 (GMT) Received: from xproxy.gmail.com ([66.249.82.195]:39015 "EHLO xproxy.gmail.com") by ftp.linux-mips.org with ESMTP id S8133566AbVLLVds (ORCPT ); Mon, 12 Dec 2005 21:33:48 +0000 Received: by xproxy.gmail.com with SMTP id s14so1126774wxc for ; Mon, 12 Dec 2005 13:34:05 -0800 (PST) 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; b=t1v/0hYabmjPKtBVNoXhBs37j7dSeWDLUMCJk8dmPkUc+uR/yGiFI9zIGBMYHWPMfDR+5WK4eVXiOGcg6ZhdDWATku+Fe42uyATsXoxx97i3mzr82CiOdZPZzNZBdE0dBmUFOuuIBsFgw8IL7t0LA7g8NsfZRkaRezpzREVHX8o= Received: by 10.70.46.17 with SMTP id t17mr9861914wxt; Mon, 12 Dec 2005 13:34:03 -0800 (PST) Received: by 10.70.30.10 with HTTP; Mon, 12 Dec 2005 13:34:03 -0800 (PST) Message-ID: Date: Mon, 12 Dec 2005 16:34:03 -0500 From: Clem Taylor To: linux-mips@linux-mips.org Subject: mprotect(PROT_NONE) doesn't prevent reading/writing on 2.6.14 Au1550 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_20475_3385653.1134423243152" 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: 9660 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: clem.taylor@gmail.com Precedence: bulk X-list: linux-mips ------=_Part_20475_3385653.1134423243152 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi, It seems that mprotect(PROT_NONE) isn't actually doing anything on my 2.6.14 au1550 system. Attached is a simple test that allocates 64K (64K aligned), reads/writes the buffer, mprotect(PROT_NONE) the buffer and then attempts to read and write to the buffer a second time. I expected that writing to a PROT_NONE page would result in a segfault, but on the Au1550 the program runs without faulting. Running the same code on x86 (2.6.13) segfaults as expected. Is there some reason why mprotect() wouldn't work on the Au1550, or is this a bug? Thanks, Clem Taylor ------=_Part_20475_3385653.1134423243152 Content-Type: text/x-csrc; name=mprotectTest.c; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="mprotectTest.c" #include #include #include #include #include #include int main ( int argc, char *argv [ ] ) { int size = 65536, i, ret; unsigned char *buffer; /* allocate 64K, 64K aligned */ buffer = memalign ( size, size ); if ( buffer == NULL ) { fprintf ( stderr, "memalign() failed.\n" ); return 1; } fprintf ( stderr, "buffer=%p size=%d\n", buffer, size ); /* write and read buffer */ memset ( buffer, 0xAA, size ); for ( i = 0; i < 2; i++ ) fprintf ( stderr, "buffer [ %d ] = 0x%02X\n", i, buffer [ i ] ); /* disable reading and writing */ ret = mprotect ( buffer, size, PROT_NONE ); if ( ret != 0 ) { fprintf ( stderr, "mprotect(%p,%d,PROT_NONE) failed: %s\n", buffer, size, strerror ( errno ) ); return 1; } /* write buffer, should segfault */ memset ( buffer, 0x55, size ); /* read buffer, should segfault */ for ( i = 0; i < 2; i++ ) fprintf ( stderr, "buffer [ %d ] = 0x%02X\n", i, buffer [ i ] ); return 0; } ------=_Part_20475_3385653.1134423243152-- From ppopov@embeddedalley.com Tue Dec 13 04:52:18 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 13 Dec 2005 04:52:36 +0000 (GMT) Received: from smtp101.biz.mail.mud.yahoo.com ([68.142.200.236]:33395 "HELO smtp101.biz.mail.mud.yahoo.com") by ftp.linux-mips.org with SMTP id S8126515AbVLMEwS (ORCPT ); Tue, 13 Dec 2005 04:52:18 +0000 Received: (qmail 56580 invoked from network); 13 Dec 2005 04:52:32 -0000 Received: from unknown (HELO ?192.168.1.110?) (ppopov@embeddedalley.com@63.194.214.47 with plain) by smtp101.biz.mail.mud.yahoo.com with SMTP; 13 Dec 2005 04:52:32 -0000 Subject: Re: mprotect(PROT_NONE) doesn't prevent reading/writing on 2.6.14 Au1550 From: Pete Popov Reply-To: ppopov@embeddedalley.com To: Clem Taylor Cc: "'linux-mips@linux-mips.org'" In-Reply-To: References: Content-Type: text/plain Organization: Embedded Alley Solutions, Inc Date: Mon, 12 Dec 2005 20:52:36 -0800 Message-Id: <1134449556.5151.2.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.0.4 (2.0.4-4) 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: 9661 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 Mon, 2005-12-12 at 16:34 -0500, Clem Taylor wrote: > Hi, > > It seems that mprotect(PROT_NONE) isn't actually doing anything on my > 2.6.14 au1550 system. > > Attached is a simple test that allocates 64K (64K aligned), > reads/writes the buffer, mprotect(PROT_NONE) the buffer and then > attempts to read and write to the buffer a second time. I expected > that writing to a PROT_NONE page would result in a segfault, but on > the Au1550 the program runs without faulting. Running the same code on > x86 (2.6.13) segfaults as expected. > > Is there some reason why mprotect() wouldn't work on the Au1550, or is > this a bug? Do you have another MIPS system you can test this on? Pete From colin@realtek.com.tw Tue Dec 13 09:27:44 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 13 Dec 2005 09:28:02 +0000 (GMT) Received: from mf2.realtek.com.tw ([220.128.56.22]:9482 "EHLO mf2.realtek.com.tw") by ftp.linux-mips.org with ESMTP id S8133519AbVLMJ1o (ORCPT ); Tue, 13 Dec 2005 09:27:44 +0000 Received: from msx.realtek.com.tw (unverified [172.21.1.77]) by mf2.realtek.com.tw (Clearswift SMTPRS 5.1.7) with ESMTP id for ; Tue, 13 Dec 2005 17:30:25 +0800 Received: from rtpdii3098 ([172.21.98.16]) by msx.realtek.com.tw (Lotus Domino Release 6.5.3) with ESMTP id 2005121317280651-53657 ; Tue, 13 Dec 2005 17:28:06 +0800 Message-ID: <017301c5ffc7$80383830$106215ac@realtek.com.tw> From: "colin" To: Subject: To put Linux kernel as closer as possible to 0x80000000 Date: Tue, 13 Dec 2005 17:27:56 +0800 MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1506 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 X-MIMETrack: Itemize by SMTP Server on msx/Realtek(Release 6.5.3|September 14, 2004) at 2005/12/13 =?Bog5?B?pFWkyCAwNToyODowNg==?=, Serialize by Router on msx/Realtek(Release 6.5.3|September 14, 2004) at 2005/12/13 =?Bog5?B?pFWkyCAwNToyODowOQ==?=, Serialize complete at 2005/12/13 =?Bog5?B?pFWkyCAwNToyODowOQ==?= Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="big5" 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: 9662 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: colin@realtek.com.tw Precedence: bulk X-list: linux-mips Hi all, We want to put Linux kernel as closer as possible to the bottom of memory. I know that there is some stuff put in the beginning of memory, like Exception table. So, what's the closest address to 0x80000000 that is allowable to store kernel? Regards, Colin From yyuasa@gmail.com Tue Dec 13 09:39:42 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 13 Dec 2005 09:40:02 +0000 (GMT) Received: from zproxy.gmail.com ([64.233.162.199]:65428 "EHLO zproxy.gmail.com") by ftp.linux-mips.org with ESMTP id S8133521AbVLMJjm convert rfc822-to-8bit (ORCPT ); Tue, 13 Dec 2005 09:39:42 +0000 Received: by zproxy.gmail.com with SMTP id z3so1615152nzf for ; Tue, 13 Dec 2005 01:40:03 -0800 (PST) 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=L7UpsrffeOmK/U+lw6M440iWnWxmTpxuYXKaFgaK8HPkfBiEnD/iRMk6/q4c/yHcIMlcv0q5f0ooDrTQYO1SHpZufR/fzoOeQksFB7igSF98+YPJlOIk1T2nevbiYBdkJSestGoq+p1j28PSx+J5rqoxjQTgU3ytCWpoGFwR2yI= Received: by 10.36.222.58 with SMTP id u58mr7078585nzg; Tue, 13 Dec 2005 01:40:02 -0800 (PST) Received: by 10.36.57.4 with HTTP; Tue, 13 Dec 2005 01:40:02 -0800 (PST) Message-ID: <4955666b0512130140i4829be04s@mail.gmail.com> Date: Tue, 13 Dec 2005 18:40:02 +0900 From: Yoichi Yuasa To: colin Subject: Re: To put Linux kernel as closer as possible to 0x80000000 Cc: linux-mips@linux-mips.org In-Reply-To: <017301c5ffc7$80383830$106215ac@realtek.com.tw> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT Content-Disposition: inline References: <017301c5ffc7$80383830$106215ac@realtek.com.tw> 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: 9663 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: yyuasa@gmail.com Precedence: bulk X-list: linux-mips Hi It has no problem. Kernel has reserved space for exception handlers. Yoichi 2005/12/13, colin : > > Hi all, > We want to put Linux kernel as closer as possible to the bottom of memory. > I know that there is some stuff put in the beginning of memory, like > Exception table. > So, what's the closest address to 0x80000000 that is allowable to store > kernel? > > Regards, > Colin > > > > > > From florian.delizy@sagem.com Tue Dec 13 12:27:50 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 13 Dec 2005 12:28:07 +0000 (GMT) Received: from ns1.sagem.com ([62.160.59.65]:61761 "EHLO mx1.sagem.com") by ftp.linux-mips.org with ESMTP id S8133551AbVLMM1u (ORCPT ); Tue, 13 Dec 2005 12:27:50 +0000 To: Yoichi Yuasa Cc: colin , linux-mips@linux-mips.org Subject: =?ISO-8859-1?Q?R=E9f=2E_=3A_Re=3A_To_put_Linux_kernel_as_closer_as?= =?ISO-8859-1?Q?_possible_to_0x80000000?= MIME-Version: 1.0 Message-ID: From: Florian DELIZY Date: Tue, 13 Dec 2005 13:28:01 +0100 Content-Type: multipart/alternative; boundary="=_alternative 00447CD5C12570D6_=" 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: 9664 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: florian.delizy@sagem.com Precedence: bulk X-list: linux-mips Message en plusieurs parties au format MIME --=_alternative 00447CD5C12570D6_= Content-Type: text/plain; charset="us-ascii" > Yoichi Yuasa wrote : > Hi > > It has no problem. > Kernel has reserved space for exception handlers. > > Yoichi > > 2005/12/13, colin : > > > > Hi all, > > We want to put Linux kernel as closer as possible to the bottom of memory. > > I know that there is some stuff put in the beginning of memory, like > > Exception table. > > So, what's the closest address to 0x80000000 that is allowable to store > > kernel? You should just take care to start after reserved exception/interruption vectors 0x80000000 : TLB Refull 0x80000080 : General Exception Vector + 32 instructions. Depending on your architecture, those addresses may vary (I don't know anything about MIPS64 BTW, what's your arch ? -- Florian -----BEGIN GEEK CODE BLOCK----- GCS:GE:GM/ d? s-:+ a-- C+++ U(BLUAVHISX)++++ P++++ L++++ E--- W+++ N+++ o++++ w--- O M V PS PE- PGP++ t 5 X+++ R+++ tv- b+ BI++++ D+++ G e+++ h-- r+++ y+++ -----END GEEK CODE BLOC------ --=_alternative 00447CD5C12570D6_= Content-Type: text/html; charset="us-ascii"

> Yoichi Yuasa wrote :
> Hi
>
> It has no problem.
> Kernel has reserved space for exception handlers.
>
> Yoichi
>
> 2005/12/13, colin <colin@realtek.com.tw>:
> >
> > Hi all,
> > We want to put Linux kernel as closer as possible to the bottom of memory.
> > I know that there is some stuff put in the beginning of memory, like
> > Exception table.
> > So, what's the closest address to 0x80000000 that is allowable to store
> > kernel?


You should just take care to start after reserved exception/interruption vectors

0x80000000 : TLB Refull
0x80000080 : General Exception Vector

+ 32 instructions.

Depending on your architecture, those addresses may vary (I don't know anything about MIPS64

BTW, what's your arch ?

-- Florian

-----BEGIN GEEK CODE BLOCK-----
GCS:GE:GM/ d? s-:+ a-- C+++
U(BLUAVHISX)++++ P++++ L++++
E--- W+++ N+++ o++++ w--- O M V
PS PE- PGP++ t 5 X+++ R+++ tv-
b+ BI++++ D+++ G e+++ h-- r+++ y+++
-----END GEEK CODE BLOC------
--=_alternative 00447CD5C12570D6_=-- From colin@realtek.com.tw Wed Dec 14 03:11:31 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 14 Dec 2005 03:11:50 +0000 (GMT) Received: from mf2.realtek.com.tw ([220.128.56.22]:29456 "EHLO mf2.realtek.com.tw") by ftp.linux-mips.org with ESMTP id S8134360AbVLNDLb (ORCPT ); Wed, 14 Dec 2005 03:11:31 +0000 Received: from msx.realtek.com.tw (unverified [172.21.1.77]) by mf2.realtek.com.tw (Clearswift SMTPRS 5.1.7) with ESMTP id ; Wed, 14 Dec 2005 11:14:17 +0800 Received: from rtpdii3098 ([172.21.98.16]) by msx.realtek.com.tw (Lotus Domino Release 6.5.3) with ESMTP id 2005121411115927-66069 ; Wed, 14 Dec 2005 11:11:59 +0800 Message-ID: <01f101c6005c$1faf2100$106215ac@realtek.com.tw> From: "colin" To: "Yoichi Yuasa" , "Florian DELIZY" Cc: References: Subject: =?iso-8859-1?Q?Re:_R=E9f._:_Re:_To_put_Linux_kernel_as_closer_as_possible?= =?iso-8859-1?Q?_to_0x80000000?= Date: Wed, 14 Dec 2005 11:11:49 +0800 MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1506 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 X-MIMETrack: Itemize by SMTP Server on msx/Realtek(Release 6.5.3|September 14, 2004) at 2005/12/14 =?Bog5?B?pFekyCAxMToxMTo1OQ==?=, Serialize by Router on msx/Realtek(Release 6.5.3|September 14, 2004) at 2005/12/14 =?Bog5?B?pFekyCAxMToxMjowMQ==?=, Serialize complete at 2005/12/14 =?Bog5?B?pFekyCAxMToxMjowMQ==?= Content-Type: multipart/alternative; boundary="----=_NextPart_000_01EE_01C6009F.2DCDA610" 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: 9665 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: colin@realtek.com.tw Precedence: bulk X-list: linux-mips This is a multi-part message in MIME format. ------=_NextPart_000_01EE_01C6009F.2DCDA610 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1" Hi Florian, We use MIPS 4kec. Linux runs in Interrupt Compatibility Mode, and it will use 0x80000200 = to store the "Jump" instruction. Therefore, we can move Linux kernel to 0x80000204. Is it right? Another new question. If we modify Linux to use Ventored Interrupt mode, = can we gain much performance? Regards, Colin ----- Original Message -----=20 From: Florian DELIZY=20 To: Yoichi Yuasa=20 Cc: colin ; linux-mips@linux-mips.org=20 Sent: Tuesday, December 13, 2005 8:28 PM Subject: R=E9f. : Re: To put Linux kernel as closer as possible to = 0x80000000 > Yoichi Yuasa wrote :=20 > Hi > > It has no problem. > Kernel has reserved space for exception handlers. >=20 > Yoichi >=20 > 2005/12/13, colin : > > > > Hi all, > > We want to put Linux kernel as closer as possible to the bottom of = memory. > > I know that there is some stuff put in the beginning of memory, = like > > Exception table. > > So, what's the closest address to 0x80000000 that is allowable to = store > > kernel?=20 You should just take care to start after reserved = exception/interruption vectors=20 0x80000000 : TLB Refull=20 0x80000080 : General Exception Vector=20 + 32 instructions.=20 Depending on your architecture, those addresses may vary (I don't know = anything about MIPS64=20 BTW, what's your arch ?=20 -- Florian=20 -----BEGIN GEEK CODE BLOCK-----=20 GCS:GE:GM/ d? s-:+ a-- C+++=20 U(BLUAVHISX)++++ P++++ L++++=20 E--- W+++ N+++ o++++ w--- O M V=20 PS PE- PGP++ t 5 X+++ R+++ tv-=20 b+ BI++++ D+++ G e+++ h-- r+++ y+++=20 -----END GEEK CODE BLOC------=20 ------=_NextPart_000_01EE_01C6009F.2DCDA610 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="iso-8859-1"
 
Hi = Florian,
We use MIPS = 4kec.
Linux runs in = Interrupt Compatibility Mode, and it will use=20 0x80000200 to store the "Jump" instruction.
Therefore, we can = move Linux kernel to 0x80000204. Is it=20 right?
 
Another new question. = If we modify Linux to use Ventored=20 Interrupt mode, can we gain much performance?
 
Regards,
Colin
 
----- = Original Message -----
From:=20 Florian DELIZY
Cc: = colin ; linux-mips@linux-mips.org =
Sent: Tuesday, December 13, = 2005 8:28=20 PM
Subject: R=E9f. : Re: To put = Linux kernel as=20 closer as possible to 0x80000000



> Yoichi Yuasa wrote :
> Hi
>
> It has no problem.
> Kernel has = reserved=20 space for exception handlers.
>
> Yoichi
>
> = 2005/12/13, colin <colin@realtek.com.tw>:
>= ;=20 >
> > Hi all,
> > We want to put Linux kernel as = closer=20 as possible to the bottom of memory.
> > I know that there is = some=20 stuff put in the beginning of memory, like
> > Exception=20 table.
> > So, what's the closest address to 0x80000000 that = is=20 allowable to store
> > kernel?


You should just take care to start after = reserved=20 exception/interruption vectors

0x80000000 : TLB Refull
0x80000080 : General Exception Vector

+ 32 instructions.

Depending on your architecture, those = addresses may=20 vary (I don't know anything about MIPS64

BTW, what's your arch ? =

-- Florian

-----BEGIN GEEK CODE BLOCK-----
GCS:GE:GM/ d? s-:+ a-- C+++
U(BLUAVHISX)++++ P++++ L++++
E--- W+++ N+++ o++++ w--- O M V
PS PE- PGP++ t 5 X+++ R+++ tv-
b+ BI++++ D+++ G e+++ h-- r+++ y+++
-----END GEEK CODE BLOC------ =
------=_NextPart_000_01EE_01C6009F.2DCDA610-- From lhrkernelcoder@gmail.com Wed Dec 14 07:24:26 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 14 Dec 2005 07:24:46 +0000 (GMT) Received: from wproxy.gmail.com ([64.233.184.198]:54477 "EHLO wproxy.gmail.com") by ftp.linux-mips.org with ESMTP id S8133367AbVLNHY0 convert rfc822-to-8bit (ORCPT ); Wed, 14 Dec 2005 07:24:26 +0000 Received: by wproxy.gmail.com with SMTP id i7so321449wra for ; Tue, 13 Dec 2005 23:24:51 -0800 (PST) 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=gGPbfGn+AXONdLoViV/y8sUXQBJaueRkRRBZbsSiCkBmAYaEgIkGS+WZPlX6Zoa47w9x59NfuPNqa8A5Nu+E7r9DvYM0VkCAcASQZ2R0+DSsR8GElSch5S2WoSSJCVzyWA6viWZpaqL61V3EGqljKCJ7Qwa9W31D0bHqkMC/6c0= Received: by 10.54.132.16 with SMTP id f16mr325158wrd; Tue, 13 Dec 2005 23:24:51 -0800 (PST) Received: by 10.54.146.1 with HTTP; Tue, 13 Dec 2005 23:24:51 -0800 (PST) Message-ID: Date: Tue, 13 Dec 2005 23:24:51 -0800 From: kernel coder To: linux-mips@linux-mips.org Subject: ENDEC ports and MII interface MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT 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: 9666 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 write ethernet driver.I need some explaination on ENDEC port and MII interface.By googling i've come to know that MII is used for phy communication by modern ethernet cards,but i haven't found much info on ENDEC ports. Actually mine card has option to select ENDEC port or MII interface for transmit and recieve. Please tell me which one should i choose and why. lhrkernelcode From florian.delizy@sagem.com Wed Dec 14 09:33:17 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 14 Dec 2005 09:33:37 +0000 (GMT) Received: from ns2.sagem.com ([62.160.59.241]:42910 "EHLO mx2.sagem.com") by ftp.linux-mips.org with ESMTP id S8133570AbVLNJdR (ORCPT ); Wed, 14 Dec 2005 09:33:17 +0000 To: linux-mips@linux-mips.org Subject: =?ISO-8859-1?Q?R=E9f=2E_=3A_Re=3A_R=E9f=2E_=3A_Re=3A_To_put_Linux_kernel?= =?ISO-8859-1?Q?_as_closer_as_possible_to_0x80000000?= MIME-Version: 1.0 Message-ID: From: Florian DELIZY Date: Wed, 14 Dec 2005 10:33:34 +0100 Content-Type: multipart/alternative; boundary="=_alternative 00348426C12570D7_=" 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: 9667 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: florian.delizy@sagem.com Precedence: bulk X-list: linux-mips Message en plusieurs parties au format MIME --=_alternative 00348426C12570D7_= Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable > Hi Florian, > We use MIPS 4kec. > Linux runs in Interrupt Compatibility Mode, and it will use 0x80000200=20 to store the "Jump" instruction. > Therefore, we can move Linux kernel to 0x80000204. Is it right? Not exactly, take care that the instruction located just after your jump=20 is also loaded and executed by the pipe, so you can place it at 0x80000208 (to have your two instructions safe), which should look like = : 800000200: j some=5Faddress 800000204: nop 800000208: LinuxFirstInstruction =20 Off course, you must also advise your boot loader to jump at the correct=20 address within the kernel (kernel=5Fentry) > Another new question. If we modify Linux to use Ventored Interrupt mode, = can we gain much performance? Ventored ?? I guess you mean "Vectored interrupt". IMO you won't get much=20 performance gain, in this particular situation, since your interrupt vector is just making a jump ... you might just gain=20 1 instruction (the nop) but that's all.=20 Somebody may have another opinion about this ... Regards --- Florian =20 > Regards, > Colin =20 ----- Original Message -----=20 From: Florian DELIZY=20 To: Yoichi Yuasa=20 Cc: colin ; linux-mips@linux-mips.org=20 Sent: Tuesday, December 13, 2005 8:28 PM Subject: R=E9f. : Re: To put Linux kernel as closer as possible to 0x800000= 00 > Yoichi Yuasa wrote :=20 > Hi > > It has no problem. > Kernel has reserved space for exception handlers. >=20 > Yoichi >=20 > 2005/12/13, colin : > > > > Hi all, > > We want to put Linux kernel as closer as possible to the bottom of=20 memory. > > I know that there is some stuff put in the beginning of memory, like > > Exception table. > > So, what's the closest address to 0x80000000 that is allowable to=20 store > > kernel?=20 You should just take care to start after reserved exception/interruption=20 vectors=20 0x80000000 : TLB Refull=20 0x80000080 : General Exception Vector=20 + 32 instructions.=20 Depending on your architecture, those addresses may vary (I don't know=20 anything about MIPS64=20 BTW, what's your arch ?=20 -- Florian=20 -----BEGIN GEEK CODE BLOCK-----=20 GCS:GE:GM/ d? s-:+ a-- C+++=20 U(BLUAVHISX)++++ P++++ L++++=20 E--- W+++ N+++ o++++ w--- O M V=20 PS PE- PGP++ t 5 X+++ R+++ tv-=20 b+ BI++++ D+++ G e+++ h-- r+++ y+++=20 -----END GEEK CODE BLOC------=20 --=_alternative 00348426C12570D7_= Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

 
> Hi Florian,
> We use MIPS 4kec.
> Linux runs in Interrupt Co= mpatibility Mode, and it will use 0x80000200 to store the "Jump" = instruction.
> Therefore, we can move Lin= ux kernel to 0x80000204. Is it right?

Not exactly, take care that the= instruction located just after your jump is also loaded and executed by th= e pipe, so you can place it
at 0x80000208 (to have your two= instructions safe), which should look like :

800000200:      =   j some=5Faddress
800000204:      =  nop
800000208:      =   LinuxFirstInstruction
 
Off course, you must also advis= e your boot loader to jump at the correct address within the kernel (kernel= =5Fentry)

> Another new question. If w= e modify Linux to use Ventored Interrupt mode, can we gain much performance= ?

Ventored ?? I guess you mean &q= uot;Vectored interrupt". IMO you won't get much performance gain, in t= his particular situation,
since your interrupt vector is = just making a jump ... you might just gain 1 instruction (the nop) but that= 's all.
Somebody may have another opini= on about this ...

Regards

--- Florian
 
> Regards,
> Colin
 
----- Original Message -----
From: Florian DELIZY
To: <= u>Yoichi Yuasa
Cc: colin ; linux-mips@linux-mips.org
Sent: Tuesday, December = 13, 2005 8:28 PM
Subject: R=E9f. : Re: To= put Linux kernel as closer as possible to 0x80000000



> Yoichi Yuasa wrote :
> Hi
>
> It has no problem.
> Kernel has reserved space for exception handlers.
>
> Yoichi
>
> 2005/12/13, colin <colin@realtek.com.tw>:
> >
> > Hi all,
> > We want to put Linux kernel as closer as possible to the bottom o= f memory.
> > I know that there is some stuff put in the beginning of memory, l= ike
> > Exception table.
> > So, what's the closest address to 0x80000000 that is allowable to= store
> > kernel?


You should just take care to start after reserved exception/interruption ve= ctors

0x80000000 : TLB Refull
0x80000080 : General Exception Vector

+ 32 instructions.

Depending on your architecture, those addresses may vary (I don't know anyt= hing about MIPS64

BTW, what's your arch ?

-- Florian

-----BEGIN GEEK CODE BLOCK-----
GCS:GE:GM/ d? s-:+ a-- C+++
U(BLUAVHISX)++++ P++++ L++++
E--- W+++ N+++ o++++ w--- O M V
PS PE- PGP++ t 5 X+++ R+++ tv-
b+ BI++++ D+++ G e+++ h-- r+++ y+++
-----END GEEK CODE BLOC------

--=_alternative 00348426C12570D7_=-- From ths@networkno.de Wed Dec 14 13:27:27 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 14 Dec 2005 13:27:44 +0000 (GMT) Received: from mx02.qsc.de ([213.148.130.14]:17105 "EHLO mx02.qsc.de") by ftp.linux-mips.org with ESMTP id S8133589AbVLNN11 (ORCPT ); Wed, 14 Dec 2005 13:27:27 +0000 Received: from port-195-158-169-121.dynamic.qsc.de ([195.158.169.121] helo=hattusa.textio) by mx02.qsc.de with esmtp (Exim 3.35 #1) id 1EmWff-0003CG-00 for linux-mips@linux-mips.org; Wed, 14 Dec 2005 14:27:51 +0100 Received: from ths by hattusa.textio with local (Exim 4.60) (envelope-from ) id 1EmWfa-000609-I1 for linux-mips@linux-mips.org; Wed, 14 Dec 2005 14:27:46 +0100 Date: Wed, 14 Dec 2005 14:27:46 +0100 To: linux-mips@linux-mips.org Subject: Re: =?iso-8859-1?B?UulmLiA6IFJlOiBU?= =?iso-8859-1?Q?o?= put Linux kernel as closer as possible to 0x80000000 Message-ID: <20051214132746.GE29411@hattusa.textio> References: <01f101c6005c$1faf2100$106215ac@realtek.com.tw> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <01f101c6005c$1faf2100$106215ac@realtek.com.tw> User-Agent: Mutt/1.5.11 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: 9668 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 colin wrote: > > Hi Florian, > We use MIPS 4kec. > Linux runs in Interrupt Compatibility Mode, and it will use 0x80000200 to store the "Jump" instruction. > Therefore, we can move Linux kernel to 0x80000204. Is it right? 0x80000208, to account for the branch delay slot. Thiemo From giometti@enneenne.com Wed Dec 14 13:46:03 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 14 Dec 2005 13:46:20 +0000 (GMT) Received: from 81-174-11-161.f5.ngi.it ([81.174.11.161]:15831 "EHLO goldrake.enneenne.com") by ftp.linux-mips.org with ESMTP id S8133589AbVLNNqD (ORCPT ); Wed, 14 Dec 2005 13:46:03 +0000 Received: from hulk.enneenne.com ([192.168.32.38] helo=localhost.localdomain ident=Debian-exim) by goldrake.enneenne.com with esmtp (Exim 4.54) id 1EmWbc-00080f-5O; Wed, 14 Dec 2005 14:27:25 +0100 Received: from giometti by localhost.localdomain with local (Exim 4.54) id 1EmWt1-0001Fm-4p; Wed, 14 Dec 2005 14:41:39 +0100 Date: Wed, 14 Dec 2005 14:41:39 +0100 From: Rodolfo Giometti To: Jordan Crouse Cc: linux-mips@linux-mips.org Message-ID: <20051214134139.GN22061@hulk.enneenne.com> References: <20051202190108.GF28227@cosmic.amd.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="G+DT6X5ssgZ56VG3" Content-Disposition: inline In-Reply-To: <20051202190108.GF28227@cosmic.amd.com> Organization: Programmi e soluzioni GNU/Linux X-PGP-Key: gpg --keyserver keyserver.penguin.de --recv-keys D25A5633 User-Agent: Mutt/1.5.9i X-SA-Exim-Connect-IP: 192.168.32.38 X-SA-Exim-Mail-From: giometti@enneenne.com Subject: Re: [PATCH] ALCHEMY: Add SD support to AU1200 MMC/SD driver X-SA-Exim-Version: 4.2 (built Thu, 03 Mar 2005 10:44:12 +0100) X-SA-Exim-Scanned: No (on goldrake.enneenne.com); Unknown failure 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: 9669 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 --G+DT6X5ssgZ56VG3 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Dec 02, 2005 at 12:01:08PM -0700, Jordan Crouse wrote: > Add SD support to the AU1200 MMC driver. This can > be added post 2.6.15, I'm just sending them out today so the various > maintainers can get them queued up.=20 According to AMD Application Note titled "MultiMediaCard Support Using the AMD Alchemy Au1200 and Au1100 Processors" I'd like to test your driver on my Au1100 based board. Can you please told me the Linux kernel version where the patch apply to? Do you think there should be some issue to keep in consideration regarding the Au1100? Thanks in advance, Rodolfo --=20 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 --G+DT6X5ssgZ56VG3 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDoCETQaTCYNJaVjMRAjl7AKCvljANJqJc7oBx0fNHn93KH/G+OgCeLTC6 i7V30tiXdsFlnUtD9Qz7DNM= =MkPw -----END PGP SIGNATURE----- --G+DT6X5ssgZ56VG3-- From jcrouse@cosmic.amd.com Wed Dec 14 15:51:26 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 14 Dec 2005 15:52:01 +0000 (GMT) Received: from amdext4.amd.com ([163.181.251.6]:10150 "EHLO amdext4.amd.com") by ftp.linux-mips.org with ESMTP id S8133639AbVLNPv0 (ORCPT ); Wed, 14 Dec 2005 15:51:26 +0000 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 jBEFpIvM017645; Wed, 14 Dec 2005 09:51:48 -0600 Received: from 163.181.250.1 by SAUSGW01.amd.com with ESMTP (AMD SMTP Relay (Email Firewall v6.1.0)); Wed, 14 Dec 2005 09:51:38 -0600 X-Server-Uuid: 8C3DB987-180B-4465-9446-45C15473FD3E Received: from ldcmail.amd.com (ldcmail.amd.com [147.5.200.40]) by amdint2.amd.com (8.12.8/8.12.8/AMD) with ESMTP id jBEFpbh5028177; Wed, 14 Dec 2005 09:51:37 -0600 (CST) Received: from cosmic.amd.com (cosmic.amd.com [147.5.201.206]) by ldcmail.amd.com (Postfix) with ESMTP id A90F1201E; Wed, 14 Dec 2005 08:51:37 -0700 (MST) Received: from cosmic.amd.com (localhost [127.0.0.1]) by cosmic.amd.com (8.13.4/8.13.4) with ESMTP id jBEFrPIv021731; Wed, 14 Dec 2005 08:53:25 -0700 Received: (from jcrouse@localhost) by cosmic.amd.com ( 8.13.4/8.13.4/Submit) id jBEFrPUr021730; Wed, 14 Dec 2005 08:53:25 -0700 Date: Wed, 14 Dec 2005 08:53:25 -0700 From: "Jordan Crouse" To: "Rodolfo Giometti" cc: linux-mips@linux-mips.org Subject: Re: ALCHEMY: Add SD support to AU1200 MMC/SD driver Message-ID: <20051214155324.GC9734@cosmic.amd.com> References: <20051202190108.GF28227@cosmic.amd.com> <20051214134139.GN22061@hulk.enneenne.com> MIME-Version: 1.0 In-Reply-To: <20051214134139.GN22061@hulk.enneenne.com> User-Agent: Mutt/1.5.11 X-WSS-ID: 6FBEE0004KG2208181-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: 9670 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 14/12/05 14:41 +0100, Rodolfo Giometti wrote: > On Fri, Dec 02, 2005 at 12:01:08PM -0700, Jordan Crouse wrote: > > Add SD support to the AU1200 MMC driver. This can > > be added post 2.6.15, I'm just sending them out today so the various > > maintainers can get them queued up. > > According to AMD Application Note titled "MultiMediaCard Support Using > the AMD Alchemy Au1200 and Au1100 Processors" I'd like to test your > driver on my Au1100 based board. > > Can you please told me the Linux kernel version where the patch apply > to? The patch should apply to the most recent linux-mips git (at least as of Wednesday morning). > Do you think there should be some issue to keep in consideration > regarding the Au1100? Well, hopefully everything will Just Work (TM), but you'll want to make sure that all the various definitions are enabled for the AU1100. I'll have to give you my standard disclaimer that I haven't compiled this for anything but a DB1200 and PB1200, so I can't promise that it will work, but there is nothing in the code that says it won't. Regards, Jordan -- Jordan Crouse Senior Linux Engineer AMD - Personal Connectivity Solutions Group From bora.sahin@ttnet.net.tr Wed Dec 14 21:56:08 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 14 Dec 2005 21:56:25 +0000 (GMT) Received: from mail.ttnet.net.tr ([212.175.13.129]:20016 "EHLO fep01.ttnet.net.tr") by ftp.linux-mips.org with ESMTP id S8133706AbVLNV4I (ORCPT ); Wed, 14 Dec 2005 21:56:08 +0000 Received: from boras ([85.102.128.41]) by fep01.ttnet.net.tr with ESMTP id <20051214215233.GDML17443.fep01.ttnet.net.tr@boras> for ; Wed, 14 Dec 2005 23:52:33 +0200 From: bora.sahin@ttnet.net.tr To: linux-mips@linux-mips.org Subject: Au1200 & IDE Date: Wed, 14 Dec 2005 23:56:14 +0200 User-Agent: KMail/1.7.2 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200512142356.14417.bora.sahin@ttnet.net.tr> X-NAI-Spam-Rules: 1 Rules triggered BAYES_00=-2.5 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: 9671 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: bora.sahin@ttnet.net.tr Precedence: bulk X-list: linux-mips Hi, drivers/ide/mips/au1xxx-ide.c includes ide-timing.h: ... #include "ide-timing.h" ... But that directory doesnt contain "ide-timing.h" so compiler complains from it. ide-timing.h is in ide folder. I did a grep and saw that some other dirs under ide also includes that file in the same manner as in mips but doesnt contain it in its own folder. After I did a sym link, compile was successfull. What's the concept behind this? Can we move it to include/linux? -- Bora SAHIN From jcrouse@cosmic.amd.com Wed Dec 14 23:48:22 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 14 Dec 2005 23:48:43 +0000 (GMT) Received: from amdext4.amd.com ([163.181.251.6]:64210 "EHLO amdext4.amd.com") by ftp.linux-mips.org with ESMTP id S8133715AbVLNXsW (ORCPT ); Wed, 14 Dec 2005 23:48:22 +0000 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 jBENkfpt020118; Wed, 14 Dec 2005 17:48:47 -0600 Received: from 163.181.250.1 by SAUSGW01.amd.com with ESMTP (AMD SMTP Relay (Email Firewall v6.1.0)); Wed, 14 Dec 2005 17:48:39 -0600 X-Server-Uuid: 8C3DB987-180B-4465-9446-45C15473FD3E Received: from ldcmail.amd.com (ldcmail.amd.com [147.5.200.40]) by amdint2.amd.com (8.12.8/8.12.8/AMD) with ESMTP id jBENmdh5022288; Wed, 14 Dec 2005 17:48:39 -0600 (CST) Received: from cosmic.amd.com (cosmic.amd.com [147.5.201.206]) by ldcmail.amd.com (Postfix) with ESMTP id 19A47201E; Wed, 14 Dec 2005 16:48:39 -0700 (MST) Received: from cosmic.amd.com (localhost [127.0.0.1]) by cosmic.amd.com (8.13.4/8.13.4) with ESMTP id jBENoVf6024550; Wed, 14 Dec 2005 16:50:31 -0700 Received: (from jcrouse@localhost) by cosmic.amd.com ( 8.13.4/8.13.4/Submit) id jBENoVNP024549; Wed, 14 Dec 2005 16:50:31 -0700 Date: Wed, 14 Dec 2005 16:50:31 -0700 From: "Jordan Crouse" To: bora.sahin@ttnet.net.tr cc: linux-mips@linux-mips.org Subject: Re: Au1200 & IDE Message-ID: <20051214235031.GD23276@cosmic.amd.com> References: <200512142356.14417.bora.sahin@ttnet.net.tr> MIME-Version: 1.0 In-Reply-To: <200512142356.14417.bora.sahin@ttnet.net.tr> User-Agent: Mutt/1.5.11 X-WSS-ID: 6FBE70DD4KG2293280-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: 9672 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 > But that directory doesnt contain "ide-timing.h" so compiler complains from > it. ide-timing.h is in ide folder. I did a grep and saw that some other > dirs under ide also includes that file in the same manner as in mips but > doesnt contain it in its own folder. After I did a sym link, compile was > successfull. What's the concept behind this? Can we move it to > include/linux. I'm not sure about that - thats probably more of a question for the core folks. For your particular error, however, it should be sufficient to add EXTRA_CFLAGS += -Idrivers/ide To drivers/ide/mips/Makefile. I do believe that the most recent patches had that fix attached. Jordan -- Jordan Crouse Senior Linux Engineer AMD - Personal Connectivity Solutions Group From bora.sahin@ttnet.net.tr Thu Dec 15 10:03:26 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 15 Dec 2005 10:03:43 +0000 (GMT) Received: from mail.ttnet.net.tr ([212.175.13.129]:45038 "EHLO fep05.ttnet.net.tr") by ftp.linux-mips.org with ESMTP id S3458530AbVLOKD0 (ORCPT ); Thu, 15 Dec 2005 10:03:26 +0000 Received: from boras ([85.102.130.181]) by fep05.ttnet.net.tr with ESMTP id <20051215095629.ZQAZ26646.fep05.ttnet.net.tr@boras>; Thu, 15 Dec 2005 11:56:29 +0200 From: bora.sahin@ttnet.net.tr To: linux-mips@linux-mips.org Subject: Re: Au1200 & IDE Date: Thu, 15 Dec 2005 11:58:18 +0200 User-Agent: KMail/1.7.2 Cc: "Jordan Crouse" References: <200512142356.14417.bora.sahin@ttnet.net.tr> <20051214235031.GD23276@cosmic.amd.com> In-Reply-To: <20051214235031.GD23276@cosmic.amd.com> MIME-Version: 1.0 Content-Type: text/plain; charset="Iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200512151158.19027.bora.sahin@ttnet.net.tr> X-NAI-Spam-Rules: 0 Rules triggered 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: 9673 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: bora.sahin@ttnet.net.tr Precedence: bulk X-list: linux-mips > I do believe that the most recent patches had that fix attached. Your IDE patches? I am using 2.6.15.rc4-g2b269cc6, and it is not there. -- Bora SAHIN From annamshr@gmail.com Thu Dec 15 12:49:10 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 15 Dec 2005 12:49:29 +0000 (GMT) Received: from xproxy.gmail.com ([66.249.82.204]:32026 "EHLO xproxy.gmail.com") by ftp.linux-mips.org with ESMTP id S8133369AbVLOMtK convert rfc822-to-8bit (ORCPT ); Thu, 15 Dec 2005 12:49:10 +0000 Received: by xproxy.gmail.com with SMTP id s18so271819wxc for ; Thu, 15 Dec 2005 04:49:44 -0800 (PST) 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=DI/HhQXri/5Zq02txvTyUvVTq2IMWsgZ18rR5RB3iXWHMJk5NPdSuhBqDrwyh4rjMMRrXvYvMg3q1uxL8xECpp6uIOdlFTe0XIwBaEF9QrLLwWrRkQBmoH2LxXBsyANoSjBlFNF4Xm95Ogyto+aZ9vePVwk7FDB9mo/5u5zm/Oo= Received: by 10.70.15.6 with SMTP id 6mr2624884wxo; Thu, 15 Dec 2005 04:49:44 -0800 (PST) Received: by 10.70.26.3 with HTTP; Thu, 15 Dec 2005 04:49:44 -0800 (PST) Message-ID: <9498e5c10512150449x625a7270s168d6a6339330e29@mail.gmail.com> Date: Thu, 15 Dec 2005 18:19:44 +0530 From: Shireesh Annam To: linux-mips@linux-mips.org Subject: 2.4.22 Kernel Build Error MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT 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: 9674 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: annamshr@gmail.com Precedence: bulk X-list: linux-mips Hi: I have an new AMD (Au1500) Bosporous Board and I intend to install MIPS Kernel 2.4.22 (linux-14oct2003.tar.gz) provided on the AMD CD provided along with the kit. I have been through the www.linux-mips.org website. I have installed the Linux/386 cross for big-endian target i.e. MIPS SDE 6.02.03 from ftp.mips.com on a Red Hat host. After that when I try to build the kernel using the following command: $make ARCH=mips CROSS_COMPILE=mips-linux- zImage I get the following error. mips-linux-gcc -D__KERNEL__ -I/root/MipsLinux/oct2003/linux/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer -I /root/MipsLinux/oct2003/linux/include/asm/gcc -G 0 -mno-abicalls -fno-pic -pipe -mabi=32 -mcpu=r4600 -mips2 -Wa,--trap -DKBUILD_BASENAME=main -c -o init/main.o init/main.c cc1: error: invalid option `-mcpu=r4600' make: *** [init/main.o] Error 1 I have selected MIPS32 for the CPU Architecture and the toolchain doesn't seem to recognize the r4600 option. Could someone throw any light on this? I'm not able to move ahead since I'm not able to build the kernel itself. Could someone help me in recommending the right toolchain for this build? Thanks, Shireesh From ralf@linux-mips.org Thu Dec 15 14:51:17 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 15 Dec 2005 14:51:38 +0000 (GMT) Received: from extgw-uk.mips.com ([62.254.210.129]:39429 "EHLO bacchus.net.dhis.org") by ftp.linux-mips.org with ESMTP id S8133453AbVLOOvR (ORCPT ); Thu, 15 Dec 2005 14:51:17 +0000 Received: from dea.linux-mips.net (localhost.localdomain [127.0.0.1]) by bacchus.net.dhis.org (8.13.4/8.13.1) with ESMTP id jBFEpY7H003147; Thu, 15 Dec 2005 14:51:34 GMT Received: (from ralf@localhost) by dea.linux-mips.net (8.13.4/8.13.4/Submit) id jBFEpWRS003146; Thu, 15 Dec 2005 14:51:32 GMT Date: Thu, 15 Dec 2005 14:51:32 +0000 From: Ralf Baechle To: Shireesh Annam Cc: linux-mips@linux-mips.org Subject: Re: 2.4.22 Kernel Build Error Message-ID: <20051215145132.GA2812@linux-mips.org> References: <9498e5c10512150449x625a7270s168d6a6339330e29@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9498e5c10512150449x625a7270s168d6a6339330e29@mail.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: 9675 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, Dec 15, 2005 at 06:19:44PM +0530, Shireesh Annam wrote: > I have an new AMD (Au1500) Bosporous Board and I intend to install > MIPS Kernel 2.4.22 (linux-14oct2003.tar.gz) provided on the AMD CD > provided along with the kit. I have been through the > www.linux-mips.org website. > > I have installed the Linux/386 cross for big-endian target i.e. MIPS > SDE 6.02.03 from ftp.mips.com on a Red Hat host. > > After that when I try to build the kernel using the following command: > $make ARCH=mips CROSS_COMPILE=mips-linux- zImage > > I get the following error. > > mips-linux-gcc -D__KERNEL__ -I/root/MipsLinux/oct2003/linux/include > -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing > -fno-common -fomit-frame-pointer -I > /root/MipsLinux/oct2003/linux/include/asm/gcc -G 0 -mno-abicalls > -fno-pic -pipe -mabi=32 -mcpu=r4600 -mips2 -Wa,--trap > -DKBUILD_BASENAME=main -c -o init/main.o init/main.c > cc1: error: invalid option `-mcpu=r4600' > make: *** [init/main.o] Error 1 > > I have selected MIPS32 for the CPU Architecture and the toolchain > doesn't seem to recognize the r4600 option. You're trying to build a stoneage kernel with a much newer compiler - SDE 6 uses gcc 3.4 - which doesn't work. Use an older compiler such as gcc <= 3.3.x. SDE 5.x contains gcc 2.96 btw. Ralf From ralf@linux-mips.org Thu Dec 15 15:02:02 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 15 Dec 2005 15:02:20 +0000 (GMT) Received: from extgw-uk.mips.com ([62.254.210.129]:22555 "EHLO bacchus.net.dhis.org") by ftp.linux-mips.org with ESMTP id S8133389AbVLOPCC (ORCPT ); Thu, 15 Dec 2005 15:02:02 +0000 Received: from dea.linux-mips.net (localhost.localdomain [127.0.0.1]) by bacchus.net.dhis.org (8.13.4/8.13.1) with ESMTP id jBFExZwc003526; Thu, 15 Dec 2005 14:59:35 GMT Received: (from ralf@localhost) by dea.linux-mips.net (8.13.4/8.13.4/Submit) id jBFExLEV003489; Thu, 15 Dec 2005 14:59:21 GMT Date: Thu, 15 Dec 2005 14:59:21 +0000 From: Ralf Baechle To: Jordan Crouse Cc: bora.sahin@ttnet.net.tr, linux-mips@linux-mips.org Subject: Re: Au1200 & IDE Message-ID: <20051215145921.GB2812@linux-mips.org> References: <200512142356.14417.bora.sahin@ttnet.net.tr> <20051214235031.GD23276@cosmic.amd.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20051214235031.GD23276@cosmic.amd.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: 9676 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, Dec 14, 2005 at 04:50:31PM -0700, Jordan Crouse wrote: > > But that directory doesnt contain "ide-timing.h" so compiler complains from > > it. ide-timing.h is in ide folder. I did a grep and saw that some other > > dirs under ide also includes that file in the same manner as in mips but > > doesnt contain it in its own folder. After I did a sym link, compile was > > successfull. What's the concept behind this? Can we move it to > > include/linux. > > I'm not sure about that - thats probably more of a question for the core > folks. For your particular error, however, it should be sufficient to add > > EXTRA_CFLAGS += -Idrivers/ide > > To drivers/ide/mips/Makefile. I do believe that the most recent patches > had that fix attached. I nuked it - it just isn't necessary to force this for all drivers. So if anything, make that CFLAGS_au1xxx-ide.o += -Idrivers/ide Ralf From annamshr@gmail.com Thu Dec 15 18:48:17 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 15 Dec 2005 18:48:35 +0000 (GMT) Received: from xproxy.gmail.com ([66.249.82.194]:38993 "EHLO xproxy.gmail.com") by ftp.linux-mips.org with ESMTP id S3467095AbVLOSsR convert rfc822-to-8bit (ORCPT ); Thu, 15 Dec 2005 18:48:17 +0000 Received: by xproxy.gmail.com with SMTP id s18so332896wxc for ; Thu, 15 Dec 2005 10:48:52 -0800 (PST) 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=dE+LBpFuMGKpGSeJCj1svWQd47UiUK3dxO0/5+X4F+fSXbxQT9LsHfEXBezzydi7LHiN4L6kAMvV+MM3+aYNQzFLEJhOCI8m8J2iHzZJhsjfSYlerZGoWTr3dLiZwyzx5UwcGjztCJBv9nxEKf+z4v+K2WQ1qhoQ0Lzfku4f9kM= Received: by 10.70.87.10 with SMTP id k10mr3154863wxb; Thu, 15 Dec 2005 10:48:50 -0800 (PST) Received: by 10.70.26.3 with HTTP; Thu, 15 Dec 2005 10:48:50 -0800 (PST) Message-ID: <9498e5c10512151048n1e615614r7ded00ad77c48724@mail.gmail.com> Date: Fri, 16 Dec 2005 00:18:50 +0530 From: Shireesh Annam To: Ralf Baechle Subject: Re: 2.4.22 Kernel Build Error Cc: linux-mips@linux-mips.org In-Reply-To: <20051215145132.GA2812@linux-mips.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT Content-Disposition: inline References: <9498e5c10512150449x625a7270s168d6a6339330e29@mail.gmail.com> <20051215145132.GA2812@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: 9677 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: annamshr@gmail.com Precedence: bulk X-list: linux-mips I'm now using the SDE-Linux 5.03.06 for the big-endian target. I started the 2.4.22 kernel build process, but soon I get the following compile error. ********** make[2]: Entering directory `/root/linux/arch/mips/mm' mips-linux-gcc -D__KERNEL__ -I/root/linux/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer -I /root/linux/include/asm/gcc -G 0 -mno-abicalls -fno-pic -pipe -mabi=32 -mcpu=r4600 -mips2 -Wa,--trap -nostdinc -iwithprefix include -DKBUILD_BASENAME=sc_ip22 -c -o sc-ip22.o sc-ip22.c {standard input}: Assembler messages: {standard input}:126: Error: Number (0x9000000080000000) larger than 32 bits {standard input}:148: Error: Number (0x9000000080000000) larger than 32 bits {standard input}:168: Error: Number (0x9000000080000000) larger than 32 bits make[2]: *** [sc-ip22.o] Error 1 make[2]: Leaving directory `/root/linux/arch/mips/mm' make[1]: *** [first_rule] Error 2 make[1]: Leaving directory `/root/linux/arch/mips/mm' make: *** [_dir_arch/mips/mm] Error 2 ********** I'm not able to understand these error messages. Could someone throiw some light on this issue? Is this because of the toolchain that I'm using for building the kernel? Thanks, Shireesh On 12/15/05, Ralf Baechle wrote: > You're trying to build a stoneage kernel with a much newer compiler - > SDE 6 uses gcc 3.4 - which doesn't work. Use an older compiler such > as gcc <= 3.3.x. SDE 5.x contains gcc 2.96 btw. > > Ralf > From giometti@enneenne.com Fri Dec 16 15:31:29 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 16 Dec 2005 15:31:48 +0000 (GMT) Received: from 81-174-11-161.f5.ngi.it ([81.174.11.161]:44742 "EHLO gundam.enneenne.com") by ftp.linux-mips.org with ESMTP id S8133454AbVLPPb3 (ORCPT ); Fri, 16 Dec 2005 15:31:29 +0000 Received: from giometti by gundam.enneenne.com with local (Exim 3.36 #1 (Debian)) id 1EnHYx-00065z-00; Fri, 16 Dec 2005 16:32:03 +0100 Date: Fri, 16 Dec 2005 16:32:03 +0100 From: Rodolfo Giometti To: linux-mips@linux-mips.org, u-boot-users@lists.sourceforge.net Subject: Freezing & Unfreezing the au11000 Message-ID: <20051216153203.GK14341@gundam.enneenne.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline \From: Rodolfo Giometti Organization: Programmi e soluzioni GNU/Linux X-PGP-Key: gpg --keyserver keyserver.penguin.de --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: 9678 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 I'm just trying to support the save_and_sleep() support into u-boot for an au1100 based board. Into u-boot I added the following code: Index: cpu/mips/start.S =================================================================== RCS file: /home/develop/cvs_private/uboot-mips-exadron/cpu/mips/start.S,v retrieving revision 1.2 diff -u -r1.2 start.S --- cpu/mips/start.S 12 Oct 2005 12:55:54 -0000 1.2 +++ cpu/mips/start.S 16 Dec 2005 15:29:22 -0000 @@ -26,6 +26,7 @@ #include #include #include +#include #include @@ -273,6 +274,33 @@ li t0, CONF_CM_CACHABLE_NONCOHERENT mtc0 t0, CP0_CONFIG + /* Now check the wakeup cause + */ + li t0, SYS_WAKESRC + lw t1, 0(t0) + andi t1, t1, 0x00000002 /* check the SW bit */ + beq zero, t1, 1f + nop + + li t0, SYS_SCRATCH0 + lw t1, 0(t0) + move sp, t1 + li t0, SYS_SCRATCH1 + lw t1, 0(t0) + j t1 /* this cause a jump into already + nop frozen Linux (brr! :) */ + + /* If we reach this point we come from a normal system power up, + so just clear the wakeup cause registers + */ + +1: li t0, SYS_WAKEMSK + li t1, 0x00000000 + sw t1, 0(t0) + + li t0, SYS_WAKESRC + li t1, 0x00000000 + sw t1, 0(t0) /* Set up temporary stack. */ in order to restore the scratch registers contents as descibed into file "linux/arch/mips/au1000/common/sleeper.S": /* Now set up the scratch registers so the boot rom will * return to this point upon wakeup. */ la k0, 1f lui k1, 0xb190 ori k1, 0x18 sw sp, 0(k1) ori k1, 0x1c sw k0, 0(k1) However it seems something is wrong since the system at the end of save_and_sleep() does not correctly continue its execution... Unlikely my JTAG do not allow me to follow the code after the save_and_sleep()'s return (I definitely have to buy a better one), however I noticed that when the system tryes to resume the register 29 (the sp) doing: lw $29, PT_R29(sp) something goes wrong! Suggestions? :) Thanks in advance, 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 madprops@gmx.net Fri Dec 16 15:34:01 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 16 Dec 2005 15:34:20 +0000 (GMT) Received: from mail.gmx.de ([213.165.64.21]:45233 "HELO mail.gmx.net") by ftp.linux-mips.org with SMTP id S8133454AbVLPPeB (ORCPT ); Fri, 16 Dec 2005 15:34:01 +0000 Received: (qmail 12550 invoked by uid 0); 16 Dec 2005 15:34:36 -0000 Received: from 129.13.186.1 by www10.gmx.net with HTTP; Fri, 16 Dec 2005 16:34:36 +0100 (MET) Date: Fri, 16 Dec 2005 16:34:36 +0100 (MET) From: madprops@gmx.net To: linux-mips@linux-mips.org MIME-Version: 1.0 Subject: Timer interrupts X-Priority: 3 (Normal) X-Authenticated: #24801140 Message-ID: <2987.1134747276@www10.gmx.net> X-Mailer: WWW-Mail 1.6 (Global Message Exchange) X-Flags: 0001 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: 9679 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: madprops@gmx.net Precedence: bulk X-list: linux-mips Hi, i'm using CP0_Count/CP0_Compare to get timer interrupts. They should be turned off while being in kernel mode (performing syscalls / handling tlb-misses etc) and enabled in user mode. Whenever a timer interrupt happens in kernel mode, the exception should be delayed until it is switched back to the user. Up to now I set CP0_Status(IE) to zero when entering the kernel. Does this allow pending interrupts or are incoming interrupts totally ignored then ?? The problem that might arise (in the second case) is that CP0_Count reaches and passes CP0_Compare while interrupts are turned off. Back in user mode, the running user process would get an unacceptable excessive time slice. Thanks, Thomas -- Telefonieren Sie schon oder sparen Sie noch? NEU: GMX Phone_Flat http://www.gmx.net/de/go/telefonie From giometti@enneenne.com Fri Dec 16 16:18:01 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 16 Dec 2005 16:18:18 +0000 (GMT) Received: from 81-174-11-161.f5.ngi.it ([81.174.11.161]:18414 "EHLO gundam.enneenne.com") by ftp.linux-mips.org with ESMTP id S8133454AbVLPQSB (ORCPT ); Fri, 16 Dec 2005 16:18:01 +0000 Received: from giometti by gundam.enneenne.com with local (Exim 3.36 #1 (Debian)) id 1EnII6-0007Qv-00 for ; Fri, 16 Dec 2005 17:18:42 +0100 Date: Fri, 16 Dec 2005 17:18:42 +0100 From: Rodolfo Giometti To: linux-mips@linux-mips.org Subject: Irda support for au1100 Message-ID: <20051216161842.GN14341@gundam.enneenne.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Organization: Programmi e soluzioni GNU/Linux X-PGP-Key: gpg --keyserver keyserver.penguin.de --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: 9680 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 Doing: giometti@vvonth:/home/develop/linux.git$ rgrep CONFIG_AU1000_FIR * drivers/net/irda/Makefile:obj-$(CONFIG_AU1000_FIR) += au1k_ir.o so I suppose that current Irda support for au1100 is broken... is that right? :) Some suggestions in order to help me to port it to the current kernel release? Thanks in advance, 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 ppopov@embeddedalley.com Fri Dec 16 16:25:18 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 16 Dec 2005 16:25:36 +0000 (GMT) Received: from smtp102.biz.mail.mud.yahoo.com ([68.142.200.237]:14473 "HELO smtp102.biz.mail.mud.yahoo.com") by ftp.linux-mips.org with SMTP id S8133454AbVLPQZS (ORCPT ); Fri, 16 Dec 2005 16:25:18 +0000 Received: (qmail 98646 invoked from network); 16 Dec 2005 16:25:53 -0000 Received: from unknown (HELO ?192.168.1.110?) (ppopov@embeddedalley.com@71.128.175.242 with plain) by smtp102.biz.mail.mud.yahoo.com with SMTP; 16 Dec 2005 16:25:52 -0000 Subject: Re: Irda support for au1100 From: Pete Popov Reply-To: ppopov@embeddedalley.com To: Rodolfo Giometti Cc: "'linux-mips@linux-mips.org'" In-Reply-To: <20051216161842.GN14341@gundam.enneenne.com> References: <20051216161842.GN14341@gundam.enneenne.com> Content-Type: text/plain Organization: Embedded Alley Solutions, Inc Date: Fri, 16 Dec 2005 08:25:54 -0800 Message-Id: <1134750354.4900.50.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.0.4 (2.0.4-4) 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: 9681 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, 2005-12-16 at 17:18 +0100, Rodolfo Giometti wrote: > Doing: > > giometti@vvonth:/home/develop/linux.git$ rgrep CONFIG_AU1000_FIR * > drivers/net/irda/Makefile:obj-$(CONFIG_AU1000_FIR) += au1k_ir.o > > so I suppose that current Irda support for au1100 is broken... is that > right? :) It hasn't been tested in a very long time. > Some suggestions in order to help me to port it to the current kernel > release? Compile it, see what's broken, and fix it :) It shouldn't be that bad. You can see how the chip works in the current driver. All breakage should be related to new kernel irda apis and such. Pete From sshtylyov@ru.mvista.com Fri Dec 16 16:28:11 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 16 Dec 2005 16:28:28 +0000 (GMT) Received: from rtsoft2.corbina.net ([85.21.88.2]:62683 "HELO mail.dev.rtsoft.ru") by ftp.linux-mips.org with SMTP id S8133454AbVLPQ2L (ORCPT ); Fri, 16 Dec 2005 16:28:11 +0000 Received: (qmail 14785 invoked from network); 16 Dec 2005 16:28:47 -0000 Received: from wasted.dev.rtsoft.ru (HELO ?192.168.1.248?) (192.168.1.248) by mail.dev.rtsoft.ru with SMTP; 16 Dec 2005 16:28:47 -0000 Message-ID: <43A2EBC9.5040502@ru.mvista.com> Date: Fri, 16 Dec 2005 19:31:05 +0300 From: Sergei Shtylylov Organization: MostaVista 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: Rodolfo Giometti Subject: Re: Freezing & Unfreezing the au11000 References: <20051216153203.GK14341@gundam.enneenne.com> In-Reply-To: <20051216153203.GK14341@gundam.enneenne.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: 9682 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 Rodolfo Giometti wrote: > in order to restore the scratch registers contents as descibed into > file "linux/arch/mips/au1000/common/sleeper.S": If you're talking about 2.6, the code in that file seems very incorrect in regard to how it deals wiht the stack frame, since it effectively trashes regs $1 and $2 reusing their slots for saving CP0 Status and Context regs. 2.4 branch has more sane variant. > Thanks in advance, > > Rodolfo WBR, Sergei From dom@mips.com Fri Dec 16 16:55:05 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 16 Dec 2005 16:55:22 +0000 (GMT) Received: from alg145.algor.co.uk ([62.254.210.145]:21257 "EHLO dmz.algor.co.uk") by ftp.linux-mips.org with ESMTP id S8133481AbVLPQzF (ORCPT ); Fri, 16 Dec 2005 16:55:05 +0000 Received: from alg158.algor.co.uk ([62.254.210.158] helo=olympia.mips.com) by dmz.algor.co.uk with esmtp (Exim 3.35 #1 (Debian)) id 1EnIpi-0007Zh-00; Fri, 16 Dec 2005 16:53:26 +0000 Received: from olympia.mips.com ([192.168.192.128] helo=boris) by olympia.mips.com with esmtp (Exim 3.36 #1 (Debian)) id 1EnIro-0005vl-00; Fri, 16 Dec 2005 16:55:36 +0000 From: Dominic Sweetman MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17314.61848.570755.340908@mips.com> Date: Fri, 16 Dec 2005 16:55:52 +0000 To: madprops@gmx.net Cc: linux-mips@linux-mips.org Subject: Re: Timer interrupts In-Reply-To: <2987.1134747276@www10.gmx.net> References: <2987.1134747276@www10.gmx.net> X-Mailer: VM 7.17 under 21.4 (patch 17) "Jumbo Shrimp" XEmacs Lucid X-MTUK-Scanner: Found to be clean X-MTUK-SpamCheck: not spam (whitelisted), SpamAssassin (score=-4.856, required 4, AWL, BAYES_00) 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: 9683 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: dom@mips.com Precedence: bulk X-list: linux-mips > i'm using CP0_Count/CP0_Compare to get timer interrupts. They should be > turned off while being in kernel mode (performing syscalls / handling > tlb-misses etc) and enabled in user mode. This isn't going to work. The hardware does nothing to inhibit interrupts in kernel mode, and the system depends on them (performance would be truly dreadful if no interrupt could be taken in kernel mode). The kernel is already using CP0_Status and Count/Compare for its own purposes, which you will be breaking... Whatever it is you were trying to do, you need to do some other way! -- Dominic Sweetman MIPS Technologies From vbarinov@ru.mvista.com Fri Dec 16 17:23:15 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 16 Dec 2005 17:23:37 +0000 (GMT) Received: from rtsoft3.corbina.net ([85.21.88.6]:38530 "EHLO buildserver.ru.mvista.com") by ftp.linux-mips.org with ESMTP id S8133479AbVLPRXP (ORCPT ); Fri, 16 Dec 2005 17:23:15 +0000 Received: from [192.168.12.17] ([10.149.0.1]) by buildserver.ru.mvista.com (8.11.6/8.11.6) with ESMTP id jBGHNbt30739; Fri, 16 Dec 2005 21:23:37 +0400 Message-ID: <43A2F819.1040106@ru.mvista.com> Date: Fri, 16 Dec 2005 20:23:37 +0300 From: "Vladimir A. Barinov" User-Agent: Mozilla Thunderbird 1.0.2-6 (X11/20050513) X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-mtd@lists.infradead.org, linux-mips@linux-mips.org Subject: [PATCH] PNX8550 NAND flash driver Content-Type: multipart/mixed; boundary="------------060504000207000008090303" 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: 9684 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: vbarinov@ru.mvista.com Precedence: bulk X-list: linux-mips This is a multi-part message in MIME format. --------------060504000207000008090303 Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit Hi All, Attached patch is NAND flash driver for PNX8550 based platforms. Any comments and suggestions are highly appreciated. Vladimir --------------060504000207000008090303 Content-Type: text/plain; name="nand.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="nand.patch" Signed-off-by: vbarinov@ru.mvista.com drivers/mtd/nand/Kconfig | 6 drivers/mtd/nand/Makefile | 1 drivers/mtd/nand/pnx8550.c | 747 +++++++++++++++++++++++++++++++++++++++++++++ 3 files changed, 754 insertions(+) Index: linux-2.6.15_0/drivers/mtd/nand/Kconfig =================================================================== --- linux-2.6.15_0.orig/drivers/mtd/nand/Kconfig +++ linux-2.6.15_0/drivers/mtd/nand/Kconfig @@ -90,6 +90,12 @@ config MTD_NAND_S3C2410 No board specfic support is done by this driver, each board must advertise a platform_device for the driver to attach. +config MTD_NAND_PNX8550 + tristate "NAND Flash support for PNX8550" + depends on PNX8550 && MTD_NAND + help + This enables the NAND flash controller on the PNX8550. + config MTD_NAND_S3C2410_DEBUG bool "S3C2410 NAND driver debug" depends on MTD_NAND_S3C2410 Index: linux-2.6.15_0/drivers/mtd/nand/pnx8550.c =================================================================== --- /dev/null +++ linux-2.6.15_0/drivers/mtd/nand/pnx8550.c @@ -0,0 +1,747 @@ +/* + * Copyright (C) 2005 Koninklijke Philips Electronics N.V. + * All Rights Reserved. + * + * Based on: drivers/mtd/nand/pnx8550.c by Torbjorn Lundberg + * $Id: pnx8550_nand.c,v 1.8 2004/11/12 10:46:58 tobbe Exp $ + * + * 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., 675 Mass Ave, Cambridge, MA 02139, USA. + * + * Overview: + * This is a device driver for the NAND flash device found on the + * PNX8550 board which utilizes the Samsung K9F5616U0C part. This is + * a 32MByte (16M x 16 bits) NAND flash device. + */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#define UBTM_NAME "microBTM" +#define UBTM_BLOCK_START ( 0x00000000) +#define UBTM_BLOCK_END ( 0x00004000) /* 16K size, first block */ +#define UBTM_SIZE ( UBTM_BLOCK_END - UBTM_BLOCK_START) + +#define BOOTLOADER_NAME "bootloader" +#define BOOTLOADER_BLOCK_START ( UBTM_BLOCK_END) +#define BOOTLOADER_BLOCK_END ( 0x00040000) /* 256K - 16K = 240K */ +#define BOOTLOADER_SIZE ( BOOTLOADER_BLOCK_END - BOOTLOADER_BLOCK_START) + +#define ROMFS_SYS_NAME "ROMFS-Tools" +#define ROMFS_SYS_BLOCK_START ( BOOTLOADER_BLOCK_END) +#define ROMFS_SYS_BLOCK_END ( 0x00600000) /* 6M - 256K = 5.75M */ +#define ROMFS_SYS_SIZE ( ROMFS_SYS_BLOCK_END - ROMFS_SYS_BLOCK_START) + +#define ROMFS_APP_NAME "ROMFS-User" +#define ROMFS_APP_BLOCK_START ( ROMFS_SYS_BLOCK_END) +#define ROMFS_APP_BLOCK_END ( 0x01000000) /* 16M - 6M = 10M */ +#define ROMFS_APP_SIZE ( ROMFS_APP_BLOCK_END - ROMFS_APP_BLOCK_START) + +#define USER_NAME "User" +#define USER_BLOCK_START ( ROMFS_APP_BLOCK_END) +#define USER_BLOCK_END ( 0x02000000) /* 32M - 16M = 16M */ +#define USER_SIZE ( USER_BLOCK_END - USER_BLOCK_START) + +#define NAND_ADDR(_col, _page) ((_col) & (mtd->oobblock - 1)) + ((_page) << this->page_shift) + +#define NAND_ADDR_SEND(_addr) pNandAddr[(_addr)/sizeof(u16)] = 0 + +#define NAND_TRANSFER_TO(_addr, _buffer, _bytes) pnx8550_nand_transfer((_buffer), ((u8*)pNandAddr) + (_addr), (_bytes), 1) + +#define NAND_TRANSFER_FROM(_addr, _buffer, _bytes) pnx8550_nand_transfer(((u8*)pNandAddr) + (_addr), (_buffer), (_bytes), 0) + +static void pnx8550_nand_register_setup(u_char cmd_no, u_char addr_no, + u_char include_data, u_char monitor_ACK, + u_char enable64M, int cmd_a, int cmd_b); + +static inline void pnx8550_nand_wait_for_dev_ready(void); + +static void pnx8550_nand_transfer(void *from, void *to, int bytes, int toxio); + +static void pnx8550_nand_transferDMA(void *from, void *to, int bytes, + int toxio); + +/* + * Define partitions for flash device + */ +#define NUM_PARTITIONS 5 +const static struct mtd_partition partition_info[NUM_PARTITIONS] = { + { + .name = UBTM_NAME, + .offset = UBTM_BLOCK_START, + .size = UBTM_SIZE}, + { + .name = BOOTLOADER_NAME, + .offset = BOOTLOADER_BLOCK_START, + .size = BOOTLOADER_SIZE}, + { + .name = ROMFS_SYS_NAME, + .offset = ROMFS_SYS_BLOCK_START, + .size = ROMFS_SYS_SIZE}, + { + .name = ROMFS_APP_NAME, + .offset = ROMFS_APP_BLOCK_START, + .size = ROMFS_APP_SIZE}, + { + .name = USER_NAME, + .offset = USER_BLOCK_START, + .size = USER_SIZE} +}; + +/* Bad block descriptor for 16Bit nand flash */ +static uint8_t scan_ff_pattern[] = { 0xff, 0xff }; +static struct nand_bbt_descr nand16bit_memorybased = { + .options = 0, + .offs = 0, + .len = 2, + .pattern = scan_ff_pattern +}; + +/* OOB Placement information that lines up with the boot loader code */ +static struct nand_oobinfo nand16bit_oob_16 = { + .useecc = MTD_NANDECC_AUTOPLACE, + .eccbytes = 6, + .eccpos = {2, 3, 4, 5, 6, 7}, + .oobfree = {{8, 8}} +}; + +/* Pointer into XIO for access to the 16Bit NAND flash device */ +static volatile u16 *pNandAddr; + +/* Last command sent to the pnx8550_nand_command function */ +static int last_command = -1; +/* + Next column address to read/write, set by pnx8550_nand_command + updated by the read/write functions +*/ +static int last_col_addr = -1; +/* + Next page address to read/write, set by pnx8550_nand_command + updated by the read/write functions +*/ +static int last_page_addr = -1; + +/* + 32bit Aligned/DMA buffer +*/ +static u_char *transferBuffer = NULL; + +static struct mtd_info pnx8550_mtd; +static struct nand_chip pnx8550_nand; + +/** + * Transfer data to/from the NAND chip. + * This function decides whether to use DMA or not depending on + * the amount of data to transfer and the alignment of the buffers. + * + * @from: Address to transfer data from + * @to: Address to transfer the data to + * @bytes: Number of bytes to transfer + * @toxio: Whether the transfer is going to XIO or not. + */ +static void pnx8550_nand_transfer(void *from, void *to, int bytes, int toxio) +{ + u16 *from16 = (u16 *) from; + u16 *to16 = (u16 *) to; + + int i; + + if ((u32) from & 3) { + printk + ("%s: from buffer not 32bit aligned, will not use fastest transfer mechanism\n", + __FUNCTION__); + } + if ((u32) to & 3) { + printk + ("%s: to buffer not 32bit aligned, will not use fastest transfer mechanism\n", + __FUNCTION__); + } + + if (((bytes & 3) || (bytes < 16)) || ((u32) to & 3) || ((u32) from & 3)) { + if (((bytes & 1) == 0) && + (((u32) to & 1) == 0) && (((u32) from & 1) == 0)) { + int words = bytes / 2; + + local_irq_disable(); + for (i = 0; i < words; i++) { + to16[i] = from16[i]; + } + local_irq_enable(); + } else { + printk + ("%s: Transfer failed, byte-aligned transfers no allowed!\n", + __FUNCTION__); + } + } else { + pnx8550_nand_transferDMA(from, to, bytes, toxio); + } +} + +/** + * Transfer data to/from the NAND chip using DMA + * + * @from: Address to transfer data from + * @to: Address to transfer the data to + * @bytes: Number of bytes to transfer + * @toxio: Whether the transfer is going to XIO or not. + */ +static void pnx8550_nand_transferDMA(void *from, void *to, int bytes, int toxio) +{ + int cmd = 0; + u32 internal; + u32 external; + + if (toxio) { + cmd = PNX8550_DMA_CTRL_PCI_CMD_WRITE; + dma_cache_wback(from, bytes); + internal = (u32) virt_to_phys(from); + external = (u32) to - KSEG1; + } else { + cmd = PNX8550_DMA_CTRL_PCI_CMD_READ; + internal = (u32) virt_to_phys(to); + external = (u32) from - KSEG1; + } + + local_irq_disable(); + PNX8550_DMA_TRANS_SIZE = bytes >> 2; /* Length in words */ + PNX8550_DMA_EXT_ADDR = external; + PNX8550_DMA_INT_ADDR = internal; + PNX8550_DMA_INT_CLEAR = 0xffff; + PNX8550_DMA_CTRL = PNX8550_DMA_CTRL_BURST_512 | + PNX8550_DMA_CTRL_SND2XIO | PNX8550_DMA_CTRL_INIT_DMA | cmd; + + while ((PNX8550_DMA_INT_STATUS & PNX8550_DMA_INT_COMPL) == 0) ; + + if (!toxio) { + dma_cache_inv(to, bytes); + } + local_irq_enable(); +} + +/** + * pnx8550_nand_read_byte - read one byte endianess aware from the chip + * @mtd: MTD device structure + * + */ +static u_char pnx8550_nand_read_byte(struct mtd_info *mtd) +{ + struct nand_chip *this = mtd->priv; + u16 data = 0; + int addr = NAND_ADDR(last_col_addr, last_page_addr); + /* + Read ID is a special case as we have to read BOTH bytes at the same + time otherwise it doesn't work, once we have both bytes we work out + which one we want. + */ + if (last_command == NAND_CMD_READID) { + u32 *pNandAddr32 = (u32 *) pNandAddr; + u32 data32; + data32 = cpu_to_le32(pNandAddr32[0]); + if (last_col_addr) { + data = (u16) (data32 >> 16); + } else { + data = (u16) data32; + } + } else { + data = cpu_to_le16(pNandAddr[(addr / sizeof(u16))]); + if ((addr & 0x1) == 1) { + data = (data & 0xff00) >> 16; + } + } + /* + Status is a special case, we don't need to increment the address + because the address isn't used by the chip + */ + if (last_command != NAND_CMD_STATUS) { + last_col_addr++; + } + return data & 0xff; +} + +/** + * pnx8550_nand_read_word - read one word from the chip + * @mtd: MTD device structure + * + * Read function for 16bit buswith without + * endianess conversion + */ +static u16 pnx8550_nand_read_word(struct mtd_info *mtd) +{ + struct nand_chip *this = mtd->priv; + int addr = NAND_ADDR(last_col_addr, last_page_addr); + u16 data = pNandAddr[(addr / sizeof(u16))]; + return data; +} + +/** + * pnx8550_nand_write_byte - write one byte endianess aware to the chip + * @mtd: MTD device structure + * @byte: pointer to data byte to write + * + * Write function for 16bit buswith with + * endianess conversion + */ +static void pnx8550_nand_write_byte(struct mtd_info *mtd, u_char byte) +{ + struct nand_chip *this = mtd->priv; + int addr = NAND_ADDR(last_col_addr, last_page_addr); + pNandAddr[(addr / sizeof(u16))] = le16_to_cpu((u16) byte); +} + +/** + * pnx8550_nand_write_word - write one word to the chip + * @mtd: MTD device structure + * @word: data word to write + * + * Write function for 16bit buswith without + * endianess conversion + */ +static void pnx8550_nand_write_word(struct mtd_info *mtd, u16 word) +{ + struct nand_chip *this = mtd->priv; + int addr = NAND_ADDR(last_col_addr, last_page_addr); + pNandAddr[(addr / sizeof(u16))] = word; +} + +/** + * pnx8550_nand_write_buf - write buffer to chip + * @mtd: MTD device structure + * @buf: data buffer + * @len: number of bytes to write + * + */ +static void pnx8550_nand_write_buf(struct mtd_info *mtd, const u_char * buf, + int len) +{ + struct nand_chip *this = mtd->priv; + int addr = NAND_ADDR(last_col_addr, last_page_addr); + int pageLen; + int oobLen = 0; + u_char *transBuf = (u_char *) buf; + + /* some sanity checking, word access only please */ + if (len & 1) { + printk("%s: non-word aligned length requested!\n", + __FUNCTION__); + } + + memcpy(transferBuffer, buf, len); + transBuf = transferBuffer; + + /* + Work out whether we are going to write to the OOB area + after a standard page write. + This is not the case when the command function is called + with a column address > page size. Then we write as though + it is to the page rather than the OOB as the command function + has already selected the OOB area. + */ + if ((last_col_addr + len) > mtd->oobblock) + oobLen = (last_col_addr + len) - mtd->oobblock; + pageLen = len - oobLen; + + /* Clear the done flag */ + PNX8550_GPXIO_CTRL |= PNX8550_GPXIO_CLR_DONE; + if (pageLen > 0) { + NAND_TRANSFER_TO(addr, transBuf, pageLen); + } + if (oobLen > 0) { + pnx8550_nand_wait_for_dev_ready(); + + pnx8550_nand_register_setup(1, 0, 0, 1, 0, NAND_CMD_READOOB, 0); + /* Work out where in the OOB we are going to start to write */ + addr = NAND_ADDR(last_col_addr - mtd->oobblock, last_page_addr); + NAND_ADDR_SEND(addr); + pnx8550_nand_register_setup(2, 3, 1, 1, 0, NAND_CMD_SEQIN, + NAND_CMD_PAGEPROG); + + /* Clear the done flag */ + PNX8550_GPXIO_CTRL |= PNX8550_GPXIO_CLR_DONE; + NAND_TRANSFER_TO(addr, transBuf + pageLen, oobLen); + } + + /* + Increment the address so on the next write we write in the + correct place. + */ + last_col_addr += len; + if (last_col_addr >= mtd->oobblock + mtd->oobsize) { + last_col_addr -= mtd->oobblock + mtd->oobsize; + last_page_addr++; + } +} + +/** + * pnx8550_nand_read_buf - read chip data into buffer + * @mtd: MTD device structure + * @buf: buffer to store date + * @len: number of bytes to read + * + */ +static void pnx8550_nand_read_buf(struct mtd_info *mtd, u_char * buf, int len) +{ + struct nand_chip *this = mtd->priv; + int addr = NAND_ADDR(last_col_addr, last_page_addr); + int pageLen; + int oobLen = 0; + u_char *transBuf = buf; + + /* some sanity checking, word access only please */ + if (len & 1) { + printk("%s: non-word aligned length\n", __FUNCTION__); + } + + transBuf = transferBuffer; + + /* + Work out whether we are going to read the OOB area + after a standard page read. + This is not the case when the command function is called + with a column address > page size. Then we read as though + it is from the page rather than the OOB as the command + function has already selected the OOB area. + */ + if ((last_col_addr + len) > mtd->oobblock) + oobLen = (last_col_addr + len) - mtd->oobblock; + pageLen = len - oobLen; + + if (pageLen) { + NAND_TRANSFER_FROM(addr, transBuf, pageLen); + } + if (oobLen > 0) { + pnx8550_nand_register_setup(1, 3, 1, 1, 0, NAND_CMD_READOOB, 0); + addr = NAND_ADDR(last_col_addr - mtd->oobblock, last_page_addr); + NAND_TRANSFER_FROM(addr, transBuf + pageLen, oobLen); + } + if (transBuf != buf) { + memcpy(buf, transBuf, len); + } + + /* + Increment the address so on the next read we read from the + correct place. + */ + last_col_addr += len; + if (last_col_addr > mtd->oobblock + mtd->oobsize) { + last_col_addr -= mtd->oobblock + mtd->oobsize; + last_page_addr++; + } + return; +} + +/** + * pnx8550_nand_verify_buf - Verify chip data against buffer + * @mtd: MTD device structure + * @buf: buffer containing the data to compare + * @len: number of bytes to compare + * + */ +static int pnx8550_nand_verify_buf(struct mtd_info *mtd, const u_char * buf, + int len) +{ + int result = 0; + + /* some sanity checking, word access only please */ + if (len & 1) { + printk("%s: non-word aligned length\n", __FUNCTION__); + } + + pnx8550_nand_read_buf(mtd, transferBuffer, len); + if (memcmp(buf, transferBuffer, len)) { + result = -EFAULT; + } + + return result; + +} + +/** + * pnx8550_nand_command - Send command to NAND device + * @mtd: MTD device structure + * @command: the command to be sent + * @column: the column address for this command, -1 if none + * @page_addr: the page address for this command, -1 if none + * + * Send command to NAND device. + */ +static void pnx8550_nand_command(struct mtd_info *mtd, unsigned command, + int column, int page_addr) +{ + register struct nand_chip *this = mtd->priv; + u_char addr_no = 0; + u_char spare = 0; + int addr; + /* + If we are starting a write work out whether it is to the + OOB or the main page and position the pointer correctly. + */ + if (command == NAND_CMD_SEQIN) { + int readcmd; + int col = column; + if (column >= mtd->oobblock) { + /* OOB area */ + col -= mtd->oobblock; + readcmd = NAND_CMD_READOOB; + spare = 1; + } else { + readcmd = NAND_CMD_READ0; + } + pnx8550_nand_register_setup(1, 0, 0, 1, 0, readcmd, 0); + addr = NAND_ADDR(col, page_addr); + NAND_ADDR_SEND(addr); + } + + /* Check the number of address bytes */ + if ((column == -1) && (page_addr == -1)) { + addr_no = 0; + column = 0; + page_addr = 0; + } else if ((column == -1) && (page_addr != -1)) { + addr_no = 2; + column = 0; + } else if ((column != -1) && (page_addr == -1)) { + addr_no = 1; + page_addr = 0; + } else { + addr_no = 3; + } + + last_command = command; + last_col_addr = column; + last_page_addr = page_addr; + + switch (command) { + + case NAND_CMD_PAGEPROG: + // Nothing to do, we've already done it! + return; + + case NAND_CMD_SEQIN: + if (addr_no != 3) + printk + ("NAND: Error. Command %02x needs 3 byte address, but addr_no = %d\n", + command, addr_no); + pnx8550_nand_register_setup(2, 3, 1, 1, spare, NAND_CMD_SEQIN, + NAND_CMD_PAGEPROG); + return; + + case NAND_CMD_ERASE1: + if (addr_no != 2) + printk + ("NAND: Error. Command %02x needs 2 byte address, but addr_no = %d\n", + command, addr_no); + + PNX8550_GPXIO_CTRL |= PNX8550_GPXIO_CLR_DONE; + + pnx8550_nand_register_setup(2, 2, 0, 1, 0, NAND_CMD_ERASE1, + NAND_CMD_ERASE2); + addr = NAND_ADDR(column, page_addr); + NAND_ADDR_SEND(addr); + return; + + case NAND_CMD_ERASE2: + // Nothing to do, we've already done it! + return; + + case NAND_CMD_STATUS: + if (addr_no != 0) + printk + ("NAND: Error. Command %02x needs 0 byte address, but addr_no = %d\n", + command, addr_no); + pnx8550_nand_register_setup(1, 0, 1, 0, 0, NAND_CMD_STATUS, 0); + return; + + case NAND_CMD_RESET: + if (addr_no != 0) + printk + ("NAND: Error. Command %02x needs 0 byte address, but addr_no = %d\n", + command, addr_no); + pnx8550_nand_register_setup(1, 0, 0, 0, 0, NAND_CMD_RESET, 0); + addr = NAND_ADDR(column, page_addr); + NAND_ADDR_SEND(addr); + return; + + case NAND_CMD_READ0: + if (addr_no != 3) + printk + ("NAND: Error. Command %02x needs 3 byte address, but addr_no = %d\n", + command, addr_no); + + pnx8550_nand_register_setup(1, 3, 1, 1, 0, NAND_CMD_READ0, 0); + return; + + case NAND_CMD_READ1: + printk("Wrong command: %02x\n", command); + return; + + case NAND_CMD_READOOB: + if (addr_no != 3) + printk + ("NAND: Error. Command %02x needs 3 byte address, but addr_no = %d\n", + command, addr_no); + pnx8550_nand_register_setup(1, 3, 1, 1, 0, NAND_CMD_READOOB, 0); + return; + + case NAND_CMD_READID: + if (addr_no != 1) + printk + ("NAND: Error. Command %02x needs 1 byte address, but addr_no = %d\n", + command, addr_no); + pnx8550_nand_register_setup(1, 1, 1, 0, 0, NAND_CMD_READID, 0); + return; + } +} + +/* + * Setup the registers in PCIXIO + */ +static void pnx8550_nand_register_setup(u_char cmd_no, + u_char addr_no, + u_char include_data, + u_char monitor_ACK, + u_char enable64M, int cmd_a, int cmd_b) +{ + unsigned int reg_nand = 0; + reg_nand |= enable64M ? PNX8550_XIO_FLASH_64MB : 0; + reg_nand |= include_data ? PNX8550_XIO_FLASH_INC_DATA : 0; + reg_nand |= PNX8550_XIO_FLASH_CMD_PH(cmd_no); + reg_nand |= PNX8550_XIO_FLASH_ADR_PH(addr_no); + reg_nand |= PNX8550_XIO_FLASH_CMD_A(cmd_a); + reg_nand |= PNX8550_XIO_FLASH_CMD_B(cmd_b); + PNX8550_XIO_FLASH_CTRL = reg_nand; + barrier(); +} + +/* + * Wait for the device to be ready for the next command + */ +static inline void pnx8550_nand_wait_for_dev_ready(void) +{ + while ((PNX8550_XIO_CTRL & PNX8550_XIO_CTRL_XIO_ACK) == 0) ; +} + +/* + * Return true if the device is ready, false otherwise + */ +static int pnx8550_nand_dev_ready(struct mtd_info *mtd) +{ + return ((PNX8550_XIO_CTRL & PNX8550_XIO_CTRL_XIO_ACK) != 0); +} + +/* + * hardware specific access to control-lines + */ +static void pnx8550_nand_hwcontrol(struct mtd_info *mtd, int cmd) +{ + // Nothing to do here, its all done by the XIO block +} + +/* + * Main initialization routine + */ +int __init pnx8550_nand_init(void) +{ + struct nand_chip *this; + + /* Get pointer to private data */ + this = &pnx8550_nand; + + /* Initialize structures */ + memset((char *)&pnx8550_mtd, 0, sizeof(struct mtd_info)); + memset((char *)this, 0, sizeof(struct nand_chip)); + + /* Work out address of Nand Flash */ + pNandAddr = (u16 *) (KSEG1 | (PNX8550_BASE18_ADDR & (~0x7))); + + pNandAddr = (u16 *) (((u32) pNandAddr) + + ((PNX8550_XIO_SEL0 & PNX8550_XIO_SEL0_OFFSET_MASK) + >> PNX8550_XIO_SEL0_OFFSET_SHIFT) * 8 * 1024 * + 1024); + + /* Link the private data with the MTD structure */ + pnx8550_mtd.priv = this; + this->chip_delay = 15; + this->options = NAND_BUSWIDTH_16; + this->cmdfunc = pnx8550_nand_command; + this->read_byte = pnx8550_nand_read_byte; + this->read_word = pnx8550_nand_read_word; + this->read_buf = pnx8550_nand_read_buf; + this->write_byte = pnx8550_nand_write_byte; + this->write_word = pnx8550_nand_write_word; + this->write_buf = pnx8550_nand_write_buf; + this->verify_buf = pnx8550_nand_verify_buf; + this->dev_ready = pnx8550_nand_dev_ready; + this->hwcontrol = pnx8550_nand_hwcontrol; + this->eccmode = NAND_ECC_SOFT; + this->badblock_pattern = &nand16bit_memorybased; + this->autooob = &nand16bit_oob_16; + + transferBuffer = + kmalloc(pnx8550_mtd.oobblock + pnx8550_mtd.oobsize, + GFP_DMA | GFP_KERNEL); + if (!transferBuffer) { + printk(KERN_ERR + "Unable to allocate NAND data buffer for PNX8550.\n"); + return -ENOMEM; + } + + /* Scan to find existence of the device */ + if (nand_scan(&pnx8550_mtd, 1)) { + printk("%s: Exiting No Devices\n", __FUNCTION__); + return -ENXIO; + } + + /* Register the partitions */ + add_mtd_partitions(&pnx8550_mtd, partition_info, NUM_PARTITIONS); + + /* Return happy */ + return 0; +} + +module_init(pnx8550_nand_init); + +/* + * Clean up routine + */ +#ifdef MODULE +static void __exit pnx8550_nand_cleanup(void) +{ + /* Unregister the device */ + del_mtd_device(&pnx8550_mtd); + if (transferBuffer) { + kfree(transferBuffer); + } +} + +module_exit(pnx8550_nand_cleanup); +#endif + +MODULE_LICENSE("GPL"); +MODULE_AUTHOR("Adam Charrett"); +MODULE_DESCRIPTION("Driver for 16Bit NAND Flash on the XIO bus for PNX8550"); Index: linux-2.6.15_0/drivers/mtd/nand/Makefile =================================================================== --- linux-2.6.15_0.orig/drivers/mtd/nand/Makefile +++ linux-2.6.15_0/drivers/mtd/nand/Makefile @@ -18,5 +18,6 @@ obj-$(CONFIG_MTD_NAND_H1900) += h1910.o obj-$(CONFIG_MTD_NAND_RTC_FROM4) += rtc_from4.o obj-$(CONFIG_MTD_NAND_SHARPSL) += sharpsl.o obj-$(CONFIG_MTD_NAND_NANDSIM) += nandsim.o +obj-$(CONFIG_MTD_NAND_PNX8550) += pnx8550.o nand-objs = nand_base.o nand_bbt.o --------------060504000207000008090303-- From mark.e.mason@broadcom.com Fri Dec 16 21:35:39 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 16 Dec 2005 21:35:56 +0000 (GMT) Received: from mms1.broadcom.com ([216.31.210.17]:55557 "EHLO mms1.broadcom.com") by ftp.linux-mips.org with ESMTP id S8133557AbVLPVfj (ORCPT ); Fri, 16 Dec 2005 21:35:39 +0000 Received: from 10.10.64.121 by mms1.broadcom.com with SMTP (Broadcom SMTP Relay (Email Firewall v6.2.0)); Fri, 16 Dec 2005 13:19:52 -0800 X-Server-Uuid: F962EFE0-448C-40EE-8100-87DF498ED0EA Received: from mail-irva-8.broadcom.com ([10.10.64.221]) by mail-irva-1.broadcom.com (Post.Office MTA v3.5.3 release 223 ID# 0-72233U7200L2200S0V35) with ESMTP id com for ; Fri, 16 Dec 2005 13:19:50 -0800 Received: from mail-sj1-12.sj.broadcom.com (mail-sj1-12.sj.broadcom.com [10.16.128.215]) by mail-irva-8.broadcom.com (MOS 3.5.6-GR) with ESMTP id CIZ43338; Fri, 16 Dec 2005 13:19:49 -0800 (PST) Received: from NT-SJCA-0750.brcm.ad.broadcom.com (nt-sjca-0750 [10.16.192.220]) by mail-sj1-12.sj.broadcom.com (Postfix) with ESMTP id 23CA820501 for ; Fri, 16 Dec 2005 13:19:49 -0800 (PST) Received: from [127.0.0.1] ([10.240.253.7]) by NT-SJCA-0750.brcm.ad.broadcom.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 16 Dec 2005 13:19:48 -0800 Message-ID: <43A32F75.2050704@broadcom.com> Date: Fri, 16 Dec 2005 13:19:49 -0800 From: "Mark Mason" User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-mips@linux-mips.org Subject: Patch for 1125 PCI support X-Enigmail-Version: 0.93.0.0 OpenPGP: id=E9620E57; url= X-OriginalArrivalTime: 16 Dec 2005 21:19:48.0819 (UTC) FILETIME=[72012A30:01C60286] X-WSS-ID: 6FBDF0F24P458023-01-01 Content-Type: text/plain; charset=iso-8859-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: 9685 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: mason@broadcom.com Precedence: bulk X-list: linux-mips Hello all, Here's a little patch to re-enable PCI support on 1125 devices. Thanks, Mark diff --git a/arch/mips/pci/Makefile b/arch/mips/pci/Makefile --- a/arch/mips/pci/Makefile +++ b/arch/mips/pci/Makefile @@ -46,6 +46,7 @@ obj-$(CONFIG_PMC_YOSEMITE) += fixup-yose 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 +obj-$(CONFIG_SIBYTE_BCM112X) += fixup-sb1250.o pci-sb1250.o obj-$(CONFIG_SIBYTE_BCM1x80) += pci-bcm1480.o pci-bcm1480ht.o obj-$(CONFIG_SNI_RM200_PCI) += fixup-sni.o ops-sni.o obj-$(CONFIG_TANBAC_TB0219) += fixup-tb0219.o From p_christ@hol.gr Sat Dec 17 02:33:51 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 17 Dec 2005 02:34:08 +0000 (GMT) Received: from [62.38.104.168] ([62.38.104.168]:62863 "EHLO pfn3.pefnos") by ftp.linux-mips.org with ESMTP id S8133608AbVLQCdu convert rfc822-to-8bit (ORCPT ); Sat, 17 Dec 2005 02:33:50 +0000 Received: from xorhgos2.pefnos (xorhgos2.pefnos [192.168.0.3]) by pfn3.pefnos (Postfix) with ESMTP id 549701F101 for ; Sat, 17 Dec 2005 04:34:28 +0200 (EET) From: "P. Christeas" To: linux-mips@linux-mips.org Subject: Build error: undefined reference to `__ashrdi3' Date: Sat, 17 Dec 2005 04:34:19 +0200 User-Agent: KMail/1.9 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-7" Content-Transfer-Encoding: 8BIT Content-Disposition: inline Message-Id: <200512170434.21990.p_christ@hol.gr> 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: 9686 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: p_christ@hol.gr Precedence: bulk X-list: linux-mips Please, a little help here.. I tried to rebuild the toolchain, giving --with-float=soft, and still get the same (as with no such option). It is gcc 4.0.2 + ìClibc I am porting mips to a new board, so this may be my mistake. Somewhere I can kick-start this? How can a kernel build (which should be autonomous) depend on some compiler setup? From gtao.lu@gmail.com Sat Dec 17 02:50:31 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 17 Dec 2005 02:50:48 +0000 (GMT) Received: from zproxy.gmail.com ([64.233.162.192]:20302 "EHLO zproxy.gmail.com") by ftp.linux-mips.org with ESMTP id S8133608AbVLQCub (ORCPT ); Sat, 17 Dec 2005 02:50:31 +0000 Received: by zproxy.gmail.com with SMTP id l8so817232nzf for ; Fri, 16 Dec 2005 18:51:14 -0800 (PST) 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; b=RczxmGA7DKbv/KqJPjwLskCOANZEHt/LwkXkRcBD+M6HBJvqeNoO6bvMI0kEh2YWyYhfaxRkuhFbeB4mHki7HCZ5UML4t8VZ+CiEw83q6JkOU9ONHOJpqRQweRMOVwt7tUfnTgV5jBdcoBxj/AwWt8Uupe0kWWZhd0mMsC0wb0A= Received: by 10.65.160.12 with SMTP id m12mr337679qbo; Fri, 16 Dec 2005 18:51:14 -0800 (PST) Received: by 10.65.84.8 with HTTP; Fri, 16 Dec 2005 18:51:14 -0800 (PST) Message-ID: <85f7d96d0512161851w6b3b25fdk298eba8205ff4b12@mail.gmail.com> Date: Sat, 17 Dec 2005 10:51:14 +0800 From: Tao Lu To: linux-mips@linux-mips.org Subject: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_16199_1739903.1134787874016" 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: 9687 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: gtao.lu@gmail.com Precedence: bulk X-list: linux-mips ------=_Part_16199_1739903.1134787874016 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline ------=_Part_16199_1739903.1134787874016 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline ------=_Part_16199_1739903.1134787874016-- From annamshr@gmail.com Sun Dec 18 05:47:40 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 18 Dec 2005 05:47:59 +0000 (GMT) Received: from xproxy.gmail.com ([66.249.82.198]:19312 "EHLO xproxy.gmail.com") by ftp.linux-mips.org with ESMTP id S8133362AbVLRFrk convert rfc822-to-8bit (ORCPT ); Sun, 18 Dec 2005 05:47:40 +0000 Received: by xproxy.gmail.com with SMTP id s18so652015wxc for ; Sat, 17 Dec 2005 21:48:30 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=SszCEgsm7B9JBrpOdnlJklAtygo4Btu9McEdvwgVaKDDvShZdvRGRxqVFhU+aQUdg4vXtEjsEgSERDQqwcgQizMm5TQ28FAXknTbDKhusKlbnDP9uVyivkDu6Gf0rgJnyVgUSF+p0X2suHwk/o6WwhDqGEcr++dsliWZWvBUK+g= Received: by 10.70.24.17 with SMTP id 17mr3012727wxx; Sat, 17 Dec 2005 21:48:30 -0800 (PST) Received: by 10.70.26.3 with HTTP; Sat, 17 Dec 2005 21:48:29 -0800 (PST) Message-ID: <9498e5c10512172148g1388017bpd2f273ba78dcfdaa@mail.gmail.com> Date: Sun, 18 Dec 2005 11:18:29 +0530 From: Shireesh Annam To: linux-mips@linux-mips.org Subject: Re: 2.4.22 Kernel Build Error In-Reply-To: <9498e5c10512172146q17c25655t9df0224bf7443111@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT Content-Disposition: inline References: <9498e5c10512150449x625a7270s168d6a6339330e29@mail.gmail.com> <20051215145132.GA2812@linux-mips.org> <9498e5c10512151048n1e615614r7ded00ad77c48724@mail.gmail.com> <9498e5c10512172146q17c25655t9df0224bf7443111@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: 9688 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: annamshr@gmail.com Precedence: bulk X-list: linux-mips I repated the build process with the kernel versions 2.4.25 and 2.4.27 and I got the same errors. I downloaded these kernels from linux-mips.org through CVS. Can someone please explain me the mistake that I seem to be committing? I'm a newbie to Linux/MIPS arena and so find these errors very confusing. Thanks, Shireesh > On 12/16/05, Shireesh Annam wrote: > > I'm now using the SDE-Linux 5.03.06 for the big-endian target. I > > started the 2.4.22 kernel build process, but soon I get the following > > compile error. > > > > ********** > > make[2]: Entering directory `/root/linux/arch/mips/mm' > > mips-linux-gcc -D__KERNEL__ -I/root/linux/include -Wall > > -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing > > -fno-common -fomit-frame-pointer -I /root/linux/include/asm/gcc -G 0 > > -mno-abicalls -fno-pic -pipe -mabi=32 -mcpu=r4600 -mips2 -Wa,--trap > > -nostdinc -iwithprefix include -DKBUILD_BASENAME=sc_ip22 -c -o > > sc-ip22.o sc-ip22.c > > {standard input}: Assembler messages: > > {standard input}:126: Error: Number (0x9000000080000000) larger than 32 bits > > {standard input}:148: Error: Number (0x9000000080000000) larger than 32 bits > > {standard input}:168: Error: Number (0x9000000080000000) larger than 32 bits > > make[2]: *** [sc-ip22.o] Error 1 > > make[2]: Leaving directory `/root/linux/arch/mips/mm' > > make[1]: *** [first_rule] Error 2 > > make[1]: Leaving directory `/root/linux/arch/mips/mm' > > make: *** [_dir_arch/mips/mm] Error 2 > > > > ********** > > > > I'm not able to understand these error messages. Could someone throiw > > some light on this issue? Is this because of the toolchain that I'm > > using for building the kernel? > > > > Thanks, > > Shireesh > > > > On 12/15/05, Ralf Baechle wrote: > > > You're trying to build a stoneage kernel with a much newer compiler - > > > SDE 6 uses gcc 3.4 - which doesn't work. Use an older compiler such > > > as gcc <= 3.3.x. SDE 5.x contains gcc 2.96 btw. > > > > > > Ralf > > > > > > From oyvind.kristiansen@q-free.com Sun Dec 18 13:39:42 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 18 Dec 2005 13:40:01 +0000 (GMT) Received: from mxfw3.q-free.com ([62.92.116.8]:21776 "HELO mxfw3.q-free.com") by ftp.linux-mips.org with SMTP id S3458391AbVLRNjm convert rfc822-to-8bit (ORCPT ); Sun, 18 Dec 2005 13:39:42 +0000 Received: from hurricane.q-free.com ([192.168.4.14]) by mxfw3.q-free.com (NAVGW 2.5.1.2) with SMTP id M2005121814404221697 for ; Sun, 18 Dec 2005 14:40:42 +0100 Received: from oyvindk.q-free.com (h192-168-2-34.q-free.com [192.168.2.34] (may be forged)) by hurricane.q-free.com (8.12.8/8.12.8) with ESMTP id jBIDeTqT031375 for ; Sun, 18 Dec 2005 14:40:29 +0100 From: =?iso-8859-1?q?=D8yvind_Kristiansen?= (by way of =?iso-8859-1?q?=D8yvind_Kristiansen?= ) Subject: Re: 2.4.22 Kernel Build Error Date: Sun, 18 Dec 2005 14:40:29 +0100 User-Agent: KMail/1.6.2 To: linux-mips@linux-mips.org MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8BIT Message-Id: <200512181440.29297.oyvind.kristiansen@q-free.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: 9689 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: oyvind.kristiansen@q-free.com Precedence: bulk X-list: linux-mips Hi! Don't expect the Linux/MIPS port to be too stable. We have used it for some time, and personally I would not recommend most of the 2.4.x kernels. With the latest kernels, it seem they have improved greatly. Best Regards, Øyvind Kristiansen On Sunday 18 December 2005 06:48, you wrote: > I repated the build process with the kernel versions 2.4.25 and 2.4.27 > and I got the same errors. I downloaded these kernels from > linux-mips.org through CVS. > > Can someone please explain me the mistake that I seem to be > committing? I'm a newbie to Linux/MIPS arena and so find these errors > very confusing. > > Thanks, > Shireesh > > > On 12/16/05, Shireesh Annam wrote: > > > I'm now using the SDE-Linux 5.03.06 for the big-endian target. I > > > started the 2.4.22 kernel build process, but soon I get the following > > > compile error. > > > > > > ********** > > > make[2]: Entering directory `/root/linux/arch/mips/mm' > > > mips-linux-gcc -D__KERNEL__ -I/root/linux/include -Wall > > > -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing > > > -fno-common -fomit-frame-pointer -I /root/linux/include/asm/gcc -G 0 > > > -mno-abicalls -fno-pic -pipe -mabi=32 -mcpu=r4600 -mips2 -Wa,--trap > > > -nostdinc -iwithprefix include -DKBUILD_BASENAME=sc_ip22 -c -o > > > sc-ip22.o sc-ip22.c > > > {standard input}: Assembler messages: > > > {standard input}:126: Error: Number (0x9000000080000000) larger than 32 > > > bits {standard input}:148: Error: Number (0x9000000080000000) larger > > > than 32 bits {standard input}:168: Error: Number (0x9000000080000000) > > > larger than 32 bits make[2]: *** [sc-ip22.o] Error 1 > > > make[2]: Leaving directory `/root/linux/arch/mips/mm' > > > make[1]: *** [first_rule] Error 2 > > > make[1]: Leaving directory `/root/linux/arch/mips/mm' > > > make: *** [_dir_arch/mips/mm] Error 2 > > > > > > ********** > > > > > > I'm not able to understand these error messages. Could someone throiw > > > some light on this issue? Is this because of the toolchain that I'm > > > using for building the kernel? > > > > > > Thanks, > > > Shireesh > > > > > > On 12/15/05, Ralf Baechle wrote: > > > > You're trying to build a stoneage kernel with a much newer compiler - > > > > SDE 6 uses gcc 3.4 - which doesn't work. Use an older compiler such > > > > as gcc <= 3.3.x. SDE 5.x contains gcc 2.96 btw. > > > > > > > > Ralf -- Oyvind Kristiansen R&D Engineer Q-Free ASA P.O.Box 3974 Leangen 7443 Trondheim Norway E-Mail: oyvind.kristiansen@q-free.com WWW: http://www.q-free.com From p_christ@hol.gr Sun Dec 18 14:27:24 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 18 Dec 2005 14:27:41 +0000 (GMT) Received: from [62.38.104.168] ([62.38.104.168]:59316 "EHLO pfn3.pefnos") by ftp.linux-mips.org with ESMTP id S3458471AbVLRO1Y convert rfc822-to-8bit (ORCPT ); Sun, 18 Dec 2005 14:27:24 +0000 Received: from xorhgos2.pefnos (xorhgos2.pefnos [192.168.0.3]) by pfn3.pefnos (Postfix) with ESMTP id 225C61F101 for ; Sun, 18 Dec 2005 16:28:06 +0200 (EET) From: "P. Christeas" To: linux-mips@linux-mips.org Subject: Re: Build error: undefined reference to `__ashrdi3' Date: Sun, 18 Dec 2005 16:27:58 +0200 User-Agent: KMail/1.9 References: <200512170434.21990.p_christ@hol.gr> In-Reply-To: <200512170434.21990.p_christ@hol.gr> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-7" Content-Transfer-Encoding: 8BIT Content-Disposition: inline Message-Id: <200512181628.01482.p_christ@hol.gr> 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: 9690 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: p_christ@hol.gr Precedence: bulk X-list: linux-mips > Please, a little help here.. > I tried to rebuild the toolchain, giving --with-float=soft, and still get > the same (as with no such option). It is gcc 4.0.2 + ìClibc > I am porting mips to a new board, so this may be my mistake. Somewhere I > can kick-start this? > How can a kernel build (which should be autonomous) depend on some compiler > setup? FYI, I have copied prototypes for these fn's from arch/ppc and it builds now. From p_christ@hol.gr Mon Dec 19 11:24:47 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 19 Dec 2005 11:25:05 +0000 (GMT) Received: from [62.38.104.168] ([62.38.104.168]:6338 "EHLO pfn3.pefnos") by ftp.linux-mips.org with ESMTP id S8133864AbVLSLYr (ORCPT ); Mon, 19 Dec 2005 11:24:47 +0000 Received: from xorhgos2.pefnos (xorhgos2.pefnos [192.168.0.3]) by pfn3.pefnos (Postfix) with ESMTP id AB29D1F101 for ; Mon, 19 Dec 2005 13:25:37 +0200 (EET) From: "P. Christeas" To: linux-mips@linux-mips.org Subject: Q: where does cmdline come from in 2.6? Date: Mon, 19 Dec 2005 13:25:32 +0200 User-Agent: KMail/1.9 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200512191325.35156.p_christ@hol.gr> 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: 9691 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: p_christ@hol.gr Precedence: bulk X-list: linux-mips I am porting to a new platform. My board gives me a custom bootloader, which boots the kernel from a std uncompressed ELF image. In MIPS, how do I find the original cmdline the bootloader provides me? I know there is one. In 2.6.15-rc it seems to get overriden by some build-time line. Can you please give me a hint.. From yallain@avilinks.com Mon Dec 19 18:10:07 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 19 Dec 2005 18:10:24 +0000 (GMT) Received: from LAubervilliers-151-13-113-26.w217-128.abo.wanadoo.fr ([217.128.183.26]:57899 "EHLO serveurSMTP") by ftp.linux-mips.org with ESMTP id S8133886AbVLSSKH (ORCPT ); Mon, 19 Dec 2005 18:10:07 +0000 Received: from [192.168.150.1] by serveurSMTP (ArGoSoft Mail Server Freeware, Version 1.8 (1.8.8.2)); Mon, 19 Dec 2005 18:48:15 +0100 Message-ID: <43A6F155.7080402@avilinks.com> Date: Mon, 19 Dec 2005 18:43:49 +0100 From: Yoann Allain Organization: Avilinks User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: fr, en MIME-Version: 1.0 To: "'linux-mips@linux-mips.org'" Subject: Preempted interrupt handler 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: 9692 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: yallain@avilinks.com Precedence: bulk X-list: linux-mips Hi, I'm actually working on a driver for a Marvell chip on a MIPS-based board running a 2.4 kernel. I have one problem: In my module, my interrupt handler is never executed. I have traced the code until action->handler(irq, action->dev_id, regs) in handle_IRQ_event() but when the handler should be executed, it is not and the kernel reenters in the low-level interrupt dispatch routine (because we're using level sensitive interrupts and it is still up). I've checked that the function pointer called is the one of my handler but my routine is never entered. But when my handler is included in the kernel (ie not compiled as a module), it works! My function gets executed and acks the interrupt. In this case all goes fine. Moreover, I've noticed that the kernel symbols are mapped at adresses like 0x80258040 (start_kernel) but my module (and so is my handler) is loaded at something like 0xc000275c . I was thinking the module would be loaded in the same memory area as the kernel, so I think this is weird... Perhaps, the module handler can't be executed because of its location but I don't know how to fix this. Some suggestions? Thanks in advance. Yoann From mbizon@freebox.fr Tue Dec 20 02:56:17 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 20 Dec 2005 02:56:34 +0000 (GMT) Received: from sakura.staff.proxad.net ([213.228.1.107]:61894 "EHLO sakura.staff.proxad.net") by ftp.linux-mips.org with ESMTP id S8133960AbVLTC4R (ORCPT ); Tue, 20 Dec 2005 02:56:17 +0000 Received: from max by sakura.staff.proxad.net with local (Exim 3.36 #1 (Debian)) id 1EoXgk-0006Jq-00 for ; Tue, 20 Dec 2005 03:57:18 +0100 Subject: Kernel freezes in r4k_flush_icache_range() with CONFIG_CPU_MIPS32_R2 From: Maxime Bizon To: linux-mips@linux-mips.org Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Tue, 20 Dec 2005 03:57:18 +0100 Message-Id: <1135047438.9874.74.camel@sakura.staff.proxad.net> Mime-Version: 1.0 X-Mailer: Evolution 2.4.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: 9693 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: mbizon@freebox.fr Precedence: bulk X-list: linux-mips Hello all, I'm porting linux for a board with a R4KECr2. So far I was using CONFIG_CPU_MIPS32_R1 and the kernel (2.6.14) was running well. But I'm unable to get it working with CONFIG_CPU_MIPS32_R2, it freezes somewhere in trap_init, more exactly in r4k_flush_icache_range(). Here is a snippet from the generated assembly code: 00002624 : 2624: 27bdffd0 addiu sp,sp,-48 2628: 3c020000 lui v0,0x0 262c: afb30024 sw s3,36(sp) 2630: afb20020 sw s2,32(sp) 2634: afbf0028 sw ra,40(sp) 2638: afb1001c sw s1,28(sp) 263c: afb00018 sw s0,24(sp) [...] 26a0: bc900000 cache 0x10,0(a0) 26a4: 1464fffd bne v1,a0,269c 26a8: 3c020000 lui v0,0x0 26ac: 2442277c addiu v0,v0,10108 <---------- 26b0: 00400408 jr.hb v0 26b4: 00000000 nop [...] 272c: 8c43000c lw v1,12(v0) 2730: 0060f809 jalr v1 2734: 00000000 nop 2738: 3c020000 lui v0,0x0 273c: 2442277c addiu v0,v0,10108 <---------- 2740: 00400408 jr.hb v0 2744: 00000000 nop 2748: 8fbf0028 lw ra,40(sp) 274c: 8fb30024 lw s3,36(sp) 2750: 8fb20020 lw s2,32(sp) 2754: 8fb1001c lw s1,28(sp) 2758: 8fb00018 lw s0,24(sp) 275c: 03e00008 jr ra 2760: 27bd0030 addiu sp,sp,48 2764: 3c020000 lui v0,0x0 2768: 8c430018 lw v1,24(v0) 276c: 0060f809 jalr v1 2770: 00000000 nop 2774: 0800099c j 2670 2778: 3c030000 lui v1,0x0 0000277c : [...] At offset 0x26ac and 0x273c, we can see that instruction_hazard() got duplicated due to inlining, and that the jr.hb is going to send us to 10108 (0x277C), outside the function... The only way I managed to get a good value in v0 was by using -O0 and making r4k_flush_icache_range return int. Now I'm really not familiar with gcc inline assembly so I don't know if this is a compiler bug or if something is missing in instruction_hazard(). # mipsel-linux-gcc -v Using built-in specs. Target: mipsel-linux-uclibc Configured with: /home/work/buildroot/toolchain_build_mipsel/gcc-4.0.2/configure --prefix=/opt/toolchains/mipsel-uclibc-0.9.28-gcc-4.0.2 --build=i386-pc-linux-gnu --host=i386-pc-linux-gnu --target=mipsel-linux-uclibc --enable-languages=c,c++ --enable-shared --disable-__cxa_atexit --enable-target-optspace --with-gnu-ld --disable-nls --enable-threads --enable-multilib Thread model: posix gcc version 4.0.2 # Thanks, -- Maxime From mbizon@freebox.fr Tue Dec 20 05:31:18 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 20 Dec 2005 05:31:36 +0000 (GMT) Received: from sakura.staff.proxad.net ([213.228.1.107]:33202 "EHLO sakura.staff.proxad.net") by ftp.linux-mips.org with ESMTP id S8133351AbVLTFbS (ORCPT ); Tue, 20 Dec 2005 05:31:18 +0000 Received: from max by sakura.staff.proxad.net with local (Exim 3.36 #1 (Debian)) id 1Eoa6m-0001cW-00 for ; Tue, 20 Dec 2005 06:32:20 +0100 Subject: [PATCH] fix local_irq_save()/local_irq_restore() when CONFIG_CPU_MIPSR2 & CONFIG_IRQ_CPU From: Maxime Bizon To: linux-mips@linux-mips.org Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Tue, 20 Dec 2005 06:32:19 +0100 Message-Id: <1135056739.9874.95.camel@sakura.staff.proxad.net> Mime-Version: 1.0 X-Mailer: Evolution 2.4.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: 9694 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: mbizon@freebox.fr Precedence: bulk X-list: linux-mips Hello all, I was unable to get my R4KECr2 board working with CONFIG_CPU_MIPSR2 & CONFIG_IRQ_CPU, irq delivery is not working. local_irq_restore() logic is to check that "flags" is non zero, and enable irq accordingly. But "flags" comes directly from di, which according to mips instruction set, saves whole status content, not just IE bit. Attached patch to fix this. Signed-off-by: Maxime Bizon --- linux.git/include/asm-mips/interrupt.h.old 2005-12-20 06:20:44.000000000 +0100 +++ linux.git/include/asm-mips/interrupt.h 2005-12-20 06:21:02.000000000 +0100 @@ -93,6 +93,7 @@ " .set noat \n" #ifdef CONFIG_CPU_MIPSR2 " di \\result \n" + " andi \\result, 1 \n" #else " mfc0 \\result, $12 \n" " ori $1, \\result, 1 \n" Thanks, -- Maxime From macro@linux-mips.org Tue Dec 20 11:46:40 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 20 Dec 2005 11:47:00 +0000 (GMT) Received: from pollux.ds.pg.gda.pl ([153.19.208.7]:44811 "EHLO pollux.ds.pg.gda.pl") by ftp.linux-mips.org with ESMTP id S3457893AbVLTLqk (ORCPT ); Tue, 20 Dec 2005 11:46:40 +0000 Received: from localhost (localhost [127.0.0.1]) by pollux.ds.pg.gda.pl (Postfix) with ESMTP id 49609F59F9; Tue, 20 Dec 2005 12:47:40 +0100 (CET) Received: from pollux.ds.pg.gda.pl ([127.0.0.1]) by localhost (pollux [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 14133-06; Tue, 20 Dec 2005 12:47:40 +0100 (CET) Received: from piorun.ds.pg.gda.pl (piorun.ds.pg.gda.pl [153.19.208.8]) by pollux.ds.pg.gda.pl (Postfix) with ESMTP id 0215EF59F7; Tue, 20 Dec 2005 12:47:40 +0100 (CET) Received: from blysk.ds.pg.gda.pl (macro@blysk.ds.pg.gda.pl [153.19.208.6]) by piorun.ds.pg.gda.pl (8.13.3/8.13.1) with ESMTP id jBKBlXh2014236; Tue, 20 Dec 2005 12:47:33 +0100 Date: Tue, 20 Dec 2005 11:47:42 +0000 (GMT) From: "Maciej W. Rozycki" To: Maxime Bizon Cc: linux-mips@linux-mips.org Subject: Re: Kernel freezes in r4k_flush_icache_range() with CONFIG_CPU_MIPS32_R2 In-Reply-To: <1135047438.9874.74.camel@sakura.staff.proxad.net> Message-ID: References: <1135047438.9874.74.camel@sakura.staff.proxad.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: ClamAV 0.87.1/1213/Mon Dec 19 15:48:34 2005 on piorun.ds.pg.gda.pl X-Virus-Status: Clean X-Virus-Scanned: by amavisd-new at pollux.ds.pg.gda.pl 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: 9695 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: macro@linux-mips.org Precedence: bulk X-list: linux-mips On Tue, 20 Dec 2005, Maxime Bizon wrote: > 272c: 8c43000c lw v1,12(v0) > 2730: 0060f809 jalr v1 > 2734: 00000000 nop > 2738: 3c020000 lui v0,0x0 > 273c: 2442277c addiu v0,v0,10108 <---------- > 2740: 00400408 jr.hb v0 > 2744: 00000000 nop > 2748: 8fbf0028 lw ra,40(sp) > 274c: 8fb30024 lw s3,36(sp) > 2750: 8fb20020 lw s2,32(sp) > 2754: 8fb1001c lw s1,28(sp) > 2758: 8fb00018 lw s0,24(sp) > 275c: 03e00008 jr ra > 2760: 27bd0030 addiu sp,sp,48 > 2764: 3c020000 lui v0,0x0 > 2768: 8c430018 lw v1,24(v0) > 276c: 0060f809 jalr v1 > 2770: 00000000 nop > 2774: 0800099c j 2670 > 2778: 3c030000 lui v1,0x0 > > 0000277c : > [...] > > At offset 0x26ac and 0x273c, we can see that instruction_hazard() got > duplicated due to inlining, and that the jr.hb is going to send us to > 10108 (0x277C), outside the function... FYI, GCC 3.4.4 produces the following code which is clearly wrong: .align 2 .align 3 .ent r4k_flush_icache_range .type r4k_flush_icache_range, @function r4k_flush_icache_range: .set nomips16 .frame $sp,56,$31 # vars= 16, regs= 5/0, args= 16, gp= 0 .mask 0x800f0000,-8 .fmask 0x00000000,0 [...] lui $2,%hi($L506) # 239 movsi_internal/2 [length = 4] addiu $2,$2,%lo($L506) # 240 *lowsi [length = 4] #APP jr.hb $2 #NO_APP lw $31,48($sp) # 304 movsi_internal/4 [length = 4] lw $19,44($sp) # 305 movsi_internal/4 [length = 4] lw $18,40($sp) # 306 movsi_internal/4 [length = 4] lw $17,36($sp) # 307 movsi_internal/4 [length = 4] lw $16,32($sp) # 308 movsi_internal/4 [length = 4] .set noreorder .set nomacro j $31 # 310 return_internal [length = 4] addiu $sp,$sp,56 # 309 addsi3_internal/2 [length = 4] .set macro .set reorder $L510: lui $2,%hi(r4k_blast_icache) # 181 movsi_internal/2 [length = 4] lw $3,%lo(r4k_blast_icache)($2) # 182 movsi_internal/4 [length = 4] jal $3 # 183 call_internal/1 [length = 8] lui $2,%hi($L506) # 313 movsi_internal/2 [length = 4] addiu $2,$2,%lo($L506) # 314 *lowsi [length = 4] #APP jr.hb $2 #NO_APP lw $31,48($sp) # 316 movsi_internal/4 [length = 4] lw $19,44($sp) # 317 movsi_internal/4 [length = 4] lw $18,40($sp) # 318 movsi_internal/4 [length = 4] lw $17,36($sp) # 319 movsi_internal/4 [length = 4] lw $16,32($sp) # 320 movsi_internal/4 [length = 4] .set noreorder .set nomacro j $31 # 322 return_internal [length = 4] addiu $sp,$sp,56 # 321 addsi3_internal/2 [length = 4] .set macro .set reorder $L508: lui $2,%hi(r4k_blast_dcache) # 67 movsi_internal/2 [length = 4] lw $3,%lo(r4k_blast_dcache)($2) # 68 movsi_internal/4 [length = 4] jal $3 # 69 call_internal/1 [length = 8] .set noreorder .set nomacro b $L512 # 334 jump [length = 4] lui $3,%hi(icache_size) # 170 movsi_internal/2 [length = 4] .set macro .set reorder $L506: .end r4k_flush_icache_range Please file a bug report at: "http://gcc.gnu.org/bugzilla/". Maciej From macro@linux-mips.org Tue Dec 20 11:59:04 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 20 Dec 2005 11:59:22 +0000 (GMT) Received: from pollux.ds.pg.gda.pl ([153.19.208.7]:42513 "EHLO pollux.ds.pg.gda.pl") by ftp.linux-mips.org with ESMTP id S3457227AbVLTL7E (ORCPT ); Tue, 20 Dec 2005 11:59:04 +0000 Received: from localhost (localhost [127.0.0.1]) by pollux.ds.pg.gda.pl (Postfix) with ESMTP id DF40CF59F7; Tue, 20 Dec 2005 13:00:04 +0100 (CET) Received: from pollux.ds.pg.gda.pl ([127.0.0.1]) by localhost (pollux [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 05337-08; Tue, 20 Dec 2005 13:00:04 +0100 (CET) Received: from piorun.ds.pg.gda.pl (piorun.ds.pg.gda.pl [153.19.208.8]) by pollux.ds.pg.gda.pl (Postfix) with ESMTP id A1510F59F4; Tue, 20 Dec 2005 13:00:02 +0100 (CET) Received: from blysk.ds.pg.gda.pl (macro@blysk.ds.pg.gda.pl [153.19.208.6]) by piorun.ds.pg.gda.pl (8.13.3/8.13.1) with ESMTP id jBKBxutK014829; Tue, 20 Dec 2005 12:59:56 +0100 Date: Tue, 20 Dec 2005 12:00:05 +0000 (GMT) From: "Maciej W. Rozycki" To: Maxime Bizon Cc: linux-mips@linux-mips.org Subject: Re: [PATCH] fix local_irq_save()/local_irq_restore() when CONFIG_CPU_MIPSR2 & CONFIG_IRQ_CPU In-Reply-To: <1135056739.9874.95.camel@sakura.staff.proxad.net> Message-ID: References: <1135056739.9874.95.camel@sakura.staff.proxad.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: ClamAV 0.87.1/1213/Mon Dec 19 15:48:34 2005 on piorun.ds.pg.gda.pl X-Virus-Status: Clean X-Virus-Scanned: by amavisd-new at pollux.ds.pg.gda.pl 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: 9696 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: macro@linux-mips.org Precedence: bulk X-list: linux-mips On Tue, 20 Dec 2005, Maxime Bizon wrote: > But "flags" comes directly from di, which according to mips instruction > set, saves whole status content, not just IE bit. > > Attached patch to fix this. Or alternatively something like this: "http://www.linux-mips.org/cgi-bin/mesg.cgi?a=linux-mips&i=Pine.LNX.4.61L.0507121626370.14155%40blysk.ds.pg.gda.pl", for consistency with the other variants. It looks like we are the only two who care... Maciej From ralf@linux-mips.org Tue Dec 20 13:17:47 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 20 Dec 2005 13:18:05 +0000 (GMT) Received: from p549F54A9.dip.t-dialin.net ([84.159.84.169]:57161 "EHLO mail.linux-mips.net") by ftp.linux-mips.org with ESMTP id S8126482AbVLTNRr (ORCPT ); Tue, 20 Dec 2005 13:17:47 +0000 Received: from fluff.linux-mips.net (localhost.localdomain [127.0.0.1]) by mail.linux-mips.net (8.13.4/8.13.1) with ESMTP id jBKDIYgC006601; Tue, 20 Dec 2005 14:18:34 +0100 Received: (from ralf@localhost) by fluff.linux-mips.net (8.13.4/8.13.4/Submit) id jBKDITN4006600; Tue, 20 Dec 2005 14:18:29 +0100 Date: Tue, 20 Dec 2005 14:18:29 +0100 From: Ralf Baechle To: Yoann Allain Cc: "'linux-mips@linux-mips.org'" Subject: Re: Preempted interrupt handler Message-ID: <20051220131829.GB3376@linux-mips.org> References: <43A6F155.7080402@avilinks.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <43A6F155.7080402@avilinks.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: 9697 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, Dec 19, 2005 at 06:43:49PM +0100, Yoann Allain wrote: > I'm actually working on a driver for a Marvell chip on a MIPS-based > board running a 2.4 kernel. I have one problem: > In my module, my interrupt handler is never executed. I have traced the > code until action->handler(irq, action->dev_id, regs) in > handle_IRQ_event() but when the handler should be executed, it is not > and the kernel reenters in the low-level interrupt dispatch routine > (because we're using level sensitive interrupts and it is still up). > I've checked that the function pointer called is the one of my handler > but my routine is never entered. > > But when my handler is included in the kernel (ie not compiled as a > module), it works! My function gets executed and acks the interrupt. In > this case all goes fine. > > Moreover, I've noticed that the kernel symbols are mapped at adresses > like 0x80258040 (start_kernel) but my module (and so is my handler) is > loaded at something like 0xc000275c . I was thinking the module would be > loaded in the same memory area as the kernel, so I think this is weird... > Perhaps, the module handler can't be executed because of its location > but I don't know how to fix this. Good new then - you don't need to fix anything :-) The sympthoms you're describing are not specific enough, so only some general advice: - Make sure you're running a current version of modutils; older versions have a number of bugs that could result in almost any kind of ill behaviour. - Make sure all object files of the modules have been built with -mlong-calls. That's done automatically by the kernel's makefiles but not necessarily when building out of tree and certain versions would silently tolerate the resulting relocation error. Ralf From vbarinov@ru.mvista.com Tue Dec 20 14:27:18 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 20 Dec 2005 14:27:42 +0000 (GMT) Received: from rtsoft3.corbina.net ([85.21.88.6]:29851 "EHLO buildserver.ru.mvista.com") by ftp.linux-mips.org with ESMTP id S8126484AbVLTO1S (ORCPT ); Tue, 20 Dec 2005 14:27:18 +0000 Received: from [192.168.12.17] ([10.149.0.1]) by buildserver.ru.mvista.com (8.11.6/8.11.6) with ESMTP id jBKERxt11783; Tue, 20 Dec 2005 18:27:59 +0400 Message-ID: <43A814EF.6060509@ru.mvista.com> Date: Tue, 20 Dec 2005 17:27:59 +0300 From: "Vladimir A. Barinov" User-Agent: Mozilla Thunderbird 1.0.2-6 (X11/20050513) X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-mtd@lists.infradead.org, linux-mips@linux-mips.org Subject: Re: [PATCH] PNX8550 NAND flash driver References: <43A2F819.1040106@ru.mvista.com> In-Reply-To: <43A2F819.1040106@ru.mvista.com> Content-Type: multipart/mixed; boundary="------------050702040603060002030909" 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: 9698 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: vbarinov@ru.mvista.com Precedence: bulk X-list: linux-mips This is a multi-part message in MIME format. --------------050702040603060002030909 Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit Hi, Vladimir A. Barinov wrote: > Hi All, > > Attached patch is NAND flash driver for PNX8550 based platforms. > Any comments and suggestions are highly appreciated. Sorry, but this patch is not complete. It's needed to add include/../nand.h file. Attachment is the recasted variant (removing "volatile u16 *" usage, "prink" usage changes and some cosmetic changes) with nand.h part. Vladimir --------------050702040603060002030909 Content-Type: text/plain; name="nand.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="nand.patch" Signed-off-by: vbarinov@ru.mvista.com drivers/mtd/nand/Kconfig | 6 drivers/mtd/nand/Makefile | 1 drivers/mtd/nand/pnx8550.c | 694 +++++++++++++++++++++++++++++++++++ include/asm-mips/mach-pnx8550/nand.h | 22 + 4 files changed, 721 insertions(+), 2 deletions(-) Index: linux-2.6.15_0/drivers/mtd/nand/Kconfig =================================================================== --- linux-2.6.15_0.orig/drivers/mtd/nand/Kconfig +++ linux-2.6.15_0/drivers/mtd/nand/Kconfig @@ -90,6 +90,12 @@ config MTD_NAND_S3C2410 No board specfic support is done by this driver, each board must advertise a platform_device for the driver to attach. +config MTD_NAND_PNX8550 + tristate "NAND Flash support for PNX8550" + depends on PNX8550 && MTD_NAND + help + This enables the NAND flash controller on the PNX8550. + config MTD_NAND_S3C2410_DEBUG bool "S3C2410 NAND driver debug" depends on MTD_NAND_S3C2410 Index: linux-2.6.15_0/drivers/mtd/nand/pnx8550.c =================================================================== --- /dev/null +++ linux-2.6.15_0/drivers/mtd/nand/pnx8550.c @@ -0,0 +1,694 @@ +/* + * Copyright (C) 2005 Koninklijke Philips Electronics N.V. + * All Rights Reserved. + * + * 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., 675 Mass Ave, Cambridge, MA 02139, USA. + * + * Overview: + * This is a device driver for the NAND flash device found on the + * PNX8550 board which utilizes the Samsung K9F5616U0C part. This is + * a 32MByte (16M x 16 bits) NAND flash device. + */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#define UBTM_NAME "microBTM" +#define UBTM_BLOCK_START ( 0x00000000) +#define UBTM_BLOCK_END ( 0x00004000) /* 16K size, first block */ +#define UBTM_SIZE ( UBTM_BLOCK_END - UBTM_BLOCK_START) + +#define BOOTLOADER_NAME "bootloader" +#define BOOTLOADER_BLOCK_START ( UBTM_BLOCK_END) +#define BOOTLOADER_BLOCK_END ( 0x00040000) /* 256K - 16K = 240K */ +#define BOOTLOADER_SIZE ( BOOTLOADER_BLOCK_END - BOOTLOADER_BLOCK_START) + +#define ROMFS_SYS_NAME "ROMFS-Tools" +#define ROMFS_SYS_BLOCK_START ( BOOTLOADER_BLOCK_END) +#define ROMFS_SYS_BLOCK_END ( 0x00600000) /* 6M - 256K = 5.75M */ +#define ROMFS_SYS_SIZE ( ROMFS_SYS_BLOCK_END - ROMFS_SYS_BLOCK_START) + +#define ROMFS_APP_NAME "ROMFS-User" +#define ROMFS_APP_BLOCK_START ( ROMFS_SYS_BLOCK_END) +#define ROMFS_APP_BLOCK_END ( 0x01000000) /* 16M - 6M = 10M */ +#define ROMFS_APP_SIZE ( ROMFS_APP_BLOCK_END - ROMFS_APP_BLOCK_START) + +#define USER_NAME "User" +#define USER_BLOCK_START ( ROMFS_APP_BLOCK_END) +#define USER_BLOCK_END ( 0x02000000) /* 32M - 16M = 16M */ +#define USER_SIZE ( USER_BLOCK_END - USER_BLOCK_START) + +#define NAND_ADDR(_col, _page) ((_col) & (mtd->oobblock - 1)) + ((_page) << this->page_shift) + +#define NAND_ADDR_SEND(_addr) writew(0, pNandAddr + _addr) + +#define NAND_TRANSFER_TO(_addr, _buffer, _bytes) pnx8550_nand_transfer(_buffer, pNandAddr + _addr, _bytes, 1) +#define NAND_TRANSFER_FROM(_addr, _buffer, _bytes) pnx8550_nand_transfer(pNandAddr + _addr, _buffer, _bytes, 0) + +/* + * Define partitions for flash device + */ +#define NUM_PARTITIONS 5 +const static struct mtd_partition partition_info[NUM_PARTITIONS] = { + { + .name = UBTM_NAME, + .offset = UBTM_BLOCK_START, + .size = UBTM_SIZE}, + { + .name = BOOTLOADER_NAME, + .offset = BOOTLOADER_BLOCK_START, + .size = BOOTLOADER_SIZE}, + { + .name = ROMFS_SYS_NAME, + .offset = ROMFS_SYS_BLOCK_START, + .size = ROMFS_SYS_SIZE}, + { + .name = ROMFS_APP_NAME, + .offset = ROMFS_APP_BLOCK_START, + .size = ROMFS_APP_SIZE}, + { + .name = USER_NAME, + .offset = USER_BLOCK_START, + .size = USER_SIZE} +}; + +/* Bad block descriptor for 16Bit nand flash */ +static uint8_t scan_ff_pattern[] = { 0xff, 0xff }; +static struct nand_bbt_descr nand16bit_memorybased = { + .options = 0, + .offs = 0, + .len = 2, + .pattern = scan_ff_pattern +}; + +/* OOB Placement information that lines up with the boot loader code */ +static struct nand_oobinfo nand16bit_oob_16 = { + .useecc = MTD_NANDECC_AUTOPLACE, + .eccbytes = 6, + .eccpos = {2, 3, 4, 5, 6, 7}, + .oobfree = {{8, 8}} +}; + +/* Pointer into XIO for access to the 16Bit NAND flash device */ +static u8 *pNandAddr; + +/* Last command sent to the pnx8550_nand_command function */ +static int last_command = -1; +/* + * Next column address to read/write, set by pnx8550_nand_command + * updated by the read/write functions + */ +static int last_col_addr = -1; +/* + * Next page address to read/write, set by pnx8550_nand_command + * updated by the read/write functions + */ +static int last_page_addr = -1; + +/* 32bit Aligned/DMA buffer */ +static u_char *transferBuffer; + +static struct mtd_info pnx8550_mtd; +static struct nand_chip pnx8550_nand; + +/** + * Setup the registers in PCIXIO + */ +static void pnx8550_nand_register_setup(u_char cmd_no, + u_char addr_no, + u_char include_data, + u_char monitor_ACK, + u_char enable64M, int cmd_a, int cmd_b) +{ + unsigned int reg_nand = 0; + reg_nand |= enable64M ? PNX8550_XIO_FLASH_64MB : 0; + reg_nand |= include_data ? PNX8550_XIO_FLASH_INC_DATA : 0; + reg_nand |= PNX8550_XIO_FLASH_CMD_PH(cmd_no); + reg_nand |= PNX8550_XIO_FLASH_ADR_PH(addr_no); + reg_nand |= PNX8550_XIO_FLASH_CMD_A(cmd_a); + reg_nand |= PNX8550_XIO_FLASH_CMD_B(cmd_b); + PNX8550_XIO_FLASH_CTRL = reg_nand; + barrier(); +} + +/** + * Wait for the device to be ready for the next command + */ +static inline void pnx8550_nand_wait_for_dev_ready(void) +{ + while ((PNX8550_XIO_CTRL & PNX8550_XIO_CTRL_XIO_ACK) == 0) ; +} + +/** + * Transfer data to/from the NAND chip using DMA + * + * @from: Address to transfer data from + * @to: Address to transfer the data to + * @bytes: Number of bytes to transfer + * @toxio: Whether the transfer is going to XIO or not. + */ +static void pnx8550_nand_transferDMA(void *from, void *to, int bytes, int toxio) +{ + int cmd = 0; + u32 internal; + u32 external; + + if (toxio) { + cmd = PNX8550_DMA_CTRL_PCI_CMD_WRITE; + dma_cache_wback((unsigned long)from, bytes); + internal = (u32) virt_to_phys(from); + external = (u32) to - KSEG1; + } else { + cmd = PNX8550_DMA_CTRL_PCI_CMD_READ; + internal = (u32) virt_to_phys(to); + external = (u32) from - KSEG1; + } + + local_irq_disable(); + PNX8550_DMA_TRANS_SIZE = bytes >> 2; /* Length in words */ + PNX8550_DMA_EXT_ADDR = external; + PNX8550_DMA_INT_ADDR = internal; + PNX8550_DMA_INT_CLEAR = 0xffff; + PNX8550_DMA_CTRL = PNX8550_DMA_CTRL_BURST_512 | + PNX8550_DMA_CTRL_SND2XIO | PNX8550_DMA_CTRL_INIT_DMA | cmd; + + while ((PNX8550_DMA_INT_STATUS & PNX8550_DMA_INT_COMPL) == 0) ; + + if (!toxio) + dma_cache_inv((unsigned long)to, bytes); + + local_irq_enable(); +} + +/** + * Transfer data to/from the NAND chip. + * This function decides whether to use DMA or not depending on + * the amount of data to transfer and the alignment of the buffers. + * + * @from: Address to transfer data from + * @to: Address to transfer the data to + * @bytes: Number of bytes to transfer + * @toxio: Whether the transfer is going to XIO or not. + */ +static void pnx8550_nand_transfer(void *from, void *to, int bytes, int toxio) +{ + u16 *from16 = (u16 *) from; + u16 *to16 = (u16 *) to; + + int i; + + if ((u32) from & 3) + printk(KERN_INFO "%s: from buffer not 32bit aligned, will not " + "use fastest transfer mechanism\n", __FUNCTION__); + if ((u32) to & 3) + printk(KERN_INFO "%s: to buffer not 32bit aligned, will not " + "use fastest transfer mechanism\n", __FUNCTION__); + + if (((bytes & 3) || (bytes < 16)) || ((u32) to & 3) || ((u32) from & 3)) { + if (((bytes & 1) == 0) && + (((u32) to & 1) == 0) && (((u32) from & 1) == 0)) { + int words = bytes / 2; + + local_irq_disable(); + for (i = 0; i < words; i++) + to16[i] = from16[i]; + local_irq_enable(); + } + else + printk(KERN_ERR "%s: Transfer failed, " + "byte-aligned transfers no allowed!\n", + __FUNCTION__); + } else { + pnx8550_nand_transferDMA(from, to, bytes, toxio); + } +} + +/** + * pnx8550_nand_read_byte - read one byte endianess aware from the chip + * @mtd: MTD device structure + */ +static u_char pnx8550_nand_read_byte(struct mtd_info *mtd) +{ + struct nand_chip *this = mtd->priv; + u16 data = 0; + int addr = NAND_ADDR(last_col_addr, last_page_addr); + /* + * Read ID is a special case as we have to read BOTH bytes at the same + * time otherwise it doesn't work, once we have both bytes we work out + * which one we want. + */ + if (last_command == NAND_CMD_READID) { + u32 data32; + data32 = cpu_to_le32(readl(pNandAddr + 0)); + if (last_col_addr) + data = (u16) (data32 >> 16); + else + data = (u16) data32; + } else { + data = readw(pNandAddr + addr); + if ((addr & 0x1) == 1) + data = (data & 0xff00) >> 16; + } + /* + * Status is a special case, we don't need to increment the address + * because the address isn't used by the chip + */ + if (last_command != NAND_CMD_STATUS) + last_col_addr++; + + return data & 0xff; +} + +/** + * pnx8550_nand_read_word - read one word from the chip + * @mtd: MTD device structure + * + * Read function for 16bit buswith without + * endianess conversion + */ +static u16 pnx8550_nand_read_word(struct mtd_info *mtd) +{ + struct nand_chip *this = mtd->priv; + int addr = NAND_ADDR(last_col_addr, last_page_addr); + u16 data = readw(pNandAddr + addr); + return data; +} + +/** + * pnx8550_nand_write_byte - write one byte endianess aware to the chip + * @mtd: MTD device structure + * @byte: pointer to data byte to write + * + * Write function for 16bit buswith with + * endianess conversion + */ +static void pnx8550_nand_write_byte(struct mtd_info *mtd, u_char byte) +{ + struct nand_chip *this = mtd->priv; + int addr = NAND_ADDR(last_col_addr, last_page_addr); + writew(le16_to_cpu((u16) byte), pNandAddr + addr); +} + +/** + * pnx8550_nand_write_word - write one word to the chip + * @mtd: MTD device structure + * @word: data word to write + * + * Write function for 16bit buswith without + * endianess conversion + */ +static void pnx8550_nand_write_word(struct mtd_info *mtd, u16 word) +{ + struct nand_chip *this = mtd->priv; + int addr = NAND_ADDR(last_col_addr, last_page_addr); + writew(word, pNandAddr + addr); +} + +/** + * pnx8550_nand_write_buf - write buffer to chip + * @mtd: MTD device structure + * @buf: data buffer + * @len: number of bytes to write + */ +static void pnx8550_nand_write_buf(struct mtd_info *mtd, const u_char * buf, + int len) +{ + struct nand_chip *this = mtd->priv; + int addr = NAND_ADDR(last_col_addr, last_page_addr); + int pageLen; + int oobLen = 0; + u_char *transBuf = (u_char *) buf; + + /* some sanity checking, word access only please */ + if (len & 1) + pr_debug("%s: non-word aligned length requested!\n", + __FUNCTION__); + + memcpy(transferBuffer, buf, len); + transBuf = transferBuffer; + + /* + * Work out whether we are going to write to the OOB area + * after a standard page write. + * This is not the case when the command function is called + * with a column address > page size. Then we write as though + * it is to the page rather than the OOB as the command function + * has already selected the OOB area. + */ + if ((last_col_addr + len) > mtd->oobblock) + oobLen = (last_col_addr + len) - mtd->oobblock; + pageLen = len - oobLen; + + /* Clear the done flag */ + PNX8550_GPXIO_CTRL |= PNX8550_GPXIO_CLR_DONE; + if (pageLen > 0) + NAND_TRANSFER_TO(addr, transBuf, pageLen); + + if (oobLen > 0) { + pnx8550_nand_wait_for_dev_ready(); + + pnx8550_nand_register_setup(1, 0, 0, 1, 0, NAND_CMD_READOOB, 0); + /* Work out where in the OOB we are going to start to write */ + addr = NAND_ADDR(last_col_addr - mtd->oobblock, last_page_addr); + NAND_ADDR_SEND(addr); + pnx8550_nand_register_setup(2, 3, 1, 1, 0, NAND_CMD_SEQIN, + NAND_CMD_PAGEPROG); + + /* Clear the done flag */ + PNX8550_GPXIO_CTRL |= PNX8550_GPXIO_CLR_DONE; + NAND_TRANSFER_TO(addr, transBuf + pageLen, oobLen); + } + + /* + * Increment the address so on the next write we write in the + * correct place. + */ + last_col_addr += len; + if (last_col_addr >= mtd->oobblock + mtd->oobsize) { + last_col_addr -= mtd->oobblock + mtd->oobsize; + last_page_addr++; + } +} + +/** + * pnx8550_nand_read_buf - read chip data into buffer + * @mtd: MTD device structure + * @buf: buffer to store date + * @len: number of bytes to read + */ +static void pnx8550_nand_read_buf(struct mtd_info *mtd, u_char * buf, int len) +{ + struct nand_chip *this = mtd->priv; + int addr = NAND_ADDR(last_col_addr, last_page_addr); + int pageLen; + int oobLen = 0; + u_char *transBuf = buf; + + /* some sanity checking, word access only please */ + if (len & 1) + pr_debug("%s: non-word aligned length\n", __FUNCTION__); + + transBuf = transferBuffer; + + /* + * Work out whether we are going to read the OOB area + * after a standard page read. + * This is not the case when the command function is called + * with a column address > page size. Then we read as though + * it is from the page rather than the OOB as the command + * function has already selected the OOB area. + */ + if ((last_col_addr + len) > mtd->oobblock) + oobLen = (last_col_addr + len) - mtd->oobblock; + + pageLen = len - oobLen; + + if (pageLen) + NAND_TRANSFER_FROM(addr, transBuf, pageLen); + + if (oobLen > 0) { + pnx8550_nand_register_setup(1, 3, 1, 1, 0, NAND_CMD_READOOB, 0); + addr = NAND_ADDR(last_col_addr - mtd->oobblock, last_page_addr); + NAND_TRANSFER_FROM(addr, transBuf + pageLen, oobLen); + } + + if (transBuf != buf) + memcpy(buf, transBuf, len); + + /* + * Increment the address so on the next read we read from the + * correct place. + */ + last_col_addr += len; + if (last_col_addr > mtd->oobblock + mtd->oobsize) { + last_col_addr -= mtd->oobblock + mtd->oobsize; + last_page_addr++; + } + return; +} + +/** + * pnx8550_nand_verify_buf - Verify chip data against buffer + * @mtd: MTD device structure + * @buf: buffer containing the data to compare + * @len: number of bytes to compare + * + */ +static int pnx8550_nand_verify_buf(struct mtd_info *mtd, const u_char * buf, + int len) +{ + int result = 0; + + /* some sanity checking, word access only please */ + if (len & 1) + pr_debug("%s: non-word aligned length\n", __FUNCTION__); + + pnx8550_nand_read_buf(mtd, transferBuffer, len); + if (memcmp(buf, transferBuffer, len)) + result = -EFAULT; + + return result; + +} + +/** + * pnx8550_nand_command - Send command to NAND device + * @mtd: MTD device structure + * @command: the command to be sent + * @column: the column address for this command, -1 if none + * @page_addr: the page address for this command, -1 if none + * + * Send command to NAND device. + */ +static void pnx8550_nand_command(struct mtd_info *mtd, unsigned command, + int column, int page_addr) +{ + register struct nand_chip *this = mtd->priv; + u_char addr_no = 0; + u_char spare = 0; + int addr; + /* + If we are starting a write work out whether it is to the + OOB or the main page and position the pointer correctly. + */ + if (command == NAND_CMD_SEQIN) { + int readcmd; + int col = column; + if (column >= mtd->oobblock) { + /* OOB area */ + col -= mtd->oobblock; + readcmd = NAND_CMD_READOOB; + spare = 1; + } else { + readcmd = NAND_CMD_READ0; + } + pnx8550_nand_register_setup(1, 0, 0, 1, 0, readcmd, 0); + addr = NAND_ADDR(col, page_addr); + NAND_ADDR_SEND(addr); + } + + /* Check the number of address bytes */ + if ((column == -1) && (page_addr == -1)) { + addr_no = 0; + column = 0; + page_addr = 0; + } else if ((column == -1) && (page_addr != -1)) { + addr_no = 2; + column = 0; + } else if ((column != -1) && (page_addr == -1)) { + addr_no = 1; + page_addr = 0; + } else { + addr_no = 3; + } + + last_command = command; + last_col_addr = column; + last_page_addr = page_addr; + + switch (command) { + case NAND_CMD_PAGEPROG: + /* Nothing to do, we've already done it! */ + return; + + case NAND_CMD_SEQIN: + if (addr_no != 3) + printk(KERN_ERR + "NAND: Command %02x needs 3 byte address, " + "but addr_no = %d\n", command, addr_no); + pnx8550_nand_register_setup(2, 3, 1, 1, spare, NAND_CMD_SEQIN, + NAND_CMD_PAGEPROG); + return; + + case NAND_CMD_ERASE1: + if (addr_no != 2) + pr_debug("NAND: Command %02x needs 2 byte" "address, " + "but addr_no = %d\n", command, addr_no); + PNX8550_GPXIO_CTRL |= PNX8550_GPXIO_CLR_DONE; + pnx8550_nand_register_setup(2, 2, 0, 1, 0, NAND_CMD_ERASE1, + NAND_CMD_ERASE2); + addr = NAND_ADDR(column, page_addr); + NAND_ADDR_SEND(addr); + return; + + case NAND_CMD_ERASE2: + /* Nothing to do, we've already done it! */ + return; + + case NAND_CMD_STATUS: + if (addr_no != 0) + pr_debug("NAND: Command %02x needs 0 byte address, " + "but addr_no = %d\n", command, addr_no); + pnx8550_nand_register_setup(1, 0, 1, 0, 0, NAND_CMD_STATUS, 0); + return; + + case NAND_CMD_RESET: + if (addr_no != 0) + pr_debug("NAND: Command %02x needs 0 byte address, " + "but addr_no = %d\n", command, addr_no); + pnx8550_nand_register_setup(1, 0, 0, 0, 0, NAND_CMD_RESET, 0); + addr = NAND_ADDR(column, page_addr); + NAND_ADDR_SEND(addr); + return; + + case NAND_CMD_READ0: + if (addr_no != 3) + pr_debug("NAND: Command %02x needs 3 byte address, " + "but addr_no = %d\n", command, addr_no); + pnx8550_nand_register_setup(1, 3, 1, 1, 0, NAND_CMD_READ0, 0); + return; + + case NAND_CMD_READ1: + printk(KERN_ERR "Wrong command: %02x\n", command); + return; + + case NAND_CMD_READOOB: + if (addr_no != 3) + pr_debug("NAND: Command %02x needs 3 byte address, " + "but addr_no = %d\n", command, addr_no); + pnx8550_nand_register_setup(1, 3, 1, 1, 0, NAND_CMD_READOOB, 0); + return; + + case NAND_CMD_READID: + if (addr_no != 1) + pr_debug("NAND: Command %02x needs 1 byte address, " + "but addr_no = %d\n", command, addr_no); + pnx8550_nand_register_setup(1, 1, 1, 0, 0, NAND_CMD_READID, 0); + return; + } +} + +/** + * Return true if the device is ready, false otherwise + */ +static int pnx8550_nand_dev_ready(struct mtd_info *mtd) +{ + return ((PNX8550_XIO_CTRL & PNX8550_XIO_CTRL_XIO_ACK) != 0); +} + +/** + * hardware specific access to control-lines + */ +static void pnx8550_nand_hwcontrol(struct mtd_info *mtd, int cmd) +{ + /* Nothing to do here, its all done by the XIO block */ +} + +/** + * Main initialization routine + */ +int __init pnx8550_nand_init(void) +{ + struct nand_chip *this; + + /* Get pointer to private data */ + this = &pnx8550_nand; + + /* Work out address of Nand Flash */ + pNandAddr = (u8 *) (KSEG1 | (PNX8550_BASE18_ADDR & (~0x7))); + + pNandAddr = (u8 *) (((u32) pNandAddr) + + ((PNX8550_XIO_SEL0 & PNX8550_XIO_SEL0_OFFSET_MASK) + >> PNX8550_XIO_SEL0_OFFSET_SHIFT) * 8 * 1024 * + 1024); + + /* Link the private data with the MTD structure */ + pnx8550_mtd.priv = this; + this->chip_delay = 15; + this->options = NAND_BUSWIDTH_16; + this->cmdfunc = pnx8550_nand_command; + this->read_byte = pnx8550_nand_read_byte; + this->read_word = pnx8550_nand_read_word; + this->read_buf = pnx8550_nand_read_buf; + this->write_byte = pnx8550_nand_write_byte; + this->write_word = pnx8550_nand_write_word; + this->write_buf = pnx8550_nand_write_buf; + this->verify_buf = pnx8550_nand_verify_buf; + this->dev_ready = pnx8550_nand_dev_ready; + this->hwcontrol = pnx8550_nand_hwcontrol; + this->eccmode = NAND_ECC_SOFT; + this->badblock_pattern = &nand16bit_memorybased; + this->autooob = &nand16bit_oob_16; + + transferBuffer = + kmalloc(pnx8550_mtd.oobblock + pnx8550_mtd.oobsize, + GFP_DMA | GFP_KERNEL); + if (!transferBuffer) { + printk(KERN_ERR + "Unable to allocate NAND data buffer for PNX8550\n"); + return -ENOMEM; + } + + /* Scan to find existence of the device */ + if (nand_scan(&pnx8550_mtd, 1)) { + printk(KERN_ERR "No NAND devices\n"); + return -ENXIO; + } + + add_mtd_partitions(&pnx8550_mtd, partition_info, NUM_PARTITIONS); + + return 0; +} + +module_init(pnx8550_nand_init); + +#ifdef MODULE +static void __exit pnx8550_nand_cleanup(void) +{ + nand_release(&pnx8550_mtd); + kfree(transferBuffer); +} + +module_exit(pnx8550_nand_cleanup); +#endif + +MODULE_LICENSE("GPL"); +MODULE_AUTHOR("Adam Charrett"); +MODULE_DESCRIPTION("Driver for 16Bit NAND Flash on the XIO bus for PNX8550"); Index: linux-2.6.15_0/drivers/mtd/nand/Makefile =================================================================== --- linux-2.6.15_0.orig/drivers/mtd/nand/Makefile +++ linux-2.6.15_0/drivers/mtd/nand/Makefile @@ -18,5 +18,6 @@ obj-$(CONFIG_MTD_NAND_H1900) += h1910.o obj-$(CONFIG_MTD_NAND_RTC_FROM4) += rtc_from4.o obj-$(CONFIG_MTD_NAND_SHARPSL) += sharpsl.o obj-$(CONFIG_MTD_NAND_NANDSIM) += nandsim.o +obj-$(CONFIG_MTD_NAND_PNX8550) += pnx8550.o nand-objs = nand_base.o nand_bbt.o Index: linux-2.6.15_0/include/asm-mips/mach-pnx8550/nand.h =================================================================== --- linux-2.6.15_0.orig/include/asm-mips/mach-pnx8550/nand.h +++ linux-2.6.15_0/include/asm-mips/mach-pnx8550/nand.h @@ -4,10 +4,14 @@ #define PNX8550_NAND_BASE_ADDR 0x10000000 #define PNX8550_PCIXIO_BASE 0xBBE40000 +#define PNX8550_BASE10_ADDR *(volatile unsigned long *)(PNX8550_PCIXIO_BASE + 0x050) +#define PNX8550_BASE14_ADDR *(volatile unsigned long *)(PNX8550_PCIXIO_BASE + 0x054) +#define PNX8550_BASE18_ADDR *(volatile unsigned long *)(PNX8550_PCIXIO_BASE + 0x058) #define PNX8550_DMA_EXT_ADDR *(volatile unsigned long *)(PNX8550_PCIXIO_BASE + 0x800) #define PNX8550_DMA_INT_ADDR *(volatile unsigned long *)(PNX8550_PCIXIO_BASE + 0x804) #define PNX8550_DMA_TRANS_SIZE *(volatile unsigned long *)(PNX8550_PCIXIO_BASE + 0x808) #define PNX8550_DMA_CTRL *(volatile unsigned long *)(PNX8550_PCIXIO_BASE + 0x80c) +#define PNX8550_XIO_CTRL *(volatile unsigned long *)(PNX8550_PCIXIO_BASE + 0x810) #define PNX8550_XIO_SEL0 *(volatile unsigned long *)(PNX8550_PCIXIO_BASE + 0x814) #define PNX8550_GPXIO_ADDR *(volatile unsigned long *)(PNX8550_PCIXIO_BASE + 0x820) #define PNX8550_GPXIO_WR *(volatile unsigned long *)(PNX8550_PCIXIO_BASE + 0x824) @@ -21,6 +25,8 @@ #define PNX8550_DMA_INT_ENABLE *(volatile unsigned long *)(PNX8550_PCIXIO_BASE + 0xfd4) #define PNX8550_DMA_INT_CLEAR *(volatile unsigned long *)(PNX8550_PCIXIO_BASE + 0xfd8) +#define PNX8550_XIO_CTRL_XIO_ACK 0x00000002 + #define PNX8550_XIO_SEL0_EN_16BIT 0x00800000 #define PNX8550_XIO_SEL0_USE_ACK 0x00400000 #define PNX8550_XIO_SEL0_REN_HIGH 0x00100000 @@ -39,6 +45,9 @@ #define PNX8550_XIO_SEL0_SIZE_64MB 0x00000006 #define PNX8550_XIO_SEL0_ENAB 0x00000001 +#define PNX8550_XIO_SEL0_OFFSET_SHIFT 5 +#define PNX8550_XIO_SEL0_OFFSET_MASK (0xf << PNX8550_XIO_SEL0_OFFSET_SHIFT) + #define PNX8550_SEL0_DEFAULT ((PNX8550_XIO_SEL0_EN_16BIT) | \ (PNX8550_XIO_SEL0_REN_HIGH*0)| \ (PNX8550_XIO_SEL0_REN_LOW*2) | \ @@ -59,11 +68,15 @@ #define PNX8550_XIO_FLASH_64MB 0x00200000 #define PNX8550_XIO_FLASH_INC_DATA 0x00100000 -#define PNX8550_XIO_FLASH_CMD_PH 0x000C0000 +#define PNX8550_XIO_FLASH_CMD_PH_SHIFT 18 +#define PNX8550_XIO_FLASH_CMD_PH_MASK (3 << PNX8550_XIO_FLASH_CMD_PH_SHIFT) +#define PNX8550_XIO_FLASH_CMD_PH(_x) (((_x) << PNX8550_XIO_FLASH_CMD_PH_SHIFT) & PNX8550_XIO_FLASH_CMD_PH_MASK) +#define PNX8550_XIO_FLASH_ADR_PH_SHIFT 16 +#define PNX8550_XIO_FLASH_ADR_PH_MASK (3 << PNX8550_XIO_FLASH_ADR_PH_SHIFT) +#define PNX8550_XIO_FLASH_ADR_PH(_x) (((_x) << PNX8550_XIO_FLASH_ADR_PH_SHIFT) & PNX8550_XIO_FLASH_ADR_PH_MASK) #define PNX8550_XIO_FLASH_CMD_PH2 0x00080000 #define PNX8550_XIO_FLASH_CMD_PH1 0x00040000 #define PNX8550_XIO_FLASH_CMD_PH0 0x00000000 -#define PNX8550_XIO_FLASH_ADR_PH 0x00030000 #define PNX8550_XIO_FLASH_ADR_PH3 0x00030000 #define PNX8550_XIO_FLASH_ADR_PH2 0x00020000 #define PNX8550_XIO_FLASH_ADR_PH1 0x00010000 @@ -118,4 +131,9 @@ #define PNX8550_DMA_INT_CLR_M_ABORT (1<<2) #define PNX8550_DMA_INT_CLR_T_ABORT (1<<1) +#define PNX8550_DMA_INT_ACK 0x00004000 +#define PNX8550_DMA_INT_COMPL 0x00001000 +#define PNX8550_DMA_INT_NONSUP 0x00000200 +#define PNX8550_DMA_INT_ABORT 0x00000004 + #endif --------------050702040603060002030909-- From vbarinov@ru.mvista.com Tue Dec 20 18:05:40 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 20 Dec 2005 18:06:04 +0000 (GMT) Received: from rtsoft3.corbina.net ([85.21.88.6]:3997 "EHLO buildserver.ru.mvista.com") by ftp.linux-mips.org with ESMTP id S8133569AbVLTSFb (ORCPT ); Tue, 20 Dec 2005 18:05:31 +0000 Received: from [192.168.12.17] ([10.149.0.1]) by buildserver.ru.mvista.com (8.11.6/8.11.6) with ESMTP id jBKI6Yt19901 for ; Tue, 20 Dec 2005 22:06:34 +0400 Message-ID: <43A8482A.1010004@ru.mvista.com> Date: Tue, 20 Dec 2005 21:06:34 +0300 From: "Vladimir A. Barinov" User-Agent: Mozilla Thunderbird 1.0.2-6 (X11/20050513) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "'linux-mips@linux-mips.org'" Subject: [Fwd: Re: [PATCH] PNX8550 NAND flash driver] Content-Type: multipart/mixed; boundary="------------050100090406070005010902" 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: 9699 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: vbarinov@ru.mvista.com Precedence: bulk X-list: linux-mips This is a multi-part message in MIME format. --------------050100090406070005010902 Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit --------------050100090406070005010902 Content-Type: message/rfc822; name="Re: [PATCH] PNX8550 NAND flash driver" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="Re: [PATCH] PNX8550 NAND flash driver" Return-Path: Received: from buildserver.ru.mvista.com ([unix socket]) (authenticated user=vbarinov bits=0) by buildserver.ru.mvista.com (Cyrus v2.1.11-Invoca-RPM-2.1.11-6) with LMTP; Tue, 20 Dec 2005 18:31:53 +0400 X-Sieve: CMU Sieve 2.2 Return-Path: Received: from av.mvista.com ([10.0.12.39]) by buildserver.ru.mvista.com (8.11.6/8.11.6) with ESMTP id jBKEVot11936 for ; Tue, 20 Dec 2005 18:31:50 +0400 Received: from apocalypse.mvista.com (av [127.0.0.1]) by av.mvista.com (8.9.3/8.9.3) with ESMTP id GAA07690 for ; Tue, 20 Dec 2005 06:30:13 -0800 Received: (qmail 29033 invoked from network); 20 Dec 2005 14:30:12 -0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on thoth.mvista.com X-Spam-Level: X-Spam-Status: No, score=-101.5 required=5.0 tests=AWL,BAYES_00, UNPARSEABLE_RELAY,USER_IN_WHITELIST autolearn=unavailable version=3.1.0 Received: from mail.linux-mips.org (HELO ftp.linux-mips.org) (62.254.210.162) by apocalypse.mvista.com with SMTP; 20 Dec 2005 14:30:08 -0000 Received: from localhost.localdomain ([127.0.0.1]:15520 "EHLO ftp.linux-mips.org") by ftp.linux-mips.org with ESMTP id S8133373AbVLTO2J (ORCPT + 2 others); Tue, 20 Dec 2005 14:28:09 +0000 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 20 Dec 2005 14:27:42 +0000 (GMT) Received: from rtsoft3.corbina.net ([85.21.88.6]:29851 "EHLO buildserver.ru.mvista.com") by ftp.linux-mips.org with ESMTP id S8126484AbVLTO1S (ORCPT ); Tue, 20 Dec 2005 14:27:18 +0000 Received: from [192.168.12.17] ([10.149.0.1]) by buildserver.ru.mvista.com (8.11.6/8.11.6) with ESMTP id jBKERxt11783; Tue, 20 Dec 2005 18:27:59 +0400 Message-ID: <43A814EF.6060509@ru.mvista.com> Date: Tue, 20 Dec 2005 17:27:59 +0300 From: "Vladimir A. Barinov" User-Agent: Mozilla Thunderbird 1.0.2-6 (X11/20050513) X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-mtd@lists.infradead.org, linux-mips@linux-mips.org Subject: Re: [PATCH] PNX8550 NAND flash driver References: <43A2F819.1040106@ru.mvista.com> In-Reply-To: <43A2F819.1040106@ru.mvista.com> Content-Type: multipart/mixed; boundary="------------050702040603060002030909" X-archive-position: 9698 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: vbarinov@ru.mvista.com Precedence: bulk X-list: linux-mips This is a multi-part message in MIME format. --------------050702040603060002030909 Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit Hi, Vladimir A. Barinov wrote: > Hi All, > > Attached patch is NAND flash driver for PNX8550 based platforms. > Any comments and suggestions are highly appreciated. Sorry, but this patch is not complete. It's needed to add include/../nand.h file. Attachment is the recasted variant (removing "volatile u16 *" usage, "prink" usage changes and some cosmetic changes) with nand.h part. Vladimir --------------050702040603060002030909 Content-Type: text/plain; name="nand.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="nand.patch" Signed-off-by: vbarinov@ru.mvista.com drivers/mtd/nand/Kconfig | 6 drivers/mtd/nand/Makefile | 1 drivers/mtd/nand/pnx8550.c | 694 +++++++++++++++++++++++++++++++++++ include/asm-mips/mach-pnx8550/nand.h | 22 + 4 files changed, 721 insertions(+), 2 deletions(-) Index: linux-2.6.15_0/drivers/mtd/nand/Kconfig =================================================================== --- linux-2.6.15_0.orig/drivers/mtd/nand/Kconfig +++ linux-2.6.15_0/drivers/mtd/nand/Kconfig @@ -90,6 +90,12 @@ config MTD_NAND_S3C2410 No board specfic support is done by this driver, each board must advertise a platform_device for the driver to attach. +config MTD_NAND_PNX8550 + tristate "NAND Flash support for PNX8550" + depends on PNX8550 && MTD_NAND + help + This enables the NAND flash controller on the PNX8550. + config MTD_NAND_S3C2410_DEBUG bool "S3C2410 NAND driver debug" depends on MTD_NAND_S3C2410 Index: linux-2.6.15_0/drivers/mtd/nand/pnx8550.c =================================================================== --- /dev/null +++ linux-2.6.15_0/drivers/mtd/nand/pnx8550.c @@ -0,0 +1,694 @@ +/* + * Copyright (C) 2005 Koninklijke Philips Electronics N.V. + * All Rights Reserved. + * + * 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., 675 Mass Ave, Cambridge, MA 02139, USA. + * + * Overview: + * This is a device driver for the NAND flash device found on the + * PNX8550 board which utilizes the Samsung K9F5616U0C part. This is + * a 32MByte (16M x 16 bits) NAND flash device. + */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#define UBTM_NAME "microBTM" +#define UBTM_BLOCK_START ( 0x00000000) +#define UBTM_BLOCK_END ( 0x00004000) /* 16K size, first block */ +#define UBTM_SIZE ( UBTM_BLOCK_END - UBTM_BLOCK_START) + +#define BOOTLOADER_NAME "bootloader" +#define BOOTLOADER_BLOCK_START ( UBTM_BLOCK_END) +#define BOOTLOADER_BLOCK_END ( 0x00040000) /* 256K - 16K = 240K */ +#define BOOTLOADER_SIZE ( BOOTLOADER_BLOCK_END - BOOTLOADER_BLOCK_START) + +#define ROMFS_SYS_NAME "ROMFS-Tools" +#define ROMFS_SYS_BLOCK_START ( BOOTLOADER_BLOCK_END) +#define ROMFS_SYS_BLOCK_END ( 0x00600000) /* 6M - 256K = 5.75M */ +#define ROMFS_SYS_SIZE ( ROMFS_SYS_BLOCK_END - ROMFS_SYS_BLOCK_START) + +#define ROMFS_APP_NAME "ROMFS-User" +#define ROMFS_APP_BLOCK_START ( ROMFS_SYS_BLOCK_END) +#define ROMFS_APP_BLOCK_END ( 0x01000000) /* 16M - 6M = 10M */ +#define ROMFS_APP_SIZE ( ROMFS_APP_BLOCK_END - ROMFS_APP_BLOCK_START) + +#define USER_NAME "User" +#define USER_BLOCK_START ( ROMFS_APP_BLOCK_END) +#define USER_BLOCK_END ( 0x02000000) /* 32M - 16M = 16M */ +#define USER_SIZE ( USER_BLOCK_END - USER_BLOCK_START) + +#define NAND_ADDR(_col, _page) ((_col) & (mtd->oobblock - 1)) + ((_page) << this->page_shift) + +#define NAND_ADDR_SEND(_addr) writew(0, pNandAddr + _addr) + +#define NAND_TRANSFER_TO(_addr, _buffer, _bytes) pnx8550_nand_transfer(_buffer, pNandAddr + _addr, _bytes, 1) +#define NAND_TRANSFER_FROM(_addr, _buffer, _bytes) pnx8550_nand_transfer(pNandAddr + _addr, _buffer, _bytes, 0) + +/* + * Define partitions for flash device + */ +#define NUM_PARTITIONS 5 +const static struct mtd_partition partition_info[NUM_PARTITIONS] = { + { + .name = UBTM_NAME, + .offset = UBTM_BLOCK_START, + .size = UBTM_SIZE}, + { + .name = BOOTLOADER_NAME, + .offset = BOOTLOADER_BLOCK_START, + .size = BOOTLOADER_SIZE}, + { + .name = ROMFS_SYS_NAME, + .offset = ROMFS_SYS_BLOCK_START, + .size = ROMFS_SYS_SIZE}, + { + .name = ROMFS_APP_NAME, + .offset = ROMFS_APP_BLOCK_START, + .size = ROMFS_APP_SIZE}, + { + .name = USER_NAME, + .offset = USER_BLOCK_START, + .size = USER_SIZE} +}; + +/* Bad block descriptor for 16Bit nand flash */ +static uint8_t scan_ff_pattern[] = { 0xff, 0xff }; +static struct nand_bbt_descr nand16bit_memorybased = { + .options = 0, + .offs = 0, + .len = 2, + .pattern = scan_ff_pattern +}; + +/* OOB Placement information that lines up with the boot loader code */ +static struct nand_oobinfo nand16bit_oob_16 = { + .useecc = MTD_NANDECC_AUTOPLACE, + .eccbytes = 6, + .eccpos = {2, 3, 4, 5, 6, 7}, + .oobfree = {{8, 8}} +}; + +/* Pointer into XIO for access to the 16Bit NAND flash device */ +static u8 *pNandAddr; + +/* Last command sent to the pnx8550_nand_command function */ +static int last_command = -1; +/* + * Next column address to read/write, set by pnx8550_nand_command + * updated by the read/write functions + */ +static int last_col_addr = -1; +/* + * Next page address to read/write, set by pnx8550_nand_command + * updated by the read/write functions + */ +static int last_page_addr = -1; + +/* 32bit Aligned/DMA buffer */ +static u_char *transferBuffer; + +static struct mtd_info pnx8550_mtd; +static struct nand_chip pnx8550_nand; + +/** + * Setup the registers in PCIXIO + */ +static void pnx8550_nand_register_setup(u_char cmd_no, + u_char addr_no, + u_char include_data, + u_char monitor_ACK, + u_char enable64M, int cmd_a, int cmd_b) +{ + unsigned int reg_nand = 0; + reg_nand |= enable64M ? PNX8550_XIO_FLASH_64MB : 0; + reg_nand |= include_data ? PNX8550_XIO_FLASH_INC_DATA : 0; + reg_nand |= PNX8550_XIO_FLASH_CMD_PH(cmd_no); + reg_nand |= PNX8550_XIO_FLASH_ADR_PH(addr_no); + reg_nand |= PNX8550_XIO_FLASH_CMD_A(cmd_a); + reg_nand |= PNX8550_XIO_FLASH_CMD_B(cmd_b); + PNX8550_XIO_FLASH_CTRL = reg_nand; + barrier(); +} + +/** + * Wait for the device to be ready for the next command + */ +static inline void pnx8550_nand_wait_for_dev_ready(void) +{ + while ((PNX8550_XIO_CTRL & PNX8550_XIO_CTRL_XIO_ACK) == 0) ; +} + +/** + * Transfer data to/from the NAND chip using DMA + * + * @from: Address to transfer data from + * @to: Address to transfer the data to + * @bytes: Number of bytes to transfer + * @toxio: Whether the transfer is going to XIO or not. + */ +static void pnx8550_nand_transferDMA(void *from, void *to, int bytes, int toxio) +{ + int cmd = 0; + u32 internal; + u32 external; + + if (toxio) { + cmd = PNX8550_DMA_CTRL_PCI_CMD_WRITE; + dma_cache_wback((unsigned long)from, bytes); + internal = (u32) virt_to_phys(from); + external = (u32) to - KSEG1; + } else { + cmd = PNX8550_DMA_CTRL_PCI_CMD_READ; + internal = (u32) virt_to_phys(to); + external = (u32) from - KSEG1; + } + + local_irq_disable(); + PNX8550_DMA_TRANS_SIZE = bytes >> 2; /* Length in words */ + PNX8550_DMA_EXT_ADDR = external; + PNX8550_DMA_INT_ADDR = internal; + PNX8550_DMA_INT_CLEAR = 0xffff; + PNX8550_DMA_CTRL = PNX8550_DMA_CTRL_BURST_512 | + PNX8550_DMA_CTRL_SND2XIO | PNX8550_DMA_CTRL_INIT_DMA | cmd; + + while ((PNX8550_DMA_INT_STATUS & PNX8550_DMA_INT_COMPL) == 0) ; + + if (!toxio) + dma_cache_inv((unsigned long)to, bytes); + + local_irq_enable(); +} + +/** + * Transfer data to/from the NAND chip. + * This function decides whether to use DMA or not depending on + * the amount of data to transfer and the alignment of the buffers. + * + * @from: Address to transfer data from + * @to: Address to transfer the data to + * @bytes: Number of bytes to transfer + * @toxio: Whether the transfer is going to XIO or not. + */ +static void pnx8550_nand_transfer(void *from, void *to, int bytes, int toxio) +{ + u16 *from16 = (u16 *) from; + u16 *to16 = (u16 *) to; + + int i; + + if ((u32) from & 3) + printk(KERN_INFO "%s: from buffer not 32bit aligned, will not " + "use fastest transfer mechanism\n", __FUNCTION__); + if ((u32) to & 3) + printk(KERN_INFO "%s: to buffer not 32bit aligned, will not " + "use fastest transfer mechanism\n", __FUNCTION__); + + if (((bytes & 3) || (bytes < 16)) || ((u32) to & 3) || ((u32) from & 3)) { + if (((bytes & 1) == 0) && + (((u32) to & 1) == 0) && (((u32) from & 1) == 0)) { + int words = bytes / 2; + + local_irq_disable(); + for (i = 0; i < words; i++) + to16[i] = from16[i]; + local_irq_enable(); + } + else + printk(KERN_ERR "%s: Transfer failed, " + "byte-aligned transfers no allowed!\n", + __FUNCTION__); + } else { + pnx8550_nand_transferDMA(from, to, bytes, toxio); + } +} + +/** + * pnx8550_nand_read_byte - read one byte endianess aware from the chip + * @mtd: MTD device structure + */ +static u_char pnx8550_nand_read_byte(struct mtd_info *mtd) +{ + struct nand_chip *this = mtd->priv; + u16 data = 0; + int addr = NAND_ADDR(last_col_addr, last_page_addr); + /* + * Read ID is a special case as we have to read BOTH bytes at the same + * time otherwise it doesn't work, once we have both bytes we work out + * which one we want. + */ + if (last_command == NAND_CMD_READID) { + u32 data32; + data32 = cpu_to_le32(readl(pNandAddr + 0)); + if (last_col_addr) + data = (u16) (data32 >> 16); + else + data = (u16) data32; + } else { + data = readw(pNandAddr + addr); + if ((addr & 0x1) == 1) + data = (data & 0xff00) >> 16; + } + /* + * Status is a special case, we don't need to increment the address + * because the address isn't used by the chip + */ + if (last_command != NAND_CMD_STATUS) + last_col_addr++; + + return data & 0xff; +} + +/** + * pnx8550_nand_read_word - read one word from the chip + * @mtd: MTD device structure + * + * Read function for 16bit buswith without + * endianess conversion + */ +static u16 pnx8550_nand_read_word(struct mtd_info *mtd) +{ + struct nand_chip *this = mtd->priv; + int addr = NAND_ADDR(last_col_addr, last_page_addr); + u16 data = readw(pNandAddr + addr); + return data; +} + +/** + * pnx8550_nand_write_byte - write one byte endianess aware to the chip + * @mtd: MTD device structure + * @byte: pointer to data byte to write + * + * Write function for 16bit buswith with + * endianess conversion + */ +static void pnx8550_nand_write_byte(struct mtd_info *mtd, u_char byte) +{ + struct nand_chip *this = mtd->priv; + int addr = NAND_ADDR(last_col_addr, last_page_addr); + writew(le16_to_cpu((u16) byte), pNandAddr + addr); +} + +/** + * pnx8550_nand_write_word - write one word to the chip + * @mtd: MTD device structure + * @word: data word to write + * + * Write function for 16bit buswith without + * endianess conversion + */ +static void pnx8550_nand_write_word(struct mtd_info *mtd, u16 word) +{ + struct nand_chip *this = mtd->priv; + int addr = NAND_ADDR(last_col_addr, last_page_addr); + writew(word, pNandAddr + addr); +} + +/** + * pnx8550_nand_write_buf - write buffer to chip + * @mtd: MTD device structure + * @buf: data buffer + * @len: number of bytes to write + */ +static void pnx8550_nand_write_buf(struct mtd_info *mtd, const u_char * buf, + int len) +{ + struct nand_chip *this = mtd->priv; + int addr = NAND_ADDR(last_col_addr, last_page_addr); + int pageLen; + int oobLen = 0; + u_char *transBuf = (u_char *) buf; + + /* some sanity checking, word access only please */ + if (len & 1) + pr_debug("%s: non-word aligned length requested!\n", + __FUNCTION__); + + memcpy(transferBuffer, buf, len); + transBuf = transferBuffer; + + /* + * Work out whether we are going to write to the OOB area + * after a standard page write. + * This is not the case when the command function is called + * with a column address > page size. Then we write as though + * it is to the page rather than the OOB as the command function + * has already selected the OOB area. + */ + if ((last_col_addr + len) > mtd->oobblock) + oobLen = (last_col_addr + len) - mtd->oobblock; + pageLen = len - oobLen; + + /* Clear the done flag */ + PNX8550_GPXIO_CTRL |= PNX8550_GPXIO_CLR_DONE; + if (pageLen > 0) + NAND_TRANSFER_TO(addr, transBuf, pageLen); + + if (oobLen > 0) { + pnx8550_nand_wait_for_dev_ready(); + + pnx8550_nand_register_setup(1, 0, 0, 1, 0, NAND_CMD_READOOB, 0); + /* Work out where in the OOB we are going to start to write */ + addr = NAND_ADDR(last_col_addr - mtd->oobblock, last_page_addr); + NAND_ADDR_SEND(addr); + pnx8550_nand_register_setup(2, 3, 1, 1, 0, NAND_CMD_SEQIN, + NAND_CMD_PAGEPROG); + + /* Clear the done flag */ + PNX8550_GPXIO_CTRL |= PNX8550_GPXIO_CLR_DONE; + NAND_TRANSFER_TO(addr, transBuf + pageLen, oobLen); + } + + /* + * Increment the address so on the next write we write in the + * correct place. + */ + last_col_addr += len; + if (last_col_addr >= mtd->oobblock + mtd->oobsize) { + last_col_addr -= mtd->oobblock + mtd->oobsize; + last_page_addr++; + } +} + +/** + * pnx8550_nand_read_buf - read chip data into buffer + * @mtd: MTD device structure + * @buf: buffer to store date + * @len: number of bytes to read + */ +static void pnx8550_nand_read_buf(struct mtd_info *mtd, u_char * buf, int len) +{ + struct nand_chip *this = mtd->priv; + int addr = NAND_ADDR(last_col_addr, last_page_addr); + int pageLen; + int oobLen = 0; + u_char *transBuf = buf; + + /* some sanity checking, word access only please */ + if (len & 1) + pr_debug("%s: non-word aligned length\n", __FUNCTION__); + + transBuf = transferBuffer; + + /* + * Work out whether we are going to read the OOB area + * after a standard page read. + * This is not the case when the command function is called + * with a column address > page size. Then we read as though + * it is from the page rather than the OOB as the command + * function has already selected the OOB area. + */ + if ((last_col_addr + len) > mtd->oobblock) + oobLen = (last_col_addr + len) - mtd->oobblock; + + pageLen = len - oobLen; + + if (pageLen) + NAND_TRANSFER_FROM(addr, transBuf, pageLen); + + if (oobLen > 0) { + pnx8550_nand_register_setup(1, 3, 1, 1, 0, NAND_CMD_READOOB, 0); + addr = NAND_ADDR(last_col_addr - mtd->oobblock, last_page_addr); + NAND_TRANSFER_FROM(addr, transBuf + pageLen, oobLen); + } + + if (transBuf != buf) + memcpy(buf, transBuf, len); + + /* + * Increment the address so on the next read we read from the + * correct place. + */ + last_col_addr += len; + if (last_col_addr > mtd->oobblock + mtd->oobsize) { + last_col_addr -= mtd->oobblock + mtd->oobsize; + last_page_addr++; + } + return; +} + +/** + * pnx8550_nand_verify_buf - Verify chip data against buffer + * @mtd: MTD device structure + * @buf: buffer containing the data to compare + * @len: number of bytes to compare + * + */ +static int pnx8550_nand_verify_buf(struct mtd_info *mtd, const u_char * buf, + int len) +{ + int result = 0; + + /* some sanity checking, word access only please */ + if (len & 1) + pr_debug("%s: non-word aligned length\n", __FUNCTION__); + + pnx8550_nand_read_buf(mtd, transferBuffer, len); + if (memcmp(buf, transferBuffer, len)) + result = -EFAULT; + + return result; + +} + +/** + * pnx8550_nand_command - Send command to NAND device + * @mtd: MTD device structure + * @command: the command to be sent + * @column: the column address for this command, -1 if none + * @page_addr: the page address for this command, -1 if none + * + * Send command to NAND device. + */ +static void pnx8550_nand_command(struct mtd_info *mtd, unsigned command, + int column, int page_addr) +{ + register struct nand_chip *this = mtd->priv; + u_char addr_no = 0; + u_char spare = 0; + int addr; + /* + If we are starting a write work out whether it is to the + OOB or the main page and position the pointer correctly. + */ + if (command == NAND_CMD_SEQIN) { + int readcmd; + int col = column; + if (column >= mtd->oobblock) { + /* OOB area */ + col -= mtd->oobblock; + readcmd = NAND_CMD_READOOB; + spare = 1; + } else { + readcmd = NAND_CMD_READ0; + } + pnx8550_nand_register_setup(1, 0, 0, 1, 0, readcmd, 0); + addr = NAND_ADDR(col, page_addr); + NAND_ADDR_SEND(addr); + } + + /* Check the number of address bytes */ + if ((column == -1) && (page_addr == -1)) { + addr_no = 0; + column = 0; + page_addr = 0; + } else if ((column == -1) && (page_addr != -1)) { + addr_no = 2; + column = 0; + } else if ((column != -1) && (page_addr == -1)) { + addr_no = 1; + page_addr = 0; + } else { + addr_no = 3; + } + + last_command = command; + last_col_addr = column; + last_page_addr = page_addr; + + switch (command) { + case NAND_CMD_PAGEPROG: + /* Nothing to do, we've already done it! */ + return; + + case NAND_CMD_SEQIN: + if (addr_no != 3) + printk(KERN_ERR + "NAND: Command %02x needs 3 byte address, " + "but addr_no = %d\n", command, addr_no); + pnx8550_nand_register_setup(2, 3, 1, 1, spare, NAND_CMD_SEQIN, + NAND_CMD_PAGEPROG); + return; + + case NAND_CMD_ERASE1: + if (addr_no != 2) + pr_debug("NAND: Command %02x needs 2 byte" "address, " + "but addr_no = %d\n", command, addr_no); + PNX8550_GPXIO_CTRL |= PNX8550_GPXIO_CLR_DONE; + pnx8550_nand_register_setup(2, 2, 0, 1, 0, NAND_CMD_ERASE1, + NAND_CMD_ERASE2); + addr = NAND_ADDR(column, page_addr); + NAND_ADDR_SEND(addr); + return; + + case NAND_CMD_ERASE2: + /* Nothing to do, we've already done it! */ + return; + + case NAND_CMD_STATUS: + if (addr_no != 0) + pr_debug("NAND: Command %02x needs 0 byte address, " + "but addr_no = %d\n", command, addr_no); + pnx8550_nand_register_setup(1, 0, 1, 0, 0, NAND_CMD_STATUS, 0); + return; + + case NAND_CMD_RESET: + if (addr_no != 0) + pr_debug("NAND: Command %02x needs 0 byte address, " + "but addr_no = %d\n", command, addr_no); + pnx8550_nand_register_setup(1, 0, 0, 0, 0, NAND_CMD_RESET, 0); + addr = NAND_ADDR(column, page_addr); + NAND_ADDR_SEND(addr); + return; + + case NAND_CMD_READ0: + if (addr_no != 3) + pr_debug("NAND: Command %02x needs 3 byte address, " + "but addr_no = %d\n", command, addr_no); + pnx8550_nand_register_setup(1, 3, 1, 1, 0, NAND_CMD_READ0, 0); + return; + + case NAND_CMD_READ1: + printk(KERN_ERR "Wrong command: %02x\n", command); + return; + + case NAND_CMD_READOOB: + if (addr_no != 3) + pr_debug("NAND: Command %02x needs 3 byte address, " + "but addr_no = %d\n", command, addr_no); + pnx8550_nand_register_setup(1, 3, 1, 1, 0, NAND_CMD_READOOB, 0); + return; + + case NAND_CMD_READID: + if (addr_no != 1) + pr_debug("NAND: Command %02x needs 1 byte address, " + "but addr_no = %d\n", command, addr_no); + pnx8550_nand_register_setup(1, 1, 1, 0, 0, NAND_CMD_READID, 0); + return; + } +} + +/** + * Return true if the device is ready, false otherwise + */ +static int pnx8550_nand_dev_ready(struct mtd_info *mtd) +{ + return ((PNX8550_XIO_CTRL & PNX8550_XIO_CTRL_XIO_ACK) != 0); +} + +/** + * hardware specific access to control-lines + */ +static void pnx8550_nand_hwcontrol(struct mtd_info *mtd, int cmd) +{ + /* Nothing to do here, its all done by the XIO block */ +} + +/** + * Main initialization routine + */ +int __init pnx8550_nand_init(void) +{ + struct nand_chip *this; + + /* Get pointer to private data */ + this = &pnx8550_nand; + + /* Work out address of Nand Flash */ + pNandAddr = (u8 *) (KSEG1 | (PNX8550_BASE18_ADDR & (~0x7))); + + pNandAddr = (u8 *) (((u32) pNandAddr) + + ((PNX8550_XIO_SEL0 & PNX8550_XIO_SEL0_OFFSET_MASK) + >> PNX8550_XIO_SEL0_OFFSET_SHIFT) * 8 * 1024 * + 1024); + + /* Link the private data with the MTD structure */ + pnx8550_mtd.priv = this; + this->chip_delay = 15; + this->options = NAND_BUSWIDTH_16; + this->cmdfunc = pnx8550_nand_command; + this->read_byte = pnx8550_nand_read_byte; + this->read_word = pnx8550_nand_read_word; + this->read_buf = pnx8550_nand_read_buf; + this->write_byte = pnx8550_nand_write_byte; + this->write_word = pnx8550_nand_write_word; + this->write_buf = pnx8550_nand_write_buf; + this->verify_buf = pnx8550_nand_verify_buf; + this->dev_ready = pnx8550_nand_dev_ready; + this->hwcontrol = pnx8550_nand_hwcontrol; + this->eccmode = NAND_ECC_SOFT; + this->badblock_pattern = &nand16bit_memorybased; + this->autooob = &nand16bit_oob_16; + + transferBuffer = + kmalloc(pnx8550_mtd.oobblock + pnx8550_mtd.oobsize, + GFP_DMA | GFP_KERNEL); + if (!transferBuffer) { + printk(KERN_ERR + "Unable to allocate NAND data buffer for PNX8550\n"); + return -ENOMEM; + } + + /* Scan to find existence of the device */ + if (nand_scan(&pnx8550_mtd, 1)) { + printk(KERN_ERR "No NAND devices\n"); + return -ENXIO; + } + + add_mtd_partitions(&pnx8550_mtd, partition_info, NUM_PARTITIONS); + + return 0; +} + +module_init(pnx8550_nand_init); + +#ifdef MODULE +static void __exit pnx8550_nand_cleanup(void) +{ + nand_release(&pnx8550_mtd); + kfree(transferBuffer); +} + +module_exit(pnx8550_nand_cleanup); +#endif + +MODULE_LICENSE("GPL"); +MODULE_AUTHOR("Adam Charrett"); +MODULE_DESCRIPTION("Driver for 16Bit NAND Flash on the XIO bus for PNX8550"); Index: linux-2.6.15_0/drivers/mtd/nand/Makefile =================================================================== --- linux-2.6.15_0.orig/drivers/mtd/nand/Makefile +++ linux-2.6.15_0/drivers/mtd/nand/Makefile @@ -18,5 +18,6 @@ obj-$(CONFIG_MTD_NAND_H1900) += h1910.o obj-$(CONFIG_MTD_NAND_RTC_FROM4) += rtc_from4.o obj-$(CONFIG_MTD_NAND_SHARPSL) += sharpsl.o obj-$(CONFIG_MTD_NAND_NANDSIM) += nandsim.o +obj-$(CONFIG_MTD_NAND_PNX8550) += pnx8550.o nand-objs = nand_base.o nand_bbt.o Index: linux-2.6.15_0/include/asm-mips/mach-pnx8550/nand.h =================================================================== --- linux-2.6.15_0.orig/include/asm-mips/mach-pnx8550/nand.h +++ linux-2.6.15_0/include/asm-mips/mach-pnx8550/nand.h @@ -4,10 +4,14 @@ #define PNX8550_NAND_BASE_ADDR 0x10000000 #define PNX8550_PCIXIO_BASE 0xBBE40000 +#define PNX8550_BASE10_ADDR *(volatile unsigned long *)(PNX8550_PCIXIO_BASE + 0x050) +#define PNX8550_BASE14_ADDR *(volatile unsigned long *)(PNX8550_PCIXIO_BASE + 0x054) +#define PNX8550_BASE18_ADDR *(volatile unsigned long *)(PNX8550_PCIXIO_BASE + 0x058) #define PNX8550_DMA_EXT_ADDR *(volatile unsigned long *)(PNX8550_PCIXIO_BASE + 0x800) #define PNX8550_DMA_INT_ADDR *(volatile unsigned long *)(PNX8550_PCIXIO_BASE + 0x804) #define PNX8550_DMA_TRANS_SIZE *(volatile unsigned long *)(PNX8550_PCIXIO_BASE + 0x808) #define PNX8550_DMA_CTRL *(volatile unsigned long *)(PNX8550_PCIXIO_BASE + 0x80c) +#define PNX8550_XIO_CTRL *(volatile unsigned long *)(PNX8550_PCIXIO_BASE + 0x810) #define PNX8550_XIO_SEL0 *(volatile unsigned long *)(PNX8550_PCIXIO_BASE + 0x814) #define PNX8550_GPXIO_ADDR *(volatile unsigned long *)(PNX8550_PCIXIO_BASE + 0x820) #define PNX8550_GPXIO_WR *(volatile unsigned long *)(PNX8550_PCIXIO_BASE + 0x824) @@ -21,6 +25,8 @@ #define PNX8550_DMA_INT_ENABLE *(volatile unsigned long *)(PNX8550_PCIXIO_BASE + 0xfd4) #define PNX8550_DMA_INT_CLEAR *(volatile unsigned long *)(PNX8550_PCIXIO_BASE + 0xfd8) +#define PNX8550_XIO_CTRL_XIO_ACK 0x00000002 + #define PNX8550_XIO_SEL0_EN_16BIT 0x00800000 #define PNX8550_XIO_SEL0_USE_ACK 0x00400000 #define PNX8550_XIO_SEL0_REN_HIGH 0x00100000 @@ -39,6 +45,9 @@ #define PNX8550_XIO_SEL0_SIZE_64MB 0x00000006 #define PNX8550_XIO_SEL0_ENAB 0x00000001 +#define PNX8550_XIO_SEL0_OFFSET_SHIFT 5 +#define PNX8550_XIO_SEL0_OFFSET_MASK (0xf << PNX8550_XIO_SEL0_OFFSET_SHIFT) + #define PNX8550_SEL0_DEFAULT ((PNX8550_XIO_SEL0_EN_16BIT) | \ (PNX8550_XIO_SEL0_REN_HIGH*0)| \ (PNX8550_XIO_SEL0_REN_LOW*2) | \ @@ -59,11 +68,15 @@ #define PNX8550_XIO_FLASH_64MB 0x00200000 #define PNX8550_XIO_FLASH_INC_DATA 0x00100000 -#define PNX8550_XIO_FLASH_CMD_PH 0x000C0000 +#define PNX8550_XIO_FLASH_CMD_PH_SHIFT 18 +#define PNX8550_XIO_FLASH_CMD_PH_MASK (3 << PNX8550_XIO_FLASH_CMD_PH_SHIFT) +#define PNX8550_XIO_FLASH_CMD_PH(_x) (((_x) << PNX8550_XIO_FLASH_CMD_PH_SHIFT) & PNX8550_XIO_FLASH_CMD_PH_MASK) +#define PNX8550_XIO_FLASH_ADR_PH_SHIFT 16 +#define PNX8550_XIO_FLASH_ADR_PH_MASK (3 << PNX8550_XIO_FLASH_ADR_PH_SHIFT) +#define PNX8550_XIO_FLASH_ADR_PH(_x) (((_x) << PNX8550_XIO_FLASH_ADR_PH_SHIFT) & PNX8550_XIO_FLASH_ADR_PH_MASK) #define PNX8550_XIO_FLASH_CMD_PH2 0x00080000 #define PNX8550_XIO_FLASH_CMD_PH1 0x00040000 #define PNX8550_XIO_FLASH_CMD_PH0 0x00000000 -#define PNX8550_XIO_FLASH_ADR_PH 0x00030000 #define PNX8550_XIO_FLASH_ADR_PH3 0x00030000 #define PNX8550_XIO_FLASH_ADR_PH2 0x00020000 #define PNX8550_XIO_FLASH_ADR_PH1 0x00010000 @@ -118,4 +131,9 @@ #define PNX8550_DMA_INT_CLR_M_ABORT (1<<2) #define PNX8550_DMA_INT_CLR_T_ABORT (1<<1) +#define PNX8550_DMA_INT_ACK 0x00004000 +#define PNX8550_DMA_INT_COMPL 0x00001000 +#define PNX8550_DMA_INT_NONSUP 0x00000200 +#define PNX8550_DMA_INT_ABORT 0x00000004 + #endif --------------050702040603060002030909-- --------------050100090406070005010902-- From zzh.hust@gmail.com Wed Dec 21 08:50:28 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 21 Dec 2005 08:50:46 +0000 (GMT) Received: from wproxy.gmail.com ([64.233.184.196]:4023 "EHLO wproxy.gmail.com") by ftp.linux-mips.org with ESMTP id S8133718AbVLUIu2 convert rfc822-to-8bit (ORCPT ); Wed, 21 Dec 2005 08:50:28 +0000 Received: by wproxy.gmail.com with SMTP id 36so82784wra for ; Wed, 21 Dec 2005 00:51:35 -0800 (PST) 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=pG02XSOmD8ZFrpCLPQC0G4BrlyVQKbt8QJHTpDRD9W93nBOnk9fAoCfSGH5JZPbN65ahEY7BEazYyNtv4UK/6hJkuQ6/NIjXN8CNjIdxMEhu8LAJGft5gzbR1lAyPns0ZGJnR0UWCBLPVQIv8ecCFEEEsrBWOswcVhdmYoj87SY= Received: by 10.54.79.15 with SMTP id c15mr532247wrb; Wed, 21 Dec 2005 00:51:35 -0800 (PST) Received: by 10.54.156.5 with HTTP; Wed, 21 Dec 2005 00:51:35 -0800 (PST) Message-ID: <50c9a2250512210051q85f813fx27b0533fe66165e2@mail.gmail.com> Date: Wed, 21 Dec 2005 16:51:35 +0800 From: zhuzhenhua To: linux-mips@linux-mips.org Subject: does someone succeed in making the toolchain for 2.6 kernel? MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT 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: 9700 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 want to compile a 2.6.14 kernel for mips 4kec, does someone compile the 2.6 kernel with self-build toolchain? how to select the gcc, gdb,glibc,linux head and binutils version? and where to get the guide doc? Best regards! zhuzhenhua From jbglaw@lug-owl.de Wed Dec 21 08:54:31 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 21 Dec 2005 08:54:49 +0000 (GMT) Received: from lug-owl.de ([195.71.106.12]:52368 "EHLO lug-owl.de") by ftp.linux-mips.org with ESMTP id S8133862AbVLUIyb (ORCPT ); Wed, 21 Dec 2005 08:54:31 +0000 Received: by lug-owl.de (Postfix, from userid 1001) id F1DE0F0046; Wed, 21 Dec 2005 09:55:39 +0100 (CET) Date: Wed, 21 Dec 2005 09:55:39 +0100 From: Jan-Benedict Glaw To: linux-mips@linux-mips.org Subject: Re: does someone succeed in making the toolchain for 2.6 kernel? Message-ID: <20051221085539.GS13985@lug-owl.de> Mail-Followup-To: linux-mips@linux-mips.org References: <50c9a2250512210051q85f813fx27b0533fe66165e2@mail.gmail.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="geeFENrZXK6HHgAa" Content-Disposition: inline In-Reply-To: <50c9a2250512210051q85f813fx27b0533fe66165e2@mail.gmail.com> X-Operating-System: Linux mail 2.6.12.3lug-owl X-gpg-fingerprint: 250D 3BCF 7127 0D8C A444 A961 1DBD 5E75 8399 E1BB X-gpg-key: wwwkeys.de.pgp.net X-Echelon-Enable: howto poison arsenous mail psychological biological nuclear warfare test the bombastical terror of flooding the spy listeners explosion sex drugs and rock'n'roll X-TKUeV: howto poison arsenous mail psychological biological nuclear warfare test the bombastical terror of flooding the spy listeners explosion sex drugs and rock'n'roll 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: 9701 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: jbglaw@lug-owl.de Precedence: bulk X-list: linux-mips --geeFENrZXK6HHgAa Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, 2005-12-21 16:51:35 +0800, zhuzhenhua wrote: > i want to compile a 2.6.14 kernel for mips 4kec, does someone compile > the 2.6 kernel with self-build toolchain? how to select the gcc, > gdb,glibc,linux head and binutils version? > and where to get the guide doc? After you've built your toolchain, it's either an additional native one (gcc-4.1), or you've build some kind of cross-toolchain that got a prefix (mips-linux-gcc). In the former case, you'd be able to "make CC=3Dgcc-4.1" a kernel, in the later case you call make like "make CROSS_COMPILE=3Dvax-linux-". MfG, JBG --=20 Jan-Benedict Glaw jbglaw@lug-owl.de . +49-172-7608481 = _ O _ "Eine Freie Meinung in einem Freien Kopf | Gegen Zensur | Gegen Krieg = _ _ O f=C3=BCr einen Freien Staat voll Freier B=C3=BCrger" | im Internet! | i= m Irak! O O O ret =3D do_actions((curr | FREE_SPEECH) & ~(NEW_COPYRIGHT_LAW | DRM | TCPA)= ); --geeFENrZXK6HHgAa Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFDqRiLHb1edYOZ4bsRArKbAKCH4JLwRjHur6/JQ8oufY7+N/4/QwCeJ5hI wDSqqScrhupXQYHxdhzGtiA= =yOYf -----END PGP SIGNATURE----- --geeFENrZXK6HHgAa-- From ppopov@embeddedalley.com Wed Dec 21 08:56:11 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 21 Dec 2005 08:56:29 +0000 (GMT) Received: from smtp102.biz.mail.mud.yahoo.com ([68.142.200.237]:18362 "HELO smtp102.biz.mail.mud.yahoo.com") by ftp.linux-mips.org with SMTP id S8133718AbVLUI4L (ORCPT ); Wed, 21 Dec 2005 08:56:11 +0000 Received: (qmail 37599 invoked from network); 21 Dec 2005 08:57:13 -0000 Received: from unknown (HELO ?192.168.1.121?) (ppopov@embeddedalley.com@71.128.175.242 with plain) by smtp102.biz.mail.mud.yahoo.com with SMTP; 21 Dec 2005 08:57:13 -0000 Subject: Re: does someone succeed in making the toolchain for 2.6 kernel? From: Pete Popov Reply-To: ppopov@embeddedalley.com To: zhuzhenhua Cc: "'linux-mips@linux-mips.org'" In-Reply-To: <50c9a2250512210051q85f813fx27b0533fe66165e2@mail.gmail.com> References: <50c9a2250512210051q85f813fx27b0533fe66165e2@mail.gmail.com> Content-Type: text/plain Organization: Embedded Alley Solutions, Inc Date: Wed, 21 Dec 2005 00:57:12 -0800 Message-Id: <1135155432.9009.18.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.0.4 (2.0.4-4) 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: 9702 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, 2005-12-21 at 16:51 +0800, zhuzhenhua wrote: > i want to compile a 2.6.14 kernel for mips 4kec, does someone compile > the 2.6 kernel with self-build toolchain? Quite a few people have, I'm sure. > how to select the gcc, > gdb,glibc,linux head and binutils version? > and where to get the guide doc? If you have such questions, I would suggest you start by compiling and booting your kernel with a toolchain and distribution that already works. Build your own toolchain, if you must, later. Pete From zzh.hust@gmail.com Wed Dec 21 09:03:20 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 21 Dec 2005 09:03:38 +0000 (GMT) Received: from wproxy.gmail.com ([64.233.184.204]:24947 "EHLO wproxy.gmail.com") by ftp.linux-mips.org with ESMTP id S8133718AbVLUJDU convert rfc822-to-8bit (ORCPT ); Wed, 21 Dec 2005 09:03:20 +0000 Received: by wproxy.gmail.com with SMTP id 36so84336wra for ; Wed, 21 Dec 2005 01:04:26 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=YGb/Vfq/HfErvxbhntQxCWaMxS/VjTLbquU67w8ZPvUlPAHcQzcJGKwA6JYVYuyqjetp78JiFB9W50OYGoCMGj0CzHpwPKdlLHo55hguPtew5/mZe1dPqyDrM5UnR0o1xiVe9ezcg726FZGDMF9KW53TOYpLBFzGxV99U5bMA7s= Received: by 10.54.105.7 with SMTP id d7mr561138wrc; Wed, 21 Dec 2005 01:04:26 -0800 (PST) Received: by 10.54.156.5 with HTTP; Wed, 21 Dec 2005 01:04:25 -0800 (PST) Message-ID: <50c9a2250512210104j4a19e37cu30c795d4acc226d2@mail.gmail.com> Date: Wed, 21 Dec 2005 17:04:25 +0800 From: zhuzhenhua To: linux-mips@linux-mips.org Subject: Re: does someone succeed in making the toolchain for 2.6 kernel? In-Reply-To: <20051221085539.GS13985@lug-owl.de> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT Content-Disposition: inline References: <50c9a2250512210051q85f813fx27b0533fe66165e2@mail.gmail.com> <20051221085539.GS13985@lug-owl.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: 9703 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 sorry to not describle clearly i want to know how to build the cross-compile toolchain On 12/21/05, Jan-Benedict Glaw wrote: > On Wed, 2005-12-21 16:51:35 +0800, zhuzhenhua wrote: > > i want to compile a 2.6.14 kernel for mips 4kec, does someone compile > > the 2.6 kernel with self-build toolchain? how to select the gcc, > > gdb,glibc,linux head and binutils version? > > and where to get the guide doc? > > After you've built your toolchain, it's either an additional native > one (gcc-4.1), or you've build some kind of cross-toolchain that got a > prefix (mips-linux-gcc). > > In the former case, you'd be able to "make CC=gcc-4.1" a kernel, in > the later case you call make like "make CROSS_COMPILE=vax-linux-". > > MfG, JBG > > -- > Jan-Benedict Glaw jbglaw@lug-owl.de . +49-172-7608481 _ O _ > "Eine Freie Meinung in einem Freien Kopf | Gegen Zensur | Gegen Krieg _ _ O > für einen Freien Staat voll Freier Bürger" | im Internet! | im Irak! O O O > ret = do_actions((curr | FREE_SPEECH) & ~(NEW_COPYRIGHT_LAW | DRM | TCPA)); > > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.1 (GNU/Linux) > > iD8DBQFDqRiLHb1edYOZ4bsRArKbAKCH4JLwRjHur6/JQ8oufY7+N/4/QwCeJ5hI > wDSqqScrhupXQYHxdhzGtiA= > =yOYf > -----END PGP SIGNATURE----- > > > Best regards zhuzhenhua From zzh.hust@gmail.com Wed Dec 21 09:05:29 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 21 Dec 2005 09:05:46 +0000 (GMT) Received: from wproxy.gmail.com ([64.233.184.192]:18820 "EHLO wproxy.gmail.com") by ftp.linux-mips.org with ESMTP id S8133718AbVLUJF3 convert rfc822-to-8bit (ORCPT ); Wed, 21 Dec 2005 09:05:29 +0000 Received: by wproxy.gmail.com with SMTP id 36so84607wra for ; Wed, 21 Dec 2005 01:06:37 -0800 (PST) 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=KpLvYIeGRfy3RAzqZpw2ZY5wlM7ERtMQNsyb5DLwRsC7ymHlkbSsptSw9NU+xtvDHP/C2WJR9/OttnlHsn3lsAdZHNcuOGH2fq1b0+V1BMHMu1MbTFnp6KLWuYjDDpIfUBtgQxPexnPWur0l8qBtm/8mnGXdAYuwYizkd9ynqLQ= Received: by 10.54.105.16 with SMTP id d16mr556214wrc; Wed, 21 Dec 2005 01:06:36 -0800 (PST) Received: by 10.54.156.5 with HTTP; Wed, 21 Dec 2005 01:06:36 -0800 (PST) Message-ID: <50c9a2250512210106h7bca5c7fu5714ea3aa16cde8a@mail.gmail.com> Date: Wed, 21 Dec 2005 17:06:36 +0800 From: zhuzhenhua To: ppopov@embeddedalley.com Subject: Re: does someone succeed in making the toolchain for 2.6 kernel? Cc: "linux-mips@linux-mips.org" In-Reply-To: <1135155432.9009.18.camel@localhost.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT Content-Disposition: inline References: <50c9a2250512210051q85f813fx27b0533fe66165e2@mail.gmail.com> <1135155432.9009.18.camel@localhost.localdomain> 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: 9704 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 am not sure which toolchain can work for the 2.6 kernel can you suggest one? thanks On 12/21/05, Pete Popov wrote: > On Wed, 2005-12-21 at 16:51 +0800, zhuzhenhua wrote: > > i want to compile a 2.6.14 kernel for mips 4kec, does someone compile > > the 2.6 kernel with self-build toolchain? > > Quite a few people have, I'm sure. > > > how to select the gcc, > > gdb,glibc,linux head and binutils version? > > and where to get the guide doc? > > If you have such questions, I would suggest you start by compiling and > booting your kernel with a toolchain and distribution that already > works. Build your own toolchain, if you must, later. > > Pete > > Best regards zhuzhenhua From jbglaw@lug-owl.de Wed Dec 21 09:17:48 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 21 Dec 2005 09:18:09 +0000 (GMT) Received: from lug-owl.de ([195.71.106.12]:11155 "EHLO lug-owl.de") by ftp.linux-mips.org with ESMTP id S3458538AbVLUJRs (ORCPT ); Wed, 21 Dec 2005 09:17:48 +0000 Received: by lug-owl.de (Postfix, from userid 1001) id B274CF0041; Wed, 21 Dec 2005 10:18:52 +0100 (CET) Date: Wed, 21 Dec 2005 10:18:52 +0100 From: Jan-Benedict Glaw To: linux-mips@linux-mips.org Subject: Re: does someone succeed in making the toolchain for 2.6 kernel? Message-ID: <20051221091852.GT13985@lug-owl.de> Mail-Followup-To: linux-mips@linux-mips.org References: <50c9a2250512210051q85f813fx27b0533fe66165e2@mail.gmail.com> <20051221085539.GS13985@lug-owl.de> <50c9a2250512210104j4a19e37cu30c795d4acc226d2@mail.gmail.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="CR5S1WJ1/E083K3u" Content-Disposition: inline In-Reply-To: <50c9a2250512210104j4a19e37cu30c795d4acc226d2@mail.gmail.com> X-Operating-System: Linux mail 2.6.12.3lug-owl X-gpg-fingerprint: 250D 3BCF 7127 0D8C A444 A961 1DBD 5E75 8399 E1BB X-gpg-key: wwwkeys.de.pgp.net X-Echelon-Enable: howto poison arsenous mail psychological biological nuclear warfare test the bombastical terror of flooding the spy listeners explosion sex drugs and rock'n'roll X-TKUeV: howto poison arsenous mail psychological biological nuclear warfare test the bombastical terror of flooding the spy listeners explosion sex drugs and rock'n'roll 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: 9705 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: jbglaw@lug-owl.de Precedence: bulk X-list: linux-mips --CR5S1WJ1/E083K3u Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, 2005-12-21 17:04:25 +0800, zhuzhenhua wrote: > sorry to not describle clearly > i want to know how to build the cross-compile toolchain Building a working toolchain for kernel-only work isn't _that_ hard (though, if you've never done that, you may find yourself asking Google for a month or two...) As a good starting point, go to http://www.kegel.com/crosstool/ . MfG, JBG --=20 Jan-Benedict Glaw jbglaw@lug-owl.de . +49-172-7608481 = _ O _ "Eine Freie Meinung in einem Freien Kopf | Gegen Zensur | Gegen Krieg = _ _ O f=C3=BCr einen Freien Staat voll Freier B=C3=BCrger" | im Internet! | i= m Irak! O O O ret =3D do_actions((curr | FREE_SPEECH) & ~(NEW_COPYRIGHT_LAW | DRM | TCPA)= ); --CR5S1WJ1/E083K3u Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFDqR38Hb1edYOZ4bsRAgRcAJ0T2G6SfqrKChrmMwkj96KbHhYtHwCfZhzJ zPIZUcd5GHE9RxeyKenKMPo= =Xawj -----END PGP SIGNATURE----- --CR5S1WJ1/E083K3u-- From jbglaw@lug-owl.de Wed Dec 21 09:20:59 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 21 Dec 2005 09:21:17 +0000 (GMT) Received: from lug-owl.de ([195.71.106.12]:14995 "EHLO lug-owl.de") by ftp.linux-mips.org with ESMTP id S3458548AbVLUJU7 (ORCPT ); Wed, 21 Dec 2005 09:20:59 +0000 Received: by lug-owl.de (Postfix, from userid 1001) id 14EE8F0041; Wed, 21 Dec 2005 10:22:08 +0100 (CET) Date: Wed, 21 Dec 2005 10:22:08 +0100 From: Jan-Benedict Glaw To: "linux-mips@linux-mips.org" Subject: Re: does someone succeed in making the toolchain for 2.6 kernel? Message-ID: <20051221092207.GU13985@lug-owl.de> Mail-Followup-To: "linux-mips@linux-mips.org" References: <50c9a2250512210051q85f813fx27b0533fe66165e2@mail.gmail.com> <1135155432.9009.18.camel@localhost.localdomain> <50c9a2250512210106h7bca5c7fu5714ea3aa16cde8a@mail.gmail.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="WXBLDYRe6ft2Yf8u" Content-Disposition: inline In-Reply-To: <50c9a2250512210106h7bca5c7fu5714ea3aa16cde8a@mail.gmail.com> X-Operating-System: Linux mail 2.6.12.3lug-owl X-gpg-fingerprint: 250D 3BCF 7127 0D8C A444 A961 1DBD 5E75 8399 E1BB X-gpg-key: wwwkeys.de.pgp.net X-Echelon-Enable: howto poison arsenous mail psychological biological nuclear warfare test the bombastical terror of flooding the spy listeners explosion sex drugs and rock'n'roll X-TKUeV: howto poison arsenous mail psychological biological nuclear warfare test the bombastical terror of flooding the spy listeners explosion sex drugs and rock'n'roll 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: 9706 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: jbglaw@lug-owl.de Precedence: bulk X-list: linux-mips --WXBLDYRe6ft2Yf8u Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, 2005-12-21 17:06:36 +0800, zhuzhenhua wrote: > i am not sure which toolchain can work for the 2.6 kernel > can you suggest one? That's a hard question... 2.95.x compilers used to work and were quite fast, but newer GCC's features are incorporated into the kernel sources so it probably will no longer work. Some 3.x based GCC should probably work. I am using GCC and binutils right from CVS/SVN in their HEAD revisions, but not for MIPS. Works for me. MfG, JBG --=20 Jan-Benedict Glaw jbglaw@lug-owl.de . +49-172-7608481 = _ O _ "Eine Freie Meinung in einem Freien Kopf | Gegen Zensur | Gegen Krieg = _ _ O f=C3=BCr einen Freien Staat voll Freier B=C3=BCrger" | im Internet! | i= m Irak! O O O ret =3D do_actions((curr | FREE_SPEECH) & ~(NEW_COPYRIGHT_LAW | DRM | TCPA)= ); --WXBLDYRe6ft2Yf8u Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFDqR6/Hb1edYOZ4bsRAmhVAJ0ZnQ20VRQYnkQWPZj8ci6SADKf+gCfX0dW 2iUVYcQPxubgpErmerMfSVg= =jJl4 -----END PGP SIGNATURE----- --WXBLDYRe6ft2Yf8u-- From kevink@mips.com Wed Dec 21 09:45:04 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 21 Dec 2005 09:45:22 +0000 (GMT) Received: from 209-232-97-206.ded.pacbell.net ([209.232.97.206]:36505 "EHLO dns0.mips.com") by ftp.linux-mips.org with ESMTP id S3458540AbVLUJpD (ORCPT ); Wed, 21 Dec 2005 09:45:03 +0000 Received: from mercury.mips.com (sbcns-dmz [209.232.97.193]) by dns0.mips.com (8.12.11/8.12.11) with ESMTP id jBL9jnf3004465; Wed, 21 Dec 2005 01:45:55 -0800 (PST) Received: from grendel (grendel [192.168.236.16]) by mercury.mips.com (8.12.9/8.12.11) with SMTP id jBL9jllk004606; Wed, 21 Dec 2005 01:45:48 -0800 (PST) Message-ID: <002f01c60613$8b346590$10eca8c0@grendel> From: "Kevin D. Kissell" To: "zhuzhenhua" , Cc: References: <50c9a2250512210051q85f813fx27b0533fe66165e2@mail.gmail.com> <1135155432.9009.18.camel@localhost.localdomain> <50c9a2250512210106h7bca5c7fu5714ea3aa16cde8a@mail.gmail.com> Subject: Re: does someone succeed in making the toolchain for 2.6 kernel? Date: Wed, 21 Dec 2005 10:47:21 +0100 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.1506 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 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: 9707 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 I've been using the 6.02 MIPS SDE for my 2.6 kernel builds. I'm not 100% certain that it's exactly the same one that you'll find on the page at http://www.linux-mips.org/wiki/MIPS_SDE_Installation but it's close enough where I'd suggest at least giving it a try. Regards, Kevin K. ----- Original Message ----- From: "zhuzhenhua" To: Cc: Sent: Wednesday, December 21, 2005 10:06 AM Subject: Re: does someone succeed in making the toolchain for 2.6 kernel? > i am not sure which toolchain can work for the 2.6 kernel > can you suggest one? > thanks > > On 12/21/05, Pete Popov wrote: > > On Wed, 2005-12-21 at 16:51 +0800, zhuzhenhua wrote: > > > i want to compile a 2.6.14 kernel for mips 4kec, does someone compile > > > the 2.6 kernel with self-build toolchain? > > > > Quite a few people have, I'm sure. > > > > > how to select the gcc, > > > gdb,glibc,linux head and binutils version? > > > and where to get the guide doc? > > > > If you have such questions, I would suggest you start by compiling and > > booting your kernel with a toolchain and distribution that already > > works. Build your own toolchain, if you must, later. > > > > Pete > > > > > > Best regards > zhuzhenhua > > From matej.kupljen@ultra.si Wed Dec 21 10:01:14 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 21 Dec 2005 10:01:34 +0000 (GMT) Received: from deliver-1.mx.triera.net ([213.161.0.31]:19374 "HELO deliver-1.mx.triera.net") by ftp.linux-mips.org with SMTP id S3458549AbVLUKBN (ORCPT ); Wed, 21 Dec 2005 10:01:13 +0000 Received: from localhost (in-2.mx.triera.net [213.161.0.26]) by deliver-1.mx.triera.net (Postfix) with ESMTP id 21689C068; Wed, 21 Dec 2005 11:02:17 +0100 (CET) Received: from smtp.triera.net (smtp.triera.net [213.161.0.30]) by in-2.mx.triera.net (Postfix) with SMTP id 5E9F31BC087; Wed, 21 Dec 2005 11:02:19 +0100 (CET) Received: from [172.18.1.53] (unknown [213.161.20.162]) by smtp.triera.net (Postfix) with ESMTP id 7D5AD1A18AD; Wed, 21 Dec 2005 11:02:19 +0100 (CET) Subject: Re: does someone succeed in making the toolchain for 2.6 kernel? From: Matej Kupljen To: Jan-Benedict Glaw Cc: linux-mips@linux-mips.org In-Reply-To: <20051221091852.GT13985@lug-owl.de> References: <50c9a2250512210051q85f813fx27b0533fe66165e2@mail.gmail.com> <20051221085539.GS13985@lug-owl.de> <50c9a2250512210104j4a19e37cu30c795d4acc226d2@mail.gmail.com> <20051221091852.GT13985@lug-owl.de> Content-Type: text/plain Date: Wed, 21 Dec 2005 11:02:34 +0100 Message-Id: <1135159354.5211.1.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.2.3 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: 9708 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 > As a good starting point, go to http://www.kegel.com/crosstool/ . Yes, we use crosstool, but the results matrix isn't rely encouraging: http://www.kegel.com/crosstool/crosstool-0.38/buildlogs/ BR, Matej From jbglaw@lug-owl.de Wed Dec 21 10:05:10 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 21 Dec 2005 10:05:28 +0000 (GMT) Received: from lug-owl.de ([195.71.106.12]:53989 "EHLO lug-owl.de") by ftp.linux-mips.org with ESMTP id S3458540AbVLUKFK (ORCPT ); Wed, 21 Dec 2005 10:05:10 +0000 Received: by lug-owl.de (Postfix, from userid 1001) id 5CB1FF0047; Wed, 21 Dec 2005 11:06:19 +0100 (CET) Date: Wed, 21 Dec 2005 11:06:19 +0100 From: Jan-Benedict Glaw To: linux-mips@linux-mips.org Subject: Re: does someone succeed in making the toolchain for 2.6 kernel? Message-ID: <20051221100619.GW13985@lug-owl.de> Mail-Followup-To: linux-mips@linux-mips.org References: <50c9a2250512210051q85f813fx27b0533fe66165e2@mail.gmail.com> <20051221085539.GS13985@lug-owl.de> <50c9a2250512210104j4a19e37cu30c795d4acc226d2@mail.gmail.com> <20051221091852.GT13985@lug-owl.de> <1135159354.5211.1.camel@localhost.localdomain> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="TMj/TYF/hpk1GcbO" Content-Disposition: inline In-Reply-To: <1135159354.5211.1.camel@localhost.localdomain> X-Operating-System: Linux mail 2.6.12.3lug-owl X-gpg-fingerprint: 250D 3BCF 7127 0D8C A444 A961 1DBD 5E75 8399 E1BB X-gpg-key: wwwkeys.de.pgp.net X-Echelon-Enable: howto poison arsenous mail psychological biological nuclear warfare test the bombastical terror of flooding the spy listeners explosion sex drugs and rock'n'roll X-TKUeV: howto poison arsenous mail psychological biological nuclear warfare test the bombastical terror of flooding the spy listeners explosion sex drugs and rock'n'roll 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: 9709 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: jbglaw@lug-owl.de Precedence: bulk X-list: linux-mips --TMj/TYF/hpk1GcbO Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, 2005-12-21 11:02:34 +0100, Matej Kupljen w= rote: > > As a good starting point, go to http://www.kegel.com/crosstool/ . >=20 > Yes, we use crosstool, but the results matrix isn't rely > encouraging: > http://www.kegel.com/crosstool/crosstool-0.38/buildlogs/ Well, try do do it any better *yourself*. Compiling a complete toolchain (incl. userland support) really isn't easy... MfG, JBG --=20 Jan-Benedict Glaw jbglaw@lug-owl.de . +49-172-7608481 = _ O _ "Eine Freie Meinung in einem Freien Kopf | Gegen Zensur | Gegen Krieg = _ _ O f=C3=BCr einen Freien Staat voll Freier B=C3=BCrger" | im Internet! | i= m Irak! O O O ret =3D do_actions((curr | FREE_SPEECH) & ~(NEW_COPYRIGHT_LAW | DRM | TCPA)= ); --TMj/TYF/hpk1GcbO Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFDqSkbHb1edYOZ4bsRAsl1AJ0VfeYKMcs3z+J+dhXuTkgSOTiBCgCeIpBv FEVkOpx1lfWYupfuWWN1nEY= =tcPV -----END PGP SIGNATURE----- --TMj/TYF/hpk1GcbO-- From p_christ@hol.gr Wed Dec 21 10:26:10 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 21 Dec 2005 10:26:28 +0000 (GMT) Received: from [62.38.104.168] ([62.38.104.168]:22959 "EHLO pfn3.pefnos") by ftp.linux-mips.org with ESMTP id S3458540AbVLUK0K (ORCPT ); Wed, 21 Dec 2005 10:26:10 +0000 Received: from xorhgos2.pefnos (xorhgos2.pefnos [192.168.0.3]) by pfn3.pefnos (Postfix) with ESMTP id 00FCC1F101; Wed, 21 Dec 2005 12:27:11 +0200 (EET) From: "P. Christeas" To: linux-mips@linux-mips.org Subject: Re: does someone succeed in making the toolchain for 2.6 kernel? Date: Wed, 21 Dec 2005 12:27:07 +0200 User-Agent: KMail/1.9 Cc: Jan-Benedict Glaw References: <50c9a2250512210051q85f813fx27b0533fe66165e2@mail.gmail.com> <50c9a2250512210104j4a19e37cu30c795d4acc226d2@mail.gmail.com> <20051221091852.GT13985@lug-owl.de> In-Reply-To: <20051221091852.GT13985@lug-owl.de> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200512211227.08501.p_christ@hol.gr> 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: 9710 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: p_christ@hol.gr Precedence: bulk X-list: linux-mips > On Wed, 2005-12-21 17:04:25 +0800, zhuzhenhua wrote: > > sorry to not describle clearly > > i want to know how to build the cross-compile toolchain > > Building a working toolchain for kernel-only work isn't _that_ hard > (though, if you've never done that, you may find yourself asking > Google for a month or two...) > > As a good starting point, go to http://www.kegel.com/crosstool/ . > I have been using the toolchain of OpenWRT. (it builds uClibs rather than glibc) However, I am noting some instability of the system and that *could* be because of gcc. I am reading that you also have some trouble with the instructions it generates. From matej.kupljen@ultra.si Wed Dec 21 10:30:55 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 21 Dec 2005 10:31:12 +0000 (GMT) Received: from deliver-1.mx.triera.net ([213.161.0.31]:6579 "HELO deliver-1.mx.triera.net") by ftp.linux-mips.org with SMTP id S3458540AbVLUKaz (ORCPT ); Wed, 21 Dec 2005 10:30:55 +0000 Received: from localhost (in-3.mx.triera.net [213.161.0.27]) by deliver-1.mx.triera.net (Postfix) with ESMTP id 24B48C009; Wed, 21 Dec 2005 11:31:59 +0100 (CET) Received: from smtp.triera.net (smtp.triera.net [213.161.0.30]) by in-3.mx.triera.net (Postfix) with SMTP id 9AC3C1BC079; Wed, 21 Dec 2005 11:32:01 +0100 (CET) Received: from [172.18.1.53] (unknown [213.161.20.162]) by smtp.triera.net (Postfix) with ESMTP id 8CC661A18B9; Wed, 21 Dec 2005 11:32:01 +0100 (CET) Subject: Re: does someone succeed in making the toolchain for 2.6 kernel? From: Matej Kupljen To: Jan-Benedict Glaw Cc: linux-mips@linux-mips.org In-Reply-To: <20051221100619.GW13985@lug-owl.de> References: <50c9a2250512210051q85f813fx27b0533fe66165e2@mail.gmail.com> <20051221085539.GS13985@lug-owl.de> <50c9a2250512210104j4a19e37cu30c795d4acc226d2@mail.gmail.com> <20051221091852.GT13985@lug-owl.de> <1135159354.5211.1.camel@localhost.localdomain> <20051221100619.GW13985@lug-owl.de> Content-Type: text/plain Date: Wed, 21 Dec 2005 11:32:16 +0100 Message-Id: <1135161136.5211.8.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.2.3 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: 9711 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 > > Yes, we use crosstool, but the results matrix isn't rely > > encouraging: > > http://www.kegel.com/crosstool/crosstool-0.38/buildlogs/ > > Well, try do do it any better *yourself*. Compiling a complete > toolchain (incl. userland support) really isn't easy... You probably misunderstood me :( I was trying to say, that we use crosstool *successfully* to build kernel 2.6.15-rc5 (and a bunch of user land binaries) and that this matrix should be updated. If someone looks at this matrix, he thinks that for mips(el) crosstool does not work. BR, Matej From zzh.hust@gmail.com Wed Dec 21 10:36:51 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 21 Dec 2005 10:37:08 +0000 (GMT) Received: from wproxy.gmail.com ([64.233.184.195]:12449 "EHLO wproxy.gmail.com") by ftp.linux-mips.org with ESMTP id S3458540AbVLUKgv convert rfc822-to-8bit (ORCPT ); Wed, 21 Dec 2005 10:36:51 +0000 Received: by wproxy.gmail.com with SMTP id 36so97266wra for ; Wed, 21 Dec 2005 02:37:59 -0800 (PST) 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=QkiPyIeDIuiG0fnMBvrBeekpsBy6Dw67p3wGOGtmBL8yXNJpUIDMKk/xTKpxj2zIKxySEqGcW4//gVeWIEuGDYbZnaFPyDa6+on7XvAoDRmtEl5BpRZITy3A9t8SiOlyD8nT0gkXoxZ2HO7d3TxX3ojXDcfQJtPM5u8WWIuYgKM= Received: by 10.54.133.9 with SMTP id g9mr672604wrd; Wed, 21 Dec 2005 02:37:58 -0800 (PST) Received: by 10.54.156.5 with HTTP; Wed, 21 Dec 2005 02:37:58 -0800 (PST) Message-ID: <50c9a2250512210237l19443e53v66a9276e193f80e8@mail.gmail.com> Date: Wed, 21 Dec 2005 18:37:58 +0800 From: zhuzhenhua To: Matej Kupljen Subject: Re: does someone succeed in making the toolchain for 2.6 kernel? Cc: Jan-Benedict Glaw , linux-mips@linux-mips.org In-Reply-To: <1135161136.5211.8.camel@localhost.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT Content-Disposition: inline References: <50c9a2250512210051q85f813fx27b0533fe66165e2@mail.gmail.com> <20051221085539.GS13985@lug-owl.de> <50c9a2250512210104j4a19e37cu30c795d4acc226d2@mail.gmail.com> <20051221091852.GT13985@lug-owl.de> <1135159354.5211.1.camel@localhost.localdomain> <20051221100619.GW13985@lug-owl.de> <1135161136.5211.8.camel@localhost.localdomain> 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: 9712 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 12/21/05, Matej Kupljen wrote: > Hi > > > > Yes, we use crosstool, but the results matrix isn't rely > > > encouraging: > > > http://www.kegel.com/crosstool/crosstool-0.38/buildlogs/ > > > > Well, try do do it any better *yourself*. Compiling a complete > > toolchain (incl. userland support) really isn't easy... > > You probably misunderstood me :( > > I was trying to say, that we use crosstool *successfully* to build > kernel 2.6.15-rc5 (and a bunch of user land binaries) and that > this matrix should be updated. > > If someone looks at this matrix, he thinks that for mips(el) crosstool > does not work. > you are right, as i see the matrix, i just think it can't work for mips with your reply, i want to try this thanks! > BR, > Matej > > > Best regards! zhuzhenhua From ralf@linux-mips.org Wed Dec 21 18:59:04 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 21 Dec 2005 18:59:21 +0000 (GMT) Received: from p549F5309.dip.t-dialin.net ([84.159.83.9]:37217 "EHLO mail.linux-mips.net") by ftp.linux-mips.org with ESMTP id S8133470AbVLUS7E (ORCPT ); Wed, 21 Dec 2005 18:59:04 +0000 Received: from fluff.linux-mips.net (localhost.localdomain [127.0.0.1]) by mail.linux-mips.net (8.13.4/8.13.1) with ESMTP id jBLJ0EYj014806 for ; Wed, 21 Dec 2005 20:00:14 +0100 Received: (from ralf@localhost) by fluff.linux-mips.net (8.13.4/8.13.4/Submit) id jBLJ0E2A014805 for linux-mips@linux-mips.org; Wed, 21 Dec 2005 20:00:14 +0100 Date: Wed, 21 Dec 2005 20:00:14 +0100 From: Ralf Baechle To: "linux-mips@linux-mips.org" Subject: Re: does someone succeed in making the toolchain for 2.6 kernel? Message-ID: <20051221190014.GA1918@linux-mips.org> References: <50c9a2250512210051q85f813fx27b0533fe66165e2@mail.gmail.com> <1135155432.9009.18.camel@localhost.localdomain> <50c9a2250512210106h7bca5c7fu5714ea3aa16cde8a@mail.gmail.com> <20051221092207.GU13985@lug-owl.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20051221092207.GU13985@lug-owl.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: 9713 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, Dec 21, 2005 at 10:22:08AM +0100, Jan-Benedict Glaw wrote: > On Wed, 2005-12-21 17:06:36 +0800, zhuzhenhua wrote: > > i am not sure which toolchain can work for the 2.6 kernel > > can you suggest one? > > That's a hard question... 2.95.x compilers used to work and were quite > fast, but newer GCC's features are incorporated into the kernel > sources so it probably will no longer work. There are still users building the kernel with gcc 2.95 and 2.96 successfully. Ralf From skommu@sjc-xdm-007.cisco.com Wed Dec 21 19:38:08 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 21 Dec 2005 19:38:27 +0000 (GMT) Received: from sj-iport-5.cisco.com ([171.68.10.87]:55921 "EHLO sj-iport-5.cisco.com") by ftp.linux-mips.org with ESMTP id S8133869AbVLUTiI (ORCPT ); Wed, 21 Dec 2005 19:38:08 +0000 Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-5.cisco.com with ESMTP; 21 Dec 2005 11:39:09 -0800 X-IronPort-AV: i="3.99,280,1131350400"; d="scan'208"; a="243733236:sNHT33022368" Received: from cisco.com (sjc-xdm-007.cisco.com [171.70.105.141]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id jBLJd6Me019119; Wed, 21 Dec 2005 11:39:07 -0800 (PST) Received: from sjc-xdm-007.cisco.com (localhost.localdomain [127.0.0.1]) by cisco.com (8.12.11/8.12.11) with ESMTP id jBLJd6tB017143; Wed, 21 Dec 2005 11:39:06 -0800 Received: (from skommu@localhost) by sjc-xdm-007.cisco.com (8.12.11/8.12.11/Submit) id jBLJd6a9017141; Wed, 21 Dec 2005 11:39:06 -0800 Date: Wed, 21 Dec 2005 11:39:06 -0800 From: Srinivas Kommu To: Ralf Baechle Cc: Yoann Allain , "'linux-mips@linux-mips.org'" Subject: Re: Preempted interrupt handler Message-ID: <20051221193906.GB1456@sjc-xdm-007.cisco.com> References: <43A6F155.7080402@avilinks.com> <20051220131829.GB3376@linux-mips.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20051220131829.GB3376@linux-mips.org> User-Agent: Mutt/1.5.10i 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: 9714 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: kommu@hotmail.com Precedence: bulk X-list: linux-mips On Tue, Dec 20, 2005 at 02:18:29PM +0100, Ralf Baechle wrote: > On Mon, Dec 19, 2005 at 06:43:49PM +0100, Yoann Allain wrote: > > > I'm actually working on a driver for a Marvell chip on a MIPS-based > > board running a 2.4 kernel. I have one problem: > > In my module, my interrupt handler is never executed. I have traced the > > code until action->handler(irq, action->dev_id, regs) in > > handle_IRQ_event() but when the handler should be executed, it is not > > and the kernel reenters in the low-level interrupt dispatch routine > > (because we're using level sensitive interrupts and it is still up). > > I've checked that the function pointer called is the one of my handler > > but my routine is never entered. > > > > But when my handler is included in the kernel (ie not compiled as a > > module), it works! My function gets executed and acks the interrupt. In > > this case all goes fine. > > > > Moreover, I've noticed that the kernel symbols are mapped at adresses > > like 0x80258040 (start_kernel) but my module (and so is my handler) is > > loaded at something like 0xc000275c . I was thinking the module would be > > loaded in the same memory area as the kernel, so I think this is weird... > > Perhaps, the module handler can't be executed because of its location > > but I don't know how to fix this. > > Good new then - you don't need to fix anything :-) > > The sympthoms you're describing are not specific enough, so only some > general advice: > > - Make sure you're running a current version of modutils; older versions > have a number of bugs that could result in almost any kind of ill > behaviour. > - Make sure all object files of the modules have been built with > -mlong-calls. That's done automatically by the kernel's makefiles > but not necessarily when building out of tree and certain versions > would silently tolerate the resulting relocation error. Is it normal for the modules to be loaded at 0xc0000000 (this is highmem, isn't it)? I see the same on my bcm1250 box. I've been wondering why they can't be loaded in kseg0. Or is it because of bad modutils/compiler flags? thanks srini > > Ralf -- Srinivas Kommu Cisco Systems, Inc. Ph. (408) 527-8610 From sjhill@realitydiluted.com Wed Dec 21 20:14:09 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 21 Dec 2005 20:14:27 +0000 (GMT) Received: from eth13.com-link.com ([208.242.241.164]:24514 "EHLO real.realitydiluted.com") by ftp.linux-mips.org with ESMTP id S8133868AbVLUUOJ (ORCPT ); Wed, 21 Dec 2005 20:14:09 +0000 Received: from localhost ([127.0.0.1]) by real.realitydiluted.com with esmtp (Exim 4.52 #1 (Debian)) id 1Ep9R6-0003Fd-Bm; Wed, 21 Dec 2005 13:15:40 -0600 Message-ID: <43A9B7D6.9070405@realitydiluted.com> Date: Wed, 21 Dec 2005 14:15:18 -0600 From: "Steven J. Hill" User-Agent: Debian Thunderbird 1.0.6 (X11/20050802) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Srinivas Kommu CC: "'linux-mips@linux-mips.org'" Subject: Re: Preempted interrupt handler References: <43A6F155.7080402@avilinks.com> <20051220131829.GB3376@linux-mips.org> <20051221193906.GB1456@sjc-xdm-007.cisco.com> In-Reply-To: <20051221193906.GB1456@sjc-xdm-007.cisco.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: 9715 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: sjhill@realitydiluted.com Precedence: bulk X-list: linux-mips Srinivas Kommu wrote: > > Is it normal for the modules to be loaded at 0xc0000000 (this is > highmem, isn't it)? I see the same on my bcm1250 box. I've been wondering > why they can't be loaded in kseg0. Or is it because of bad > modutils/compiler flags? > Yes, it is normal to load them at 0xc0000000. No it is not because of bad modutils/compiler flags. -Steve From jbglaw@lug-owl.de Wed Dec 21 20:28:31 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 21 Dec 2005 20:28:48 +0000 (GMT) Received: from lug-owl.de ([195.71.106.12]:44209 "EHLO lug-owl.de") by ftp.linux-mips.org with ESMTP id S8133868AbVLUU2b (ORCPT ); Wed, 21 Dec 2005 20:28:31 +0000 Received: by lug-owl.de (Postfix, from userid 1001) id 0151BF0044; Wed, 21 Dec 2005 21:29:37 +0100 (CET) Date: Wed, 21 Dec 2005 21:29:37 +0100 From: Jan-Benedict Glaw To: "linux-mips@linux-mips.org" Subject: Re: does someone succeed in making the toolchain for 2.6 kernel? Message-ID: <20051221202937.GB13985@lug-owl.de> Mail-Followup-To: "linux-mips@linux-mips.org" References: <50c9a2250512210051q85f813fx27b0533fe66165e2@mail.gmail.com> <1135155432.9009.18.camel@localhost.localdomain> <50c9a2250512210106h7bca5c7fu5714ea3aa16cde8a@mail.gmail.com> <20051221092207.GU13985@lug-owl.de> <20051221190014.GA1918@linux-mips.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="lBgcuyUB+qD0f9A9" Content-Disposition: inline In-Reply-To: <20051221190014.GA1918@linux-mips.org> X-Operating-System: Linux mail 2.6.12.3lug-owl X-gpg-fingerprint: 250D 3BCF 7127 0D8C A444 A961 1DBD 5E75 8399 E1BB X-gpg-key: wwwkeys.de.pgp.net X-Echelon-Enable: howto poison arsenous mail psychological biological nuclear warfare test the bombastical terror of flooding the spy listeners explosion sex drugs and rock'n'roll X-TKUeV: howto poison arsenous mail psychological biological nuclear warfare test the bombastical terror of flooding the spy listeners explosion sex drugs and rock'n'roll 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: 9716 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: jbglaw@lug-owl.de Precedence: bulk X-list: linux-mips --lBgcuyUB+qD0f9A9 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, 2005-12-21 20:00:14 +0100, Ralf Baechle wrote: > On Wed, Dec 21, 2005 at 10:22:08AM +0100, Jan-Benedict Glaw wrote: > > On Wed, 2005-12-21 17:06:36 +0800, zhuzhenhua wrot= e: > > > i am not sure which toolchain can work for the 2.6 kernel > > > can you suggest one? > >=20 > > That's a hard question... 2.95.x compilers used to work and were quite > > fast, but newer GCC's features are incorporated into the kernel > > sources so it probably will no longer work. >=20 > There are still users building the kernel with gcc 2.95 and 2.96 > successfully. I guess evolution will get'em all... And that of course depends on how much you take part in it. Only compiling a minimum set of drivers will probably help you out for some time :-> MfG, JBG --=20 Jan-Benedict Glaw jbglaw@lug-owl.de . +49-172-7608481 = _ O _ "Eine Freie Meinung in einem Freien Kopf | Gegen Zensur | Gegen Krieg = _ _ O f=C3=BCr einen Freien Staat voll Freier B=C3=BCrger" | im Internet! | i= m Irak! O O O ret =3D do_actions((curr | FREE_SPEECH) & ~(NEW_COPYRIGHT_LAW | DRM | TCPA)= ); --lBgcuyUB+qD0f9A9 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFDqbsxHb1edYOZ4bsRAng9AKCO0s2iqgpwmCIqiywbQsf6TasZNQCfQeSS Y+ZaE4HxAkZYExqMNtLaFVU= =0PMA -----END PGP SIGNATURE----- --lBgcuyUB+qD0f9A9-- From p_christ@hol.gr Wed Dec 21 22:24:24 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 21 Dec 2005 22:24:41 +0000 (GMT) Received: from [62.38.104.168] ([62.38.104.168]:38632 "EHLO pfn3.pefnos") by ftp.linux-mips.org with ESMTP id S8133560AbVLUWYX (ORCPT ); Wed, 21 Dec 2005 22:24:23 +0000 Received: from xorhgos2.pefnos (xorhgos2.pefnos [192.168.0.3]) by pfn3.pefnos (Postfix) with ESMTP id 656FA1F101 for ; Thu, 22 Dec 2005 00:25:24 +0200 (EET) From: "P. Christeas" To: linux-mips@linux-mips.org Subject: Port of RB532 Date: Thu, 22 Dec 2005 00:25:20 +0200 User-Agent: KMail/1.9 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200512220025.22834.p_christ@hol.gr> 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: 9717 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: p_christ@hol.gr Precedence: bulk X-list: linux-mips I have posted there: http://forum.routerboard.com/viewtopic.php?p=11942#11942 I'd like to stay in sync with linux-mips tree of git, but it gives me too much trouble. If somebody has some Linux+mips tree, I'd like to hear from it (when I try it, the .git just gets huge). From fxzhang@ict.ac.cn Thu Dec 22 00:45:44 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 22 Dec 2005 00:46:02 +0000 (GMT) Received: from webmail.ict.ac.cn ([159.226.39.7]:43721 "HELO ict.ac.cn") by ftp.linux-mips.org with SMTP id S3466995AbVLVApo (ORCPT ); Thu, 22 Dec 2005 00:45:44 +0000 Received: (qmail 18693 invoked by uid 507); 22 Dec 2005 00:22:01 -0000 Received: from unknown (HELO ?192.168.2.202?) (fxzhang@222.92.8.142) by ict.ac.cn with SMTP; 22 Dec 2005 00:22:01 -0000 Message-ID: <43A9F76A.4080305@ict.ac.cn> Date: Thu, 22 Dec 2005 08:46:34 +0800 From: Fuxin Zhang User-Agent: Thunderbird 1.5 (Windows/20051025) MIME-Version: 1.0 To: Srinivas Kommu CC: Linux/MIPS Development Subject: Re: Preempted interrupt handler References: <43A6F155.7080402@avilinks.com> <20051220131829.GB3376@linux-mips.org> <20051221193906.GB1456@sjc-xdm-007.cisco.com> In-Reply-To: <20051221193906.GB1456@sjc-xdm-007.cisco.com> X-Enigmail-Version: 0.93.0.0 Content-Type: text/plain; charset=ISO-8859-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: 9718 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: fxzhang@ict.ac.cn Precedence: bulk X-list: linux-mips > Is it normal for the modules to be loaded at 0xc0000000 (this is > highmem, isn't it)? I see the same on my bcm1250 box. I've been wondering > why they can't be loaded in kseg0. Or is it because of bad > modutils/compiler flags? It is not necessary highmem. 0xc0000000 is a MAPPED(i.e. use TLB) kernel segment, used by vmalloc to allocate a large virtually continous memory area for modules. Use kseg0 you have to get a large physically continuous area, and that is difficult unless you reserve some memory. > > thanks > srini > >> Ralf > From ralf@linux-mips.org Thu Dec 22 01:47:06 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 22 Dec 2005 01:47:22 +0000 (GMT) Received: from p549F5309.dip.t-dialin.net ([84.159.83.9]:40786 "EHLO mail.linux-mips.net") by ftp.linux-mips.org with ESMTP id S3466994AbVLVBrG (ORCPT ); Thu, 22 Dec 2005 01:47:06 +0000 Received: from fluff.linux-mips.net (localhost.localdomain [127.0.0.1]) by mail.linux-mips.net (8.13.4/8.13.1) with ESMTP id jBM1mG9g026011; Thu, 22 Dec 2005 02:48:16 +0100 Received: (from ralf@localhost) by fluff.linux-mips.net (8.13.4/8.13.4/Submit) id jBM1mAZS026009; Thu, 22 Dec 2005 02:48:10 +0100 Date: Thu, 22 Dec 2005 02:48:10 +0100 From: Ralf Baechle To: Maxime Bizon Cc: linux-mips@linux-mips.org Subject: Re: [PATCH] fix local_irq_save()/local_irq_restore() when CONFIG_CPU_MIPSR2 & CONFIG_IRQ_CPU Message-ID: <20051222014810.GC1918@linux-mips.org> References: <1135056739.9874.95.camel@sakura.staff.proxad.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1135056739.9874.95.camel@sakura.staff.proxad.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: 9719 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, Dec 20, 2005 at 06:32:19AM +0100, Maxime Bizon wrote: > > I was unable to get my R4KECr2 board working with CONFIG_CPU_MIPSR2 & > CONFIG_IRQ_CPU, irq delivery is not working. > > local_irq_restore() logic is to check that "flags" is non zero, and > enable irq accordingly. > > But "flags" comes directly from di, which according to mips instruction > set, saves whole status content, not just IE bit. There are less local_irq_save than local_irq_restore calls, so is the preferable place for the fix. Applied, Ralf From mbizon@freebox.fr Thu Dec 22 02:30:19 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 22 Dec 2005 02:30:37 +0000 (GMT) Received: from sakura.staff.proxad.net ([213.228.1.107]:31886 "EHLO sakura.staff.proxad.net") by ftp.linux-mips.org with ESMTP id S3466999AbVLVCaT (ORCPT ); Thu, 22 Dec 2005 02:30:19 +0000 Received: from max by sakura.staff.proxad.net with local (Exim 3.36 #1 (Debian)) id 1EpGEt-00027s-00; Thu, 22 Dec 2005 03:31:31 +0100 Subject: Re: Kernel freezes in r4k_flush_icache_range() with CONFIG_CPU_MIPS32_R2 From: Maxime Bizon To: "Maciej W. Rozycki" Cc: linux-mips@linux-mips.org In-Reply-To: References: <1135047438.9874.74.camel@sakura.staff.proxad.net> Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Thu, 22 Dec 2005 03:31:31 +0100 Message-Id: <1135218691.9874.186.camel@sakura.staff.proxad.net> Mime-Version: 1.0 X-Mailer: Evolution 2.4.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: 9720 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: mbizon@freebox.fr Precedence: bulk X-list: linux-mips On Tue, 2005-12-20 at 11:47 +0000, Maciej W. Rozycki wrote: > FYI, GCC 3.4.4 produces the following code which is clearly wrong: > Please file a bug report at: "http://gcc.gnu.org/bugzilla/". Same with 3.3 and 3.2... I'm really not familiar with inline assembly so I would appreciate that any gcc guru here confirm instruction_hazard() code is correct before I (or he) submit the bug report. As the bug seems to be in all gcc versions, I guess we should find a workaround... I changed the code to use an asm label instead of the C label and the bug disappeared. But I'm not sure my changes are correct for any platform other than mine... Could anyone with the right skills help me to write a valid workaround please ? Here is what I have: __asm__ __volatile__( "lui $2,1f\n" "addiu $2,1f\n" "jr.hb $2\n1:":: ); Thanks, -- Maxime From zzh.hust@gmail.com Thu Dec 22 02:42:19 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 22 Dec 2005 02:42:37 +0000 (GMT) Received: from wproxy.gmail.com ([64.233.184.196]:5067 "EHLO wproxy.gmail.com") by ftp.linux-mips.org with ESMTP id S3466994AbVLVCmT convert rfc822-to-8bit (ORCPT ); Thu, 22 Dec 2005 02:42:19 +0000 Received: by wproxy.gmail.com with SMTP id 36so272101wra for ; Wed, 21 Dec 2005 18:43:31 -0800 (PST) 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=opr6diJZblOxITZTQH6rcqXUZSC+3/7Txv3SXi89mNtvRP1QFP7TrOmLCyW473l0JhoYDSvK/DvF64c8K+LMuTARw9aoXVY56eh8p0ktejB0lBoVtIODn9tuT4jix/UoF3jtcKPjvV0CiKlgZQgxM9jVlueEWGjp26uH7HBXy7s= Received: by 10.54.105.16 with SMTP id d16mr1514877wrc; Wed, 21 Dec 2005 18:43:31 -0800 (PST) Received: by 10.54.156.5 with HTTP; Wed, 21 Dec 2005 18:43:31 -0800 (PST) Message-ID: <50c9a2250512211843o469601e4p557f4645dd721949@mail.gmail.com> Date: Thu, 22 Dec 2005 10:43:31 +0800 From: zhuzhenhua To: Matej Kupljen Subject: Re: does someone succeed in making the toolchain for 2.6 kernel? Cc: Jan-Benedict Glaw , linux-mips@linux-mips.org In-Reply-To: <1135161136.5211.8.camel@localhost.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT Content-Disposition: inline References: <50c9a2250512210051q85f813fx27b0533fe66165e2@mail.gmail.com> <20051221085539.GS13985@lug-owl.de> <50c9a2250512210104j4a19e37cu30c795d4acc226d2@mail.gmail.com> <20051221091852.GT13985@lug-owl.de> <1135159354.5211.1.camel@localhost.localdomain> <20051221100619.GW13985@lug-owl.de> <1135161136.5211.8.camel@localhost.localdomain> 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: 9721 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 12/21/05, Matej Kupljen wrote: > Hi > > > > Yes, we use crosstool, but the results matrix isn't rely > > > encouraging: > > > http://www.kegel.com/crosstool/crosstool-0.38/buildlogs/ > > > > Well, try do do it any better *yourself*. Compiling a complete > > toolchain (incl. userland support) really isn't easy... > > You probably misunderstood me :( > > I was trying to say, that we use crosstool *successfully* to build > kernel 2.6.15-rc5 (and a bunch of user land binaries) and that > this matrix should be updated. > > If someone looks at this matrix, he thinks that for mips(el) crosstool > does not work. > > BR, > Matej > > > i have use the crosstool to try,but i get a "#error "glibc cannot be compiled without optimization" what CFLAGS and CXXFLAGS should to set in demo-mipsel.sh BR, zhuzhenhua From yallain@avilinks.com Thu Dec 22 08:36:37 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 22 Dec 2005 08:36:55 +0000 (GMT) Received: from 252.237.98-84.rev.gaoland.net ([84.98.237.252]:58940 "EHLO serveurSMTP") by ftp.linux-mips.org with ESMTP id S8133516AbVLVIgh (ORCPT ); Thu, 22 Dec 2005 08:36:37 +0000 Received: from [192.168.150.1] by serveurSMTP (ArGoSoft Mail Server Freeware, Version 1.8 (1.8.8.2)); Thu, 22 Dec 2005 09:39:35 +0100 Message-ID: <43AA653B.6050207@avilinks.com> Date: Thu, 22 Dec 2005 09:35:07 +0100 From: Yoann Allain Organization: Avilinks User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: fr, en MIME-Version: 1.0 To: Fuxin Zhang CC: Srinivas Kommu , Linux/MIPS Development Subject: Re: Preempted interrupt handler References: <43A6F155.7080402@avilinks.com> <20051220131829.GB3376@linux-mips.org> <20051221193906.GB1456@sjc-xdm-007.cisco.com> <43A9F76A.4080305@ict.ac.cn> In-Reply-To: <43A9F76A.4080305@ict.ac.cn> Content-Type: text/plain; charset=ISO-8859-1; format=flowed 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: 9723 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: yallain@avilinks.com Precedence: bulk X-list: linux-mips Content-Length: 1202 Lines: 32 Fuxin Zhang a écrit : >>Is it normal for the modules to be loaded at 0xc0000000 (this is >>highmem, isn't it)? I see the same on my bcm1250 box. I've been wondering >>why they can't be loaded in kseg0. Or is it because of bad >>modutils/compiler flags? >> >> >It is not necessary highmem. 0xc0000000 is a MAPPED(i.e. use TLB) kernel >segment, >used by vmalloc to allocate a large virtually continous memory area for >modules. Use kseg0 you have to get a large physically continuous area, >and that is difficult unless you reserve some memory. > > I've just found in LDD 2nd version book (page 218), that on MIPS, addresses returned by vmalloc belong to a completely different address range from kmalloc addresses, whereas on x86 platforms they belong to the same. Concerning the clues given by Ralf, I've tried insmoding the module by a recent version of modutils instead of using the insmod brought with Busybox : the kernel behaved the same, it doesn't want to use the handler of my kernel. I've also checked that I was compiling with the mlong-calls flag... Therefore, I think I will compile my module into the kernel, until I found a solution to this problem... Thanks everyone! From jbglaw@lug-owl.de Thu Dec 22 08:56:27 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 22 Dec 2005 08:56:46 +0000 (GMT) Received: from lug-owl.de ([195.71.106.12]:34974 "EHLO lug-owl.de") by ftp.linux-mips.org with ESMTP id S8133516AbVLVI41 (ORCPT ); Thu, 22 Dec 2005 08:56:27 +0000 Received: by lug-owl.de (Postfix, from userid 1001) id F093EF0047; Thu, 22 Dec 2005 09:57:36 +0100 (CET) Date: Thu, 22 Dec 2005 09:57:36 +0100 From: Jan-Benedict Glaw To: zhuzhenhua Cc: Matej Kupljen , linux-mips@linux-mips.org Subject: Re: does someone succeed in making the toolchain for 2.6 kernel? Message-ID: <20051222085736.GD13985@lug-owl.de> Mail-Followup-To: zhuzhenhua , Matej Kupljen , linux-mips@linux-mips.org References: <50c9a2250512210051q85f813fx27b0533fe66165e2@mail.gmail.com> <20051221085539.GS13985@lug-owl.de> <50c9a2250512210104j4a19e37cu30c795d4acc226d2@mail.gmail.com> <20051221091852.GT13985@lug-owl.de> <1135159354.5211.1.camel@localhost.localdomain> <20051221100619.GW13985@lug-owl.de> <1135161136.5211.8.camel@localhost.localdomain> <50c9a2250512211843o469601e4p557f4645dd721949@mail.gmail.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="lUGOeNWztp/TKlGK" Content-Disposition: inline In-Reply-To: <50c9a2250512211843o469601e4p557f4645dd721949@mail.gmail.com> X-Operating-System: Linux mail 2.6.12.3lug-owl X-gpg-fingerprint: 250D 3BCF 7127 0D8C A444 A961 1DBD 5E75 8399 E1BB X-gpg-key: wwwkeys.de.pgp.net X-Echelon-Enable: howto poison arsenous mail psychological biological nuclear warfare test the bombastical terror of flooding the spy listeners explosion sex drugs and rock'n'roll X-TKUeV: howto poison arsenous mail psychological biological nuclear warfare test the bombastical terror of flooding the spy listeners explosion sex drugs and rock'n'roll 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: 9724 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: jbglaw@lug-owl.de Precedence: bulk X-list: linux-mips Content-Length: 1335 Lines: 44 --lUGOeNWztp/TKlGK Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, 2005-12-22 10:43:31 +0800, zhuzhenhua wrote: > On 12/21/05, Matej Kupljen wrote: > > > > Yes, we use crosstool, but the results matrix isn't rely > > > > encouraging: > > > > http://www.kegel.com/crosstool/crosstool-0.38/buildlogs/ >=20 > i have use the crosstool to try,but i get a > "#error "glibc cannot be compiled without optimization" > what CFLAGS and CXXFLAGS should to set in demo-mipsel.sh At least -O I guess, or -O2. MfG, JBG --=20 Jan-Benedict Glaw jbglaw@lug-owl.de . +49-172-7608481 = _ O _ "Eine Freie Meinung in einem Freien Kopf | Gegen Zensur | Gegen Krieg = _ _ O f=C3=BCr einen Freien Staat voll Freier B=C3=BCrger" | im Internet! | i= m Irak! O O O ret =3D do_actions((curr | FREE_SPEECH) & ~(NEW_COPYRIGHT_LAW | DRM | TCPA)= ); --lUGOeNWztp/TKlGK Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFDqmqAHb1edYOZ4bsRAt4fAJ9KOYR7/2H4kbVWJo077dlt5fVaPQCfdTQT 5cKoKa8Pm5eIfvJBPi3kq8c= =gfd8 -----END PGP SIGNATURE----- --lUGOeNWztp/TKlGK-- From zzh.hust@gmail.com Thu Dec 22 09:04:44 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 22 Dec 2005 09:05:03 +0000 (GMT) Received: from wproxy.gmail.com ([64.233.184.198]:45110 "EHLO wproxy.gmail.com") by ftp.linux-mips.org with ESMTP id S8133516AbVLVJEo (ORCPT ); Thu, 22 Dec 2005 09:04:44 +0000 Received: by wproxy.gmail.com with SMTP id 36so313712wra for ; Thu, 22 Dec 2005 01:05:58 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=jqvFDav9dXEY4J/fhtbFRKOEYigbTWOR6lN7gPzFJABnn1+8iB0AHl1BT9wSPuG7MGDdRhLbEe/Z8UCymWq0C2S9Wz4cZkQ0l+MTysMvWgbPZZMSfkK7hfv6z2soxlb75WohOm0H8FurpJjsf91s42nBTZBABAB3tLFXOGcXnds= Received: by 10.54.125.7 with SMTP id x7mr1825669wrc; Thu, 22 Dec 2005 01:05:58 -0800 (PST) Received: by 10.54.156.5 with HTTP; Thu, 22 Dec 2005 01:05:58 -0800 (PST) Message-ID: <50c9a2250512220105s190d7f72mde52616984f3fe88@mail.gmail.com> Date: Thu, 22 Dec 2005 17:05:58 +0800 From: zhuzhenhua To: zhuzhenhua , Matej Kupljen , linux-mips@linux-mips.org Subject: Re: does someone succeed in making the toolchain for 2.6 kernel? In-Reply-To: <20051222085736.GD13985@lug-owl.de> MIME-Version: 1.0 Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: base64 Content-Disposition: inline References: <50c9a2250512210051q85f813fx27b0533fe66165e2@mail.gmail.com> <20051221085539.GS13985@lug-owl.de> <50c9a2250512210104j4a19e37cu30c795d4acc226d2@mail.gmail.com> <20051221091852.GT13985@lug-owl.de> <1135159354.5211.1.camel@localhost.localdomain> <20051221100619.GW13985@lug-owl.de> <1135161136.5211.8.camel@localhost.localdomain> <50c9a2250512211843o469601e4p557f4645dd721949@mail.gmail.com> <20051222085736.GD13985@lug-owl.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: 9725 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 Content-Length: 1642 Lines: 22 T24gMTIvMjIvMDUsIEphbi1CZW5lZGljdCBHbGF3IDxqYmdsYXdAbHVnLW93bC5kZT4gd3JvdGU6 Cj4gT24gVGh1LCAyMDA1LTEyLTIyIDEwOjQzOjMxICswODAwLCB6aHV6aGVuaHVhIDx6emguaHVz dEBnbWFpbC5jb20+IHdyb3RlOgo+ID4gT24gMTIvMjEvMDUsIE1hdGVqIEt1cGxqZW4gPG1hdGVq Lmt1cGxqZW5AdWx0cmEuc2k+IHdyb3RlOgo+ID4gPiA+ID4gWWVzLCB3ZSB1c2UgY3Jvc3N0b29s LCBidXQgdGhlIHJlc3VsdHMgbWF0cml4IGlzbid0IHJlbHkKPiA+ID4gPiA+IGVuY291cmFnaW5n Ogo+ID4gPiA+ID4gaHR0cDovL3d3dy5rZWdlbC5jb20vY3Jvc3N0b29sL2Nyb3NzdG9vbC0wLjM4 L2J1aWxkbG9ncy8KPiA+Cj4gPiBpIGhhdmUgdXNlIHRoZSBjcm9zc3Rvb2wgdG8gdHJ5LGJ1dCBp IGdldCBhCj4gPiAiI2Vycm9yICJnbGliYyBjYW5ub3QgYmUgY29tcGlsZWQgd2l0aG91dCBvcHRp bWl6YXRpb24iCj4gPiB3aGF0IENGTEFHUyBhbmQgQ1hYRkxBR1Mgc2hvdWxkICB0byBzZXQgaW4g ZGVtby1taXBzZWwuc2gKPgo+IEF0IGxlYXN0IC1PIEkgZ3Vlc3MsIG9yIC1PMi4KCmluIHRoZSBt aXBzZWwuZGF0IGl0IGhhcyBkZWZpbmUgLU8yo6wKaSB0cnkgLU8gYW5kIC1PMixib3RoIGZhaWxl ZAoKPgo+IE1mRywgSkJHCj4KPiAtLQo+IEphbi1CZW5lZGljdCBHbGF3ICAgICAgIGpiZ2xhd0Bs dWctb3dsLmRlICAgIC4gKzQ5LTE3Mi03NjA4NDgxICAgICAgICAgICAgIF8gTyBfCj4gIkVpbmUg RnJlaWUgTWVpbnVuZyBpbiAgZWluZW0gRnJlaWVuIEtvcGYgICAgfCBHZWdlbiBaZW5zdXIgfCBH ZWdlbiBLcmllZyAgXyBfIE8KPiAgZqi5ciBlaW5lbiBGcmVpZW4gU3RhYXQgdm9sbCBGcmVpZXIg Qqi5cmdlciIgIHwgaW0gSW50ZXJuZXQhIHwgICBpbSBJcmFrISAgIE8gTyBPCj4gcmV0ID0gZG9f YWN0aW9ucygoY3VyciB8IEZSRUVfU1BFRUNIKSAmIH4oTkVXX0NPUFlSSUdIVF9MQVcgfCBEUk0g fCBUQ1BBKSk7Cj4KPgo+IC0tLS0tQkVHSU4gUEdQIFNJR05BVFVSRS0tLS0tCj4gVmVyc2lvbjog R251UEcgdjEuNC4xIChHTlUvTGludXgpCj4KPiBpRDhEQlFGRHFtcUFIYjFlZFlPWjRic1JBdDRm QUo5S09ZUjcvMkg0a2JWV0pvMDc3ZGx0NWZWYVBRQ2ZkVFFUCj4gNWNLb0thOFBtNWVJZnZKQlBp M2txOGM9Cj4gPWdmZDgKPiAtLS0tLUVORCBQR1AgU0lHTkFUVVJFLS0tLS0KPgo+Cj4KQmVzdCBy ZWdhcmRzCnpodXpoZW5odWEK From matej.kupljen@ultra.si Thu Dec 22 09:21:03 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 22 Dec 2005 09:21:20 +0000 (GMT) Received: from deliver-1.mx.triera.net ([213.161.0.31]:55506 "HELO deliver-1.mx.triera.net") by ftp.linux-mips.org with SMTP id S8133355AbVLVJVD (ORCPT ); Thu, 22 Dec 2005 09:21:03 +0000 Received: from localhost (in-2.mx.triera.net [213.161.0.26]) by deliver-1.mx.triera.net (Postfix) with ESMTP id B9FA8C06D; Thu, 22 Dec 2005 10:22:11 +0100 (CET) Received: from smtp.triera.net (smtp.triera.net [213.161.0.30]) by in-2.mx.triera.net (Postfix) with SMTP id C26011BC07B; Thu, 22 Dec 2005 10:22:13 +0100 (CET) Received: from [172.18.1.53] (unknown [213.161.20.162]) by smtp.triera.net (Postfix) with ESMTP id 080F71A18BA; Thu, 22 Dec 2005 10:22:14 +0100 (CET) Subject: Re: does someone succeed in making the toolchain for 2.6 kernel? From: Matej Kupljen To: zhuzhenhua Cc: Jan-Benedict Glaw , linux-mips@linux-mips.org In-Reply-To: <50c9a2250512211843o469601e4p557f4645dd721949@mail.gmail.com> References: <50c9a2250512210051q85f813fx27b0533fe66165e2@mail.gmail.com> <20051221085539.GS13985@lug-owl.de> <50c9a2250512210104j4a19e37cu30c795d4acc226d2@mail.gmail.com> <20051221091852.GT13985@lug-owl.de> <1135159354.5211.1.camel@localhost.localdomain> <20051221100619.GW13985@lug-owl.de> <1135161136.5211.8.camel@localhost.localdomain> <50c9a2250512211843o469601e4p557f4645dd721949@mail.gmail.com> Content-Type: text/plain Date: Thu, 22 Dec 2005 10:23:18 +0100 Message-Id: <1135243398.6902.3.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.2.3 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: 9726 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 Content-Length: 523 Lines: 22 Hi > i have use the crosstool to try,but i get a > "#error "glibc cannot be compiled without optimization" > what CFLAGS and CXXFLAGS should to set in demo-mipsel.sh If you mean mipsel.dat then I have this defined: KERNELCONFIG=`pwd`/mipsel.config TARGET=mipsel-linux TARGET_CFLAGS="-O2 -finline-limit=10000" GCC_EXTRA_CONFIG="--with-float=soft" GLIBC_EXTRA_CONFIG="--without-fp" BINUTILS_EXTRA_CONFIG="--enable-shared" Note, I have additional patches for "real SF". I have no flags set in demo-mipsel.sh BR, Matej From zzh.hust@gmail.com Thu Dec 22 09:29:28 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 22 Dec 2005 09:29:45 +0000 (GMT) Received: from wproxy.gmail.com ([64.233.184.205]:24291 "EHLO wproxy.gmail.com") by ftp.linux-mips.org with ESMTP id S8133355AbVLVJ32 convert rfc822-to-8bit (ORCPT ); Thu, 22 Dec 2005 09:29:28 +0000 Received: by wproxy.gmail.com with SMTP id 36so316900wra for ; Thu, 22 Dec 2005 01:30:42 -0800 (PST) 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=KfNpF71xEFPCNLOUR0da0xGeVJGeLplYU00sJupyepChtp+OH5PIEIpPnOoTltab/YFLhZEhjx4VaBR+tSB2S02rjQ2OKdkh9UPu3m+1hVfyAZckxDdoIgf62rrbeb5/u81h7KSoHnhAsplhqLkiR+yz5q+2OSOXdL3cypL6dn8= Received: by 10.54.156.18 with SMTP id d18mr1904021wre; Thu, 22 Dec 2005 01:30:42 -0800 (PST) Received: by 10.54.156.5 with HTTP; Thu, 22 Dec 2005 01:30:42 -0800 (PST) Message-ID: <50c9a2250512220130k6d4330acsc8cf4325771ba73c@mail.gmail.com> Date: Thu, 22 Dec 2005 17:30:42 +0800 From: zhuzhenhua To: Matej Kupljen Subject: Re: does someone succeed in making the toolchain for 2.6 kernel? Cc: Jan-Benedict Glaw , linux-mips@linux-mips.org In-Reply-To: <1135243398.6902.3.camel@localhost.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT Content-Disposition: inline References: <50c9a2250512210051q85f813fx27b0533fe66165e2@mail.gmail.com> <20051221085539.GS13985@lug-owl.de> <50c9a2250512210104j4a19e37cu30c795d4acc226d2@mail.gmail.com> <20051221091852.GT13985@lug-owl.de> <1135159354.5211.1.camel@localhost.localdomain> <20051221100619.GW13985@lug-owl.de> <1135161136.5211.8.camel@localhost.localdomain> <50c9a2250512211843o469601e4p557f4645dd721949@mail.gmail.com> <1135243398.6902.3.camel@localhost.localdomain> 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: 9727 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 Content-Length: 818 Lines: 33 On 12/22/05, Matej Kupljen wrote: > Hi > > > i have use the crosstool to try,but i get a > > "#error "glibc cannot be compiled without optimization" > > what CFLAGS and CXXFLAGS should to set in demo-mipsel.sh > > If you mean mipsel.dat then I have this defined: > > KERNELCONFIG=`pwd`/mipsel.config > TARGET=mipsel-linux > TARGET_CFLAGS="-O2 -finline-limit=10000" > GCC_EXTRA_CONFIG="--with-float=soft" > GLIBC_EXTRA_CONFIG="--without-fp" > BINUTILS_EXTRA_CONFIG="--enable-shared" > > Note, I have additional patches for "real SF". > > I have no flags set in demo-mipsel.sh > > BR, > Matej > > thanks, another question: do you change the demo-mipsel.sh to eval another sh or just keep the eval `cat mipsel.dat gcc-3.4.2-glibc-2.2.5.dat` sh all.sh --notest Best Regards zhuzhenhua From matej.kupljen@ultra.si Thu Dec 22 09:43:54 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 22 Dec 2005 09:44:11 +0000 (GMT) Received: from deliver-1.mx.triera.net ([213.161.0.31]:32214 "HELO deliver-1.mx.triera.net") by ftp.linux-mips.org with SMTP id S8133355AbVLVJny (ORCPT ); Thu, 22 Dec 2005 09:43:54 +0000 Received: from localhost (in-3.mx.triera.net [213.161.0.27]) by deliver-1.mx.triera.net (Postfix) with ESMTP id BAC88C064; Thu, 22 Dec 2005 10:45:03 +0100 (CET) Received: from smtp.triera.net (smtp.triera.net [213.161.0.30]) by in-3.mx.triera.net (Postfix) with SMTP id C3F221BC093; Thu, 22 Dec 2005 10:45:05 +0100 (CET) Received: from [172.18.1.53] (unknown [213.161.20.162]) by smtp.triera.net (Postfix) with ESMTP id 2C0C01A18AA; Thu, 22 Dec 2005 10:45:06 +0100 (CET) Subject: Re: does someone succeed in making the toolchain for 2.6 kernel? From: Matej Kupljen To: zhuzhenhua Cc: Jan-Benedict Glaw , linux-mips@linux-mips.org In-Reply-To: <50c9a2250512220130k6d4330acsc8cf4325771ba73c@mail.gmail.com> References: <50c9a2250512210051q85f813fx27b0533fe66165e2@mail.gmail.com> <20051221085539.GS13985@lug-owl.de> <50c9a2250512210104j4a19e37cu30c795d4acc226d2@mail.gmail.com> <20051221091852.GT13985@lug-owl.de> <1135159354.5211.1.camel@localhost.localdomain> <20051221100619.GW13985@lug-owl.de> <1135161136.5211.8.camel@localhost.localdomain> <50c9a2250512211843o469601e4p557f4645dd721949@mail.gmail.com> <1135243398.6902.3.camel@localhost.localdomain> <50c9a2250512220130k6d4330acsc8cf4325771ba73c@mail.gmail.com> Content-Type: text/plain Date: Thu, 22 Dec 2005 10:46:10 +0100 Message-Id: <1135244770.6902.5.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.2.3 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: 9728 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 Content-Length: 335 Lines: 14 Hi > another question: do you change the demo-mipsel.sh to eval another sh or just > keep the > eval `cat mipsel.dat gcc-3.4.2-glibc-2.2.5.dat` sh all.sh --notest eval `cat mipsel-sf.dat gcc-3.4.4-glibc-2.3.5-hdrs-2.6.11.2.dat` sh all.sh --notest (mipsel-sf.dat contains what I have written in a previous mail.) BR, Matej From lhrkernelcoder@gmail.com Thu Dec 22 09:50:01 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 22 Dec 2005 09:50:18 +0000 (GMT) Received: from wproxy.gmail.com ([64.233.184.200]:46668 "EHLO wproxy.gmail.com") by ftp.linux-mips.org with ESMTP id S8133355AbVLVJuB convert rfc822-to-8bit (ORCPT ); Thu, 22 Dec 2005 09:50:01 +0000 Received: by wproxy.gmail.com with SMTP id 36so319386wra for ; Thu, 22 Dec 2005 01:51:15 -0800 (PST) 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=ECfuB7OdgjBLugJzicMIb3e6qr3qiYoE5C7Nomst7b3belD442ueA4DktkqN6nnC1qwftT+5jaBngIsJUXBa6ZIpkNCXwJ3vzoovDYEFzX3gWxsyWYFhhe5NYEgTKfgjFHTCU/pNB6wnLp8lqiZ3c6p19pMQdFUh1qKYTlRScrQ= Received: by 10.54.135.7 with SMTP id i7mr1303636wrd; Thu, 22 Dec 2005 01:51:15 -0800 (PST) Received: by 10.54.147.20 with HTTP; Thu, 22 Dec 2005 01:51:15 -0800 (PST) Message-ID: Date: Thu, 22 Dec 2005 01:51:15 -0800 From: kernel coder To: linux-mips@linux-mips.org Subject: IDE subsystem MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT 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: 9729 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 Content-Length: 188 Lines: 7 hi, I was trying to figure out the control flow in IDE subsystem.I googled but could not get information. Please refer me some document about about linux IDE susbsytem lhrkernelcoder From ralf@linux-mips.org Thu Dec 22 09:57:32 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 22 Dec 2005 09:57:49 +0000 (GMT) Received: from p549F4E16.dip.t-dialin.net ([84.159.78.22]:41567 "EHLO mail.linux-mips.net") by ftp.linux-mips.org with ESMTP id S8133355AbVLVJ5c (ORCPT ); Thu, 22 Dec 2005 09:57:32 +0000 Received: from fluff.linux-mips.net (localhost.localdomain [127.0.0.1]) by mail.linux-mips.net (8.13.4/8.13.1) with ESMTP id jBM9whBU015607; Thu, 22 Dec 2005 10:58:43 +0100 Received: (from ralf@localhost) by fluff.linux-mips.net (8.13.4/8.13.4/Submit) id jBM9wcUF015605; Thu, 22 Dec 2005 10:58:38 +0100 Date: Thu, 22 Dec 2005 10:58:38 +0100 From: Ralf Baechle To: kernel coder Cc: linux-mips@linux-mips.org Subject: Re: IDE subsystem Message-ID: <20051222095838.GA21089@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: 9730 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 Content-Length: 337 Lines: 10 On Thu, Dec 22, 2005 at 01:51:15AM -0800, kernel coder wrote: > I was trying to figure out the control flow in IDE subsystem.I > googled but could not get information. > Please refer me some document about about linux IDE susbsytem Surprise - there is none. And your chances for an answer are better on the linux-ide list. Ralf From alan@lxorguk.ukuu.org.uk Thu Dec 22 10:39:40 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 22 Dec 2005 10:39:57 +0000 (GMT) Received: from clock-tower.bc.nu ([81.2.110.250]:1412 "EHLO lxorguk.ukuu.org.uk") by ftp.linux-mips.org with ESMTP id S8133551AbVLVKjk (ORCPT ); Thu, 22 Dec 2005 10:39:40 +0000 Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by lxorguk.ukuu.org.uk (8.13.4/8.13.4) with ESMTP id jBMAfxLm016326; Thu, 22 Dec 2005 10:41:59 GMT Received: (from alan@localhost) by localhost.localdomain (8.13.4/8.13.4/Submit) id jBMAfwhL016325; Thu, 22 Dec 2005 10:41:58 GMT X-Authentication-Warning: localhost.localdomain: alan set sender to alan@lxorguk.ukuu.org.uk using -f Subject: Re: IDE subsystem From: Alan Cox To: kernel coder Cc: linux-mips@linux-mips.org In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Thu, 22 Dec 2005 10:41:56 +0000 Message-Id: <1135248117.10383.25.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.2.3 (2.2.3-2.fc4) 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: 9731 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: alan@lxorguk.ukuu.org.uk Precedence: bulk X-list: linux-mips Content-Length: 312 Lines: 11 On Iau, 2005-12-22 at 01:51 -0800, kernel coder wrote: > hi, > > I was trying to figure out the control flow in IDE subsystem.I > googled but could not get information. > Please refer me some document about about linux IDE susbsytem There is no good documentation on the old drivers/ide layer code. Alan From ralf@linux-mips.org Thu Dec 22 11:09:10 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 22 Dec 2005 11:09:36 +0000 (GMT) Received: from p549F4E16.dip.t-dialin.net ([84.159.78.22]:10332 "EHLO mail.linux-mips.net") by ftp.linux-mips.org with ESMTP id S8133612AbVLVLJJ (ORCPT ); Thu, 22 Dec 2005 11:09:09 +0000 Received: from fluff.linux-mips.net (localhost.localdomain [127.0.0.1]) by mail.linux-mips.net (8.13.4/8.13.1) with ESMTP id jBMBANH9004290; Thu, 22 Dec 2005 12:10:23 +0100 Received: (from ralf@localhost) by fluff.linux-mips.net (8.13.4/8.13.4/Submit) id jBMBANWt004289; Thu, 22 Dec 2005 12:10:23 +0100 Date: Thu, 22 Dec 2005 12:10:23 +0100 From: Ralf Baechle To: Maxime Bizon Cc: "Maciej W. Rozycki" , linux-mips@linux-mips.org Subject: Re: Kernel freezes in r4k_flush_icache_range() with CONFIG_CPU_MIPS32_R2 Message-ID: <20051222111023.GD1918@linux-mips.org> References: <1135047438.9874.74.camel@sakura.staff.proxad.net> <1135218691.9874.186.camel@sakura.staff.proxad.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1135218691.9874.186.camel@sakura.staff.proxad.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: 9732 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 Content-Length: 1270 Lines: 37 On Thu, Dec 22, 2005 at 03:31:31AM +0100, Maxime Bizon wrote: > > FYI, GCC 3.4.4 produces the following code which is clearly wrong: > > > Please file a bug report at: "http://gcc.gnu.org/bugzilla/". > > Same with 3.3 and 3.2... > > I'm really not familiar with inline assembly so I would appreciate that > any gcc guru here confirm instruction_hazard() code is correct before I > (or he) submit the bug report. > > As the bug seems to be in all gcc versions, I guess we should find a > workaround... I changed the code to use an asm label instead of the C > label and the bug disappeared. But I'm not sure my changes are correct > for any platform other than mine... We ran into similar problems in the past. It only seems to be a matter of the code nearby and the exact options to trigger it. The alternative is manually loading the address using la / dla which defeats gcc's splitting of address loading. And having to use different code for 32-bit and 64-bit sucks. > Could anyone with the right skills help me to write a valid workaround > please ? > > Here is what I have: > > __asm__ __volatile__( > "lui $2,1f\n" > "addiu $2,1f\n" > "jr.hb $2\n1:":: ); Wrong, breaks 64-bit and uses $2 without telling gcc about it. Ralf From geoman@gentoo.org Thu Dec 22 13:28:29 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 22 Dec 2005 13:28:47 +0000 (GMT) Received: from lennier.cc.vt.edu ([198.82.162.213]:20932 "EHLO lennier.cc.vt.edu") by ftp.linux-mips.org with ESMTP id S8133736AbVLVN23 (ORCPT ); Thu, 22 Dec 2005 13:28:29 +0000 Received: from zidane.cc.vt.edu (IDENT:mirapoint@evil-zidane.cc.vt.edu [10.1.1.13]) by lennier.cc.vt.edu (8.12.11/8.12.11) with ESMTP id jBMDTcc3017239; Thu, 22 Dec 2005 08:29:38 -0500 Received: from [192.168.1.2] (blacksburg-bsr1-69-170-32-128.chvlva.adelphia.net [69.170.32.128]) by zidane.cc.vt.edu (MOS 3.6.4-CR) with ESMTP id ETL32796 (AUTH spbecker); Thu, 22 Dec 2005 08:29:36 -0500 (EST) Message-ID: <43AAAA3F.1090302@gentoo.org> Date: Thu, 22 Dec 2005 08:29:35 -0500 From: "Stephen P. Becker" User-Agent: Mozilla Thunderbird 1.0.7 (X11/20051204) X-Accept-Language: en-us, en MIME-Version: 1.0 To: zhuzhenhua CC: linux-mips@linux-mips.org Subject: Re: does someone succeed in making the toolchain for 2.6 kernel? References: <50c9a2250512210051q85f813fx27b0533fe66165e2@mail.gmail.com> <20051221085539.GS13985@lug-owl.de> <50c9a2250512210104j4a19e37cu30c795d4acc226d2@mail.gmail.com> <20051221091852.GT13985@lug-owl.de> <1135159354.5211.1.camel@localhost.localdomain> <20051221100619.GW13985@lug-owl.de> <1135161136.5211.8.camel@localhost.localdomain> <50c9a2250512211843o469601e4p557f4645dd721949@mail.gmail.com> In-Reply-To: <50c9a2250512211843o469601e4p557f4645dd721949@mail.gmail.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: 9733 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: geoman@gentoo.org Precedence: bulk X-list: linux-mips Content-Length: 451 Lines: 14 > i have use the crosstool to try,but i get a > "#error "glibc cannot be compiled without optimization" > what CFLAGS and CXXFLAGS should to set in demo-mipsel.sh > > BR, > zhuzhenhua Do you only want to build kernels, or do you want to build userland stuff also? You have indicated the former, but not the latter, in which case you really only need binutils and gcc (a static, C-only bootstrap gcc works fine for compiling a kernel). -Steve From zzh.hust@gmail.com Fri Dec 23 04:44:52 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 23 Dec 2005 04:45:10 +0000 (GMT) Received: from wproxy.gmail.com ([64.233.184.192]:1590 "EHLO wproxy.gmail.com") by ftp.linux-mips.org with ESMTP id S8133364AbVLWEow (ORCPT ); Fri, 23 Dec 2005 04:44:52 +0000 Received: by wproxy.gmail.com with SMTP id 36so512537wra for ; Thu, 22 Dec 2005 20:46:10 -0800 (PST) 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=MmtrseeskV1y1rjQ8du9qf7+993dbTFNPA4Et4ywho7W1nUuk4lTMCJ3VKS+KMx1PFoDz4CXkPedveBUItko32L8mz/mxkgjOQccC6HHY8q8LkvDvgg1j76gUGqffbYa58MNJ+ZVGXk62INaDjGMRxziSHRjfkY1YKGnCFVViT8= Received: by 10.54.133.9 with SMTP id g9mr2958455wrd; Thu, 22 Dec 2005 20:46:10 -0800 (PST) Received: by 10.54.156.5 with HTTP; Thu, 22 Dec 2005 20:46:10 -0800 (PST) Message-ID: <50c9a2250512222046i4bdc0bc1y2d5f04e4852f6624@mail.gmail.com> Date: Fri, 23 Dec 2005 12:46:10 +0800 From: zhuzhenhua To: "Stephen P. Becker" Subject: Re: does someone succeed in making the toolchain for 2.6 kernel? Cc: linux-mips@linux-mips.org In-Reply-To: <43AAAA3F.1090302@gentoo.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <50c9a2250512210051q85f813fx27b0533fe66165e2@mail.gmail.com> <20051221085539.GS13985@lug-owl.de> <50c9a2250512210104j4a19e37cu30c795d4acc226d2@mail.gmail.com> <20051221091852.GT13985@lug-owl.de> <1135159354.5211.1.camel@localhost.localdomain> <20051221100619.GW13985@lug-owl.de> <1135161136.5211.8.camel@localhost.localdomain> <50c9a2250512211843o469601e4p557f4645dd721949@mail.gmail.com> <43AAAA3F.1090302@gentoo.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: 9734 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 Content-Length: 745 Lines: 25 On 12/22/05, Stephen P. Becker wrote: > > i have use the crosstool to try,but i get a > > "#error "glibc cannot be compiled without optimization" > > what CFLAGS and CXXFLAGS should to set in demo-mipsel.sh > > > > BR, > > zhuzhenhua > > > Do you only want to build kernels, or do you want to build userland > stuff also? You have indicated the former, but not the latter, in which > case you really only need binutils and gcc (a static, C-only bootstrap > gcc works fine for compiling a kernel). > > -Steve > sorry to not discribe clearly, i want to build the toolchain both for kernel nand userland stuff. and i succeed now using the crosstool with Matej Kupljen's advices. thanks all$B!*(B best regards zhuzhenhua From pf@net.alphadv.de Fri Dec 23 23:09:11 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 23 Dec 2005 23:09:31 +0000 (GMT) Received: from mail.alphastar.de ([194.59.236.179]:36370 "EHLO mail.alphastar.de") by ftp.linux-mips.org with ESMTP id S8133455AbVLWXJL (ORCPT ); Fri, 23 Dec 2005 23:09:11 +0000 Received: by mail.alphastar.de with MERCUR Mailserver (v4.02.28 MTIxLTIxODAtNjY2OA==) for ; Sat, 24 Dec 2005 00:07:14 +0100 Received: from Indigo2.Peter (Indigo2.Peter [192.168.1.28]) by SNaIlmail.Peter (8.12.6/8.12.6/Sendmail/Linux 2.0.32) with ESMTP id jBNMC8Im000156 for ; Fri, 23 Dec 2005 23:12:09 +0100 Received: from Indigo2.Peter (localhost [127.0.0.1]) by Indigo2.Peter (8.12.6/8.12.6/Sendmail/Linux 2.6.11-rc3-ip28) with ESMTP id jBNLgHZn000393 for ; Fri, 23 Dec 2005 22:42:17 +0100 Received: from localhost (pf@localhost) by Indigo2.Peter (8.12.6/8.12.6/Submit) with ESMTP id jBNLgHkC000390 for ; Fri, 23 Dec 2005 22:42:17 +0100 Date: Fri, 23 Dec 2005 22:42:17 +0100 (CET) From: peter fuerst To: linux-mips@linux-mips.org Subject: IP28 patches In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Reply-To: pf@net.alphadv.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: 9735 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: pf@net.alphadv.de Precedence: bulk X-list: linux-mips Content-Length: 324 Lines: 14 Hi, after some time of trial and error there's an updated version of the Impact kernel-driver for IP28. Changes in DMA-setup allow a reliable Xserver startup now. (For at least two weeks of daily use X didn't hang in the "dmabusy"-loop anymore). These kernel-patches can be found in the usual place. kind regards pf From hvr@gnu.org Sat Dec 24 11:51:30 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 24 Dec 2005 11:51:48 +0000 (GMT) Received: from h081217049130.dyn.cm.kabsi.at ([81.217.49.130]:21926 "EHLO phobos.hvrlab.org") by ftp.linux-mips.org with ESMTP id S8133369AbVLXLva (ORCPT ); Sat, 24 Dec 2005 11:51:30 +0000 Received: from mini.intra (mini.intra [10.49.1.11]) (authenticated bits=0) by phobos.hvrlab.org (8.13.4/8.13.4/Debian-3) with ESMTP id jBOBqh9Z021904 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Sat, 24 Dec 2005 12:52:54 +0100 Subject: Re: USB on AU1550 From: Herbert Valerio Riedel To: Jay Monkman Cc: linux-mips@linux-mips.org In-Reply-To: <433B0299.8080507@smoothsmoothie.com> References: <433B0299.8080507@smoothsmoothie.com> Content-Type: text/plain Organization: Free Software Foundation Date: Sat, 24 Dec 2005 12:52:42 +0100 Message-Id: <1135425163.13029.13.camel@mini.intra> Mime-Version: 1.0 X-Mailer: Evolution 2.4.1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.84/1216/Sat Dec 24 11:08:45 2005 on phobos.hvrlab.org X-Virus-Status: Clean 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: 9736 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 Content-Length: 1862 Lines: 62 hello, On Wed, 2005-09-28 at 15:52 -0500, Jay Monkman wrote: > I'm trying to get USB working on my AU1550 board, and I'm getting an error I > don't understand. I've searched the web and the mailing list archives, but > haven't found anything relevant. there was a post of mine, dating back to 22 Nov 2004 which could have been relevant to your cause :-) > > I'm using 2.6.12, in big-endian mode. [..] > Can anyone point me in the right direction to get this working? don't know whether you still require being pointed in to any direction; however, the following patch (against current GIT HEAD, works for me, YMMV :-) might provide a hint: diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig index ed1899d..914b964 100644 --- a/drivers/usb/host/Kconfig +++ b/drivers/usb/host/Kconfig @@ -100,12 +100,14 @@ config USB_OHCI_HCD_PCI config USB_OHCI_BIG_ENDIAN bool depends on USB_OHCI_HCD + default y if SOC_AU1X00 && CPU_BIG_ENDIAN default n config USB_OHCI_LITTLE_ENDIAN bool depends on USB_OHCI_HCD default n if STB03xxx || PPC_MPC52xx + default n if SOC_AU1X00 && CPU_BIG_ENDIAN default y config USB_UHCI_HCD diff --git a/drivers/usb/host/ohci.h b/drivers/usb/host/ohci.h index caacf14..bf18351 100644 --- a/drivers/usb/host/ohci.h +++ b/drivers/usb/host/ohci.h @@ -462,6 +462,11 @@ static inline struct usb_hcd *ohci_to_hc #define writel_be(val, addr) out_be32((__force unsigned *)addr, val) #endif +#if defined(CONFIG_SOC_AU1X00) +#define readl_be(addr) __raw_readl((__force u32 *)(addr)) +#define writel_be(val, addr) __raw_writel(val, (__force u32 *)(addr)) +#endif + static inline unsigned int ohci_readl (const struct ohci_hcd *ohci, __hc32 __iomem * regs) { greetings, -- Herbert Valerio Riedel GnuPG Key Fingerprint: 7BB9 2D6C D485 CE64 4748 5F65 4981 E064 883F 4142 From sshtylyov@ru.mvista.com Mon Dec 26 22:20:54 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 26 Dec 2005 22:21:11 +0000 (GMT) Received: from rtsoft2.corbina.net ([85.21.88.2]:27322 "HELO mail.dev.rtsoft.ru") by ftp.linux-mips.org with SMTP id S8133530AbVLZWUx (ORCPT ); Mon, 26 Dec 2005 22:20:53 +0000 Received: (qmail 10330 invoked from network); 26 Dec 2005 22: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; 26 Dec 2005 22:22:29 -0000 Message-ID: <43B06DB4.409@ru.mvista.com> Date: Tue, 27 Dec 2005 01:24:52 +0300 From: Sergei Shtylylov Organization: MostaVista 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: rmk+serial@arm.linux.org.uk CC: linux-mips@linux-mips.org, anemo@mba.ocn.ne.jp Subject: [PATCH] serial_txx9: forcibly init the spinlock for PCI UART used as a console Content-Type: multipart/mixed; boundary="------------060002020409050600060303" 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: 9737 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 Content-Length: 1780 Lines: 54 This is a multi-part message in MIME format. --------------060002020409050600060303 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hello. When a system console gets assigned to the UART located on the Toshiba GOKU-S PCI card, the port spinlock is not initialized at all -- uart_add_one_port() thinks it's been initialized by the console setup code which is called too early for being able to do that, before the PCI card is even detected by the driver, and therefore fails. That unitialized spinlock causes 3 BUG messages in the boot log with Ingo Molnar's RT preemption patch as uart_add_one_port() called to register PCI UART with the serial core calls uart_configure_port() which makes use of the port spinlock. WBR, Sergei Signed-off-by: Sergei Shtylyov --------------060002020409050600060303 Content-Type: text/plain; name="GOKU-console-spinlock-fix.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="GOKU-console-spinlock-fix.patch" diff --git a/drivers/serial/serial_txx9.c b/drivers/serial/serial_txx9.c index f10c86d..3f8dc41 100644 --- a/drivers/serial/serial_txx9.c +++ b/drivers/serial/serial_txx9.c @@ -1065,6 +1065,14 @@ static int __devinit serial_txx9_registe uart->port.mapbase = port->mapbase; if (port->dev) uart->port.dev = port->dev; + + /* + * If this port is a console, its spinlock couldn't have been + * initialized by serial_txx9_console_setup() and it won't be + * initialized by uart_add_one_port(), so have to do it here... + */ + spin_lock_init(&uart->port.lock); + ret = uart_add_one_port(&serial_txx9_reg, &uart->port); if (ret == 0) ret = uart->port.line; --------------060002020409050600060303-- From anemo@mba.ocn.ne.jp Tue Dec 27 05:44:15 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 27 Dec 2005 05:44:35 +0000 (GMT) Received: from topsns.toshiba-tops.co.jp ([202.230.225.5]:13333 "HELO topsns.toshiba-tops.co.jp") by ftp.linux-mips.org with SMTP id S8126497AbVL0FoP (ORCPT ); Tue, 27 Dec 2005 05:44:15 +0000 Received: from inside-ms1.toshiba-tops.co.jp by topsns.toshiba-tops.co.jp via smtpd (for mail.linux-mips.org [62.254.210.162]) with SMTP; 27 Dec 2005 05:45:56 UT Received: from topsms.toshiba-tops.co.jp (localhost.localdomain [127.0.0.1]) by localhost.toshiba-tops.co.jp (Postfix) with ESMTP id 1E67A201C3; Tue, 27 Dec 2005 14:45:53 +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 0B6EE1D6D8; Tue, 27 Dec 2005 14:45:53 +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 jBR5jp4D041321; Tue, 27 Dec 2005 14:45:52 +0900 (JST) (envelope-from anemo@mba.ocn.ne.jp) Date: Tue, 27 Dec 2005 14:45:51 +0900 (JST) Message-Id: <20051227.144551.79070832.nemoto@toshiba-tops.co.jp> To: sshtylyov@ru.mvista.com Cc: rmk+serial@arm.linux.org.uk, linux-mips@linux-mips.org, ralf@linux-mips.org Subject: Re: [PATCH] serial_txx9: forcibly init the spinlock for PCI UART used as a console From: Atsushi Nemoto In-Reply-To: <43B06DB4.409@ru.mvista.com> References: <43B06DB4.409@ru.mvista.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.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: 9738 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 Content-Length: 7556 Lines: 228 >>>>> On Tue, 27 Dec 2005 01:24:52 +0300, Sergei Shtylylov said: sshtylyov> When a system console gets assigned to the UART sshtylyov> located on the Toshiba GOKU-S PCI card, the port spinlock sshtylyov> is not initialized at all -- uart_add_one_port() thinks sshtylyov> it's been initialized by the console setup code which is sshtylyov> called too early for being able to do that, before the PCI sshtylyov> card is even detected by the driver, and therefore sshtylyov> fails. The problem is not just only spin_lock_init. The parameters of "console=" option (baudrate, etc.) are not passed for PCI UART. Also, if console setup failed, the console never enabled. So the console can not be used anyway. I have an another fix. Call register_console() again for PCI UART if the console was not enabled. This fixes spin_lock_init issue and makes PCI UART really usable as console. Also, I have some other pending changes for this driver. * More strict check in verify_port. Cleanup. * Do not insert a char caused previous overrun. * Fix some spin_locks. * Call register_console again for PCI ports. This is a patch against linux-mips GIT. Signed-off-by: Atsushi Nemoto diff --git a/drivers/serial/serial_txx9.c b/drivers/serial/serial_txx9.c index f10c86d..c24e0c3 100644 --- a/drivers/serial/serial_txx9.c +++ b/drivers/serial/serial_txx9.c @@ -33,6 +33,10 @@ * 1.02 Cleanup. (import 8250.c changes) * 1.03 Fix low-latency mode. (import 8250.c changes) * 1.04 Remove usage of deprecated functions, cleanup. + * 1.05 More strict check in verify_port. Cleanup. + * 1.06 Do not insert a char caused previous overrun. + * Fix some spin_locks. + * Call register_console again for PCI ports. */ #include @@ -56,7 +60,7 @@ #include #include -static char *serial_version = "1.04"; +static char *serial_version = "1.06"; static char *serial_name = "TX39/49 Serial driver"; #define PASS_LIMIT 256 @@ -209,7 +213,7 @@ static inline unsigned int sio_in(struct { switch (up->port.iotype) { default: - return *(volatile u32 *)(up->port.membase + offset); + return __raw_readl(up->port.membase + offset); case UPIO_PORT: return inl(up->port.iobase + offset); } @@ -220,7 +224,7 @@ sio_out(struct uart_txx9_port *up, int o { switch (up->port.iotype) { default: - *(volatile u32 *)(up->port.membase + offset) = value; + __raw_writel(value, up->port.membase + offset); break; case UPIO_PORT: outl(value, up->port.iobase + offset); @@ -258,34 +262,19 @@ sio_quot_set(struct uart_txx9_port *up, static void serial_txx9_stop_tx(struct uart_port *port) { struct uart_txx9_port *up = (struct uart_txx9_port *)port; - unsigned long flags; - - spin_lock_irqsave(&up->port.lock, flags); sio_mask(up, TXX9_SIDICR, TXX9_SIDICR_TIE); - spin_unlock_irqrestore(&up->port.lock, flags); } static void serial_txx9_start_tx(struct uart_port *port) { struct uart_txx9_port *up = (struct uart_txx9_port *)port; - unsigned long flags; - - spin_lock_irqsave(&up->port.lock, flags); sio_set(up, TXX9_SIDICR, TXX9_SIDICR_TIE); - spin_unlock_irqrestore(&up->port.lock, flags); } static void serial_txx9_stop_rx(struct uart_port *port) { struct uart_txx9_port *up = (struct uart_txx9_port *)port; - unsigned long flags; - - spin_lock_irqsave(&up->port.lock, flags); up->port.read_status_mask &= ~TXX9_SIDISR_RDIS; -#if 0 - sio_mask(up, TXX9_SIDICR, TXX9_SIDICR_RIE); -#endif - spin_unlock_irqrestore(&up->port.lock, flags); } static void serial_txx9_enable_ms(struct uart_port *port) @@ -301,6 +290,7 @@ receive_chars(struct uart_txx9_port *up, unsigned int disr = *status; int max_count = 256; char flag; + unsigned int next_ignore_status_mask; do { /* The following is not allowed by the tty layer and @@ -318,6 +308,9 @@ receive_chars(struct uart_txx9_port *up, flag = TTY_NORMAL; up->port.icount.rx++; + /* mask out RFDN_MASK bit added by previous overrun */ + next_ignore_status_mask = + up->port.ignore_status_mask & ~TXX9_SIDISR_RFDN_MASK; if (unlikely(disr & (TXX9_SIDISR_UBRK | TXX9_SIDISR_UPER | TXX9_SIDISR_UFER | TXX9_SIDISR_UOER))) { /* @@ -338,8 +331,17 @@ receive_chars(struct uart_txx9_port *up, up->port.icount.parity++; else if (disr & TXX9_SIDISR_UFER) up->port.icount.frame++; - if (disr & TXX9_SIDISR_UOER) + if (disr & TXX9_SIDISR_UOER) { up->port.icount.overrun++; + /* + * The receiver read buffer still hold + * a char which caused overrun. + * Ignore next char by adding RFDN_MASK + * to ignore_status_mask temporarily. + */ + next_ignore_status_mask |= + TXX9_SIDISR_RFDN_MASK; + } /* * Mask off conditions which should be ingored. @@ -359,6 +361,7 @@ receive_chars(struct uart_txx9_port *up, uart_insert_char(&up->port, disr, TXX9_SIDISR_UOER, ch, flag); ignore_char: + up->port.ignore_status_mask = next_ignore_status_mask; disr = sio_in(up, TXX9_SIDISR); } while (!(disr & TXX9_SIDISR_UVALID) && (max_count-- > 0)); spin_unlock(&up->port.lock); @@ -460,14 +463,11 @@ static unsigned int serial_txx9_get_mctr static void serial_txx9_set_mctrl(struct uart_port *port, unsigned int mctrl) { struct uart_txx9_port *up = (struct uart_txx9_port *)port; - unsigned long flags; - spin_lock_irqsave(&up->port.lock, flags); if (mctrl & TIOCM_RTS) sio_mask(up, TXX9_SIFLCR, TXX9_SIFLCR_RTSSC); else sio_set(up, TXX9_SIFLCR, TXX9_SIFLCR_RTSSC); - spin_unlock_irqrestore(&up->port.lock, flags); } static void serial_txx9_break_ctl(struct uart_port *port, int break_state) @@ -794,8 +794,13 @@ static void serial_txx9_config_port(stru static int serial_txx9_verify_port(struct uart_port *port, struct serial_struct *ser) { - if (ser->irq < 0 || - ser->baud_base < 9600 || ser->type != PORT_TXX9) + unsigned long new_port = (unsigned long)ser->port + + ((unsigned long)ser->port_high << ((sizeof(long) - sizeof(int)) * 8)); + if (ser->type != port->type || + ser->irq != port->irq || + ser->io_type != port->iotype || + new_port != port->iobase || + (unsigned long)ser->iomem_base != port->mapbase) return -EINVAL; return 0; } @@ -937,11 +942,6 @@ static int serial_txx9_console_setup(str return -ENODEV; /* - * Temporary fix. - */ - spin_lock_init(&port->lock); - - /* * Disable UART interrupts, set DTR and RTS high * and set speed. */ @@ -1065,6 +1065,14 @@ static int __devinit serial_txx9_registe uart->port.mapbase = port->mapbase; if (port->dev) uart->port.dev = port->dev; +#ifdef CONFIG_SERIAL_TXX9_CONSOLE + /* + * The 'early' register_console fails for PCI ports. + * Do it again. + */ + if (!(serial_txx9_console.flags & CON_ENABLED)) + register_console(&serial_txx9_console); +#endif ret = uart_add_one_port(&serial_txx9_reg, &uart->port); if (ret == 0) ret = uart->port.line; @@ -1090,7 +1098,7 @@ static void __devexit serial_txx9_unregi uart->port.type = PORT_UNKNOWN; uart->port.iobase = 0; uart->port.mapbase = 0; - uart->port.membase = 0; + uart->port.membase = NULL; uart->port.dev = NULL; uart_add_one_port(&serial_txx9_reg, &uart->port); up(&serial_txx9_sem); @@ -1195,7 +1203,7 @@ static int __init serial_txx9_init(void) serial_txx9_register_ports(&serial_txx9_reg); #ifdef ENABLE_SERIAL_TXX9_PCI - ret = pci_module_init(&serial_txx9_pci_driver); + ret = pci_register_driver(&serial_txx9_pci_driver); #endif } return ret; From zzh.hust@gmail.com Tue Dec 27 06:31:30 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 27 Dec 2005 06:31:59 +0000 (GMT) Received: from wproxy.gmail.com ([64.233.184.192]:33314 "EHLO wproxy.gmail.com") by ftp.linux-mips.org with ESMTP id S8126497AbVL0Gb3 convert rfc822-to-8bit (ORCPT ); Tue, 27 Dec 2005 06:31:29 +0000 Received: by wproxy.gmail.com with SMTP id 36so1109481wra for ; Mon, 26 Dec 2005 22:33:11 -0800 (PST) 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=b60SN/7ZjQYzaL22EErV/fCwVDij0fCThNNMpM85HgN9w7E1NGJr2XimW3QPsDV/6D+iNX26nL4khhvUZO1dRsOEPN9CxIyymWutvTZT2PedoA7EVgYymrlDiPr6XLJBm44D+qNZwntqPQNtArgit8ratIXoAr75I9eZOtcNehA= Received: by 10.54.157.19 with SMTP id f19mr2518185wre; Mon, 26 Dec 2005 22:33:11 -0800 (PST) Received: by 10.54.156.5 with HTTP; Mon, 26 Dec 2005 22:33:11 -0800 (PST) Message-ID: <50c9a2250512262233n651294acicd1da8ed677472f1@mail.gmail.com> Date: Tue, 27 Dec 2005 14:33:11 +0800 From: zhuzhenhua To: linux-mips@linux-mips.org Subject: implicit declaration of function `BUILD_BUG' MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT 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: 9739 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 Content-Length: 317 Lines: 15 when i compile the linux-2.6.14, i have too many warning as follow: implicit declaration of function `BUILD_BUG' include/asm/io.h:399: warning: implicit declaration of function `BUILD_BUG' i have checked the io.h:399, but i can not find something wrong can someone tell me why? thanks! Best regards zhuzhenhua From sshtylyov@ru.mvista.com Tue Dec 27 13:35:03 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 27 Dec 2005 13:35:21 +0000 (GMT) Received: from rtsoft2.corbina.net ([85.21.88.2]:49338 "HELO mail.dev.rtsoft.ru") by ftp.linux-mips.org with SMTP id S8133529AbVL0NfD (ORCPT ); Tue, 27 Dec 2005 13:35:03 +0000 Received: (qmail 17108 invoked from network); 27 Dec 2005 13:36:32 -0000 Received: from wasted.dev.rtsoft.ru (HELO ?192.168.1.248?) (192.168.1.248) by mail.dev.rtsoft.ru with SMTP; 27 Dec 2005 13:36:32 -0000 Message-ID: <43B143EE.6070700@ru.mvista.com> Date: Tue, 27 Dec 2005 16:38:54 +0300 From: Sergei Shtylylov Organization: MostaVista 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: Atsushi Nemoto CC: rmk+serial@arm.linux.org.uk, linux-mips@linux-mips.org, ralf@linux-mips.org Subject: Re: [PATCH] serial_txx9: forcibly init the spinlock for PCI UART used as a console References: <43B06DB4.409@ru.mvista.com> <20051227.144551.79070832.nemoto@toshiba-tops.co.jp> In-Reply-To: <20051227.144551.79070832.nemoto@toshiba-tops.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: 9740 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 Content-Length: 3018 Lines: 91 Hello. Atsushi Nemoto wrote: >>>>>>On Tue, 27 Dec 2005 01:24:52 +0300, Sergei Shtylylov said: > > sshtylyov> When a system console gets assigned to the UART > sshtylyov> located on the Toshiba GOKU-S PCI card, the port spinlock > sshtylyov> is not initialized at all -- uart_add_one_port() thinks > sshtylyov> it's been initialized by the console setup code which is > sshtylyov> called too early for being able to do that, before the PCI > sshtylyov> card is even detected by the driver, and therefore > sshtylyov> fails. > The problem is not just only spin_lock_init. The parameters of > "console=" option (baudrate, etc.) are not passed for PCI UART. They are -- uart_add_one_port() calls console setup once more when registering PCI UART with serial code. > Also, > if console setup failed, the console never enabled. So the console > can not be used anyway. I'm able to use it with ths fix in 2.6.10 with 1.04 driver version backported. > I have an another fix. Call register_console() again for PCI UART if > the console was not enabled. I disagree. Look at what uart_add_one_port() does closely. > This fixes spin_lock_init issue and > makes PCI UART really usable as console. > Also, I have some other pending changes for this driver. > > * More strict check in verify_port. Cleanup. > * Do not insert a char caused previous overrun. > * Fix some spin_locks. Yeah, I was about to send the patch that deasl with the nested spinlocks as well... :-) > * Call register_console again for PCI ports. This change doesn't look correct to me... > This is a patch against linux-mips GIT. > Signed-off-by: Atsushi Nemoto > > > diff --git a/drivers/serial/serial_txx9.c b/drivers/serial/serial_txx9.c > index f10c86d..c24e0c3 100644 > --- a/drivers/serial/serial_txx9.c > +++ b/drivers/serial/serial_txx9.c > @@ -937,11 +942,6 @@ static int serial_txx9_console_setup(str > return -ENODEV; > > /* > - * Temporary fix. > - */ > - spin_lock_init(&port->lock); > - > - /* > * Disable UART interrupts, set DTR and RTS high > * and set speed. > */ Can you tell me, how this is supposed to work with TX49xx SOC UARTs? When that spinlock will be init'ed for the console port? uart_add_one_port() won't do it, and your added code below won't do it either, so I disagree with this change (though with "empty" spinlock it will no doubt work) since there's nothing to init. > @@ -1065,6 +1065,14 @@ static int __devinit serial_txx9_registe > uart->port.mapbase = port->mapbase; > if (port->dev) > uart->port.dev = port->dev; > +#ifdef CONFIG_SERIAL_TXX9_CONSOLE > + /* > + * The 'early' register_console fails for PCI ports. > + * Do it again. > + */ > + if (!(serial_txx9_console.flags & CON_ENABLED)) > + register_console(&serial_txx9_console); > +#endif > ret = uart_add_one_port(&serial_txx9_reg, &uart->port); > if (ret == 0) > ret = uart->port.line; WBR, Sergei From anemo@mba.ocn.ne.jp Tue Dec 27 15:33:55 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 27 Dec 2005 15:34:15 +0000 (GMT) Received: from mba.ocn.ne.jp ([210.190.142.172]:37315 "HELO smtp.mba.ocn.ne.jp") by ftp.linux-mips.org with SMTP id S8133538AbVL0Pdy (ORCPT ); Tue, 27 Dec 2005 15:33:54 +0000 Received: from localhost (p8078-ipad25funabasi.chiba.ocn.ne.jp [220.104.86.78]) by smtp.mba.ocn.ne.jp (Postfix) with ESMTP id A774F9B88; Wed, 28 Dec 2005 00:35:36 +0900 (JST) Date: Wed, 28 Dec 2005 00:34:57 +0900 (JST) Message-Id: <20051228.003457.74752441.anemo@mba.ocn.ne.jp> To: sshtylyov@ru.mvista.com Cc: rmk+serial@arm.linux.org.uk, linux-mips@linux-mips.org, ralf@linux-mips.org Subject: Re: [PATCH] serial_txx9: forcibly init the spinlock for PCI UART used as a console From: Atsushi Nemoto In-Reply-To: <43B143EE.6070700@ru.mvista.com> References: <43B06DB4.409@ru.mvista.com> <20051227.144551.79070832.nemoto@toshiba-tops.co.jp> <43B143EE.6070700@ru.mvista.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: 9741 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 Content-Length: 7774 Lines: 243 Thanks for your comment. >>>>> On Tue, 27 Dec 2005 16:38:54 +0300, Sergei Shtylylov said: >> The problem is not just only spin_lock_init. The parameters of >> "console=" option (baudrate, etc.) are not passed for PCI UART. sshtylyov> They are -- uart_add_one_port() calls console setup sshtylyov> once more when registering PCI UART with serial code. Yes, you are right. I missed the register_console call in uart_add_one_port(). So your patch will fix the problem. But I suppose the spinlock should be initialized in serial_core. How about this? --- a/drivers/serial/serial_core.c +++ b/drivers/serial/serial_core.c @@ -2233,7 +2233,7 @@ int uart_add_one_port(struct uart_driver * If this port is a console, then the spinlock is already * initialised. */ - if (!uart_console(port)) + if (!(uart_console(port) && (port->cons->flags & CON_ENABLED))) spin_lock_init(&port->lock); uart_configure_port(drv, state, port); >> --- a/drivers/serial/serial_txx9.c >> +++ b/drivers/serial/serial_txx9.c >> @@ -937,11 +942,6 @@ static int serial_txx9_console_setup(str >> return -ENODEV; >> >> /* >> - * Temporary fix. >> - */ >> - spin_lock_init(&port->lock); >> - >> - /* >> * Disable UART interrupts, set DTR and RTS high >> * and set speed. >> */ sshtylyov> Can you tell me, how this is supposed to work with TX49xx sshtylyov> SOC UARTs? When that spinlock will be init'ed for the sshtylyov> console port? uart_add_one_port() won't do it, and your sshtylyov> added code below won't do it either, so I disagree with sshtylyov> this change (though with "empty" spinlock it will no doubt sshtylyov> work) since there's nothing to init. The spinlock is initialized in uart_set_options() which is called from console setup function. And this is a revised patch. * More strict check in verify_port. Cleanup. * Do not insert a char caused previous overrun. * Fix some spin_locks. Signed-off-by: Atsushi Nemoto diff --git a/drivers/serial/serial_txx9.c b/drivers/serial/serial_txx9.c index f10c86d..7f484ad 100644 --- a/drivers/serial/serial_txx9.c +++ b/drivers/serial/serial_txx9.c @@ -33,6 +33,9 @@ * 1.02 Cleanup. (import 8250.c changes) * 1.03 Fix low-latency mode. (import 8250.c changes) * 1.04 Remove usage of deprecated functions, cleanup. + * 1.05 More strict check in verify_port. Cleanup. + * 1.06 Do not insert a char caused previous overrun. + * Fix some spin_locks. */ #include @@ -56,7 +59,7 @@ #include #include -static char *serial_version = "1.04"; +static char *serial_version = "1.06"; static char *serial_name = "TX39/49 Serial driver"; #define PASS_LIMIT 256 @@ -209,7 +212,7 @@ static inline unsigned int sio_in(struct { switch (up->port.iotype) { default: - return *(volatile u32 *)(up->port.membase + offset); + return __raw_readl(up->port.membase + offset); case UPIO_PORT: return inl(up->port.iobase + offset); } @@ -220,7 +223,7 @@ sio_out(struct uart_txx9_port *up, int o { switch (up->port.iotype) { default: - *(volatile u32 *)(up->port.membase + offset) = value; + __raw_writel(value, up->port.membase + offset); break; case UPIO_PORT: outl(value, up->port.iobase + offset); @@ -258,34 +261,19 @@ sio_quot_set(struct uart_txx9_port *up, static void serial_txx9_stop_tx(struct uart_port *port) { struct uart_txx9_port *up = (struct uart_txx9_port *)port; - unsigned long flags; - - spin_lock_irqsave(&up->port.lock, flags); sio_mask(up, TXX9_SIDICR, TXX9_SIDICR_TIE); - spin_unlock_irqrestore(&up->port.lock, flags); } static void serial_txx9_start_tx(struct uart_port *port) { struct uart_txx9_port *up = (struct uart_txx9_port *)port; - unsigned long flags; - - spin_lock_irqsave(&up->port.lock, flags); sio_set(up, TXX9_SIDICR, TXX9_SIDICR_TIE); - spin_unlock_irqrestore(&up->port.lock, flags); } static void serial_txx9_stop_rx(struct uart_port *port) { struct uart_txx9_port *up = (struct uart_txx9_port *)port; - unsigned long flags; - - spin_lock_irqsave(&up->port.lock, flags); up->port.read_status_mask &= ~TXX9_SIDISR_RDIS; -#if 0 - sio_mask(up, TXX9_SIDICR, TXX9_SIDICR_RIE); -#endif - spin_unlock_irqrestore(&up->port.lock, flags); } static void serial_txx9_enable_ms(struct uart_port *port) @@ -301,6 +289,7 @@ receive_chars(struct uart_txx9_port *up, unsigned int disr = *status; int max_count = 256; char flag; + unsigned int next_ignore_status_mask; do { /* The following is not allowed by the tty layer and @@ -318,6 +307,9 @@ receive_chars(struct uart_txx9_port *up, flag = TTY_NORMAL; up->port.icount.rx++; + /* mask out RFDN_MASK bit added by previous overrun */ + next_ignore_status_mask = + up->port.ignore_status_mask & ~TXX9_SIDISR_RFDN_MASK; if (unlikely(disr & (TXX9_SIDISR_UBRK | TXX9_SIDISR_UPER | TXX9_SIDISR_UFER | TXX9_SIDISR_UOER))) { /* @@ -338,8 +330,17 @@ receive_chars(struct uart_txx9_port *up, up->port.icount.parity++; else if (disr & TXX9_SIDISR_UFER) up->port.icount.frame++; - if (disr & TXX9_SIDISR_UOER) + if (disr & TXX9_SIDISR_UOER) { up->port.icount.overrun++; + /* + * The receiver read buffer still hold + * a char which caused overrun. + * Ignore next char by adding RFDN_MASK + * to ignore_status_mask temporarily. + */ + next_ignore_status_mask |= + TXX9_SIDISR_RFDN_MASK; + } /* * Mask off conditions which should be ingored. @@ -359,6 +360,7 @@ receive_chars(struct uart_txx9_port *up, uart_insert_char(&up->port, disr, TXX9_SIDISR_UOER, ch, flag); ignore_char: + up->port.ignore_status_mask = next_ignore_status_mask; disr = sio_in(up, TXX9_SIDISR); } while (!(disr & TXX9_SIDISR_UVALID) && (max_count-- > 0)); spin_unlock(&up->port.lock); @@ -460,14 +462,11 @@ static unsigned int serial_txx9_get_mctr static void serial_txx9_set_mctrl(struct uart_port *port, unsigned int mctrl) { struct uart_txx9_port *up = (struct uart_txx9_port *)port; - unsigned long flags; - spin_lock_irqsave(&up->port.lock, flags); if (mctrl & TIOCM_RTS) sio_mask(up, TXX9_SIFLCR, TXX9_SIFLCR_RTSSC); else sio_set(up, TXX9_SIFLCR, TXX9_SIFLCR_RTSSC); - spin_unlock_irqrestore(&up->port.lock, flags); } static void serial_txx9_break_ctl(struct uart_port *port, int break_state) @@ -794,8 +793,13 @@ static void serial_txx9_config_port(stru static int serial_txx9_verify_port(struct uart_port *port, struct serial_struct *ser) { - if (ser->irq < 0 || - ser->baud_base < 9600 || ser->type != PORT_TXX9) + unsigned long new_port = (unsigned long)ser->port + + ((unsigned long)ser->port_high << ((sizeof(long) - sizeof(int)) * 8)); + if (ser->type != port->type || + ser->irq != port->irq || + ser->io_type != port->iotype || + new_port != port->iobase || + (unsigned long)ser->iomem_base != port->mapbase) return -EINVAL; return 0; } @@ -937,11 +941,6 @@ static int serial_txx9_console_setup(str return -ENODEV; /* - * Temporary fix. - */ - spin_lock_init(&port->lock); - - /* * Disable UART interrupts, set DTR and RTS high * and set speed. */ @@ -1090,7 +1089,7 @@ static void __devexit serial_txx9_unregi uart->port.type = PORT_UNKNOWN; uart->port.iobase = 0; uart->port.mapbase = 0; - uart->port.membase = 0; + uart->port.membase = NULL; uart->port.dev = NULL; uart_add_one_port(&serial_txx9_reg, &uart->port); up(&serial_txx9_sem); @@ -1195,7 +1194,7 @@ static int __init serial_txx9_init(void) serial_txx9_register_ports(&serial_txx9_reg); #ifdef ENABLE_SERIAL_TXX9_PCI - ret = pci_module_init(&serial_txx9_pci_driver); + ret = pci_register_driver(&serial_txx9_pci_driver); #endif } return ret; From sshtylyov@ru.mvista.com Tue Dec 27 16:25:00 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 27 Dec 2005 16:25:17 +0000 (GMT) Received: from rtsoft2.corbina.net ([85.21.88.2]:26253 "HELO mail.dev.rtsoft.ru") by ftp.linux-mips.org with SMTP id S8133544AbVL0QZA (ORCPT ); Tue, 27 Dec 2005 16:25:00 +0000 Received: (qmail 19346 invoked from network); 27 Dec 2005 16:26:44 -0000 Received: from wasted.dev.rtsoft.ru (HELO ?192.168.1.248?) (192.168.1.248) by mail.dev.rtsoft.ru with SMTP; 27 Dec 2005 16:26:44 -0000 Message-ID: <43B16BD3.9080108@ru.mvista.com> Date: Tue, 27 Dec 2005 19:29:07 +0300 From: Sergei Shtylylov Organization: MostaVista 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: Atsushi Nemoto CC: rmk+serial@arm.linux.org.uk, linux-mips@linux-mips.org, ralf@linux-mips.org Subject: Re: [PATCH] serial_txx9: forcibly init the spinlock for PCI UART used as a console References: <43B06DB4.409@ru.mvista.com> <20051227.144551.79070832.nemoto@toshiba-tops.co.jp> <43B143EE.6070700@ru.mvista.com> <20051228.003457.74752441.anemo@mba.ocn.ne.jp> In-Reply-To: <20051228.003457.74752441.anemo@mba.ocn.ne.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: 9742 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 Content-Length: 1986 Lines: 61 Hello. Atsushi Nemoto wrote: >>>>>>On Tue, 27 Dec 2005 16:38:54 +0300, Sergei Shtylylov said: >>>The problem is not just only spin_lock_init. The parameters of >>>"console=" option (baudrate, etc.) are not passed for PCI UART. > sshtylyov> They are -- uart_add_one_port() calls console setup > sshtylyov> once more when registering PCI UART with serial code. > Yes, you are right. I missed the register_console call in > uart_add_one_port(). So your patch will fix the problem. But I > suppose the spinlock should be initialized in serial_core. How about > this? > --- a/drivers/serial/serial_core.c > +++ b/drivers/serial/serial_core.c > @@ -2233,7 +2233,7 @@ int uart_add_one_port(struct uart_driver > * If this port is a console, then the spinlock is already > * initialised. > */ > - if (!uart_console(port)) > + if (!(uart_console(port) && (port->cons->flags & CON_ENABLED))) > spin_lock_init(&port->lock); > > uart_configure_port(drv, state, port); I wouldn't object. >>>--- a/drivers/serial/serial_txx9.c >>>+++ b/drivers/serial/serial_txx9.c >>>@@ -937,11 +942,6 @@ static int serial_txx9_console_setup(str >>>return -ENODEV; >>> >>>/* >>>- * Temporary fix. >>>- */ >>>- spin_lock_init(&port->lock); >>>- >>>- /* >>>* Disable UART interrupts, set DTR and RTS high >>>* and set speed. >>>*/ > sshtylyov> Can you tell me, how this is supposed to work with TX49xx > sshtylyov> SOC UARTs? When that spinlock will be init'ed for the > sshtylyov> console port? uart_add_one_port() won't do it, and your > sshtylyov> added code below won't do it either, so I disagree with > sshtylyov> this change (though with "empty" spinlock it will no doubt > sshtylyov> work) since there's nothing to init. > > The spinlock is initialized in uart_set_options() which is called > from console setup function. I'm sorry, haven't dug that deep. :-) Thought explicit spinlock init was really necessary there... WBR, Sergei From rmk+linux-mips=linux-mips.org@arm.linux.org.uk Tue Dec 27 18:40:12 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 27 Dec 2005 18:40:37 +0000 (GMT) Received: from caramon.arm.linux.org.uk ([212.18.232.186]:29710 "EHLO caramon.arm.linux.org.uk") by ftp.linux-mips.org with ESMTP id S8133548AbVL0SkM (ORCPT ); Tue, 27 Dec 2005 18:40:12 +0000 Received: from flint.arm.linux.org.uk ([2002:d412:e8ba:1:201:2ff:fe14:8fad]) by caramon.arm.linux.org.uk with esmtpsa (TLSv1:DES-CBC3-SHA:168) (Exim 4.52) id 1ErJli-0002YI-QM; Tue, 27 Dec 2005 18:41:55 +0000 Received: from rmk by flint.arm.linux.org.uk with local (Exim 4.52) id 1ErJlg-00057B-QU; Tue, 27 Dec 2005 18:41:52 +0000 Date: Tue, 27 Dec 2005 18:41:52 +0000 From: Russell King To: Atsushi Nemoto Cc: sshtylyov@ru.mvista.com, linux-mips@linux-mips.org, ralf@linux-mips.org Subject: Re: [PATCH] serial_txx9: forcibly init the spinlock for PCI UART used as a console Message-ID: <20051227184152.GA4474@flint.arm.linux.org.uk> References: <43B06DB4.409@ru.mvista.com> <20051227.144551.79070832.nemoto@toshiba-tops.co.jp> <43B143EE.6070700@ru.mvista.com> <20051228.003457.74752441.anemo@mba.ocn.ne.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20051228.003457.74752441.anemo@mba.ocn.ne.jp> User-Agent: Mutt/1.4.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: 9743 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: rmk@arm.linux.org.uk Precedence: bulk X-list: linux-mips Content-Length: 1433 Lines: 36 On Wed, Dec 28, 2005 at 12:34:57AM +0900, Atsushi Nemoto wrote: > Thanks for your comment. > > >>>>> On Tue, 27 Dec 2005 16:38:54 +0300, Sergei Shtylylov said: > > >> The problem is not just only spin_lock_init. The parameters of > >> "console=" option (baudrate, etc.) are not passed for PCI UART. > > sshtylyov> They are -- uart_add_one_port() calls console setup > sshtylyov> once more when registering PCI UART with serial code. > > Yes, you are right. I missed the register_console call in > uart_add_one_port(). So your patch will fix the problem. But I > suppose the spinlock should be initialized in serial_core. How about > this? I think you're layering work-around on top of work-around on top of work-around here. I think the first thing you need to resolve is the way you're registering your ports. Firstly, if you're solely PCI-based, there's no need to pre-register all the uart ports at driver initialisation time. Consequently, there's no need to remove them all when you remove the module. Secondly, the upshot of this is that you only call uart_add_one_port() when you initialise a PCI card. This should result in a cleaner implementation, and the console will not be started until you detect the PCI card. Which is the behaviour you desire in any case. -- Russell King Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of: 2.6 Serial core From sshtylyov@ru.mvista.com Tue Dec 27 18:50:16 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 27 Dec 2005 18:50:36 +0000 (GMT) Received: from rtsoft2.corbina.net ([85.21.88.2]:9902 "HELO mail.dev.rtsoft.ru") by ftp.linux-mips.org with SMTP id S8133560AbVL0SuQ (ORCPT ); Tue, 27 Dec 2005 18:50:16 +0000 Received: (qmail 20876 invoked from network); 27 Dec 2005 18:51:47 -0000 Received: from wasted.dev.rtsoft.ru (HELO ?192.168.1.248?) (192.168.1.248) by mail.dev.rtsoft.ru with SMTP; 27 Dec 2005 18:51:47 -0000 Message-ID: <43B18DD2.3090206@ru.mvista.com> Date: Tue, 27 Dec 2005 21:54:10 +0300 From: Sergei Shtylylov Organization: MostaVista 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: Russell King CC: Atsushi Nemoto , linux-mips@linux-mips.org, ralf@linux-mips.org Subject: Re: [PATCH] serial_txx9: forcibly init the spinlock for PCI UART used as a console References: <43B06DB4.409@ru.mvista.com> <20051227.144551.79070832.nemoto@toshiba-tops.co.jp> <43B143EE.6070700@ru.mvista.com> <20051228.003457.74752441.anemo@mba.ocn.ne.jp> <20051227184152.GA4474@flint.arm.linux.org.uk> In-Reply-To: <20051227184152.GA4474@flint.arm.linux.org.uk> 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: 9744 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 Content-Length: 1784 Lines: 51 Hello. Russell King wrote: > On Wed, Dec 28, 2005 at 12:34:57AM +0900, Atsushi Nemoto wrote: > >>Thanks for your comment. >> >> >>>>>>>On Tue, 27 Dec 2005 16:38:54 +0300, Sergei Shtylylov said: >> >>>>The problem is not just only spin_lock_init. The parameters of >>>>"console=" option (baudrate, etc.) are not passed for PCI UART. >> >>sshtylyov> They are -- uart_add_one_port() calls console setup >>sshtylyov> once more when registering PCI UART with serial code. >> >>Yes, you are right. I missed the register_console call in >>uart_add_one_port(). So your patch will fix the problem. But I >>suppose the spinlock should be initialized in serial_core. How about >>this? > I think you're layering work-around on top of work-around on top of > work-around here. > I think the first thing you need to resolve is the way you're > registering your ports. Firstly, if you're solely PCI-based, there's No, this is not the case. The driver serves Toshiba TX39xx/49xx SOC UARTs as well as the compatible PCI UART (GOKU-S). > no need to pre-register all the uart ports at driver initialisation > time. Consequently, there's no need to remove them all when you > remove the module. Hm, then the driver would need to keep track of which ports it has registered and which it has not... > Secondly, the upshot of this is that you only call uart_add_one_port() > when you initialise a PCI card. Not the case as I've said; uart_add_one_port() should be called on driver startup anyway... > This should result in a cleaner implementation, and the console will > not be started until you detect the PCI card. It will still be started with the console_initcall() in this driver, if that code is not also deleted... WBR, Sergei From sshtylyov@dev.rtsoft.ru Tue Dec 27 19:27:46 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 27 Dec 2005 19:28:11 +0000 (GMT) Received: from rtsoft2.corbina.net ([85.21.88.2]:6837 "HELO mail.dev.rtsoft.ru") by ftp.linux-mips.org with SMTP id S8133548AbVL0T1q (ORCPT ); Tue, 27 Dec 2005 19:27:46 +0000 Received: (qmail 21276 invoked from network); 27 Dec 2005 19:29:31 -0000 Received: from wasted.dev.rtsoft.ru (HELO ?192.168.1.248?) (192.168.1.248) by mail.dev.rtsoft.ru with SMTP; 27 Dec 2005 19:29:31 -0000 Message-ID: <43B196A9.8010608@dev.rtsoft.ru> Date: Tue, 27 Dec 2005 22:31:53 +0300 From: Sergei Shtylyov Organization: RTSoft, 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: Russell King CC: Atsushi Nemoto , linux-mips@linux-mips.org, ralf@linux-mips.org Subject: Re: [PATCH] serial_txx9: forcibly init the spinlock for PCI UART used as a console References: <43B06DB4.409@ru.mvista.com> <20051227.144551.79070832.nemoto@toshiba-tops.co.jp> <43B143EE.6070700@ru.mvista.com> <20051228.003457.74752441.anemo@mba.ocn.ne.jp> <20051227184152.GA4474@flint.arm.linux.org.uk> <43B18DD2.3090206@ru.mvista.com> In-Reply-To: <43B18DD2.3090206@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: 9745 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@dev.rtsoft.ru Precedence: bulk X-list: linux-mips Content-Length: 1410 Lines: 36 Hello. Sergei Shtylylov wrote: >> no need to pre-register all the uart ports at driver initialisation >> time. Consequently, there's no need to remove them all when you >> remove the module. > Hm, then the driver would need to keep track of which ports it has > registered and which it has not... However, it does this already in a way, via port type. > > Secondly, the upshot of this is that you only call uart_add_one_port() > > when you initialise a PCI card. > Not the case as I've said; uart_add_one_port() should be called on > driver startup anyway... >> This should result in a cleaner implementation, and the console will >> not be started until you detect the PCI card. > It will still be started with the console_initcall() in this driver, > if that code is not also deleted... That doesn't matter. Driver init time uart_add_one_port() calls to register SOC UARTs will result in register_console() being called multiple times unsuccesfully anyway before we get to the PCI UART to which the console is assigned. All in all, the problem of uninit'ed PCI port spinlock will remain unless serial core is fixed (ot at least the driver). Proposed driver re-design wouldn't help as this is actually chicken-before-egg type problem -- uart_add_one_port() assumes that the console is setup beforehand, and this just can't happen in case of a PCI card. WBR, Sergei From anemo@mba.ocn.ne.jp Wed Dec 28 04:24:04 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 28 Dec 2005 04:24:40 +0000 (GMT) Received: from topsns.toshiba-tops.co.jp ([202.230.225.5]:24353 "HELO topsns.toshiba-tops.co.jp") by ftp.linux-mips.org with SMTP id S8133349AbVL1EYE (ORCPT ); Wed, 28 Dec 2005 04:24:04 +0000 Received: from inside-ms1.toshiba-tops.co.jp by topsns.toshiba-tops.co.jp via smtpd (for mail.linux-mips.org [62.254.210.162]) with SMTP; 28 Dec 2005 04:25:50 UT Received: from topsms.toshiba-tops.co.jp (localhost.localdomain [127.0.0.1]) by localhost.toshiba-tops.co.jp (Postfix) with ESMTP id CEB59201B9; Wed, 28 Dec 2005 13:25:46 +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 BAB6F1FF17; Wed, 28 Dec 2005 13:25:46 +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 jBS4Pi4D046215; Wed, 28 Dec 2005 13:25:44 +0900 (JST) (envelope-from anemo@mba.ocn.ne.jp) Date: Wed, 28 Dec 2005 13:25:44 +0900 (JST) Message-Id: <20051228.132544.96684396.nemoto@toshiba-tops.co.jp> To: sshtylyov@dev.rtsoft.ru Cc: rmk@arm.linux.org.uk, linux-mips@linux-mips.org, ralf@linux-mips.org Subject: Re: [PATCH] serial_txx9: forcibly init the spinlock for PCI UART used as a console From: Atsushi Nemoto In-Reply-To: <43B196A9.8010608@dev.rtsoft.ru> <20051227184152.GA4474@flint.arm.linux.org.uk> References: <20051227184152.GA4474@flint.arm.linux.org.uk> <43B18DD2.3090206@ru.mvista.com> <43B196A9.8010608@dev.rtsoft.ru> 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: 9746 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 Content-Length: 9372 Lines: 283 >>>>> On Tue, 27 Dec 2005 18:41:52 +0000, Russell King said: rmk> This should result in a cleaner implementation, and the console rmk> will not be started until you detect the PCI card. Which is the rmk> behaviour you desire in any case. Thanks for your advise. Though this is not fix the problem as Sergei said, I would refine the driver. >>>>> On Tue, 27 Dec 2005 22:31:53 +0300, Sergei Shtylyov said: sshtylyov> All in all, the problem of uninit'ed PCI port spinlock sshtylyov> will remain unless serial core is fixed (ot at least the sshtylyov> driver). Proposed driver re-design wouldn't help as this is sshtylyov> actually chicken-before-egg type problem -- sshtylyov> uart_add_one_port() assumes that the console is setup sshtylyov> beforehand, and this just can't happen in case of a PCI sshtylyov> card. I agree. Let me clarify a situation. * The serial_txx9 driver handles both SOC UARTs and PCI UARTs. * We want to use console_initcall to register console for SOC UARTs. * PCI UARTs were not detected when console_initcall function was called. * For PCI UARTs, uart_add_one_port() calls register_console (again) _after_ configuring the port. The spinlock must be initialized before configure the port. * By first register_console, port->cons->index has been initialized. (even if console setup function failed) * The uart_console() returns 1 even if the console was not successfully configured (CON_ENABLED was not set and spinlock did not initialized). So uart_add_one_port() does not initialize the spinlock for the console. There would be 3 solutions: 1. uart_add_one_port() initialize the spinlock for console port without CON_ENABLED. 2. lowlevel driver initialize the spinlock somewhere. 3. register_console() revert console->index to -1 when console->setup function failed. (But register_console is already too complex for me ...) I would prefer (1), but if not acceptable, I do not object to (2). This is a refined patch following Russell's advise. This does not include Sergei's fix. * More strict check in verify_port. Cleanup. * Do not insert a char caused previous overrun. * Fix some spin_locks. * Do not call uart_add_one_port for absent ports. Signed-off-by: Atsushi Nemoto diff --git a/drivers/serial/serial_txx9.c b/drivers/serial/serial_txx9.c index f10c86d..37fa0aa 100644 --- a/drivers/serial/serial_txx9.c +++ b/drivers/serial/serial_txx9.c @@ -33,6 +33,10 @@ * 1.02 Cleanup. (import 8250.c changes) * 1.03 Fix low-latency mode. (import 8250.c changes) * 1.04 Remove usage of deprecated functions, cleanup. + * 1.05 More strict check in verify_port. Cleanup. + * 1.06 Do not insert a char caused previous overrun. + * Fix some spin_locks. + * Do not call uart_add_one_port for absent ports. */ #include @@ -56,7 +60,7 @@ #include #include -static char *serial_version = "1.04"; +static char *serial_version = "1.06"; static char *serial_name = "TX39/49 Serial driver"; #define PASS_LIMIT 256 @@ -209,7 +213,7 @@ static inline unsigned int sio_in(struct { switch (up->port.iotype) { default: - return *(volatile u32 *)(up->port.membase + offset); + return __raw_readl(up->port.membase + offset); case UPIO_PORT: return inl(up->port.iobase + offset); } @@ -220,7 +224,7 @@ sio_out(struct uart_txx9_port *up, int o { switch (up->port.iotype) { default: - *(volatile u32 *)(up->port.membase + offset) = value; + __raw_writel(value, up->port.membase + offset); break; case UPIO_PORT: outl(value, up->port.iobase + offset); @@ -258,34 +262,19 @@ sio_quot_set(struct uart_txx9_port *up, static void serial_txx9_stop_tx(struct uart_port *port) { struct uart_txx9_port *up = (struct uart_txx9_port *)port; - unsigned long flags; - - spin_lock_irqsave(&up->port.lock, flags); sio_mask(up, TXX9_SIDICR, TXX9_SIDICR_TIE); - spin_unlock_irqrestore(&up->port.lock, flags); } static void serial_txx9_start_tx(struct uart_port *port) { struct uart_txx9_port *up = (struct uart_txx9_port *)port; - unsigned long flags; - - spin_lock_irqsave(&up->port.lock, flags); sio_set(up, TXX9_SIDICR, TXX9_SIDICR_TIE); - spin_unlock_irqrestore(&up->port.lock, flags); } static void serial_txx9_stop_rx(struct uart_port *port) { struct uart_txx9_port *up = (struct uart_txx9_port *)port; - unsigned long flags; - - spin_lock_irqsave(&up->port.lock, flags); up->port.read_status_mask &= ~TXX9_SIDISR_RDIS; -#if 0 - sio_mask(up, TXX9_SIDICR, TXX9_SIDICR_RIE); -#endif - spin_unlock_irqrestore(&up->port.lock, flags); } static void serial_txx9_enable_ms(struct uart_port *port) @@ -301,6 +290,7 @@ receive_chars(struct uart_txx9_port *up, unsigned int disr = *status; int max_count = 256; char flag; + unsigned int next_ignore_status_mask; do { /* The following is not allowed by the tty layer and @@ -318,6 +308,9 @@ receive_chars(struct uart_txx9_port *up, flag = TTY_NORMAL; up->port.icount.rx++; + /* mask out RFDN_MASK bit added by previous overrun */ + next_ignore_status_mask = + up->port.ignore_status_mask & ~TXX9_SIDISR_RFDN_MASK; if (unlikely(disr & (TXX9_SIDISR_UBRK | TXX9_SIDISR_UPER | TXX9_SIDISR_UFER | TXX9_SIDISR_UOER))) { /* @@ -338,8 +331,17 @@ receive_chars(struct uart_txx9_port *up, up->port.icount.parity++; else if (disr & TXX9_SIDISR_UFER) up->port.icount.frame++; - if (disr & TXX9_SIDISR_UOER) + if (disr & TXX9_SIDISR_UOER) { up->port.icount.overrun++; + /* + * The receiver read buffer still hold + * a char which caused overrun. + * Ignore next char by adding RFDN_MASK + * to ignore_status_mask temporarily. + */ + next_ignore_status_mask |= + TXX9_SIDISR_RFDN_MASK; + } /* * Mask off conditions which should be ingored. @@ -359,6 +361,7 @@ receive_chars(struct uart_txx9_port *up, uart_insert_char(&up->port, disr, TXX9_SIDISR_UOER, ch, flag); ignore_char: + up->port.ignore_status_mask = next_ignore_status_mask; disr = sio_in(up, TXX9_SIDISR); } while (!(disr & TXX9_SIDISR_UVALID) && (max_count-- > 0)); spin_unlock(&up->port.lock); @@ -460,14 +463,11 @@ static unsigned int serial_txx9_get_mctr static void serial_txx9_set_mctrl(struct uart_port *port, unsigned int mctrl) { struct uart_txx9_port *up = (struct uart_txx9_port *)port; - unsigned long flags; - spin_lock_irqsave(&up->port.lock, flags); if (mctrl & TIOCM_RTS) sio_mask(up, TXX9_SIFLCR, TXX9_SIFLCR_RTSSC); else sio_set(up, TXX9_SIFLCR, TXX9_SIFLCR_RTSSC); - spin_unlock_irqrestore(&up->port.lock, flags); } static void serial_txx9_break_ctl(struct uart_port *port, int break_state) @@ -794,8 +794,13 @@ static void serial_txx9_config_port(stru static int serial_txx9_verify_port(struct uart_port *port, struct serial_struct *ser) { - if (ser->irq < 0 || - ser->baud_base < 9600 || ser->type != PORT_TXX9) + unsigned long new_port = (unsigned long)ser->port + + ((unsigned long)ser->port_high << ((sizeof(long) - sizeof(int)) * 8)); + if (ser->type != port->type || + ser->irq != port->irq || + ser->io_type != port->iotype || + new_port != port->iobase || + (unsigned long)ser->iomem_base != port->mapbase) return -EINVAL; return 0; } @@ -837,7 +842,8 @@ static void __init serial_txx9_register_ up->port.line = i; up->port.ops = &serial_txx9_pops; - uart_add_one_port(drv, &up->port); + if (up->port.iobase || up->port.mapbase) + uart_add_one_port(drv, &up->port); } } @@ -937,11 +943,6 @@ static int serial_txx9_console_setup(str return -ENODEV; /* - * Temporary fix. - */ - spin_lock_init(&port->lock); - - /* * Disable UART interrupts, set DTR and RTS high * and set speed. */ @@ -1051,11 +1052,10 @@ static int __devinit serial_txx9_registe down(&serial_txx9_sem); for (i = 0; i < UART_NR; i++) { uart = &serial_txx9_ports[i]; - if (uart->port.type == PORT_UNKNOWN) + if (!(uart->port.iobase || uart->port.mapbase)) break; } if (i < UART_NR) { - uart_remove_one_port(&serial_txx9_reg, &uart->port); uart->port.iobase = port->iobase; uart->port.membase = port->membase; uart->port.irq = port->irq; @@ -1090,9 +1090,8 @@ static void __devexit serial_txx9_unregi uart->port.type = PORT_UNKNOWN; uart->port.iobase = 0; uart->port.mapbase = 0; - uart->port.membase = 0; + uart->port.membase = NULL; uart->port.dev = NULL; - uart_add_one_port(&serial_txx9_reg, &uart->port); up(&serial_txx9_sem); } @@ -1195,7 +1194,7 @@ static int __init serial_txx9_init(void) serial_txx9_register_ports(&serial_txx9_reg); #ifdef ENABLE_SERIAL_TXX9_PCI - ret = pci_module_init(&serial_txx9_pci_driver); + ret = pci_register_driver(&serial_txx9_pci_driver); #endif } return ret; @@ -1208,8 +1207,11 @@ static void __exit serial_txx9_exit(void #ifdef ENABLE_SERIAL_TXX9_PCI pci_unregister_driver(&serial_txx9_pci_driver); #endif - for (i = 0; i < UART_NR; i++) - uart_remove_one_port(&serial_txx9_reg, &serial_txx9_ports[i].port); + for (i = 0; i < UART_NR; i++) { + struct uart_txx9_port *up = &serial_txx9_ports[i]; + if (up->port.iobase || up->port.mapbase) + uart_remove_one_port(&serial_txx9_reg, &up->port); + } uart_unregister_driver(&serial_txx9_reg); } From adilhafeez80@gmail.com Wed Dec 28 07:35:06 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 28 Dec 2005 07:35:24 +0000 (GMT) Received: from xproxy.gmail.com ([66.249.82.200]:49895 "EHLO xproxy.gmail.com") by ftp.linux-mips.org with ESMTP id S8126502AbVL1HfG (ORCPT ); Wed, 28 Dec 2005 07:35:06 +0000 Received: by xproxy.gmail.com with SMTP id s19so808114wxc for ; Tue, 27 Dec 2005 23:36:54 -0800 (PST) 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; b=MUNq21E50pgL+4QMwF6qt44DS2+QmrALwqtVGWDLr2tRIHQeO+s9o3raUa2KREzaqIeZHE2g/odn0OasGr0xqj+rynqWRhr966gOjogbChWMQKPCxZhGhUHBEWjMjGIHIAfmvoJK594/1kB8NQrbwU29eDTuUdnzBtU6nm0eAos= Received: by 10.70.99.13 with SMTP id w13mr7580710wxb; Tue, 27 Dec 2005 23:36:54 -0800 (PST) Received: by 10.70.96.11 with HTTP; Tue, 27 Dec 2005 23:36:54 -0800 (PST) Message-ID: <82e4189c0512272336xed0fe2ax9fee6119ea2d6b00@mail.gmail.com> Date: Wed, 28 Dec 2005 12:36:54 +0500 From: Adil Hafeez To: linux-mips@linux-mips.org Subject: Fixed kernel entry point suggestion MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_46479_25644177.1135755414286" 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: 9747 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: adilhafeez80@gmail.com Precedence: bulk X-list: linux-mips Content-Length: 1054 Lines: 32 ------=_Part_46479_25644177.1135755414286 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi, Everytime we add/remove a feature from kernel location of entry_point symbo= l changes. As a result we 've to recompile bootloader with new entry_point location. Adding a simply jump instruction to kernel_entry point in head.Scan solve this problem. Why dont we make this change permanent in kernel. - Adil ------=_Part_46479_25644177.1135755414286 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline
Hi,

Everytime we add/remove a feature from kernel location of entry_po= int symbol changes. As a result we 've to recompile bootloader with new ent= ry_point location. Adding a simply jump instruction to kernel_entry point i= n=20 head.S can solve this problem. Why dont we make this change permanent in ke= rnel.
 
- Adil
------=_Part_46479_25644177.1135755414286-- From dan@embeddedalley.com Wed Dec 28 14:21:17 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 28 Dec 2005 14:21:35 +0000 (GMT) Received: from smtp107.biz.mail.re2.yahoo.com ([206.190.52.176]:15694 "HELO smtp107.biz.mail.re2.yahoo.com") by ftp.linux-mips.org with SMTP id S8133528AbVL1OVR (ORCPT ); Wed, 28 Dec 2005 14:21:17 +0000 Received: (qmail 52647 invoked from network); 28 Dec 2005 14:22:57 -0000 Received: from unknown (HELO ?192.168.2.27?) (dan@embeddedalley.com@69.21.252.132 with plain) by smtp107.biz.mail.re2.yahoo.com with SMTP; 28 Dec 2005 14:22:57 -0000 In-Reply-To: <82e4189c0512272336xed0fe2ax9fee6119ea2d6b00@mail.gmail.com> References: <82e4189c0512272336xed0fe2ax9fee6119ea2d6b00@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v623) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <06af7c9f9f82dd2b306e02997869e709@embeddedalley.com> Content-Transfer-Encoding: 7bit Cc: linux-mips@linux-mips.org From: Dan Malek Subject: Re: Fixed kernel entry point suggestion Date: Wed, 28 Dec 2005 09:22:55 -0500 To: Adil Hafeez X-Mailer: Apple Mail (2.623) 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: 9748 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@embeddedalley.com Precedence: bulk X-list: linux-mips Content-Length: 1078 Lines: 34 On Dec 28, 2005, at 2:36 AM, Adil Hafeez wrote: > Everytime we add/remove a feature from kernel location of entry_point > symbol changes. If you "wrap" the kernel image with a simple header and have a boot loader that understands this, or even understands the ELF header, or download S-records (yuk) as most systems do, I guess it isn't necessary to fix this. I've been providing the compressed zImage patches for a long time that solves this, as well as the u-boot uImage patches. The process of building these images not only locates the proper entry point, but it provides advantages for embedded systems by creating smaller images and faster boot times. > ..... Adding a simply jump instruction to kernel_entry point in > head.S can solve this problem. Why dont we make this change permanent > in kernel. :-) It seems MIPS likes to be different from other architectures that have solved these irritating little details years ago :-) Submit a patch and see what happens, as just complaining on the list isn't likely to make it happen. Thanks. -- Dan From sshtylyov@ru.mvista.com Wed Dec 28 22:21:48 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 28 Dec 2005 22:22:07 +0000 (GMT) Received: from rtsoft2.corbina.net ([85.21.88.2]:44010 "HELO mail.dev.rtsoft.ru") by ftp.linux-mips.org with SMTP id S8133607AbVL1WVs (ORCPT ); Wed, 28 Dec 2005 22:21:48 +0000 Received: (qmail 5437 invoked from network); 28 Dec 2005 22:23:35 -0000 Received: from wasted.dev.rtsoft.ru (HELO ?192.168.1.248?) (192.168.1.248) by mail.dev.rtsoft.ru with SMTP; 28 Dec 2005 22:23:35 -0000 Message-ID: <43B310F5.4090507@ru.mvista.com> Date: Thu, 29 Dec 2005 01:25:57 +0300 From: Sergei Shtylylov Organization: MostaVista 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 , Jordan Crouse , ralf@linux-mips.org Subject: Re: [PATCH] Retain the write-only OD from being clobbered References: <20051122205938.GR18119@cosmic.amd.com> <43838957.2020106@ru.mvista.com> In-Reply-To: <43838957.2020106@ru.mvista.com> Content-Type: multipart/mixed; boundary="------------030905000906030802040701" 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: 9749 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 Content-Length: 4134 Lines: 114 This is a multi-part message in MIME format. --------------030905000906030802040701 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hello Sergei Shtylylov wrote: > Jordan Crouse wrote: >> First of several patches forwarded to me by Sergei Shtylyov. Ralf, >> these should be good to go for the tree. >> >> Retain the write-only OD bit from being clobbered by coherency_setup() >> >> Signed-off-by: Sergei Shtylyov >> Acked-by: Jordan Crouse > A long story of a long standing bug follows... > AMD Au1x00 board setup code in au1x00_setup() sets CONFIG.OD bit for > the early steppings of the Au1x00 SOCs, consulting the PRID table in > arch/mips/au1000/common/cputable.c. This bit disables the bus > transaction overlapping which causes a number of errata in those early > SOC steppings (including the one that I think we've run into with USB > host--at least setting the bit back to 1 fixed it, although disabling > USB host DMA coherency also seemd to help). The problem is that this bit > is write-only and reads > as 0 on almost all SOCs that need it set. So, when the arch/mm/c-r4k.c code > does RMW to the CONFIG reg. in coherency_setup(), its value is lost, and > the > chip again becomes prone to all the nasty errata that it has just been > saved > from... :-) > There's couple more places in the assembly code where the CP0 > CONFIG reg. is written without care of OD bit: > 1) In the cache parity error handler (arch/mips/mm/cex-gen.S) -- as > the panic() call follows shortly, probably CACHE.OD=0 doesn't matter > much at this point; > 2) In arch/mips/au1000/common/sleeper.S, when the CPU regs are being > restored on wakeup; Au1x00 PM code in 2.6 seem to have fallen out of > maintenance, and the stack frame set up there seemed just erratic (2.4 > situation in this module is much better). > I didn't touch both those places. And of course, this CONFIG.OD bug is > present in 2.4 kernels as well... Posting the reworked patch at last -- this variant doesn't include machine-specific header into arch/mips/c-r4k.c... WBR, Sergei Signed-off-by: Konstantin Baidarov Signed-off-by: Sergei Shtylyov --------------030905000906030802040701 Content-Type: text/plain; name="Au1x00-retain-OD-bit.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="Au1x00-retain-OD-bit.patch" diff --git a/arch/mips/au1000/common/setup.c b/arch/mips/au1000/common/setup.c index 08c8c85..e36289b 100644 --- a/arch/mips/au1000/common/setup.c +++ b/arch/mips/au1000/common/setup.c @@ -143,6 +143,17 @@ void __init plat_setup(void) au_writel(0, SYS_TOYTRIM); } +/* + * Fix up write-only Config[OD] bit after a write to that register. Since the + * bit always reads as 0 on those SOC revs that require it to be set to fight + * the various errata, we need to set it back to 1... + */ +void au1x00_fixup_config_od(void) +{ + if (cur_cpu_spec[0]->cpu_od) + set_c0_config(1<<19); +} + #if defined(CONFIG_64BIT_PHYS_ADDR) /* This routine should be valid for all Au1x based boards */ phys_t __fixup_bigphys_addr(phys_t phys_addr, phys_t size) diff --git a/arch/mips/mm/c-r4k.c b/arch/mips/mm/c-r4k.c index 422b55f..8447699 100644 --- a/arch/mips/mm/c-r4k.c +++ b/arch/mips/mm/c-r4k.c @@ -1201,8 +1201,20 @@ static void __init setup_scache(void) static inline void coherency_setup(void) { + extern void au1x00_fixup_config_od(void); + change_c0_config(CONF_CM_CMASK, CONF_CM_DEFAULT); +#ifdef CONFIG_SOC_AU1X00 + /* + * c0_config.od (bit 19) is write only (and reads as 0) on many early + * revs of AMD Au1x00 SOCs. It disables the bus transaction overlapping + * and needs to be set to correct the various errata. So if it has been + * set by the board setup code we must leave it set... + */ + au1x00_fixup_config_od(); +#endif + /* * c0_status.cu=0 specifies that updates by the sc instruction use * the coherency mode specified by the TLB; 1 means cachable --------------030905000906030802040701-- From confirm-return-linux-mips=linux-mips.org@returns.groups.yahoo.com Thu Dec 29 02:03:03 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 29 Dec 2005 02:03:20 +0000 (GMT) Received: from n4a.bullet.scd.yahoo.com ([66.94.237.38]:55205 "HELO n4a.bullet.scd.yahoo.com") by ftp.linux-mips.org with SMTP id S8133471AbVL2CDD (ORCPT ); Thu, 29 Dec 2005 02:03:03 +0000 Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=lima; d=yahoogroups.com; b=RHNGWDLc/fGey4pm8EfVVqfi5ObGDzOOSpzCUXHD6R1cjTuglzGZUVIb9S8tlFzqWqJl3HOZQgfampkdgkH/GgjDl4SpYVxEG4oEeH6Rvye68dP/r5+M323lJJyPB6gD; Received: from [66.218.69.4] by n4.bullet.scd.yahoo.com with NNFMP; 29 Dec 2005 02:04:50 -0000 Received: from [66.218.66.81] by mailer4.bullet.scd.yahoo.com with NNFMP; 29 Dec 2005 02:04:50 -0000 Date: 29 Dec 2005 02:04:48 -0000 Message-ID: <1135821888.59.92883.w114@yahoogroups.com> X-Yahoo-Newman-Property: groups-notify From: Yahoo! Groups Reply-To: confirm-s2-o_0IslQ3J8le8B2IQnKJ2LOVkWY-linux-mips=linux-mips.org@yahoogroups.com To: linux-mips@linux-mips.org Subject: Please confirm your request to join movaznaustva MIME-Version: 1.0 Content-Type: text/plain 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: 9750 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: confirm-s2-o_0IslQ3J8le8B2IQnKJ2LOVkWY-linux-mips=linux-mips.org@yahoogroups.com Precedence: bulk X-list: linux-mips Content-Length: 837 Lines: 37 Hello linux-mips@linux-mips.org, We have received your request to join the movaznaustva group hosted by Yahoo! Groups, a free, easy-to-use community service. This request will expire in 7 days. TO BECOME A MEMBER OF THE GROUP: 1) Go to the Yahoo! Groups site by clicking on this link: http://groups.yahoo.com/i?i=o_0IslQ3J8le8B2IQnKJ2LOVkWY&e=linux-mips%40linux-mips%2Eorg (If clicking doesn't work, "Cut" and "Paste" the line above into your Web browser's address bar.) -OR- 2) REPLY to this email by clicking "Reply" and then "Send" in your email program If you did not request, or do not want, a membership in the movaznaustva group, please accept our apologies and ignore this message. Regards, Yahoo! Groups Customer Care Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ From anemo@mba.ocn.ne.jp Thu Dec 29 16:31:30 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 29 Dec 2005 16:31:48 +0000 (GMT) Received: from mba.ocn.ne.jp ([210.190.142.172]:60646 "HELO smtp.mba.ocn.ne.jp") by ftp.linux-mips.org with SMTP id S8133523AbVL2Qba (ORCPT ); Thu, 29 Dec 2005 16:31:30 +0000 Received: from localhost (p1122-ipad201funabasi.chiba.ocn.ne.jp [222.146.64.122]) by smtp.mba.ocn.ne.jp (Postfix) with ESMTP id 9ECE48C89; Fri, 30 Dec 2005 01:33:20 +0900 (JST) Date: Fri, 30 Dec 2005 01:32:42 +0900 (JST) Message-Id: <20051230.013242.74752856.anemo@mba.ocn.ne.jp> To: sshtylyov@dev.rtsoft.ru Cc: rmk@arm.linux.org.uk, linux-mips@linux-mips.org, ralf@linux-mips.org Subject: Re: [PATCH] serial_txx9: forcibly init the spinlock for PCI UART used as a console From: Atsushi Nemoto In-Reply-To: <20051228.132544.96684396.nemoto@toshiba-tops.co.jp> References: <43B18DD2.3090206@ru.mvista.com> <43B196A9.8010608@dev.rtsoft.ru> <20051228.132544.96684396.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: 9752 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 Content-Length: 626 Lines: 16 >>>>> On Wed, 28 Dec 2005 13:25:44 +0900 (JST), Atsushi Nemoto said: anemo> * The uart_console() returns 1 even if the console was not anemo> successfully configured (CON_ENABLED was not set and spinlock anemo> did not initialized). So uart_add_one_port() does not anemo> initialize the spinlock for the console. This is same for the 8250 driver which also can handle PCI and legacy ports. The 8250 driver is working correctly just because serial8250_isa_init_ports() initializes all spinlocks. If this way a right way, spin_lock_init() in uart_add_one_port() seems redundant... --- Atsushi Nemoto From adilhafeez80@gmail.com Fri Dec 30 09:34:23 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 30 Dec 2005 09:34:41 +0000 (GMT) Received: from xproxy.gmail.com ([66.249.82.195]:16020 "EHLO xproxy.gmail.com") by ftp.linux-mips.org with ESMTP id S8133562AbVL3JeW (ORCPT ); Fri, 30 Dec 2005 09:34:22 +0000 Received: by xproxy.gmail.com with SMTP id s19so1051150wxc for ; Fri, 30 Dec 2005 01:36:23 -0800 (PST) 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=QTtfqt4IHcNcaZ7bM7I4LIhfjut69o6C6bSNZtWF/dr5kWuUx/BXWbssmk/RYStrf6W2OunNNhqlxDkquNBBYMMymfgmGKkJfY2ZXPC2BS26AvBylqF80o/Jbqfyf2nylvIP0JIc/mFW1BNYhbZVF6n77pyIKD5n1vrQUqgcNjY= Received: by 10.70.97.9 with SMTP id u9mr10190202wxb; Fri, 30 Dec 2005 01:36:22 -0800 (PST) Received: by 10.70.94.10 with HTTP; Fri, 30 Dec 2005 01:36:22 -0800 (PST) Message-ID: <82e4189c0512300136w5112edf2kf3d243ddbc9313d@mail.gmail.com> Date: Fri, 30 Dec 2005 14:36:22 +0500 From: Adil Hafeez To: Dan Malek Subject: Re: Fixed kernel entry point suggestion Cc: linux-mips@linux-mips.org In-Reply-To: <06af7c9f9f82dd2b306e02997869e709@embeddedalley.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_18434_15657856.1135935382945" References: <82e4189c0512272336xed0fe2ax9fee6119ea2d6b00@mail.gmail.com> <06af7c9f9f82dd2b306e02997869e709@embeddedalley.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: 9753 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: adilhafeez80@gmail.com Precedence: bulk X-list: linux-mips Content-Length: 4825 Lines: 119 ------=_Part_18434_15657856.1135935382945 Content-Type: multipart/alternative; boundary="----=_Part_18435_27731220.1135935382945" ------=_Part_18435_27731220.1135935382945 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi Dan, Here is the patch. diff --git a/arch/mips/kernel/head.S b/arch/mips/kernel/head.S index eebdaa2..a5e6d4e 100644 --- a/arch/mips/kernel/head.S +++ b/arch/mips/kernel/head.S @@ -28,6 +28,7 @@ #include #include + j kernel_entry .text /* * Reserved space for exception handlers. On 12/28/05, Dan Malek wrote: > > On Dec 28, 2005, at 2:36 AM, Adil Hafeez wrote: > > > Everytime we add/remove a feature from kernel location of entry_point > > symbol changes. > > If you "wrap" the kernel image with a simple header and have a boot > loader > that understands this, or even understands the ELF header, or download > S-records (yuk) as most systems do, I guess it isn't necessary to fix > this. > I've been providing the compressed zImage patches for a long time that > solves > this, as well as the u-boot uImage patches. The process of building > these > images not only locates the proper entry point, but it provides > advantages > for embedded systems by creating smaller images and faster boot times. > > > ..... Adding a simply jump instruction to kernel_entry point in > > head.S can solve this problem. Why dont we make this change permanent > > in kernel. > > :-) It seems MIPS likes to be different from other architectures that > have > solved these irritating little details years ago :-) Submit a patch > and see > what happens, as just complaining on the list isn't likely to make it > happen. > > Thanks. > > -- Dan > > ------=_Part_18435_27731220.1135935382945 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline
Hi Dan,
 
Here is the patch.
 
diff --git a/arch/mips/kernel/head.S b/arch/mips/kernel/head.S
inde= x eebdaa2..a5e6d4e 100644
--- a/arch/mips/kernel/head.S
+++ b/arch/mi= ps/kernel/head.S
@@ -28,6 +28,7 @@
#include <asm/mipsregs.h>
#include <asm/stackframe.h>

+     = ;   j kernel_entry
.text
/*
* Reserved space for excepti= on handlers.

On 12/28/05, Dan Malek < dan@embeddedalley.com> wrote:

On Dec 28, 2005, at 2:36 AM,= Adil Hafeez wrote:

> Everytime we add/remove a feature from kern= el location of entry_point
> symbol changes.

If you "wrap" the kernel image wi= th a simple header and have a boot
loader
that understands this, or e= ven understands the ELF header, or download
S-records (yuk) as most syst= ems do, I guess it isn't necessary to fix
this.
I've been providing the compressed zImage patches for a long t= ime that
solves
this, as well as the u-boot uImage patches. &nbs= p;The process of building
these
images not only locates the proper en= try point, but it provides
advantages
for embedded systems by creating smaller images and faste= r boot times.

>  .....   Adding a simply jump= instruction to kernel_entry point in
> head.S can solve this problem= . Why dont we make this change permanent
> in kernel.

:-)  It seems MIPS likes to be differe= nt from other architectures that
have
solved these irritating little = details years ago :-)  Submit a patch
and see
what happens,= as just complaining on the list isn't likely to make it
happen.

Thanks.

       -- D= an


------=_Part_18435_27731220.1135935382945-- ------=_Part_18434_15657856.1135935382945 Content-Type: text/plain; name="kernel_entry-fix.patch" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="kernel_entry-fix.patch" ZGlmZiAtLWdpdCBhL2FyY2gvbWlwcy9rZXJuZWwvaGVhZC5TIGIvYXJjaC9taXBzL2tlcm5lbC9o ZWFkLlMKaW5kZXggZWViZGFhMi4uYTVlNmQ0ZSAxMDA2NDQKLS0tIGEvYXJjaC9taXBzL2tlcm5l bC9oZWFkLlMKKysrIGIvYXJjaC9taXBzL2tlcm5lbC9oZWFkLlMKQEAgLTI4LDYgKzI4LDcgQEAK ICNpbmNsdWRlIDxhc20vbWlwc3JlZ3MuaD4KICNpbmNsdWRlIDxhc20vc3RhY2tmcmFtZS5oPgog CisgICAgICAgIGoga2VybmVsX2VudHJ5CiAJCS50ZXh0CiAJCS8qCiAJCSAqIFJlc2VydmVkIHNw YWNlIGZvciBleGNlcHRpb24gaGFuZGxlcnMuCg== ------=_Part_18434_15657856.1135935382945-- From ths@networkno.de Fri Dec 30 09:46:01 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 30 Dec 2005 09:46:18 +0000 (GMT) Received: from mx01.qsc.de ([213.148.129.14]:55175 "EHLO mx01.qsc.de") by ftp.linux-mips.org with ESMTP id S8133470AbVL3JqB (ORCPT ); Fri, 30 Dec 2005 09:46:01 +0000 Received: from port-195-158-168-159.dynamic.qsc.de ([195.158.168.159] helo=hattusa.textio) by mx01.qsc.de with esmtp (Exim 3.35 #1) id 1EsGrc-000582-00 for linux-mips@linux-mips.org; Fri, 30 Dec 2005 10:47:56 +0100 Received: from ths by hattusa.textio with local (Exim 4.60) (envelope-from ) id 1EsGrX-0005Tg-3B for linux-mips@linux-mips.org; Fri, 30 Dec 2005 10:47:51 +0100 Date: Fri, 30 Dec 2005 10:47:51 +0100 To: linux-mips@linux-mips.org Subject: Re: Fixed kernel entry point suggestion Message-ID: <20051230094750.GI1882@hattusa.textio> References: <82e4189c0512272336xed0fe2ax9fee6119ea2d6b00@mail.gmail.com> <06af7c9f9f82dd2b306e02997869e709@embeddedalley.com> <82e4189c0512300136w5112edf2kf3d243ddbc9313d@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <82e4189c0512300136w5112edf2kf3d243ddbc9313d@mail.gmail.com> User-Agent: Mutt/1.5.11 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: 9754 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 Content-Length: 521 Lines: 23 Adil Hafeez wrote: > Hi Dan, > > Here is the patch. > > diff --git a/arch/mips/kernel/head.S b/arch/mips/kernel/head.S > index eebdaa2..a5e6d4e 100644 > --- a/arch/mips/kernel/head.S > +++ b/arch/mips/kernel/head.S > @@ -28,6 +28,7 @@ > #include > #include > > + j kernel_entry > .text > /* > * Reserved space for exception handlers. But certainly not _before_ .text. Also, it shouldn't move the reserved space, it would need "align" instead of "space" afterwards. Thiemo From david.goodenough@btconnect.com Fri Dec 30 10:06:40 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 30 Dec 2005 10:06:57 +0000 (GMT) Received: from smtp.uk.colt.net ([195.110.64.125]:45773 "EHLO smtp.uk.colt.net") by ftp.linux-mips.org with ESMTP id S8133581AbVL3KGk (ORCPT ); Fri, 30 Dec 2005 10:06:40 +0000 Received: from [10.0.1.4] (117-21-161-212.DSL.ONCOLT.COM [212.161.21.117]) by smtp.uk.colt.net (Postfix) with ESMTP id 299A0E2CF5 for ; Fri, 30 Dec 2005 09:59:39 +0000 (GMT) From: David Goodenough To: linux-mips@linux-mips.org Subject: Watchdog support on Broadcomm MIPS chips Date: Fri, 30 Dec 2005 10:08:35 +0000 User-Agent: KMail/1.8.2 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200512301008.35788.david.goodenough@btconnect.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: 9755 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.goodenough@btconnect.com Precedence: bulk X-list: linux-mips Content-Length: 926 Lines: 21 I was referred to this list as I am interested in extending the kind of support that I am used to with SC200 based systems to the systems supported by OpenWrt such as the Netgear WGT634U which is built around a Broadcomm BCM947XX chip. In the bcm947xx arch directory on OpenWrt (and I am not quite sure how it got there) there is some code (marked as copyright Broadcomm) which talks about Watchdog functionality, but does not seem to link it into the rest of the linux watchdog functionality which Alan Cox seems to have either written or rewritten. There is a /dev/watchdog that is used by a watchdog daemon (in the OpenWrt case this would be the BusyBox watchdog function) to refresh the watchdog and stop the box rebooting itself. Does anyone know anything about watchdog functionality in the Broadcomm chips, or about the code that Broadcomm seem to have written for it and how to use it? Thanks in advance David From adilhafeez80@gmail.com Fri Dec 30 10:20:34 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 30 Dec 2005 10:21:00 +0000 (GMT) Received: from xproxy.gmail.com ([66.249.82.192]:56684 "EHLO xproxy.gmail.com") by ftp.linux-mips.org with ESMTP id S8133581AbVL3KUe (ORCPT ); Fri, 30 Dec 2005 10:20:34 +0000 Received: by xproxy.gmail.com with SMTP id s19so1054473wxc for ; Fri, 30 Dec 2005 02:22:35 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; b=rN1UsGcDt5Wp/dO5qMWAHdnsr6QFiY5qEUJbR83SUxF3QVpjR43MYayNw9ncnNtvJpbFTuzigMAIuVePKsvxadVtuTNaDDZj/vTuGT9cFhDoyo1W5CH87OPF39rzDCkYkADIt+We2p53ff0wC2xFf711SY8BxqcalIXFP7zKBFo= Received: by 10.70.109.10 with SMTP id h10mr6091762wxc; Fri, 30 Dec 2005 02:22:35 -0800 (PST) Received: by 10.70.94.10 with HTTP; Fri, 30 Dec 2005 02:22:35 -0800 (PST) Message-ID: <82e4189c0512300222k426764e0ldefeafb232ad36d@mail.gmail.com> Date: Fri, 30 Dec 2005 15:22:35 +0500 From: Adil Hafeez To: linux-mips@linux-mips.org Subject: Re: Fixed kernel entry point suggestion In-Reply-To: <20051230094750.GI1882@hattusa.textio> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_18571_7923318.1135938155760" References: <82e4189c0512272336xed0fe2ax9fee6119ea2d6b00@mail.gmail.com> <06af7c9f9f82dd2b306e02997869e709@embeddedalley.com> <82e4189c0512300136w5112edf2kf3d243ddbc9313d@mail.gmail.com> <20051230094750.GI1882@hattusa.textio> 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: 9756 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: adilhafeez80@gmail.com Precedence: bulk X-list: linux-mips Content-Length: 3560 Lines: 94 ------=_Part_18571_7923318.1135938155760 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline What about placing the jump instruction just after reserved space, like thi= s .text /* * Reserved space for exception handlers. * Necessary for machines which link their kernels at KSEG0. */ .fill 0x400 /* The following two symbols are used for kernel profiling. */ EXPORT(stext) EXPORT(_stext) =3D> j kernel_entry __INIT I disassembled vmlinux binary and now jump instruction is placed after reserved space On 12/30/05, Thiemo Seufer wrote: > > Adil Hafeez wrote: > > Hi Dan, > > > > Here is the patch. > > > > diff --git a/arch/mips/kernel/head.S b/arch/mips/kernel/head.S > > index eebdaa2..a5e6d4e 100644 > > --- a/arch/mips/kernel/head.S > > +++ b/arch/mips/kernel/head.S > > @@ -28,6 +28,7 @@ > > #include > > #include > > > > + j kernel_entry > > .text > > /* > > * Reserved space for exception handlers. > > But certainly not _before_ .text. Also, it shouldn't move the reserved > space, it would need "align" instead of "space" afterwards. > > > Thiemo > > ------=_Part_18571_7923318.1135938155760 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline
What about placing the jump instruction just after reserved space, lik= e this
 
        .text
   =      /*
       &n= bsp; * Reserved space for exception handlers.
    &n= bsp;    * Necessary for machines which link their kernels at= KSEG0.
         */
 &nb= sp;      .fill   0x400

        /* The following two symbols = are used for kernel profiling. */
      &n= bsp; EXPORT(stext)
        EXPORT(_st= ext)
=3D>     j kernel_entry
   = ;     __INIT

I disassembled vmlinux binary and now jump instruction is placed after r= eserved space



 
On 12/30/05, Thiemo Seufer <ths@networkno.de= > wrote:
Adil Hafeez wrote:
> Hi Da= n,
>
> Here is the patch.
>
> diff --git a/arch/mip= s/kernel/head.S b/arch/mips/kernel/head.S
> index eebdaa2..a5e6d4e 100644
> --- a/arch/mips/kernel/head.= S
> +++ b/arch/mips/kernel/head.S
> @@ -28,6 +28,7 @@
> #= include <asm/mipsregs.h>
> #include <asm/stackframe.h>
>
> +        j kernel_= entry
> .text
> /*
> * Reserved space for exception handl= ers.

But certainly not _before_ .text. Also, it shouldn't move the r= eserved
space, it would need "align" instead of "space&qu= ot; afterwards.


Thiemo


------=_Part_18571_7923318.1135938155760-- From sshtylyov@ru.mvista.com Fri Dec 30 19:02:28 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 30 Dec 2005 19:02:47 +0000 (GMT) Received: from rtsoft2.corbina.net ([85.21.88.2]:10905 "HELO mail.dev.rtsoft.ru") by ftp.linux-mips.org with SMTP id S8133373AbVL3TC2 (ORCPT ); Fri, 30 Dec 2005 19:02:28 +0000 Received: (qmail 31606 invoked from network); 30 Dec 2005 19:04:26 -0000 Received: from wasted.dev.rtsoft.ru (HELO ?192.168.1.248?) (192.168.1.248) by mail.dev.rtsoft.ru with SMTP; 30 Dec 2005 19:04:26 -0000 Message-ID: <43B58548.4050208@ru.mvista.com> Date: Fri, 30 Dec 2005 22:06:48 +0300 From: Sergei Shtylylov Organization: MostaVista 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: rmk+serial@arm.linux.org.uk CC: Manish Lachwani , Linux MIPS , Jordan Crouse Subject: [PATCH] AMD Au1xx0 serial: claim the memory resource Content-Type: multipart/mixed; boundary="------------060801020000050309040506" 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: 9757 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 Content-Length: 6914 Lines: 252 This is a multi-part message in MIME format. --------------060801020000050309040506 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hello. We've noticed that Au1x00 UART driver (drivers/serial/au1x00_uart.c) wasn't claiming its memory resources (in fact, as the heading comment had it, it wasn't doing this almost intentionally :-), so decided to add that cabability, cleaning the driver from a lot of unneeded code brought in during presumably very quick cut-and-pasting the driver from 8250.c: like handling of I/O port, ioremap() and PCMCIA cases which don't at all apply to Au1xx0 UARTs -- the KSEG1-mapped UART addresses are always taken from , so it was easy to get physical addresses back from them. WBR, Sergei Sighed-off-by: Sergei Shtylyov --------------060801020000050309040506 Content-Type: text/plain; name="au1x00_uart-claim-memory.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="au1x00_uart-claim-memory.patch" diff --git a/drivers/serial/au1x00_uart.c b/drivers/serial/au1x00_uart.c index 878e0f3..6f4acc9 100644 --- a/drivers/serial/au1x00_uart.c +++ b/drivers/serial/au1x00_uart.c @@ -12,12 +12,8 @@ * * A note about mapbase / membase * - * mapbase is the physical address of the IO port. Currently, we don't - * support this very well, and it may well be dropped from this driver - * in future. As such, mapbase should be NULL. - * - * membase is an 'ioremapped' cookie. This is compatible with the old - * serial.c driver, and is currently the preferred form. + * mapbase is the physical address of the IO port. + * membase is an 'ioremapped' cookie. */ #include #include @@ -157,9 +153,6 @@ static void autoconfig(struct uart_8250_ up->port.fifosize = uart_config[up->port.type].dfl_xmit_fifo_size; - if (up->port.type == PORT_UNKNOWN) - goto out; - /* * Reset the UART. */ @@ -171,7 +164,6 @@ static void autoconfig(struct uart_8250_ (void)serial_in(up, UART_RX); serial_outp(up, UART_IER, 0); - out: spin_unlock_irqrestore(&up->port.lock, flags); // restore_flags(flags); DEBUG_AUTOCONF("type=%s\n", uart_config[up->port.type].name); @@ -870,122 +862,35 @@ serial8250_pm(struct uart_port *port, un } } -/* - * Resource handling. This is complicated by the fact that resources - * depend on the port type. Maybe we should be claiming the standard - * 8250 ports, and then trying to get other resources as necessary? - */ -static int -serial8250_request_std_resource(struct uart_8250_port *up, struct resource **res) -{ - unsigned int size = 8 << up->port.regshift; - int ret = 0; - - switch (up->port.iotype) { - case SERIAL_IO_MEM: - if (up->port.mapbase) { - *res = request_mem_region(up->port.mapbase, size, "serial"); - if (!*res) - ret = -EBUSY; - } - break; - - case SERIAL_IO_HUB6: - case SERIAL_IO_PORT: - *res = request_region(up->port.iobase, size, "serial"); - if (!*res) - ret = -EBUSY; - break; - } - return ret; -} - - static void serial8250_release_port(struct uart_port *port) { struct uart_8250_port *up = (struct uart_8250_port *)port; - unsigned long start, offset = 0, size = 0; - - size <<= up->port.regshift; - - switch (up->port.iotype) { - case SERIAL_IO_MEM: - if (up->port.mapbase) { - /* - * Unmap the area. - */ - iounmap(up->port.membase); - up->port.membase = NULL; - - start = up->port.mapbase; - if (size) - release_mem_region(start + offset, size); - release_mem_region(start, 8 << up->port.regshift); - } - break; - - case SERIAL_IO_HUB6: - case SERIAL_IO_PORT: - start = up->port.iobase; - - if (size) - release_region(start + offset, size); - release_region(start + offset, 8 << up->port.regshift); - break; - - default: - break; - } + if (up->port.mapbase) + release_mem_region(up->port.mapbase, 0x100000); } static int serial8250_request_port(struct uart_port *port) { struct uart_8250_port *up = (struct uart_8250_port *)port; - struct resource *res = NULL, *res_rsa = NULL; - int ret = 0; - ret = serial8250_request_std_resource(up, &res); - - /* - * If we have a mapbase, then request that as well. - */ - if (ret == 0 && up->port.flags & UPF_IOREMAP) { - int size = res->end - res->start + 1; - - up->port.membase = ioremap(up->port.mapbase, size); - if (!up->port.membase) - ret = -ENOMEM; - } + if (up->port.mapbase && + request_mem_region(up->port.mapbase, 0x100000, "Au1x00 UART") == NULL) + return -EBUSY; - if (ret < 0) { - if (res_rsa) - release_resource(res_rsa); - if (res) - release_resource(res); - } - return ret; + return 0; } static void serial8250_config_port(struct uart_port *port, int flags) { struct uart_8250_port *up = (struct uart_8250_port *)port; - struct resource *res_std = NULL, *res_rsa = NULL; - int probeflags = PROBE_ANY; - probeflags &= ~PROBE_RSA; + if (up->port.mapbase && + request_mem_region(up->port.mapbase, 0x100000, "Au1x00 UART") == NULL) + return; if (flags & UART_CONFIG_TYPE) - autoconfig(up, probeflags); - - /* - * If the port wasn't an RSA port, release the resource. - */ - if (up->port.type != PORT_RSA && res_rsa) - release_resource(res_rsa); - - if (up->port.type == PORT_UNKNOWN && res_std) - release_resource(res_std); + autoconfig(up, PROBE_ANY); } static int @@ -1049,6 +954,7 @@ static void __init serial8250_isa_init_p up->port.flags = old_serial_port[i].flags; up->port.hub6 = old_serial_port[i].hub6; up->port.membase = old_serial_port[i].iomem_base; + up->port.mapbase = CPHYSADDR(up->port.membase); up->port.iotype = old_serial_port[i].io_type; up->port.regshift = old_serial_port[i].iomem_reg_shift; up->port.ops = &serial8250_pops; @@ -1226,30 +1132,6 @@ int __init early_serial_setup(struct uar return 0; } -/** - * serial8250_suspend_port - suspend one serial port - * @line: serial line number - * @level: the level of port suspension, as per uart_suspend_port - * - * Suspend one serial port. - */ -void serial8250_suspend_port(int line) -{ - uart_suspend_port(&serial8250_reg, &serial8250_ports[line].port); -} - -/** - * serial8250_resume_port - resume one serial port - * @line: serial line number - * @level: the level of port resumption, as per uart_resume_port - * - * Resume one serial port. - */ -void serial8250_resume_port(int line) -{ - uart_resume_port(&serial8250_reg, &serial8250_ports[line].port); -} - static int __init serial8250_init(void) { int ret, i; @@ -1279,8 +1161,5 @@ static void __exit serial8250_exit(void) module_init(serial8250_init); module_exit(serial8250_exit); -EXPORT_SYMBOL(serial8250_suspend_port); -EXPORT_SYMBOL(serial8250_resume_port); - MODULE_LICENSE("GPL"); MODULE_DESCRIPTION("Au1x00 serial driver\n"); --------------060801020000050309040506-- From ppopov@embeddedalley.com Fri Dec 30 20:34:57 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 30 Dec 2005 20:35:15 +0000 (GMT) Received: from smtp101.biz.mail.mud.yahoo.com ([68.142.200.236]:47715 "HELO smtp101.biz.mail.mud.yahoo.com") by ftp.linux-mips.org with SMTP id S8133373AbVL3Ue5 (ORCPT ); Fri, 30 Dec 2005 20:34:57 +0000 Received: (qmail 77741 invoked from network); 30 Dec 2005 20:36:54 -0000 Received: from unknown (HELO ?192.168.1.110?) (ppopov@embeddedalley.com@71.128.175.242 with plain) by smtp101.biz.mail.mud.yahoo.com with SMTP; 30 Dec 2005 20:36:53 -0000 Subject: Re: [PATCH] AMD Au1xx0 serial: claim the memory resource From: Pete Popov Reply-To: ppopov@embeddedalley.com To: Sergei Shtylylov Cc: rmk+serial@arm.linux.org.uk, Manish Lachwani , Linux MIPS , Jordan Crouse In-Reply-To: <43B58548.4050208@ru.mvista.com> References: <43B58548.4050208@ru.mvista.com> Content-Type: text/plain Organization: Embedded Alley Solutions, Inc Date: Fri, 30 Dec 2005 12:36:36 -0800 Message-Id: <1135974996.7848.117.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.0.4 (2.0.4-4) 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: 9758 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 Content-Length: 7199 Lines: 246 I think the new 8250 based driver is already upstream so this one should be nuked anyway at some point. Pete On Fri, 2005-12-30 at 22:06 +0300, Sergei Shtylylov wrote: > Hello. > > We've noticed that Au1x00 UART driver (drivers/serial/au1x00_uart.c) > wasn't claiming its memory resources (in fact, as the heading comment had it, > it wasn't doing this almost intentionally :-), so decided to add that > cabability, cleaning the driver from a lot of unneeded code brought in during > presumably very quick cut-and-pasting the driver from 8250.c: like handling of > I/O port, ioremap() and PCMCIA cases which don't at all apply to Au1xx0 UARTs > -- the KSEG1-mapped UART addresses are always taken from , > so it was easy to get physical addresses back from them. > > WBR, Sergei > > Sighed-off-by: Sergei Shtylyov > > > plain text document attachment (au1x00_uart-claim-memory.patch) > diff --git a/drivers/serial/au1x00_uart.c b/drivers/serial/au1x00_uart.c > index 878e0f3..6f4acc9 100644 > --- a/drivers/serial/au1x00_uart.c > +++ b/drivers/serial/au1x00_uart.c > @@ -12,12 +12,8 @@ > * > * A note about mapbase / membase > * > - * mapbase is the physical address of the IO port. Currently, we don't > - * support this very well, and it may well be dropped from this driver > - * in future. As such, mapbase should be NULL. > - * > - * membase is an 'ioremapped' cookie. This is compatible with the old > - * serial.c driver, and is currently the preferred form. > + * mapbase is the physical address of the IO port. > + * membase is an 'ioremapped' cookie. > */ > #include > #include > @@ -157,9 +153,6 @@ static void autoconfig(struct uart_8250_ > > up->port.fifosize = uart_config[up->port.type].dfl_xmit_fifo_size; > > - if (up->port.type == PORT_UNKNOWN) > - goto out; > - > /* > * Reset the UART. > */ > @@ -171,7 +164,6 @@ static void autoconfig(struct uart_8250_ > (void)serial_in(up, UART_RX); > serial_outp(up, UART_IER, 0); > > - out: > spin_unlock_irqrestore(&up->port.lock, flags); > // restore_flags(flags); > DEBUG_AUTOCONF("type=%s\n", uart_config[up->port.type].name); > @@ -870,122 +862,35 @@ serial8250_pm(struct uart_port *port, un > } > } > > -/* > - * Resource handling. This is complicated by the fact that resources > - * depend on the port type. Maybe we should be claiming the standard > - * 8250 ports, and then trying to get other resources as necessary? > - */ > -static int > -serial8250_request_std_resource(struct uart_8250_port *up, struct resource **res) > -{ > - unsigned int size = 8 << up->port.regshift; > - int ret = 0; > - > - switch (up->port.iotype) { > - case SERIAL_IO_MEM: > - if (up->port.mapbase) { > - *res = request_mem_region(up->port.mapbase, size, "serial"); > - if (!*res) > - ret = -EBUSY; > - } > - break; > - > - case SERIAL_IO_HUB6: > - case SERIAL_IO_PORT: > - *res = request_region(up->port.iobase, size, "serial"); > - if (!*res) > - ret = -EBUSY; > - break; > - } > - return ret; > -} > - > - > static void serial8250_release_port(struct uart_port *port) > { > struct uart_8250_port *up = (struct uart_8250_port *)port; > - unsigned long start, offset = 0, size = 0; > - > - size <<= up->port.regshift; > - > - switch (up->port.iotype) { > - case SERIAL_IO_MEM: > - if (up->port.mapbase) { > - /* > - * Unmap the area. > - */ > - iounmap(up->port.membase); > - up->port.membase = NULL; > - > - start = up->port.mapbase; > > - if (size) > - release_mem_region(start + offset, size); > - release_mem_region(start, 8 << up->port.regshift); > - } > - break; > - > - case SERIAL_IO_HUB6: > - case SERIAL_IO_PORT: > - start = up->port.iobase; > - > - if (size) > - release_region(start + offset, size); > - release_region(start + offset, 8 << up->port.regshift); > - break; > - > - default: > - break; > - } > + if (up->port.mapbase) > + release_mem_region(up->port.mapbase, 0x100000); > } > > static int serial8250_request_port(struct uart_port *port) > { > struct uart_8250_port *up = (struct uart_8250_port *)port; > - struct resource *res = NULL, *res_rsa = NULL; > - int ret = 0; > > - ret = serial8250_request_std_resource(up, &res); > - > - /* > - * If we have a mapbase, then request that as well. > - */ > - if (ret == 0 && up->port.flags & UPF_IOREMAP) { > - int size = res->end - res->start + 1; > - > - up->port.membase = ioremap(up->port.mapbase, size); > - if (!up->port.membase) > - ret = -ENOMEM; > - } > + if (up->port.mapbase && > + request_mem_region(up->port.mapbase, 0x100000, "Au1x00 UART") == NULL) > + return -EBUSY; > > - if (ret < 0) { > - if (res_rsa) > - release_resource(res_rsa); > - if (res) > - release_resource(res); > - } > - return ret; > + return 0; > } > > static void serial8250_config_port(struct uart_port *port, int flags) > { > struct uart_8250_port *up = (struct uart_8250_port *)port; > - struct resource *res_std = NULL, *res_rsa = NULL; > - int probeflags = PROBE_ANY; > > - probeflags &= ~PROBE_RSA; > + if (up->port.mapbase && > + request_mem_region(up->port.mapbase, 0x100000, "Au1x00 UART") == NULL) > + return; > > if (flags & UART_CONFIG_TYPE) > - autoconfig(up, probeflags); > - > - /* > - * If the port wasn't an RSA port, release the resource. > - */ > - if (up->port.type != PORT_RSA && res_rsa) > - release_resource(res_rsa); > - > - if (up->port.type == PORT_UNKNOWN && res_std) > - release_resource(res_std); > + autoconfig(up, PROBE_ANY); > } > > static int > @@ -1049,6 +954,7 @@ static void __init serial8250_isa_init_p > up->port.flags = old_serial_port[i].flags; > up->port.hub6 = old_serial_port[i].hub6; > up->port.membase = old_serial_port[i].iomem_base; > + up->port.mapbase = CPHYSADDR(up->port.membase); > up->port.iotype = old_serial_port[i].io_type; > up->port.regshift = old_serial_port[i].iomem_reg_shift; > up->port.ops = &serial8250_pops; > @@ -1226,30 +1132,6 @@ int __init early_serial_setup(struct uar > return 0; > } > > -/** > - * serial8250_suspend_port - suspend one serial port > - * @line: serial line number > - * @level: the level of port suspension, as per uart_suspend_port > - * > - * Suspend one serial port. > - */ > -void serial8250_suspend_port(int line) > -{ > - uart_suspend_port(&serial8250_reg, &serial8250_ports[line].port); > -} > - > -/** > - * serial8250_resume_port - resume one serial port > - * @line: serial line number > - * @level: the level of port resumption, as per uart_resume_port > - * > - * Resume one serial port. > - */ > -void serial8250_resume_port(int line) > -{ > - uart_resume_port(&serial8250_reg, &serial8250_ports[line].port); > -} > - > static int __init serial8250_init(void) > { > int ret, i; > @@ -1279,8 +1161,5 @@ static void __exit serial8250_exit(void) > module_init(serial8250_init); > module_exit(serial8250_exit); > > -EXPORT_SYMBOL(serial8250_suspend_port); > -EXPORT_SYMBOL(serial8250_resume_port); > - > MODULE_LICENSE("GPL"); > MODULE_DESCRIPTION("Au1x00 serial driver\n"); > > > From sshtylyov@ru.mvista.com Fri Dec 30 20:37:44 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 30 Dec 2005 20:38:02 +0000 (GMT) Received: from rtsoft2.corbina.net ([85.21.88.2]:21404 "HELO mail.dev.rtsoft.ru") by ftp.linux-mips.org with SMTP id S8133656AbVL3Uho (ORCPT ); Fri, 30 Dec 2005 20:37:44 +0000 Received: (qmail 32235 invoked from network); 30 Dec 2005 20:39:48 -0000 Received: from wasted.dev.rtsoft.ru (HELO ?192.168.1.248?) (192.168.1.248) by mail.dev.rtsoft.ru with SMTP; 30 Dec 2005 20:39:48 -0000 Message-ID: <43B59BA2.2090805@ru.mvista.com> Date: Fri, 30 Dec 2005 23:42:10 +0300 From: Sergei Shtylylov Organization: MostaVista 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: ppopov@embeddedalley.com CC: rmk+serial@arm.linux.org.uk, Manish Lachwani , Linux MIPS , Jordan Crouse Subject: Re: [PATCH] AMD Au1xx0 serial: claim the memory resource References: <43B58548.4050208@ru.mvista.com> <1135974996.7848.117.camel@localhost.localdomain> In-Reply-To: <1135974996.7848.117.camel@localhost.localdomain> 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: 9759 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 Content-Length: 233 Lines: 11 Hello. Pete Popov wrote: > I think the new 8250 based driver is already upstream so this one should > be nuked anyway at some point. I only knew of its existence yesterday -- I'm using 2.6.10 kernel :-) > Pete WBR, Sergei From ths@networkno.de Fri Dec 30 21:02:29 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 30 Dec 2005 21:02:46 +0000 (GMT) Received: from mx01.qsc.de ([213.148.129.14]:7873 "EHLO mx01.qsc.de") by ftp.linux-mips.org with ESMTP id S8133656AbVL3VC3 (ORCPT ); Fri, 30 Dec 2005 21:02:29 +0000 Received: from port-195-158-168-159.dynamic.qsc.de ([195.158.168.159] helo=hattusa.textio) by mx01.qsc.de with esmtp (Exim 3.35 #1) id 1EsRQO-00009w-00; Fri, 30 Dec 2005 22:04:32 +0100 Received: from ths by hattusa.textio with local (Exim 4.60) (envelope-from ) id 1EsRQJ-0008WP-5T; Fri, 30 Dec 2005 22:04:27 +0100 Date: Fri, 30 Dec 2005 22:04:27 +0100 To: Adil Hafeez Cc: linux-mips@linux-mips.org Subject: Re: Fixed kernel entry point suggestion Message-ID: <20051230210427.GJ1882@hattusa.textio> References: <82e4189c0512272336xed0fe2ax9fee6119ea2d6b00@mail.gmail.com> <06af7c9f9f82dd2b306e02997869e709@embeddedalley.com> <82e4189c0512300136w5112edf2kf3d243ddbc9313d@mail.gmail.com> <20051230094750.GI1882@hattusa.textio> <82e4189c0512300222k426764e0ldefeafb232ad36d@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <82e4189c0512300222k426764e0ldefeafb232ad36d@mail.gmail.com> User-Agent: Mutt/1.5.11 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: 9760 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 Content-Length: 733 Lines: 25 Adil Hafeez wrote: > What about placing the jump instruction just after reserved space, like this > > .text > /* > * Reserved space for exception handlers. > * Necessary for machines which link their kernels at KSEG0. > */ > .fill 0x400 > > /* The following two symbols are used for kernel profiling. */ > EXPORT(stext) > EXPORT(_stext) > => j kernel_entry > __INIT > > I disassembled vmlinux binary and now jump instruction is placed after > reserved space This only works iff the fill is done with NOPs. On a more general note, it is usually considered to be the bootloader's job to find the correct entry, not the kernel's one. Thiemo From sshtylyov@ru.mvista.com Fri Dec 30 23:03:40 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 30 Dec 2005 23:03:58 +0000 (GMT) Received: from rtsoft2.corbina.net ([85.21.88.2]:29344 "HELO mail.dev.rtsoft.ru") by ftp.linux-mips.org with SMTP id S8133593AbVL3XDk (ORCPT ); Fri, 30 Dec 2005 23:03:40 +0000 Received: (qmail 774 invoked from network); 30 Dec 2005 23:05:37 -0000 Received: from wasted.dev.rtsoft.ru (HELO ?192.168.1.248?) (192.168.1.248) by mail.dev.rtsoft.ru with SMTP; 30 Dec 2005 23:05:37 -0000 Message-ID: <43B5BDCF.7010900@ru.mvista.com> Date: Sat, 31 Dec 2005 02:07:59 +0300 From: Sergei Shtylylov Organization: MostaVista 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: Andrew Morton CC: Linux MIPS Development , Jordan Crouse , ralf@linux-mips.org Subject: [PATCH] Au1xx0: replace casual readl() with au_readl() in the drivers References: <43452054.2090305@ru.mvista.com> <436FB1DE.6010405@ru.mvista.com> In-Reply-To: <436FB1DE.6010405@ru.mvista.com> Content-Type: multipart/mixed; boundary="------------060507020306000301020709" 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: 9761 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 Content-Length: 3192 Lines: 106 This is a multi-part message in MIME format. --------------060507020306000301020709 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hello, I wrote: >> We have found some issues with Au1550 AC'97 OSS driver in 2.6 >> (sound/oss/au1550_ac97.c), though it also should concern 2.4 driver >> (drivers/sound/au1550_psc.c). >> First, we don't think that using readl() calls instead of >> au_readl() is >> correct -- readl() is subject to byte-swapping etc., so may not work in >> BE mode anymore and au_readl() is intended for embedded Au1550 devices >> for which the byte swapping issue is resolved automagically, and BTW the same >> PSC_AC97STAT register is read "both ways" in the driver. [skipped] Additionally, I've found one unjustified call to readl() in the Au1xx0 USB code, so adding the fix for it to the patch. Andrew, I'm sending the patch to you as was advised by Ralf and Jordan... WBR, Sergei --------------060507020306000301020709 Content-Type: text/plain; name="Au1xx0-use-au_readl.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="Au1xx0-use-au_readl.patch" diff --git a/drivers/usb/host/ohci-au1xxx.c b/drivers/usb/host/ohci-au1xxx.c index 486202d..0fc728e 100644 --- a/drivers/usb/host/ohci-au1xxx.c +++ b/drivers/usb/host/ohci-au1xxx.c @@ -66,7 +66,7 @@ static void au1xxx_stop_hc(struct platfo ": stopping Au1xxx OHCI USB Controller\n"); /* Disable clock */ - au_writel(readl((void *)USB_HOST_CONFIG) & ~USBH_ENABLE_CE, USB_HOST_CONFIG); + au_writel(au_readl(USB_HOST_CONFIG) & ~USBH_ENABLE_CE, USB_HOST_CONFIG); } diff --git a/sound/oss/au1550_ac97.c b/sound/oss/au1550_ac97.c index f70effd..64e2e46 100644 --- a/sound/oss/au1550_ac97.c +++ b/sound/oss/au1550_ac97.c @@ -463,7 +463,7 @@ stop_dac(struct au1550_state *s) /* Wait for Transmit Busy to show disabled. */ do { - stat = readl((void *)PSC_AC97STAT); + stat = au_readl(PSC_AC97STAT); au_sync(); } while ((stat & PSC_AC97STAT_TB) != 0); @@ -492,7 +492,7 @@ stop_adc(struct au1550_state *s) /* Wait for Receive Busy to show disabled. */ do { - stat = readl((void *)PSC_AC97STAT); + stat = au_readl(PSC_AC97STAT); au_sync(); } while ((stat & PSC_AC97STAT_RB) != 0); @@ -542,7 +542,7 @@ set_xmit_slots(int num_channels) /* Wait for Device ready. */ do { - stat = readl((void *)PSC_AC97STAT); + stat = au_readl(PSC_AC97STAT); au_sync(); } while ((stat & PSC_AC97STAT_DR) == 0); } @@ -574,7 +574,7 @@ set_recv_slots(int num_channels) /* Wait for Device ready. */ do { - stat = readl((void *)PSC_AC97STAT); + stat = au_readl(PSC_AC97STAT); au_sync(); } while ((stat & PSC_AC97STAT_DR) == 0); } @@ -1996,7 +1996,7 @@ au1550_probe(void) /* Wait for PSC ready. */ do { - val = readl((void *)PSC_AC97STAT); + val = au_readl(PSC_AC97STAT); au_sync(); } while ((val & PSC_AC97STAT_SR) == 0); @@ -2019,7 +2019,7 @@ au1550_probe(void) /* Wait for Device ready. */ do { - val = readl((void *)PSC_AC97STAT); + val = au_readl(PSC_AC97STAT); au_sync(); } while ((val & PSC_AC97STAT_DR) == 0); --------------060507020306000301020709-- From jcrouse@cosmic.amd.com Sat Dec 31 04:04:03 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 31 Dec 2005 04:04:25 +0000 (GMT) Received: from amdext4.amd.com ([163.181.251.6]:28341 "EHLO amdext4.amd.com") by ftp.linux-mips.org with ESMTP id S8133373AbVLaEED (ORCPT ); Sat, 31 Dec 2005 04:04:03 +0000 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 jBV45vtJ018947; Fri, 30 Dec 2005 22:06:02 -0600 Received: from 163.181.250.1 by SAUSGW02.amd.com with ESMTP (AMD SMTP Relay (Email Firewall v6.1.0)); Fri, 30 Dec 2005 22:05:51 -0600 X-Server-Uuid: 5FC0E2DF-CD44-48CD-883A-0ED95B391E89 Received: from ldcmail.amd.com (ldcmail.amd.com [147.5.200.40]) by amdint2.amd.com (8.12.8/8.12.8/AMD) with ESMTP id jBV45oh5001854; Fri, 30 Dec 2005 22:05:50 -0600 (CST) Received: from cosmic.amd.com (cosmic.amd.com [147.5.201.206]) by ldcmail.amd.com (Postfix) with ESMTP id 01F262028; Fri, 30 Dec 2005 21:05:50 -0700 (MST) Received: from cosmic.amd.com (localhost [127.0.0.1]) by cosmic.amd.com (8.13.4/8.13.4) with ESMTP id jBV4Btwo005529; Fri, 30 Dec 2005 21:11:55 -0700 Received: (from jcrouse@localhost) by cosmic.amd.com ( 8.13.4/8.13.4/Submit) id jBV4BtJU005528; Fri, 30 Dec 2005 21:11:55 -0700 Date: Fri, 30 Dec 2005 21:11:55 -0700 From: "Jordan Crouse" To: "Sergei Shtylylov" cc: "Andrew Morton" , "Linux MIPS Development" , ralf@linux-mips.org Subject: Re: Au1xx0: replace casual readl() with au_readl() in the drivers Message-ID: <20051231041155.GA5422@cosmic.amd.com> References: <43452054.2090305@ru.mvista.com> <436FB1DE.6010405@ru.mvista.com> <43B5BDCF.7010900@ru.mvista.com> MIME-Version: 1.0 In-Reply-To: <43B5BDCF.7010900@ru.mvista.com> User-Agent: Mutt/1.5.11 X-WSS-ID: 6FA8DC150T0670651-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: 9762 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 Content-Length: 3181 Lines: 106 Acked-by: Jordan CRouse On 31/12/05 02:07 +0300, Sergei Shtylylov wrote: > Hello, I wrote: > > >> We have found some issues with Au1550 AC'97 OSS driver in 2.6 > >>(sound/oss/au1550_ac97.c), though it also should concern 2.4 driver > >>(drivers/sound/au1550_psc.c). > >> First, we don't think that using readl() calls instead of > >>au_readl() is > >>correct -- readl() is subject to byte-swapping etc., so may not work in > >>BE mode anymore and au_readl() is intended for embedded Au1550 devices > >>for which the byte swapping issue is resolved automagically, and BTW the > >>same > >>PSC_AC97STAT register is read "both ways" in the driver. > > [skipped] > > Additionally, I've found one unjustified call to readl() in the Au1xx0 > USB > code, so adding the fix for it to the patch. Andrew, I'm sending the patch > to > you as was advised by Ralf and Jordan... > > WBR, Sergei > > diff --git a/drivers/usb/host/ohci-au1xxx.c b/drivers/usb/host/ohci-au1xxx.c > index 486202d..0fc728e 100644 > --- a/drivers/usb/host/ohci-au1xxx.c > +++ b/drivers/usb/host/ohci-au1xxx.c > @@ -66,7 +66,7 @@ static void au1xxx_stop_hc(struct platfo > ": stopping Au1xxx OHCI USB Controller\n"); > > /* Disable clock */ > - au_writel(readl((void *)USB_HOST_CONFIG) & ~USBH_ENABLE_CE, USB_HOST_CONFIG); > + au_writel(au_readl(USB_HOST_CONFIG) & ~USBH_ENABLE_CE, USB_HOST_CONFIG); > } > > > diff --git a/sound/oss/au1550_ac97.c b/sound/oss/au1550_ac97.c > index f70effd..64e2e46 100644 > --- a/sound/oss/au1550_ac97.c > +++ b/sound/oss/au1550_ac97.c > @@ -463,7 +463,7 @@ stop_dac(struct au1550_state *s) > /* Wait for Transmit Busy to show disabled. > */ > do { > - stat = readl((void *)PSC_AC97STAT); > + stat = au_readl(PSC_AC97STAT); > au_sync(); > } while ((stat & PSC_AC97STAT_TB) != 0); > > @@ -492,7 +492,7 @@ stop_adc(struct au1550_state *s) > /* Wait for Receive Busy to show disabled. > */ > do { > - stat = readl((void *)PSC_AC97STAT); > + stat = au_readl(PSC_AC97STAT); > au_sync(); > } while ((stat & PSC_AC97STAT_RB) != 0); > > @@ -542,7 +542,7 @@ set_xmit_slots(int num_channels) > /* Wait for Device ready. > */ > do { > - stat = readl((void *)PSC_AC97STAT); > + stat = au_readl(PSC_AC97STAT); > au_sync(); > } while ((stat & PSC_AC97STAT_DR) == 0); > } > @@ -574,7 +574,7 @@ set_recv_slots(int num_channels) > /* Wait for Device ready. > */ > do { > - stat = readl((void *)PSC_AC97STAT); > + stat = au_readl(PSC_AC97STAT); > au_sync(); > } while ((stat & PSC_AC97STAT_DR) == 0); > } > @@ -1996,7 +1996,7 @@ au1550_probe(void) > /* Wait for PSC ready. > */ > do { > - val = readl((void *)PSC_AC97STAT); > + val = au_readl(PSC_AC97STAT); > au_sync(); > } while ((val & PSC_AC97STAT_SR) == 0); > > @@ -2019,7 +2019,7 @@ au1550_probe(void) > /* Wait for Device ready. > */ > do { > - val = readl((void *)PSC_AC97STAT); > + val = au_readl(PSC_AC97STAT); > au_sync(); > } while ((val & PSC_AC97STAT_DR) == 0); > -- Jordan Crouse Senior Linux Engineer AMD - Personal Connectivity Solutions Group