* [PATCH 4/7] [POWERPC] Xilinx: update compatible list for interrupt controller
From: Stephen Neuendorffer @ 2007-12-13 23:43 UTC (permalink / raw)
To: grant.likely, simekm2, jwilliams, linuxppc-dev
In-Reply-To: <1197589413-5965-3-git-send-email-stephen.neuendorffer@xilinx.com>
These values now match what is generated by the uboot BSP generator.
Signed-off-by: Stephen Neuendorffer <stephen.neuendorffer@xilinx.com>
---
arch/powerpc/sysdev/xilinx_intc.c | 8 +++++++-
1 files changed, 7 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/sysdev/xilinx_intc.c b/arch/powerpc/sysdev/xilinx_intc.c
index c2f17cc..10345dd 100644
--- a/arch/powerpc/sysdev/xilinx_intc.c
+++ b/arch/powerpc/sysdev/xilinx_intc.c
@@ -135,10 +135,16 @@ void __init xilinx_intc_init_tree(void)
struct device_node *np;
/* find top level interrupt controller */
- for_each_compatible_node(np, NULL, "xilinx,intc") {
+ for_each_compatible_node(np, NULL, "xlnx,opb-intc-1.00.c") {
if (!of_get_property(np, "interrupts", NULL))
break;
}
+ if(!np) {
+ for_each_compatible_node(np, NULL, "xlnx,xps-intc-1.00.a") {
+ if (!of_get_property(np, "interrupts", NULL))
+ break;
+ }
+ }
/* xilinx interrupt controller needs to be top level */
BUG_ON(!np);
--
1.5.3.4
^ permalink raw reply related
* [PATCH 5/7] [POWERPC] Xilinx: Update compatible to use values generated by BSP generator.
From: Stephen Neuendorffer @ 2007-12-13 23:43 UTC (permalink / raw)
To: grant.likely, simekm2, jwilliams, linuxppc-dev
In-Reply-To: <1197589413-5965-4-git-send-email-stephen.neuendorffer@xilinx.com>
Mainly, this involves two changes:
1) xilinx->xlnx (recognized standard is to use the stock ticker)
2) In order to have the device tree focus on describing what the hardware is as exactly as possible, the compatible strings contain the full IP name and IP version.
Signed-off-by: Stephen Neuendorffer <stephen.neuendorffer@xilinx.com>
---
arch/powerpc/platforms/40x/virtex.c | 2 +-
drivers/block/xsysace.c | 4 ++-
drivers/serial/uartlite.c | 42 +++++++++++++++++++++-------------
drivers/video/xilinxfb.c | 2 +-
4 files changed, 31 insertions(+), 19 deletions(-)
diff --git a/arch/powerpc/platforms/40x/virtex.c b/arch/powerpc/platforms/40x/virtex.c
index 14bbc32..859ba1d 100644
--- a/arch/powerpc/platforms/40x/virtex.c
+++ b/arch/powerpc/platforms/40x/virtex.c
@@ -30,7 +30,7 @@ static int __init virtex_probe(void)
{
unsigned long root = of_get_flat_dt_root();
- if (!of_flat_dt_is_compatible(root, "xilinx,virtex"))
+ if (!of_flat_dt_is_compatible(root, "xlnx,virtex"))
return 0;
return 1;
diff --git a/drivers/block/xsysace.c b/drivers/block/xsysace.c
index 82effce..45bc51b 100644
--- a/drivers/block/xsysace.c
+++ b/drivers/block/xsysace.c
@@ -1208,7 +1208,9 @@ static int __devexit ace_of_remove(struct of_device *op)
/* Match table for of_platform binding */
static struct of_device_id __devinit ace_of_match[] = {
- { .compatible = "xilinx,xsysace", },
+ { .compatible = "xlnx,opb-sysace-1.00.b", },
+ { .compatible = "xlnx,opb-sysace-1.00.c", },
+ { .compatible = "xlnx,xps-sysace-1.00.a", },
{},
};
MODULE_DEVICE_TABLE(of, ace_of_match);
diff --git a/drivers/serial/uartlite.c b/drivers/serial/uartlite.c
index 5ec42f3..6536cc7 100644
--- a/drivers/serial/uartlite.c
+++ b/drivers/serial/uartlite.c
@@ -21,8 +21,18 @@
#include <linux/interrupt.h>
#include <asm/io.h>
#if defined(CONFIG_OF)
+#include <linux/of.h>
#include <linux/of_device.h>
#include <linux/of_platform.h>
+
+/* Match table for of_platform binding */
+static struct of_device_id __devinit ulite_of_match[] = {
+ { .type = "serial", .compatible = "xlnx,opb-uartlite-1.00.b", },
+ { .type = "serial", .compatible = "xlnx,xps-uartlite-1.00.a", },
+ {},
+};
+MODULE_DEVICE_TABLE(of, ulite_of_match);
+
#endif
#define ULITE_NAME "ttyUL"
@@ -427,18 +437,25 @@ static inline u32 __init ulite_console_of_find_device(int id)
struct resource res;
const unsigned int *of_id;
int rc;
+ const struct of_device_id *matches = ulite_of_match;
+
+ while (matches->compatible[0]) {
+ for_each_compatible_node(np, NULL, matches->compatible) {
+ if (!of_match_node(matches, np))
+ continue;
- for_each_compatible_node(np, NULL, "xilinx,uartlite") {
- of_id = of_get_property(np, "port-number", NULL);
- if ((!of_id) || (*of_id != id))
- continue;
+ of_id = of_get_property(np, "port-number", NULL);
+ if ((!of_id) || (*of_id != id))
+ continue;
- rc = of_address_to_resource(np, 0, &res);
- if (rc)
- continue;
+ rc = of_address_to_resource(np, 0, &res);
+ if (rc)
+ continue;
- of_node_put(np);
- return res.start+3;
+ of_node_put(np);
+ return res.start+3;
+ }
+ matches++;
}
return 0;
@@ -654,13 +671,6 @@ static int __devexit ulite_of_remove(struct of_device *op)
return ulite_release(&op->dev);
}
-/* Match table for of_platform binding */
-static struct of_device_id __devinit ulite_of_match[] = {
- { .type = "serial", .compatible = "xilinx,uartlite", },
- {},
-};
-MODULE_DEVICE_TABLE(of, ulite_of_match);
-
static struct of_platform_driver ulite_of_driver = {
.owner = THIS_MODULE,
.name = "uartlite",
diff --git a/drivers/video/xilinxfb.c b/drivers/video/xilinxfb.c
index e38d3b7..9b426d3 100644
--- a/drivers/video/xilinxfb.c
+++ b/drivers/video/xilinxfb.c
@@ -460,7 +460,7 @@ static int __devexit xilinxfb_of_remove(struct of_device *op)
/* Match table for of_platform binding */
static struct of_device_id __devinit xilinxfb_of_match[] = {
- { .compatible = "xilinx,ml300-fb", },
+ { .compatible = "xlnx,plb-tft-cntlr-ref-1.00.a", },
{},
};
MODULE_DEVICE_TABLE(of, xilinxfb_of_match);
--
1.5.3.4
^ permalink raw reply related
* [PATCH 7/7] [POWERPC] Xilinx: Update booting-without-of.
From: Stephen Neuendorffer @ 2007-12-13 23:43 UTC (permalink / raw)
To: grant.likely, simekm2, jwilliams, linuxppc-dev
In-Reply-To: <1197589413-5965-6-git-send-email-stephen.neuendorffer@xilinx.com>
This now better describes what the UBoot device tree generator actually does. In particular:
1) Nodes have a label derived from the device name, and a node name
derived from the device type.
2) Usage of compound nodes (representing more than one device in the same IP) which actually works. This requires having a valid compatible node, and all the other things that a bus normally has. I've chosen 'xlnx,compound' as the bus name to describe these compound nodes.
3) Uartlite requires a port-number property for the console to work.
In addition, I've clarified some of the language relating to how mhs
nodes should be represent in the device tree.
---
Documentation/powerpc/booting-without-of.txt | 61 +++++++++++++++-----------
1 files changed, 36 insertions(+), 25 deletions(-)
diff --git a/Documentation/powerpc/booting-without-of.txt b/Documentation/powerpc/booting-without-of.txt
index e9a3cb1..5e2b85a 100644
--- a/Documentation/powerpc/booting-without-of.txt
+++ b/Documentation/powerpc/booting-without-of.txt
@@ -2276,7 +2276,7 @@ platforms are moved over to use the flattened-device-tree model.
properties of the device node. In general, device nodes for IP-cores
will take the following form:
- (name)@(base-address) {
+ (name): (ip-core-name)@(base-address) {
compatible = "xlnx,(ip-core-name)-(HW_VER)"
[, (list of compatible devices), ...];
reg = <(baseaddr) (size)>;
@@ -2294,9 +2294,9 @@ platforms are moved over to use the flattened-device-tree model.
dropped from the parameter name, the name is converted
to lowercase and all underscore '_' characters are
converted to dashes '-'.
- (baseaddr): the C_BASEADDR parameter.
+ (baseaddr): the baseaddr parameter value (often named C_BASEADDR).
(HW_VER): from the HW_VER parameter.
- (size): equals C_HIGHADDR - C_BASEADDR + 1
+ (size): the address range size (often C_HIGHADDR - C_BASEADDR + 1).
Typically, the compatible list will include the exact IP core version
followed by an older IP core version which implements the same
@@ -2326,12 +2326,13 @@ platforms are moved over to use the flattened-device-tree model.
becomes the following device tree node:
- opb-uartlite-0@ec100000 {
+ opb_uartlite_0: serial@ec100000 {
device_type = "serial";
compatible = "xlnx,opb-uartlite-1.00.b";
reg = <ec100000 10000>;
- interrupt-parent = <&opb-intc>;
+ interrupt-parent = <&opb_intc_0>;
interrupts = <1 0>; // got this from the opb_intc parameters
+ port-number = <0>;
current-speed = <d#115200>; // standard serial device prop
clock-frequency = <d#50000000>; // standard serial device prop
xlnx,data-bits = <8>;
@@ -2339,16 +2340,19 @@ platforms are moved over to use the flattened-device-tree model.
xlnx,use-parity = <0>;
};
- Some IP cores actually implement 2 or more logical devices. In this case,
- the device should still describe the whole IP core with a single node
- and add a child node for each logical device. The ranges property can
- be used to translate from parent IP-core to the registers of each device.
- (Note: this makes the assumption that both logical devices have the same
- bus binding. If this is not true, then separate nodes should be used for
- each logical device). The 'cell-index' property can be used to enumerate
- logical devices within an IP core. For example, the following is the
- system.mhs entry for the dual ps2 controller found on the ml403 reference
- design.
+ Some IP cores actually implement 2 or more logical devices. In
+ this case, the device should still describe the whole IP core with
+ a single node and add a child node for each logical device. The
+ ranges property can be used to translate from parent IP-core to the
+ registers of each device. In addition, the parent node should be
+ compatible with the bus type 'xlnx,compound', and should contain
+ #address-cells and #size-cells, as with any other bus. (Note: this
+ makes the assumption that both logical devices have the same bus
+ binding. If this is not true, then separate nodes should be used
+ for each logical device). The 'cell-index' property can be used to
+ enumerate logical devices within an IP core. For example, the
+ following is the system.mhs entry for the dual ps2 controller found
+ on the ml403 reference design.
BEGIN opb_ps2_dual_ref
PARAMETER INSTANCE = opb_ps2_dual_ref_0
@@ -2370,21 +2374,24 @@ platforms are moved over to use the flattened-device-tree model.
It would result in the following device tree nodes:
- opb_ps2_dual_ref_0@a9000000 {
+ opb_ps2_dual_ref_0: opb-ps2-dual-ref@a9000000 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "xlnx,compound";
ranges = <0 a9000000 2000>;
// If this device had extra parameters, then they would
// go here.
- ps2@0 {
+ opb-ps2-dual-ref@0 {
compatible = "xlnx,opb-ps2-dual-ref-1.00.a";
reg = <0 40>;
- interrupt-parent = <&opb-intc>;
+ interrupt-parent = <&opb_intc_0>;
interrupts = <3 0>;
cell-index = <0>;
};
- ps2@1000 {
+ opb-ps2-dual-ref@1000 {
compatible = "xlnx,opb-ps2-dual-ref-1.00.a";
reg = <1000 40>;
- interrupt-parent = <&opb-intc>;
+ interrupt-parent = <&opb_intc_0>;
interrupts = <3 0>;
cell-index = <0>;
};
@@ -2447,17 +2454,18 @@ platforms are moved over to use the flattened-device-tree model.
Gives this device tree (some properties removed for clarity):
- plb-v34-0 {
+ plb_v34 {
#address-cells = <1>;
#size-cells = <1>;
+ compatible = "xlnx,plb-v34-1.02.a";
device_type = "ibm,plb";
ranges; // 1:1 translation
- plb-bram-if-cntrl-0@ffff0000 {
+ plb_bram_if_cntrl_0: plb-bram-if-cntrl@ffff0000 {
reg = <ffff0000 10000>;
}
- opb-v20-0 {
+ opb_v20 {
#address-cells = <1>;
#size-cells = <1>;
ranges = <20000000 20000000 20000000
@@ -2465,11 +2473,11 @@ platforms are moved over to use the flattened-device-tree model.
80000000 80000000 40000000
c0000000 c0000000 20000000>;
- opb-uart16550-0@a0000000 {
+ opb_uart16550_0: opb-uart16550@a0000000 {
reg = <a00000000 2000>;
};
- opb-intc-0@d1000fc0 {
+ opb_intc_0: opb-intc@d1000fc0 {
reg = <d1000fc0 20>;
};
};
@@ -2513,6 +2521,9 @@ platforms are moved over to use the flattened-device-tree model.
Requred properties:
- current-speed : Baud rate of uartlite
+ Optional properties:
+ - port-number : unique ordinal index of the device. This
+ property is required for a console on uartlite.
More devices will be defined as this spec matures.
--
1.5.3.4
^ permalink raw reply related
* Re: apm_emulation regression
From: Benjamin Herrenschmidt @ 2007-12-14 0:05 UTC (permalink / raw)
To: Rafael J. Wysocki; +Cc: linuxppc-dev list, Johannes Berg, linux-pm, ralf
In-Reply-To: <1197590675.15741.195.camel@pasglop>
On Fri, 2007-12-14 at 11:04 +1100, Benjamin Herrenschmidt wrote:
> On Fri, 2007-12-14 at 01:10 +0100, Rafael J. Wysocki wrote:
> >
> > Hmm.
> >
> > I'm not that familiar with the APM emulation code, but the description
> > of the
> > problem above suggests that the APM emulation can install a suspend
> > notifier for this purpose.
>
> It can use the new notifier that happens before freezing yes. Johannes,
> I think that's pretty much what my old powermac implementation did
> (using my private notifier scheme I had there), might be worth reviving
> that bit and sticking it into the generic apm_emu ...
Note that you may want to improve on it with a timeout in case userspace
doesn't ack...
Ben.
^ permalink raw reply
* Re: apm_emulation regression
From: Benjamin Herrenschmidt @ 2007-12-14 0:04 UTC (permalink / raw)
To: Rafael J. Wysocki; +Cc: linuxppc-dev list, Johannes Berg, linux-pm, ralf
In-Reply-To: <200712140110.44406.rjw@sisk.pl>
On Fri, 2007-12-14 at 01:10 +0100, Rafael J. Wysocki wrote:
>
> Hmm.
>
> I'm not that familiar with the APM emulation code, but the description
> of the
> problem above suggests that the APM emulation can install a suspend
> notifier for this purpose.
It can use the new notifier that happens before freezing yes. Johannes,
I think that's pretty much what my old powermac implementation did
(using my private notifier scheme I had there), might be worth reviving
that bit and sticking it into the generic apm_emu ...
Ben.
^ permalink raw reply
* Re: [PATCH 2/7] [POWERPC] Xilinx: clear data caches.
From: Benjamin Herrenschmidt @ 2007-12-14 0:07 UTC (permalink / raw)
To: Stephen Neuendorffer; +Cc: linuxppc-dev, simekm2
In-Reply-To: <20071213234240.F3CC3AD805D@mail122-sin.bigfish.com>
On Thu, 2007-12-13 at 15:43 -0800, Stephen Neuendorffer wrote:
> This code is needed to boot without a boot loader.
>
> Grant: I'm not sure where the right place to put this is. I'm assuming we'll actually need some boot code that is not generic? Also, note that there is a V4FX errata workaround in arch/ppc/boot/head.S, which probably also needs to get pulled to powerpc.
>
> Signed-off-by: Stephen Neuendorffer <stephen.neuendorffer@xilinx.com>
> ---
> arch/powerpc/boot/raw-platform.c | 22 ++++++++++++++++++++++
> 1 files changed, 22 insertions(+), 0 deletions(-)
This raw-platform.c file doesn't seem like a good place for code that is
totally platform specific ...
Ben.
> diff --git a/arch/powerpc/boot/raw-platform.c b/arch/powerpc/boot/raw-platform.c
> index b9caeee..2a5e493 100644
> --- a/arch/powerpc/boot/raw-platform.c
> +++ b/arch/powerpc/boot/raw-platform.c
> @@ -24,6 +24,28 @@ void platform_init(unsigned long r3, unsigned long r4, unsigned long r5,
> unsigned long r6, unsigned long r7)
> {
> u64 memsize64 = memsize[0];
> + static const unsigned long line_size = 32;
> + static const unsigned long congruence_classes = 256;
> + unsigned long addr;
> + unsigned long dccr;
> +
> + /*
> + * Invalidate the data cache if the data cache is turned off.
> + * - The 405 core does not invalidate the data cache on power-up
> + * or reset but does turn off the data cache. We cannot assume
> + * that the cache contents are valid.
> + * - If the data cache is turned on this must have been done by
> + * a bootloader and we assume that the cache contents are
> + * valid.
> + */
> + __asm__("mfdccr %0": "=r" (dccr));
> + if (dccr == 0) {
> + for (addr = 0;
> + addr < (congruence_classes * line_size);
> + addr += line_size) {
> + __asm__("dccci 0,%0": :"b"(addr));
> + }
> + }
>
> if (mem_size_cells == 2) {
> memsize64 <<= 32;
^ permalink raw reply
* Re: apm_emulation regression
From: Rafael J. Wysocki @ 2007-12-14 0:10 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-pm, ralf, linuxppc-dev list
In-Reply-To: <1197482587.6558.145.camel@johannes.berg>
On Wednesday, 12 of December 2007, Johannes Berg wrote:
>
> On Wed, 2007-12-12 at 13:45 +1100, Benjamin Herrenschmidt wrote:
> > I only just noticed a huge regression that was introduced when we moved
> > PowerPC to the generic APM emulation code instead of our own. I'm in
> > large part to blame since I acked the patch...
> >
> > Basically, what we lost is the mechanism for notifying user applications
> > and waiting for their ACK before proceeding to system suspend. The new
> > generic code will still do that ... only when the actual suspend request
> > initiates from an APM suspend ioctl.
>
> Indeed.
>
> > For any other suspend (via our private PMU ioctl or via the sysfs
> > interface), userspace will -not- be notified.
>
> Right.
>
> > That basically means X will break. That's why X broke on the latest
> > ubuntu until I whacked some new scripts in them to force console
> > switching, among other things. Possibly other apps that relied
> > on /dev/apm_bios to be notified of system suspend/resume broke as well.
>
> Ah. I guess I never noticed because I had the scripts to do console
> switching all along.
>
> > Now the question is that is it still work trying to fix it ? That would
> > probably require APM emulation hooking at a fairly high level into the
> > generic PM code to trigger the signaling & waiting of processes before
> > freeze & device suspend among others...
>
> Yeah, bit icky... but doable. Rafael, any ideas?
Hmm.
I'm not that familiar with the APM emulation code, but the description of the
problem above suggests that the APM emulation can install a suspend
notifier for this purpose.
Greetings,
Rafael
^ permalink raw reply
* Re: [PATCH 2/7] [POWERPC] Xilinx: clear data caches.
From: Benjamin Herrenschmidt @ 2007-12-14 0:09 UTC (permalink / raw)
To: Stephen Neuendorffer; +Cc: linuxppc-dev, simekm2
In-Reply-To: <1197590848.15741.199.camel@pasglop>
On Fri, 2007-12-14 at 11:07 +1100, Benjamin Herrenschmidt wrote:
> On Thu, 2007-12-13 at 15:43 -0800, Stephen Neuendorffer wrote:
> > This code is needed to boot without a boot loader.
> >
> > Grant: I'm not sure where the right place to put this is. I'm assuming we'll actually need some boot code that is not generic? Also, note that there is a V4FX errata workaround in arch/ppc/boot/head.S, which probably also needs to get pulled to powerpc.
> >
> > Signed-off-by: Stephen Neuendorffer <stephen.neuendorffer@xilinx.com>
> > ---
> > arch/powerpc/boot/raw-platform.c | 22 ++++++++++++++++++++++
> > 1 files changed, 22 insertions(+), 0 deletions(-)
>
> This raw-platform.c file doesn't seem like a good place for code that is
> totally platform specific ...
Maybe best is to do that in asm ? The problem when you are in C code is
that you may already have hit stale cache entries. "raw" platforms
probably need to perform various CPU-specific initializations anyway,
prior to entering C code, in a custom crt0.S, so that's probably the
best place to do the cache clearing.
Ben.
^ permalink raw reply
* How is a device tree used to specifiy flash?
From: Bruce_Leonard @ 2007-12-13 23:28 UTC (permalink / raw)
To: linuxppc-embedded
Okay I just don't get it, but that's not a surprise. I'm booting a 2.6.23
kernel on an MPC8347 using u-boot 1.3.0. I'm trying to use the device
tree to spec my single Spansion/AMD NOR flash part and I can't get the
kernel to recognize the part. Or maybe I just don't know how to tell if
the kernel is recognizing the part. It's possible that everything is fine
and I'm just to dumb to know it.
So I've got a Spansion S29GL128N flash part and the following entry in my
device tree:
flash@ff000000 {
compatible = "amd,s29g128n", "cfi-flash";
reg = <ff000000 01000000>;
bank-width = <2>;
device-width = <1>;
#address-cells = <1>;
#size-cells = <1>;
bit@200000 {
label = "bit";
reg = <200000 a0000>;
};
kernel@400000 {
label = "kernel";
reg = <400000 140000>;
};
blob@600000 {
label = "blob";
reg = <600000 20000>;
};
uboot@f00000 {
label = "uboot";
reg = <f00000 60000>;
read-only;
};
};
I've got the following in my .config for the kernel (I think this is all
that's relavent but I'm not sure);
#
# Device Drivers
#
#
# Generic Driver Options
#
CONFIG_STANDALONE=y
CONFIG_PREVENT_FIRMWARE_BUILD=y
# CONFIG_FW_LOADER is not set
# CONFIG_DEBUG_DRIVER is not set
# CONFIG_DEBUG_DEVRES is not set
# CONFIG_SYS_HYPERVISOR is not set
# CONFIG_CONNECTOR is not set
CONFIG_MTD=y
CONFIG_MTD_DEBUG=y
CONFIG_MTD_DEBUG_VERBOSE=3
# CONFIG_MTD_CONCAT is not set
CONFIG_MTD_PARTITIONS=y
# CONFIG_MTD_REDBOOT_PARTS is not set
CONFIG_MTD_CMDLINE_PARTS=y
#
# User Modules And Translation Layers
#
CONFIG_MTD_CHAR=y
# CONFIG_MTD_BLKDEVS is not set
# CONFIG_MTD_BLOCK is not set
# CONFIG_MTD_BLOCK_RO is not set
# CONFIG_FTL is not set
# CONFIG_NFTL is not set
# CONFIG_INFTL is not set
# CONFIG_RFD_FTL is not set
# CONFIG_SSFDC is not set
#
# RAM/ROM/Flash chip drivers
#
CONFIG_MTD_CFI=y
# CONFIG_MTD_JEDECPROBE is not set
CONFIG_MTD_GEN_PROBE=y
# CONFIG_MTD_CFI_ADV_OPTIONS is not set
CONFIG_MTD_MAP_BANK_WIDTH_1=y
CONFIG_MTD_MAP_BANK_WIDTH_2=y
CONFIG_MTD_MAP_BANK_WIDTH_4=y
# CONFIG_MTD_MAP_BANK_WIDTH_8 is not set
# CONFIG_MTD_MAP_BANK_WIDTH_16 is not set
# CONFIG_MTD_MAP_BANK_WIDTH_32 is not set
CONFIG_MTD_CFI_I1=y
CONFIG_MTD_CFI_I2=y
# CONFIG_MTD_CFI_I4 is not set
# CONFIG_MTD_CFI_I8 is not set
# CONFIG_MTD_CFI_INTELEXT is not set
CONFIG_MTD_CFI_AMDSTD=y
# CONFIG_MTD_CFI_STAA is not set
CONFIG_MTD_CFI_UTIL=y
# CONFIG_MTD_RAM is not set
# CONFIG_MTD_ROM is not set
# CONFIG_MTD_ABSENT is not set
#
# Mapping drivers for chip access
#
# CONFIG_MTD_COMPLEX_MAPPINGS is not set
# CONFIG_MTD_PHYSMAP is not set
CONFIG_MTD_PHYSMAP_OF=y
# CONFIG_MTD_PLATRAM is not set
#
# Self-contained MTD device drivers
#
# CONFIG_MTD_PMC551 is not set
# CONFIG_MTD_SLRAM is not set
# CONFIG_MTD_PHRAM is not set
# CONFIG_MTD_MTDRAM is not set
# CONFIG_MTD_BLOCK2MTD is not set
#
# Disk-On-Chip Device Drivers
#
# CONFIG_MTD_DOC2000 is not set
# CONFIG_MTD_DOC2001 is not set
# CONFIG_MTD_DOC2001PLUS is not set
# CONFIG_MTD_NAND is not set
# CONFIG_MTD_ONENAND is not set
#
# UBI - Unsorted block images
#
# CONFIG_MTD_UBI is not set
CONFIG_OF_DEVICE=y
# CONFIG_PARPORT is not set
CONFIG_BLK_DEV=y
# CONFIG_BLK_DEV_FD is not set
# CONFIG_BLK_CPQ_DA is not set
# CONFIG_BLK_CPQ_CISS_DA is not set
# CONFIG_BLK_DEV_DAC960 is not set
# CONFIG_BLK_DEV_UMEM is not set
# CONFIG_BLK_DEV_COW_COMMON is not set
# CONFIG_BLK_DEV_LOOP is not set
CONFIG_BLK_DEV_NBD=y
# CONFIG_BLK_DEV_SX8 is not set
# CONFIG_BLK_DEV_UB is not set
# CONFIG_BLK_DEV_RAM is not set
# CONFIG_CDROM_PKTCDVD is not set
# CONFIG_ATA_OVER_ETH is not set
# CONFIG_MISC_DEVICES is not set
# CONFIG_IDE is not set
With this device tree and this .config the kernel never probes the flash
part and 'cat /dev/mtd1' says the device doesn't exist. If I then use
Kconfig to specify the start of flash, the size of flash, and the bank
width, dmesg shows that the part has been probed and 'cat /dev/mtd' spews
out all sorts of stuff.
What black magic is there that doesn't showup in booting-without-of.txt
that I'm missing?
Thanks for any feedback.
Bruce
^ permalink raw reply
* RE: [PATCH 2/7] [POWERPC] Xilinx: clear data caches.
From: Stephen Neuendorffer @ 2007-12-14 0:36 UTC (permalink / raw)
To: benh; +Cc: linuxppc-dev, simekm2
In-Reply-To: <1197590981.15741.201.camel@pasglop>
Unfortunately, I think your right... The asm code seems so clean at the
moment, I don't really want be the one to start tarnishing it with a
bunch of little fixups.. :)
Steve
> -----Original Message-----
> From: Benjamin Herrenschmidt [mailto:benh@kernel.crashing.org]=20
> Sent: Thursday, December 13, 2007 4:10 PM
> To: Stephen Neuendorffer
> Cc: grant.likely@secretlab.ca; simekm2@fel.cvut.cz;=20
> jwilliams@itee.uq.edu.au; linuxppc-dev@ozlabs.org
> Subject: Re: [PATCH 2/7] [POWERPC] Xilinx: clear data caches.
>=20
>=20
> On Fri, 2007-12-14 at 11:07 +1100, Benjamin Herrenschmidt wrote:
> > On Thu, 2007-12-13 at 15:43 -0800, Stephen Neuendorffer wrote:
> > > This code is needed to boot without a boot loader.
> > >=20
> > > Grant: I'm not sure where the right place to put this=20
> is. I'm assuming we'll actually need some boot code that is=20
> not generic? Also, note that there is a V4FX errata=20
> workaround in arch/ppc/boot/head.S, which probably also needs=20
> to get pulled to powerpc.
> > >=20
> > > Signed-off-by: Stephen Neuendorffer=20
> <stephen.neuendorffer@xilinx.com>
> > > ---
> > > arch/powerpc/boot/raw-platform.c | 22 ++++++++++++++++++++++
> > > 1 files changed, 22 insertions(+), 0 deletions(-)
> >=20
> > This raw-platform.c file doesn't seem like a good place for=20
> code that is
> > totally platform specific ...
>=20
> Maybe best is to do that in asm ? The problem when you are in=20
> C code is
> that you may already have hit stale cache entries. "raw" platforms
> probably need to perform various CPU-specific initializations anyway,
> prior to entering C code, in a custom crt0.S, so that's probably the
> best place to do the cache clearing.
>=20
> Ben.
>=20
>=20
>=20
^ permalink raw reply
* Re: How is a device tree used to specifiy flash?
From: Josh Boyer @ 2007-12-14 1:57 UTC (permalink / raw)
To: Bruce_Leonard; +Cc: linuxppc-embedded
In-Reply-To: <OFE841AC61.3D44C925-ON882573B0.007FA29F-882573B0.0080F67D@selinc.com>
On Thu, 13 Dec 2007 15:28:37 -0800
Bruce_Leonard@selinc.com wrote:
> Okay I just don't get it, but that's not a surprise. I'm booting a 2.6.23
> kernel on an MPC8347 using u-boot 1.3.0. I'm trying to use the device
> tree to spec my single Spansion/AMD NOR flash part and I can't get the
> kernel to recognize the part. Or maybe I just don't know how to tell if
> the kernel is recognizing the part. It's possible that everything is fine
> and I'm just to dumb to know it.
>
> So I've got a Spansion S29GL128N flash part and the following entry in my
> device tree:
>
> flash@ff000000 {
What bus is this node under in your DTS file? Make sure that bus is
getting probed in the platform code.
josh
^ permalink raw reply
* Re: How is a device tree used to specifiy flash?
From: Bruce_Leonard @ 2007-12-14 2:27 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-embedded
In-Reply-To: <20071213195759.0de2a917@vader.jdub.homelinux.org>
> >
> > flash@ff000000 {
>
> What bus is this node under in your DTS file? Make sure that bus is
> getting probed in the platform code.
>
Well, I was starting to wonder about that. This node isn't under any bus
in the DTS file. It's at the same level as the CPU node. Does it need to
be under a localbus node like the pq2fads.dts? I've attached the entire
DTS this time which may help.
Bruce
/ {
model = "MPC8349EMITX";
compatible = "MPC8349EMITX", "MPC834xMITX", "MPC83xxMITX";
#address-cells = <1>;
#size-cells = <1>;
cpus {
#cpus = <1>;
#address-cells = <1>;
#size-cells = <0>;
PowerPC,8349@0 {
device_type = "cpu";
reg = <0>;
d-cache-line-size = <20>;
i-cache-line-size = <20>;
d-cache-size = <8000>;
i-cache-size = <8000>;
timebase-frequency = <0>; // from bootloader
bus-frequency = <0>; // from bootloader
clock-frequency = <0>; // from bootloader
32-bit;
};
};
memory {
device_type = "memory";
reg = <00000000 20000000>;
};
flash@ff000000 {
compatible = "amd,s29g128n", "cfi-flash";
reg = <ff000000 01000000>;
bank-width = <2>;
device-width = <1>;
#address-cells = <1>;
#size-cells = <1>;
bit@200000 {
label = "bit";
reg = <200000 a0000>;
};
kernel@400000 {
label = "kernel";
reg = <400000 140000>;
};
blob@600000 {
label = "blob";
reg = <600000 20000>;
};
uboot@f00000 {
label = "uboot";
reg = <f00000 60000>;
read-only;
};
};
soc8349@e0000000 {
#address-cells = <1>;
#size-cells = <1>;
#interrupt-cells = <2>;
device_type = "soc";
ranges = <0 e0000000 00100000>;
reg = <e0000000 00000200>;
bus-frequency = <0>; // from bootloader
wdt@200 {
device_type = "watchdog";
compatible = "mpc83xx_wdt";
reg = <200 100>;
};
i2c@3000 {
device_type = "i2c";
compatible = "fsl-i2c";
reg = <3000 100>;
interrupts = <e 8>;
interrupt-parent = < &ipic >;
dfsrr;
rtc@68 {
#address-cells = <1>;
#size-cells = <0>;
device_type = "rtc";
compatible = "stm,m41t00";
reg = <68 8>;
};
};
i2c@3100 {
device_type = "i2c";
compatible = "fsl-i2c";
reg = <3100 100>;
interrupts = <f 8>;
interrupt-parent = < &ipic >;
dfsrr;
};
spi@7000 {
device_type = "spi";
compatible = "mpc83xx_spi";
reg = <7000 1000>;
interrupts = <10 8>;
interrupt-parent = < &ipic >;
mode = <0>;
};
usb@22000 {
device_type = "usb";
compatible = "fsl-usb2-mph";
reg = <22000 1000>;
#address-cells = <1>;
#size-cells = <0>;
interrupt-parent = < &ipic >;
interrupts = <27 8>;
phy_type = "ulpi";
// port1;
port0;
};
// usb@23000 {
// device_type = "usb";
// compatible = "fsl-usb2-dr";
// reg = <23000 1000>;
// #address-cells = <1>;
// #size-cells = <0>;
// interrupt-parent = < &ipic >;
// interrupts = <26 8>;
// phy_type = "ulpi";
// };
mdio@24520 {
device_type = "mdio";
compatible = "gianfar";
reg = <24520 20>;
#address-cells = <1>;
#size-cells = <0>;
/* Vitesse 8201 */
phy0: ethernet-phy@1c {
interrupt-parent = < &ipic >;
interrupts = <12 8>;
reg = <0>;
device_type = "ethernet-phy";
};
/* Vitesse 7385 */
phy1: ethernet-phy@1f {
interrupt-parent = < &ipic >;
interrupts = <12 8>;
reg = <1>;
device_type = "ethernet-phy";
};
};
ethernet@24000 {
device_type = "network";
model = "TSEC";
compatible = "gianfar";
reg = <24000 1000>;
address = [ 00 00 00 00 00 00 ];
local-mac-address = [ 00 00 00 00 00 00 ];
interrupts = <20 8 21 8 22 8>;
interrupt-parent = < &ipic >;
phy-handle = < &phy0 >;
};
ethernet@25000 {
#address-cells = <1>;
#size-cells = <0>;
device_type = "network";
model = "TSEC";
compatible = "gianfar";
reg = <25000 1000>;
address = [ 00 00 00 00 00 00 ];
local-mac-address = [ 00 00 00 00 00 00 ];
interrupts = <23 8 24 8 25 8>;
interrupt-parent = < &ipic >;
phy-handle = < &phy1 >;
};
serial@4500 {
device_type = "serial";
compatible = "ns16550";
reg = <4500 100>;
clock-frequency = <0>; // from bootloader
interrupts = <9 8>;
interrupt-parent = < &ipic >;
};
serial@4600 {
device_type = "serial";
compatible = "ns16550";
reg = <4600 100>;
clock-frequency = <0>; // from bootloader
interrupts = <a 8>;
interrupt-parent = < &ipic >;
};
pci@8500 {
interrupt-map-mask = <f800 0 0 7>;
interrupt-map = <
// IDSEL 0x12 - FPGA
9000 0 0 1 &ipic 15 8 // INTA -
UARTS
9000 0 0 2 &ipic 16 8 // INTB -
IRIG
// IDSEL 0x13 - PCI Enet
9800 0 0 1 &ipic 14 8 // INTA
// IDSEL 0x14 - PCI104 Slot 1
a000 0 0 1 &ipic 12 8 // INTA
a000 0 0 2 &ipic 13 8 // INTB
a000 0 0 3 &ipic 15 8 // INTC
a000 0 0 4 &ipic 16 8 // INTD
// IDSEL 0x15 - PCI104 Slot 2
a800 0 0 1 &ipic 13 8 // INTA
a800 0 0 2 &ipic 15 8 // INTB
a800 0 0 3 &ipic 16 8 // INTC
a800 0 0 4 &ipic 12 8 // INTD
// IDSEL 0x16 - PCI104 Slot 3
b000 0 0 1 &ipic 15 8 // INTA
b000 0 0 2 &ipic 16 8 // INTB
b000 0 0 3 &ipic 12 8 // INTC
b000 0 0 4 &ipic 13 8 // INTD
>;
interrupt-parent = < &ipic >;
interrupts = <42 8>;
bus-range = <0 0>;
ranges = <42000000 0 80000000 80000000 0 10000000
02000000 0 90000000 90000000 0 08000000
01000000 0 98000000 98000000 0
08000000>;
clock-frequency = <1f78a40>;
#interrupt-cells = <1>;
#size-cells = <2>;
#address-cells = <3>;
reg = <8500 100>;
compatible = "83xx";
device_type = "pci";
};
crypto@30000 {
device_type = "crypto";
model = "SEC2";
compatible = "talitos";
reg = <30000 10000>;
interrupts = <b 8>;
interrupt-parent = < &ipic >;
num-channels = <4>;
channel-fifo-len = <18>;
exec-units-mask = <0000007e>;
descriptor-types-mask = <01010ebf>;
};
ipic: pic@700 {
interrupt-controller;
#address-cells = <0>;
#interrupt-cells = <2>;
reg = <700 100>;
built-in;
device_type = "ipic";
};
};
};
^ permalink raw reply
* Re: How is a device tree used to specifiy flash?
From: Jon Smirl @ 2007-12-14 2:28 UTC (permalink / raw)
To: Bruce_Leonard@selinc.com; +Cc: linuxppc-embedded
In-Reply-To: <OFE841AC61.3D44C925-ON882573B0.007FA29F-882573B0.0080F67D@selinc.com>
To get this working on the mpc5200 I had to add the localbus node
above the flash.
lpb@ff000000 {
compatible = "fsl,lpb";
ranges = <0 ff000000 01000000>;
flash@00000000 {
compatible = "cfi-flash";
reg = <00000000 01000000>;
bank-width = <2>;
#size-cells = <1>;
#address-cells = <1>;
partition@0 {
label = "ubootl";
reg = <00000000 00040000>;
};
partition@40000 {
label = "kernel";
reg = <00040000 001c0000>;
};
partition@200000 {
label = "jffs2";
reg = <00200000 00D00000>;
};
partition@f00000 {
label = "uboot";
reg = <00f00000 00040000>;
};
partition@f40000 {
label = "oftree";
reg = <00f40000 00040000>;
};
partition@f80000 {
label = "space";
reg = <00f80000 00080000>;
};
};
};
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: How is a device tree used to specifiy flash?
From: Bruce_Leonard @ 2007-12-14 2:48 UTC (permalink / raw)
To: Jon Smirl; +Cc: linuxppc-embedded
In-Reply-To: <9e4733910712131828v532e6aaep316c72e14d92c921@mail.gmail.com>
"Jon Smirl" <jonsmirl@gmail.com> wrote on 12/13/2007 06:28:28 PM:
> To get this working on the mpc5200 I had to add the localbus node
> above the flash.
>
> lpb@ff000000 {
> compatible = "fsl,lpb";
> ranges = <0 ff000000 01000000>;
>
Thanks. I'll give it a try. Do you know if the "fsl,lpb" compaibility
extends to the 83xx code?
Bruce
^ permalink raw reply
* Re: [PATCH] ipic: ack only for edge interrupts
From: Kumar Gala @ 2007-12-14 4:29 UTC (permalink / raw)
To: Li Yang; +Cc: linuxppc-dev
In-Reply-To: <1196766100-7411-1-git-send-email-leoli@freescale.com>
On Dec 4, 2007, at 5:01 AM, Li Yang wrote:
> Only external interrupts in edge detect mode support ack operation.
> Therefore, in most cases ack is not needed. The patch makes ipic
> ack only when it's needed. This could boost over all system
> performance.
>
> Signed-off-by: Li Yang <leoli@freescale.com>
> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> ---
> Update to use different irq_chip for level and edge interrupts as Ben
> suggested.
> Supercedes [PATCH] ipic: change ack operation that register is
> accessed
> only when needed
>
> arch/powerpc/sysdev/ipic.c | 113 ++++++++++++++++
> +---------------------------
> arch/powerpc/sysdev/ipic.h | 6 +--
> 2 files changed, 45 insertions(+), 74 deletions(-)
applied.
- k
^ permalink raw reply
* [PATCH 0/6] xics.c and time.c optimizations
From: Milton Miller @ 2007-12-14 4:51 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
The following patches against for-2.2.25 do some optimizations related
to the usage smp_processor_id().
The xics one has been tested on SMP on 2.6.23, and still applies cleanly.
In time.c I started with the per_cpu to __get_cpu_var transformations
which affect ppc64 (the calls were added in 2.6.24), and from there
went looking for redundant global accesses from objdump -d --reloc.
I primarly looked at the pseries_defconfig and checked the results on
chrp32_defconfig.
Optimization results were checked on debian using
gcc version 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)
milton
^ permalink raw reply
* [PATCH 1/6] push down or eliminate smp_processor_id in xics
From: Milton Miller @ 2007-12-14 4:52 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
In-Reply-To: <mm-cpu-0@bga.com>
Delay callling smp_processor_id until its needed.
The per-processor interrupt request register and current processor
priority register are only accessed on the current cpu. In fact the
hypervisor doesn't even let us choose this.
The only function to use cpu twice is xics_migrate_irqs_away, not a fast
path. But we can cache the result of get_hard_processor_id() instead of
calling get_hard_smp_processor_id(cpu) in a loop across the call to rtas.
Years ago the irq code passed smp_processor_id into get_irq, I thought
we might initialize the CPPR third party at boot as an extra measure of
saftey, and it made the code symetric with the qirr (queued interrupt for
software generated interrupts), but now it is just extra and sometimes
unneeded work to pass it down.
Signed-off-by: Milton Miller <miltonm@bga.com>
---
Index: kernel/arch/powerpc/platforms/pseries/xics.c
===================================================================
--- kernel.orig/arch/powerpc/platforms/pseries/xics.c 2007-10-10 03:44:55.000000000 -0500
+++ kernel/arch/powerpc/platforms/pseries/xics.c 2007-10-10 04:28:58.000000000 -0500
@@ -87,19 +87,25 @@ static int ibm_int_off;
/* Direct HW low level accessors */
-static inline unsigned int direct_xirr_info_get(int n_cpu)
+static inline unsigned int direct_xirr_info_get(void)
{
- return in_be32(&xics_per_cpu[n_cpu]->xirr.word);
+ int cpu = smp_processor_id();
+
+ return in_be32(&xics_per_cpu[cpu]->xirr.word);
}
-static inline void direct_xirr_info_set(int n_cpu, int value)
+static inline void direct_xirr_info_set(int value)
{
- out_be32(&xics_per_cpu[n_cpu]->xirr.word, value);
+ int cpu = smp_processor_id();
+
+ out_be32(&xics_per_cpu[cpu]->xirr.word, value);
}
-static inline void direct_cppr_info(int n_cpu, u8 value)
+static inline void direct_cppr_info(u8 value)
{
- out_8(&xics_per_cpu[n_cpu]->xirr.bytes[0], value);
+ int cpu = smp_processor_id();
+
+ out_8(&xics_per_cpu[cpu]->xirr.bytes[0], value);
}
static inline void direct_qirr_info(int n_cpu, u8 value)
@@ -111,7 +117,7 @@ static inline void direct_qirr_info(int
/* LPAR low level accessors */
-static inline unsigned int lpar_xirr_info_get(int n_cpu)
+static inline unsigned int lpar_xirr_info_get(void)
{
unsigned long lpar_rc;
unsigned long return_value;
@@ -122,7 +128,7 @@ static inline unsigned int lpar_xirr_inf
return (unsigned int)return_value;
}
-static inline void lpar_xirr_info_set(int n_cpu, int value)
+static inline void lpar_xirr_info_set(int value)
{
unsigned long lpar_rc;
unsigned long val64 = value & 0xffffffff;
@@ -133,7 +139,7 @@ static inline void lpar_xirr_info_set(in
val64);
}
-static inline void lpar_cppr_info(int n_cpu, u8 value)
+static inline void lpar_cppr_info(u8 value)
{
unsigned long lpar_rc;
@@ -275,21 +281,19 @@ static unsigned int xics_startup(unsigne
static void xics_eoi_direct(unsigned int virq)
{
- int cpu = smp_processor_id();
unsigned int irq = (unsigned int)irq_map[virq].hwirq;
iosync();
- direct_xirr_info_set(cpu, (0xff << 24) | irq);
+ direct_xirr_info_set((0xff << 24) | irq);
}
static void xics_eoi_lpar(unsigned int virq)
{
- int cpu = smp_processor_id();
unsigned int irq = (unsigned int)irq_map[virq].hwirq;
iosync();
- lpar_xirr_info_set(cpu, (0xff << 24) | irq);
+ lpar_xirr_info_set((0xff << 24) | irq);
}
static inline unsigned int xics_remap_irq(unsigned int vec)
@@ -312,16 +316,12 @@ static inline unsigned int xics_remap_ir
static unsigned int xics_get_irq_direct(void)
{
- unsigned int cpu = smp_processor_id();
-
- return xics_remap_irq(direct_xirr_info_get(cpu));
+ return xics_remap_irq(direct_xirr_info_get());
}
static unsigned int xics_get_irq_lpar(void)
{
- unsigned int cpu = smp_processor_id();
-
- return xics_remap_irq(lpar_xirr_info_get(cpu));
+ return xics_remap_irq(lpar_xirr_info_get());
}
#ifdef CONFIG_SMP
@@ -387,12 +387,12 @@ void xics_cause_IPI(int cpu)
#endif /* CONFIG_SMP */
-static void xics_set_cpu_priority(int cpu, unsigned char cppr)
+static void xics_set_cpu_priority(unsigned char cppr)
{
if (firmware_has_feature(FW_FEATURE_LPAR))
- lpar_cppr_info(cpu, cppr);
+ lpar_cppr_info(cppr);
else
- direct_cppr_info(cpu, cppr);
+ direct_cppr_info(cppr);
iosync();
}
@@ -440,9 +440,7 @@ static void xics_set_affinity(unsigned i
void xics_setup_cpu(void)
{
- int cpu = smp_processor_id();
-
- xics_set_cpu_priority(cpu, 0xff);
+ xics_set_cpu_priority(0xff);
/*
* Put the calling processor into the GIQ. This is really only
@@ -783,7 +781,7 @@ void xics_teardown_cpu(int secondary)
unsigned int ipi;
struct irq_desc *desc;
- xics_set_cpu_priority(cpu, 0);
+ xics_set_cpu_priority(0);
/*
* Clear IPI
@@ -824,10 +822,11 @@ void xics_teardown_cpu(int secondary)
void xics_migrate_irqs_away(void)
{
int status;
- unsigned int irq, virq, cpu = smp_processor_id();
+ int cpu = smp_processor_id(), hw_cpu = hard_smp_processor_id();
+ unsigned int irq, virq;
/* Reject any interrupt that was queued to us... */
- xics_set_cpu_priority(cpu, 0);
+ xics_set_cpu_priority(0);
/* remove ourselves from the global interrupt queue */
status = rtas_set_indicator_fast(GLOBAL_INTERRUPT_QUEUE,
@@ -835,7 +834,7 @@ void xics_migrate_irqs_away(void)
WARN_ON(status < 0);
/* Allow IPIs again... */
- xics_set_cpu_priority(cpu, DEFAULT_PRIORITY);
+ xics_set_cpu_priority(DEFAULT_PRIORITY);
for_each_irq(virq) {
struct irq_desc *desc;
@@ -874,7 +873,7 @@ void xics_migrate_irqs_away(void)
* The irq has to be migrated only in the single cpu
* case.
*/
- if (xics_status[0] != get_hard_smp_processor_id(cpu))
+ if (xics_status[0] != hw_cpu)
goto unlock;
printk(KERN_WARNING "IRQ %u affinity broken off cpu %u\n",
Index: kernel/arch/powerpc/platforms/pseries/xics.h
===================================================================
--- kernel.orig/arch/powerpc/platforms/pseries/xics.h 2007-10-10 03:46:30.000000000 -0500
+++ kernel/arch/powerpc/platforms/pseries/xics.h 2007-10-10 03:48:57.000000000 -0500
@@ -21,9 +21,6 @@ extern void xics_cause_IPI(int cpu);
extern void xics_request_IPIs(void);
extern void xics_migrate_irqs_away(void);
-/* first argument is ignored for now*/
-void pSeriesLP_cppr_info(int n_cpu, u8 value);
-
struct xics_ipi_struct {
volatile unsigned long value;
} ____cacheline_aligned;
^ permalink raw reply
* [PATCH 2/6] init_decrementer_clockevent can be static __init
From: Milton Miller @ 2007-12-14 4:52 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
In-Reply-To: <mm-cpu-0@bga.com>
as its only called from time_init, which is __init.
Also remove unneeded forward declaration.
Signed-off-by: Milton Miller <miltonm@bga.com>
---
Index: kernel/arch/powerpc/kernel/time.c
===================================================================
--- kernel.orig/arch/powerpc/kernel/time.c 2007-12-13 17:46:59.000000000 -0600
+++ kernel/arch/powerpc/kernel/time.c 2007-12-13 17:56:37.000000000 -0600
@@ -117,7 +117,6 @@ static struct clock_event_device decreme
};
static DEFINE_PER_CPU(struct clock_event_device, decrementers);
-void init_decrementer_clockevent(void);
static DEFINE_PER_CPU(u64, decrementer_next_tb);
#ifdef CONFIG_PPC_ISERIES
@@ -836,7 +835,7 @@ static void register_decrementer_clockev
clockevents_register_device(dec);
}
-void init_decrementer_clockevent(void)
+static void __init init_decrementer_clockevent(void)
{
int cpu = smp_processor_id();
^ permalink raw reply
* any more patches for 2.6.24?
From: Paul Mackerras @ 2007-12-14 4:52 UTC (permalink / raw)
To: linuxppc-dev
Currently I have just this one bugfix queued up to go to Linus for
2.6.24:
Stephen Rothwell (1):
[POWERPC] iSeries: don't printk with HV spinlock held
Does anyone else have bugfixes that need to go in 2.6.24?
Paul.
^ permalink raw reply
* [PATCH 3/6] use __get_cpu_var in time.c
From: Milton Miller @ 2007-12-14 4:52 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
In-Reply-To: <mm-cpu-0@bga.com>
use __get_cpu_var(x) instead of per_cpu(x, smp_processor_id()), as it
is optimied on ppc64 to access the current cpus per-cpu offset directly.
Its local_paca.offset instead of TOC->paca[local_paca->processor_id].offset.
This is the trivial portion, two functions with one use each.
Signed-off-by: Milton Miller <miltonm@bga.com>
---
Index: kernel/arch/powerpc/kernel/time.c
===================================================================
--- kernel.orig/arch/powerpc/kernel/time.c 2007-12-13 20:37:03.000000000 -0600
+++ kernel/arch/powerpc/kernel/time.c 2007-12-13 20:37:03.000000000 -0600
@@ -327,7 +327,7 @@ void calculate_steal_time(void)
if (!cpu_has_feature(CPU_FTR_PURR))
return;
- pme = &per_cpu(cpu_purr_data, smp_processor_id());
+ pme = &__get_cpu_var(cpu_purr_data);
if (!pme->initialized)
return; /* this can happen in early boot */
tb = mftb();
@@ -352,7 +352,7 @@ static void snapshot_purr(void)
if (!cpu_has_feature(CPU_FTR_PURR))
return;
local_irq_save(flags);
- pme = &per_cpu(cpu_purr_data, smp_processor_id());
+ pme = &__get_cpu_var(cpu_purr_data);
pme->tb = mftb();
pme->purr = mfspr(SPRN_PURR);
pme->initialized = 1;
^ permalink raw reply
* [PATCH 4/6] timer interrupt: use a struct for two per_cpu varables
From: Milton Miller @ 2007-12-14 4:52 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
In-Reply-To: <mm-cpu-0@bga.com>
timer_interrupt was calculating per_cpu_offset several times, having to
start from the toc because of potential aliasing issues.
Placing both decrementer per_cpu varables in a struct and calculating
the address once with __get_cpu_var results in better code on both 32
and 64 bit.
Signed-off-by: Milton Miller <miltonm@bga.com>
---
Index: kernel/arch/powerpc/kernel/time.c
===================================================================
--- kernel.orig/arch/powerpc/kernel/time.c 2007-12-13 17:56:37.000000000 -0600
+++ kernel/arch/powerpc/kernel/time.c 2007-12-13 18:07:13.000000000 -0600
@@ -116,8 +116,12 @@ static struct clock_event_device decreme
.features = CLOCK_EVT_FEAT_ONESHOT,
};
-static DEFINE_PER_CPU(struct clock_event_device, decrementers);
-static DEFINE_PER_CPU(u64, decrementer_next_tb);
+struct decrementer_clock {
+ struct clock_event_device event;
+ u64 next_tb;
+};
+
+static DEFINE_PER_CPU(struct decrementer_clock, decrementers);
#ifdef CONFIG_PPC_ISERIES
static unsigned long __initdata iSeries_recal_titan;
@@ -555,8 +559,8 @@ void __init iSeries_time_init_early(void
void timer_interrupt(struct pt_regs * regs)
{
struct pt_regs *old_regs;
- int cpu = smp_processor_id();
- struct clock_event_device *evt = &per_cpu(decrementers, cpu);
+ struct decrementer_clock *decrementer = &__get_cpu_var(decrementers);
+ struct clock_event_device *evt = &decrementer->event;
u64 now;
/* Ensure a positive value is written to the decrementer, or else
@@ -569,9 +573,9 @@ void timer_interrupt(struct pt_regs * re
#endif
now = get_tb_or_rtc();
- if (now < per_cpu(decrementer_next_tb, cpu)) {
+ if (now < decrementer->next_tb) {
/* not time for this event yet */
- now = per_cpu(decrementer_next_tb, cpu) - now;
+ now = decrementer->next_tb - now;
if (now <= DECREMENTER_MAX)
set_dec((int)now);
return;
@@ -810,7 +814,7 @@ void __init clocksource_init(void)
static int decrementer_set_next_event(unsigned long evt,
struct clock_event_device *dev)
{
- __get_cpu_var(decrementer_next_tb) = get_tb_or_rtc() + evt;
+ __get_cpu_var(decrementers).next_tb = get_tb_or_rtc() + evt;
set_dec(evt);
return 0;
}
@@ -824,7 +828,7 @@ static void decrementer_set_mode(enum cl
static void register_decrementer_clockevent(int cpu)
{
- struct clock_event_device *dec = &per_cpu(decrementers, cpu);
+ struct clock_event_device *dec = &per_cpu(decrementers, cpu).event;
*dec = decrementer_clockevent;
dec->cpumask = cpumask_of_cpu(cpu);
^ permalink raw reply
* [PATCH 5/6] depend on ->initialized in calc_steal_time
From: Milton Miller @ 2007-12-14 4:52 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
In-Reply-To: <mm-cpu-0@bga.com>
If CPU_FTR_PURR is not set, we will never set cpu_purr_data->initialized.
Checking via __get_cpu_var on 64 bit avoids one dependent load compared
to cpu_has_feature in the not present case, and is always required when
it is present. The code is under CONFIG_VIRT_CPU_ACCOUNTING so 32 bit
will not be affected.
Signed-off-by: Milton Miller <miltonm@bga.com>
---
Index: kernel/arch/powerpc/kernel/time.c
===================================================================
--- kernel.orig/arch/powerpc/kernel/time.c 2007-12-13 18:16:10.000000000 -0600
+++ kernel/arch/powerpc/kernel/time.c 2007-12-13 18:23:55.000000000 -0600
@@ -329,11 +329,9 @@ void calculate_steal_time(void)
s64 stolen;
struct cpu_purr_data *pme;
- if (!cpu_has_feature(CPU_FTR_PURR))
- return;
pme = &__get_cpu_var(cpu_purr_data);
if (!pme->initialized)
- return; /* this can happen in early boot */
+ return; /* !CPU_FTR_PURR or early in early boot */
tb = mftb();
purr = mfspr(SPRN_PURR);
stolen = (tb - pme->tb) - (purr - pme->purr);
^ permalink raw reply
* [PATCH 6/6] optimize account_system_vtime
From: Milton Miller @ 2007-12-14 4:52 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
In-Reply-To: <mm-cpu-0@bga.com>
We have multiple calls to has_feature being inlined, but gcc can't
be sure that the store via get_paca() doesn't alias the path to
cur_cpu_spec->feature.
Reorder to put the calls to read_purr and read_spurr adjacent to each
other. To add a sense of consistency, reorder the remaining lines to
perform parallel steps on purr and scaled purr of each line instead of
calculating and then using one value before going on to the next.
In addition, we can tell gcc that no SPURR means no PURR. The test is
completely hidden in the PURR case, and in the !PURR case the second test
is eliminated resulting in the simple register copy in the out-of-line
branch.
Further, gcc sees get_paca()->system_time referenced several times and
allocates a register to address it (shadowing r13) instead of caching its
value. Reading into a local varable saves the shadow of r13 and removes
a potentially duplicate load (between the nested if and its parent).
Signed-off-by: Milton Miller <miltonm@bga.com>
---
The purr and spurr fields of the paca are only used in this c code,
but system_time and user_time are also used in asm and I decided to
leave all of these fields in the paca.
Index: kernel/arch/powerpc/kernel/time.c
===================================================================
--- kernel.orig/arch/powerpc/kernel/time.c 2007-12-13 21:58:10.000000000 -0600
+++ kernel/arch/powerpc/kernel/time.c 2007-12-13 22:00:36.000000000 -0600
@@ -219,7 +219,11 @@ static u64 read_purr(void)
*/
static u64 read_spurr(u64 purr)
{
- if (cpu_has_feature(CPU_FTR_SPURR))
+ /*
+ * cpus without PURR won't have a SPURR
+ * We already know the former when we use this, so tell gcc
+ */
+ if (cpu_has_feature(CPU_FTR_PURR) && cpu_has_feature(CPU_FTR_SPURR))
return mfspr(SPRN_SPURR);
return purr;
}
@@ -230,29 +234,30 @@ static u64 read_spurr(u64 purr)
*/
void account_system_vtime(struct task_struct *tsk)
{
- u64 now, nowscaled, delta, deltascaled;
+ u64 now, nowscaled, delta, deltascaled, sys_time;
unsigned long flags;
local_irq_save(flags);
now = read_purr();
- delta = now - get_paca()->startpurr;
- get_paca()->startpurr = now;
nowscaled = read_spurr(now);
+ delta = now - get_paca()->startpurr;
deltascaled = nowscaled - get_paca()->startspurr;
+ get_paca()->startpurr = now;
get_paca()->startspurr = nowscaled;
if (!in_interrupt()) {
/* deltascaled includes both user and system time.
* Hence scale it based on the purr ratio to estimate
* the system time */
+ sys_time = get_paca()->system_time;
if (get_paca()->user_time)
- deltascaled = deltascaled * get_paca()->system_time /
- (get_paca()->system_time + get_paca()->user_time);
- delta += get_paca()->system_time;
+ deltascaled = deltascaled * sys_time /
+ (sys_time + get_paca()->user_time);
+ delta += sys_time;
get_paca()->system_time = 0;
}
account_system_time(tsk, 0, delta);
- get_paca()->purrdelta = delta;
account_system_time_scaled(tsk, deltascaled);
+ get_paca()->purrdelta = delta;
get_paca()->spurrdelta = deltascaled;
local_irq_restore(flags);
}
^ permalink raw reply
* Re: [PATCH] mpc834x_mds: Fix whitespace and call of_platform_bus_probe().
From: Kumar Gala @ 2007-12-14 4:54 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev
In-Reply-To: <20071213171905.GA4630@loki.buserror.net>
On Dec 13, 2007, at 11:19 AM, Scott Wood wrote:
> Signed-off-by: Scott Wood <scottwood@freescale.com>
> ---
> arch/powerpc/platforms/83xx/mpc834x_mds.c | 21 +++++++++++++++++++--
> 1 files changed, 19 insertions(+), 2 deletions(-)
applied.
- k
^ permalink raw reply
* [PATCH 0/15] [POWERPC] PCI updates & merges
From: Benjamin Herrenschmidt @ 2007-12-14 4:56 UTC (permalink / raw)
To: linuxppc-dev
(THIS SERIES STILL NEEDS MORE TESTING)
(This version is rebased on top of current for-2.6.25, my remaining
4xx patches will apply on top of this)
This serie of patches converts the 32 bits PCI code to use the generic
pci_assign_unassigned_resources() instead of its own assignment code
which was unable to deal with unassigned PCI<->PCI bridges among
other issues.
It then merges the resource fixup and allocation code between 32 and
64 bits (mostly making 64 bits use the 32 bits code with a few fixups),
hopefully fixing the longstanding issue that not setting pci_probe_only
on ppc64 would generally not work.
We also add flags to control the behaviour of the PCI code, such as
letting some platforms force a full re-assignment (similar to what
pci-auto used to provide in arch/ppc) and remove a whole bunch of
hackish code that is made obsolete by that change.
32 bits platforms with 64 bits resources support will also need my
separate patch to fix the generic setup-bus.c for that situation.
Finally, I also merge the implementations of pcibios_enable_device()
and fixup the PowerMac code that used hooks in that area in ways
that don't work anymore.
^ 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