On Friday 29 February 2008, Michael Ellerman wrote:
On Fri, 2008-02-29 at 06:12 +0100, Arnd Bergmann wrote:
Hi Paul,
Please pull from:
master.kernel.org:/pub/scm/linux/kernel/git/arnd/cell-2.6.git for-2.6.25
To pick up a few small fixes for the cell platform. Most of it is a
On Fri, Feb 29, 2008 at 12:48:33AM -0500, Jarod Wilson wrote:
Benjamin Herrenschmidt wrote:
On Thu, 2008-02-28 at 13:42 -0500, Jarod Wilson wrote:
On Thursday 28 February 2008 01:25:59 am Benjamin Herrenschmidt wrote:
Under Mac OS X, system.log says FireWire (OHCI) Apple ID 31 built-in now
Gabriel Paubert [EMAIL PROTECTED] writes:
Now that I think a bit more about it, I believe that the C version is
incorrect: the clrldi/extsb dance takes a value between -255 and +255
and collapses it into the -128 to 127 range, meaning that the return
value may be wrong if we rely on the sign
Linus,
Please do:
git pull \
git://git.kernel.org/pub/scm/linux/kernel/git/paulus/powerpc.git merge
to get a collection of bug-fixes for powerpc, for the Cell, 4xx and
52xx platforms.
Thanks,
Paul.
arch/powerpc/boot/cuboot-bamboo.c|1
arch/powerpc/boot/cuboot-ebony.c
Fixed Kconfig: ehea driver requires sparse mem
Signed-off-by: Thomas Klein [EMAIL PROTECTED]
---
diff -Nurp linux-2.6.25-rc3.org/drivers/net/Kconfig
linux-2.6.25-rc3/drivers/net/Kconfig
--- linux-2.6.25-rc3.org/drivers/net/Kconfig2008-02-24 22:25:54.0
+0100
+++
Hi all,
I have a currently almost working ARCH=ppc linux-2.6.24 configuration for a
new mpc8540 board (except for a RTC chip connected to an i2c bus).
Knowing that ARCH=ppc will be removed, I try to make the ARCH=powerpc version
work, but that's not easy.
I have copied the mpc8540ads.dts file
On Mon, Mar 3, 2008 at 7:47 AM, Philippe De Muyter [EMAIL PROTECTED] wrote:
My root device is on a compact-flash connected to a PCI yenta chip from TI,
and this one is not working, altough it seems to be discovered :
Yenta: CardBus bridge found at :00:12.0 [:]
Gabriel Paubert wrote:
I have a Pismo which I use on a virtually
daily basis (and about to remove the last remnants of MacOS on it).
However I have disabled Firewire because it would not sleep and wake
up properly.
I can test it on Wednesday with a 5GB fireflly disk from 2001.
Please
Paul, can you please pick up this one too?
http://patchwork.ozlabs.org/linuxppc/patch?id=16965
Thanks,
g.
On Mon, Mar 3, 2008 at 4:41 AM, Paul Mackerras [EMAIL PROTECTED] wrote:
Linus,
Please do:
git pull \
git://git.kernel.org/pub/scm/linux/kernel/git/paulus/powerpc.git merge
to
On Monday 25 February 2008 12:56, Bernhard Reiter wrote:
On Friday 22 February 2008 15:50, Bernhard Reiter wrote:
Ok, so it seems -mcpu=440 was added in gcc 3.4. The -mcpu=405 option
has been around since 2001. Seeing as how there really isn't anything
440 specific in the files
On Mon, Mar 03, 2008 at 03:47:27PM +0100, Philippe De Muyter wrote:
My root device is on a compact-flash connected to a PCI yenta chip from TI,
and this one is not working, altough it seems to be discovered :
Yenta: CardBus bridge found at :00:12.0 [:]
Yenta: Using
On Wednesday, February 27, 2008 4:04 pm Bjorn Helgaas wrote:
Move bridge enable from pcibios_enable_resources() to
platform_pci_enable_device() so the former matches other
architectures and can be shared.
I really like the direction of these patches. Getting PCI resources assigned
devices
On Thursday, February 28, 2008 9:31 am Grant Grundler wrote:
In general, I'm wondering if the check for device class would be
sufficient here to NOT enable PERR/SERR for graphics automatically.
While disabling PERR was the right thing for older mostly write
devices of the 1990's and early
Add support for the SST 36VF3203 flash chip. It is used on Emerson KSI8560
board.
Signed-off-by: Andrei Dolnikov [EMAIL PROTECTED]
---
jedec_probe.c | 13 +
1 files changed, 13 insertions(+)
diff --git a/drivers/mtd/chips/jedec_probe.c b/drivers/mtd/chips/jedec_probe.c
index
Even if it was logically faster (which I still doubt) it's a hell of
a lot
of cache lines to waste.
Yeah, 1 on 64-bit and 3 on 32-bit, that's a terrible lot./sarcasm
Indeed, but there are some corner cases that the C code handles. Like
a length of 0 which may lead to infinite loop in the
On Sun, Mar 02, 2008 at 10:43:17PM -0600, Josh Boyer wrote:
On Mon, 3 Mar 2008 04:43:42 +0100
Arnd Bergmann [EMAIL PROTECTED] wrote:
I wonder whether we should move the check for used-by-rtas into the
of_device_is_available function. I understand that used-by-rtas is
another way of
On Mon, 3 Mar 2008 13:09:25 -0600
Scott Wood [EMAIL PROTECTED] wrote:
On Sun, Mar 02, 2008 at 10:43:17PM -0600, Josh Boyer wrote:
On Mon, 3 Mar 2008 04:43:42 +0100
Arnd Bergmann [EMAIL PROTECTED] wrote:
I wonder whether we should move the check for used-by-rtas into the
On Monday 03 March 2008 11:45:06 am Jesse Barnes wrote:
On Wednesday, February 27, 2008 4:04 pm Bjorn Helgaas wrote:
Not-Yet-Signed-off-by: Bjorn Helgaas [EMAIL PROTECTED]
So you'd like to see the MIPS stuff cleaned up a bit more first before actual
sign-off? Or just more testing?
I
Original-Nachricht
Datum: Mon, 03 Mar 2008 09:56:09 +1100
Von: Benjamin Herrenschmidt [EMAIL PROTECTED]
An: Gerhard Pircher [EMAIL PROTECTED]
CC: linuxppc-dev@ozlabs.org, [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL
PROTECTED]
Betreff: Re: [BUG/RFC/PATCH] drm: Fix for
On Wed, Feb 27, 2008 at 05:04:37PM -0700, Bjorn Helgaas wrote:
There are many implementations of pcibios_enable_resources() that differ
in minor ways that look more like bugs than architectural differences.
This patch series consolidates most of them to use the x86 version.
Changes between
On Mon, 2008-03-03 at 09:59 -0800, Jesse Barnes wrote:
On Wednesday, February 27, 2008 4:04 pm Bjorn Helgaas wrote:
Move bridge enable from pcibios_enable_resources() to
platform_pci_enable_device() so the former matches other
architectures and can be shared.
I really like the direction
On Monday, March 03, 2008 12:35 pm Benjamin Herrenschmidt wrote:
On Mon, 2008-03-03 at 09:59 -0800, Jesse Barnes wrote:
On Wednesday, February 27, 2008 4:04 pm Bjorn Helgaas wrote:
Move bridge enable from pcibios_enable_resources() to
platform_pci_enable_device() so the former matches
Hi Scott,
On Mon, Mar 03, 2008 at 11:07:20AM -0600, Scott Wood wrote:
On Mon, Mar 03, 2008 at 03:47:27PM +0100, Philippe De Muyter wrote:
My root device is on a compact-flash connected to a PCI yenta chip from TI,
and this one is not working, altough it seems to be discovered :
Philippe De Muyter wrote:
Is the PCI-interrupt map that part of the dts file :
interrupt-map =
/* IDSEL 0x02 */
1000 0 0 1 mpic 1 1
1000 0 0 2 mpic 2 1
1000 0 0 3 mpic 3 1
Hi Scott,
On Mon, Mar 03, 2008 at 03:11:08PM -0600, Scott Wood wrote:
Philippe De Muyter wrote:
Is the PCI-interrupt map that part of the dts file :
interrupt-map =
/* IDSEL 0x02 */
1000 0 0 1 mpic 1 1
Maybe your PCI interrupt-map is wrong...
Is the PCI-interrupt map that part of the dts file :
interrupt-map =
/* IDSEL 0x02 */
1000 0 0 1 mpic 1 1
1000 0 0 2 mpic 2 1
Original-Nachricht
Datum: Tue, 04 Mar 2008 07:44:11 +1100
Von: Benjamin Herrenschmidt [EMAIL PROTECTED]
An: Gerhard Pircher [EMAIL PROTECTED]
CC: [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED],
linuxppc-dev@ozlabs.org
Betreff: Re: [BUG/RFC/PATCH] drm: Fix for
Josh Boyer wrote:
On Mon, 3 Mar 2008 13:09:25 -0600
Scott Wood [EMAIL PROTECTED] wrote:
On Sun, Mar 02, 2008 at 10:43:17PM -0600, Josh Boyer wrote:
On Mon, 3 Mar 2008 04:43:42 +0100
Arnd Bergmann [EMAIL PROTECTED] wrote:
I wonder whether we should move the check for used-by-rtas
Thanks
The following seems important also :
/*
interrupts = 18 2;
*/
/* interrupts number are coded in hexa ! */
interrupts = 12 2 19 2 1a 2 1b 2 35 2 36 2 37 2;
I have replaced the interrupts spec in comments by the longer interrupts
Philippe De Muyter wrote:
The following seems important also :
/*
interrupts = 18 2;
*/
/* interrupts number are coded in hexa ! */
interrupts = 12 2 19 2 1a 2 1b 2 35 2 36 2 37 2;
I have replaced the interrupts spec in comments by the
Hi I am trying to get PREEMPT_RT pach to wokr on my 2.6.24 kernel, but
kept gettign a BUG() (kernel BUG at kernel/rtmutex.c:692).
While tryiong to figure out what it was, I saw some mention of trying
LOCKDEP to see what is going on, so I patched my -rt1 kernel with some
lockdep patches from BenH.
On Mon, 2008-03-03 at 16:10 -0600, Rune Torgersen wrote:
Hi I am trying to get PREEMPT_RT pach to wokr on my 2.6.24 kernel, but
kept gettign a BUG() (kernel BUG at kernel/rtmutex.c:692).
While tryiong to figure out what it was, I saw some mention of trying
LOCKDEP to see what is going on, so
Benjamin Herrenschmidt wrote:
On Mon, 2008-03-03 at 16:10 -0600, Rune Torgersen wrote:
Hi I am trying to get PREEMPT_RT pach to wokr on my 2.6.24 kernel,
What core is in the 8280 ? At this stage, I wouldn't rule out a bug in
the lockdep patches, I need to do more work on them.
Should be an
On Mon, 2008-03-03 at 16:44 -0600, Rune Torgersen wrote:
Benjamin Herrenschmidt wrote:
On Mon, 2008-03-03 at 16:10 -0600, Rune Torgersen wrote:
Hi I am trying to get PREEMPT_RT pach to wokr on my 2.6.24 kernel,
What core is in the 8280 ? At this stage, I wouldn't rule out a bug in
the
From: Benjamin Herrenschmidt
In fact, I remember working on 64 bits lockdep, based on patches from
Johannes, but I didn't do 32 bits. I think somebody worked on it, but
now I can't find the patches...
http://patchwork.ozlabs.org/linuxppc/patch?id=16652
Whoever did it can bounce them back to
This looks like it is to a stable usable point now. In my opinion it is
ready to be merged into the next tree for 2.6.26.
Reviewed-by: Joel Schopp [EMAIL PROTECTED]
Manish Ahuja wrote:
Changes from previous version:
The only changes are in patch 2.
moved early_init_dt_scan_phyp_dump from
I'm having two problems with PCI interrupts as described in bamboo.dts.
Here is are the properties in question:
/* Bamboo has all 4 IRQ pins tied together per slot */
interrupt-map-mask = f800 0 0 0;
interrupt-map =
/* IDSEL 1 */
0800 0 0 0
Michael Ellerman wrote:
On Thu, 2008-02-28 at 08:46 -0800, Badari Pulavarty wrote:
Hotplug memory notifier for ppc64. This gets invoked by writing
the device-node that needs to be removed to /proc/ppc64/ofdt.
We need to adjust the sections and remove sysfs entries by
calling
On Monday 03 March 2008, Nathan Lynch wrote:
I agree. Josh's patch is immediately useful to other code as-is.
used-by-rtas is powerpc-specific and doesn't belong in drivers/of IMO.
Ok, makes sense, plus paulus looked at the PAPR spec with me and we found
that used-by-rtas doesn't necessarily
On Mon, Mar 03, 2008 at 06:02:33PM -0600, Hollis Blanchard wrote:
I'm having two problems with PCI interrupts as described in bamboo.dts.
Here is are the properties in question:
/* Bamboo has all 4 IRQ pins tied together per slot */
interrupt-map-mask = f800 0 0 0;
On Tue, 2008-03-04 at 11:59 +1100, David Gibson wrote:
Uh.. there's no binding written down, it's just encoded into uic.c.
But UIC doesn't use OpenPIC sensitivity encoding. Like FSL's IPIC, it
uses Linux IRQ_TYPE values from include/linux/irq.h which makes 8
level sensitive, active-low.
Guys,
Sorry to bother everyone, but someone at MontaVista
who was trying to get the DTC today needs to update
their version of git to be something modern.
Thanks,
jdl
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
On Tue, Mar 04, 2008 at 12:42:47PM +1100, Benjamin Herrenschmidt wrote:
On Tue, 2008-03-04 at 11:59 +1100, David Gibson wrote:
Uh.. there's no binding written down, it's just encoded into uic.c.
But UIC doesn't use OpenPIC sensitivity encoding. Like FSL's IPIC, it
uses Linux IRQ_TYPE
Uh.. there's no binding written down, it's just encoded into uic.c.
But UIC doesn't use OpenPIC sensitivity encoding. Like FSL's IPIC,
it
uses Linux IRQ_TYPE values from include/linux/irq.h which makes 8
level sensitive, active-low.
On a related note: aren't we taking a risk here of
On Tue, Mar 04, 2008 at 03:07:50AM +0100, Segher Boessenkool wrote:
Uh.. there's no binding written down, it's just encoded into uic.c.
But UIC doesn't use OpenPIC sensitivity encoding. Like FSL's IPIC,
it
uses Linux IRQ_TYPE values from include/linux/irq.h which makes 8
level
On Mon, 03 Mar 2008 18:02:33 -0600
Hollis Blanchard [EMAIL PROTECTED] wrote:
I'm having two problems with PCI interrupts as described in bamboo.dts.
Here is are the properties in question:
/* Bamboo has all 4 IRQ pins tied together per slot */
interrupt-map-mask = f800 0 0 0;
It would be a pity if we can't all enjoy this.
Signed-off-by: Segher Boessenkool [EMAIL PROTECTED]
---
Documentation/feature-removal-schedule.txt |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/Documentation/feature-removal-schedule.txt
* eval_literal() is defined and used only in the parser, so make it
static.
* The Bison documentation explicitly permits yyerror() to be a
variadic function, so fold yyerror() and yyerrorf() into a single
printf-style function. The combined function is defined and used
only in the parse,
On Mon, 2008-03-03 at 21:37 -0600, Josh Boyer wrote:
I plugged in an old 3Com ethernet card tonight. Slot 0. It was
assigned dev #4 IRQ 25. Using the device tree as-is, I could see
interrupts happening in /proc/interrupts but ethernet traffic failed.
Then I changed the sense level to 4
On Tue, Mar 04, 2008 at 04:10:39PM +1100, David Gibson wrote:
dt_from_source() and dt_from_fs() both take a filename (or directory
name) argument and open files as necessary themselves.
dt_from_blob(), however, expects the caller to open a file and pass it
in.
This patch makes
On Tuesday 04 March 2008, Josh Boyer wrote:
Is anybody using Bamboo PCI support right now? Does it actually work?
I plugged in an old 3Com ethernet card tonight. Slot 0. It was
assigned dev #4 IRQ 25. Using the device tree as-is, I could see
interrupts happening in /proc/interrupts but
dt_from_source() and dt_from_fs() both take a filename (or directory
name) argument and open files as necessary themselves.
dt_from_blob(), however, expects the caller to open a file and pass it
in.
This patch makes dt_from_blob() take a filename and open its own
files, removing the
On Tue, 2008-03-04 at 07:15 +0100, Stefan Roese wrote:
Using '8' is correct. PCI interrupts are *always* level sensitive and
active
low.
Unless you use one of those strange bridges that stick not gates on the
PCI IRQ inputs :-) But I don't think that's the case on the 440EP.
Ben.
53 matches
Mail list logo
