Re: PCIe Access - achieve bursts without DMA

2014-02-03 Thread Michael Moese
On Fri, Jan 31, 2014 at 03:18:30PM -0800, David Hawkins wrote:
> 1. Peripheral board DMA (board-to-board)
> 2. Peripheral board DMA to host memory.
> 3. Host (root complex) DMA.
> 
> As far as "verification" of your custom peripheral board FPGA IP is
> concerned, if I was a customer, and you had data for (1) and (2),
> I'd be pretty happy (and could care less about (2), since its so
> system dependent).

Usually I would totally agree with you and try to implement the benchmark
using DMA transfers Unfortunately, we have some boards and IP cores that
do not support DMA transfers, or the target system must not do by a 
requirement, and as I have no influence on these, I had to investigate
on how to improve my throughput.
I've submitted a RFC Patch earlier today, which allowed me to perform
PCIe read bursts on IO memory, achieving 18 MB/s instead of the 3 MB/s
I got when using non-cached reads. However, I had to ioremap() my 
memory, like Gabriel said, using write-thru configuration. 

> Since its an FPGA-based IP. I'd also expect to see a PCIe simulation
> with Bus Functional Models showing what the optimal performance of
> your IP was, and then how it nicely matches with the measurements
> in (1). If you do not have a PCIe logic analyzer, both Xilinx and
> Altera have Chipscope/SignalTap logic analyzers that can be used
> for tracing traffic at the TLP layer inside the FPGA.

Of course our IP developers to simulation and analyzing, we have PCI
and PCIe analyzer and all other equipment one might need. However,
we've seen that not only on PowerPC but also on x86, performing real
bursts is not intuitive.


Thank you for your help - we might be satisfied with the achieved 
18 MB/s.


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


Re: [RFC PATCH] powerpc: add ioremap_wt

2014-02-03 Thread Gabriel Paubert
On Mon, Feb 03, 2014 at 08:16:49AM +0100, Michael Moese wrote:
> Allow for IO memory to be mapped cacheable for performing
> PCI read bursts.
> 
> Signed-off-by: Michael Moese 
> ---
>  arch/powerpc/include/asm/io.h | 3 +++
>  arch/powerpc/mm/pgtable_32.c  | 8 
>  2 files changed, 11 insertions(+)
> 
> diff --git a/arch/powerpc/include/asm/io.h b/arch/powerpc/include/asm/io.h
> index 45698d5..9591fff 100644
> --- a/arch/powerpc/include/asm/io.h
> +++ b/arch/powerpc/include/asm/io.h
> @@ -631,6 +631,8 @@ static inline void iosync(void)
>   *
>   * * ioremap_wc enables write combining
>   *
> + * * ioremap_wc enables write thru

Typo: _wc -> _wt

Looks fine in principle, but there is a significant difference with wc
on x86, where read accesses always go to the bus (no read caching).

Gabriel

