Re: [Cbe-oss-dev] Please pull 'for-2.6.25' branch of cell tree
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 follow-up to the IOMMU rework that got merged in 2.6.25-rc1 and caused problems on machines with large amounts of memory. Sorry, I have updated versions of the IOMMU patches to send. Arnd is away for the weekend, so Paul if you just want to cherry pick the other fixes that might work. I'll send the updated IOMMU patches momentarily. The git tree should finally be fixed up now, same location as before, commit ID is now da40451bba23b51eaca4170a095891646ce72104. Arnd ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/2] firewire: endianess fix
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 active. Could still be lucent though, judging by the subsys device ID of 5811, which matches up w/the Lucent/Agere FW323. But no, apparently I don't have the interesting one. Well, it's interesting in the sense that it's a normal OHCI then on a BE machine :-) My Pismo, which had the weirdo one, unfortunately died a while ago. I'll see if I can find another machine with that one in. Ah, the pismo has it, eh? I think I may actually know of someone in the office that still has one of those that I might be able to borrow and poke at... I -think- it has it... Pismo definitely has one of the first variant of UniNorth with working FW afaik. The first UniNorth was used in the first toilet-seat ibook, but I think this one didn't have firewire, or a non-working one... and in the first Sawtooth G4 for which FW and Ethernet even were separate PCI chips because the ones in UniNorth were too broken. It's possible that early G4 titanium powerbooks or other model of FW iBooks have that UniNorth FW variant too. Still no luck finding one here. The person I was thinking of has a Lombard, which has no firewire. I did get ahold of a 667MHz Titanium, but its got an Agere FW323. Pretty sure my old man actually has a Pismo, but its about a 3000 mile drive over to my folks house. The search continues... I wonder how many people still actually 1) have a machine with this controller, 2) are running Linux on it and 3) use firewire devices with it. Both of you, please speak up, we're trying to help you! (if only out of morbid curiosity to see this mythical goofy controller). Definitely yes to 1) and 2), 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 tell me which configuration options I need to set for Firewire (which stack, etc...). Regards, Gabriel ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] add strncmp to PowerPC
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 of the result. So unless I miss something, the problem is much more serious than just stupid code (I had just a look at the libc version in C and characters are cast to unsigned char before the comparison). The latter is explicitly required by the C standard. Ie. even if your characters are signed they are always compared as unsigned by strcmp/strncmp/memcmp. Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 And now for something completely different. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Please pull powerpc.git merge branch
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 |1 arch/powerpc/boot/cuboot-katmai.c|1 arch/powerpc/boot/cuboot-taishan.c |2 arch/powerpc/boot/cuboot-warp.c |1 arch/powerpc/boot/dts/haleakala.dts |2 arch/powerpc/boot/dts/katmai.dts | 58 +- arch/powerpc/oprofile/op_model_cell.c|2 arch/powerpc/platforms/52xx/mpc52xx_common.c |1 arch/powerpc/platforms/cell/iommu.c | 151 +++--- arch/powerpc/platforms/cell/setup.c |7 + arch/powerpc/platforms/cell/spu_base.c | 16 ++- arch/powerpc/platforms/cell/spufs/context.c |7 + arch/powerpc/platforms/cell/spufs/file.c | 12 ++ arch/powerpc/platforms/cell/spufs/sched.c|2 arch/powerpc/platforms/cell/spufs/sputrace.c |7 + arch/powerpc/platforms/cell/spufs/switch.c |6 + arch/powerpc/platforms/celleb/beat.h |3 - drivers/char/xilinx_hwicap/buffer_icap.c | 80 +++--- drivers/char/xilinx_hwicap/fifo_icap.c | 60 +- drivers/char/xilinx_hwicap/xilinx_hwicap.c | 138 +++- drivers/char/xilinx_hwicap/xilinx_hwicap.h | 24 ++-- include/asm-powerpc/reg.h|3 + 23 files changed, 318 insertions(+), 267 deletions(-) Andre Detsch (1): [POWERPC] spufs: fix use time accounting on SPE-overcommit Arnd Bergmann (3): [POWERPC] spufs: synchronize IRQ when disabling [POWERPC] spufs: invalidate SLB translation before adding a new entry [POWERPC] spufs: serialize SLB invalidation against SLB loading Bob Nelson (1): [POWERPC] OProfile: enable callgraph support for Cell Eric Dujardin (1): [POWERPC] Add export for mpc52xx_set_psc_clkdiv Jens Osterkamp (2): [POWERPC] move celleb DABRX definitions [POWERPC] enable hardware watchpoints on cell blades Jeremy Kerr (3): [POWERPC] spufs: fix context destruction during psmap fault [POWERPC] spufs: fix invalid scheduling of forgotten contexts [POWERPC] spufs: fix order of sputrace thread IDs Josh Boyer (1): [POWERPC] 4xx: Use correct board info structure in cuboot wrappers Michael Ellerman (8): [POWERPC] Clearup cell IOMMU fixed mapping terminology [POWERPC] Use it_offset not pte_offset in cell IOMMU code [POWERPC] Remove unused pte_offset variable [POWERPC] Move allocation of cell IOMMU pad page [POWERPC] Split setup of IOMMU stab and ptab, allocate dynamic/fixed ptabs separately [POWERPC] Cell IOMMU: n_pte_pages is in 4K page units, not IOMMU_PAGE_SIZE [POWERPC] Allow for different IOMMU page sizes in cell IOMMU code [POWERPC] Convert the cell IOMMU fixed mapping to 16M IOMMU pages Stefan Roese (2): [POWERPC] 4xx: Fix Haleakala PCIe compatibility problem in dts [POWERPC] 4xx: Fix L1 cache size in katmai DTS Stephen Neuendorffer (1): [POWERPC] Xilinx: hwicap cleanup Valentine Barshak (1): [POWERPC] 44x: add missing define TARGET_4xx and TARGET_440GX to cuboot-taishan ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] ehea: Fix missing Kconfig dependency
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/drivers/net/Kconfig2008-03-03 13:36:48.0 +0100 @@ -2513,7 +2513,7 @@ config CHELSIO_T3 config EHEA tristate eHEA Ethernet support - depends on IBMEBUS INET + depends on IBMEBUS INET SPARSEMEM select INET_LRO ---help--- This driver supports the IBM pSeries eHEA ethernet adapter. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
ARCH=ppc - ARCH=powerpc : help needed for dts file
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 a new dts file, and added the
following :
[EMAIL PROTECTED] {
+ #address-cells = 1;
+ #size-cells = 0;
device_type = i2c;
compatible = fsl-i2c;
reg = 3000 100;
interrupts = 2b 2;
interrupt-parent = mpic;
dfsrr;
+
+ [EMAIL PROTECTED] {
+ compatible = stm,m41t81;
+ reg = 68;
+ };
};
and I see in the boot log that my RTC chip is now working.
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 CSCINT to route CSC interrupts to PCI
Yenta: Routing CardBus interrupts to PCI
Yenta TI: socket :00:12.0, mfunc 0x1b22, 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
but my boot finally fails with :
VFS: Cannot open root device hda1 or unknown-block(0,0)
Please append a correct root= boot option; here are the
available partitions:
1f00 8192 mtdblock0 (driver?)
Kernel panic - not syncing: VFS: Unable to mount root fs
on unknown-block(0,0)
Is there an easy way to use values found in /proc or even in the sources
in my working ppc setup to put them in the dts file to make my new powerpc
configuration work ?
Thanks for listening
Philippe
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: ARCH=ppc - ARCH=powerpc : help needed for 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 [:] Yenta: Using CSCINT to route CSC interrupts to PCI Yenta: Routing CardBus interrupts to PCI Yenta TI: socket :00:12.0, mfunc 0x1b22, 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 but my boot finally fails with : VFS: Cannot open root device hda1 or unknown-block(0,0) Please append a correct root= boot option; here are the available partitions: 1f00 8192 mtdblock0 (driver?) Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0) Is there an easy way to use values found in /proc or even in the sources in my working ppc setup to put them in the dts file to make my new powerpc configuration work ? It does not look like you are having dts problems. Once your in the PCI domain, Linux will probe the devices (as your boot log shows). Rather, your boot failure is due to the yenta device failure. Cheers, g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/2] firewire: endianess fix
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 tell me which configuration options I need to set for Firewire (which stack, etc...). Config options of the new stack: FIREWIRE=m FIREWIRE_OHCI=m FIREWIRE_SBP2=m Config options of the old stack: IEEE1394=m IEEE1394_OHCI1394=m IEEE1394_SBP2=m and if desired also the other drivers for raw userspace access, isochronous I/O (alias video1394 even though it can also be used for other purposes), DV I/O, and IPv4 over 1394. The two SBP2 drivers also need SCSI and BLK_DEV_SD a.k.a. SCSI disk support or/and BLK_DEV_SR a.k.a. SCSI CDROM support. You can also set the options to Y but I find loadable and hence unloadable modules more practical... 'cause I unload and reload them all the time. :-) Regarding which of the two stacks to build: If you are going to test FireWire with a storage device only, then you can choose either stack. Caveats: - You could build and install both stacks but should then blacklist at least one of ohci1394 or firewire-ohci. Better keep it simple and install only one of the stacks at a time. - We still have a serious use-after-free bug in the new stack. This may lead to kernel panic if the kernel was build with (slab? or page allocation?) debugging enabled. Users of IP over 1394 and pro/semipro audio still need the old stack. Users of video should stick with the stack which their distribution has enabled because our support in the lowlevel libraries libraw1394 and libdc1394 to switch between the stacks is not quite comfortable yet. Suspend (to RAM) and resume worked for me [TM] when I last tested them with each stack. I tested i586/APM, x86-64/ACPI, and last weekend ppc32 on 1st generation PowerBook G4. I haven't tested hibernate (to disk) and restore yet. For successful resume on the Pismo with the new stack, you will most certainly need the brand new patches which add PPC_PMAC platform support to firewire-ohci. From what I saw with the PowerBook, you will also need the UniNorth rev1 related patch. I wasn't able to fully test that patch though because the electrical interface of my PowerBook's onboard FireWire is dead. You can get the patches from kernel.org's linux1394-2.6.git (master branch, close to Linus's latest linux-2.6.git) or http://me.in-berlin.de/~s5r6/linux1394/updates/ (for a few kernel.org kernels). The old stack as found in any remotely recent 2.6 kernel should be OK out of the box without patches... in theory. I wouldn't be surprised of until now unreported bugs or old reported but forgotten bugs though. -- Stefan Richter -=-==--- --== ---== http://arcgraph.de/sr/ ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Please pull powerpc.git merge branch
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 get a collection of bug-fixes for powerpc, for the Cell, 4xx and 52xx platforms. Thanks, Paul. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: compile quirk linux-2.6.24 (with workaround)
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 --- 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 pgpBJiL4YehAx.pgp Description: PGP signature ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: ARCH=ppc - ARCH=powerpc : help needed for dts file
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 CSCINT to route CSC interrupts to PCI Yenta: Routing CardBus interrupts to PCI Yenta TI: socket :00:12.0, mfunc 0x1b22, 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 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [patch 4/6] ARM: move bridge enable out of pcibios_enable_resources()
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 [EMAIL PROTECTED]
Index: work6/arch/arm/kernel/bios32.c
===
--- work6.orig/arch/arm/kernel/bios32.c 2008-02-27 11:25:29.0
-0700
+++ work6/arch/arm/kernel/bios32.c2008-02-27 11:55:59.0 -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
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [patch 5/6] PARISC: move PERR SERR enables out of pcibios_enable_resources()
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 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH][MTD][NOR]Add support for the SST 36VF3203 flash chip
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 6405938..15e061b 100644
--- a/drivers/mtd/chips/jedec_probe.c
+++ b/drivers/mtd/chips/jedec_probe.c
@@ -160,6 +160,7 @@
#define SST49LF030A0x001C
#define SST49LF040A0x0051
#define SST49LF080A0x005B
+#define SST36VF32030x7354
/* 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(0x1,64),
+ }
+ }, {
.mfr_id = MANUFACTURER_ST,
.dev_id = M29F800AB,
.name = ST M29F800AB,
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] add strncmp to PowerPC
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
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 2/2 v2] [POWERPC] Ignore disabled serial ports
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 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 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 2/2 v2] [POWERPC] Ignore disabled serial ports
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 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 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [patch 6/6] PCI: consolidate several pcibios_enable_resources() implementations
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 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 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [BUG/RFC/PATCH] drm: Fix for non-coherent DMA PowerPC
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 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 (f000)!.
Gerhard
--
Pt! Schon vom neuen GMX MultiMessenger gehört?
Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [patch 0/6] RFC: PCI: consolidate pcibios_enable_resources() implementations, v2
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 kernel2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of: ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [patch 4/6] ARM: move bridge enable out of pcibios_enable_resources()
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. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [patch 4/6] ARM: move bridge enable out of pcibios_enable_resources()
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 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: ARCH=ppc - ARCH=powerpc : help needed for dts file
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 :00:12.0 [:] Yenta: Using CSCINT to route CSC interrupts to PCI Yenta: Routing CardBus interrupts to PCI Yenta TI: socket :00:12.0, mfunc 0x1b22, 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 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: ARCH=ppc - ARCH=powerpc : help needed for dts file
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 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: ARCH=ppc - ARCH=powerpc : help needed for dts file
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 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: ARCH=ppc - ARCH=powerpc : help needed for dts file
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=A4=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. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [BUG/RFC/PATCH] drm: Fix for non-coherent DMA PowerPC
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 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 (f000)!. 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 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 2/2 v2] [POWERPC] Ignore disabled serial ports
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 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. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: ARCH=ppc - ARCH=powerpc : help needed for dts file
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. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: ARCH=ppc - ARCH=powerpc : help needed for dts file
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 longer interrupts spec below, Why? and it seems to have some positive effect, What kind of positive effect? I'd think the extra interrupts would just be ignored. The interrupts property for the PCI node itself is generally for error reporting. 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 ARCH=ppc version? There are no device trees for non-OF boards in arch/ppc. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
locking problem in sata_sil24?
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.
Now I get an inconsistent locking state, but I need help in trying to
fiure out what I should look for.
kernel is fo an Freescale 8280 and the locking seems to occur in the
driver for a Silicon Image SII3124 SATA disk driver
Linux version 2.6.24-rt1 ([EMAIL PROTECTED]) (gcc version 4.1.2) #12 PREEMPT
RT Mon Mar 3 15:47:03 CST 2008
Trying to allocate DevcomPtr
DevcomHugeMemPtr = c180
Zone PFN ranges:
DMA 0 - 196608
Normal 196608 - 196608
HighMem196608 - 262144
Movable zone start PFN for each node
early_node_map[1] active PFN ranges
0:0 - 262144
Real-Time Preemption Support (C) 2004-2007 Ingo Molnar
Built 1 zonelists in Zone order, mobility grouping on. Total pages:
260096
Kernel command line: root=/dev/sda3 rw console=ttyCPM0,115200
WARNING: experimental RCU implementation.
PID hash table entries: 4096 (order: 12, 16384 bytes)
clocksource: timebase mult[a0c0437] shift[22] registered
console [ttyCPM0] enabled
Lock dependency validator: Copyright (c) 2006 Red Hat, Inc., Ingo Molnar
... MAX_LOCKDEP_SUBCLASSES: 8
... MAX_LOCK_DEPTH: 30
... MAX_LOCKDEP_KEYS: 2048
... CLASSHASH_SIZE: 1024
... MAX_LOCKDEP_ENTRIES: 16384
... MAX_LOCKDEP_CHAINS: 32768
... CHAINHASH_SIZE: 16384
memory used by lock dependency info: 1568 kB
per task-struct memory footprint: 1200 bytes
Dentry cache hash table entries: 131072 (order: 7, 524288 bytes)
Inode-cache hash table entries: 65536 (order: 6, 262144 bytes)
Memory: 1007824k/1048576k available (3240k kernel code, 302324k
reserved, 176k data, 2803k bss, 128k init)
Mount-cache hash table entries: 512
net_namespace: 88 bytes
NET: Registered protocol family 16
PCI: Probing PCI hardware
SCSI subsystem initialized
NET: Registered protocol family 2
IP route cache hash table entries: 32768 (order: 5, 131072 bytes)
TCP established hash table entries: 131072 (order: 8, 1048576 bytes)
TCP bind hash table entries: 32768 (order: 9, 2228224 bytes)
TCP: Hash tables configured (established 131072 bind 32768)
TCP reno registered
krcupreemptd setsched 0
prio = 98
highmem bounce pool size: 64 pages
JFFS2 version 2.2. (NAND) .. 2001-2006 Red Hat, Inc.
io scheduler noop registered
io scheduler anticipatory registered (default)
io scheduler deadline registered
io scheduler cfq registered
ttyCPM0 at MMIO 0xf1050a80 (irq = 16) is a CPM UART
Fixed MDIO Bus: probed
tun: Universal TUN/TAP device driver, 1.6
tun: (C) 1999-2004 Max Krasnyansky [EMAIL PROTECTED]
eth0: fs_enet: 00:30:d7:00:14:52
eth1: fs_enet: 00:30:d7:00:14:53
eth2: fs_enet: 00:30:d7:00:00:01
Driver 'sd' needs updating - please use bus_type methods
scsi0 : sata_sil24
scsi1 : sata_sil24
scsi2 : sata_sil24
scsi3 : sata_sil24
ata1: SATA max UDMA/100 host [EMAIL PROTECTED] port 0x90008000 irq 17
ata2: SATA max UDMA/100 host [EMAIL PROTECTED] port 0x9000a000 irq 17
ata3: SATA max UDMA/100 host [EMAIL PROTECTED] port 0x9000c000 irq 17
ata4: SATA max UDMA/100 host [EMAIL PROTECTED] port 0x9000e000 irq 17
ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 0)
stopped custom tracer.
=
[ INFO: inconsistent lock state ]
[ 2.6.24-rt1 #12
-
inconsistent {hardirq-on-W} - {in-hardirq-W} usage.
swapper/0 [HC1[1]:SC0[0]:HE0:SE1] takes:
(host-lock){+-..}, at: [c01c8e14] sil24_interrupt+0x68/0x53c
{hardirq-on-W} state was registered at:
[c0047724] __lock_acquire+0x494/0xc04
[c0047ee8] lock_acquire+0x54/0x78
[c025c8f0] rt_spin_lock+0x34/0x54
[c01b45ac] ata_dev_init+0x38/0x88
[c01b467c] ata_link_init+0x80/0xa4
[c01b4840] ata_port_alloc+0x1a0/0x1bc
[c01b48f4] ata_host_alloc+0x98/0xf8
[c01b4974] ata_host_alloc_pinfo+0x20/0x104
[c01c83b4] sil24_init_one+0x128/0x390
[c01802f0] pci_device_probe+0x70/0xa8
[c0197d10] driver_probe_device+0x104/0x1ac
[c0197e0c] __driver_attach+0x54/0x8c
[c0197030] bus_for_each_dev+0x58/0xa0
[c0197adc] driver_attach+0x2c/0x44
[c0197778] bus_add_driver+0xb4/0x1b8
[c01980b8] driver_register+0x7c/0x114
[c01803bc] __pci_register_driver+0x60/0x78
[c031e620] sil24_init+0x2c/0x44
[c030a2c8] kernel_init+0xdc/0x334
[c0010408] kernel_thread+0x44/0x60
irq event stamp: 16174
hardirqs last enabled at (16173): [c0046d18]
trace_hardirqs_on+0x1c/0x34
hardirqs last disabled at (16174): [c0045554]
trace_hardirqs_off+0x1c/0x34
softirqs last enabled at (0): [] 0x0
softirqs last disabled at (0): [] 0x0
other info that might help us debug this:
no locks held by swapper/0.
stack backtrace:
Call Trace:
[c0357ca0] [c0008474] show_stack+0x54/0x18c (unreliable)
[c0357cd0] [c00085cc] dump_stack+0x20/0x38
[c0357ce0] [c00460a0]
Re: locking problem in sata_sil24?
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 I patched my -rt1 kernel with some lockdep patches from BenH. Now I get an inconsistent locking state, but I need help in trying to fiure out what I should look for. kernel is fo an Freescale 8280 and the locking seems to occur in the driver for a Silicon Image SII3124 SATA disk driver 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. Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: locking problem in sata_sil24?
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 603e adn revision (from u-boot) CPU: MPC8280 (HiP7 Rev 14, Mask 1.0 1K49M) at 447.897 MHz I am currently compiling a LOCKDEP kernel for my x86 desktop, as it has the exact same SiliconImage controller on a card, so I'll see if it gets a similar detection. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: locking problem in sata_sil24?
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 lockdep patches, I need to do more work on them. Should be an 603e adn revision (from u-boot) CPU: MPC8280 (HiP7 Rev 14, Mask 1.0 1K49M) at 447.897 MHz I am currently compiling a LOCKDEP kernel for my x86 desktop, as it has the exact same SiliconImage controller on a card, so I'll see if it gets a similar detection. 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... Whoever did it can bounce them back to me ? I intend to do some more work on this soon. Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: locking problem in sata_sil24?
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 me ? I intend to do some more work on this soon. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 0/8] pseries: phyp dump: hypervisor-assisted dump
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 rtas.c to phyp_dump.c Added dummy function in phyp_dump.h Patch 3 required repatching due to changes to patch 2. Resubmitting all patches to avoid confusion. Thanks, Manish Michael Ellerman wrote: On Sun, 2008-02-17 at 22:53 -0600, Manish Ahuja wrote: The following series of patches implement a basic framework for hypervisor-assisted dump. The very first patch provides documentation explaining what this is :-) . Yes, its supposed to be an improvement over kdump. A list of open issues / todo list is included in the documentation. It also appears that the not-yet-released firmware versions this was tested on are still, ahem, incomplete; this work is also pending. I have included most of the changes requested. Although, I did find one or two, fixed in a later patch file rather than the first location they appeared at. This series still doesn't build on !CONFIG_RTAS configs: http://kisskb.ellerman.id.au/kisskb/head/629/ This solution is to move early_init_dt_scan_phyp_dump() into arch/powerpc/platforms/pseries/phyp_dump.c and provide a dummy implementation in asm-powerpc/phyp_dump.c for the !CONFIG_PHYP_DUMP case. cheers ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Bamboo PCI interrupt issues
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 UIC0 1c 8 /* IDSEL 2 */ 1000 0 0 0 UIC0 1b 8 /* IDSEL 3 */ 1800 0 0 0 UIC0 1a 8 /* IDSEL 4 */ 2000 0 0 0 UIC0 19 8 ; First, the 440EP[1] and Bamboo[2] user manuals indicate that PCI IRQ 0-3 - board IRQ 2-5 - UIC IRQ 25-28. However, the device tree has that reversed, so PCI IRQ 0 appears as UIC IRQ 28 (0x1c). Second, the sensitivity seems to be wrong. All these interrupts have the sensitivity encoded as 8, which means high to low edge in the OpenPIC binding. Now, 440EP has a UIC, rather than an OpenPIC, but there is no UIC binding AFAICS. When I change the 8 to a 4 (active high level), I see the proper values in the UIC polarity register, and PCI interrupts start working in KVM. Is anybody using Bamboo PCI support right now? Does it actually work? [1] https://www.amcc.com/MyAMCC/retrieveDocument/PowerPC/440EP/PPC440EP_UM2000.pdf [2] Seems to have been deleted from the web. Thanks, AMCC. -- Hollis Blanchard IBM Linux Technology Center ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 3/3] ppc64-specific memory notifier support
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 __remove_pages(). Then call arch specific code to
get rid of htab mappings for the section of memory.
Signed-off-by: Badari Pulavarty [EMAIL PROTECTED]
---
arch/powerpc/platforms/pseries/Makefile |1
arch/powerpc/platforms/pseries/hotplug-memory.c | 98
2 files changed, 99 insertions(+)
Index: linux-2.6.25-rc2/arch/powerpc/platforms/pseries/hotplug-memory.c
===
--- /dev/null 1970-01-01 00:00:00.0 +
+++ linux-2.6.25-rc2/arch/powerpc/platforms/pseries/hotplug-memory.c
2008-02-28 08:20:14.0 -0800
+
+static struct notifier_block pseries_smp_nb = {
+ .notifier_call = pseries_memory_notifier,
+};
+
+static int __init pseries_memory_hotplug_init(void)
+{
+ if (firmware_has_feature(FW_FEATURE_LPAR))
+ pSeries_reconfig_notifier_register(pseries_smp_nb);
+
+ return 0;
+}
+arch_initcall(pseries_memory_hotplug_init);
This is going to fire on non-pseries LPAR platforms, like iSeries and
PS3. Which is not what you want I think.
Well, the notifier will be registered, yes, but it will never be
called because that path is reachable only from a write to
/proc/ppc64/ofdt, which is not created on non-pseries.
Maybe it should be
machine_device_initcall(pseries, pseries_memory_hotplug_init);
(and pseries_cpu_hotplug_init in hotplug-cpu.c should be changed to
machine_arch_initcall)
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 2/2 v2] [POWERPC] Ignore disabled serial ports
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 mean don't touch in all circumstances, so original patch Acked-by: Arnd Bergmann [EMAIL PROTECTED] ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Bamboo PCI interrupt issues
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; interrupt-map = /* IDSEL 1 */ 0800 0 0 0 UIC0 1c 8 /* IDSEL 2 */ 1000 0 0 0 UIC0 1b 8 /* IDSEL 3 */ 1800 0 0 0 UIC0 1a 8 /* IDSEL 4 */ 2000 0 0 0 UIC0 19 8 ; First, the 440EP[1] and Bamboo[2] user manuals indicate that PCI IRQ 0-3 - board IRQ 2-5 - UIC IRQ 25-28. However, the device tree has that reversed, so PCI IRQ 0 appears as UIC IRQ 28 (0x1c). Second, the sensitivity seems to be wrong. All these interrupts have the sensitivity encoded as 8, which means high to low edge in the OpenPIC binding. Now, 440EP has a UIC, rather than an OpenPIC, but there is no UIC binding AFAICS. 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. When I change the 8 to a 4 (active high level), I see the proper values in the UIC polarity register, and PCI interrupts start working in KVM. Is anybody using Bamboo PCI support right now? Does it actually work? [1] https://www.amcc.com/MyAMCC/retrieveDocument/PowerPC/440EP/PPC440EP_UM2000.pdf [2] Seems to have been deleted from the web. Thanks, AMCC. -- David Gibson| I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Bamboo PCI interrupt issues
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. On a related note: aren't we taking a risk here of seeing those values change in linux ? Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
DTC and Git and MontaVista
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/listinfo/linuxppc-dev
Re: Bamboo PCI interrupt issues
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 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 seeing those values change in linux ? We've discussed this before. If that happens, the binding must remain on the old values. It means the driver will then need a translation which it doesn't now, but we can deal with it. -- David Gibson| I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Bamboo PCI interrupt issues
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 seeing those values change in linux ? We've discussed this before. If that happens, the binding must remain on the old values. It means the driver will then need a translation which it doesn't now, but we can deal with it. It also means it should be written down in the binding _already_. Come on, how much work is that? Segher ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Bamboo PCI interrupt issues
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 sensitive, active-low. On a related note: aren't we taking a risk here of seeing those values change in linux ? We've discussed this before. If that happens, the binding must remain on the old values. It means the driver will then need a translation which it doesn't now, but we can deal with it. It also means it should be written down in the binding _already_. Well, yes, there should be, but isn't, a written binding for this, amongst many other things. Come on, how much work is that? Greater than zero. -- David Gibson| I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Bamboo PCI interrupt issues
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; interrupt-map = /* IDSEL 1 */ 0800 0 0 0 UIC0 1c 8 /* IDSEL 2 */ 1000 0 0 0 UIC0 1b 8 /* IDSEL 3 */ 1800 0 0 0 UIC0 1a 8 /* IDSEL 4 */ 2000 0 0 0 UIC0 19 8 ; First, the 440EP[1] and Bamboo[2] user manuals indicate that PCI IRQ 0-3 - board IRQ 2-5 - UIC IRQ 25-28. However, the device tree has that reversed, so PCI IRQ 0 appears as UIC IRQ 28 (0x1c). Actually, the device tree is right. I got annoyed with myself for not knowing how this works so I went and figured it out. 2000 0 0 0 is device #4. According to the specs, device #4 has AD(14) asserted during type 0 configuration. Looking at the board schematics, PCI slot 0 has it's IDSEL line tied to AD(14). So: dev #4 - PCI 0 - board IRQ 2 - UIC IRQ 25. which is exactly what the device tree has. Second, the sensitivity seems to be wrong. All these interrupts have the sensitivity encoded as 8, which means high to low edge in the OpenPIC binding. Now, 440EP has a UIC, rather than an OpenPIC, but there is no UIC binding AFAICS. There isn't. It uses the sense numbers from linux/irq.h. Which means 8 is level, low. This matches exactly what the board manual says for IRQ2-5 on page 69. When I change the 8 to a 4 (active high level), I see the proper values in the UIC polarity register, and PCI interrupts start working in KVM. That's odd. 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 ethernet traffic failed. Then I changed the sense level to 4 as you suggested, and my card hung hard on the first ethernet traffic. I've no idea if we're dealing with a crappy card or a crappy driver but the device tree seems to be working ok. If I can find a different card to test with I will. Ben, do you have any input here? josh ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] Correct a terrible scheduling error
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-removal-schedule.txt index c1d1fd0..78021bf 100644 --- a/Documentation/feature-removal-schedule.txt +++ b/Documentation/feature-removal-schedule.txt @@ -201,13 +201,13 @@ Who: Tejun Heo [EMAIL PROTECTED] --- What: The arch/ppc and include/asm-ppc directories -When: Jun 2008 +When: end of July 2008 Why: The arch/powerpc tree is the merged architecture for ppc32 and ppc64 platforms. Currently there are efforts underway to port the remaining arch/ppc platforms to the merged tree. New submissions to the arch/ppc tree have been frozen with the 2.6.22 kernel release and that tree will remain in bug-fix only mode until its scheduled removal. Platforms - that are not ported by June 2008 will be removed due to the lack of an + that are not ported by July 2008 will be removed due to the lack of an interested maintainer. Who: linuxppc-dev@ozlabs.org -- 1.5.3.4.208.g805a ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
dtc: Make some functions local to parser
* 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, so make it static.
Signed-off-by: David Gibson [EMAIL PROTECTED]
---
dtc-parser.y | 14 +-
srcpos.h |3 ---
2 files changed, 5 insertions(+), 12 deletions(-)
Index: dtc/dtc-parser.y
===
--- dtc.orig/dtc-parser.y 2008-03-04 15:29:09.0 +1100
+++ dtc/dtc-parser.y2008-03-04 15:31:32.0 +1100
@@ -24,12 +24,13 @@
#include dtc.h
#include srcpos.h
-int yylex(void);
-unsigned long long eval_literal(const char *s, int base, int bits);
+extern int yylex(void);
extern struct boot_info *the_boot_info;
extern int treesource_error;
+static void yyerror(char const *, ...) __attribute__((format(printf, 1, 2)));
+static unsigned long long eval_literal(const char *s, int base, int bits);
%}
%union {
@@ -308,7 +309,7 @@ label:
%%
-void yyerrorf(char const *s, ...)
+static void yyerror(char const *s, ...)
{
const char *fname = srcpos_file ? srcpos_file-name : no-file;
va_list va;
@@ -325,12 +326,7 @@ void yyerrorf(char const *s, ...)
va_end(va);
}
-void yyerror (char const *s)
-{
- yyerrorf(%s, s);
-}
-
-unsigned long long eval_literal(const char *s, int base, int bits)
+static unsigned long long eval_literal(const char *s, int base, int bits)
{
unsigned long long val;
char *e;
Index: dtc/srcpos.h
===
--- dtc.orig/srcpos.h 2008-03-04 15:30:06.0 +1100
+++ dtc/srcpos.h2008-03-04 15:30:09.0 +1100
@@ -70,9 +70,6 @@ typedef struct YYLTYPE {
-extern void yyerror(char const *);
-extern void yyerrorf(char const *, ...) __attribute__((format(printf, 1, 2)));
-
extern struct dtc_file *srcpos_file;
extern void push_input_file(const char *filename);
--
David Gibson| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Bamboo PCI interrupt issues
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 as you suggested, and my card hung hard on the first ethernet traffic. I've no idea if we're dealing with a crappy card or a crappy driver but the device tree seems to be working ok. If I can find a different card to test with I will. Ben, do you have any input here? Other than bamboo has the weirdest combination of FPGA/CPLD/DIP switches that I could never figure out if PCI was clocked properly ? That might just be the problem :-) I do remember having issues now that we talk about it. Though not specifically what they were. Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: dtc: Make dt_from_blob() open its own file
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_blob() take a filename and open its own files, removing the inconsistency. In addition, dt_from_blob() now correctly uses dtc_close_file() to close the file opened with dtc_open_file(), rather than directly calling fclose() on the contained FILE *. Signed-off-by: David Gibson [EMAIL PROTECTED] Sorry, ignore. There's a bug in this one, revised version coming. -- David Gibson| I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Bamboo PCI interrupt issues
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 ethernet traffic failed. Then I changed the sense level to 4 as you suggested, and my card hung hard on the first ethernet traffic. Using '8' is correct. PCI interrupts are *always* level sensitive and active low. I've no idea if we're dealing with a crappy card or a crappy driver but the device tree seems to be working ok. If I can find a different card to test with I will. One thing always worth to check on 4xx IRQ problems is, if the external IRQ pins are configured correctly for IRQ usage. Most of the times, the external IRQ's are shared with other peripheral pins and/or GPIO pins. This configuration is done in the GPIO core (and sometimes SDR PFCx registers). This should be done correctly by the bootloader but sometimes the configuration is wrong. I have to admit that I probably never tested PCI on Bamboo. Just a thought. Best regards, Stefan ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
dtc: Make dt_from_blob() open its own file
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. In addition, dt_from_blob() now
correctly uses dtc_close_file() to close the file opened with
dtc_open_file(), rather than directly calling fclose() on the
contained FILE *.
Signed-off-by: David Gibson [EMAIL PROTECTED]
---
dtc.c | 11 +--
dtc.h |4 ++--
flattree.c | 10 +-
3 files changed, 12 insertions(+), 13 deletions(-)
Index: dtc/dtc.c
===
--- dtc.orig/dtc.c 2008-03-04 15:58:49.0 +1100
+++ dtc/dtc.c 2008-03-04 16:02:12.0 +1100
@@ -118,7 +118,6 @@ int main(int argc, char *argv[])
int force = 0, check = 0;
const char *arg;
int opt;
- struct dtc_file *inf = NULL;
FILE *outf = NULL;
int outversion = DEFAULT_FDT_VERSION;
int boot_cpuid_phys = 0xfeedbeef;
@@ -192,19 +191,11 @@ int main(int argc, char *argv[])
} else if (streq(inform, fs)) {
bi = dt_from_fs(arg);
} else if(streq(inform, dtb)) {
- inf = dtc_open_file(arg, NULL);
- if (!inf)
- die(Couldn't open \%s\: %s\n, arg,
- strerror(errno));
-
- bi = dt_from_blob(inf-file);
+ bi = dt_from_blob(arg);
} else {
die(Unknown input format \%s\\n, inform);
}
- if (inf inf-file != stdin)
- fclose(inf-file);
-
if (! bi || ! bi-dt || bi-error)
die(Couldn't read input tree\n);
Index: dtc/flattree.c
===
--- dtc.orig/flattree.c 2008-03-04 15:59:53.0 +1100
+++ dtc/flattree.c 2008-03-04 16:06:55.0 +1100
@@ -19,6 +19,7 @@
*/
#include dtc.h
+#include srcpos.h
#define FTF_FULLPATH 0x1
#define FTF_VARALIGN 0x2
@@ -780,8 +781,10 @@ static struct node *unflatten_tree(struc
}
-struct boot_info *dt_from_blob(FILE *f)
+struct boot_info *dt_from_blob(const char *fname)
{
+ struct dtc_file *dtcf;
+ FILE *f;
u32 magic, totalsize, version, size_dt;
u32 off_dt, off_str, off_mem_rsvmap;
int rc;
@@ -796,6 +799,9 @@ struct boot_info *dt_from_blob(FILE *f)
u32 val;
int flags = 0;
+ dtcf = dtc_open_file(fname, NULL);
+ f = dtcf-file;
+
rc = fread(magic, sizeof(magic), 1, f);
if (ferror(f))
die(Error reading DT blob magic number: %s\n,
@@ -902,5 +908,7 @@ struct boot_info *dt_from_blob(FILE *f)
free(blob);
+ dtc_close_file(dtcf);
+
return build_boot_info(reservelist, tree);
}
Index: dtc/dtc.h
===
--- dtc.orig/dtc.h 2008-03-04 16:01:22.0 +1100
+++ dtc/dtc.h 2008-03-04 16:01:43.0 +1100
@@ -250,12 +250,12 @@ void dt_to_blob(FILE *f, struct boot_inf
void dt_to_asm(FILE *f, struct boot_info *bi, int version,
int boot_cpuid_phys);
-struct boot_info *dt_from_blob(FILE *f);
+struct boot_info *dt_from_blob(const char *fname);
/* Tree source */
void dt_to_source(FILE *f, struct boot_info *bi);
-struct boot_info *dt_from_source(const char *f);
+struct boot_info *dt_from_source(const char *fname);
/* FS trees */
--
David Gibson| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Bamboo PCI interrupt issues
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. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
