* [PATCH 06/15] [POWERPC] Added self_busno to indicate which bus number the PHB is
From: Kumar Gala @ 2007-06-27 1:16 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <11829070111239-git-send-email-galak@kernel.crashing.org>
Added self_busno to pci_controller and indirect PCI ops to be set by
board code to indicate which bus number to use when talking to the PHB.
By default we use zero since the majority of controllers that have
implicit mechanisms to talk to the PHBs use a bus number of zero.
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
---
arch/powerpc/sysdev/indirect_pci.c | 12 ++++++++++--
include/asm-ppc/pci-bridge.h | 1 +
2 files changed, 11 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/sysdev/indirect_pci.c b/arch/powerpc/sysdev/indirect_pci.c
index 3dedf8f..d490e71 100644
--- a/arch/powerpc/sysdev/indirect_pci.c
+++ b/arch/powerpc/sysdev/indirect_pci.c
@@ -33,6 +33,7 @@ indirect_read_config(struct pci_bus *bus, unsigned int devfn, int offset,
struct pci_controller *hose = bus->sysdata;
volatile void __iomem *cfg_data;
u8 cfg_type = 0;
+ u32 bus_no;
if (ppc_md.pci_exclude_device)
if (ppc_md.pci_exclude_device(hose, bus->number, devfn))
@@ -42,8 +43,11 @@ indirect_read_config(struct pci_bus *bus, unsigned int devfn, int offset,
if (bus->number != hose->first_busno)
cfg_type = 1;
+ bus_no = (bus->number == hose->first_busno) ?
+ hose->self_busno : bus->number - hose->bus_offset;
+
PCI_CFG_OUT(hose->cfg_addr,
- (0x80000000 | ((bus->number - hose->bus_offset) << 16)
+ (0x80000000 | (bus_no << 16)
| (devfn << 8) | ((offset & 0xfc) | cfg_type)));
/*
@@ -72,6 +76,7 @@ indirect_write_config(struct pci_bus *bus, unsigned int devfn, int offset,
struct pci_controller *hose = bus->sysdata;
volatile void __iomem *cfg_data;
u8 cfg_type = 0;
+ u32 bus_no;
if (ppc_md.pci_exclude_device)
if (ppc_md.pci_exclude_device(hose, bus->number, devfn))
@@ -81,8 +86,11 @@ indirect_write_config(struct pci_bus *bus, unsigned int devfn, int offset,
if (bus->number != hose->first_busno)
cfg_type = 1;
+ bus_no = (bus->number == hose->first_busno) ?
+ hose->self_busno : bus->number - hose->bus_offset;
+
PCI_CFG_OUT(hose->cfg_addr,
- (0x80000000 | ((bus->number - hose->bus_offset) << 16)
+ (0x80000000 | (bus_no << 16)
| (devfn << 8) | ((offset & 0xfc) | cfg_type)));
/*
diff --git a/include/asm-ppc/pci-bridge.h b/include/asm-ppc/pci-bridge.h
index 4d35b84..2c2abda 100644
--- a/include/asm-ppc/pci-bridge.h
+++ b/include/asm-ppc/pci-bridge.h
@@ -47,6 +47,7 @@ struct pci_controller {
int first_busno;
int last_busno;
+ int self_busno;
int bus_offset;
void __iomem *io_base_virt;
--
1.5.2.1
^ permalink raw reply related
* [PATCH 05/15] [POWERPC] Remove bus_offset in places its not really used
From: Kumar Gala @ 2007-06-27 1:16 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <11829070102887-git-send-email-galak@kernel.crashing.org>
The user of the fsl_pcie code doesn't set bus_offset and 82xx doesn't
require it either. Remove the places in the code that reference it so
we can remove it all together.
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
---
arch/powerpc/platforms/82xx/mpc82xx_ads.c | 1 -
arch/powerpc/sysdev/fsl_pcie.c | 8 ++++----
2 files changed, 4 insertions(+), 5 deletions(-)
diff --git a/arch/powerpc/platforms/82xx/mpc82xx_ads.c b/arch/powerpc/platforms/82xx/mpc82xx_ads.c
index 715107b..d1e0919 100644
--- a/arch/powerpc/platforms/82xx/mpc82xx_ads.c
+++ b/arch/powerpc/platforms/82xx/mpc82xx_ads.c
@@ -552,7 +552,6 @@ static void __init mpc82xx_add_bridge(struct device_node *np)
hose->first_busno = bus_range ? bus_range[0] : 0;
hose->last_busno = bus_range ? bus_range[1] : 0xff;
- hose->bus_offset = 0;
setup_indirect_pci(hose,
r.start + offsetof(pci_cpm2_t, pci_cfg_addr),
diff --git a/arch/powerpc/sysdev/fsl_pcie.c b/arch/powerpc/sysdev/fsl_pcie.c
index 6bbd7f8..ea3ec6b 100644
--- a/arch/powerpc/sysdev/fsl_pcie.c
+++ b/arch/powerpc/sysdev/fsl_pcie.c
@@ -50,12 +50,12 @@ indirect_read_config_pcie(struct pci_bus *bus, unsigned int devfn, int offset,
if (bus->number == 0xff) {
PCI_CFG_OUT(hose->cfg_addr,
(0x80000000 | ((offset & 0xf00) << 16) |
- ((bus->number - hose->bus_offset) << 16)
+ (bus->number<< 16)
| (devfn << 8) | ((offset & 0xfc) )));
} else {
PCI_CFG_OUT(hose->cfg_addr,
(0x80000001 | ((offset & 0xf00) << 16) |
- ((bus->number - hose->bus_offset) << 16)
+ (bus->number<< 16)
| (devfn << 8) | ((offset & 0xfc) )));
}
@@ -101,12 +101,12 @@ indirect_write_config_pcie(struct pci_bus *bus, unsigned int devfn, int offset,
if (bus->number == 0xff) {
PCI_CFG_OUT(hose->cfg_addr,
(0x80000000 | ((offset & 0xf00) << 16) |
- ((bus->number - hose->bus_offset) << 16)
+ (bus->number << 16)
| (devfn << 8) | ((offset & 0xfc) )));
} else {
PCI_CFG_OUT(hose->cfg_addr,
(0x80000001 | ((offset & 0xf00) << 16) |
- ((bus->number - hose->bus_offset) << 16)
+ (bus->number << 16)
| (devfn << 8) | ((offset & 0xfc) )));
}
--
1.5.2.1
^ permalink raw reply related
* [PATCH 04/15] [POWERPC] Remove hack to determine the 2nd PHBs bus number
From: Kumar Gala @ 2007-06-27 1:16 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <11829070091056-git-send-email-galak@kernel.crashing.org>
Now that we have the pci_controller in the exclude function we can easy
figure out if the bus number is the PHB or not. The old style of using a
variable setup at init time was actually broken and would only work in
specific cases.
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
---
arch/powerpc/platforms/83xx/pci.c | 8 +-------
arch/powerpc/platforms/85xx/mpc85xx_cds.c | 7 +------
arch/powerpc/platforms/85xx/pci.c | 3 ---
3 files changed, 2 insertions(+), 16 deletions(-)
diff --git a/arch/powerpc/platforms/83xx/pci.c b/arch/powerpc/platforms/83xx/pci.c
index f92e71f..8da935c 100644
--- a/arch/powerpc/platforms/83xx/pci.c
+++ b/arch/powerpc/platforms/83xx/pci.c
@@ -33,15 +33,10 @@
#define DBG(x...)
#endif
-int mpc83xx_pci2_busno;
-
int mpc83xx_exclude_device(struct pci_controller *hose, u_char bus, u_char devfn)
{
- if (bus == 0 && PCI_SLOT(devfn) == 0)
+ if ((bus == hose->first_busno) && PCI_SLOT(devfn) == 0)
return PCIBIOS_DEVICE_NOT_FOUND;
- if (mpc83xx_pci2_busno)
- if (bus == (mpc83xx_pci2_busno) && PCI_SLOT(devfn) == 0)
- return PCIBIOS_DEVICE_NOT_FOUND;
return PCIBIOS_SUCCESSFUL;
}
@@ -86,7 +81,6 @@ int __init mpc83xx_add_bridge(struct device_node *dev)
setup_indirect_pci(hose, immr + 0x8380, immr + 0x8384);
primary = 0;
hose->bus_offset = hose->first_busno;
- mpc83xx_pci2_busno = hose->first_busno;
}
printk(KERN_INFO "Found MPC83xx PCI host bridge at 0x%016llx. "
diff --git a/arch/powerpc/platforms/85xx/mpc85xx_cds.c b/arch/powerpc/platforms/85xx/mpc85xx_cds.c
index fcea5ab..04a1eaa 100644
--- a/arch/powerpc/platforms/85xx/mpc85xx_cds.c
+++ b/arch/powerpc/platforms/85xx/mpc85xx_cds.c
@@ -55,16 +55,11 @@ static volatile u8 *cadmus;
#define ARCADIA_HOST_BRIDGE_IDSEL 17
#define ARCADIA_2ND_BRIDGE_IDSEL 3
-extern int mpc85xx_pci2_busno;
-
static int mpc85xx_exclude_device(struct pci_controller *hose,
u_char bus, u_char devfn)
{
- if (bus == 0 && PCI_SLOT(devfn) == 0)
+ if ((bus == hose->first_busno) && PCI_SLOT(devfn) == 0)
return PCIBIOS_DEVICE_NOT_FOUND;
- if (mpc85xx_pci2_busno)
- if (bus == (mpc85xx_pci2_busno) && PCI_SLOT(devfn) == 0)
- return PCIBIOS_DEVICE_NOT_FOUND;
/* We explicitly do not go past the Tundra 320 Bridge */
if ((bus == 1) && (PCI_SLOT(devfn) == ARCADIA_2ND_BRIDGE_IDSEL))
return PCIBIOS_DEVICE_NOT_FOUND;
diff --git a/arch/powerpc/platforms/85xx/pci.c b/arch/powerpc/platforms/85xx/pci.c
index 72a1bc5..be67f67 100644
--- a/arch/powerpc/platforms/85xx/pci.c
+++ b/arch/powerpc/platforms/85xx/pci.c
@@ -33,8 +33,6 @@
#define DBG(x...)
#endif
-int mpc85xx_pci2_busno = 0;
-
#ifdef CONFIG_PCI
int __init mpc85xx_add_bridge(struct device_node *dev)
{
@@ -74,7 +72,6 @@ int __init mpc85xx_add_bridge(struct device_node *dev)
setup_indirect_pci(hose, immr + 0x9000, immr + 0x9004);
primary = 0;
hose->bus_offset = hose->first_busno;
- mpc85xx_pci2_busno = hose->first_busno;
}
printk(KERN_INFO "Found MPC85xx PCI host bridge at 0x%016llx. "
--
1.5.2.1
^ permalink raw reply related
* [PATCH 03/15] [POWERPC] Pass the pci_controller into pci_exclude_device
From: Kumar Gala @ 2007-06-27 1:16 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <11829070073637-git-send-email-galak@kernel.crashing.org>
There are times that we need to know which controller we are on to decide
how to exclude devices properly. We now pass the pci_controller that we
are going to use down to the pci_exclude_device function. This will
greatly simplify being able to exclude the PHBs in multiple controller
setups.
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
---
arch/powerpc/platforms/82xx/mpc82xx_ads.c | 3 +-
arch/powerpc/platforms/83xx/mpc83xx.h | 4 +-
arch/powerpc/platforms/83xx/pci.c | 2 +-
arch/powerpc/platforms/85xx/mpc85xx_ads.c | 3 +-
arch/powerpc/platforms/85xx/mpc85xx_cds.c | 3 +-
arch/powerpc/platforms/86xx/mpc86xx.h | 3 +-
arch/powerpc/platforms/86xx/pci.c | 2 +-
arch/powerpc/platforms/embedded6xx/holly.c | 2 +-
arch/powerpc/platforms/embedded6xx/mpc7448_hpc2.c | 3 +-
arch/powerpc/sysdev/Makefile | 2 +-
arch/powerpc/sysdev/fsl_pcie.c | 4 +-
arch/powerpc/sysdev/indirect_pci.c | 8 +-
arch/powerpc/sysdev/tsi108_pci.c | 6 +-
arch/ppc/syslib/Makefile | 1 +
arch/ppc/syslib/indirect_pci.c | 134 +++++++++++++++++++++
include/asm-powerpc/machdep.h | 2 +-
16 files changed, 163 insertions(+), 19 deletions(-)
create mode 100644 arch/ppc/syslib/indirect_pci.c
diff --git a/arch/powerpc/platforms/82xx/mpc82xx_ads.c b/arch/powerpc/platforms/82xx/mpc82xx_ads.c
index 04bf570..715107b 100644
--- a/arch/powerpc/platforms/82xx/mpc82xx_ads.c
+++ b/arch/powerpc/platforms/82xx/mpc82xx_ads.c
@@ -507,7 +507,8 @@ void m82xx_pci_init_irq(void)
return;
}
-static int m82xx_pci_exclude_device(u_char bus, u_char devfn)
+static int m82xx_pci_exclude_device(struct pci_controller *hose,
+ u_char bus, u_char devfn)
{
if (bus == 0 && PCI_SLOT(devfn) == 0)
return PCIBIOS_DEVICE_NOT_FOUND;
diff --git a/arch/powerpc/platforms/83xx/mpc83xx.h b/arch/powerpc/platforms/83xx/mpc83xx.h
index 9bd85f5..f5c5034 100644
--- a/arch/powerpc/platforms/83xx/mpc83xx.h
+++ b/arch/powerpc/platforms/83xx/mpc83xx.h
@@ -3,6 +3,7 @@
#include <linux/init.h>
#include <linux/device.h>
+#include <asm/pci-bridge.h>
/* System Clock Control Register */
#define MPC83XX_SCCR_OFFS 0xA08
@@ -28,7 +29,8 @@
*/
extern int mpc83xx_add_bridge(struct device_node *dev);
-extern int mpc83xx_exclude_device(u_char bus, u_char devfn);
+extern int mpc83xx_exclude_device(struct pci_controller *hose,
+ u_char bus, u_char devfn);
extern void mpc83xx_restart(char *cmd);
extern long mpc83xx_time_init(void);
diff --git a/arch/powerpc/platforms/83xx/pci.c b/arch/powerpc/platforms/83xx/pci.c
index 3471602..f92e71f 100644
--- a/arch/powerpc/platforms/83xx/pci.c
+++ b/arch/powerpc/platforms/83xx/pci.c
@@ -35,7 +35,7 @@
int mpc83xx_pci2_busno;
-int mpc83xx_exclude_device(u_char bus, u_char devfn)
+int mpc83xx_exclude_device(struct pci_controller *hose, u_char bus, u_char devfn)
{
if (bus == 0 && PCI_SLOT(devfn) == 0)
return PCIBIOS_DEVICE_NOT_FOUND;
diff --git a/arch/powerpc/platforms/85xx/mpc85xx_ads.c b/arch/powerpc/platforms/85xx/mpc85xx_ads.c
index 4100e17..1262d1b 100644
--- a/arch/powerpc/platforms/85xx/mpc85xx_ads.c
+++ b/arch/powerpc/platforms/85xx/mpc85xx_ads.c
@@ -39,7 +39,8 @@
#endif
#ifdef CONFIG_PCI
-static int mpc85xx_exclude_device(u_char bus, u_char devfn)
+static int mpc85xx_exclude_device(struct pci_controller *hose,
+ u_char bus, u_char devfn)
{
if (bus == 0 && PCI_SLOT(devfn) == 0)
return PCIBIOS_DEVICE_NOT_FOUND;
diff --git a/arch/powerpc/platforms/85xx/mpc85xx_cds.c b/arch/powerpc/platforms/85xx/mpc85xx_cds.c
index fa6b6be..fcea5ab 100644
--- a/arch/powerpc/platforms/85xx/mpc85xx_cds.c
+++ b/arch/powerpc/platforms/85xx/mpc85xx_cds.c
@@ -57,7 +57,8 @@ static volatile u8 *cadmus;
extern int mpc85xx_pci2_busno;
-static int mpc85xx_exclude_device(u_char bus, u_char devfn)
+static int mpc85xx_exclude_device(struct pci_controller *hose,
+ u_char bus, u_char devfn)
{
if (bus == 0 && PCI_SLOT(devfn) == 0)
return PCIBIOS_DEVICE_NOT_FOUND;
diff --git a/arch/powerpc/platforms/86xx/mpc86xx.h b/arch/powerpc/platforms/86xx/mpc86xx.h
index dc2f6fd..4c2789d 100644
--- a/arch/powerpc/platforms/86xx/mpc86xx.h
+++ b/arch/powerpc/platforms/86xx/mpc86xx.h
@@ -17,7 +17,8 @@
extern int mpc86xx_add_bridge(struct device_node *dev);
-extern int mpc86xx_exclude_device(u_char bus, u_char devfn);
+extern int mpc86xx_exclude_device(struct pci_controller *hose,
+ u_char bus, u_char devfn);
extern void setup_indirect_pcie(struct pci_controller *hose,
u32 cfg_addr, u32 cfg_data);
diff --git a/arch/powerpc/platforms/86xx/pci.c b/arch/powerpc/platforms/86xx/pci.c
index 1e47c14..7659259 100644
--- a/arch/powerpc/platforms/86xx/pci.c
+++ b/arch/powerpc/platforms/86xx/pci.c
@@ -140,7 +140,7 @@ mpc86xx_setup_pcie(struct pci_controller *hose, u32 pcie_offset, u32 pcie_size)
early_write_config_dword(hose, 0, 0, PCI_PRIMARY_BUS, temps);
}
-int mpc86xx_exclude_device(u_char bus, u_char devfn)
+int mpc86xx_exclude_device(struct pci_controller *hose, u_char bus, u_char devfn)
{
if (bus == 0 && PCI_SLOT(devfn) == 0)
return PCIBIOS_DEVICE_NOT_FOUND;
diff --git a/arch/powerpc/platforms/embedded6xx/holly.c b/arch/powerpc/platforms/embedded6xx/holly.c
index 3a0b4a0..6292e36 100644
--- a/arch/powerpc/platforms/embedded6xx/holly.c
+++ b/arch/powerpc/platforms/embedded6xx/holly.c
@@ -45,7 +45,7 @@
#define HOLLY_PCI_CFG_PHYS 0x7c000000
-int holly_exclude_device(u_char bus, u_char devfn)
+int holly_exclude_device(struct pci_controller *hose, u_char bus, u_char devfn)
{
if (bus == 0 && PCI_SLOT(devfn) == 0)
return PCIBIOS_DEVICE_NOT_FOUND;
diff --git a/arch/powerpc/platforms/embedded6xx/mpc7448_hpc2.c b/arch/powerpc/platforms/embedded6xx/mpc7448_hpc2.c
index 69eab17..1e3cc69 100644
--- a/arch/powerpc/platforms/embedded6xx/mpc7448_hpc2.c
+++ b/arch/powerpc/platforms/embedded6xx/mpc7448_hpc2.c
@@ -56,7 +56,8 @@
extern void _nmask_and_or_msr(unsigned long nmask, unsigned long or_val);
-int mpc7448_hpc2_exclude_device(u_char bus, u_char devfn)
+int mpc7448_hpc2_exclude_device(struct pci_controller *hose,
+ u_char bus, u_char devfn)
{
if (bus == 0 && PCI_SLOT(devfn) == 0)
return PCIBIOS_DEVICE_NOT_FOUND;
diff --git a/arch/powerpc/sysdev/Makefile b/arch/powerpc/sysdev/Makefile
index c3ce0bd..43fd7e0 100644
--- a/arch/powerpc/sysdev/Makefile
+++ b/arch/powerpc/sysdev/Makefile
@@ -5,7 +5,6 @@ endif
mpic-msi-obj-$(CONFIG_PCI_MSI) += mpic_msi.o mpic_u3msi.o
obj-$(CONFIG_MPIC) += mpic.o $(mpic-msi-obj-y)
-obj-$(CONFIG_PPC_INDIRECT_PCI) += indirect_pci.o
obj-$(CONFIG_PPC_MPC106) += grackle.o
obj-$(CONFIG_PPC_DCR) += dcr.o
obj-$(CONFIG_PPC_DCR_NATIVE) += dcr-low.o
@@ -23,6 +22,7 @@ obj-$(CONFIG_MV64X60) += $(mv64x60-y) mv64x60_pic.o mv64x60_dev.o
obj-$(CONFIG_PM) += timer.o
ifeq ($(CONFIG_PPC_MERGE),y)
+obj-$(CONFIG_PPC_INDIRECT_PCI) += indirect_pci.o
obj-$(CONFIG_PPC_I8259) += i8259.o
obj-$(CONFIG_PPC_83xx) += ipic.o
obj-$(CONFIG_4xx) += uic.o
diff --git a/arch/powerpc/sysdev/fsl_pcie.c b/arch/powerpc/sysdev/fsl_pcie.c
index 041c07e..6bbd7f8 100644
--- a/arch/powerpc/sysdev/fsl_pcie.c
+++ b/arch/powerpc/sysdev/fsl_pcie.c
@@ -39,7 +39,7 @@ indirect_read_config_pcie(struct pci_bus *bus, unsigned int devfn, int offset,
u32 temp;
if (ppc_md.pci_exclude_device)
- if (ppc_md.pci_exclude_device(bus->number, devfn))
+ if (ppc_md.pci_exclude_device(hose, bus->number, devfn))
return PCIBIOS_DEVICE_NOT_FOUND;
/* Possible artifact of CDCpp50937 needs further investigation */
@@ -90,7 +90,7 @@ indirect_write_config_pcie(struct pci_bus *bus, unsigned int devfn, int offset,
u32 temp;
if (ppc_md.pci_exclude_device)
- if (ppc_md.pci_exclude_device(bus->number, devfn))
+ if (ppc_md.pci_exclude_device(hose, bus->number, devfn))
return PCIBIOS_DEVICE_NOT_FOUND;
/* Possible artifact of CDCpp50937 needs further investigation */
diff --git a/arch/powerpc/sysdev/indirect_pci.c b/arch/powerpc/sysdev/indirect_pci.c
index e714884..3dedf8f 100644
--- a/arch/powerpc/sysdev/indirect_pci.c
+++ b/arch/powerpc/sysdev/indirect_pci.c
@@ -35,14 +35,14 @@ indirect_read_config(struct pci_bus *bus, unsigned int devfn, int offset,
u8 cfg_type = 0;
if (ppc_md.pci_exclude_device)
- if (ppc_md.pci_exclude_device(bus->number, devfn))
+ if (ppc_md.pci_exclude_device(hose, bus->number, devfn))
return PCIBIOS_DEVICE_NOT_FOUND;
if (hose->set_cfg_type)
if (bus->number != hose->first_busno)
cfg_type = 1;
- PCI_CFG_OUT(hose->cfg_addr,
+ PCI_CFG_OUT(hose->cfg_addr,
(0x80000000 | ((bus->number - hose->bus_offset) << 16)
| (devfn << 8) | ((offset & 0xfc) | cfg_type)));
@@ -74,14 +74,14 @@ indirect_write_config(struct pci_bus *bus, unsigned int devfn, int offset,
u8 cfg_type = 0;
if (ppc_md.pci_exclude_device)
- if (ppc_md.pci_exclude_device(bus->number, devfn))
+ if (ppc_md.pci_exclude_device(hose, bus->number, devfn))
return PCIBIOS_DEVICE_NOT_FOUND;
if (hose->set_cfg_type)
if (bus->number != hose->first_busno)
cfg_type = 1;
- PCI_CFG_OUT(hose->cfg_addr,
+ PCI_CFG_OUT(hose->cfg_addr,
(0x80000000 | ((bus->number - hose->bus_offset) << 16)
| (devfn << 8) | ((offset & 0xfc) | cfg_type)));
diff --git a/arch/powerpc/sysdev/tsi108_pci.c b/arch/powerpc/sysdev/tsi108_pci.c
index 33177b6..298e2dd 100644
--- a/arch/powerpc/sysdev/tsi108_pci.c
+++ b/arch/powerpc/sysdev/tsi108_pci.c
@@ -64,9 +64,10 @@ tsi108_direct_write_config(struct pci_bus *bus, unsigned int devfunc,
int offset, int len, u32 val)
{
volatile unsigned char *cfg_addr;
+ struct pci_controller *hose = bus->sysdata;
if (ppc_md.pci_exclude_device)
- if (ppc_md.pci_exclude_device(bus->number, devfunc))
+ if (ppc_md.pci_exclude_device(hose, bus->number, devfunc))
return PCIBIOS_DEVICE_NOT_FOUND;
cfg_addr = (unsigned char *)(tsi_mk_config_addr(bus->number,
@@ -149,10 +150,11 @@ tsi108_direct_read_config(struct pci_bus *bus, unsigned int devfn, int offset,
int len, u32 * val)
{
volatile unsigned char *cfg_addr;
+ struct pci_controller *hose = bus->sysdata;
u32 temp;
if (ppc_md.pci_exclude_device)
- if (ppc_md.pci_exclude_device(bus->number, devfn))
+ if (ppc_md.pci_exclude_device(hose, bus->number, devfn))
return PCIBIOS_DEVICE_NOT_FOUND;
cfg_addr = (unsigned char *)(tsi_mk_config_addr(bus->number,
diff --git a/arch/ppc/syslib/Makefile b/arch/ppc/syslib/Makefile
index 9569415..543795b 100644
--- a/arch/ppc/syslib/Makefile
+++ b/arch/ppc/syslib/Makefile
@@ -7,6 +7,7 @@ CFLAGS_btext.o += -fPIC
wdt-mpc8xx-$(CONFIG_8xx_WDT) += m8xx_wdt.o
+obj-$(CONFIG_PPC_INDIRECT_PCI) += indirect_pci.o
obj-$(CONFIG_PPCBUG_NVRAM) += prep_nvram.o
obj-$(CONFIG_PPC_OCP) += ocp.o
obj-$(CONFIG_IBM_OCP) += ibm_ocp.o
diff --git a/arch/ppc/syslib/indirect_pci.c b/arch/ppc/syslib/indirect_pci.c
new file mode 100644
index 0000000..e714884
--- /dev/null
+++ b/arch/ppc/syslib/indirect_pci.c
@@ -0,0 +1,134 @@
+/*
+ * Support for indirect PCI bridges.
+ *
+ * Copyright (C) 1998 Gabriel Paubert.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version
+ * 2 of the License, or (at your option) any later version.
+ */
+
+#include <linux/kernel.h>
+#include <linux/pci.h>
+#include <linux/delay.h>
+#include <linux/string.h>
+#include <linux/init.h>
+
+#include <asm/io.h>
+#include <asm/prom.h>
+#include <asm/pci-bridge.h>
+#include <asm/machdep.h>
+
+#ifdef CONFIG_PPC_INDIRECT_PCI_BE
+#define PCI_CFG_OUT out_be32
+#else
+#define PCI_CFG_OUT out_le32
+#endif
+
+static int
+indirect_read_config(struct pci_bus *bus, unsigned int devfn, int offset,
+ int len, u32 *val)
+{
+ struct pci_controller *hose = bus->sysdata;
+ volatile void __iomem *cfg_data;
+ u8 cfg_type = 0;
+
+ if (ppc_md.pci_exclude_device)
+ if (ppc_md.pci_exclude_device(bus->number, devfn))
+ return PCIBIOS_DEVICE_NOT_FOUND;
+
+ if (hose->set_cfg_type)
+ if (bus->number != hose->first_busno)
+ cfg_type = 1;
+
+ PCI_CFG_OUT(hose->cfg_addr,
+ (0x80000000 | ((bus->number - hose->bus_offset) << 16)
+ | (devfn << 8) | ((offset & 0xfc) | cfg_type)));
+
+ /*
+ * Note: the caller has already checked that offset is
+ * suitably aligned and that len is 1, 2 or 4.
+ */
+ cfg_data = hose->cfg_data + (offset & 3);
+ switch (len) {
+ case 1:
+ *val = in_8(cfg_data);
+ break;
+ case 2:
+ *val = in_le16(cfg_data);
+ break;
+ default:
+ *val = in_le32(cfg_data);
+ break;
+ }
+ return PCIBIOS_SUCCESSFUL;
+}
+
+static int
+indirect_write_config(struct pci_bus *bus, unsigned int devfn, int offset,
+ int len, u32 val)
+{
+ struct pci_controller *hose = bus->sysdata;
+ volatile void __iomem *cfg_data;
+ u8 cfg_type = 0;
+
+ if (ppc_md.pci_exclude_device)
+ if (ppc_md.pci_exclude_device(bus->number, devfn))
+ return PCIBIOS_DEVICE_NOT_FOUND;
+
+ if (hose->set_cfg_type)
+ if (bus->number != hose->first_busno)
+ cfg_type = 1;
+
+ PCI_CFG_OUT(hose->cfg_addr,
+ (0x80000000 | ((bus->number - hose->bus_offset) << 16)
+ | (devfn << 8) | ((offset & 0xfc) | cfg_type)));
+
+ /*
+ * Note: the caller has already checked that offset is
+ * suitably aligned and that len is 1, 2 or 4.
+ */
+ cfg_data = hose->cfg_data + (offset & 3);
+ switch (len) {
+ case 1:
+ out_8(cfg_data, val);
+ break;
+ case 2:
+ out_le16(cfg_data, val);
+ break;
+ default:
+ out_le32(cfg_data, val);
+ break;
+ }
+ return PCIBIOS_SUCCESSFUL;
+}
+
+static struct pci_ops indirect_pci_ops =
+{
+ indirect_read_config,
+ indirect_write_config
+};
+
+void __init
+setup_indirect_pci_nomap(struct pci_controller* hose, void __iomem * cfg_addr,
+ void __iomem * cfg_data)
+{
+ hose->cfg_addr = cfg_addr;
+ hose->cfg_data = cfg_data;
+ hose->ops = &indirect_pci_ops;
+}
+
+void __init
+setup_indirect_pci(struct pci_controller* hose, u32 cfg_addr, u32 cfg_data)
+{
+ unsigned long base = cfg_addr & PAGE_MASK;
+ void __iomem *mbase, *addr, *data;
+
+ mbase = ioremap(base, PAGE_SIZE);
+ addr = mbase + (cfg_addr & ~PAGE_MASK);
+ if ((cfg_data & PAGE_MASK) != base)
+ mbase = ioremap(cfg_data & PAGE_MASK, PAGE_SIZE);
+ data = mbase + (cfg_data & ~PAGE_MASK);
+ setup_indirect_pci_nomap(hose, addr, data);
+}
diff --git a/include/asm-powerpc/machdep.h b/include/asm-powerpc/machdep.h
index 6cf1a83..71c6e7e 100644
--- a/include/asm-powerpc/machdep.h
+++ b/include/asm-powerpc/machdep.h
@@ -218,7 +218,7 @@ struct machdep_calls {
int (*pcibios_enable_device_hook)(struct pci_dev *, int initial);
/* Called in indirect_* to avoid touching devices */
- int (*pci_exclude_device)(unsigned char, unsigned char);
+ int (*pci_exclude_device)(struct pci_controller *, unsigned char, unsigned char);
/* Called at then very end of pcibios_init() */
void (*pcibios_after_init)(void);
--
1.5.2.1
^ permalink raw reply related
* [PATCH 02/15] [POWERPC] 52xx: Remove support for PCI bus_offset
From: Kumar Gala @ 2007-06-27 1:16 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <11829070063989-git-send-email-galak@kernel.crashing.org>
The hose->bus_offset is only used for PCI config cycles and the 52xx PCI
config code doesn't actually ever set bus_offset to a non-zero value.
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
---
arch/powerpc/platforms/52xx/mpc52xx_pci.c | 9 ++++-----
1 files changed, 4 insertions(+), 5 deletions(-)
diff --git a/arch/powerpc/platforms/52xx/mpc52xx_pci.c b/arch/powerpc/platforms/52xx/mpc52xx_pci.c
index 51164c8..57ca2fe 100644
--- a/arch/powerpc/platforms/52xx/mpc52xx_pci.c
+++ b/arch/powerpc/platforms/52xx/mpc52xx_pci.c
@@ -117,13 +117,13 @@ mpc52xx_pci_read_config(struct pci_bus *bus, unsigned int devfn,
out_be32(hose->cfg_addr,
(1 << 31) |
- ((bus->number - hose->bus_offset) << 16) |
+ (bus->number << 16) |
(devfn << 8) |
(offset & 0xfc));
mb();
#if defined(CONFIG_PPC_MPC5200_BUGFIX)
- if (bus->number != hose->bus_offset) {
+ if (bus->number) {
/* workaround for the bug 435 of the MPC5200 (L25R);
* Don't do 32 bits config access during type-1 cycles */
switch (len) {
@@ -174,13 +174,13 @@ mpc52xx_pci_write_config(struct pci_bus *bus, unsigned int devfn,
out_be32(hose->cfg_addr,
(1 << 31) |
- ((bus->number - hose->bus_offset) << 16) |
+ (bus->number << 16) |
(devfn << 8) |
(offset & 0xfc));
mb();
#if defined(CONFIG_PPC_MPC5200_BUGFIX)
- if (bus->number != hose->bus_offset) {
+ if (bus->number) {
/* workaround for the bug 435 of the MPC5200 (L25R);
* Don't do 32 bits config access during type-1 cycles */
switch (len) {
@@ -394,7 +394,6 @@ mpc52xx_add_bridge(struct device_node *node)
hose->first_busno = bus_range ? bus_range[0] : 0;
hose->last_busno = bus_range ? bus_range[1] : 0xff;
- hose->bus_offset = 0;
hose->ops = &mpc52xx_pci_ops;
pci_regs = ioremap(rsrc.start, rsrc.end - rsrc.start + 1);
--
1.5.2.1
^ permalink raw reply related
* [PATCH 01/15] [POWERPC] Remove set_cfg_type for PCI indirect users that don't need it
From: Kumar Gala @ 2007-06-27 1:16 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <11829070051484-git-send-email-galak@kernel.crashing.org>
The Freescale and Marvell PCI controllers dont require explicit setting for
type 1 config cycles. They handle producing them by implicitly looking at the
bus, devfn.
The TSI108 and 52xx don't use the generic PCI indirect code and thus don't
bother with set_cfg_type.
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
---
arch/powerpc/platforms/52xx/mpc52xx_pci.c | 1 -
arch/powerpc/platforms/82xx/mpc82xx_ads.c | 3 ---
arch/powerpc/platforms/83xx/pci.c | 1 -
arch/powerpc/platforms/85xx/pci.c | 1 -
arch/powerpc/platforms/86xx/pci.c | 1 -
arch/powerpc/sysdev/mv64x60_pci.c | 1 -
arch/powerpc/sysdev/tsi108_pci.c | 1 -
7 files changed, 0 insertions(+), 9 deletions(-)
diff --git a/arch/powerpc/platforms/52xx/mpc52xx_pci.c b/arch/powerpc/platforms/52xx/mpc52xx_pci.c
index 34d34a2..51164c8 100644
--- a/arch/powerpc/platforms/52xx/mpc52xx_pci.c
+++ b/arch/powerpc/platforms/52xx/mpc52xx_pci.c
@@ -390,7 +390,6 @@ mpc52xx_add_bridge(struct device_node *node)
return -ENOMEM;
hose->arch_data = node;
- hose->set_cfg_type = 1;
hose->first_busno = bus_range ? bus_range[0] : 0;
hose->last_busno = bus_range ? bus_range[1] : 0xff;
diff --git a/arch/powerpc/platforms/82xx/mpc82xx_ads.c b/arch/powerpc/platforms/82xx/mpc82xx_ads.c
index 081c0ab..04bf570 100644
--- a/arch/powerpc/platforms/82xx/mpc82xx_ads.c
+++ b/arch/powerpc/platforms/82xx/mpc82xx_ads.c
@@ -548,14 +548,11 @@ static void __init mpc82xx_add_bridge(struct device_node *np)
return;
hose->arch_data = np;
- hose->set_cfg_type = 1;
hose->first_busno = bus_range ? bus_range[0] : 0;
hose->last_busno = bus_range ? bus_range[1] : 0xff;
hose->bus_offset = 0;
- hose->set_cfg_type = 1;
-
setup_indirect_pci(hose,
r.start + offsetof(pci_cpm2_t, pci_cfg_addr),
r.start + offsetof(pci_cpm2_t, pci_cfg_data));
diff --git a/arch/powerpc/platforms/83xx/pci.c b/arch/powerpc/platforms/83xx/pci.c
index 1752d45..3471602 100644
--- a/arch/powerpc/platforms/83xx/pci.c
+++ b/arch/powerpc/platforms/83xx/pci.c
@@ -70,7 +70,6 @@ int __init mpc83xx_add_bridge(struct device_node *dev)
if (!hose)
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;
diff --git a/arch/powerpc/platforms/85xx/pci.c b/arch/powerpc/platforms/85xx/pci.c
index 3c38ae4..72a1bc5 100644
--- a/arch/powerpc/platforms/85xx/pci.c
+++ b/arch/powerpc/platforms/85xx/pci.c
@@ -61,7 +61,6 @@ int __init mpc85xx_add_bridge(struct device_node *dev)
if (!hose)
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;
diff --git a/arch/powerpc/platforms/86xx/pci.c b/arch/powerpc/platforms/86xx/pci.c
index c1d65fa..1e47c14 100644
--- a/arch/powerpc/platforms/86xx/pci.c
+++ b/arch/powerpc/platforms/86xx/pci.c
@@ -172,7 +172,6 @@ int __init mpc86xx_add_bridge(struct device_node *dev)
if (!hose)
return -ENOMEM;
hose->arch_data = dev;
- hose->set_cfg_type = 1;
/* last_busno = 0xfe cause by MPC8641 PCIE bug */
hose->first_busno = bus_range ? bus_range[0] : 0x0;
diff --git a/arch/powerpc/sysdev/mv64x60_pci.c b/arch/powerpc/sysdev/mv64x60_pci.c
index b5aef4c..6b08e76 100644
--- a/arch/powerpc/sysdev/mv64x60_pci.c
+++ b/arch/powerpc/sysdev/mv64x60_pci.c
@@ -142,7 +142,6 @@ static int __init mv64x60_add_bridge(struct device_node *dev)
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;
diff --git a/arch/powerpc/sysdev/tsi108_pci.c b/arch/powerpc/sysdev/tsi108_pci.c
index 2153163..33177b6 100644
--- a/arch/powerpc/sysdev/tsi108_pci.c
+++ b/arch/powerpc/sysdev/tsi108_pci.c
@@ -226,7 +226,6 @@ int __init tsi108_setup_pci(struct device_node *dev, u32 cfg_phys, int primary)
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;
--
1.5.2.1
^ permalink raw reply related
* [PATCH 00/15] [POWERPC] PCI/PCIe cleanups and fixups for 8641
From: Kumar Gala @ 2007-06-27 1:16 UTC (permalink / raw)
To: linuxppc-dev
This is a set of patches queued for 2.6.23 that cleanup some of the PCI
code for ppc32 and get PCIe working on 8641. Most of these patches have
been seen in one form or another before on the list.
Also available at:
master.kernel.org:/pub/scm/linux/kernel/git/galak/powerpc.git for_paulus
- k
^ permalink raw reply
* Re: Katmai w/ DENX git - "init has generated signal 4" error
From: Josh Boyer @ 2007-06-27 0:59 UTC (permalink / raw)
To: Stephen Winiecki; +Cc: linuxppc-embedded
In-Reply-To: <OF374AD003.85F388B3-ON87257306.0075D915-85257306.0076BA68@us.ibm.com>
On Tue, Jun 26, 2007 at 05:38:31PM -0400, Stephen Winiecki wrote:
> Josh Boyer <jwboyer@linux.vnet.ibm.com> wrote on 06/26/2007 01:12:38 PM:
>
> > Signal 4 is SIGILL, which could be returned for float instructions I
> > suppose. Try turning on CONFIG_MATH_EMULATION in your kernel config for
> > Katmai and see if the problem goes away.
>
> Thanks Josh - that actually did the trick w/ the original distro (which
> apparently generates some FP ops).
Good, glad it's working for you. Performance for apps that have FP
instructions will be slower than if you had a true FPU, but that's better
than not functioning at all.
>
> Valentine Barshak <vbarshak@ru.mvista.com> wrote on 06/26/2007 01:58:23
> PM:
> > Looks like 440SPe entry is missing in the arch/ppc/kernel/cputable.c
>
> I'm using a git snapshot version of the DENX kernel - is there some effort
> underway to start to merge this platform support into the public tree?
I don't know of anyone starting an arch/powerpc port for Katmai yet. And it
seems that new submissions to arch/ppc are frozen.
josh
^ permalink raw reply
* Re: Katmai w/ DENX git - "init has generated signal 4" error
From: Stephen Winiecki @ 2007-06-26 21:38 UTC (permalink / raw)
To: jwboyer, vbarshak; +Cc: linuxppc-embedded
In-Reply-To: <1182877959.19501.17.camel@weaponx.rchland.ibm.com>
Josh Boyer <jwboyer@linux.vnet.ibm.com> wrote on 06/26/2007 01:12:38 PM:
> Signal 4 is SIGILL, which could be returned for float instructions I
> suppose. Try turning on CONFIG_MATH_EMULATION in your kernel config for
> Katmai and see if the problem goes away.
Thanks Josh - that actually did the trick w/ the original distro (which
apparently generates some FP ops).
Valentine Barshak <vbarshak@ru.mvista.com> wrote on 06/26/2007 01:58:23
PM:
> Looks like 440SPe entry is missing in the arch/ppc/kernel/cputable.c
I'm using a git snapshot version of the DENX kernel - is there some effort
underway to start to merge this platform support into the public tree?
^ permalink raw reply
* Re: [CURIOUSITY] When will we stop caring about arch/ppc?
From: Vitaly Bordug @ 2007-06-26 21:11 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: linuxppc-dev
In-Reply-To: <200706261903.41801.arnd@arndb.de>
On Tue, 26 Jun 2007 19:03:41 +0200
Arnd Bergmann wrote:
> On Tuesday 26 June 2007, Segher Boessenkool wrote:
> > Well the arch/ppc tree is basically frozen already, all Freescale
> > stuff got moved over already as far as I can see, and 4xx has
> > started moving.
>
> 8xx has been moved over, but last time I tried, it was not possible
> to actually compile that code. Note sure if the arch/ppc version of
> it is in a much better shape though.
>
8xx should be ok now, yet, we have to be aware that only 2 platforms are in arch/powerpc
and there are plenty in arch/ppc still.
> 82xx seems to be in a similar state to 4xx, with a single platform
> moved over, but most of the code still being arch/ppc only.
>
The situation is better here - most stuff is very similar to what is done (except sandpoint but that's another story)
and the number of platforms is reasonable.
for the 8xx feild, there is quite a lot of boards...
with all the "specifics", it is nearly impossible to provide robust port without actual HW
(or, heh, the result won't work at all).
> Arnd <><
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
--
Sincerely, Vitaly
^ permalink raw reply
* Re: [CURIOUSITY] When will we stop caring about arch/ppc?
From: Kumar Gala @ 2007-06-26 18:51 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: linuxppc-dev
In-Reply-To: <200706261903.41801.arnd@arndb.de>
On Jun 26, 2007, at 12:03 PM, Arnd Bergmann wrote:
> On Tuesday 26 June 2007, Segher Boessenkool wrote:
>> Well the arch/ppc tree is basically frozen already, all Freescale
>> stuff got moved over already as far as I can see, and 4xx has
>> started moving.
>
> 8xx has been moved over, but last time I tried, it was not possible
> to actually compile that code. Note sure if the arch/ppc version of
> it is in a much better shape though.
>
> 82xx seems to be in a similar state to 4xx, with a single platform
> moved over, but most of the code still being arch/ppc only.
Scott Wood is look at both of these post OLS.
- k
^ permalink raw reply
* RE: ML403 gigabit ethernet bandwidth - 2.6 kernel
From: Ming Liu @ 2007-06-26 18:12 UTC (permalink / raw)
To: mamsadegh; +Cc: akonovalov, linuxppc-embedded
In-Reply-To: <BAY115-W41EBB7B6501204F68D497B20B0@phx.gbl>
Dear Mohammad,
>ML403--->PC : 410Mbits/s
>PC--->ML403 : 210Mbits/s
These results are interesting. In priciple, board to PC will be less than
PC to board. And also you board to PC speed is quite fast. I never had that
high before. :)
>We have described the characteristics of our base system in previous posts
here
>
>In additiona we have :
>1- enabled the ppc caches
This will help the improvement quite a lot.
>2- we have set BD_IN_BRAM in adapter.c to 1. ( default is 0 )
Actually I didn't try to modify this before. My previous results are based
on bd_NOT_in_bram. :) From my understanding, enable this option will put
the buffer descriptor in BRAM rather than DDR. Perhaps I can also try it
and to see if there is any improvement on my system.
>TX_THRESHOLD is 16 and RX_THRESHOLD is 2.
>
>the virtex4 fx12 device on ML403 is now completely full, we do not have
any free block memories nor any logic slices. Maybe if we had more space we
could choose higher values for XTE_SEND_BD_CNT and XTE_RECV_BD_CNT i.e.
384. Do you think this will improve performance?
Probably yes. But I never modified these numbers before. My default ones
are 512 respectively.
>There is also another interesting test,
>We executed netperf on both of PC and ML403 simultanously , when we do not
put BDs in BRAM, the performance of ML403-->PC link drops from 390Mbits to
45Mbits, but when using PLB BRAMs for BDs the performance decreases from
410Mbits/s to just 130Mbita/s. It is important when the user wants to
transfer data in both directions simulatanously.
Definitely! The bottleneck is CPU processing capability. So if you send and
receive data at the same time, the results will be much worse. I think
another reason is TCP is guaranteed protocal. So there will be some
acknowledgements returning back when you send packets out. Thus your
bandwidth will be taken a little away. However compared with the
consumption of CPU, this perhaps will be trivial.
BR
Ming
>
>
>----------------------------------------
> > From: eemingliu@hotmail.com
> > To: mamsadegh@hotmail.com
> > CC: akonovalov@ru.mvista.com; linuxppc-embedded@ozlabs.org
> > Subject: RE: ML403 gigabit ethernet bandwidth - 2.6 kernel
> > Date: Mon, 25 Jun 2007 10:03:30 +0000
> >
> > Dear Mohammad,
> >
> > >The results are as follows:
> > >PC-->ML403
> > >TCP_SENDFILE : 38Mbps
> > >
> > >ML403--->PC
> > >TCP_SENDFILE: 155Mbps
> >
> > This result is unreasonable. Because PC is more powerful than your
board,
> > so PC->board should be faster than board->PC.
> >
> > >The transfer rate from ML403 to PC has improved by a factor of 2,
> > >I see on the posts here in the mailing list that you have reached a
band
> > width of 301Mbps.
> >
> > Yes, with all features which could improve performance enabled, we can
get
> > around 300Mbps for TCP transfer. one more hint, did you enable caches
on
> > your system? perhaps it will help. Anyway, double check your hardware
> > design to make sure all features are enabled.That's all I can suggest.
> >
> > BR
> > Ming
> >
> >
> > >
> > >
> > >
> > >
> > >----------------------------------------
> > > > From: eemingliu@hotmail.com
> > > > To: mamsadegh@hotmail.com; akonovalov@ru.mvista.com;
> > linuxppc-embedded@ozlabs.org; grant.likely@secretlab.ca
> > > > Subject: RE: ML403 gigabit ethernet bandwidth - 2.6 kernel
> > > > Date: Sat, 23 Jun 2007 19:10:16 +0000
> > > >
> > > > Use the following command in Linux please:
> > > >
> > > > ifconfig eth0 mtu 8982
> > > >
> > > > As well you should do that on your PC in the measurement.
> > > >
> > > > Ming
> > > >
> > > >
> > > > >From: Mohammad Sadegh Sadri
> > > > >To: Ming Liu ,
> > > > ,,
> > > >
> > > > >Subject: RE: ML403 gigabit ethernet bandwidth - 2.6 kernel
> > > > >Date: Sat, 23 Jun 2007 19:08:29 +0000
> > > > >
> > > > >
> > > > >Dear Ming,
> > > > >
> > > > >Really thanks for reply,
> > > > >
> > > > >about thresholds and waitbound OK! I'll adjust them in adapter.c ,
> > > > >
> > > > >but what about enabling jumbo frames? should I do any thing
special to
> > > > enable Jumbo fram support?
> > > > >
> > > > >we were thinking that it is enabled by default. Is it?
> > > > >
> > > > >thanks
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >----------------------------------------
> > > > > > From: eemingliu@hotmail.com
> > > > > > To: mamsadegh@hotmail.com; akonovalov@ru.mvista.com;
> > > > linuxppc-embedded@ozlabs.org; grant.likely@secretlab.ca
> > > > > > Subject: RE: ML403 gigabit ethernet bandwidth - 2.6 kernel
> > > > > > Date: Sat, 23 Jun 2007 18:48:19 +0000
> > > > > >
> > > > > > Dear Mohammad,
> > > > > > There are some parameters which could be adjusted to improve
the
> > > > > > performance. They are: TX and RX_Threshold TX and RX_waitbound.
In
> > my
> > > > > > system, we use TX_Threshold=16 and Rx_Threshold=8 and both
> > waitbound=1.
> > > > > >
> > > > > > Also Jumbo frame of 8982 could be enable.
> > > > > >
> > > > > > Try those hints and share your improvement with us.
> > > > > >
> > > > > > BR
> > > > > > Ming
> > > > > >
> > > > > > >From: Mohammad Sadegh Sadri
> > > > > > >To: Andrei Konovalov , Linux PPC Linux
> > > > > > PPC, Grant Likely
> > > > > > >Subject: ML403 gigabit ethernet bandwidth - 2.6 kernel
> > > > > > >Date: Sat, 23 Jun 2007 12:19:12 +0000
> > > > > > >
> > > > > > >
> > > > > > >Dear all,
> > > > > > >
> > > > > > >Recently we did a set of tests on performance of virtex 4FX
hard
> > TEMAC
> > > > > > module using ML403
> > > > > > >
> > > > > > >we studied all of the posts here carefully: these are the
system
> > > > > > characteristics;
> > > > > > >
> > > > > > >Board : ML403
> > > > > > >EDK : EDK9.1SP2
> > > > > > >Hard TEMAC version and PLTEMAC version are both 3.0.a
> > > > > > >PPC clock frequency : 300MHz
> > > > > > >Kernel : 2.6.21-rc7 , downloaded from grant's git tree some
thing
> > near
> > > > one
> > > > > > week ago
> > > > > > >DMA type: 3 (sg dma)
> > > > > > >DRE : enabled for TX and RX, (2)
> > > > > > >CSUM offload is enabled for both of TX and RX
> > > > > > >tx and rx fifo sizes : 131072 bits
> > > > > > >
> > > > > > >the board comes up over NFS root file system completely and
> > without
> > > > any
> > > > > > problems.
> > > > > > >
> > > > > > >PC system used for these tests is : CPU P4 Dual Core, 3.4GHz ,
> > > > 2Gigabytes
> > > > > > memory, Dual gigabit ethernet port, running linux 2.6.21.3
> > > > > > >We have tested the PC system band width and it can easily
reach
> > > > 966mbits/s
> > > > > > when connected to the same PC. ( using the same cross cable
used
> > for
> > > > ml403
> > > > > > test)
> > > > > > >
> > > > > > >Netperf is compiled with TCP SEND FILE enabled, (
-DHAVE_SENDFILE)
> > > > > > >
> > > > > > >(from board to PC)
> > > > > > >netperf -t TCP_SENDFILE -H 10.10.10.250 -F /boot/zImage.elf --
-m
> > > > 16384 -s
> > > > > > 87380 -S 87380
> > > > > > >
> > > > > > >the measured bandwidth for this test was just 40.66Mbits.
> > > > > > >It is also true for netperf from PC to board.
> > > > > > >
> > > > > > >we do not have any more idea about what we should do to
improve
> > the
> > > > > > bandwidth.
> > > > > > >any help or ideas is appreciated...
> > > > > > >
> > > > > >
>_________________________________________________________________
> > > > > > >Connect to the next generation of MSN
> > > > > >
> > > >
> >
Messenger?>http://imagine-msn.com/messenger/launch80/default.aspx?locale=en-us&source=wlmailtagline
> >
> > > >
> > > > > >
> > > > > > >_______________________________________________
> > > > > > >Linuxppc-embedded mailing list
> > > > > > >Linuxppc-embedded@ozlabs.org
> > > > > > >https://ozlabs.org/mailman/listinfo/linuxppc-embedded
> > > > > >
> > > > > >
_________________________________________________________________
> > > > > > 免费下载 MSN Explorer: http://explorer.msn.com/lccn/
> > > > > >
> > > > >
> > > > >_________________________________________________________________
> > > > >News, entertainment and everything you care about at Live.com. Get
it
> > now!
> > > > >http://www.live.com/getstarted.aspx
> > > >
> > > > _________________________________________________________________
> > > > 免费下载 MSN Explorer: http://explorer.msn.com/lccn/
> > > >
> > >
> > >_________________________________________________________________
> > >Discover the new Windows Vista
> > >http://search.msn.com/results.aspx?q=windows+vista&mkt=en-US&form=QBRE
> >
> > _________________________________________________________________
> > 免费下载 MSN Explorer: http://explorer.msn.com/lccn/
> >
>
>_________________________________________________________________
>News, entertainment and everything you care about at Live.com. Get it now!
>http://www.live.com/getstarted.aspx
_________________________________________________________________
与联机的朋友进行交流，请使用 MSN Messenger: http://messenger.msn.com/cn
^ permalink raw reply
* Re: Katmai w/ DENX git - "init has generated signal 4" error
From: Valentine Barshak @ 2007-06-26 17:58 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-embedded
In-Reply-To: <1182877959.19501.17.camel@weaponx.rchland.ibm.com>
Josh Boyer wrote:
> On Tue, 2007-06-26 at 12:02 -0400, Stephen Winiecki wrote:
>
>>> I'm using the Denx linux-2.6-denx.git repository with a Katmai board. I
>>> want to boot off a disk (initialized w/ Debian 4.0). I've installed a
>>> Promise Ultra133 Tx2 IDE controller card in the PCI slot, and configured
>>>
>>> it in the kernel. I boot this same disk w/ IDE card on other 4xx
>>>
>> boards
>>
>>> without a problem (Bamboo w/ Denx 4.1 for example). I am getting an
>>>
>> error
>>
>>> "init has generated signal 4 but has no handler for it".
>>>
>> I believe the problem may be due to lack of HW FP on the processor(?).
>> Copying an embedded 440 RFS on disk works OK.
>>
>
> Signal 4 is SIGILL, which could be returned for float instructions I
> suppose. Try turning on CONFIG_MATH_EMULATION in your kernel config for
> Katmai and see if the problem goes away.
>
> josh
>
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
Looks like 440SPe entry is missing in the arch/ppc/kernel/cputable.c
Thanks.
^ permalink raw reply
* Re: [Cbe-oss-dev] [patch 3/5] cell: updated driver for DDR2 memory on AXON
From: Carsten Otte @ 2007-06-26 17:53 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: Maxim Shchetynin, linuxppc-dev, cbe-oss-dev
In-Reply-To: <200706261821.06516.arnd@arndb.de>
Arnd Bergmann wrote:
> What will actually happen if you try to mount an axonram device with ext2?
> I suppose mount should fail with a proper error code if the block size is
> larger than 4kb, but does that happen?
>
> If you have a 4k block size axonram device, the ext2 really should work
> using XIP as expected, including the mmap() operation.
>
Absolutely. What's the symptom if you try mount -o xip? I am willing
to fix any bugs that show in the ext2/xip code in that scenario...
>> We have the direct_access method here only because it is needed for the
>> azfs file-system, which we recommend to use for accessing the Axon's RAM
>> rather then ext2 or any other buffered file-systems.
>
> I think I've understood what the problem is now. The generic xip code
> assumes that the data to be mapped has a 'struct page' in mem_map,
> and that it's part of the linear kernel mapping. This is actually
> true on s390, where it is currently used, but not for us. The point
> on s390 is that the kernel virtual address is _identical_ to the
> physical address, so it may never have shown up as a problem.
>
> I'll talk to Carsten about this, he already had plans to remove
> the need for struct page from the filemap_xip infrastructure.
Removing the need for struct page is indeed impossible with current
memory management because of the fact that VM_PFNMAP vmas have the
downside that they require a linear physical image of the vma. Ext2
does not comply to that requriement, a given file may be spread all
over a media.
^ permalink raw reply
* Re: [Cbe-oss-dev] [patch 3/5] cell: updated driver for DDR2 memory on AXON
From: Arnd Bergmann @ 2007-06-26 17:38 UTC (permalink / raw)
To: carsteno; +Cc: Maxim Shchetynin, linuxppc-dev, cbe-oss-dev, linux-kernel
In-Reply-To: <46815286.1010808@de.ibm.com>
On Tuesday 26 June 2007, Carsten Otte wrote:
>
> Arnd Bergmann wrote:
> > What will actually happen if you try to mount an axonram device with ext2?
> > I suppose mount should fail with a proper error code if the block size is
> > larger than 4kb, but does that happen?
> >
> > If you have a 4k block size axonram device, the ext2 really should work
> > using XIP as expected, including the mmap() operation.
> >
> Absolutely. What's the symptom if you try mount -o xip? I am willing
> to fix any bugs that show in the ext2/xip code in that scenario...
The real problem is that the ->direct_access function is supposed to return
a kernel virtual address in the linear mapping, which does not make any
sense for axonram. The physical address of the underlying device is
outside of the kernel mapping, and gets mapped into the kernel virtual
space using ioremap, with flags to disallow caching.
If ->direct_access returns a physical address, the file system cannot
access the data through the kernel mapping, but if it returns the
ioremapped address, it cannot know what address to map into the
user page tables, because virt_to_page() is not defined for the
ioremap space.
Maximchose to return the physical address, which is what he needs in
his file system, but that's just not how the interface was designed
to be used.
One way to change fix the problem might be to give a flag to the
->direct_access function to ask for either the page frame number,
or the virtual address (from ioremap or the linear mapping).
It's rather ugly though, so if you have a better idea, let us
know.
Another problem is that the mmap, or no_page, function really
needs to know about the pgprot value it should use. If we add
a field to struct block_device for this, the drivers could set
it there.
Arnd <><
^ permalink raw reply
* Re: [CURIOUSITY] When will we stop caring about arch/ppc?
From: Arnd Bergmann @ 2007-06-26 17:03 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <1ce7f225511ea3d67a63b8a4ac683e0c@kernel.crashing.org>
On Tuesday 26 June 2007, Segher Boessenkool wrote:
> Well the arch/ppc tree is basically frozen already, all Freescale
> stuff got moved over already as far as I can see, and 4xx has
> started moving.
8xx has been moved over, but last time I tried, it was not possible
to actually compile that code. Note sure if the arch/ppc version of
it is in a much better shape though.
82xx seems to be in a similar state to 4xx, with a single platform
moved over, but most of the code still being arch/ppc only.
Arnd <><
^ permalink raw reply
* Re: [CURIOUSITY] When will we stop caring about arch/ppc?
From: Mark A. Greer @ 2007-06-26 17:18 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev
In-Reply-To: <1ce7f225511ea3d67a63b8a4ac683e0c@kernel.crashing.org>
On Tue, Jun 26, 2007 at 03:46:58PM +0200, Segher Boessenkool wrote:
> >>> But I meant adding
> >>> something in the Documentation/powerpc/ directory and maybe
> >>> feature-removal-schedule.txt. Basically a written down thing in the
> >>> kernel source to refer people to.
> >>
> >> How about this time next year -- special event at
> >> the OLS PowerPC BOF :-)
> >
> > Heh, sounds good to me.
> >
> > Of course, getting stuff done in a year.... ;)
>
> Well the arch/ppc tree is basically frozen already, all Freescale
> stuff got moved over already as far as I can see, and 4xx has
> started moving. I think a year is enough, since the tree is
> frozen anyway, people can resurrect stuff from older releases
> if need be, no problem with deleting it. In fact, why not do
> so this year :-) [Yeah that was a joke].
Actually, I wouldn't have a problem with getting rid of arch/ppc right
now. It won't really be lost, just git checkout your favorite tag that
still has it. It'll get rid of code people shouldn't be worrying about
anymore anyway.
I realize, I'm probably the only one with this opinion so you don't have
to tell me all the reasons I'm wrong. :)
Mark
^ permalink raw reply
* Re: Katmai w/ DENX git - "init has generated signal 4" error
From: Josh Boyer @ 2007-06-26 17:12 UTC (permalink / raw)
To: Stephen Winiecki; +Cc: linuxppc-embedded
In-Reply-To: <OFBF408254.9B235C85-ON87257306.0057DC6C-85257306.0057F0B4@us.ibm.com>
On Tue, 2007-06-26 at 12:02 -0400, Stephen Winiecki wrote:
> > I'm using the Denx linux-2.6-denx.git repository with a Katmai board. I
> > want to boot off a disk (initialized w/ Debian 4.0). I've installed a
> > Promise Ultra133 Tx2 IDE controller card in the PCI slot, and configured
>
> > it in the kernel. I boot this same disk w/ IDE card on other 4xx
> boards
> > without a problem (Bamboo w/ Denx 4.1 for example). I am getting an
> error
> > "init has generated signal 4 but has no handler for it".
>
> I believe the problem may be due to lack of HW FP on the processor(?).
> Copying an embedded 440 RFS on disk works OK.
Signal 4 is SIGILL, which could be returned for float instructions I
suppose. Try turning on CONFIG_MATH_EMULATION in your kernel config for
Katmai and see if the problem goes away.
josh
^ permalink raw reply
* Re: [Cbe-oss-dev] [patch 3/5] cell: updated driver for DDR2 memory on AXON
From: Arnd Bergmann @ 2007-06-26 16:21 UTC (permalink / raw)
To: cbe-oss-dev; +Cc: Maxim Shchetynin, linuxppc-dev, Carsten Otte
In-Reply-To: <OF39A5D2DB.6FC50A30-ONC1257306.0051B925-C1257306.0052040B@de.ibm.com>
On Tuesday 26 June 2007, Maxim Shchetynin wrote:
> Actually, axon_ram's direct_access method would not be used by ext2 at all
> - ext2 feels comfortable with make_request().
not for mmap().
What will actually happen if you try to mount an axonram device with ext2?
I suppose mount should fail with a proper error code if the block size is
larger than 4kb, but does that happen?
If you have a 4k block size axonram device, the ext2 really should work
using XIP as expected, including the mmap() operation.
> We have the direct_access method here only because it is needed for the
> azfs file-system, which we recommend to use for accessing the Axon's RAM
> rather then ext2 or any other buffered file-systems.
I think I've understood what the problem is now. The generic xip code
assumes that the data to be mapped has a 'struct page' in mem_map,
and that it's part of the linear kernel mapping. This is actually
true on s390, where it is currently used, but not for us. The point
on s390 is that the kernel virtual address is _identical_ to the
physical address, so it may never have shown up as a problem.
I'll talk to Carsten about this, he already had plans to remove
the need for struct page from the filemap_xip infrastructure.
Arnd <><
^ permalink raw reply
* [PATCH] [POWERPC] Oprofile enhanced instruction sampling support
From: Will Schmidt @ 2007-06-26 16:12 UTC (permalink / raw)
To: linuxppc-dev, paulus; +Cc: will_schmidt, anton
Oprofile enhanced instruction sampling support.
When performing instruction sampling, the mmcra[SLOT] field can be used to
more accurately identify the address of the sampled instruction.
Tested on power4, js20, power5 and power5+.
Signed-off-by: Will Schmidt <will_schmidt@vnet.ibm.com>
cc: Maynard Johnson <maynardj@us.ibm.com>
---
arch/powerpc/oprofile/op_model_power4.c | 14 ++++++++++++++
include/asm-powerpc/reg.h | 2 ++
2 files changed, 16 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/oprofile/op_model_power4.c b/arch/powerpc/oprofile/op_model_power4.c
index fe597a1..a7c206b 100644
--- a/arch/powerpc/oprofile/op_model_power4.c
+++ b/arch/powerpc/oprofile/op_model_power4.c
@@ -1,5 +1,7 @@
/*
* Copyright (C) 2004 Anton Blanchard <anton@au.ibm.com>, IBM
+ * Added mmcra[slot] support:
+ * Copyright (C) 2006-2007 Will Schmidt <willschm@us.ibm.com>, IBM
*
* This program is free software; you can redistribute it and/or
* modify it under the terms of the GNU General Public License
@@ -181,11 +183,17 @@ static void __attribute_used__ kernel_unknown_bucket(void)
* On GQ and newer the MMCRA stores the HV and PR bits at the time
* the SIAR was sampled. We use that to work out if the SIAR was sampled in
* the hypervisor, our exception vectors or RTAS.
+ * If the MMCRA_SAMPLE_ENABLE bit is set, we can use the MMCRA[slot] bits
+ * to more accurately identify the address of the sampled instruction. The
+ * mmcra[slot] bits represent the slot number of a sampled instruction
+ * within an instruction group. The slot will contain a value between 1
+ * and 5 if MMCRA_SAMPLE_ENABLE is set, otherwise 0.
*/
static unsigned long get_pc(struct pt_regs *regs)
{
unsigned long pc = mfspr(SPRN_SIAR);
unsigned long mmcra;
+ unsigned long slot;
/* Cant do much about it */
if (!cur_cpu_spec->oprofile_mmcra_sihv)
@@ -193,6 +201,12 @@ static unsigned long get_pc(struct pt_regs *regs)
mmcra = mfspr(SPRN_MMCRA);
+ if (mmcra & MMCRA_SAMPLE_ENABLE) {
+ slot = ((mmcra & MMCRA_SLOT) >> MMCRA_SLOT_SHIFT);
+ if (slot > 1)
+ pc += 4 * (slot - 1);
+ }
+
/* Were we in the hypervisor? */
if (firmware_has_feature(FW_FEATURE_LPAR) &&
(mmcra & cur_cpu_spec->oprofile_mmcra_sihv))
diff --git a/include/asm-powerpc/reg.h b/include/asm-powerpc/reg.h
index 749c7f9..281011e 100644
--- a/include/asm-powerpc/reg.h
+++ b/include/asm-powerpc/reg.h
@@ -453,6 +453,8 @@
#define SPRN_MMCRA 0x312
#define MMCRA_SIHV 0x10000000UL /* state of MSR HV when SIAR set */
#define MMCRA_SIPR 0x08000000UL /* state of MSR PR when SIAR set */
+#define MMCRA_SLOT 0x07000000UL /* SLOT bits (37-39) */
+#define MMCRA_SLOT_SHIFT 24
#define MMCRA_SAMPLE_ENABLE 0x00000001UL /* enable sampling */
#define POWER6_MMCRA_SIHV 0x0000040000000000ULL
#define POWER6_MMCRA_SIPR 0x0000020000000000ULL
^ permalink raw reply related
* Re: Katmai w/ DENX git - "init has generated signal 4" error
From: Stephen Winiecki @ 2007-06-26 16:02 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <OF6593F764.1D9AA110-ON87257305.0067371E-85257305.00688AB4@us.ibm.com>
> I'm using the Denx linux-2.6-denx.git repository with a Katmai board. I
> want to boot off a disk (initialized w/ Debian 4.0). I've installed a
> Promise Ultra133 Tx2 IDE controller card in the PCI slot, and configured
> it in the kernel. I boot this same disk w/ IDE card on other 4xx
boards
> without a problem (Bamboo w/ Denx 4.1 for example). I am getting an
error
> "init has generated signal 4 but has no handler for it".
I believe the problem may be due to lack of HW FP on the processor(?).
Copying an embedded 440 RFS on disk works OK.
^ permalink raw reply
* Re: [PATCH] powerpc: fix MAC address entries for 83xx, 85xx, and 86xx device trees
From: Timur Tabi @ 2007-06-26 15:58 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev
In-Reply-To: <f7b7186d108fee941496ea15fd902474@kernel.crashing.org>
Segher Boessenkool wrote:
> It is not safe since you might happen upon a network device without
> "mac-address" property (since the device hasn't been used at boot in
> a real OF, or the firmware knows no mac address at all, etc.) and no
> "local-mac-address" either -- but it _does_ have an "address", and
> it can have an "address" with the correct semantics, not the broken
> stuff.
>
> It's not very likely for this happens, sure :-)
Maybe we're using different definitions of "safe" here. When I said the code was "safe",
I meant that it if U-Boot puts the MAC address into the 'address' property only,
of_get_mac_address() will safely detect that and use the address:
pp = of_find_property(np, "address", NULL);
if (pp && (pp->length == 6) && is_valid_ether_addr(pp->value))
return pp->value;
It checks if the property exists, that it's 6 bytes long, and that it is a valid MAC
address. AFAIK, no version of U-Boot and no DTS file, past or present, will confuse this
code.
--
Timur Tabi
Linux Kernel Developer @ Freescale
^ permalink raw reply
* Re: [PATCH] powerpc: fix MAC address entries for 83xx, 85xx, and 86xx device trees
From: Segher Boessenkool @ 2007-06-26 15:42 UTC (permalink / raw)
To: Timur Tabi; +Cc: linuxppc-dev
In-Reply-To: <46812F19.1070302@freescale.com>
>> Yeah, that's fine. I just meant the current kernel (before
>> .25) could detect you are using a uboot that won't work after
>> .25 anymore, and shout at the user. Would save you some bug
>> reports ;-)
>
> I don't think that's possible.
Hrm I phrased it incorrectly I suppose, I meant something just
like the patch you propose below :-)
> Unfortunately, I don't see how I can fix these problems.
You cannot fix it but you can sometimes detect it. Not all
that important anyway.
>>> In other words, the current U-Boot and Linux code is written to not
>>> care what the other one does. I have no plans to remove the code in
>>> the kernel that looks for obsolete entries (I'm talking about
>>> function of_get_mac_address), because it's "safe".
>> Well you should remove the "address" thing, it is _not_ safe.
>
> Checking for 'address' after finding no match on 'mac-address' and
> 'local-mac-address' is safe, because if that's the only property that
> has a valid MAC address, I want to use it. As long as there are
> people out there using U-Boot 1.1.x, we'll need to keep that code
> around.
It is not safe since you might happen upon a network device without
"mac-address" property (since the device hasn't been used at boot in
a real OF, or the firmware knows no mac address at all, etc.) and no
"local-mac-address" either -- but it _does_ have an "address", and
it can have an "address" with the correct semantics, not the broken
stuff.
It's not very likely for this happens, sure :-)
>>> However, now that you mention it, I could update function
>>> of_get_mac_address() to display a warning if it only finds the
>>> 'address' property.
>> Yeah exactly.
>
> Ok, I will submit a patch to do that.
Thanks!
Segher
^ permalink raw reply
* Re: [PATCH] powerpc: fix MAC address entries for 83xx, 85xx, and 86xx device trees
From: Timur Tabi @ 2007-06-26 15:22 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev
In-Reply-To: <b50d825c36a92dc2e16f486455e0623d@kernel.crashing.org>
Segher Boessenkool wrote:
> Yeah, that's fine. I just meant the current kernel (before
> .25) could detect you are using a uboot that won't work after
> .25 anymore, and shout at the user. Would save you some bug
> reports ;-)
I don't think that's possible. I'm only updating the DTS files, not the kernel, because
the kernel has already been updated. Any 2.6.21 or later kernel will work with any U-Boot
and any DTS. The only time we're going to run into a problem is if someone updates the
DTS but does *not* update U-Boot. In this case, U-Boot won't find what it's looking for.
Some U-Boots will even panic in these cases. Not only that, but older U-Boots don't
even check the version number of the device tree they're parsing, and they'll just fail
silently when they get a version they don't understand. Unfortunately, I don't see how I
can fix these problems.
>> In other words, the current U-Boot and Linux code is written to not
>> care what the other one does. I have no plans to remove the code in
>> the kernel that looks for obsolete entries (I'm talking about function
>> of_get_mac_address), because it's "safe".
>
> Well you should remove the "address" thing, it is _not_ safe.
Checking for 'address' after finding no match on 'mac-address' and 'local-mac-address' is
safe, because if that's the only property that has a valid MAC address, I want to use it.
As long as there are people out there using U-Boot 1.1.x, we'll need to keep that code
around.
>> However, now that you mention it, I could update function
>> of_get_mac_address() to display a warning if it only finds the
>> 'address' property.
>
> Yeah exactly.
Ok, I will submit a patch to do that.
--
Timur Tabi
Linux Kernel Developer @ Freescale
^ permalink raw reply
* zImage on mpc5200
From: sarpa @ 2007-06-26 15:11 UTC (permalink / raw)
To: linuxppc-embedded
I am building the Linux kernel target "zImage.elf" in PPC branch of Linux
Kernel 2.6.16.11 and then converting it to zImage.bin using OBJCOPY so that
i can flash it to my PPC based target using BDI. i am currently facing
issues in booting this kernel using my own bootloader(i am not using
u-boot). Before I flood mailing list with more detailed questions I just
wish to know if the standalone kernel image type zImage.elf is know to work
in Linux kernel 2.6.16.11 or not ? Has anyone ever tested standalone
zImage.elf on PPC ? Note that I am able to boot uImage using U-boot for this
kernel but now I am trying to use my own Bootloader to boot zImage.elf "
--
View this message in context: http://www.nabble.com/zImage-on-mpc5200-tf3982933.html#a11307459
Sent from the linuxppc-embedded mailing list archive at Nabble.com.
^ 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