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
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 bu
On Fri, Feb 29, 2008 at 10:56:45PM -0500, Steven Rostedt wrote:
>
> On Sat, 1 Mar 2008, Benjamin Herrenschmidt wrote:
> >
> > Do we have any indication that it performs better than the C one ?
>
> See below.
>
> >
> > Ben.
> >
>
> > >
> > > +_GLOBAL(strncmp)
> > > + mtctr r5
> > > + addir
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
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
+++ linux-2.6.25-rc3/dr
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 to
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.
>
>
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
>
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 file
Fix a typo in qe_upload_firmware() that prevented uploading firmware on
systems with more than one RISC core.
Signed-off-by: Timur Tabi <[EMAIL PROTECTED]>
---
This patch is for 2.6.25.
arch/powerpc/sysdev/qe_lib/qe.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arc
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: Usin
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
& device
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 ear
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 64
On Wednesday, February 27, 2008 4:04 pm 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 consolidates most of them to use the version annotated below.
> This is the
>> 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.
> 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 as
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
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 testi
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: Fi
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 betwe
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 d
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 mat
On Mon, 2008-03-03 at 20:51 +0100, Gerhard Pircher wrote:
> > Remove the GFP_HIGHMEM from the above. It looks like our cache
> > flushing isn't going to work for highmem, it would need some
> > kmap's for that.
> Yes, it looks like this was the problem. No kernel oops anymore.
> The machine locks
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 &m
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: Fi
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 f
> 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 long
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 comment
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,
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
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 i
> 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 bac
> In fact, I remember working on 64 bits lockdep, based on patches from
> Johannes,
Your patches never really worked for me so far but I'll be happy to try
new ones, haven't gotten around to checking into the differences.
> but I didn't do 32 bits. I think somebody worked on it, but
> now I can
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
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 = ;
interrupt-map = <
/* IDSEL 1 */
0800 0 0 0 &UIC0 1c
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 __rem
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 necessari
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 = ;
> interrupt-ma
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-lo
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
https://ozlabs.org/mailman/listi
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
>>> 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
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
>
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 = ;
>
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
b/Documentation/feature-remov
* 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
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 dt_from_
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 b
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 inconsistency.
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.
58 matches
Mail list logo