> + *
>   * * iounmap undoes such a mapping and can be hooked
>   *
>   * * __ioremap_at (and the pending __iounmap_at) are low level functions to
> @@ -652,6 +654,7 @@ extern void __iomem *ioremap(phys_addr_t address, 
> unsigned long size);
>  extern void __iomem *ioremap_prot(phys_addr_t address, unsigned long size,
> unsigned long flags);
>  extern void __iomem *ioremap_wc(phys_addr_t address, unsigned long size);
> +extern void __iomem *ioremap_wt(phys_addr_t address, unsigned long size);
>  #define ioremap_nocache(addr, size)  ioremap((addr), (size))
>  
>  extern void iounmap(volatile void __iomem *addr);
> diff --git a/arch/powerpc/mm/pgtable_32.c b/arch/powerpc/mm/pgtable_32.c
> index 51f8795..9ab0a54 100644
> --- a/arch/powerpc/mm/pgtable_32.c
> +++ b/arch/powerpc/mm/pgtable_32.c
> @@ -141,6 +141,14 @@ ioremap_wc(phys_addr_t addr, unsigned long size)
>  EXPORT_SYMBOL(ioremap_wc);
>  
>  void __iomem *
> +ioremap_wt(phys_addr_t addr, unsigned long size)
> +{
> + return __ioremap_caller(addr, size, _PAGE_WRITETHRU,
> + __builtin_return_address(0));
> +}
> +EXPORT_SYMBOL(ioremap_wt);
> +
> +void __iomem *
>  ioremap_prot(phys_addr_t addr, unsigned long size, unsigned long flags)
>  {
>   /* writeable implies dirty for kernel addresses */
> -- 
> 1.8.5.3
> 
> ___
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


RE: PCIe Access - achieve bursts without DMA

2014-02-03 Thread David Laight
From: Michael Moese
> Thank you for your help - we might be satisfied with the achieved
> 18 MB/s.

We achieved about twice that using the PEX dma controller.
I found the following comment I wrote:

/* Long transfer requests are cut into smaller DMA requests.
 * Each PCIe request can contain a maximum of 128 bytes, but the
 * dma engine can have multiple PCIe requests outstanding and this
 * speeds things up somewhat (50ns/byte with 128, 24ns/byte with 1024).
 * 1k is somewhere near the point of diminishing returns. */

Those times would include a system call.
The transfers were done through a simple driver that converted pread()
and pwrite() requests into accesses to the boards memory.
The non-dma versions are just copy_to/from_user() directly between
the PCIe and user buffers.

Your 3MB/s for single word transfers is similar to what we saw.
Cycle times that make an ISA bus look fast.

David



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


Re: PCIe Access - achieve bursts without DMA

2014-02-03 Thread Michael Moese
On Mon, Feb 03, 2014 at 10:17:43AM +, David Laight wrote:

> We achieved about twice that using the PEX dma controller.

> Your 3MB/s for single word transfers is similar to what we saw.
> Cycle times that make an ISA bus look fast.

Indeed, this is a really poor performance. I know we could achieve much
more performance using DMA, we have several products where we simply 
don't have DMA available - this requires searching for other paths.

My ioremap_wt() could help in these situations, at least increasing
performance for non-DMA operation to a not-that-bad level.

I don't know if other devices could benefit from this, but surely we
got several IPs that would, but those were not yet upstreamed, we're
still working on this.

Michael


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


RE: PCIe Access - achieve bursts without DMA

2014-02-03 Thread David Laight
From: Michael Moese 
> On Mon, Feb 03, 2014 at 10:17:43AM +, David Laight wrote:
> 
> > We achieved about twice that using the PEX dma controller.
> 
> > Your 3MB/s for single word transfers is similar to what we saw.
> > Cycle times that make an ISA bus look fast.
> 
> Indeed, this is a really poor performance. I know we could achieve much
> more performance using DMA, we have several products where we simply
> don't have DMA available - this requires searching for other paths.

I got the host (ppc) to do a dma, not the card. (This does need a
dma controller that is adequately intergrated with the PCIe logic.)
So it doesn't require any hardware changes.
I did have to design the software to minimise the number of single
memory transfers.

> My ioremap_wt() could help in these situations, at least increasing
> performance for non-DMA operation to a not-that-bad level.

I needed to do writes as well as reads - so I think I would have
needed to map PCIe space fully cached (rather than write-through).
The speed of back to back writes is better than reads (even if they don't
get combined) because the requests get 'posted' and overlap on the
PCIe bus.

Managing cached accesses does get tricky - you need to make sure that
both sides never have to write to the same cache line.

> I don't know if other devices could benefit from this, but surely we
> got several IPs that would, but those were not yet upstreamed, we're
> still working on this.
> 
> Michael
> 



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


Re: [PATCH] powerpc: thp: Fix crash on mremap

2014-02-03 Thread Luis Henriques
On Tue, Jan 28, 2014 at 05:47:03PM +0530, Aneesh Kumar K.V wrote:
> This patch fix the below crash
> 
> NIP [c004cee4] .__hash_page_thp+0x2a4/0x440
> LR [c00439ac] .hash_page+0x18c/0x5e0
> ...
> Call Trace:
> [c00736103c40] [1b00] 0x1b00(unreliable)
> [437908.479693] [c00736103d50] [c00439ac] .hash_page+0x18c/0x5e0
> [437908.479699] [c00736103e30] [c000924c] .do_hash_page+0x4c/0x58
> 
> On ppc64 we use the pgtable for storing the hpte slot information and
> store address to the pgtable at a constant offset (PTRS_PER_PMD) from
> pmd. On mremap, when we switch the pmd, we need to withdraw and deposit
> the pgtable again, so that we find the pgtable at PTRS_PER_PMD offset
> from new pmd.
> 
> We also want to move the withdraw and deposit before the set_pmd so
> that, when page fault find the pmd as trans huge we can be sure that
> pgtable can be located at the offset.
> 
> variant of upstream SHA1: b3084f4db3aeb991c507ca774337c7e7893ed04f
> for 3.11 stable series
> 

Since both you and Benjamin Herrenschmidt claim this is good for stable, I
am queuing this variant for the 3.11 kernel.  Thanks a lot!

Cheers,
--
Luis

> Signed-off-by: Aneesh Kumar K.V 
> ---
>  arch/Kconfig   |  3 +++
>  arch/powerpc/platforms/Kconfig.cputype |  1 +
>  mm/huge_memory.c   | 12 
>  3 files changed, 16 insertions(+)
> 
> diff --git a/arch/Kconfig b/arch/Kconfig
> index 1feb169274fe..c5863b35d054 100644
> --- a/arch/Kconfig
> +++ b/arch/Kconfig
> @@ -368,6 +368,9 @@ config HAVE_ARCH_TRANSPARENT_HUGEPAGE
>  config HAVE_ARCH_SOFT_DIRTY
>   bool
>  
> +config ARCH_THP_MOVE_PMD_ALWAYS_WITHDRAW
> + bool
> +
>  config HAVE_MOD_ARCH_SPECIFIC
>   bool
>   help
> diff --git a/arch/powerpc/platforms/Kconfig.cputype 
> b/arch/powerpc/platforms/Kconfig.cputype
> index 47d9a03dd415..d11a34be018d 100644
> --- a/arch/powerpc/platforms/Kconfig.cputype
> +++ b/arch/powerpc/platforms/Kconfig.cputype
> @@ -71,6 +71,7 @@ config PPC_BOOK3S_64
>   select PPC_FPU
>   select PPC_HAVE_PMU_SUPPORT
>   select SYS_SUPPORTS_HUGETLBFS
> + select ARCH_THP_MOVE_PMD_ALWAYS_WITHDRAW
>   select HAVE_ARCH_TRANSPARENT_HUGEPAGE if PPC_64K_PAGES
>  
>  config PPC_BOOK3E_64
> diff --git a/mm/huge_memory.c b/mm/huge_memory.c
> index 12acb0ba7991..beaa7cc9de75 100644
> --- a/mm/huge_memory.c
> +++ b/mm/huge_memory.c
> @@ -1461,8 +1461,20 @@ int move_huge_pmd(struct vm_area_struct *vma, struct 
> vm_area_struct *new_vma,
>  
>   ret = __pmd_trans_huge_lock(old_pmd, vma);
>   if (ret == 1) {
> +#ifdef CONFIG_ARCH_THP_MOVE_PMD_ALWAYS_WITHDRAW
> + pgtable_t pgtable;
> +#endif
>   pmd = pmdp_get_and_clear(mm, old_addr, old_pmd);
>   VM_BUG_ON(!pmd_none(*new_pmd));
> +#ifdef CONFIG_ARCH_THP_MOVE_PMD_ALWAYS_WITHDRAW
> + /*
> +  * Archs like ppc64 use pgtable to store per pmd
> +  * specific information. So when we switch the pmd,
> +  * we should also withdraw and deposit the pgtable
> +  */
> + pgtable = pgtable_trans_huge_withdraw(mm, old_pmd);
> + pgtable_trans_huge_deposit(mm, new_pmd, pgtable);
> +#endif
>   set_pmd_at(mm, new_addr, new_pmd, pmd_mksoft_dirty(pmd));
>   spin_unlock(&mm->page_table_lock);
>   }
> -- 
> 1.8.5.3
> 
> --
> To unsubscribe from this list: send the line "unsubscribe stable" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


Re: PCIe Access - achieve bursts without DMA

2014-02-03 Thread David Hawkins

Hi Michael,


On Fri, Jan 31, 2014 at 03:18:30PM -0800, David Hawkins wrote:

1. Peripheral board DMA (board-to-board)
2. Peripheral board DMA to host memory.
3. Host (root complex) DMA.

As far as "verification" of your custom peripheral board FPGA IP is
concerned, if I was a customer, and you had data for (1) and (2),
I'd be pretty happy (and could care less about (2), since its so
system dependent).


Usually I would totally agree with you and try to implement the benchmark
using DMA transfers Unfortunately, we have some boards and IP cores that
do not support DMA transfers, or the target system must not do by a
requirement, and as I have no influence on these, I had to investigate
on how to improve my throughput.


Ah, I see, that does make your life difficult then.


I've submitted a RFC Patch earlier today, which allowed me to perform
PCIe read bursts on IO memory, achieving 18 MB/s instead of the 3 MB/s
I got when using non-cached reads. However, I had to ioremap() my
memory, like Gabriel said, using write-thru configuration.


That sounds like a reasonable compromise.

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


[PATCH V4 1/3] powerpc/powernv: Push critical error logs to FSP

2014-02-03 Thread Deepthi Dharwar
This patch provides error logging interfaces to report critical
powernv error logs to FSP.
All the required information to dump the error is collected
at POWERNV level through error log interfaces
and then pushed on to FSP.

Signed-off-by: Deepthi Dharwar 
---
 arch/powerpc/include/asm/opal.h|   36 ++
 arch/powerpc/platforms/powernv/opal-elog.c |   77 ++
 arch/powerpc/platforms/powernv/opal-wrappers.S |2 -
 arch/powerpc/platforms/powernv/powernv.h   |   84 
 4 files changed, 196 insertions(+), 3 deletions(-)

diff --git a/arch/powerpc/include/asm/opal.h b/arch/powerpc/include/asm/opal.h
index 554a031..6f9e02a 100644
--- a/arch/powerpc/include/asm/opal.h
+++ b/arch/powerpc/include/asm/opal.h
@@ -268,6 +268,40 @@ enum OpalMessageType {
OPAL_MSG_TYPE_MAX,
 };
 
+/* Max user dump size is 14K*/
+#define OPAL_LOG_MAX_DUMP   14336
+
+/* Multiple user data sections */
+struct __attribute__((__packed__)) opal_user_data_section {
+   uint32_t tag;
+   uint16_t size;
+   uint16_t component_id;
+   char data_dump[1];
+};
+
+/*
+ * All the information regarding an error/event to be reported
+ * needs to populate this structure using pre-defined interfaces
+ * only
+ */
+struct __attribute__((__packed__)) opal_errorlog {
+
+   uint16_t component_id;
+   uint8_t error_event_type;
+   uint8_t subsystem_id;
+
+   uint8_t event_severity;
+   uint8_t event_subtype;
+   uint8_t user_section_count;
+   uint8_t elog_origin;
+
+   uint32_t user_section_size;
+   uint32_t reason_code;
+   uint32_t additional_info[4];
+
+   char user_data_dump[OPAL_LOG_MAX_DUMP];
+};
+
 /* Machine check related definitions */
 enum OpalMCE_Version {
OpalMCE_V1 = 1,
@@ -859,7 +893,7 @@ int64_t opal_lpc_read(uint32_t chip_id, enum 
OpalLPCAddressType addr_type,
  uint32_t addr, uint32_t *data, uint32_t sz);
 int64_t opal_read_elog(uint64_t buffer, size_t size, uint64_t log_id);
 int64_t opal_get_elog_size(uint64_t *log_id, size_t *size, uint64_t 
*elog_type);
-int64_t opal_write_elog(uint64_t buffer, uint64_t size, uint64_t offset);
+int64_t opal_elog_write(void *buffer);
 int64_t opal_send_ack_elog(uint64_t log_id);
 void opal_resend_pending_logs(void);
 int64_t opal_validate_flash(uint64_t buffer, uint32_t *size, uint32_t *result);
diff --git a/arch/powerpc/platforms/powernv/opal-elog.c 
b/arch/powerpc/platforms/powernv/opal-elog.c
index fc891ae..0a03b60 100644
--- a/arch/powerpc/platforms/powernv/opal-elog.c
+++ b/arch/powerpc/platforms/powernv/opal-elog.c
@@ -8,6 +8,9 @@
  * as published by the Free Software Foundation; either version
  * 2 of the License, or (at your option) any later version.
  */
+#undef DEBUG
+#define pr_fmt(fmt) "ELOG: " fmt
+
 #include 
 #include 
 #include 
@@ -16,8 +19,9 @@
 #include 
 #include 
 #include 
+#include 
 #include 
-#include 
+#include "powernv.h"
 
 /* Maximum size of a single log on FSP is 16KB */
 #define OPAL_MAX_ERRLOG_SIZE   16384
@@ -272,6 +276,77 @@ static int init_err_log_buffer(void)
return 0;
 }
 
+/* Interface to be used by POWERNV to push the logs to FSP via Sapphire */
+struct opal_errorlog *pnv_elog_create(uint8_t pnv_error_event_type,
+   uint16_t pnv_component_id, uint8_t pnv_subsystem_id,
+   uint8_t pnv_event_severity, uint8_t pnv_event_subtype,
+   uint32_t reason_code, uint32_t info0, uint32_t info1,
+   uint32_t info2, uint32_t info3)
+{
+   struct opal_errorlog *buf;
+
+   buf = kzalloc(sizeof(struct opal_errorlog), GFP_ATOMIC);
+   if (!buf) {
+   pr_err("Failed to allocate buffer for generating error log\n");
+   return NULL;
+   }
+
+   buf->error_event_type = pnv_error_event_type;
+   buf->component_id = pnv_component_id;
+   buf->subsystem_id = pnv_subsystem_id;
+   buf->event_severity = pnv_event_severity;
+   buf->event_subtype = pnv_event_subtype;
+   buf->reason_code = reason_code;
+   buf->additional_info[0] = info0;
+   buf->additional_info[1] = info1;
+   buf->additional_info[2] = info2;
+   buf->additional_info[3] = info3;
+   return buf;
+}
+
+int pnv_elog_update_user_dump(struct opal_errorlog *buf, unsigned char *data,
+   uint32_t tag, uint16_t size)
+{
+   char *buffer;
+   struct opal_user_data_section *tmp;
+
+   if (!buf) {
+   pr_err("Cannot update user data. Error log buffer is invalid");
+   return -1;
+   }
+
+   buffer = (char *)buf->user_data_dump + buf->user_section_size;
+   if ((buf->user_section_size + size) > OPAL_LOG_MAX_DUMP) {
+   pr_err("Size of user data overruns the buffer");
+   return -1;
+   }
+
+   tmp = (struct opal_user_data_section *)buffer;
+   tmp->tag = tag;
+ 

[PATCH V4 0/3] powerpc/powernv: Error logging interfaces

2014-02-03 Thread Deepthi Dharwar
This patch series defines generic interfaces for error logging to
push down critical errors from powernv platform to FSP.

Also, it contains few minor fixes for the exisiting error logging
framework that retrieves error logs from FSP.

Changes from V3:
* Change memory allocation to GFP_ATOMIC, to generate
  errors in bad context
* Move all error log generation related code to arch/powernv
  rename it from opal_* to pnv_* .

Changes from V2:
* Review comments from V2 have been addressed
  includes comment formats, changing naming
  conventions and incorporated error handling
  of the buffers.
* Minor typo fix and use of pr_err/pr_fmt to
  log errors.

 Deepthi Dharwar (3):
  powernv: Push critical error logs to FSP
  powernv: Correct spell error in opal-elog.c
  powernv: Have uniform logging of errors in opal-elog.c


 arch/powerpc/include/asm/opal.h|   36 +
 arch/powerpc/platforms/powernv/opal-elog.c |   93 +---
 arch/powerpc/platforms/powernv/opal-wrappers.S |2 -
 arch/powerpc/platforms/powernv/powernv.h   |   84 ++
 4 files changed, 203 insertions(+), 12 deletions(-)


-- Deepthi

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


[PATCH V4 2/3] powerpc/powernv: Correct spell error in opal-elog.c

2014-02-03 Thread Deepthi Dharwar
Correct spell error in opal-elog.c

Signed-off-by: Deepthi Dharwar 
---
 arch/powerpc/platforms/powernv/opal-elog.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/powerpc/platforms/powernv/opal-elog.c 
b/arch/powerpc/platforms/powernv/opal-elog.c
index 0a03b60..13874b1 100644
--- a/arch/powerpc/platforms/powernv/opal-elog.c
+++ b/arch/powerpc/platforms/powernv/opal-elog.c
@@ -26,7 +26,7 @@
 /* Maximum size of a single log on FSP is 16KB */
 #define OPAL_MAX_ERRLOG_SIZE   16384
 
-/* maximu number of records powernv can hold */
+/* Maximum number of records powernv platform can hold */
 #define MAX_NUM_RECORD 128
 
 struct opal_err_log {

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


[PATCH V4 3/3] powerpc/powernv: Have uniform logging of errors in opal-elog.c

2014-02-03 Thread Deepthi Dharwar
Currently some errors/info to be reported use
printk and the rest pr_fmt(). This patch
makes the complete error logging uniform.

Signed-off-by: Deepthi Dharwar 
---
 arch/powerpc/platforms/powernv/opal-elog.c |   14 ++
 1 file changed, 6 insertions(+), 8 deletions(-)

diff --git a/arch/powerpc/platforms/powernv/opal-elog.c 
b/arch/powerpc/platforms/powernv/opal-elog.c
index 13874b1..d7a3e68 100644
--- a/arch/powerpc/platforms/powernv/opal-elog.c
+++ b/arch/powerpc/platforms/powernv/opal-elog.c
@@ -63,7 +63,7 @@ void opal_elog_ack(uint64_t ack_id)
struct opal_err_log *record, *next;
bool found = false;
 
-   printk(KERN_INFO "OPAL Log ACK=%llx", ack_id);
+   pr_info("OPAL Log ACK=%llx", ack_id);
 
/* once user acknowledge a log delete record from list */
spin_lock_irqsave(&opal_elog_lock, flags);
@@ -189,7 +189,7 @@ static void opal_elog_read(void)
/* read log size and log ID from OPAL */
rc = opal_get_elog_size(&log_id, &elog_size, &elog_type);
if (rc != OPAL_SUCCESS) {
-   pr_err("ELOG: Opal log read failed\n");
+   pr_err("Opal log read failed\n");
return;
}
if (elog_size >= OPAL_MAX_ERRLOG_SIZE)
@@ -203,7 +203,7 @@ static void opal_elog_read(void)
rc = opal_read_elog(__pa(err_log_data), elog_size, log_id);
if (rc != OPAL_SUCCESS) {
mutex_unlock(&err_log_data_mutex);
-   pr_err("ELOG: log read failed for log-id=%llx\n", log_id);
+   pr_err("Reading of log failed for log-id=%llx\n", log_id);
/* put back the free node. */
spin_lock_irqsave(&opal_elog_lock, flags);
list_add(&record->link, &elog_ack_list);
@@ -265,7 +265,7 @@ static int init_err_log_buffer(void)
 
buf_ptr = vmalloc(sizeof(struct opal_err_log) * MAX_NUM_RECORD);
if (!buf_ptr) {
-   printk(KERN_ERR "ELOG: failed to allocate memory.\n");
+   pr_err("Failed to allocate memory for error logging 
buffers.\n");
return -ENOMEM;
}
memset(buf_ptr, 0, sizeof(struct opal_err_log) * MAX_NUM_RECORD);
@@ -358,15 +358,13 @@ int __init opal_elog_init(void)
 
rc = sysfs_create_bin_file(opal_kobj, &opal_elog_attr);
if (rc) {
-   printk(KERN_ERR "ELOG: unable to create sysfs file"
-   "opal_elog (%d)\n", rc);
+   pr_err("Unable to create sysfs file opal_elog (%d)\n", rc);
return rc;
}
 
rc = sysfs_create_file(opal_kobj, &opal_elog_ack_attr.attr);
if (rc) {
-   printk(KERN_ERR "ELOG: unable to create sysfs file"
-   " opal_elog_ack (%d)\n", rc);
+   pr_err("Unable to create sysfs file opal_elog_ack (%d)\n", rc);
return rc;
}
 

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


Re: [PATCH 6/8] powerpc/perf: add support for the hv gpci (get performance counter info) interface

2014-02-03 Thread Cody P Schafer

On 01/31/2014 09:58 PM, Michael Ellerman wrote:

On Thu, 2014-16-01 at 23:53:52 UTC, Cody P Schafer wrote:

This provides a basic link between perf and hv_gpci. Notably, it does
not yet support transactions and does not list any events (they can
still be manually composed).


What are the plans for listing?


I'm looking at extending the sysfs api for listing perf events. We can't 
use the existing one as it doesn't let us parametrize the events by 
anything, meaning we'd need to list an essentially duplicate event for 
each cpu/core/chip and lpar (guest). The duplication in cpu/core/chip 
comes from not using the typical cpu parameter to perf_event_open() 
(which we don't do because it wouldn't make sense when the guest 
monitored isn't us).



The manual compose is nice but pretty hairy to use in practice I would think.


diff --git a/arch/powerpc/perf/hv-gpci.c b/arch/powerpc/perf/hv-gpci.c
new file mode 100644
index 000..31d9d59
--- /dev/null
+++ b/arch/powerpc/perf/hv-gpci.c
@@ -0,0 +1,235 @@
+/*
+ * Hypervisor supplied "gpci" ("get performance counter info") performance
+ * counter support
+ *
+ * Author: Cody P Schafer 
+ * Copyright 2014 IBM Corporation.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version
+ * 2 of the License, or (at your option) any later version.
+ */
+#define pr_fmt(fmt) "hv-gpci: " fmt
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 


Needed?



asm/io.h is for virt_to_phys(). And yes, I need it.


+/* See arch/powerpc/include/asm/hv_gpci.h for details on the hcall interface */
+
+PMU_RANGE_ATTR(request, config, 0, 31); /* u32 */
+PMU_RANGE_ATTR(starting_index, config, 32, 63); /* u32 */
+PMU_RANGE_ATTR(secondary_index, config1, 0, 15); /* u16 */
+PMU_RANGE_ATTR(counter_info_version, config1, 16, 23); /* u8 */
+PMU_RANGE_ATTR(length, config1, 24, 31); /* u8, bytes of data (1-8) */
+PMU_RANGE_ATTR(offset, config1, 32, 63); /* u32, byte offset */
+
+static struct attribute *format_attr[] = {
+   &format_attr_request.attr,
+   &format_attr_starting_index.attr,
+   &format_attr_secondary_index.attr,
+   &format_attr_counter_info_version.attr,
+

Lonley blank line.


Which was seperating "real" attributes from those provided by the kernel 
(gpci doesn't know about "offset" and "length"). I'll remove.



+   &format_attr_offset.attr,
+   &format_attr_length.attr,
+   NULL,
+};
+
+static struct attribute_group format_group = {
+   .name = "format",
+   .attrs = format_attr,
+};
+
+static const struct attribute_group *attr_groups[] = {
+   &format_group,
+   NULL,
+};
+
+static unsigned long single_gpci_request(u32 req, u32 starting_index,
+   u16 secondary_index, u8 version_in, u32 offset, u8 length,
+   u64 *value)


Passing the event and extracting the values in here would be neater IMHO.



Well, I'll at least add a wrapper that does that. The idea here was to 
separate the perf specific logic from the gpci specific logic. And I'll 
end up taking advantage of that separation when doing the interface 
probing (mentioned way down near the end of this email).



+{
+   unsigned long ret;
+   size_t i;
+   u64 count;
+
+   struct {
+   struct hv_get_perf_counter_info_params params;
+   union {
+   union h_gpci_cvs data;
+   uint8_t bytes[sizeof(union h_gpci_cvs)];
+   };
+   } arg = {
+   .params = {
+   .counter_request = cpu_to_be32(req),
+   .starting_index = cpu_to_be32(starting_index),
+   .secondary_index = cpu_to_be16(secondary_index),
+   .counter_info_version_in = version_in,
+   }
+   };
+
+   ret = plpar_hcall_norets(H_GET_PERF_COUNTER_INFO,
+   virt_to_phys(&arg), sizeof(arg));
+   if (ret) {
+   pr_devel("hcall failed: 0x%lx\n", ret);
+   return ret;
+   }
+
+   /*
+* we verify offset and length are within the zeroed buffer at event
+* init.
+*/
+   count = 0;
+   for (i = offset; i < offset + length; i++)
+   count |= arg.bytes[i] << (i - offset);
+
+   *value = count;
+   return ret;
+}
+
+static u64 h_gpci_get_value(struct perf_event *event)
+{
+   u64 count;
+   unsigned long ret = single_gpci_request(event_get_request(event),
+   event_get_starting_index(event),
+   event_get_secondary_index(event),
+   event_get_counter_info_version(event),
+   event_get_offset(event),
+   event_get_length(event),
+   

Re: [PATCH 1/8] perf: add PMU_RANGE_ATTR() helper for use by sw-like pmus

2014-02-03 Thread Cody P Schafer

On 01/31/2014 09:58 PM, Michael Ellerman wrote:

On Thu, 2014-16-01 at 23:53:47 UTC, Cody P Schafer wrote:

Add PMU_RANGE_ATTR() and PMU_RANGE_RESV() (for reserved areas) which
generate functions to extract the relevent bits from
event->attr.config{,1,2} for use by sw-like pmus where the
'config{,1,2}' values don't map directly to hardware registers.


This is neat.

The split of the macros is a bit weird, ie. PMU_RANGE_RESV() doesn't really do
what it's name suggests.

I think you want one macro which creates the accessors, with a name that
reflects that - yeah I can't think of a good one right now, but "event" should
probably be in there because that's what it operates on.

Having a macro for the reserved regions is good, but you MUST actually check
that the reserved regions are zero. Otherwise you are permitting your caller to
pass junk in there and you then can't unreserved them in a future version of
the API.

So I think a macro that gives you a special reserved region routine would be
good, so you can write something like:

   if (event_check_reserved1() || event_check_reserved2())
return -EINVAL;



The way it's set up right now, RESV is just a hint to the user of the 
PMU_RANGE_ATTR() and PMU_RANGE_RESV() macros to indicate which to use. 
RESV simply avoids creating an attr format which would go unused only in 
the case where the range is a reserved one (and gcc would complain about 
it).


I don't like the "event_check_foo()" bit because that is actually 
identical to "event_get_foo()", I don't see a point in generating 
differently named functions that do exactly the same thing.


The current user (hv-24x7.c) of PMU_RANGE_RESV() already does the 
appropriate checking:


if (event_get_reserved1(event) ||
event_get_reserved2(event) ||
event_get_reserved3(event)) {
		pr_devel("reserved set when forbidden 0x%llx(0x%llx) 0x%llx(0x%llx) 
0x%llx(0x%llx)\n",

event->attr.config,
event_get_reserved1(event),
event->attr.config1,
event_get_reserved2(event),
event->attr.config2,
event_get_reserved3(event));
return -EINVAL;
}

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


Re: [PATCH 3/8] powerpc: add hvcalls for 24x7 and gpci (get performance counter info)

2014-02-03 Thread Cody P Schafer

On 01/31/2014 09:58 PM, Michael Ellerman wrote:

On Thu, 2014-16-01 at 23:53:49 UTC, Cody P Schafer wrote:

Signed-off-by: Cody P Schafer 
---
  arch/powerpc/include/asm/hvcall.h | 6 +-
  1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/arch/powerpc/include/asm/hvcall.h 
b/arch/powerpc/include/asm/hvcall.h
index d8b600b..48d6efa 100644
--- a/arch/powerpc/include/asm/hvcall.h
+++ b/arch/powerpc/include/asm/hvcall.h
@@ -269,11 +269,15 @@
  #define H_COP 0x304
  #define H_GET_MPP_X   0x314
  #define H_SET_MODE0x31C
-#define MAX_HCALL_OPCODE   H_SET_MODE
+#define H_GET_24X7_CATALOG_PAGE 0xF078
+#define H_GET_24X7_DATA0xF07C
+#define H_GET_PERF_COUNTER_INFO 0xF080


Ugh, why the hell did they put them up there.


+#define MAX_HCALL_OPCODE   H_GET_PERF_COUNTER_INFO


We have an array which is sized based on this, which is unpleasant.

I think you're better off putting these below in the platform specific section,
and leaving MAX_HCALL_OPCODE alone. The only downside is you can't use the
hcall tracing to see them.


Ya, I'm aware. I've got them up there as I did want to trace them :) . I 
don't see a big issue with moving them out of that section, though.



  /* Platform specific hcalls, used by KVM */
  #define H_RTAS0xf000





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


Re: [PATCH 4/8] powerpc: add hv_gpci interface header

2014-02-03 Thread Cody P Schafer

On 01/31/2014 09:58 PM, Michael Ellerman wrote:

On Thu, 2014-16-01 at 23:53:50 UTC, Cody P Schafer wrote:

"H_GetPerformanceCounterInfo" (refered to as hv_gpci or just gpci from
here on) is an interface to retrieve specific performance counters and
other data from the hypervisor. All outputs have a fixed format (and
are represented as structs in this patch).


So how much of this are we actually using? A lot of these seem to be only used
in the union at the bottom of this file, and not touched elsewhere - or am I
missing something subtle?

Some of it doesn't seem to be used at all?


We're using very little of the actual interface. In 24x7 we use 
cv_system_performance_capabilities, but other than that all the cv_* 
structures go unused.





diff --git a/arch/powerpc/include/asm/hv_gpci.h 
b/arch/powerpc/include/asm/hv_gpci.h


Any reason this can't just live in arch/powerpc/perf ?


+++ b/arch/powerpc/include/asm/hv_gpci.h
@@ -0,0 +1,490 @@
+#ifndef LINUX_POWERPC_UAPI_HV_GPCI_H_
+#define LINUX_POWERPC_UAPI_HV_GPCI_H_
+
+#include 
+
+/* From the document "H_GetPerformanceCounterInfo Interface" v1.06, paritialy
+ * updated with v1.07 */


Is that public?


Nope.


+
+/* H_GET_PERF_COUNTER_INFO argument */
+struct hv_get_perf_counter_info_params {
+   __be32 counter_request; /* I */
+   __be32 starting_index;  /* IO */
+   __be16 secondary_index; /* IO */
+   __be16 returned_values; /* O */
+   __be32 detail_rc; /* O, "only for 32bit clients" */
+
+   /*
+* O, size each of counter_value element in bytes, only set for version
+* >= 0x3
+*/
+   __be16 cv_element_size;
+
+   /* I, funny if version < 0x3 */


Funny how? Or better still, do we only support operating on some minimum
sane version of the API?


Right now the perf stuff is setup to let the user specify the version 
they want to operate in, and we avoid trying to provide cross-version 
compatibility.


Funny = must be set to 0x0. I'll update the comment.




+   __u8 counter_info_version_in;
+
+   /* O, funny if version < 0x3 */
+   __u8 counter_info_version_out;
+   __u8 reserved[0xC];
+   __u8 counter_value[];
+} __packed;
+
+/* 8 => power8 (1.07)
+ * 6 => TLBIE  (1.07)
+ * 5 => (1.05)
+ * 4 => ?
+ * 3 => ?
+ * 2 => v7r7m0.phyp (?)
+ * 1 => v7r6m0.phyp (?)
+ * 0 => v7r{2,3,4}m0.phyp (?)
+ */


I think this is a mapping of version numbers to firmware releases, it should
say so.


It is, I'll note it.




+#define COUNTER_INFO_VERSION_CURRENT 0x8
+
+/* these determine the counter_value[] layout and the meaning of starting_index
+ * and secondary_index */


Needs: leading capital, full stop, block comment.


ack




+enum counter_info_requests {
+
+   /* GENERAL */
+
+   /* @starting_index: "starting" physical processor index or -1 for


Why '"starting"' ?


The requests are designed to return a sequence of data blocks. For 
example, in this case where the index refers to a physical processor id, 
one can request phys processor 0,1,2,3 in a single hcall (as long as the 
buffer is sized appropriately. We don't take advantage of this.





+*  current phyical processor. Data is only collected
+*  for the processors' "primary" thread.
+* @secondary_index: unused


This seems to be true in all cases at least for this enum, can we drop it?



CIR_affinity_domain_information_by_virutal_processor uses 
secondary_index. That said, I'll note that if not mentioned, 
secondary_index is unused and use that to cut out some of the duplication.




+*/
+   CIR_dispatch_timebase_by_processor = 0x10,


Any reason for the weird capitialisation? You've obviously learnt the
noCamelCase rule, but this is still a bit odd :)



Mainly because these end up rather long and I was getting tired of 
fiddling with caps lock (and this weird capitalization lets macros do 
fun things without having to specify a long name twice, not that I'm 
doing that right now). Also, the spec gives them as 
"Dispatch_timebase_by_processor" (not that this really matters).


I'll properly capitalize them all if that's preferred (I expect it is).


+
+   /* @starting_index: starting partition id or -1 for the current logical
+*  partition (virtual machine).
+* @secondary_index: unused
+*/
+   CIR_entitled_capped_uncapped_donated_idle_timebase_by_partition = 0x20,
+
+   /* @starting_index: starting partition id or -1 for the current logical
+*  partition (virtual machine).
+* @secondary_index: unused
+*/
+   CIR_run_instructions_run_cycles_by_partition = 0x30,
+
+   /* @starting_index: must be -1 (to refer to the current partition)
+* @secondary_index: unused
+*/
+   CIR_system_performance_capabilities = 0x40,
+
+
+   /* Data from this should only be considered valid if
+* counter_info_version >= 0x3
+* @startin

Re: [PATCH] slub: Don't throw away partial remote slabs if there is no local memory

2014-02-03 Thread Nishanth Aravamudan
On 28.01.2014 [10:29:47 -0800], Nishanth Aravamudan wrote:
> On 27.01.2014 [14:58:05 +0900], Joonsoo Kim wrote:
> > On Fri, Jan 24, 2014 at 05:10:42PM -0800, Nishanth Aravamudan wrote:
> > > On 24.01.2014 [16:25:58 -0800], David Rientjes wrote:
> > > > On Fri, 24 Jan 2014, Nishanth Aravamudan wrote:
> > > > 
> > > > > Thank you for clarifying and providing  a test patch. I ran with this 
> > > > > on
> > > > > the system showing the original problem, configured to have 15GB of
> > > > > memory.
> > > > > 
> > > > > With your patch after boot:
> > > > > 
> > > > > MemTotal:   15604736 kB
> > > > > MemFree: 8768192 kB
> > > > > Slab:3882560 kB
> > > > > SReclaimable: 105408 kB
> > > > > SUnreclaim:  3777152 kB
> > > > > 
> > > > > With Anton's patch after boot:
> > > > > 
> > > > > MemTotal:   15604736 kB
> > > > > MemFree:11195008 kB
> > > > > Slab:1427968 kB
> > > > > SReclaimable: 109184 kB
> > > > > SUnreclaim:  1318784 kB
> > > > > 
> > > > > 
> > > > > I know that's fairly unscientific, but the numbers are reproducible. 
> > > > > 
> > 
> > Hello,
> > 
> > I think that there is one mistake on David's patch although I'm not sure
> > that it is the reason for this result.
> > 
> > With David's patch, get_partial() in new_slab_objects() doesn't work
> > properly, because we only change node id in !node_match() case. If we
> > meet just !freelist case, we pass node id directly to
> > new_slab_objects(), so we always try to allocate new slab page
> > regardless existence of partial pages. We should solve it.
> > 
> > Could you try this one?
> 
> This helps about the same as David's patch -- but I found the reason
> why! ppc64 doesn't set CONFIG_HAVE_MEMORYLESS_NODES :) Expect a patch
> shortly for that and one other case I found.
> 
> This patch on its own seems to help on our test system by saving around
> 1.5GB of slab.
> 
> Tested-by: Nishanth Aravamudan 
> Acked-by: Nishanth Aravamudan 
> 
> with the caveat below.

So what's the status of this patch? Christoph, do you think this is fine
as it is?

Thanks,
Nish

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


Re: [PATCH 1/2][v8] driver/memory:Move Freescale IFC driver to a common driver

2014-02-03 Thread Scott Wood
On Fri, 2014-01-31 at 15:09 +0530, Prabhakar Kushwaha wrote:
>  Freescale IFC controller has been used for mpc8xxx. It will be used
>  for ARM-based SoC as well. This patch moves the driver to driver/memory
>  and fix the header file includes.
> 
>  Also remove module_platform_driver() and  instead call
>  platform_driver_register() from subsys_initcall() to make sure this module
>  has been loaded before MTD partition parsing starts.
> 
> Signed-off-by: Prabhakar Kushwaha 
> Acked-by: Arnd Bergmann 

Again, when did Arnd ack this?

>  .../{powerpc => memory-controllers}/fsl/ifc.txt|0
>  arch/powerpc/Kconfig   |4 
>  arch/powerpc/sysdev/Makefile   |1 -
>  drivers/memory/Kconfig |8 
>  drivers/memory/Makefile|1 +
>  {arch/powerpc/sysdev => drivers/memory}/fsl_ifc.c  |8 ++--
>  drivers/mtd/nand/fsl_ifc_nand.c|2 +-
>  .../include/asm => include/linux}/fsl_ifc.h|0
>  8 files changed, 16 insertions(+), 8 deletions(-)
>  rename Documentation/devicetree/bindings/{powerpc => 
> memory-controllers}/fsl/ifc.txt (100%)
>  rename {arch/powerpc/sysdev => drivers/memory}/fsl_ifc.c (98%)
>  rename {arch/powerpc/include/asm => include/linux}/fsl_ifc.h (100%)

Do we need a MAINTAINERS entry for this?  I don't see anything covering
drivers/memory currently.

-Scott


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


Re: [PATCH] powerpc/eeh: drop taken reference to driver on eeh_rmv_device

2014-02-03 Thread Gavin Shan
On Fri, Jan 31, 2014 at 03:24:58PM -0200, Thadeu Lima de Souza Cascardo wrote:
>On Fri, Jan 31, 2014 at 08:46:11AM +0800, Gavin Shan wrote:
>> On Thu, Jan 30, 2014 at 11:00:48AM -0200, Thadeu Lima de Souza Cascardo 
>> wrote:
>> >Commit f5c57710dd62dd06f176934a8b4b8accbf00f9f8 ("powerpc/eeh: Use
>> >partial hotplug for EEH unaware drivers") introduces eeh_rmv_device,
>> >which may grab a reference to a driver, but not release it.
>> >
>> >That prevents a driver from being removed after it has gone through EEH
>> >recovery.
>> >
>> >This patch drops the reference in either exit path if it was taken.
>> >
>> >Signed-off-by: Thadeu Lima de Souza Cascardo 
>> >---
>> > arch/powerpc/kernel/eeh_driver.c |5 -
>> > 1 files changed, 4 insertions(+), 1 deletions(-)
>> >
>> >diff --git a/arch/powerpc/kernel/eeh_driver.c 
>> >b/arch/powerpc/kernel/eeh_driver.c
>> >index 7bb30dc..afe7337 100644
>> >--- a/arch/powerpc/kernel/eeh_driver.c
>> >+++ b/arch/powerpc/kernel/eeh_driver.c
>> >@@ -364,7 +364,7 @@ static void *eeh_rmv_device(void *data, void *userdata)
>> >return NULL;
>> >driver = eeh_pcid_get(dev);
>> >if (driver && driver->err_handler)
>> >-   return NULL;
>> >+   goto out;
>> >
>> >/* Remove it from PCI subsystem */
>> >pr_debug("EEH: Removing %s without EEH sensitive driver\n",
>> >@@ -377,6 +377,9 @@ static void *eeh_rmv_device(void *data, void *userdata)
>> 
>> For normal case (driver without EEH support), we probably release the 
>> reference
>> to the driver before pci_stop_and_remove_bus_device().
>
>You are right, we need to call it before we call
>pci_stop_and_remove_bus_device, otherwise dev->driver will be NULL, and
>eeh_pcid_put will not do module_put. On the other hand, we could change
>the call to eeh_pcid_put to accept struct pci_driver instead.
>
>> 
>> >pci_stop_and_remove_bus_device(dev);
>> >pci_unlock_rescan_remove();
>> >
>> >+out:
>> >+   if (driver)
>> >+   eeh_pcid_put(dev);
>> >return NULL;
>> 
>> We needn't "if (driver)" here as eeh_pcid_put() already had the check.
>> 
>
>What if try_module_get returned false on eeh_pcid_get?
>
>How about something like the patch below?
>
>> > }
>> >
>> 
>> Thanks,
>> Gavin
>---
>diff --git a/arch/powerpc/kernel/eeh_driver.c 
>b/arch/powerpc/kernel/eeh_driver.c
>index 7bb30dc..3a397fa 100644
>--- a/arch/powerpc/kernel/eeh_driver.c
>+++ b/arch/powerpc/kernel/eeh_driver.c
>@@ -352,6 +352,7 @@ static void *eeh_rmv_device(void *data, void *userdata)
>   struct eeh_dev *edev = (struct eeh_dev *)data;
>   struct pci_dev *dev = eeh_dev_to_pci_dev(edev);
>   int *removed = (int *)userdata;
>+  bool has_err_handler;
>
>   /*
>* Actually, we should remove the PCI bridges as well.
>@@ -362,8 +363,12 @@ static void *eeh_rmv_device(void *data, void *userdata)
>*/
>   if (!dev || (dev->hdr_type & PCI_HEADER_TYPE_BRIDGE))
>   return NULL;
>+
>   driver = eeh_pcid_get(dev);
>-  if (driver && driver->err_handler)
>+  has_err_handler = driver && driver->err_handler;
>+  if (driver)
>+  eeh_pcid_put(dev);
>+  if (has_err_handler)
>   return NULL;
>
>   /* Remove it from PCI subsystem */

It looks good to me. Could you please send v2 with:

Acked-by: Gavin Shan 

Or we can simply do like this. It depends your preference :-)

if (driver) {
eeh_pcid_put(dev);
if (driver->err_handler)
return NULL;
}

Thanks,
Gavin


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


RE: [PATCH 1/2][v8] driver/memory:Move Freescale IFC driver to a common driver

2014-02-03 Thread prabha...@freescale.com


> -Original Message-
> From: Wood Scott-B07421
> Sent: Tuesday, February 04, 2014 4:52 AM
> To: Kushwaha Prabhakar-B32579
> Cc: linuxppc-dev@lists.ozlabs.org; Arnd Bergmann
> Subject: Re: [PATCH 1/2][v8] driver/memory:Move Freescale IFC driver to a 
> common
> driver
> 
> On Fri, 2014-01-31 at 15:09 +0530, Prabhakar Kushwaha wrote:
> >  Freescale IFC controller has been used for mpc8xxx. It will be used
> > for ARM-based SoC as well. This patch moves the driver to
> > driver/memory  and fix the header file includes.
> >
> >  Also remove module_platform_driver() and  instead call
> >  platform_driver_register() from subsys_initcall() to make sure this
> > module  has been loaded before MTD partition parsing starts.
> >
> > Signed-off-by: Prabhakar Kushwaha 
> > Acked-by: Arnd Bergmann 
> 
> Again, when did Arnd ack this?
> 

Hi Scott,

I guess you missed his mail on kernel.org. Please find attached mail.


> >  .../{powerpc => memory-controllers}/fsl/ifc.txt|0
> >  arch/powerpc/Kconfig   |4 
> >  arch/powerpc/sysdev/Makefile   |1 -
> >  drivers/memory/Kconfig |8 
> >  drivers/memory/Makefile|1 +
> >  {arch/powerpc/sysdev => drivers/memory}/fsl_ifc.c  |8 ++--
> >  drivers/mtd/nand/fsl_ifc_nand.c|2 +-
> >  .../include/asm => include/linux}/fsl_ifc.h|0
> >  8 files changed, 16 insertions(+), 8 deletions(-)  rename
> > Documentation/devicetree/bindings/{powerpc =>
> > memory-controllers}/fsl/ifc.txt (100%)  rename {arch/powerpc/sysdev =>
> > drivers/memory}/fsl_ifc.c (98%)  rename {arch/powerpc/include/asm =>
> > include/linux}/fsl_ifc.h (100%)
> 
> Do we need a MAINTAINERS entry for this?  I don't see anything covering
> drivers/memory currently.
> 

I am not sure about this. 

Regards,
Prabhakar
--- Begin Message ---
On Wednesday 15 January 2014, Prabhakar Kushwaha wrote:
> Freescale IFC controller has been used for mpc8xxx. It will be used
> for ARM-based SoC as well. This patch moves the driver to driver/memory
> and fix the header file includes.
>
> Also remove module_platform_driver() and  instead call
> platform_driver_register() from subsys_initcall() to make sure this module
> has been loaded before MTD partition parsing starts.
>
> Signed-off-by: Prabhakar Kushwaha 

Acked-by: Arnd Bergmann 

provided that you also move the binding from powerpc/fsl/ifc.txt to
memory/fsl-ifc.txt.


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

Re: [PATCH] slub: Don't throw away partial remote slabs if there is no local memory

2014-02-03 Thread Christoph Lameter
On Mon, 3 Feb 2014, Nishanth Aravamudan wrote:

> So what's the status of this patch? Christoph, do you think this is fine
> as it is?

Certainly enabling CONFIG_MEMORYLESS_NODES is the right thing to do and I
already acked the patch.

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


Re: [PATCH] slub: Don't throw away partial remote slabs if there is no local memory

2014-02-03 Thread Nishanth Aravamudan
On 03.02.2014 [21:38:36 -0600], Christoph Lameter wrote:
> On Mon, 3 Feb 2014, Nishanth Aravamudan wrote:
> 
> > So what's the status of this patch? Christoph, do you think this is fine
> > as it is?
> 
> Certainly enabling CONFIG_MEMORYLESS_NODES is the right thing to do and I
> already acked the patch.

Yes, sorry for my lack of clarity. I meant Joonsoo's latest patch for
the $SUBJECT issue.

Thanks,
Nish

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