2006-06-23 16:44:10 +08:00
|
|
|
#include <linux/string.h>
|
|
|
|
#include <linux/kernel.h>
|
2007-05-01 14:40:36 +08:00
|
|
|
#include <linux/of.h>
|
2006-06-23 16:44:10 +08:00
|
|
|
#include <linux/init.h>
|
|
|
|
#include <linux/module.h>
|
|
|
|
#include <linux/mod_devicetable.h>
|
|
|
|
#include <linux/slab.h>
|
2007-05-03 00:38:57 +08:00
|
|
|
#include <linux/errno.h>
|
2008-03-19 19:52:48 +08:00
|
|
|
#include <linux/irq.h>
|
2007-05-03 00:38:57 +08:00
|
|
|
#include <linux/of_device.h>
|
|
|
|
#include <linux/of_platform.h>
|
2011-08-02 01:42:48 +08:00
|
|
|
#include <asm/spitfire.h>
|
2006-06-23 16:44:10 +08:00
|
|
|
|
2009-06-04 17:00:02 +08:00
|
|
|
#include "of_device_common.h"
|
|
|
|
|
2006-06-30 05:35:33 +08:00
|
|
|
void __iomem *of_ioremap(struct resource *res, unsigned long offset, unsigned long size, char *name)
|
|
|
|
{
|
|
|
|
unsigned long ret = res->start + offset;
|
2006-10-19 14:00:35 +08:00
|
|
|
struct resource *r;
|
2006-06-30 05:35:33 +08:00
|
|
|
|
2006-10-19 14:00:35 +08:00
|
|
|
if (res->flags & IORESOURCE_MEM)
|
|
|
|
r = request_mem_region(ret, size, name);
|
|
|
|
else
|
|
|
|
r = request_region(ret, size, name);
|
|
|
|
if (!r)
|
2006-06-30 05:35:33 +08:00
|
|
|
ret = 0;
|
|
|
|
|
|
|
|
return (void __iomem *) ret;
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(of_ioremap);
|
|
|
|
|
2006-12-29 13:01:32 +08:00
|
|
|
void of_iounmap(struct resource *res, void __iomem *base, unsigned long size)
|
2006-06-30 05:35:33 +08:00
|
|
|
{
|
2006-12-29 13:01:32 +08:00
|
|
|
if (res->flags & IORESOURCE_MEM)
|
|
|
|
release_mem_region((unsigned long) base, size);
|
|
|
|
else
|
|
|
|
release_region((unsigned long) base, size);
|
2006-06-30 05:35:33 +08:00
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(of_iounmap);
|
|
|
|
|
2006-06-30 05:34:50 +08:00
|
|
|
/*
|
|
|
|
* PCI bus specific translator
|
|
|
|
*/
|
|
|
|
|
|
|
|
static int of_bus_pci_match(struct device_node *np)
|
|
|
|
{
|
2008-09-21 13:00:40 +08:00
|
|
|
if (!strcmp(np->name, "pci")) {
|
2007-03-29 16:50:16 +08:00
|
|
|
const char *model = of_get_property(np, "model", NULL);
|
2007-03-05 04:53:19 +08:00
|
|
|
|
|
|
|
if (model && !strcmp(model, "SUNW,simba"))
|
|
|
|
return 0;
|
|
|
|
|
[SPARC]: Fix OF register translations under sub-PCI busses.
There is an implicit assumption in the code that ranges will translate
to something that can fit in 2 32-bit cells, or a 64-bit value. For
certain kinds of things below PCI this isn't necessarily true.
Here is what the relevant OF device hierarchy looks like for one of
the serial controllers on an Ultra5:
Node 0xf005f1e0
ranges: 00000000.00000000.00000000.000001fe.01000000.00000000.01000000
01000000.00000000.00000000.000001fe.02000000.00000000.01000000
02000000.00000000.00000000.000001ff.00000000.00000001.00000000
03000000.00000000.00000000.000001ff.00000000.00000001.00000000
device_type: 'pci'
model: 'SUNW,sabre'
Node 0xf005f9d4
device_type: 'pci'
model: 'SUNW,simba'
Node 0xf0060d24
ranges: 00000010.00000000 82010810.00000000.f0000000 01000000
00000014.00000000 82010814.00000000.f1000000 00800000
name: 'ebus'
Node 0xf0062dac
reg: 00000014.003083f8.00000008 --> 0x1ff.f13083f8
device_type: 'serial'
name: 'su'
So the correct translation here is:
1) Match "su" register to second ranges entry of 'ebus', which translates
into a PCI triplet "82010814.00000000.f1000000" of size 00800000, which
gives us "82010814.00000000.f13083f8".
2) Pass-through "SUNW,simba" since it lacks ranges property
3) Match "82010814.00000000.f13083f8" to third ranges property of PCI
controller node 'SUNW,sabre', and we arrive at the final physical
MMIO address of "0x1fff13083f8".
Due to the 2-cell assumption, we couldn't translate to a PCI 3-cell
value, and we couldn't perform a pass-thru on it either.
It was easiest to just stop splitting the ranges application operation
between two methods, ->map and ->translate, and just let ->map do all
the work. That way it would work purely on 32-bit cell arrays instead
of having to "return" some value like a u64.
It's still not %100 correct because the out-of-range check is still
done using the 64 least significant bits of the range and address.
But it does work for all the cases I've thrown at it so far.
Signed-off-by: David S. Miller <davem@davemloft.net>
2006-07-13 14:19:31 +08:00
|
|
|
/* Do not do PCI specific frobbing if the
|
|
|
|
* PCI bridge lacks a ranges property. We
|
|
|
|
* want to pass it through up to the next
|
|
|
|
* parent as-is, not with the PCI translate
|
|
|
|
* method which chops off the top address cell.
|
|
|
|
*/
|
|
|
|
if (!of_find_property(np, "ranges", NULL))
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
|
|
|
|
return 0;
|
2006-06-30 05:34:50 +08:00
|
|
|
}
|
|
|
|
|
2007-03-05 04:53:19 +08:00
|
|
|
static int of_bus_simba_match(struct device_node *np)
|
|
|
|
{
|
2007-03-29 16:50:16 +08:00
|
|
|
const char *model = of_get_property(np, "model", NULL);
|
2007-03-05 04:53:19 +08:00
|
|
|
|
|
|
|
if (model && !strcmp(model, "SUNW,simba"))
|
|
|
|
return 1;
|
2007-06-08 12:59:44 +08:00
|
|
|
|
|
|
|
/* Treat PCI busses lacking ranges property just like
|
|
|
|
* simba.
|
|
|
|
*/
|
2008-09-21 13:00:40 +08:00
|
|
|
if (!strcmp(np->name, "pci")) {
|
2007-06-08 12:59:44 +08:00
|
|
|
if (!of_find_property(np, "ranges", NULL))
|
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
|
2007-03-05 04:53:19 +08:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int of_bus_simba_map(u32 *addr, const u32 *range,
|
|
|
|
int na, int ns, int pna)
|
|
|
|
{
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2006-06-30 05:34:50 +08:00
|
|
|
static void of_bus_pci_count_cells(struct device_node *np,
|
|
|
|
int *addrc, int *sizec)
|
|
|
|
{
|
|
|
|
if (addrc)
|
|
|
|
*addrc = 3;
|
|
|
|
if (sizec)
|
|
|
|
*sizec = 2;
|
|
|
|
}
|
|
|
|
|
[SPARC]: Fix OF register translations under sub-PCI busses.
There is an implicit assumption in the code that ranges will translate
to something that can fit in 2 32-bit cells, or a 64-bit value. For
certain kinds of things below PCI this isn't necessarily true.
Here is what the relevant OF device hierarchy looks like for one of
the serial controllers on an Ultra5:
Node 0xf005f1e0
ranges: 00000000.00000000.00000000.000001fe.01000000.00000000.01000000
01000000.00000000.00000000.000001fe.02000000.00000000.01000000
02000000.00000000.00000000.000001ff.00000000.00000001.00000000
03000000.00000000.00000000.000001ff.00000000.00000001.00000000
device_type: 'pci'
model: 'SUNW,sabre'
Node 0xf005f9d4
device_type: 'pci'
model: 'SUNW,simba'
Node 0xf0060d24
ranges: 00000010.00000000 82010810.00000000.f0000000 01000000
00000014.00000000 82010814.00000000.f1000000 00800000
name: 'ebus'
Node 0xf0062dac
reg: 00000014.003083f8.00000008 --> 0x1ff.f13083f8
device_type: 'serial'
name: 'su'
So the correct translation here is:
1) Match "su" register to second ranges entry of 'ebus', which translates
into a PCI triplet "82010814.00000000.f1000000" of size 00800000, which
gives us "82010814.00000000.f13083f8".
2) Pass-through "SUNW,simba" since it lacks ranges property
3) Match "82010814.00000000.f13083f8" to third ranges property of PCI
controller node 'SUNW,sabre', and we arrive at the final physical
MMIO address of "0x1fff13083f8".
Due to the 2-cell assumption, we couldn't translate to a PCI 3-cell
value, and we couldn't perform a pass-thru on it either.
It was easiest to just stop splitting the ranges application operation
between two methods, ->map and ->translate, and just let ->map do all
the work. That way it would work purely on 32-bit cell arrays instead
of having to "return" some value like a u64.
It's still not %100 correct because the out-of-range check is still
done using the 64 least significant bits of the range and address.
But it does work for all the cases I've thrown at it so far.
Signed-off-by: David S. Miller <davem@davemloft.net>
2006-07-13 14:19:31 +08:00
|
|
|
static int of_bus_pci_map(u32 *addr, const u32 *range,
|
|
|
|
int na, int ns, int pna)
|
2006-06-30 05:34:50 +08:00
|
|
|
{
|
[SPARC]: Fix OF register translations under sub-PCI busses.
There is an implicit assumption in the code that ranges will translate
to something that can fit in 2 32-bit cells, or a 64-bit value. For
certain kinds of things below PCI this isn't necessarily true.
Here is what the relevant OF device hierarchy looks like for one of
the serial controllers on an Ultra5:
Node 0xf005f1e0
ranges: 00000000.00000000.00000000.000001fe.01000000.00000000.01000000
01000000.00000000.00000000.000001fe.02000000.00000000.01000000
02000000.00000000.00000000.000001ff.00000000.00000001.00000000
03000000.00000000.00000000.000001ff.00000000.00000001.00000000
device_type: 'pci'
model: 'SUNW,sabre'
Node 0xf005f9d4
device_type: 'pci'
model: 'SUNW,simba'
Node 0xf0060d24
ranges: 00000010.00000000 82010810.00000000.f0000000 01000000
00000014.00000000 82010814.00000000.f1000000 00800000
name: 'ebus'
Node 0xf0062dac
reg: 00000014.003083f8.00000008 --> 0x1ff.f13083f8
device_type: 'serial'
name: 'su'
So the correct translation here is:
1) Match "su" register to second ranges entry of 'ebus', which translates
into a PCI triplet "82010814.00000000.f1000000" of size 00800000, which
gives us "82010814.00000000.f13083f8".
2) Pass-through "SUNW,simba" since it lacks ranges property
3) Match "82010814.00000000.f13083f8" to third ranges property of PCI
controller node 'SUNW,sabre', and we arrive at the final physical
MMIO address of "0x1fff13083f8".
Due to the 2-cell assumption, we couldn't translate to a PCI 3-cell
value, and we couldn't perform a pass-thru on it either.
It was easiest to just stop splitting the ranges application operation
between two methods, ->map and ->translate, and just let ->map do all
the work. That way it would work purely on 32-bit cell arrays instead
of having to "return" some value like a u64.
It's still not %100 correct because the out-of-range check is still
done using the 64 least significant bits of the range and address.
But it does work for all the cases I've thrown at it so far.
Signed-off-by: David S. Miller <davem@davemloft.net>
2006-07-13 14:19:31 +08:00
|
|
|
u32 result[OF_MAX_ADDR_CELLS];
|
|
|
|
int i;
|
2006-06-30 05:34:50 +08:00
|
|
|
|
|
|
|
/* Check address type match */
|
2009-12-09 17:39:09 +08:00
|
|
|
if (!((addr[0] ^ range[0]) & 0x03000000))
|
|
|
|
goto type_match;
|
|
|
|
|
|
|
|
/* Special exception, we can map a 64-bit address into
|
|
|
|
* a 32-bit range.
|
|
|
|
*/
|
|
|
|
if ((addr[0] & 0x03000000) == 0x03000000 &&
|
|
|
|
(range[0] & 0x03000000) == 0x02000000)
|
|
|
|
goto type_match;
|
|
|
|
|
|
|
|
return -EINVAL;
|
2006-06-30 05:34:50 +08:00
|
|
|
|
2009-12-09 17:39:09 +08:00
|
|
|
type_match:
|
[SPARC]: Fix OF register translations under sub-PCI busses.
There is an implicit assumption in the code that ranges will translate
to something that can fit in 2 32-bit cells, or a 64-bit value. For
certain kinds of things below PCI this isn't necessarily true.
Here is what the relevant OF device hierarchy looks like for one of
the serial controllers on an Ultra5:
Node 0xf005f1e0
ranges: 00000000.00000000.00000000.000001fe.01000000.00000000.01000000
01000000.00000000.00000000.000001fe.02000000.00000000.01000000
02000000.00000000.00000000.000001ff.00000000.00000001.00000000
03000000.00000000.00000000.000001ff.00000000.00000001.00000000
device_type: 'pci'
model: 'SUNW,sabre'
Node 0xf005f9d4
device_type: 'pci'
model: 'SUNW,simba'
Node 0xf0060d24
ranges: 00000010.00000000 82010810.00000000.f0000000 01000000
00000014.00000000 82010814.00000000.f1000000 00800000
name: 'ebus'
Node 0xf0062dac
reg: 00000014.003083f8.00000008 --> 0x1ff.f13083f8
device_type: 'serial'
name: 'su'
So the correct translation here is:
1) Match "su" register to second ranges entry of 'ebus', which translates
into a PCI triplet "82010814.00000000.f1000000" of size 00800000, which
gives us "82010814.00000000.f13083f8".
2) Pass-through "SUNW,simba" since it lacks ranges property
3) Match "82010814.00000000.f13083f8" to third ranges property of PCI
controller node 'SUNW,sabre', and we arrive at the final physical
MMIO address of "0x1fff13083f8".
Due to the 2-cell assumption, we couldn't translate to a PCI 3-cell
value, and we couldn't perform a pass-thru on it either.
It was easiest to just stop splitting the ranges application operation
between two methods, ->map and ->translate, and just let ->map do all
the work. That way it would work purely on 32-bit cell arrays instead
of having to "return" some value like a u64.
It's still not %100 correct because the out-of-range check is still
done using the 64 least significant bits of the range and address.
But it does work for all the cases I've thrown at it so far.
Signed-off-by: David S. Miller <davem@davemloft.net>
2006-07-13 14:19:31 +08:00
|
|
|
if (of_out_of_range(addr + 1, range + 1, range + na + pna,
|
|
|
|
na - 1, ns))
|
|
|
|
return -EINVAL;
|
2006-06-30 05:34:50 +08:00
|
|
|
|
[SPARC]: Fix OF register translations under sub-PCI busses.
There is an implicit assumption in the code that ranges will translate
to something that can fit in 2 32-bit cells, or a 64-bit value. For
certain kinds of things below PCI this isn't necessarily true.
Here is what the relevant OF device hierarchy looks like for one of
the serial controllers on an Ultra5:
Node 0xf005f1e0
ranges: 00000000.00000000.00000000.000001fe.01000000.00000000.01000000
01000000.00000000.00000000.000001fe.02000000.00000000.01000000
02000000.00000000.00000000.000001ff.00000000.00000001.00000000
03000000.00000000.00000000.000001ff.00000000.00000001.00000000
device_type: 'pci'
model: 'SUNW,sabre'
Node 0xf005f9d4
device_type: 'pci'
model: 'SUNW,simba'
Node 0xf0060d24
ranges: 00000010.00000000 82010810.00000000.f0000000 01000000
00000014.00000000 82010814.00000000.f1000000 00800000
name: 'ebus'
Node 0xf0062dac
reg: 00000014.003083f8.00000008 --> 0x1ff.f13083f8
device_type: 'serial'
name: 'su'
So the correct translation here is:
1) Match "su" register to second ranges entry of 'ebus', which translates
into a PCI triplet "82010814.00000000.f1000000" of size 00800000, which
gives us "82010814.00000000.f13083f8".
2) Pass-through "SUNW,simba" since it lacks ranges property
3) Match "82010814.00000000.f13083f8" to third ranges property of PCI
controller node 'SUNW,sabre', and we arrive at the final physical
MMIO address of "0x1fff13083f8".
Due to the 2-cell assumption, we couldn't translate to a PCI 3-cell
value, and we couldn't perform a pass-thru on it either.
It was easiest to just stop splitting the ranges application operation
between two methods, ->map and ->translate, and just let ->map do all
the work. That way it would work purely on 32-bit cell arrays instead
of having to "return" some value like a u64.
It's still not %100 correct because the out-of-range check is still
done using the 64 least significant bits of the range and address.
But it does work for all the cases I've thrown at it so far.
Signed-off-by: David S. Miller <davem@davemloft.net>
2006-07-13 14:19:31 +08:00
|
|
|
/* Start with the parent range base. */
|
|
|
|
memcpy(result, range + na, pna * 4);
|
2006-06-30 05:34:50 +08:00
|
|
|
|
[SPARC]: Fix OF register translations under sub-PCI busses.
There is an implicit assumption in the code that ranges will translate
to something that can fit in 2 32-bit cells, or a 64-bit value. For
certain kinds of things below PCI this isn't necessarily true.
Here is what the relevant OF device hierarchy looks like for one of
the serial controllers on an Ultra5:
Node 0xf005f1e0
ranges: 00000000.00000000.00000000.000001fe.01000000.00000000.01000000
01000000.00000000.00000000.000001fe.02000000.00000000.01000000
02000000.00000000.00000000.000001ff.00000000.00000001.00000000
03000000.00000000.00000000.000001ff.00000000.00000001.00000000
device_type: 'pci'
model: 'SUNW,sabre'
Node 0xf005f9d4
device_type: 'pci'
model: 'SUNW,simba'
Node 0xf0060d24
ranges: 00000010.00000000 82010810.00000000.f0000000 01000000
00000014.00000000 82010814.00000000.f1000000 00800000
name: 'ebus'
Node 0xf0062dac
reg: 00000014.003083f8.00000008 --> 0x1ff.f13083f8
device_type: 'serial'
name: 'su'
So the correct translation here is:
1) Match "su" register to second ranges entry of 'ebus', which translates
into a PCI triplet "82010814.00000000.f1000000" of size 00800000, which
gives us "82010814.00000000.f13083f8".
2) Pass-through "SUNW,simba" since it lacks ranges property
3) Match "82010814.00000000.f13083f8" to third ranges property of PCI
controller node 'SUNW,sabre', and we arrive at the final physical
MMIO address of "0x1fff13083f8".
Due to the 2-cell assumption, we couldn't translate to a PCI 3-cell
value, and we couldn't perform a pass-thru on it either.
It was easiest to just stop splitting the ranges application operation
between two methods, ->map and ->translate, and just let ->map do all
the work. That way it would work purely on 32-bit cell arrays instead
of having to "return" some value like a u64.
It's still not %100 correct because the out-of-range check is still
done using the 64 least significant bits of the range and address.
But it does work for all the cases I've thrown at it so far.
Signed-off-by: David S. Miller <davem@davemloft.net>
2006-07-13 14:19:31 +08:00
|
|
|
/* Add in the child address offset, skipping high cell. */
|
|
|
|
for (i = 0; i < na - 1; i++)
|
|
|
|
result[pna - 1 - i] +=
|
|
|
|
(addr[na - 1 - i] -
|
|
|
|
range[na - 1 - i]);
|
|
|
|
|
|
|
|
memcpy(addr, result, pna * 4);
|
|
|
|
|
|
|
|
return 0;
|
2006-06-30 05:34:50 +08:00
|
|
|
}
|
|
|
|
|
2008-08-29 12:02:58 +08:00
|
|
|
static unsigned long of_bus_pci_get_flags(const u32 *addr, unsigned long flags)
|
2006-06-30 05:34:50 +08:00
|
|
|
{
|
|
|
|
u32 w = addr[0];
|
|
|
|
|
2008-08-29 12:02:58 +08:00
|
|
|
/* For PCI, we override whatever child busses may have used. */
|
|
|
|
flags = 0;
|
2006-06-30 05:34:50 +08:00
|
|
|
switch((w >> 24) & 0x03) {
|
|
|
|
case 0x01:
|
|
|
|
flags |= IORESOURCE_IO;
|
2008-08-29 12:02:58 +08:00
|
|
|
break;
|
|
|
|
|
2006-06-30 05:34:50 +08:00
|
|
|
case 0x02: /* 32 bits */
|
|
|
|
case 0x03: /* 64 bits */
|
|
|
|
flags |= IORESOURCE_MEM;
|
2008-08-29 12:02:58 +08:00
|
|
|
break;
|
2006-06-30 05:34:50 +08:00
|
|
|
}
|
|
|
|
if (w & 0x40000000)
|
|
|
|
flags |= IORESOURCE_PREFETCH;
|
|
|
|
return flags;
|
|
|
|
}
|
|
|
|
|
2006-10-26 13:31:06 +08:00
|
|
|
/*
|
|
|
|
* FHC/Central bus specific translator.
|
|
|
|
*
|
|
|
|
* This is just needed to hard-code the address and size cell
|
|
|
|
* counts. 'fhc' and 'central' nodes lack the #address-cells and
|
|
|
|
* #size-cells properties, and if you walk to the root on such
|
|
|
|
* Enterprise boxes all you'll get is a #size-cells of 2 which is
|
|
|
|
* not what we want to use.
|
|
|
|
*/
|
|
|
|
static int of_bus_fhc_match(struct device_node *np)
|
2006-06-30 05:34:50 +08:00
|
|
|
{
|
2006-10-26 13:31:06 +08:00
|
|
|
return !strcmp(np->name, "fhc") ||
|
|
|
|
!strcmp(np->name, "central");
|
2006-06-30 05:34:50 +08:00
|
|
|
}
|
|
|
|
|
2006-10-26 13:31:06 +08:00
|
|
|
#define of_bus_fhc_count_cells of_bus_sbus_count_cells
|
2006-06-30 05:34:50 +08:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Array of bus specific translators
|
|
|
|
*/
|
|
|
|
|
|
|
|
static struct of_bus of_busses[] = {
|
|
|
|
/* PCI */
|
|
|
|
{
|
|
|
|
.name = "pci",
|
|
|
|
.addr_prop_name = "assigned-addresses",
|
|
|
|
.match = of_bus_pci_match,
|
|
|
|
.count_cells = of_bus_pci_count_cells,
|
|
|
|
.map = of_bus_pci_map,
|
|
|
|
.get_flags = of_bus_pci_get_flags,
|
|
|
|
},
|
2007-03-05 04:53:19 +08:00
|
|
|
/* SIMBA */
|
|
|
|
{
|
|
|
|
.name = "simba",
|
|
|
|
.addr_prop_name = "assigned-addresses",
|
|
|
|
.match = of_bus_simba_match,
|
|
|
|
.count_cells = of_bus_pci_count_cells,
|
|
|
|
.map = of_bus_simba_map,
|
|
|
|
.get_flags = of_bus_pci_get_flags,
|
|
|
|
},
|
2006-06-30 05:34:50 +08:00
|
|
|
/* SBUS */
|
|
|
|
{
|
|
|
|
.name = "sbus",
|
|
|
|
.addr_prop_name = "reg",
|
|
|
|
.match = of_bus_sbus_match,
|
|
|
|
.count_cells = of_bus_sbus_count_cells,
|
2006-10-26 13:31:06 +08:00
|
|
|
.map = of_bus_default_map,
|
|
|
|
.get_flags = of_bus_default_get_flags,
|
|
|
|
},
|
|
|
|
/* FHC */
|
|
|
|
{
|
|
|
|
.name = "fhc",
|
|
|
|
.addr_prop_name = "reg",
|
|
|
|
.match = of_bus_fhc_match,
|
|
|
|
.count_cells = of_bus_fhc_count_cells,
|
|
|
|
.map = of_bus_default_map,
|
|
|
|
.get_flags = of_bus_default_get_flags,
|
2006-06-30 05:34:50 +08:00
|
|
|
},
|
|
|
|
/* Default */
|
|
|
|
{
|
|
|
|
.name = "default",
|
|
|
|
.addr_prop_name = "reg",
|
|
|
|
.match = NULL,
|
|
|
|
.count_cells = of_bus_default_count_cells,
|
|
|
|
.map = of_bus_default_map,
|
|
|
|
.get_flags = of_bus_default_get_flags,
|
|
|
|
},
|
|
|
|
};
|
|
|
|
|
|
|
|
static struct of_bus *of_match_bus(struct device_node *np)
|
|
|
|
{
|
|
|
|
int i;
|
|
|
|
|
|
|
|
for (i = 0; i < ARRAY_SIZE(of_busses); i ++)
|
|
|
|
if (!of_busses[i].match || of_busses[i].match(np))
|
|
|
|
return &of_busses[i];
|
|
|
|
BUG();
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int __init build_one_resource(struct device_node *parent,
|
|
|
|
struct of_bus *bus,
|
|
|
|
struct of_bus *pbus,
|
|
|
|
u32 *addr,
|
|
|
|
int na, int ns, int pna)
|
|
|
|
{
|
2007-04-24 06:53:27 +08:00
|
|
|
const u32 *ranges;
|
2008-09-12 14:53:41 +08:00
|
|
|
int rone, rlen;
|
2006-06-30 05:34:50 +08:00
|
|
|
|
|
|
|
ranges = of_get_property(parent, "ranges", &rlen);
|
|
|
|
if (ranges == NULL || rlen == 0) {
|
[SPARC]: Fix OF register translations under sub-PCI busses.
There is an implicit assumption in the code that ranges will translate
to something that can fit in 2 32-bit cells, or a 64-bit value. For
certain kinds of things below PCI this isn't necessarily true.
Here is what the relevant OF device hierarchy looks like for one of
the serial controllers on an Ultra5:
Node 0xf005f1e0
ranges: 00000000.00000000.00000000.000001fe.01000000.00000000.01000000
01000000.00000000.00000000.000001fe.02000000.00000000.01000000
02000000.00000000.00000000.000001ff.00000000.00000001.00000000
03000000.00000000.00000000.000001ff.00000000.00000001.00000000
device_type: 'pci'
model: 'SUNW,sabre'
Node 0xf005f9d4
device_type: 'pci'
model: 'SUNW,simba'
Node 0xf0060d24
ranges: 00000010.00000000 82010810.00000000.f0000000 01000000
00000014.00000000 82010814.00000000.f1000000 00800000
name: 'ebus'
Node 0xf0062dac
reg: 00000014.003083f8.00000008 --> 0x1ff.f13083f8
device_type: 'serial'
name: 'su'
So the correct translation here is:
1) Match "su" register to second ranges entry of 'ebus', which translates
into a PCI triplet "82010814.00000000.f1000000" of size 00800000, which
gives us "82010814.00000000.f13083f8".
2) Pass-through "SUNW,simba" since it lacks ranges property
3) Match "82010814.00000000.f13083f8" to third ranges property of PCI
controller node 'SUNW,sabre', and we arrive at the final physical
MMIO address of "0x1fff13083f8".
Due to the 2-cell assumption, we couldn't translate to a PCI 3-cell
value, and we couldn't perform a pass-thru on it either.
It was easiest to just stop splitting the ranges application operation
between two methods, ->map and ->translate, and just let ->map do all
the work. That way it would work purely on 32-bit cell arrays instead
of having to "return" some value like a u64.
It's still not %100 correct because the out-of-range check is still
done using the 64 least significant bits of the range and address.
But it does work for all the cases I've thrown at it so far.
Signed-off-by: David S. Miller <davem@davemloft.net>
2006-07-13 14:19:31 +08:00
|
|
|
u32 result[OF_MAX_ADDR_CELLS];
|
|
|
|
int i;
|
|
|
|
|
|
|
|
memset(result, 0, pna * 4);
|
|
|
|
for (i = 0; i < na; i++)
|
|
|
|
result[pna - 1 - i] =
|
|
|
|
addr[na - 1 - i];
|
|
|
|
|
|
|
|
memcpy(addr, result, pna * 4);
|
|
|
|
return 0;
|
2006-06-30 05:34:50 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
/* Now walk through the ranges */
|
|
|
|
rlen /= 4;
|
|
|
|
rone = na + pna + ns;
|
|
|
|
for (; rlen >= rone; rlen -= rone, ranges += rone) {
|
[SPARC]: Fix OF register translations under sub-PCI busses.
There is an implicit assumption in the code that ranges will translate
to something that can fit in 2 32-bit cells, or a 64-bit value. For
certain kinds of things below PCI this isn't necessarily true.
Here is what the relevant OF device hierarchy looks like for one of
the serial controllers on an Ultra5:
Node 0xf005f1e0
ranges: 00000000.00000000.00000000.000001fe.01000000.00000000.01000000
01000000.00000000.00000000.000001fe.02000000.00000000.01000000
02000000.00000000.00000000.000001ff.00000000.00000001.00000000
03000000.00000000.00000000.000001ff.00000000.00000001.00000000
device_type: 'pci'
model: 'SUNW,sabre'
Node 0xf005f9d4
device_type: 'pci'
model: 'SUNW,simba'
Node 0xf0060d24
ranges: 00000010.00000000 82010810.00000000.f0000000 01000000
00000014.00000000 82010814.00000000.f1000000 00800000
name: 'ebus'
Node 0xf0062dac
reg: 00000014.003083f8.00000008 --> 0x1ff.f13083f8
device_type: 'serial'
name: 'su'
So the correct translation here is:
1) Match "su" register to second ranges entry of 'ebus', which translates
into a PCI triplet "82010814.00000000.f1000000" of size 00800000, which
gives us "82010814.00000000.f13083f8".
2) Pass-through "SUNW,simba" since it lacks ranges property
3) Match "82010814.00000000.f13083f8" to third ranges property of PCI
controller node 'SUNW,sabre', and we arrive at the final physical
MMIO address of "0x1fff13083f8".
Due to the 2-cell assumption, we couldn't translate to a PCI 3-cell
value, and we couldn't perform a pass-thru on it either.
It was easiest to just stop splitting the ranges application operation
between two methods, ->map and ->translate, and just let ->map do all
the work. That way it would work purely on 32-bit cell arrays instead
of having to "return" some value like a u64.
It's still not %100 correct because the out-of-range check is still
done using the 64 least significant bits of the range and address.
But it does work for all the cases I've thrown at it so far.
Signed-off-by: David S. Miller <davem@davemloft.net>
2006-07-13 14:19:31 +08:00
|
|
|
if (!bus->map(addr, ranges, na, ns, pna))
|
|
|
|
return 0;
|
2006-06-30 05:34:50 +08:00
|
|
|
}
|
[SPARC]: Fix OF register translations under sub-PCI busses.
There is an implicit assumption in the code that ranges will translate
to something that can fit in 2 32-bit cells, or a 64-bit value. For
certain kinds of things below PCI this isn't necessarily true.
Here is what the relevant OF device hierarchy looks like for one of
the serial controllers on an Ultra5:
Node 0xf005f1e0
ranges: 00000000.00000000.00000000.000001fe.01000000.00000000.01000000
01000000.00000000.00000000.000001fe.02000000.00000000.01000000
02000000.00000000.00000000.000001ff.00000000.00000001.00000000
03000000.00000000.00000000.000001ff.00000000.00000001.00000000
device_type: 'pci'
model: 'SUNW,sabre'
Node 0xf005f9d4
device_type: 'pci'
model: 'SUNW,simba'
Node 0xf0060d24
ranges: 00000010.00000000 82010810.00000000.f0000000 01000000
00000014.00000000 82010814.00000000.f1000000 00800000
name: 'ebus'
Node 0xf0062dac
reg: 00000014.003083f8.00000008 --> 0x1ff.f13083f8
device_type: 'serial'
name: 'su'
So the correct translation here is:
1) Match "su" register to second ranges entry of 'ebus', which translates
into a PCI triplet "82010814.00000000.f1000000" of size 00800000, which
gives us "82010814.00000000.f13083f8".
2) Pass-through "SUNW,simba" since it lacks ranges property
3) Match "82010814.00000000.f13083f8" to third ranges property of PCI
controller node 'SUNW,sabre', and we arrive at the final physical
MMIO address of "0x1fff13083f8".
Due to the 2-cell assumption, we couldn't translate to a PCI 3-cell
value, and we couldn't perform a pass-thru on it either.
It was easiest to just stop splitting the ranges application operation
between two methods, ->map and ->translate, and just let ->map do all
the work. That way it would work purely on 32-bit cell arrays instead
of having to "return" some value like a u64.
It's still not %100 correct because the out-of-range check is still
done using the 64 least significant bits of the range and address.
But it does work for all the cases I've thrown at it so far.
Signed-off-by: David S. Miller <davem@davemloft.net>
2006-07-13 14:19:31 +08:00
|
|
|
|
2007-05-14 13:01:18 +08:00
|
|
|
/* When we miss an I/O space match on PCI, just pass it up
|
|
|
|
* to the next PCI bridge and/or controller.
|
|
|
|
*/
|
|
|
|
if (!strcmp(bus->name, "pci") &&
|
|
|
|
(addr[0] & 0x03000000) == 0x01000000)
|
|
|
|
return 0;
|
|
|
|
|
[SPARC]: Fix OF register translations under sub-PCI busses.
There is an implicit assumption in the code that ranges will translate
to something that can fit in 2 32-bit cells, or a 64-bit value. For
certain kinds of things below PCI this isn't necessarily true.
Here is what the relevant OF device hierarchy looks like for one of
the serial controllers on an Ultra5:
Node 0xf005f1e0
ranges: 00000000.00000000.00000000.000001fe.01000000.00000000.01000000
01000000.00000000.00000000.000001fe.02000000.00000000.01000000
02000000.00000000.00000000.000001ff.00000000.00000001.00000000
03000000.00000000.00000000.000001ff.00000000.00000001.00000000
device_type: 'pci'
model: 'SUNW,sabre'
Node 0xf005f9d4
device_type: 'pci'
model: 'SUNW,simba'
Node 0xf0060d24
ranges: 00000010.00000000 82010810.00000000.f0000000 01000000
00000014.00000000 82010814.00000000.f1000000 00800000
name: 'ebus'
Node 0xf0062dac
reg: 00000014.003083f8.00000008 --> 0x1ff.f13083f8
device_type: 'serial'
name: 'su'
So the correct translation here is:
1) Match "su" register to second ranges entry of 'ebus', which translates
into a PCI triplet "82010814.00000000.f1000000" of size 00800000, which
gives us "82010814.00000000.f13083f8".
2) Pass-through "SUNW,simba" since it lacks ranges property
3) Match "82010814.00000000.f13083f8" to third ranges property of PCI
controller node 'SUNW,sabre', and we arrive at the final physical
MMIO address of "0x1fff13083f8".
Due to the 2-cell assumption, we couldn't translate to a PCI 3-cell
value, and we couldn't perform a pass-thru on it either.
It was easiest to just stop splitting the ranges application operation
between two methods, ->map and ->translate, and just let ->map do all
the work. That way it would work purely on 32-bit cell arrays instead
of having to "return" some value like a u64.
It's still not %100 correct because the out-of-range check is still
done using the 64 least significant bits of the range and address.
But it does work for all the cases I've thrown at it so far.
Signed-off-by: David S. Miller <davem@davemloft.net>
2006-07-13 14:19:31 +08:00
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int __init use_1to1_mapping(struct device_node *pp)
|
|
|
|
{
|
|
|
|
/* If we have a ranges property in the parent, use it. */
|
|
|
|
if (of_find_property(pp, "ranges", NULL) != NULL)
|
|
|
|
return 0;
|
2006-06-30 05:34:50 +08:00
|
|
|
|
[SPARC]: Fix OF register translations under sub-PCI busses.
There is an implicit assumption in the code that ranges will translate
to something that can fit in 2 32-bit cells, or a 64-bit value. For
certain kinds of things below PCI this isn't necessarily true.
Here is what the relevant OF device hierarchy looks like for one of
the serial controllers on an Ultra5:
Node 0xf005f1e0
ranges: 00000000.00000000.00000000.000001fe.01000000.00000000.01000000
01000000.00000000.00000000.000001fe.02000000.00000000.01000000
02000000.00000000.00000000.000001ff.00000000.00000001.00000000
03000000.00000000.00000000.000001ff.00000000.00000001.00000000
device_type: 'pci'
model: 'SUNW,sabre'
Node 0xf005f9d4
device_type: 'pci'
model: 'SUNW,simba'
Node 0xf0060d24
ranges: 00000010.00000000 82010810.00000000.f0000000 01000000
00000014.00000000 82010814.00000000.f1000000 00800000
name: 'ebus'
Node 0xf0062dac
reg: 00000014.003083f8.00000008 --> 0x1ff.f13083f8
device_type: 'serial'
name: 'su'
So the correct translation here is:
1) Match "su" register to second ranges entry of 'ebus', which translates
into a PCI triplet "82010814.00000000.f1000000" of size 00800000, which
gives us "82010814.00000000.f13083f8".
2) Pass-through "SUNW,simba" since it lacks ranges property
3) Match "82010814.00000000.f13083f8" to third ranges property of PCI
controller node 'SUNW,sabre', and we arrive at the final physical
MMIO address of "0x1fff13083f8".
Due to the 2-cell assumption, we couldn't translate to a PCI 3-cell
value, and we couldn't perform a pass-thru on it either.
It was easiest to just stop splitting the ranges application operation
between two methods, ->map and ->translate, and just let ->map do all
the work. That way it would work purely on 32-bit cell arrays instead
of having to "return" some value like a u64.
It's still not %100 correct because the out-of-range check is still
done using the 64 least significant bits of the range and address.
But it does work for all the cases I've thrown at it so far.
Signed-off-by: David S. Miller <davem@davemloft.net>
2006-07-13 14:19:31 +08:00
|
|
|
/* If the parent is the dma node of an ISA bus, pass
|
|
|
|
* the translation up to the root.
|
2008-09-03 17:04:41 +08:00
|
|
|
*
|
|
|
|
* Some SBUS devices use intermediate nodes to express
|
|
|
|
* hierarchy within the device itself. These aren't
|
|
|
|
* real bus nodes, and don't have a 'ranges' property.
|
|
|
|
* But, we should still pass the translation work up
|
|
|
|
* to the SBUS itself.
|
[SPARC]: Fix OF register translations under sub-PCI busses.
There is an implicit assumption in the code that ranges will translate
to something that can fit in 2 32-bit cells, or a 64-bit value. For
certain kinds of things below PCI this isn't necessarily true.
Here is what the relevant OF device hierarchy looks like for one of
the serial controllers on an Ultra5:
Node 0xf005f1e0
ranges: 00000000.00000000.00000000.000001fe.01000000.00000000.01000000
01000000.00000000.00000000.000001fe.02000000.00000000.01000000
02000000.00000000.00000000.000001ff.00000000.00000001.00000000
03000000.00000000.00000000.000001ff.00000000.00000001.00000000
device_type: 'pci'
model: 'SUNW,sabre'
Node 0xf005f9d4
device_type: 'pci'
model: 'SUNW,simba'
Node 0xf0060d24
ranges: 00000010.00000000 82010810.00000000.f0000000 01000000
00000014.00000000 82010814.00000000.f1000000 00800000
name: 'ebus'
Node 0xf0062dac
reg: 00000014.003083f8.00000008 --> 0x1ff.f13083f8
device_type: 'serial'
name: 'su'
So the correct translation here is:
1) Match "su" register to second ranges entry of 'ebus', which translates
into a PCI triplet "82010814.00000000.f1000000" of size 00800000, which
gives us "82010814.00000000.f13083f8".
2) Pass-through "SUNW,simba" since it lacks ranges property
3) Match "82010814.00000000.f13083f8" to third ranges property of PCI
controller node 'SUNW,sabre', and we arrive at the final physical
MMIO address of "0x1fff13083f8".
Due to the 2-cell assumption, we couldn't translate to a PCI 3-cell
value, and we couldn't perform a pass-thru on it either.
It was easiest to just stop splitting the ranges application operation
between two methods, ->map and ->translate, and just let ->map do all
the work. That way it would work purely on 32-bit cell arrays instead
of having to "return" some value like a u64.
It's still not %100 correct because the out-of-range check is still
done using the 64 least significant bits of the range and address.
But it does work for all the cases I've thrown at it so far.
Signed-off-by: David S. Miller <davem@davemloft.net>
2006-07-13 14:19:31 +08:00
|
|
|
*/
|
2008-09-03 17:04:41 +08:00
|
|
|
if (!strcmp(pp->name, "dma") ||
|
|
|
|
!strcmp(pp->name, "espdma") ||
|
|
|
|
!strcmp(pp->name, "ledma") ||
|
|
|
|
!strcmp(pp->name, "lebuffer"))
|
[SPARC]: Fix OF register translations under sub-PCI busses.
There is an implicit assumption in the code that ranges will translate
to something that can fit in 2 32-bit cells, or a 64-bit value. For
certain kinds of things below PCI this isn't necessarily true.
Here is what the relevant OF device hierarchy looks like for one of
the serial controllers on an Ultra5:
Node 0xf005f1e0
ranges: 00000000.00000000.00000000.000001fe.01000000.00000000.01000000
01000000.00000000.00000000.000001fe.02000000.00000000.01000000
02000000.00000000.00000000.000001ff.00000000.00000001.00000000
03000000.00000000.00000000.000001ff.00000000.00000001.00000000
device_type: 'pci'
model: 'SUNW,sabre'
Node 0xf005f9d4
device_type: 'pci'
model: 'SUNW,simba'
Node 0xf0060d24
ranges: 00000010.00000000 82010810.00000000.f0000000 01000000
00000014.00000000 82010814.00000000.f1000000 00800000
name: 'ebus'
Node 0xf0062dac
reg: 00000014.003083f8.00000008 --> 0x1ff.f13083f8
device_type: 'serial'
name: 'su'
So the correct translation here is:
1) Match "su" register to second ranges entry of 'ebus', which translates
into a PCI triplet "82010814.00000000.f1000000" of size 00800000, which
gives us "82010814.00000000.f13083f8".
2) Pass-through "SUNW,simba" since it lacks ranges property
3) Match "82010814.00000000.f13083f8" to third ranges property of PCI
controller node 'SUNW,sabre', and we arrive at the final physical
MMIO address of "0x1fff13083f8".
Due to the 2-cell assumption, we couldn't translate to a PCI 3-cell
value, and we couldn't perform a pass-thru on it either.
It was easiest to just stop splitting the ranges application operation
between two methods, ->map and ->translate, and just let ->map do all
the work. That way it would work purely on 32-bit cell arrays instead
of having to "return" some value like a u64.
It's still not %100 correct because the out-of-range check is still
done using the 64 least significant bits of the range and address.
But it does work for all the cases I've thrown at it so far.
Signed-off-by: David S. Miller <davem@davemloft.net>
2006-07-13 14:19:31 +08:00
|
|
|
return 0;
|
|
|
|
|
2007-06-08 12:59:44 +08:00
|
|
|
/* Similarly for all PCI bridges, if we get this far
|
|
|
|
* it lacks a ranges property, and this will include
|
|
|
|
* cases like Simba.
|
|
|
|
*/
|
2008-09-21 13:00:40 +08:00
|
|
|
if (!strcmp(pp->name, "pci"))
|
[SPARC]: Fix OF register translations under sub-PCI busses.
There is an implicit assumption in the code that ranges will translate
to something that can fit in 2 32-bit cells, or a 64-bit value. For
certain kinds of things below PCI this isn't necessarily true.
Here is what the relevant OF device hierarchy looks like for one of
the serial controllers on an Ultra5:
Node 0xf005f1e0
ranges: 00000000.00000000.00000000.000001fe.01000000.00000000.01000000
01000000.00000000.00000000.000001fe.02000000.00000000.01000000
02000000.00000000.00000000.000001ff.00000000.00000001.00000000
03000000.00000000.00000000.000001ff.00000000.00000001.00000000
device_type: 'pci'
model: 'SUNW,sabre'
Node 0xf005f9d4
device_type: 'pci'
model: 'SUNW,simba'
Node 0xf0060d24
ranges: 00000010.00000000 82010810.00000000.f0000000 01000000
00000014.00000000 82010814.00000000.f1000000 00800000
name: 'ebus'
Node 0xf0062dac
reg: 00000014.003083f8.00000008 --> 0x1ff.f13083f8
device_type: 'serial'
name: 'su'
So the correct translation here is:
1) Match "su" register to second ranges entry of 'ebus', which translates
into a PCI triplet "82010814.00000000.f1000000" of size 00800000, which
gives us "82010814.00000000.f13083f8".
2) Pass-through "SUNW,simba" since it lacks ranges property
3) Match "82010814.00000000.f13083f8" to third ranges property of PCI
controller node 'SUNW,sabre', and we arrive at the final physical
MMIO address of "0x1fff13083f8".
Due to the 2-cell assumption, we couldn't translate to a PCI 3-cell
value, and we couldn't perform a pass-thru on it either.
It was easiest to just stop splitting the ranges application operation
between two methods, ->map and ->translate, and just let ->map do all
the work. That way it would work purely on 32-bit cell arrays instead
of having to "return" some value like a u64.
It's still not %100 correct because the out-of-range check is still
done using the 64 least significant bits of the range and address.
But it does work for all the cases I've thrown at it so far.
Signed-off-by: David S. Miller <davem@davemloft.net>
2006-07-13 14:19:31 +08:00
|
|
|
return 0;
|
|
|
|
|
|
|
|
return 1;
|
2006-06-30 05:34:50 +08:00
|
|
|
}
|
|
|
|
|
[SPARC]: Fix OF register translations under sub-PCI busses.
There is an implicit assumption in the code that ranges will translate
to something that can fit in 2 32-bit cells, or a 64-bit value. For
certain kinds of things below PCI this isn't necessarily true.
Here is what the relevant OF device hierarchy looks like for one of
the serial controllers on an Ultra5:
Node 0xf005f1e0
ranges: 00000000.00000000.00000000.000001fe.01000000.00000000.01000000
01000000.00000000.00000000.000001fe.02000000.00000000.01000000
02000000.00000000.00000000.000001ff.00000000.00000001.00000000
03000000.00000000.00000000.000001ff.00000000.00000001.00000000
device_type: 'pci'
model: 'SUNW,sabre'
Node 0xf005f9d4
device_type: 'pci'
model: 'SUNW,simba'
Node 0xf0060d24
ranges: 00000010.00000000 82010810.00000000.f0000000 01000000
00000014.00000000 82010814.00000000.f1000000 00800000
name: 'ebus'
Node 0xf0062dac
reg: 00000014.003083f8.00000008 --> 0x1ff.f13083f8
device_type: 'serial'
name: 'su'
So the correct translation here is:
1) Match "su" register to second ranges entry of 'ebus', which translates
into a PCI triplet "82010814.00000000.f1000000" of size 00800000, which
gives us "82010814.00000000.f13083f8".
2) Pass-through "SUNW,simba" since it lacks ranges property
3) Match "82010814.00000000.f13083f8" to third ranges property of PCI
controller node 'SUNW,sabre', and we arrive at the final physical
MMIO address of "0x1fff13083f8".
Due to the 2-cell assumption, we couldn't translate to a PCI 3-cell
value, and we couldn't perform a pass-thru on it either.
It was easiest to just stop splitting the ranges application operation
between two methods, ->map and ->translate, and just let ->map do all
the work. That way it would work purely on 32-bit cell arrays instead
of having to "return" some value like a u64.
It's still not %100 correct because the out-of-range check is still
done using the 64 least significant bits of the range and address.
But it does work for all the cases I've thrown at it so far.
Signed-off-by: David S. Miller <davem@davemloft.net>
2006-07-13 14:19:31 +08:00
|
|
|
static int of_resource_verbose;
|
|
|
|
|
2010-07-23 06:04:30 +08:00
|
|
|
static void __init build_device_resources(struct platform_device *op,
|
2006-06-30 05:34:50 +08:00
|
|
|
struct device *parent)
|
|
|
|
{
|
2010-07-23 06:04:30 +08:00
|
|
|
struct platform_device *p_op;
|
2006-06-30 05:34:50 +08:00
|
|
|
struct of_bus *bus;
|
|
|
|
int na, ns;
|
|
|
|
int index, num_reg;
|
2007-04-24 06:53:27 +08:00
|
|
|
const void *preg;
|
2006-06-30 05:34:50 +08:00
|
|
|
|
|
|
|
if (!parent)
|
|
|
|
return;
|
|
|
|
|
2010-07-23 06:04:30 +08:00
|
|
|
p_op = to_platform_device(parent);
|
2010-04-14 07:12:29 +08:00
|
|
|
bus = of_match_bus(p_op->dev.of_node);
|
|
|
|
bus->count_cells(op->dev.of_node, &na, &ns);
|
2006-06-30 05:34:50 +08:00
|
|
|
|
2010-04-14 07:12:29 +08:00
|
|
|
preg = of_get_property(op->dev.of_node, bus->addr_prop_name, &num_reg);
|
2006-06-30 05:34:50 +08:00
|
|
|
if (!preg || num_reg == 0)
|
|
|
|
return;
|
|
|
|
|
|
|
|
/* Convert to num-cells. */
|
|
|
|
num_reg /= 4;
|
|
|
|
|
2006-07-17 13:10:44 +08:00
|
|
|
/* Convert to num-entries. */
|
2006-06-30 05:34:50 +08:00
|
|
|
num_reg /= na + ns;
|
|
|
|
|
2007-05-12 04:52:08 +08:00
|
|
|
/* Prevent overrunning the op->resources[] array. */
|
2006-07-17 13:10:44 +08:00
|
|
|
if (num_reg > PROMREG_MAX) {
|
|
|
|
printk(KERN_WARNING "%s: Too many regs (%d), "
|
|
|
|
"limiting to %d.\n",
|
2010-04-14 07:12:29 +08:00
|
|
|
op->dev.of_node->full_name, num_reg, PROMREG_MAX);
|
2006-07-17 13:10:44 +08:00
|
|
|
num_reg = PROMREG_MAX;
|
|
|
|
}
|
|
|
|
|
2010-06-19 01:09:58 +08:00
|
|
|
op->resource = op->archdata.resource;
|
|
|
|
op->num_resources = num_reg;
|
2006-06-30 05:34:50 +08:00
|
|
|
for (index = 0; index < num_reg; index++) {
|
|
|
|
struct resource *r = &op->resource[index];
|
|
|
|
u32 addr[OF_MAX_ADDR_CELLS];
|
2007-04-24 06:53:27 +08:00
|
|
|
const u32 *reg = (preg + (index * ((na + ns) * 4)));
|
2010-04-14 07:12:29 +08:00
|
|
|
struct device_node *dp = op->dev.of_node;
|
|
|
|
struct device_node *pp = p_op->dev.of_node;
|
2007-03-01 15:20:12 +08:00
|
|
|
struct of_bus *pbus, *dbus;
|
2006-06-30 05:34:50 +08:00
|
|
|
u64 size, result = OF_BAD_ADDR;
|
|
|
|
unsigned long flags;
|
|
|
|
int dna, dns;
|
|
|
|
int pna, pns;
|
|
|
|
|
|
|
|
size = of_read_addr(reg + na, ns);
|
|
|
|
memcpy(addr, reg, na * 4);
|
|
|
|
|
2008-08-29 12:02:58 +08:00
|
|
|
flags = bus->get_flags(addr, 0);
|
|
|
|
|
[SPARC]: Fix OF register translations under sub-PCI busses.
There is an implicit assumption in the code that ranges will translate
to something that can fit in 2 32-bit cells, or a 64-bit value. For
certain kinds of things below PCI this isn't necessarily true.
Here is what the relevant OF device hierarchy looks like for one of
the serial controllers on an Ultra5:
Node 0xf005f1e0
ranges: 00000000.00000000.00000000.000001fe.01000000.00000000.01000000
01000000.00000000.00000000.000001fe.02000000.00000000.01000000
02000000.00000000.00000000.000001ff.00000000.00000001.00000000
03000000.00000000.00000000.000001ff.00000000.00000001.00000000
device_type: 'pci'
model: 'SUNW,sabre'
Node 0xf005f9d4
device_type: 'pci'
model: 'SUNW,simba'
Node 0xf0060d24
ranges: 00000010.00000000 82010810.00000000.f0000000 01000000
00000014.00000000 82010814.00000000.f1000000 00800000
name: 'ebus'
Node 0xf0062dac
reg: 00000014.003083f8.00000008 --> 0x1ff.f13083f8
device_type: 'serial'
name: 'su'
So the correct translation here is:
1) Match "su" register to second ranges entry of 'ebus', which translates
into a PCI triplet "82010814.00000000.f1000000" of size 00800000, which
gives us "82010814.00000000.f13083f8".
2) Pass-through "SUNW,simba" since it lacks ranges property
3) Match "82010814.00000000.f13083f8" to third ranges property of PCI
controller node 'SUNW,sabre', and we arrive at the final physical
MMIO address of "0x1fff13083f8".
Due to the 2-cell assumption, we couldn't translate to a PCI 3-cell
value, and we couldn't perform a pass-thru on it either.
It was easiest to just stop splitting the ranges application operation
between two methods, ->map and ->translate, and just let ->map do all
the work. That way it would work purely on 32-bit cell arrays instead
of having to "return" some value like a u64.
It's still not %100 correct because the out-of-range check is still
done using the 64 least significant bits of the range and address.
But it does work for all the cases I've thrown at it so far.
Signed-off-by: David S. Miller <davem@davemloft.net>
2006-07-13 14:19:31 +08:00
|
|
|
if (use_1to1_mapping(pp)) {
|
2006-06-30 05:34:50 +08:00
|
|
|
result = of_read_addr(addr, na);
|
|
|
|
goto build_res;
|
|
|
|
}
|
|
|
|
|
|
|
|
dna = na;
|
|
|
|
dns = ns;
|
2007-03-01 15:20:12 +08:00
|
|
|
dbus = bus;
|
2006-06-30 05:34:50 +08:00
|
|
|
|
|
|
|
while (1) {
|
|
|
|
dp = pp;
|
|
|
|
pp = dp->parent;
|
|
|
|
if (!pp) {
|
|
|
|
result = of_read_addr(addr, dna);
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
|
|
|
pbus = of_match_bus(pp);
|
|
|
|
pbus->count_cells(dp, &pna, &pns);
|
|
|
|
|
2007-03-01 15:20:12 +08:00
|
|
|
if (build_one_resource(dp, dbus, pbus, addr,
|
[SPARC]: Fix OF register translations under sub-PCI busses.
There is an implicit assumption in the code that ranges will translate
to something that can fit in 2 32-bit cells, or a 64-bit value. For
certain kinds of things below PCI this isn't necessarily true.
Here is what the relevant OF device hierarchy looks like for one of
the serial controllers on an Ultra5:
Node 0xf005f1e0
ranges: 00000000.00000000.00000000.000001fe.01000000.00000000.01000000
01000000.00000000.00000000.000001fe.02000000.00000000.01000000
02000000.00000000.00000000.000001ff.00000000.00000001.00000000
03000000.00000000.00000000.000001ff.00000000.00000001.00000000
device_type: 'pci'
model: 'SUNW,sabre'
Node 0xf005f9d4
device_type: 'pci'
model: 'SUNW,simba'
Node 0xf0060d24
ranges: 00000010.00000000 82010810.00000000.f0000000 01000000
00000014.00000000 82010814.00000000.f1000000 00800000
name: 'ebus'
Node 0xf0062dac
reg: 00000014.003083f8.00000008 --> 0x1ff.f13083f8
device_type: 'serial'
name: 'su'
So the correct translation here is:
1) Match "su" register to second ranges entry of 'ebus', which translates
into a PCI triplet "82010814.00000000.f1000000" of size 00800000, which
gives us "82010814.00000000.f13083f8".
2) Pass-through "SUNW,simba" since it lacks ranges property
3) Match "82010814.00000000.f13083f8" to third ranges property of PCI
controller node 'SUNW,sabre', and we arrive at the final physical
MMIO address of "0x1fff13083f8".
Due to the 2-cell assumption, we couldn't translate to a PCI 3-cell
value, and we couldn't perform a pass-thru on it either.
It was easiest to just stop splitting the ranges application operation
between two methods, ->map and ->translate, and just let ->map do all
the work. That way it would work purely on 32-bit cell arrays instead
of having to "return" some value like a u64.
It's still not %100 correct because the out-of-range check is still
done using the 64 least significant bits of the range and address.
But it does work for all the cases I've thrown at it so far.
Signed-off-by: David S. Miller <davem@davemloft.net>
2006-07-13 14:19:31 +08:00
|
|
|
dna, dns, pna))
|
2006-06-30 05:34:50 +08:00
|
|
|
break;
|
|
|
|
|
2008-08-29 12:02:58 +08:00
|
|
|
flags = pbus->get_flags(addr, flags);
|
|
|
|
|
2006-06-30 05:34:50 +08:00
|
|
|
dna = pna;
|
|
|
|
dns = pns;
|
2007-03-01 15:20:12 +08:00
|
|
|
dbus = pbus;
|
2006-06-30 05:34:50 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
build_res:
|
|
|
|
memset(r, 0, sizeof(*r));
|
[SPARC]: Fix OF register translations under sub-PCI busses.
There is an implicit assumption in the code that ranges will translate
to something that can fit in 2 32-bit cells, or a 64-bit value. For
certain kinds of things below PCI this isn't necessarily true.
Here is what the relevant OF device hierarchy looks like for one of
the serial controllers on an Ultra5:
Node 0xf005f1e0
ranges: 00000000.00000000.00000000.000001fe.01000000.00000000.01000000
01000000.00000000.00000000.000001fe.02000000.00000000.01000000
02000000.00000000.00000000.000001ff.00000000.00000001.00000000
03000000.00000000.00000000.000001ff.00000000.00000001.00000000
device_type: 'pci'
model: 'SUNW,sabre'
Node 0xf005f9d4
device_type: 'pci'
model: 'SUNW,simba'
Node 0xf0060d24
ranges: 00000010.00000000 82010810.00000000.f0000000 01000000
00000014.00000000 82010814.00000000.f1000000 00800000
name: 'ebus'
Node 0xf0062dac
reg: 00000014.003083f8.00000008 --> 0x1ff.f13083f8
device_type: 'serial'
name: 'su'
So the correct translation here is:
1) Match "su" register to second ranges entry of 'ebus', which translates
into a PCI triplet "82010814.00000000.f1000000" of size 00800000, which
gives us "82010814.00000000.f13083f8".
2) Pass-through "SUNW,simba" since it lacks ranges property
3) Match "82010814.00000000.f13083f8" to third ranges property of PCI
controller node 'SUNW,sabre', and we arrive at the final physical
MMIO address of "0x1fff13083f8".
Due to the 2-cell assumption, we couldn't translate to a PCI 3-cell
value, and we couldn't perform a pass-thru on it either.
It was easiest to just stop splitting the ranges application operation
between two methods, ->map and ->translate, and just let ->map do all
the work. That way it would work purely on 32-bit cell arrays instead
of having to "return" some value like a u64.
It's still not %100 correct because the out-of-range check is still
done using the 64 least significant bits of the range and address.
But it does work for all the cases I've thrown at it so far.
Signed-off-by: David S. Miller <davem@davemloft.net>
2006-07-13 14:19:31 +08:00
|
|
|
|
|
|
|
if (of_resource_verbose)
|
2009-01-07 05:19:28 +08:00
|
|
|
printk("%s reg[%d] -> %llx\n",
|
2010-04-14 07:12:29 +08:00
|
|
|
op->dev.of_node->full_name, index,
|
[SPARC]: Fix OF register translations under sub-PCI busses.
There is an implicit assumption in the code that ranges will translate
to something that can fit in 2 32-bit cells, or a 64-bit value. For
certain kinds of things below PCI this isn't necessarily true.
Here is what the relevant OF device hierarchy looks like for one of
the serial controllers on an Ultra5:
Node 0xf005f1e0
ranges: 00000000.00000000.00000000.000001fe.01000000.00000000.01000000
01000000.00000000.00000000.000001fe.02000000.00000000.01000000
02000000.00000000.00000000.000001ff.00000000.00000001.00000000
03000000.00000000.00000000.000001ff.00000000.00000001.00000000
device_type: 'pci'
model: 'SUNW,sabre'
Node 0xf005f9d4
device_type: 'pci'
model: 'SUNW,simba'
Node 0xf0060d24
ranges: 00000010.00000000 82010810.00000000.f0000000 01000000
00000014.00000000 82010814.00000000.f1000000 00800000
name: 'ebus'
Node 0xf0062dac
reg: 00000014.003083f8.00000008 --> 0x1ff.f13083f8
device_type: 'serial'
name: 'su'
So the correct translation here is:
1) Match "su" register to second ranges entry of 'ebus', which translates
into a PCI triplet "82010814.00000000.f1000000" of size 00800000, which
gives us "82010814.00000000.f13083f8".
2) Pass-through "SUNW,simba" since it lacks ranges property
3) Match "82010814.00000000.f13083f8" to third ranges property of PCI
controller node 'SUNW,sabre', and we arrive at the final physical
MMIO address of "0x1fff13083f8".
Due to the 2-cell assumption, we couldn't translate to a PCI 3-cell
value, and we couldn't perform a pass-thru on it either.
It was easiest to just stop splitting the ranges application operation
between two methods, ->map and ->translate, and just let ->map do all
the work. That way it would work purely on 32-bit cell arrays instead
of having to "return" some value like a u64.
It's still not %100 correct because the out-of-range check is still
done using the 64 least significant bits of the range and address.
But it does work for all the cases I've thrown at it so far.
Signed-off-by: David S. Miller <davem@davemloft.net>
2006-07-13 14:19:31 +08:00
|
|
|
result);
|
|
|
|
|
2006-06-30 05:34:50 +08:00
|
|
|
if (result != OF_BAD_ADDR) {
|
2006-06-30 10:58:28 +08:00
|
|
|
if (tlb_type == hypervisor)
|
|
|
|
result &= 0x0fffffffffffffffUL;
|
|
|
|
|
2006-06-30 05:34:50 +08:00
|
|
|
r->start = result;
|
|
|
|
r->end = result + size - 1;
|
|
|
|
r->flags = flags;
|
|
|
|
}
|
2010-04-14 07:12:29 +08:00
|
|
|
r->name = op->dev.of_node->name;
|
2006-06-30 05:34:50 +08:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2006-06-30 06:07:37 +08:00
|
|
|
static struct device_node * __init
|
|
|
|
apply_interrupt_map(struct device_node *dp, struct device_node *pp,
|
2007-04-24 06:53:27 +08:00
|
|
|
const u32 *imap, int imlen, const u32 *imask,
|
2006-06-30 06:07:37 +08:00
|
|
|
unsigned int *irq_p)
|
|
|
|
{
|
|
|
|
struct device_node *cp;
|
|
|
|
unsigned int irq = *irq_p;
|
|
|
|
struct of_bus *bus;
|
|
|
|
phandle handle;
|
2007-04-24 06:53:27 +08:00
|
|
|
const u32 *reg;
|
2006-06-30 06:07:37 +08:00
|
|
|
int na, num_reg, i;
|
|
|
|
|
|
|
|
bus = of_match_bus(pp);
|
|
|
|
bus->count_cells(dp, &na, NULL);
|
|
|
|
|
|
|
|
reg = of_get_property(dp, "reg", &num_reg);
|
|
|
|
if (!reg || !num_reg)
|
|
|
|
return NULL;
|
|
|
|
|
|
|
|
imlen /= ((na + 3) * 4);
|
|
|
|
handle = 0;
|
|
|
|
for (i = 0; i < imlen; i++) {
|
|
|
|
int j;
|
|
|
|
|
|
|
|
for (j = 0; j < na; j++) {
|
|
|
|
if ((reg[j] & imask[j]) != imap[j])
|
|
|
|
goto next;
|
|
|
|
}
|
|
|
|
if (imap[na] == irq) {
|
|
|
|
handle = imap[na + 1];
|
|
|
|
irq = imap[na + 2];
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
|
|
|
next:
|
|
|
|
imap += (na + 3);
|
|
|
|
}
|
2006-07-17 13:10:44 +08:00
|
|
|
if (i == imlen) {
|
|
|
|
/* Psycho and Sabre PCI controllers can have 'interrupt-map'
|
|
|
|
* properties that do not include the on-board device
|
|
|
|
* interrupts. Instead, the device's 'interrupts' property
|
|
|
|
* is already a fully specified INO value.
|
|
|
|
*
|
|
|
|
* Handle this by deciding that, if we didn't get a
|
|
|
|
* match in the parent's 'interrupt-map', and the
|
2011-03-31 09:57:33 +08:00
|
|
|
* parent is an IRQ translator, then use the parent as
|
2006-07-17 13:10:44 +08:00
|
|
|
* our IRQ controller.
|
|
|
|
*/
|
|
|
|
if (pp->irq_trans)
|
|
|
|
return pp;
|
|
|
|
|
2006-06-30 06:07:37 +08:00
|
|
|
return NULL;
|
2006-07-17 13:10:44 +08:00
|
|
|
}
|
2006-06-30 06:07:37 +08:00
|
|
|
|
|
|
|
*irq_p = irq;
|
|
|
|
cp = of_find_node_by_phandle(handle);
|
|
|
|
|
|
|
|
return cp;
|
|
|
|
}
|
|
|
|
|
|
|
|
static unsigned int __init pci_irq_swizzle(struct device_node *dp,
|
|
|
|
struct device_node *pp,
|
|
|
|
unsigned int irq)
|
|
|
|
{
|
2007-04-24 06:53:27 +08:00
|
|
|
const struct linux_prom_pci_registers *regs;
|
2007-02-27 06:55:06 +08:00
|
|
|
unsigned int bus, devfn, slot, ret;
|
2006-06-30 06:07:37 +08:00
|
|
|
|
|
|
|
if (irq < 1 || irq > 4)
|
|
|
|
return irq;
|
|
|
|
|
|
|
|
regs = of_get_property(dp, "reg", NULL);
|
|
|
|
if (!regs)
|
|
|
|
return irq;
|
|
|
|
|
2007-02-27 06:55:06 +08:00
|
|
|
bus = (regs->phys_hi >> 16) & 0xff;
|
2006-06-30 06:07:37 +08:00
|
|
|
devfn = (regs->phys_hi >> 8) & 0xff;
|
|
|
|
slot = (devfn >> 3) & 0x1f;
|
|
|
|
|
2007-02-27 06:55:06 +08:00
|
|
|
if (pp->irq_trans) {
|
|
|
|
/* Derived from Table 8-3, U2P User's Manual. This branch
|
|
|
|
* is handling a PCI controller that lacks a proper set of
|
|
|
|
* interrupt-map and interrupt-map-mask properties. The
|
|
|
|
* Ultra-E450 is one example.
|
|
|
|
*
|
|
|
|
* The bit layout is BSSLL, where:
|
|
|
|
* B: 0 on bus A, 1 on bus B
|
|
|
|
* D: 2-bit slot number, derived from PCI device number as
|
|
|
|
* (dev - 1) for bus A, or (dev - 2) for bus B
|
|
|
|
* L: 2-bit line number
|
|
|
|
*/
|
|
|
|
if (bus & 0x80) {
|
|
|
|
/* PBM-A */
|
|
|
|
bus = 0x00;
|
|
|
|
slot = (slot - 1) << 2;
|
|
|
|
} else {
|
|
|
|
/* PBM-B */
|
|
|
|
bus = 0x10;
|
|
|
|
slot = (slot - 2) << 2;
|
|
|
|
}
|
|
|
|
irq -= 1;
|
|
|
|
|
|
|
|
ret = (bus | slot | irq);
|
|
|
|
} else {
|
|
|
|
/* Going through a PCI-PCI bridge that lacks a set of
|
|
|
|
* interrupt-map and interrupt-map-mask properties.
|
|
|
|
*/
|
|
|
|
ret = ((irq - 1 + (slot & 3)) & 3) + 1;
|
|
|
|
}
|
2006-06-30 06:07:37 +08:00
|
|
|
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
[SPARC]: Fix OF register translations under sub-PCI busses.
There is an implicit assumption in the code that ranges will translate
to something that can fit in 2 32-bit cells, or a 64-bit value. For
certain kinds of things below PCI this isn't necessarily true.
Here is what the relevant OF device hierarchy looks like for one of
the serial controllers on an Ultra5:
Node 0xf005f1e0
ranges: 00000000.00000000.00000000.000001fe.01000000.00000000.01000000
01000000.00000000.00000000.000001fe.02000000.00000000.01000000
02000000.00000000.00000000.000001ff.00000000.00000001.00000000
03000000.00000000.00000000.000001ff.00000000.00000001.00000000
device_type: 'pci'
model: 'SUNW,sabre'
Node 0xf005f9d4
device_type: 'pci'
model: 'SUNW,simba'
Node 0xf0060d24
ranges: 00000010.00000000 82010810.00000000.f0000000 01000000
00000014.00000000 82010814.00000000.f1000000 00800000
name: 'ebus'
Node 0xf0062dac
reg: 00000014.003083f8.00000008 --> 0x1ff.f13083f8
device_type: 'serial'
name: 'su'
So the correct translation here is:
1) Match "su" register to second ranges entry of 'ebus', which translates
into a PCI triplet "82010814.00000000.f1000000" of size 00800000, which
gives us "82010814.00000000.f13083f8".
2) Pass-through "SUNW,simba" since it lacks ranges property
3) Match "82010814.00000000.f13083f8" to third ranges property of PCI
controller node 'SUNW,sabre', and we arrive at the final physical
MMIO address of "0x1fff13083f8".
Due to the 2-cell assumption, we couldn't translate to a PCI 3-cell
value, and we couldn't perform a pass-thru on it either.
It was easiest to just stop splitting the ranges application operation
between two methods, ->map and ->translate, and just let ->map do all
the work. That way it would work purely on 32-bit cell arrays instead
of having to "return" some value like a u64.
It's still not %100 correct because the out-of-range check is still
done using the 64 least significant bits of the range and address.
But it does work for all the cases I've thrown at it so far.
Signed-off-by: David S. Miller <davem@davemloft.net>
2006-07-13 14:19:31 +08:00
|
|
|
static int of_irq_verbose;
|
|
|
|
|
2010-07-23 06:04:30 +08:00
|
|
|
static unsigned int __init build_one_device_irq(struct platform_device *op,
|
2006-06-30 06:07:37 +08:00
|
|
|
struct device *parent,
|
|
|
|
unsigned int irq)
|
|
|
|
{
|
2010-04-14 07:12:29 +08:00
|
|
|
struct device_node *dp = op->dev.of_node;
|
2006-06-30 06:07:37 +08:00
|
|
|
struct device_node *pp, *ip;
|
|
|
|
unsigned int orig_irq = irq;
|
2008-03-19 19:52:48 +08:00
|
|
|
int nid;
|
2006-06-30 06:07:37 +08:00
|
|
|
|
|
|
|
if (irq == 0xffffffff)
|
|
|
|
return irq;
|
|
|
|
|
|
|
|
if (dp->irq_trans) {
|
|
|
|
irq = dp->irq_trans->irq_build(dp, irq,
|
|
|
|
dp->irq_trans->data);
|
[SPARC]: Fix OF register translations under sub-PCI busses.
There is an implicit assumption in the code that ranges will translate
to something that can fit in 2 32-bit cells, or a 64-bit value. For
certain kinds of things below PCI this isn't necessarily true.
Here is what the relevant OF device hierarchy looks like for one of
the serial controllers on an Ultra5:
Node 0xf005f1e0
ranges: 00000000.00000000.00000000.000001fe.01000000.00000000.01000000
01000000.00000000.00000000.000001fe.02000000.00000000.01000000
02000000.00000000.00000000.000001ff.00000000.00000001.00000000
03000000.00000000.00000000.000001ff.00000000.00000001.00000000
device_type: 'pci'
model: 'SUNW,sabre'
Node 0xf005f9d4
device_type: 'pci'
model: 'SUNW,simba'
Node 0xf0060d24
ranges: 00000010.00000000 82010810.00000000.f0000000 01000000
00000014.00000000 82010814.00000000.f1000000 00800000
name: 'ebus'
Node 0xf0062dac
reg: 00000014.003083f8.00000008 --> 0x1ff.f13083f8
device_type: 'serial'
name: 'su'
So the correct translation here is:
1) Match "su" register to second ranges entry of 'ebus', which translates
into a PCI triplet "82010814.00000000.f1000000" of size 00800000, which
gives us "82010814.00000000.f13083f8".
2) Pass-through "SUNW,simba" since it lacks ranges property
3) Match "82010814.00000000.f13083f8" to third ranges property of PCI
controller node 'SUNW,sabre', and we arrive at the final physical
MMIO address of "0x1fff13083f8".
Due to the 2-cell assumption, we couldn't translate to a PCI 3-cell
value, and we couldn't perform a pass-thru on it either.
It was easiest to just stop splitting the ranges application operation
between two methods, ->map and ->translate, and just let ->map do all
the work. That way it would work purely on 32-bit cell arrays instead
of having to "return" some value like a u64.
It's still not %100 correct because the out-of-range check is still
done using the 64 least significant bits of the range and address.
But it does work for all the cases I've thrown at it so far.
Signed-off-by: David S. Miller <davem@davemloft.net>
2006-07-13 14:19:31 +08:00
|
|
|
|
|
|
|
if (of_irq_verbose)
|
|
|
|
printk("%s: direct translate %x --> %x\n",
|
|
|
|
dp->full_name, orig_irq, irq);
|
|
|
|
|
2008-03-19 19:52:48 +08:00
|
|
|
goto out;
|
2006-06-30 06:07:37 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
/* Something more complicated. Walk up to the root, applying
|
|
|
|
* interrupt-map or bus specific translations, until we hit
|
|
|
|
* an IRQ translator.
|
|
|
|
*
|
|
|
|
* If we hit a bus type or situation we cannot handle, we
|
|
|
|
* stop and assume that the original IRQ number was in a
|
|
|
|
* format which has special meaning to it's immediate parent.
|
|
|
|
*/
|
|
|
|
pp = dp->parent;
|
|
|
|
ip = NULL;
|
|
|
|
while (pp) {
|
2007-04-24 06:53:27 +08:00
|
|
|
const void *imap, *imsk;
|
2006-06-30 06:07:37 +08:00
|
|
|
int imlen;
|
|
|
|
|
|
|
|
imap = of_get_property(pp, "interrupt-map", &imlen);
|
|
|
|
imsk = of_get_property(pp, "interrupt-map-mask", NULL);
|
|
|
|
if (imap && imsk) {
|
|
|
|
struct device_node *iret;
|
|
|
|
int this_orig_irq = irq;
|
|
|
|
|
|
|
|
iret = apply_interrupt_map(dp, pp,
|
|
|
|
imap, imlen, imsk,
|
|
|
|
&irq);
|
[SPARC]: Fix OF register translations under sub-PCI busses.
There is an implicit assumption in the code that ranges will translate
to something that can fit in 2 32-bit cells, or a 64-bit value. For
certain kinds of things below PCI this isn't necessarily true.
Here is what the relevant OF device hierarchy looks like for one of
the serial controllers on an Ultra5:
Node 0xf005f1e0
ranges: 00000000.00000000.00000000.000001fe.01000000.00000000.01000000
01000000.00000000.00000000.000001fe.02000000.00000000.01000000
02000000.00000000.00000000.000001ff.00000000.00000001.00000000
03000000.00000000.00000000.000001ff.00000000.00000001.00000000
device_type: 'pci'
model: 'SUNW,sabre'
Node 0xf005f9d4
device_type: 'pci'
model: 'SUNW,simba'
Node 0xf0060d24
ranges: 00000010.00000000 82010810.00000000.f0000000 01000000
00000014.00000000 82010814.00000000.f1000000 00800000
name: 'ebus'
Node 0xf0062dac
reg: 00000014.003083f8.00000008 --> 0x1ff.f13083f8
device_type: 'serial'
name: 'su'
So the correct translation here is:
1) Match "su" register to second ranges entry of 'ebus', which translates
into a PCI triplet "82010814.00000000.f1000000" of size 00800000, which
gives us "82010814.00000000.f13083f8".
2) Pass-through "SUNW,simba" since it lacks ranges property
3) Match "82010814.00000000.f13083f8" to third ranges property of PCI
controller node 'SUNW,sabre', and we arrive at the final physical
MMIO address of "0x1fff13083f8".
Due to the 2-cell assumption, we couldn't translate to a PCI 3-cell
value, and we couldn't perform a pass-thru on it either.
It was easiest to just stop splitting the ranges application operation
between two methods, ->map and ->translate, and just let ->map do all
the work. That way it would work purely on 32-bit cell arrays instead
of having to "return" some value like a u64.
It's still not %100 correct because the out-of-range check is still
done using the 64 least significant bits of the range and address.
But it does work for all the cases I've thrown at it so far.
Signed-off-by: David S. Miller <davem@davemloft.net>
2006-07-13 14:19:31 +08:00
|
|
|
|
|
|
|
if (of_irq_verbose)
|
|
|
|
printk("%s: Apply [%s:%x] imap --> [%s:%x]\n",
|
2010-04-14 07:12:29 +08:00
|
|
|
op->dev.of_node->full_name,
|
[SPARC]: Fix OF register translations under sub-PCI busses.
There is an implicit assumption in the code that ranges will translate
to something that can fit in 2 32-bit cells, or a 64-bit value. For
certain kinds of things below PCI this isn't necessarily true.
Here is what the relevant OF device hierarchy looks like for one of
the serial controllers on an Ultra5:
Node 0xf005f1e0
ranges: 00000000.00000000.00000000.000001fe.01000000.00000000.01000000
01000000.00000000.00000000.000001fe.02000000.00000000.01000000
02000000.00000000.00000000.000001ff.00000000.00000001.00000000
03000000.00000000.00000000.000001ff.00000000.00000001.00000000
device_type: 'pci'
model: 'SUNW,sabre'
Node 0xf005f9d4
device_type: 'pci'
model: 'SUNW,simba'
Node 0xf0060d24
ranges: 00000010.00000000 82010810.00000000.f0000000 01000000
00000014.00000000 82010814.00000000.f1000000 00800000
name: 'ebus'
Node 0xf0062dac
reg: 00000014.003083f8.00000008 --> 0x1ff.f13083f8
device_type: 'serial'
name: 'su'
So the correct translation here is:
1) Match "su" register to second ranges entry of 'ebus', which translates
into a PCI triplet "82010814.00000000.f1000000" of size 00800000, which
gives us "82010814.00000000.f13083f8".
2) Pass-through "SUNW,simba" since it lacks ranges property
3) Match "82010814.00000000.f13083f8" to third ranges property of PCI
controller node 'SUNW,sabre', and we arrive at the final physical
MMIO address of "0x1fff13083f8".
Due to the 2-cell assumption, we couldn't translate to a PCI 3-cell
value, and we couldn't perform a pass-thru on it either.
It was easiest to just stop splitting the ranges application operation
between two methods, ->map and ->translate, and just let ->map do all
the work. That way it would work purely on 32-bit cell arrays instead
of having to "return" some value like a u64.
It's still not %100 correct because the out-of-range check is still
done using the 64 least significant bits of the range and address.
But it does work for all the cases I've thrown at it so far.
Signed-off-by: David S. Miller <davem@davemloft.net>
2006-07-13 14:19:31 +08:00
|
|
|
pp->full_name, this_orig_irq,
|
|
|
|
(iret ? iret->full_name : "NULL"), irq);
|
|
|
|
|
2006-06-30 06:07:37 +08:00
|
|
|
if (!iret)
|
|
|
|
break;
|
|
|
|
|
|
|
|
if (iret->irq_trans) {
|
|
|
|
ip = iret;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
} else {
|
2008-09-21 13:00:40 +08:00
|
|
|
if (!strcmp(pp->name, "pci")) {
|
2006-06-30 06:07:37 +08:00
|
|
|
unsigned int this_orig_irq = irq;
|
|
|
|
|
|
|
|
irq = pci_irq_swizzle(dp, pp, irq);
|
[SPARC]: Fix OF register translations under sub-PCI busses.
There is an implicit assumption in the code that ranges will translate
to something that can fit in 2 32-bit cells, or a 64-bit value. For
certain kinds of things below PCI this isn't necessarily true.
Here is what the relevant OF device hierarchy looks like for one of
the serial controllers on an Ultra5:
Node 0xf005f1e0
ranges: 00000000.00000000.00000000.000001fe.01000000.00000000.01000000
01000000.00000000.00000000.000001fe.02000000.00000000.01000000
02000000.00000000.00000000.000001ff.00000000.00000001.00000000
03000000.00000000.00000000.000001ff.00000000.00000001.00000000
device_type: 'pci'
model: 'SUNW,sabre'
Node 0xf005f9d4
device_type: 'pci'
model: 'SUNW,simba'
Node 0xf0060d24
ranges: 00000010.00000000 82010810.00000000.f0000000 01000000
00000014.00000000 82010814.00000000.f1000000 00800000
name: 'ebus'
Node 0xf0062dac
reg: 00000014.003083f8.00000008 --> 0x1ff.f13083f8
device_type: 'serial'
name: 'su'
So the correct translation here is:
1) Match "su" register to second ranges entry of 'ebus', which translates
into a PCI triplet "82010814.00000000.f1000000" of size 00800000, which
gives us "82010814.00000000.f13083f8".
2) Pass-through "SUNW,simba" since it lacks ranges property
3) Match "82010814.00000000.f13083f8" to third ranges property of PCI
controller node 'SUNW,sabre', and we arrive at the final physical
MMIO address of "0x1fff13083f8".
Due to the 2-cell assumption, we couldn't translate to a PCI 3-cell
value, and we couldn't perform a pass-thru on it either.
It was easiest to just stop splitting the ranges application operation
between two methods, ->map and ->translate, and just let ->map do all
the work. That way it would work purely on 32-bit cell arrays instead
of having to "return" some value like a u64.
It's still not %100 correct because the out-of-range check is still
done using the 64 least significant bits of the range and address.
But it does work for all the cases I've thrown at it so far.
Signed-off-by: David S. Miller <davem@davemloft.net>
2006-07-13 14:19:31 +08:00
|
|
|
if (of_irq_verbose)
|
|
|
|
printk("%s: PCI swizzle [%s] "
|
|
|
|
"%x --> %x\n",
|
2010-04-14 07:12:29 +08:00
|
|
|
op->dev.of_node->full_name,
|
[SPARC]: Fix OF register translations under sub-PCI busses.
There is an implicit assumption in the code that ranges will translate
to something that can fit in 2 32-bit cells, or a 64-bit value. For
certain kinds of things below PCI this isn't necessarily true.
Here is what the relevant OF device hierarchy looks like for one of
the serial controllers on an Ultra5:
Node 0xf005f1e0
ranges: 00000000.00000000.00000000.000001fe.01000000.00000000.01000000
01000000.00000000.00000000.000001fe.02000000.00000000.01000000
02000000.00000000.00000000.000001ff.00000000.00000001.00000000
03000000.00000000.00000000.000001ff.00000000.00000001.00000000
device_type: 'pci'
model: 'SUNW,sabre'
Node 0xf005f9d4
device_type: 'pci'
model: 'SUNW,simba'
Node 0xf0060d24
ranges: 00000010.00000000 82010810.00000000.f0000000 01000000
00000014.00000000 82010814.00000000.f1000000 00800000
name: 'ebus'
Node 0xf0062dac
reg: 00000014.003083f8.00000008 --> 0x1ff.f13083f8
device_type: 'serial'
name: 'su'
So the correct translation here is:
1) Match "su" register to second ranges entry of 'ebus', which translates
into a PCI triplet "82010814.00000000.f1000000" of size 00800000, which
gives us "82010814.00000000.f13083f8".
2) Pass-through "SUNW,simba" since it lacks ranges property
3) Match "82010814.00000000.f13083f8" to third ranges property of PCI
controller node 'SUNW,sabre', and we arrive at the final physical
MMIO address of "0x1fff13083f8".
Due to the 2-cell assumption, we couldn't translate to a PCI 3-cell
value, and we couldn't perform a pass-thru on it either.
It was easiest to just stop splitting the ranges application operation
between two methods, ->map and ->translate, and just let ->map do all
the work. That way it would work purely on 32-bit cell arrays instead
of having to "return" some value like a u64.
It's still not %100 correct because the out-of-range check is still
done using the 64 least significant bits of the range and address.
But it does work for all the cases I've thrown at it so far.
Signed-off-by: David S. Miller <davem@davemloft.net>
2006-07-13 14:19:31 +08:00
|
|
|
pp->full_name, this_orig_irq,
|
|
|
|
irq);
|
|
|
|
|
2006-06-30 06:07:37 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
if (pp->irq_trans) {
|
|
|
|
ip = pp;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
dp = pp;
|
|
|
|
pp = pp->parent;
|
|
|
|
}
|
|
|
|
if (!ip)
|
|
|
|
return orig_irq;
|
|
|
|
|
2010-04-14 07:12:29 +08:00
|
|
|
irq = ip->irq_trans->irq_build(op->dev.of_node, irq,
|
2006-06-30 06:07:37 +08:00
|
|
|
ip->irq_trans->data);
|
[SPARC]: Fix OF register translations under sub-PCI busses.
There is an implicit assumption in the code that ranges will translate
to something that can fit in 2 32-bit cells, or a 64-bit value. For
certain kinds of things below PCI this isn't necessarily true.
Here is what the relevant OF device hierarchy looks like for one of
the serial controllers on an Ultra5:
Node 0xf005f1e0
ranges: 00000000.00000000.00000000.000001fe.01000000.00000000.01000000
01000000.00000000.00000000.000001fe.02000000.00000000.01000000
02000000.00000000.00000000.000001ff.00000000.00000001.00000000
03000000.00000000.00000000.000001ff.00000000.00000001.00000000
device_type: 'pci'
model: 'SUNW,sabre'
Node 0xf005f9d4
device_type: 'pci'
model: 'SUNW,simba'
Node 0xf0060d24
ranges: 00000010.00000000 82010810.00000000.f0000000 01000000
00000014.00000000 82010814.00000000.f1000000 00800000
name: 'ebus'
Node 0xf0062dac
reg: 00000014.003083f8.00000008 --> 0x1ff.f13083f8
device_type: 'serial'
name: 'su'
So the correct translation here is:
1) Match "su" register to second ranges entry of 'ebus', which translates
into a PCI triplet "82010814.00000000.f1000000" of size 00800000, which
gives us "82010814.00000000.f13083f8".
2) Pass-through "SUNW,simba" since it lacks ranges property
3) Match "82010814.00000000.f13083f8" to third ranges property of PCI
controller node 'SUNW,sabre', and we arrive at the final physical
MMIO address of "0x1fff13083f8".
Due to the 2-cell assumption, we couldn't translate to a PCI 3-cell
value, and we couldn't perform a pass-thru on it either.
It was easiest to just stop splitting the ranges application operation
between two methods, ->map and ->translate, and just let ->map do all
the work. That way it would work purely on 32-bit cell arrays instead
of having to "return" some value like a u64.
It's still not %100 correct because the out-of-range check is still
done using the 64 least significant bits of the range and address.
But it does work for all the cases I've thrown at it so far.
Signed-off-by: David S. Miller <davem@davemloft.net>
2006-07-13 14:19:31 +08:00
|
|
|
if (of_irq_verbose)
|
|
|
|
printk("%s: Apply IRQ trans [%s] %x --> %x\n",
|
2010-04-14 07:12:29 +08:00
|
|
|
op->dev.of_node->full_name, ip->full_name, orig_irq, irq);
|
2006-06-30 06:07:37 +08:00
|
|
|
|
2008-03-19 19:52:48 +08:00
|
|
|
out:
|
|
|
|
nid = of_node_to_nid(dp);
|
|
|
|
if (nid != -1) {
|
2011-05-17 04:38:07 +08:00
|
|
|
cpumask_t numa_mask;
|
2008-03-19 19:52:48 +08:00
|
|
|
|
2011-05-17 04:38:07 +08:00
|
|
|
cpumask_copy(&numa_mask, cpumask_of_node(nid));
|
2008-12-13 18:50:26 +08:00
|
|
|
irq_set_affinity(irq, &numa_mask);
|
2008-03-19 19:52:48 +08:00
|
|
|
}
|
|
|
|
|
2006-06-30 06:07:37 +08:00
|
|
|
return irq;
|
|
|
|
}
|
|
|
|
|
2010-07-23 06:04:30 +08:00
|
|
|
static struct platform_device * __init scan_one_device(struct device_node *dp,
|
2006-06-30 05:34:50 +08:00
|
|
|
struct device *parent)
|
|
|
|
{
|
2010-07-23 06:04:30 +08:00
|
|
|
struct platform_device *op = kzalloc(sizeof(*op), GFP_KERNEL);
|
2007-04-24 06:53:27 +08:00
|
|
|
const unsigned int *irq;
|
2007-07-19 13:03:25 +08:00
|
|
|
struct dev_archdata *sd;
|
2006-06-30 06:07:37 +08:00
|
|
|
int len, i;
|
2006-06-30 05:34:50 +08:00
|
|
|
|
|
|
|
if (!op)
|
|
|
|
return NULL;
|
|
|
|
|
2007-07-19 13:03:25 +08:00
|
|
|
sd = &op->dev.archdata;
|
|
|
|
sd->op = op;
|
|
|
|
|
2010-04-14 07:12:28 +08:00
|
|
|
op->dev.of_node = dp;
|
2006-06-30 05:34:50 +08:00
|
|
|
|
|
|
|
irq = of_get_property(dp, "interrupts", &len);
|
2006-06-30 06:07:37 +08:00
|
|
|
if (irq) {
|
2010-06-19 01:09:58 +08:00
|
|
|
op->archdata.num_irqs = len / 4;
|
2008-12-27 07:39:11 +08:00
|
|
|
|
|
|
|
/* Prevent overrunning the op->irqs[] array. */
|
2010-06-19 01:09:58 +08:00
|
|
|
if (op->archdata.num_irqs > PROMINTR_MAX) {
|
2008-12-27 07:39:11 +08:00
|
|
|
printk(KERN_WARNING "%s: Too many irqs (%d), "
|
|
|
|
"limiting to %d.\n",
|
2010-06-19 01:09:58 +08:00
|
|
|
dp->full_name, op->archdata.num_irqs, PROMINTR_MAX);
|
|
|
|
op->archdata.num_irqs = PROMINTR_MAX;
|
2008-12-27 07:39:11 +08:00
|
|
|
}
|
2010-06-19 01:09:58 +08:00
|
|
|
memcpy(op->archdata.irqs, irq, op->archdata.num_irqs * 4);
|
2006-06-30 06:07:37 +08:00
|
|
|
} else {
|
2010-06-19 01:09:58 +08:00
|
|
|
op->archdata.num_irqs = 0;
|
2006-06-30 06:07:37 +08:00
|
|
|
}
|
2006-06-30 05:34:50 +08:00
|
|
|
|
|
|
|
build_device_resources(op, parent);
|
2010-06-19 01:09:58 +08:00
|
|
|
for (i = 0; i < op->archdata.num_irqs; i++)
|
|
|
|
op->archdata.irqs[i] = build_one_device_irq(op, parent, op->archdata.irqs[i]);
|
2006-06-30 05:34:50 +08:00
|
|
|
|
|
|
|
op->dev.parent = parent;
|
2010-06-08 21:48:21 +08:00
|
|
|
op->dev.bus = &platform_bus_type;
|
2006-06-30 05:34:50 +08:00
|
|
|
if (!parent)
|
2008-05-02 12:02:41 +08:00
|
|
|
dev_set_name(&op->dev, "root");
|
2006-06-30 05:34:50 +08:00
|
|
|
else
|
2010-01-29 05:06:53 +08:00
|
|
|
dev_set_name(&op->dev, "%08x", dp->phandle);
|
2006-06-30 05:34:50 +08:00
|
|
|
|
|
|
|
if (of_device_register(op)) {
|
|
|
|
printk("%s: Could not register of device.\n",
|
|
|
|
dp->full_name);
|
|
|
|
kfree(op);
|
|
|
|
op = NULL;
|
|
|
|
}
|
|
|
|
|
|
|
|
return op;
|
|
|
|
}
|
|
|
|
|
|
|
|
static void __init scan_tree(struct device_node *dp, struct device *parent)
|
|
|
|
{
|
|
|
|
while (dp) {
|
2010-07-23 06:04:30 +08:00
|
|
|
struct platform_device *op = scan_one_device(dp, parent);
|
2006-06-30 05:34:50 +08:00
|
|
|
|
|
|
|
if (op)
|
|
|
|
scan_tree(dp->child, &op->dev);
|
|
|
|
|
|
|
|
dp = dp->sibling;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2010-06-08 21:48:21 +08:00
|
|
|
static int __init scan_of_devices(void)
|
2006-06-30 05:34:50 +08:00
|
|
|
{
|
|
|
|
struct device_node *root = of_find_node_by_path("/");
|
2010-07-23 06:04:30 +08:00
|
|
|
struct platform_device *parent;
|
2006-06-30 05:34:50 +08:00
|
|
|
|
|
|
|
parent = scan_one_device(root, NULL);
|
|
|
|
if (!parent)
|
2010-06-08 21:48:21 +08:00
|
|
|
return 0;
|
2006-06-30 05:34:50 +08:00
|
|
|
|
|
|
|
scan_tree(root->child, &parent->dev);
|
2010-06-08 21:48:21 +08:00
|
|
|
return 0;
|
2006-06-30 05:34:50 +08:00
|
|
|
}
|
2010-06-08 21:48:21 +08:00
|
|
|
postcore_initcall(scan_of_devices);
|
2006-06-23 16:44:10 +08:00
|
|
|
|
[SPARC]: Fix OF register translations under sub-PCI busses.
There is an implicit assumption in the code that ranges will translate
to something that can fit in 2 32-bit cells, or a 64-bit value. For
certain kinds of things below PCI this isn't necessarily true.
Here is what the relevant OF device hierarchy looks like for one of
the serial controllers on an Ultra5:
Node 0xf005f1e0
ranges: 00000000.00000000.00000000.000001fe.01000000.00000000.01000000
01000000.00000000.00000000.000001fe.02000000.00000000.01000000
02000000.00000000.00000000.000001ff.00000000.00000001.00000000
03000000.00000000.00000000.000001ff.00000000.00000001.00000000
device_type: 'pci'
model: 'SUNW,sabre'
Node 0xf005f9d4
device_type: 'pci'
model: 'SUNW,simba'
Node 0xf0060d24
ranges: 00000010.00000000 82010810.00000000.f0000000 01000000
00000014.00000000 82010814.00000000.f1000000 00800000
name: 'ebus'
Node 0xf0062dac
reg: 00000014.003083f8.00000008 --> 0x1ff.f13083f8
device_type: 'serial'
name: 'su'
So the correct translation here is:
1) Match "su" register to second ranges entry of 'ebus', which translates
into a PCI triplet "82010814.00000000.f1000000" of size 00800000, which
gives us "82010814.00000000.f13083f8".
2) Pass-through "SUNW,simba" since it lacks ranges property
3) Match "82010814.00000000.f13083f8" to third ranges property of PCI
controller node 'SUNW,sabre', and we arrive at the final physical
MMIO address of "0x1fff13083f8".
Due to the 2-cell assumption, we couldn't translate to a PCI 3-cell
value, and we couldn't perform a pass-thru on it either.
It was easiest to just stop splitting the ranges application operation
between two methods, ->map and ->translate, and just let ->map do all
the work. That way it would work purely on 32-bit cell arrays instead
of having to "return" some value like a u64.
It's still not %100 correct because the out-of-range check is still
done using the 64 least significant bits of the range and address.
But it does work for all the cases I've thrown at it so far.
Signed-off-by: David S. Miller <davem@davemloft.net>
2006-07-13 14:19:31 +08:00
|
|
|
static int __init of_debug(char *str)
|
|
|
|
{
|
|
|
|
int val = 0;
|
|
|
|
|
|
|
|
get_option(&str, &val);
|
|
|
|
if (val & 1)
|
|
|
|
of_resource_verbose = 1;
|
|
|
|
if (val & 2)
|
|
|
|
of_irq_verbose = 1;
|
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
|
|
|
|
__setup("of_debug=", of_debug);
|