* Re: [PATCH] 86xx: mark functions static, other minor cleanups
From: Kumar Gala @ 2008-04-15 23:24 UTC (permalink / raw)
To: Paul Gortmaker; +Cc: linuxppc-dev, Timur Tabi, sfr
In-Reply-To: <20080415224628.GA21663@windriver.com>
On Apr 15, 2008, at 5:46 PM, Paul Gortmaker wrote:
> In message: Re: [PATCH] 86xx: mark functions static, other minor
> cleanups
> on 15/04/2008 Timur Tabi wrote:
>
>> Paul Gortmaker wrote:
>>
>>> Valid point. Is there a precedent here -- like a printk indicating
>>> that the old ID matched, to let the user know?
>>
>> Not really, but a pr_warning() would be nice.
>
> Done.
>
> I've also removed the sbc8641 content from this patch, and rolled it
> into the resend of those board specific patches. This is now just for
> incorporating that same feedback into existing boards.
>
> Thanks,
> Paul.
> ---
>
> From aa2d1dd871c7eb440b3947cf8952d28249acf218 Mon Sep 17 00:00:00 2001
> From: Paul Gortmaker <paul.gortmaker@windriver.com>
> Date: Fri, 11 Apr 2008 12:51:04 -0400
> Subject: [PATCH] 86xx: mark functions static, other minor cleanups
>
> Cleanups as suggested by Stephen Rothwell and Dale Farnsworth, which
> incudes marking a bunch of functions static and add a vendor prefix to
> the compat node check for uniqueness. We match on the old compat node
> ID for one version and warn accordingly, so as to not plunge people
> into silent boot death, as suggested by Timur Tabi.
can you add a commit about the change to the root compatible and its
eventual removal for backward compatibility.
- k
^ permalink raw reply
* Re: [PATCH 12/12] [POWERPC] 85xx: Add support for relocatble kernel (and booting at non-zero)
From: Paul Mackerras @ 2008-04-16 0:03 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
In-Reply-To: <C2C3AFC1-7527-4571-8E21-3EB5904695DE@kernel.crashing.org>
Kumar Gala writes:
> > What happens if CONFIG_KERNEL_START != CONFIG_PAGE_OFFSET and the
> > kernel is loaded at some address != CONFIG_PHYSICAL_START?
>
> Assuming its not a CONFIG_RELOCATABLE kernel than bad things. Is
> there some concern you have here?
No, I meant if it is a CONFIG_RELOCATABLE kernel.
BTW, the various bits of discussion we've about this stuff would make
good material for the patch description.
Paul.
^ permalink raw reply
* Re: [PATCH v2.6.26 0/2] Dynamic TBIPA for gianfar
From: Paul Mackerras @ 2008-04-16 0:25 UTC (permalink / raw)
To: Paul Gortmaker; +Cc: linuxppc-dev
In-Reply-To: <1208276601-16964-1-git-send-email-paul.gortmaker@windriver.com>
Paul Gortmaker writes:
> This is the resend of the two patches as per Andy's request for v2.6.26
> that allow boards with a PHY at the end of the bus to function, by having
> the TBIPA set dynamically. The 1st patch factors out some of the PHY
> probe code so it can be recycled by the TBIPA probe, and the second patch
> implements the dynamic probe itself.
I notice that these two patches only touch drivers/net and
include/linux. If you want these to go upstream into Linus' tree, you
will need to send them to Jeff Garzik and the netdev list. Posting
them to the linuxppc-dev list is fine for getting them reviewed but
isn't a path to upstream.
Paul.
^ permalink raw reply
* Re: [PATCH 12/12] [POWERPC] 85xx: Add support for relocatble kernel (and booting at non-zero)
From: Kumar Gala @ 2008-04-16 0:50 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
In-Reply-To: <18437.16961.768567.782611@cargo.ozlabs.ibm.com>
On Apr 15, 2008, at 7:03 PM, Paul Mackerras wrote:
> Kumar Gala writes:
>
>>> What happens if CONFIG_KERNEL_START != CONFIG_PAGE_OFFSET and the
>>> kernel is loaded at some address != CONFIG_PHYSICAL_START?
>>
>> Assuming its not a CONFIG_RELOCATABLE kernel than bad things. Is
>> there some concern you have here?
>
> No, I meant if it is a CONFIG_RELOCATABLE kernel.
if CONFIG_RELOCATABLE is set, than PHYSICAL_START has no meaning
(beyond being what we set paddr to for the PHDR).
Its ok if KERNEL_START != PAGE_OFFSET. The key is that the physical
address the kernel is loaded at meet the alignment requirements.
(currently 256M, will relax in the future once we get a form of this
in the tree).
> BTW, the various bits of discussion we've about this stuff would make
> good material for the patch description.
Agreed was thinking the same thing. Suggestions on useful bits to add
are welcome.
- k
^ permalink raw reply
* Re: Get new_emac driver running on 405EP
From: Josh Boyer @ 2008-04-16 1:43 UTC (permalink / raw)
To: Markus Brunner; +Cc: ppc-dev
In-Reply-To: <200804152351.42651.super.firetwister@gmail.com>
On Tue, 2008-04-15 at 23:51 +0200, Markus Brunner wrote:
> On Monday 14 April 2008, Benjamin Herrenschmidt wrote:
> > > 2) On the 405EP only the MDIO pin of the emac0 is pinned out, so both
> > > phys have to be accessed through this one. This affectes the mdio
> > > read/write functions.
> >
> > The later can easily be described in the device-tree as it's a fairly
> > common setup.
>
> mdio-device does the trick. This feature wasn't used by any other board in the
> kernel yet.
>
> I made another error. I did mix up the order of the MAL irqs, so the irq
> handlers went mad. This was detected as a soft lock-up.
>
> After correcting that both emacs are working on ppc405EP :).
Cool. Btw, new board ports are welcome :).
josh
^ permalink raw reply
* Re: [PATCH v2.6.26 0/2] Dynamic TBIPA for gianfar
From: Paul Gortmaker @ 2008-04-16 1:57 UTC (permalink / raw)
To: Paul Mackerras; +Cc: Paul Gortmaker, linuxppc-dev
In-Reply-To: <18437.18289.944128.351533@cargo.ozlabs.ibm.com>
On Tue, Apr 15, 2008 at 8:25 PM, Paul Mackerras <paulus@samba.org> wrote:
> Paul Gortmaker writes:
>
> > This is the resend of the two patches as per Andy's request for v2.6.26
> > that allow boards with a PHY at the end of the bus to function, by having
> > the TBIPA set dynamically. The 1st patch factors out some of the PHY
> > probe code so it can be recycled by the TBIPA probe, and the second patch
> > implements the dynamic probe itself.
>
> I notice that these two patches only touch drivers/net and
> include/linux. If you want these to go upstream into Linus' tree, you
> will need to send them to Jeff Garzik and the netdev list. Posting
> them to the linuxppc-dev list is fine for getting them reviewed but
> isn't a path to upstream.
Yep, they have already been sent to Jeff/netdev earlier today as well.
I'd inadvertently left them off the CC but Andy reminded me already.
Thanks,
Paul.
>
>
>
> Paul.
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
>
^ permalink raw reply
* Re: [PATCH v2.6.26 0/2] Dynamic TBIPA for gianfar
From: Kumar Gala @ 2008-04-16 2:06 UTC (permalink / raw)
To: Paul Gortmaker
Cc: Paul Gortmaker, netdev, Paul Mackerras,
linuxppc-dev@ozlabs.org list
In-Reply-To: <7d1d9c250804151857x65cf14cfxe6dc5696505631c7@mail.gmail.com>
On Apr 15, 2008, at 8:57 PM, Paul Gortmaker wrote:
> On Tue, Apr 15, 2008 at 8:25 PM, Paul Mackerras <paulus@samba.org>
> wrote:
>> Paul Gortmaker writes:
>>
>>> This is the resend of the two patches as per Andy's request for
>>> v2.6.26
>>> that allow boards with a PHY at the end of the bus to function, by
>>> having
>>> the TBIPA set dynamically. The 1st patch factors out some of the
>>> PHY
>>> probe code so it can be recycled by the TBIPA probe, and the
>>> second patch
>>> implements the dynamic probe itself.
>>
>> I notice that these two patches only touch drivers/net and
>> include/linux. If you want these to go upstream into Linus' tree,
>> you
>> will need to send them to Jeff Garzik and the netdev list. Posting
>> them to the linuxppc-dev list is fine for getting them reviewed but
>> isn't a path to upstream.
>
> Yep, they have already been sent to Jeff/netdev earlier today as well.
> I'd inadvertently left them off the CC but Andy reminded me already.
>
> Thanks,
> Paul.
these should get an Ack by Andy before going in to any tree.
- k
^ permalink raw reply
* SystemACE on Kernel 2.6
From: rodolfo @ 2008-04-16 2:40 UTC (permalink / raw)
To: Linuxppc embedded
Hi Grant likely,
I got kernel 2.6.20 from kernel.org and I want boot it on XUP Virtex II Pro
University board.
I edited the Makefile putting:
ARCH? = ppc
CROSS_COMPILE? = ppc_4xx-
But I can't see anything about SystemACE driver on make menuconfig from
this Kernel. How can I add SystemACE controler?
I compiled the kernel repeatedly generating a file zImage.elf. I used this
file with the genace.tcl from Xilinx and this opt file:
-jprog
-board user
-target ppc_hw
-hw implementation/download.bit
-elf zImage.elf
-configdevice devicenr 1 idcode 0x1127e093 irlength 14 partname xc2vp30
-debugdevice devicenr 1 cpunr 1
-ace system.ace
to generated ace file and put it in FAT16 partition of CF card, like a lot
of references in web. But it doesn't works!
Which IP cores must be present in my project of the EDK?
Still speaking in the EDK Did i have to mark bram with ppc_405_0_bootloop?
Did I have to mark bram whit any software project?
My work in with Linux on Virtex don't work. I am almost dropping...
Thanks!!
^ permalink raw reply
* some highmem questions
From: Kumar Gala @ 2008-04-16 3:36 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev@ozlabs.org list
Paul,
Do you why we have the following:
* include/asm-powerpc/highmem.h - kunmap_atomic - comment about //FIXME?
* CONFIG_HIGHMEM_START -- what was the thinking here?
- k
^ permalink raw reply
* [PATCH 1/2] Move prototype for find_udbg_vterm() into a header file
From: Michael Ellerman @ 2008-04-16 3:51 UTC (permalink / raw)
To: linuxppc-dev
Move the prototype for find_udbg_vterm() into pseries.h, removing
it from setup.c
Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
---
arch/powerpc/platforms/pseries/lpar.c | 1 +
arch/powerpc/platforms/pseries/pseries.h | 2 ++
arch/powerpc/platforms/pseries/setup.c | 3 ---
3 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/platforms/pseries/lpar.c b/arch/powerpc/platforms/pseries/lpar.c
index 233d9be..8a20452 100644
--- a/arch/powerpc/platforms/pseries/lpar.c
+++ b/arch/powerpc/platforms/pseries/lpar.c
@@ -40,6 +40,7 @@
#include <asm/smp.h>
#include "plpar_wrappers.h"
+#include "pseries.h"
#ifdef DEBUG_LOW
#define DBG_LOW(fmt...) do { udbg_printf(fmt); } while(0)
diff --git a/arch/powerpc/platforms/pseries/pseries.h b/arch/powerpc/platforms/pseries/pseries.h
index 61136d0..9e17c0d 100644
--- a/arch/powerpc/platforms/pseries/pseries.h
+++ b/arch/powerpc/platforms/pseries/pseries.h
@@ -38,4 +38,6 @@ extern void pSeries_final_fixup(void);
/* Poweron flag used for enabling auto ups restart */
extern unsigned long rtas_poweron_auto;
+extern void find_udbg_vterm(void);
+
#endif /* _PSERIES_PSERIES_H */
diff --git a/arch/powerpc/platforms/pseries/setup.c b/arch/powerpc/platforms/pseries/setup.c
index 90555a3..fccca89 100644
--- a/arch/powerpc/platforms/pseries/setup.c
+++ b/arch/powerpc/platforms/pseries/setup.c
@@ -76,9 +76,6 @@
#define DBG(fmt...)
#endif
-/* move those away to a .h */
-extern void find_udbg_vterm(void);
-
int fwnmi_active; /* TRUE if an FWNMI handler is present */
static void pseries_shared_idle_sleep(void);
--
1.5.5
^ permalink raw reply related
* [PATCH 2/2] Always add preferred consoles in platforms/pseries/lpar.c
From: Michael Ellerman @ 2008-04-16 3:51 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <0709e3bcb1c8a4341b474f530c1823d2735d26ce.1208317906.git.michael@ellerman.id.au>
There is logic in platforms/peries/lpars.c which checks if the user has
specified a console on the command line, and refrains from adding a
preferred console entry for the hvc/hvsi console if they have.
This trips up if you use "netconsole=foo" on the command line, and has
the result that you get _only_ the netconsole, because the hvc device is
never added as a preferred console. Worse still if you get the netconsole
configuration wrong somehow, you end up with no console at all.
As it turns out we don't need to worry about checking the command line.
If the user has specified "console=foo", then foo will be set as the
preferred console when the command line is parsed in start_kernel(), much
later than the pseries code, and so the latter setting will take effect.
Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
---
arch/powerpc/platforms/pseries/lpar.c | 9 ++-------
1 files changed, 2 insertions(+), 7 deletions(-)
diff --git a/arch/powerpc/platforms/pseries/lpar.c b/arch/powerpc/platforms/pseries/lpar.c
index 8a20452..9235c46 100644
--- a/arch/powerpc/platforms/pseries/lpar.c
+++ b/arch/powerpc/platforms/pseries/lpar.c
@@ -204,7 +204,6 @@ void __init find_udbg_vterm(void)
struct device_node *stdout_node;
const u32 *termno;
const char *name;
- int add_console;
/* find the boot console from /chosen/stdout */
if (!of_chosen)
@@ -220,8 +219,6 @@ void __init find_udbg_vterm(void)
printk(KERN_WARNING "stdout node missing 'name' property!\n");
goto out;
}
- /* The user has requested a console so this is already set up. */
- add_console = !strstr(cmd_line, "console=");
/* Check if it's a virtual terminal */
if (strncmp(name, "vty", 3) != 0)
@@ -235,15 +232,13 @@ void __init find_udbg_vterm(void)
udbg_putc = udbg_putcLP;
udbg_getc = udbg_getcLP;
udbg_getc_poll = udbg_getc_pollLP;
- if (add_console)
- add_preferred_console("hvc", termno[0] & 0xff, NULL);
+ add_preferred_console("hvc", termno[0] & 0xff, NULL);
} else if (of_device_is_compatible(stdout_node, "hvterm-protocol")) {
vtermno = termno[0];
udbg_putc = udbg_hvsi_putc;
udbg_getc = udbg_hvsi_getc;
udbg_getc_poll = udbg_hvsi_getc_poll;
- if (add_console)
- add_preferred_console("hvsi", termno[0] & 0xff, NULL);
+ add_preferred_console("hvsi", termno[0] & 0xff, NULL);
}
out:
of_node_put(stdout_node);
--
1.5.5
^ permalink raw reply related
* Re: io_block_mapping & ioremap question
From: Kumar Gala @ 2008-04-16 3:52 UTC (permalink / raw)
To: Gutson Daniel-ADG035; +Cc: linuxppc-embedded
In-Reply-To: <0539F2514A979C4B9386FF81809203FF016B6540@ct11exm66.ds.mot.com>
On Apr 15, 2008, at 11:25 AM, Gutson Daniel-ADG035 wrote:
> Hi,
> I'm doing some work on 2.6.10, and got this problem:
> - there are some io_block_mapping calls in the setup_io_mapping
> callback, that use the BATs, and passing same va and pa each one.
> Problem arises later when vmallocs gets a a pointer within the mapped
> ranges. In other words, seems like the VMM is not aware of the BATs
> mapping.
>
> So what I did is: called first ioremap and then io_block_mapping in
> the
> callback thus not hardcoding the va, something like:
> va = ioremap(pa, size);
> io_block_mapping(pa, va, size);
>
> Questions:
> 1) Is it right?
> 2) Should I unmap that address sometime later? (i.e. after
> mem_init_done).
You should look at getting ride of your io_block_mapping calls as
we've removed that in new kernels.
However, ioremap() should work properly in that it should lookup the
address you are mapping via p_mapped_by_bats().
- k
^ permalink raw reply
* Re: SystemACE on Kernel 2.6
From: Grant Likely @ 2008-04-16 4:57 UTC (permalink / raw)
To: rodolfo; +Cc: Linuxppc embedded
In-Reply-To: <7aa21da00314dfb40c194e38e2488048@lesc.ufc.br>
On Tue, Apr 15, 2008 at 7:40 PM, rodolfo <rodolfo@lesc.ufc.br> wrote:
> Hi Grant likely,
>
> I got kernel 2.6.20 from kernel.org and I want boot it on XUP Virtex II Pro
This is an old kernel. Use a current kernel.
> University board.
> I edited the Makefile putting:
> ARCH? = ppc
> CROSS_COMPILE? = ppc_4xx-
> But I can't see anything about SystemACE driver on make menuconfig from
> this Kernel. How can I add SystemACE controler?
Its in the block device menu
> I compiled the kernel repeatedly generating a file zImage.elf. I used this
> file with the genace.tcl from Xilinx and this opt file:
> -jprog
> -board user
> -target ppc_hw
> -hw implementation/download.bit
> -elf zImage.elf
> -configdevice devicenr 1 idcode 0x1127e093 irlength 14 partname xc2vp30
> -debugdevice devicenr 1 cpunr 1
> -ace system.ace
>
> to generated ace file and put it in FAT16 partition of CF card, like a lot
> of references in web. But it doesn't works!
> Which IP cores must be present in my project of the EDK?
> Still speaking in the EDK Did i have to mark bram with ppc_405_0_bootloop?
> Did I have to mark bram whit any software project?
- Did you generate an xparameters_ml40x.h in edk and copy it into the
kernel tree?
- you need either a uart16550 or a uartlite for the console
- Make sure the matching serial driver is compiled into the kernel
- Make sure console support is enabled for the serial driver
- Make sure your kernel boot parameters include 'console=ttyS0,115200'
for uart16550 or 'console=ttyUL0' for uartlite.
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: [PATCH 2/11] cell: generalize io-workarounds code
From: Benjamin Herrenschmidt @ 2008-04-16 7:18 UTC (permalink / raw)
To: Ishizaki Kou; +Cc: linuxppc-dev, paulus
In-Reply-To: <20080314.212034.-1625856941.kouish@swc.toshiba.co.jp>
On Fri, 2008-03-14 at 21:20 +0900, Ishizaki Kou wrote:
> This patch splits cell io-workaround code into spider-pci dependent
> code and a generic part, and also adds interfaces to the generic
> io-workaround mechanism.
>
> Signed-off-by: Kou Ishizaki <kou.ishizaki@toshiba.co.jp>
> ---
>
> Please test on CellBlade because I don't have any access to CellBlade.
Unfortunately, that crashes on spider based cell blade, see below:
> +
> + /* setup dummy read */
> + /*
> + * On CellBlade, we can't know that which XDR memory is used by
> + * kmalloc() to allocate dummy_page_va.
> + * In order to imporve the performance, the XDR which is used to
> + * allocate dummy_page_va is the nearest the spider-pci.
> + * We have to select the CBE which is the nearest the spider-pci
> + * to allocate memory from the best XDR, but I don't know that
> + * how to do.
> + *
> + * Celleb does not have this problem, because it has only one XDR.
> + */
> + dummy_page_va = kmalloc(PAGE_SIZE, GFP_KERNEL);
> + if (!dummy_page_va) {
> + pr_err("SPIDERPCI-IOWA:Alloc dummy_page_va failed.\n");
> + return -1;
> + }
> +
> + dummy_page_da = dma_map_single(phb->parent, dummy_page_va,
> + PAGE_SIZE, DMA_FROM_DEVICE);
> + if (dma_mapping_error(dummy_page_da)) {
> + pr_err("SPIDER-IOWA:Map dummy page filed.\n");
> + kfree(dummy_page_va);
> + return -1;
> + }
The above dma_map_single() will crash on QS20 because there is no
phb->parent on these. The QS20 uses the "old style" PCI probing
mechanism where PCI busses are setup off the root node at setup_arch
time and have no struct device attached, which means yo ucan't call
dma_map_single on them unfortunately.
Now I wonder...
> +int __init spiderpci_iowa_init(struct iowa_bus *bus, void *data)
> +{
> + void __iomem *regs = NULL;
> + struct spiderpci_iowa_private *priv;
> + struct device_node *np = bus->phb->dn;
> + struct resource r;
> + unsigned long offset = (unsigned long)data;
> +
> + pr_debug("SPIDERPCI-IOWA:Bus initialize for spider(%s)\n",
> + np->full_name);
> +
.../...
Is the above spiderpci_iowa_init() function ever used on Celleb ? It
looks to me like Celleb relies on the new of_platform stuff to create
the PCI host bridges off OF devices, after boot, in which case that
would work for you. That would mean that the above function is really
only useful for busses created in setup_arch() which is really only the
QS20 cell blade, right ?
In that case, I think that function should be moved to the cell blade
setup.c file instead of here. Now, regarding the above problem, I'm not
sure what is the best fix at this stage. We can't create sane struct
device objects at setup_arch() time.
We could create a hand-made platform or of_platform device from the
above function for every bridge that doesn't have one and hook up it's
DMA ops... I suppose that would fix it.
I've started hacking something but didn't yet get it working, I'll
continue tomorrow unless you come up with some other solution.
Cheers,
Ben.
^ permalink raw reply
* Re: SystemACE on Kernel 2.6
From: Yoshio Kashiwagi @ 2008-04-16 7:23 UTC (permalink / raw)
To: rodolfo, Linuxppc embedded
In-Reply-To: <7aa21da00314dfb40c194e38e2488048@lesc.ufc.br>
Hi,
The mark of BRAM is good at bootloop.
Priority is given to specified initial pc if -start_address is specified
by an opt file. Before starting a Linux kernel, can TestApp_Memory or a
TestApp_Peripheral program be started from CF?
The opt file which I am using is as follows.
-jprog
-hw implementation/download.bit
-ace cfboot.ace
-board ml405
-target ppc_hw
-elf zImage.elf
-start_address 0x00400000
Best Regards,
Yoshio Kashiwagi - Nissin Systems
> Hi Grant likely,
>
> I got kernel 2.6.20 from kernel.org and I want boot it on XUP Virtex
II Pro
> University board.
> I edited the Makefile putting:
> ARCH? = ppc
> CROSS_COMPILE? = ppc_4xx-
> But I can't see anything about SystemACE driver on make menuconfig
from
> this Kernel. How can I add SystemACE controler?
>
> I compiled the kernel repeatedly generating a file zImage.elf. I used
this
> file with the genace.tcl from Xilinx and this opt file:
> -jprog
> -board user
> -target ppc_hw
> -hw implementation/download.bit
> -elf zImage.elf
> -configdevice devicenr 1 idcode 0x1127e093 irlength 14 partname
xc2vp30
> -debugdevice devicenr 1 cpunr 1
> -ace system.ace
>
> to generated ace file and put it in FAT16 partition of CF card, like a
lot
> of references in web. But it doesn't works!
> Which IP cores must be present in my project of the EDK?
> Still speaking in the EDK Did i have to mark bram with ppc_405_0_
bootloop?
> Did I have to mark bram whit any software project?
>
> My work in with Linux on Virtex don't work. I am almost dropping...
>
> Thanks!!
^ permalink raw reply
* [PATCH] powerpc: Modem control lines support for the cpm_uart driver
From: Laurent Pinchart @ 2008-04-16 9:10 UTC (permalink / raw)
To: linux-ppc list
This patch replaces the get_mctrl/set_mctrl stubs with modem control line
read/write access through the GPIO lib.
Available modem control lines are described in the device tree using GPIO
bindings.
Signed-off-by: Laurent Pinchart <laurentp@cse-semaphore.com>
---
Documentation/powerpc/booting-without-of.txt | 10 ++++++
drivers/serial/cpm_uart/cpm_uart.h | 10 ++++++
drivers/serial/cpm_uart/cpm_uart_core.c | 40 ++++++++++++++++++++++++--
3 files changed, 57 insertions(+), 3 deletions(-)
diff --git a/Documentation/powerpc/booting-without-of.txt b/Documentation/powerpc/booting-without-of.txt
index 1e5572a..012f231 100644
--- a/Documentation/powerpc/booting-without-of.txt
+++ b/Documentation/powerpc/booting-without-of.txt
@@ -1976,6 +1976,14 @@ platforms are moved over to use the flattened-device-tree model.
- fsl,cpm2-scc-uart
- fsl,qe-uart
+ Modem control lines connected to GPIO controllers are listed in the
+ gpios property as described in section VIII.1 in the following order:
+
+ CTS, RTS, DCD, DSR, DTR, and RI.
+
+ The gpios property is optional and can be left out when control lines are
+ not used.
+
Example:
serial@11a00 {
@@ -1987,6 +1995,8 @@ platforms are moved over to use the flattened-device-tree model.
interrupt-parent = <&PIC>;
fsl,cpm-brg = <1>;
fsl,cpm-command = <00800000>;
+ gpios = <&gpio_c 15 0
+ &gpio_d 29 0>;
};
iii) Network
diff --git a/drivers/serial/cpm_uart/cpm_uart.h b/drivers/serial/cpm_uart/cpm_uart.h
index 0cc39f8..d0c55e2 100644
--- a/drivers/serial/cpm_uart/cpm_uart.h
+++ b/drivers/serial/cpm_uart/cpm_uart.h
@@ -50,6 +50,15 @@
#define SCC_WAIT_CLOSING 100
+#define GPIO_CTS 0
+#define GPIO_RTS 1
+#define GPIO_DCD 2
+#define GPIO_DSR 3
+#define GPIO_DTR 4
+#define GPIO_RI 5
+
+#define NUM_GPIOS (GPIO_RI+1)
+
struct uart_cpm_port {
struct uart_port port;
u16 rx_nrfifos;
@@ -82,6 +91,7 @@ struct uart_cpm_port {
int wait_closing;
/* value to combine with opcode to form cpm command */
u32 command;
+ int gpios[NUM_GPIOS];
};
#ifndef CONFIG_PPC_CPM_NEW_BINDING
diff --git a/drivers/serial/cpm_uart/cpm_uart_core.c b/drivers/serial/cpm_uart/cpm_uart_core.c
index 7a704ff..0f08071 100644
--- a/drivers/serial/cpm_uart/cpm_uart_core.c
+++ b/drivers/serial/cpm_uart/cpm_uart_core.c
@@ -42,6 +42,8 @@
#include <linux/bootmem.h>
#include <linux/dma-mapping.h>
#include <linux/fs_uart_pd.h>
+#include <linux/gpio.h>
+#include <linux/of_gpio.h>
#include <asm/io.h>
#include <asm/irq.h>
@@ -152,13 +154,41 @@ static unsigned int cpm_uart_tx_empty(struct uart_port *port)
static void cpm_uart_set_mctrl(struct uart_port *port, unsigned int mctrl)
{
- /* Whee. Do nothing. */
+ struct uart_cpm_port *pinfo = (struct uart_cpm_port *)port;
+
+ if (pinfo->gpios[GPIO_RTS] >= 0)
+ gpio_set_value(pinfo->gpios[GPIO_RTS], !(mctrl & TIOCM_RTS));
+
+ if (pinfo->gpios[GPIO_DTR] >= 0)
+ gpio_set_value(pinfo->gpios[GPIO_DTR], !(mctrl & TIOCM_DTR));
}
static unsigned int cpm_uart_get_mctrl(struct uart_port *port)
{
- /* Whee. Do nothing. */
- return TIOCM_CAR | TIOCM_DSR | TIOCM_CTS;
+ struct uart_cpm_port *pinfo = (struct uart_cpm_port *)port;
+ unsigned int mctrl = TIOCM_CTS | TIOCM_DSR | TIOCM_CAR;
+
+ if (pinfo->gpios[GPIO_CTS] >= 0) {
+ if (gpio_get_value(pinfo->gpios[GPIO_CTS]))
+ mctrl &= ~TIOCM_CTS;
+ }
+
+ if (pinfo->gpios[GPIO_DSR] >= 0) {
+ if (gpio_get_value(pinfo->gpios[GPIO_DSR]))
+ mctrl &= ~TIOCM_DSR;
+ }
+
+ if (pinfo->gpios[GPIO_DCD] >= 0) {
+ if (gpio_get_value(pinfo->gpios[GPIO_DCD]))
+ mctrl &= ~TIOCM_CAR;
+ }
+
+ if (pinfo->gpios[GPIO_RI] >= 0) {
+ if (!gpio_get_value(pinfo->gpios[GPIO_RI]))
+ mctrl |= TIOCM_RNG;
+ }
+
+ return mctrl;
}
/*
@@ -959,6 +989,7 @@ static int cpm_uart_init_port(struct device_node *np,
void __iomem *mem, *pram;
int len;
int ret;
+ int i;
data = of_get_property(np, "fsl,cpm-brg", &len);
if (!data || len != 4) {
@@ -1017,6 +1048,9 @@ static int cpm_uart_init_port(struct device_node *np,
goto out_pram;
}
+ for (i = 0; i < NUM_GPIOS; i++)
+ pinfo->gpios[i] = of_get_gpio(np, i);
+
return cpm_uart_request_port(&pinfo->port);
out_pram:
--
1.5.0
--
Laurent Pinchart
CSE Semaphore Belgium
Chaussee de Bruxelles, 732A
B-1410 Waterloo
Belgium
T +32 (2) 387 42 59
F +32 (2) 387 42 75
^ permalink raw reply related
* linux-next: 4xx build failure
From: Stephen Rothwell @ 2008-04-16 9:42 UTC (permalink / raw)
To: Josh Boyer; +Cc: ppc-dev, linux-next
[-- Attachment #1: Type: text/plain, Size: 1211 bytes --]
Hi Josh,
Today's linux-next build (powerpc allyesconfig) failed like this:
drivers/net/ibm_newemac/core.c: In function ‘emac_rx_clk_tx’:
drivers/net/ibm_newemac/core.c:146: error: implicit declaration of function ‘dcri_clrset’
drivers/net/ibm_newemac/core.c:146: error: ‘SDR0’ undeclared (first use in this function)
drivers/net/ibm_newemac/core.c:146: error: (Each undeclared identifier is reported only once
drivers/net/ibm_newemac/core.c:146: error: for each function it appears in.)
drivers/net/ibm_newemac/core.c: In function ‘emac_rx_clk_default’:
drivers/net/ibm_newemac/core.c:152: error: ‘SDR0’ undeclared (first use in this function)
drivers/net/ibm_newemac/core.c: In function ‘emac_init_phy’:
drivers/net/ibm_newemac/core.c:2361: error: ‘SDR0’ undeclared (first use in this function)
I have reverted commit 863a1175e22cb108f596a5aa55b1e535a77e7cce
("[POWERPC] ibm_newemac: PowerPC 440EP/440GR EMAC PHY clock workaround")
and commit 4b2d72f5035764cd2e89f5a13ab35c11a27c557b ("[POWERPC]
ibm_newemac: PowerPC 440GX EMAC PHY clock workaround").
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Phy read timeout in ibm_new_emac driver
From: M B @ 2008-04-16 10:49 UTC (permalink / raw)
To: netdev; +Cc: ppc-dev
The __emac_mdio_read function of the emac driver (core.c) will retry
100 times and wait 99us (until the last call of emac_phy_done). I
assume this is an off by one error.
/* Wait for read to complete */
n = 100;
while (!emac_phy_done(dev, (r = in_be32(&p->stacr)))) {
udelay(1);
if (!--n) {
DBG2(dev, " -> timeout wait complete\n");
goto bail;
}
}
My Micrel/Kendin KSZ8721BT on my ppc405EP board needs one us longer to
finish. I was able to reproduce this all the time. So I wonder if the
timeout of 100us is defined by the MII standard, or by the author of
the driver?
If it's a standard I've still a bad feeling if we just correct the
timeout to 100us, maybe 110 should be fine. If it's not defined by the
standard, I would add 50% to the timeout. It won't slow down other
phys, but a scan on the phy bus might get slowed down.
Same applies for __emac_mdio_write.
Oh and we could save a us by putting the udelay(1) after the if section ;-)
Regards
Markus
^ permalink raw reply
* Re: State of the MPC5200 PSC AC97 driver
From: Juergen Beisert @ 2008-04-16 11:24 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <200804151003.17865.jbe@pengutronix.de>
On Tuesday 15 April 2008 10:03, Juergen Beisert wrote:
> Currently it fails to play anything with an external Wolfson WM9712
> connected to it. It seems the current AC97 reset sequence switches the
> WM9712 into testmode due to SDATA_OUT and Sync are not held low while the
> reset is active. Any idea to solve this? Switching both signals to GPIO a=
nd
> force them to low level while reset is active? How to cover PSC1 and PSC2
> with different GPIOs for this case?
Cannot reproduce the reset issue now, but in my case the bestcomm was
programmed to service the wrong PSC unit. That was the reason I never heard
any sound.
Can us give the oftree a better differentiation to program the bestcomm in a
correct manner?
Subject: [@num@/@total@] mpc52xx: Change the AC97 driver to be more generic
=46rom: Juergen Beisert <j.beisert@pengutronix.de>
The current AC97 driver for the mpc52xx CPU is fixed to work on PSC2. This
patch tries to make it more generic, as it detects the PSC unit for AC97 us=
age
to forward this information into the Bestcomm-API.
Signed-off-by: Juergen Beisert <j.beisert@pengutronix.de>
=2D--
sound/ppc/mpc52xx_ac97.c | 21 ++++++++++++++++++++-
1 file changed, 20 insertions(+), 1 deletion(-)
Index: sound/ppc/mpc52xx_ac97.c
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
=2D-- sound/ppc/mpc52xx_ac97.c.orig
+++ sound/ppc/mpc52xx_ac97.c
@@ -651,6 +651,7 @@ mpc52xx_ac97_probe(struct of_device *op,
struct mpc52xx_ac97_priv *priv;
struct snd_card *card;
struct resource res;
+ int tx_initiator;
int rv;
=20
dev_dbg(&op->dev, "probing MPC52xx PSC AC97 driver\n");
@@ -699,10 +700,27 @@ mpc52xx_ac97_probe(struct of_device *op,
/* Setup Bestcomm tasks */
spin_lock_init(&priv->dma_lock);
=20
+ /*
+ * PSC1 or PSC2 can be configured for AC97 usage. Select the right
+ * channel, to let the BCOMM unit does its job correctly.
+ */
+ switch (priv->mem_start & 0xFFFF) {
+ case 0x2000: /* PSC1 */
+ tx_initiator =3D 14;
+ break;
+ case 0x2200: /* PSC2 */
+ tx_initiator =3D 12;
+ break;
+ default:
+ dev_dbg(priv->dev, "Unknown PSC unit for AC97 usage!\n");
+ rv - ENODEV;
+ goto err_irq;
+ }
+
priv->tsk_tx =3D bcom_gen_bd_tx_init(AC97_TX_NUM_BD,
priv->mem_start + offsetof(struct mpc52xx_psc,
tfdata),
=2D 12, /* initiator : FIXME */
+ tx_initiator,
2); /* ipr : FIXME */
if (!priv->tsk_tx) {
printk(KERN_ERR DRV_NAME ": bcom_gen_bd_tx_init failed\n");
@@ -759,6 +777,7 @@ err_irqreq:
bcom_gen_bd_tx_release(priv->tsk_tx);
err_bcomm:
mpc52xx_ac97_hwshutdown(priv);
+err_irq:
irq_dispose_mapping(priv->irq);
err_irqmap:
iounmap(priv->psc);
Juergen
=2D-=20
Dipl.-Ing. Juergen Beisert | http://www.pengutronix.de
=A0Pengutronix - Linux Solutions for Science and Industry
=A0 Handelsregister: Amtsgericht Hildesheim, HRA 2686
=A0 =A0 =A0 Vertretung Sued/Muenchen, Germany
Phone: +49-8766-939 228 | Fax: +49-5121-206917-9
^ permalink raw reply
* MPC5200B MMC over SPI into PSC6
From: tosettofabio83 @ 2008-04-16 11:26 UTC (permalink / raw)
To: linuxppc-embedded
Hello, I have an embedded system with an on-board processor powerpc MPC5200B
and Linux kernel 2.6.22,
I must turn over to MMC SPI on the PSC6.
First, I
have enabled PSC6:
in ../arch/ppc/platforms/lite5200.c added PSC6 in SPI mode
struct mpc52xx_psc_func mpc52xx_psc_functions[] = {
{ .id = 3,
.func = "uart",
},
{ .id = 4,
.func = "uart",
},
{ .id = 5,
.func = "spi",
},
};
in ..
/arch/powerpc/boot/dts/lite5200b.dts enabled PSC6 in SPI mode
// PSC6 in spi mode example
spi@2c00 { // PSC6
device_type = "spi";
compatible = "mpc5200b-psc-spi\0mpc5200-psc-spi";
cell-index = <5>;
reg =
<2c00 100>;
interrupts = <2 4 0>;
interrupt-parent = <&mpc5200_pic>;
};
Now on the menuconfig enabling these options:
$ make ARCH=powerpc
CROSS_COMPILE=powerpc-linux-gnu- menuconfig
Platform support --->
[*]
MPC5200 (L25R) bugfix support
[*] Freescale Lite5200 Eval Board
Device
Drivers ---> SPI Support --->
[*] SPI support
<*> Freescale MPC52xx
PSC SPI controller
this options settings the CONFIG_SPI_MPC52xx_PSC=y variable
into .config
When linux booting, if I debug ../driver/spi/mpc52xx_psc_spi.c,
see that:
bus platform: add driver mpc52xx-psc-
spi
bus platform: remove driver mpc52xx-psc-spi
drivers/spi/mpc52xx_psc_spi.c:
of_register_platform_driver failed (-19)
why??
any idea??
Someone knows how
to enable mmc over spi on PSC6?
thanks Fabio Tosetto
^ permalink raw reply
* USB @ MPC8343
From: Andre Schwarz @ 2008-04-16 12:08 UTC (permalink / raw)
To: linux-ppc list
Dear List,
on my MPC8343 based board there is a "USB3300" ULPI-PHY connected to the
processor.
It's an OTG capable PHY but host mode should be enough right now.
Since USB is not used inside bootloader it's not configured at all...
As far as I can see the setup should be done inside the kernel completely.
My dts looks like this :
usb@23000 {
device_type = "usb";
compatible = "fsl-usb2-dr";
reg = <0x23000 0x1000>;
#address-cells = <1>;
#size-cells = <0>;
interrupt-parent = <&ipic>;
interrupts = <38 0x8>;
dr_mode = "host";
phy_type = "ulpi";
port1;
};
Since the MPC8343 has only one USB port I assume it is "port1" since the
port1-pins are coming out of the package :-)
DR registers are located @ 0x23000
Kernel log :
fsl-ehci fsl-ehci.0: Freescale On-Chip EHCI Host Controller
fsl-ehci fsl-ehci.0: new USB bus registered, assigned bus number 1
fsl-ehci fsl-ehci.0: irq 38, io base 0xe0023000
fsl-ehci fsl-ehci.0: USB 2.0 started, EHCI 1.00, driver 10 Dec 2004
usb usb1: configuration #1 chosen from 1 choice
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 1 port detected
usb usb1: New USB device found, idVendor=1d6b, idProduct=0002
usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1
usb usb1: Product: Freescale On-Chip EHCI Host Controller
usb usb1: Manufacturer: Linux 2.6.25-rc8-01233-g6249f9d-dirty ehci_hcd
usb usb1: SerialNumber: fsl-ehci.0
ohci_hcd: 2006 August 04 USB 1.1 'Open' Host Controller (OHCI) Driver
usbcore: registered new interface driver cdc_acm
drivers/usb/class/cdc-acm.c: v0.25:USB Abstract Control Model driver for
USB modems and ISDN adapters
Initializing USB Mass Storage driver...
usbcore: registered new interface driver usb-storage
USB Mass Storage support registered.
usbcore: registered new interface driver libusual
Clocks and communication are looking fine (from an electrical point of
view) and bus power is applied.
But : no device (mouse, memory stick, ...) gets recognized.
No interrupts either.
An hints ?
regards,
Andre Schwarz
Matrix Vision
MATRIX VISION GmbH, Talstraße 16, DE-71570 Oppenweiler - Registergericht: Amtsgericht Stuttgart, HRB 271090
Geschäftsführer: Gerhard Thullner, Werner Armingeon, Uwe Furtner
^ permalink raw reply
* Re: Phy read timeout in ibm_new_emac driver
From: Benjamin Herrenschmidt @ 2008-04-16 12:09 UTC (permalink / raw)
To: M B; +Cc: netdev, ppc-dev
In-Reply-To: <6a6049b80804160349q42120b4bs1c0db49ea5ad055d@mail.gmail.com>
> My Micrel/Kendin KSZ8721BT on my ppc405EP board needs one us longer to
> finish. I was able to reproduce this all the time. So I wonder if the
> timeout of 100us is defined by the MII standard, or by the author of
> the driver?
> If it's a standard I've still a bad feeling if we just correct the
> timeout to 100us, maybe 110 should be fine. If it's not defined by the
> standard, I would add 50% to the timeout. It won't slow down other
> phys, but a scan on the phy bus might get slowed down.
> Same applies for __emac_mdio_write.
>
> Oh and we could save a us by putting the udelay(1) after the if section ;-)
Increasing the timeout is fine. In fact, EMAC specifically can sleep in
it's MDIO access routines (it already takes mutexes) so maybe a good
option here is to use longer sleeping delays and less iterations.
Somebody knows off hand what the standard says the timeout should be ? I
can check that tomorrow, I don't have it at hand right now and it's
getting late but feel free to beat me to it :-)
Cheers,
Ben.
^ permalink raw reply
* Re: linux-next: 4xx build failure
From: Josh Boyer @ 2008-04-16 12:24 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: ppc-dev, linux-next
In-Reply-To: <20080416194227.1e5e1a9a.sfr@canb.auug.org.au>
On Wed, 16 Apr 2008 19:42:27 +1000
Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> Hi Josh,
>=20
> Today's linux-next build (powerpc allyesconfig) failed like this:
>=20
> drivers/net/ibm_newemac/core.c: In function =E2=80=98emac_rx_clk_tx=E2=80=
=99:
> drivers/net/ibm_newemac/core.c:146: error: implicit declaration of functi=
on =E2=80=98dcri_clrset=E2=80=99
> drivers/net/ibm_newemac/core.c:146: error: =E2=80=98SDR0=E2=80=99 undecla=
red (first use in this function)
> drivers/net/ibm_newemac/core.c:146: error: (Each undeclared identifier is=
reported only once
> drivers/net/ibm_newemac/core.c:146: error: for each function it appears i=
n.)
> drivers/net/ibm_newemac/core.c: In function =E2=80=98emac_rx_clk_default=
=E2=80=99:
> drivers/net/ibm_newemac/core.c:152: error: =E2=80=98SDR0=E2=80=99 undecla=
red (first use in this function)
> drivers/net/ibm_newemac/core.c: In function =E2=80=98emac_init_phy=E2=80=
=99:
> drivers/net/ibm_newemac/core.c:2361: error: =E2=80=98SDR0=E2=80=99 undecl=
ared (first use in this function)
>=20
> I have reverted commit 863a1175e22cb108f596a5aa55b1e535a77e7cce
> ("[POWERPC] ibm_newemac: PowerPC 440EP/440GR EMAC PHY clock workaround")
> and commit 4b2d72f5035764cd2e89f5a13ab35c11a27c557b ("[POWERPC]
> ibm_newemac: PowerPC 440GX EMAC PHY clock workaround").
Grr. Yes, that's probably the right solution for now. I had forgotten
about Axon.
Sorry for the trouble. I'll revert those commits locally and repush.
josh
^ permalink raw reply
* Re: Please pull 'for-2.6.26' branch of 4xx tree
From: Josh Boyer @ 2008-04-16 12:27 UTC (permalink / raw)
To: paulus; +Cc: linuxppc-dev
In-Reply-To: <20080415102704.39511160@zod.rchland.ibm.com>
On Tue, 15 Apr 2008 10:27:04 -0500
Josh Boyer <jwboyer@linux.vnet.ibm.com> wrote:
> Valentine Barshak (2):
> [POWERPC] ibm_newemac: PowerPC 440GX EMAC PHY clock workaround
> [POWERPC] ibm_newemac: PowerPC 440EP/440GR EMAC PHY clock workaround
These two commits have been dropped from the branch. They cause the
allyesconfig build for powerpc to fail because CONFIG_PPC_DCR_MMIO
doesn't understand the dcri_clrset macro.
josh
^ permalink raw reply
* More patches pushed to powerpc.git master and powerpc-next branches
From: Paul Mackerras @ 2008-04-16 12:32 UTC (permalink / raw)
To: linuxppc-dev
The following commits are now in the master and powerpc-next branches
in the powerpc.git tree. This includes commits pulled from Josh
Boyer's and Olof Johansson's trees.
Paul.
Adrian Bunk (1):
[POWERPC] Add MODULE_LICENSE to powerpc/sysdev/rtc_cmos_setup.c
Anton Vorontsov (2):
[POWERPC] OF helpers for the GPIO API
[POWERPC] Implement support for the GPIO LIB API
Benjamin Herrenschmidt (3):
[POWERPC] Initialize paca->current earlier
[POWERPC] Fixup softirq preempt count
[POWERPC] properly declare onstack completion in iseries veth
David Woodhouse (1):
[POWERPC] Efika: Really, don't pretend to be CHRP
Ishizaki Kou (2):
[POWERPC] celleb: Coding style cleanup
[POWERPC] hvcbeat: Fix buffer manipulation
Jerone Young (1):
[POWERPC] 4xx: Add idle wait support for 44x platforms
Jochen Friedrich (1):
[POWERPC] i2c: OF helpers for the i2c API
Josh Boyer (2):
[POWERPC] 4xx: Reorganize 4xx defconfigs
[POWERPC] 4xx: Add ppc40x_defconfig
Kumar Gala (12):
[POWERPC] Remove Kconfig option BOOT_LOAD
[POWERPC] Provide access to arch/powerpc include path on ppc64
[POWERPC] Remove and replace uses of PPC_MEMSTART with memstart_addr
[POWERPC] Introduce lowmem_end_addr to distinguish from total_lowmem
[POWERPC] 85xx: Cleanup TLB initialization
[POWERPC] Use lowmem_end_addr to limit lmb allocations on ppc32
[POWERPC] Rename __initial_memory_limit to __initial_memory_limit_addr
[POWERPC] Clean up some linker and symbol usage
[POWERPC] Move phys_addr_t definition into asm/types.h
[POWERPC] Update linker script to properly set physical addresses
[POWERPC] bootwrapper: Use physical address in PHDR for uImage
[POWERPC] Cleanup pgtable-ppc32.h
Manish Ahuja (1):
[POWERPC] pseries/phyp dump: Reserve a variable amount of space at boot
Nate Case (1):
pasemi_mac: Netpoll support
Olof Johansson (2):
pasemi_mac: Jumbo frame bugfixes
[POWERPC] pasemi: Minor iommu cleanup
Valentine Barshak (3):
[POWERPC] kexec: MPIC ack interrupts at mpic_teardown_this_cpu()
[POWERPC] ibm_newemac: PowerPC 440GX EMAC PHY clock workaround
[POWERPC] ibm_newemac: PowerPC 440EP/440GR EMAC PHY clock workaround
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox