[PATCH 1/2] powerpc: Remove ibm,smt-snooze-delay OF property
I'm not sure why we have code for parsing an ibm,smt-snooze-delay OF
property. Since we have a smt-snooze-delay= boot option and we can
also set it at runtime via sysfs, it should be safe to get rid of
this code.
Signed-off-by: Anton Blanchard an...@samba.org
---
Index: powerpc.git/arch/powerpc/kernel/sysfs.c
===
--- powerpc.git.orig/arch/powerpc/kernel/sysfs.c2010-05-17
15:05:29.917208655 +1000
+++ powerpc.git/arch/powerpc/kernel/sysfs.c 2010-05-17 15:18:24.164704601
+1000
@@ -67,33 +67,6 @@ static ssize_t show_smt_snooze_delay(str
static SYSDEV_ATTR(smt_snooze_delay, 0644, show_smt_snooze_delay,
store_smt_snooze_delay);
-/* Only parse OF options if the matching cmdline option was not specified */
-static int smt_snooze_cmdline;
-
-static int __init smt_setup(void)
-{
- struct device_node *options;
- const unsigned int *val;
- unsigned int cpu;
-
- if (!cpu_has_feature(CPU_FTR_SMT))
- return -ENODEV;
-
- options = of_find_node_by_path(/options);
- if (!options)
- return -ENODEV;
-
- val = of_get_property(options, ibm,smt-snooze-delay, NULL);
- if (!smt_snooze_cmdline val) {
- for_each_possible_cpu(cpu)
- per_cpu(smt_snooze_delay, cpu) = *val;
- }
-
- of_node_put(options);
- return 0;
-}
-__initcall(smt_setup);
-
static int __init setup_smt_snooze_delay(char *str)
{
unsigned int cpu;
@@ -102,8 +75,6 @@ static int __init setup_smt_snooze_delay
if (!cpu_has_feature(CPU_FTR_SMT))
return 1;
- smt_snooze_cmdline = 1;
-
if (get_option(str, snooze)) {
for_each_possible_cpu(cpu)
per_cpu(smt_snooze_delay, cpu) = snooze;
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 2/2] powerpc: Use smt_snooze_delay=-1 to always busy loop
Right now if we want to busy loop and not give up any time to the hypervisor
we put a very large value into smt_snooze_delay. This is sometimes useful
when running a single partition and you want to avoid any latencies due
to the hypervisor or CPU power state transitions. While this works, it's a bit
ugly - how big a number is enough now we have NO_HZ and can be idle for a very
long time.
The patch below makes smt_snooze_delay signed, and a negative value means loop
forever:
echo -1 /sys/devices/system/cpu/cpu0/smt_snooze_delay
This change shouldn't affect the existing userspace tools (eg ppc64_cpu), but
I'm cc-ing Nathan just to be sure.
Signed-off-by: Anton Blanchard an...@samba.org
---
Index: powerpc.git/arch/powerpc/kernel/sysfs.c
===
--- powerpc.git.orig/arch/powerpc/kernel/sysfs.c2010-05-17
15:18:24.164704601 +1000
+++ powerpc.git/arch/powerpc/kernel/sysfs.c 2010-05-17 15:18:26.207205125
+1000
@@ -35,7 +35,7 @@ static DEFINE_PER_CPU(struct cpu, cpu_de
#ifdef CONFIG_PPC64
/* Time in microseconds we delay before sleeping in the idle loop */
-DEFINE_PER_CPU(unsigned long, smt_snooze_delay) = { 100 };
+DEFINE_PER_CPU(long, smt_snooze_delay) = { 100 };
static ssize_t store_smt_snooze_delay(struct sys_device *dev,
struct sysdev_attribute *attr,
@@ -44,9 +44,9 @@ static ssize_t store_smt_snooze_delay(st
{
struct cpu *cpu = container_of(dev, struct cpu, sysdev);
ssize_t ret;
- unsigned long snooze;
+ long snooze;
- ret = sscanf(buf, %lu, snooze);
+ ret = sscanf(buf, %ld, snooze);
if (ret != 1)
return -EINVAL;
@@ -61,7 +61,7 @@ static ssize_t show_smt_snooze_delay(str
{
struct cpu *cpu = container_of(dev, struct cpu, sysdev);
- return sprintf(buf, %lu\n, per_cpu(smt_snooze_delay, cpu-sysdev.id));
+ return sprintf(buf, %ld\n, per_cpu(smt_snooze_delay, cpu-sysdev.id));
}
static SYSDEV_ATTR(smt_snooze_delay, 0644, show_smt_snooze_delay,
@@ -70,15 +70,14 @@ static SYSDEV_ATTR(smt_snooze_delay, 064
static int __init setup_smt_snooze_delay(char *str)
{
unsigned int cpu;
- int snooze;
+ long snooze;
if (!cpu_has_feature(CPU_FTR_SMT))
return 1;
- if (get_option(str, snooze)) {
- for_each_possible_cpu(cpu)
- per_cpu(smt_snooze_delay, cpu) = snooze;
- }
+ snooze = simple_strtol(str, NULL, 10);
+ for_each_possible_cpu(cpu)
+ per_cpu(smt_snooze_delay, cpu) = snooze;
return 1;
}
Index: powerpc.git/arch/powerpc/platforms/pseries/setup.c
===
--- powerpc.git.orig/arch/powerpc/platforms/pseries/setup.c 2010-05-17
15:05:29.827204407 +1000
+++ powerpc.git/arch/powerpc/platforms/pseries/setup.c 2010-05-17
15:18:26.207205125 +1000
@@ -496,13 +496,14 @@ static int __init pSeries_probe(void)
}
-DECLARE_PER_CPU(unsigned long, smt_snooze_delay);
+DECLARE_PER_CPU(long, smt_snooze_delay);
static void pseries_dedicated_idle_sleep(void)
{
unsigned int cpu = smp_processor_id();
unsigned long start_snooze;
unsigned long in_purr, out_purr;
+ long snooze = __get_cpu_var(smt_snooze_delay);
/*
* Indicate to the HV that we are idle. Now would be
@@ -517,13 +518,12 @@ static void pseries_dedicated_idle_sleep
* has been checked recently. If we should poll for a little
* while, do so.
*/
- if (__get_cpu_var(smt_snooze_delay)) {
- start_snooze = get_tb() +
- __get_cpu_var(smt_snooze_delay) * tb_ticks_per_usec;
+ if (snooze) {
+ start_snooze = get_tb() + snooze * tb_ticks_per_usec;
local_irq_enable();
set_thread_flag(TIF_POLLING_NRFLAG);
- while (get_tb() start_snooze) {
+ while ((snooze 0) || (get_tb() start_snooze)) {
if (need_resched() || cpu_is_offline(cpu))
goto out;
ppc64_runlatch_off();
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 2/3] powerpc: numa: Use ibm,architecture-vec-5 to detect form 1 affinity
I've been told that the architected way to determine we are in form 1
affinity mode is by reading the ibm,architecture-vec-5 property which
mirrors the layout of the fifth byte of the ibm,client-architecture
structure.
Eventually we may want to parse the ibm,architecture-vec-5 and create
FW_FEATURE_* bits.
Signed-off-by: Anton Blanchard an...@samba.org
---
Index: powerpc.git/arch/powerpc/mm/numa.c
===
--- powerpc.git.orig/arch/powerpc/mm/numa.c 2010-05-17 12:56:02.0
+1000
+++ powerpc.git/arch/powerpc/mm/numa.c 2010-05-17 15:01:40.345954329 +1000
@@ -271,7 +271,8 @@ static int __init find_min_common_depth(
const unsigned int *ref_points;
struct device_node *rtas_root;
unsigned int len;
- struct device_node *options;
+ struct device_node *chosen;
+ const char *vec5;
rtas_root = of_find_node_by_path(/rtas);
@@ -289,14 +290,17 @@ static int __init find_min_common_depth(
ibm,associativity-reference-points, len);
/*
-* For type 1 affinity information we want the first field
+* For form 1 affinity information we want the first field
*/
- options = of_find_node_by_path(/options);
- if (options) {
- const char *str;
- str = of_get_property(options, ibm,associativity-form, NULL);
- if (str !strcmp(str, 1))
-index = 0;
+#define VEC5_AFFINITY_BYTE 5
+#define VEC5_AFFINITY 0x80
+ chosen = of_find_node_by_path(/chosen);
+ if (chosen) {
+ vec5 = of_get_property(chosen, ibm,architecture-vec-5, NULL);
+ if (vec5 (vec5[VEC5_AFFINITY_BYTE] VEC5_AFFINITY)) {
+ dbg(Using form 1 affinity\n);
+ index = 0;
+ }
}
if ((len = 2 * sizeof(unsigned int)) ref_points) {
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 3/3] powerpc: numa: Use form 1 affinity to setup node distance
Form 1 affinity allows multiple entries in ibm,associativity-reference-points
which represent affinity domains in decreasing order of importance. The
Linux concept of a node is always the first entry, but using the other
values as an input to node_distance() allows the memory allocator to make
better decisions on which node to go first when local memory has been
exhausted.
We keep things simple and create an array indexed by NUMA node, capped at
4 entries. Each time we lookup an associativity property we initialise
the array which is overkill, but since we should only hit this path during
boot it didn't seem worth adding a per node valid bit.
Signed-off-by: Anton Blanchard an...@samba.org
---
Index: powerpc.git/arch/powerpc/mm/numa.c
===
--- powerpc.git.orig/arch/powerpc/mm/numa.c 2010-05-17 15:01:40.345954329
+1000
+++ powerpc.git/arch/powerpc/mm/numa.c 2010-05-17 15:01:43.334704959 +1000
@@ -42,6 +42,12 @@ EXPORT_SYMBOL(node_data);
static int min_common_depth;
static int n_mem_addr_cells, n_mem_size_cells;
+static int form1_affinity;
+
+#define MAX_DISTANCE_REF_POINTS 4
+static int distance_ref_points_depth;
+static const unsigned int *distance_ref_points;
+static int distance_lookup_table[MAX_NUMNODES][MAX_DISTANCE_REF_POINTS];
/*
* Allocate node_to_cpumask_map based on number of available nodes
@@ -204,6 +210,39 @@ static const u32 *of_get_usable_memory(s
return prop;
}
+int __node_distance(int a, int b)
+{
+ int i;
+ int distance = LOCAL_DISTANCE;
+
+ if (!form1_affinity)
+ return distance;
+
+ for (i = 0; i distance_ref_points_depth; i++) {
+ if (distance_lookup_table[a][i] == distance_lookup_table[b][i])
+ break;
+
+ /* Double the distance for each NUMA level */
+ distance *= 2;
+ }
+
+ return distance;
+}
+
+static void initialize_distance_lookup_table(int nid,
+ const unsigned int *associativity)
+{
+ int i;
+
+ if (!form1_affinity)
+ return;
+
+ for (i = 0; i distance_ref_points_depth; i++) {
+ distance_lookup_table[nid][i] =
+ associativity[distance_ref_points[i]];
+ }
+}
+
/* Returns nid in the range [0..MAX_NUMNODES-1], or -1 if no useful numa
* info is found.
*/
@@ -225,6 +264,10 @@ static int of_node_to_nid_single(struct
/* POWER4 LPAR uses 0x as invalid node */
if (nid == 0x || nid = MAX_NUMNODES)
nid = -1;
+
+ if (nid 0 tmp[0] = distance_ref_points_depth)
+ initialize_distance_lookup_table(nid, tmp);
+
out:
return nid;
}
@@ -251,26 +294,10 @@ int of_node_to_nid(struct device_node *d
}
EXPORT_SYMBOL_GPL(of_node_to_nid);
-/*
- * In theory, the ibm,associativity property may contain multiple
- * associativity lists because a resource may be multiply connected
- * into the machine. This resource then has different associativity
- * characteristics relative to its multiple connections. We ignore
- * this for now. We also assume that all cpu and memory sets have
- * their distances represented at a common level. This won't be
- * true for hierarchical NUMA.
- *
- * In any case the ibm,associativity-reference-points should give
- * the correct depth for a normal NUMA system.
- *
- * - Dave Hansen haveb...@us.ibm.com
- */
static int __init find_min_common_depth(void)
{
- int depth, index;
- const unsigned int *ref_points;
+ int depth;
struct device_node *rtas_root;
- unsigned int len;
struct device_node *chosen;
const char *vec5;
@@ -280,18 +307,28 @@ static int __init find_min_common_depth(
return -1;
/*
-* this property is 2 32-bit integers, each representing a level of
-* depth in the associativity nodes. The first is for an SMP
-* configuration (should be all 0's) and the second is for a normal
-* NUMA configuration.
+* This property is a set of 32-bit integers, each representing
+* an index into the ibm,associativity nodes.
+*
+* With form 0 affinity the first integer is for an SMP configuration
+* (should be all 0's) and the second is for a normal NUMA
+* configuration. We have only one level of NUMA.
+*
+* With form 1 affinity the first integer is the most significant
+* NUMA boundary and the following are progressively less significant
+* boundaries. There can be more than one level of NUMA.
*/
- index = 1;
- ref_points = of_get_property(rtas_root,
- ibm,associativity-reference-points, len);
+ distance_ref_points = of_get_property(rtas_root,
+ ibm,associativity-reference-points,
+
[PATCH 1/3] powerpc: numa: Set a smaller value for RECLAIM_DISTANCE to enable zone reclaim
I noticed /proc/sys/vm/zone_reclaim_mode was 0 on a ppc64 NUMA box. It gets enabled via this: /* * If another node is sufficiently far away then it is better * to reclaim pages in a zone before going off node. */ if (distance RECLAIM_DISTANCE) zone_reclaim_mode = 1; Since we use the default value of 20 for REMOTE_DISTANCE and 20 for RECLAIM_DISTANCE it never kicks in. The local to remote bandwidth ratios can be quite large on System p machines so it makes sense for us to reclaim clean pagecache locally before going off node. The patch below sets a smaller value for RECLAIM_DISTANCE and thus enables zone reclaim. Signed-off-by: Anton Blanchard an...@samba.org --- Index: powerpc.git/arch/powerpc/include/asm/topology.h === --- powerpc.git.orig/arch/powerpc/include/asm/topology.h2010-05-17 12:56:02.0 +1000 +++ powerpc.git/arch/powerpc/include/asm/topology.h 2010-05-17 15:01:37.514703571 +1000 @@ -18,6 +18,16 @@ struct device_node; */ #define RECLAIM_DISTANCE 10 +/* + * Before going off node we want the VM to try and reclaim from the local + * node. It does this if the remote distance is larger than RECLAIM_DISTANCE. + * With the default REMOTE_DISTANCE of 20 and the default RECLAIM_DISTANCE of + * 20, we never reclaim and go off node straight away. + * + * To fix this we choose a smaller value of RECLAIM_DISTANCE. + */ +#define RECLAIM_DISTANCE 10 + #include asm/mmzone.h static inline int cpu_to_node(int cpu) ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 2/3] powerpc: numa: Use ibm,architecture-vec-5 to detect form 1 affinity
I've been told that the architected way to determine we are in form 1
affinity mode is by reading the ibm,architecture-vec-5 property which
mirrors the layout of the fifth vector of the ibm,client-architecture
structure.
Eventually we may want to parse the ibm,architecture-vec-5 and create
FW_FEATURE_* bits.
Signed-off-by: Anton Blanchard an...@samba.org
---
v2: I said fifth byte of the ibm,client-architecture when I should have
said fifth vector of the ibm,client-architecture
Index: powerpc.git/arch/powerpc/mm/numa.c
===
--- powerpc.git.orig/arch/powerpc/mm/numa.c 2010-05-17 12:56:02.0
+1000
+++ powerpc.git/arch/powerpc/mm/numa.c 2010-05-17 15:01:40.345954329 +1000
@@ -271,7 +271,8 @@ static int __init find_min_common_depth(
const unsigned int *ref_points;
struct device_node *rtas_root;
unsigned int len;
- struct device_node *options;
+ struct device_node *chosen;
+ const char *vec5;
rtas_root = of_find_node_by_path(/rtas);
@@ -289,14 +290,17 @@ static int __init find_min_common_depth(
ibm,associativity-reference-points, len);
/*
-* For type 1 affinity information we want the first field
+* For form 1 affinity information we want the first field
*/
- options = of_find_node_by_path(/options);
- if (options) {
- const char *str;
- str = of_get_property(options, ibm,associativity-form, NULL);
- if (str !strcmp(str, 1))
-index = 0;
+#define VEC5_AFFINITY_BYTE 5
+#define VEC5_AFFINITY 0x80
+ chosen = of_find_node_by_path(/chosen);
+ if (chosen) {
+ vec5 = of_get_property(chosen, ibm,architecture-vec-5, NULL);
+ if (vec5 (vec5[VEC5_AFFINITY_BYTE] VEC5_AFFINITY)) {
+ dbg(Using form 1 affinity\n);
+ index = 0;
+ }
}
if ((len = 2 * sizeof(unsigned int)) ref_points) {
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v3 3/3] ptp: Added a clock that uses the eTSEC found on the MPC85xx.
On Fri, May 14, 2010 at 12:46:57PM -0500, Scott Wood wrote:
On 05/14/2010 11:46 AM, Richard Cochran wrote:
diff --git a/Documentation/powerpc/dts-bindings/fsl/tsec.txt
b/Documentation/powerpc/dts-bindings/fsl/tsec.txt
Get rid of both device_type and model, and specify a compatible
string instead (e.g. fsl,etsec-ptp).
Okay, will do. I really am at a loss at understanding all the rules in
the whole device tree world. I just tried to follow
Documentation/powerpc and what is already present in the kernel.
Or perhaps this should just be some additional properties on the
existing gianfar nodes, rather than presenting it as a separate
device? How do you associate a given ptp block with the
corresponding gianfar node?
There only one PTP clock. Its registers repeat in each port's memory
space, but you are only supposed to touch the first set of PTP
registers. If you consider how PTP works, there can never be per port
clocks, since this would make it impossible to make a boundary clock,
for example.
The whole idea of this PTP clock framework is to keep the clock
drivers separate from the MAC drivers, even when they use the same
hardware. The functionality is logically divided into two parts. The
MAC provides time stamps, and the clock provides a way to control its
offset and frequency.
Up until this point, people have simply hacked new private ioctls into
the driver for each MAC that supports PTP. That is not a good long
term solution for PTP support in Linux.
In general, I think it will not be hard to keep the MAC and the clock
drivers from stepping on each other's toes. The eTSEC hardware is
certainly able to be used in this way.
If there are differences in ptp implementation between different
versions of etsec, can the ptp driver see the etsec version
register?
There are no differences (that I know of) in how the PTP clocks
work. I have in house the mpc8313, the mpc8572, and the p2020. The
mpc8572 appears to lack some of the TMR_CTRL bits, but this is
probably a documentation bug. I will check it.
+ - tclk_period Timer reference clock period in nanoseconds.
+ - tmr_prsc Prescaler, divides the output clock.
+ - tmr_add Frequency compensation value.
+ - cksel0= external clock, 1= eTSEC system clock, 3= RTC clock
input.
+ Currently the driver only supports choice 1.
+ - tmr_fiper1 Fixed interval period pulse generator.
+ - tmr_fiper2 Fixed interval period pulse generator.
Dashes are more typical in OF names than underscores, and it's
generally better to be a little more verbose -- these aren't local
loop iterators.
The names come from the register mnemonics from the documentation. I
prefer to use the same names as is found in the manuals. That way, a
person working with docu in hand will have an easier job.
They should probably have an fsl,ptp- prefix as well.
Okay, but must I then change the following code in order to find them?
Does adding the prefix just mean that I also add it to my search
strings, or is it preprocessed (stripped) somehow?
static int get_of_u32(struct device_node *node, char *str, u32 *val)
{
int plen;
const u32 *prop = of_get_property(node, str, plen);
if (!prop || plen != sizeof(*prop))
return -1;
*val = *prop;
return 0;
}
...
if (get_of_u32(node, tclk_period,etsects-tclk_period) ||
get_of_u32(node, tmr_prsc,etsects-tmr_prsc) ||
get_of_u32(node, tmr_add,etsects-tmr_add) ||
get_of_u32(node, cksel,etsects-cksel) ||
get_of_u32(node, tmr_fiper1,etsects-tmr_fiper1) ||
get_of_u32(node, tmr_fiper2,etsects-tmr_fiper2))
return -ENODEV;
+ These properties set the operational parameters for the PTP
+ clock. You must choose these carefully for the clock to work right.
Do these values describe the way the hardware is, or how it's been
configured by firmware, or a set of values that are clearly optimal
for this particular board? If it's just configuration for the Linux
driver, that could reasonably differ based on what a given user or
OS will want, the device tree probably isn't the right place for it.
The values are related to the board. One important parameter is the
input clock, and the rest reflect some engineering decisions/tradeoffs
related to the signals to and from the PTP clock. There is not just
one optimal choice, so I wanted to let the designer set the
values. In any case, the parameters are definitely related to the
board (not to the cpu or to linux), so I think the device tree is the
right place for them.
This one has 3 interrupts? The driver supports only two.
The documentation does not specify the IRQ line that each event
belongs to. After some trial and error, it appears that all of the
ancillary clock interrupts arrive on the first interrupt. The other
lines (one per port) must be for the Tx/Rx packet time stamp
indication, but we don't need
Re: [RFC][PATCH 0/12] KVM, x86, ppc, asm-generic: moving dirty bitmaps to user space
User allocated bitmaps have the advantage of reducing pinned memory. However we have plenty more pinned memory allocated in memory slots, so by itself, user allocated bitmaps don't justify this change. In that sense, what do you think about the question I sent last week? === REPOST 1 === mark_page_dirty is called with the mmu_lock spinlock held in set_spte. Must find a way to move it outside of the spinlock section. Oh, it's a serious problem. I have to consider it. Avi, Marcelo, Sorry but I have to say that mmu_lock spin_lock problem was completely out of my mind. Although I looked through the code, it seems not easy to move the set_bit_user to outside of spinlock section without breaking the semantics of its protection. So this may take some time to solve. But personally, I want to do something for x86's vmallc() every time problem even though moving dirty bitmaps to user space cannot be achieved soon. In that sense, do you mind if we do double buffering without moving dirty bitmaps to user space? I know that the resource for vmalloc() is precious for x86 but even now, at the timing of get_dirty_log, we use the same amount of memory as double buffering. === 1 END === Perhaps if we optimize memory slot write protection (I have some ideas about this) we can make the performance improvement more pronounced. It's really nice! Even now we can measure the performance improvement by introducing switch ioctl when guest is relatively idle, so the combination will be really effective! === REPOST 2 === Can you post such a test, for an idle large guest? OK, I'll do! Result of low workload test (running top during migration) first, 4GB guest picked up slots[1](len=3757047808) only * get.org get.optswitch.opt 1060875 310292 190335 1076754 301295 188600 655504 318284 196029 529769 301471325 694796 70216 221172 651868 353073 196184 543339 312865 213236 1061938 72785 203090 689527 323901 249519 621364 323881473 1063671 70703 192958 915903 336318 174008 1046462 332384782 1037942 72783 190655 680122 318305 243544 688156 314935 193526 558658 265934 190550 652454 372135 196270 660140 68613352 1101947 378642 186575 ......... * As expected we've got the difference more clearly. In this case, switch.opt reduced 1/3 (.1 msec) compared to get.opt for each iteration. And when the slot is cleaner, the ratio is bigger. === 2 END === ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH]460EX on-chip SATA driver Kernel 2.6.33 resubmission
Hi Ben,
On Sunday 16 May 2010 01:40:28 Benjamin Herrenschmidt wrote:
+ SATA0: s...@bffd1000 {
+compatible = amcc,sata-460ex;
+ reg = 4 0xbffd1000 0x800 4 0xbffd0800 0x400;
+interrupt-parent = UIC3;
+interrupts = 0x0 0x4 /* SATA */
+ 0x5 0x4; /* AHBDMA */
+};
+
POB0: opb {
compatible = ibm,opb-460ex, ibm,opb;
#address-cells = 1;
Please put the device tree update in a separate patch to go thru the
PowerPC tree.
Additionally, the boot wrapper should probably either remove the node or
at least use a status property ok / disabled to represent whether
the board is configured for SATA or PCIe x1...
U-Boot already sets the status property of the PCIe or SATA node
accordingly. Just let me know if this doesn't work for you.
Cheers,
Stefan
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH]460EX on-chip SATA driver Kernel 2.6.33 resubmission
Additionally, the boot wrapper should probably either remove the node or at least use a status property ok / disabled to represent whether the board is configured for SATA or PCIe x1... U-Boot already sets the status property of the PCIe or SATA node accordingly. Just let me know if this doesn't work for you. That's probably enough. Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] powerpc/pseries: Make request_ras_irqs() available to other pseries code
At the moment only the RAS code uses event-sources interrupts (for EPOW
events and internal errors) so request_ras_irqs() (which actually requests
the event-sources interrupts) is found in ras.c and is static.
We want to be able to use event-sources interrupts in other pseries code,
so let's rename request_ras_irqs() to request_event_sources_irqs() and
move it to event_sources.c.
This will be used in an upcoming patch that adds support for IO Event
interrupts that come through as event sources.
Signed-off-by: Mark Nelson ma...@au1.ibm.com
---
arch/powerpc/platforms/pseries/Makefile|2
arch/powerpc/platforms/pseries/event_sources.c | 79 +
arch/powerpc/platforms/pseries/event_sources.h | 29 +
arch/powerpc/platforms/pseries/ras.c | 63 +--
4 files changed, 113 insertions(+), 60 deletions(-)
Index: upstream/arch/powerpc/platforms/pseries/event_sources.c
===
--- /dev/null
+++ upstream/arch/powerpc/platforms/pseries/event_sources.c
@@ -0,0 +1,79 @@
+/*
+ * Copyright (C) 2001 Dave Engebretsen IBM Corporation
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ */
+
+#include asm/prom.h
+
+#include event_sources.h
+
+void request_event_sources_irqs(struct device_node *np,
+ irq_handler_t handler,
+ const char *name)
+{
+ int i, index, count = 0;
+ struct of_irq oirq;
+ const u32 *opicprop;
+ unsigned int opicplen;
+ unsigned int virqs[16];
+
+ /* Check for obsolete open-pic-interrupt property. If present, then
+* map those interrupts using the default interrupt host and default
+* trigger
+*/
+ opicprop = of_get_property(np, open-pic-interrupt, opicplen);
+ if (opicprop) {
+ opicplen /= sizeof(u32);
+ for (i = 0; i opicplen; i++) {
+ if (count 15)
+ break;
+ virqs[count] = irq_create_mapping(NULL, *(opicprop++));
+ if (virqs[count] == NO_IRQ)
+ printk(KERN_ERR Unable to allocate interrupt
+ number for %s\n, np-full_name);
+ else
+ count++;
+
+ }
+ }
+ /* Else use normal interrupt tree parsing */
+ else {
+ /* First try to do a proper OF tree parsing */
+ for (index = 0; of_irq_map_one(np, index, oirq) == 0;
+index++) {
+ if (count 15)
+ break;
+ virqs[count] = irq_create_of_mapping(oirq.controller,
+ oirq.specifier,
+ oirq.size);
+ if (virqs[count] == NO_IRQ)
+ printk(KERN_ERR Unable to allocate interrupt
+ number for %s\n, np-full_name);
+ else
+ count++;
+ }
+ }
+
+ /* Now request them */
+ for (i = 0; i count; i++) {
+ if (request_irq(virqs[i], handler, 0, name, NULL)) {
+ printk(KERN_ERR Unable to request interrupt %d for
+ %s\n, virqs[i], np-full_name);
+ return;
+ }
+ }
+}
+
Index: upstream/arch/powerpc/platforms/pseries/event_sources.h
===
--- /dev/null
+++ upstream/arch/powerpc/platforms/pseries/event_sources.h
@@ -0,0 +1,29 @@
+/*
+ * Copyright (C) 2001 Dave Engebretsen IBM Corporation
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A
Re: [Patch 2/2] PPC64-HWBKPT: Implement hw-breakpoints for PPC64
On Fri, May 14, 2010 at 12:25:31PM +0530, K.Prasad wrote: Okay. I will re-use single_step_exception() after modifications; it appearsto have no in-kernel users for it. It's called from exceptions-64s.S, head_32.S and head_8xx.S in arch/powerpc/kernel. Suppose the address at which the data breakpoint has been unmapped, and the process has a handler for the SIGSEGV signal. When we try to single-step the load or store, we will get a DSI (0x300) interrupt, call into do_page_fault, and end up sending the process a SIGSEGV. That will invoke the signal handler, which can then do anything it likes. It can do a blocking system call, it can longjmp() back into its main event, or it can return from the signal handler. Only in the last case will it retry the load or store, and then only if the signal handler hasn't modified the NIP value in the signal frame. That's what I mean by doesn't return to the instruction. At the outset, this seemed to be a scary thing to happen; but turns out to be harmful only to the extent of generating a false hw-breakpoint exception in certain cases. A case-by-case basis analysis reveals thus: Consider an instruction stream i1, i2, i3, ... iN, where i1 has finished execution and i2 is about to be executed but has generated a DSI interrupt with the above-mentioned conditions i.e. DSISR indicates a DABR match + Page-Table entry not found. Now according to do_hash_page in exception-64s.S (as pasted below), do_page_fault() and do_dabr() are invoked one after the other. _STATIC(do_hash_page) std r3,_DAR(r1) std r4,_DSISR(r1) andis. r0,r4,0xa410/* weird error? */ bne-handle_page_fault /* if not, try to insert a HPTE */ andis. r0,r4,dsisr_dabrma...@h bne-handle_dabr_fault Note that bne is not a procedure call; we'll actually get two DSIs in this scenario. But I don't think that matters. Also note that the branch to handle_page_fault here is not for the HPTE-not-found case; it's for the unusual errors. So we'll handle the HPTE insertion after handling the DABR match. Thus, when control returns to user-space to instruction 'i2', the hw_breakpoint_handler() has completed execution, and a SIGSEGV is pending to be delivered and single-stepping enabled MSR_SE is set. Upon return to user-space, the handler for SIGSEGV is executed and it may perform one of the following (as you stated previously): (a) Make a blocking syscall, eventually yielding the CPU to a new thread (b) Jump to a different instruction in user-space, say iN, and not complete the execution of instruction i2 at all. (c) Return to instruction i2 and complete the execution. In case of (a), the context-switches should not affect the ability to single-step the instruction when the thread is eventually scheduled to run. The thread, when scheduled onto the CPU will complete signal handling, return to execute instruction i2, cause single-step exception, restore breakpoints and run smoothly thereafter. Right. However, the thread is running the signal handler without the DABR being set, which is unfortunate. In case of (b), the new instruction iN is single-stepped, the breakpoint values are restored and the hw-breakpoint exception callback is invoked after iN is executed. The user of this breakpoint i.e. the caller of register_user_hw_breakpoint() who had placed a breakpoint on addressed accessed by instruction i2 will be confused to find that an unrelated instruction (which may not be a load/store) has caused the breakpoint. That's the case if the signal handler modifies the NIP value in the register set saved on the stack and returns. If the signal handler instead simply jumps to instruction iN (e.g. with longjmp or siglongjmp), we'll never get the single-step callback. If so desired, we may adopt the 'trigger-before-execute' semantics for user-space breakpoints wherein the hw-breakpoint callback (through perf_bp_event()) is invoked in hw_breakpoint_handler() itself. This would indicate to the user that the impending instruction causes a DABR 'hit' but it may or may not be executed due to the role of signal-handler or due to self-modifying code (as mentioned below). Kindly let me know what you think about it. (c) is the normal execution path we desire. The instruction i2 will be safely single-stepped and breakpoints are restored. The instruction could be changed underneath us if the program is multi-threaded and another thread writes another instruction to the instruction word where the load or store is. Or it could use mmap() to map some other page at the address of the load or store. Either way we could end up with a different instruction there. If the instruction that originally caused the DABR exception is changed, the new instruction in its place would still single-step to restore breakpoint values. However the user of breakpoint interface will
[PATCH] powerpc/pseries: Add support for IO Event interrupt drivers
This patch adds support for handling IO Event interrupts which come
through at the /event-sources/ibm,io-events device tree node.
There is one ibm,io-events interrupt, but this interrupt might be used
for multiple I/O devices, each with their own separate driver. So, we
create a platform interrupt handler that will do the RTAS check-exception
call and then call the appropriate driver's interrupt handler (the one(s)
that registered with a scope that matches the scope of the incoming
interrupt).
So, a driver for a device that uses IO Event interrupts will register
it's interrupt service routine (or interrupt handler) with the platform
code using ioei_register_isr(). This register function takes a function
pointer to the driver's handler and the scope that the driver is
interested in (scopes defined in arch/powerpc/include/asm/io_events.h).
The driver's handler must take a pointer to a struct io_events_section
and must not return anything.
The platform code registers io_event_interrupt() as the interrupt handler
for the ibm,io-events interrupt. Upon receiving an IO Event interrupt, it
checks the scope of the incoming interrupt and only calls those drivers'
handlers that have registered as being interested in that scope.
It is possible for a single driver to register the same function pointer
more than once with different scopes if it is interested in more than one
type of IO Event interrupt. If a handler wants to be notified of all
incoming IO Event interrupts it can register with IOEI_SCOPE_ANY.
A driver can unregister to stop receiving the IO Event interrupts using
ioei_unregister_isr(), passing it the same function pointer to the
driver's handler and the scope the driver was registered with.
Signed-off-by: Mark Nelson ma...@au1.ibm.com
---
arch/powerpc/include/asm/io_events.h | 40 +
arch/powerpc/platforms/pseries/Makefile|2
arch/powerpc/platforms/pseries/io_events.c | 205 +
3 files changed, 246 insertions(+), 1 deletion(-)
Index: upstream/arch/powerpc/include/asm/io_events.h
===
--- /dev/null
+++ upstream/arch/powerpc/include/asm/io_events.h
@@ -0,0 +1,40 @@
+/*
+ * Copyright 2010 IBM Corporation, Mark Nelson
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version
+ * 2 of the License, or (at your option) any later version.
+ */
+
+#ifndef _ASM_POWERPC_IOEVENTS_H
+#define _ASM_POWERPC_IOEVENTS_H
+
+struct io_events_section {
+ u16 id; // Unique section identifierx00-x01
+ u16 length; // Section length (bytes) x02-x03
+ u8 version;// Section Version x04-x04
+ u8 sec_subtype;// Section subtype x05-x05
+ u16 creator_id; // Creator Component ID x06-x07
+ u8 event_type; // IO-Event Typex08-x08
+ u8 rpc_field_len; // PRC Field Length x09-x09
+ u8 scope; // Error/Event Scopex0A-x0A
+ u8 event_subtype; // I/O-Event Sub-Type x0B-x0B
+ u32 drc_index; // DRC Indexx0C-x0F
+ u32 rpc_data[]; // RPC Data (optional) x10-...
+};
+
+#define IOEI_SCOPE_NOT_APP 0x00
+#define IOEI_SCOPE_RIO_HUB 0x36
+#define IOEI_SCOPE_RIO_BRIDGE 0x37
+#define IOEI_SCOPE_PHB 0x38
+#define IOEI_SCOPE_EADS_GLOBAL 0x39
+#define IOEI_SCOPE_EADS_SLOT 0x3A
+#define IOEI_SCOPE_TORRENT_HUB 0x3B
+#define IOEI_SCOPE_SERVICE_PROC0x51
+#define IOEI_SCOPE_ANY -1
+
+int ioei_register_isr(void (*isr)(struct io_events_section *), int scope);
+int ioei_unregister_isr(void (*isr)(struct io_events_section *), int scope);
+
+#endif /* _ASM_POWERPC_IOEVENTS_H */
Index: upstream/arch/powerpc/platforms/pseries/io_events.c
===
--- /dev/null
+++ upstream/arch/powerpc/platforms/pseries/io_events.c
@@ -0,0 +1,205 @@
+/*
+ * Copyright 2010 IBM Corporation, Mark Nelson
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version
+ * 2 of the License, or (at your option) any later version.
+ */
+
+#include linux/errno.h
+#include linux/spinlock.h
+#include linux/slab.h
+#include linux/module.h
+#include linux/irq.h
+#include linux/interrupt.h
+#include linux/of.h
+
+#include asm/io_events.h
+#include asm/rtas.h
+#include asm/irq.h
+
+#include event_sources.h
+
+struct ioei_consumer {
+ void (*ioei_isr)(struct io_events_section *);
+ int scope;
+ struct ioei_consumer
Re: event-scan failed logflood
Benjamin Herrenschmidt benh at kernel.crashing.org writes: _omissis__ Ok, that gives us a good thing to use to not do the scanning then. If that's 0 then we assume it's a bogus OF and we disable the scan completely. I'll do a patch later today, though feel free to beat me to it. Cheers, Ben. hi, is there available that patch? With the fresh new 2.6.34 the logflood problem is still present. thanks, --nello ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v3 1/3] ptp: Added a brand new class driver for ptp clocks.
On 05/14/2010 06:45 PM, Richard Cochran wrote: This patch adds an infrastructure for hardware clocks that implement IEEE 1588, the Precision Time Protocol (PTP). A class driver offers a registration method to particular hardware clock drivers. Each clock is exposed to user space as a character device with ioctls that allow tuning of the PTP clock. Signed-off-by: Richard Cochran richard.coch...@omicron.at Tested-by: Wolfgang Grandegger w...@denx.de on my Freescale MPC8313 setup with ptpd and ptpv2d. Wolfgang. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v3 3/3] ptp: Added a clock that uses the eTSEC found on the MPC85xx.
On 05/14/2010 06:46 PM, Richard Cochran wrote: The eTSEC includes a PTP clock with quite a few features. This patch adds support for the basic clock adjustment functions, plus two external time stamps and one alarm. Signed-off-by: Richard Cochran richard.coch...@omicron.at Tested-by: Wolfgang Grandegger w...@denx.de on my Freescale MPC8313 setup with ptpd and ptpv2d. FYI: checkplatch.pl reports various errors for this patch series. Wolfgang. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc: remove tls_ssl_stream descriptor type capability in sec3.3 node
On Apr 22, 2010, at 7:25 PM, Kim Phillips wrote: Technically, whilst SEC v3.3 h/w honours the tls_ssl_stream descriptor type, it lacks the ARC4 algorithm execution unit required to be able to execute anything meaningful with it. Change the node to agree with the documentation that declares that the sec3.3 really doesn't have such a descriptor type. Reported-by: Haiying Wang haiying.w...@freescale.com Signed-off-by: Kim Phillips kim.phill...@freescale.com --- arch/powerpc/boot/dts/mpc8315erdb.dts |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) applied to next - k ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc/85xx: Add eTSEC 2.0 support for P1020RDB boards
On Apr 15, 2010, at 1:36 PM, Anton Vorontsov wrote: This patch adds support for eTSEC 2.0 as found in P1020. The changes include introduction of the group nodes for the etsec nodes. Signed-off-by: Sandeep Gopalpet sandeep.ku...@freescale.com Signed-off-by: Anton Vorontsov avoront...@mvista.com --- This is based on http://www.bitshrine.org/gpp/kernel-2.6.32-rc3-P1020RDB-DTS-Support-for-eTSEC-2.0-v0.patch but revamped for the mainline's OF bindings. arch/powerpc/boot/dts/p1020rdb.dts | 119 1 files changed, 119 insertions(+), 0 deletions(-) applied to next - k ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH-V3] mpc8xxx_gpio: add interrupt support
On Jan 7, 2010, at 10:57 AM, Peter Korsgaard wrote: Signed-off-by: Peter Korsgaard jac...@sunsite.dk --- Changes since v1: - Document OF binding for IRQ as requested by Kumar. Changes since v2: - Fix xlate prototype mismatch warning (intspec should be const) .../powerpc/dts-bindings/fsl/8xxx_gpio.txt | 22 +++- arch/powerpc/sysdev/mpc8xxx_gpio.c | 147 2 files changed, 168 insertions(+), 1 deletions(-) applied to next - k ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc/85xx: Fix P1020RDB boot hang due USB2
On Apr 22, 2010, at 10:44 AM, Anton Vorontsov wrote: Since USB2 is shared with local bus, either local bus or USB2 should be disabled. By default U-Boot enables local bus, so we have to disable USB2, otherwise kernel hangs: ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver fsl-ehci fsl-ehci.0: Freescale On-Chip EHCI Host Controller fsl-ehci fsl-ehci.0: new USB bus registered, assigned bus number 1 fsl-ehci fsl-ehci.0: irq 28, io base 0xffe22000 fsl-ehci fsl-ehci.0: USB 2.0 started, EHCI 1.00 hub 1-0:1.0: USB hub found hub 1-0:1.0: 1 port detected fsl-ehci fsl-ehci.1: Freescale On-Chip EHCI Host Controller fsl-ehci fsl-ehci.1: new USB bus registered, assigned bus number 2 hangs here Note that U-Boot doesn't clear 'status' property when it enables USB2, so we have to comment out the whole node. To enable USB2, one can issue 'setenv hwconfig usb2:dr_mode=host|peripheral' command at the U-Boot prompt. Signed-off-by: Anton Vorontsov avoront...@mvista.com --- arch/powerpc/boot/dts/p1020rdb.dts |6 ++ 1 files changed, 6 insertions(+), 0 deletions(-) applied to next - k ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc/83xx: Add MCU LEDs support for MPC837xRDB and MPC8315RDB boards
On May 2, 2010, at 12:27 PM, Anton Vorontsov wrote: There are two front-panel LEDs on MPC837xRDB and MPC8315RDB boards: PWR and HDD. After adding appropriate nodes we can program these LEDs from kernel and user space. Signed-off-by: Anton Vorontsov avoront...@mvista.com --- arch/powerpc/boot/dts/mpc8315erdb.dts | 14 ++ arch/powerpc/boot/dts/mpc8377_rdb.dts | 14 ++ arch/powerpc/boot/dts/mpc8378_rdb.dts | 14 ++ arch/powerpc/boot/dts/mpc8379_rdb.dts | 14 ++ arch/powerpc/platforms/83xx/mpc831x_rdb.c |1 + arch/powerpc/platforms/83xx/mpc837x_rdb.c |1 + 6 files changed, 58 insertions(+), 0 deletions(-) applied to next - k ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/2] powerpc/8610: add probing for individual DMA channels, not just DMA controllers
On May 3, 2010, at 4:54 PM, Timur Tabi wrote: A future version of the MPC8610 HPCD's ASoC DMA driver will probe on individual DMA channel nodes, so the DMA controller nodes' compatible string must be listed in mpc8610_ids[] for the probe to work. Also remove the gianfar compatible from mpc8610_ids[], since there is no gianfar (or any other networking device) on the 8610. Signed-off-by: Timur Tabi ti...@freescale.com --- Kumar, the ASoC mainters are willing to pick up this patch, but they want an ACK from you first. Or, you could pick it up, since by itself it's harmless. arch/powerpc/platforms/86xx/mpc8610_hpcd.c |3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) applied to next - k ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v4] powerpc: Add hibernation support for FSL BookE processors
On Apr 16, 2010, at 2:03 PM, Anton Vorontsov wrote: This is started as swsusp_32.S modifications, but the amount of #ifdefs made the whole file horribly unreadable, so let's put the support into its own separate file. The code should be relatively easy to modify to support 44x BookEs as well, but since I don't have any 44x to test, let's confine the code to FSL BookE. (The only FSL-specific part so far is 'flush_dcache_L1'.) Signed-off-by: Anton Vorontsov avoront...@mvista.com --- On Fri, Apr 16, 2010 at 10:54:36AM -0500, Scott Wood wrote: Anton Vorontsov wrote: + /* Invalidate TLB0 TLB1 */ + li r6,0x04 + tlbivax 0,r6 + TLBSYNC + li r6,0x0c + tlbivax 0,r6 + TLBSYNC Is this needed? Shouldn't the boot process have already given us a sane TLB? Thanks for catching, it seems that it's just a left over from some debugging code and not actually needed. ..that reminded me the time I spent inserting BookE specific code into swsusp_32.S, and then debugging all that #ifdef mess... This is tested on e500v2. arch/powerpc/kernel/Makefile |8 +- arch/powerpc/kernel/swsusp_booke.S | 192 2 files changed, 198 insertions(+), 2 deletions(-) create mode 100644 arch/powerpc/kernel/swsusp_booke.S Scott, you ok (ACK) this version or still need tweaks? - k ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v3 3/3] ptp: Added a clock that uses the eTSEC found on the MPC85xx.
On 05/17/2010 03:27 AM, Richard Cochran wrote:
On Fri, May 14, 2010 at 12:46:57PM -0500, Scott Wood wrote:
On 05/14/2010 11:46 AM, Richard Cochran wrote:
diff --git a/Documentation/powerpc/dts-bindings/fsl/tsec.txt
b/Documentation/powerpc/dts-bindings/fsl/tsec.txt
Get rid of both device_type and model, and specify a compatible
string instead (e.g. fsl,etsec-ptp).
Okay, will do. I really am at a loss at understanding all the rules in
the whole device tree world. I just tried to follow
Documentation/powerpc and what is already present in the kernel.
There's some stuff in there that isn't how we'd do it now, but is slow
to change for compatibility reasons.
Or perhaps this should just be some additional properties on the
existing gianfar nodes, rather than presenting it as a separate
device? How do you associate a given ptp block with the
corresponding gianfar node?
There only one PTP clock. Its registers repeat in each port's memory
space, but you are only supposed to touch the first set of PTP
registers.
OK. I'm not too familiar with PTP itself, was looking more at the
device tree and similar structural bits.
There are no differences (that I know of) in how the PTP clocks
work. I have in house the mpc8313, the mpc8572, and the p2020. The
mpc8572 appears to lack some of the TMR_CTRL bits, but this is
probably a documentation bug. I will check it.
If there's any possibility of needing to make a distinction (which
probably can't be ruled out with future chips), the chip name could be
made part of the compatible string, with a secondary compatible showing
a canonical part name for that version of the PTP block. E.g. p2020
might have:
compatble = fsl,p2020-etsec-ptp, fsl,mpc8313-etsec-ptp;
The driver would bind only on the mpc8313 version.
There are several examples of this, such as the Freescale i2c driver and
binding (ignore the legacy fsl-i2c).
+ - tmr_fiper1 Fixed interval period pulse generator.
+ - tmr_fiper2 Fixed interval period pulse generator.
MPC8572 and P2020 have fiper3 as well.
They should probably have an fsl,ptp- prefix as well.
Okay, but must I then change the following code in order to find them?
Does adding the prefix just mean that I also add it to my search
strings, or is it preprocessed (stripped) somehow?
It is not stripped; you have to change the code as well.
You've got two IRQs, with the same handler, and the same dev_id?
From the manual it looks like there's one PTP interrupt per eTSEC
(which would explain 3 interrupts on p2020).
Will reduce to just one IRQ.
The device tree should still contain all of the interrupts, in case
they're needed later -- and put a comment in the driver saying why the
first interrupt seems sufficient.
+static struct of_device_id match_table[] = {
+ { .type = ptp_clock },
+ {},
+};
This driver controls every possible PTP implementation?
No, I only want to match with the eTSEC clock device. Given the
compatible string above (fsl,etsec-ptp), what is the correct way to
do this? (pointer to an existing driver to emulate would be enough)
Put .compatible = fsl,etsec-ptp (or fsl,mpc8313-etsec-ptp) where you
have .type = ptp_clock.
-Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v4] powerpc: Add hibernation support for FSL BookE processors
On 04/16/2010 02:03 PM, Anton Vorontsov wrote: + /* restore the MSR */ + lwz r3,SL_MSR(r11) + + /* Restore TB */ + li r3,0 Missing mtmsr? Otherwise ACK. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [git pull] Please pull powerpc.git merge branch
On May 13, 2010, at 11:28 PM, Kumar Gala wrote: The following changes since commit 131c6c9eddfa252e376edb4aeff9c7fe1b96a798: Benjamin Herrenschmidt (1): Merge commit 'kumar/merge' into merge are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/galak/powerpc.git merge Kumar Gala (1): powerpc/fsl-booke: Move loadcam_entry back to asm code to fix SMP ftrace Li Yang (1): powerpc/fsl-booke: Fix InstructionTLBError execute permission check arch/powerpc/kernel/asm-offsets.c|8 arch/powerpc/kernel/head_fsl_booke.S | 13 ++--- arch/powerpc/mm/fsl_booke_mmu.c | 25 +++-- arch/powerpc/mm/mmu_decl.h | 10 +- arch/powerpc/mm/tlb_nohash_low.S | 28 5 files changed, 58 insertions(+), 26 deletions(-) ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev I've just moved these into my next branch. Will send them to stable once they get pulled into .35. - k ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v2] powerpc/e500mc: Implement machine check handler.
On Apr 8, 2010, at 12:38 AM, Kumar Gala wrote: From: Scott Wood scottw...@freescale.com Most of the MSCR bit assigments are different in e500mc versus e500, and they are now write-one-to-clear. Some e500mc machine check conditions are made recoverable (as long as they aren't stuck on), most notably L1 instruction cache parity errors. Signed-off-by: Scott Wood scottw...@freescale.com Signed-off-by: Kumar Gala ga...@kernel.crashing.org --- * Fix build error arch/powerpc/include/asm/cputable.h |1 + arch/powerpc/include/asm/reg_booke.h | 33 + arch/powerpc/kernel/cputable.c |2 +- arch/powerpc/kernel/traps.c | 88 +- 4 files changed, 112 insertions(+), 12 deletions(-) applied to next - k ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/3] powerpc/fsl: 85xx: document cache sram bindings
On Dec 8, 2009, at 1:31 AM, Vivek Mahajan wrote: Adds binding documentation for cache sram for the PQ3 and some QorIQ based platforms. Signed-off-by: Vivek Mahajan vivek.maha...@freescale.com --- .../powerpc/dts-bindings/fsl/85xx_cache_sram.txt | 20 1 files changed, 20 insertions(+), 0 deletions(-) create mode 100644 Documentation/powerpc/dts-bindings/fsl/85xx_cache_sram.txt This looks fine, I'm going to rename the file when I apply this patch since its applicable to more than 85xx. - k ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 2/3] powerpc/fsl: 85xx: p2020rdb: add cache sram node
On Dec 8, 2009, at 1:31 AM, Vivek Mahajan wrote:
Signed-off-by: Vivek Mahajan vivek.maha...@freescale.com
---
arch/powerpc/boot/dts/p2020rdb.dts |6 ++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/boot/dts/p2020rdb.dts
b/arch/powerpc/boot/dts/p2020rdb.dts
index da4cb0d..8a26050 100644
--- a/arch/powerpc/boot/dts/p2020rdb.dts
+++ b/arch/powerpc/boot/dts/p2020rdb.dts
@@ -583,4 +583,10 @@
0x0 0x10;
};
};
+
+ cache-s...@fff0 {
+ fsl,cache-sram-ctlr-handle = L2;
+ reg = 0 0xfff0 0 0x1;
+ compatible = fsl,p2020-cache-sram;
+ };
};
--
1.5.6.5
Sorry, we've let this sit too long:
This should be created by u-boot instead of static in the .dts. The assumption
should be the cache/SRAM is already setup this way via u-boot and its just
conveying the HW config to the kernel.
In the future we should have the kernel dynamically allocate a physical address
region for the SRAM (if its not already setup by u-boot).
- k
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH v5] powerpc: Add hibernation support for FSL BookE processors
This is started as swsusp_32.S modifications, but the amount of #ifdefs made the whole file horribly unreadable, so let's put the support into its own separate file. The code should be relatively easy to modify to support 44x BookEs as well, but since I don't have any 44x to test, let's confine the code to FSL BookE. (The only FSL-specific part so far is 'flush_dcache_L1'.) Signed-off-by: Anton Vorontsov avoront...@mvista.com Acked-by: Scott Wood scottw...@freescale.com --- On Mon, May 17, 2010 at 01:12:37PM -0500, Scott Wood wrote: On 04/16/2010 02:03 PM, Anton Vorontsov wrote: +/* restore the MSR */ +lwz r3,SL_MSR(r11) + +/* Restore TB */ +li r3,0 Missing mtmsr? Otherwise ACK. Fixed, thanks! arch/powerpc/kernel/Makefile |8 +- arch/powerpc/kernel/swsusp_booke.S | 193 2 files changed, 199 insertions(+), 2 deletions(-) create mode 100644 arch/powerpc/kernel/swsusp_booke.S diff --git a/arch/powerpc/kernel/Makefile b/arch/powerpc/kernel/Makefile index 8773263..58d0572 100644 --- a/arch/powerpc/kernel/Makefile +++ b/arch/powerpc/kernel/Makefile @@ -57,8 +57,12 @@ obj-$(CONFIG_CRASH_DUMP) += crash_dump.o obj-$(CONFIG_E500) += idle_e500.o obj-$(CONFIG_6xx) += idle_6xx.o l2cr_6xx.o cpu_setup_6xx.o obj-$(CONFIG_TAU) += tau_6xx.o -obj-$(CONFIG_HIBERNATION) += swsusp.o suspend.o \ - swsusp_$(CONFIG_WORD_SIZE).o +obj-$(CONFIG_HIBERNATION) += swsusp.o suspend.o +ifeq ($(CONFIG_FSL_BOOKE),y) +obj-$(CONFIG_HIBERNATION) += swsusp_booke.o +else +obj-$(CONFIG_HIBERNATION) += swsusp_$(CONFIG_WORD_SIZE).o +endif obj64-$(CONFIG_HIBERNATION)+= swsusp_asm64.o obj-$(CONFIG_MODULES) += module.o module_$(CONFIG_WORD_SIZE).o obj-$(CONFIG_44x) += cpu_setup_44x.o diff --git a/arch/powerpc/kernel/swsusp_booke.S b/arch/powerpc/kernel/swsusp_booke.S new file mode 100644 index 000..b674d6d --- /dev/null +++ b/arch/powerpc/kernel/swsusp_booke.S @@ -0,0 +1,193 @@ +/* + * Based on swsusp_32.S, modified for FSL BookE by + * Anton Vorontsov avoront...@ru.mvista.com + * Copyright (c) 2009-2010 MontaVista Software, LLC. + */ + +#include linux/threads.h +#include asm/processor.h +#include asm/page.h +#include asm/cputable.h +#include asm/thread_info.h +#include asm/ppc_asm.h +#include asm/asm-offsets.h +#include asm/mmu.h + +/* + * Structure for storing CPU registers on the save area. + */ +#define SL_SP 0 +#define SL_PC 4 +#define SL_MSR 8 +#define SL_TCR 0xc +#define SL_SPRG0 0x10 +#define SL_SPRG1 0x14 +#define SL_SPRG2 0x18 +#define SL_SPRG3 0x1c +#define SL_SPRG4 0x20 +#define SL_SPRG5 0x24 +#define SL_SPRG6 0x28 +#define SL_SPRG7 0x2c +#define SL_TBU 0x30 +#define SL_TBL 0x34 +#define SL_R2 0x38 +#define SL_CR 0x3c +#define SL_LR 0x40 +#define SL_R12 0x44/* r12 to r31 */ +#define SL_SIZE(SL_R12 + 80) + + .section .data + .align 5 + +_GLOBAL(swsusp_save_area) + .space SL_SIZE + + + .section .text + .align 5 + +_GLOBAL(swsusp_arch_suspend) + lis r11,swsusp_save_a...@h + ori r11,r11,swsusp_save_a...@l + + mflrr0 + stw r0,SL_LR(r11) + mfcrr0 + stw r0,SL_CR(r11) + stw r1,SL_SP(r11) + stw r2,SL_R2(r11) + stmwr12,SL_R12(r11) + + /* Save MSR TCR */ + mfmsr r4 + stw r4,SL_MSR(r11) + mfspr r4,SPRN_TCR + stw r4,SL_TCR(r11) + + /* Get a stable timebase and save it */ +1: mfspr r4,SPRN_TBRU + stw r4,SL_TBU(r11) + mfspr r5,SPRN_TBRL + stw r5,SL_TBL(r11) + mfspr r3,SPRN_TBRU + cmpwr3,r4 + bne 1b + + /* Save SPRGs */ + mfsprg r4,0 + stw r4,SL_SPRG0(r11) + mfsprg r4,1 + stw r4,SL_SPRG1(r11) + mfsprg r4,2 + stw r4,SL_SPRG2(r11) + mfsprg r4,3 + stw r4,SL_SPRG3(r11) + mfsprg r4,4 + stw r4,SL_SPRG4(r11) + mfsprg r4,5 + stw r4,SL_SPRG5(r11) + mfsprg r4,6 + stw r4,SL_SPRG6(r11) + mfsprg r4,7 + stw r4,SL_SPRG7(r11) + + /* Call the low level suspend stuff (we should probably have made +* a stackframe... +*/ + bl swsusp_save + + /* Restore LR from the save area */ + lis r11,swsusp_save_a...@h + ori r11,r11,swsusp_save_a...@l + lwz r0,SL_LR(r11) + mtlrr0 + + blr + +_GLOBAL(swsusp_arch_resume) + sync + + /* Load ptr the list of pages to copy in r3 */ + lis r11,(restore_pblist)@h + ori r11,r11,restore_pbl...@l + lwz r3,0(r11) + + /* Copy the pages. This is a very basic implementation, to +
Re: [RFC PATCH v2 1/2] powerpc: cleanup APIs for cpu/thread/core mappings
* Vaidyanathan Srinivasan sva...@linux.vnet.ibm.com [2010-05-10 11:18:01]: * Paul Mackerras pau...@samba.org [2010-05-10 09:05:22]: On Fri, May 07, 2010 at 05:18:42PM +0530, Vaidyanathan Srinivasan wrote: These APIs take logical cpu number as input Change cpu_first_thread_in_core() to cpu_leftmost_thread_sibling() Change cpu_last_thread_in_core() to cpu_rightmost_thread_sibling() These APIs convert core number (index) to logical cpu/thread numbers Add cpu_first_thread_of_core(int core) Changed cpu_thread_to_core() to cpu_core_of_thread(int cpu) Why make all these changes? The end result doesn't seem any cleaner or better than how it was before, and your patch description doesn't give any reason for us to think yes, we should make this change. I assume you think this is a good change to make, so you need to explain why it's a good idea and convince the rest of us. Sure Paul.. let me explain. The crux of the issue is to make 'threads_per_core' accessible to the pseries_energy module. In the first RFC, I had directly exported the variable which is not a good design. Ben H suggested to make an API around it and then export the function: http://lists.ozlabs.org/pipermail/linuxppc-dev/2010-April/081610.html Instead of making an API to read threads_per_core, as Ben suggested, I have made a wrapper at a higher level to make an API to convert from logical cpu number to core number. The current APIs cpu_first_thread_in_core() and cpu_last_thread_in_core() returns logical CPU number while cpu_thread_to_core() returns core number or index which is not a logical CPU number. Ben recommended to clearly name them to distinguish 'core number' versus first and last 'logical cpu number' in that core. Hence in the new scheme, I have: Change cpu_first_thread_in_core() to cpu_leftmost_thread_sibling() Change cpu_last_thread_in_core() to cpu_rightmost_thread_sibling() which work on logical cpu numbers. While cpu_first_thread_of_core() and cpu_core_of_thread() work on core index. Example usage: (4 threads per core system) cpu_leftmost_thread_sibling(5) = 4 cpu_rightmost_thread_sibling(5) = 7 cpu_core_of_thread(5) = 1 cpu_first_thread_of_core(1) = 4 cpu_core_of_thread() is used in cpu_to_drc_index() in the module and cpu_first_thread_of_core() is used in drc_index_to_cpu() in the module. These APIs may be useful in other modules in future, and the proposed design is a good method to export these APIs to modules. An alternative approach could be to move both the base functions cpu_to_drc_index() and drc_index_to_cpu() into the kernel like in arch/powerpc/kernel/smp.c Thanks for the review, I hope I have explained the requirements and design for this cleanup. Hi Paul and Ben, Do you have any further comments on this patch series and related cleanup? I will post the next iteration in a day or two. Thanks, Vaidy ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: mpc870 support in the powerpc arch?
On Fri, May 14, 2010 at 02:41:29PM -0700, Shawn Jin wrote: Hi, Is mpc870 fully supported in the powerpc arch? I know it's an old processor but 8xx is still one of platforms in the powerpc arch. If it's not supported, how much effort will it be to resurrect mpc870 in the new arch considering we have substantial 8xx support? It should work, with appropriate board support -- MPC875 and MPC885 have been used with arch/powerpc, and MPC870 is very similar (albeit with fewer devices). -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] hwmon: (tmp421) Add nfactor support (2nd attempt)
Here is a second attempt at a patch to add nfactor support to the tmp421 driver.
This includes the changes as suggested by Andre Prendel, the original driver
author.
From 8ebe84174ff6bd294656d77183758044f19d8900 Mon Sep 17 00:00:00 2001
From: Jeff Angielski j...@theptrgroup.com
Date: Mon, 10 May 2010 10:26:34 -0400
Subject: [PATCH] hwmon: (tmp421) Add nfactor support
Add support for reading and writing the n-factor correction
registers. This is needed to compensate for the characteristics
of a particular sensor hanging off of the remote channels.
Signed-off-by: Jeff Angielski j...@theptrgroup.com
---
drivers/hwmon/tmp421.c | 41 +
1 files changed, 41 insertions(+), 0 deletions(-)
diff --git a/drivers/hwmon/tmp421.c b/drivers/hwmon/tmp421.c
index 738c472..ce1f6d1 100644
--- a/drivers/hwmon/tmp421.c
+++ b/drivers/hwmon/tmp421.c
@@ -49,6 +49,7 @@ enum chips { tmp421, tmp422, tmp423 };
static const u8 TMP421_TEMP_MSB[4] = { 0x00, 0x01, 0x02, 0x03 };
static const u8 TMP421_TEMP_LSB[4] = { 0x10, 0x11, 0x12, 0x13 };
+static const u8 TMP421_NFACTOR[3] = { 0x21, 0x22, 0x23 };
/* Flags */
#define TMP421_CONFIG_SHUTDOWN 0x40
@@ -76,6 +77,7 @@ struct tmp421_data {
int channels;
u8 config;
s16 temp[4];
+ s8 nfactor[3];
};
static int temp_from_s16(s16 reg)
@@ -115,6 +117,10 @@ static struct tmp421_data *tmp421_update_device(struct
device *dev)
data-temp[i] |= i2c_smbus_read_byte_data(client,
TMP421_TEMP_LSB[i]);
}
+ for (i = 1; i data-channels; i++) {
+ data-nfactor[i - 1] = i2c_smbus_read_byte_data(client,
+ TMP421_NFACTOR[i - 1]);
+ }
data-last_updated = jiffies;
data-valid = 1;
}
@@ -157,6 +163,32 @@ static ssize_t show_fault(struct device *dev,
return sprintf(buf, 0\n);
}
+static ssize_t show_nfactor(struct device *dev,
+ struct device_attribute *devattr, char *buf)
+{
+ int index = to_sensor_dev_attr(devattr)-index;
+ struct tmp421_data *data = tmp421_update_device(dev);
+
+ return sprintf(buf, %d\n, data-nfactor[index - 1]);
+}
+
+static ssize_t set_nfactor(struct device *dev,
+ struct device_attribute *devattr,
+ const char *buf, size_t count)
+{
+ struct i2c_client *client = to_i2c_client(dev);
+ struct tmp421_data *data = i2c_get_clientdata(client);
+ int index = to_sensor_dev_attr(devattr)-index;
+ int nfactor = simple_strtol(buf, NULL, 10);
+
+ mutex_lock(data-update_lock);
+ i2c_smbus_write_byte_data(client, TMP421_NFACTOR[index - 1],
+ SENSORS_LIMIT(nfactor, -128, 127));
+ mutex_unlock(data-update_lock);
+
+ return count;
+}
+
static mode_t tmp421_is_visible(struct kobject *kobj, struct attribute *a,
int n)
{
@@ -177,19 +209,28 @@ static mode_t tmp421_is_visible(struct kobject *kobj,
struct attribute *a,
static SENSOR_DEVICE_ATTR(temp1_input, S_IRUGO, show_temp_value, NULL, 0);
static SENSOR_DEVICE_ATTR(temp2_input, S_IRUGO, show_temp_value, NULL, 1);
static SENSOR_DEVICE_ATTR(temp2_fault, S_IRUGO, show_fault, NULL, 1);
+static SENSOR_DEVICE_ATTR(temp2_nfactor, S_IRUSR | S_IWUSR | S_IRGRP,
+ show_nfactor, set_nfactor, 1);
static SENSOR_DEVICE_ATTR(temp3_input, S_IRUGO, show_temp_value, NULL, 2);
static SENSOR_DEVICE_ATTR(temp3_fault, S_IRUGO, show_fault, NULL, 2);
+static SENSOR_DEVICE_ATTR(temp3_nfactor, S_IRUSR | S_IWUSR | S_IRGRP,
+ show_nfactor, set_nfactor, 2);
static SENSOR_DEVICE_ATTR(temp4_input, S_IRUGO, show_temp_value, NULL, 3);
static SENSOR_DEVICE_ATTR(temp4_fault, S_IRUGO, show_fault, NULL, 3);
+static SENSOR_DEVICE_ATTR(temp4_nfactor, S_IRUSR | S_IWUSR | S_IRGRP,
+ show_nfactor, set_nfactor, 3);
static struct attribute *tmp421_attr[] = {
sensor_dev_attr_temp1_input.dev_attr.attr,
sensor_dev_attr_temp2_input.dev_attr.attr,
sensor_dev_attr_temp2_fault.dev_attr.attr,
+ sensor_dev_attr_temp2_nfactor.dev_attr.attr,
sensor_dev_attr_temp3_input.dev_attr.attr,
sensor_dev_attr_temp3_fault.dev_attr.attr,
+ sensor_dev_attr_temp3_nfactor.dev_attr.attr,
sensor_dev_attr_temp4_input.dev_attr.attr,
sensor_dev_attr_temp4_fault.dev_attr.attr,
+ sensor_dev_attr_temp4_nfactor.dev_attr.attr,
NULL
};
--
Jeff Angielski
The PTR Group
www.theptrgroup.com
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v5] powerpc: Add hibernation support for FSL BookE processors
On May 17, 2010, at 1:56 PM, Anton Vorontsov wrote: This is started as swsusp_32.S modifications, but the amount of #ifdefs made the whole file horribly unreadable, so let's put the support into its own separate file. The code should be relatively easy to modify to support 44x BookEs as well, but since I don't have any 44x to test, let's confine the code to FSL BookE. (The only FSL-specific part so far is 'flush_dcache_L1'.) Signed-off-by: Anton Vorontsov avoront...@mvista.com Acked-by: Scott Wood scottw...@freescale.com --- On Mon, May 17, 2010 at 01:12:37PM -0500, Scott Wood wrote: On 04/16/2010 02:03 PM, Anton Vorontsov wrote: + /* restore the MSR */ + lwz r3,SL_MSR(r11) + + /* Restore TB */ + li r3,0 Missing mtmsr? Otherwise ACK. Fixed, thanks! arch/powerpc/kernel/Makefile |8 +- arch/powerpc/kernel/swsusp_booke.S | 193 2 files changed, 199 insertions(+), 2 deletions(-) create mode 100644 arch/powerpc/kernel/swsusp_booke.S applied to next (fixed one white space issue). - k ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v5] powerpc: Add hibernation support for FSL BookE processors
On May 17, 2010, at 1:56 PM, Anton Vorontsov wrote: This is started as swsusp_32.S modifications, but the amount of #ifdefs made the whole file horribly unreadable, so let's put the support into its own separate file. The code should be relatively easy to modify to support 44x BookEs as well, but since I don't have any 44x to test, let's confine the code to FSL BookE. (The only FSL-specific part so far is 'flush_dcache_L1'.) Signed-off-by: Anton Vorontsov avoront...@mvista.com Acked-by: Scott Wood scottw...@freescale.com --- On Mon, May 17, 2010 at 01:12:37PM -0500, Scott Wood wrote: On 04/16/2010 02:03 PM, Anton Vorontsov wrote: + /* restore the MSR */ + lwz r3,SL_MSR(r11) + + /* Restore TB */ + li r3,0 Missing mtmsr? Otherwise ACK. Fixed, thanks! arch/powerpc/kernel/Makefile |8 +- arch/powerpc/kernel/swsusp_booke.S | 193 2 files changed, 199 insertions(+), 2 deletions(-) create mode 100644 arch/powerpc/kernel/swsusp_booke.S Is there board specific code to go along with this? When I enable I get: arch/powerpc/kernel/built-in.o: In function `cpu_idle': /home/galak/git/master/powerpc/arch/powerpc/kernel/idle.c:98: undefined reference to `cpu_die' make: *** [.tmp_vmlinux1] Error 1 - k ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v2] kexec-tools, ppc64: Fix segfault parsing DR memory property
In message 4becbe89.3020...@ozlabs.org you wrote:
add_dyn_reconf_usable_mem_property() iterates over memory spans
in /ibm,dynamic-reconfiguration-memory/ibm,dynamic-memory and intersects
these with usablemem_rgns ranges. In doing so it used an unchecked
fixed-size array which will overrun on machines with lots of LMBs.
This patch removes the fixed-sized arrays from
add_dyn_reconf_usable_mem_property() and add_usable_mem_property(), in lieu o
f
malloc/realloc/free.
Signed-off-by: Matt Evans m...@ozlabs.org
So this works our large P7 machine unlike the last one.
Acked-by: Michael Neuling mi...@neuling.org
---
kexec/arch/ppc64/fs2dt.c | 82 +++-
--
1 files changed, 70 insertions(+), 12 deletions(-)
diff --git a/kexec/arch/ppc64/fs2dt.c b/kexec/arch/ppc64/fs2dt.c
index 762bf04..4400f13 100644
--- a/kexec/arch/ppc64/fs2dt.c
+++ b/kexec/arch/ppc64/fs2dt.c
@@ -37,7 +37,7 @@
#define NAMESPACE 16384 /* max bytes for property names */
#define INIT_TREE_WORDS 65536/* Initial num words for prop values */
#define MEMRESERVE 256 /* max number of reserved memory blocks
*/
-#define MAX_MEMORY_RANGES 1024
+#define MEM_RANGE_CHUNK_SZ 2048 /* Initial num dwords for mem ranges */
static char pathname[MAXPATH], *pathstart;
static char propnames[NAMESPACE] = { 0 };
@@ -148,7 +148,8 @@ static void add_dyn_reconf_usable_mem_property(int fd)
{
char fname[MAXPATH], *bname;
uint64_t buf[32];
- uint64_t ranges[2*MAX_MEMORY_RANGES];
+ uint64_t *ranges;
+ int ranges_size = MEM_RANGE_CHUNK_SZ;
uint64_t base, end, loc_base, loc_end;
size_t i, rngs_cnt, range;
int rlen = 0;
@@ -165,6 +166,11 @@ static void add_dyn_reconf_usable_mem_property(int fd)
die(unrecoverable error: error seeking in \%s\: %s\n,
pathname, strerror(errno));
+ ranges = malloc(ranges_size*8);
+ if (!ranges)
+ die(unrecoverable error: can't alloc %d bytes for ranges.\n,
+ ranges_size*8);
+
rlen = 0;
for (i = 0; i num_of_lmbs; i++) {
if (read(fd, buf, 24) 0)
@@ -180,24 +186,57 @@ static void add_dyn_reconf_usable_mem_property(int fd)
rngs_cnt = 0;
for (range = 0; range usablemem_rgns.size; range++) {
+ int add = 0;
loc_base = usablemem_rgns.ranges[range].start;
loc_end = usablemem_rgns.ranges[range].end;
if (loc_base = base loc_end = end) {
- ranges[rlen++] = loc_base;
- ranges[rlen++] = loc_end - loc_base;
- rngs_cnt++;
+ add = 1;
} else if (base loc_end end loc_base) {
if (loc_base base)
loc_base = base;
if (loc_end end)
loc_end = end;
+ add = 1;
+ }
+
+ if (add) {
+ if (rlen = (ranges_size-2)) {
+ ranges_size += MEM_RANGE_CHUNK_SZ;
+ ranges = realloc(ranges, ranges_size*8)
;
+ if (!ranges)
+ die(unrecoverable error: can't
+ realloc %d bytes for
+ ranges.\n,
+ ranges_size*8);
+ }
ranges[rlen++] = loc_base;
ranges[rlen++] = loc_end - loc_base;
rngs_cnt++;
}
}
- /* Store the count of (base, size) duple */
- ranges[tmp_indx] = rngs_cnt;
+ if (rngs_cnt == 0) {
+ /* We still need to add a counter for every LMB because
+ * the kernel parsing code is dumb. We just have
+ * a zero in this case, with no following base/len.
+ */
+ ranges[tmp_indx] = 0;
+ /* rlen is already just tmp_indx+1 as we didn't write
+ * anything. Check array size here, as we'll probably
+ * go on for a while writing zeros now.
+ */
+ if (rlen = (ranges_size-1)) {
+ ranges_size += MEM_RANGE_CHUNK_SZ;
+ ranges = realloc(ranges, ranges_size*8);
+ if (!ranges)
+ die(unrecoverable error:
Re: [PATCH] 85xx: Enable support for ports 3 and 4 on 8548 CDS
On Mar 29, 2010, at 8:39 PM, Andy Fleming wrote: I believe support was disabled due to issues with earlier versions of the board/processor. At worst, adding the ports back into the device tree should result in enabling ports that don't work on older systems, so the default should be to enable them. Signed-off-by: Andy Fleming aflem...@freescale.com --- arch/powerpc/boot/dts/mpc8548cds.dts |4 1 files changed, 0 insertions(+), 4 deletions(-) applied to next - k ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v5] powerpc: Add hibernation support for FSL BookE processors
On Mon, May 17, 2010 at 04:22:37PM -0500, Kumar Gala wrote: [...] arch/powerpc/kernel/Makefile |8 +- arch/powerpc/kernel/swsusp_booke.S | 193 2 files changed, 199 insertions(+), 2 deletions(-) create mode 100644 arch/powerpc/kernel/swsusp_booke.S Is there board specific code to go along with this? Nope. When I enable I get: arch/powerpc/kernel/built-in.o: In function `cpu_idle': /home/galak/git/master/powerpc/arch/powerpc/kernel/idle.c:98: undefined reference to `cpu_die' make: *** [.tmp_vmlinux1] Error 1 This isn't caused by hibernation or my patch specifically. Instead, it's a long standing issue, enabling CONFIG_SMP and CONFIG_SUSPEND is enough to trigger this. Patch exists: http://www.mail-archive.com/linuxppc-dev@lists.ozlabs.org/msg27982.html No idea why it didn't make Linus' tree. -- Anton Vorontsov email: cbouatmai...@gmail.com irc://irc.freenode.net/bd2 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
