* Re: compile quirk linux-2.6.24 (with workaround)
From: Bernhard Reiter @ 2008-03-03 17:26 UTC (permalink / raw)
To: debian-powerpc; +Cc: linuxppc-dev, paulus
In-Reply-To: <200802251256.41037.bernhard@intevation.de>
[-- Attachment #1.1: Type: text/plain, Size: 1338 bytes --]
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 effected, we should be able to pass -mcpu=405
> > > for everything and have it still work.
> > >
> > > Bernhard, can you try the patch below?
> >
> > I will test it in the next days.
>
> Done. Looks good.
> (I did _not_ do a full rebuild and installation, only a build test.
> I will do a full blown test with 2.6.24.3.)
Worked fine for me with the attached patch.
Thanks again.
> Note: Your original did not fully apply, I think it had lines like
> -$(obj)/cuboot-taishan.o: BOOTCFLAGS += -mcpu=440
> -$(obj)/cuboot-katmai.o: BOOTCFLAGS += -mcpu=440
> which I did not have in my 2.6.24.
> Probably because you've used a git version of linux.
> What I did was to change the similiar occurances from 440 to 405.
--
Managing Director - Owner: www.intevation.net (Free Software Company)
Germany Coordinator: fsfeurope.org. Coordinator: www.Kolab-Konsortium.com.
Intevation GmbH, Osnabrück, DE; Amtsgericht Osnabrück, HRB 18998
Geschäftsführer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner
[-- Attachment #1.2: linux-2.4.24-fix-ppcbuild-josh-boyer2.diff --]
[-- Type: text/x-diff, Size: 506 bytes --]
--- linux-2.6.24.3/arch/powerpc/boot/Makefile.org 2008-02-26 22:48:00.709872603 +0100
+++ linux-2.6.24.3/arch/powerpc/boot/Makefile 2008-02-26 22:48:17.509876780 +0100
@@ -35,8 +35,8 @@
BOOTCFLAGS += -I$(obj) -I$(srctree)/$(obj)
-$(obj)/4xx.o: BOOTCFLAGS += -mcpu=440
-$(obj)/ebony.o: BOOTCFLAGS += -mcpu=440
+$(obj)/4xx.o: BOOTCFLAGS += -mcpu=405
+$(obj)/ebony.o: BOOTCFLAGS += -mcpu=405
$(obj)/treeboot-walnut.o: BOOTCFLAGS += -mcpu=405
zlib := inffast.c inflate.c inftrees.c
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* [PATCH] fix QE firmware uploading limit
From: Timur Tabi @ 2008-03-03 17:11 UTC (permalink / raw)
To: galak, linuxppc-dev; +Cc: Timur Tabi
Fix a typo in qe_upload_firmware() that prevented uploading firmware on
systems with more than one RISC core.
Signed-off-by: Timur Tabi <timur@freescale.com>
---
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/arch/powerpc/sysdev/qe_lib/qe.c b/arch/powerpc/sysdev/qe_lib/qe.c
index 6efbd5e..f963fbf 100644
--- a/arch/powerpc/sysdev/qe_lib/qe.c
+++ b/arch/powerpc/sysdev/qe_lib/qe.c
@@ -509,7 +509,7 @@ int qe_upload_firmware(const struct qe_firmware *firmware)
}
/* Validate some of the fields */
- if ((firmware->count < 1) || (firmware->count >= MAX_QE_RISC)) {
+ if ((firmware->count < 1) || (firmware->count > MAX_QE_RISC)) {
printk(KERN_ERR "qe-firmware: invalid data\n");
return -EINVAL;
}
--
1.5.4
^ permalink raw reply related
* Re: ARCH=ppc -> ARCH=powerpc : help needed for dts file
From: Scott Wood @ 2008-03-03 17:07 UTC (permalink / raw)
To: Philippe De Muyter; +Cc: linuxppc-dev
In-Reply-To: <20080303144727.GA27949@ingate.macqel>
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 0000:00:12.0 [0000:0000]
> Yenta: Using CSCINT to route CSC interrupts to PCI
> Yenta: Routing CardBus interrupts to PCI
> Yenta TI: socket 0000:00:12.0, mfunc 0x00001b22, devctl 0x64
> irq 18: nobody cared (try booting with the "irqpoll" option)
> Call Trace:
> [cf813af0] [c00066c8] show_stack+0x3c/0x1bc (unreliable)
> [cf813b30] [c003c1ac] __report_bad_irq+0x38/0xcc
> [cf813b50] [c003c4c8] note_interrupt+0x288/0x2cc
> [cf813b80] [c003cc34] handle_fasteoi_irq+0x94/0xf8
Maybe your PCI interrupt-map is wrong...
-Scott
^ permalink raw reply
* Re: [patch 4/6] ARM: move bridge enable out of pcibios_enable_resources()
From: Jesse Barnes @ 2008-03-03 17:59 UTC (permalink / raw)
To: linux-pci
Cc: linux-arch, Chris Zankel, Grant Grundler, linux-parisc,
Matthew Wilcox, Kyle McMartin, linuxppc-dev, Paul Mackerras,
linux-arm-kernel, Russell King, Bjorn Helgaas
In-Reply-To: <20080228001053.013269726@ldl.fc.hp.com>
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 setup correctly for new arches has always been a bit more trouble
than it should be...
>
> Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
>
> Index: work6/arch/arm/kernel/bios32.c
> ===================================================================
> --- work6.orig/arch/arm/kernel/bios32.c 2008-02-27 11:25:29.000000000 -0700
> +++ work6/arch/arm/kernel/bios32.c 2008-02-27 11:55:59.000000000 -0700
> @@ -683,15 +683,32 @@
> cmd |= PCI_COMMAND_MEMORY;
> }
>
> + if (cmd != old_cmd) {
> + printk("PCI: enabling device %s (%04x -> %04x)\n",
> + pci_name(dev), old_cmd, cmd);
Probably worth giving this printk a prefix at some point (doesn't matter for
this patchset though since you're just moving it around).
Rest of it looks good.
Jesse
^ permalink raw reply
* Re: [patch 5/6] PARISC: move PERR & SERR enables out of pcibios_enable_resources()
From: Jesse Barnes @ 2008-03-03 18:30 UTC (permalink / raw)
To: linux-pci
Cc: linux-arch, Chris Zankel, Grant Grundler, linux-parisc,
Matthew Wilcox, Kyle McMartin, linuxppc-dev, Paul Mackerras,
linux-arm-kernel, Russell King, Bjorn Helgaas
In-Reply-To: <20080228173125.GA16270@colo.lackof.org>
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 2000, it might not be correct for
> current 3-D graphics devices which use host mem to buffer processed
> results. I'm thinking of Intel graphics controllers in particular
> but I don't know any details of how they actually work.
Well, in general chipset devices aren't required to support parity checking,
AIUI; Intel gfx devices don't bother (PERR enable is hardwired to 0).
> I'm also a bit concerned about this now becuase (IIRC) AGP didn't
> implement parity though it looked like PCI protocol. PCI-e certainly
> does but it's possible BIOS/Firmware disable parity generation
> on the host bridge when connected to a gfx device.
> We wouldn't want to enable parity checking on a PCI-e gfx device in this
> case and I hope someone (perhaps at Intel) could double check this.
I'd have to ping our BIOS folks to see if that's the case, but I doubt it. It
would be a bad idea to disable any PCIe error reporting (including legacy
error mapping) just because a gfx device was attached. Apparently the AMD
PCIe parts include PERR generation, so disabling upstream reporting at boot
time seems like it would be an outright bug; it should be left up to driver &
OS software.
Jesse
^ permalink raw reply
* [PATCH][MTD][NOR]Add support for the SST 36VF3203 flash chip
From: Andrei Dolnikov @ 2008-03-03 18:01 UTC (permalink / raw)
To: linux-mtd; +Cc: linuxppc-dev
Add support for the SST 36VF3203 flash chip. It is used on Emerson KSI8560 board.
Signed-off-by: Andrei Dolnikov <adolnikov@ru.mvista.com>
---
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 6405938..15e061b 100644
--- a/drivers/mtd/chips/jedec_probe.c
+++ b/drivers/mtd/chips/jedec_probe.c
@@ -160,6 +160,7 @@
#define SST49LF030A 0x001C
#define SST49LF040A 0x0051
#define SST49LF080A 0x005B
+#define SST36VF3203 0x7354
/* Toshiba */
#define TC58FVT160 0x00C2
@@ -1412,6 +1413,18 @@ static const struct amd_flash_info jedec_table[] = {
ERASEINFO(0x1000,256)
}
}, {
+ .mfr_id = MANUFACTURER_SST,
+ .dev_id = SST36VF3203,
+ .name = "SST 36VF3203",
+ .devtypes = CFI_DEVICETYPE_X16|CFI_DEVICETYPE_X8,
+ .uaddr = MTD_UADDR_0x0AAA_0x0555,
+ .dev_size = SIZE_4MiB,
+ .cmd_set = P_ID_AMD_STD,
+ .nr_regions = 1,
+ .regions = {
+ ERASEINFO(0x10000,64),
+ }
+ }, {
.mfr_id = MANUFACTURER_ST,
.dev_id = M29F800AB,
.name = "ST M29F800AB",
^ permalink raw reply related
* Re: [patch 6/6] PCI: consolidate several pcibios_enable_resources() implementations
From: Jesse Barnes @ 2008-03-03 18:45 UTC (permalink / raw)
To: linux-pci
Cc: linux-arch, Chris Zankel, Grant Grundler, linux-parisc,
Matthew Wilcox, Kyle McMartin, linuxppc-dev, Paul Mackerras,
linux-arm-kernel, Russell King, Bjorn Helgaas
In-Reply-To: <20080228001053.404893334@ldl.fc.hp.com>
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 original x86 version, except that it uses the resource
> collision check from powerpc at (5):
Looks really good to me, definitely a step in the right direction.
> The mips/pmc-sierra implementation of pcibios_enable_resources() is
> cluttered with a bunch of titan stuff, so I can't immediately consolidate
> it with the others. So I made the generic version "weak" so pmc-sierra
> can override it.
>
> Not-Yet-Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
So you'd like to see the MIPS stuff cleaned up a bit more first before actual
sign-off? Or just more testing?
> 18 files changed, 43 insertions(+), 507 deletions(-)
Nice diffstat. :)
Jesse
^ permalink raw reply
* Re: [PATCH] add strncmp to PowerPC
From: Segher Boessenkool @ 2008-03-03 19:08 UTC (permalink / raw)
To: Gabriel Paubert; +Cc: linuxppc-dev, paulus, LKML, Steven Rostedt
In-Reply-To: <20080303095443.GB27105@iram.es>
>> 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 asm code.
>
> OTOH, I'm a bit surprised by the extsb instructions in the compiler
> generated
> code. We don't compile with -fsigned-char, do we? The clrldi
> instructions are also extremely stupid.
Those are both necessary to be equivalent to the C code, which uses
signed char explicitly. It is generally considered a Good Thing(tm)
for the compiler to generate assembler code equivalent to the C code,
even if the C code is wrong.
> Now that I think a bit more about it, I believe that the C version is
> incorrect
It is. It's a great entry for the IOCCC as well.
I just tested the following (can't guarantee it's correct, just a PoC):
int strncmp(const char *s1, const char *s2, unsigned long /*size_t*/
len)
{
while (len--) {
unsigned char c1, c2;
c1 = *s1++;
c2 = *s2++;
int cmp = c1 - c2;
if (cmp)
return cmp;
if (c1 == 0 || c2 == 0)
break;
}
return 0;
}
which generates (with GCC-4.2.3)
strncmp:
addi 5,5,1
mtctr 5
.L2:
bdz .L11
lbz 0,0(3)
addi 3,3,1
lbz 9,0(4)
addi 4,4,1
cmpwi 7,0,0
subf. 0,9,0
cmpwi 6,9,0
bne- 0,.L4
beq- 7,.L4
bne+ 6,.L2
.L4:
mr 3,0
blr
.L11:
li 0,0
mr 3,0
blr
which isn't horrid, although it does some weirdish things obviously.
Current GCC-4.4.0 generates
strncmp:
addi 5,5,1
mr 10,3
mtctr 5
li 11,0
bdz .L7
.p2align 4,,15
.L4:
lbzx 0,10,11
lbzx 9,4,11
addi 11,11,1
subf. 3,9,0
cmpwi 6,9,0
cmpwi 7,0,0
bnelr 0
beqlr 7
beqlr 6
bdnz .L4
.L7:
li 3,0
blr
which is about as good as it can get (well, it didn't realise you
only need to test one of c1, c2 for zero. Did I say this was just
proof-of-concept code?)
Segher
^ permalink raw reply
* Re: [PATCH 2/2 v2] [POWERPC] Ignore disabled serial ports
From: Scott Wood @ 2008-03-03 19:09 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-dev, paulus, Arnd Bergmann
In-Reply-To: <20080302224317.15f259ca@zod.rchland.ibm.com>
On Sun, Mar 02, 2008 at 10:43:17PM -0600, Josh Boyer wrote:
> On Mon, 3 Mar 2008 04:43:42 +0100
> Arnd Bergmann <arnd@arndb.de> 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 expressing the idea that the kernel is not supposed to
> > access the specific device. In this case, the device is physically
> > present, but is not available to the OS.
>
> I'd rather not at the moment. My intention was to only look at the
> status property for now. I'd like to avoid this function growing into
> a huge switch statement for $random_firmware's way of flagging
> something as "don't touch".
Better that than having the "huge" list of tests in every driver...
-Scott
^ permalink raw reply
* Re: [PATCH 2/2 v2] [POWERPC] Ignore disabled serial ports
From: Josh Boyer @ 2008-03-03 19:21 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev, paulus, Arnd Bergmann
In-Reply-To: <20080303190925.GA6735@loki.buserror.net>
On Mon, 3 Mar 2008 13:09:25 -0600
Scott Wood <scottwood@freescale.com> 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 <arnd@arndb.de> 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 expressing the idea that the kernel is not supposed to
> > > access the specific device. In this case, the device is physically
> > > present, but is not available to the OS.
> >
> > I'd rather not at the moment. My intention was to only look at the
> > status property for now. I'd like to avoid this function growing into
> > a huge switch statement for $random_firmware's way of flagging
> > something as "don't touch".
>
> Better that than having the "huge" list of tests in every driver...
Perhaps.
This isn't set in stone. I'd rather get what's in the patch in-tree
now and massage it as we go. Otherwise this bike shed will wind up
being rainbow colored yet totally useless because it's a never-ending
patch rework.
josh
^ permalink raw reply
* Re: [patch 6/6] PCI: consolidate several pcibios_enable_resources() implementations
From: Bjorn Helgaas @ 2008-03-03 19:10 UTC (permalink / raw)
To: Jesse Barnes
Cc: linux-arch, Chris Zankel, Grant Grundler, linux-parisc,
Matthew Wilcox, Kyle McMartin, linuxppc-dev, Paul Mackerras,
linux-pci, linux-arm-kernel, Russell King
In-Reply-To: <200803031045.07054.jbarnes@virtuousgeek.org>
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 <bjorn.helgaas@hp.com>
>
> So you'd like to see the MIPS stuff cleaned up a bit more first before actual
> sign-off? Or just more testing?
I think it'd be *nice* if that MIPS stuff got cleaned up, but that's
way beyond my scope. I just want to address Kyle's comments and make
sure I don't screw up ARM and PARISC.
Bjorn
^ permalink raw reply
* Re: [BUG/RFC/PATCH] drm: Fix for non-coherent DMA PowerPC
From: Gerhard Pircher @ 2008-03-03 19:51 UTC (permalink / raw)
To: benh; +Cc: airlied, linuxppc-dev, dri-devel, linux-kernel
In-Reply-To: <1204498569.15052.488.camel@pasglop>
-------- Original-Nachricht --------
> Datum: Mon, 03 Mar 2008 09:56:09 +1100
> Von: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> An: Gerhard Pircher <gerhard_pircher@gmx.net>
> CC: linuxppc-dev@ozlabs.org, dri-devel@lists.sourceforge.net, linux-kernel@vger.kernel.org, airlied@linux.ie
> Betreff: Re: [BUG/RFC/PATCH] drm: Fix for non-coherent DMA PowerPC
> Bah, I think I found the problem:
>
> +static inline void *drm_vmalloc_dma(unsigned long size)
> +{
> +#if defined(__powerpc__) && defined(CONFIG_NOT_COHERENT_CACHE)
> + return __vmalloc(size, GFP_KERNEL | __GFP_HIGHMEM,
> + PAGE_KERNEL | _PAGE_NO_CACHE);
> +#else
> + return vmalloc_32(size);
> +#endif
> +}
> +
>
> 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 up anyway (which is a well known hardware problem).
It doesn't lock up with CPPIOMode=true, but probably only because the
initialization of DRI fails with "BAD cp_mode (f0000000)!".
Gerhard
--
Psssst! Schon vom neuen GMX MultiMessenger gehört?
Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger
^ permalink raw reply
* RE: Xilinx PowerPC
From: Stephen Neuendorffer @ 2008-03-03 19:53 UTC (permalink / raw)
To: monstr; +Cc: linuxppc-embedded
In-Reply-To: <47CAF0FC.70706@seznam.cz>
Michel,
I've had it on my todo list to get the u-boot stuff working for powerpc
too... However, I remember a brief comment from John Williams that
you'd separated the BSP generation process more. Details (or better
yet, code and patches) would be appreciated, here, since I'm a bit
swamped at the moment.
Steve
> -----Original Message-----
> From: Michal Simek [mailto:monstr@seznam.cz]
> Sent: Sunday, March 02, 2008 10:25 AM
> To: Stephen Neuendorffer
> Cc: David H. Lynch Jr.; Grant Likely; linuxppc-embedded
> Subject: Re: Xilinx PowerPC
>=20
> Hi All,
>=20
> > http://git.xilinx.com/gen-mhs-devtree.git contains two utilities for
> > generating device trees from EDK projects. The older option is a
python
> > script, originally written by Grant. The newer (and probably more
> > mature at this point) option is an EDK BSP generator for u-boot,
> > originally written by Michal Simek. Preferably this gets passed
from a
> > uboot, although it's also possible to compile it into the kernel.
> > Currently, the uboot option is somewhat annoying because there's not
a
> > good surefire way for getting uboot up and running on an EDK design.
> > (Unfortunately, the EDK BSP generator is incomplete, and the uboot
> > support for virtex needs some work to get it integrated as well).
>=20
> U-BOOT part will be removed from EDK generator. The new name will be
only
> fdt_v1.00.a. I have prepared separated version for FDT generation and
for U-BOOT
> generation.
>=20
> Steve: You can remove U-BOOT part from generator. This part is useful
only for
> Microblaze cpu.
>=20
> Regards,
> Michal Simek
^ permalink raw reply
* Re: [patch 0/6] RFC: PCI: consolidate pcibios_enable_resources() implementations, v2
From: Russell King @ 2008-03-03 19:44 UTC (permalink / raw)
To: Bjorn Helgaas
Cc: linux-arch, Chris Zankel, Grant Grundler, linux-parisc,
Matthew Wilcox, Kyle McMartin, linuxppc-dev, Paul Mackerras,
linux-pci, linux-arm-kernel
In-Reply-To: <20080228000437.880811124@ldl.fc.hp.com>
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 v1 and v2:
>
> - Moved ARM bridge enable to new platform_pci_enable_device(),
> called by pcibios_enable_device()
Looks fine. However, long term I've no idea what to do about this because
I don't remember the reasoning behind it. So to change it risks breakage
of one sort or another.
It might have been something to do with the Mobility Cardbus docking
station, which adds a pair of P2P bridges onto the PCI chain downstream
of the Cardbus controller, and then a full PCI bus containing USB, VGA,
and other peripherals.
This _once_ used to work with Linux but I suspect as a result of "fixing"
other issues its now utterly broken.
In any case, that docking station isn't ARM specific in any way; merely
a toy Alan Cox sent me. When I gave up my PCMCIA maintainership, I gave
up trying to keep it supported by Linux.
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of:
^ permalink raw reply
* Re: [patch 4/6] ARM: move bridge enable out of pcibios_enable_resources()
From: Benjamin Herrenschmidt @ 2008-03-03 20:35 UTC (permalink / raw)
To: Jesse Barnes
Cc: linux-arch, Chris Zankel, Grant Grundler, linux-parisc,
Matthew Wilcox, Kyle McMartin, linuxppc-dev, Paul Mackerras,
linux-pci, linux-arm-kernel, Russell King, Bjorn Helgaas
In-Reply-To: <200803030959.35625.jbarnes@virtuousgeek.org>
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 of these patches. Getting PCI resources assigned
> & devices setup correctly for new arches has always been a bit more trouble
> than it should be...
You'll noticed that I recently moved powerpc to something more common to
x86 in the are of resource allocation. Still -slightly- different but I
do believe there is room for somebody with some skills to try to turn
some of that into generic code.
Ben.
^ permalink raw reply
* Re: [patch 4/6] ARM: move bridge enable out of pcibios_enable_resources()
From: Jesse Barnes @ 2008-03-03 20:43 UTC (permalink / raw)
To: benh
Cc: linux-arch, Chris Zankel, Grant Grundler, linux-parisc,
Matthew Wilcox, Kyle McMartin, linuxppc-dev, Paul Mackerras,
linux-pci, linux-arm-kernel, Russell King, Bjorn Helgaas
In-Reply-To: <1204576557.21545.4.camel@pasglop>
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 other
> > > architectures and can be shared.
> >
> > I really like the direction of these patches. Getting PCI resources
> > assigned & devices setup correctly for new arches has always been a bit
> > more trouble than it should be...
>
> You'll noticed that I recently moved powerpc to something more common to
> x86 in the are of resource allocation. Still -slightly- different but I
> do believe there is room for somebody with some skills to try to turn
> some of that into generic code.
Yeah, I think that would be a good thing to shoot for. Even on PCs there are
times when we need resource allocation to be done (or re-done) by the kernel
for hotplug or just because the platform is pared down enough that it doesn't
to it all by itself.
I might be able to find time to look into that myself in the next few weeks; I
think we even have some open PCI bugs that could be solved by better resource
allocation.
Jesse
^ permalink raw reply
* Re: [BUG/RFC/PATCH] drm: Fix for non-coherent DMA PowerPC
From: Benjamin Herrenschmidt @ 2008-03-03 20:44 UTC (permalink / raw)
To: Gerhard Pircher; +Cc: airlied, linuxppc-dev, dri-devel, linux-kernel
In-Reply-To: <20080303195117.7040@gmx.net>
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 up anyway (which is a well known hardware problem).
> It doesn't lock up with CPPIOMode=true, but probably only because the
> initialization of DRI fails with "BAD cp_mode (f0000000)!".
Damn, I wonder why you insist trying to make that machine work :-) The
hardware is just totally busted.
Ben.
^ permalink raw reply
* Re: I2S driver
From: Timur Tabi @ 2008-03-03 20:50 UTC (permalink / raw)
To: Angelo; +Cc: Linuxppc-embedded
In-Reply-To: <157246.48338.qm@web23111.mail.ird.yahoo.com>
Angelo wrote:
> Timur wrote:
>>I wrote an ASoC driver for the MPC8610, which also has
>>an I2S interface. You can find it in sound/soc/fsl.
>
> in my kernel version (2.6.22) there isn't any folder named
> fsl in sound/soc/
It's in 2.6.25.
--
Timur Tabi
Linux kernel developer at Freescale
^ permalink raw reply
* Re: ARCH=ppc -> ARCH=powerpc : help needed for dts file
From: Philippe De Muyter @ 2008-03-03 21:05 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev
In-Reply-To: <20080303170719.GC28951@ld0162-tx32.am.freescale.net>
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 :
> >
> > Yenta: CardBus bridge found at 0000:00:12.0 [0000:0000]
> > Yenta: Using CSCINT to route CSC interrupts to PCI
> > Yenta: Routing CardBus interrupts to PCI
> > Yenta TI: socket 0000:00:12.0, mfunc 0x00001b22, devctl 0x64
> > irq 18: nobody cared (try booting with the "irqpoll" option)
> > Call Trace:
> > [cf813af0] [c00066c8] show_stack+0x3c/0x1bc (unreliable)
> > [cf813b30] [c003c1ac] __report_bad_irq+0x38/0xcc
> > [cf813b50] [c003c4c8] note_interrupt+0x288/0x2cc
> > [cf813b80] [c003cc34] handle_fasteoi_irq+0x94/0xf8
>
> 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
1000 0 0 3 &mpic 3 1
1000 0 0 4 &mpic 4 1
/* IDSEL 0x03 */
1800 0 0 1 &mpic 4 1
1800 0 0 2 &mpic 1 1
1800 0 0 3 &mpic 2 1
1800 0 0 4 &mpic 3 1
...
I do not understand anything there :(
Philippe
^ permalink raw reply
* Re: ARCH=ppc -> ARCH=powerpc : help needed for dts file
From: Scott Wood @ 2008-03-03 21:11 UTC (permalink / raw)
To: Philippe De Muyter; +Cc: linuxppc-dev
In-Reply-To: <20080303210532.GA20382@netgate.macqel>
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
> 1000 0 0 4 &mpic 4 1
>
> /* IDSEL 0x03 */
> 1800 0 0 1 &mpic 4 1
> 1800 0 0 2 &mpic 1 1
> 1800 0 0 3 &mpic 2 1
> 1800 0 0 4 &mpic 3 1
>
> ...
Yes.
> I do not understand anything there :(
It maps PCI interrupts to mpic interrupts. The first three cells are
the PCI address (only the device number is unmasked), then the PCI
interrupt (INTA=1, INTB=2, etc.), then a phandle to the parent interrupt
controller, then the interrupt specifier for the parent controller.
-Scott
^ permalink raw reply
* Re: ARCH=ppc -> ARCH=powerpc : help needed for dts file
From: Philippe De Muyter @ 2008-03-03 21:26 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev
In-Reply-To: <47CC696C.4090103@freescale.com>
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
>> 1000 0 0 2 &mpic 2 1
>> 1000 0 0 3 &mpic 3 1
>> 1000 0 0 4 &mpic 4 1
>> /* IDSEL 0x03 */
>> 1800 0 0 1 &mpic 4 1
>> 1800 0 0 2 &mpic 1 1
>> 1800 0 0 3 &mpic 2 1
>> 1800 0 0 4 &mpic 3 1
>> ...
>
> Yes.
>
>> I do not understand anything there :(
>
> It maps PCI interrupts to mpic interrupts. The first three cells are the
> PCI address (only the device number is unmasked), then the PCI interrupt
> (INTA=1, INTB=2, etc.), then a phandle to the parent interrupt controller,
> then the interrupt specifier for the parent controller.
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 spec
below, and it seems to have some positive effect, but I do not know
precisely what I have described there.
I know that 25, 26, 27, 53, 54 and 55 decimal i(hence 19, 1a etc...) are the
interrupts numbers that I had in the ARCH=ppc version. I added 18 because
of the error message, but it did not help.
What should be described here and how ?
Philippe
^ permalink raw reply
* Re: ARCH=ppc -> ARCH=powerpc : help needed for dts file
From: Benjamin Herrenschmidt @ 2008-03-03 21:26 UTC (permalink / raw)
To: Philippe De Muyter; +Cc: Scott Wood, linuxppc-dev
In-Reply-To: <20080303210532.GA20382@netgate.macqel>
> > 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
> 1000 0 0 3 &mpic 3 1
> 1000 0 0 4 &mpic 4 1
>
> /* IDSEL 0x03 */
> 1800 0 0 1 &mpic 4 1
> 1800 0 0 2 &mpic 1 1
> 1800 0 0 3 &mpic 2 1
> 1800 0 0 4 &mpic 3 1
>
> ...
>
> I do not understand anything there :(
It's documented in booting-without-of.txt afaik... The interrupt-map
goes along with the interrupt-map-mask. The later defines which bits of
the map are relevant.
The first part of the map is 3 cells containing a PCI address, followed
by a cell containing a PCI IRQ line (1=A....4=D). The next is the parent
interrupt controller, followed by the IRQ specification, which for MPIC
is the interrupt number on that controller, followed by an encoding of
the interrupt polarity & trigger type (1 for level-low).
The first part, the PCI address, has a special format, which should be
documented as well in the document I pointed out. For readability, we
ommited the top 16 bits of the first cell, which are the address type
and bus number, mostly irrelevant for interrupt mapping. The next bits
are the device/function. Usually only the device part is unmasked.
Ben.
^ permalink raw reply
* Re: [BUG/RFC/PATCH] drm: Fix for non-coherent DMA PowerPC
From: Gerhard Pircher @ 2008-03-03 21:37 UTC (permalink / raw)
To: benh; +Cc: airlied, linuxppc-dev, dri-devel, linux-kernel
In-Reply-To: <1204577051.21545.12.camel@pasglop>
-------- Original-Nachricht --------
> Datum: Tue, 04 Mar 2008 07:44:11 +1100
> Von: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> An: Gerhard Pircher <gerhard_pircher@gmx.net>
> CC: airlied@linux.ie, linux-kernel@vger.kernel.org, dri-devel@lists.sourceforge.net, linuxppc-dev@ozlabs.org
> Betreff: Re: [BUG/RFC/PATCH] drm: Fix for non-coherent DMA PowerPC
> 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 up anyway (which is a well known hardware problem).
> > It doesn't lock up with CPPIOMode=true, but probably only because the
> > initialization of DRI fails with "BAD cp_mode (f0000000)!".
>
> Damn, I wonder why you insist trying to make that machine work :-) The
> hardware is just totally busted.
Because it's a challenge! :) Or because the OS4 developers say that
PCIGART works.
Gerhard
--
Psst! Geheimtipp: Online Games kostenlos spielen bei den GMX Free Games!
http://games.entertainment.web.de/de/entertainment/games/free
^ permalink raw reply
* Re: [PATCH 2/2 v2] [POWERPC] Ignore disabled serial ports
From: Nathan Lynch @ 2008-03-03 21:40 UTC (permalink / raw)
To: Josh Boyer; +Cc: Scott Wood, linuxppc-dev, paulus, Arnd Bergmann
In-Reply-To: <20080303132107.67200634@weaponx>
Josh Boyer wrote:
> On Mon, 3 Mar 2008 13:09:25 -0600
> Scott Wood <scottwood@freescale.com> 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 <arnd@arndb.de> 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 expressing the idea that the kernel is not supposed to
> > > > access the specific device. In this case, the device is physically
> > > > present, but is not available to the OS.
> > >
> > > I'd rather not at the moment. My intention was to only look at the
> > > status property for now. I'd like to avoid this function growing into
> > > a huge switch statement for $random_firmware's way of flagging
> > > something as "don't touch".
> >
> > Better that than having the "huge" list of tests in every driver...
>
> Perhaps.
>
> This isn't set in stone. I'd rather get what's in the patch in-tree
> now and massage it as we go. Otherwise this bike shed will wind up
> being rainbow colored yet totally useless because it's a never-ending
> patch rework.
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.
^ permalink raw reply
* Re: ARCH=ppc -> ARCH=powerpc : help needed for dts file
From: Benjamin Herrenschmidt @ 2008-03-03 21:41 UTC (permalink / raw)
To: Philippe De Muyter; +Cc: Scott Wood, linuxppc-dev
In-Reply-To: <20080303212622.GB20382@netgate.macqel>
> 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 spec
> below, and it seems to have some positive effect, but I do not know
> precisely what I have described there.
>
> I know that 25, 26, 27, 53, 54 and 55 decimal i(hence 19, 1a etc...) are the
> interrupts numbers that I had in the ARCH=ppc version. I added 18 because
> of the error message, but it did not help.
Where is this ? (What node ?) The above looks like the interrupt spec
for a single device with 7 interrupts, is that what you are trying to
do ?
If not, then it's incorrect, you have to figure the interrupt-map out
(it's really not -that- hard).
Ben.
^ 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