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.
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 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
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_
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.
* 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,
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
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 = ;
>
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
>
>>> 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 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
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, 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
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 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
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
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
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
> 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
> 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
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
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: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,
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.
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
> 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
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
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
> > 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
>
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
>>
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 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 :
> >
> >
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
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 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 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
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 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
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 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
>> 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 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
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 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
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 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
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 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
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
>
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.
>
>
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 [:]
>
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
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
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
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
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
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 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
58 matches
Mail list logo
