* RE: [PATCH/2.6.17-rc4 1/10] Powerpc: Add general support for mpc7 448h pc2 (Taiga) platform
From: Zang Roy-r61911 @ 2006-05-18 7:12 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: linuxppc-dev list, Yang Xin-Xin-r48390, Paul Mackerras,
Alexandre.Bounine
> I'm not repeating Kumar's comments about that CONFIG_7xxx
> thing and that
> 7xxx/ directory, it should all go.
>
Should I move my code to embedded6xx?
> Some more bits:
>
> > +static u_char mpc7448_hpc2_pic_initsenses[] __initdata = {
> > + (IRQ_SENSE_LEVEL | IRQ_POLARITY_NEGATIVE), /*
> INT[0] XINT0 from FPGA */
> > + (IRQ_SENSE_LEVEL | IRQ_POLARITY_NEGATIVE), /*
> INT[1] XINT1 from FPGA */
> > + (IRQ_SENSE_LEVEL | IRQ_POLARITY_NEGATIVE), /*
> INT[2] PHY_INT from both GIGE */
> > + (IRQ_SENSE_LEVEL | IRQ_POLARITY_NEGATIVE), /*
> INT[3] RESERVED */
> > +};
> > +
> > +/*
> > + * mpc7448hpc2 PCI interrupt routing. all PCI interrupt comes from
> > + * external PCI source at 23. need to program pci
> interrupt control registers
> > + * to route per slot IRQs.
> > + */
> > +
> > +static inline int
> > +mpc7448_hpc2_map_irq(struct pci_dev *dev, unsigned char idsel,
> > + unsigned char pin)
> > +{
> > + static char pci_irq_table[][4] =
> > + /*
> > + * PCI IDSEL/INTPIN->INTLINE
> > + * A B C D
> > + */
> > + {
> > + {IRQ_PCI_INTA, IRQ_PCI_INTB, IRQ_PCI_INTC,
> IRQ_PCI_INTD}, /* A SLOT 1 IDSEL 17 */
> > + {IRQ_PCI_INTB, IRQ_PCI_INTC, IRQ_PCI_INTD,
> IRQ_PCI_INTA}, /* B SLOT 2 IDSEL 18 */
> > + {IRQ_PCI_INTC, IRQ_PCI_INTD, IRQ_PCI_INTA,
> IRQ_PCI_INTB}, /* C SATA IDSEL 19 */
> > + {IRQ_PCI_INTD, IRQ_PCI_INTA, IRQ_PCI_INTB,
> IRQ_PCI_INTC}, /* D USB IDSEL 20 */
> > + };
> > +
> > + const long min_idsel = 1, max_idsel = 4, irqs_per_slot = 4;
> > + return PCI_IRQ_TABLE_LOOKUP;
> > +}
>
> This whole irq map stuff is excactly what the device-tree is
> there for .
> Please implement proper interrupt maps in the device-tree and
> get rid of
> those tables.
I will get rid of those tables. I can see that in file
arch/powerpc/platforms/85xx/mpc85xx_ads.c (2.6.17-rc4), there is
a similar table. Should it be removed in future :)?
>
> > +static void __init mpc7448_hpc2_map_io(void)
> > +{
> > + /* PCI IO mapping */
> > + io_block_mapping(MPC7448_HPC2_PCI_IO_BASE_VIRT,
> > + MPC7448_HPC2_PCI_IO_BASE_PHYS,
> 0x00800000, _PAGE_IO);
> > + /* Tsi108 CSR mapping */
> > + io_block_mapping(TSI108_CSR_ADDR_VIRT, TSI108_CSR_ADDR_PHYS,
> > + 0x100000, _PAGE_IO);
> > +
> > + /* PCI Config mapping */
> > + io_block_mapping(MPC7448_HPC2_PCI_CFG_BASE_VIRT,
> > + MPC7448_HPC2_PCI_CFG_BASE_PHYS,
> > + MPC7448_HPC2_PCI_CFG_SIZE, _PAGE_IO);
> > +
> > + tsi108_pci_cfg_base = MPC7448_HPC2_PCI_CFG_BASE_VIRT;
> > + /* NVRAM mapping */
> > + io_block_mapping(MPC7448_HPC2_NVRAM_BASE_ADDR,
> > + MPC7448_HPC2_NVRAM_BASE_ADDR,
> MPC7448_HPC2_NVRAM_SIZE,
> > + _PAGE_IO);
> > +}
>
> io_block_mapping is bad ! see endless discussions in the archives of
> why ... Use ioremap.
OK!
>
> > +static int __init mpc7448_hpc2_probe(void)
> > +{
> > + /* We always match for now, eventually we should look
> at the flat
> > + dev tree to ensure this is the board we are suppose to run on
> > + */
> > + return 1;
> > +}
>
> Yes, please do so, we will not accept a board that does the above :)
I just do the same thing as 85xx :).
>
> > +extern int tsi108_direct_write_config(struct pci_bus *bus,
> unsigned int devfn,
> > + int offset, int len, u32 val);
> > +extern int tsi108_direct_read_config(struct pci_bus *bus,
> unsigned int devfn,
> > + int offset, int len, u32 * val);
> >
> > +void tsi108_clear_pci_error(u32 pci_cfg_base);
> > +
> > +extern int
> > +tsi108_read_config(int bus, unsigned int devfn, int
> offset, int len, u32 * val);
> > +#ifdef CONFIG_PCI
> > +static struct pci_ops direct_pci_ops = {
> > + tsi108_direct_read_config,
> > + tsi108_direct_write_config
> > +};
>
> That sounds bogus. You should instead have a tsi108_pci.c file that
> contains all of the functions _and_ the pci_ops structure
> (with a better
> name please) and exports some kind of setup_tsi108_pci(device_node *).
>
OK!
> > +void tsi108_clear_pci_cfg_error(void)
> > +{
> > + tsi108_clear_pci_error(MPC7448_HPC2_PCI_CFG_BASE_PHYS);
> > +}
> > +
> > +int __init add_bridge(struct device_node *dev)
> > +{
> > + int len;
> > + struct pci_controller *hose;
> > + struct resource rsrc;
> > + int *bus_range;
> > + int primary = 0, has_address = 0;
> > +
> > + DBG("TSI_PCI: %s tsi108_pci_cfg_base=0x%x\n", __FUNCTION__,
> > + tsi108_pci_cfg_base);
> > +
> > + /* Fetch host bridge registers address */
> > + has_address = (of_address_to_resource(dev, 0, &rsrc) == 0);
> > +
> > + /* Get bus range if any */
> > + bus_range = (int *)get_property(dev, "bus-range", &len);
> > + if (bus_range == NULL || len < 2 * sizeof(int)) {
> > + printk(KERN_WARNING "Can't get bus-range for %s, assume"
> > + " bus 0\n", dev->full_name);
> > + }
> > +
> > + hose = pcibios_alloc_controller();
> > +
> > + if (!hose) {
> > + printk("PCI Host bridge init failed\n");
> > + return -ENOMEM;
> > + }
> > + hose->arch_data = dev;
> > + hose->set_cfg_type = 1;
> > +
> > + hose->first_busno = bus_range ? bus_range[0] : 0;
> > + hose->last_busno = bus_range ? bus_range[1] : 0xff;
> > +
> > + (hose)->ops = &direct_pci_ops;
> > +
> > + printk(KERN_INFO "Found tsi108 PCI host bridge at 0x%08lx. "
> > + "Firmware bus number: %d->%d\n",
> > + rsrc.start, hose->first_busno, hose->last_busno);
> > +
> > + /* Interpret the "ranges" property */
> > + /* This also maps the I/O region and sets isa_io/mem_base */
> > + pci_process_bridge_OF_ranges(hose, dev, primary);
> > + return 0;
> > +
> > +}
>
> We need a generic add_bridge that goes through PCI bridges and
> instanciate based on their type as provided by the device-tree. You
> should try to work in that direction...
OK!
^ permalink raw reply
* RE: [PATCH/2.6.17-rc4 2/10] Powerpc: Add Tundra Semiconductor tsi 108 macro define
From: Zang Roy-r61911 @ 2006-05-18 7:16 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: linuxppc-dev list, Yang Xin-Xin-r48390, Paul Mackerras,
Alexandre.Bounine
>
> > +/* Error codes */
> > +
> > +#define MPIC_OK 0
> > +#define MPIC_ERROR 1
>
> What the heck are these for ?
>
> Ben.
I will remove them.
Roy
>
>
^ permalink raw reply
* RE: [PATCH/2.6.17-rc4 1/10] Powerpc: Add general support for mpc7 448h pc2 (Taiga) platform
From: Benjamin Herrenschmidt @ 2006-05-18 7:19 UTC (permalink / raw)
To: Zang Roy-r61911
Cc: linuxppc-dev list, Paul Mackerras, Alexandre.Bounine,
Yang Xin-Xin-r48390
In-Reply-To: <9FCDBA58F226D911B202000BDBAD4673062C05CC@zch01exm40.ap.freescale.net>
> Well , should I register this data to a platform device or the Ethernet
> driver get the information from device-tree directly?
You probably want to define a bus structure (/soc might work even if
it's not strictly a /soc) or use of_platform device to link a
device-tree node to a driver instance. You can create as many nodes as
you have devices and provide all the additional infos you need including
interrupt routing via the device-tree.
Ben.
^ permalink raw reply
* [PATCH] powerpc: the iSeries vio lan driver changed device type
From: Stephen Rothwell @ 2006-05-18 7:21 UTC (permalink / raw)
To: paulus; +Cc: ppc-dev
So the IOMMU table building code needs to match.
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
arch/powerpc/kernel/vio.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
This patch is relative to the four iSeries vio patches I sent on Moday.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
af5dbd2219106b6ce52b075485fca3c2a08cec58
diff --git a/arch/powerpc/kernel/vio.c b/arch/powerpc/kernel/vio.c
index ac5c7bf..b559cbd 100644
--- a/arch/powerpc/kernel/vio.c
+++ b/arch/powerpc/kernel/vio.c
@@ -71,7 +71,7 @@ static struct iommu_table *vio_build_iom
{
#ifdef CONFIG_PPC_ISERIES
if (firmware_has_feature(FW_FEATURE_ISERIES)) {
- if (strcmp(dev->type, "vlan") == 0)
+ if (strcmp(dev->type, "network") == 0)
return &veth_iommu_table;
return &vio_iommu_table;
} else
--
1.3.1.ge923
^ permalink raw reply related
* RE: [PATCH/2.6.17-rc4 1/10] Powerpc: Add general support for mpc7 448h pc2 (Taiga) platform
From: Benjamin Herrenschmidt @ 2006-05-18 7:22 UTC (permalink / raw)
To: Zang Roy-r61911
Cc: linuxppc-dev list, Yang Xin-Xin-r48390, Paul Mackerras,
Alexandre.Bounine
In-Reply-To: <9FCDBA58F226D911B202000BDBAD4673062C064E@zch01exm40.ap.freescale.net>
On Thu, 2006-05-18 at 15:12 +0800, Zang Roy-r61911 wrote:
> > I'm not repeating Kumar's comments about that CONFIG_7xxx
> > thing and that
> > 7xxx/ directory, it should all go.
> >
>
> Should I move my code to embedded6xx?
Probably for now yes.
> I will get rid of those tables. I can see that in file
> arch/powerpc/platforms/85xx/mpc85xx_ads.c (2.6.17-rc4), there is
> a similar table. Should it be removed in future :)?
Yes. And somebody beaten up for letting that stuff leak into
arch/powerpc :)
> > Yes, please do so, we will not accept a board that does the above :)
>
> I just do the same thing as 85xx :).
Yes and I intend to LART Kumar seriously for that next time I meet
him :)
> > We need a generic add_bridge that goes through PCI bridges and
> > instanciate based on their type as provided by the device-tree. You
> > should try to work in that direction...
I suggest you also read my comments to Mark A. Greer as most of that
stuff overlaps... I wish I had more times to work myself on that but I'm
fairly overflowed at the moment...
Ben
^ permalink raw reply
* Re: snd-aoa status update / automatic driver loading
From: Eddy Petrişor @ 2006-05-18 7:25 UTC (permalink / raw)
To: Johannes Berg; +Cc: linuxppc-dev list, debian-powerpc
In-Reply-To: <1147860564.14395.6.camel@johannes>
T24gNS8xNy8wNiwgSm9oYW5uZXMgQmVyZyA8am9oYW5uZXNAc2lwc29sdXRpb25zLm5ldD4gd3Jv
dGU6Cj4gSGV5LAo+Cj4gQ3VycmVudGx5IHNuZC1hb2EgaXMga25vd24gdG8gd29yayBvbiB0aGUg
Zm9sbG93aW5nIG1hY2hpbmVzOgo+ICogUG93ZXJCb29rNSw4Cj4gKiBQb3dlckJvb2s1LDcKPiAq
IFBvd2VyTWFjOCwxCj4gKiBQb3dlck1hYzgsMgo+ICogMTciIE9jdG9iZXIgMjAwNSBQb3dlckJv
b2sgKGRvbid0IGtub3cgdGhlIG51bWJlcikKPiAqIFBvd2VyTWFjMTEsMgo+ICogUG93ZXJCb29r
Niw4Cj4gYW5kIG15Cj4gKiBQb3dlckJvb2s1LDYKCkFueSBjaGFuY2UgZm9yIDUsMiA/IFdoYXQg
aXMgbmVlZGVkIGZvciBpdD8gQ29kZWMgb25seT8KCi0tIApSZWdhcmRzLApFZGR5UAo9PT09PT09
PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KIkltYWdpbmF0aW9uIGlzIG1v
cmUgaW1wb3J0YW50IHRoYW4ga25vd2xlZGdlIiBBLkVpbnN0ZWluCg==
^ permalink raw reply
* mm/rmap.c incompatible with ppc/kernel/dma-mapping.c?
From: Gerhard Pircher @ 2006-05-18 8:03 UTC (permalink / raw)
To: linuxppc-dev
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="us-ascii", Size: 2037 bytes --]
Hi,
Since I managed to compile in not cache coherent DMA support in the AmigaOne
Linux kernel, the system crashes whenever I try to view a movie for example
in totem or VLC. The following log snipped is the only debug information I
could extract, because most of the time the system hard locks and can only
be reactivated with a hardware reset.
May 12 00:04:17 localhost kernel: kernel BUG in page_add_file_rmap at
mm/rmap.c:387!
May 12 00:04:17 localhost kernel: Oops: Exception in kernel mode, sig: 5
[#1]
May 12 00:04:17 localhost kernel: NIP: C004968C LR: C0044CB8 SP: D2C77E20
REGS: d2c77d70 TRAP: 0700 Not tainted
May 12 00:04:17 localhost kernel: MSR: 00029032 EE: 1 PR: 0 FP: 0 ME: 1
IR/DR: 11
May 12 00:04:17 localhost kernel: TASK = d4918000[2900] 'totem' THREAD:
d2c76000Last syscall: 246
May 12 00:04:17 localhost kernel: GPR00: 00000001 D2C77E20 D4918000 C0D02720
00000000 D27B02A0 02000000 D4FE4400
May 12 00:04:17 localhost kernel: GPR08: C03D0000 38139785 00000000 38139785
24048444 10054698 00000000 10171158
May 12 00:04:17 localhost kernel: GPR16: 00000000 00000000 0EADDD7C 00015F90
000001F6 315B1970 33CA8000 D4D6BBA0
May 12 00:04:17 localhost kernel: GPR24: 00000000 00000000 02000000 D4B7D33C
33CA8000 C0D02720 38139785 D2888220
May 12 00:04:17 localhost kernel: NIP [c004968c] page_add_file_rmap+0x8/0x78
May 12 00:04:17 localhost kernel: LR [c0044cb8] do_no_page+0x1cc/0x37c
May 12 00:04:17 localhost kernel: Call trace:
May 12 00:04:17 localhost kernel: [c004503c] handle_mm_fault+0xf4/0x174
May 12 00:04:17 localhost kernel: [c0012100] do_page_fault+0x140/0x398
May 12 00:04:17 localhost kernel: [c0008178] handle_page_fault+0xc/0x80
I tested this with kernel 2.6.8 and 2.6.14.2. Both show the same behavior.
Is this a known problem on PPC systems with desktop CPUs? What about others
PPC boards that have 6xx/7xxx cpus and not cache coherent northbridges?
Thanks in advance!
regards,
Gerhard
--
Echte DSL-Flatrate dauerhaft für 0,- Euro*!
"Feel free" mit GMX DSL! http://www.gmx.net/de/go/dsl
^ permalink raw reply
* [PATCH] powerpc: Add of_parse_dma_window()
From: Jeremy Kerr @ 2006-05-18 8:05 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <1147933975.484840.681634501201.qpush@pokey>
Add a function for generic parsing of dma-window properties (ie,
ibm,dma-window and ibm,my-dma-window) of pci and virtual device nodes.
This function will also be used by cell.
Signed-off-by: Jeremy Kerr <jk@ozlabs.org>
---
Update: don't EXPORT_SYMBOL - dma-window won't be needed by a module
arch/powerpc/kernel/prom_parse.c | 22 ++++++++++++++++++++++
include/asm-powerpc/prom.h | 6 ++++++
2 files changed, 28 insertions(+)
Index: linux-2.6/arch/powerpc/kernel/prom_parse.c
===================================================================
--- linux-2.6.orig/arch/powerpc/kernel/prom_parse.c
+++ linux-2.6/arch/powerpc/kernel/prom_parse.c
@@ -548,3 +548,25 @@ int of_pci_address_to_resource(struct de
return __of_address_to_resource(dev, addrp, size, flags, r);
}
EXPORT_SYMBOL_GPL(of_pci_address_to_resource);
+
+void of_parse_dma_window(struct device_node *dn, unsigned char *dma_window_prop,
+ unsigned long *busno, unsigned long *phys, unsigned long *size)
+{
+ u32 *dma_window, cells;
+ unsigned char *prop;
+
+ dma_window = (u32 *)dma_window_prop;
+
+ /* busno is always one cell */
+ *busno = *(dma_window++);
+
+ prop = get_property(dn, "ibm,#dma-address-cells", NULL);
+ cells = prop ? *(u32 *)prop : prom_n_addr_cells(dn);
+ *phys = of_read_addr(dma_window, cells);
+
+ dma_window += cells;
+
+ prop = get_property(dn, "ibm,#dma-size-cells", NULL);
+ cells = prop ? *(u32 *)prop : prom_n_size_cells(dn);
+ *size = of_read_addr(dma_window, cells);
+}
Index: linux-2.6/include/asm-powerpc/prom.h
===================================================================
--- linux-2.6.orig/include/asm-powerpc/prom.h
+++ linux-2.6/include/asm-powerpc/prom.h
@@ -230,6 +230,12 @@ extern int of_address_to_resource(struct
extern int of_pci_address_to_resource(struct device_node *dev, int bar,
struct resource *r);
+/* Parse the ibm,dma-window property of an OF node into the busno, phys and
+ * size parameters.
+ */
+void of_parse_dma_window(struct device_node *dn, unsigned char *dma_window_prop,
+ unsigned long *busno, unsigned long *phys, unsigned long *size);
+
extern void kdump_move_device_tree(void);
#endif /* __KERNEL__ */
^ permalink raw reply
* RE: [PATCH/2.6.17-rc4 1/10] Powerpc: Add general support for mpc7 448h pc2 (Taiga) platform
From: Zang Roy-r61911 @ 2006-05-18 8:05 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: linuxppc-dev list, Paul Mackerras, Alexandre.Bounine,
Yang Xin-Xin-r48390
>
> > The tsi108 serial port is not a sub node of "soc". well, any way,
> > I can try soc!
>
> What is it ? Where is it ? "soc" is a bit of a generic name for
> something in the device-tree in fact... we might want to
> define a way to
> expose any bus via some kind of soc mecanism even if it's not a root
> bus.
>
>
Should I just use add_legacy_soc_port() instead of a new function
add_legacy_tsi_port()?
--- arch/powerpc/kernel/legacy_serial.c.orig Thu May 18 15:35:19 2006
+++ arch/powerpc/kernel/legacy_serial.c Thu May 18 15:50:38 2006
@@ -302,6 +302,17 @@ void __init find_legacy_serial_ports(voi
of_node_put(isa);
}
+ /* First fill our array with tsi-bridge ports */
+ for (np = NULL; (np = of_find_compatible_node(np, "serial", "ns16550")) != NULL;) {
+ struct device_node *tsi = of_get_parent(np);
+ if (tsi && !strcmp(tsi->type, "tsi-bridge")) {
+ index = add_legacy_soc_port(np, np);
+ if (index >= 0 && np == stdout)
+ legacy_serial_console = index;
+ }
+ of_node_put(tsi);
+ }
+
#ifdef CONFIG_PCI
/* Next, try to locate PCI ports */
for (np = NULL; (np = of_find_all_nodes(np));)
^ permalink raw reply
* [PATCH] powerpc: pseries: Use generic dma-window parsing function
From: Jeremy Kerr @ 2006-05-18 8:06 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <1147933975.516311.850847048300.qpush@pokey>
Change the pseries iommu init code to use the new of_parse_dma_window()
to parse the ibm,dma-window and ibm,my-dma-window properties of pci and
virtual device nodes.
Also, clean up vio_build_iommu_table() a little.
Tested on pseries, with both vio and pci devices.
Signed-off-by: Jeremy Kerr <jk@ozlabs.org>
---
Update: rebase to current powerpc head: vio driver has been merged
arch/powerpc/kernel/vio.c | 36 ++++++++++++---------------------
arch/powerpc/platforms/pseries/iommu.c | 29 +++++++++-----------------
2 files changed, 24 insertions(+), 41 deletions(-)
Index: linux-2.6/arch/powerpc/platforms/pseries/iommu.c
===================================================================
--- linux-2.6.orig/arch/powerpc/platforms/pseries/iommu.c
+++ linux-2.6/arch/powerpc/platforms/pseries/iommu.c
@@ -281,30 +281,22 @@ static void iommu_table_setparms(struct
* iommu_table_setparms_lpar
*
* Function: On pSeries LPAR systems, return TCE table info, given a pci bus.
- *
- * ToDo: properly interpret the ibm,dma-window property. The definition is:
- * logical-bus-number (1 word)
- * phys-address (#address-cells words)
- * size (#cell-size words)
- *
- * Currently we hard code these sizes (more or less).
*/
static void iommu_table_setparms_lpar(struct pci_controller *phb,
struct device_node *dn,
struct iommu_table *tbl,
- unsigned int *dma_window)
+ unsigned char *dma_window)
{
+ unsigned long offset, size;
+
tbl->it_busno = PCI_DN(dn)->bussubno;
+ of_parse_dma_window(dn, dma_window, &tbl->it_index, &offset, &size);
- /* TODO: Parse field size properties properly. */
- tbl->it_size = (((unsigned long)dma_window[4] << 32) |
- (unsigned long)dma_window[5]) >> PAGE_SHIFT;
- tbl->it_offset = (((unsigned long)dma_window[2] << 32) |
- (unsigned long)dma_window[3]) >> PAGE_SHIFT;
tbl->it_base = 0;
- tbl->it_index = dma_window[0];
tbl->it_blocksize = 16;
tbl->it_type = TCE_PCI;
+ tbl->it_offset = offset >> PAGE_SHIFT;
+ tbl->it_size = size >> PAGE_SHIFT;
}
static void iommu_bus_setup_pSeries(struct pci_bus *bus)
@@ -396,7 +388,7 @@ static void iommu_bus_setup_pSeriesLP(st
struct iommu_table *tbl;
struct device_node *dn, *pdn;
struct pci_dn *ppci;
- unsigned int *dma_window = NULL;
+ unsigned char *dma_window = NULL;
DBG("iommu_bus_setup_pSeriesLP, bus %p, bus->self %p\n", bus, bus->self);
@@ -404,7 +396,7 @@ static void iommu_bus_setup_pSeriesLP(st
/* Find nearest ibm,dma-window, walking up the device tree */
for (pdn = dn; pdn != NULL; pdn = pdn->parent) {
- dma_window = (unsigned int *)get_property(pdn, "ibm,dma-window", NULL);
+ dma_window = get_property(pdn, "ibm,dma-window", NULL);
if (dma_window != NULL)
break;
}
@@ -498,7 +490,7 @@ static void iommu_dev_setup_pSeriesLP(st
{
struct device_node *pdn, *dn;
struct iommu_table *tbl;
- int *dma_window = NULL;
+ unsigned char *dma_window = NULL;
struct pci_dn *pci;
DBG("iommu_dev_setup_pSeriesLP, dev %p (%s)\n", dev, pci_name(dev));
@@ -513,8 +505,7 @@ static void iommu_dev_setup_pSeriesLP(st
for (pdn = dn; pdn && PCI_DN(pdn) && !PCI_DN(pdn)->iommu_table;
pdn = pdn->parent) {
- dma_window = (unsigned int *)
- get_property(pdn, "ibm,dma-window", NULL);
+ dma_window = get_property(pdn, "ibm,dma-window", NULL);
if (dma_window)
break;
}
Index: linux-2.6/arch/powerpc/kernel/vio.c
===================================================================
--- linux-2.6.orig/arch/powerpc/kernel/vio.c
+++ linux-2.6/arch/powerpc/kernel/vio.c
@@ -77,36 +77,28 @@ static struct iommu_table *vio_build_iom
} else
#endif
{
- unsigned int *dma_window;
- struct iommu_table *newTceTable;
- unsigned long offset;
- int dma_window_property_size;
-
- dma_window = (unsigned int *)get_property(
- dev->dev.platform_data, "ibm,my-dma-window",
- &dma_window_property_size);
+ unsigned char *dma_window;
+ struct iommu_table *tbl;
+ unsigned long offset, size;
+
+ dma_window = get_property(dev->dev.platform_data,
+ "ibm,my-dma-window", NULL);
if (!dma_window)
return NULL;
- newTceTable = kmalloc(sizeof(struct iommu_table), GFP_KERNEL);
+ tbl = kmalloc(sizeof(*tbl), GFP_KERNEL);
- /*
- * There should be some code to extract the phys-encoded
- * offset using prom_n_addr_cells(). However, according to
- * a comment on earlier versions, it's always zero, so we
- * don't bother
- */
- offset = dma_window[1] >> PAGE_SHIFT;
+ of_parse_dma_window(dev->dev.platform_data, dma_window,
+ &tbl->it_index, &offset, &size);
/* TCE table size - measured in tce entries */
- newTceTable->it_size = dma_window[4] >> PAGE_SHIFT;
+ tbl->it_size = size >> PAGE_SHIFT;
/* offset for VIO should always be 0 */
- newTceTable->it_offset = offset;
- newTceTable->it_busno = 0;
- newTceTable->it_index = (unsigned long)dma_window[0];
- newTceTable->it_type = TCE_VB;
+ tbl->it_offset = offset >> PAGE_SHIFT;
+ tbl->it_busno = 0;
+ tbl->it_type = TCE_VB;
- return iommu_init_table(newTceTable);
+ return iommu_init_table(tbl);
}
}
^ permalink raw reply
* Re: snd-aoa status update / automatic driver loading
From: Rene Rebe @ 2006-05-18 8:56 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Johannes Berg
In-Reply-To: <1147860564.14395.6.camel@johannes>
Hi,
thanks for the update. Is record/capture supost to work now?
Yours,
=2D-=20
Ren=E9 Rebe - Rubensstr. 64 - 12157 Berlin (Europe / Germany)
http://exactcode.de | http://t2-project.org | http://rebe.name
+49 (0)30 / 255 897 45
^ permalink raw reply
* RE: [PATCH/2.6.17-rc4 7/10] Powerpc: workaround for tsi108 pci c onfi g read exception
From: Zang Roy-r61911 @ 2006-05-18 9:45 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: linuxppc-dev list, Yang Xin-Xin-r48390, Paul Mackerras,
Alexandre.Bounine
>
> On Wed, 2006-05-17 at 18:14 +0800, Zang Roy-r61911 wrote:
> > Workaround for Tundra Semiconductor tsi108 host bridge pci
> config read
> > exception
>
> Use ppc_md.machine_check_exception instead of modifying the generic
> traps.c. Also make sure you can't configure your chip not to issue
> machine checks on target/master aborts on config space accesses....
>
> Ben.
I will try ppc_md.machine_check_exception. I am sure this machine check is
needed. I can not pass the pci probe, if I comment off this code.
Roy.
>
> > Signed-off-by: Alexandre Bounine <alexandreb@tundra.com>
> > Signed-off-by: Roy Zang <tie-fei.zang@freescale.com>
> >
> > ---
> >
> > arch/powerpc/kernel/traps.c | 13 +++++++++++++
> > 1 files changed, 13 insertions(+), 0 deletions(-)
> >
> > 0575fbe21e4f1045528bb91ec4b34bb7955c4a92
> > diff --git a/arch/powerpc/kernel/traps.c
> b/arch/powerpc/kernel/traps.c
> > index 064a525..7468d76 100644
> > --- a/arch/powerpc/kernel/traps.c
> > +++ b/arch/powerpc/kernel/traps.c
> > @@ -262,6 +262,19 @@ #if defined(CONFIG_PPC_PMAC) && defined(
> > }
> > }
> > #endif /* CONFIG_PPC_PMAC && CONFIG_PPC32 */
> > +
> > +#ifdef CONFIG_TSI108_BRIDGE
> > + extern void tsi108_clear_pci_cfg_error(void);
> > + const struct exception_table_entry *entry;
> > +
> > + /* Are we prepared to handle this fault? */
> > + if ((entry = search_exception_tables(regs->nip)) != NULL) {
> > + tsi108_clear_pci_cfg_error();
> > + regs->msr |= MSR_RI;
> > + regs->nip = entry->fixup;
> > + return 1;
> > + }
> > +#endif /* CONFIG_TSI108_BRIDGE */
> > return 0;
> > }
> >
>
^ permalink raw reply
* Re: snd-aoa status update / automatic driver loading
From: Johannes Berg @ 2006-05-18 10:08 UTC (permalink / raw)
To: Rene Rebe; +Cc: linuxppc-dev
In-Reply-To: <200605181056.35768.rene@exactcode.de>
[-- Attachment #1: Type: text/plain, Size: 169 bytes --]
On Thu, 2006-05-18 at 10:56 +0200, Rene Rebe wrote:
> thanks for the update. Is record/capture supost to work now?
Yes, that was a pretty stupid bug.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 793 bytes --]
^ permalink raw reply
* Re: snd-aoa status update / automatic driver loading
From: Johannes Berg @ 2006-05-18 10:13 UTC (permalink / raw)
To: Wolfgang Pfeiffer; +Cc: linuxppc-dev list, debian-powerpc
In-Reply-To: <20060517221945.GA2902@localhost>
[-- Attachment #1: Type: text/plain, Size: 169 bytes --]
On Thu, 2006-05-18 at 00:19 +0200, Wolfgang Pfeiffer wrote:
> changed /etc/modules to explicitly load only i2sbus:
Even that should not be necessary.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 793 bytes --]
^ permalink raw reply
* Re: snd-aoa status update / automatic driver loading
From: Johannes Berg @ 2006-05-18 10:14 UTC (permalink / raw)
To: Andreas Schwab; +Cc: linuxppc-dev list, debian-powerpc
In-Reply-To: <jey7x04edq.fsf@sykes.suse.de>
[-- Attachment #1: Type: text/plain, Size: 292 bytes --]
On Wed, 2006-05-17 at 21:53 +0200, Andreas Schwab wrote:
> /* PowerBook6,7 */
> { .layout_id = 92,
> .codecs[0] = {
> .name = "tas",
> .connections = tas_connections_nolineout,
> },
> },
Thanks, I'll add that.
Autodetection will come some time too :)
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 793 bytes --]
^ permalink raw reply
* RE: [PATCH/2.6.17-rc4 1/10] Powerpc: Add general support for mpc7 448h pc2 (Taiga) platform
From: Zang Roy-r61911 @ 2006-05-18 10:21 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: linuxppc-dev list, Yang Xin-Xin-r48390, Paul Mackerras,
Alexandre.Bounine
> On Thu, 2006-05-18 at 15:12 +0800, Zang Roy-r61911 wrote:
> > > I'm not repeating Kumar's comments about that CONFIG_7xxx
> > > thing and that
> > > 7xxx/ directory, it should all go.
> > >
> >
> > Should I move my code to embedded6xx?
>
> Probably for now yes.
I can migrate my code to embedded6xx technically. In fact,
I can move it into anywhere in the arch/powerpc/platforms.
While for mpc7448hpc2(taiga) board, it is not a embedded
application board. It is a high performance server! It seems
odd to put code there :). What's your opinion?
^ permalink raw reply
* Re: snd-aoa status update / automatic driver loading
From: Johannes Berg @ 2006-05-18 10:23 UTC (permalink / raw)
To: Eddy Petrişor; +Cc: linuxppc-dev list, debian-powerpc
In-Reply-To: <60381eeb0605180025v2495715scb345d7067518ecc@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 379 bytes --]
On Thu, 2006-05-18 at 10:25 +0300, Eddy Petrişor wrote:
> Any chance for 5,2 ? What is needed for it? Codec only?
I don't know. If you try loading the modules, the kernel will tell you
something about an unhandled layout id. Alternatively, you can find the
layout-id file in your /proc/device-tree/ and tell me the number in it.
The rest I can figure out.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 793 bytes --]
^ permalink raw reply
* RE: [HACK] add sandpoint + flattened dt support to arch/powerpc/b oot
From: Zang Roy-r61911 @ 2006-05-18 10:24 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Mark A. Greer; +Cc: linuxppc-dev
> > diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
> > index 6729c98..de09eac 100644
> > --- a/arch/powerpc/Kconfig
> > +++ b/arch/powerpc/Kconfig
> > @@ -323,7 +323,10 @@ config PPC_ISERIES
> >
> > config EMBEDDED6xx
> > bool "Embedded 6xx/7xx/7xxx-based board"
> > - depends on PPC32 && BROKEN
> > + depends on PPC32
> > + select PPC_UDBG_16550
> > + select MPIC
> > + select MPIC_SERIAL
>
> Not totally related to your patch but I'm tempted to turn that into a
> "Generic 6xx/7xx/7xxx" rather than "embedded" if we manage to always
> avoid board specific code most of the time, but instead add necessary
> bits in the device-tree. We still need a per-board Kconfig option I
> think that will just select the necessary bits and pieces
> (and more than
> one can be selected at one time). Also, I think right now,
> the embedded
> stuff is +/- exclusive from the MULTIPLATFORM stuff, that
> must be fixed
> asap. We are all living in the same kernel now :)
config Embedded6xx is not accurate. It can not cover all the
board with 7xx/7xxx based processor.
^ permalink raw reply
* RE: [PATCH/2.6.17-rc4 1/10] Powerpc: Add general support for mpc7 448h pc2 (Taiga) platform
From: Benjamin Herrenschmidt @ 2006-05-18 10:35 UTC (permalink / raw)
To: Zang Roy-r61911
Cc: linuxppc-dev list, Yang Xin-Xin-r48390, Paul Mackerras,
Alexandre.Bounine
In-Reply-To: <9FCDBA58F226D911B202000BDBAD4673062C0A97@zch01exm40.ap.freescale.net>
On Thu, 2006-05-18 at 18:21 +0800, Zang Roy-r61911 wrote:
> > On Thu, 2006-05-18 at 15:12 +0800, Zang Roy-r61911 wrote:
> > > > I'm not repeating Kumar's comments about that CONFIG_7xxx
> > > > thing and that
> > > > 7xxx/ directory, it should all go.
> > > >
> > >
> > > Should I move my code to embedded6xx?
> >
> > Probably for now yes.
>
> I can migrate my code to embedded6xx technically. In fact,
> I can move it into anywhere in the arch/powerpc/platforms.
> While for mpc7448hpc2(taiga) board, it is not a embedded
> application board. It is a high performance server! It seems
> odd to put code there :). What's your opinion?
I think we should do a platform/generic for boards that don't need more
than a single platform file, which I think will be the case once we are
done with your port ;)
Ben.
^ permalink raw reply
* RE: [HACK] add sandpoint + flattened dt support to arch/powerpc/b oot
From: Benjamin Herrenschmidt @ 2006-05-18 10:36 UTC (permalink / raw)
To: Zang Roy-r61911; +Cc: linuxppc-dev
In-Reply-To: <9FCDBA58F226D911B202000BDBAD4673062C0A9D@zch01exm40.ap.freescale.net>
On Thu, 2006-05-18 at 18:24 +0800, Zang Roy-r61911 wrote:
> > > diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
> > > index 6729c98..de09eac 100644
> > > --- a/arch/powerpc/Kconfig
> > > +++ b/arch/powerpc/Kconfig
> > > @@ -323,7 +323,10 @@ config PPC_ISERIES
> > >
> > > config EMBEDDED6xx
> > > bool "Embedded 6xx/7xx/7xxx-based board"
> > > - depends on PPC32 && BROKEN
> > > + depends on PPC32
> > > + select PPC_UDBG_16550
> > > + select MPIC
> > > + select MPIC_SERIAL
> >
> > Not totally related to your patch but I'm tempted to turn that into a
> > "Generic 6xx/7xx/7xxx" rather than "embedded" if we manage to always
> > avoid board specific code most of the time, but instead add necessary
> > bits in the device-tree. We still need a per-board Kconfig option I
> > think that will just select the necessary bits and pieces
> > (and more than
> > one can be selected at one time). Also, I think right now,
> > the embedded
> > stuff is +/- exclusive from the MULTIPLATFORM stuff, that
> > must be fixed
> > asap. We are all living in the same kernel now :)
>
> config Embedded6xx is not accurate. It can not cover all the
> board with 7xx/7xxx based processor.
Forget about CONFIG_EMBEDDED6xx, just do your own CONFIG_BOARDNAME for
now, the processor is irrelevant as long as it's a 6xx/7xx/7xxx
derivative.
Ben.
^ permalink raw reply
* RE: [PATCH/2.6.17-rc4 1/10] Powerpc: Add general support for mpc7 448h pc2 (Taiga) platform
From: Paul Mackerras @ 2006-05-18 10:39 UTC (permalink / raw)
To: Zang Roy-r61911; +Cc: Yang Xin-Xin-r48390, Alexandre.Bounine, linuxppc-dev list
In-Reply-To: <9FCDBA58F226D911B202000BDBAD4673062C0A97@zch01exm40.ap.freescale.net>
Zang Roy-r61911 writes:
> I can migrate my code to embedded6xx technically. In fact,
> I can move it into anywhere in the arch/powerpc/platforms.
> While for mpc7448hpc2(taiga) board, it is not a embedded
> application board. It is a high performance server! It seems
> odd to put code there :). What's your opinion?
What sort of machine(s) is this board used in? Or what machines will
it be in?
Paul.
^ permalink raw reply
* Re: PowerMac7,3 sound (was: PowerBook5,4 -- no sound?)
From: Johannes Berg @ 2006-05-18 10:39 UTC (permalink / raw)
To: Andreas Schwab; +Cc: linuxppc-dev
In-Reply-To: <je3bf85twf.fsf@sykes.suse.de>
[-- Attachment #1: Type: text/plain, Size: 807 bytes --]
On Wed, 2006-05-17 at 21:32 +0200, Andreas Schwab wrote:
> I have the following sound resources in /proc/iomem:
>
> 80008000-800083ff : 0.00010000:i2s
> 80008000-800083ff : Sound DMA
> 80010000-80010fff : 0.00010000:i2s
> 80010000-80010fff : Sound Control
>
> I'm not sure whether the first mapping should be split, but I don't know
> much about how resource mappings work.
That looks like you have snd-powermac loaded, or some other driver,
otherwise it shouldn't show up in /proc/iomem at all. It isn't my
driver, because it would generated 'i2sbus ...' names there.
> The layout id is 36, and it has both line out and headphone, detected as a
> Snapper.
Hmm. What's that again? tas3004 or 3001? I'll look at the OSX layout
file.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 793 bytes --]
^ permalink raw reply
* RE: [HACK] add sandpoint + flattened dt support to arch/powerpc/b oot
From: Zang Roy-r61911 @ 2006-05-18 10:47 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev
> On Thu, 2006-05-18 at 18:24 +0800, Zang Roy-r61911 wrote:
> > > > diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
> > > > index 6729c98..de09eac 100644
> > > > --- a/arch/powerpc/Kconfig
> > > > +++ b/arch/powerpc/Kconfig
> > > > @@ -323,7 +323,10 @@ config PPC_ISERIES
> > > >
> > > > config EMBEDDED6xx
> > > > bool "Embedded 6xx/7xx/7xxx-based board"
> > > > - depends on PPC32 && BROKEN
> > > > + depends on PPC32
> > > > + select PPC_UDBG_16550
> > > > + select MPIC
> > > > + select MPIC_SERIAL
> > >
> > > Not totally related to your patch but I'm tempted to turn
> that into a
> > > "Generic 6xx/7xx/7xxx" rather than "embedded" if we
> manage to always
> > > avoid board specific code most of the time, but instead
> add necessary
> > > bits in the device-tree. We still need a per-board
> Kconfig option I
> > > think that will just select the necessary bits and pieces
> > > (and more than
> > > one can be selected at one time). Also, I think right now,
> > > the embedded
> > > stuff is +/- exclusive from the MULTIPLATFORM stuff, that
> > > must be fixed
> > > asap. We are all living in the same kernel now :)
> >
> > config Embedded6xx is not accurate. It can not cover all the
> > board with 7xx/7xxx based processor.
>
> Forget about CONFIG_EMBEDDED6xx, just do your own CONFIG_BOARDNAME for
> now, the processor is irrelevant as long as it's a 6xx/7xx/7xxx
> derivative.
>
> Ben.
>
>
I can just do as your suggestion!
^ permalink raw reply
* RE: [PATCH/2.6.17-rc4 1/10] Powerpc: Add general support for mpc7 448h pc2 (Taiga) platform
From: Zang Roy-r61911 @ 2006-05-18 10:49 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: linuxppc-dev list, Yang Xin-Xin-r48390, Paul Mackerras,
Alexandre.Bounine
> On Thu, 2006-05-18 at 18:21 +0800, Zang Roy-r61911 wrote:
> > > On Thu, 2006-05-18 at 15:12 +0800, Zang Roy-r61911 wrote:
> > > > > I'm not repeating Kumar's comments about that CONFIG_7xxx
> > > > > thing and that
> > > > > 7xxx/ directory, it should all go.
> > > > >
> > > >
> > > > Should I move my code to embedded6xx?
> > >
> > > Probably for now yes.
> >
> > I can migrate my code to embedded6xx technically. In fact,
> > I can move it into anywhere in the arch/powerpc/platforms.
> > While for mpc7448hpc2(taiga) board, it is not a embedded
> > application board. It is a high performance server! It seems
> > odd to put code there :). What's your opinion?
>
> I think we should do a platform/generic for boards that don't
> need more
> than a single platform file, which I think will be the case
> once we are
> done with your port ;)
>
> Ben.
>
>
I will implement my board port as early as I can
according to the feedback :).
^ permalink raw reply
* Re: [PATCH] Fix do_mlock so page alignment is to hugepage boundries when needed
From: Hugh Dickins @ 2006-05-18 11:13 UTC (permalink / raw)
To: Eric Paris; +Cc: discuss, linux-kernel, wli, linuxppc-dev
In-Reply-To: <1147895964.26468.35.camel@localhost.localdomain>
On Wed, 17 May 2006, Eric Paris wrote:
>
> This patch still solves the problem of the kernel currently being more
> restrictive on what we accept from userspace for the length of the mlock
> if it is a hugepage rather than a regular page. With a regular page we
> will round the value from userspace and happily go about our business of
> mlocking. For a hugepage it just rejects it if userspace doesn't align
> it themselves. This allows the kernel to do the same work for hugepages
> that it does for normal pages.
You do have a point that there's an inconsistency there. But we could
argue a long time what's inconsistent with what - I'd say it's mlock
being inconsistent with mprotect, munmap, msync, madvise, etc. I
don't see an outright reason to change from the current behaviour.
You do realize that there's almost no point in mlocking a hugepage area
anyway? (I wrote that first without the "almost", but now with hugepage
faulting, it does provide another way to fault in all the pages at once.)
Hugh
^ 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