* [PATCH 5121 pci 2/3] powerpc: 5121: Add PCI support.
From: John Rigby @ 2008-08-07 17:36 UTC (permalink / raw)
To: linuxppc-dev; +Cc: John Rigby
In-Reply-To: <1218130587-31176-1-git-send-email-jrigby@freescale.com>
Uses mpc83xx_add_bridge in fsl_pci.c
Adds second register tuple to pci node register property
as previously done for 83xx device trees in a previous patch.
Signed-off-by: John Rigby <jrigby@freescale.com>
---
arch/powerpc/boot/dts/mpc5121ads.dts | 4 +++-
arch/powerpc/platforms/512x/Kconfig | 2 ++
arch/powerpc/platforms/512x/mpc5121_ads.c | 10 ++++++++++
arch/powerpc/sysdev/fsl_pci.c | 4 ++--
4 files changed, 17 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/boot/dts/mpc5121ads.dts b/arch/powerpc/boot/dts/mpc5121ads.dts
index 1f9036c..b5444f7 100644
--- a/arch/powerpc/boot/dts/mpc5121ads.dts
+++ b/arch/powerpc/boot/dts/mpc5121ads.dts
@@ -403,8 +403,10 @@
#interrupt-cells = <1>;
#size-cells = <2>;
#address-cells = <3>;
- reg = <0x80008500 0x100>;
+ reg = <0x80008500 0x100 /* internal registers */
+ 0x80008300 0x8>; /* config space access registers */
compatible = "fsl,mpc5121-pci";
device_type = "pci";
+ primary;
};
};
diff --git a/arch/powerpc/platforms/512x/Kconfig b/arch/powerpc/platforms/512x/Kconfig
index c62f893..326852c 100644
--- a/arch/powerpc/platforms/512x/Kconfig
+++ b/arch/powerpc/platforms/512x/Kconfig
@@ -3,6 +3,8 @@ config PPC_MPC512x
select FSL_SOC
select IPIC
select PPC_CLOCK
+ select PPC_PCI_CHOICE
+ select FSL_PCI if PCI
config PPC_MPC5121
bool
diff --git a/arch/powerpc/platforms/512x/mpc5121_ads.c b/arch/powerpc/platforms/512x/mpc5121_ads.c
index 5ebf693..441abc4 100644
--- a/arch/powerpc/platforms/512x/mpc5121_ads.c
+++ b/arch/powerpc/platforms/512x/mpc5121_ads.c
@@ -22,16 +22,26 @@
#include <asm/prom.h>
#include <asm/time.h>
+#include <sysdev/fsl_pci.h>
+
#include "mpc512x.h"
#include "mpc5121_ads.h"
static void __init mpc5121_ads_setup_arch(void)
{
+#ifdef CONFIG_PCI
+ struct device_node *np;
+#endif
printk(KERN_INFO "MPC5121 ADS board from Freescale Semiconductor\n");
/*
* cpld regs are needed early
*/
mpc5121_ads_cpld_map();
+
+#ifdef CONFIG_PCI
+ for_each_compatible_node(np, "pci", "fsl,mpc5121-pci")
+ mpc83xx_add_bridge(np);
+#endif
}
static void __init mpc5121_ads_init_IRQ(void)
diff --git a/arch/powerpc/sysdev/fsl_pci.c b/arch/powerpc/sysdev/fsl_pci.c
index c4bdfc2..0acdd1e 100644
--- a/arch/powerpc/sysdev/fsl_pci.c
+++ b/arch/powerpc/sysdev/fsl_pci.c
@@ -251,7 +251,7 @@ DECLARE_PCI_FIXUP_HEADER(0x1957, PCI_DEVICE_ID_MPC8641D, quirk_fsl_pcie_header);
DECLARE_PCI_FIXUP_HEADER(0x1957, PCI_DEVICE_ID_MPC8610, quirk_fsl_pcie_header);
#endif /* CONFIG_PPC_85xx || CONFIG_PPC_86xx */
-#if defined(CONFIG_PPC_83xx)
+#if defined(CONFIG_PPC_83xx) || defined(CONFIG_PPC_MPC512x)
int __init mpc83xx_add_bridge(struct device_node *dev)
{
int len;
@@ -313,7 +313,7 @@ int __init mpc83xx_add_bridge(struct device_node *dev)
setup_indirect_pci(hose, rsrc_cfg.start, rsrc_cfg.start + 4, 0);
- printk(KERN_INFO "Found MPC83xx PCI host bridge at 0x%016llx. "
+ printk(KERN_INFO "Found FSL PCI host bridge at 0x%016llx. "
"Firmware bus number: %d->%d\n",
(unsigned long long)rsrc_reg.start, hose->first_busno,
hose->last_busno);
--
^ permalink raw reply related
* [PATCH 5121 pci 1/3] powerpc: 83xx: pci: Remove need for get_immrbase from mpc83xx_add_bridge.
From: John Rigby @ 2008-08-07 17:36 UTC (permalink / raw)
To: linuxppc-dev; +Cc: John Rigby
Modify mpc83xx_add_bridge to get config space register base address from the device
tree instead of immr + hardcoded offset.
83xx pci nodes have these changes:
register properties now contain two address length tuples:
First is the pci bridge register base, this has always been there.
Second is the config base, this is new.
The primary pci bus should have the "primary" property.
These are documented in Documentation/powerpc/dts-bindings/fsl/83xx-512x-pci.txt
The changes accomplish these things:
mpc83xx_add_bridge no longer needs to call get_immrbase
it uses hard coded addresses if the second register value is missing
it no longer needs to devine primary property from register base
Signed-off-by: John Rigby <jrigby@freescale.com>
---
.../powerpc/dts-bindings/fsl/83xx-512x-pci.txt | 43 ++++++++++++++++
arch/powerpc/boot/dts/mpc8313erdb.dts | 4 +-
arch/powerpc/boot/dts/mpc8315erdb.dts | 4 +-
arch/powerpc/boot/dts/mpc832x_mds.dts | 4 +-
arch/powerpc/boot/dts/mpc832x_rdb.dts | 4 +-
arch/powerpc/boot/dts/mpc8349emitx.dts | 7 ++-
arch/powerpc/boot/dts/mpc8349emitxgp.dts | 4 +-
arch/powerpc/boot/dts/mpc834x_mds.dts | 7 ++-
arch/powerpc/boot/dts/mpc836x_mds.dts | 4 +-
arch/powerpc/boot/dts/mpc836x_rdk.dts | 4 +-
arch/powerpc/boot/dts/mpc8377_mds.dts | 4 +-
arch/powerpc/boot/dts/mpc8377_rdb.dts | 4 +-
arch/powerpc/boot/dts/mpc8378_mds.dts | 4 +-
arch/powerpc/boot/dts/mpc8378_rdb.dts | 4 +-
arch/powerpc/boot/dts/mpc8379_mds.dts | 4 +-
arch/powerpc/boot/dts/mpc8379_rdb.dts | 4 +-
arch/powerpc/boot/dts/sbc8349.dts | 4 +-
arch/powerpc/sysdev/fsl_pci.c | 53 +++++++++++++------
18 files changed, 131 insertions(+), 35 deletions(-)
create mode 100644 Documentation/powerpc/dts-bindings/fsl/83xx-512x-pci.txt
diff --git a/Documentation/powerpc/dts-bindings/fsl/83xx-512x-pci.txt b/Documentation/powerpc/dts-bindings/fsl/83xx-512x-pci.txt
new file mode 100644
index 0000000..51214a0
--- /dev/null
+++ b/Documentation/powerpc/dts-bindings/fsl/83xx-512x-pci.txt
@@ -0,0 +1,43 @@
+* Freescale 83xx and 512x PCI bridges
+
+Freescale 83xx and 512x SOCs include the same pci bridge core.
+
+83xx/512x specific notes:
+- reg: should contain two address length tuples
+ The first is for the internal pci bridge registers
+ The second is for the pci config space access registers
+- primary:
+ This property should be present for the primary pci bridge
+
+Example (MPC8313ERDB)
+ pci0: pci@e0008500 {
+ cell-index = <1>;
+ interrupt-map-mask = <0xf800 0x0 0x0 0x7>;
+ interrupt-map = <
+ /* IDSEL 0x0E -mini PCI */
+ 0x7000 0x0 0x0 0x1 &ipic 18 0x8
+ 0x7000 0x0 0x0 0x2 &ipic 18 0x8
+ 0x7000 0x0 0x0 0x3 &ipic 18 0x8
+ 0x7000 0x0 0x0 0x4 &ipic 18 0x8
+
+ /* IDSEL 0x0F - PCI slot */
+ 0x7800 0x0 0x0 0x1 &ipic 17 0x8
+ 0x7800 0x0 0x0 0x2 &ipic 18 0x8
+ 0x7800 0x0 0x0 0x3 &ipic 17 0x8
+ 0x7800 0x0 0x0 0x4 &ipic 18 0x8>;
+ interrupt-parent = <&ipic>;
+ interrupts = <66 0x8>;
+ bus-range = <0x0 0x0>;
+ ranges = <0x02000000 0x0 0x90000000 0x90000000 0x0 0x10000000
+ 0x42000000 0x0 0x80000000 0x80000000 0x0 0x10000000
+ 0x01000000 0x0 0x00000000 0xe2000000 0x0 0x00100000>;
+ clock-frequency = <66666666>;
+ #interrupt-cells = <1>;
+ #size-cells = <2>;
+ #address-cells = <3>;
+ reg = <0xe0008500 0x100 /* internal registers */
+ 0xe0008300 0x8>; /* config space access registers */
+ compatible = "fsl,mpc8349-pci";
+ device_type = "pci";
+ primary;
+ };
diff --git a/arch/powerpc/boot/dts/mpc8313erdb.dts b/arch/powerpc/boot/dts/mpc8313erdb.dts
index 2a94ae0..f4d84bb 100644
--- a/arch/powerpc/boot/dts/mpc8313erdb.dts
+++ b/arch/powerpc/boot/dts/mpc8313erdb.dts
@@ -359,9 +359,11 @@
#interrupt-cells = <1>;
#size-cells = <2>;
#address-cells = <3>;
- reg = <0xe0008500 0x100>;
+ reg = <0xe0008500 0x100 /* internal registers */
+ 0xe0008300 0x8>; /* config space access registers */
compatible = "fsl,mpc8349-pci";
device_type = "pci";
+ primary;
};
dma@82a8 {
diff --git a/arch/powerpc/boot/dts/mpc8315erdb.dts b/arch/powerpc/boot/dts/mpc8315erdb.dts
index f704513..d7a6c4a 100644
--- a/arch/powerpc/boot/dts/mpc8315erdb.dts
+++ b/arch/powerpc/boot/dts/mpc8315erdb.dts
@@ -314,8 +314,10 @@
#interrupt-cells = <1>;
#size-cells = <2>;
#address-cells = <3>;
- reg = <0xe0008500 0x100>;
+ reg = <0xe0008500 0x100 /* internal registers */
+ 0xe0008300 0x8>; /* config space access registers */
compatible = "fsl,mpc8349-pci";
device_type = "pci";
+ primary;
};
};
diff --git a/arch/powerpc/boot/dts/mpc832x_mds.dts b/arch/powerpc/boot/dts/mpc832x_mds.dts
index fbc9304..fe3bb7d 100644
--- a/arch/powerpc/boot/dts/mpc832x_mds.dts
+++ b/arch/powerpc/boot/dts/mpc832x_mds.dts
@@ -419,8 +419,10 @@
#interrupt-cells = <1>;
#size-cells = <2>;
#address-cells = <3>;
- reg = <0xe0008500 0x100>;
+ reg = <0xe0008500 0x100 /* internal registers */
+ 0xe0008300 0x8>; /* config space access registers */
compatible = "fsl,mpc8349-pci";
device_type = "pci";
+ primary;
};
};
diff --git a/arch/powerpc/boot/dts/mpc832x_rdb.dts b/arch/powerpc/boot/dts/mpc832x_rdb.dts
index b157d18..74206e8 100644
--- a/arch/powerpc/boot/dts/mpc832x_rdb.dts
+++ b/arch/powerpc/boot/dts/mpc832x_rdb.dts
@@ -327,8 +327,10 @@
#interrupt-cells = <1>;
#size-cells = <2>;
#address-cells = <3>;
- reg = <0xe0008500 0x100>;
+ reg = <0xe0008500 0x100 /* internal registers */
+ 0xe0008300 0x8>; /* config space access registers */
compatible = "fsl,mpc8349-pci";
device_type = "pci";
+ primary;
};
};
diff --git a/arch/powerpc/boot/dts/mpc8349emitx.dts b/arch/powerpc/boot/dts/mpc8349emitx.dts
index 700e076..f78feac 100644
--- a/arch/powerpc/boot/dts/mpc8349emitx.dts
+++ b/arch/powerpc/boot/dts/mpc8349emitx.dts
@@ -250,9 +250,11 @@
#interrupt-cells = <1>;
#size-cells = <2>;
#address-cells = <3>;
- reg = <0xe0008500 0x100>;
+ reg = <0xe0008500 0x100 /* internal registers */
+ 0xe0008300 0x8>; /* config space access registers */
compatible = "fsl,mpc8349-pci";
device_type = "pci";
+ primary;
};
pci1: pci@e0008600 {
@@ -276,7 +278,8 @@
#interrupt-cells = <1>;
#size-cells = <2>;
#address-cells = <3>;
- reg = <0xe0008600 0x100>;
+ reg = <0xe0008600 0x100 /* internal registers */
+ 0xe0008380 0x8>; /* config space access registers */
compatible = "fsl,mpc8349-pci";
device_type = "pci";
};
diff --git a/arch/powerpc/boot/dts/mpc8349emitxgp.dts b/arch/powerpc/boot/dts/mpc8349emitxgp.dts
index cdd3063..2c1121b 100644
--- a/arch/powerpc/boot/dts/mpc8349emitxgp.dts
+++ b/arch/powerpc/boot/dts/mpc8349emitxgp.dts
@@ -224,8 +224,10 @@
#interrupt-cells = <1>;
#size-cells = <2>;
#address-cells = <3>;
- reg = <0xe0008600 0x100>;
+ reg = <0xe0008600 0x100 /* internal registers */
+ 0xe0008380 0x8>; /* config space access registers */
compatible = "fsl,mpc8349-pci";
device_type = "pci";
+ primary;
};
};
diff --git a/arch/powerpc/boot/dts/mpc834x_mds.dts b/arch/powerpc/boot/dts/mpc834x_mds.dts
index 783241c..5df5ee1 100644
--- a/arch/powerpc/boot/dts/mpc834x_mds.dts
+++ b/arch/powerpc/boot/dts/mpc834x_mds.dts
@@ -311,9 +311,11 @@
#interrupt-cells = <1>;
#size-cells = <2>;
#address-cells = <3>;
- reg = <0xe0008500 0x100>;
+ reg = <0xe0008500 0x100 /* internal registers */
+ 0xe0008300 0x8>; /* config space access registers */
compatible = "fsl,mpc8349-pci";
device_type = "pci";
+ primary;
};
pci1: pci@e0008600 {
@@ -372,7 +374,8 @@
#interrupt-cells = <1>;
#size-cells = <2>;
#address-cells = <3>;
- reg = <0xe0008600 0x100>;
+ reg = <0xe0008600 0x100 /* internal registers */
+ 0xe0008380 0x8>; /* config space access registers */
compatible = "fsl,mpc8349-pci";
device_type = "pci";
};
diff --git a/arch/powerpc/boot/dts/mpc836x_mds.dts b/arch/powerpc/boot/dts/mpc836x_mds.dts
index a3b76a7..d735c82 100644
--- a/arch/powerpc/boot/dts/mpc836x_mds.dts
+++ b/arch/powerpc/boot/dts/mpc836x_mds.dts
@@ -405,8 +405,10 @@
#interrupt-cells = <1>;
#size-cells = <2>;
#address-cells = <3>;
- reg = <0xe0008500 0x100>;
+ reg = <0xe0008500 0x100 /* internal registers */
+ 0xe0008300 0x8>; /* config space access registers */
compatible = "fsl,mpc8349-pci";
device_type = "pci";
+ primary;
};
};
diff --git a/arch/powerpc/boot/dts/mpc836x_rdk.dts b/arch/powerpc/boot/dts/mpc836x_rdk.dts
index 89c9202..cef069f 100644
--- a/arch/powerpc/boot/dts/mpc836x_rdk.dts
+++ b/arch/powerpc/boot/dts/mpc836x_rdk.dts
@@ -405,7 +405,8 @@
#interrupt-cells = <1>;
device_type = "pci";
compatible = "fsl,mpc8360-pci", "fsl,mpc8349-pci";
- reg = <0xe0008500 0x100>;
+ reg = <0xe0008500 0x100 /* internal registers */
+ 0xe0008300 0x8>; /* config space access registers */
ranges = <0x02000000 0 0x90000000 0x90000000 0 0x10000000
0x42000000 0 0x80000000 0x80000000 0 0x10000000
0x01000000 0 0xe0300000 0xe0300000 0 0x00100000>;
@@ -424,5 +425,6 @@
/* filled by u-boot */
bus-range = <0 0>;
clock-frequency = <0>;
+ primary;
};
};
diff --git a/arch/powerpc/boot/dts/mpc8377_mds.dts b/arch/powerpc/boot/dts/mpc8377_mds.dts
index 432782b..c206688 100644
--- a/arch/powerpc/boot/dts/mpc8377_mds.dts
+++ b/arch/powerpc/boot/dts/mpc8377_mds.dts
@@ -374,8 +374,10 @@
#interrupt-cells = <1>;
#size-cells = <2>;
#address-cells = <3>;
- reg = <0xe0008500 0x100>;
+ reg = <0xe0008500 0x100 /* internal registers */
+ 0xe0008300 0x8>; /* config space access registers */
compatible = "fsl,mpc8349-pci";
device_type = "pci";
+ primary;
};
};
diff --git a/arch/powerpc/boot/dts/mpc8377_rdb.dts b/arch/powerpc/boot/dts/mpc8377_rdb.dts
index ed137aa..f79ede2 100644
--- a/arch/powerpc/boot/dts/mpc8377_rdb.dts
+++ b/arch/powerpc/boot/dts/mpc8377_rdb.dts
@@ -315,8 +315,10 @@
#interrupt-cells = <1>;
#size-cells = <2>;
#address-cells = <3>;
- reg = <0xe0008500 0x100>;
+ reg = <0xe0008500 0x100 /* internal registers */
+ 0xe0008300 0x8>; /* config space access registers */
compatible = "fsl,mpc8349-pci";
device_type = "pci";
+ primary;
};
};
diff --git a/arch/powerpc/boot/dts/mpc8378_mds.dts b/arch/powerpc/boot/dts/mpc8378_mds.dts
index ed32c8d..0f1f3d8 100644
--- a/arch/powerpc/boot/dts/mpc8378_mds.dts
+++ b/arch/powerpc/boot/dts/mpc8378_mds.dts
@@ -360,8 +360,10 @@
#interrupt-cells = <1>;
#size-cells = <2>;
#address-cells = <3>;
- reg = <0xe0008500 0x100>;
+ reg = <0xe0008500 0x100 /* internal registers */
+ 0xe0008300 0x8>; /* config space access registers */
compatible = "fsl,mpc8349-pci";
device_type = "pci";
+ primary;
};
};
diff --git a/arch/powerpc/boot/dts/mpc8378_rdb.dts b/arch/powerpc/boot/dts/mpc8378_rdb.dts
index 34a7f2f..795fb08 100644
--- a/arch/powerpc/boot/dts/mpc8378_rdb.dts
+++ b/arch/powerpc/boot/dts/mpc8378_rdb.dts
@@ -301,8 +301,10 @@
#interrupt-cells = <1>;
#size-cells = <2>;
#address-cells = <3>;
- reg = <0xe0008500 0x100>;
+ reg = <0xe0008500 0x100 /* internal registers */
+ 0xe0008300 0x8>; /* config space access registers */
compatible = "fsl,mpc8349-pci";
device_type = "pci";
+ primary;
};
};
diff --git a/arch/powerpc/boot/dts/mpc8379_mds.dts b/arch/powerpc/boot/dts/mpc8379_mds.dts
index f4db9ed..0b75826 100644
--- a/arch/powerpc/boot/dts/mpc8379_mds.dts
+++ b/arch/powerpc/boot/dts/mpc8379_mds.dts
@@ -388,8 +388,10 @@
#interrupt-cells = <1>;
#size-cells = <2>;
#address-cells = <3>;
- reg = <0xe0008500 0x100>;
+ reg = <0xe0008500 0x100 /* internal registers */
+ 0xe0008300 0x8>; /* config space access registers */
compatible = "fsl,mpc8349-pci";
device_type = "pci";
+ primary;
};
};
diff --git a/arch/powerpc/boot/dts/mpc8379_rdb.dts b/arch/powerpc/boot/dts/mpc8379_rdb.dts
index e4d7030..cc7cac1 100644
--- a/arch/powerpc/boot/dts/mpc8379_rdb.dts
+++ b/arch/powerpc/boot/dts/mpc8379_rdb.dts
@@ -329,8 +329,10 @@
#interrupt-cells = <1>;
#size-cells = <2>;
#address-cells = <3>;
- reg = <0xe0008500 0x100>;
+ reg = <0xe0008500 0x100 /* internal registers */
+ 0xe0008300 0x8>; /* config space access registers */
compatible = "fsl,mpc8349-pci";
device_type = "pci";
+ primary;
};
};
diff --git a/arch/powerpc/boot/dts/sbc8349.dts b/arch/powerpc/boot/dts/sbc8349.dts
index 45f789b..ac41fad 100644
--- a/arch/powerpc/boot/dts/sbc8349.dts
+++ b/arch/powerpc/boot/dts/sbc8349.dts
@@ -268,8 +268,10 @@
#interrupt-cells = <1>;
#size-cells = <2>;
#address-cells = <3>;
- reg = <0xe0008500 0x100>;
+ reg = <0xe0008500 0x100 /* internal registers */
+ 0xe0008300 0x8>; /* config space access registers */
compatible = "fsl,mpc8349-pci";
device_type = "pci";
+ primary;
};
};
diff --git a/arch/powerpc/sysdev/fsl_pci.c b/arch/powerpc/sysdev/fsl_pci.c
index 61e6d77..c4bdfc2 100644
--- a/arch/powerpc/sysdev/fsl_pci.c
+++ b/arch/powerpc/sysdev/fsl_pci.c
@@ -256,15 +256,45 @@ int __init mpc83xx_add_bridge(struct device_node *dev)
{
int len;
struct pci_controller *hose;
- struct resource rsrc;
+ struct resource rsrc_reg;
+ struct resource rsrc_cfg;
const int *bus_range;
- int primary = 1, has_address = 0;
- phys_addr_t immr = get_immrbase();
+ int primary = 0;
pr_debug("Adding PCI host bridge %s\n", dev->full_name);
/* Fetch host bridge registers address */
- has_address = (of_address_to_resource(dev, 0, &rsrc) == 0);
+ if (of_address_to_resource(dev, 0, &rsrc_reg)) {
+ printk(KERN_WARNING "Can't get pci register base!\n");
+ return -ENOMEM;
+ }
+
+ memset(&rsrc_cfg, 0, sizeof(rsrc_cfg));
+
+ if (of_address_to_resource(dev, 1, &rsrc_cfg)) {
+ printk(KERN_WARNING
+ "No pci config register base in dev tree, "
+ "using default\n");
+ /*
+ * MPC83xx supports up to two host controllers, one at 0x8500
+ * from immrbar. The other is at 0x8600. We consider the
+ * one at 0x8500 the primary controller.
+ */
+ /* PCI 1 */
+ if ((rsrc_reg.start & 0xfffff) == 0x8500) {
+ rsrc_cfg.start = (rsrc_reg.start & 0xfff00000) + 0x8300;
+ primary = 1;
+ }
+ /* PCI 2 */
+ if ((rsrc_reg.start & 0xfffff) == 0x8600) {
+ rsrc_cfg.start = (rsrc_reg.start & 0xfff00000) + 0x8380;
+ primary = 0;
+ }
+ }
+
+ /* Check if primary bridge */
+ if (of_get_property(dev, "primary", NULL))
+ primary = 1;
/* Get bus range if any */
bus_range = of_get_property(dev, "bus-range", &len);
@@ -281,22 +311,11 @@ int __init mpc83xx_add_bridge(struct device_node *dev)
hose->first_busno = bus_range ? bus_range[0] : 0;
hose->last_busno = bus_range ? bus_range[1] : 0xff;
- /* MPC83xx supports up to two host controllers one at 0x8500 from immrbar
- * the other at 0x8600, we consider the 0x8500 the primary controller
- */
- /* PCI 1 */
- if ((rsrc.start & 0xfffff) == 0x8500) {
- setup_indirect_pci(hose, immr + 0x8300, immr + 0x8304, 0);
- }
- /* PCI 2 */
- if ((rsrc.start & 0xfffff) == 0x8600) {
- setup_indirect_pci(hose, immr + 0x8380, immr + 0x8384, 0);
- primary = 0;
- }
+ setup_indirect_pci(hose, rsrc_cfg.start, rsrc_cfg.start + 4, 0);
printk(KERN_INFO "Found MPC83xx PCI host bridge at 0x%016llx. "
"Firmware bus number: %d->%d\n",
- (unsigned long long)rsrc.start, hose->first_busno,
+ (unsigned long long)rsrc_reg.start, hose->first_busno,
hose->last_busno);
pr_debug(" ->Hose at 0x%p, cfg_addr=0x%p,cfg_data=0x%p\n",
--
^ permalink raw reply related
* Re: [RFC] [PATCH 0/5 V2] Huge page backed user-space stacks
From: Dave Hansen @ 2008-08-07 17:29 UTC (permalink / raw)
To: Mel Gorman
Cc: linux-mm, libhugetlbfs-devel, linux-kernel, linuxppc-dev, abh,
ebmunson, Andrew Morton
In-Reply-To: <20080807160605.GA9200@csn.ul.ie>
On Thu, 2008-08-07 at 17:06 +0100, Mel Gorman wrote:
> On (06/08/08 12:50), Dave Hansen didst pronounce:
> > The main thing this set of patches does that I care about is take an
> > anonymous VMA and replace it with a hugetlb VMA. It does this on a
> > special cue, but does it nonetheless.
>
> This is not actually a new thing. For a long time now, it has been possible to
> back malloc() with hugepages at a userspace level using the morecore glibc
> hook. That is replacing anonymous memory with a file-backed VMA. It happens
> in a different place but it's just as deliberate as backing stack and the
> end result is very similar. As the file is ram-based, it doesn't have the
> same types of consequences like dirty page syncing that you'd ordinarily
> watch for when moving from anonymous to file-backed memory.
Yes, it has already been done in userspace. That's fine. It isn't
adding any complexity to the kernel. This is adding behavior that the
kernel has to support as well as complexity.
> > This patch has crossed a line in that it is really the first
> > *replacement* of a normal VMA with a hugetlb VMA instead of the creation
> > of the VMAs at the user's request.
>
> We crossed that line with morecore, it's back there somewhere. We're just
> doing in kernel this time because backing stacks with hugepages in userspace
> turned out to be a hairy endevour.
>
> Properly supporting anonymous hugepages would either require larger
> changes to the core or reimplementing yet more of mm/ in mm/hugetlb.c.
> Neither is a particularly appealing approach, nor is it likely to be a
> very popular one.
I agree. It is always much harder to write code that can work
generically (and get it accepted) than just write the smallest possible
hack and stick it in fs/exec.c.
Could this patch at least get fixed up to look like it could be used
more generically? Some code to look up and replace anonymous VMAs with
hugetlb-backed ones.
> > Because of the limitations like its inability to grow the VMA, I can't
> > imagine that this would be a generic mechanism that we can use
> > elsewhere.
>
> What other than a stack even cares about VM_GROWSDOWN working? Besides,
> VM_GROWSDOWN could be supported in a hugetlbfs file by mapping the end of
> the file and moving the offset backwards (yeah ok, it ain't the prettiest
> but it's less churn than introducing significantly different codepaths). It's
> just not something that needs to be supported at first cut.
>
> brk() if you wanted to back hugepages with it conceivably needs a resizing
> VMA but in that case it's growing up in which case just extend the end of
> the VMA and increase the size of the file.
I'm more worried about a small huge page size (say 64k) and not being
able to merge the VMAs. I guess it could start in the *middle* of a
file and map both directions.
I guess you could always just have a single (very sparse) hugetlb file
per mm to do all of this 'anonymous' hugetlb memory memory stuff, and
just map its offsets 1:1 on to the process's virtual address space.
That would make sure you could always merge VMAs, no matter how they
grew together.
-- Dave
^ permalink raw reply
* RE: [RFC/PATCH 2/3] of: add of_lookup_stdout() utility function
From: Yoder Stuart @ 2008-08-07 17:28 UTC (permalink / raw)
To: David Gibson, TABI TIMUR
Cc: linuxppc-dev, devicetree-discuss, paulus, miltonm
In-Reply-To: <20080807061254.GB12571@yookeroo.seuss>
=20
> -----Original Message-----
> From: linuxppc-dev-bounces+b08248=3Dfreescale.com@ozlabs.org=20
> [mailto:linuxppc-dev-bounces+b08248=3Dfreescale.com@ozlabs.org]=20
> On Behalf Of David Gibson
> Sent: Thursday, August 07, 2008 1:13 AM
> To: Tabi Timur
> Cc: linuxppc-dev@ozlabs.org; paulus@samba.org; miltonm@bga.com
> Subject: Re: [RFC/PATCH 2/3] of: add of_lookup_stdout()=20
> utility function
>=20
> On Wed, Aug 06, 2008 at 11:46:47AM -0500, Timur Tabi wrote:
> > On Wed, Aug 6, 2008 at 1:02 AM, Grant Likely=20
> <grant.likely@secretlab.ca> wrote:
> > > From: Grant Likely <grant.likely@secretlab.ca>
> > >
> > > of_lookup_stdout() is useful for figuring out what device=20
> to use as output
> > > for early boot progress messages. It returns the node=20
> pointed to by the
> > > linux,stdout-path property in the chosen node.
> >=20
> > I thought linux,stdout-path is deprecated are we're supposed to be
> > using the aliases node instead?
>=20
> During the ePAPR process this idea came up - standardising a 'stdout'
> alias that would replace linux,stdout-path in chosen. However that
> was done in ignorance of the history of the linux,stdout-path property
> and its connection to the stdout ihandle in chosen. In any case, the
> proposed 'stdout' alias didn't make the final cut for ePAPR, so how to
> address this for flat-tree systems is still an open question.
In the ePAPR discussion I think we generally agreed that
an alias was better than a property under /chosen. There
were 2 things that caused us to delete the /aliases/stdout.
One was discussions around whether we needed to support
multiple consoles somehow.
The second was the idea that we may need a /aliases/stdin as well.
You could conceptually have stdout be a monitor and a stdin
be a keyboard.
Stuart
^ permalink raw reply
* Re: [RFC/PATCH 1/3] powerpc: add ioremap_bat() function for setting up BAT translated IO regions.
From: Scott Wood @ 2008-08-07 16:45 UTC (permalink / raw)
To: Grant Likely; +Cc: paulus, miltonm, linuxppc-dev
In-Reply-To: <fa686aa40808061611p616208bp2baf9a0d5e095870@mail.gmail.com>
On Wed, Aug 06, 2008 at 05:11:08PM -0600, Grant Likely wrote:
> I do this particular test to make absolute sure that the caller
> absolutely understands the limitations of the block mapping. If they
> call this with something that isn't 128k aligned, then I make it fail
> immediately so the coder is forced to go and understand what they are
> allowed to do. Basically, I'm reinforcing the fact that this is not
> the same as ioremap().
>
> I haven't decided yet if I should test size in the same way. Thoughts?
I'd prefer it round up the size as needed to cover the requested mapping
and needed alignment.
The minimum size is going to be different on Book E, for example, and I
can think of at least one user that will be shared between Book E and
classic (CPM2 early console).
-Scott
^ permalink raw reply
* [RFC] Driver helper functions.....
From: Sean MacLennan @ 2008-08-07 16:22 UTC (permalink / raw)
To: linuxppc-dev, Josh Boyer
The design of the warp is basically a processor, an FPGA, some RAM,
some flash, and some glue logic. As the number of drivers rapidly
expands... we are starting to hit inter-driver conflicts with a select
few FPGA registers.
So we need a few "helper" functions to handle locking. Basically
something like this:
static DEFINE_SPINLOCK(fpga_lock);
void warp_fpga_set_imr(imr)
{ /* imr = interrupt mask register */
lock
read/modify/write imr
unlock
}
void warp_fpga_clear_imr(imr);
int warp_fpga_indirect_read();
int warp_fpga_indirect_write();
Maybe a couple more, but I think it would basically be four functions.
So I see a few solutions:
1) Write an fpga driver. That seems overkill for basically exporting
four functions.
2) Add a non-static spinlock to the platform code and export that. This
adds minimal code to the platform code but gives eveybody a lock that
is always there.
3) Add the above functions to the platform code.
So my questions are, what would be best practice? Would adding the
functions and/or spinlock to the platform code be kosher?
And if I did add the spinlock and/or functions to the platform code,
where would I put the include file to export them from? In the arch
code itself? i.e. arch/powerpc/platforms/44x/warp.h?
Cheers,
Sean
^ permalink raw reply
* Re: [RFC] [PATCH 0/5 V2] Huge page backed user-space stacks
From: Mel Gorman @ 2008-08-07 16:06 UTC (permalink / raw)
To: Dave Hansen
Cc: linux-mm, libhugetlbfs-devel, linux-kernel, linuxppc-dev, abh,
ebmunson, Andrew Morton
In-Reply-To: <1218052249.10907.125.camel@nimitz>
On (06/08/08 12:50), Dave Hansen didst pronounce:
> On Wed, 2008-08-06 at 10:02 +0100, Mel Gorman wrote:
> > > That said, this particular patch doesn't appear *too* bound to hugetlb
> > > itself. But, some of its limitations *do* come from the filesystem,
> > > like its inability to handle VM_GROWS...
> >
> > The lack of VM_GROWSX is an issue, but on its own it does not justify
> > the amount of churn necessary to support direct pagetable insertions for
> > MAP_ANONYMOUS|MAP_PRIVATE. I think we'd need another case or two that would
> > really benefit from direct insertions to pagetables instead of hugetlbfs so
> > that the path would get adequately tested.
>
> I'm jumping around here a bit, but I'm trying to get to the core of what
> my problem with these patches is. I'll see if I can close the loop
> here.
>
> The main thing this set of patches does that I care about is take an
> anonymous VMA and replace it with a hugetlb VMA. It does this on a
> special cue, but does it nonetheless.
>
This is not actually a new thing. For a long time now, it has been possible to
back malloc() with hugepages at a userspace level using the morecore glibc
hook. That is replacing anonymous memory with a file-backed VMA. It happens
in a different place but it's just as deliberate as backing stack and the
end result is very similar. As the file is ram-based, it doesn't have the
same types of consequences like dirty page syncing that you'd ordinarily
watch for when moving from anonymous to file-backed memory.
> This patch has crossed a line in that it is really the first
> *replacement* of a normal VMA with a hugetlb VMA instead of the creation
> of the VMAs at the user's request.
We crossed that line with morecore, it's back there somewhere. We're just
doing in kernel this time because backing stacks with hugepages in userspace
turned out to be a hairy endevour.
Properly supporting anonymous hugepages would either require larger
changes to the core or reimplementing yet more of mm/ in mm/hugetlb.c.
Neither is a particularly appealing approach, nor is it likely to be a
very popular one.
> I'm really curious what the plan is
> to follow up on this. Will this stack stuff turn out to be one-off
> code, or is this *the* route for getting transparent large pages in the
> future?
>
Conceivably, we could also implement MAP_LARGEPAGE for MAP_ANONYMOUS
which would use the same hugetlb_file_setup() as for shmem and stacks
with this patch. It would be a reliavely straight-forward patch if reusing
hugetlb_file_setup() as the flags can be passed through almost verbatim. In
that case, hugetlbfs still makes a good fit without making direct pagetable
insertions necessary.
> Because of the limitations like its inability to grow the VMA, I can't
> imagine that this would be a generic mechanism that we can use
> elsewhere.
>
What other than a stack even cares about VM_GROWSDOWN working? Besides,
VM_GROWSDOWN could be supported in a hugetlbfs file by mapping the end of
the file and moving the offset backwards (yeah ok, it ain't the prettiest
but it's less churn than introducing significantly different codepaths). It's
just not something that needs to be supported at first cut.
brk() if you wanted to back hugepages with it conceivably needs a resizing
VMA but in that case it's growing up in which case just extend the end of
the VMA and increase the size of the file.
--
Mel Gorman
Part-time Phd Student Linux Technology Center
University of Limerick IBM Dublin Software Lab
^ permalink raw reply
* Re: [PATCH] i2c-mpc: suppress I2C device probing
From: Grant Likely @ 2008-08-07 14:33 UTC (permalink / raw)
To: Jean Delvare; +Cc: Linuxppc-dev
In-Reply-To: <20080807130717.56694249@hyperion.delvare>
On Thu, Aug 7, 2008 at 5:07 AM, Jean Delvare <khali@linux-fr.org> wrote:
> On Thu, 07 Aug 2008 12:50:11 +0200, Jochen Friedrich wrote:
>> Hi Wolfgang,
>>
>> > $ grep I2C_CLASS_HWMON *
>> > i2c-cpm.c: .class = I2C_CLASS_HWMON | I2C_CLASS_SPD,
>> > i2c-mpc.c: .class = I2C_CLASS_HWMON | I2C_CLASS_SPD,
>> > i2c-ibm_iic.c: adap->class = I2C_CLASS_HWMON | I2C_CLASS_SPD;
>> > i2c-pasemi.c: smbus->adapter.class = I2C_CLASS_HWMON | I2C_CLASS_SPD;
>> > i2c-mv64xxx.c: drv_data->adapter.class = I2C_CLASS_HWMON | I2C_CLASS_SPD;
>> >
>> > It would be consequent to remove them as well.
>>
>> ACK for the i2c-cpm part.
>
> No objection on my side. It's really up to each platform to choose the
> way they want to handle i2c device creation, and stick to it.
>
> As I understand it, the removal of the adapter class needs to be
> synchronized with platform code changes. Thus it might make sense to
> push these through their respective arch trees, rather than the i2c
> tree.
All right, I'm happy to pick these patches up if nobody objects.
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: [PATCH 4/6] powerpc: add USB peripheral support to MPC8272ADS
From: Scott Wood @ 2008-08-07 14:19 UTC (permalink / raw)
To: Li Yang; +Cc: linuxppc-dev
In-Reply-To: <1218081014.29628.9.camel@Gundam>
On Thu, Aug 07, 2008 at 11:50:14AM +0800, Li Yang wrote:
> udc is a common name for USB device mode drivers to work with Linux
> gadget. We will have two separate drivers for USB host and device.
> Probably we can have two compatibles "fsl,qe_udc" and "fsl,qe-usb-host"
1. If you have separate compatibles, what do you need the "mode" property
for?
2. mpc8272 is not QE.
3. fsl,cpm2-usb-slave would be much more readable than fsl,qe_udc.
-Scott
^ permalink raw reply
* Re: [PATCH] powerpc: Fix Book-E watchdog timer interval setting
From: Matthias Fuchs @ 2008-08-07 14:04 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
In-Reply-To: <A4CCB071-0FCE-490A-B563-399FCA74C71E@kernel.crashing.org>
Sure,
the former line:
mtspr(SPRN_TCR, (mfspr(SPRN_TCR)&~WDTP(0))|WDTP(booke_wdt_period));
tries to mask the wdt interval period bits by and'ing with ~WDTP(0) which
is 0xffffffff. So no bits are cleared and or'ing a new value does not change anything.
The default interval is '3' which is the maximum, so any attempt to set a new
interval keeps the former '3'.
The patch correctly masks the period bits in SPRN_TCR before writing the new value.
That's all.
Matthias
On Thursday 07 August 2008 15:19, Kumar Gala wrote:
>
> On Aug 7, 2008, at 7:48 AM, Matthias Fuchs wrote:
>
> > This patch fixes the setting of the Book-E watchdog timer interval
> > setup
> > on initialization and by ioctl().
> >
> > Tested on PPC440EPx sequoia evaluation board.
> >
> > Signed-off-by: Matthias Fuchs <matthias.fuchs@esd-electronics.com>
> > ---
> > drivers/watchdog/booke_wdt.c | 6 +++++-
> > 1 files changed, 5 insertions(+), 1 deletions(-)
>
> can you be more explicit about what the bug was.
>
> - k
>
>
^ permalink raw reply
* Re: [PATCH 5/6] powerpc: add USB peripheral support to MPC836xMDS
From: Anton Vorontsov @ 2008-08-07 13:23 UTC (permalink / raw)
To: Li Yang; +Cc: linuxppc-dev
In-Reply-To: <1218101504.29628.32.camel@Gundam>
On Thu, Aug 07, 2008 at 05:31:44PM +0800, Li Yang wrote:
[...]
> >
> > > reg = <0x6c0 0x40 0x8b00 0x100>;
> > > interrupts = <11>;
> > > interrupt-parent = <&qeic>;
> > > mode = "slave";
> >
> > I'd suggest to rename this to "peripheral" as we use for fsl dual-role
> > usb controller.
>
> As there will be two drivers chosen by compatible, I'm now inclined to
> put this information in compatible.
Please don't. I deliberately wrote bindings w/o specifing "udc" or
"host" in the compatible entry.
"udc"/"host" is the modes of an USB controller, but the controller
itself is the same: "fsl,mpc8323-qe-usb" (the first chip with QE USB).
So the driver should always match this device, but it can return
-ENODEV if mode is unspecified or !peripheral.
> > > + usb-clock = <21>;
> > > + pio-handle = <&pio_usb>;
> >
> > Can we not introduce new pio maps? The pio setup should be done
> > by the firmware, or at least fixed up via the board file, as in
> > arch/powerpc/platforms/83xx/mpc832x_rdb.c.
>
> Actually I am more apt to leaving full hardware access to kernel than
> firmware, especially for devices that are not used in firmware. The
> reason why I made the pin-configuration flexible is that for development
> boards the role of pins are often changeable.
[...]
> Pio config is board and board configuration specific. It's better to
> make it configurable by device tree.
Device tree isn't configuration file. The bad thing about pio-map is that
it is passing raw values instead of actually describing the hardware.
For example,
pio-map = <1 6 2 0 1 0>;
The thing describes bankB/pin6.. but you'll can't tell what exactly
this pin supposed to do. :-/
Basically "pio-map" is expanded version of this:
fsl,cpodr-reg = <0x...>;
fsl,cppar1-reg = <0x...>;
fsl,cppar2-reg = <0x...>;
...
Instead, it would be great to have something like this:
usb@... {
/*
* gpio/pinmux pin
* controller
*/
pio-map = <&pinmuxA 1 /* bindings says first pin is clk */
&pinmuxB 14 /* bindings says second pin is usboe */
...>;
};
ucc@... {
pio-map = <&pinmuxA 2 /* bindings says first pin is clk */
&pinmuxB 24 /* bindings says second pin is rxd0 */
&pinmuxB 21 /* bindings says second pin is rxd1 */
...>;
};
Then drivers would call something like this in probe():
clk = qe_get_clock(node, "fsl,fullspeed-clock");
qe_set_pinmux(pin0, QE_PIN_FUNC_CLK(clk));
qe_set_pinmux(pin1, QE_PIN_FUNC_USB_OE);
...or ucc ethernet...
qe_set_pinmux(pin[rx_n], QE_PIN_FUNC_UCC_RXD(ucc_num, rx_n));
Obviously, this is quite hard to implement (and expensive, too), since
each SoC implementation has its own function<->pin<->regvalue mapping..
Thus nobody even think to bother with this.
Anyway, I'm not that opposed to the current pio-maps, but it
would be great if we could avoid them where possible.
--
Anton Vorontsov
email: cbouatmailru@gmail.com
irc://irc.freenode.net/bd2
^ permalink raw reply
* Re: [PATCH] powerpc: Fix Book-E watchdog timer interval setting
From: Kumar Gala @ 2008-08-07 13:19 UTC (permalink / raw)
To: Matthias Fuchs; +Cc: linuxppc-dev
In-Reply-To: <200808071448.06183.matthias.fuchs@esd-electronics.com>
On Aug 7, 2008, at 7:48 AM, Matthias Fuchs wrote:
> This patch fixes the setting of the Book-E watchdog timer interval
> setup
> on initialization and by ioctl().
>
> Tested on PPC440EPx sequoia evaluation board.
>
> Signed-off-by: Matthias Fuchs <matthias.fuchs@esd-electronics.com>
> ---
> drivers/watchdog/booke_wdt.c | 6 +++++-
> 1 files changed, 5 insertions(+), 1 deletions(-)
can you be more explicit about what the bug was.
- k
^ permalink raw reply
* Re: [PATCH 2/3] gianfar: Magic Packet and suspend/resume support.
From: Kumar Gala @ 2008-08-07 12:58 UTC (permalink / raw)
To: Jeff Garzik; +Cc: Scott Wood, linuxppc-dev, netdev
In-Reply-To: <489AAB3E.8020507@pobox.com>
On Aug 7, 2008, at 2:58 AM, Jeff Garzik wrote:
> Scott Wood wrote:
>> Signed-off-by: Scott Wood <scottwood@freescale.com>
>> ---
>> Documentation/powerpc/booting-without-of.txt | 5 +-
>> arch/powerpc/sysdev/fsl_soc.c | 3 +
>> drivers/net/gianfar.c | 118 ++++++++++++++++
>> +++++++++-
>> drivers/net/gianfar.h | 12 ++-
>> drivers/net/gianfar_ethtool.c | 41 +++++++++-
>> include/linux/fsl_devices.h | 1 +
>> 6 files changed, 172 insertions(+), 8 deletions(-)
>
> did this ever get ack'd by Kumar? I don't have a record of it.
>
A version of this is already in linus's tree. I just forgot to add
your Ack to it (and I apologize for that).
git commit d87eb12785c14de1586e3bad86ca2c0991300339
- k
^ permalink raw reply
* Re: Powerpc and ioremap
From: Sébastien Chrétien @ 2008-08-07 12:56 UTC (permalink / raw)
To: Juergen Beisert; +Cc: linuxppc-dev
In-Reply-To: <319b0ac50808070515o7a28cf34ue190dd3dba0ee157@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1351 bytes --]
Can we call ioremap() during udbg_early_init ?
2008/8/7, Sébastien Chrétien <sebastien.chretien.enseirb@gmail.com>:
>
> Thanks for your answer.
> But it doesn't work.
> I think ioremap create a kernel panic. But I can't see because i have no
> UART ready.
> Is there a way in order to trace the failure ?
>
> 2008/8/7, Juergen Beisert <j.beisert@pengutronix.de>:
>>
>> Am Donnerstag, 7. August 2008 11:54 schrieb Sébastien Chrétien:
>>
>> > Hello,
>> >
>> > I am trying to port linux on my Powerpc Board. I have used Linux 2.6.26
>> and
>> > gcc 3.4.5.
>> > I have used Uboot 1.2.
>> > Linux seems running from _start to udbg_early_init(). That's why I
>> > develloped a udbg_driver.
>> > It must write in a register which is located at 0x2001b044. So I wrote :
>> >
>> > void __iomem *p;
>> > p=ioremap(0x2001b044,4);
>> > iowrite32('O',p);
>> > iowrite32('K',p);
>>
>>
>> try
>>
>> p=ioremap(0x2001b000, 0x1000);
>> iowrite32('O',p + 0x44);
>> iowrite32('K',p + 0x44);
>>
>> instead.
>>
>> jbe
>>
>> --
>> Dipl.-Ing. Juergen Beisert | http://www.pengutronix.de
>> Pengutronix - Linux Solutions for Science and Industry
>> Handelsregister: Amtsgericht Hildesheim, HRA 2686
>> Hannoversche Str. 2, 31134 Hildesheim, Germany
>> Phone: +49-5121-206917-7 | Fax: +49-5121-206917-9
>>
>
>
[-- Attachment #2: Type: text/html, Size: 2358 bytes --]
^ permalink raw reply
* [PATCH] powerpc: Fix Book-E watchdog timer interval setting
From: Matthias Fuchs @ 2008-08-07 12:48 UTC (permalink / raw)
To: linuxppc-dev
This patch fixes the setting of the Book-E watchdog timer interval setup
on initialization and by ioctl().
Tested on PPC440EPx sequoia evaluation board.
Signed-off-by: Matthias Fuchs <matthias.fuchs@esd-electronics.com>
---
drivers/watchdog/booke_wdt.c | 6 +++++-
1 files changed, 5 insertions(+), 1 deletions(-)
diff --git a/drivers/watchdog/booke_wdt.c b/drivers/watchdog/booke_wdt.c
index 7708244..9db5478 100644
--- a/drivers/watchdog/booke_wdt.c
+++ b/drivers/watchdog/booke_wdt.c
@@ -42,8 +42,10 @@ u32 booke_wdt_period = WDT_PERIOD_DEFAULT;
#ifdef CONFIG_FSL_BOOKE
#define WDTP(x) ((((63-x)&0x3)<<30)|(((63-x)&0x3c)<<15))
+#define WDTP_MASK (WDTP(63))
#else
#define WDTP(x) (TCR_WP(x))
+#define WDTP_MASK (TCR_WP_MASK)
#endif
static DEFINE_SPINLOCK(booke_wdt_lock);
@@ -65,6 +67,7 @@ static void __booke_wdt_enable(void *data)
/* clear status before enabling watchdog */
__booke_wdt_ping(NULL);
val = mfspr(SPRN_TCR);
+ val &= ~WDTP_MASK;
val |= (TCR_WIE|TCR_WRC(WRC_CHIP)|WDTP(booke_wdt_period));
mtspr(SPRN_TCR, val);
@@ -106,7 +109,8 @@ static int booke_wdt_ioctl(struct inode *inode, struct file *file,
case WDIOC_SETTIMEOUT:
if (get_user(booke_wdt_period, p))
return -EFAULT;
- mtspr(SPRN_TCR, (mfspr(SPRN_TCR)&~WDTP(0))|WDTP(booke_wdt_period));
+ tmp = mfspr(SPRN_TCR) & ~WDTP_MASK;
+ mtspr(SPRN_TCR, tmp | WDTP(booke_wdt_period));
return 0;
case WDIOC_GETTIMEOUT:
return put_user(booke_wdt_period, p);
--
1.5.3
^ permalink raw reply related
* Re: Powerpc and ioremap
From: Sébastien Chrétien @ 2008-08-07 12:15 UTC (permalink / raw)
To: Juergen Beisert; +Cc: linuxppc-dev
In-Reply-To: <200808071223.11156.j.beisert@pengutronix.de>
[-- Attachment #1: Type: text/plain, Size: 1173 bytes --]
Thanks for your answer.
But it doesn't work.
I think ioremap create a kernel panic. But I can't see because i have no
UART ready.
Is there a way in order to trace the failure ?
2008/8/7, Juergen Beisert <j.beisert@pengutronix.de>:
>
> Am Donnerstag, 7. August 2008 11:54 schrieb Sébastien Chrétien:
>
> > Hello,
> >
> > I am trying to port linux on my Powerpc Board. I have used Linux 2.6.26
> and
> > gcc 3.4.5.
> > I have used Uboot 1.2.
> > Linux seems running from _start to udbg_early_init(). That's why I
> > develloped a udbg_driver.
> > It must write in a register which is located at 0x2001b044. So I wrote :
> >
> > void __iomem *p;
> > p=ioremap(0x2001b044,4);
> > iowrite32('O',p);
> > iowrite32('K',p);
>
>
> try
>
> p=ioremap(0x2001b000, 0x1000);
> iowrite32('O',p + 0x44);
> iowrite32('K',p + 0x44);
>
> instead.
>
> jbe
>
> --
> Dipl.-Ing. Juergen Beisert | http://www.pengutronix.de
> Pengutronix - Linux Solutions for Science and Industry
> Handelsregister: Amtsgericht Hildesheim, HRA 2686
> Hannoversche Str. 2, 31134 Hildesheim, Germany
> Phone: +49-5121-206917-7 | Fax: +49-5121-206917-9
>
[-- Attachment #2: Type: text/html, Size: 1695 bytes --]
^ permalink raw reply
* Re: [PATCH 2/6] powerpc: export cpm2_immr symbol for CPM2 drivers to compile as module
From: Anton Vorontsov @ 2008-08-07 11:38 UTC (permalink / raw)
To: Li Yang; +Cc: linuxppc-dev
In-Reply-To: <1218104362.29628.41.camel@Gundam>
On Thu, Aug 07, 2008 at 06:19:22PM +0800, Li Yang wrote:
> On Wed, 2008-08-06 at 19:24 +0400, Anton Vorontsov wrote:
> > On Wed, Aug 06, 2008 at 03:04:41PM +0800, Li Yang wrote:
> > > Signed-off-by: Li Yang <leoli@freescale.com>
> > > ---
> > > arch/powerpc/sysdev/cpm2.c | 1 +
> > > 1 files changed, 1 insertions(+), 0 deletions(-)
> > >
> > > diff --git a/arch/powerpc/sysdev/cpm2.c b/arch/powerpc/sysdev/cpm2.c
> > > index f1c3395..021480e 100644
> > > --- a/arch/powerpc/sysdev/cpm2.c
> > > +++ b/arch/powerpc/sysdev/cpm2.c
> > > @@ -52,6 +52,7 @@ cpm_cpm2_t __iomem *cpmp; /* Pointer to comm processor space */
> > > * the communication processor devices.
> > > */
> > > cpm2_map_t __iomem *cpm2_immr;
> > > +EXPORT_SYMBOL(cpm2_immr);
> >
> > This is uneeded if you'll start using cpm_muram_* functions
> > from include/asm-powerpc/cpm.h.
>
> Right. But there are still a few in tree drivers rely on this such as
> fs_enet.
Probably they should be fixed... Only two users left:
$ git-grep cpm2_immr drivers/
drivers/mtd/maps/wr_sbc82xx_flash.c: volatile memctl_cpm2_t *mc = &cpm2_immr->im_memctl;
drivers/mtd/maps/wr_sbc82xx_flash.c: mc = &cpm2_immr->im_memctl;
drivers/net/fs_enet/fs_enet-main.c: fs_enet_immap = cpm2_immr;
drivers/net/fs_enet/mac-fcc.c: fep->fcc.mem = (void __iomem *)cpm2_immr;
I think wr_sbc82xx_flash.c is superseded by the physmap_of driver. There
is no single CONFIG_MTD_SBC8240 enabled in the powerpc/configs.
Plus, I wonder how they didn't break the build all that time w/o
EXPORT_SYMBOL(). Probably nobody tried to build them as modules.
> Ps: In your cpm_muram_init() you re-mapped the muram space separately .
> Are we planning to get rid of cpm2_immr completely and manage memory
> mapping by each block?
At least I always thought so...
Thanks,
--
Anton Vorontsov
email: cbouatmailru@gmail.com
irc://irc.freenode.net/bd2
^ permalink raw reply
* Re: [PATCH 6/8] powerpc: set up OF properties for ppc32 kdump
From: Anton Vorontsov @ 2008-08-07 11:11 UTC (permalink / raw)
To: Michael Ellerman; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <1218106051.7914.12.camel@localhost>
On Thu, Aug 07, 2008 at 08:47:31PM +1000, Michael Ellerman wrote:
> On Fri, 2008-08-01 at 18:14 +0400, Anton Vorontsov wrote:
> > From: Dale Farnsworth <dale@farnsworth.org>
> >
> > Refactor the setting of kexec OF properties, moving the common code
> > from machine_kexec_64.c to machine_kexec.c where it can be used on
> > both ppc64 and ppc32. This will be needed for kdump to work on ppc32
> > platforms.
>
> Hi Anton,
Hi,
> > diff --git a/arch/powerpc/kernel/machine_kexec.c b/arch/powerpc/kernel/machine_kexec.c
> > index ac42cfb..bfef717 100644
> > --- a/arch/powerpc/kernel/machine_kexec.c
> > +++ b/arch/powerpc/kernel/machine_kexec.c
> > @@ -117,6 +117,7 @@ int overlaps_crashkernel(unsigned long start, unsigned long size)
> >
>
> > static int __init kexec_setup(void)
> > {
> > struct device_node *node;
> > @@ -135,6 +171,8 @@ static int __init kexec_setup(void)
> > kernel_end = __pa(_end);
> > prom_add_property(node, &kernel_end_prop);
> >
> > + export_crashk_values(node);
> > +
> > of_node_put(node);
> > return 0;
> > }
> > diff --git a/arch/powerpc/kernel/machine_kexec_64.c b/arch/powerpc/kernel/machine_kexec_64.c
> > index c30678d..2aab296 100644
> > --- a/arch/powerpc/kernel/machine_kexec_64.c
> > +++ b/arch/powerpc/kernel/machine_kexec_64.c
> ...
>
> > -
> > static int __init kexec_setup(void)
> > {
> > export_htab_values();
> > - export_crashk_values();
> > return 0;
> > }
> > __initcall(kexec_setup);
>
> This leaves us with two routines called kexec_setup(), do you mind
> getting rid of this one and making export_htab_values() an initcall
> directly.
Yup, good idea. Will do this, and will address your other comments,
too.
Thanks!
--
Anton Vorontsov
email: cbouatmailru@gmail.com
irc://irc.freenode.net/bd2
^ permalink raw reply
* Re: [PATCH] i2c-mpc: suppress I2C device probing
From: Jean Delvare @ 2008-08-07 11:07 UTC (permalink / raw)
To: Jochen Friedrich; +Cc: Linuxppc-dev
In-Reply-To: <489AD363.6070608@scram.de>
On Thu, 07 Aug 2008 12:50:11 +0200, Jochen Friedrich wrote:
> Hi Wolfgang,
>
> > $ grep I2C_CLASS_HWMON *
> > i2c-cpm.c: .class = I2C_CLASS_HWMON | I2C_CLASS_SPD,
> > i2c-mpc.c: .class = I2C_CLASS_HWMON | I2C_CLASS_SPD,
> > i2c-ibm_iic.c: adap->class = I2C_CLASS_HWMON | I2C_CLASS_SPD;
> > i2c-pasemi.c: smbus->adapter.class = I2C_CLASS_HWMON | I2C_CLASS_SPD;
> > i2c-mv64xxx.c: drv_data->adapter.class = I2C_CLASS_HWMON | I2C_CLASS_SPD;
> >
> > It would be consequent to remove them as well.
>
> ACK for the i2c-cpm part.
No objection on my side. It's really up to each platform to choose the
way they want to handle i2c device creation, and stick to it.
As I understand it, the removal of the adapter class needs to be
synchronized with platform code changes. Thus it might make sense to
push these through their respective arch trees, rather than the i2c
tree.
--
Jean Delvare
^ permalink raw reply
* Re: [PATCH] i2c-mpc: suppress I2C device probing
From: Jochen Friedrich @ 2008-08-07 10:50 UTC (permalink / raw)
To: Wolfgang Grandegger; +Cc: Jean Delvare, Linuxppc-dev
In-Reply-To: <489ACC69.5070701@grandegger.com>
Hi Wolfgang,
> $ grep I2C_CLASS_HWMON *
> i2c-cpm.c: .class = I2C_CLASS_HWMON | I2C_CLASS_SPD,
> i2c-mpc.c: .class = I2C_CLASS_HWMON | I2C_CLASS_SPD,
> i2c-ibm_iic.c: adap->class = I2C_CLASS_HWMON | I2C_CLASS_SPD;
> i2c-pasemi.c: smbus->adapter.class = I2C_CLASS_HWMON | I2C_CLASS_SPD;
> i2c-mv64xxx.c: drv_data->adapter.class = I2C_CLASS_HWMON | I2C_CLASS_SPD;
>
> It would be consequent to remove them as well.
ACK for the i2c-cpm part.
Thanks,
Jochen
^ permalink raw reply
* Re: [PATCH 6/8] powerpc: set up OF properties for ppc32 kdump
From: Michael Ellerman @ 2008-08-07 10:47 UTC (permalink / raw)
To: Anton Vorontsov; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <20080801141425.GF1161@polina.dev.rtsoft.ru>
[-- Attachment #1: Type: text/plain, Size: 1764 bytes --]
On Fri, 2008-08-01 at 18:14 +0400, Anton Vorontsov wrote:
> From: Dale Farnsworth <dale@farnsworth.org>
>
> Refactor the setting of kexec OF properties, moving the common code
> from machine_kexec_64.c to machine_kexec.c where it can be used on
> both ppc64 and ppc32. This will be needed for kdump to work on ppc32
> platforms.
Hi Anton,
> diff --git a/arch/powerpc/kernel/machine_kexec.c b/arch/powerpc/kernel/machine_kexec.c
> index ac42cfb..bfef717 100644
> --- a/arch/powerpc/kernel/machine_kexec.c
> +++ b/arch/powerpc/kernel/machine_kexec.c
> @@ -117,6 +117,7 @@ int overlaps_crashkernel(unsigned long start, unsigned long size)
>
> static int __init kexec_setup(void)
> {
> struct device_node *node;
> @@ -135,6 +171,8 @@ static int __init kexec_setup(void)
> kernel_end = __pa(_end);
> prom_add_property(node, &kernel_end_prop);
>
> + export_crashk_values(node);
> +
> of_node_put(node);
> return 0;
> }
> diff --git a/arch/powerpc/kernel/machine_kexec_64.c b/arch/powerpc/kernel/machine_kexec_64.c
> index c30678d..2aab296 100644
> --- a/arch/powerpc/kernel/machine_kexec_64.c
> +++ b/arch/powerpc/kernel/machine_kexec_64.c
...
> -
> static int __init kexec_setup(void)
> {
> export_htab_values();
> - export_crashk_values();
> return 0;
> }
> __initcall(kexec_setup);
This leaves us with two routines called kexec_setup(), do you mind
getting rid of this one and making export_htab_values() an initcall
directly.
cheers
--
Michael Ellerman
OzLabs, IBM Australia Development Lab
wwweb: http://michael.ellerman.id.au
phone: +61 2 6212 1183 (tie line 70 21183)
We do not inherit the earth from our ancestors,
we borrow it from our children. - S.M.A.R.T Person
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH 1/8] powerpc: set up OF properties for ppc32 kexec
From: Michael Ellerman @ 2008-08-07 10:44 UTC (permalink / raw)
To: Anton Vorontsov; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <20080801141414.GA1161@polina.dev.rtsoft.ru>
[-- Attachment #1: Type: text/plain, Size: 1234 bytes --]
On Fri, 2008-08-01 at 18:14 +0400, Anton Vorontsov wrote:
> From: Dale Farnsworth <dale@farnsworth.org>
>
> Refactor the setting of kexec OF properties, moving the common code
> from machine_kexec_64.c to machine_kexec.c where it can be used on
> both ppc64 and ppc32. This is needed for kexec to work on ppc32
> platforms.
Hi Anton,
> diff --git a/arch/powerpc/kernel/machine_kexec.c b/arch/powerpc/kernel/machine_kexec.c
> index aab7688..a625673 100644
> --- a/arch/powerpc/kernel/machine_kexec.c
> +++ b/arch/powerpc/kernel/machine_kexec.c
...
> +
> +static int __init kexec_setup(void)
> +{
> + struct device_node *node;
> +
> + node = of_find_node_by_path("/chosen");
> + if (!node)
> + return -ENOENT;
> +
> + kernel_end = __pa(_end);
> + prom_add_property(node, &kernel_end_prop);
> +
> + of_node_put(node);
> + return 0;
> +}
> +__initcall(kexec_setup);
__initcall() is supposedly deprecated, use device_initcall() instead.
cheers
--
Michael Ellerman
OzLabs, IBM Australia Development Lab
wwweb: http://michael.ellerman.id.au
phone: +61 2 6212 1183 (tie line 70 21183)
We do not inherit the earth from our ancestors,
we borrow it from our children. - S.M.A.R.T Person
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH 7/8] powerpc: implement crash_setup_regs for ppc32
From: Michael Ellerman @ 2008-08-07 10:32 UTC (permalink / raw)
To: Anton Vorontsov; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <20080801141427.GG1161@polina.dev.rtsoft.ru>
[-- Attachment #1: Type: text/plain, Size: 1372 bytes --]
On Fri, 2008-08-01 at 18:14 +0400, Anton Vorontsov wrote:
> From: Dale Farnsworth <dale@farnsworth.org>
>
> Signed-off-by: Dale Farnsworth <dale@farnsworth.org>
> Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
> @@ -51,6 +50,7 @@ static inline void crash_setup_regs(struct pt_regs *newregs,
> else {
> /* FIXME Merge this with xmon_save_regs ?? */
> unsigned long tmp1, tmp2;
> +#ifdef __powerpc64__
> __asm__ __volatile__ (
> "std 0,0(%2)\n"
> "std 1,8(%2)\n"
> @@ -99,16 +99,58 @@ static inline void crash_setup_regs(struct pt_regs *newregs,
> : "=&r" (tmp1), "=&r" (tmp2)
> : "b" (newregs)
> : "memory");
> +#else /* __powerpc64__ */
> + __asm__ __volatile__ (
> + "stw 0,0(%2)\n"
> + "stw 1,4(%2)\n"
> + "stw 2,8(%2)\n"
> + "stw 3,12(%2)\n"
> + "stw 4,16(%2)\n"
> + "stw 5,20(%2)\n"
> + "stw 6,24(%2)\n"
> + "stw 7,28(%2)\n"
> + "stw 8,32(%2)\n"
..
Hi Anton,
You should be able to avoid any use of #ifdefs in this routine. Look at
SAVE_GPR() and friends in asm/ppc_asm.h.
cheers
--
Michael Ellerman
OzLabs, IBM Australia Development Lab
wwweb: http://michael.ellerman.id.au
phone: +61 2 6212 1183 (tie line 70 21183)
We do not inherit the earth from our ancestors,
we borrow it from our children. - S.M.A.R.T Person
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: Powerpc and ioremap
From: Juergen Beisert @ 2008-08-07 10:23 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Sébastien Chrétien
In-Reply-To: <319b0ac50808070254x27606b48sb15fb4ee6105c6c6@mail.gmail.com>
Am Donnerstag, 7. August 2008 11:54 schrieb S=E9bastien Chr=E9tien:
> Hello,
>
> I am trying to port linux on my Powerpc Board. I have used Linux 2.6.26 a=
nd
> gcc 3.4.5.
> I have used Uboot 1.2.
> Linux seems running from _start to udbg_early_init(). That's why I
> develloped a udbg_driver.
> It must write in a register which is located at 0x2001b044. So I wrote :
>
> void __iomem *p;
> p=3Dioremap(0x2001b044,4);
> iowrite32('O',p);
> iowrite32('K',p);
try
p=3Dioremap(0x2001b000, 0x1000);
iowrite32('O',p + 0x44);
iowrite32('K',p + 0x44);
instead.
jbe
=2D-=20
Dipl.-Ing. Juergen Beisert | http://www.pengutronix.de
Pengutronix - Linux Solutions for Science and Industry
Handelsregister: Amtsgericht Hildesheim, HRA 2686
Hannoversche Str. 2, 31134 Hildesheim, Germany
Phone: +49-5121-206917-7 | Fax: +49-5121-206917-9
^ permalink raw reply
* Re: [PATCH] i2c-mpc: suppress I2C device probing
From: Wolfgang Grandegger @ 2008-08-07 10:20 UTC (permalink / raw)
To: Jean Delvare; +Cc: Linuxppc-dev
In-Reply-To: <20080807102126.5980c761@hyperion.delvare>
Jean Delvare wrote:
> Hi Grant, Wolgang,
>
> On Thu, 17 Jul 2008 12:02:50 -0600, Grant Likely wrote:
>> On Thu, Jul 17, 2008 at 4:37 AM, Wolfgang Grandegger <wg@grandegger.com> wrote:
>>> This patch suppresses I2C device probing by clearing the class field
>>> of the "struct i2c_adapter" for the MPC I2C bus adapters. Some board
>>> configurations which rely on probing must be fixed up by adding a
>>> proper I2C device node to the DTS file, like the TQM85xx modules.
>>>
>>> Signed-off-by: Wolfgang Grandegger <wg@grandegger.com>
>> Acked-by: Grant Likely <grant.likely@secretlab.ca>
>>
>>> ---
>>> drivers/i2c/busses/i2c-mpc.c | 1 -
>>> 1 file changed, 1 deletion(-)
>>>
>>> Index: powerpc/drivers/i2c/busses/i2c-mpc.c
>>> ===================================================================
>>> --- powerpc.orig/drivers/i2c/busses/i2c-mpc.c
>>> +++ powerpc/drivers/i2c/busses/i2c-mpc.c
>>> @@ -312,7 +312,6 @@ static struct i2c_adapter mpc_ops = {
>>> .name = "MPC adapter",
>>> .id = I2C_HW_MPC107,
>>> .algo = &mpc_algo,
>>> - .class = I2C_CLASS_HWMON | I2C_CLASS_SPD,
>>> .timeout = 1,
>>> };
>
> Unless you intend to push this patch upstream yourself (through the ppc
> tree), you should send it to Ben Dooks (who is in charge of this part
> of the i2c subsystem) with Cc to the i2c list.
I just want to mention, that other I2 bus drivers set I2C_CLASS_HWMON as well.
Here are the PowerPC related ones:
$ grep I2C_CLASS_HWMON *
i2c-cpm.c: .class = I2C_CLASS_HWMON | I2C_CLASS_SPD,
i2c-mpc.c: .class = I2C_CLASS_HWMON | I2C_CLASS_SPD,
i2c-ibm_iic.c: adap->class = I2C_CLASS_HWMON | I2C_CLASS_SPD;
i2c-pasemi.c: smbus->adapter.class = I2C_CLASS_HWMON | I2C_CLASS_SPD;
i2c-mv64xxx.c: drv_data->adapter.class = I2C_CLASS_HWMON | I2C_CLASS_SPD;
It would be consequent to remove them as well.
Wolfgang.
^ 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