On Wed, 2007-09-26 at 09:42 +0200, Geert Uytterhoeven wrote:
> On Wed, 26 Sep 2007, Kumar Gala wrote:
> > On Sep 25, 2007, at 11:56 PM, Mark Nelson wrote:
> > > What cores have SPE at the moment? Also, perhaps more importantly,
> > > are there any plans to have Altivec and SPE in the same core?
>
On Wed, 2007-09-26 at 00:37 -0500, Kumar Gala wrote:
> On Sep 25, 2007, at 11:56 PM, Mark Nelson wrote:
>
> > Kumar Gala wrote:
> >>
> >> On Sep 25, 2007, at 8:22 PM, Mark Nelson wrote:
> >>
> >>> Kumar Gala wrote:
>
> On Sep 24, 2007, at 11:03 PM, Mark Nelson wrote:
>
> > Updat
On Wed, Sep 26, 2007 at 11:19:47AM -0500, Milton Miller wrote:
> On Sep 24, 2007, at 10:46 PM, David Gibson wrote:
> > On Mon, Sep 24, 2007 at 01:54:32AM -0500, Milton Miller wrote:
> >> On Sep 23, 2007, at 10:36 PM, David Gibson wrote:
> >>> On Fri, Sep 21, 2007 at 06:05:06PM -0500, Milton Miller
On Wed, 2007-09-26 at 18:33 +0200, Geert Uytterhoeven wrote:
> Hi,
>
> Here are some new patches for the PS3 AV Settings Driver (ps3av), which is
> used in close collaboration with the PS3 Virtual Frame Buffer Device Driver
> (ps3fb):
> [1] ps3av: eliminate unneeded temporary variables
>
On Wed, 2007-09-26 at 23:39 +0400, Sergei Shtylyov wrote:
> Hello.
>
> Steven Rostedt wrote:
> > Tony,
>
> > I'm about to release a new -rt patch based on -rc8. This patch series
> > blew up totally in trying to get it applied. I'm leaving it out, so after
> > I release the next series, could yo
Since about May 2001, we have put two AT_IGNOREPPC entries at the
beginning of the ELF auxiliary vector. The reason for this is that
glibc prior to April 2001 rounded up the address of the base of the
aux vector to a multiple of 16. I think we can now get rid of the
AT_IGNOREPPC entries.
Well, i
On Fri, 21 Sep 2007 18:41:49 +0400
Valentine Barshak <[EMAIL PROTECTED]> wrote:
> This patchset adds cpu_setup functionality to PowerPC 44x,
> moves FPU init to cpu_setup callback and adds 440EPx/440GRx
> incorrect write to DDR SDRAM errata workaround.
This set looks pretty good to me. Aside fro
After Serial gadget is being unloaded, neither serial itself, nor other
gadget stuff can be loaded subsequently.
Signed-off-by: Vitaly Bordug <[EMAIL PROTECTED]>
---
drivers/usb/gadget/serial.c |6 ++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/drivers/usb/gadget/se
On Wed, 2007-09-26 at 15:44 -0400, Steven Rostedt wrote:
> > No wonder here: the -rt patch already has much of this code since around
> > 2.6.21. They have been submitted by me, mostly... and this patchset is
> > against the Linus' tree.
>
> That would explain it ;-)
>
> I was searching the
--
On Wed, 26 Sep 2007, Sergei Shtylyov wrote:
> Hello.
>
> Steven Rostedt wrote:
> > Tony,
>
> > I'm about to release a new -rt patch based on -rc8. This patch series
> > blew up totally in trying to get it applied. I'm leaving it out, so after
> > I release the next series, could you update the
Hello.
Steven Rostedt wrote:
> Tony,
> I'm about to release a new -rt patch based on -rc8. This patch series
> blew up totally in trying to get it applied. I'm leaving it out, so after
> I release the next series, could you update these patches.
No wonder here: the -rt patch already has much
Tony,
I'm about to release a new -rt patch based on -rc8. This patch series
blew up totally in trying to get it applied. I'm leaving it out, so after
I release the next series, could you update these patches.
Thanks,
-- Steve
___
Linuxppc-dev mailing
According to the publicly available MPC8360E RM (rev. 1 from 09/2006 and rev. 2
from 05/2007) and MPC8323E RM (rev. 1 from 09/2006), CEURNR is the QE microcode
revision number register and is located at offset 0x1b8 within the QE internal
register space
Signed-off-by: Emil Medve <[EMAIL PROTECTED]
ps3av: add a quirk database for broken monitors where the `best' advertised
video mode doesn't work
Signed-off-by: Geert Uytterhoeven <[EMAIL PROTECTED]>
---
drivers/ps3/ps3av.c | 41 +
1 files changed, 41 insertions(+)
--- a/drivers/ps3/ps3av.c
+++ b/dr
ps3av: don't distinguish between `boot' and `non-boot' autodetection now the
autodetection code has been improved
Signed-off-by: Geert Uytterhoeven <[EMAIL PROTECTED]>
---
drivers/ps3/ps3av.c | 35 ++-
drivers/video/ps3fb.c |6 ++
include/as
ps3av: add autodetection for VESA modes
Signed-off-by: Geert Uytterhoeven <[EMAIL PROTECTED]>
---
drivers/ps3/ps3av.c | 93 ++--
include/asm-powerpc/ps3av.h | 11 -
2 files changed, 67 insertions(+), 37 deletions(-)
--- a/drivers/ps3/ps3av.
ps3av: remove unused ps3av_set_mode()
Signed-off-by: Geert Uytterhoeven <[EMAIL PROTECTED]>
---
drivers/ps3/ps3av.c | 21 -
include/asm-powerpc/ps3av.h |1 -
2 files changed, 22 deletions(-)
--- a/drivers/ps3/ps3av.c
+++ b/drivers/ps3/ps3av.c
@@ -903,27 +903,6 @
ps3av: use PS3 video mode ids in autodetect code
It doesn't make much sense to use the PS3AV_CMD_VIDEO_VID_* values in the
autodetection code, just to convert them to PS3 video mode ids afterwards.
Signed-off-by: Geert Uytterhoeven <[EMAIL PROTECTED]>
---
drivers/ps3/ps3av.c | 90 +
ps3av: treat DVI-D monitors like HDMI monitors when autodetecting the best
video mode
Signed-off-by: Geert Uytterhoeven <[EMAIL PROTECTED]>
---
drivers/ps3/ps3av.c | 24
include/asm-powerpc/ps3av.h |1 -
2 files changed, 8 insertions(+), 17 deletions(-)
---
ps3av: eliminate PS3AV_DEBUG
- Move ps3av_cmd_av_monitor_info_dump from ps3av_cmd.c to ps3av.c, as it's
used there only
- Integrate ps3av_cmd_av_hw_conf_dump() into its sole user
- Use pr_debug() for printing debug info
Signed-off-by: Geert Uytterhoeven <[EMAIL PROTECTED]>
---
drivers/p
ps3av: eliminate unneeded temporary variables
Signed-off-by: Geert Uytterhoeven <[EMAIL PROTECTED]>
---
drivers/ps3/ps3av_cmd.c | 17 ++---
1 files changed, 6 insertions(+), 11 deletions(-)
--- a/drivers/ps3/ps3av_cmd.c
+++ b/drivers/ps3/ps3av_cmd.c
@@ -512,7 +512,6 @@ static const
Hi,
Here are some new patches for the PS3 AV Settings Driver (ps3av), which is
used in close collaboration with the PS3 Virtual Frame Buffer Device Driver
(ps3fb):
[1] ps3av: eliminate unneeded temporary variables
[2] ps3av: eliminate PS3AV_DEBUG
[3] ps3av: use PS3 video mode ids in
On Sep 24, 2007, at 10:46 PM, David Gibson wrote:
> On Mon, Sep 24, 2007 at 01:54:32AM -0500, Milton Miller wrote:
>> On Sep 23, 2007, at 10:36 PM, David Gibson wrote:
>>> On Fri, Sep 21, 2007 at 06:05:06PM -0500, Milton Miller wrote:
> [snip]
+#define MIN_VERSION 2
+#define OUT_VERSION 1
On Fri, Apr 20, 2007 at 03:47:20PM -0500, Linas Vepstas wrote:
> Implement the so-called "first failure data capture" (FFDC) for the
> symbios PCI error recovery. After a PCI error event is reported,
> the driver requests that MMIO be enabled. Once enabled, it
> then reads and dumps assorted stat
The /proc/bus/pci/* files list PCI domain numbers only for
devices that claim to be on a multi-domain system. The check
for this is broken on powerpc, because the buid value is
truncated to 32 bits.
There is at least one machine (IBM QS21) that only uses
the high-order bits of the buid, so the ret
Segher Boessenkool wrote:
Why not put the PVR in core dumps that'd make it all easier..
>>>
>>> PVR wouldn't be very useful... What if you have altivec disabled ? Also
>>> that would mean your gdb has to know about all new processors...
>>
>> Is that such a big deal? :D
>>
>> Hypothetically
> Why not put the PVR in core dumps that'd make it all easier..
PVR wouldn't be very useful... What if you have altivec disabled ?
Also
that would mean your gdb has to know about all new processors...
>>>
>>> Is that such a big deal? :D
>>>
>>> Hypothetically it would be im
On Sep 26, 2007, at 8:21 AM, Segher Boessenkool wrote:
Why not put the PVR in core dumps that'd make it all easier..
>>>
>>> PVR wouldn't be very useful... What if you have altivec disabled ?
>>> Also
>>> that would mean your gdb has to know about all new processors...
>>
>> Is that such a
>>> Why not put the PVR in core dumps that'd make it all easier..
>>
>> PVR wouldn't be very useful... What if you have altivec disabled ?
>> Also
>> that would mean your gdb has to know about all new processors...
>
> Is that such a big deal? :D
>
> Hypothetically it would be impossible to deter
On Tue, Sep 25, 2007 at 11:00:38PM -0500, Kumar Gala wrote:
> I'm still in favor of making it PPC_83xx || QUICC_ENGINE.
Submitting... ;-)
- - - -
From: Anton Vorontsov <[EMAIL PROTECTED]>
Subject: [POWERPC][SPI] spi_mpc83xx: allow use on any processors with QUICC
Engine
Currently, all QE SPI co
>> -avr_clock = *(u32*)of_get_property(avr, "clock-frequency", &len);
>> -phys_addr = ((u32*)of_get_property(avr, "reg", &len))[0];
>> +phys_addr = of_get_property(avr, "reg", &len);
>> +avr_clock_prop = of_get_property(avr, "clock-frequency", &len);
>
> If you don't use the value o
Hello ,
>>
>> hi everyone,
>>
>> I m using custom board similar to MPC8272ADS board...
>>
>> 1) For the first time it boots up properly in case if we overwrite any
>> existing binaries using nfs mounted file system on the board, after
>> rebooting it displays fallowing message...
>>
>> Furth
On Wednesday 26 September 2007, Ishizaki Kou wrote:
> This is a workaround NOT to insert EA=0 entry at initializing SLB.
> Without this patch, you can see /sbin/init hanging at a machine
> which has less or equal than 256MB memory.
Can you elaborate? I don't understand why /sbin/init will hang
bec
On Wednesday 26 September 2007, Ishizaki Kou wrote:
> This is a patch kit to support PCI bus on Celleb with new "I/O routines
> for PowerPC." External PCI on Celleb must do explicit synchronization
> with devices (Bus has no automatic synchronization feature).
It seems you are duplicating a lot of
On Wednesday 26 September 2007, Ishizaki Kou wrote:
> This is a patch to support Power/Reset buttons on Beat on Celleb.
>
> On Beat, we have an event from Beat if Power button or Reset button
> is pressed. This patch catches the event and convert it to a signal
> to INIT process.
>
> /sbin/initta
On Wednesday 26 September 2007, Ishizaki Kou wrote:
> This patch is an update for "Beat on Celleb"
> - Move beat_pause(), beat_kexec_cpu_down() from setup.c to beat.c
>
> Signed-off-by: <[EMAIL PROTECTED]>
Acked-by: Arnd Bergmann <[EMAIL PROTECTED]>
The patch looks good, once you fix this one
I wrote:
> Linus,
>
> Please do
>
> git pull \
> git://git.kernel.org/pub/scm/linux/kernel/git/paulus/powerpc.git merge
>
> to get a patch from Roland McGrath that fixes a user-triggerable oops
> on 64-bit powerpc.
I have added another commit from Jeremy Kerr fixing a mismerge that
caused a us
Benjamin Herrenschmidt wrote:
> On Tue, 2007-09-25 at 19:00 +0100, Matt Sealey wrote:
>> Kumar Gala wrote:
>>> I'm wondering how we distinguish a core dump w/altivec state vs one
>>> with SPE state.
>> Sheer number of registers saved?
>>
>> Why not put the PVR in core dumps that'd make it all ea
Signed-off-by: Joachim Fenkes <[EMAIL PROTECTED]>
---
arch/powerpc/kernel/ibmebus.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/kernel/ibmebus.c b/arch/powerpc/kernel/ibmebus.c
index c1e2963..0bd186c 100644
--- a/arch/powerpc/kernel/ibmebus.c
+++ b/arch
Replace struct ibmebus_dev and struct ibmebus_driver with struct of_device
and struct of_platform_driver, respectively. Match the external ibmebus
interface and drivers using it.
Signed-off-by: Joachim Fenkes <[EMAIL PROTECTED]>
---
drivers/infiniband/hw/ehca/ehca_classes.h |2 +-
drivers/net
The devtree root is now searched for devices matching a built-in whitelist
during boot, so these devices appear on the bus from the beginning. It is
still possible to manually add/remove devices to/from the bus by using the
probe/remove sysfs interface. Also, when a device driver registers itself,
Remove old code that will be replaced by rewritten and shorter functions in
the next patch. Keep struct ibmebus_dev and struct ibmebus_driver for now,
but replace ibmebus_{,un}register_driver() by dummy functions. This way, the
kernel will still compile and run during the transition and git bisect
Extract generic of_device allocation code from of_platform_device_create()
and move it into of_device.[ch], called of_device_alloc(). Also, there's now
of_device_free() which puts the device node.
This way, bus drivers that build on of_platform (like ibmebus will) can
build upon this code instead
This patchset will merge the ibmebus and of_platform bus drivers by basing a
lot of ibmebus functionality on of_platform code and adding the features
specific to ibmebus on top of that.
This is a repost of my previous patchset incorporating Arnd's comments.
I split the actual ibmebus rework into
Arnd Bergmann <[EMAIL PROTECTED]> wrote on 25.09.2007 16:27:57:
> The patch looks good to me, especially since you did exactly what I
> suggested ;-)
Yes, our discussions were very productive. Thanks and sorry I forgot to
mention your input.
> Maybe the description should have another sentence
Arnd Bergmann <[EMAIL PROTECTED]> wrote on 25.09.2007 16:29:51:
> The description makes it sound like a git-bisect would get broken
> by this patch, which should never happen. If the patch indeed
> ends up with a broken kernel, it would be better to merge it with
> the later patch that fixes the c
> > +/* These devices will automatically be added to the bus during init
*/
> > +static struct of_device_id builtin_matches[] = {
> > + { .name = "lhca" },
> > + { .compatible = "IBM,lhca" },
> > + { .name = "lhea" },
> > + { .compatible = "IBM,lhea" },
> > + {},
> > +};
> > +
>
> Hmm,
Arnd Bergmann <[EMAIL PROTECTED]> wrote on 25.09.2007 16:42:40:
> This is missing a description,
The description is "ibmebus: Move to of_device and of_platform_driver,
match eHCA and eHEA drivers" -- I thought that should be enough since the
patch is rather straightforward. I can add a more det
Hi,
* Andrew Morton <[EMAIL PROTECTED]> [2007-09-25 21:45]:
> On Tue, 25 Sep 2007 20:23:02 +0200 Bernhard Walle <[EMAIL PROTECTED]> wrote:
>
> > This patch adapts the ppc64 code to use the generic parse_crashkernel()
> > function introduced in the generic patch of that series.
>
> I really don't
On Wed, 26 Sep 2007, Kumar Gala wrote:
> On Sep 25, 2007, at 11:56 PM, Mark Nelson wrote:
> > What cores have SPE at the moment? Also, perhaps more importantly,
> > are there any plans to have Altivec and SPE in the same core?
>
> The e500 cores's from Freescale.
>
> No, they are pretty much mu
50 matches
Mail list logo
