* Framebuffer driver using SM501 hardware.
From: Surendra Yadav @ 2005-08-16 13:34 UTC (permalink / raw)
To: linuxppc-dev
Hi all,
I am writing framebuffer driver using SM501. This graphics driver chip can
drive CRT and TFT panel. I have written two seperate framebuffer driver, one
for CRT and one for TFT Panel.
But I am not able to test both the devices. Any one of them work at a time.
I have created two files /dev/fb0 and /dev/fb1. These two can be open
successfully and mmap is also successful from userspace. If I am trying to
write on fb0 and fb1 with different data, they displayed on either CRT or
TFT panel.
Can any one help me How to test two different framebuffer devices?
Thanks.
^ permalink raw reply
* Re: Best kernel for Xilinx VirtexII Pro/PPC405 ?
From: Andrei Konovalov @ 2005-08-16 10:38 UTC (permalink / raw)
To: Keith J Outwater; +Cc: linuxppc-embedded
In-Reply-To: <OF688E8333.A7E991BA-ON0725705E.00780121-0725705E.00787A39@mck.us.ray.com>
Keith J Outwater wrote:
> Hello all -
> I am designing an embedded system using a Xilinx Virtex II Pro FPGA.
> Can anyone point me to the "best" kernel source tree to use ?
> "Best" in this case means:
> 1. A 2.4 series kernel with good support for Xilinx peripheral devices
> (existing Xilinx ML300 support is fine).
> 2. Good stability
>
> By default I'll use the Montavista linuxppc_2.4 tree unless there is a
> better choice out there.
If you mean the rsync access to source.mvista.com::linuxppc-2.4
then yes, this is the most recent (as regards to Virtex II Pro support)
community 2.4 tree.
Thanks,
Andrei
> Thanks!
>
> Keith
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
^ permalink raw reply
* Re: CONFIG_FRAME_POINTER on ppc/ppc64?
From: Segher Boessenkool @ 2005-08-16 9:44 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc64-dev, David Edelsohn, linuxppc-dev list
In-Reply-To: <473FD762-FB04-4B63-93E9-11931492AC60@freescale.com>
>> Because -fomit-frame-pointer and -fno-omit-frame-pointer have no
>> effect on ppc or ppc64, I assume. :)
>
> I'm assuming that's a guess. The reason I ask that is my memory
> serves correctly r31 is used as the frame pointer if compiled that
> way. Maybe some GCC expert can chime in. I'll copy David Edelsohn
> and see if I get a response :)
Yes, GPR31 is used as frame pointer. All optimization
levels other than -O0 enable -fomit-frame-pointer. But
-fno-omit-frame-pointer certainly works.
Segher
^ permalink raw reply
* RMII support for MPC8280
From: Tore Martin Hagen @ 2005-08-16 8:48 UTC (permalink / raw)
To: LinuxPPC Support
Hi.
Has anybody made u-boot (1.1.2) with support for RMII on the MPC8280?
The code currently only supports the MII interface.
/Tore
^ permalink raw reply
* Re: [PATCH] Use todc on Mot PReP platforms
From: Sven Luther @ 2005-08-16 7:19 UTC (permalink / raw)
To: Matt Porter; +Cc: Tom Rini, linuxppc-dev
In-Reply-To: <20050815225224.F28706@cox.net>
On Mon, Aug 15, 2005 at 10:52:24PM -0700, Matt Porter wrote:
> On Thu, Aug 11, 2005 at 12:43:07PM -0700, Tom Rini wrote:
> > On Wed, Aug 10, 2005 at 09:37:35AM -0700, Matt Porter wrote:
> >
> > > This restores behavior from 2.4 where PReP platforms identified
> > > as Motorola would calibrate the decrementer using the RTC. On
> > > real Motorola PReP hardware this isn't needed. However, in order
> > > to boot a stock 2.6 PReP kernel on qemu (which emulates a Motorola
> > > PReP system) it is necessary to allow it to calibrate the decrementer
> > > using an emulated RTC. If the decrementer rate is read from
> > > residual data then timing is screwed since a qemu PReP system typically
> > > runs much faster than the original hardware.
> > >
> > > If anybody has objections to this as the default, let me know. It
> > > still works (as did 2.4) on a couple of my Mot PReP boxes and doesn't
> > > affect the IBM PReP paths. My goal with this is to be able to run
> > > a stock 2.6 defconfig PReP build on qemu.
> >
> > So, I like this, and not just because I'm playing with qemu as well.
>
> Why? It has no other redeeming quality except that it makes qemu work.
> It's better to use residual data versus todc calibration in real machine
> cases since residual data is accurate for this particular value on these
> machines. I'm just curious why you would like this patch outside of
> its qemu value.
>
> BTW, it's _possible_ that we might eventually modify the open
> hackware OF to do a timing loop and dynamically fill in the
> residual data time base freq but that's unfamiliar territory and
> this is an easy workaround.
What about modifying qemu's OF to emulate a chrp machine instead ?
Friendly,
Sven Luther
^ permalink raw reply
* Re: [PATCH] Use todc on Mot PReP platforms
From: Matt Porter @ 2005-08-16 7:33 UTC (permalink / raw)
To: Sven Luther; +Cc: Tom Rini, linuxppc-dev
In-Reply-To: <20050816071912.GA18653@localhost.localdomain>
On Tue, Aug 16, 2005 at 09:19:12AM +0200, Sven Luther wrote:
> On Mon, Aug 15, 2005 at 10:52:24PM -0700, Matt Porter wrote:
> > On Thu, Aug 11, 2005 at 12:43:07PM -0700, Tom Rini wrote:
> > > On Wed, Aug 10, 2005 at 09:37:35AM -0700, Matt Porter wrote:
> > >
> > > > This restores behavior from 2.4 where PReP platforms identified
> > > > as Motorola would calibrate the decrementer using the RTC. On
> > > > real Motorola PReP hardware this isn't needed. However, in order
> > > > to boot a stock 2.6 PReP kernel on qemu (which emulates a Motorola
> > > > PReP system) it is necessary to allow it to calibrate the decrementer
> > > > using an emulated RTC. If the decrementer rate is read from
> > > > residual data then timing is screwed since a qemu PReP system typically
> > > > runs much faster than the original hardware.
> > > >
> > > > If anybody has objections to this as the default, let me know. It
> > > > still works (as did 2.4) on a couple of my Mot PReP boxes and doesn't
> > > > affect the IBM PReP paths. My goal with this is to be able to run
> > > > a stock 2.6 defconfig PReP build on qemu.
> > >
> > > So, I like this, and not just because I'm playing with qemu as well.
> >
> > Why? It has no other redeeming quality except that it makes qemu work.
> > It's better to use residual data versus todc calibration in real machine
> > cases since residual data is accurate for this particular value on these
> > machines. I'm just curious why you would like this patch outside of
> > its qemu value.
> >
> > BTW, it's _possible_ that we might eventually modify the open
> > hackware OF to do a timing loop and dynamically fill in the
> > residual data time base freq but that's unfamiliar territory and
> > this is an easy workaround.
>
> What about modifying qemu's OF to emulate a chrp machine instead ?
That's good, but not the point of this exercise...at least for me. :)
Eventually, we should be able to boot a stock prep, chrp, or pmac
image built from the mainline kernel defconfig. Personally, I
want to boot some stock embedded kernels as well, but that's a
lot more work emulating on-chip I/O.
FWIW, jmayer did PReP first because all the PeeCee hardware was
already emulated. I believe CHRP/Pmac work to some degree but
I haven't personally tried them yet.
-Matt
^ permalink raw reply
* Re: [PATCH] Use todc on Mot PReP platforms
From: Matt Porter @ 2005-08-16 5:52 UTC (permalink / raw)
To: Tom Rini; +Cc: linuxppc-dev
In-Reply-To: <20050811194307.GW3187@smtp.west.cox.net>
On Thu, Aug 11, 2005 at 12:43:07PM -0700, Tom Rini wrote:
> On Wed, Aug 10, 2005 at 09:37:35AM -0700, Matt Porter wrote:
>
> > This restores behavior from 2.4 where PReP platforms identified
> > as Motorola would calibrate the decrementer using the RTC. On
> > real Motorola PReP hardware this isn't needed. However, in order
> > to boot a stock 2.6 PReP kernel on qemu (which emulates a Motorola
> > PReP system) it is necessary to allow it to calibrate the decrementer
> > using an emulated RTC. If the decrementer rate is read from
> > residual data then timing is screwed since a qemu PReP system typically
> > runs much faster than the original hardware.
> >
> > If anybody has objections to this as the default, let me know. It
> > still works (as did 2.4) on a couple of my Mot PReP boxes and doesn't
> > affect the IBM PReP paths. My goal with this is to be able to run
> > a stock 2.6 defconfig PReP build on qemu.
>
> So, I like this, and not just because I'm playing with qemu as well.
Why? It has no other redeeming quality except that it makes qemu work.
It's better to use residual data versus todc calibration in real machine
cases since residual data is accurate for this particular value on these
machines. I'm just curious why you would like this patch outside of
its qemu value.
BTW, it's _possible_ that we might eventually modify the open
hackware OF to do a timing loop and dynamically fill in the
residual data time base freq but that's unfamiliar territory and
this is an easy workaround.
> Leigh, can you run this on any 'interesting' PReP you've got that might
> tickle a bug here? Thanks.
Let me know if there's anything more that needs to be tested. Otherwise,
I plan to send upstream soon.
Thanks,
Matt
^ permalink raw reply
* Re: Redwood-6 and 2.6
From: Matt Porter @ 2005-08-16 5:25 UTC (permalink / raw)
To: Otto Solares; +Cc: linuxppc-embedded
In-Reply-To: <20050812032819.GA4763@guug.org>
On Thu, Aug 11, 2005 at 09:28:19PM -0600, Otto Solares wrote:
> Hi!
>
> Redwood-6 support in 2.6 is broken. I subscribed to this
> list just to know if somebody is working on it? 2.4.30
> works ok.
I went ahead and fixed this compile issue in the following patch:
http://ozlabs.org/pipermail/linuxppc-embedded/2005-August/019782.html
-Matt
^ permalink raw reply
* Re: CONFIG_FRAME_POINTER on ppc/ppc64?
From: Paul Mackerras @ 2005-08-16 5:23 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev list, David Edelsohn, linuxppc64-dev
In-Reply-To: <200508160403.j7G43Hd29692@makai.watson.ibm.com>
David Edelsohn writes:
> Kumar> I'm assuming that's a guess. The reason I ask that is my memory
> Kumar> serves correctly r31 is used as the frame pointer if compiled that
> Kumar> way. Maybe some GCC expert can chime in. I'll copy David Edelsohn
> Kumar> and see if I get a response :)
>
> I am missing some context here. On both 32-bit PowerPC Linux
> (PowerPC SVR4) and 64-bit PowerPC Linux, GPR r31 is used as the frame
> pointer. PowerPC does not have a dedicated frame pointer and the PowerPC
> ABI does not require an independent frame pointer in a function at all
> times, so it can be omitted by default. If the frame pointer is not
> referenced for any unique needs, uses of the frame pointer are adjusted to
> reference the stack pointer. GCC only retains the PowerPC frame pointer
> when dynamic stack allocation (alloca) is used within a function.
> -fomit-frame-pointer has no effect on PowerPC because it is enabled by
> default.
OK, my memory was at fault then.
The reason for having the kernel config option is that it is
impossible to get reliable stack traces on x86 without frame pointers.
On PPC, because the stack frames are always linked together, even if
you don't use a frame pointer, the frame pointer doesn't help in
getting stack traces. Thus there is no point in having the kernel
config option.
Paul.
^ permalink raw reply
* [PATCH] ppc32: fix ppc4xx stb03xxx dma build
From: Matt Porter @ 2005-08-16 5:21 UTC (permalink / raw)
To: akpm; +Cc: linuxppc-embedded
Fixes build on 4xx stb03xxx when general purpose dma engine support
is enabled.
Signed-off-by: Matt Porter <mporter@kernel.crashing.org>
diff --git a/arch/ppc/syslib/ppc4xx_dma.c b/arch/ppc/syslib/ppc4xx_dma.c
--- a/arch/ppc/syslib/ppc4xx_dma.c
+++ b/arch/ppc/syslib/ppc4xx_dma.c
@@ -620,6 +620,7 @@ ppc4xx_clr_dma_status(unsigned int dmanr
return DMA_STATUS_GOOD;
}
+#ifdef CONFIG_PPC4xx_EDMA
/*
* Enables the burst on the channel (BTEN bit in the control/count register)
* Note:
@@ -685,6 +686,11 @@ ppc4xx_set_burst_size(unsigned int dmanr
return DMA_STATUS_GOOD;
}
+EXPORT_SYMBOL(ppc4xx_enable_burst);
+EXPORT_SYMBOL(ppc4xx_disable_burst);
+EXPORT_SYMBOL(ppc4xx_set_burst_size);
+#endif /* CONFIG_PPC4xx_EDMA */
+
EXPORT_SYMBOL(ppc4xx_init_dma_channel);
EXPORT_SYMBOL(ppc4xx_get_channel_config);
EXPORT_SYMBOL(ppc4xx_set_channel_priority);
@@ -703,6 +709,4 @@ EXPORT_SYMBOL(ppc4xx_enable_dma_interrup
EXPORT_SYMBOL(ppc4xx_disable_dma_interrupt);
EXPORT_SYMBOL(ppc4xx_get_dma_status);
EXPORT_SYMBOL(ppc4xx_clr_dma_status);
-EXPORT_SYMBOL(ppc4xx_enable_burst);
-EXPORT_SYMBOL(ppc4xx_disable_burst);
-EXPORT_SYMBOL(ppc4xx_set_burst_size);
+
diff --git a/include/asm-ppc/ppc4xx_dma.h b/include/asm-ppc/ppc4xx_dma.h
--- a/include/asm-ppc/ppc4xx_dma.h
+++ b/include/asm-ppc/ppc4xx_dma.h
@@ -285,7 +285,7 @@ typedef uint32_t sgl_handle_t;
#define GET_DMA_POLARITY(chan) (DMAReq_ActiveLow(chan) | DMAAck_ActiveLow(chan) | EOT_ActiveLow(chan))
-#elif defined(CONFIG_STBXXX_DMA) /* stb03xxx */
+#elif defined(CONFIG_STB03xxx) /* stb03xxx */
#define DMA_PPC4xx_SIZE 4096
^ permalink raw reply
* Re: Best kernel for Xilinx VirtexII Pro/PPC405 ?
From: Peter Ryser @ 2005-08-16 4:15 UTC (permalink / raw)
To: Keith J Outwater; +Cc: linuxppc-embedded
In-Reply-To: <OF688E8333.A7E991BA-ON0725705E.00780121-0725705E.00787A39@mck.us.ray.com>
You might want to look at Xilinx Application Note 765 (XAPP765,
http://www.xilinx.com/bvdocs/appnotes/xapp765.pdf) for some instructions
on how to get started with EDK and Linux. All source is published in
linuxppc-2.4.
- Peter
Keith J Outwater wrote:
>Hello all -
>I am designing an embedded system using a Xilinx Virtex II Pro FPGA.
>Can anyone point me to the "best" kernel source tree to use ?
>"Best" in this case means:
>1. A 2.4 series kernel with good support for Xilinx peripheral devices
>(existing Xilinx ML300 support is fine).
>2. Good stability
>
>By default I'll use the Montavista linuxppc_2.4 tree unless there is a
>better choice out there.
>
>Thanks!
>
>Keith
>_______________________________________________
>Linuxppc-embedded mailing list
>Linuxppc-embedded@ozlabs.org
>https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
>
>
>
^ permalink raw reply
* Re: CONFIG_FRAME_POINTER on ppc/ppc64?
From: David Edelsohn @ 2005-08-16 4:03 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev list, linuxppc64-dev
In-Reply-To: <473FD762-FB04-4B63-93E9-11931492AC60@freescale.com>
>>>>> Kumar Gala writes:
>> Because -fomit-frame-pointer and -fno-omit-frame-pointer have no
>> effect on ppc or ppc64, I assume. :)
Kumar> I'm assuming that's a guess. The reason I ask that is my memory
Kumar> serves correctly r31 is used as the frame pointer if compiled that
Kumar> way. Maybe some GCC expert can chime in. I'll copy David Edelsohn
Kumar> and see if I get a response :)
I am missing some context here. On both 32-bit PowerPC Linux
(PowerPC SVR4) and 64-bit PowerPC Linux, GPR r31 is used as the frame
pointer. PowerPC does not have a dedicated frame pointer and the PowerPC
ABI does not require an independent frame pointer in a function at all
times, so it can be omitted by default. If the frame pointer is not
referenced for any unique needs, uses of the frame pointer are adjusted to
reference the stack pointer. GCC only retains the PowerPC frame pointer
when dynamic stack allocation (alloca) is used within a function.
-fomit-frame-pointer has no effect on PowerPC because it is enabled by
default.
David
^ permalink raw reply
* Re: CONFIG_FRAME_POINTER on ppc/ppc64?
From: Kumar Gala @ 2005-08-16 3:41 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev list, David Edelsohn, linuxppc64-dev
In-Reply-To: <17153.8284.3721.188488@cargo.ozlabs.ibm.com>
On Aug 15, 2005, at 6:08 PM, Paul Mackerras wrote:
>> Is there any reason we dont allow building with frame pointers on
>> ppc/
>>
>
>
>> ppc64?
>>
>
> Because -fomit-frame-pointer and -fno-omit-frame-pointer have no
> effect on ppc or ppc64, I assume. :)
I'm assuming that's a guess. The reason I ask that is my memory
serves correctly r31 is used as the frame pointer if compiled that
way. Maybe some GCC expert can chime in. I'll copy David Edelsohn
and see if I get a response :)
- kumar
^ permalink raw reply
* Re: MPC885 - USB HCI drivers.
From: Adam Kent @ 2005-08-16 1:21 UTC (permalink / raw)
To: Bastos Fernandez Alexandre, Pantelis Antoniou,
Bryan O'Donoghue
Cc: linuxppc-embedded
In-Reply-To: <51DB8827D393D411BB69003048003F4601B1C220@tvesntr>
Bryan O'Donoghue wrote:
>Pantelis Antoniou wrote:
>
>>Well I have USB host drivers for both 8xx & 82xx working.
>>
>>
Bastos Fernandez Alexandre wrote:
>Finally, was the patch submitted to the list?
>I have searched deeply both ozlabs and gmane, but I couldn't
>find it ...
>
I'd be keen for a look at this code as well, even if it's not in the
form of a nice patch or if it's still "too hideous for human eyes".
It's been a few months, has anyone got something they can post to the
list or stick up on the web somewhere?
Thanks in advance,
Adam Kent
^ permalink raw reply
* Re: CONFIG_FRAME_POINTER on ppc/ppc64?
From: Paul Mackerras @ 2005-08-15 23:08 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev list, linuxppc64-dev
In-Reply-To: <3E78617E-D2D4-44DB-A3F1-9C5D8814E37F@freescale.com>
> Is there any reason we dont allow building with frame pointers on ppc/
> ppc64?
Because -fomit-frame-pointer and -fno-omit-frame-pointer have no
effect on ppc or ppc64, I assume. :)
Paul.
^ permalink raw reply
* Best kernel for Xilinx VirtexII Pro/PPC405 ?
From: Keith J Outwater @ 2005-08-15 21:55 UTC (permalink / raw)
To: linuxppc-embedded
Hello all -
I am designing an embedded system using a Xilinx Virtex II Pro FPGA.
Can anyone point me to the "best" kernel source tree to use ?
"Best" in this case means:
1. A 2.4 series kernel with good support for Xilinx peripheral devices
(existing Xilinx ML300 support is fine).
2. Good stability
By default I'll use the Montavista linuxppc_2.4 tree unless there is a
better choice out there.
Thanks!
Keith
^ permalink raw reply
* GCJ
From: mcnernbm @ 2005-08-15 20:20 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 571 bytes --]
I have used crosstools to build a cross compiler that support C,C++, and
java code. I have no problems build my kernel and filesystem and what
not. But when I try to build java code using GCJ everything seems to
build with no issues. But when I copie the compiled code to the target
device and execute the code I get an an error stating libjava.so can not
be found. I have copied the libjava.so file from my host machine to the
target device but can not get the code to see it.
Any help on how to get rid of this error would be greatly appreciated.
Thanks
Brett
[-- Attachment #2: Type: text/html, Size: 754 bytes --]
^ permalink raw reply
* eBay Inc: Please Confirm Your Banking Details [Mon, 15 Aug 2005 22:38:14 -0100]
From: eBay @ 2005-08-15 19:18 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/html, Size: 3761 bytes --]
^ permalink raw reply
* eBay Inc: Please Confirm Your Banking Details [Mon, 15 Aug 2005 22:38:14 -0100]
From: eBay @ 2005-08-15 19:18 UTC (permalink / raw)
To: linuxppc-dev
[-- Attachment #1: Type: text/html, Size: 3761 bytes --]
^ permalink raw reply
* subscribe linuxppc-embedded
From: Randazzo, Michael @ 2005-08-15 19:35 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 292 bytes --]
subscribe linuxppc-embedded
Regards,
Mike
Michael J. Randazzo
Senior Applications Engineer
Data Device Corporation
105 Wilbur Place
Bohemia, NY 11716-2482
Voice: 800-DDC-1772 ext. 7321
Fax: 631-567-7358
Email: randazzo@ddc-web.com
Web: <http://www.ddc-web.com>
[-- Attachment #2: Type: text/html, Size: 1728 bytes --]
^ permalink raw reply
* [-mm PATCH 12/32] ppc: fix-up schedule_timeout() usage
From: Nishanth Aravamudan @ 2005-08-15 18:15 UTC (permalink / raw)
To: paulus; +Cc: akpm, linuxppc-dev
In-Reply-To: <20050815180514.GC2854@us.ibm.com>
Description: Use schedule_timeout_interruptible() instead of
set_current_state()/schedule_timeout() to reduce kernel size. Also use
human-time conversion functions instead of hard-coded HZ division to
avoid rounding errors.
Signed-off-by: Nishanth Aravamudan <nacc@us.ibm.com>
---
arch/ppc/4xx_io/serial_sicc.c | 17 +++++++----------
arch/ppc/8260_io/fcc_enet.c | 3 +--
2 files changed, 8 insertions(+), 12 deletions(-)
diff -urpN 2.6.13-rc5-mm1/arch/ppc/4xx_io/serial_sicc.c 2.6.13-rc5-mm1-dev/arch/ppc/4xx_io/serial_sicc.c
--- 2.6.13-rc5-mm1/arch/ppc/4xx_io/serial_sicc.c 2005-03-01 23:37:30.000000000 -0800
+++ 2.6.13-rc5-mm1-dev/arch/ppc/4xx_io/serial_sicc.c 2005-08-11 15:55:47.000000000 -0700
@@ -1145,8 +1145,8 @@ static int set_serial_info(struct SICC_i
info->flags = ((state->flags & ~ASYNC_INTERNAL_FLAGS) |
(info->flags & ASYNC_INTERNAL_FLAGS));
state->custom_divisor = new_serial.custom_divisor;
- state->close_delay = new_serial.close_delay * HZ / 100;
- state->closing_wait = new_serial.closing_wait * HZ / 100;
+ state->close_delay = msecs_to_jiffies(10 * new_serial.close_delay);
+ state->closing_wait = msecs_to_jiffies(10 * new_serial.closing_wait);
info->tty->low_latency = (info->flags & ASYNC_LOW_LATENCY) ? 1 : 0;
port->fifosize = new_serial.xmit_fifo_size;
@@ -1465,10 +1465,8 @@ static void siccuart_close(struct tty_st
info->event = 0;
info->tty = NULL;
if (info->blocked_open) {
- if (info->state->close_delay) {
- set_current_state(TASK_INTERRUPTIBLE);
- schedule_timeout(info->state->close_delay);
- }
+ if (info->state->close_delay)
+ schedule_timeout_interruptible(info->state->close_delay);
wake_up_interruptible(&info->open_wait);
}
info->flags &= ~(ASYNC_NORMAL_ACTIVE|ASYNC_CLOSING);
@@ -1496,7 +1494,7 @@ static void siccuart_wait_until_sent(str
* Note: we have to use pretty tight timings here to satisfy
* the NIST-PCTS.
*/
- char_time = (info->timeout - HZ/50) / info->port->fifosize;
+ char_time = (info->timeout - msecs_to_jiffies(20)) / info->port->fifosize;
char_time = char_time / 5;
if (char_time == 0)
char_time = 1;
@@ -1521,8 +1519,7 @@ static void siccuart_wait_until_sent(str
tty->index, jiffies,
expire, char_time);
while ((readb(info->port->uart_base + BL_SICC_LSR) & _LSR_TX_ALL) != _LSR_TX_ALL) {
- set_current_state(TASK_INTERRUPTIBLE);
- schedule_timeout(char_time);
+ schedule_timeout_interruptible(char_time);
if (signal_pending(current))
break;
if (timeout && time_after(jiffies, expire))
@@ -1773,7 +1770,7 @@ int __init siccuart_init(void)
for (i = 0; i < SERIAL_SICC_NR; i++) {
struct SICC_state *state = sicc_state + i;
state->line = i;
- state->close_delay = 5 * HZ / 10;
+ state->close_delay = msecs_to_jiffies(500);
state->closing_wait = 30 * HZ;
spin_lock_init(&state->sicc_lock);
}
diff -urpN 2.6.13-rc5-mm1/arch/ppc/8260_io/fcc_enet.c 2.6.13-rc5-mm1-dev/arch/ppc/8260_io/fcc_enet.c
--- 2.6.13-rc5-mm1/arch/ppc/8260_io/fcc_enet.c 2005-08-07 09:57:22.000000000 -0700
+++ 2.6.13-rc5-mm1-dev/arch/ppc/8260_io/fcc_enet.c 2005-08-08 13:54:41.000000000 -0700
@@ -1309,8 +1309,7 @@ static void mii_dm9161_wait(uint mii_reg
/* Davicom takes a bit to come up after a reset,
* so wait here for a bit */
- set_current_state(TASK_UNINTERRUPTIBLE);
- schedule_timeout(timeout);
+ schedule_timeout_uninterruptible(timeout);
}
static phy_info_t phy_info_dm9161 = {
^ permalink raw reply
* CONFIG_FRAME_POINTER on ppc/ppc64?
From: Kumar Gala @ 2005-08-15 18:25 UTC (permalink / raw)
To: linuxppc-dev list; +Cc: linuxppc64-dev
Is there any reason we dont allow building with frame pointers on ppc/
ppc64?
- kumar
^ permalink raw reply
* Re: RFC: proposed arch/powerpc directory structure
From: Segher Boessenkool @ 2005-08-15 18:25 UTC (permalink / raw)
To: Tom Rini; +Cc: linuxppc64-dev, linuxppc-dev, Becky Bruce
In-Reply-To: <20050812041443.GC3187@smtp.west.cox.net>
> Ok. How about 9xx/ instead of classic64 ?
That would be tons better, as there doesn't exist anything
called "classic64"...
Segher
^ permalink raw reply
* [-mm PATCH 23/32] drivers/macintosh: fix-up schedule_timeout() usage
From: Nishanth Aravamudan @ 2005-08-15 18:23 UTC (permalink / raw)
To: benh; +Cc: akpm, linuxppc-dev
In-Reply-To: <20050815180514.GC2854@us.ibm.com>
Description: Use schedule_timeout_interruptible() instead of
set_current_state()/schedule_timeout() to reduce kernel size.
Signed-off-by: Nishanth Aravamudan <nacc@us.ibm.com>
---
arch/m68k/atari/time.c | 6 ++----
1 files changed, 2 insertions(+), 4 deletions(-)
diff -urpN 2.6.13-rc5-mm1/drivers/macintosh/therm_pm72.c 2.6.13-rc5-mm1-dev/drivers/macintosh/therm_pm72.c
--- 2.6.13-rc5-mm1/drivers/macintosh/therm_pm72.c 2005-08-07 09:57:58.000000000 -0700
+++ 2.6.13-rc5-mm1-dev/drivers/macintosh/therm_pm72.c 2005-08-08 15:06:08.000000000 -0700
@@ -1678,10 +1678,9 @@ static int main_control_loop(void *x)
}
// FIXME: Deal with signals
- set_current_state(TASK_INTERRUPTIBLE);
elapsed = jiffies - start;
if (elapsed < HZ)
- schedule_timeout(HZ - elapsed);
+ schedule_timeout_interruptible(HZ - elapsed);
}
out:
^ permalink raw reply
* Re: [00/02] MPC5200 Bestcomm platform driver
From: Andrey Volkov @ 2005-08-15 17:51 UTC (permalink / raw)
To: Dale Farnsworth; +Cc: linuxppc-embedded
In-Reply-To: <20050815171637.GA20943@xyzzy.farnsworth.org>
Dale Farnsworth wrote:
> On Mon, Aug 15, 2005 at 03:05:37PM +0000, Andrey Volkov wrote:
>
>>Sylvain Munaut wrote:
>>
>>>Obviously I haven't yet had the time to review all the code but the
>>>glance I had looked good ! I'll review it deeper and test it and come
>>>back to you asap.
>>
>>As you could see it was only first step (I hope at not so long way :)):
>>bring Dale's code to the current kernel, and make point from which
>>everyone could start dance.
>
>
> Andrey, thanks for keeping this alive.
>
> I agree with Sylvain's other comments.
>
> The main thing I would like to see happen to this driver (other
> than getting it in mainline :-) is an attempt to replace the
> ugly phy code with calls to the new phy abstraction layer.
> On the other hand, I'm glad to see progress on any front.
Ok. But if smb, wish do it now -- welcome.
Because I planned do it only after bestcomm will be accepted.
--
Regards
Andrey Volkov
^ 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