* MPC5200b external interrupt registration problem
From: Nick @ 2008-05-09 18:49 UTC (permalink / raw)
To: linuxppc-dev
Hi,
I am writing a driver to service an interrupt from our fpga. I am calling request_irq in the open
function of my driver. The fpga is connected to external interrupt 1. I am using interrupt
number 65 in the request_irq but the function is failing. I traced to a function called setup_irq
in file /kernel/irq/manage.c. It fails because at this line: if (desc->chip == &no_irq_chip) .
Is 65 the wrong interrupt number? What do I need to do to properly setup for external interrupts?
Thanks for any help,
Nick
^ permalink raw reply
* Re: [PATCH 3/3] [POWERPC] 86xx: mpc8610_hpcd: use ULI526X driver for on-board ethernet
From: Timur Tabi @ 2008-05-09 18:50 UTC (permalink / raw)
To: Anton Vorontsov; +Cc: netdev, Jeff Garzik, linuxppc-dev
In-Reply-To: <20080429155333.GC28166@polina.dev.rtsoft.ru>
Anton Vorontsov wrote:
> As of current mainline tree, TULIP driver is unusable on MPC8610HPCD
> boards. There is a patch[1] floating around (and also included in the
> BSP), which tries to heal the situation, though the ethernet is still
> unusable. Practically it takes ages to mount NFS filesystem:
Acked-By: Timur Tabi <timur@freescale.com>
After applying this patch and Anton's two ULI driver patches, the ULI drivers
works great on an 8610HPCD.
--
Timur Tabi
Linux kernel developer at Freescale
^ permalink raw reply
* patch to install unstripped vDSO on disk breaks powerpc kernel build
From: Chris Friesen @ 2008-05-09 17:16 UTC (permalink / raw)
To: linuxppc-dev, roland, paulus, benh
I'm using gcc 3.4.3 and binutils 2.15.92.0.2. I originally saw the
following problem in 2.6.25 but it's present in git head as well:
CALL /home/cfriesen/kernels/2.6.25/linux-2.6.25/scripts/checksyscalls.sh
CHK include/linux/compile.h
CALL
/home/cfriesen/kernels/2.6.25/linux-2.6.25/arch/powerpc/kernel/systbl_chk.sh
AS arch/powerpc/kernel/systbl.o
OBJCOPY arch/powerpc/kernel/vdso64/vdso64.so
BFD: arch/powerpc/kernel/vdso64/vdso64.so: The first section in the
PT_DYNAMIC segment is not the .dynamic section
/home/cfriesen/bin/ppc64-R9a/bin/ppc64-R9a-objcopy:
arch/powerpc/kernel/vdso64/vdso64.so: Bad value
BFD: arch/powerpc/kernel/vdso64/vdso64.so: The first section in the
PT_DYNAMIC segment is not the .dynamic section
/home/cfriesen/bin/ppc64-R9a/bin/ppc64-R9a-objcopy:
arch/powerpc/kernel/vdso64/vdso64.so: Bad value
make[3]: *** [arch/powerpc/kernel/vdso64/vdso64.so] Error 1
make[2]: *** [arch/powerpc/kernel/vdso64] Error 2
make[1]: *** [arch/powerpc/kernel] Error 2
make: *** [sub-make] Error 2
I installed git and bisected the problem. It turns out that it's due to
the following commit:
commit 8150caad02266623b5b9f58088d589f130fccd97
Author: Roland McGrath <roland@redhat.com>
Date: Tue Oct 2 13:30:04 2007 -0700
[POWERPC] powerpc vDSO: install unstripped copies on disk
This keeps an unstripped copy of the vDSO images built before they are
stripped and embedded in the kernel. The unstripped copies get
installed in $(MODLIB)/vdso/ by "make install". These files can be
useful when they contain source-level debugging information.
Signed-off-by: Roland McGrath <roland@redhat.com>
Cc: Sam Ravnborg <sam@ravnborg.org>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Paul Mackerras <paulus@samba.org>
Anyone have any idea what's going on?
Thanks,
Chris
^ permalink raw reply
* Re: [PATCH 1/4 V2] booting-without-of for Freescale MSI
From: Grant Likely @ 2008-05-09 16:24 UTC (permalink / raw)
To: Timur Tabi; +Cc: linuxppc-dev, Jason Jin
In-Reply-To: <4824795D.30004@freescale.com>
On Fri, May 9, 2008 at 10:18 AM, Timur Tabi <timur@freescale.com> wrote:
> Grant Likely wrote:
>
>> But here, you are only adding section t)
>
> That's because r) and s) already exist. The person who added those sections
> didn't update the TOC.
heh. I'm obviously being far too lazy in my patch review.
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: [PATCH 1/4 V2] booting-without-of for Freescale MSI
From: Timur Tabi @ 2008-05-09 16:18 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev, Jason Jin
In-Reply-To: <fa686aa40805090634r66fbffd7i886ade757145e24f@mail.gmail.com>
Grant Likely wrote:
> But here, you are only adding section t)
That's because r) and s) already exist. The person who added those sections
didn't update the TOC.
--
Timur Tabi
Linux kernel developer at Freescale
^ permalink raw reply
* Re: [PATCH] Sam440ep support
From: Giuseppe Coviello @ 2008-05-09 15:53 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <a265241c0805060937m25921c56o6fb2b132a3f821d6@mail.gmail.com>
2008/5/6 Giuseppe Coviello <cjg@cruxppc.org>:
> I've prepared another path to add the support for the sam440ep;
> shortly I've merged arch/powerpc/boot/sam440ep.c in
> arch/powerpc/boot/cuboot-sam440ep.c; I've inserted the code to make
> the rtc works directly in arch/powerpc/platforms/44x/sam440ep.c (so
> there isn't any arch/powerpc/sysdev/sam440ep.c anymore), and I've
> cutted away the nasty hack (dma-mapping.h and memmalloc.c) to make the
> sound works.
[cut]
Sorry for our impatience, but we'll happy to know if this (second)
version of the patch
is acceptable, and, of course, what could be the future of this same patch.
Thank you, Giuseppe
^ permalink raw reply
* Re: MPC5200b MMC over SPI into PSC6
From: Grant Likely @ 2008-05-09 15:20 UTC (permalink / raw)
To: Fabri; +Cc: linuxppc-dev, Fabio Tosetto
In-Reply-To: <ed84ed090805090802s177f9d47r4be59b5a47138d2a@mail.gmail.com>
On Fri, May 9, 2008 at 9:02 AM, Fabri <rider4ever@gmail.com> wrote:
> Thanks for the patches, now some more rows are printed after RamDisk loading:
>
> Verifying Checksum ... OK
> Loading Ramdisk to 0fe68000, end 0ff49bf2 ... OK
> Memory <- <0x0 0x10000000> (256MB)
> CPU clock-frequency <- 0xbcd3d80 (198MHz)
> CPU timebase-frequency <- 0x1f78a40 (33MHz)
> CPU bus-frequency <- 0x7de2900 (132MHz)
>
> zImage starting: loaded at 0x00400000 (sp: 0x0ff4a958)
> Allocating 0x32d410 bytes for kernel ...
> gunzipping (0x00000000 <- 0x0040d000:0x00730fd4)...done 0x30d150 bytes
> Using loader supplied ramdisk at 0xfe68000-0xff49bf2
> initrd head: 0x1f8b0808
>
> Linux/PowerPC load:
^^^^^^^^^^^^^^^^^^
Doesn't look like you are passing a kernel parameters line. The
kernel probably is booting, but doesn't know where to output the
console. Try adding "console=ttyPSC0,115200".
Cheers,
g.
>
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: [Cbe-oss-dev] [PATCH] Updated: Reworked Cell OProfile: SPU mutex lock fix
From: Robert Richter @ 2008-05-09 15:07 UTC (permalink / raw)
To: Carl Love
Cc: linuxppc-dev, oprofile-list, cbe-oss-dev, Arnd Bergmann,
linux-kernel
In-Reply-To: <1209587712.7531.42.camel@carll-linux-desktop>
Please see my comments below.
-Roberta
On 30.04.08 13:35:12, Carl Love wrote:
[...]
> -int spu_sync_stop(void)
> +void spu_sync_stop(void)
> {
> unsigned long flags = 0;
> - int ret = spu_switch_event_unregister(&spu_active);
> - if (ret) {
> - printk(KERN_ERR "SPU_PROF: "
> - "%s, line %d: spu_switch_event_unregister returned %d\n",
> - __FUNCTION__, __LINE__, ret);
> - goto out;
> - }
> +
> + /* Ignoring the return value from the unregister
> + * call. A failed return value simply says there
> + * was no registered event. Hence there will not
> + * be any calls to process a switch event that
> + * could cause a problem.
> + */
> + spu_switch_event_unregister(&spu_active);
Better to use this here, to show the return value is ignored:
(void)spu_switch_event_unregister(...)
>
> spin_lock_irqsave(&cache_lock, flags);
> - ret = release_cached_info(RELEASE_ALL);
> + release_cached_info(RELEASE_ALL);
Dito.
> spin_unlock_irqrestore(&cache_lock, flags);
> -out:
> pr_debug("spu_sync_stop -- done.\n");
> - return ret;
> + return;
> }
>
>
> Index: Cell_kernel_4_15_2008/arch/powerpc/oprofile/op_model_cell.c
> ===================================================================
> --- Cell_kernel_4_15_2008.orig/arch/powerpc/oprofile/op_model_cell.c
> +++ Cell_kernel_4_15_2008/arch/powerpc/oprofile/op_model_cell.c
> @@ -1191,15 +1191,15 @@ static int cell_sync_start(void)
> if (spu_cycle_reset)
> return spu_sync_start();
> else
> - return DO_GENERIC_SYNC;
> + return 0;
> }
>
> -static int cell_sync_stop(void)
> +static void cell_sync_stop(void)
> {
> if (spu_cycle_reset)
> - return spu_sync_stop();
> - else
> - return 1;
> + spu_sync_stop();
Same here.
> +
> + return;
> }
>
> struct op_powerpc_model op_model_cell = {
[...]
--
Advanced Micro Devices, Inc.
Operating System Research Center
email: robert.richter@amd.com
^ permalink raw reply
* Re: MPC5200b MMC over SPI into PSC6
From: Fabri @ 2008-05-09 15:02 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev, Fabio Tosetto
In-Reply-To: <fa686aa40805090706q572b44e9n2b39a6808562b2ad@mail.gmail.com>
Thanks for the patches, now some more rows are printed after RamDisk loading:
Verifying Checksum ... OK
Loading Ramdisk to 0fe68000, end 0ff49bf2 ... OK
Memory <- <0x0 0x10000000> (256MB)
CPU clock-frequency <- 0xbcd3d80 (198MHz)
CPU timebase-frequency <- 0x1f78a40 (33MHz)
CPU bus-frequency <- 0x7de2900 (132MHz)
zImage starting: loaded at 0x00400000 (sp: 0x0ff4a958)
Allocating 0x32d410 bytes for kernel ...
gunzipping (0x00000000 <- 0x0040d000:0x00730fd4)...done 0x30d150 bytes
Using loader supplied ramdisk at 0xfe68000-0xff49bf2
initrd head: 0x1f8b0808
Linux/PowerPC load:
Finalizing device tree... flat tree at 0x73d300
-----------------------------------------------------------------------------------------------------
and then it stops. Maybe are there some problems related to my rootfs.uimage?
On Fri, May 9, 2008 at 4:06 PM, Grant Likely <grant.likely@secretlab.ca> wrote:
> See if this patch makes any difference for you:
>
> diff --git a/arch/powerpc/boot/dts/lite5200b.dts b/arch/powerpc/boot/dts/lite520
> index 8505e97..70d9a8e 100644
> --- a/arch/powerpc/boot/dts/lite5200b.dts
> +++ b/arch/powerpc/boot/dts/lite5200b.dts
> @@ -342,4 +342,8 @@
> 0x02000000 0 0xa0000000 0xa0000000 0 0x10000000
> 0x01000000 0 0x00000000 0xb0000000 0 0x01000000>;
> };
> +
> + chosen {
> + linux,stdout-path = "/soc5200@f0000000/serial@2000";
> + };
> };
>
>
> Oh, and the fix I told you about (fixing the unterminated list) didn't
> make it into 2.6.25.2. You still need to manually apply it. It
> should be in 2.6.25.3.
>
> Cheers,
> g.
>
> On Fri, May 9, 2008 at 7:51 AM, Fabri <rider4ever@gmail.com> wrote:
>> Errage corrige: Excuse me, bad cut and paste :)
>> This is the right output of the first try
>>
>> ## Booting image at 03000000 ...
>> Image Name: Linux-2.6.25.2
>> Created: 2008-05-09 12:46:22 UTC
>> Image Type: PowerPC Linux Kernel Image (gzip compressed)
>> Data Size: 1518744 Bytes = 1.4 MB
>> Load Address: 00400000
>> Entry Point: 00400550
>> Verifying Checksum ... OK
>> Uncompressing Kernel Image ... OK
>> ## Loading RAMDisk Image at 04000000 ...
>> Image Name: RamDisk Image Lite5200b
>> Created: 2008-03-04 11:28:40 UTC
>> Image Type: PowerPC Linux RAMDisk Image (gzip compressed)
>> Data Size: 1135278 Bytes = 1109 kB
>> Load Address: 00000000
>> Entry Point: 00000000
>> Verifying Checksum ... OK
>> Loading Ramdisk to 0fe68000, end 0ff7d2ae ... OK
>>
>> By the way, Grant, you seem to be very expert in making a kernel with
>> ARCH=powerpc. Can you tell me how to find some docs to improve my
>> knowledge in this field? I've found something interesting in
>> Documentation/powerpc, but they are not too explicative about the
>> differences between PPC/Powerpc building, and about how to make the
>> last one.
>>
>
>
>
> --
> Grant Likely, B.Sc., P.Eng.
> Secret Lab Technologies Ltd.
>
^ permalink raw reply
* Re: MPC5200b MMC over SPI into PSC6
From: Grant Likely @ 2008-05-09 14:06 UTC (permalink / raw)
To: Fabri; +Cc: linuxppc-dev, Fabio Tosetto
In-Reply-To: <ed84ed090805090651g65ab474fk13d549e7166c3f1c@mail.gmail.com>
See if this patch makes any difference for you:
diff --git a/arch/powerpc/boot/dts/lite5200b.dts b/arch/powerpc/boot/dts/lite520
index 8505e97..70d9a8e 100644
--- a/arch/powerpc/boot/dts/lite5200b.dts
+++ b/arch/powerpc/boot/dts/lite5200b.dts
@@ -342,4 +342,8 @@
0x02000000 0 0xa0000000 0xa0000000 0 0x10000000
0x01000000 0 0x00000000 0xb0000000 0 0x01000000>;
};
+
+ chosen {
+ linux,stdout-path = "/soc5200@f0000000/serial@2000";
+ };
};
Oh, and the fix I told you about (fixing the unterminated list) didn't
make it into 2.6.25.2. You still need to manually apply it. It
should be in 2.6.25.3.
Cheers,
g.
On Fri, May 9, 2008 at 7:51 AM, Fabri <rider4ever@gmail.com> wrote:
> Errage corrige: Excuse me, bad cut and paste :)
> This is the right output of the first try
>
> ## Booting image at 03000000 ...
> Image Name: Linux-2.6.25.2
> Created: 2008-05-09 12:46:22 UTC
> Image Type: PowerPC Linux Kernel Image (gzip compressed)
> Data Size: 1518744 Bytes = 1.4 MB
> Load Address: 00400000
> Entry Point: 00400550
> Verifying Checksum ... OK
> Uncompressing Kernel Image ... OK
> ## Loading RAMDisk Image at 04000000 ...
> Image Name: RamDisk Image Lite5200b
> Created: 2008-03-04 11:28:40 UTC
> Image Type: PowerPC Linux RAMDisk Image (gzip compressed)
> Data Size: 1135278 Bytes = 1109 kB
> Load Address: 00000000
> Entry Point: 00000000
> Verifying Checksum ... OK
> Loading Ramdisk to 0fe68000, end 0ff7d2ae ... OK
>
> By the way, Grant, you seem to be very expert in making a kernel with
> ARCH=powerpc. Can you tell me how to find some docs to improve my
> knowledge in this field? I've found something interesting in
> Documentation/powerpc, but they are not too explicative about the
> differences between PPC/Powerpc building, and about how to make the
> last one.
>
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply related
* Re: How to link a .o with all modules
From: Kumar Gala @ 2008-05-09 13:52 UTC (permalink / raw)
To: Sam Ravnborg; +Cc: linuxppc-dev@ozlabs.org list, lkml List
In-Reply-To: <20080508202200.GA12578@uranus.ravnborg.org>
[-- Attachment #1: Type: text/plain, Size: 1638 bytes --]
On May 8, 2008, at 3:22 PM, Sam Ravnborg wrote:
> On Thu, May 08, 2008 at 09:16:10AM -0500, Kumar Gala wrote:
>>
>> On May 5, 2008, at 3:44 PM, Sam Ravnborg wrote:
>>
>>>>>
>>>>>
>>>>> Let me know if this does address your question.
>>>>
>>>> The problem is MODPOST complains about undefined symbols:
>>>>
>>>> MODPOST 24 modules
>>>> ERROR: "_restgpr_20_x" [net/key/af_key.ko] undefined!
>>>> ERROR: "_restgpr_25_x" [net/key/af_key.ko] undefined!
>>>> ERROR: "_restgpr_30_x" [net/key/af_key.ko] undefined!
>>>
>>> I need a bit more context to try to analyse this.
>>> Where did you expect _restgpr_20_x to be defined.
>>> If in vmlinux then were they present in the
>>> Module.symvers file?
>>
>> No they aren't there since we I'm not EXPORT_SYMBOL() them. Should I
>> also be doing EXPORT_SYMBOL?
>
> So modpost claim it cannot find the symbols.
>
>>
>>> If in the linked in .o file - could you
>>> see the symbols using objdump.
>>
>> Yes.
>>
>> readelf -a:
>>
>> ...
>> Symbol table '.symtab' contains 113 entries:
>> Num: Value Size Type Bind Vis Ndx Name
>> ...
>> 5: 00000000 0 FUNC GLOBAL DEFAULT 1 _savegpr_14
>> 6: 00000000 0 FUNC GLOBAL DEFAULT 1 _save32gpr_14
>> ...
>
> Strange.
>
> I did not look closer.
> But it looks like the linker failed to resolve these symbols
> in the final link somehow - despite the symbols are present in
> the linked in .o file.
>
> Can you try to drop me the output of the relocation records for the
> finally linked .o file (the one with your .o file linked in).
>
> objdump -r IIRC
I'm assuming you mean objdump -r arch/powerpc/lib/built-in.o
[-- Attachment #2: reloc.dump.gz --]
[-- Type: application/x-gzip, Size: 14925 bytes --]
[-- Attachment #3: Type: text/plain, Size: 1 bytes --]
^ permalink raw reply
* Re: MPC5200b MMC over SPI into PSC6
From: Fabri @ 2008-05-09 13:51 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev, Fabio Tosetto
In-Reply-To: <ed84ed090805090640w11dcfc57r1303ac4fceb482cb@mail.gmail.com>
Errage corrige: Excuse me, bad cut and paste :)
This is the right output of the first try
## Booting image at 03000000 ...
Image Name: Linux-2.6.25.2
Created: 2008-05-09 12:46:22 UTC
Image Type: PowerPC Linux Kernel Image (gzip compressed)
Data Size: 1518744 Bytes = 1.4 MB
Load Address: 00400000
Entry Point: 00400550
Verifying Checksum ... OK
Uncompressing Kernel Image ... OK
## Loading RAMDisk Image at 04000000 ...
Image Name: RamDisk Image Lite5200b
Created: 2008-03-04 11:28:40 UTC
Image Type: PowerPC Linux RAMDisk Image (gzip compressed)
Data Size: 1135278 Bytes = 1109 kB
Load Address: 00000000
Entry Point: 00000000
Verifying Checksum ... OK
Loading Ramdisk to 0fe68000, end 0ff7d2ae ... OK
By the way, Grant, you seem to be very expert in making a kernel with
ARCH=powerpc. Can you tell me how to find some docs to improve my
knowledge in this field? I've found something interesting in
Documentation/powerpc, but they are not too explicative about the
differences between PPC/Powerpc building, and about how to make the
last one.
^ permalink raw reply
* Re: MPC5200b MMC over SPI into PSC6
From: Fabri @ 2008-05-09 13:40 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev, Fabio Tosetto
In-Reply-To: <fa686aa40805080832l2492c46l400986472e985d9a@mail.gmail.com>
Hello!
I've seen you guys are playing with a Lite5200b board, so I've decided
to do another attempt with mine.
On Thu, May 8, 2008 at 5:32 PM, Grant Likely <grant.likely@secretlab.ca> wrote:
> For example, use "make ARCH=powerpc cuImage.lite5200b" to build an
> image for the lite5200b board. The build scripts will use the
> lite5200b.dts file in the dts directory for building the image.
If I'm not wrong, the right sequence of commands should be the following:
$ make ARCH=powerpc mpc5200_defconfig
$ make ARCH=powerpc menuconfig
... [customizations]...
$ make ARCH=powerpc CROSS_COMPILE=powerpc-linux-gnu- cuImage.lite5200b
and this is the output:
...
CHK include/linux/version.h
CHK include/linux/utsrelease.h
CALL scripts/checksyscalls.sh
CHK include/linux/compile.h
CALL arch/powerpc/kernel/systbl_chk.sh
WRAP arch/powerpc/boot/cuImage.lite5200b
DTC: dts->dtb on file
"/home/fgaretto/linux-2.6.25.2-lite5200/arch/powerpc/boot/dts/lite5200b.dts"
Image Name: Linux-2.6.25.2
Created: Fri May 9 14:46:22 2008
Image Type: PowerPC Linux Kernel Image (gzip compressed)
Data Size: 1518744 Bytes = 1483.15 kB = 1.45 MB
Load Address: 0x00400000
Entry Point: 0x00400550
At this point I've loaded the cuImage and rootfs.uimage on the board:
=> usb start
=> usb scan
=> fatload usb 0 0x03000000 cuImage.lite5200b
=> fatload usb 0 0x04000000 rootfs.uimage
=> bootm 0x03000000 0x04000000
but it still hangs after this:
## Booting image at 03000000 ...
Image Name: RadioNav-Linux 2.6.22.1
Created: 2008-05-09 13:11:43 UTC
Image Type: PowerPC Linux Kernel Image (uncompressed)
Data Size: 1518808 Bytes = 1.4 MB
Load Address: 00000000
Entry Point: 00000000
Verifying Checksum ... OK
OK
## Loading RAMDisk Image at 04000000 ...
Image Name: RamDisk Image Lite5200b
Created: 2008-03-04 11:28:40 UTC
Image Type: PowerPC Linux RAMDisk Image (gzip compressed)
Data Size: 1135278 Bytes = 1109 kB
Load Address: 00000000
Entry Point: 00000000
Verifying Checksum ... OK
Loading Ramdisk to 0fe68000, end 0ff7d2ae ... OK
I've looked at Load Address and Entry Point of the cuImage and it
sounds a little strange to me that these values are not zero, so I've
manually changed them both to 0x00000000 using mkimage, but the
result is always the same: no boot at all.
^ permalink raw reply
* Re: [PATCH 1/4 V2] booting-without-of for Freescale MSI
From: Grant Likely @ 2008-05-09 13:34 UTC (permalink / raw)
To: Jason Jin; +Cc: linuxppc-dev
In-Reply-To: <1210323810-24833-1-git-send-email-Jason.jin@freescale.com>
On Fri, May 9, 2008 at 3:03 AM, Jason Jin <Jason.jin@freescale.com> wrote:
> Binding document adding for Freescale MSI support.
>
> Signed-off-by: Jason Jin <Jason.jin@freescale.com>
> ---
> Updated to V2 version per Segher's suggestion.
>
> Documentation/powerpc/booting-without-of.txt | 40 +++++++++++++++++++++++++-
> 1 files changed, 39 insertions(+), 1 deletions(-)
>
> diff --git a/Documentation/powerpc/booting-without-of.txt b/Documentation/powerpc/booting-without-of.txt
> index 1d2a772..887783c 100644
> --- a/Documentation/powerpc/booting-without-of.txt
> +++ b/Documentation/powerpc/booting-without-of.txt
> @@ -57,7 +57,10 @@ Table of Contents
> n) 4xx/Axon EMAC ethernet nodes
> o) Xilinx IP cores
> p) Freescale Synchronous Serial Interface
> - q) USB EHCI controllers
> + q) USB EHCI controllers
> + r) Freescale Display Interface Unit
> + s) Freescale on board FPGA
> + t) Freescael MSI interrupt controller
One more comment: Here we see sections r), s) & t) added.
>
> VII - Marvell Discovery mv64[345]6x System Controller chips
> 1) The /system-controller node
> @@ -2870,6 +2873,41 @@ platforms are moved over to use the flattened-device-tree model.
> reg = <0xe8000000 32>;
> };
>
> + t) Freescale MSI interrupt controller
> +
But here, you are only adding section t)
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: [PATCH 2/4 V4] MSI support on 83xx/85xx/86xx board
From: Grant Likely @ 2008-05-09 13:31 UTC (permalink / raw)
To: Jason Jin; +Cc: linuxppc-dev
In-Reply-To: <1210323810-24833-2-git-send-email-Jason.jin@freescale.com>
On Fri, May 9, 2008 at 3:03 AM, Jason Jin <Jason.jin@freescale.com> wrote:
> This MSI driver can be used on 83xx/85xx/86xx board.
> In this driver, virtual interrupt host and chip were
> setup. There are 256 MSI interrupts in this host, Every 32
> MSI interrupts cascaded to one IPIC/MPIC interrupt.
> The chip was treated as edge sensitive and some necessary
> functions were setup for this chip.
>
> Before using the MSI interrupt, PCI/PCIE device need to
> ask for a MSI interrupt in the 256 MSI interrupts. A 256bit
> bitmap show which MSI interrupt was used, reserve bit in
> the bitmap can be used to force the device use some designate
> MSI interrupt in the 256 MSI interrupts. Sometimes this is useful
> for testing the all the MSI interrupts. The msi-available-ranges
> property in the dts file was used for this purpose.
>
> Signed-off-by: Jason Jin <Jason.jin@freescale.com>
> ---
> Update to V4 version per the suggestion's from Michael Ellerman
> +static struct of_platform_driver fsl_of_msi_driver = {
> + .name = "fsl-of-msi",
> + .match_table = fsl_of_msi_ids,
> + .probe = fsl_of_msi_probe,
> +};
nitpick: 'of' in 'fsl-of-msi' is redundant. We *already* know that
this is an of_platform driver. :-)
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: [PATCH 1/4 V2] booting-without-of for Freescale MSI
From: Grant Likely @ 2008-05-09 13:25 UTC (permalink / raw)
To: Jason Jin; +Cc: linuxppc-dev
In-Reply-To: <1210323810-24833-1-git-send-email-Jason.jin@freescale.com>
On Fri, May 9, 2008 at 3:03 AM, Jason Jin <Jason.jin@freescale.com> wrote:
> Binding document adding for Freescale MSI support.
>
> Signed-off-by: Jason Jin <Jason.jin@freescale.com>
> ---
> Updated to V2 version per Segher's suggestion.
>
> Documentation/powerpc/booting-without-of.txt | 40 +++++++++++++++++++++++++-
> 1 files changed, 39 insertions(+), 1 deletions(-)
>
> diff --git a/Documentation/powerpc/booting-without-of.txt b/Documentation/powerpc/booting-without-of.txt
> index 1d2a772..887783c 100644
> --- a/Documentation/powerpc/booting-without-of.txt
> +++ b/Documentation/powerpc/booting-without-of.txt
> @@ -57,7 +57,10 @@ Table of Contents
> n) 4xx/Axon EMAC ethernet nodes
> o) Xilinx IP cores
> p) Freescale Synchronous Serial Interface
> - q) USB EHCI controllers
> + q) USB EHCI controllers
> + r) Freescale Display Interface Unit
> + s) Freescale on board FPGA
> + t) Freescael MSI interrupt controller
>
> VII - Marvell Discovery mv64[345]6x System Controller chips
> 1) The /system-controller node
> @@ -2870,6 +2873,41 @@ platforms are moved over to use the flattened-device-tree model.
> reg = <0xe8000000 32>;
> };
>
> + t) Freescale MSI interrupt controller
> +
> + Reguired properities:
> + - compatible : set as "fsl,86xx-MSI" for 86xx cpu, "fsl,85xx-MSI" for 85xx
> + cpu and "fsl,83xx-MSI" for 83xx cpu.
As Segher mentioned; don't use 'generic' compatible values. Use names
of *actual* devices and have newer parts claim compatibility with
older ones.
Otherwise looks good to me.
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* [git pull] Please pull powerpc.git merge branch
From: Paul Mackerras @ 2008-05-09 13:19 UTC (permalink / raw)
To: Linus Torvalds; +Cc: linuxppc-dev, akpm, linux-kernel
Linus,
Please pull from 'merge' branch of
git://git.kernel.org/pub/scm/linux/kernel/git/paulus/powerpc.git merge
to get some bug fixes and documentation/comment updates for powerpc,
as listed below.
There is one commit there that isn't just a fix, the "Add endpoint
support to 4xx PCIe driver" one. I think it's OK to go in because (a)
it's only adding functionality, (b) it only affects ppc4xx processors,
and (c) the 4xx maintainer (Josh Boyer) said about it: "Stefan's pci-e
endpoint driver is also included here as it is a fairly contained
change with Ben's Ack. It should have been included in my last pull
request, but I missed it and have been out."
Thanks,
Paul.
arch/powerpc/boot/dts/sequoia.dts | 9 +
arch/powerpc/kernel/btext.c | 1
arch/powerpc/kernel/cputable.c | 53 ++++++--
arch/powerpc/kernel/head_44x.S | 9 +
arch/powerpc/kernel/head_64.S | 4 -
arch/powerpc/kernel/isa-bridge.c | 3
arch/powerpc/kernel/setup_64.c | 10 +
arch/powerpc/platforms/cell/interrupt.c | 53 +++++++-
arch/powerpc/platforms/cell/spu_base.c | 31 +++-
arch/powerpc/platforms/cell/spu_priv1_mmio.c | 16 ++
arch/powerpc/platforms/cell/spufs/fault.c | 17 ++
arch/powerpc/platforms/cell/spufs/inode.c | 10 +
arch/powerpc/platforms/cell/spufs/run.c | 38 +++--
arch/powerpc/platforms/cell/spufs/sched.c | 7 +
arch/powerpc/platforms/cell/spufs/spufs.h | 3
arch/powerpc/platforms/cell/spufs/switch.c | 71 +++++++---
arch/powerpc/sysdev/ppc4xx_pci.c | 180 +++++++++++++++++++-------
arch/powerpc/xmon/xmon.c | 6 +
include/asm-powerpc/pgtable-ppc32.h | 7 +
include/asm-powerpc/spu.h | 9 +
include/asm-powerpc/spu_csa.h | 3
include/linux/of_i2c.h | 4 -
22 files changed, 399 insertions(+), 145 deletions(-)
Benjamin Herrenschmidt (4):
[POWERPC] Make default cputable entries reflect selected CPU family
[POWERPC] Fix bogus paca->_current initialization
[POWERPC] Document when printk is useable
[POWERPC] Initialize lockdep earlier
Christian Ehrhardt (1):
[POWERPC] 4xx: Fix PCI mem in sequoia DTS
Christoph Hellwig (3):
[POWERPC] spufs: spu_create should send inotify IM_CREATE event
[POWERPC] spufs: don't requeue victim contex in find_victim if it's not in spu_run
[POWERPC] spufs: lockdep annotations for spufs_dir_close
Huang Weiyi (1):
[POWERPC] Remove duplicate #include
Jeremy Kerr (6):
[POWERPC] cell: Fix lost interrupts due to fasteoi handler
[POWERPC] spufs: don't touch suspend bits when purging DMA queue
[POWERPC] spufs: fix save of mfc_cntl register
[POWERPC] spufs: fix post-stopped update of MFC_CNTL register
[POWERPC] spufs: update master runcntl with context lock held
[POWERPC] spufs: don't acquire state_mutex interruptible while performing callback
Jochen Friedrich (1):
[POWERPC] Fix of_i2c include for module compilation
Luke Browning (4):
[POWERPC] spufs: set SPU_CONTEXT_SWITCH_PENDING before synchronising SPU irqs
[POWERPC] spufs: try to route SPU interrupts to local node
[POWERPC] spufs: fix concurrent delivery of class 0 & 1 exceptions
[POWERPC] spufs: handle faults while the context switch pending flag is set
Nate Case (1):
[POWERPC] Remove leftover printk in isa-bridge.c
Stefan Roese (2):
[POWERPC] 4xx: Fix problem with new TLB storage attibute fields on 440x6 core
[POWERPC] 4xx: Add endpoint support to 4xx PCIe driver
^ permalink raw reply
* Re: [PATCH 2/4 V4] MSI support on 83xx/85xx/86xx board
From: Michael Ellerman @ 2008-05-09 12:21 UTC (permalink / raw)
To: Jason Jin; +Cc: linuxppc-dev
In-Reply-To: <1210323810-24833-2-git-send-email-Jason.jin@freescale.com>
[-- Attachment #1: Type: text/plain, Size: 1160 bytes --]
On Fri, 2008-05-09 at 17:03 +0800, Jason Jin wrote:
> This MSI driver can be used on 83xx/85xx/86xx board.
> In this driver, virtual interrupt host and chip were
> setup. There are 256 MSI interrupts in this host, Every 32
> MSI interrupts cascaded to one IPIC/MPIC interrupt.
> The chip was treated as edge sensitive and some necessary
> functions were setup for this chip.
> diff --git a/arch/powerpc/sysdev/fsl_msi.c b/arch/powerpc/sysdev/fsl_msi.c
> new file mode 100644
> index 0000000..be3304d
> --- /dev/null
> +++ b/arch/powerpc/sysdev/fsl_msi.c
> @@ -0,0 +1,446 @@
...
> +static int fsl_msi_host_match(struct irq_host *h, struct device_node *node)
> +{
> + /* Exact match*/
> + return h->of_node == node;
> +}
This is the default behaviour, so technically you don't need this
routine - but I'm not fussed.
Acked-by: Michael Ellerman <michael@ellerman.id.au>
cheers
--
Michael Ellerman
OzLabs, IBM Australia Development Lab
wwweb: http://michael.ellerman.id.au
phone: +61 2 6212 1183 (tie line 70 21183)
We do not inherit the earth from our ancestors,
we borrow it from our children. - S.M.A.R.T Person
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH 1/4 V2] booting-without-of for Freescale MSI
From: Segher Boessenkool @ 2008-05-09 10:51 UTC (permalink / raw)
To: Jin Zhengxiong; +Cc: linuxppc-dev
In-Reply-To: <CC27DED0F8F39E48A7E75FD768688B7A8C16F0@zch01exm27.fsl.freescale.net>
>> Sure, I didn't say to drop the property, just make it
>> optional, since most trees will want the same value anyway.
>
> So, The code should change to work with this change, If there's the
> property, use it. If no, make it all available, Am I right?
Yeah, exactly.
Segher
^ permalink raw reply
* RE: [PATCH 1/4 V2] booting-without-of for Freescale MSI
From: Jin Zhengxiong @ 2008-05-09 10:18 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev
In-Reply-To: <a7387ce0860d7d5bcd990f1364310221@kernel.crashing.org>
> -----Original Message-----
> From: Segher Boessenkool [mailto:segher@kernel.crashing.org]=20
> Sent: Friday, May 09, 2008 6:14 PM
> To: Jin Zhengxiong
> Cc: michael@ellerman.id.au; linuxppc-dev@ozlabs.org;=20
> galak@kernel.crashing.org
> Subject: Re: [PATCH 1/4 V2] booting-without-of for Freescale MSI
>=20
> >> If these MSI devices work really identical for 83xx, 85xx, 86xx,=20
> >> there is no need to distinguish between them for probing either --=20
> >> you want to use the same driver for all, anyway
> > .
> > The driver can work for 83xx, 85xx and 86xx, but the msiir=20
> offset is=20
> > different for 83xx and 85xx/86xx cpu. I need this to get different=20
> > msiir offset in the driver.
>=20
> It's a different offset _within_ the region specified in "reg"?
> Yeah, using different "compatible" is cleanest then, no doubt.
>=20
Yes, It's different offset _within_ the "reg" region.
> >>> + - msi-available-ranges: use <start count> style
> >> section to define
> >>> which
> >>> + msi interrupt can be used in the 256 msi interrupts.
> >>
> >> Please make this property optional, default to "all available".
> >>
> > The value setting for this property is "all available", and this=20
> > ranges maybe useful for some other MSI controller.
>=20
> Sure, I didn't say to drop the property, just make it=20
> optional, since most trees will want the same value anyway.
So, The code should change to work with this change, If there's the=20
property, use it. If no, make it all available, Am I right?
Jason
^ permalink raw reply
* Re: [PATCH 1/4 V2] booting-without-of for Freescale MSI
From: Segher Boessenkool @ 2008-05-09 10:13 UTC (permalink / raw)
To: Jin Zhengxiong; +Cc: linuxppc-dev
In-Reply-To: <CC27DED0F8F39E48A7E75FD768688B7A8C16ED@zch01exm27.fsl.freescale.net>
>> If these MSI devices work really identical for 83xx, 85xx,
>> 86xx, there is no need to distinguish between them for
>> probing either -- you want to use the same driver for all, anyway
> .
> The driver can work for 83xx, 85xx and 86xx, but the msiir offset
> is different for 83xx and 85xx/86xx cpu. I need this to get different
> msiir offset in the driver.
It's a different offset _within_ the region specified in "reg"?
Yeah, using different "compatible" is cleanest then, no doubt.
>>> + - msi-available-ranges: use <start count> style
>> section to define
>>> which
>>> + msi interrupt can be used in the 256 msi interrupts.
>>
>> Please make this property optional, default to "all available".
>>
> The value setting for this property is "all available", and this ranges
> maybe
> useful for some other MSI controller.
Sure, I didn't say to drop the property, just make it optional,
since most trees will want the same value anyway.
Segher
^ permalink raw reply
* RE: [PATCH 1/4 V2] booting-without-of for Freescale MSI
From: Jin Zhengxiong @ 2008-05-09 9:52 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev
In-Reply-To: <c6e4b0f3534e38db766d76fd6450f163@kernel.crashing.org>
Hi, Segher.
Thanks=20
> > + - compatible : set as "fsl,86xx-MSI" for 86xx cpu,=20
> "fsl,85xx-MSI"=20
> > for 85xx
> > + cpu and "fsl,83xx-MSI" for 83xx cpu.
>=20
> Don't use "xx", use real device names instead. If for=20
> example the oldest 86xx device that implements this is 8600,=20
> and you write a tree for the 8699, you'd write compatible =3D=20
> "fsl,8699-msi", "fsl,8600-msi"; and the driver will look for=20
> "fsl,8600-msi" only usually, but it can take some special=20
> actions for 8699 if it needs to.
>=20
> If these MSI devices work really identical for 83xx, 85xx,=20
> 86xx, there is no need to distinguish between them for=20
> probing either -- you want to use the same driver for all, anyway
.
The driver can work for 83xx, 85xx and 86xx, but the msiir offset=20
is different for 83xx and 85xx/86xx cpu. I need this to get different=20
msiir offset in the driver.
> Oh, and the norm is to write compatible values in lower case.
Ok.
> > + - msi-available-ranges: use <start count> style=20
> section to define
> > which
> > + msi interrupt can be used in the 256 msi interrupts.
>=20
> Please make this property optional, default to "all available".
>=20
The value setting for this property is "all available", and this ranges
maybe
useful for some other MSI controller.=20
Jason
^ permalink raw reply
* Re: [PATCH 1/4 V2] booting-without-of for Freescale MSI
From: Segher Boessenkool @ 2008-05-09 9:26 UTC (permalink / raw)
To: Jason Jin; +Cc: linuxppc-dev
In-Reply-To: <1210323810-24833-1-git-send-email-Jason.jin@freescale.com>
Hi Jason,
Some more comments...
> + - compatible : set as "fsl,86xx-MSI" for 86xx cpu, "fsl,85xx-MSI"
> for 85xx
> + cpu and "fsl,83xx-MSI" for 83xx cpu.
Don't use "xx", use real device names instead. If for example the
oldest
86xx device that implements this is 8600, and you write a tree for the
8699,
you'd write compatible = "fsl,8699-msi", "fsl,8600-msi"; and the
driver
will look for "fsl,8600-msi" only usually, but it can take some special
actions for 8699 if it needs to.
If these MSI devices work really identical for 83xx, 85xx, 86xx, there
is
no need to distinguish between them for probing either -- you want to
use
the same driver for all, anyway.
Oh, and the norm is to write compatible values in lower case.
> + - msi-available-ranges: use <start count> style section to define
> which
> + msi interrupt can be used in the 256 msi interrupts.
Please make this property optional, default to "all available".
Segher
^ permalink raw reply
* [PATCH 4/4 V2] Enable MSI support for 85xxds board.
From: Jason Jin @ 2008-05-09 9:14 UTC (permalink / raw)
To: galak; +Cc: linuxppc-dev, Jason Jin
This patch enabled MSI on 8544ds and 8572ds board.
only one MSI interrupt can generate on 8544 board.
Signed-off-by: Jason Jin <Jason.jin@freescale.com>
---
compatible name in dts was changed in V2 version.
arch/powerpc/boot/dts/mpc8544ds.dts | 16 ++++++++++++++++
arch/powerpc/boot/dts/mpc8572ds.dts | 16 ++++++++++++++++
arch/powerpc/platforms/85xx/mpc85xx_ds.c | 7 ++++++-
3 files changed, 38 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/boot/dts/mpc8544ds.dts b/arch/powerpc/boot/dts/mpc8544ds.dts
index 6a0d8db..5e9b774 100644
--- a/arch/powerpc/boot/dts/mpc8544ds.dts
+++ b/arch/powerpc/boot/dts/mpc8544ds.dts
@@ -219,6 +219,22 @@
device_type = "open-pic";
big-endian;
};
+
+ msi@41600 {
+ compatible = "fsl,85xx-MSI";
+ reg = <0x41600 0x80>;
+ msi-available-ranges = <0 0x100>;
+ interrupts = <
+ 0xb0 0
+ 0xb1 0
+ 0xb2 0
+ 0xb3 0
+ 0xb4 0
+ 0xb5 0
+ 0xb6 0
+ 0xb7 0>;
+ interrupt-parent = <&mpic>;
+ };
};
pci0: pci@e0008000 {
diff --git a/arch/powerpc/boot/dts/mpc8572ds.dts b/arch/powerpc/boot/dts/mpc8572ds.dts
index 66f27ab..6fe9e4c 100644
--- a/arch/powerpc/boot/dts/mpc8572ds.dts
+++ b/arch/powerpc/boot/dts/mpc8572ds.dts
@@ -221,6 +221,22 @@
fsl,has-rstcr;
};
+ msi@41600 {
+ compatible = "fsl,86xx-msi";
+ reg = <0x41600 0x80>;
+ msi-available-ranges = <0 0x100>;
+ interrupts = <
+ 0xb0 0
+ 0xb1 0
+ 0xb2 0
+ 0xb3 0
+ 0xb4 0
+ 0xb5 0
+ 0xb6 0
+ 0xb7 0>;
+ interrupt-parent = <&mpic>;
+ };
+
mpic: pic@40000 {
clock-frequency = <0>;
interrupt-controller;
diff --git a/arch/powerpc/platforms/85xx/mpc85xx_ds.c b/arch/powerpc/platforms/85xx/mpc85xx_ds.c
index dfd8b4a..2696d2f 100644
--- a/arch/powerpc/platforms/85xx/mpc85xx_ds.c
+++ b/arch/powerpc/platforms/85xx/mpc85xx_ds.c
@@ -79,9 +79,13 @@ void __init mpc85xx_ds_pic_init(void)
mpic = mpic_alloc(np, r.start,
MPIC_PRIMARY | MPIC_WANTS_RESET | MPIC_BIG_ENDIAN,
- 0, 256, " OpenPIC ");
+ 64, 256, " OpenPIC ");
BUG_ON(mpic == NULL);
+ mpic_assign_isu(mpic, 0, r.start + 0x10000);
+ mpic_assign_isu(mpic, 1, r.start + 0x10800);
+ mpic_assign_isu(mpic, 2, r.start + 0x11600);
+
mpic_init(mpic);
#ifdef CONFIG_PPC_I8259
@@ -195,6 +199,7 @@ static int __init mpc85xxds_publish_devices(void)
return of_platform_bus_probe(NULL, mpc85xxds_ids, NULL);
}
machine_device_initcall(mpc8544_ds, mpc85xxds_publish_devices);
+machine_device_initcall(mpc8572_ds, mpc85xxds_publish_devices);
/*
* Called very early, device-tree isn't unflattened
--
1.5.4
^ permalink raw reply related
* [PATCH 3/4 V2] Enable MSI support for MPC8610HPCD board
From: Jason Jin @ 2008-05-09 9:13 UTC (permalink / raw)
To: galak; +Cc: linuxppc-dev, Jason Jin
This patch enable the MSI on 8610hpcd board.
Through the msi-available-ranges property, All the 256
msi interrupts can be tested on this board.
Signed-off-by: Jason Jin <Jason.jin@freescale.com>
---
compatible name in dts was changed in V2 version.
arch/powerpc/boot/dts/mpc8610_hpcd.dts | 16 ++++++++++++++++
arch/powerpc/platforms/86xx/mpc8610_hpcd.c | 6 +++++-
2 files changed, 21 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/boot/dts/mpc8610_hpcd.dts b/arch/powerpc/boot/dts/mpc8610_hpcd.dts
index bba234e..93e681b 100644
--- a/arch/powerpc/boot/dts/mpc8610_hpcd.dts
+++ b/arch/powerpc/boot/dts/mpc8610_hpcd.dts
@@ -128,6 +128,22 @@
big-endian;
};
+ msi@41600 {
+ compatible = "fsl,86xx-MSI";
+ reg = <0x41600 0x80>;
+ msi-available-ranges = <0 0x100>;
+ interrupts = <
+ 0xb0 0
+ 0xb1 0
+ 0xb2 0
+ 0xb3 0
+ 0xb4 0
+ 0xb5 0
+ 0xb6 0
+ 0xb7 0>;
+ interrupt-parent = <&mpic>;
+ };
+
global-utilities@e0000 {
compatible = "fsl,mpc8610-guts";
reg = <0xe0000 0x1000>;
diff --git a/arch/powerpc/platforms/86xx/mpc8610_hpcd.c b/arch/powerpc/platforms/86xx/mpc8610_hpcd.c
index 5e1e8cf..59f75f7 100644
--- a/arch/powerpc/platforms/86xx/mpc8610_hpcd.c
+++ b/arch/powerpc/platforms/86xx/mpc8610_hpcd.c
@@ -70,9 +70,13 @@ static void __init mpc86xx_hpcd_init_irq(void)
/* Alloc mpic structure and per isu has 16 INT entries. */
mpic1 = mpic_alloc(np, res.start,
MPIC_PRIMARY | MPIC_WANTS_RESET | MPIC_BIG_ENDIAN,
- 0, 256, " MPIC ");
+ 64, 256, " MPIC ");
BUG_ON(mpic1 == NULL);
+ mpic_assign_isu(mpic1, 0, res.start + 0x10000);
+ mpic_assign_isu(mpic1, 1, res.start + 0x10800);
+ mpic_assign_isu(mpic1, 2, res.start + 0x11600);
+
mpic_init(mpic1);
}
--
1.5.4
^ permalink raw reply related
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