Re: [PATCH v4 23/32] cxlflash: Fix function prolog parameters and return codes

2015-09-28 Thread Andrew Donnellan

On 26/09/15 09:18, Matthew R. Ochs wrote:

Several function prologs have incorrect parameter names and return
code descriptions. This can lead to confusion when reviewing the
source and creates inaccurate documentation.

To remedy, update the function prologs to properly reflect parameter
names and return codes.

Signed-off-by: Matthew R. Ochs 
Signed-off-by: Manoj N. Kumar 
Reviewed-by: Brian King 


Reviewed-by: Andrew Donnellan 

See further comments below.


--- a/drivers/scsi/cxlflash/main.c
+++ b/drivers/scsi/cxlflash/main.c
@@ -401,8 +401,7 @@ static void wait_resp(struct afu *afu, struct afu_cmd *cmd)
   * @tmfcmd:   TMF command to send.
   *
   * Return:
- * 0 on success
- * SCSI_MLQUEUE_HOST_BUSY when host is busy
+ * 0 on success or SCSI_MLQUEUE_HOST_BUSY
   */
  static int send_tmf(struct afu *afu, struct scsi_cmnd *scp, u64 tmfcmd)
  {
@@ -491,9 +490,7 @@ static const char *cxlflash_driver_info(struct Scsi_Host 
*host)
   * @host: SCSI host associated with device.
   * @scp:  SCSI command to send.
   *
- * Return:
- * 0 on success
- * SCSI_MLQUEUE_HOST_BUSY when host is busy
+ * Return: 0 on success or SCSI_MLQUEUE_HOST_BUSY
   */


I'd prefer it to say "SCSI_MLQUEUE_HOST_BUSY on failure". (Aesthetically 
I prefer having it on a separate line, but that's just personal preference.)


As an aside, while checking the correctness of this, I found that the 
comment for cxlflash_send_cmd() states that it returns -1 on failure, 
when the only error value it actually returns is SCSI_MLQUEUE_HOST_BUSY. 
If you send a v5 you might want to fix this.



Andrew

--
Andrew Donnellan  Software Engineer, OzLabs
andrew.donnel...@au1.ibm.com  Australia Development Lab, Canberra
+61 2 6201 8874 (work)IBM Australia Limited

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH v4 12/32] cxlflash: Fix to avoid spamming the kernel log

2015-09-28 Thread Andrew Donnellan

On 26/09/15 09:15, Matthew R. Ochs wrote:

During run-time the driver can be very chatty and spam the system
kernel log. Various print statements can be limited and/or moved
to development-only mode. Additionally, numerous prints can be
converted to trace the corresponding device.

The following changes were made:
  - pr_debug to pr_devel
  - pr_debug to pr_debug_ratelimited
  - pr_err to dev_err
  - pr_debug to dev_dbg

Signed-off-by: Matthew R. Ochs 
Signed-off-by: Manoj N. Kumar 
Reviewed-by: Brian King 


Reviewed-by: Andrew Donnellan 

Changes mostly look fine, further comments below.


--- a/drivers/scsi/cxlflash/main.c
+++ b/drivers/scsi/cxlflash/main.c
@@ -58,8 +58,8 @@ static struct afu_cmd *cmd_checkout(struct afu *afu)
cmd = >cmd[k];

if (!atomic_dec_if_positive(>free)) {
-   pr_debug("%s: returning found index=%d\n",
-__func__, cmd->slot);
+   pr_devel("%s: returning found index=%d cmd=%p\n",
+__func__, cmd->slot, cmd);



pr_debug("%s: cmd failed afu_rc=%d scsi_rc=%d fc_rc=%d "
-"afu_extra=0x%X, scsi_entra=0x%X, fc_extra=0x%X\n",
+"afu_extra=0x%X, scsi_extra=0x%X, fc_extra=0x%X\n",
 __func__, ioasa->rc.afu_rc, ioasa->rc.scsi_rc,
 ioasa->rc.fc_rc, ioasa->afu_extra, ioasa->scsi_extra,
 ioasa->fc_extra);


Minor nitpicking: mention that you fix these in the commit message.


@@ -240,9 +240,9 @@ static void cmd_complete(struct afu_cmd *cmd)
cmd_is_tmf = cmd->cmd_tmf;
cmd_checkin(cmd); /* Don't use cmd after here */

-   pr_debug("%s: calling scsi_set_resid, scp=%p "
-"result=%X resid=%d\n", __func__,
-scp, scp->result, resid);
+   pr_debug_ratelimited("%s: calling scsi_done scp=%p result=%X "
+"ioasc=%d\n", __func__, scp, scp->result,
+cmd->sa.ioasc);

scsi_set_resid(scp, resid);
scsi_dma_unmap(scp);


Why has the message changed from scsi_set_resid to scsi_done, and should 
the message be moved to immediately before the scsi_done call?



Andrew

--
Andrew Donnellan  Software Engineer, OzLabs
andrew.donnel...@au1.ibm.com  Australia Development Lab, Canberra
+61 2 6201 8874 (work)IBM Australia Limited

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH v4 02/32] cxlflash: Replace magic numbers with literals

2015-09-28 Thread Andrew Donnellan

On 26/09/15 09:12, Matthew R. Ochs wrote:

From: Manoj Kumar 

Magic numbers are not meaningful and can create confusion. As a
remedy, replace them with descriptive literals.

Replace 512 with literal MAX_SECTOR_UNIT.
Replace 5 with literal CMD_RETRIES.

Signed-off-by: Matthew R. Ochs 
Signed-off-by: Manoj N. Kumar 
Reviewed-by: Brian King 


Reviewed-by: Andrew Donnellan 

--
Andrew Donnellan  Software Engineer, OzLabs
andrew.donnel...@au1.ibm.com  Australia Development Lab, Canberra
+61 2 6201 8874 (work)IBM Australia Limited

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH] perf record: Limit --intr-regs to platforms supporting PERF_REGS

2015-09-28 Thread Naveen N. Rao
On 2015/09/24 10:15PM, Naveen N Rao wrote:
> On 2015/09/24 08:32AM, Stephane Eranian wrote:
> > On Thu, Sep 24, 2015 at 5:57 AM, Jiri Olsa  wrote:
> > >
> > > On Thu, Sep 24, 2015 at 05:41:58PM +0530, Naveen N. Rao wrote:
> > > > perf build currently fails on powerpc:
> > > >
> > > >   LINK perf
> > > > libperf.a(libperf-in.o):(.toc+0x120): undefined reference to
> > > > `sample_reg_masks'
> > > > libperf.a(libperf-in.o):(.toc+0x130): undefined reference to
> > > > `sample_reg_masks'
> > > > collect2: error: ld returned 1 exit status
> > > > make[1]: *** [perf] Error 1
> > > > make: *** [all] Error 2
> > > >
> > > > This is due to parse-regs-options.c using sample_reg_masks, which is
> > > > defined only with CONFIG_PERF_REGS.
> > > >
> > > > In addition, perf record -I is only useful if the arch supports
> > > > PERF_REGS. Hence, let's expose -I conditionally.
> > > >
> > > > Signed-off-by: Naveen N. Rao 
> > >
> > > hum, I wonder why we have sample_reg_masks defined as weak in 
> > > util/perf_regs.c
> > > which is also built only via CONFIG_PERF_REGS
> > >
> > > I wonder we could get rid of the weak definition via attached patch, 
> > > Stephane?
> > >
> > But the whole point of having it weak is to avoid this error scenario
> > on any arch without support
> > and avoid ugly #ifdef HAVE_ in generic files.
> > 
> > if perf_regs.c is compiled on PPC, then why do we get the undefined?
> 
> As Jiri Olsa pointed out, powerpc and many other architectures don't 
> (yet) have support for perf regs.
> 
> But, the larger reason to introduce #ifdef is so the user doesn't see 
> options (s)he can't use on a specific architecture, along the same lines 
> as builtin-probe.c

Stephane, Arnaldo,
Suka has also posted a fix for this with a different approach [1]. Can 
you please ack/pull one of these versions? Building perf is broken on 
v4.3-rc due to this.

[1] http://article.gmane.org/gmane.linux.kernel/2046370

Thanks,
Naveen

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH v4 11/32] cxlflash: Refine host/device attributes

2015-09-28 Thread Andrew Donnellan

On 26/09/15 09:14, Matthew R. Ochs wrote:

Implement the following suggestions and add two new attributes
to allow for debugging the port LUN table.

  - use scnprintf() instead of snprintf()
  - use DEVICE_ATTR_RO and DEVICE_ATTR_RW

Suggested-by: Shane Seymour 
Signed-off-by: Matthew R. Ochs 
Signed-off-by: Manoj N. Kumar 
Reviewed-by: Brian King 


The commit message could explain the patch a bit better.


Andrew

--
Andrew Donnellan  Software Engineer, OzLabs
andrew.donnel...@au1.ibm.com  Australia Development Lab, Canberra
+61 2 6201 8874 (work)IBM Australia Limited

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH RFC 0/5] powerpc:numa Add serial nid support

2015-09-28 Thread Nishanth Aravamudan
On 28.09.2015 [13:44:42 +0300], Denis Kirjanov wrote:
> On 9/27/15, Raghavendra K T  wrote:
> > Problem description:
> > Powerpc has sparse node numbering, i.e. on a 4 node system nodes are
> > numbered (possibly) as 0,1,16,17. At a lower level, we map the chipid
> > got from device tree is naturally mapped (directly) to nid.
> 
> Interesting thing to play with, I'll try to test it on my POWER7 box,
> but it doesn't have the OPAL layer :(

Note that it's also interesting to try it under PowerVM, with odd NUMA
topologies and report any issues found :)


-Nish

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH RFC 2/5] powerpc:numa Rename functions referring to nid as chipid

2015-09-28 Thread Nishanth Aravamudan
On 27.09.2015 [23:59:10 +0530], Raghavendra K T wrote:
> There is no change in the fuctionality
> 
> Signed-off-by: Raghavendra K T 
> ---
>  arch/powerpc/mm/numa.c | 42 +-
>  1 file changed, 21 insertions(+), 21 deletions(-)
> 
> diff --git a/arch/powerpc/mm/numa.c b/arch/powerpc/mm/numa.c
> index d5e6eee..f84ed2f 100644
> --- a/arch/powerpc/mm/numa.c
> +++ b/arch/powerpc/mm/numa.c
> @@ -235,47 +235,47 @@ static void initialize_distance_lookup_table(int nid,
>   }
>  }
> 
> -/* Returns nid in the range [0..MAX_NUMNODES-1], or -1 if no useful numa
> +/* Returns chipid in the range [0..MAX_NUMNODES-1], or -1 if no useful numa
>   * info is found.
>   */
> -static int associativity_to_nid(const __be32 *associativity)
> +static int associativity_to_chipid(const __be32 *associativity)

This is confusing to me. This function is also used by the DLPAR code
under PowerVM to indicate what node the CPU is on -- not a chip (which I
don't believe is exposed at all under PowerVM).

>  {
> - int nid = -1;
> + int chipid = -1;
> 
>   if (min_common_depth == -1)
>   goto out;
> 
>   if (of_read_number(associativity, 1) >= min_common_depth)
> - nid = of_read_number([min_common_depth], 1);
> + chipid = of_read_number([min_common_depth], 1);

Doesn't this, in the PAPR documentation, specifically refer to the NODE
level domain?

>   /* POWER4 LPAR uses 0x as invalid node */
> - if (nid == 0x || nid >= MAX_NUMNODES)
> - nid = -1;
> + if (chipid == 0x || chipid >= MAX_NUMNODES)
> + chipid = -1;
> 
> - if (nid > 0 &&
> + if (chipid > 0 &&
>   of_read_number(associativity, 1) >= distance_ref_points_depth) {
>   /*
>* Skip the length field and send start of associativity array
>*/
> - initialize_distance_lookup_table(nid, associativity + 1);
> + initialize_distance_lookup_table(chipid, associativity + 1);
>   }
> 
>  out:
> - return nid;
> + return chipid;
>  }
> 
> -/* Returns the nid associated with the given device tree node,
> +/* Returns the chipid associated with the given device tree node,
>   * or -1 if not found.
>   */
> -static int of_node_to_nid_single(struct device_node *device)
> +static int of_node_to_chipid_single(struct device_node *device)
>  {
> - int nid = -1;
> + int chipid = -1;
>   const __be32 *tmp;
> 
>   tmp = of_get_associativity(device);
>   if (tmp)
> - nid = associativity_to_nid(tmp);
> - return nid;
> + chipid = associativity_to_chipid(tmp);
> + return chipid;
>  }
> 
>  /* Walk the device tree upwards, looking for an associativity id */
> @@ -286,7 +286,7 @@ int of_node_to_nid(struct device_node *device)
> 
>   of_node_get(device);
>   while (device) {
> - nid = of_node_to_nid_single(device);
> + nid = of_node_to_chipid_single(device);
>   if (nid != -1)
>   break;
> 
> @@ -498,7 +498,7 @@ static int of_get_assoc_arrays(struct device_node *memory,
>  }
> 
>  /*
> - * This is like of_node_to_nid_single() for memory represented in the
> + * This is like of_node_to_chipid_single() for memory represented in the
>   * ibm,dynamic-reconfiguration-memory node.
>   */
>  static int of_drconf_to_nid_single(struct of_drconf_cell *drmem,
> @@ -557,7 +557,7 @@ static int numa_setup_cpu(unsigned long lcpu)
>   goto out;
>   }
> 
> - nid = of_node_to_nid_single(cpu);
> + nid = of_node_to_chipid_single(cpu);
> 
>  out_present:
>   if (nid < 0 || !node_online(nid))
> @@ -754,7 +754,7 @@ static int __init parse_numa_properties(void)
> 
>   cpu = of_get_cpu_node(i, NULL);
>   BUG_ON(!cpu);
> - nid = of_node_to_nid_single(cpu);
> + nid = of_node_to_chipid_single(cpu);
>   of_node_put(cpu);
> 
>   /*
> @@ -796,7 +796,7 @@ new_range:
>* have associativity properties.  If none, then
>* everything goes to default_nid.
>*/
> - nid = of_node_to_nid_single(memory);
> + nid = of_node_to_chipid_single(memory);
>   if (nid < 0)
>   nid = default_nid;
> 
> @@ -1119,7 +1119,7 @@ static int hot_add_node_scn_to_nid(unsigned long 
> scn_addr)
>   if ((scn_addr < start) || (scn_addr >= (start + size)))
>   continue;
> 
> - nid = of_node_to_nid_single(memory);
> + nid = of_node_to_chipid_single(memory);
>   break;
>   }
> 
> @@ -1415,7 +1415,7 @@ int arch_update_cpu_topology(void)
> 
>   /* Use associativity from first thread for all siblings */
>   vphn_get_associativity(cpu, associativity);
> - 

Re: [PATCH RFC 4/5] powerpc:numa Add helper functions to maintain chipid to nid mapping

2015-09-28 Thread Nishanth Aravamudan
On 27.09.2015 [23:59:12 +0530], Raghavendra K T wrote:
> Create arrays that maps serial nids and sparse chipids.
> 
> Note: My original idea had only two arrays of chipid to nid map. Final
> code is inspired by driver/acpi/numa.c that maps a proximity node with
> a logical node by Takayoshi Kochi , and thus
> uses an additional chipid_map nodemask. The mask helps in first unused
> nid easily by knowing first unset bit in the mask.
> 
> No change in functionality.
> 
> Signed-off-by: Raghavendra K T 
> ---
>  arch/powerpc/mm/numa.c | 48 +++-
>  1 file changed, 47 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/powerpc/mm/numa.c b/arch/powerpc/mm/numa.c
> index dd2073b..f015cad 100644
> --- a/arch/powerpc/mm/numa.c
> +++ b/arch/powerpc/mm/numa.c
> @@ -63,6 +63,11 @@ static int form1_affinity;
>  static int distance_ref_points_depth;
>  static const __be32 *distance_ref_points;
>  static int distance_lookup_table[MAX_NUMNODES][MAX_DISTANCE_REF_POINTS];
> +static nodemask_t chipid_map = NODE_MASK_NONE;
> +static int chipid_to_nid_map[MAX_NUMNODES]
> + = { [0 ... MAX_NUMNODES - 1] = NUMA_NO_NODE };

Hrm, conceptually there are *more* chips than nodes, right? So what
guarantees we won't see > MAX_NUMNODES chips?

> +static int nid_to_chipid_map[MAX_NUMNODES]
> + = { [0 ... MAX_NUMNODES - 1] = NUMA_NO_NODE };
> 
>  /*
>   * Allocate node_to_cpumask_map based on number of available nodes
> @@ -133,6 +138,48 @@ static int __init fake_numa_create_new_node(unsigned 
> long end_pfn,
>   return 0;
>  }
> 
> +int chipid_to_nid(int chipid)
> +{
> + if (chipid < 0)
> + return NUMA_NO_NODE;

Do you really want to support these cases? Or should they be
bugs/warnings indicating that you got an unexpected input? Or at least
WARN_ON_ONCE?

> + return chipid_to_nid_map[chipid];
> +}
> +
> +int nid_to_chipid(int nid)
> +{
> + if (nid < 0)
> + return NUMA_NO_NODE;
> + return nid_to_chipid_map[nid];
> +}
> +
> +static void __map_chipid_to_nid(int chipid, int nid)
> +{
> + if (chipid_to_nid_map[chipid] == NUMA_NO_NODE
> +  || nid < chipid_to_nid_map[chipid])
> + chipid_to_nid_map[chipid] = nid;
> + if (nid_to_chipid_map[nid] == NUMA_NO_NODE
> + || chipid < nid_to_chipid_map[nid])
> + nid_to_chipid_map[nid] = chipid;
> +}

chip <-> node mapping is a static (physical) concept, right? Should we
emit some debugging if for some reason we get a runtime call to remap
an already mapped chip to a new node?

> +
> +int map_chipid_to_nid(int chipid)
> +{
> + int nid;
> +
> + if (chipid < 0 || chipid >= MAX_NUMNODES)
> + return NUMA_NO_NODE;
> +
> + nid = chipid_to_nid_map[chipid];
> + if (nid == NUMA_NO_NODE) {
> + if (nodes_weight(chipid_map) >= MAX_NUMNODES)
> + return NUMA_NO_NODE;

If you create a KVM guest with a bogus topology, doesn't this just start
losing NUMA information for very high-noded guests?

> + nid = first_unset_node(chipid_map);
> + __map_chipid_to_nid(chipid, nid);
> + node_set(nid, chipid_map);
> + }
> + return nid;
> +}
> +
>  int numa_cpu_lookup(int cpu)
>  {
>   return numa_cpu_lookup_table[cpu];
> @@ -264,7 +311,6 @@ out:
>   return chipid;
>  }
> 
> -

stray change?

>   /* Return the nid from associativity */
>  static int associativity_to_nid(const __be32 *associativity)
>  {
> -- 
> 1.7.11.7
> 

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH RFC 0/5] powerpc:numa Add serial nid support

2015-09-28 Thread Nishanth Aravamudan
On 27.09.2015 [23:59:08 +0530], Raghavendra K T wrote:
> Problem description:
> Powerpc has sparse node numbering, i.e. on a 4 node system nodes are
> numbered (possibly) as 0,1,16,17. At a lower level, we map the chipid
> got from device tree is naturally mapped (directly) to nid.

chipid is a OPAL concept, I believe, and not documented in PAPR... How
does this work under PowerVM?

> Potential side effect of that is:
> 
> 1) There are several places in kernel that assumes serial node numbering.
> and memory allocations assume that all the nodes from 0-(highest nid)
> exist inturn ending up allocating memory for the nodes that does not exist.
> 
> 2) For virtualization use cases (such as qemu, libvirt, openstack), mapping
> sparse nid of the host system to contiguous nids of guest (numa affinity,
> placement) could be a challenge.
> 
> Possible Solutions:
> 1) Handling the memory allocations is kernel case by case: Though in some
> cases it is easy to achieve, some cases may be intrusive/not trivial. 
> at the end it does not handle side effect (2) above.
> 
> 2) Map the sparse chipid got from device tree to a serial nid at kernel
> level (The idea proposed in this series).
> Pro: It is more natural to handle at kernel level than at lower (OPAL) layer.
> con: The chipid is in device tree no longer the same as nid in kernel

Is there any debugging/logging? Looks like not -- so how does a sysadmin
map from firmware-provided values to the Linux values? That's going to
make debugging of large systems (PowerVM or otherwise) less than
pleasant, it seems? Possibly you could put something in sysfs?

-Nish

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH 00/31] powerpc/mm: Update page table format for book3s 64

2015-09-28 Thread Scott Wood
On Mon, 2015-09-28 at 10:26 +0530, Aneesh Kumar K.V wrote:
> Scott Wood  writes:
> 
> > On Tue, 2015-09-22 at 12:18 +0530, Aneesh Kumar K.V wrote:
> > > Scott Wood  writes:
> > > 
> > > > On Mon, 2015-09-21 at 12:10 +0530, Aneesh Kumar K.V wrote:
> > > > > Hi All,
> > > > > 
> > > > > This patch series attempt to update book3s 64 linux page table 
> > > > > format to
> > > > > make it more flexible. Our current pte format is very restrictive 
> > > > > and we
> > > > > overload multiple pte bits. This is due to the non-availability of 
> > > > > free 
> > > > > bits
> > > > > in pte_t. We use pte_t to track the validity of 4K subpages. This 
> > > > > patch
> > > > > series free up pte_t of 11 bits by moving 4K subpage tracking to the
> > > > > lower half of PTE page. The pte format is updated such that we have 
> > > > > a
> > > > > better method for identifying a pte entry at pmd level. This will 
> > > > > also 
> > > > > enable
> > > > > us to implement hugetlb migration(not yet done in this series). 
> > > > > 
> > > > > Before making the changes to the pte format, I am splitting the
> > > > > pte header definition such that we now have the below layout for 
> > > > > headers
> > > > > 
> > > > > book3s
> > > > >32
> > > > >  hash.h pgtable.h 
> > > > >64
> > > > >  hash.h  pgtable.h hash-4k.h hash-64k.h
> > > > > booke
> > > > >   32
> > > > >  pgtable.h pte-40x.h pte-44x.h pte-8xx.h pte-fsl-booke.h
> > > > >   64
> > > > > pgtable-4k.h  pgtable-64k.h  pgtable.h
> > > > 
> > > > 40x and 8xx are not booke.  Is there a better name that can be used 
> > > > for 
> > > > this 
> > > > directory?  Maybe "nohash", similar to arch/powerpc/mm/tlb_nohash.c?
> > > > 
> > > 
> > > I looked at Documentation/powerpc/cpu_families.txt to name the headers.
> > > It lists then below booke.
> > 
> > It lists 40x as booke (there was some question about that when 
> > cpu_families.txt was added...  I guess you could call it "proto-booke", 
> > though it doesn't use CONFIG_BOOKE in Linux), but 8xx is in its own 
> > category.
> > 
> > In any case, "nohash" is the term used elsewhere.
> 
> How about using swtlb ? (nohash always confused me, It would be nice to
> be explict and us software tlb ?)

I'd prefer nohash.  Besides being existing practice (what's confusing about 
it?), e6500 is nohash but has a partial hw tlb, and 603 is considered hash 
despite having a software-loaded tlb.

-Scott

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH RFC 3/5] powerpc:numa create 1:1 mappaing between chipid and nid

2015-09-28 Thread Nishanth Aravamudan
On 27.09.2015 [23:59:11 +0530], Raghavendra K T wrote:
> Once we have made the distinction between nid and chipid
> create a 1:1 mapping between them. This makes compacting the
> nids easy later.
> 
> No functionality change.
> 
> Signed-off-by: Raghavendra K T 
> ---
>  arch/powerpc/mm/numa.c | 36 +---
>  1 file changed, 29 insertions(+), 7 deletions(-)
> 
> diff --git a/arch/powerpc/mm/numa.c b/arch/powerpc/mm/numa.c
> index f84ed2f..dd2073b 100644
> --- a/arch/powerpc/mm/numa.c
> +++ b/arch/powerpc/mm/numa.c
> @@ -264,6 +264,17 @@ out:
>   return chipid;
>  }
> 
> +
> + /* Return the nid from associativity */
> +static int associativity_to_nid(const __be32 *associativity)
> +{
> + int nid;
> +
> + nid = associativity_to_chipid(associativity);
> + return nid;
> +}

This is ultimately confusing. You are assigning the semantic return
value of a chipid to a nid -- is it a nid or a chipid? Shouldn't the
variable naming be consistent?

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH RFC 3/5] powerpc:numa create 1:1 mappaing between chipid and nid

2015-09-28 Thread Nishanth Aravamudan
On 27.09.2015 [23:59:11 +0530], Raghavendra K T wrote:
> Once we have made the distinction between nid and chipid
> create a 1:1 mapping between them. This makes compacting the
> nids easy later.


Didn't the previous patch just do the opposite of...

> @@ -286,7 +308,7 @@ int of_node_to_nid(struct device_node *device)
> 
>   of_node_get(device);
>   while (device) {
> - nid = of_node_to_chipid_single(device);
> + nid = of_node_to_nid_single(device);
>   if (nid != -1)
>   break;
> 
> @@ -498,7 +520,7 @@ static int of_get_assoc_arrays(struct device_node *memory,
>  }
> 
>  /*
> - * This is like of_node_to_chipid_single() for memory represented in the
> + * This is like of_node_to_nid_single() for memory represented in the
>   * ibm,dynamic-reconfiguration-memory node.
>   */
>  static int of_drconf_to_nid_single(struct of_drconf_cell *drmem,
> @@ -557,7 +579,7 @@ static int numa_setup_cpu(unsigned long lcpu)
>   goto out;
>   }
> 
> - nid = of_node_to_chipid_single(cpu);
> + nid = of_node_to_nid_single(cpu);
> 
>  out_present:
>   if (nid < 0 || !node_online(nid))
> @@ -754,7 +776,7 @@ static int __init parse_numa_properties(void)
> 
>   cpu = of_get_cpu_node(i, NULL);
>   BUG_ON(!cpu);
> - nid = of_node_to_chipid_single(cpu);
> + nid = of_node_to_nid_single(cpu);
>   of_node_put(cpu);
> 
>   /*
> @@ -796,7 +818,7 @@ new_range:
>* have associativity properties.  If none, then
>* everything goes to default_nid.
>*/
> - nid = of_node_to_chipid_single(memory);
> + nid = of_node_to_nid_single(memory);
>   if (nid < 0)
>   nid = default_nid;
> 
> @@ -1119,7 +1141,7 @@ static int hot_add_node_scn_to_nid(unsigned long 
> scn_addr)
>   if ((scn_addr < start) || (scn_addr >= (start + size)))
>   continue;
> 
> - nid = of_node_to_chipid_single(memory);
> + nid = of_node_to_nid_single(memory);
>   break;
>   }
> 
> @@ -1415,7 +1437,7 @@ int arch_update_cpu_topology(void)
> 
>   /* Use associativity from first thread for all siblings */
>   vphn_get_associativity(cpu, associativity);
> - new_nid = associativity_to_chipid(associativity);
> + new_nid = associativity_to_nid(associativity);
>   if (new_nid < 0 || !node_online(new_nid))
>   new_nid = first_online_node;
> 

