* Fwd: MPIC ISU
From: vb @ 2008-01-20 20:32 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <f608b67d0801201216o60be67a1w3ead9714c3bba5aa@mail.gmail.com>
[add linuxppc-embedded@ozlabs.org,]
On Jan 19, 2008 8:19 AM, Kumar Gala <galak@kernel.crashing.org> wrote:
>
> >
> > what platform is linkstation and what kernel version can I find it in?
>
> arch/powerpc/platforms/embedded6xx/linkstation.c
>
> you should be able to find it 2.6.23 or newer.
>
Kumar, thank you for this clarification, I see this file in the latest kernel.
One more question, just out of curiosity - why is it in
platforms/embedded6xx and not in platforms/82xx - is there any
explicit reason for this distinction?
TIA,
/vb
> - k
>
>
^ permalink raw reply
* [PATCH] [POWERPC] Always hookup PHB IO resource even when empty
From: Benjamin Herrenschmidt @ 2008-01-21 0:32 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
We must always hookup the pci_bus resource 0 to the PHB io_resource even
if the later is empty (the bus has no IO support). Otherwise, some other
code will end up hooking it up to something bogus and the resource tree
will end up being broken.
This fixes boot on QS20 Cell blades where the IDE driver failed to allocate
the IO resources due to breakage of the resource tree.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
---
This is for 2.6.25, fixes a bug in my PCI rework.
arch/powerpc/kernel/pci_64.c | 11 ++++-------
1 file changed, 4 insertions(+), 7 deletions(-)
--- linux-merge.orig/arch/powerpc/kernel/pci_64.c 2008-01-21 11:27:41.000000000 +1100
+++ linux-merge/arch/powerpc/kernel/pci_64.c 2008-01-21 11:28:07.000000000 +1100
@@ -357,7 +357,6 @@ void __devinit scan_phb(struct pci_contr
struct pci_bus *bus;
struct device_node *node = hose->dn;
int i, mode;
- struct resource *res;
DBG("PCI: Scanning PHB %s\n", node ? node->full_name : "<NO NAME>");
@@ -375,12 +374,10 @@ void __devinit scan_phb(struct pci_contr
pcibios_map_io_space(bus);
/* Wire up PHB bus resources */
- if (hose->io_resource.flags) {
- DBG("PCI: PHB IO resource = %016lx-%016lx [%lx]\n",
- hose->io_resource.start, hose->io_resource.end,
- hose->io_resource.flags);
- bus->resource[0] = res = &hose->io_resource;
- }
+ DBG("PCI: PHB IO resource = %016lx-%016lx [%lx]\n",
+ hose->io_resource.start, hose->io_resource.end,
+ hose->io_resource.flags);
+ bus->resource[0] = &hose->io_resource;
for (i = 0; i < 3; ++i) {
DBG("PCI: PHB MEM resource %d = %016lx-%016lx [%lx]\n", i,
hose->mem_resources[i].start,
^ permalink raw reply
* Re: [PATCH] [POWERPC] Always hookup PHB IO resource even when empty
From: Michael Ellerman @ 2008-01-21 0:37 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <20080121003256.E1EBDDDDF0@ozlabs.org>
[-- Attachment #1: Type: text/plain, Size: 780 bytes --]
On Mon, 2008-01-21 at 11:32 +1100, Benjamin Herrenschmidt wrote:
> We must always hookup the pci_bus resource 0 to the PHB io_resource even
> if the later is empty (the bus has no IO support). Otherwise, some other
> code will end up hooking it up to something bogus and the resource tree
> will end up being broken.
>
> This fixes boot on QS20 Cell blades where the IDE driver failed to allocate
> the IO resources due to breakage of the resource tree.
Tested-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
* [PATCH 1/7] Set archdata.dma_data for direct DMA in cell_dma_dev_setup()
From: Michael Ellerman @ 2008-01-21 5:42 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Arnd Bergmann, cbe-oss-dev
Store the direct_dma_offset in each device's dma_data in the case
where we're using the direct DMA ops.
We need to make sure we setup the ppc_md.pci_dma_dev_setup() callback
if we're using a non-zero offset.
Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
---
arch/powerpc/platforms/cell/iommu.c | 8 ++++++--
1 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/platforms/cell/iommu.c b/arch/powerpc/platforms/cell/iommu.c
index bceb5e1..9682b63 100644
--- a/arch/powerpc/platforms/cell/iommu.c
+++ b/arch/powerpc/platforms/cell/iommu.c
@@ -496,9 +496,10 @@ static void cell_dma_dev_setup(struct device *dev)
struct cbe_iommu *iommu;
struct dev_archdata *archdata = &dev->archdata;
- /* If we run without iommu, no need to do anything */
- if (get_pci_dma_ops() == &dma_direct_ops)
+ if (get_pci_dma_ops() == &dma_direct_ops) {
+ archdata->dma_data = (void *)dma_direct_offset;
return;
+ }
/* Current implementation uses the first window available in that
* node's iommu. We -might- do something smarter later though it may
@@ -690,6 +691,9 @@ static int __init cell_iommu_init_disabled(void)
dma_direct_offset += base;
+ if (dma_direct_offset != 0)
+ ppc_md.pci_dma_dev_setup = cell_pci_dma_dev_setup;
+
printk("iommu: disabled, direct DMA offset is 0x%lx\n",
dma_direct_offset);
--
1.5.2.rc1.1884.g59b20
^ permalink raw reply related
* [PATCH 2/7] Add celleb_dma_dev_setup()
From: Michael Ellerman @ 2008-01-21 5:42 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Arnd Bergmann, cbe-oss-dev
In-Reply-To: <2949748ba6ad7e14f0768ac3889267e42c050d7a.1200894155.git.michael@ellerman.id.au>
Celleb always uses dma_direct_ops, and sets dma_direct_offset, so it too
should set dma_data to dma_direct_offset.
Currently there's no pci_dma_dev_setup() routine for Celleb so add one.
Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
---
arch/powerpc/platforms/celleb/iommu.c | 14 +++++++++++++-
1 files changed, 13 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/platforms/celleb/iommu.c b/arch/powerpc/platforms/celleb/iommu.c
index 41e1e6f..843a66f 100644
--- a/arch/powerpc/platforms/celleb/iommu.c
+++ b/arch/powerpc/platforms/celleb/iommu.c
@@ -72,6 +72,17 @@ static void __init celleb_init_direct_mapping(void)
dma_direct_offset = dma_base;
}
+static void celleb_dma_dev_setup(struct device *dev)
+{
+ dev->archdata.dma_ops = get_pci_dma_ops();
+ dev->archdata.dma_data = (void *)dma_direct_offset;
+}
+
+static void celleb_pci_dma_dev_setup(struct pci_dev *pdev)
+{
+ celleb_dma_dev_setup(&pdev->dev);
+}
+
static int celleb_of_bus_notify(struct notifier_block *nb,
unsigned long action, void *data)
{
@@ -81,7 +92,7 @@ static int celleb_of_bus_notify(struct notifier_block *nb,
if (action != BUS_NOTIFY_ADD_DEVICE)
return 0;
- dev->archdata.dma_ops = get_pci_dma_ops();
+ celleb_dma_dev_setup(dev);
return 0;
}
@@ -94,6 +105,7 @@ static int __init celleb_init_iommu(void)
{
celleb_init_direct_mapping();
set_pci_dma_ops(&dma_direct_ops);
+ ppc_md.pci_dma_dev_setup = celleb_pci_dma_dev_setup;
bus_register_notifier(&of_platform_bus_type, &celleb_of_bus_notifier);
return 0;
--
1.5.2.rc1.1884.g59b20
^ permalink raw reply related
* [PATCH 3/7] Use archdata.dma_data in dma_direct_ops and add the offset
From: Michael Ellerman @ 2008-01-21 5:42 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Arnd Bergmann, cbe-oss-dev
In-Reply-To: <2949748ba6ad7e14f0768ac3889267e42c050d7a.1200894155.git.michael@ellerman.id.au>
Now that all platforms using dma_direct_offset setup the archdata.dma_data
correctly, we can change the dma_direct_ops to retrieve the offset from
the dma_data, rather than directly from the global.
While we're here, change the way the offset is used - instead of or'ing it
into the value, add it. This should have no effect on current implementations
where the offset is far larger than memory, however in future we may want
to use smaller offsets.
Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
---
arch/powerpc/kernel/dma_64.c | 11 ++++++++---
1 files changed, 8 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/kernel/dma_64.c b/arch/powerpc/kernel/dma_64.c
index 14206e3..a2d076d 100644
--- a/arch/powerpc/kernel/dma_64.c
+++ b/arch/powerpc/kernel/dma_64.c
@@ -117,6 +117,11 @@ EXPORT_SYMBOL(dma_iommu_ops);
*/
unsigned long dma_direct_offset;
+static unsigned long get_dma_direct_offset(struct device *dev)
+{
+ return (unsigned long)dev->archdata.dma_data;
+}
+
static void *dma_direct_alloc_coherent(struct device *dev, size_t size,
dma_addr_t *dma_handle, gfp_t flag)
{
@@ -130,7 +135,7 @@ static void *dma_direct_alloc_coherent(struct device *dev, size_t size,
return NULL;
ret = page_address(page);
memset(ret, 0, size);
- *dma_handle = virt_to_abs(ret) | dma_direct_offset;
+ *dma_handle = virt_to_abs(ret) + get_dma_direct_offset(dev);
return ret;
}
@@ -145,7 +150,7 @@ static dma_addr_t dma_direct_map_single(struct device *dev, void *ptr,
size_t size,
enum dma_data_direction direction)
{
- return virt_to_abs(ptr) | dma_direct_offset;
+ return virt_to_abs(ptr) + get_dma_direct_offset(dev);
}
static void dma_direct_unmap_single(struct device *dev, dma_addr_t dma_addr,
@@ -161,7 +166,7 @@ static int dma_direct_map_sg(struct device *dev, struct scatterlist *sgl,
int i;
for_each_sg(sgl, sg, nents, i) {
- sg->dma_address = sg_phys(sg) | dma_direct_offset;
+ sg->dma_address = sg_phys(sg) + get_dma_direct_offset(dev);
sg->dma_length = sg->length;
}
--
1.5.2.rc1.1884.g59b20
^ permalink raw reply related
* [PATCH 4/7] Have cell use its own dma_direct_offset variable
From: Michael Ellerman @ 2008-01-21 5:42 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Arnd Bergmann, cbe-oss-dev
In-Reply-To: <2949748ba6ad7e14f0768ac3889267e42c050d7a.1200894155.git.michael@ellerman.id.au>
Rather than using the global variable, have cell use its own variable to
store the direct DMA offset.
Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
---
arch/powerpc/platforms/cell/iommu.c | 12 +++++++-----
1 files changed, 7 insertions(+), 5 deletions(-)
diff --git a/arch/powerpc/platforms/cell/iommu.c b/arch/powerpc/platforms/cell/iommu.c
index 9682b63..7f45d59 100644
--- a/arch/powerpc/platforms/cell/iommu.c
+++ b/arch/powerpc/platforms/cell/iommu.c
@@ -490,6 +490,8 @@ static struct cbe_iommu *cell_iommu_for_node(int nid)
return NULL;
}
+static unsigned long cell_dma_direct_offset;
+
static void cell_dma_dev_setup(struct device *dev)
{
struct iommu_window *window;
@@ -497,7 +499,7 @@ static void cell_dma_dev_setup(struct device *dev)
struct dev_archdata *archdata = &dev->archdata;
if (get_pci_dma_ops() == &dma_direct_ops) {
- archdata->dma_data = (void *)dma_direct_offset;
+ archdata->dma_data = (void *)cell_dma_direct_offset;
return;
}
@@ -655,7 +657,7 @@ static int __init cell_iommu_init_disabled(void)
/* If we have no Axon, we set up the spider DMA magic offset */
if (of_find_node_by_name(NULL, "axon") == NULL)
- dma_direct_offset = SPIDER_DMA_OFFSET;
+ cell_dma_direct_offset = SPIDER_DMA_OFFSET;
/* Now we need to check to see where the memory is mapped
* in PCI space. We assume that all busses use the same dma
@@ -689,13 +691,13 @@ static int __init cell_iommu_init_disabled(void)
return -ENODEV;
}
- dma_direct_offset += base;
+ cell_dma_direct_offset += base;
- if (dma_direct_offset != 0)
+ if (cell_dma_direct_offset != 0)
ppc_md.pci_dma_dev_setup = cell_pci_dma_dev_setup;
printk("iommu: disabled, direct DMA offset is 0x%lx\n",
- dma_direct_offset);
+ cell_dma_direct_offset);
return 0;
}
--
1.5.2.rc1.1884.g59b20
^ permalink raw reply related
* [PATCH 5/7] Have celleb use its own dma_direct_offset variable
From: Michael Ellerman @ 2008-01-21 5:42 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Arnd Bergmann, cbe-oss-dev
In-Reply-To: <2949748ba6ad7e14f0768ac3889267e42c050d7a.1200894155.git.michael@ellerman.id.au>
Rather than using the global variable, have celleb use its own variable to
store the direct DMA offset.
Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
---
arch/powerpc/platforms/celleb/iommu.c | 6 ++++--
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/platforms/celleb/iommu.c b/arch/powerpc/platforms/celleb/iommu.c
index 843a66f..93b0efd 100644
--- a/arch/powerpc/platforms/celleb/iommu.c
+++ b/arch/powerpc/platforms/celleb/iommu.c
@@ -52,6 +52,8 @@ static int __init find_dma_window(u64 *io_space_id, u64 *ioid,
return 0;
}
+static unsigned long celleb_dma_direct_offset;
+
static void __init celleb_init_direct_mapping(void)
{
u64 lpar_addr, io_addr;
@@ -69,13 +71,13 @@ static void __init celleb_init_direct_mapping(void)
ioid, DMA_FLAGS);
}
- dma_direct_offset = dma_base;
+ celleb_dma_direct_offset = dma_base;
}
static void celleb_dma_dev_setup(struct device *dev)
{
dev->archdata.dma_ops = get_pci_dma_ops();
- dev->archdata.dma_data = (void *)dma_direct_offset;
+ dev->archdata.dma_data = (void *)celleb_dma_direct_offset;
}
static void celleb_pci_dma_dev_setup(struct pci_dev *pdev)
--
1.5.2.rc1.1884.g59b20
^ permalink raw reply related
* [PATCH 6/7] Remove the global dma_direct_offset
From: Michael Ellerman @ 2008-01-21 5:42 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Arnd Bergmann, cbe-oss-dev
In-Reply-To: <2949748ba6ad7e14f0768ac3889267e42c050d7a.1200894155.git.michael@ellerman.id.au>
We no longer need the global dma_direct_offset, update the comment to
reflect the new reality.
Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
---
arch/powerpc/kernel/dma_64.c | 7 ++++---
include/asm-powerpc/dma-mapping.h | 2 --
2 files changed, 4 insertions(+), 5 deletions(-)
diff --git a/arch/powerpc/kernel/dma_64.c b/arch/powerpc/kernel/dma_64.c
index a2d076d..72fdc06 100644
--- a/arch/powerpc/kernel/dma_64.c
+++ b/arch/powerpc/kernel/dma_64.c
@@ -112,10 +112,11 @@ EXPORT_SYMBOL(dma_iommu_ops);
/*
* Generic direct DMA implementation
*
- * This implementation supports a global offset that can be applied if
- * the address at which memory is visible to devices is not 0.
+ * This implementation supports a per-device offset that can be applied if
+ * the address at which memory is visible to devices is not 0. Platform code
+ * can set archdata.dma_data to an unsigned long holding the offset. By
+ * default the offset is zero.
*/
-unsigned long dma_direct_offset;
static unsigned long get_dma_direct_offset(struct device *dev)
{
diff --git a/include/asm-powerpc/dma-mapping.h b/include/asm-powerpc/dma-mapping.h
index e974876..5eea6db 100644
--- a/include/asm-powerpc/dma-mapping.h
+++ b/include/asm-powerpc/dma-mapping.h
@@ -189,8 +189,6 @@ static inline void dma_unmap_sg(struct device *dev, struct scatterlist *sg,
extern struct dma_mapping_ops dma_iommu_ops;
extern struct dma_mapping_ops dma_direct_ops;
-extern unsigned long dma_direct_offset;
-
#else /* CONFIG_PPC64 */
#define dma_supported(dev, mask) (1)
--
1.5.2.rc1.1884.g59b20
^ permalink raw reply related
* [PATCH 7/7] Remove bogus comment in dma_direct_alloc_coherent()
From: Michael Ellerman @ 2008-01-21 5:42 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Arnd Bergmann, cbe-oss-dev
In-Reply-To: <2949748ba6ad7e14f0768ac3889267e42c050d7a.1200894155.git.michael@ellerman.id.au>
Since commit c80d9133e99de1af607314107910a2a1645efb17 (Make direct DMA use
node local allocations) went in this comment makes no sense.
Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
---
arch/powerpc/kernel/dma_64.c | 1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/kernel/dma_64.c b/arch/powerpc/kernel/dma_64.c
index 72fdc06..8423907 100644
--- a/arch/powerpc/kernel/dma_64.c
+++ b/arch/powerpc/kernel/dma_64.c
@@ -130,7 +130,6 @@ static void *dma_direct_alloc_coherent(struct device *dev, size_t size,
void *ret;
int node = dev->archdata.numa_node;
- /* TODO: Maybe use the numa node here too ? */
page = alloc_pages_node(node, flag, get_order(size));
if (page == NULL)
return NULL;
--
1.5.2.rc1.1884.g59b20
^ permalink raw reply related
* Re: [PATCH 1/7] Set archdata.dma_data for direct DMA in cell_dma_dev_setup()
From: Benjamin Herrenschmidt @ 2008-01-21 6:20 UTC (permalink / raw)
To: Michael Ellerman; +Cc: linuxppc-dev, Arnd Bergmann, cbe-oss-dev
In-Reply-To: <2949748ba6ad7e14f0768ac3889267e42c050d7a.1200894155.git.michael@ellerman.id.au>
On Mon, 2008-01-21 at 16:42 +1100, Michael Ellerman wrote:
> Store the direct_dma_offset in each device's dma_data in the case
> where we're using the direct DMA ops.
>
> We need to make sure we setup the ppc_md.pci_dma_dev_setup() callback
> if we're using a non-zero offset.
>
> Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> ---
> arch/powerpc/platforms/cell/iommu.c | 8 ++++++--
> 1 files changed, 6 insertions(+), 2 deletions(-)
>
> diff --git a/arch/powerpc/platforms/cell/iommu.c b/arch/powerpc/platforms/cell/iommu.c
> index bceb5e1..9682b63 100644
> --- a/arch/powerpc/platforms/cell/iommu.c
> +++ b/arch/powerpc/platforms/cell/iommu.c
> @@ -496,9 +496,10 @@ static void cell_dma_dev_setup(struct device *dev)
> struct cbe_iommu *iommu;
> struct dev_archdata *archdata = &dev->archdata;
>
> - /* If we run without iommu, no need to do anything */
> - if (get_pci_dma_ops() == &dma_direct_ops)
> + if (get_pci_dma_ops() == &dma_direct_ops) {
> + archdata->dma_data = (void *)dma_direct_offset;
> return;
> + }
>
> /* Current implementation uses the first window available in that
> * node's iommu. We -might- do something smarter later though it may
> @@ -690,6 +691,9 @@ static int __init cell_iommu_init_disabled(void)
>
> dma_direct_offset += base;
>
> + if (dma_direct_offset != 0)
> + ppc_md.pci_dma_dev_setup = cell_pci_dma_dev_setup;
> +
> printk("iommu: disabled, direct DMA offset is 0x%lx\n",
> dma_direct_offset);
>
^ permalink raw reply
* Re: [PATCH 2/7] Add celleb_dma_dev_setup()
From: Benjamin Herrenschmidt @ 2008-01-21 6:20 UTC (permalink / raw)
To: Michael Ellerman; +Cc: linuxppc-dev, Arnd Bergmann, cbe-oss-dev
In-Reply-To: <4bdf881cfc1386c5167495a5e64bdb9dc3ca90d5.1200894155.git.michael@ellerman.id.au>
On Mon, 2008-01-21 at 16:42 +1100, Michael Ellerman wrote:
> Celleb always uses dma_direct_ops, and sets dma_direct_offset, so it too
> should set dma_data to dma_direct_offset.
>
> Currently there's no pci_dma_dev_setup() routine for Celleb so add one.
>
> Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> ---
> arch/powerpc/platforms/celleb/iommu.c | 14 +++++++++++++-
> 1 files changed, 13 insertions(+), 1 deletions(-)
>
> diff --git a/arch/powerpc/platforms/celleb/iommu.c b/arch/powerpc/platforms/celleb/iommu.c
> index 41e1e6f..843a66f 100644
> --- a/arch/powerpc/platforms/celleb/iommu.c
> +++ b/arch/powerpc/platforms/celleb/iommu.c
> @@ -72,6 +72,17 @@ static void __init celleb_init_direct_mapping(void)
> dma_direct_offset = dma_base;
> }
>
> +static void celleb_dma_dev_setup(struct device *dev)
> +{
> + dev->archdata.dma_ops = get_pci_dma_ops();
> + dev->archdata.dma_data = (void *)dma_direct_offset;
> +}
> +
> +static void celleb_pci_dma_dev_setup(struct pci_dev *pdev)
> +{
> + celleb_dma_dev_setup(&pdev->dev);
> +}
> +
> static int celleb_of_bus_notify(struct notifier_block *nb,
> unsigned long action, void *data)
> {
> @@ -81,7 +92,7 @@ static int celleb_of_bus_notify(struct notifier_block *nb,
> if (action != BUS_NOTIFY_ADD_DEVICE)
> return 0;
>
> - dev->archdata.dma_ops = get_pci_dma_ops();
> + celleb_dma_dev_setup(dev);
>
> return 0;
> }
> @@ -94,6 +105,7 @@ static int __init celleb_init_iommu(void)
> {
> celleb_init_direct_mapping();
> set_pci_dma_ops(&dma_direct_ops);
> + ppc_md.pci_dma_dev_setup = celleb_pci_dma_dev_setup;
> bus_register_notifier(&of_platform_bus_type, &celleb_of_bus_notifier);
>
> return 0;
^ permalink raw reply
* Re: [PATCH 3/7] Use archdata.dma_data in dma_direct_ops and add the offset
From: Benjamin Herrenschmidt @ 2008-01-21 6:21 UTC (permalink / raw)
To: Michael Ellerman; +Cc: linuxppc-dev, Arnd Bergmann, cbe-oss-dev
In-Reply-To: <651e15968afb5bbd9eeafb0b66cd5b59eabcf8d9.1200894155.git.michael@ellerman.id.au>
On Mon, 2008-01-21 at 16:42 +1100, Michael Ellerman wrote:
> Now that all platforms using dma_direct_offset setup the archdata.dma_data
> correctly, we can change the dma_direct_ops to retrieve the offset from
> the dma_data, rather than directly from the global.
>
> While we're here, change the way the offset is used - instead of or'ing it
> into the value, add it. This should have no effect on current implementations
> where the offset is far larger than memory, however in future we may want
> to use smaller offsets.
>
> Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> ---
> arch/powerpc/kernel/dma_64.c | 11 ++++++++---
> 1 files changed, 8 insertions(+), 3 deletions(-)
>
> diff --git a/arch/powerpc/kernel/dma_64.c b/arch/powerpc/kernel/dma_64.c
> index 14206e3..a2d076d 100644
> --- a/arch/powerpc/kernel/dma_64.c
> +++ b/arch/powerpc/kernel/dma_64.c
> @@ -117,6 +117,11 @@ EXPORT_SYMBOL(dma_iommu_ops);
> */
> unsigned long dma_direct_offset;
>
> +static unsigned long get_dma_direct_offset(struct device *dev)
> +{
> + return (unsigned long)dev->archdata.dma_data;
> +}
> +
> static void *dma_direct_alloc_coherent(struct device *dev, size_t size,
> dma_addr_t *dma_handle, gfp_t flag)
> {
> @@ -130,7 +135,7 @@ static void *dma_direct_alloc_coherent(struct device *dev, size_t size,
> return NULL;
> ret = page_address(page);
> memset(ret, 0, size);
> - *dma_handle = virt_to_abs(ret) | dma_direct_offset;
> + *dma_handle = virt_to_abs(ret) + get_dma_direct_offset(dev);
>
> return ret;
> }
> @@ -145,7 +150,7 @@ static dma_addr_t dma_direct_map_single(struct device *dev, void *ptr,
> size_t size,
> enum dma_data_direction direction)
> {
> - return virt_to_abs(ptr) | dma_direct_offset;
> + return virt_to_abs(ptr) + get_dma_direct_offset(dev);
> }
>
> static void dma_direct_unmap_single(struct device *dev, dma_addr_t dma_addr,
> @@ -161,7 +166,7 @@ static int dma_direct_map_sg(struct device *dev, struct scatterlist *sgl,
> int i;
>
> for_each_sg(sgl, sg, nents, i) {
> - sg->dma_address = sg_phys(sg) | dma_direct_offset;
> + sg->dma_address = sg_phys(sg) + get_dma_direct_offset(dev);
> sg->dma_length = sg->length;
> }
>
^ permalink raw reply
* Re: [PATCH 4/7] Have cell use its own dma_direct_offset variable
From: Benjamin Herrenschmidt @ 2008-01-21 6:21 UTC (permalink / raw)
To: Michael Ellerman; +Cc: linuxppc-dev, Arnd Bergmann, cbe-oss-dev
In-Reply-To: <0a87a8672c76341044ebb0231ff0c1fba4e82c36.1200894155.git.michael@ellerman.id.au>
On Mon, 2008-01-21 at 16:42 +1100, Michael Ellerman wrote:
> Rather than using the global variable, have cell use its own variable to
> store the direct DMA offset.
>
> Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
> ---
> arch/powerpc/platforms/cell/iommu.c | 12 +++++++-----
> 1 files changed, 7 insertions(+), 5 deletions(-)
>
> diff --git a/arch/powerpc/platforms/cell/iommu.c b/arch/powerpc/platforms/cell/iommu.c
> index 9682b63..7f45d59 100644
> --- a/arch/powerpc/platforms/cell/iommu.c
> +++ b/arch/powerpc/platforms/cell/iommu.c
> @@ -490,6 +490,8 @@ static struct cbe_iommu *cell_iommu_for_node(int nid)
> return NULL;
> }
>
> +static unsigned long cell_dma_direct_offset;
> +
> static void cell_dma_dev_setup(struct device *dev)
> {
> struct iommu_window *window;
> @@ -497,7 +499,7 @@ static void cell_dma_dev_setup(struct device *dev)
> struct dev_archdata *archdata = &dev->archdata;
>
> if (get_pci_dma_ops() == &dma_direct_ops) {
> - archdata->dma_data = (void *)dma_direct_offset;
> + archdata->dma_data = (void *)cell_dma_direct_offset;
> return;
> }
>
> @@ -655,7 +657,7 @@ static int __init cell_iommu_init_disabled(void)
>
> /* If we have no Axon, we set up the spider DMA magic offset */
> if (of_find_node_by_name(NULL, "axon") == NULL)
> - dma_direct_offset = SPIDER_DMA_OFFSET;
> + cell_dma_direct_offset = SPIDER_DMA_OFFSET;
>
> /* Now we need to check to see where the memory is mapped
> * in PCI space. We assume that all busses use the same dma
> @@ -689,13 +691,13 @@ static int __init cell_iommu_init_disabled(void)
> return -ENODEV;
> }
>
> - dma_direct_offset += base;
> + cell_dma_direct_offset += base;
>
> - if (dma_direct_offset != 0)
> + if (cell_dma_direct_offset != 0)
> ppc_md.pci_dma_dev_setup = cell_pci_dma_dev_setup;
>
> printk("iommu: disabled, direct DMA offset is 0x%lx\n",
> - dma_direct_offset);
> + cell_dma_direct_offset);
>
> return 0;
> }
^ permalink raw reply
* Re: [PATCH 4/7] Have cell use its own dma_direct_offset variable
From: Benjamin Herrenschmidt @ 2008-01-21 6:21 UTC (permalink / raw)
To: Michael Ellerman; +Cc: linuxppc-dev, Arnd Bergmann, cbe-oss-dev
In-Reply-To: <0a87a8672c76341044ebb0231ff0c1fba4e82c36.1200894155.git.michael@ellerman.id.au>
On Mon, 2008-01-21 at 16:42 +1100, Michael Ellerman wrote:
> Rather than using the global variable, have cell use its own variable to
> store the direct DMA offset.
>
> Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> ---
> arch/powerpc/platforms/cell/iommu.c | 12 +++++++-----
> 1 files changed, 7 insertions(+), 5 deletions(-)
>
> diff --git a/arch/powerpc/platforms/cell/iommu.c b/arch/powerpc/platforms/cell/iommu.c
> index 9682b63..7f45d59 100644
> --- a/arch/powerpc/platforms/cell/iommu.c
> +++ b/arch/powerpc/platforms/cell/iommu.c
> @@ -490,6 +490,8 @@ static struct cbe_iommu *cell_iommu_for_node(int nid)
> return NULL;
> }
>
> +static unsigned long cell_dma_direct_offset;
> +
> static void cell_dma_dev_setup(struct device *dev)
> {
> struct iommu_window *window;
> @@ -497,7 +499,7 @@ static void cell_dma_dev_setup(struct device *dev)
> struct dev_archdata *archdata = &dev->archdata;
>
> if (get_pci_dma_ops() == &dma_direct_ops) {
> - archdata->dma_data = (void *)dma_direct_offset;
> + archdata->dma_data = (void *)cell_dma_direct_offset;
> return;
> }
>
> @@ -655,7 +657,7 @@ static int __init cell_iommu_init_disabled(void)
>
> /* If we have no Axon, we set up the spider DMA magic offset */
> if (of_find_node_by_name(NULL, "axon") == NULL)
> - dma_direct_offset = SPIDER_DMA_OFFSET;
> + cell_dma_direct_offset = SPIDER_DMA_OFFSET;
>
> /* Now we need to check to see where the memory is mapped
> * in PCI space. We assume that all busses use the same dma
> @@ -689,13 +691,13 @@ static int __init cell_iommu_init_disabled(void)
> return -ENODEV;
> }
>
> - dma_direct_offset += base;
> + cell_dma_direct_offset += base;
>
> - if (dma_direct_offset != 0)
> + if (cell_dma_direct_offset != 0)
> ppc_md.pci_dma_dev_setup = cell_pci_dma_dev_setup;
>
> printk("iommu: disabled, direct DMA offset is 0x%lx\n",
> - dma_direct_offset);
> + cell_dma_direct_offset);
>
> return 0;
> }
^ permalink raw reply
* Re: [PATCH 5/7] Have celleb use its own dma_direct_offset variable
From: Benjamin Herrenschmidt @ 2008-01-21 6:21 UTC (permalink / raw)
To: Michael Ellerman; +Cc: linuxppc-dev, Arnd Bergmann, cbe-oss-dev
In-Reply-To: <e9ff0b0489aa17d36387d252811c2846976684fd.1200894155.git.michael@ellerman.id.au>
On Mon, 2008-01-21 at 16:42 +1100, Michael Ellerman wrote:
> Rather than using the global variable, have celleb use its own variable to
> store the direct DMA offset.
>
> Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> ---
> arch/powerpc/platforms/celleb/iommu.c | 6 ++++--
> 1 files changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/arch/powerpc/platforms/celleb/iommu.c b/arch/powerpc/platforms/celleb/iommu.c
> index 843a66f..93b0efd 100644
> --- a/arch/powerpc/platforms/celleb/iommu.c
> +++ b/arch/powerpc/platforms/celleb/iommu.c
> @@ -52,6 +52,8 @@ static int __init find_dma_window(u64 *io_space_id, u64 *ioid,
> return 0;
> }
>
> +static unsigned long celleb_dma_direct_offset;
> +
> static void __init celleb_init_direct_mapping(void)
> {
> u64 lpar_addr, io_addr;
> @@ -69,13 +71,13 @@ static void __init celleb_init_direct_mapping(void)
> ioid, DMA_FLAGS);
> }
>
> - dma_direct_offset = dma_base;
> + celleb_dma_direct_offset = dma_base;
> }
>
> static void celleb_dma_dev_setup(struct device *dev)
> {
> dev->archdata.dma_ops = get_pci_dma_ops();
> - dev->archdata.dma_data = (void *)dma_direct_offset;
> + dev->archdata.dma_data = (void *)celleb_dma_direct_offset;
> }
>
> static void celleb_pci_dma_dev_setup(struct pci_dev *pdev)
^ permalink raw reply
* Re: [PATCH 6/7] Remove the global dma_direct_offset
From: Benjamin Herrenschmidt @ 2008-01-21 6:21 UTC (permalink / raw)
To: Michael Ellerman; +Cc: linuxppc-dev, Arnd Bergmann, cbe-oss-dev
In-Reply-To: <1e7b4eed15ca7723dd904b056d85b09873b70e8c.1200894155.git.michael@ellerman.id.au>
On Mon, 2008-01-21 at 16:42 +1100, Michael Ellerman wrote:
> We no longer need the global dma_direct_offset, update the comment to
> reflect the new reality.
>
> Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> ---
> arch/powerpc/kernel/dma_64.c | 7 ++++---
> include/asm-powerpc/dma-mapping.h | 2 --
> 2 files changed, 4 insertions(+), 5 deletions(-)
>
> diff --git a/arch/powerpc/kernel/dma_64.c b/arch/powerpc/kernel/dma_64.c
> index a2d076d..72fdc06 100644
> --- a/arch/powerpc/kernel/dma_64.c
> +++ b/arch/powerpc/kernel/dma_64.c
> @@ -112,10 +112,11 @@ EXPORT_SYMBOL(dma_iommu_ops);
> /*
> * Generic direct DMA implementation
> *
> - * This implementation supports a global offset that can be applied if
> - * the address at which memory is visible to devices is not 0.
> + * This implementation supports a per-device offset that can be applied if
> + * the address at which memory is visible to devices is not 0. Platform code
> + * can set archdata.dma_data to an unsigned long holding the offset. By
> + * default the offset is zero.
> */
> -unsigned long dma_direct_offset;
>
> static unsigned long get_dma_direct_offset(struct device *dev)
> {
> diff --git a/include/asm-powerpc/dma-mapping.h b/include/asm-powerpc/dma-mapping.h
> index e974876..5eea6db 100644
> --- a/include/asm-powerpc/dma-mapping.h
> +++ b/include/asm-powerpc/dma-mapping.h
> @@ -189,8 +189,6 @@ static inline void dma_unmap_sg(struct device *dev, struct scatterlist *sg,
> extern struct dma_mapping_ops dma_iommu_ops;
> extern struct dma_mapping_ops dma_direct_ops;
>
> -extern unsigned long dma_direct_offset;
> -
> #else /* CONFIG_PPC64 */
>
> #define dma_supported(dev, mask) (1)
^ permalink raw reply
* Re: [PATCH 7/7] Remove bogus comment in dma_direct_alloc_coherent()
From: Benjamin Herrenschmidt @ 2008-01-21 6:22 UTC (permalink / raw)
To: Michael Ellerman; +Cc: linuxppc-dev, Arnd Bergmann, cbe-oss-dev
In-Reply-To: <f62c2a7477a956c09fe9286922c350465a60dacd.1200894155.git.michael@ellerman.id.au>
On Mon, 2008-01-21 at 16:42 +1100, Michael Ellerman wrote:
> Since commit c80d9133e99de1af607314107910a2a1645efb17 (Make direct DMA use
> node local allocations) went in this comment makes no sense.
>
> Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> ---
> arch/powerpc/kernel/dma_64.c | 1 -
> 1 files changed, 0 insertions(+), 1 deletions(-)
>
> diff --git a/arch/powerpc/kernel/dma_64.c b/arch/powerpc/kernel/dma_64.c
> index 72fdc06..8423907 100644
> --- a/arch/powerpc/kernel/dma_64.c
> +++ b/arch/powerpc/kernel/dma_64.c
> @@ -130,7 +130,6 @@ static void *dma_direct_alloc_coherent(struct device *dev, size_t size,
> void *ret;
> int node = dev->archdata.numa_node;
>
> - /* TODO: Maybe use the numa node here too ? */
> page = alloc_pages_node(node, flag, get_order(size));
> if (page == NULL)
> return NULL;
^ permalink raw reply
* [PATCH] Make IOMMU code safe for > 132 GB of memory
From: Michael Ellerman @ 2008-01-21 7:01 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Arnd Bergmann, Jeremy Kerr
Currently the IOMMU code allocates one page for the segment table, that
isn't safe if we have more than 132 GB of RAM.
Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
---
arch/powerpc/platforms/cell/iommu.c | 7 ++++---
1 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/platforms/cell/iommu.c b/arch/powerpc/platforms/cell/iommu.c
index 7f45d59..eb2a94b 100644
--- a/arch/powerpc/platforms/cell/iommu.c
+++ b/arch/powerpc/platforms/cell/iommu.c
@@ -310,8 +310,8 @@ static void cell_iommu_setup_hardware(struct cbe_iommu *iommu, unsigned long siz
{
struct page *page;
int ret, i;
- unsigned long reg, segments, pages_per_segment, ptab_size, n_pte_pages;
- unsigned long xlate_base;
+ unsigned long reg, segments, pages_per_segment, ptab_size, stab_size,
+ n_pte_pages, xlate_base;
unsigned int virq;
if (cell_iommu_find_ioc(iommu->nid, &xlate_base))
@@ -328,7 +328,8 @@ static void cell_iommu_setup_hardware(struct cbe_iommu *iommu, unsigned long siz
__FUNCTION__, iommu->nid, segments, pages_per_segment);
/* set up the segment table */
- page = alloc_pages_node(iommu->nid, GFP_KERNEL, 0);
+ stab_size = segments * sizeof(unsigned long);
+ page = alloc_pages_node(iommu->nid, GFP_KERNEL, get_order(stab_size));
BUG_ON(!page);
iommu->stab = page_address(page);
clear_page(iommu->stab);
--
1.5.2.rc1.1884.g59b20
^ permalink raw reply related
* Re: Endian problem when accessing internel regs on 8347
From: Bruce_Leonard @ 2008-01-21 7:21 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-embedded
In-Reply-To: <478FD442.8060902@freescale.com>
> >>> __asm__ __volatile__("lwz%U1%X1 %0,%1; twi 0,%0,0; isync" : "=r"
(ret)
> > :
> >>> "m" (*addr));
> >> They allow the compiler to use update and/or index mode for the
memory
> >> operand.
> >
> > Well that makes sense, U for update and X for index, but I'm not sure
> > they're applicable to this particular instruction and I'm not sure
that
> > the memory operand makes sense for PowerPC.
>
> Why not?
Okay, after much digging and experimenting, I'll agree that the memory
operand makes sense. When I first said that I was thinking of direct
manipulation of memory, which the PPC doesn't support. (Don't ask, my
brain sometimes goes off into la-la land without me :-> ) Also, update
mode is applicable and makes sense. But I do still have a problem with
the index mode, though it could be compiler magic. Here's why: the index
mode of the 'lwz' instruction requires three operands, i.e., 'lwzx
rD,rA,rB', and there's only place holders for two operands. Is the
compiler smart enough to add the third operand for the index mode? If so,
what does it put for the third operand?
Another question is how does the compiler know which mode to pick? And
what is the significance of the trailing number? Some places in the code
have %U1%X1 and others have %U2%X2? I've found documentation for the #
and ## tokens, but I can't find anything for the %U or %X tokens.
Now this has all been very interesting to learn but doesn't solve my
underlying problem which I've finally drilled down to. At first I thought
in_be32() might be broken because I wasn't getting back the value I knew
to be in the internal register. I knew I had the address and the mapping
to kernel space correct because I could use in_le32 and get the right
value though it was byte swapped. The value in the register was
0xFFFFFFE7 but what I was getting from in_be32 was 0xFFFFFFFF. Then I
started playing and here's what I found:
Register value in_be32 value
0x12345678 0x1234567
0xff345678 0xff345678
0xffff5678 0xffff5678
0xfffff678 0xfffff678
0xfffffe78 0xffffffff
0xffffff78 0xffffffff
This isn't an exhastive list but I tried about twenty values and pretty
much what I found was that if bits 0 through 22 are set to 1 then in_be32
reads 0xffffffff. I've also tried it at a variety of addresses and the
behaviour is the same. in_le32 works fine as does in_be16. I've got no
ideas as to what may be wrong. I don't want to just arbitrarily point to
that %U1%X1 parameter list, but I get compiler errors if I try to remove
them so I can't prove or disprove it and I can't find any documentation on
it I can't even form a theroy. Has anyone ever seen anything like this?
Can't anyone suggest anything I can try?
^ permalink raw reply
* Re: [MPC5200] problem running FEC and ATA
From: Mehlan, Markus (Ritter Elektronik) @ 2008-01-21 7:10 UTC (permalink / raw)
To: linuxppc-dev
Hello all,
i have the same problem with the fec driver. See my posting
at
http://ozlabs.org/pipermail/linuxppc-embedded/2008-January/029466.html
Arnon, have you already fixed the FEC problem?
Thanks and regards,
Markus.
^ permalink raw reply
* Xilinx XPS_LL_TEMAC vs PLB_TEMAC
From: Mohammad Sadegh Sadri @ 2008-01-21 7:36 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 500 bytes --]
Hi All,
As you know Xilinx PLB TEMAC is a module which connects Hard TEMAC in Virtex-4 FX devices to PLB bus,
now, in the new release of EDK , EDK 9.2 Xilinx has added a new interface core , which is called XPS_LL_TEMAC and has a different structure than normal PLB TEMAC. spacially it has some additional data transfer buses.
Now the question is,... is there any linux driver available for this new core?
thanks
_________________________________________________________________
[-- Attachment #2: Type: text/html, Size: 679 bytes --]
^ permalink raw reply
* Re: Xilinx XPS_LL_TEMAC vs PLB_TEMAC
From: David Baird @ 2008-01-21 7:55 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <BAY115-W17ECE16AB6FA79B2D4DBBDB23D0@phx.gbl>
On Jan 21, 2008 12:36 AM, Mohammad Sadegh Sadri <mamsadegh@hotmail.com> wrote:
> As you know Xilinx PLB TEMAC is a module which connects Hard TEMAC in
> Virtex-4 FX devices to PLB bus,
> now, in the new release of EDK , EDK 9.2 Xilinx has added a new interface
> core , which is called XPS_LL_TEMAC and has a different structure than
> normal PLB TEMAC. spacially it has some additional data transfer buses.
>
> Now the question is,... is there any linux driver available for this new
> core?
Yes there is, but I had to use the git sources at:
git.xilinx.com
^ permalink raw reply
* RE: Xilinx XPS_LL_TEMAC vs PLB_TEMAC
From: Mohammad Sadegh Sadri @ 2008-01-21 8:54 UTC (permalink / raw)
To: David Baird, linuxppc-embedded
In-Reply-To: <440abda90801202354l5a0ce4caq382af5991e36f775@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1477 bytes --]
thanks for you reply david,
As far as I know the Linux driver for Xilinx PLB TEMAC was two parts : 1- adapter.c and 2- the rest of the driver files
Only adapter.c was really a linux related file and the rest of the files were Xilinx generic driver code for PLB TEMAC.
correct?
then now, I know EDK 9.2 generates the needed Linux support package and needed related files, so if this is the case can we use these files as the needed driver in our linux kernel?
by the way, i did never hear about this git repository before...can you describe us, where is it and how we can access it and which projects are now hosted by it?
thanks
> Date: Mon, 21 Jan 2008 00:54:30 -0700
> From: dhbaird@gmail.com
> To: mamsadegh@hotmail.com
> Subject: Re: Xilinx XPS_LL_TEMAC vs PLB_TEMAC
>
> On Jan 21, 2008 12:36 AM, Mohammad Sadegh Sadri <mamsadegh@hotmail.com> wrote:
> > As you know Xilinx PLB TEMAC is a module which connects Hard TEMAC in
> > Virtex-4 FX devices to PLB bus,
> > now, in the new release of EDK , EDK 9.2 Xilinx has added a new interface
> > core , which is called XPS_LL_TEMAC and has a different structure than
> > normal PLB TEMAC. spacially it has some additional data transfer buses.
> >
> > Now the question is,... is there any linux driver available for this new
> > core?
>
> Yes there is, but I had to use the git sources at:
>
> git.xilinx.com
_________________________________________________________________
[-- Attachment #2: Type: text/html, Size: 1790 bytes --]
^ permalink raw reply
* Re: [MPC5200] problem running FEC and ATA
From: Juergen Beisert @ 2008-01-21 8:57 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Mehlan, Markus (Ritter Elektronik)
In-Reply-To: <FACFFB02D783C64FB2CEF2D6825F6FC206EEF1BE@SRVEXC01.sts.saurer.vpn>
Markus,
On Monday 21 January 2008 08:10, Mehlan, Markus (Ritter Elektronik) wrote:
> i have the same problem with the fec driver. See my posting
> at
> http://ozlabs.org/pipermail/linuxppc-embedded/2008-January/029466.html
>
> Arnon, have you already fixed the FEC problem?
Can you check this?
http://ozlabs.org/pipermail/linuxppc-embedded/2007-May/027046.html
Regards,
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
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