[PATCH 1/2] powerpc: Remove ibm,smt-snooze-delay OF property

2010-05-17 Thread Anton Blanchard

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

2010-05-17 Thread Anton Blanchard

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

2010-05-17 Thread Anton Blanchard

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

2010-05-17 Thread Anton Blanchard

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

2010-05-17 Thread Anton Blanchard

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

2010-05-17 Thread Anton Blanchard

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.

2010-05-17 Thread Richard Cochran
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

2010-05-17 Thread Takuya Yoshikawa



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

2010-05-17 Thread Stefan Roese
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

2010-05-17 Thread Benjamin Herrenschmidt

  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

2010-05-17 Thread Mark Nelson
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

2010-05-17 Thread Paul Mackerras
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

2010-05-17 Thread Mark Nelson
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

2010-05-17 Thread nello martuscielli
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.

2010-05-17 Thread Wolfgang Grandegger
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.

2010-05-17 Thread Wolfgang Grandegger
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

2010-05-17 Thread Kumar Gala

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

2010-05-17 Thread Kumar Gala

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

2010-05-17 Thread Kumar Gala

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

2010-05-17 Thread Kumar Gala

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

2010-05-17 Thread Kumar Gala

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

2010-05-17 Thread Kumar Gala

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

2010-05-17 Thread Kumar Gala

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.

2010-05-17 Thread Scott Wood

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

2010-05-17 Thread Scott Wood

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

2010-05-17 Thread Kumar Gala

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.

2010-05-17 Thread Kumar Gala

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

2010-05-17 Thread Kumar Gala

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

2010-05-17 Thread Kumar Gala

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

2010-05-17 Thread Anton Vorontsov
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

2010-05-17 Thread Vaidyanathan Srinivasan
* 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?

2010-05-17 Thread Scott Wood
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)

2010-05-17 Thread Jeff Angielski

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

2010-05-17 Thread Kumar Gala

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

2010-05-17 Thread Kumar Gala

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

2010-05-17 Thread Michael Neuling


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

2010-05-17 Thread Kumar Gala

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

2010-05-17 Thread Anton Vorontsov
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