Why is this churn useful?

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH v8 1/4] perf, kvm/{x86, s390}: Remove dependency on uapi/kvm_perf.h

2015-09-28 Thread Alexander Yarygin
Hemant Kumar  writes:

> Its better to remove the dependency on uapi/kvm_perf.h to allow dynamic
> discovery of kvm events (if its needed). To do this, some extern
> variables have been introduced with which we can keep the generic
> functions generic.
>
> Signed-off-by: Hemant Kumar 
> ---
> Changes since v7:
> - Removed __maybe_unused for some parameters which weren't needed.
>
>  tools/perf/arch/s390/util/kvm-stat.c | 10 -
>  tools/perf/arch/x86/util/kvm-stat.c  | 12 ++-
>  tools/perf/builtin-kvm.c | 39 
> +++-
>  tools/perf/util/kvm-stat.h   |  3 +++
>  4 files changed, 48 insertions(+), 16 deletions(-)

Hello,


The patchset doesn't break s390 code (and at least build on x86), but I
don't really like some things here (e.g. direct access to
kvm_events_tp), see below.

Thanks.

CC: David Ahern 

>
> diff --git a/tools/perf/arch/s390/util/kvm-stat.c 
> b/tools/perf/arch/s390/util/kvm-stat.c
> index a5dbc07..c2acb3e 100644
> --- a/tools/perf/arch/s390/util/kvm-stat.c
> +++ b/tools/perf/arch/s390/util/kvm-stat.c
> @@ -10,7 +10,11 @@
>   */
>
>  #include "../../util/kvm-stat.h"
> -#include 
> +#include 
> +
> +#define DECODE_STR_LEN 40
> +#define VCPU_ID "id"
> +#define KVM_EXIT_REASON "icptcode"
>

I would probably drop them. There are no users besides newly
introduced const char *vcpu_id_str and decore_str_len etc anyway.

>  define_exit_reasons_table(sie_exit_reasons, sie_intercept_code);
>  define_exit_reasons_table(sie_icpt_insn_codes, icpt_insn_codes);
> @@ -83,6 +87,10 @@ const char * const kvm_events_tp[] = {
>   NULL,
>  };
>
> +const char *vcpu_id_str = VCPU_ID;
> +const int decode_str_len = DECODE_STR_LEN;
> +const char *exit_reason_code = KVM_EXIT_REASON;
> +
>  struct kvm_reg_events_ops kvm_reg_events_ops[] = {
>   { .name = "vmexit", .ops = _events },
>   { NULL, NULL },
> diff --git a/tools/perf/arch/x86/util/kvm-stat.c 
> b/tools/perf/arch/x86/util/kvm-stat.c
> index 14e4e66..2d0d43b5 100644
> --- a/tools/perf/arch/x86/util/kvm-stat.c
> +++ b/tools/perf/arch/x86/util/kvm-stat.c
> @@ -1,5 +1,11 @@
>  #include "../../util/kvm-stat.h"
> -#include 
> +#include 
> +#include 
> +#include 
> +
> +#define DECODE_STR_LEN 20
> +#define VCPU_ID "vcpu_id"
> +#define KVM_EXIT_REASON "exit_reason"
>
>  define_exit_reasons_table(vmx_exit_reasons, VMX_EXIT_REASONS);
>  define_exit_reasons_table(svm_exit_reasons, SVM_EXIT_REASONS);
> @@ -129,6 +135,10 @@ const char * const kvm_events_tp[] = {
>   NULL,
>  };
>
> +const char *vcpu_id_str = VCPU_ID;
> +const int decode_str_len = DECODE_STR_LEN;
> +const char *exit_reason_code = KVM_EXIT_REASON;
> +
>  struct kvm_reg_events_ops kvm_reg_events_ops[] = {
>   { .name = "vmexit", .ops = _events },
>   { .name = "mmio", .ops = _events },
> diff --git a/tools/perf/builtin-kvm.c b/tools/perf/builtin-kvm.c
> index fc1cffb..ef25fcf 100644
> --- a/tools/perf/builtin-kvm.c
> +++ b/tools/perf/builtin-kvm.c
> @@ -31,20 +31,18 @@
>  #include 
>
>  #ifdef HAVE_KVM_STAT_SUPPORT
> -#include 
>  #include "util/kvm-stat.h"
>
> -void exit_event_get_key(struct perf_evsel *evsel,
> - struct perf_sample *sample,
> +void exit_event_get_key(struct perf_evsel *evsel, struct perf_sample *sample,
>   struct event_key *key)
>  {
>   key->info = 0;
> - key->key = perf_evsel__intval(evsel, sample, KVM_EXIT_REASON);
> + key->key = perf_evsel__intval(evsel, sample, exit_reason_code);
>  }
>
>  bool kvm_exit_event(struct perf_evsel *evsel)
>  {
> - return !strcmp(evsel->name, KVM_EXIT_TRACE);
> + return !strncmp(evsel->name, kvm_events_tp[1], strlen(evsel->name));
>  }

Hmm, direct access to kvm_events_tp? Maybe add a getter for this or
something like extern char *kvm_exit_trace;?
/* why strncmp? */

>
>  bool exit_event_begin(struct perf_evsel *evsel,
> @@ -60,7 +58,7 @@ bool exit_event_begin(struct perf_evsel *evsel,
>
>  bool kvm_entry_event(struct perf_evsel *evsel)
>  {
> - return !strcmp(evsel->name, KVM_ENTRY_TRACE);
> + return !strncmp(evsel->name, kvm_events_tp[0], strlen(evsel->name));
>  }
>
>  bool exit_event_end(struct perf_evsel *evsel,
> @@ -71,8 +69,8 @@ bool exit_event_end(struct perf_evsel *evsel,
>  }
>
>  static const char *get_exit_reason(struct perf_kvm_stat *kvm,
> -struct exit_reasons_table *tbl,
> -u64 exit_code)
> + struct exit_reasons_table *tbl,
> + u64 exit_code)
>  {
>   while (tbl->reason != NULL) {
>   if (tbl->exit_code == exit_code)
> @@ -92,7 +90,7 @@ void exit_event_decode_key(struct perf_kvm_stat *kvm,
>   const char *exit_reason = get_exit_reason(kvm, key->exit_reasons,
> key->key);
>
> - scnprintf(decode, DECODE_STR_LEN, "%s", exit_reason);
> + 

Re: [PATCH v8 1/4] perf,kvm/{x86,s390}: Remove dependency on uapi/kvm_perf.h

2015-09-28 Thread David Ahern

On 9/28/15 7:00 AM, Alexander Yarygin wrote:

diff --git a/tools/perf/builtin-kvm.c b/tools/perf/builtin-kvm.c
index fc1cffb..ef25fcf 100644
--- a/tools/perf/builtin-kvm.c
+++ b/tools/perf/builtin-kvm.c
@@ -31,20 +31,18 @@
  #include 

  #ifdef HAVE_KVM_STAT_SUPPORT
-#include 
  #include "util/kvm-stat.h"

-void exit_event_get_key(struct perf_evsel *evsel,
-   struct perf_sample *sample,
+void exit_event_get_key(struct perf_evsel *evsel, struct perf_sample *sample,
struct event_key *key)
  {
key->info = 0;
-   key->key = perf_evsel__intval(evsel, sample, KVM_EXIT_REASON);
+   key->key = perf_evsel__intval(evsel, sample, exit_reason_code);
  }

  bool kvm_exit_event(struct perf_evsel *evsel)
  {
-   return !strcmp(evsel->name, KVM_EXIT_TRACE);
+   return !strncmp(evsel->name, kvm_events_tp[1], strlen(evsel->name));
  }


Hmm, direct access to kvm_events_tp? Maybe add a getter for this or
something like extern char *kvm_exit_trace;?
/* why strncmp? */



  bool exit_event_begin(struct perf_evsel *evsel,
@@ -60,7 +58,7 @@ bool exit_event_begin(struct perf_evsel *evsel,

  bool kvm_entry_event(struct perf_evsel *evsel)
  {
-   return !strcmp(evsel->name, KVM_ENTRY_TRACE);
+   return !strncmp(evsel->name, kvm_events_tp[0], strlen(evsel->name));
  }

  bool exit_event_end(struct perf_evsel *evsel,


I agree; don't rely on kvm_events_tp. Define KVM_ENTRY_TRACE and 
KVM_EXIT_TRACE like x86.


___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH v8 1/4] perf,kvm/{x86,s390}: Remove dependency on uapi/kvm_perf.h

2015-09-28 Thread David Ahern

On 9/28/15 9:16 AM, Scott Wood wrote:

On Mon, 2015-09-28 at 08:31 -0600, David Ahern wrote:

On 9/28/15 7:00 AM, Alexander Yarygin wrote:

diff --git a/tools/perf/builtin-kvm.c b/tools/perf/builtin-kvm.c
index fc1cffb..ef25fcf 100644
--- a/tools/perf/builtin-kvm.c
+++ b/tools/perf/builtin-kvm.c
@@ -31,20 +31,18 @@
   #include 

   #ifdef HAVE_KVM_STAT_SUPPORT
-#include 
   #include "util/kvm-stat.h"

-void exit_event_get_key(struct perf_evsel *evsel,
- struct perf_sample *sample,
+void exit_event_get_key(struct perf_evsel *evsel, struct perf_sample
*sample,
   struct event_key *key)
   {
   key->info = 0;
- key->key = perf_evsel__intval(evsel, sample, KVM_EXIT_REASON);
+ key->key = perf_evsel__intval(evsel, sample, exit_reason_code);
   }

   bool kvm_exit_event(struct perf_evsel *evsel)
   {
- return !strcmp(evsel->name, KVM_EXIT_TRACE);
+ return !strncmp(evsel->name, kvm_events_tp[1], strlen(evsel->name));
   }


Hmm, direct access to kvm_events_tp? Maybe add a getter for this or
something like extern char *kvm_exit_trace;?
/* why strncmp? */



   bool exit_event_begin(struct perf_evsel *evsel,
@@ -60,7 +58,7 @@ bool exit_event_begin(struct perf_evsel *evsel,

   bool kvm_entry_event(struct perf_evsel *evsel)
   {
- return !strcmp(evsel->name, KVM_ENTRY_TRACE);
+ return !strncmp(evsel->name, kvm_events_tp[0], strlen(evsel->name));
   }

   bool exit_event_end(struct perf_evsel *evsel,


I agree; don't rely on kvm_events_tp. Define KVM_ENTRY_TRACE and
KVM_EXIT_TRACE like x86.


If you mean defining them in uapi, that doesn't work for arches that have
multiple subarches that may have different trace events.  This patchset
doesn't actually implement dynamic support for the subarches, but it avoids
adding constants to uapi headers that only apply to one of the subarches.


I don't agree on relying on kvm_events_tp[0] and [1]. If you need that 
to be a runtime definition then change KVM_ENTRY_TRACE to const char 
*kvm_entry_trace and s390 and other arches can have code to set 
kvm_{entry,exit}_trace at runtime.


David
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH v8 1/4] perf,kvm/{x86,s390}: Remove dependency on uapi/kvm_perf.h

2015-09-28 Thread Scott Wood
On Mon, 2015-09-28 at 08:31 -0600, David Ahern wrote:
> On 9/28/15 7:00 AM, Alexander Yarygin wrote:
> > > diff --git a/tools/perf/builtin-kvm.c b/tools/perf/builtin-kvm.c
> > > index fc1cffb..ef25fcf 100644
> > > --- a/tools/perf/builtin-kvm.c
> > > +++ b/tools/perf/builtin-kvm.c
> > > @@ -31,20 +31,18 @@
> > >   #include 
> > > 
> > >   #ifdef HAVE_KVM_STAT_SUPPORT
> > > -#include 
> > >   #include "util/kvm-stat.h"
> > > 
> > > -void exit_event_get_key(struct perf_evsel *evsel,
> > > - struct perf_sample *sample,
> > > +void exit_event_get_key(struct perf_evsel *evsel, struct perf_sample 
> > > *sample,
> > >   struct event_key *key)
> > >   {
> > >   key->info = 0;
> > > - key->key = perf_evsel__intval(evsel, sample, KVM_EXIT_REASON);
> > > + key->key = perf_evsel__intval(evsel, sample, exit_reason_code);
> > >   }
> > > 
> > >   bool kvm_exit_event(struct perf_evsel *evsel)
> > >   {
> > > - return !strcmp(evsel->name, KVM_EXIT_TRACE);
> > > + return !strncmp(evsel->name, kvm_events_tp[1], strlen(evsel->name));
> > >   }
> > 
> > Hmm, direct access to kvm_events_tp? Maybe add a getter for this or
> > something like extern char *kvm_exit_trace;?
> > /* why strncmp? */
> > 
> > > 
> > >   bool exit_event_begin(struct perf_evsel *evsel,
> > > @@ -60,7 +58,7 @@ bool exit_event_begin(struct perf_evsel *evsel,
> > > 
> > >   bool kvm_entry_event(struct perf_evsel *evsel)
> > >   {
> > > - return !strcmp(evsel->name, KVM_ENTRY_TRACE);
> > > + return !strncmp(evsel->name, kvm_events_tp[0], strlen(evsel->name));
> > >   }
> > > 
> > >   bool exit_event_end(struct perf_evsel *evsel,
> 
> I agree; don't rely on kvm_events_tp. Define KVM_ENTRY_TRACE and 
> KVM_EXIT_TRACE like x86.

If you mean defining them in uapi, that doesn't work for arches that have 
multiple subarches that may have different trace events.  This patchset 
doesn't actually implement dynamic support for the subarches, but it avoids 
adding constants to uapi headers that only apply to one of the subarches.

-Scott


___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH v7 1/4] perf,kvm/{x86,s390}: Remove dependency on uapi/kvm_perf.h

2015-09-28 Thread Christian Borntraeger
Am 24.09.2015 um 21:02 schrieb Hemant Kumar:
> Its better to remove the dependency on uapi/kvm_perf.h to allow dynamic
> discovery of kvm events (if its needed). To do this, some extern
> variables have been introduced with which we can keep the generic
> functions generic.
> 
> Signed-off-by: Hemant Kumar 

When touching s390, can you CC the s390 maintainers? We are not powerpc :-)
Alexander, can you have a look at this series?


> ---
>  tools/perf/arch/s390/util/kvm-stat.c | 10 +++-
>  tools/perf/arch/x86/util/kvm-stat.c  | 12 +-
>  tools/perf/builtin-kvm.c | 44 
> ++--
>  tools/perf/util/kvm-stat.h   |  3 +++
>  4 files changed, 50 insertions(+), 19 deletions(-)
> 
> diff --git a/tools/perf/arch/s390/util/kvm-stat.c 
> b/tools/perf/arch/s390/util/kvm-stat.c
> index a5dbc07..c2acb3e 100644
> --- a/tools/perf/arch/s390/util/kvm-stat.c
> +++ b/tools/perf/arch/s390/util/kvm-stat.c
> @@ -10,7 +10,11 @@
>   */
> 
>  #include "../../util/kvm-stat.h"
> -#include 
> +#include 
> +
> +#define DECODE_STR_LEN 40
> +#define VCPU_ID "id"
> +#define KVM_EXIT_REASON "icptcode"
> 
>  define_exit_reasons_table(sie_exit_reasons, sie_intercept_code);
>  define_exit_reasons_table(sie_icpt_insn_codes, icpt_insn_codes);
> @@ -83,6 +87,10 @@ const char * const kvm_events_tp[] = {
>   NULL,
>  };
> 
> +const char *vcpu_id_str = VCPU_ID;
> +const int decode_str_len = DECODE_STR_LEN;
> +const char *exit_reason_code = KVM_EXIT_REASON;
> +
>  struct kvm_reg_events_ops kvm_reg_events_ops[] = {
>   { .name = "vmexit", .ops = _events },
>   { NULL, NULL },
> diff --git a/tools/perf/arch/x86/util/kvm-stat.c 
> b/tools/perf/arch/x86/util/kvm-stat.c
> index 14e4e66..2d0d43b5 100644
> --- a/tools/perf/arch/x86/util/kvm-stat.c
> +++ b/tools/perf/arch/x86/util/kvm-stat.c
> @@ -1,5 +1,11 @@
>  #include "../../util/kvm-stat.h"
> -#include 
> +#include 
> +#include 
> +#include 
> +
> +#define DECODE_STR_LEN 20
> +#define VCPU_ID "vcpu_id"
> +#define KVM_EXIT_REASON "exit_reason"
> 
>  define_exit_reasons_table(vmx_exit_reasons, VMX_EXIT_REASONS);
>  define_exit_reasons_table(svm_exit_reasons, SVM_EXIT_REASONS);
> @@ -129,6 +135,10 @@ const char * const kvm_events_tp[] = {
>   NULL,
>  };
> 
> +const char *vcpu_id_str = VCPU_ID;
> +const int decode_str_len = DECODE_STR_LEN;
> +const char *exit_reason_code = KVM_EXIT_REASON;
> +
>  struct kvm_reg_events_ops kvm_reg_events_ops[] = {
>   { .name = "vmexit", .ops = _events },
>   { .name = "mmio", .ops = _events },
> diff --git a/tools/perf/builtin-kvm.c b/tools/perf/builtin-kvm.c
> index fc1cffb..dbb1b1e 100644
> --- a/tools/perf/builtin-kvm.c
> +++ b/tools/perf/builtin-kvm.c
> @@ -31,20 +31,19 @@
>  #include 
> 
>  #ifdef HAVE_KVM_STAT_SUPPORT
> -#include 
>  #include "util/kvm-stat.h"
> 
> -void exit_event_get_key(struct perf_evsel *evsel,
> - struct perf_sample *sample,
> - struct event_key *key)
> +void exit_event_get_key(struct perf_evsel *evsel __maybe_unused,
> +struct perf_sample *sample __maybe_unused,
> +struct event_key *key __maybe_unused)
>  {
>   key->info = 0;
> - key->key = perf_evsel__intval(evsel, sample, KVM_EXIT_REASON);
> + key->key = perf_evsel__intval(evsel, sample, exit_reason_code);
>  }
> 
> -bool kvm_exit_event(struct perf_evsel *evsel)
> +bool kvm_exit_event(struct perf_evsel *evsel __maybe_unused)
>  {
> - return !strcmp(evsel->name, KVM_EXIT_TRACE);
> + return !strncmp(evsel->name, kvm_events_tp[1], strlen(evsel->name));
>  }
> 
>  bool exit_event_begin(struct perf_evsel *evsel,
> @@ -58,9 +57,9 @@ bool exit_event_begin(struct perf_evsel *evsel,
>   return false;
>  }
> 
> -bool kvm_entry_event(struct perf_evsel *evsel)
> +bool kvm_entry_event(struct perf_evsel *evsel __maybe_unused)
>  {
> - return !strcmp(evsel->name, KVM_ENTRY_TRACE);
> + return !strncmp(evsel->name, kvm_events_tp[0], strlen(evsel->name));
>  }
> 
>  bool exit_event_end(struct perf_evsel *evsel,
> @@ -71,8 +70,8 @@ bool exit_event_end(struct perf_evsel *evsel,
>  }
> 
>  static const char *get_exit_reason(struct perf_kvm_stat *kvm,
> -struct exit_reasons_table *tbl,
> -u64 exit_code)
> + struct exit_reasons_table *tbl,
> + u64 exit_code)
>  {
>   while (tbl->reason != NULL) {
>   if (tbl->exit_code == exit_code)
> @@ -92,7 +91,7 @@ void exit_event_decode_key(struct perf_kvm_stat *kvm,
>   const char *exit_reason = get_exit_reason(kvm, key->exit_reasons,
> key->key);
> 
> - scnprintf(decode, DECODE_STR_LEN, "%s", exit_reason);
> + scnprintf(decode, decode_str_len, "%s", exit_reason);
>  }
> 
>  static bool register_kvm_events_ops(struct perf_kvm_stat *kvm)
> @@ -358,7 +357,11 @@ 

Re: [PATCH v2 1/2] powerpc/selftest: Add gettimeofday() benchmark

2015-09-28 Thread Denis Kirjanov
On 9/28/15, Michael Neuling  wrote:
> On Fri, 2015-09-25 at 11:37 +0200, Gabriel Paubert wrote:
>> On Fri, Sep 25, 2015 at 12:28:30PM +0300, Denis Kirjanov wrote:
>> > On 9/25/15, Arnd Bergmann  wrote:
>> > > On Friday 25 September 2015 14:01:39 Michael Neuling wrote:
>> > >> This adds a benchmark directory to the powerpc selftests and adds a
>> > >> gettimeofday() benchmark to it.
>> > >>
>> > >> Suggested-by: Michael Ellerman 
>> > >> Signed-off-by: Michael Neuling 
>> > >>
>> > >
>> > > Any reason for keeping this powerpc specific? It seems generally
>> > > useful.
>> > > and portable.
>> > You're right. Moreover, we can put some comment to the benchmark why
>> > we've made such decision to add it (reference to the commit
>> > "powerpc/vdso: Avoid link stack corruption in __get_datapage()")
>>
>> Why gettimeofday? Isn't clock_gettime the modern variant?
>
> We can do either here really.  I just wanted to test __get_datapage()
> really.  I just stole the benchmark from Anton, which turned into mpe
> wanting it in selftests.  I dumped it in powerpc mostly because I knew
> mpe would take it (ie. I'm was being lazy).

Yeah, so the quickest way would be to apply the patch as is. Then
someone can make it generic.
So now it depends on Michael's decision :)
>
>> BTW: dows anyone receive 2 copies of every messge in this thread ?
>
> I'm not.
>
> Mikey
>
>>
>> I do, and I suspect that this is due to the Cc: list having both
>> linuxppc-...@ozlabs.org and linuxppc-dev@lists.ozlabs.org. I removed the
>> former for this reply.
>>
>> Gabriel
>
>
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH v2 1/2] powerpc/selftest: Add gettimeofday() benchmark

2015-09-28 Thread Michael Neuling
On Fri, 2015-09-25 at 11:37 +0200, Gabriel Paubert wrote:
> On Fri, Sep 25, 2015 at 12:28:30PM +0300, Denis Kirjanov wrote:
> > On 9/25/15, Arnd Bergmann  wrote:
> > > On Friday 25 September 2015 14:01:39 Michael Neuling wrote:
> > >> This adds a benchmark directory to the powerpc selftests and adds a
> > >> gettimeofday() benchmark to it.
> > >>
> > >> Suggested-by: Michael Ellerman 
> > >> Signed-off-by: Michael Neuling 
> > >>
> > >
> > > Any reason for keeping this powerpc specific? It seems generally useful.
> > > and portable.
> > You're right. Moreover, we can put some comment to the benchmark why
> > we've made such decision to add it (reference to the commit
> > "powerpc/vdso: Avoid link stack corruption in __get_datapage()")
> 
> Why gettimeofday? Isn't clock_gettime the modern variant?

We can do either here really.  I just wanted to test __get_datapage()
really.  I just stole the benchmark from Anton, which turned into mpe
wanting it in selftests.  I dumped it in powerpc mostly because I knew
mpe would take it (ie. I'm was being lazy).

> BTW: dows anyone receive 2 copies of every messge in this thread ?

I'm not.

Mikey

> 
> I do, and I suspect that this is due to the Cc: list having both
> linuxppc-...@ozlabs.org and linuxppc-dev@lists.ozlabs.org. I removed the
> former for this reply.
> 
> Gabriel

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH RFC 0/5] powerpc:numa Add serial nid support

2015-09-28 Thread Denis Kirjanov
On 9/27/15, Raghavendra K T  wrote:
> Problem description:
> Powerpc has sparse node numbering, i.e. on a 4 node system nodes are
> numbered (possibly) as 0,1,16,17. At a lower level, we map the chipid
> got from device tree is naturally mapped (directly) to nid.

Interesting thing to play with, I'll try to test it on my POWER7 box,
but it doesn't have the OPAL layer :(

>
> Potential side effect of that is:
>
> 1) There are several places in kernel that assumes serial node numbering.
> and memory allocations assume that all the nodes from 0-(highest nid)
> exist inturn ending up allocating memory for the nodes that does not exist.
>
> 2) For virtualization use cases (such as qemu, libvirt, openstack), mapping
> sparse nid of the host system to contiguous nids of guest (numa affinity,
> placement) could be a challenge.
>
> Possible Solutions:
> 1) Handling the memory allocations is kernel case by case: Though in some
> cases it is easy to achieve, some cases may be intrusive/not trivial.
> at the end it does not handle side effect (2) above.
>
> 2) Map the sparse chipid got from device tree to a serial nid at kernel
> level (The idea proposed in this series).
> Pro: It is more natural to handle at kernel level than at lower (OPAL)
> layer.
> con: The chipid is in device tree no longer the same as nid in kernel
>
> 3) Let the lower layer (OPAL) give the serial node ids after parsing the
> chipid and the associativity etc [ either as a separate item in device tree
> or by compacting the chipid numbers ]
> Pros: kernel, device tree are on same page and less change in kernel
> Con: is it the functionality expected in lower layer
>
> As mentioned above, current patch series tries to map chipid from lower
> layer
> to a contiguos nid at kernel level keeping the node distance calculation and
> so on intact.
>
> Result:
> Before the patch: numactl -H
>
> available: 4 nodes (0-1,16-17)
> node 0 cpus: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23
> 24 25 26 27 28 29 30 31
> node 0 size: 31665 MB
> node 0 free: 29836 MB
> node 1 cpus: 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52
> 53 54 55 56 57 58 59 60 61 62 63
> node 1 size: 32722 MB
> node 1 free: 32019 MB
> node 16 cpus: 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84
> 85 86 87 88 89 90 91 92 93 94 95
> node 16 size: 32571 MB
> node 16 free: 31222 MB
> node 17 cpus: 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111
> 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127
> node 17 size: 0 MB
> node 17 free: 0 MB
> node distances:
> node   0   1  16  17
>   0:  10  20  40  40
>   1:  20  10  40  40
>  16:  40  40  10  20
>  17:  40  40  20  10
>
> After the patch: numactl -H
>
> available: 4 nodes (0-3)
> node 0 cpus: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23
> 24 25 26 27 28 29 30 31
> node 0 size: 31665 MB
> node 0 free: 30657 MB
> node 1 cpus: 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52
> 53 54 55 56 57 58 59 60 61 62 63
> node 1 size: 32722 MB
> node 1 free: 32566 MB
> node 2 cpus: 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84
> 85 86 87 88 89 90 91 92 93 94 95
> node 2 size: 32571 MB
> node 2 free: 32401 MB
> node 3 cpus: 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112
> 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127
> node 3 size: 0 MB
> node 3 free: 0 MB
> node distances:
> node   0   1   2   3
>   0:  10  20  40  40
>   1:  20  10  40  40
>   2:  40  40  10  20
>   3:  40  40  20  10
>
> (note that numa distances are intact). Apart from this, The following tests
> are done with the patched kernel (both baremetal and KVM guest with multiple
> nodes) to ensure there is no breakage.
>
> 1) offlining and onlining of memory in /sys/devices/system/node/nodeX path
>
> 2) offlining and onlining of cpus in /sys/devices/system/cpu/ path
>
> 3) Numactl tests from
> ftp://oss.sgi.com/www/projects/libnuma/download/numactl-2.0.10.tar.gz
>
> (infact there were more breakage before the patch because of sparse nid
> and memoryless node cases of powerpc)
>
> 4) Thousands of docker containers were spawned.
>
> Please let me know your comments.
>
>  patch 1-3: cleanup patches
>  patch 4: Adds helper function to map nid and chipid
>  patch 5: Uses the mapping to get serial nid
>
> Raghavendra K T (5):
>   powerpc:numa Add numa_cpu_lookup function to update lookup table
>   powerpc:numa Rename functions referring to nid as chipid
>   powerpc:numa create 1:1 mappaing between chipid and nid
>   powerpc:numa Add helper functions to maintain chipid to nid mapping
>   powerpc:numa Use chipid to nid mapping to get serial numa node ids
>
>  arch/powerpc/include/asm/mmzone.h |   2 +-
>  arch/powerpc/kernel/smp.c |  10 ++--
>  arch/powerpc/mm/numa.c| 121
> +++---
>  3 files changed, 105 insertions(+), 28 deletions(-)
>
> --
> 1.7.11.7
>
> 

Re: [PATCH v4 08/32] cxlflash: Fix to avoid CXL services during EEH

2015-09-28 Thread Brian King
Reviewed-by: Brian King 


-- 
Brian King
Power Linux I/O
IBM Linux Technology Center

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH v4 07/32] cxlflash: Fix context encode mask width

2015-09-28 Thread Daniel Axtens
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512


Looks good to me.

Reviewed-by: Daniel Axtens 

Regards,
Daniel

"Matthew R. Ochs"  writes:

> The context encode mask covers more than 32-bits, making it
> a long integer. This should be noted by appending the ULL
> width suffix to the mask.
>
> Signed-off-by: Matthew R. Ochs 
> Signed-off-by: Manoj N. Kumar 
> Reviewed-by: Brian King 
> ---
>  drivers/scsi/cxlflash/superpipe.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/scsi/cxlflash/superpipe.h 
> b/drivers/scsi/cxlflash/superpipe.h
> index 72d53cf..7947091 100644
> --- a/drivers/scsi/cxlflash/superpipe.h
> +++ b/drivers/scsi/cxlflash/superpipe.h
> @@ -87,7 +87,7 @@ enum ctx_ctrl {
>   CTX_CTRL_FILE   = (1 << 5)
>  };
>  
> -#define ENCODE_CTXID(_ctx, _id)  (u64)_ctx) & 0x0) << 28) | 
> _id)
> +#define ENCODE_CTXID(_ctx, _id)  (u64)_ctx) & 0x0ULL) << 28) 
> | _id)
>  #define DECODE_CTXID(_val)   (_val & 0x)
>  
>  struct ctx_info {
> -- 
> 2.1.0
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: GPGTools - https://gpgtools.org

iQIcBAEBCgAGBQJWCcGLAAoJEPC3R3P2I92FJ1kP/juiS2a5hBDOGjVliW6KlWK6
pb9yRZ1qmvgiL1xtMO/rfSEEb/kwO6QSbDcKqLtKwI24DBkVF2eDAOo9mOKKNhBI
EF/AwZsvG1DE3o0+AAx3mY7+AO1rP+uZSvCJf5GvDDdSfYXfq5f49+aM6HJ0n130
ewlQmOnwwGDpO2gehccrDSmSbUB1CwKY1uQ5KtczGqdtfkgSu7YVRHKiNiid9Nop
uJWDE452NBm2dM5Jf2hXFXwMSzx9bbmM5Ue27gf1HES8CGw3Z2BQtYIx6tjHLYH/
Rj4dPSLBjuBeEI4YZHqxkYs3ipBV38wRwuG0O5o+YKUD6TczeYtwwCVAmma8pTm2
tYT8xrY19Ng3oQ1P68zxP4D5uYbdFhIOyqLhss9Lnas0VxzZUbdfiuF4V8ABSGTz
L8WFw2ff/73LtVaSr/KGyt1RvfLpoEFxkYd3+sGwsfqM/HyC2K3g4RZucLct1oeX
PPPKz5ZQF9K/R/mKJEIAG+Fh0usryj97Wgf+r3Ie0QQDorOoG+8itGg0OJ0o1ojV
wjduJiwsoD+2HwnTw85TwSp6PPY+8o7Gml1PvfGUFWJjPgSUkcQ6L3lrispE4twt
hgrWSsRE/GO5+JD9KNSYnKr8dRxD6iDFefppZv64nWJKi11PZoz7z09Q+dE1KAng
jpNUi5wyGph2AwD7E9I2
=M1UV
-END PGP SIGNATURE-
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH v2 06/25] powerpc32: iounmap() cannot vunmap() area mapped by TLBCAMs either

2015-09-28 Thread Scott Wood
On Tue, Sep 22, 2015 at 06:50:40PM +0200, Christophe Leroy wrote:
> iounmap() cannot vunmap() area mapped by TLBCAMs either
> 
> Signed-off-by: Christophe Leroy 
> ---
> No change in v2
> 
>  arch/powerpc/mm/pgtable_32.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/powerpc/mm/pgtable_32.c b/arch/powerpc/mm/pgtable_32.c
> index 7692d1b..03a073a 100644
> --- a/arch/powerpc/mm/pgtable_32.c
> +++ b/arch/powerpc/mm/pgtable_32.c
> @@ -278,7 +278,9 @@ void iounmap(volatile void __iomem *addr)
>* If mapped by BATs then there is nothing to do.
>* Calling vfree() generates a benign warning.
>*/
> - if (v_mapped_by_bats((unsigned long)addr)) return;
> + if (v_mapped_by_bats((unsigned long)addr) ||
> + v_mapped_by_tlbcam((unsigned long)addr))
> + return;

This is pretty pointless given that the next patch replaces both with
v_mapped_by_other().

-Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH v2 01/25] powerpc/8xx: Save r3 all the time in DTLB miss handler

2015-09-28 Thread Scott Wood
On Tue, Sep 22, 2015 at 06:50:29PM +0200, Christophe Leroy wrote:
> We are spending between 40 and 160 cycles with a mean of 65 cycles in
> the TLB handling routines (measured with mftbl) so make it more
> simple althought it adds one instruction.
> 
> Signed-off-by: Christophe Leroy 

Does this just make it simpler or does it make it faster?  What is the
performance impact?  Is the performance impact seen with or without
CONFIG_8xx_CPU6 enabled?  Without it, it looks like you're adding an
mtspr/mfspr combo in order to replace one mfspr.

-Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH v4 09/32] cxlflash: Correct naming of limbo state and waitq

2015-09-28 Thread Daniel Axtens
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

"Matthew R. Ochs"  writes:

Looks good from an EEH point of view: in an error situation, your driver
asks to be reset and then is waiting for CXL and EEH to carry that out,
so 'reset' matches with that as well.

Reviewed-by: Daniel Axtens 

> Limbo is not an accurate representation of this state and is
> also not consistent with the terminology that other drivers
> use to represent this concept. Rename the state and and its
> associated waitq to 'reset'.
>
> Signed-off-by: Matthew R. Ochs 
> Signed-off-by: Manoj N. Kumar 
> Reviewed-by: Brian King 
> ---
>  drivers/scsi/cxlflash/common.h|  4 ++--
>  drivers/scsi/cxlflash/main.c  | 26 +-
>  drivers/scsi/cxlflash/superpipe.c | 14 +++---
>  3 files changed, 22 insertions(+), 22 deletions(-)
>
> diff --git a/drivers/scsi/cxlflash/common.h b/drivers/scsi/cxlflash/common.h
> index 1abe4e0..11318de 100644
> --- a/drivers/scsi/cxlflash/common.h
> +++ b/drivers/scsi/cxlflash/common.h
> @@ -79,7 +79,7 @@ enum cxlflash_init_state {
>  
>  enum cxlflash_state {
>   STATE_NORMAL,   /* Normal running state, everything good */
> - STATE_LIMBO,/* Limbo running state, trying to reset/recover */
> + STATE_RESET,/* Reset state, trying to reset/recover */
>   STATE_FAILTERM  /* Failed/terminating state, error out users/threads */
>  };
>  
> @@ -125,7 +125,7 @@ struct cxlflash_cfg {
>  
>   wait_queue_head_t tmf_waitq;
>   bool tmf_active;
> - wait_queue_head_t limbo_waitq;
> + wait_queue_head_t reset_waitq;
>   enum cxlflash_state state;
>  };
>  
> diff --git a/drivers/scsi/cxlflash/main.c b/drivers/scsi/cxlflash/main.c
> index 6e85c77..8940336 100644
> --- a/drivers/scsi/cxlflash/main.c
> +++ b/drivers/scsi/cxlflash/main.c
> @@ -382,8 +382,8 @@ static int cxlflash_queuecommand(struct Scsi_Host *host, 
> struct scsi_cmnd *scp)
>   spin_unlock_irqrestore(>tmf_waitq.lock, lock_flags);
>  
>   switch (cfg->state) {
> - case STATE_LIMBO:
> - dev_dbg_ratelimited(>dev->dev, "%s: device in limbo!\n",
> + case STATE_RESET:
> + dev_dbg_ratelimited(>dev->dev, "%s: device is in reset!\n",
>   __func__);
>   rc = SCSI_MLQUEUE_HOST_BUSY;
>   goto out;
> @@ -479,8 +479,8 @@ static int cxlflash_eh_device_reset_handler(struct 
> scsi_cmnd *scp)
>   if (unlikely(rcr))
>   rc = FAILED;
>   break;
> - case STATE_LIMBO:
> - wait_event(cfg->limbo_waitq, cfg->state != STATE_LIMBO);
> + case STATE_RESET:
> + wait_event(cfg->reset_waitq, cfg->state != STATE_RESET);
>   if (cfg->state == STATE_NORMAL)
>   break;
>   /* fall through */
> @@ -519,7 +519,7 @@ static int cxlflash_eh_host_reset_handler(struct 
> scsi_cmnd *scp)
>  
>   switch (cfg->state) {
>   case STATE_NORMAL:
> - cfg->state = STATE_LIMBO;
> + cfg->state = STATE_RESET;
>   scsi_block_requests(cfg->host);
>   cxlflash_mark_contexts_error(cfg);
>   rcr = cxlflash_afu_reset(cfg);
> @@ -528,11 +528,11 @@ static int cxlflash_eh_host_reset_handler(struct 
> scsi_cmnd *scp)
>   cfg->state = STATE_FAILTERM;
>   } else
>   cfg->state = STATE_NORMAL;
> - wake_up_all(>limbo_waitq);
> + wake_up_all(>reset_waitq);
>   scsi_unblock_requests(cfg->host);
>   break;
> - case STATE_LIMBO:
> - wait_event(cfg->limbo_waitq, cfg->state != STATE_LIMBO);
> + case STATE_RESET:
> + wait_event(cfg->reset_waitq, cfg->state != STATE_RESET);
>   if (cfg->state == STATE_NORMAL)
>   break;
>   /* fall through */
> @@ -705,7 +705,7 @@ static void cxlflash_wait_for_pci_err_recovery(struct 
> cxlflash_cfg *cfg)
>   struct pci_dev *pdev = cfg->dev;
>  
>   if (pci_channel_offline(pdev))
> - wait_event_timeout(cfg->limbo_waitq,
> + wait_event_timeout(cfg->reset_waitq,
>  !pci_channel_offline(pdev),
>  CXLFLASH_PCI_ERROR_RECOVERY_TIMEOUT);
>  }
> @@ -2304,7 +2304,7 @@ static int cxlflash_probe(struct pci_dev *pdev,
>   cfg->mcctx = NULL;
>  
>   init_waitqueue_head(>tmf_waitq);
> - init_waitqueue_head(>limbo_waitq);
> + init_waitqueue_head(>reset_waitq);
>  
>   INIT_WORK(>work_q, cxlflash_worker_thread);
>   cfg->lr_state = LINK_RESET_INVALID;
> @@ -2396,7 +2396,7 @@ static pci_ers_result_t 
> cxlflash_pci_error_detected(struct pci_dev *pdev,
>  
>   switch (state) {
>   case pci_channel_io_frozen:
> - cfg->state = STATE_LIMBO;

Re: [PATCH v2 05/25] powerpc/8xx: Fix vaddr for IMMR early remap

2015-09-28 Thread Scott Wood
On Tue, Sep 22, 2015 at 06:50:38PM +0200, Christophe Leroy wrote:
> Memory: 124428K/131072K available (3748K kernel code, 188K rwdata,
> 648K rodata, 508K init, 290K bss, 6644K reserved)
> Kernel virtual memory layout:
>   * 0xfffdf000..0xf000  : fixmap
>   * 0xfde0..0xfe00  : consistent mem
>   * 0xfddf6000..0xfde0  : early ioremap
>   * 0xc900..0xfddf6000  : vmalloc & ioremap
> SLUB: HWalign=16, Order=0-3, MinObjects=0, CPUs=1, Nodes=1
> 
> Mapping IMMR 1:1 is just wrong because it may overlap with another
> area. On most mpc8xx boards it is OK because IMMR is set to
> 0xff00 but for instance on EP88xC board, IMMR is at 0xfa20
> which overlaps with VM ioremap area
> 
> This patch fixes the virtual address for remapping IMMR to 0xff00,
> regardless of the value of IMMR.
> 
> The size of IMMR area is 256kbytes (CPM at offset 0, security engine
> at offset 128) so 512kbytes is enough and allows to handle the EP88xC
> case (which is not 8Mbytes but only 2Mbytes aligned) the same way.
> 
> Signed-off-by: Christophe Leroy 

Instead of hardcoding 0xff00, can you use asm/fixmap.h to allocate a
virtual address at compile time?

-Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH v2 07/25] powerpc32: refactor x_mapped_by_bats() and x_mapped_by_tlbcam() together

2015-09-28 Thread Scott Wood
On Tue, Sep 22, 2015 at 06:50:42PM +0200, Christophe Leroy wrote:
> x_mapped_by_bats() and x_mapped_by_tlbcam() serve the same kind of
> purpose, so lets group them into a single function.
> 
> Signed-off-by: Christophe Leroy 
> ---
> No change in v2
> 
>  arch/powerpc/mm/pgtable_32.c | 33 ++---
>  1 file changed, 26 insertions(+), 7 deletions(-)
> 
> diff --git a/arch/powerpc/mm/pgtable_32.c b/arch/powerpc/mm/pgtable_32.c
> index 03a073a..3fd9083 100644
> --- a/arch/powerpc/mm/pgtable_32.c
> +++ b/arch/powerpc/mm/pgtable_32.c
> @@ -67,6 +67,28 @@ extern unsigned long p_mapped_by_tlbcam(phys_addr_t pa);
>  #define p_mapped_by_tlbcam(x)(0UL)
>  #endif /* HAVE_TLBCAM */
>  
> +static inline unsigned long p_mapped_by_other(phys_addr_t pa)
> +{
> + unsigned long v;
> +
> + v = p_mapped_by_bats(pa);
> + if (v /*&& p_mapped_by_bats(p+size-1)*/)
> + return v;
> +
> + return p_mapped_by_tlbcam(pa);
> +}

Did you forget to remove that comment?

-Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH v4 06/32] cxlflash: Fix to avoid sizeof(bool)

2015-09-28 Thread Daniel Axtens
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512


Looks good to me.

Reviewed-by: Daniel Axtens 

Regards,
Daniel

"Matthew R. Ochs"  writes:

> Using sizeof(bool) is considered poor form for various reasons and
> sparse warns us of that. Correct by changing type from bool to u8.
>
> Signed-off-by: Matthew R. Ochs 
> Signed-off-by: Manoj N. Kumar 
> Reviewed-by: Brian King 
> ---
>  drivers/scsi/cxlflash/superpipe.c | 2 +-
>  drivers/scsi/cxlflash/superpipe.h | 2 +-
>  2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/scsi/cxlflash/superpipe.c 
> b/drivers/scsi/cxlflash/superpipe.c
> index ffa68cc..28aa9d9 100644
> --- a/drivers/scsi/cxlflash/superpipe.c
> +++ b/drivers/scsi/cxlflash/superpipe.c
> @@ -737,7 +737,7 @@ static struct ctx_info *create_context(struct 
> cxlflash_cfg *cfg,
>   struct afu *afu = cfg->afu;
>   struct ctx_info *ctxi = NULL;
>   struct llun_info **lli = NULL;
> - bool *ws = NULL;
> + u8 *ws = NULL;
>   struct sisl_rht_entry *rhte;
>  
>   ctxi = kzalloc(sizeof(*ctxi), GFP_KERNEL);
> diff --git a/drivers/scsi/cxlflash/superpipe.h 
> b/drivers/scsi/cxlflash/superpipe.h
> index fffb179..72d53cf 100644
> --- a/drivers/scsi/cxlflash/superpipe.h
> +++ b/drivers/scsi/cxlflash/superpipe.h
> @@ -97,7 +97,7 @@ struct ctx_info {
>   u32 rht_out;/* Number of checked out RHT entries */
>   u32 rht_perms;  /* User-defined permissions for RHT entries */
>   struct llun_info **rht_lun;   /* Mapping of RHT entries to LUNs */
> - bool *rht_needs_ws; /* User-desired write-same function per RHTE */
> + u8 *rht_needs_ws;   /* User-desired write-same function per RHTE */
>  
>   struct cxl_ioctl_start_work work;
>   u64 ctxid;
> -- 
> 2.1.0
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: GPGTools - https://gpgtools.org

iQIcBAEBCgAGBQJWCcCzAAoJEPC3R3P2I92FisQP/1Gd443NSLYkye19i4D7qlA/
3tfNTBBSYL68A1L1ssgRxtpOkqb80hjOSXZhR2SDLRGNXDoC5+8fwti/sF8wxewF
rxIsliMN2WnqgyYpw4qt7T6AMZtSyP1yXQkPWZcVQi5a9p1w3YmLdvwr9hnyKx8n
TRjEe3OoDS/dde8l+4C1YKCL/U4oDuGdH7DLT+vhn49TfxQL4aNiV52Wu5l3Sptw
f4/VVXAklNkU6yHJiRonjf/GJggfcgKUmsy4y8ayvkNuMu2V+ffP9AbdwdZXrplK
CempBE0AvQdjLS0b8oIErOHfyWJcagHhMZicblLT5xp4kR0mDsIybEI433cGjESI
4ECg2AjKRoBEu6s8fR3WFR82nZo97o0ck2pAD4RVJTA/aY7h1DlZ45kg2cYEatRW
OVnQqd//bHKyWljWzl7qXuwpXF8G92iP4CFQ4d8aruUFp9vwFlR8GuIpsq69kb5X
FM6EuTzcbD+GkT+P9lw2T/6LHrb+2kTANHJgWKalfugJxAwcDps6X7tKxQ9mvqps
HyVVfOtNkK2yvAV8iEqPdT9ltXIhJ/g9c9ZtQ7F2Qg7pxnB15M5ykOIeVVsRIEof
F1HAG8xzPNY0Q7MBHDixqQ7IbHDnbkM+SI9outZu5C0ECjc3UwdfOaegm+A6eWs9
3bv8aFdbQlHfjSFUIhqY
=RI1B
-END PGP SIGNATURE-
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH v4 08/32] cxlflash: Fix to avoid CXL services during EEH

2015-09-28 Thread Daniel Axtens

You have two versions of check_state() below, which is a bit
confusing. It looks like you've moved the function and also added the
up/down of the read semaphore. I assume that's all that changed?

>  
>  /**
> + * check_state() - checks and responds to the current adapter state
> + * @cfg: Internal structure associated with the host.
> + *
> + * This routine can block and should only be used on process context.
> + * It assumes that the caller is an ioctl thread and holding the ioctl
> + * read semaphore. This is temporarily let up across the wait to allow
> + * for draining actively running ioctls. Also note that when waking up
> + * from waiting in reset, the state is unknown and must be checked again
> + * before proceeding.
> + *
> + * Return: 0 on success, -errno on failure
> + */
> +static int check_state(struct cxlflash_cfg *cfg)
> +{
> + struct device *dev = >dev->dev;
> + int rc = 0;
> +
> +retry:
> + switch (cfg->state) {
> + case STATE_LIMBO:
> + dev_dbg(dev, "%s: Limbo state, going to wait...\n", __func__);
> + up_read(>ioctl_rwsem);
> + rc = wait_event_interruptible(cfg->limbo_waitq,
> +   cfg->state != STATE_LIMBO);
> + down_read(>ioctl_rwsem);
> + if (unlikely(rc))
> + break;
> + goto retry;
> + case STATE_FAILTERM:
> + dev_dbg(dev, "%s: Failed/Terminating!\n", __func__);
> + rc = -ENODEV;
> + break;
> + default:
> + break;
> + }
> +
> + return rc;
> +}
> +
> +/**
>   * cxlflash_disk_attach() - attach a LUN to a context
>   * @sdev:SCSI device associated with LUN.
>   * @attach:  Attach ioctl data structure.
> @@ -1523,41 +1563,6 @@ err1:
>  }
>  
>  /**
> - * check_state() - checks and responds to the current adapter state
> - * @cfg: Internal structure associated with the host.
> - *
> - * This routine can block and should only be used on process context.
> - * Note that when waking up from waiting in limbo, the state is unknown
> - * and must be checked again before proceeding.
> - *
> - * Return: 0 on success, -errno on failure
> - */
> -static int check_state(struct cxlflash_cfg *cfg)
> -{
> - struct device *dev = >dev->dev;
> - int rc = 0;
> -
> -retry:
> - switch (cfg->state) {
> - case STATE_LIMBO:
> - dev_dbg(dev, "%s: Limbo, going to wait...\n", __func__);
> - rc = wait_event_interruptible(cfg->limbo_waitq,
> -   cfg->state != STATE_LIMBO);
> - if (unlikely(rc))
> - break;
> - goto retry;
> - case STATE_FAILTERM:
> - dev_dbg(dev, "%s: Failed/Terminating!\n", __func__);
> - rc = -ENODEV;
> - break;
> - default:
> - break;
> - }
> -
> - return rc;
> -}
> -
> -/**
>   * cxlflash_afu_recover() - initiates AFU recovery
>   * @sdev:SCSI device associated with LUN.
>   * @recover: Recover ioctl data structure.
> @@ -1646,9 +1651,14 @@ retry_recover:
>   /* Test if in error state */
>   reg = readq_be(>ctrl_map->mbox_r);
>   if (reg == -1) {
> - dev_dbg(dev, "%s: MMIO read fail! Wait for recovery...\n",
> - __func__);
> - mutex_unlock(>mutex);
> + dev_dbg(dev, "%s: MMIO fail, wait for recovery.\n", __func__);
> +
> + /*
> +  * Before checking the state, put back the context obtained with
> +  * get_context() as it is no longer needed and sleep for a short
> +  * period of time (see prolog notes).
> +  */
> + put_context(ctxi);

Is this needed for the drain to work? It looks like it fixes a
refcounting bug in the function, but I'm not sure I understand how it
interacts with the rest of this patch.

Anyway, the patch overall looks good to me, and makes your driver
interact with CXL's EEH support in the way I intended when I wrote it.

Reviewed-by: Daniel Axtens 

Regards,
Daniel
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH v4 17/32] cxlflash: Remove dual port online dependency

2015-09-28 Thread Daniel Axtens
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi,

>  static int afu_set_wwpn(struct afu *afu, int port, u64 *fc_regs, u64 wwpn)
>  {
> - int ret = 0;
> + int rc = 0;
I realise it's nice to have things consistent, but making this change
now makes the rest of the patch quite difficult to follow.

>  
>   set_port_offline(fc_regs);
>  
> @@ -1038,33 +1038,26 @@ static int afu_set_wwpn(struct afu *afu, int port, 
> u64 *fc_regs, u64 wwpn)
>  FC_PORT_STATUS_RETRY_CNT)) {
>   pr_debug("%s: wait on port %d to go offline timed out\n",
>__func__, port);
> - ret = -1; /* but continue on to leave the port back online */
> + rc = -1; /* but continue on to leave the port back online */
>   }
>  
> - if (ret == 0)
> + if (rc == 0)
>   writeq_be(wwpn, _regs[FC_PNAME / 8]);
>  
> + /* Always return success after programming WWPN */
> + rc = 0;
> +
>   set_port_online(fc_regs);
>  
>   if (!wait_port_online(fc_regs, FC_PORT_STATUS_RETRY_INTERVAL_US,
> FC_PORT_STATUS_RETRY_CNT)) {
>   pr_debug("%s: wait on port %d to go online timed out\n",
>__func__, port);
> - ret = -1;
> -
> - /*
> -  * Override for internal lun!!!
> -  */
> - if (afu->internal_lun) {
> - pr_debug("%s: Overriding port %d online timeout!!!\n",
> -  __func__, port);
> - ret = 0;
> - }
>   }
>  
> - pr_debug("%s: returning rc=%d\n", __func__, ret);
> + pr_debug("%s: returning rc=%d\n", __func__, rc);
I'm not sure I fully understand the flow of this function, but it looks
like you set rc=0 regardless of how things actually go: is this ever
going to print a return value other than zero?

Regards,
Daniel
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: GPGTools - https://gpgtools.org

iQIcBAEBCgAGBQJWCc87AAoJEPC3R3P2I92FQNcP/RF+M8MGZ2PJ8heh98D84rb5
Dx+Yq1czRJ+YZbK5tCfkyU66KspEzM7IIOiiXDLlBZ+AjcQtCUopTNMbL/UN+oVT
5lWrvPZlWRJqRN5bA/RA3i/DSBRucucmP8n4pmTKqsMMqKwzk/f3sE+Uo5oAzS+y
JaSywxm+Vd4dkW5T94kc6TXCeWcaD47tG0mgg0jHGwFtOioDEeWgf7Kie52+RV+o
I6z7GlQj9dgcKs2NmVr67AoY1dfRYl1ZvvJN7bYoLbHnEgiSw1d6XZK/2cqHzIpE
S1KEHOyuSZJh8Txwfg6oJ3sbpFZaurSIXDXfOhWuJ90OrOu4hgeODTPX/3o2CKae
K+WhsL6XOhrxyMhfq/VWplF6Hjo7VqLcT9e0sYZ4YNkUJrGAza3iPOqngK9zmdsM
80HLJdbsiZMkl+i55IOuisckCtvjUtVE+bDlzau6vwgBlgZ9DKByPPmqJGjS9I3L
vCEKsRZryaSvaYSnK46kpqXsukN/+QMefXL25IfTf4wQQaV4O+mSJxkkLXPAKqfd
cvCFg08MyAQS+YyNMBdFDJyj7tWVclGZhJkqlyjPjQ2YrFA5tQ7MoqY05NomxY9Q
xo0JuaceNccFetKPg1LMmTp5Ag/2DCcnGq/0Z3ioGVJTFIVil0BnWIFctlGbquya
n4Ylfe3h1T6hWJ7bjxwF
=cZRI
-END PGP SIGNATURE-
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH v4 32/32] cxlflash: Fix to avoid potential deadlock on EEH

2015-09-28 Thread Brian King
On 09/25/2015 06:19 PM, Matthew R. Ochs wrote:
>  static int write_same16(struct scsi_device *sdev,
> @@ -433,9 +451,20 @@ static int write_same16(struct scsi_device *sdev,
>   put_unaligned_be32(ws_limit < left ? ws_limit : left,
>  _cmd[10]);
> 
> + /* Drop the ioctl read semahpore across lengthy call */
> + up_read(>ioctl_rwsem);
>   result = scsi_execute(sdev, scsi_cmd, DMA_TO_DEVICE, cmd_buf,
> CMD_BUFSIZE, sense_buf, to, CMD_RETRIES,
> 0, NULL);
> + down_read(>ioctl_rwsem);
> + rc = check_state(cfg);
> + if (rc) {
> + dev_err(dev, "%s: Failed state! result=0x08%X\n",
> + __func__, result);
> + rc = -ENODEV;

Since check_state only returns 0 or -ENODEV, this is a bit redundant, but not 
worth redoing the
patch in my mind.

Reviewed-by: Brian King 




-- 
Brian King
Power Linux I/O
IBM Linux Technology Center

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH v2 08/25] powerpc/8xx: Map IMMR area with 512k page at a fixed address

2015-09-28 Thread Scott Wood
On Tue, Sep 22, 2015 at 06:50:44PM +0200, Christophe Leroy wrote:

> diff --git a/arch/powerpc/mm/pgtable_32.c b/arch/powerpc/mm/pgtable_32.c
> index 3fd9083..1f2fdbc 100644
> --- a/arch/powerpc/mm/pgtable_32.c
> +++ b/arch/powerpc/mm/pgtable_32.c
> @@ -49,6 +49,10 @@ EXPORT_SYMBOL(ioremap_bot);/* aka VMALLOC_END */
>  #define HAVE_TLBCAM  1
>  #endif
>  
> +#if CONFIG_PPC_8xx
> +#define HAVE_LTLB1
> +#endif
> +
>  extern char etext[], _stext[];
>  
>  #ifdef HAVE_BATS
> @@ -67,6 +71,14 @@ extern unsigned long p_mapped_by_tlbcam(phys_addr_t pa);
>  #define p_mapped_by_tlbcam(x)(0UL)
>  #endif /* HAVE_TLBCAM */
>  
> +#ifdef HAVE_LTLB
> +phys_addr_t v_mapped_by_ltlb(unsigned long va);
> +unsigned long p_mapped_by_ltlb(phys_addr_t pa);
> +#else /* !HAVE_LTLB */
> +#define v_mapped_by_ltlb(x)  (0UL)
> +#define p_mapped_by_ltlb(x)  (0UL)
> +#endif /* HAVE_LTLB */
> +
>  static inline unsigned long p_mapped_by_other(phys_addr_t pa)
>  {
>   unsigned long v;
> @@ -75,6 +87,10 @@ static inline unsigned long p_mapped_by_other(phys_addr_t 
> pa)
>   if (v /*&& p_mapped_by_bats(p+size-1)*/)
>   return v;
>  
> + v = p_mapped_by_ltlb(pa);
> + if (v)
> + return v;
> +
>   return p_mapped_by_tlbcam(pa);
>  }
>  
> @@ -86,6 +102,10 @@ static inline phys_addr_t v_mapped_by_other(unsigned long 
> va)
>   if (p)
>   return p;
>  
> + p = v_mapped_by_ltlb(va);
> + if (p)
> + return p;
> +
>   return v_mapped_by_tlbcam(va);
>  }

Since there is no kernel with more than one of {bats,ltlb,tlbcam} can we
just call it *_block_mapped() and have each subarch provide its
implementation (or stub) thereof?

-Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH v4 27/32] cxlflash: Fix to prevent stale AFU RRQ

2015-09-28 Thread Daniel Axtens
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

"Matthew R. Ochs"  writes:

> Following an adapter reset, the AFU RRQ that resides in host memory
> holds stale data. This can lead to a condition where the RRQ interrupt
> handler tries to process stale entries and/or endlessly loops due to an
> out of sync generation bit.
>
> To fix, the AFU RRQ in host memory needs to be cleared after each reset.

This looks good. Do you need anything to bail out of cxlflash_rrq_irq if
the data goes stale or to all Fs while that function is running?

Daniel

>
> Signed-off-by: Matthew R. Ochs 
> Signed-off-by: Manoj N. Kumar 
> Reviewed-by: Brian King 
> ---
>  drivers/scsi/cxlflash/main.c | 3 +++
>  1 file changed, 3 insertions(+)
>
> diff --git a/drivers/scsi/cxlflash/main.c b/drivers/scsi/cxlflash/main.c
> index 24aedfb..ab11ee6 100644
> --- a/drivers/scsi/cxlflash/main.c
> +++ b/drivers/scsi/cxlflash/main.c
> @@ -1598,6 +1598,9 @@ static int start_afu(struct cxlflash_cfg *cfg)
>  
>   init_pcr(cfg);
>  
> + /* After an AFU reset, RRQ entries are stale, clear them */
> + memset(>rrq_entry, 0, sizeof(afu->rrq_entry));
> +
>   /* Initialize RRQ pointers */
>   afu->hrrq_start = >rrq_entry[0];
>   afu->hrrq_end = >rrq_entry[NUM_RRQ_ENTRY - 1];
> -- 
> 2.1.0
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: GPGTools - https://gpgtools.org

iQIcBAEBCgAGBQJWCesgAAoJEPC3R3P2I92FE4kP+wYTEdCDP50RfKZPNCpoY//T
5tDNV58W1RasTrJLVGrpeGBboI4WTzRlKYAYX1iLC6ZSkX1rQS5rBqgImQQAg3i5
N9qoAdNCch06UVO7psceptT9653xt0OzitHW/tmB8pOMII65UIm8AtydSs2+J0e8
htw9Jnw098jls8NJtzz32T48QoM+kV1w7vfJJN36Z6FjL36KJLQCAL2/gLvv+3Zt
2ueeP6MM0q0iFxnQJwPFdf3DebggbMqeVbNorNAyCSkNNoUh2QR8NMHeFS8OoXCl
nrzjFoeSFDXh4c4bRzVoGRalIFzP+VY9guk9d/VtAt8ZkkrIyfI3K9lJTgDq2gqj
ShnT/WB4lskUVc/FjdkyIc+Nyg6pPkm4OftCnN7sf7CSd2+myO/d6S1f1qJlCn7s
3KBLXEFrKXKHl9TVDqkZSZVvyJOKmxoMqT98I00CWhXFkRgO126tnqsMsmrqgzxu
QxZQSo+/Oi7av6YuVtTP2c9SeYbGBfhOMOH5Dx7z9VY57rWvE5CVsduYJoG2D59P
Td5ToL1H3UOt8G1vzeqmkb7AWK882py2OLS7WG0PUDRDa2dfE6+8NOCJmuX9tW2x
/NnLlInDTiVTpz3iiJpe9Efu3SkL2KeMEBxi4jdt31hFO0BPeFWnZHKjwOa+uQ/w
OSaHCUZEZ6LRdbeJ1GLk
=O6Zk
-END PGP SIGNATURE-
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH v4 29/32] cxlflash: Fix to double the delay each time

2015-09-28 Thread Daniel Axtens
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

"Matthew R. Ochs"  writes:

> From: Manoj Kumar 
>
> The operator used to double the delay is incorrect and
> does not result in delay doubling.
>
> To fix, use a left shift instead of the XOR operator.
>
I can see that the patch is correct, but this commit message is a bit
confusing. What delay? In what circumstances are you doubling it? Why?

Regards,
Daniel

> Reported-by: Tomas Henzl 
> Signed-off-by: Matthew R. Ochs 
> Signed-off-by: Manoj N. Kumar 
> Reviewed-by: Brian King 
> ---
>  drivers/scsi/cxlflash/main.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/scsi/cxlflash/main.c b/drivers/scsi/cxlflash/main.c
> index ab11ee6..be78906 100644
> --- a/drivers/scsi/cxlflash/main.c
> +++ b/drivers/scsi/cxlflash/main.c
> @@ -303,7 +303,7 @@ write_rrin:
>   if (rrin != 0x1)
>   break;
>   /* Double delay each time */
> - udelay(2 ^ nretry);
> + udelay(2 << nretry);
>   } while (nretry++ < MC_ROOM_RETRY_CNT);
>  }
>  
> -- 
> 2.1.0
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: GPGTools - https://gpgtools.org

iQIcBAEBCgAGBQJWCewRAAoJEPC3R3P2I92F7xQQAKxvcnUpB/xLeq6CyB3LwsB/
cqFMP7OwDRfmQZG5ld5uqfXsjCCW4c0BaVknMgpD5gAdHbrwbc5gFgYuC0kIDUrH
aEwTyXwaH7+o82agjxf7TRrsh2NtLzdSB6NN1UNL73aPVXJFKWITajIKUAnYF5d1
AvB3yb4KtX0qklo205igVceuLbBBaXY6Lz3V58XDSG2JAtVlVkamJK7M8zySrNTY
Y627zTVkbopOGaBMLmu0q92dWDk2saU2wqKolo+pRy1NpOmY2XOU9hSRqCqAhnS4
xOWj7Bdrh1HdnQX26EC+f485nOijf0zddpJ6LsgPWMElJ04N4siQwmrwG55FbOs4
QDFKPdsVdZ8qmVueGCLRdTsMNAxcobi44P1/QXxGTmsn9xqyQBgZUzbd5oRUVswI
md21qir3xjRN7g4R78084I88dM1yrHpJ6NuHDxFeXbtrw8087lKgU05Ys6m+ebuC
7nPnYRJ54frAi6a7mmBq+Xc4IbVnaGl9IZi1gujM2mkTaAk7/wl7oRMYyUTKlblp
BeoQN0cdG1fChP1yLHzZV6G1JXwSw7nP6otf7YfUIrmjbzeZ5zWovSqJjnvNYBCT
zgW681gIF3GwaN9z9I+XY9BO1P6EkYp+dgAQM7PqdR00GjFjTJO0yn8WHh113lmE
L2sC0Nezuq8V4/qtspmh
=Km/z
-END PGP SIGNATURE-
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH v4 24/32] cxlflash: Fix MMIO and endianness errors

2015-09-28 Thread Andrew Donnellan

On 26/09/15 09:18, Matthew R. Ochs wrote:

Sparse uncovered several errors with MMIO operations (accessing
directly) and handling endianness. These can cause issues when
running in different environments.

Introduce __iomem and proper endianness tags/swaps where
appropriate to make driver sparse clean.

Signed-off-by: Matthew R. Ochs 
Signed-off-by: Manoj N. Kumar 
Reviewed-by: Brian King 


Reviewed-by: Andrew Donnellan 

--
Andrew Donnellan  Software Engineer, OzLabs
andrew.donnel...@au1.ibm.com  Australia Development Lab, Canberra
+61 2 6201 8874 (work)IBM Australia Limited

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[PATCH v11 1/6] genalloc:support memory-allocation with bytes-alignment to genalloc

2015-09-28 Thread Zhao Qiang
Bytes alignment is required to manage some special RAM,
so add gen_pool_first_fit_align to genalloc,
meanwhile add gen_pool_alloc_data to pass data to
gen_pool_first_fit_align(modify gen_pool_alloc as a wrapper)

Signed-off-by: Zhao Qiang 
---
Changes for v6:
- patches set v6 include a new patch because of using 
- genalloc to manage QE MURAM, patch 0001 is the new 
- patch, adding bytes alignment for allocation for use.
Changes for v7:
- cpm muram also need to use genalloc to manage, it has 
  a function to reserve a specific region of muram,
  add offset to genpool_data for start addr to be allocated.
Changes for v8:
- remove supporting reserving a specific region from this patch
  add a new patch to support it.
Changes for v9:
- Nil 
Changes for v10:
- Nil
Changes for v11:
- Nil

 include/linux/genalloc.h | 24 
 lib/genalloc.c   | 58 +++-
 2 files changed, 73 insertions(+), 9 deletions(-)

diff --git a/include/linux/genalloc.h b/include/linux/genalloc.h
index 1ccaab4..aaf3dc2 100644
--- a/include/linux/genalloc.h
+++ b/include/linux/genalloc.h
@@ -30,10 +30,12 @@
 #ifndef __GENALLOC_H__
 #define __GENALLOC_H__
 
+#include 
 #include 
 
 struct device;
 struct device_node;
+struct gen_pool;
 
 /**
  * Allocation callback function type definition
@@ -47,7 +49,7 @@ typedef unsigned long (*genpool_algo_t)(unsigned long *map,
unsigned long size,
unsigned long start,
unsigned int nr,
-   void *data);
+   void *data, struct gen_pool *pool);
 
 /*
  *  General purpose special memory pool descriptor.
@@ -73,6 +75,13 @@ struct gen_pool_chunk {
unsigned long bits[0];  /* bitmap for allocating memory chunk */
 };
 
+/*
+ *  gen_pool data descriptor for gen_pool_first_fit_align.
+ */
+struct genpool_data_align {
+   int align;  /* alignment by bytes for starting address */
+};
+
 extern struct gen_pool *gen_pool_create(int, int);
 extern phys_addr_t gen_pool_virt_to_phys(struct gen_pool *pool, unsigned long);
 extern int gen_pool_add_virt(struct gen_pool *, unsigned long, phys_addr_t,
@@ -96,6 +105,7 @@ static inline int gen_pool_add(struct gen_pool *pool, 
unsigned long addr,
 }
 extern void gen_pool_destroy(struct gen_pool *);
 extern unsigned long gen_pool_alloc(struct gen_pool *, size_t);
+extern unsigned long gen_pool_alloc_data(struct gen_pool *, size_t, void 
*data);
 extern void *gen_pool_dma_alloc(struct gen_pool *pool, size_t size,
dma_addr_t *dma);
 extern void gen_pool_free(struct gen_pool *, unsigned long, size_t);
@@ -108,14 +118,20 @@ extern void gen_pool_set_algo(struct gen_pool *pool, 
genpool_algo_t algo,
void *data);
 
 extern unsigned long gen_pool_first_fit(unsigned long *map, unsigned long size,
-   unsigned long start, unsigned int nr, void *data);
+   unsigned long start, unsigned int nr, void *data,
+   struct gen_pool *pool);
+
+extern unsigned long gen_pool_first_fit_align(unsigned long *map,
+   unsigned long size, unsigned long start, unsigned int nr,
+   void *data, struct gen_pool *pool);
 
 extern unsigned long gen_pool_first_fit_order_align(unsigned long *map,
unsigned long size, unsigned long start, unsigned int nr,
-   void *data);
+   void *data, struct gen_pool *pool);
 
 extern unsigned long gen_pool_best_fit(unsigned long *map, unsigned long size,
-   unsigned long start, unsigned int nr, void *data);
+   unsigned long start, unsigned int nr, void *data,
+   struct gen_pool *pool);
 
 extern struct gen_pool *devm_gen_pool_create(struct device *dev,
int min_alloc_order, int nid);
diff --git a/lib/genalloc.c b/lib/genalloc.c
index d214866..b8762b1 100644
--- a/lib/genalloc.c
+++ b/lib/genalloc.c
@@ -269,6 +269,24 @@ EXPORT_SYMBOL(gen_pool_destroy);
  */
 unsigned long gen_pool_alloc(struct gen_pool *pool, size_t size)
 {
+   return gen_pool_alloc_data(pool, size, pool->data);
+}
+EXPORT_SYMBOL(gen_pool_alloc);
+
+/**
+ * gen_pool_alloc_data - allocate special memory from the pool
+ * @pool: pool to allocate from
+ * @size: number of bytes to allocate from the pool
+ * @data: data passed to algorithm
+ *
+ * Allocate the requested number of bytes from the specified pool.
+ * Uses the pool allocation function (with first-fit algorithm by default).
+ * Can not be used in NMI handler on architectures without
+ * NMI-safe cmpxchg implementation.
+ */
+unsigned long gen_pool_alloc_data(struct gen_pool *pool, size_t size,
+   void *data)
+{
struct gen_pool_chunk *chunk;
unsigned long addr = 0;
int order = pool->min_alloc_order;
@@ -290,7 

[PATCH v11 2/6] genalloc:support allocating specific region

2015-09-28 Thread Zhao Qiang
Add new algo for genalloc, it reserve a specific region of
memory matching the size requirement (no alignment constraint)

Signed-off-by: Zhao Qiang 
---
Changes for v9:
- reserve a specific region, if the return region
- is not during the specific region, return fail.
Changes for v10:
- rename gen_pool_fixed_fit to gen_pool_fixed_alloc
Changes for v11:
- rename gen_pool_fixed_fit to gen_pool_fixed_alloc


 include/linux/genalloc.h | 11 +++
 lib/genalloc.c   | 30 ++
 2 files changed, 41 insertions(+)

diff --git a/include/linux/genalloc.h b/include/linux/genalloc.h
index aaf3dc2..56d5d96 100644
--- a/include/linux/genalloc.h
+++ b/include/linux/genalloc.h
@@ -82,6 +82,13 @@ struct genpool_data_align {
int align;  /* alignment by bytes for starting address */
 };
 
+/*
+ *  gen_pool data descriptor for gen_pool_fixed_alloc.
+ */
+struct genpool_data_fixed {
+   unsigned long offset;   /* The offset of the specific region */
+};
+
 extern struct gen_pool *gen_pool_create(int, int);
 extern phys_addr_t gen_pool_virt_to_phys(struct gen_pool *pool, unsigned long);
 extern int gen_pool_add_virt(struct gen_pool *, unsigned long, phys_addr_t,
@@ -121,6 +128,10 @@ extern unsigned long gen_pool_first_fit(unsigned long 
*map, unsigned long size,
unsigned long start, unsigned int nr, void *data,
struct gen_pool *pool);
 
+extern unsigned long gen_pool_fixed_alloc(unsigned long *map,
+   unsigned long size, unsigned long start, unsigned int nr,
+   void *data, struct gen_pool *pool);
+
 extern unsigned long gen_pool_first_fit_align(unsigned long *map,
unsigned long size, unsigned long start, unsigned int nr,
void *data, struct gen_pool *pool);
diff --git a/lib/genalloc.c b/lib/genalloc.c
index b8762b1..1e6fde8 100644
--- a/lib/genalloc.c
+++ b/lib/genalloc.c
@@ -554,6 +554,36 @@ unsigned long gen_pool_first_fit_align(unsigned long *map, 
unsigned long size,
 EXPORT_SYMBOL(gen_pool_first_fit_align);
 
 /**
+ * gen_pool_fixed_alloc - reserve a specific region of
+ * matching the size requirement (no alignment constraint)
+ * @map: The address to base the search on
+ * @size: The bitmap size in bits
+ * @start: The bitnumber to start searching at
+ * @nr: The number of zeroed bits we're looking for
+ * @data: data for alignment
+ * @pool: pool to get order from
+ */
+unsigned long gen_pool_fixed_alloc(unsigned long *map, unsigned long size,
+   unsigned long start, unsigned int nr, void *data,
+   struct gen_pool *pool)
+{
+   struct genpool_data_fixed *fixed_data;
+   int order;
+   unsigned long offset_bit;
+   unsigned long start_bit;
+
+   fixed_data = data;
+   order = pool->min_alloc_order;
+   offset_bit = fixed_data->offset >> order;
+   start_bit = bitmap_find_next_zero_area(map, size,
+   start + offset_bit, nr, 0);
+   if (start_bit != offset_bit)
+   start_bit = size;
+   return start_bit;
+}
+EXPORT_SYMBOL(gen_pool_fixed_alloc);
+
+/**
  * gen_pool_first_fit_order_align - find the first available region
  * of memory matching the size requirement. The region will be aligned
  * to the order of the size specified.
-- 
2.1.0.27.g96db324

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[PATCH v11 3/6] CPM/QE: use genalloc to manage CPM/QE muram

2015-09-28 Thread Zhao Qiang
Use genalloc to manage CPM/QE muram instead of rheap.

Signed-off-by: Zhao Qiang 
---
Changes for v9:
- splitted from patch 3/5, modify cpm muram management functions.
Changes for v10:
- modify cpm muram first, then move to qe_common
- modify commit.
Changes for v11:
- factor out the common alloc code
- modify min_alloc_order to zero for cpm_muram_alloc_fixed.

 arch/powerpc/include/asm/cpm.h   |   1 +
 arch/powerpc/platforms/Kconfig   |   1 +
 arch/powerpc/sysdev/cpm_common.c | 129 +++
 3 files changed, 93 insertions(+), 38 deletions(-)

diff --git a/arch/powerpc/include/asm/cpm.h b/arch/powerpc/include/asm/cpm.h
index 4398a6c..0e1ac3f 100644
--- a/arch/powerpc/include/asm/cpm.h
+++ b/arch/powerpc/include/asm/cpm.h
@@ -161,6 +161,7 @@ int cpm_muram_init(void);
 unsigned long cpm_muram_alloc(unsigned long size, unsigned long align);
 int cpm_muram_free(unsigned long offset);
 unsigned long cpm_muram_alloc_fixed(unsigned long offset, unsigned long size);
+unsigned long cpm_muram_alloc_common(unsigned long size, void *data);
 void __iomem *cpm_muram_addr(unsigned long offset);
 unsigned long cpm_muram_offset(void __iomem *addr);
 dma_addr_t cpm_muram_dma(void __iomem *addr);
diff --git a/arch/powerpc/platforms/Kconfig b/arch/powerpc/platforms/Kconfig
index b7f9c40..01f98a2 100644
--- a/arch/powerpc/platforms/Kconfig
+++ b/arch/powerpc/platforms/Kconfig
@@ -276,6 +276,7 @@ config QUICC_ENGINE
bool "Freescale QUICC Engine (QE) Support"
depends on FSL_SOC && PPC32
select PPC_LIB_RHEAP
+   select GENERIC_ALLOCATOR
select CRC32
help
  The QUICC Engine (QE) is a new generation of communications
diff --git a/arch/powerpc/sysdev/cpm_common.c b/arch/powerpc/sysdev/cpm_common.c
index 4f78695..ff47072 100644
--- a/arch/powerpc/sysdev/cpm_common.c
+++ b/arch/powerpc/sysdev/cpm_common.c
@@ -17,6 +17,7 @@
  * published by the Free Software Foundation.
  */
 
+#include 
 #include 
 #include 
 #include 
@@ -27,7 +28,6 @@
 
 #include 
 #include 
-#include 
 #include 
 
 #include 
@@ -65,14 +65,22 @@ void __init udbg_init_cpm(void)
 }
 #endif
 
+static struct gen_pool *muram_pool;
 static spinlock_t cpm_muram_lock;
-static rh_block_t cpm_boot_muram_rh_block[16];
-static rh_info_t cpm_muram_info;
 static u8 __iomem *muram_vbase;
 static phys_addr_t muram_pbase;
 
-/* Max address size we deal with */
+struct muram_block {
+   struct list_head head;
+   unsigned long start;
+   int size;
+};
+
+static LIST_HEAD(muram_block_list);
+
+/* max address size we deal with */
 #define OF_MAX_ADDR_CELLS  4
+#define GENPOOL_OFFSET (4096 * 8)
 
 int cpm_muram_init(void)
 {
@@ -87,50 +95,52 @@ int cpm_muram_init(void)
return 0;
 
spin_lock_init(_muram_lock);
-   /* initialize the info header */
-   rh_init(_muram_info, 1,
-   sizeof(cpm_boot_muram_rh_block) /
-   sizeof(cpm_boot_muram_rh_block[0]),
-   cpm_boot_muram_rh_block);
-
np = of_find_compatible_node(NULL, NULL, "fsl,cpm-muram-data");
if (!np) {
/* try legacy bindings */
np = of_find_node_by_name(NULL, "data-only");
if (!np) {
-   printk(KERN_ERR "Cannot find CPM muram data node");
+   pr_err("Cannot find CPM muram data node");
ret = -ENODEV;
-   goto out;
+   goto out_muram;
}
}
 
+   muram_pool = gen_pool_create(0, -1);
muram_pbase = of_translate_address(np, zero);
if (muram_pbase == (phys_addr_t)OF_BAD_ADDR) {
-   printk(KERN_ERR "Cannot translate zero through CPM muram node");
+   pr_err("Cannot translate zero through CPM muram node");
ret = -ENODEV;
-   goto out;
+   goto out_pool;
}
 
while (of_address_to_resource(np, i++, ) == 0) {
if (r.end > max)
max = r.end;
+   ret = gen_pool_add(muram_pool, r.start - muram_pbase +
+  GENPOOL_OFFSET, resource_size(), -1);
+   if (ret) {
+   pr_err("QE: couldn't add muram to pool!\n");
+   goto out_pool;
+   }
 
-   rh_attach_region(_muram_info, r.start - muram_pbase,
-resource_size());
}
 
muram_vbase = ioremap(muram_pbase, max - muram_pbase + 1);
if (!muram_vbase) {
-   printk(KERN_ERR "Cannot map CPM muram");
+   pr_err("Cannot map QE muram");
ret = -ENOMEM;
+   goto out_pool;
}
-
-out:
+   goto out_muram;
+out_pool:
+   gen_pool_destroy(muram_pool);
+out_muram:
of_node_put(np);
return ret;

[PATCH v11 4/6] QE/CPM: move muram management functions to qe_common

2015-09-28 Thread Zhao Qiang
QE and CPM have the same muram, they use the same management
functions. Now QE support both ARM and PowerPC, it is necessary
to move QE to "driver/soc", so move the muram management functions
from cpm_common to qe_common for preparing to move QE code to "driver/soc"

Signed-off-by: Zhao Qiang 
---
Changes for v2:
- no changes
Changes for v3:
- no changes
Changes for v4:
- no changes
Changes for v5:
- no changes
Changes for v6:
- using genalloc instead rheap to manage QE MURAM
- remove qe_reset from platform file, using 
- subsys_initcall to call qe_init function.
Changes for v7:
- move this patch from 3/3 to 2/3
- convert cpm with genalloc
- check for gen_pool allocation failure
Changes for v8:
- rebase
- move BD_SC_* macro instead of copy
Changes for v9:
- doesn't modify CPM, add a new patch to modify.
- rebase
Changes for v10:
- rebase
Changes for v11:
- remove renaming
- delete removing qe_reset and delete adding qe_init.

 arch/powerpc/include/asm/cpm.h |  44 -
 arch/powerpc/include/asm/qe.h  |  16 ++
 arch/powerpc/sysdev/cpm_common.c   | 210 +
 arch/powerpc/sysdev/qe_lib/Makefile|   2 +-
 .../sysdev/{cpm_common.c => qe_lib/qe_common.c}| 188 +-
 5 files changed, 27 insertions(+), 433 deletions(-)
 copy arch/powerpc/sysdev/{cpm_common.c => qe_lib/qe_common.c} (54%)

diff --git a/arch/powerpc/include/asm/cpm.h b/arch/powerpc/include/asm/cpm.h
index 0e1ac3f..05a1c15 100644
--- a/arch/powerpc/include/asm/cpm.h
+++ b/arch/powerpc/include/asm/cpm.h
@@ -155,50 +155,6 @@ typedef struct cpm_buf_desc {
  */
 #define BD_I2C_START   (0x0400)
 
-int cpm_muram_init(void);
-
-#if defined(CONFIG_CPM) || defined(CONFIG_QUICC_ENGINE)
-unsigned long cpm_muram_alloc(unsigned long size, unsigned long align);
-int cpm_muram_free(unsigned long offset);
-unsigned long cpm_muram_alloc_fixed(unsigned long offset, unsigned long size);
-unsigned long cpm_muram_alloc_common(unsigned long size, void *data);
-void __iomem *cpm_muram_addr(unsigned long offset);
-unsigned long cpm_muram_offset(void __iomem *addr);
-dma_addr_t cpm_muram_dma(void __iomem *addr);
-#else
-static inline unsigned long cpm_muram_alloc(unsigned long size,
-   unsigned long align)
-{
-   return -ENOSYS;
-}
-
-static inline int cpm_muram_free(unsigned long offset)
-{
-   return -ENOSYS;
-}
-
-static inline unsigned long cpm_muram_alloc_fixed(unsigned long offset,
- unsigned long size)
-{
-   return -ENOSYS;
-}
-
-static inline void __iomem *cpm_muram_addr(unsigned long offset)
-{
-   return NULL;
-}
-
-static inline unsigned long cpm_muram_offset(void __iomem *addr)
-{
-   return -ENOSYS;
-}
-
-static inline dma_addr_t cpm_muram_dma(void __iomem *addr)
-{
-   return 0;
-}
-#endif /* defined(CONFIG_CPM) || defined(CONFIG_QUICC_ENGINE) */
-
 #ifdef CONFIG_CPM
 int cpm_command(u32 command, u8 opcode);
 #else
diff --git a/arch/powerpc/include/asm/qe.h b/arch/powerpc/include/asm/qe.h
index 32b9bfa..c2dd8e6 100644
--- a/arch/powerpc/include/asm/qe.h
+++ b/arch/powerpc/include/asm/qe.h
@@ -16,11 +16,15 @@
 #define _ASM_POWERPC_QE_H
 #ifdef __KERNEL__
 
+#include 
 #include 
 #include 
 #include 
 #include 
 #include 
+#include 
+#include 
+#include 
 
 #define QE_NUM_OF_SNUM 256 /* There are 256 serial number in QE */
 #define QE_NUM_OF_BRGS 16
@@ -92,6 +96,18 @@ extern void qe_reset(void);
 static inline void qe_reset(void) {}
 #endif
 
+int cpm_muram_init(void);
+
+#if defined(CONFIG_CPM) || defined(CONFIG_QUICC_ENGINE)
+unsigned long cpm_muram_alloc(unsigned long size, unsigned long align);
+int cpm_muram_free(unsigned long offset);
+unsigned long cpm_muram_alloc_fixed(unsigned long offset, unsigned long size);
+unsigned long cpm_muram_alloc_common(unsigned long size, void *data);
+void __iomem *cpm_muram_addr(unsigned long offset);
+unsigned long cpm_muram_offset(void __iomem *addr);
+dma_addr_t cpm_muram_dma(void __iomem *addr);
+#endif /* defined(CONFIG_CPM) || defined(CONFIG_QUICC_ENGINE) */
+
 /* QE PIO */
 #define QE_PIO_PINS 32
 
diff --git a/arch/powerpc/sysdev/cpm_common.c b/arch/powerpc/sysdev/cpm_common.c
index ff47072..6993aa8 100644
--- a/arch/powerpc/sysdev/cpm_common.c
+++ b/arch/powerpc/sysdev/cpm_common.c
@@ -17,7 +17,6 @@
  * published by the Free Software Foundation.
  */
 
-#include 
 #include 
 #include 
 #include 
@@ -29,6 +28,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 
@@ -65,214 +65,6 @@ void __init udbg_init_cpm(void)
 }
 #endif
 
-static struct gen_pool *muram_pool;
-static spinlock_t cpm_muram_lock;
-static u8 __iomem *muram_vbase;
-static phys_addr_t muram_pbase;
-
-struct muram_block {
-   struct list_head head;
- 

[PATCH v11 5/6] QE: use subsys_initcall to init qe

2015-09-28 Thread Zhao Qiang
Use subsys_initcall to init qe to adapt ARM architecture.
Remove qe_reset from PowerPC platform file.

Signed-off-by: Zhao Qiang 
---
 arch/powerpc/platforms/83xx/km83xx.c  |  2 --
 arch/powerpc/platforms/83xx/mpc832x_mds.c |  2 --
 arch/powerpc/platforms/83xx/mpc832x_rdb.c |  2 --
 arch/powerpc/platforms/83xx/mpc836x_mds.c |  2 --
 arch/powerpc/platforms/83xx/mpc836x_rdk.c |  3 ---
 arch/powerpc/platforms/85xx/common.c  |  1 -
 arch/powerpc/sysdev/qe_lib/qe.c   | 15 +++
 7 files changed, 15 insertions(+), 12 deletions(-)

diff --git a/arch/powerpc/platforms/83xx/km83xx.c 
b/arch/powerpc/platforms/83xx/km83xx.c
index bf4c447..ae111581 100644
--- a/arch/powerpc/platforms/83xx/km83xx.c
+++ b/arch/powerpc/platforms/83xx/km83xx.c
@@ -136,8 +136,6 @@ static void __init mpc83xx_km_setup_arch(void)
mpc83xx_setup_pci();
 
 #ifdef CONFIG_QUICC_ENGINE
-   qe_reset();
-
np = of_find_node_by_name(NULL, "par_io");
if (np != NULL) {
par_io_init(np);
diff --git a/arch/powerpc/platforms/83xx/mpc832x_mds.c 
b/arch/powerpc/platforms/83xx/mpc832x_mds.c
index 8d76220..aacc43f 100644
--- a/arch/powerpc/platforms/83xx/mpc832x_mds.c
+++ b/arch/powerpc/platforms/83xx/mpc832x_mds.c
@@ -74,8 +74,6 @@ static void __init mpc832x_sys_setup_arch(void)
mpc83xx_setup_pci();
 
 #ifdef CONFIG_QUICC_ENGINE
-   qe_reset();
-
if ((np = of_find_node_by_name(NULL, "par_io")) != NULL) {
par_io_init(np);
of_node_put(np);
diff --git a/arch/powerpc/platforms/83xx/mpc832x_rdb.c 
b/arch/powerpc/platforms/83xx/mpc832x_rdb.c
index eff5baa..0c7a43e 100644
--- a/arch/powerpc/platforms/83xx/mpc832x_rdb.c
+++ b/arch/powerpc/platforms/83xx/mpc832x_rdb.c
@@ -203,8 +203,6 @@ static void __init mpc832x_rdb_setup_arch(void)
mpc83xx_setup_pci();
 
 #ifdef CONFIG_QUICC_ENGINE
-   qe_reset();
-
if ((np = of_find_node_by_name(NULL, "par_io")) != NULL) {
par_io_init(np);
of_node_put(np);
diff --git a/arch/powerpc/platforms/83xx/mpc836x_mds.c 
b/arch/powerpc/platforms/83xx/mpc836x_mds.c
index 1a26d2f..eb24abd 100644
--- a/arch/powerpc/platforms/83xx/mpc836x_mds.c
+++ b/arch/powerpc/platforms/83xx/mpc836x_mds.c
@@ -82,8 +82,6 @@ static void __init mpc836x_mds_setup_arch(void)
mpc83xx_setup_pci();
 
 #ifdef CONFIG_QUICC_ENGINE
-   qe_reset();
-
if ((np = of_find_node_by_name(NULL, "par_io")) != NULL) {
par_io_init(np);
of_node_put(np);
diff --git a/arch/powerpc/platforms/83xx/mpc836x_rdk.c 
b/arch/powerpc/platforms/83xx/mpc836x_rdk.c
index b63b42d..823e370 100644
--- a/arch/powerpc/platforms/83xx/mpc836x_rdk.c
+++ b/arch/powerpc/platforms/83xx/mpc836x_rdk.c
@@ -35,9 +35,6 @@ static void __init mpc836x_rdk_setup_arch(void)
ppc_md.progress("mpc836x_rdk_setup_arch()", 0);
 
mpc83xx_setup_pci();
-#ifdef CONFIG_QUICC_ENGINE
-   qe_reset();
-#endif
 }
 
 /*
diff --git a/arch/powerpc/platforms/85xx/common.c 
b/arch/powerpc/platforms/85xx/common.c
index 7bfb9b1..0f91edc 100644
--- a/arch/powerpc/platforms/85xx/common.c
+++ b/arch/powerpc/platforms/85xx/common.c
@@ -105,7 +105,6 @@ void __init mpc85xx_qe_init(void)
return;
}
 
-   qe_reset();
of_node_put(np);
 
 }
diff --git a/arch/powerpc/sysdev/qe_lib/qe.c b/arch/powerpc/sysdev/qe_lib/qe.c
index c2518cd..3f9f596 100644
--- a/arch/powerpc/sysdev/qe_lib/qe.c
+++ b/arch/powerpc/sysdev/qe_lib/qe.c
@@ -671,6 +671,21 @@ unsigned int qe_get_num_of_snums(void)
 }
 EXPORT_SYMBOL(qe_get_num_of_snums);
 
+static int __init qe_init(void)
+{
+   struct device_node *np;
+
+   np = of_find_compatible_node(NULL, NULL, "fsl,qe");
+   if (!np) {
+   pr_err("%s: Could not find Quicc Engine node\n", __func__);
+   return -ENODEV;
+   }
+   qe_reset();
+   of_node_put(np);
+   return 0;
+}
+subsys_initcall(qe_init);
+
 #if defined(CONFIG_SUSPEND) && defined(CONFIG_PPC_85xx)
 static int qe_resume(struct platform_device *ofdev)
 {
-- 
2.1.0.27.g96db324

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[PATCH v11 6/6] QE: Move QE from arch/powerpc to drivers/soc

2015-09-28 Thread Zhao Qiang
ls1 has qe and ls1 has arm cpu.
move qe from arch/powerpc to drivers/soc/fsl
to adapt to powerpc and arm

Signed-off-by: Zhao Qiang 
---
Changes for v2:
- move code to driver/soc
Changes for v3:
- change drivers/soc/qe to drivers/soc/fsl-qe
Changes for v4:
- move drivers/soc/fsl-qe to drivers/soc/fsl/qe
- move head files for qe from include/linux/fsl to include/soc/fsl
- move qe_ic.c to drivers/irqchip/
Changes for v5:
- update MAINTAINERS
Changes for v6:
- rebase
Changes for v7:
- move this patch from 2/3 to 3/3
Changes for v8:
- Nil 
Changes for v9:
- Nil 
Changes for v10:
- Nil 
Changes for v11:
- rebase

 MAINTAINERS|  5 ++--
 arch/powerpc/platforms/83xx/km83xx.c   |  4 +--
 arch/powerpc/platforms/83xx/misc.c |  2 +-
 arch/powerpc/platforms/83xx/mpc832x_mds.c  |  4 +--
 arch/powerpc/platforms/83xx/mpc832x_rdb.c  |  4 +--
 arch/powerpc/platforms/83xx/mpc836x_mds.c  |  4 +--
 arch/powerpc/platforms/83xx/mpc836x_rdk.c  |  4 +--
 arch/powerpc/platforms/85xx/common.c   |  2 +-
 arch/powerpc/platforms/85xx/corenet_generic.c  |  2 +-
 arch/powerpc/platforms/85xx/mpc85xx_mds.c  |  4 +--
 arch/powerpc/platforms/85xx/mpc85xx_rdb.c  |  4 +--
 arch/powerpc/platforms/85xx/twr_p102x.c|  4 +--
 arch/powerpc/platforms/Kconfig | 20 -
 arch/powerpc/sysdev/cpm_common.c   |  2 +-
 arch/powerpc/sysdev/qe_lib/Kconfig | 22 ---
 arch/powerpc/sysdev/qe_lib/Makefile|  6 +---
 arch/powerpc/sysdev/qe_lib/gpio.c  |  2 +-
 arch/powerpc/sysdev/qe_lib/qe_io.c |  2 +-
 arch/powerpc/sysdev/qe_lib/usb.c   |  4 +--
 drivers/irqchip/Makefile   |  1 +
 .../sysdev/qe_lib => drivers/irqchip}/qe_ic.c  |  2 +-
 .../sysdev/qe_lib => drivers/irqchip}/qe_ic.h  |  4 +--
 drivers/net/ethernet/freescale/fsl_pq_mdio.c   |  2 +-
 drivers/net/ethernet/freescale/ucc_geth.c  |  8 +++---
 drivers/net/ethernet/freescale/ucc_geth.h  |  8 +++---
 drivers/soc/Kconfig|  1 +
 drivers/soc/Makefile   |  1 +
 drivers/soc/fsl/Makefile   |  5 
 drivers/soc/fsl/qe/Kconfig | 33 ++
 drivers/soc/fsl/qe/Makefile|  9 ++
 .../sysdev/qe_lib => drivers/soc/fsl/qe}/qe.c  |  4 +--
 .../qe_lib => drivers/soc/fsl/qe}/qe_common.c  |  2 +-
 .../sysdev/qe_lib => drivers/soc/fsl/qe}/ucc.c |  6 ++--
 .../qe_lib => drivers/soc/fsl/qe}/ucc_fast.c   |  8 +++---
 .../qe_lib => drivers/soc/fsl/qe}/ucc_slow.c   |  8 +++---
 drivers/spi/spi-fsl-cpm.c  |  2 +-
 drivers/tty/serial/ucc_uart.c  |  2 +-
 drivers/usb/gadget/udc/fsl_qe_udc.c|  2 +-
 drivers/usb/host/fhci-hcd.c|  2 +-
 drivers/usb/host/fhci-hub.c|  2 +-
 drivers/usb/host/fhci-sched.c  |  2 +-
 drivers/usb/host/fhci.h|  4 +--
 .../include/asm => include/linux/fsl/qe}/qe_ic.h   |  0
 .../include/asm => include/soc/fsl/qe}/immap_qe.h  |  0
 .../include/asm => include/soc/fsl/qe}/qe.h|  2 +-
 .../include/asm => include/soc/fsl/qe}/ucc.h   |  4 +--
 .../include/asm => include/soc/fsl/qe}/ucc_fast.h  |  6 ++--
 .../include/asm => include/soc/fsl/qe}/ucc_slow.h  |  6 ++--
 48 files changed, 127 insertions(+), 110 deletions(-)
 rename {arch/powerpc/sysdev/qe_lib => drivers/irqchip}/qe_ic.c (99%)
 rename {arch/powerpc/sysdev/qe_lib => drivers/irqchip}/qe_ic.h (97%)
 create mode 100644 drivers/soc/fsl/Makefile
 create mode 100644 drivers/soc/fsl/qe/Kconfig
 create mode 100644 drivers/soc/fsl/qe/Makefile
 rename {arch/powerpc/sysdev/qe_lib => drivers/soc/fsl/qe}/qe.c (99%)
 rename {arch/powerpc/sysdev/qe_lib => drivers/soc/fsl/qe}/qe_common.c (99%)
 rename {arch/powerpc/sysdev/qe_lib => drivers/soc/fsl/qe}/ucc.c (98%)
 rename {arch/powerpc/sysdev/qe_lib => drivers/soc/fsl/qe}/ucc_fast.c (98%)
 rename {arch/powerpc/sysdev/qe_lib => drivers/soc/fsl/qe}/ucc_slow.c (98%)
 rename {arch/powerpc/include/asm => include/linux/fsl/qe}/qe_ic.h (100%)
 rename {arch/powerpc/include/asm => include/soc/fsl/qe}/immap_qe.h (100%)
 rename {arch/powerpc/include/asm => include/soc/fsl/qe}/qe.h (99%)
 rename {arch/powerpc/include/asm => include/soc/fsl/qe}/ucc.h (96%)
 rename {arch/powerpc/include/asm => include/soc/fsl/qe}/ucc_fast.h (98%)
 rename {arch/powerpc/include/asm => include/soc/fsl/qe}/ucc_slow.h (99%)

diff --git a/MAINTAINERS b/MAINTAINERS
index 562ae4e..c688e61 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -4155,8 +4155,9 @@ F:

Re: [PATCH v2 11/25] powerpc/8xx: map 16M RAM at startup

2015-09-28 Thread Scott Wood
On Tue, Sep 22, 2015 at 06:50:50PM +0200, Christophe Leroy wrote:
> On recent kernels, with some debug options like for instance
> CONFIG_LOCKDEP, the BSS requires more than 8M memory, allthough
> the kernel code fits in the first 8M.
> Today, it is necessary to activate CONFIG_PIN_TLB to get more than 8M
> at startup, allthough pinning TLB is not necessary for that.
> 
> This patch adds a second 8M page to the initial mapping in order to
> have 16M mapped regardless of CONFIG_PIN_TLB, like several other
> 32 bits PPC (40x, 601, ...)
> 
> Signed-off-by: Christophe Leroy 
> ---

Is the assumption that nobody is still running 8xx systems with only 8
MiB RAM on current kernels?

-Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH 00/31] powerpc/mm: Update page table format for book3s 64

2015-09-28 Thread Benjamin Herrenschmidt
On Mon, 2015-09-28 at 10:26 +0530, Aneesh Kumar K.V wrote:
> > In any case, "nohash" is the term used elsewhere.
> 
> How about using swtlb ? (nohash always confused me, It would be nice 
> to be explict and us software tlb ?)

Stick to nohash, that's been our convention so far, I don't see
the point in changing it.

Cheers,
Ben.

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH v2 20/25] powerpc32: Remove clear_pages() and define clear_page() inline

2015-09-28 Thread Scott Wood
On Tue, Sep 22, 2015 at 06:51:09PM +0200, Christophe Leroy wrote:
> clear_pages() is never used, and PPC32 is the only architecture
> (still) having this function. Neither PPC64 nor any other
> architecture has it.

It is used, by clear_page().

> This patch removes clear_page() and move clear_page() function
> inline (same as PPC64) as it only is a few isns

It removes clear_pages(), not clear_page().

-Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH v2 22/25] powerpc32: move xxxxx_dcache_range() functions inline

2015-09-28 Thread Scott Wood
On Tue, Sep 22, 2015 at 06:51:13PM +0200, Christophe Leroy wrote:
> flush/clean/invalidate _dcache_range() functions are all very
> similar and are quite short. They are mainly used in __dma_sync()
> perf_event locate them in the top 3 consumming functions during
> heavy ethernet activity
> 
> They are good candidate for inlining, as __dma_sync() does
> almost nothing but calling them
> 
> Signed-off-by: Christophe Leroy 
> ---
> New in v2
> 
>  arch/powerpc/include/asm/cacheflush.h | 55 +++--
>  arch/powerpc/kernel/misc_32.S | 65 
> ---
>  arch/powerpc/kernel/ppc_ksyms.c   |  2 ++
>  3 files changed, 54 insertions(+), 68 deletions(-)
> 
> diff --git a/arch/powerpc/include/asm/cacheflush.h 
> b/arch/powerpc/include/asm/cacheflush.h
> index 6229e6b..6169604 100644
> --- a/arch/powerpc/include/asm/cacheflush.h
> +++ b/arch/powerpc/include/asm/cacheflush.h
> @@ -47,12 +47,61 @@ static inline void __flush_dcache_icache_phys(unsigned 
> long physaddr)
>  }
>  #endif
>  
> -extern void flush_dcache_range(unsigned long start, unsigned long stop);
>  #ifdef CONFIG_PPC32
> -extern void clean_dcache_range(unsigned long start, unsigned long stop);
> -extern void invalidate_dcache_range(unsigned long start, unsigned long stop);
> +/*
> + * Write any modified data cache blocks out to memory and invalidate them.
> + * Does not invalidate the corresponding instruction cache blocks.
> + */
> +static inline void flush_dcache_range(unsigned long start, unsigned long 
> stop)
> +{
> + void *addr = (void *)(start & ~(L1_CACHE_BYTES - 1));
> + unsigned int size = stop - (unsigned long)addr + (L1_CACHE_BYTES - 1);
> + unsigned int i;
> +
> + for (i = 0; i < size >> L1_CACHE_SHIFT; i++, addr += L1_CACHE_BYTES)
> + dcbf(addr);
> + if (i)
> + mb();   /* sync */
> +}

I know this is 32-bit-specific code, but it's still bad practice to use
"unsigned int" for addresses or sizes thereof.

-Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH v2 14/25] powerpc32: remove ioremap_base

2015-09-28 Thread Scott Wood
On Tue, Sep 22, 2015 at 06:50:56PM +0200, Christophe Leroy wrote:
> ioremap_base is not initialised and is nowhere used so remove it
> 
> Signed-off-by: Christophe Leroy 
> ---
> No change in v2

Could you also clean up the references to ioremap_base in the comments?

-Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[PATCH v17 00/19] perf, tools: Add support for PMU events in JSON format

2015-09-28 Thread Sukadev Bhattiprolu
CPUs support a large number of performance monitoring events (PMU events)
and often these events are very specific to an architecture/model of the
CPU. To use most of these PMU events with perf, we currently have to identify
them by their raw codes:

perf stat -e r100f2 sleep 1

This patchset allows architectures to specify these PMU events in JSON
files located in 'tools/perf/pmu-events/arch/' of the mainline tree.
The events from the JSON files for the architecture are then built into
the perf binary.

At run time, perf identifies the specific set of events for the CPU and
creates "event aliases". These aliases allow users to specify events by
"name" as:

perf stat -e pm_1plus_ppc_cmpl sleep 1

The file, 'tools/perf/pmu-events/README' in [PATCH 16/16] gives more
details.

Note:
- All known events tables for the architecture are included in the
  perf binary.

- For architectures that don't have any JSON files, an empty mapping
  table is created and they should continue to build.

Thanks to input from Andi Kleen, Jiri Olsa, Namhyung Kim and Ingo Molnar.

These patches are available from:

https://github.com/sukadev/linux.git 

Branch  Description
--
json-code-v17   Source Code only 
json-data-8 x86 and Powerpc datafiles only
json-code+data-v17  Both code and data (for build/test)

NOTE:   Only "source code" patches (i.e those in json-code-v17) are being
emailed.  Please pull the "data files" from the json-data-8 branch.

Changelog[v17]
Rebase to recent perf/core; couple of small fixes to processing Intel
JSON files; allow case-insensitive PMU event names.

Changelog[v16]
Rebase to recent perf/core; fix minor merge conflicts; drop 3 patches
that were merged into perf/core.

Changelog[v15]
Code changes:
- Fix 'perf list' usage string and update man page.
- Remove a redundant __maybe_unused tag.
- Rebase to recent perf/core branch.

Data files updates: json-files-5 branch
- Rebase to perf/intel-json-files-5 from Andi Kleen
- Add patch from Madhavan Srinivasan for couple more Powerpc models

Changelog[v14]
Comments from Jiri Olsa:
- Change parameter name/type for pmu_add_cpu_aliases (from void *data
  to list_head *head)
- Use asprintf() in file_name_to_tablename() and simplify/reorg code.
- Use __weak definition from 
- Use fopen() with mode "w" and eliminate unlink()
- Remove minor TODO.
- Add error check for return value from strdup() in print_pmu_events().
- Move independent changes from patches 3,11,12 .. to separate patches
  for easier review/backport.
- Clarify mapfile's "header line support" in patch description.
- Fix build failure with DEBUG=1

Comment from Andi Kleen:
- In tools/perf/pmu-events/Build, check for 'mapfile.csv' rather than
  'mapfile*'

Misc:
- Minor changes/clarifications to tools/perf/pmu-events/README.


Changelog[v13]
Version: Individual patches have their own history :-) that I am
preserving. Patchset version (v13) is for overall patchset and is
somewhat arbitrary.

- Added support for "categories" of events to perf
- Add mapfile, jevents build dependency on pmu-events.c
- Silence jevents when parsing JSON files unless V=1 is specified
- Cleanup error messages
- Fix memory leak with ->cpuid
- Rebase to Arnaldo's tree
- Allow overriding CPUID via environment variable
- Support long descriptions for events
- Handle header line in mapfile.csv
- Cleanup JSON files (trim PublicDescription if identical to/prefix of
  BriefDescription field)


Andi Kleen (12):
  perf, tools: Add jsmn `jasmine' JSON parser
  perf, tools, jevents: Program to convert JSON file to C style file
  perf, tools: Support CPU id matching for x86 v2
  perf, tools: Support alias descriptions
  perf, tools: Query terminal width and use in perf list
  perf, tools: Add a --no-desc flag to perf list
  perf, tools: Add override support for event list CPUID
  perf, tools: Add support for event list topics
  perf, tools: Handle header line in mapfile
  perf, tools: Make alias matching case-insensitive
  perf, tools, pmu-events: Fix fixed counters on Intel
  perf, tools, pmu-events: Add Skylake frontend MSR support

Sukadev Bhattiprolu (8):
  perf: Fix build break on powerpc due to sample_reg_masks
  perf, tools: Use pmu_events table to create aliases
  perf, tools: Support CPU ID matching for Powerpc
  perf, tools, jevents: Add support for long descriptions
  perf, tools: Add alias support for long descriptions
  perf, tools: Support long descriptions with perf list
  perf, tools, 

[PATCH v17 02/19] perf, tools, jevents: Program to convert JSON file to C style file

2015-09-28 Thread Sukadev Bhattiprolu
From: Andi Kleen 

This is a modified version of an earlier patch by Andi Kleen.

We expect architectures to describe the performance monitoring events
for each CPU in a corresponding JSON file, which look like:

[
{
"EventCode": "0x00",
"UMask": "0x01",
"EventName": "INST_RETIRED.ANY",
"BriefDescription": "Instructions retired from execution.",
"PublicDescription": "Instructions retired from execution.",
"Counter": "Fixed counter 1",
"CounterHTOff": "Fixed counter 1",
"SampleAfterValue": "203",
"SampleAfterValue": "203",
"MSRIndex": "0",
"MSRValue": "0",
"TakenAlone": "0",
"CounterMask": "0",
"Invert": "0",
"AnyThread": "0",
"EdgeDetect": "0",
"PEBS": "0",
"PRECISE_STORE": "0",
"Errata": "null",
"Offcore": "0"
}
]

We also expect the architectures to provide a mapping between individual
CPUs to their JSON files. Eg:

GenuineIntel-6-1E,V1,/NHM-EP/NehalemEP_core_V1.json,core

which maps each CPU, identified by [vendor, family, model, version, type]
to a JSON file.

Given these files, the program, jevents::
- locates all JSON files for the architecture,
- parses each JSON file and generates a C-style "PMU-events table"
  (pmu-events.c)
- locates a mapfile for the architecture
- builds a global table, mapping each model of CPU to the
  corresponding PMU-events table.

The 'pmu-events.c' is generated when building perf and added to libperf.a.
The global table pmu_events_map[] table in this pmu-events.c will be used
in perf in a follow-on patch.

If the architecture does not have any JSON files or there is an error in
processing them, an empty mapping file is created. This would allow the
build of perf to proceed even if we are not able to provide aliases for
events.

The parser for JSON files allows parsing Intel style JSON event files. This
allows to use an Intel event list directly with perf. The Intel event lists
can be quite large and are too big to store in unswappable kernel memory.

The conversion from JSON to C-style is straight forward.  The parser knows
(very little) Intel specific information, and can be easily extended to
handle fields for other CPUs.

The parser code is partially shared with an independent parsing library,
which is 2-clause BSD licenced. To avoid any conflicts I marked those
files as BSD licenced too. As part of perf they become GPLv2.

Signed-off-by: Andi Kleen 
Signed-off-by: Sukadev Bhattiprolu 
Acked-by: Jiri Olsa 
---

v2: Address review feedback. Rename option to --event-files
v3: Add JSON example
v4: Update manpages.
v5: Don't remove dot in fixname. Fix compile error. Add include
protection. Comment realloc.
v6: Include debug/util.h
v7: (Sukadev Bhattiprolu)
Rebase to 4.0 and fix some conflicts.
v8: (Sukadev Bhattiprolu)
Move jevents.[hc] to tools/perf/pmu-events/
Rewrite to locate and process arch specific JSON and "map" files;
and generate a C file.
(Removed acked-by Namhyung Kim due to modest changes to patch)
Compile the generated pmu-events.c and add the pmu-events.o to
libperf.a
v9: [Sukadev Bhattiprolu/Andi Kleen] Rename ->vfm to ->cpuid and use
that field to encode the PVR in Power.
Allow blank lines in mapfile.
[Jiri Olsa] Pass ARCH as a parameter to jevents so we don't have
to detect it.
[Jiri Olsa] Use the infrastrastructure to build pmu-events/perf
(Makefile changes from Jiri included in this patch).
[Jiri Olsa, Andi Kleen] Detect changes to JSON files and rebuild
pmu-events.o only if necessary.

v11:- [Andi Kleen] Add mapfile, jevents dependency on pmu-events.c
- [Jiri Olsa] Be silient if arch doesn't have JSON files
- Also silence 'jevents' when parsing JSON files unless V=1 is
  specified during build. Cleanup error messages.

v14:-   - [Jiri Olsa] Fix compile error with DEBUG=1; drop unlink() and
  use "w" mode with fopen(); simplify file_name_to_table_name()

v15:- Fix minor conflict in tools/perf/Makefile.perf when rebasing
  to recent perf/core.

v16:- Rebase to upstream; fix conflicts in tools/perf/Makefile.perf
---
 tools/perf/Makefile.perf   |  26 +-
 tools/perf/pmu-events/Build|  11 +
 tools/perf/pmu-events/jevents.c| 686 +
 tools/perf/pmu-events/jevents.h|  17 +
 tools/perf/pmu-events/json.h   |   3 +
 tools/perf/pmu-events/pmu-events.h |  35 ++
 6 files changed, 774 insertions(+), 4 deletions(-)
 create mode 100644 tools/perf/pmu-events/Build
 create mode 100644 tools/perf/pmu-events/jevents.c
 create mode 100644 tools/perf/pmu-events/jevents.h
 create mode 100644 

[PATCH v17 05/19] perf, tools: Support CPU id matching for x86 v2

2015-09-28 Thread Sukadev Bhattiprolu
From: Andi Kleen 

Implement the code to match CPU types to mapfile types for x86
based on CPUID. This extends an existing similar function,
but changes it to use the x86 mapfile cpu description.
This allows to resolve event lists generated by jevents.

Signed-off-by: Andi Kleen 
Signed-off-by: Sukadev Bhattiprolu 
Acked-by: Jiri Olsa 
---

v2: Update to new get_cpuid_str() interface
---
 tools/perf/arch/x86/util/header.c | 24 +---
 1 file changed, 21 insertions(+), 3 deletions(-)

diff --git a/tools/perf/arch/x86/util/header.c 
b/tools/perf/arch/x86/util/header.c
index 146d12a..a74a48d 100644
--- a/tools/perf/arch/x86/util/header.c
+++ b/tools/perf/arch/x86/util/header.c
@@ -19,8 +19,8 @@ cpuid(unsigned int op, unsigned int *a, unsigned int *b, 
unsigned int *c,
: "a" (op));
 }
 
-int
-get_cpuid(char *buffer, size_t sz)
+static int
+__get_cpuid(char *buffer, size_t sz, const char *fmt)
 {
unsigned int a, b, c, d, lvl;
int family = -1, model = -1, step = -1;
@@ -48,7 +48,7 @@ get_cpuid(char *buffer, size_t sz)
if (family >= 0x6)
model += ((a >> 16) & 0xf) << 4;
}
-   nb = scnprintf(buffer, sz, "%s,%u,%u,%u$", vendor, family, model, step);
+   nb = scnprintf(buffer, sz, fmt, vendor, family, model, step);
 
/* look for end marker to ensure the entire data fit */
if (strchr(buffer, '$')) {
@@ -57,3 +57,21 @@ get_cpuid(char *buffer, size_t sz)
}
return -1;
 }
+
+int
+get_cpuid(char *buffer, size_t sz)
+{
+   return __get_cpuid(buffer, sz, "%s,%u,%u,%u$");
+}
+
+char *
+get_cpuid_str(void)
+{
+   char *buf = malloc(128);
+
+   if (__get_cpuid(buf, 128, "%s-%u-%X$") < 0) {
+   free(buf);
+   return NULL;
+   }
+   return buf;
+}
-- 
2.5.3

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[PATCH v17 06/19] perf, tools: Support alias descriptions

2015-09-28 Thread Sukadev Bhattiprolu
From: Andi Kleen 

Add support to print alias descriptions in perf list, which
are taken from the generated event files.

The sorting code is changed to put the events with descriptions
at the end. The descriptions are printed as possibly multiple word
wrapped lines.

Example output:

% perf list
...
  arith.fpu_div
   [Divide operations executed]
  arith.fpu_div_active
   [Cycles when divider is busy executing divide operations]

Signed-off-by: Andi Kleen 
Signed-off-by: Sukadev Bhattiprolu 
Acked-by: Jiri Olsa 
---

Changelog
- Delete a redundant free()

Changelog[v14]
- [Jiri Olsa] Fail, rather than continue if strdup() returns NULL;
  remove unnecessary __maybe_unused.
---
 tools/perf/util/pmu.c | 82 +--
 tools/perf/util/pmu.h |  1 +
 2 files changed, 67 insertions(+), 16 deletions(-)

diff --git a/tools/perf/util/pmu.c b/tools/perf/util/pmu.c
index b8f7627..cb0396e 100644
--- a/tools/perf/util/pmu.c
+++ b/tools/perf/util/pmu.c
@@ -209,7 +209,7 @@ static int perf_pmu__parse_snapshot(struct perf_pmu_alias 
*alias,
 }
 
 static int __perf_pmu__new_alias(struct list_head *list, char *dir, char *name,
-char *desc __maybe_unused, char *val)
+char *desc, char *val)
 {
struct perf_pmu_alias *alias;
int ret;
@@ -241,6 +241,8 @@ static int __perf_pmu__new_alias(struct list_head *list, 
char *dir, char *name,
perf_pmu__parse_snapshot(alias, dir, name);
}
 
+   alias->desc = desc ? strdup(desc) : NULL;
+
list_add_tail(>list, list);
 
return 0;
@@ -1030,11 +1032,42 @@ static char *format_alias_or(char *buf, int len, struct 
perf_pmu *pmu,
return buf;
 }
 
-static int cmp_string(const void *a, const void *b)
+struct pair {
+   char *name;
+   char *desc;
+};
+
+static int cmp_pair(const void *a, const void *b)
+{
+   const struct pair *as = a;
+   const struct pair *bs = b;
+
+   /* Put extra events last */
+   if (!!as->desc != !!bs->desc)
+   return !!as->desc - !!bs->desc;
+   return strcmp(as->name, bs->name);
+}
+
+static void wordwrap(char *s, int start, int max, int corr)
 {
-   const char * const *as = a;
-   const char * const *bs = b;
-   return strcmp(*as, *bs);
+   int column = start;
+   int n;
+
+   while (*s) {
+   int wlen = strcspn(s, " \t");
+
+   if (column + wlen >= max && column > start) {
+   printf("\n%*s", start, "");
+   column = start + corr;
+   }
+   n = printf("%s%.*s", column > start ? " " : "", wlen, s);
+   if (n <= 0)
+   break;
+   s += wlen;
+   column += n;
+   while (isspace(*s))
+   s++;
+   }
 }
 
 void print_pmu_events(const char *event_glob, bool name_only)
@@ -1044,7 +1077,9 @@ void print_pmu_events(const char *event_glob, bool 
name_only)
char buf[1024];
int printed = 0;
int len, j;
-   char **aliases;
+   struct pair *aliases;
+   int numdesc = 0;
+   int columns = 78;
 
pmu = NULL;
len = 0;
@@ -1054,14 +1089,15 @@ void print_pmu_events(const char *event_glob, bool 
name_only)
if (pmu->selectable)
len++;
}
-   aliases = zalloc(sizeof(char *) * len);
+   aliases = zalloc(sizeof(struct pair) * len);
if (!aliases)
goto out_enomem;
pmu = NULL;
j = 0;
while ((pmu = perf_pmu__scan(pmu)) != NULL) {
list_for_each_entry(alias, >aliases, list) {
-   char *name = format_alias(buf, sizeof(buf), pmu, alias);
+   char *name = alias->desc ? alias->name :
+   format_alias(buf, sizeof(buf), pmu, alias);
bool is_cpu = !strcmp(pmu->name, "cpu");
 
if (event_glob != NULL &&
@@ -1070,37 +1106,51 @@ void print_pmu_events(const char *event_glob, bool 
name_only)
   event_glob
continue;
 
-   if (is_cpu && !name_only)
+   if (is_cpu && !name_only && !alias->desc)
name = format_alias_or(buf, sizeof(buf), pmu, 
alias);
 
-   aliases[j] = strdup(name);
-   if (aliases[j] == NULL)
+   aliases[j].name = name;
+   if (is_cpu && !name_only && !alias->desc)
+   aliases[j].name = format_alias_or(buf, 
sizeof(buf),
+ pmu, alias);
+   

[PATCH v17 08/19] perf, tools: Add a --no-desc flag to perf list

2015-09-28 Thread Sukadev Bhattiprolu
From: Andi Kleen 

Add a --no-desc flag to perf list to not print the event descriptions
that were earlier added for JSON events. This may be useful to
get a less crowded listing.

It's still default to print descriptions as that is the more useful
default for most users.

Signed-off-by: Andi Kleen 
Signed-off-by: Sukadev Bhattiprolu 
Acked-by: Jiri Olsa 
---

v2: Rename --quiet to --no-desc. Add option to man page.
---
 tools/perf/Documentation/perf-list.txt |  8 +++-
 tools/perf/builtin-list.c  | 12 
 tools/perf/util/parse-events.c |  4 ++--
 tools/perf/util/parse-events.h |  2 +-
 tools/perf/util/pmu.c  |  4 ++--
 tools/perf/util/pmu.h  |  2 +-
 6 files changed, 21 insertions(+), 11 deletions(-)

diff --git a/tools/perf/Documentation/perf-list.txt 
b/tools/perf/Documentation/perf-list.txt
index bada893..9507552 100644
--- a/tools/perf/Documentation/perf-list.txt
+++ b/tools/perf/Documentation/perf-list.txt
@@ -8,13 +8,19 @@ perf-list - List all symbolic event types
 SYNOPSIS
 
 [verse]
-'perf list' [hw|sw|cache|tracepoint|pmu|event_glob]
+'perf list' [--no-desc] [hw|sw|cache|tracepoint|pmu|event_glob]
 
 DESCRIPTION
 ---
 This command displays the symbolic event types which can be selected in the
 various perf commands with the -e option.
 
+OPTIONS
+---
+--no-desc::
+Don't print descriptions.
+
+
 [[EVENT_MODIFIERS]]
 EVENT MODIFIERS
 ---
diff --git a/tools/perf/builtin-list.c b/tools/perf/builtin-list.c
index af5bd05..3f058f7 100644
--- a/tools/perf/builtin-list.c
+++ b/tools/perf/builtin-list.c
@@ -16,16 +16,20 @@
 #include "util/pmu.h"
 #include "util/parse-options.h"
 
+static bool desc_flag = true;
+
 int cmd_list(int argc, const char **argv, const char *prefix __maybe_unused)
 {
int i;
bool raw_dump = false;
struct option list_options[] = {
OPT_BOOLEAN(0, "raw-dump", _dump, "Dump raw events"),
+   OPT_BOOLEAN('d', "desc", _flag,
+   "Print extra event descriptions. --no-desc to not 
print."),
OPT_END()
};
const char * const list_usage[] = {
-   "perf list [hw|sw|cache|tracepoint|pmu|event_glob]",
+   "perf list [--no-desc] [hw|sw|cache|tracepoint|pmu|event_glob]",
NULL
};
 
@@ -40,7 +44,7 @@ int cmd_list(int argc, const char **argv, const char *prefix 
__maybe_unused)
printf("\nList of pre-defined events (to be used in -e):\n\n");
 
if (argc == 0) {
-   print_events(NULL, raw_dump);
+   print_events(NULL, raw_dump, !desc_flag);
return 0;
}
 
@@ -59,13 +63,13 @@ int cmd_list(int argc, const char **argv, const char 
*prefix __maybe_unused)
 strcmp(argv[i], "hwcache") == 0)
print_hwcache_events(NULL, raw_dump);
else if (strcmp(argv[i], "pmu") == 0)
-   print_pmu_events(NULL, raw_dump);
+   print_pmu_events(NULL, raw_dump, !desc_flag);
else {
char *sep = strchr(argv[i], ':'), *s;
int sep_idx;
 
if (sep == NULL) {
-   print_events(argv[i], raw_dump);
+   print_events(argv[i], raw_dump, !desc_flag);
continue;
}
sep_idx = sep - argv[i];
diff --git a/tools/perf/util/parse-events.c b/tools/perf/util/parse-events.c
index 61c2bc2..e9563a0 100644
--- a/tools/perf/util/parse-events.c
+++ b/tools/perf/util/parse-events.c
@@ -1717,7 +1717,7 @@ out_enomem:
 /*
  * Print the help text for the event symbols:
  */
-void print_events(const char *event_glob, bool name_only)
+void print_events(const char *event_glob, bool name_only, bool quiet_flag)
 {
print_symbol_events(event_glob, PERF_TYPE_HARDWARE,
event_symbols_hw, PERF_COUNT_HW_MAX, name_only);
@@ -1727,7 +1727,7 @@ void print_events(const char *event_glob, bool name_only)
 
print_hwcache_events(event_glob, name_only);
 
-   print_pmu_events(event_glob, name_only);
+   print_pmu_events(event_glob, name_only, quiet_flag);
 
if (event_glob != NULL)
return;
diff --git a/tools/perf/util/parse-events.h b/tools/perf/util/parse-events.h
index ffee7ec..37857e7 100644
--- a/tools/perf/util/parse-events.h
+++ b/tools/perf/util/parse-events.h
@@ -139,7 +139,7 @@ void parse_events_update_lists(struct list_head *list_event,
 void parse_events_evlist_error(struct parse_events_evlist *data,
   int idx, const char *str);
 
-void print_events(const char *event_glob, bool name_only);
+void print_events(const char *event_glob, bool 

[PATCH v17 15/19] perf, tools: Handle header line in mapfile

2015-09-28 Thread Sukadev Bhattiprolu
From: Andi Kleen 

To work with existing mapfiles, assume that the first line in
'mapfile.csv' is a header line and skip over it.

Signed-off-by: Andi Kleen 
Signed-off-by: Sukadev Bhattiprolu 
Acked-by: Jiri Olsa 
---

Changelog[v2]
All architectures may not use the "Family" to identify. So,
assume first line is header.
---
 tools/perf/pmu-events/jevents.c | 9 +++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/tools/perf/pmu-events/jevents.c b/tools/perf/pmu-events/jevents.c
index ea3474b..7347cca 100644
--- a/tools/perf/pmu-events/jevents.c
+++ b/tools/perf/pmu-events/jevents.c
@@ -462,7 +462,12 @@ static int process_mapfile(FILE *outfp, char *fpath)
 
print_mapping_table_prefix(outfp);
 
-   line_num = 0;
+   /* Skip first line (header) */
+   p = fgets(line, n, mapfp);
+   if (!p)
+   goto out;
+
+   line_num = 1;
while (1) {
char *cpuid, *version, *type, *fname;
 
@@ -506,8 +511,8 @@ static int process_mapfile(FILE *outfp, char *fpath)
fprintf(outfp, "},\n");
}
 
+out:
print_mapping_table_suffix(outfp);
-
return 0;
 }
 
-- 
2.5.3

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[PATCH v17 16/19] perf, tools: Add README for info on parsing JSON/map files

2015-09-28 Thread Sukadev Bhattiprolu
Signed-off-by: Sukadev Bhattiprolu 
Acked-by: Jiri Olsa 
---
 tools/perf/pmu-events/README | 122 +++
 1 file changed, 122 insertions(+)
 create mode 100644 tools/perf/pmu-events/README

diff --git a/tools/perf/pmu-events/README b/tools/perf/pmu-events/README
new file mode 100644
index 000..da57cb5
--- /dev/null
+++ b/tools/perf/pmu-events/README
@@ -0,0 +1,122 @@
+
+The contents of this directory allow users to specify PMU events in
+their CPUs by their symbolic names rather than raw event codes (see
+example below).
+
+The main program in this directory, is the 'jevents', which is built and
+executed _before_ the perf binary itself is built.
+
+The 'jevents' program tries to locate and process JSON files in the directory
+tree tools/perf/pmu-events/arch/foo.
+
+   - Regular files with '.json' extension in the name are assumed to be
+ JSON files, each of which describes a set of PMU events.
+
+   - Regular files with basename starting with 'mapfile.csv' are assumed
+ to be a CSV file that maps a specific CPU to its set of PMU events.
+ (see below for mapfile format)
+
+   - Directories are traversed, but all other files are ignored.
+
+Using the JSON files and the mapfile, 'jevents' generates the C source file,
+'pmu-events.c', which encodes the two sets of tables:
+
+   - Set of 'PMU events tables' for all known CPUs in the architecture,
+ (one table like the following, per JSON file; table name 'pme_power8'
+ is derived from JSON file name, 'power8.json').
+
+   struct pmu_event pme_power8[] = {
+
+   ...
+
+   {
+   .name = "pm_1plus_ppc_cmpl",
+   .event = "event=0x100f2",
+   .desc = "1 or more ppc insts finished,",
+   },
+
+   ...
+   }
+
+   - A 'mapping table' that maps each CPU of the architecture, to its
+ 'PMU events table'
+
+   struct pmu_events_map pmu_events_map[] = {
+   {
+   .cpuid = "004b",
+   .version = "1",
+   .type = "core",
+   .table = pme_power8
+   },
+   ...
+
+   };
+
+After the 'pmu-events.c' is generated, it is compiled and the resulting
+'pmu-events.o' is added to 'libperf.a' which is then used to build perf.
+
+NOTES:
+   1. Several CPUs can support same set of events and hence use a common
+  JSON file. Hence several entries in the pmu_events_map[] could map
+  to a single 'PMU events table'.
+
+   2. The 'pmu-events.h' has an extern declaration for the mapping table
+  and the generated 'pmu-events.c' defines this table.
+
+   3. _All_ known CPU tables for architecture are included in the perf
+  binary.
+
+At run time, perf determines the actual CPU it is running on, finds the
+matching events table and builds aliases for those events. This allows
+users to specify events by their name:
+
+   $ perf stat -e pm_1plus_ppc_cmpl sleep 1
+
+where 'pm_1plus_ppc_cmpl' is a Power8 PMU event.
+
+In case of errors when processing files in the tools/perf/pmu-events/arch
+directory, 'jevents' tries to create an empty mapping file to allow the perf
+build to succeed even if the PMU event aliases cannot be used.
+
+However some errors in processing may cause the perf build to fail.
+
+Mapfile format
+===
+
+The mapfile.csv format is expected to be:
+
+   Header line
+   CPUID,Version,File/path/name.json,Type
+
+where:
+
+   Comma:
+   is the required field delimiter (i.e other fields cannot
+   have commas within them).
+
+   Comments:
+   Lines in which the first character is either '\n' or '#'
+   are ignored.
+
+   Header line
+   The header line is the first line in the file, which is
+   _IGNORED_. It can be a comment (begin with '#') or empty.
+
+   CPUID:
+   CPUID is an arch-specific char string, that can be used
+   to identify CPU (and associate it with a set of PMU events
+   it supports). Multiple CPUIDS can point to the same
+   File/path/name.json.
+
+   Example:
+   CPUID == 'GenuineIntel-6-2E' (on x86).
+   CPUID == '004b0100' (PVR value in Powerpc)
+   Version:
+   is the Version of the mapfile.
+
+   File/path/name.json:
+   is the pathname for the JSON file, relative to the directory
+   containing the mapfile.csv
+
+   Type:
+   indicates whether the events or "core" or "uncore" events.
-- 
2.5.3

___
Linuxppc-dev 

[PATCH v17 18/19] perf, tools, pmu-events: Fix fixed counters on Intel

2015-09-28 Thread Sukadev Bhattiprolu
From: Andi Kleen 

The JSON event lists use a different encoding for fixed counters
than perf for instructions and cycles (ref-cycles is ok)

This lead to some common events like inst_retired.any
or cpu_clk_unhalted.thread not counting, when specified with their
JSON name.

Special case these events in the jevents conversion process.
I prefer to not touch the JSON files for this, as it's intended
that standard JSON files can be just dropped into the perf
build without changes.

Signed-off-by: Andi Kleen 
Signed-off-by: Sukadev Bhattiprolu 
[Fix minor compile error]
---
 tools/perf/pmu-events/jevents.c | 25 +++--
 1 file changed, 23 insertions(+), 2 deletions(-)

diff --git a/tools/perf/pmu-events/jevents.c b/tools/perf/pmu-events/jevents.c
index 7347cca..247d777e 100644
--- a/tools/perf/pmu-events/jevents.c
+++ b/tools/perf/pmu-events/jevents.c
@@ -237,6 +237,28 @@ static void print_events_table_suffix(FILE *outfp)
fprintf(outfp, "};\n");
 }
 
+static struct fixed {
+   const char *name;
+   const char *event;
+} fixed[] = {
+   { "inst_retired.any", "event=0xc0" },
+   { "cpu_clk_unhalted.thread", "event=0x3c" },
+   { "cpu_clk_unhalted.thread_any", "event=0x3c,any=1" },
+   { NULL, NULL},
+};
+
+/*
+ * Handle different fixed counter encodings between JSON and perf.
+ */
+static char *real_event(const char *name, char *event)
+{
+   int i;
+   for (i = 0; fixed[i].name; i++)
+   if (!strcasecmp(name, fixed[i].name))
+   return (char *)fixed[i].event;
+   return event;
+}
+
 /* Call func with each event in the json file */
 int json_events(const char *fn,
  int (*func)(void *data, char *name, char *event, char *desc,
@@ -324,8 +346,7 @@ int json_events(const char *fn,
if (msr != NULL)
addfield(map, , ",", msr->pname, msrval);
fixname(name);
-
-   err = func(data, name, event, desc, long_desc, topic);
+   err = func(data, name, real_event(name, event), desc, 
long_desc, topic);
free(event);
free(desc);
free(name);
-- 
2.5.3

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH v4 30/32] cxlflash: Fix to avoid corrupting adapter fops

2015-09-28 Thread Andrew Donnellan

On 26/09/15 09:19, Matthew R. Ochs wrote:

The fops owned by the adapter can be corrupted in certain scenarios,
opening a window where certain fops are temporarily NULLed before being
reset to their proper value. This can potentially lead software to make
incorrect decisions, leaving the user with the inability to function as
intended.

An example of this behavior can be observed when there are a number of
users with a high rate of turn around (attach to LUN, perform an I/O,
detach from LUN, repeat). Every so often a user is given a valid
context and adapter file descriptor, but the file associated with the
descriptor lacks the correct read permission bit (FMODE_CAN_READ) and
thus the read system call bails before calling the valid read fop.

Background:

The fops is stored in the adapter structure to provide the ability to
lookup the adapter structure from within the fop handler. CXL services
use the file's private_data and at present, the CXL context does not
have a private section. In an effort to limit areas of the cxlflash
driver with code specific the superpipe function, a design choice was
made to keep the details of the fops situated away from the legacy
portions of the driver. This drove the behavior that the adapter fops
is set at the beginning of the disk attach ioctl handler when there
are no users present.

The corruption that this fix remedies is due to the fact that the fops
is initially defaulted to values found within a static structure. When
the fops is handed down to the CXL services later in the attach path,
certain services are patched. The fops structure remains correct until
the user count drops to 0 and the fops is reset, triggering the process
to repeat again. The user counts are tightly coupled with the creation
and deletion of the user context. If multiple users perform a disk
attach at the same time, when the user count is currently 0, some users
can be in the middle of obtaining a file descriptor and have not yet
reached the context creation code that [in addition to creating the
context] increments the user count. Subsequent users coming in to
perform the attach see that the user count is still 0, and reinitialize
the fops, temporarily removing the patched fops. The users that are in
the middle obtaining their file descriptor may then receive an invalid
descriptor.

The fix simply removes the user count altogether and moves the fops
initialization to probe time such that it is only performed one time
for the life of the adapter. In the future, if the CXL services adopt
a private member for their context, that could be used to store the
adapter structure reference and cxlflash could revert to a model that
does not require an embedded fops.

Signed-off-by: Matthew R. Ochs 
Signed-off-by: Manoj N. Kumar 


Reviewed-by: Andrew Donnellan 

--
Andrew Donnellan  Software Engineer, OzLabs
andrew.donnel...@au1.ibm.com  Australia Development Lab, Canberra
+61 2 6201 8874 (work)IBM Australia Limited

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH v4 26/32] cxlflash: Correct spelling, grammar, and alignment mistakes

2015-09-28 Thread Andrew Donnellan

On 26/09/15 09:18, Matthew R. Ochs wrote:

There are several spelling and grammar mistakes throughout the
driver. Additionally there are a handful of places where there
are extra lines and unnecessary variables/statements. These are
a nuisance and pollute the driver.

Fix spelling and grammar issues. Update some comments for clarity and
consistency. Remove extra lines and a few unneeded variables/statements.

Signed-off-by: Matthew R. Ochs 
Signed-off-by: Manoj N. Kumar 
Reviewed-by: Brian King 


Reviewed-by: Andrew Donnellan 

--
Andrew Donnellan  Software Engineer, OzLabs
andrew.donnel...@au1.ibm.com  Australia Development Lab, Canberra
+61 2 6201 8874 (work)IBM Australia Limited

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH v4 31/32] cxlflash: Correct trace string

2015-09-28 Thread Andrew Donnellan

On 26/09/15 09:19, Matthew R. Ochs wrote:

The trace following the failure of alloc_mem() incorrectly identifies
which function failed. This can lead to misdiagnosing a failure.

Fix the string to correctly indicate that alloc_mem() failed.

Reported-by: Brian King 
Signed-off-by: Matthew R. Ochs 
Signed-off-by: Manoj N. Kumar 
Reviewed-by: Brian King 


Reviewed-by: Andrew Donnellan 

--
Andrew Donnellan  Software Engineer, OzLabs
andrew.donnel...@au1.ibm.com  Australia Development Lab, Canberra
+61 2 6201 8874 (work)IBM Australia Limited

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH v4 25/32] cxlflash: Fix to prevent EEH recovery failure

2015-09-28 Thread Daniel Axtens
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

"Matthew R. Ochs"  writes:


> The process_sense() routine can perform a read capacity which
> can take some time to complete. If an EEH occurs while waiting
> on the read capacity, the EEH handler is unable to obtain the
> context's mutex in order to put the context in an error state.
> The EEH handler will sit and wait until the context is free,
> but this wait can last longer than the EEH handler tolerates,
> leading to a failed recovery.

I'm not quite clear on what you mean by the EEH handler timing
out. AFAIK there's nothing in eehd and the EEH core that times out if a
driver doesn't respond - indeed, it's pretty easy to hang eehd with a
misbehaving driver.

Are you referring to your own internal timeouts?
cxlflash_wait_for_pci_err_recovery and anything else that uses
CXLFLASH_PCI_ERROR_RECOVERY_TIMEOUT?

Regards,
Daniel

>
> To address this issue, make the context unavailable to new,
> non-system owned threads and release the context while calling
> into process_sense(). After returning from process_sense() the
> context mutex is reacquired and the context is made available
> again. The context can be safely moved to the error state if
> needed during the unavailable window as no other threads will
> hold its reference.
>
> Signed-off-by: Matthew R. Ochs 
> Signed-off-by: Manoj N. Kumar 
> Reviewed-by: Brian King 
> ---
>  drivers/scsi/cxlflash/superpipe.c | 9 +
>  1 file changed, 9 insertions(+)
>
> diff --git a/drivers/scsi/cxlflash/superpipe.c 
> b/drivers/scsi/cxlflash/superpipe.c
> index a6316f5..7283e83 100644
> --- a/drivers/scsi/cxlflash/superpipe.c
> +++ b/drivers/scsi/cxlflash/superpipe.c
> @@ -1787,12 +1787,21 @@ static int cxlflash_disk_verify(struct scsi_device 
> *sdev,
>* inquiry (i.e. the Unit attention is due to the WWN changing).
>*/
>   if (verify->hint & DK_CXLFLASH_VERIFY_HINT_SENSE) {
> + /* Can't hold mutex across process_sense/read_cap16,
> +  * since we could have an intervening EEH event.
> +  */
> + ctxi->unavail = true;
> + mutex_unlock(>mutex);
>   rc = process_sense(sdev, verify);
>   if (unlikely(rc)) {
>   dev_err(dev, "%s: Failed to validate sense data (%d)\n",
>   __func__, rc);
> + mutex_lock(>mutex);
> + ctxi->unavail = false;
>   goto out;
>   }
> + mutex_lock(>mutex);
> + ctxi->unavail = false;
>   }
>  
>   switch (gli->mode) {
> -- 
> 2.1.0
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: GPGTools - https://gpgtools.org

iQIcBAEBCgAGBQJWCeieAAoJEPC3R3P2I92F+hMP/1OdLQCin+kKbOb9qxf952bH
DUAkmEhc0oD7xZFQI8HgDmHRxpes5HHxXtwXFsLgsr8QYG+aOIV568GXIZtTbrl0
aCFMqtKXZ6jVqv5L60r1tgzcWxmWdshMLd1op6t3BwA67nUc5Edcr94ePUyDDLj1
at335wCnxuGxn0kdB0Ud/lbPzTsgDPcuV6tCLy0o4J15KFOyFt9hCjO4nmL/wcIt
kmjyn5SHbdgje+73uaRQnXkli4wDA9x7x6/8wFgLspnOxgMEJgnHmm+HYbOXnHyX
nFFHw9+X2ETUcucVWuKNaFzW1vH+WJDteEZbjS7t7liJIkmIiZSFHyUTtVGdBkl1
FsWswA0pkzuGq94Wsb0nGtNHbsMw+WeWTcTlNN46DMG/wqz75iO3yMGK9MZuddSX
9jUokiM0kQvvfwAoujmvpMCVB4b2oseRRG4/yJ0lKSCcC8kETQTXgVHbT8oLmCdk
rUA0hxbbKzVQsDzw8s5HqYZjqHdLp3sDPeyukPeJl2CNhysrmnyHXpq8XgcLi3op
kbuuiR3z8UH3MW4BDpplnjhZ+5Wyw9cSI57vRF2Kr80NnU+5hBvftNh4rBneeny2
0gCDlPHDvB7Ks9HkcxkK9MW78FTgj50ePofS/dUUod4M9ohDd4MSwRKjpwQ+H3By
jmxnzfvWO/oTlL1D9+2W
=3BcU
-END PGP SIGNATURE-
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH v2 13/25] powerpc/8xx: also use r3 in the ITLB miss in all situations

2015-09-28 Thread Scott Wood
On Tue, Sep 22, 2015 at 06:50:54PM +0200, Christophe Leroy wrote:
> We are spending between 40 and 160 cycles with a mean of 65 cycles
> in the TLB handling routines (measured with mftbl) so make it more
> simple althought it adds one instruction
> 
> Signed-off-by: Christophe Leroy 
> ---
> No change in v2
> 
>  arch/powerpc/kernel/head_8xx.S | 15 ---
>  1 file changed, 4 insertions(+), 11 deletions(-)

Why is this a separate patch from 1/25?

Same comments as on that patch.

-Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH v2 15/25] powerpc/8xx: move 8xx SPRN defines into reg_8xx.h and add some missing ones

2015-09-28 Thread Scott Wood
On Tue, Sep 22, 2015 at 06:50:58PM +0200, Christophe Leroy wrote:
> Move 8xx SPRN defines into reg_8xx.h and add some missing ones
> 
> Signed-off-by: Christophe Leroy 
> ---
> No change in v2

Why are they being moved?  Why are they being separated from the bit
definitions?

-Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH v2 21/25] powerpc: add inline functions for cache related instructions

2015-09-28 Thread Scott Wood
On Tue, Sep 22, 2015 at 06:51:11PM +0200, Christophe Leroy wrote:
> This patch adds inline functions to use dcbz, dcbi, dcbf, dcbst
> from C functions
> 
> Signed-off-by: Christophe Leroy 
> ---
> New in v2
> 
>  arch/powerpc/include/asm/cache.h | 19 +++
>  1 file changed, 19 insertions(+)

This patch needs to come before patch 20/25, which uses dcbz().

-Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[PATCH v17 01/19] perf, tools: Add jsmn `jasmine' JSON parser

2015-09-28 Thread Sukadev Bhattiprolu
From: Andi Kleen 

I need a JSON parser. This adds the simplest JSON
parser I could find -- Serge Zaitsev's jsmn `jasmine' --
to the perf library. I merely converted it to (mostly)
Linux style and added support for non 0 terminated input.

The parser is quite straight forward and does not
copy any data, just returns tokens with offsets
into the input buffer. So it's relatively efficient
and simple to use.

The code is not fully checkpatch clean, but I didn't
want to completely fork the upstream code.

Original source: http://zserge.bitbucket.org/jsmn.html

In addition I added a simple wrapper that mmaps a json
file and provides some straight forward access functions.

Used in follow-on patches to parse event files.

Acked-by: Namhyung Kim 
Acked-by: Jiri Olsa 
Signed-off-by: Andi Kleen 
Signed-off-by: Sukadev Bhattiprolu 
---
v2: Address review feedback.
v3: Minor checkpatch fixes.
v4 (by Sukadev Bhattiprolu)
- Rebase to 4.0 and fix minor conflicts in tools/perf/Makefile.perf
- Report error if specified events file is invalid.
v5 (Sukadev Bhattiprolu)
- Move files to tools/perf/pmu-events/ since parsing of JSON file
now occurs when _building_ rather than running perf.
---
 tools/perf/pmu-events/jsmn.c | 313 +++
 tools/perf/pmu-events/jsmn.h |  67 +
 tools/perf/pmu-events/json.c | 162 ++
 tools/perf/pmu-events/json.h |  36 +
 4 files changed, 578 insertions(+)
 create mode 100644 tools/perf/pmu-events/jsmn.c
 create mode 100644 tools/perf/pmu-events/jsmn.h
 create mode 100644 tools/perf/pmu-events/json.c
 create mode 100644 tools/perf/pmu-events/json.h

diff --git a/tools/perf/pmu-events/jsmn.c b/tools/perf/pmu-events/jsmn.c
new file mode 100644
index 000..11d1fa1
--- /dev/null
+++ b/tools/perf/pmu-events/jsmn.c
@@ -0,0 +1,313 @@
+/*
+ * Copyright (c) 2010 Serge A. Zaitsev
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a copy
+ * of this software and associated documentation files (the "Software"), to 
deal
+ * in the Software without restriction, including without limitation the rights
+ * to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+ * copies of the Software, and to permit persons to whom the Software is
+ * furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+ * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING 
FROM,
+ * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
+ * THE SOFTWARE.
+ *
+ * Slightly modified by AK to not assume 0 terminated input.
+ */
+
+#include 
+#include "jsmn.h"
+
+/*
+ * Allocates a fresh unused token from the token pool.
+ */
+static jsmntok_t *jsmn_alloc_token(jsmn_parser *parser,
+  jsmntok_t *tokens, size_t num_tokens)
+{
+   jsmntok_t *tok;
+
+   if ((unsigned)parser->toknext >= num_tokens)
+   return NULL;
+   tok = [parser->toknext++];
+   tok->start = tok->end = -1;
+   tok->size = 0;
+   return tok;
+}
+
+/*
+ * Fills token type and boundaries.
+ */
+static void jsmn_fill_token(jsmntok_t *token, jsmntype_t type,
+   int start, int end)
+{
+   token->type = type;
+   token->start = start;
+   token->end = end;
+   token->size = 0;
+}
+
+/*
+ * Fills next available token with JSON primitive.
+ */
+static jsmnerr_t jsmn_parse_primitive(jsmn_parser *parser, const char *js,
+ size_t len,
+ jsmntok_t *tokens, size_t num_tokens)
+{
+   jsmntok_t *token;
+   int start;
+
+   start = parser->pos;
+
+   for (; parser->pos < len; parser->pos++) {
+   switch (js[parser->pos]) {
+#ifndef JSMN_STRICT
+   /*
+* In strict mode primitive must be followed by ","
+* or "}" or "]"
+*/
+   case ':':
+#endif
+   case '\t':
+   case '\r':
+   case '\n':
+   case ' ':
+   case ',':
+   case ']':
+   case '}':
+   goto found;
+   default:
+   break;
+   }
+   if (js[parser->pos] < 32 || js[parser->pos] >= 127) {
+   parser->pos = start;
+   return 

[PATCH v17 03/19] perf, tools: Use pmu_events table to create aliases

2015-09-28 Thread Sukadev Bhattiprolu
At run time (when 'perf' is starting up), locate the specific table
of PMU events that corresponds to the current CPU. Using that table,
create aliases for the each of the PMU events in the CPU. The use
these aliases to parse the user specified perf event.

In short this would allow the user to specify events using their
aliases rather than raw event codes.

Based on input and some earlier patches from Andi Kleen, Jiri Olsa.

Signed-off-by: Sukadev Bhattiprolu 
Acked-by: Jiri Olsa 
---

Changelog[v4]
- Split off unrelated code into separate patches.
Changelog[v3]
- [Jiri Olsa] Fix memory leak in cpuid
Changelog[v2]
- [Andi Kleen] Replace pmu_events_map->vfm with a generic "cpuid".
---
 tools/perf/util/header.h |  1 +
 tools/perf/util/pmu.c| 61 
 2 files changed, 62 insertions(+)

diff --git a/tools/perf/util/header.h b/tools/perf/util/header.h
index 05f27cb..d02b2f9 100644
--- a/tools/perf/util/header.h
+++ b/tools/perf/util/header.h
@@ -133,4 +133,5 @@ int write_padded(int fd, const void *bf, size_t count, 
size_t count_aligned);
  */
 int get_cpuid(char *buffer, size_t sz);
 
+char *get_cpuid_str(void);
 #endif /* __PERF_HEADER_H */
diff --git a/tools/perf/util/pmu.c b/tools/perf/util/pmu.c
index 89c91a1..b8f7627 100644
--- a/tools/perf/util/pmu.c
+++ b/tools/perf/util/pmu.c
@@ -12,6 +12,8 @@
 #include "pmu.h"
 #include "parse-events.h"
 #include "cpumap.h"
+#include "header.h"
+#include "pmu-events/pmu-events.h"
 
 struct perf_pmu_format {
char *name;
@@ -449,6 +451,62 @@ static struct cpu_map *pmu_cpumask(const char *name)
return cpus;
 }
 
+/*
+ * Return the CPU id as a raw string.
+ *
+ * Each architecture should provide a more precise id string that
+ * can be use to match the architecture's "mapfile".
+ */
+char * __weak get_cpuid_str(void)
+{
+   return NULL;
+}
+
+/*
+ * From the pmu_events_map, find the table of PMU events that corresponds
+ * to the current running CPU. Then, add all PMU events from that table
+ * as aliases.
+ */
+static int pmu_add_cpu_aliases(struct list_head *head)
+{
+   int i;
+   struct pmu_events_map *map;
+   struct pmu_event *pe;
+   char *cpuid;
+
+   cpuid = get_cpuid_str();
+   if (!cpuid)
+   return 0;
+
+   i = 0;
+   while (1) {
+   map = _events_map[i++];
+   if (!map->table)
+   goto out;
+
+   if (!strcmp(map->cpuid, cpuid))
+   break;
+   }
+
+   /*
+* Found a matching PMU events table. Create aliases
+*/
+   i = 0;
+   while (1) {
+   pe = >table[i++];
+   if (!pe->name)
+   break;
+
+   /* need type casts to override 'const' */
+   __perf_pmu__new_alias(head, NULL, (char *)pe->name,
+   (char *)pe->desc, (char *)pe->event);
+   }
+
+out:
+   free(cpuid);
+   return 0;
+}
+
 struct perf_event_attr * __weak
 perf_pmu__get_default_config(struct perf_pmu *pmu __maybe_unused)
 {
@@ -473,6 +531,9 @@ static struct perf_pmu *pmu_lookup(const char *name)
if (pmu_aliases(name, ))
return NULL;
 
+   if (!strcmp(name, "cpu"))
+   (void)pmu_add_cpu_aliases();
+
if (pmu_type(name, ))
return NULL;
 
-- 
2.5.3

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[PATCH v17 04/19] perf, tools: Support CPU ID matching for Powerpc

2015-09-28 Thread Sukadev Bhattiprolu
Implement code that returns the generic CPU ID string for Powerpc.
This will be used to identify the specific table of PMU events to
parse/compare user specified events against.

Signed-off-by: Sukadev Bhattiprolu 
Acked-by: Jiri Olsa 
---

Changelog[v14]
- [Jiri Olsa] Move this independent code off into a separate patch.
---
 tools/perf/arch/powerpc/util/header.c | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/tools/perf/arch/powerpc/util/header.c 
b/tools/perf/arch/powerpc/util/header.c
index 6c1b8a7..65f9391 100644
--- a/tools/perf/arch/powerpc/util/header.c
+++ b/tools/perf/arch/powerpc/util/header.c
@@ -32,3 +32,14 @@ get_cpuid(char *buffer, size_t sz)
}
return -1;
 }
+
+char *
+get_cpuid_str(void)
+{
+   char *bufp;
+
+   if (asprintf(, "%.8lx", mfspr(SPRN_PVR)) < 0)
+   bufp = NULL;
+
+   return bufp;
+}
-- 
2.5.3

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[PATCH v17 07/19] perf, tools: Query terminal width and use in perf list

2015-09-28 Thread Sukadev Bhattiprolu
From: Andi Kleen 

Automatically adapt the now wider and word wrapped perf list
output to wider terminals. This requires querying the terminal
before the auto pager takes over, and exporting this
information from the pager subsystem.

Signed-off-by: Andi Kleen 
Signed-off-by: Sukadev Bhattiprolu 
Acked-by: Namhyung Kim 
Acked-by: Jiri Olsa 
---
 tools/perf/util/cache.h |  1 +
 tools/perf/util/pager.c | 15 +++
 tools/perf/util/pmu.c   |  3 ++-
 3 files changed, 18 insertions(+), 1 deletion(-)

diff --git a/tools/perf/util/cache.h b/tools/perf/util/cache.h
index c861373..8e0d4b8 100644
--- a/tools/perf/util/cache.h
+++ b/tools/perf/util/cache.h
@@ -32,6 +32,7 @@ extern const char *perf_config_dirname(const char *, const 
char *);
 extern void setup_pager(void);
 extern int pager_in_use(void);
 extern int pager_use_color;
+int pager_get_columns(void);
 
 char *alias_lookup(const char *alias);
 int split_cmdline(char *cmdline, const char ***argv);
diff --git a/tools/perf/util/pager.c b/tools/perf/util/pager.c
index 53ef006..1770c88 100644
--- a/tools/perf/util/pager.c
+++ b/tools/perf/util/pager.c
@@ -1,6 +1,7 @@
 #include "cache.h"
 #include "run-command.h"
 #include "sigchain.h"
+#include 
 
 /*
  * This is split up from the rest of git so that we can do
@@ -8,6 +9,7 @@
  */
 
 static int spawned_pager;
+static int pager_columns;
 
 static void pager_preexec(void)
 {
@@ -47,9 +49,12 @@ static void wait_for_pager_signal(int signo)
 void setup_pager(void)
 {
const char *pager = getenv("PERF_PAGER");
+   struct winsize sz;
 
if (!isatty(1))
return;
+   if (ioctl(1, TIOCGWINSZ, ) == 0)
+   pager_columns = sz.ws_col;
if (!pager)
pager = getenv("PAGER");
if (!(pager || access("/usr/bin/pager", X_OK)))
@@ -93,3 +98,13 @@ int pager_in_use(void)
env = getenv("PERF_PAGER_IN_USE");
return env ? perf_config_bool("PERF_PAGER_IN_USE", env) : 0;
 }
+
+int pager_get_columns(void)
+{
+   char *s;
+
+   s = getenv("COLUMNS");
+   if (s)
+   return atoi(s);
+   return (pager_columns ? pager_columns : 80) - 2;
+}
diff --git a/tools/perf/util/pmu.c b/tools/perf/util/pmu.c
index cb0396e..0f10fa3 100644
--- a/tools/perf/util/pmu.c
+++ b/tools/perf/util/pmu.c
@@ -14,6 +14,7 @@
 #include "cpumap.h"
 #include "header.h"
 #include "pmu-events/pmu-events.h"
+#include "cache.h"
 
 struct perf_pmu_format {
char *name;
@@ -1079,7 +1080,7 @@ void print_pmu_events(const char *event_glob, bool 
name_only)
int len, j;
struct pair *aliases;
int numdesc = 0;
-   int columns = 78;
+   int columns = pager_get_columns();
 
pmu = NULL;
len = 0;
-- 
2.5.3

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[PATCH v17 10/19] perf, tools, jevents: Add support for long descriptions

2015-09-28 Thread Sukadev Bhattiprolu
Implement support in jevents to parse long descriptions for events
that may have them in the JSON files. A follow on patch will make this
long description available to user through the 'perf list' command.

Signed-off-by: Andi Kleen 
Signed-off-by: Sukadev Bhattiprolu 
Acked-by: Jiri Olsa 
---

Changelog[v14]
- [Jiri Olsa] Break up independent parts of the patch into
  separate patches.
---
 tools/perf/pmu-events/jevents.c| 31 +++
 tools/perf/pmu-events/jevents.h|  3 ++-
 tools/perf/pmu-events/pmu-events.h |  1 +
 3 files changed, 26 insertions(+), 9 deletions(-)

diff --git a/tools/perf/pmu-events/jevents.c b/tools/perf/pmu-events/jevents.c
index 5f7603b..a8507c9 100644
--- a/tools/perf/pmu-events/jevents.c
+++ b/tools/perf/pmu-events/jevents.c
@@ -203,7 +203,7 @@ static void print_events_table_prefix(FILE *fp, const char 
*tblname)
 }
 
 static int print_events_table_entry(void *data, char *name, char *event,
-   char *desc)
+   char *desc, char *long_desc)
 {
FILE *outfp = data;
/*
@@ -215,6 +215,8 @@ static int print_events_table_entry(void *data, char *name, 
char *event,
fprintf(outfp, "\t.name = \"%s\",\n", name);
fprintf(outfp, "\t.event = \"%s\",\n", event);
fprintf(outfp, "\t.desc = \"%s\",\n", desc);
+   if (long_desc && long_desc[0])
+   fprintf(outfp, "\t.long_desc = \"%s\",\n", long_desc);
 
fprintf(outfp, "},\n");
 
@@ -235,7 +237,8 @@ static void print_events_table_suffix(FILE *outfp)
 
 /* Call func with each event in the json file */
 int json_events(const char *fn,
- int (*func)(void *data, char *name, char *event, char *desc),
+ int (*func)(void *data, char *name, char *event, char *desc,
+ char *long_desc),
  void *data)
 {
int err = -EIO;
@@ -254,6 +257,8 @@ int json_events(const char *fn,
tok = tokens + 1;
for (i = 0; i < tokens->size; i++) {
char *event = NULL, *desc = NULL, *name = NULL;
+   char *long_desc = NULL;
+   char *extra_desc = NULL;
struct msrmap *msr = NULL;
jsmntok_t *msrval = NULL;
jsmntok_t *precise = NULL;
@@ -279,6 +284,9 @@ int json_events(const char *fn,
} else if (json_streq(map, field, "BriefDescription")) {
addfield(map, , "", "", val);
fixdesc(desc);
+   } else if (json_streq(map, field, "PublicDescription")) 
{
+   addfield(map, _desc, "", "", val);
+   fixdesc(long_desc);
} else if (json_streq(map, field, "PEBS") && nz) {
precise = val;
} else if (json_streq(map, field, "MSRIndex") && nz) {
@@ -287,10 +295,10 @@ int json_events(const char *fn,
msrval = val;
} else if (json_streq(map, field, "Errata") &&
   !json_streq(map, val, "null")) {
-   addfield(map, , ". ",
+   addfield(map, _desc, ". ",
" Spec update: ", val);
} else if (json_streq(map, field, "Data_LA") && nz) {
-   addfield(map, , ". ",
+   addfield(map, _desc, ". ",
" Supports address when precise",
NULL);
}
@@ -298,19 +306,26 @@ int json_events(const char *fn,
}
if (precise && !strstr(desc, "(Precise Event)")) {
if (json_streq(map, precise, "2"))
-   addfield(map, , " ", "(Must be precise)",
-   NULL);
+   addfield(map, _desc, " ",
+   "(Must be precise)", NULL);
else
-   addfield(map, , " ",
+   addfield(map, _desc, " ",
"(Precise event)", NULL);
}
+   if (desc && extra_desc)
+   addfield(map, , " ", extra_desc, NULL);
+   if (long_desc && extra_desc)
+   addfield(map, _desc, " ", extra_desc, NULL);
if (msr != NULL)
addfield(map, , ",", msr->pname, msrval);
fixname(name);
-   err = func(data, name, event, desc);
+
+   err = func(data, name, event, desc, long_desc);
free(event);

[PATCH v17 09/19] perf, tools: Add override support for event list CPUID

2015-09-28 Thread Sukadev Bhattiprolu
From: Andi Kleen 

Add a PERF_CPUID variable to override the CPUID of the current CPU (within
the current architecture). This is useful for testing, so that all event
lists can be tested on a single system.

Signed-off-by: Andi Kleen 
Signed-off-by: Sukadev Bhattiprolu 
Acked-by: Jiri Olsa 
---

v2: Fix double free in earlier version.
Print actual CPUID being used with verbose option.
---
 tools/perf/util/pmu.c | 8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/tools/perf/util/pmu.c b/tools/perf/util/pmu.c
index e4cb21e..ca01aea 100644
--- a/tools/perf/util/pmu.c
+++ b/tools/perf/util/pmu.c
@@ -477,10 +477,16 @@ static int pmu_add_cpu_aliases(struct list_head *head)
struct pmu_event *pe;
char *cpuid;
 
-   cpuid = get_cpuid_str();
+   cpuid = getenv("PERF_CPUID");
+   if (cpuid)
+   cpuid = strdup(cpuid);
+   if (!cpuid)
+   cpuid = get_cpuid_str();
if (!cpuid)
return 0;
 
+   pr_debug("Using CPUID %s\n", cpuid);
+
i = 0;
while (1) {
map = _events_map[i++];
-- 
2.5.3

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[PATCH v17 13/19] perf, tools, jevents: Add support for event topics

2015-09-28 Thread Sukadev Bhattiprolu
Allow assigning categories "Topics" field to the PMU events  i.e.
process the topic field from the JSON file and add a corresponding
topic field to the generated C events tables.

Signed-off-by: Andi Kleen 
Signed-off-by: Sukadev Bhattiprolu 
Acked-by: Jiri Olsa 
---

Changelog[v14]
[Jiri Olsa] Move this independent code off into a separate patch.
---
 tools/perf/pmu-events/jevents.c| 12 +---
 tools/perf/pmu-events/jevents.h|  2 +-
 tools/perf/pmu-events/pmu-events.h |  1 +
 3 files changed, 11 insertions(+), 4 deletions(-)

diff --git a/tools/perf/pmu-events/jevents.c b/tools/perf/pmu-events/jevents.c
index a8507c9..ea3474b 100644
--- a/tools/perf/pmu-events/jevents.c
+++ b/tools/perf/pmu-events/jevents.c
@@ -203,7 +203,7 @@ static void print_events_table_prefix(FILE *fp, const char 
*tblname)
 }
 
 static int print_events_table_entry(void *data, char *name, char *event,
-   char *desc, char *long_desc)
+   char *desc, char *long_desc, char *topic)
 {
FILE *outfp = data;
/*
@@ -217,6 +217,8 @@ static int print_events_table_entry(void *data, char *name, 
char *event,
fprintf(outfp, "\t.desc = \"%s\",\n", desc);
if (long_desc && long_desc[0])
fprintf(outfp, "\t.long_desc = \"%s\",\n", long_desc);
+   if (topic)
+   fprintf(outfp, "\t.topic = \"%s\",\n", topic);
 
fprintf(outfp, "},\n");
 
@@ -238,7 +240,7 @@ static void print_events_table_suffix(FILE *outfp)
 /* Call func with each event in the json file */
 int json_events(const char *fn,
  int (*func)(void *data, char *name, char *event, char *desc,
- char *long_desc),
+ char *long_desc, char *topic),
  void *data)
 {
int err = -EIO;
@@ -259,6 +261,7 @@ int json_events(const char *fn,
char *event = NULL, *desc = NULL, *name = NULL;
char *long_desc = NULL;
char *extra_desc = NULL;
+   char *topic = NULL;
struct msrmap *msr = NULL;
jsmntok_t *msrval = NULL;
jsmntok_t *precise = NULL;
@@ -297,6 +300,8 @@ int json_events(const char *fn,
   !json_streq(map, val, "null")) {
addfield(map, _desc, ". ",
" Spec update: ", val);
+   } else if (json_streq(map, field, "Topic")) {
+   addfield(map, , "", "", val);
} else if (json_streq(map, field, "Data_LA") && nz) {
addfield(map, _desc, ". ",
" Supports address when precise",
@@ -320,12 +325,13 @@ int json_events(const char *fn,
addfield(map, , ",", msr->pname, msrval);
fixname(name);
 
-   err = func(data, name, event, desc, long_desc);
+   err = func(data, name, event, desc, long_desc, topic);
free(event);
free(desc);
free(name);
free(long_desc);
free(extra_desc);
+   free(topic);
if (err)
break;
tok += j;
diff --git a/tools/perf/pmu-events/jevents.h b/tools/perf/pmu-events/jevents.h
index b0eb274..9ffcb89 100644
--- a/tools/perf/pmu-events/jevents.h
+++ b/tools/perf/pmu-events/jevents.h
@@ -3,7 +3,7 @@
 
 int json_events(const char *fn,
int (*func)(void *data, char *name, char *event, char *desc,
-   char *long_desc),
+   char *long_desc, char *topic),
void *data);
 char *get_cpu_str(void);
 
diff --git a/tools/perf/pmu-events/pmu-events.h 
b/tools/perf/pmu-events/pmu-events.h
index 711f049..6b69f4b 100644
--- a/tools/perf/pmu-events/pmu-events.h
+++ b/tools/perf/pmu-events/pmu-events.h
@@ -9,6 +9,7 @@ struct pmu_event {
const char *event;
const char *desc;
const char *long_desc;
+   const char *topic;
 };
 
 /*
-- 
2.5.3

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[PATCH v17 11/19] perf, tools: Add alias support for long descriptions

2015-09-28 Thread Sukadev Bhattiprolu
Previously we were dropping the useful longer descriptions that some
events have in the event list completely. Now that jevents provides
support for longer descriptions (see previous patch), add support for
parsing the long descriptions

Signed-off-by: Andi Kleen 
Signed-off-by: Sukadev Bhattiprolu 
Acked-by: Jiri Olsa 
---

Changelog[v14]
- [Jiri Olsa] Break up independent parts of the patch into
  separate patches.
---
 tools/perf/util/parse-events.c |  5 +++--
 tools/perf/util/parse-events.h |  3 ++-
 tools/perf/util/pmu.c  | 15 ++-
 tools/perf/util/pmu.h  |  4 +++-
 4 files changed, 18 insertions(+), 9 deletions(-)

diff --git a/tools/perf/util/parse-events.c b/tools/perf/util/parse-events.c
index e9563a0..b23baa5 100644
--- a/tools/perf/util/parse-events.c
+++ b/tools/perf/util/parse-events.c
@@ -1717,7 +1717,8 @@ out_enomem:
 /*
  * Print the help text for the event symbols:
  */
-void print_events(const char *event_glob, bool name_only, bool quiet_flag)
+void print_events(const char *event_glob, bool name_only, bool quiet_flag,
+   bool long_desc)
 {
print_symbol_events(event_glob, PERF_TYPE_HARDWARE,
event_symbols_hw, PERF_COUNT_HW_MAX, name_only);
@@ -1727,7 +1728,7 @@ void print_events(const char *event_glob, bool name_only, 
bool quiet_flag)
 
print_hwcache_events(event_glob, name_only);
 
-   print_pmu_events(event_glob, name_only, quiet_flag);
+   print_pmu_events(event_glob, name_only, quiet_flag, long_desc);
 
if (event_glob != NULL)
return;
diff --git a/tools/perf/util/parse-events.h b/tools/perf/util/parse-events.h
index 37857e7..d081b73 100644
--- a/tools/perf/util/parse-events.h
+++ b/tools/perf/util/parse-events.h
@@ -139,7 +139,8 @@ void parse_events_update_lists(struct list_head *list_event,
 void parse_events_evlist_error(struct parse_events_evlist *data,
   int idx, const char *str);
 
-void print_events(const char *event_glob, bool name_only, bool quiet);
+void print_events(const char *event_glob, bool name_only, bool quiet,
+ bool long_desc);
 
 struct event_symbol {
const char  *symbol;
diff --git a/tools/perf/util/pmu.c b/tools/perf/util/pmu.c
index ca01aea..e608ccc 100644
--- a/tools/perf/util/pmu.c
+++ b/tools/perf/util/pmu.c
@@ -210,7 +210,7 @@ static int perf_pmu__parse_snapshot(struct perf_pmu_alias 
*alias,
 }
 
 static int __perf_pmu__new_alias(struct list_head *list, char *dir, char *name,
-char *desc, char *val)
+char *desc, char *val, char *long_desc)
 {
struct perf_pmu_alias *alias;
int ret;
@@ -243,6 +243,8 @@ static int __perf_pmu__new_alias(struct list_head *list, 
char *dir, char *name,
}
 
alias->desc = desc ? strdup(desc) : NULL;
+   alias->long_desc = long_desc ? strdup(long_desc) :
+   desc ? strdup(desc) : NULL;
 
list_add_tail(>list, list);
 
@@ -260,7 +262,7 @@ static int perf_pmu__new_alias(struct list_head *list, char 
*dir, char *name, FI
 
buf[ret] = 0;
 
-   return __perf_pmu__new_alias(list, dir, name, NULL, buf);
+   return __perf_pmu__new_alias(list, dir, name, NULL, buf, NULL);
 }
 
 static inline bool pmu_alias_info_file(char *name)
@@ -508,7 +510,8 @@ static int pmu_add_cpu_aliases(struct list_head *head)
 
/* need type casts to override 'const' */
__perf_pmu__new_alias(head, NULL, (char *)pe->name,
-   (char *)pe->desc, (char *)pe->event);
+   (char *)pe->desc, (char *)pe->event,
+   (char *)pe->long_desc);
}
 
 out:
@@ -1077,7 +1080,8 @@ static void wordwrap(char *s, int start, int max, int 
corr)
}
 }
 
-void print_pmu_events(const char *event_glob, bool name_only, bool quiet_flag)
+void print_pmu_events(const char *event_glob, bool name_only, bool quiet_flag,
+   bool long_desc)
 {
struct perf_pmu *pmu;
struct perf_pmu_alias *alias;
@@ -1124,7 +1128,8 @@ void print_pmu_events(const char *event_glob, bool 
name_only, bool quiet_flag)
if (!aliases[j].name)
goto out_enomem;
 
-   aliases[j].desc = alias->desc;
+   aliases[j].desc = long_desc ? alias->long_desc :
+   alias->desc;
j++;
}
if (pmu->selectable) {
diff --git a/tools/perf/util/pmu.h b/tools/perf/util/pmu.h
index 42999c7..1aa614e 100644
--- a/tools/perf/util/pmu.h
+++ b/tools/perf/util/pmu.h
@@ -39,6 +39,7 @@ struct perf_pmu_info {
 struct perf_pmu_alias {
char *name;
char *desc;
+   char *long_desc;
 

[PATCH v17 14/19] perf, tools: Add support for event list topics

2015-09-28 Thread Sukadev Bhattiprolu
From: Andi Kleen 

Add support to group the output of perf list by the Topic field
in the JSON file.

Example output:

% perf list
...
Cache:
  l1d.replacement
   [L1D data line replacements]
  l1d_pend_miss.pending
   [L1D miss oustandings duration in cycles]
  l1d_pend_miss.pending_cycles
   [Cycles with L1D load Misses outstanding]
  l2_l1d_wb_rqsts.all
   [Not rejected writebacks from L1D to L2 cache lines in any state]
  l2_l1d_wb_rqsts.hit_e
   [Not rejected writebacks from L1D to L2 cache lines in E state]
  l2_l1d_wb_rqsts.hit_m
   [Not rejected writebacks from L1D to L2 cache lines in M state]

...
Pipeline:
  arith.fpu_div
   [Divide operations executed]
  arith.fpu_div_active
   [Cycles when divider is busy executing divide operations]
  baclears.any
   [Counts the total number when the front end is resteered, mainly
   when the BPU cannot provide a correct prediction and this is
   corrected by other branch handling mechanisms at the front end]
  br_inst_exec.all_branches
   [Speculative and retired branches]
  br_inst_exec.all_conditional
   [Speculative and retired macro-conditional branches]
  br_inst_exec.all_direct_jmp
   [Speculative and retired macro-unconditional branches excluding
   calls and indirects]
  br_inst_exec.all_direct_near_call
   [Speculative and retired direct near calls]
  br_inst_exec.all_indirect_jump_non_call_ret

Signed-off-by: Andi Kleen 
Signed-off-by: Sukadev Bhattiprolu 
Acked-by: Jiri Olsa 
---

Changelog[v14]
- [Jiri Olsa] Move jevents support for Topic to a separate patch.
---
 tools/perf/util/pmu.c | 37 +++--
 tools/perf/util/pmu.h |  1 +
 2 files changed, 28 insertions(+), 10 deletions(-)

diff --git a/tools/perf/util/pmu.c b/tools/perf/util/pmu.c
index e608ccc..75a53d3 100644
--- a/tools/perf/util/pmu.c
+++ b/tools/perf/util/pmu.c
@@ -210,7 +210,8 @@ static int perf_pmu__parse_snapshot(struct perf_pmu_alias 
*alias,
 }
 
 static int __perf_pmu__new_alias(struct list_head *list, char *dir, char *name,
-char *desc, char *val, char *long_desc)
+char *desc, char *val, char *long_desc,
+char *topic)
 {
struct perf_pmu_alias *alias;
int ret;
@@ -245,6 +246,7 @@ static int __perf_pmu__new_alias(struct list_head *list, 
char *dir, char *name,
alias->desc = desc ? strdup(desc) : NULL;
alias->long_desc = long_desc ? strdup(long_desc) :
desc ? strdup(desc) : NULL;
+   alias->topic = topic ? strdup(topic) : NULL;
 
list_add_tail(>list, list);
 
@@ -262,7 +264,7 @@ static int perf_pmu__new_alias(struct list_head *list, char 
*dir, char *name, FI
 
buf[ret] = 0;
 
-   return __perf_pmu__new_alias(list, dir, name, NULL, buf, NULL);
+   return __perf_pmu__new_alias(list, dir, name, NULL, buf, NULL, NULL);
 }
 
 static inline bool pmu_alias_info_file(char *name)
@@ -511,7 +513,7 @@ static int pmu_add_cpu_aliases(struct list_head *head)
/* need type casts to override 'const' */
__perf_pmu__new_alias(head, NULL, (char *)pe->name,
(char *)pe->desc, (char *)pe->event,
-   (char *)pe->long_desc);
+   (char *)pe->long_desc, (char *)pe->topic);
}
 
 out:
@@ -1042,19 +1044,26 @@ static char *format_alias_or(char *buf, int len, struct 
perf_pmu *pmu,
return buf;
 }
 
-struct pair {
+struct sevent {
char *name;
char *desc;
+   char *topic;
 };
 
-static int cmp_pair(const void *a, const void *b)
+static int cmp_sevent(const void *a, const void *b)
 {
-   const struct pair *as = a;
-   const struct pair *bs = b;
+   const struct sevent *as = a;
+   const struct sevent *bs = b;
 
/* Put extra events last */
if (!!as->desc != !!bs->desc)
return !!as->desc - !!bs->desc;
+   if (as->topic && bs->topic) {
+   int n = strcmp(as->topic, bs->topic);
+
+   if (n)
+   return n;
+   }
return strcmp(as->name, bs->name);
 }
 
@@ -1088,9 +1097,10 @@ void print_pmu_events(const char *event_glob, bool 
name_only, bool quiet_flag,
char buf[1024];
int printed = 0;
int len, j;
-   struct pair *aliases;
+   struct sevent *aliases;
int numdesc = 0;
int columns = pager_get_columns();
+   char *topic = NULL;
 
pmu = NULL;
len = 0;
@@ -1100,7 +1110,7 @@ void print_pmu_events(const char *event_glob, bool 
name_only, bool quiet_flag,
if (pmu->selectable)
len++;
}
-   aliases = zalloc(sizeof(struct pair) * len);
+   aliases = zalloc(sizeof(struct sevent) 

[PATCH v17 12/19] perf, tools: Support long descriptions with perf list

2015-09-28 Thread Sukadev Bhattiprolu
Previously we were dropping the useful longer descriptions that some
events have in the event list completely. This patch makes them appear with
perf list.

Old perf list:

baclears:
  baclears.all
   [Counts the number of baclears]

vs new:

perf list -v:
...
baclears:
  baclears.all
   [The BACLEARS event counts the number of times the front end is
resteered, mainly when the Branch Prediction Unit cannot provide
a correct prediction and this is corrected by the Branch Address
Calculator at the front end. The BACLEARS.ANY event counts the
number of baclears for any type of branch]

Signed-off-by: Andi Kleen 
Signed-off-by: Sukadev Bhattiprolu 
Acked-by: Jiri Olsa 
---

Changelog[v15]
- [Jir Olsa, Andi Kleen] Fix usage strings; update man page.

Changelog[v14]
- [Jiri Olsa] Break up independent parts of the patch into
  separate patches.
---
 tools/perf/Documentation/perf-list.txt |  6 +-
 tools/perf/builtin-list.c  | 13 +
 2 files changed, 14 insertions(+), 5 deletions(-)

diff --git a/tools/perf/Documentation/perf-list.txt 
b/tools/perf/Documentation/perf-list.txt
index 9507552..48202f2 100644
--- a/tools/perf/Documentation/perf-list.txt
+++ b/tools/perf/Documentation/perf-list.txt
@@ -8,7 +8,7 @@ perf-list - List all symbolic event types
 SYNOPSIS
 
 [verse]
-'perf list' [--no-desc] [hw|sw|cache|tracepoint|pmu|event_glob]
+'perf list' [--no-desc] [--long-desc] [hw|sw|cache|tracepoint|pmu|event_glob]
 
 DESCRIPTION
 ---
@@ -20,6 +20,10 @@ OPTIONS
 --no-desc::
 Don't print descriptions.
 
+-v::
+--long-desc::
+Print longer event descriptions.
+
 
 [[EVENT_MODIFIERS]]
 EVENT MODIFIERS
diff --git a/tools/perf/builtin-list.c b/tools/perf/builtin-list.c
index 3f058f7..f800927 100644
--- a/tools/perf/builtin-list.c
+++ b/tools/perf/builtin-list.c
@@ -22,14 +22,17 @@ int cmd_list(int argc, const char **argv, const char 
*prefix __maybe_unused)
 {
int i;
bool raw_dump = false;
+   bool long_desc_flag = false;
struct option list_options[] = {
OPT_BOOLEAN(0, "raw-dump", _dump, "Dump raw events"),
OPT_BOOLEAN('d', "desc", _flag,
"Print extra event descriptions. --no-desc to not 
print."),
+   OPT_BOOLEAN('v', "long-desc", _desc_flag,
+   "Print longer event descriptions."),
OPT_END()
};
const char * const list_usage[] = {
-   "perf list [--no-desc] [hw|sw|cache|tracepoint|pmu|event_glob]",
+   "perf list [] [hw|sw|cache|tracepoint|pmu|event_glob]",
NULL
};
 
@@ -44,7 +47,7 @@ int cmd_list(int argc, const char **argv, const char *prefix 
__maybe_unused)
printf("\nList of pre-defined events (to be used in -e):\n\n");
 
if (argc == 0) {
-   print_events(NULL, raw_dump, !desc_flag);
+   print_events(NULL, raw_dump, !desc_flag, long_desc_flag);
return 0;
}
 
@@ -63,13 +66,15 @@ int cmd_list(int argc, const char **argv, const char 
*prefix __maybe_unused)
 strcmp(argv[i], "hwcache") == 0)
print_hwcache_events(NULL, raw_dump);
else if (strcmp(argv[i], "pmu") == 0)
-   print_pmu_events(NULL, raw_dump, !desc_flag);
+   print_pmu_events(NULL, raw_dump, !desc_flag,
+   long_desc_flag);
else {
char *sep = strchr(argv[i], ':'), *s;
int sep_idx;
 
if (sep == NULL) {
-   print_events(argv[i], raw_dump, !desc_flag);
+   print_events(argv[i], raw_dump, !desc_flag,
+   long_desc_flag);
continue;
}
sep_idx = sep - argv[i];
-- 
2.5.3

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[PATCH v17 17/19] perf, tools: Make alias matching case-insensitive

2015-09-28 Thread Sukadev Bhattiprolu
From: Andi Kleen 

Make alias matching the events parser case-insensitive. This is useful
with the JSON events. perf uses lower case events, but the CPU manuals
generally use upper case event names. The JSON files use lower
case by default too. But if we search case insensitively then
users can cut-n-paste the upper case event names.

So the following works:

% perf stat -e BR_INST_EXEC.TAKEN_INDIRECT_NEAR_CALL true

 Performance counter stats for 'true':

   305  BR_INST_EXEC.TAKEN_INDIRECT_NEAR_CALL

   0.000492799 seconds time elapsed

Signed-off-by: Andi Kleen 
---
 tools/perf/util/parse-events.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/perf/util/parse-events.c b/tools/perf/util/parse-events.c
index b23baa5..9982fd6 100644
--- a/tools/perf/util/parse-events.c
+++ b/tools/perf/util/parse-events.c
@@ -1020,7 +1020,7 @@ comp_pmu(const void *p1, const void *p2)
struct perf_pmu_event_symbol *pmu1 = (struct perf_pmu_event_symbol *) 
p1;
struct perf_pmu_event_symbol *pmu2 = (struct perf_pmu_event_symbol *) 
p2;
 
-   return strcmp(pmu1->symbol, pmu2->symbol);
+   return strcasecmp(pmu1->symbol, pmu2->symbol);
 }
 
 static void perf_pmu__parse_cleanup(void)
-- 
2.5.3

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[PATCH v17 19/19] perf, tools, pmu-events: Add Skylake frontend MSR support

2015-09-28 Thread Sukadev Bhattiprolu
From: Andi Kleen 

Add support for the "frontend" extra MSR on Skylake in the JSON
conversion.

Signed-off-by: Andi Kleen 
---
 tools/perf/pmu-events/jevents.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/tools/perf/pmu-events/jevents.c b/tools/perf/pmu-events/jevents.c
index 247d777e..96e233e 100644
--- a/tools/perf/pmu-events/jevents.c
+++ b/tools/perf/pmu-events/jevents.c
@@ -126,6 +126,7 @@ static struct msrmap {
{ "0x3F6", "ldlat=" },
{ "0x1A6", "offcore_rsp=" },
{ "0x1A7", "offcore_rsp=" },
+   { "0x3F7", "frontend=" },
{ NULL, NULL }
 };
 
-- 
2.5.3

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH v3 3/3] dmaengine: mpc512x: initialize with subsys_initcall()

2015-09-28 Thread Alexander Popov
On 25.09.2015 03:16, Timur Tabi wrote:
> Alexander Popov wrote:
>> Initialize Freescale MPC512x DMA driver with subsys_initcall()
>> to allow the depending drivers to call dma_request_slave_channel()
>> during their probe.
>>
>> Signed-off-by: Alexander Popov
> 
> Is there any way we can use -EPROBEDEFER instead?

Thanks Timur, I'll try.

Best regards,
Alexander
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH v3 2/3] powerpc/512x: add a device tree binding for LocalPlus Bus FIFO

2015-09-28 Thread Alexander Popov
On 25.09.2015 03:18, Timur Tabi wrote:
> Alexander Popov wrote:
>> +- dma-names: should be "rx-tx";
> 
> Why bother, if it can only be one value?

I've just followed devicetree/bindings/dma/dma.txt...
This "rx-tx" doesn't mean much but it could show that LocalPlus Bus FIFO
uses a single DMA read-write channel. Should I really drop it?

Best regards,
Alexander
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH v3 2/3] powerpc/512x: add a device tree binding for LocalPlus Bus FIFO

2015-09-28 Thread Timur Tabi

Alexander Popov wrote:

I've just followed devicetree/bindings/dma/dma.txt...
This "rx-tx" doesn't mean much but it could show that LocalPlus Bus FIFO
uses a single DMA read-write channel. Should I really drop it?


Hmmm, I'm not sure.  Is there anything else (besides your driver) that 
parses this device tree node?


dma.txt says this:

	"The specific strings that can be used are defined in the binding of 
the DMA client device."


So this looks like it's driver-specific, but it is a required property.
I guess you should keep it, but I think you should get a second opinion.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH v3 1/3] powerpc/512x: add LocalPlus Bus FIFO device driver

2015-09-28 Thread Alexander Popov
Hello, Timur, thanks a lot for your review.
I'll fix all the issues you pointed at and return with v4.

The only question I have: why calling dma_unmap_single() from within
a spinlock is a bad practice?

Best regards,
Alexander
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH v3 1/3] powerpc/512x: add LocalPlus Bus FIFO device driver

2015-09-28 Thread Timur Tabi

Alexander Popov wrote:

The only question I have: why calling dma_unmap_single() from within
a spinlock is a bad practice?


I don't know, but usually functions that allocate or free memory cannot 
be called from within a spinlock.  You need to check that.  Since the 
MPC5121 is a single-core CPU, you might not notice if you're doing 
something wrong.

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev