* Re: Serial console problem on MPC8272ADS board
From: Vitaly Bordug @ 2005-02-01 17:10 UTC (permalink / raw)
To: ning; +Cc: linuxppc-embedded
In-Reply-To: <20050128100238.27631.qmail@web606.mail.yahoo.co.jp>
ning wrote:
>Hello,Vitaly
>
>Thanks for your reply.
>
>I added SCC4 to rs_table as following:
>static struct serial_state rs_table[] = {
> /* UART CLK PORT IRQ FLAGS NUM */
> { 0, 0, PROFF_SCC1, SIU_INT_SCC1, 0, (0 |
>NUM_IS_SCC) }, /* SCC1 ttyS0 */
> { 0, 0, PROFF_SCC4, SIU_INT_SCC4, 0, (3 |
>NUM_IS_SCC) }, /* SCC4 ttyS1 */
>};
>
>ttyS0,ttyS1 work as COM port,but linux boot log only is
>outputed at ttyS0,how can I redirect it at ttyS1?
>After linux boots successfully,linux prompt will display
>at ttyS1,and I use it normally.
>(u-boot parameter: setenv bootargs root=/dev/nfs rw
>console=ttyS1,115200n8
>rootfs: /dev/console --> ttyS1)
>
>at \arch\ppc\boot\simple\m8260_tty.c,Even if I define
>SCC_CONSOLE to 4,Linux boot log is outputed at ttyS0.
>the following comment is written at m8260_tty.c:
>
>/* If defined, enables serial console. The value (1
>through 4) should designate which SCC is used, but this
>isn't complete. Only SCC1 is known to work at this time.
>*/
>
>#ifdef CONFIG_SCC_CONSOLE
>#define SCC_CONSOLE 4
>#endif
>
>
>Maybe it is true.
>
>
Well, I can only advice to try linuxppc_2_4 or -2.4 repositories, adding
bits to support SCC4 console and so on...
--
Regards,
Vitaly
^ permalink raw reply
* Re[2]: [linux-cirrus] Re: Cirrus Logic MaverickCrunch support
From: Bora Þahin @ 2005-02-01 18:19 UTC (permalink / raw)
To: Matt Porter; +Cc: linuxppc-embedded
In-Reply-To: <20050201093352.A30421@cox.net>
Hi,
Matt> Even then, this depends completely on what else the platform has to
Matt> do as well as what profile/level of MPEG-2 you are decoding. Something
Matt> like a ~800Mhz e500 core has no chance of handling a main profile high
Matt> level MPEG-2 stream for playback (typically 720p/1080i video). A high-end
Matt> (1.45Ghzish) 7457 with an optimized altivec mpeg2 software decode library
Matt> and a video card with iDCT assist is about the minimum PPC for these
Matt> applications.
It is not that quality. I dont know decoding algoritms. But I have a film encoded bu Xvid.
Video Codec
Aspect ratio: 592 x 320 (1.850 : 1)
Frame/Sec : 25
Avg Bitrate : 1175 kb/s
I think quality is sufficiently enough. My Celeron 466/440 BX buddy does a good job.
Matt> This is why most consumer products are using something with a decoder,
Matt> like the integrated one in the IBM STBxxxx chips or
I am looking for probable and reasonable powerful cpu based solutions without going in that
direction...
Matt> the Sigma Designs decoders.
AFAIK, it does not support PPC platform...
--
Bora SAHIN
^ permalink raw reply
* Re: Testing ISP1362 USB network device driver.
From: Wolfgang Denk @ 2005-02-01 22:45 UTC (permalink / raw)
To: David Ho; +Cc: linuxppc-embedded
In-Reply-To: <OFAA7E66FB.78AF3A29-ON85256F9B.005B85BD-85256F9B.005C32E2@nanometrics.ca>
Dear David,
in message <OFAA7E66FB.78AF3A29-ON85256F9B.005B85BD-85256F9B.005C32E2@nanometrics.ca> you wrote:
>
> I'm testing the device side of the ISP1362 using your USB network driver.
> I can get a PC to enumerate with the 1362 but then I don't have a windows
> driver to route IP traffic to it. I'm just curious how you test the
> driver? Do you have a Linux host side driver to communicate with the 1362
> as a USB NIC device?
We used a standard Linux PC with the "usbnet" driver (at the time of
our tests under RH-7.1 running kernel version 2.4.20-19.7); our
customer also verified operation using the Bahia Network Driver
release 0.9beta under Windows XP (we couldn't do these tests as we're
a 100% M$-free company :-).
^ permalink raw reply
* [PATCH][PPC32] include/asm-ppc/rwsem.h RWSEM_DEBUG usage
From: Mark A. Greer @ 2005-02-01 23:53 UTC (permalink / raw)
To: akpm; +Cc: Linux/PPC Development
[-- Attachment #1: Type: text/plain, Size: 292 bytes --]
include/asm-ppc/rwsem.h has '#ifdef RWSEM_DEBUG' but RWSEM_DEBUG is
always defined (as 0) in include/linux/rwsem.h. The #ifdef's should be
#if's. This also brings the ppc usage in line with the the other
architectures.
Please apply.
Signed-off-by: Mark A. Greer <mgreer@mvista.com>
--
[-- Attachment #2: rwsem.patch --]
[-- Type: text/plain, Size: 740 bytes --]
diff -Nru a/include/asm-ppc/rwsem.h b/include/asm-ppc/rwsem.h
--- a/include/asm-ppc/rwsem.h 2005-02-01 16:46:53 -07:00
+++ b/include/asm-ppc/rwsem.h 2005-02-01 16:46:53 -07:00
@@ -27,7 +27,7 @@
#define RWSEM_ACTIVE_WRITE_BIAS (RWSEM_WAITING_BIAS + RWSEM_ACTIVE_BIAS)
spinlock_t wait_lock;
struct list_head wait_list;
-#ifdef RWSEM_DEBUG
+#if RWSEM_DEBUG
int debug;
#endif
};
@@ -35,7 +35,7 @@
/*
* initialisation
*/
-#ifdef RWSEM_DEBUG
+#if RWSEM_DEBUG
#define __RWSEM_DEBUG_INIT , 0
#else
#define __RWSEM_DEBUG_INIT /* */
@@ -59,7 +59,7 @@
sem->count = RWSEM_UNLOCKED_VALUE;
spin_lock_init(&sem->wait_lock);
INIT_LIST_HEAD(&sem->wait_list);
-#ifdef RWSEM_DEBUG
+#if RWSEM_DEBUG
sem->debug = 0;
#endif
}
^ permalink raw reply
* Re: [PATCH][NET] Add PPC440SP support to IBM EMAC driver
From: Jeff Garzik @ 2005-02-02 5:29 UTC (permalink / raw)
To: Matt Porter; +Cc: akpm, netdev, linuxppc-embedded
In-Reply-To: <20050131171009.F25809@cox.net>
applied
^ permalink raw reply
* AW: The RS485 driver problem...
From: Martin Krause @ 2005-02-02 8:27 UTC (permalink / raw)
To: David Jander, linuxppc-embedded
Hi David,
linuxppc-embedded-bounces@ozlabs.org wrote on :
> If you want to connect a RS485 transceiver to a normal UART, you
> always have the problem of dealing with enabling/disabling
> transmitter and recveiver. I have seen hardware that misuses RS-232
> hardware handshaking lines (RTS/CTS) for this purpose. What I have
> not been able to find is a linux driver or software solution to this
> problem.=20
>=20
> Has anybody used the CPM uarts (or even a standard 16C550 uart) for
> this purpose? How?
Yes, we used normal UARTs several times to form a RS485 interface. It=20
is a bit tricky, because you must disable the transmitter just in time
after the last bit of a message has been left the transmit shift
register. Otherwise the answer from the addressed bus node could be
(partly) overwritten. It depends on your bus protocol how much time
you could afford to disable the transmitter. Since linux is not a
real time OS, and the transmitter is controlled by software (we use
an GPIO for this), there is no guarantee that this works under all
circumstances fast enough.
For us it is working well with a baudrate of 38.400 und a maximum
time of < 400 us to disable the transmitter after sending a message.=20
We used a 16752 UART. The driver could be found in the 'linuxarm'=20
kernel tree on the Denx CVS server (look at www.denx.de). If you=20
couldn't use CVS I could send you the driver sources directly.
Regards,
Martin
^ permalink raw reply
* Getty prob solved, problem with Telnetd persists
From: Vijay Padiyar @ 2005-02-02 10:55 UTC (permalink / raw)
To: Embedded TUX, LinuxPPC Support, BusyBox Support
Hi all
With reference to my mail to this list yesterday, the Getty problem has been
solved. It was due to a mistake we made in writing /etc/inittab. Our
original inittab was:
ttyCPM::once:/bin/sh
..
ttyCPM::once:/sbin/getty -L 57600 ttyCPM
This was causing the problem described earlier. It didn't strike us that we
don't need to call the shell when we're calling getty, as it'll call the
appropriate shell on its own after user authentication. We commented out the
first ttyCPM line and now all is fine.
However, the Telnetd problem still persists. When I do a ls -l on a
directory with several contents, the remote telnet terminal gets _stuck_ and
there's no way to recover except to either close the telnet terminal window
or kill the shell application on the target running telnetd.
What could the problem be? Please advise.
I would also like to point out a problem with BusyBox 1.00. I have enabled
the DEVPTS file system in Linux and have enabled support for it in BusyBox.
This means that CONFIG_FEATURE_DEVPTS is enabled and defined in config.h in
the include subfolder inside the BusyBox source directory. However, the
following code still doesn't get compiled:
#ifdef CONFIG_FEATURE_DEVPTS
p = open("/dev/ptmx", 2);
if (p > 0) {
grantpt(p);
unlockpt(p);
strcpy(line, ptsname(p));
return(p);
}
#else
..
I had to resolve the issue by explicitly including the config.h file from
telnetd.c, by adding the following line:
#include <config.h>
I don't know if there are similar problems with other headers that don't
take effect.
However, the problem of the terminal getting stuck still persists. Please
guide me as to what I need to change.
Regards
Vijay Padiyar
^ permalink raw reply
* Re: Serial console problem on MPC8272ADS board
From: Jeff Angielski @ 2005-02-02 12:28 UTC (permalink / raw)
To: ning; +Cc: linuxppc-embedded
In-Reply-To: <20050128100238.27631.qmail@web606.mail.yahoo.co.jp>
On Fri, 2005-01-28 at 05:02, ning wrote:
> I added SCC4 to rs_table as following:
> static struct serial_state rs_table[] = {
> /* UART CLK PORT IRQ FLAGS NUM */
> { 0, 0, PROFF_SCC1, SIU_INT_SCC1, 0, (0 |
> NUM_IS_SCC) }, /* SCC1 ttyS0 */
> { 0, 0, PROFF_SCC4, SIU_INT_SCC4, 0, (3 |
> NUM_IS_SCC) }, /* SCC4 ttyS1 */
> };
Did you configure the SCC4 I/O pins correctly?
Have you programmed the BRGs correctly? Does it match what is routed to
SCC4 in the CMX registers?
When booting using SCC1 as the console, can you read and write data
using SCC4? If not, you should get this working and then worry about
configuring it as the console.
Jeff Angielski
The PTR Group
^ permalink raw reply
* 2.6.10-rc3 8xx (MPC 880) i2c driver - "about to sleep"
From: Alex @ 2005-02-02 12:38 UTC (permalink / raw)
To: linuxppc-dev, 'linuxppc-embedded
Hi,
Sorry for bothering you again - I will appreciate your opinion/advise/guidance !
What is your interpretation of entries I found in the log buf with regards to I2C driver ?
.....
<6>i2c /dev entries driver.
<7>device class 'i2c-dev': registering.
<7>bus i2c:add driver dev_driver.
<7>i2c-core: driver dev_driver registered
<6>i2c-rpx: i2c MPC8xx driver.
<7>DEV: registering device: ID ='i2c-0'.
<7>CLASS: registering class device: ID= 'i2c-0'.
<7>i2c_adapter i2c-0:Registered as minor 0.
<7>CLASS:registering class device: ID = 'i2c-0'
<7>i2c_adapter i2c-0: registered as adapter #0.
<4>cpm_iic_init() - iip=fa203c80.
<4>cpm_iic_init[132] Install ISR for IRQ 16.
<6>CPM interrupt c0105d90 replacing c01f7a8c.
<3>request_irq() returned -22 for CPM vector 32.
<6> i2c-algo-8xx.o: scanning bus m8xx........
<4>cpm_iic_tryaddress(cpm=c019b9f8,addr=0).
<4>iip fa203c80, dp_addr 0x800.
<4>iic_tbase 2048, r_tbase 2048
<4>about to sleep
........
BOOTING HANGS FROM HERE !!!!
The board is equipped with M24Cxx-x Serial I2C bus EEPROM
- does above means that the EEPROM device was not detected on the I2C bus ?
Do I need to supply in the code the addresses to be scanned ?
Thanks,
Alex
___________________________________________________________________
Speed up your surfing with Juno SpeedBand.
Now includes pop-up blocker!
Only $14.95/month -visit http://www.juno.com/surf to sign up today!
^ permalink raw reply
* 2.6.10-rc3 8xx (MPC 880) i2c driver - "about to sleep"
From: Alex @ 2005-02-02 12:42 UTC (permalink / raw)
To: linuxppc-embedded
Hi,
Sorry for bothering you again - I will appreciate your opinion/advise/guidance !
What is your interpretation of entries I found in the log buf with regards to I2C driver ?
.....
<6>i2c /dev entries driver.
<7>device class 'i2c-dev': registering.
<7>bus i2c:add driver dev_driver.
<7>i2c-core: driver dev_driver registered
<6>i2c-rpx: i2c MPC8xx driver.
<7>DEV: registering device: ID ='i2c-0'.
<7>CLASS: registering class device: ID= 'i2c-0'.
<7>i2c_adapter i2c-0:Registered as minor 0.
<7>CLASS:registering class device: ID = 'i2c-0'
<7>i2c_adapter i2c-0: registered as adapter #0.
<4>cpm_iic_init() - iip=fa203c80.
<4>cpm_iic_init[132] Install ISR for IRQ 16.
<6>CPM interrupt c0105d90 replacing c01f7a8c.
<3>request_irq() returned -22 for CPM vector 32.
<6> i2c-algo-8xx.o: scanning bus m8xx........
<4>cpm_iic_tryaddress(cpm=c019b9f8,addr=0).
<4>iip fa203c80, dp_addr 0x800.
<4>iic_tbase 2048, r_tbase 2048
<4>about to sleep
........
BOOTING HANGS FROM HERE !!!!
The board is equipped with M24Cxx-x Serial I2C bus EEPROM
- does above means that the EEPROM device was not detected on the I2C bus ?
Do I need to supply in the code the addresses to be scanned ?
Thanks,
Alex
___________________________________________________________________
Speed up your surfing with Juno SpeedBand.
Now includes pop-up blocker!
Only $14.95/month -visit http://www.juno.com/surf to sign up today!
___________________________________________________________________
Speed up your surfing with Juno SpeedBand.
Now includes pop-up blocker!
Only $14.95/month -visit http://www.juno.com/surf to sign up today!
^ permalink raw reply
* Re: The RS485 driver problem...
From: Mark Chambers @ 2005-02-02 13:15 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <DE2CC66C40EAB74EA6D66AC71BF98E1E03055B60@TQ-MAILSRV-1>
linuxppc-embedded-bounces@ozlabs.org wrote on :
> If you want to connect a RS485 transceiver to a normal UART, you
> always have the problem of dealing with enabling/disabling
> transmitter and recveiver. I have seen hardware that misuses RS-232
> hardware handshaking lines (RTS/CTS) for this purpose. What I have
> not been able to find is a linux driver or software solution to this
> problem.
>
> Has anybody used the CPM uarts (or even a standard 16C550 uart) for
> this purpose? How?
I took a look at some old non-linux code for the MPC860, and it appears
that the RTSM bit in GSMR_H provides switched-RTS in UART mode.
It will negate RTS after the last character in a BD. (SCCs only, not SMC)
Another trick you can use, depending on your hardware config, is to loop
your transmit data back to receive. When you receive the last character
you sent you know it's safe to turn off RTS, and since you're getting an
interrupt it's deterministic.
Mark Chambers
^ permalink raw reply
* Re: How to enable TAH on PPC 440GX un lk 2.4.x?
From: Ralph Siemsen @ 2005-02-02 15:32 UTC (permalink / raw)
To: Sanjay Bajaj; +Cc: linuxppc-dev
In-Reply-To: <0007F077BB3476449151699150E8FEA205922F@exchange.tsi-telsys.com>
Sanjay Bajaj wrote:
> Please share any information on enabling TCP/IP Acceleration Hardware on IBM PPC 440GX processor based board.
Matt answered this question for you when you asked it on the
linuxppc-embedded list last week. There is no TAH support in 2.4, but
the IBM EMAC ethernet driver 2.6 does support TAH mode. You would need
to backport this driver to use it with 2.4. Nobody has done this work
as far as I know, all of the current development effort is focused on
2.6. So your options are either to do the work to backport the driver,
or else use 2.6.
Regards
-Ralph
^ permalink raw reply
* buggy mlock() behaviour in 2.6.9 on ppc64?
From: Chris Friesen @ 2005-02-02 18:11 UTC (permalink / raw)
To: linux-kernel, linuxppc-dev
I've got a simple test app that tries to mmap() and mlock() an amount of
memory specified on the commandline.
If I specify more than the amount of physical memory in the system, I
get different behaviours between ppc and ppc64.
With the ppc kernel, my mmap() call will eventually fail and return
MAP_FAILED.
With the ppc64 kernel, however, the system hangs, and the fans speed
starts increasing. It seems like it doesn't realize that there is
simply no way that it will ever be able to succeed.
Is this expected behaviour for ppc64?
Chris
^ permalink raw reply
* MPC8560 TCP/IP Offloading (SDP)
From: Laurent Lagrange @ 2005-02-02 18:40 UTC (permalink / raw)
To: 'Laurent Lagrange'; +Cc: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 352 bytes --]
Hi,
I work on a custom MPC8560 board with Linux 2.4.25.
I plan to use it as a TCP/IP Offloading Engine (TOE).
Does anybody know where I can get Socket Direct Protocol (SDP)
source code for Linux ?
There are tons of documentation on implementation of the SDP and
user APIs but no direction where and how to download the SDP package.
Thanks
Laurent
[-- Attachment #2: Type: text/html, Size: 1612 bytes --]
^ permalink raw reply
* new binutils breaks "tlbie" instruction in kernel?
From: Chris Friesen @ 2005-02-02 18:39 UTC (permalink / raw)
To: linuxppc-dev
The "tlbie" instruction has a bit which may be set to indicate regular
or large page size. This used to be set via an optional second parameter.
Apparently some time between binutils versions 2.15.91.0.2 and
2.15.92.0.2 a change went in to make this second parameter mandatory,
which breaks the kernel ppc code.
What is the recommended way to fix this? Do all binutils versions
understand the second parameter, or will "sufficiently old" versions
choke on it?
Thanks,
Chris
^ permalink raw reply
* [PATCH 18/20] ppc/serial_sicc: remove interruptible_sleep_on_timeout() usage
From: Nishanth Aravamudan @ 2005-02-02 22:55 UTC (permalink / raw)
To: mporter; +Cc: kernel-janitors, linuxppc-embedded
Hello,
Please consider applying.
Description: Remove deprecated interruptible_sleep_on_timeout() function calls
and replace with direct wait-queue usage.
Signed-off-by: Nishanth Aravamudan <nacc@us.ibm.com>
--- 2.6.11-rc2-kj-v/arch/ppc/4xx_io/serial_sicc.c 2005-01-24 09:34:02.000000000 -0800
+++ 2.6.11-rc2-kj/arch/ppc/4xx_io/serial_sicc.c 2005-02-02 14:41:49.000000000 -0800
@@ -52,6 +52,7 @@
#include <linux/console.h>
#include <linux/sysrq.h>
#include <linux/bitops.h>
+#include <linux/wait.h>
#include <asm/system.h>
#include <asm/io.h>
@@ -1561,8 +1562,11 @@ static int block_til_ready(struct tty_st
*/
if (tty_hung_up_p(filp) ||
(info->flags & ASYNC_CLOSING)) {
- if (info->flags & ASYNC_CLOSING)
- interruptible_sleep_on(&info->close_wait);
+ if (info->flags & ASYNC_CLOSING) {
+ prepare_to_wait(&info->close_wait, &wait, TASK_INTERRUPTIBLE);
+ schedule();
+ finish_wait(&info->close_wait, &wait);
+ }
return (info->flags & ASYNC_HUP_NOTIFY) ?
-EAGAIN : -ERESTARTSYS;
}
^ permalink raw reply
* [UPDATE PATCH 18/20] ppc/serial_sicc: remove interruptible_sleep_on_timeout() usage
From: Nishanth Aravamudan @ 2005-02-02 23:05 UTC (permalink / raw)
To: mporter; +Cc: kernel-janitors, linuxppc-embedded
In-Reply-To: <20050202225504.GX2546@us.ibm.com>
On Wed, Feb 02, 2005 at 02:55:04PM -0800, Nishanth Aravamudan wrote:
> Hello,
>
> Please consider applying.
Sorry, for the noise, but the patch was incomplete, as there was another call to
sleep_on() in the same file. Fixed below, please consider applying.
Description: Remove deprecated interruptible_sleep_on_timeout() function calls
and replace with direct wait-queue usage.
Signed-off-by: Nishanth Aravamudan <nacc@us.ibm.com>
--- 2.6.11-rc2-kj-v/arch/ppc/4xx_io/serial_sicc.c 2005-01-24 09:34:02.000000000 -0800
+++ 2.6.11-rc2-kj/arch/ppc/4xx_io/serial_sicc.c 2005-02-02 15:04:20.000000000 -0800
@@ -52,6 +52,7 @@
#include <linux/console.h>
#include <linux/sysrq.h>
#include <linux/bitops.h>
+#include <linux/wait.h>
#include <asm/system.h>
#include <asm/io.h>
@@ -1561,8 +1562,11 @@ static int block_til_ready(struct tty_st
*/
if (tty_hung_up_p(filp) ||
(info->flags & ASYNC_CLOSING)) {
- if (info->flags & ASYNC_CLOSING)
- interruptible_sleep_on(&info->close_wait);
+ if (info->flags & ASYNC_CLOSING) {
+ prepare_to_wait(&info->close_wait, &wait, TASK_INTERRUPTIBLE);
+ schedule();
+ finish_wait(&info->close_wait, &wait);
+ }
return (info->flags & ASYNC_HUP_NOTIFY) ?
-EAGAIN : -ERESTARTSYS;
}
@@ -1664,6 +1668,7 @@ static struct SICC_info *siccuart_get(in
static int siccuart_open(struct tty_struct *tty, struct file *filp)
{
+ DEFINE_WAIT(wait);
struct SICC_info *info;
int retval, line = tty->index;
@@ -1699,8 +1704,11 @@ static int siccuart_open(struct tty_stru
*/
if (tty_hung_up_p(filp) ||
(info->flags & ASYNC_CLOSING)) {
- if (info->flags & ASYNC_CLOSING)
- interruptible_sleep_on(&info->close_wait);
+ if (info->flags & ASYNC_CLOSING) {
+ prepare_to_wait(&info->close_wait, &wait, TASK_INTERRUPTIBLE);
+ schedule();
+ finish_wait(&info->close_wait, &wait);
+ }
return -EAGAIN;
}
^ permalink raw reply
* [PATCH][PPC32] fix locking bugs in mv64x60 code
From: Mark A. Greer @ 2005-02-03 0:20 UTC (permalink / raw)
To: akpm; +Cc: Brian Waite, Embedded PPC Linux list
[Original patch slightly edited by mgreer]
This patch fixes 2 SMP deadlocks. The first is that mv64x60_read() was
returning before the unlock. The second was mv64x60_modify() locks the spin
lock and calls mv64x60_read() and mv64x60_write() which also lock the same spin lock.
Please apply.
Signed-Off-By: Brian Waite <waite@skycomputers.com>
Signed-off-by: Mark A. Greer <mgreer@mvista.com>
^ permalink raw reply
* Re: [PATCH][PPC32] fix locking bugs in mv64x60 code
From: Mark A. Greer @ 2005-02-03 0:21 UTC (permalink / raw)
To: akpm; +Cc: Brian Waite, Embedded PPC Linux list
In-Reply-To: <42016E33.9070804@mvista.com>
[-- Attachment #1: Type: text/plain, Size: 478 bytes --]
And with the patch this time...
--
Mark A. Greer wrote:
> [Original patch slightly edited by mgreer]
>
> This patch fixes 2 SMP deadlocks. The first is that mv64x60_read() was
> returning before the unlock. The second was mv64x60_modify() locks the
> spin lock and calls mv64x60_read() and mv64x60_write() which also lock
> the same spin lock.
>
> Please apply.
>
> Signed-Off-By: Brian Waite <waite@skycomputers.com>
> Signed-off-by: Mark A. Greer <mgreer@mvista.com>
>
>
[-- Attachment #2: mv_smp.patch --]
[-- Type: text/plain, Size: 1368 bytes --]
diff -Nru a/arch/ppc/syslib/mv64x60.c b/arch/ppc/syslib/mv64x60.c
--- a/arch/ppc/syslib/mv64x60.c 2005-02-02 17:15:26 -07:00
+++ b/arch/ppc/syslib/mv64x60.c 2005-02-02 17:15:26 -07:00
@@ -32,7 +32,7 @@
u8 mv64x60_pci_exclude_bridge = 1;
-spinlock_t mv64x60_lock; /* Only really used by PIC code once init done */
+spinlock_t mv64x60_lock = SPIN_LOCK_UNLOCKED;
static phys_addr_t mv64x60_bridge_pbase = 0;
static void *mv64x60_bridge_vbase = 0;
diff -Nru a/include/asm-ppc/mv64x60.h b/include/asm-ppc/mv64x60.h
--- a/include/asm-ppc/mv64x60.h 2005-02-02 17:15:26 -07:00
+++ b/include/asm-ppc/mv64x60.h 2005-02-02 17:15:26 -07:00
@@ -254,10 +254,12 @@
extern inline u32
mv64x60_read(struct mv64x60_handle *bh, u32 offset) {
ulong flags;
+ u32 reg;
spin_lock_irqsave(&mv64x60_lock, flags);
- return in_le32(bh->v_base + offset);
+ reg = in_le32(bh->v_base + offset);
spin_unlock_irqrestore(&mv64x60_lock, flags);
+ return reg;
}
extern inline void
@@ -267,9 +269,9 @@
ulong flags;
spin_lock_irqsave(&mv64x60_lock, flags);
- reg = mv64x60_read(bh, offs) & (~mask); /* zero bits we care about */
- reg |= data & mask; /* set bits from the data */
- mv64x60_write(bh, offs, reg);
+ reg = in_le32(bh->v_base + offs) & (~mask);
+ reg |= data & mask;
+ out_le32(bh->v_base + offs, reg);
spin_unlock_irqrestore(&mv64x60_lock, flags);
}
^ permalink raw reply
* Re: new binutils breaks "tlbie" instruction in kernel?
From: Benjamin Herrenschmidt @ 2005-02-03 5:13 UTC (permalink / raw)
To: Chris Friesen; +Cc: linuxppc-dev list
In-Reply-To: <42011E77.6040906@nortel.com>
On Wed, 2005-02-02 at 12:39 -0600, Chris Friesen wrote:
> The "tlbie" instruction has a bit which may be set to indicate regular
> or large page size. This used to be set via an optional second parameter.
>
> Apparently some time between binutils versions 2.15.91.0.2 and
> 2.15.92.0.2 a change went in to make this second parameter mandatory,
> which breaks the kernel ppc code.
>
> What is the recommended way to fix this? Do all binutils versions
> understand the second parameter, or will "sufficiently old" versions
> choke on it?
Wasn't it fixed ?
Ben.
^ permalink raw reply
* Re: new binutils breaks "tlbie" instruction in kernel?
From: Kumar Gala @ 2005-02-03 5:55 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev list, Chris Friesen
In-Reply-To: <1107407613.2363.9.camel@gaston>
Someone should just add some of our asm files into the ppc binutils=20
testsuite, why we cant seem to get a stability on this seems beyond me=20=
:) Well, something else to add to the ppc kernel janitors list.
- kumar
On Feb 2, 2005, at 11:13 PM, Benjamin Herrenschmidt wrote:
> On Wed, 2005-02-02 at 12:39 -0600, Chris Friesen wrote:
> > The "tlbie" instruction has a bit which may be set to indicate=20
> regular
> > or large page size.=A0 This used to be set via an optional second=20
> parameter.
> >
> > Apparently some time between binutils versions 2.15.91.0.2 and
> > 2.15.92.0.2 a change went in to make this second parameter =
mandatory,
> > which breaks the kernel ppc code.
> >
> > What is the recommended way to fix this?=A0 Do all binutils versions
> > understand the second parameter, or will "sufficiently old" versions
> > choke on it?
>
> Wasn't it fixed ?
>
> Ben.
>
>
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
^ permalink raw reply
* U-Boot support for MPC8270
From: Dmytro Bablinyuk @ 2005-02-03 5:46 UTC (permalink / raw)
To: linuxppc-embedded
At what stage right now support for MPC8270 in U-Boot.
Based on this we are thinking whether buy or not eval board, or try to
get system running already on a target.
Can anybody suggest.
Thank you
^ permalink raw reply
* Re: U-Boot support for MPC8270
From: Hans Schillstrom @ 2005-02-03 7:17 UTC (permalink / raw)
To: Dmytro Bablinyuk; +Cc: linuxppc-embedded
In-Reply-To: <4201BAA1.3010002@rftechnology.com.au>
Hi,
I have a custom board with mpc8270vr runing uboot 1.1.2 and it works
without any problem. If you follow Denx instructions it's very easy to
get it runing.
Right now Linux 2.6.10 is runing on the board.
The only problem with the MPC8270 we had was that VCORE has to be 1.7V
not 1.5V ,
/Hans
On Thu, 2005-02-03 at 06:46, Dmytro Bablinyuk wrote:
> At what stage right now support for MPC8270 in U-Boot.
> Based on this we are thinking whether buy or not eval board, or try to
> get system running already on a target.
> Can anybody suggest.
>
> Thank you
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
^ permalink raw reply
* Re: U-Boot support for MPC8270
From: Matt Porter @ 2005-02-03 7:26 UTC (permalink / raw)
To: Dmytro Bablinyuk; +Cc: linuxppc-embedded
In-Reply-To: <4201BAA1.3010002@rftechnology.com.au>
On Thu, Feb 03, 2005 at 04:46:09PM +1100, Dmytro Bablinyuk wrote:
> At what stage right now support for MPC8270 in U-Boot.
> Based on this we are thinking whether buy or not eval board, or try to
> get system running already on a target.
> Can anybody suggest.
You are confusing this list with U-Boot list where this post belongs.
-Matt
^ permalink raw reply
* Re: U-Boot support for MPC8270
From: Dmytro Bablinyuk @ 2005-02-03 7:38 UTC (permalink / raw)
To: Matt Porter; +Cc: linuxppc-embedded
In-Reply-To: <20050203002616.A7336@cox.net>
My apologise.
>
> You are confusing this list with U-Boot list where this post belongs.
>
> -Matt
--
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.300 / Virus Database: 265.8.4 - Release Date: 1/02/05
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox