All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH V7 1/3] genalloc:support memory-allocation with bytes-alignment to genalloc
@ 2015-08-31  8:58 Zhao Qiang
  2015-08-31  8:58 ` [PATCH V7 2/3] qe_common: add qe_muram_ functions to manage muram Zhao Qiang
                   ` (2 more replies)
  0 siblings, 3 replies; 42+ messages in thread
From: Zhao Qiang @ 2015-08-31  8:58 UTC (permalink / raw)
  To: scottwood
  Cc: linux-kernel, linuxppc-dev, lauraa, X.xie, benh, leoli, paulus,
	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 <qiang.zhao@freescale.com>
---
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.

 include/linux/genalloc.h | 25 ++++++++++++++++----
 lib/genalloc.c           | 61 ++++++++++++++++++++++++++++++++++++++++++++----
 2 files changed, 77 insertions(+), 9 deletions(-)

diff --git a/include/linux/genalloc.h b/include/linux/genalloc.h
index 1ccaab4..1958053 100644
--- a/include/linux/genalloc.h
+++ b/include/linux/genalloc.h
@@ -30,10 +30,12 @@
 #ifndef __GENALLOC_H__
 #define __GENALLOC_H__
 
+#include <linux/types.h>
 #include <linux/spinlock_types.h>
 
 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,14 @@ 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 */
+	unsigned long offset;	/* the offset of allocation start addr*/
+};
+
 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 +106,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 +119,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..b9f8344 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 +308,7 @@ unsigned long gen_pool_alloc(struct gen_pool *pool, size_t size)
 		end_bit = chunk_size(chunk) >> order;
 retry:
 		start_bit = pool->algo(chunk->bits, end_bit, start_bit, nbits,
-				pool->data);
+				data, pool);
 		if (start_bit >= end_bit)
 			continue;
 		remain = bitmap_set_ll(chunk->bits, start_bit, nbits);
@@ -309,7 +327,7 @@ retry:
 	rcu_read_unlock();
 	return addr;
 }
-EXPORT_SYMBOL(gen_pool_alloc);
+EXPORT_SYMBOL(gen_pool_alloc_data);
 
 /**
  * gen_pool_dma_alloc - allocate special memory from the pool for DMA usage
@@ -500,15 +518,45 @@ EXPORT_SYMBOL(gen_pool_set_algo);
  * @start: The bitnumber to start searching at
  * @nr: The number of zeroed bits we're looking for
  * @data: additional data - unused
+ * @pool: pool to find the fit region memory from
  */
 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)
 {
 	return bitmap_find_next_zero_area(map, size, start, nr, 0);
 }
 EXPORT_SYMBOL(gen_pool_first_fit);
 
 /**
+ * gen_pool_first_fit_align - find the first available region
+ * of memory matching the size requirement (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_first_fit_align(unsigned long *map, unsigned long size,
+		unsigned long start, unsigned int nr, void *data,
+		struct gen_pool *pool)
+{
+	struct genpool_data_align *alignment;
+	unsigned long align_mask;
+	unsigned long offset_bit;
+	int order;
+
+	alignment = data;
+	order = pool->min_alloc_order;
+	align_mask = ((alignment->align + (1UL << order) - 1) >> order) - 1;
+	offset_bit = (alignment->offset + (1UL << order) - 1) >> order;
+	return bitmap_find_next_zero_area(map, size, start + offset_bit, nr,
+			align_mask);
+}
+EXPORT_SYMBOL(gen_pool_first_fit_align);
+
+/**
  * 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.
@@ -517,10 +565,11 @@ EXPORT_SYMBOL(gen_pool_first_fit);
  * @start: The bitnumber to start searching at
  * @nr: The number of zeroed bits we're looking for
  * @data: additional data - unused
+ * @pool: pool to find the fit region memory from
  */
 unsigned long gen_pool_first_fit_order_align(unsigned long *map,
 		unsigned long size, unsigned long start,
-		unsigned int nr, void *data)
+		unsigned int nr, void *data, struct gen_pool *pool)
 {
 	unsigned long align_mask = roundup_pow_of_two(nr) - 1;
 
@@ -536,12 +585,14 @@ EXPORT_SYMBOL(gen_pool_first_fit_order_align);
  * @start: The bitnumber to start searching at
  * @nr: The number of zeroed bits we're looking for
  * @data: additional data - unused
+ * @pool: pool to find the fit region memory from
  *
  * Iterate over the bitmap to find the smallest free region
  * which we can allocate the memory.
  */
 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)
 {
 	unsigned long start_bit = size;
 	unsigned long len = size + 1;
-- 
2.1.0.27.g96db324


^ permalink raw reply related	[flat|nested] 42+ messages in thread

* [PATCH V7 2/3] qe_common: add qe_muram_ functions to manage muram
  2015-08-31  8:58 [PATCH V7 1/3] genalloc:support memory-allocation with bytes-alignment to genalloc Zhao Qiang
@ 2015-08-31  8:58 ` Zhao Qiang
  2015-09-02  0:34   ` Scott Wood
  2015-08-31  8:58 ` [PATCH V7 3/3] QE: Move QE from arch/powerpc to drivers/soc Zhao Qiang
  2015-09-02  0:30 ` [PATCH V7 1/3] genalloc:support memory-allocation with bytes-alignment to genalloc Scott Wood
  2 siblings, 1 reply; 42+ messages in thread
From: Zhao Qiang @ 2015-08-31  8:58 UTC (permalink / raw)
  To: scottwood
  Cc: linux-kernel, linuxppc-dev, lauraa, X.xie, benh, leoli, paulus,
	Zhao Qiang

muram is used for qe, add qe_muram_ functions to manage
muram.

Signed-off-by: Zhao Qiang <qiang.zhao@freescale.com>
---
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

 arch/powerpc/include/asm/cpm.h            |  43 ------
 arch/powerpc/include/asm/qe.h             |  51 ++++++-
 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/platforms/Kconfig            |   1 +
 arch/powerpc/sysdev/cpm_common.c          | 141 +------------------
 arch/powerpc/sysdev/qe_lib/Makefile       |   2 +-
 arch/powerpc/sysdev/qe_lib/qe.c           |  15 ++
 arch/powerpc/sysdev/qe_lib/qe_common.c    | 222 ++++++++++++++++++++++++++++++
 13 files changed, 284 insertions(+), 203 deletions(-)
 create mode 100644 arch/powerpc/sysdev/qe_lib/qe_common.c

diff --git a/arch/powerpc/include/asm/cpm.h b/arch/powerpc/include/asm/cpm.h
index 4398a6c..05a1c15 100644
--- a/arch/powerpc/include/asm/cpm.h
+++ b/arch/powerpc/include/asm/cpm.h
@@ -155,49 +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);
-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..35257c8 100644
--- a/arch/powerpc/include/asm/qe.h
+++ b/arch/powerpc/include/asm/qe.h
@@ -16,10 +16,13 @@
 #define _ASM_POWERPC_QE_H
 #ifdef __KERNEL__
 
+#include <linux/compiler.h>
 #include <linux/spinlock.h>
 #include <linux/errno.h>
 #include <linux/err.h>
-#include <asm/cpm.h>
+#include <linux/of.h>
+#include <linux/of_address.h>
+#include <linux/types.h>
 #include <asm/immap_qe.h>
 
 #define QE_NUM_OF_SNUM	256	/* There are 256 serial number in QE */
@@ -187,12 +190,25 @@ static inline int qe_alive_during_sleep(void)
 }
 
 /* we actually use cpm_muram implementation, define this for convenience */
-#define qe_muram_init cpm_muram_init
-#define qe_muram_alloc cpm_muram_alloc
-#define qe_muram_alloc_fixed cpm_muram_alloc_fixed
-#define qe_muram_free cpm_muram_free
-#define qe_muram_addr cpm_muram_addr
-#define qe_muram_offset cpm_muram_offset
+#define cpm_muram_init qe_muram_init
+#define cpm_muram_alloc qe_muram_alloc
+#define cpm_muram_alloc_fixed qe_muram_alloc_fixed
+#define cpm_muram_free qe_muram_free
+#define cpm_muram_addr qe_muram_addr
+#define cpm_muram_offset qe_muram_offset
+
+int qe_muram_init(void);
+
+#if defined(CONFIG_QUICC_ENGINE)
+unsigned long qe_muram_alloc_common(unsigned long size, unsigned long align,
+		unsigned long offset);
+unsigned long qe_muram_alloc(unsigned long size, unsigned long align);
+unsigned long qe_muram_alloc_fixed(unsigned long offset, unsigned long size);
+int qe_muram_free(unsigned long offset);
+void __iomem *qe_muram_addr(unsigned long offset);
+unsigned long qe_muram_offset(void __iomem *addr);
+dma_addr_t qe_muram_dma(void __iomem *addr);
+#endif /* defined(CONFIG_QUICC_ENGINE) */
 
 /* Structure that defines QE firmware binary files.
  *
@@ -266,6 +282,27 @@ struct qe_bd {
 #define BD_STATUS_MASK	0xffff0000
 #define BD_LENGTH_MASK	0x0000ffff
 
+/* Buffer descriptor control/status used by serial
+ */
+
+#define BD_SC_EMPTY	(0x8000)	/* Receive is empty */
+#define BD_SC_READY	(0x8000)	/* Transmit is ready */
+#define BD_SC_WRAP	(0x2000)	/* Last buffer descriptor */
+#define BD_SC_INTRPT	(0x1000)	/* Interrupt on change */
+#define BD_SC_LAST	(0x0800)	/* Last buffer in frame */
+#define BD_SC_TC	(0x0400)	/* Transmit CRC */
+#define BD_SC_CM	(0x0200)	/* Continuous mode */
+#define BD_SC_ID	(0x0100)	/* Rec'd too many idles */
+#define BD_SC_P		(0x0100)	/* xmt preamble */
+#define BD_SC_BR	(0x0020)	/* Break received */
+#define BD_SC_FR	(0x0010)	/* Framing error */
+#define BD_SC_PR	(0x0008)	/* Parity error */
+#define BD_SC_NAK	(0x0004)	/* NAK - did not respond */
+#define BD_SC_OV	(0x0002)	/* Overrun */
+#define BD_SC_UN	(0x0002)	/* Underrun */
+#define BD_SC_CD	(0x0001)	/* */
+#define BD_SC_CL	(0x0001)	/* Collision */
+
 /* Alignment */
 #define QE_INTR_TABLE_ALIGN	16	/* ??? */
 #define QE_ALIGNMENT_OF_BD	8
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/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..328c3ec 100644
--- a/arch/powerpc/sysdev/cpm_common.c
+++ b/arch/powerpc/sysdev/cpm_common.c
@@ -27,8 +27,8 @@
 
 #include <asm/udbg.h>
 #include <asm/io.h>
-#include <asm/rheap.h>
 #include <asm/cpm.h>
+#include <asm/qe.h>
 
 #include <mm/mmu_decl.h>
 
@@ -65,151 +65,12 @@ void __init udbg_init_cpm(void)
 }
 #endif
 
-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 */
 #define OF_MAX_ADDR_CELLS	4
 
-int cpm_muram_init(void)
-{
-	struct device_node *np;
-	struct resource r;
-	u32 zero[OF_MAX_ADDR_CELLS] = {};
-	resource_size_t max = 0;
-	int i = 0;
-	int ret = 0;
-
-	if (muram_pbase)
-		return 0;
-
-	spin_lock_init(&cpm_muram_lock);
-	/* initialize the info header */
-	rh_init(&cpm_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");
-			ret = -ENODEV;
-			goto out;
-		}
-	}
-
-	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");
-		ret = -ENODEV;
-		goto out;
-	}
-
-	while (of_address_to_resource(np, i++, &r) == 0) {
-		if (r.end > max)
-			max = r.end;
-
-		rh_attach_region(&cpm_muram_info, r.start - muram_pbase,
-				 resource_size(&r));
-	}
-
-	muram_vbase = ioremap(muram_pbase, max - muram_pbase + 1);
-	if (!muram_vbase) {
-		printk(KERN_ERR "Cannot map CPM muram");
-		ret = -ENOMEM;
-	}
-
-out:
-	of_node_put(np);
-	return ret;
-}
-
-/**
- * cpm_muram_alloc - allocate the requested size worth of multi-user ram
- * @size: number of bytes to allocate
- * @align: requested alignment, in bytes
- *
- * This function returns an offset into the muram area.
- * Use cpm_dpram_addr() to get the virtual address of the area.
- * Use cpm_muram_free() to free the allocation.
- */
-unsigned long cpm_muram_alloc(unsigned long size, unsigned long align)
-{
-	unsigned long start;
-	unsigned long flags;
-
-	spin_lock_irqsave(&cpm_muram_lock, flags);
-	cpm_muram_info.alignment = align;
-	start = rh_alloc(&cpm_muram_info, size, "commproc");
-	memset(cpm_muram_addr(start), 0, size);
-	spin_unlock_irqrestore(&cpm_muram_lock, flags);
-
-	return start;
-}
-EXPORT_SYMBOL(cpm_muram_alloc);
-
-/**
- * cpm_muram_free - free a chunk of multi-user ram
- * @offset: The beginning of the chunk as returned by cpm_muram_alloc().
- */
-int cpm_muram_free(unsigned long offset)
-{
-	int ret;
-	unsigned long flags;
-
-	spin_lock_irqsave(&cpm_muram_lock, flags);
-	ret = rh_free(&cpm_muram_info, offset);
-	spin_unlock_irqrestore(&cpm_muram_lock, flags);
-
-	return ret;
-}
-EXPORT_SYMBOL(cpm_muram_free);
-
-/**
- * cpm_muram_alloc_fixed - reserve a specific region of multi-user ram
- * @offset: the offset into the muram area to reserve
- * @size: the number of bytes to reserve
- *
- * This function returns "start" on success, -ENOMEM on failure.
- * Use cpm_dpram_addr() to get the virtual address of the area.
- * Use cpm_muram_free() to free the allocation.
- */
-unsigned long cpm_muram_alloc_fixed(unsigned long offset, unsigned long size)
-{
-	unsigned long start;
-	unsigned long flags;
-
-	spin_lock_irqsave(&cpm_muram_lock, flags);
-	cpm_muram_info.alignment = 1;
-	start = rh_alloc_fixed(&cpm_muram_info, offset, size, "commproc");
-	spin_unlock_irqrestore(&cpm_muram_lock, flags);
-
-	return start;
-}
-EXPORT_SYMBOL(cpm_muram_alloc_fixed);
-
-/**
- * cpm_muram_addr - turn a muram offset into a virtual address
- * @offset: muram offset to convert
- */
-void __iomem *cpm_muram_addr(unsigned long offset)
-{
-	return muram_vbase + offset;
-}
-EXPORT_SYMBOL(cpm_muram_addr);
-
-unsigned long cpm_muram_offset(void __iomem *addr)
-{
-	return addr - (void __iomem *)muram_vbase;
-}
-EXPORT_SYMBOL(cpm_muram_offset);
-
 /**
  * cpm_muram_dma - turn a muram virtual address into a DMA address
  * @offset: virtual address from cpm_muram_addr() to convert
diff --git a/arch/powerpc/sysdev/qe_lib/Makefile b/arch/powerpc/sysdev/qe_lib/Makefile
index f1855c1..9507a27 100644
--- a/arch/powerpc/sysdev/qe_lib/Makefile
+++ b/arch/powerpc/sysdev/qe_lib/Makefile
@@ -1,7 +1,7 @@
 #
 # Makefile for the linux ppc-specific parts of QE
 #
-obj-$(CONFIG_QUICC_ENGINE)+= qe.o qe_ic.o qe_io.o
+obj-$(CONFIG_QUICC_ENGINE)+= qe.o qe_common.o qe_ic.o qe_io.o
 
 obj-$(CONFIG_UCC)	+= ucc.o
 obj-$(CONFIG_UCC_SLOW)	+= ucc_slow.o
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)
 {
diff --git a/arch/powerpc/sysdev/qe_lib/qe_common.c b/arch/powerpc/sysdev/qe_lib/qe_common.c
new file mode 100644
index 0000000..55079b9
--- /dev/null
+++ b/arch/powerpc/sysdev/qe_lib/qe_common.c
@@ -0,0 +1,222 @@
+/*
+ * Freescale QE common code
+ *
+ * Author: Zhao Qiang  <qiang.zhao@freescale.com>
+ *
+ * Copyright 2015 Freescale Semiconductor, Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+
+#include <linux/genalloc.h>
+#include <linux/list.h>
+#include <linux/init.h>
+#include <linux/of_device.h>
+#include <linux/spinlock.h>
+#include <linux/export.h>
+#include <linux/of.h>
+#include <linux/of_address.h>
+#include <linux/slab.h>
+
+#include <linux/io.h>
+#include <asm/qe.h>
+
+static struct gen_pool *muram_pool;
+static struct genpool_data_align muram_pool_data;
+static spinlock_t qe_muram_lock;
+static u8 __iomem *muram_vbase;
+static phys_addr_t muram_pbase;
+
+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
+
+int qe_muram_init(void)
+{
+	struct device_node *np;
+	struct resource r;
+	u32 zero[OF_MAX_ADDR_CELLS] = {};
+	resource_size_t max = 0;
+	int i = 0;
+	int ret = 0;
+
+	if (muram_pbase)
+		return 0;
+
+	np = of_find_compatible_node(NULL, NULL, "fsl,qe-muram-data");
+	if (!np) {
+		/* try legacy bindings */
+		np = of_find_node_by_name(NULL, "data-only");
+		if (!np) {
+			pr_err("Cannot find CPM muram data node");
+			ret = -ENODEV;
+			goto out;
+		}
+	}
+
+	muram_pool = gen_pool_create(1, -1);
+	gen_pool_set_algo(muram_pool, gen_pool_first_fit_align,
+			  &muram_pool_data);
+
+	muram_pbase = of_translate_address(np, zero);
+	if (muram_pbase == (phys_addr_t)OF_BAD_ADDR) {
+		pr_err("Cannot translate zero through CPM muram node");
+		ret = -ENODEV;
+		goto err;
+	}
+
+	while (of_address_to_resource(np, i++, &r) == 0) {
+		if (r.end > max)
+			max = r.end;
+		ret = gen_pool_add(muram_pool, r.start - muram_pbase +
+				   GENPOOL_OFFSET, resource_size(&r), -1);
+		if (ret) {
+				pr_err("QE: couldn't add muram to pool!\n");
+				goto err;
+			}
+
+	}
+
+	muram_vbase = ioremap(muram_pbase, max - muram_pbase + 1);
+	if (!muram_vbase) {
+		pr_err("Cannot map QE muram");
+		ret = -ENOMEM;
+		goto err;
+	}
+	goto out;
+err:
+	gen_pool_destroy(muram_pool);
+out:
+	of_node_put(np);
+	return ret;
+}
+
+/*
+ * qe_muram_alloc - allocate the requested size worth of multi-user ram
+ * @size: number of bytes to allocate
+ * @align: requested alignment, in bytes
+ *
+ * This function returns an offset into the muram area.
+ */
+unsigned long qe_muram_alloc(unsigned long size, unsigned long align)
+{
+	return qe_muram_alloc_common(size, align, 0);
+}
+EXPORT_SYMBOL(qe_muram_alloc);
+
+/*
+ * qe_muram_alloc_fixed - reserve a specific region of multi-user ram
+ * @size: number of bytes to allocate
+ * @offset: offset of allocation start address
+ *
+ * This function returns an offset into the muram area.
+ */
+unsigned long qe_muram_alloc_fixed(unsigned long offset, unsigned long size)
+{
+	return qe_muram_alloc_common(size, 1, offset);
+}
+EXPORT_SYMBOL(qe_muram_alloc_fixed);
+
+/*
+ * qe_muram_alloc_common - allocate the requested size worth of multi-user ram
+ * @size: number of bytes to allocate
+ * @align: requested alignment, in bytes
+ * @offset: offset of allocation start address
+ *
+ * This function returns an offset into the muram area.
+ */
+unsigned long qe_muram_alloc_common(unsigned long size, unsigned long align,
+		unsigned long offset)
+{
+	unsigned long start;
+	unsigned long flags;
+	struct muram_block *entry;
+
+	spin_lock_irqsave(&qe_muram_lock, flags);
+	muram_pool_data.align = align;
+	muram_pool_data.offset = offset;
+	start = gen_pool_alloc(muram_pool, size);
+	if (!start)
+		goto out2;
+	start = start - GENPOOL_OFFSET;
+	memset(qe_muram_addr(start), 0, size);
+	entry = kmalloc(sizeof(*entry), GFP_KERNEL);
+	if (!entry)
+		goto out1;
+	entry->start = start;
+	entry->size = size;
+	list_add(&entry->head, &muram_block_list);
+	spin_unlock_irqrestore(&qe_muram_lock, flags);
+
+	return start;
+out1:
+	gen_pool_free(muram_pool, start, size);
+out2:
+	spin_unlock_irqrestore(&qe_muram_lock, flags);
+	return (unsigned long) -ENOMEM;
+}
+EXPORT_SYMBOL(qe_muram_alloc_common);
+
+/**
+ * qe_muram_free - free a chunk of multi-user ram
+ * @offset: The beginning of the chunk as returned by qe_muram_alloc().
+ */
+int qe_muram_free(unsigned long offset)
+{
+	unsigned long flags;
+	int size;
+	struct muram_block *tmp;
+
+	size = 0;
+	spin_lock_irqsave(&qe_muram_lock, flags);
+	list_for_each_entry(tmp, &muram_block_list, head) {
+		if (tmp->start == offset) {
+			size = tmp->size;
+			list_del(&tmp->head);
+			kfree(tmp);
+			break;
+		}
+	}
+	gen_pool_free(muram_pool, offset + GENPOOL_OFFSET, size);
+	spin_unlock_irqrestore(&qe_muram_lock, flags);
+
+	return size;
+}
+EXPORT_SYMBOL(qe_muram_free);
+
+/**
+ * qe_muram_addr - turn a muram offset into a virtual address
+ * @offset: muram offset to convert
+ */
+void __iomem *qe_muram_addr(unsigned long offset)
+{
+	return muram_vbase + offset;
+}
+EXPORT_SYMBOL(qe_muram_addr);
+
+unsigned long qe_muram_offset(void __iomem *addr)
+{
+	return addr - (void __iomem *)muram_vbase;
+}
+EXPORT_SYMBOL(qe_muram_offset);
+
+/**
+ * qe_muram_dma - turn a muram virtual address into a DMA address
+ * @offset: virtual address from qe_muram_addr() to convert
+ */
+dma_addr_t qe_muram_dma(void __iomem *addr)
+{
+	return muram_pbase + ((u8 __iomem *)addr - muram_vbase);
+}
+EXPORT_SYMBOL(qe_muram_dma);
-- 
2.1.0.27.g96db324


^ permalink raw reply related	[flat|nested] 42+ messages in thread

* [PATCH V7 3/3] QE: Move QE from arch/powerpc to drivers/soc
  2015-08-31  8:58 [PATCH V7 1/3] genalloc:support memory-allocation with bytes-alignment to genalloc Zhao Qiang
  2015-08-31  8:58 ` [PATCH V7 2/3] qe_common: add qe_muram_ functions to manage muram Zhao Qiang
@ 2015-08-31  8:58 ` Zhao Qiang
  2015-09-02  0:30 ` [PATCH V7 1/3] genalloc:support memory-allocation with bytes-alignment to genalloc Scott Wood
  2 siblings, 0 replies; 42+ messages in thread
From: Zhao Qiang @ 2015-08-31  8:58 UTC (permalink / raw)
  To: scottwood
  Cc: linux-kernel, linuxppc-dev, lauraa, X.xie, benh, leoli, paulus,
	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 <qiang.zhao@freescale.com>
---
hanges 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
 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:	include/linux/fs_enet_pd.h
 FREESCALE QUICC ENGINE LIBRARY
 L:	linuxppc-dev@lists.ozlabs.org
 S:	Orphan
-F:	arch/powerpc/sysdev/qe_lib/
-F:	arch/powerpc/include/asm/*qe.h
+F:	drivers/soc/fsl/qe/
+F:	include/soc/fsl/*qe*.h
+F:	include/soc/fsl/*ucc*.h
 
 FREESCALE USB PERIPHERAL DRIVERS
 M:	Li Yang <leoli@freescale.com>
diff --git a/arch/powerpc/platforms/83xx/km83xx.c b/arch/powerpc/platforms/83xx/km83xx.c
index ae111581..7ecd758 100644
--- a/arch/powerpc/platforms/83xx/km83xx.c
+++ b/arch/powerpc/platforms/83xx/km83xx.c
@@ -37,8 +37,8 @@
 #include <asm/udbg.h>
 #include <sysdev/fsl_soc.h>
 #include <sysdev/fsl_pci.h>
-#include <asm/qe.h>
-#include <asm/qe_ic.h>
+#include <soc/fsl/qe/qe.h>
+#include <linux/fsl/qe/qe_ic.h>
 
 #include "mpc83xx.h"
 
diff --git a/arch/powerpc/platforms/83xx/misc.c b/arch/powerpc/platforms/83xx/misc.c
index ef9d01a..eacf34b 100644
--- a/arch/powerpc/platforms/83xx/misc.c
+++ b/arch/powerpc/platforms/83xx/misc.c
@@ -17,7 +17,7 @@
 #include <asm/io.h>
 #include <asm/hw_irq.h>
 #include <asm/ipic.h>
-#include <asm/qe_ic.h>
+#include <linux/fsl/qe/qe_ic.h>
 #include <sysdev/fsl_soc.h>
 #include <sysdev/fsl_pci.h>
 
diff --git a/arch/powerpc/platforms/83xx/mpc832x_mds.c b/arch/powerpc/platforms/83xx/mpc832x_mds.c
index aacc43f..20dce79 100644
--- a/arch/powerpc/platforms/83xx/mpc832x_mds.c
+++ b/arch/powerpc/platforms/83xx/mpc832x_mds.c
@@ -36,8 +36,8 @@
 #include <asm/udbg.h>
 #include <sysdev/fsl_soc.h>
 #include <sysdev/fsl_pci.h>
-#include <asm/qe.h>
-#include <asm/qe_ic.h>
+#include <soc/fsl/qe/qe.h>
+#include <linux/fsl/qe/qe_ic.h>
 
 #include "mpc83xx.h"
 
diff --git a/arch/powerpc/platforms/83xx/mpc832x_rdb.c b/arch/powerpc/platforms/83xx/mpc832x_rdb.c
index 0c7a43e..2e6a6a4 100644
--- a/arch/powerpc/platforms/83xx/mpc832x_rdb.c
+++ b/arch/powerpc/platforms/83xx/mpc832x_rdb.c
@@ -25,8 +25,8 @@
 #include <asm/time.h>
 #include <asm/ipic.h>
 #include <asm/udbg.h>
-#include <asm/qe.h>
-#include <asm/qe_ic.h>
+#include <soc/fsl/qe/qe.h>
+#include <linux/fsl/qe/qe_ic.h>
 #include <sysdev/fsl_soc.h>
 #include <sysdev/fsl_pci.h>
 
diff --git a/arch/powerpc/platforms/83xx/mpc836x_mds.c b/arch/powerpc/platforms/83xx/mpc836x_mds.c
index eb24abd..b1b8ab8 100644
--- a/arch/powerpc/platforms/83xx/mpc836x_mds.c
+++ b/arch/powerpc/platforms/83xx/mpc836x_mds.c
@@ -44,8 +44,8 @@
 #include <sysdev/fsl_soc.h>
 #include <sysdev/fsl_pci.h>
 #include <sysdev/simple_gpio.h>
-#include <asm/qe.h>
-#include <asm/qe_ic.h>
+#include <soc/fsl/qe/qe.h>
+#include <linux/fsl/qe/qe_ic.h>
 
 #include "mpc83xx.h"
 
diff --git a/arch/powerpc/platforms/83xx/mpc836x_rdk.c b/arch/powerpc/platforms/83xx/mpc836x_rdk.c
index 823e370..9a5a00d 100644
--- a/arch/powerpc/platforms/83xx/mpc836x_rdk.c
+++ b/arch/powerpc/platforms/83xx/mpc836x_rdk.c
@@ -20,8 +20,8 @@
 #include <asm/time.h>
 #include <asm/ipic.h>
 #include <asm/udbg.h>
-#include <asm/qe.h>
-#include <asm/qe_ic.h>
+#include <soc/fsl/qe/qe.h>
+#include <linux/fsl/qe/qe_ic.h>
 #include <sysdev/fsl_soc.h>
 #include <sysdev/fsl_pci.h>
 
diff --git a/arch/powerpc/platforms/85xx/common.c b/arch/powerpc/platforms/85xx/common.c
index 0f91edc..d81ea0c 100644
--- a/arch/powerpc/platforms/85xx/common.c
+++ b/arch/powerpc/platforms/85xx/common.c
@@ -9,7 +9,7 @@
 #include <linux/of_irq.h>
 #include <linux/of_platform.h>
 
-#include <asm/qe.h>
+#include <soc/fsl/qe/qe.h>
 #include <sysdev/cpm2_pic.h>
 
 #include "mpc85xx.h"
diff --git a/arch/powerpc/platforms/85xx/corenet_generic.c b/arch/powerpc/platforms/85xx/corenet_generic.c
index bd839dc..1ecbf7f 100644
--- a/arch/powerpc/platforms/85xx/corenet_generic.c
+++ b/arch/powerpc/platforms/85xx/corenet_generic.c
@@ -27,7 +27,7 @@
 #include <asm/udbg.h>
 #include <asm/mpic.h>
 #include <asm/ehv_pic.h>
-#include <asm/qe_ic.h>
+#include <linux/fsl/qe/qe_ic.h>
 
 #include <linux/of_platform.h>
 #include <sysdev/fsl_soc.h>
diff --git a/arch/powerpc/platforms/85xx/mpc85xx_mds.c b/arch/powerpc/platforms/85xx/mpc85xx_mds.c
index a392e94..ea4d4f3 100644
--- a/arch/powerpc/platforms/85xx/mpc85xx_mds.c
+++ b/arch/powerpc/platforms/85xx/mpc85xx_mds.c
@@ -47,8 +47,8 @@
 #include <sysdev/fsl_soc.h>
 #include <sysdev/fsl_pci.h>
 #include <sysdev/simple_gpio.h>
-#include <asm/qe.h>
-#include <asm/qe_ic.h>
+#include <soc/fsl/qe/qe.h>
+#include <linux/fsl/qe/qe_ic.h>
 #include <asm/mpic.h>
 #include <asm/swiotlb.h>
 #include <asm/fsl_guts.h>
diff --git a/arch/powerpc/platforms/85xx/mpc85xx_rdb.c b/arch/powerpc/platforms/85xx/mpc85xx_rdb.c
index e358bed..0c5e313 100644
--- a/arch/powerpc/platforms/85xx/mpc85xx_rdb.c
+++ b/arch/powerpc/platforms/85xx/mpc85xx_rdb.c
@@ -25,8 +25,8 @@
 #include <asm/prom.h>
 #include <asm/udbg.h>
 #include <asm/mpic.h>
-#include <asm/qe.h>
-#include <asm/qe_ic.h>
+#include <soc/fsl/qe/qe.h>
+#include <linux/fsl/qe/qe_ic.h>
 #include <asm/fsl_guts.h>
 
 #include <sysdev/fsl_soc.h>
diff --git a/arch/powerpc/platforms/85xx/twr_p102x.c b/arch/powerpc/platforms/85xx/twr_p102x.c
index 30e002f..a47654e 100644
--- a/arch/powerpc/platforms/85xx/twr_p102x.c
+++ b/arch/powerpc/platforms/85xx/twr_p102x.c
@@ -21,8 +21,8 @@
 #include <asm/pci-bridge.h>
 #include <asm/udbg.h>
 #include <asm/mpic.h>
-#include <asm/qe.h>
-#include <asm/qe_ic.h>
+#include <soc/fsl/qe/qe.h>
+#include <linux/fsl/qe/qe_ic.h>
 #include <asm/fsl_guts.h>
 
 #include <sysdev/fsl_soc.h>
diff --git a/arch/powerpc/platforms/Kconfig b/arch/powerpc/platforms/Kconfig
index 01f98a2..c9541a5 100644
--- a/arch/powerpc/platforms/Kconfig
+++ b/arch/powerpc/platforms/Kconfig
@@ -272,26 +272,6 @@ config TAU_AVERAGE
 
 	  If in doubt, say N here.
 
-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
-	  coprocessors on Freescale embedded CPUs (akin to CPM in older chips).
-	  Selecting this option means that you wish to build a kernel
-	  for a machine with a QE coprocessor.
-
-config QE_GPIO
-	bool "QE GPIO support"
-	depends on QUICC_ENGINE
-	select ARCH_REQUIRE_GPIOLIB
-	help
-	  Say Y here if you're going to use hardware that connects to the
-	  QE GPIOs.
-
 config CPM2
 	bool "Enable support for the CPM2 (Communications Processor Module)"
 	depends on (FSL_SOC_BOOKE && PPC32) || 8260
diff --git a/arch/powerpc/sysdev/cpm_common.c b/arch/powerpc/sysdev/cpm_common.c
index 328c3ec..eaee6f6 100644
--- a/arch/powerpc/sysdev/cpm_common.c
+++ b/arch/powerpc/sysdev/cpm_common.c
@@ -28,7 +28,7 @@
 #include <asm/udbg.h>
 #include <asm/io.h>
 #include <asm/cpm.h>
-#include <asm/qe.h>
+#include <soc/fsl/qe/qe.h>
 
 #include <mm/mmu_decl.h>
 
diff --git a/arch/powerpc/sysdev/qe_lib/Kconfig b/arch/powerpc/sysdev/qe_lib/Kconfig
index 3c25199..2f80075 100644
--- a/arch/powerpc/sysdev/qe_lib/Kconfig
+++ b/arch/powerpc/sysdev/qe_lib/Kconfig
@@ -1,24 +1,14 @@
 #
 # QE Communication options
 #
-
-config UCC_SLOW
-	bool
-	default y if SERIAL_QE
-	help
-	  This option provides qe_lib support to UCC slow
-	  protocols: UART, BISYNC, QMC
-
-config UCC_FAST
-	bool
-	default y if UCC_GETH
+config QE_GPIO
+	bool "QE GPIO support"
+	depends on QUICC_ENGINE
+	select ARCH_REQUIRE_GPIOLIB
 	help
-	  This option provides qe_lib support to UCC fast
-	  protocols: HDLC, Ethernet, ATM, transparent
+	  Say Y here if you're going to use hardware that connects to the
+	  QE GPIOs.
 
-config UCC
-	bool
-	default y if UCC_FAST || UCC_SLOW
 
 config QE_USB
 	bool
diff --git a/arch/powerpc/sysdev/qe_lib/Makefile b/arch/powerpc/sysdev/qe_lib/Makefile
index 9507a27..1b123df 100644
--- a/arch/powerpc/sysdev/qe_lib/Makefile
+++ b/arch/powerpc/sysdev/qe_lib/Makefile
@@ -1,10 +1,6 @@
 #
 # Makefile for the linux ppc-specific parts of QE
 #
-obj-$(CONFIG_QUICC_ENGINE)+= qe.o qe_common.o qe_ic.o qe_io.o
-
-obj-$(CONFIG_UCC)	+= ucc.o
-obj-$(CONFIG_UCC_SLOW)	+= ucc_slow.o
-obj-$(CONFIG_UCC_FAST)	+= ucc_fast.o
+obj-$(CONFIG_QUICC_ENGINE)+= qe_io.o
 obj-$(CONFIG_QE_USB)	+= usb.o
 obj-$(CONFIG_QE_GPIO)	+= gpio.o
diff --git a/arch/powerpc/sysdev/qe_lib/gpio.c b/arch/powerpc/sysdev/qe_lib/gpio.c
index 521e67a..aa5c11ac 100644
--- a/arch/powerpc/sysdev/qe_lib/gpio.c
+++ b/arch/powerpc/sysdev/qe_lib/gpio.c
@@ -21,7 +21,7 @@
 #include <linux/gpio.h>
 #include <linux/slab.h>
 #include <linux/export.h>
-#include <asm/qe.h>
+#include <soc/fsl/qe/qe.h>
 
 struct qe_gpio_chip {
 	struct of_mm_gpio_chip mm_gc;
diff --git a/arch/powerpc/sysdev/qe_lib/qe_io.c b/arch/powerpc/sysdev/qe_lib/qe_io.c
index 7ea0174..7ae59ab 100644
--- a/arch/powerpc/sysdev/qe_lib/qe_io.c
+++ b/arch/powerpc/sysdev/qe_lib/qe_io.c
@@ -21,7 +21,7 @@
 #include <linux/ioport.h>
 
 #include <asm/io.h>
-#include <asm/qe.h>
+#include <soc/fsl/qe/qe.h>
 #include <asm/prom.h>
 #include <sysdev/fsl_soc.h>
 
diff --git a/arch/powerpc/sysdev/qe_lib/usb.c b/arch/powerpc/sysdev/qe_lib/usb.c
index 27f23bd..111f7ab 100644
--- a/arch/powerpc/sysdev/qe_lib/usb.c
+++ b/arch/powerpc/sysdev/qe_lib/usb.c
@@ -17,8 +17,8 @@
 #include <linux/errno.h>
 #include <linux/export.h>
 #include <linux/io.h>
-#include <asm/immap_qe.h>
-#include <asm/qe.h>
+#include <soc/fsl/qe/immap_qe.h>
+#include <soc/fsl/qe/qe.h>
 
 int qe_usb_clock_set(enum qe_clock clk, int rate)
 {
diff --git a/drivers/irqchip/Makefile b/drivers/irqchip/Makefile
index dda4927..9ff5932 100644
--- a/drivers/irqchip/Makefile
+++ b/drivers/irqchip/Makefile
@@ -47,3 +47,4 @@ obj-$(CONFIG_KEYSTONE_IRQ)		+= irq-keystone.o
 obj-$(CONFIG_MIPS_GIC)			+= irq-mips-gic.o
 obj-$(CONFIG_ARCH_MEDIATEK)		+= irq-mtk-sysirq.o
 obj-$(CONFIG_ARCH_DIGICOLOR)		+= irq-digicolor.o
+obj-$(CONFIG_QUICC_ENGINE)		+= qe_ic.o
diff --git a/arch/powerpc/sysdev/qe_lib/qe_ic.c b/drivers/irqchip/qe_ic.c
similarity index 99%
rename from arch/powerpc/sysdev/qe_lib/qe_ic.c
rename to drivers/irqchip/qe_ic.c
index 6512cd8..e31d95b 100644
--- a/arch/powerpc/sysdev/qe_lib/qe_ic.c
+++ b/drivers/irqchip/qe_ic.c
@@ -27,7 +27,7 @@
 #include <asm/irq.h>
 #include <asm/io.h>
 #include <asm/prom.h>
-#include <asm/qe_ic.h>
+#include <linux/fsl/qe/qe_ic.h>
 
 #include "qe_ic.h"
 
diff --git a/arch/powerpc/sysdev/qe_lib/qe_ic.h b/drivers/irqchip/qe_ic.h
similarity index 97%
rename from arch/powerpc/sysdev/qe_lib/qe_ic.h
rename to drivers/irqchip/qe_ic.h
index efef7ab..9f15cc4 100644
--- a/arch/powerpc/sysdev/qe_lib/qe_ic.h
+++ b/drivers/irqchip/qe_ic.h
@@ -1,5 +1,5 @@
 /*
- * arch/powerpc/sysdev/qe_lib/qe_ic.h
+ * drivers/irqchip/qe_ic.h
  *
  * QUICC ENGINE Interrupt Controller Header
  *
@@ -16,7 +16,7 @@
 #ifndef _POWERPC_SYSDEV_QE_IC_H
 #define _POWERPC_SYSDEV_QE_IC_H
 
-#include <asm/qe_ic.h>
+#include <linux/fsl/qe/qe_ic.h>
 
 #define NR_QE_IC_INTS		64
 
diff --git a/drivers/net/ethernet/freescale/fsl_pq_mdio.c b/drivers/net/ethernet/freescale/fsl_pq_mdio.c
index 3c40f6b..21bdf55 100644
--- a/drivers/net/ethernet/freescale/fsl_pq_mdio.c
+++ b/drivers/net/ethernet/freescale/fsl_pq_mdio.c
@@ -29,7 +29,7 @@
 
 #include <asm/io.h>
 #if IS_ENABLED(CONFIG_UCC_GETH)
-#include <asm/ucc.h>	/* for ucc_set_qe_mux_mii_mng() */
+#include <soc/fsl/qe/ucc.h>
 #endif
 
 #include "gianfar.h"
diff --git a/drivers/net/ethernet/freescale/ucc_geth.c b/drivers/net/ethernet/freescale/ucc_geth.c
index 4dd40e0..7d24664 100644
--- a/drivers/net/ethernet/freescale/ucc_geth.c
+++ b/drivers/net/ethernet/freescale/ucc_geth.c
@@ -40,10 +40,10 @@
 #include <asm/uaccess.h>
 #include <asm/irq.h>
 #include <asm/io.h>
-#include <asm/immap_qe.h>
-#include <asm/qe.h>
-#include <asm/ucc.h>
-#include <asm/ucc_fast.h>
+#include <soc/fsl/qe/immap_qe.h>
+#include <soc/fsl/qe/qe.h>
+#include <soc/fsl/qe/ucc.h>
+#include <soc/fsl/qe/ucc_fast.h>
 #include <asm/machdep.h>
 
 #include "ucc_geth.h"
diff --git a/drivers/net/ethernet/freescale/ucc_geth.h b/drivers/net/ethernet/freescale/ucc_geth.h
index 75f3371..5da19b4 100644
--- a/drivers/net/ethernet/freescale/ucc_geth.h
+++ b/drivers/net/ethernet/freescale/ucc_geth.h
@@ -22,11 +22,11 @@
 #include <linux/list.h>
 #include <linux/if_ether.h>
 
-#include <asm/immap_qe.h>
-#include <asm/qe.h>
+#include <soc/fsl/qe/immap_qe.h>
+#include <soc/fsl/qe/qe.h>
 
-#include <asm/ucc.h>
-#include <asm/ucc_fast.h>
+#include <soc/fsl/qe/ucc.h>
+#include <soc/fsl/qe/ucc_fast.h>
 
 #define DRV_DESC "QE UCC Gigabit Ethernet Controller"
 #define DRV_NAME "ucc_geth"
diff --git a/drivers/soc/Kconfig b/drivers/soc/Kconfig
index d8bde82..676737a 100644
--- a/drivers/soc/Kconfig
+++ b/drivers/soc/Kconfig
@@ -1,5 +1,6 @@
 menu "SOC (System On Chip) specific Drivers"
 
+source "drivers/soc/fsl/qe/Kconfig"
 source "drivers/soc/mediatek/Kconfig"
 source "drivers/soc/qcom/Kconfig"
 source "drivers/soc/ti/Kconfig"
diff --git a/drivers/soc/Makefile b/drivers/soc/Makefile
index 70042b2..0259e23 100644
--- a/drivers/soc/Makefile
+++ b/drivers/soc/Makefile
@@ -2,6 +2,7 @@
 # Makefile for the Linux Kernel SOC specific device drivers.
 #
 
+obj-y				+= fsl/
 obj-$(CONFIG_ARCH_MEDIATEK)	+= mediatek/
 obj-$(CONFIG_ARCH_QCOM)		+= qcom/
 obj-$(CONFIG_ARCH_TEGRA)	+= tegra/
diff --git a/drivers/soc/fsl/Makefile b/drivers/soc/fsl/Makefile
new file mode 100644
index 0000000..7c7d045
--- /dev/null
+++ b/drivers/soc/fsl/Makefile
@@ -0,0 +1,5 @@
+#
+# Makefile for the Linux Kernel SOC fsl specific device drivers
+#
+
+obj-$(CONFIG_QUICC_ENGINE)		+= qe/
diff --git a/drivers/soc/fsl/qe/Kconfig b/drivers/soc/fsl/qe/Kconfig
new file mode 100644
index 0000000..3012571
--- /dev/null
+++ b/drivers/soc/fsl/qe/Kconfig
@@ -0,0 +1,33 @@
+#
+# QE Communication options
+#
+
+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
+	  coprocessors on Freescale embedded CPUs (akin to CPM in older chips).
+	  Selecting this option means that you wish to build a kernel
+	  for a machine with a QE coprocessor.
+
+config UCC_SLOW
+	bool
+	default y if SERIAL_QE
+	help
+	  This option provides qe_lib support to UCC slow
+	  protocols: UART, BISYNC, QMC
+
+config UCC_FAST
+	bool
+	default y if UCC_GETH
+	help
+	  This option provides qe_lib support to UCC fast
+	  protocols: HDLC, Ethernet, ATM, transparent
+
+config UCC
+	bool
+	default y if UCC_FAST || UCC_SLOW
diff --git a/drivers/soc/fsl/qe/Makefile b/drivers/soc/fsl/qe/Makefile
new file mode 100644
index 0000000..51c9dce
--- /dev/null
+++ b/drivers/soc/fsl/qe/Makefile
@@ -0,0 +1,9 @@
+#
+#Makefile for the Linux fsl parts of QE
+#
+
+
+obj-$(CONFIG_QUICC_ENGINE)+= qe.o qe_common.o
+obj-$(CONFIG_UCC)	+= ucc.o
+obj-$(CONFIG_UCC_SLOW)	+= ucc_slow.o
+obj-$(CONFIG_UCC_FAST)	+= ucc_fast.o
diff --git a/arch/powerpc/sysdev/qe_lib/qe.c b/drivers/soc/fsl/qe/qe.c
similarity index 99%
rename from arch/powerpc/sysdev/qe_lib/qe.c
rename to drivers/soc/fsl/qe/qe.c
index 3f9f596..d8fd4cd 100644
--- a/arch/powerpc/sysdev/qe_lib/qe.c
+++ b/drivers/soc/fsl/qe/qe.c
@@ -31,8 +31,8 @@
 #include <asm/irq.h>
 #include <asm/page.h>
 #include <asm/pgtable.h>
-#include <asm/immap_qe.h>
-#include <asm/qe.h>
+#include <soc/fsl/qe/immap_qe.h>
+#include <soc/fsl/qe/qe.h>
 #include <asm/prom.h>
 #include <asm/rheap.h>
 
diff --git a/arch/powerpc/sysdev/qe_lib/qe_common.c b/drivers/soc/fsl/qe/qe_common.c
similarity index 99%
rename from arch/powerpc/sysdev/qe_lib/qe_common.c
rename to drivers/soc/fsl/qe/qe_common.c
index 55079b9..b3ca0cf 100644
--- a/arch/powerpc/sysdev/qe_lib/qe_common.c
+++ b/drivers/soc/fsl/qe/qe_common.c
@@ -22,7 +22,7 @@
 #include <linux/slab.h>
 
 #include <linux/io.h>
-#include <asm/qe.h>
+#include <soc/fsl/qe/qe.h>
 
 static struct gen_pool *muram_pool;
 static struct genpool_data_align muram_pool_data;
diff --git a/arch/powerpc/sysdev/qe_lib/ucc.c b/drivers/soc/fsl/qe/ucc.c
similarity index 98%
rename from arch/powerpc/sysdev/qe_lib/ucc.c
rename to drivers/soc/fsl/qe/ucc.c
index 621575b..b59d335 100644
--- a/arch/powerpc/sysdev/qe_lib/ucc.c
+++ b/drivers/soc/fsl/qe/ucc.c
@@ -21,9 +21,9 @@
 
 #include <asm/irq.h>
 #include <asm/io.h>
-#include <asm/immap_qe.h>
-#include <asm/qe.h>
-#include <asm/ucc.h>
+#include <soc/fsl/qe/immap_qe.h>
+#include <soc/fsl/qe/qe.h>
+#include <soc/fsl/qe/ucc.h>
 
 int ucc_set_qe_mux_mii_mng(unsigned int ucc_num)
 {
diff --git a/arch/powerpc/sysdev/qe_lib/ucc_fast.c b/drivers/soc/fsl/qe/ucc_fast.c
similarity index 98%
rename from arch/powerpc/sysdev/qe_lib/ucc_fast.c
rename to drivers/soc/fsl/qe/ucc_fast.c
index 65aaf15..a768931 100644
--- a/arch/powerpc/sysdev/qe_lib/ucc_fast.c
+++ b/drivers/soc/fsl/qe/ucc_fast.c
@@ -21,11 +21,11 @@
 #include <linux/export.h>
 
 #include <asm/io.h>
-#include <asm/immap_qe.h>
-#include <asm/qe.h>
+#include <soc/fsl/qe/immap_qe.h>
+#include <soc/fsl/qe/qe.h>
 
-#include <asm/ucc.h>
-#include <asm/ucc_fast.h>
+#include <soc/fsl/qe/ucc.h>
+#include <soc/fsl/qe/ucc_fast.h>
 
 void ucc_fast_dump_regs(struct ucc_fast_private * uccf)
 {
diff --git a/arch/powerpc/sysdev/qe_lib/ucc_slow.c b/drivers/soc/fsl/qe/ucc_slow.c
similarity index 98%
rename from arch/powerpc/sysdev/qe_lib/ucc_slow.c
rename to drivers/soc/fsl/qe/ucc_slow.c
index 5f91628..9334bdb 100644
--- a/arch/powerpc/sysdev/qe_lib/ucc_slow.c
+++ b/drivers/soc/fsl/qe/ucc_slow.c
@@ -21,11 +21,11 @@
 #include <linux/export.h>
 
 #include <asm/io.h>
-#include <asm/immap_qe.h>
-#include <asm/qe.h>
+#include <soc/fsl/qe/immap_qe.h>
+#include <soc/fsl/qe/qe.h>
 
-#include <asm/ucc.h>
-#include <asm/ucc_slow.h>
+#include <soc/fsl/qe/ucc.h>
+#include <soc/fsl/qe/ucc_slow.h>
 
 u32 ucc_slow_get_qe_cr_subblock(int uccs_num)
 {
diff --git a/drivers/spi/spi-fsl-cpm.c b/drivers/spi/spi-fsl-cpm.c
index 9c46a30..bcb26bb 100644
--- a/drivers/spi/spi-fsl-cpm.c
+++ b/drivers/spi/spi-fsl-cpm.c
@@ -16,7 +16,7 @@
  * option) any later version.
  */
 #include <asm/cpm.h>
-#include <asm/qe.h>
+#include <soc/fsl/qe/qe.h>
 #include <linux/dma-mapping.h>
 #include <linux/fsl_devices.h>
 #include <linux/kernel.h>
diff --git a/drivers/tty/serial/ucc_uart.c b/drivers/tty/serial/ucc_uart.c
index 7d2532b..0b2cccd 100644
--- a/drivers/tty/serial/ucc_uart.c
+++ b/drivers/tty/serial/ucc_uart.c
@@ -31,7 +31,7 @@
 #include <linux/dma-mapping.h>
 
 #include <linux/fs_uart_pd.h>
-#include <asm/ucc_slow.h>
+#include <soc/fsl/qe/ucc_slow.h>
 
 #include <linux/firmware.h>
 #include <asm/reg.h>
diff --git a/drivers/usb/gadget/udc/fsl_qe_udc.c b/drivers/usb/gadget/udc/fsl_qe_udc.c
index e0822f1..f44659e 100644
--- a/drivers/usb/gadget/udc/fsl_qe_udc.c
+++ b/drivers/usb/gadget/udc/fsl_qe_udc.c
@@ -38,7 +38,7 @@
 #include <linux/usb/ch9.h>
 #include <linux/usb/gadget.h>
 #include <linux/usb/otg.h>
-#include <asm/qe.h>
+#include <soc/fsl/qe/qe.h>
 #include <asm/cpm.h>
 #include <asm/dma.h>
 #include <asm/reg.h>
diff --git a/drivers/usb/host/fhci-hcd.c b/drivers/usb/host/fhci-hcd.c
index c6cebb9..0960f41 100644
--- a/drivers/usb/host/fhci-hcd.c
+++ b/drivers/usb/host/fhci-hcd.c
@@ -31,7 +31,7 @@
 #include <linux/of_platform.h>
 #include <linux/of_gpio.h>
 #include <linux/slab.h>
-#include <asm/qe.h>
+#include <soc/fsl/qe/qe.h>
 #include <asm/fsl_gtm.h>
 #include "fhci.h"
 
diff --git a/drivers/usb/host/fhci-hub.c b/drivers/usb/host/fhci-hub.c
index 3bacdd7..60d55eb 100644
--- a/drivers/usb/host/fhci-hub.c
+++ b/drivers/usb/host/fhci-hub.c
@@ -24,7 +24,7 @@
 #include <linux/usb.h>
 #include <linux/usb/hcd.h>
 #include <linux/gpio.h>
-#include <asm/qe.h>
+#include <soc/fsl/qe/qe.h>
 #include "fhci.h"
 
 /* virtual root hub specific descriptor */
diff --git a/drivers/usb/host/fhci-sched.c b/drivers/usb/host/fhci-sched.c
index 95ca598..a9609a3 100644
--- a/drivers/usb/host/fhci-sched.c
+++ b/drivers/usb/host/fhci-sched.c
@@ -25,7 +25,7 @@
 #include <linux/io.h>
 #include <linux/usb.h>
 #include <linux/usb/hcd.h>
-#include <asm/qe.h>
+#include <soc/fsl/qe/qe.h>
 #include <asm/fsl_gtm.h>
 #include "fhci.h"
 
diff --git a/drivers/usb/host/fhci.h b/drivers/usb/host/fhci.h
index 154e6a0..3fc82c1 100644
--- a/drivers/usb/host/fhci.h
+++ b/drivers/usb/host/fhci.h
@@ -27,8 +27,8 @@
 #include <linux/io.h>
 #include <linux/usb.h>
 #include <linux/usb/hcd.h>
-#include <asm/qe.h>
-#include <asm/immap_qe.h>
+#include <soc/fsl/qe/qe.h>
+#include <soc/fsl/qe/immap_qe.h>
 
 #define USB_CLOCK	48000000
 
diff --git a/arch/powerpc/include/asm/qe_ic.h b/include/linux/fsl/qe/qe_ic.h
similarity index 100%
rename from arch/powerpc/include/asm/qe_ic.h
rename to include/linux/fsl/qe/qe_ic.h
diff --git a/arch/powerpc/include/asm/immap_qe.h b/include/soc/fsl/qe/immap_qe.h
similarity index 100%
rename from arch/powerpc/include/asm/immap_qe.h
rename to include/soc/fsl/qe/immap_qe.h
diff --git a/arch/powerpc/include/asm/qe.h b/include/soc/fsl/qe/qe.h
similarity index 99%
rename from arch/powerpc/include/asm/qe.h
rename to include/soc/fsl/qe/qe.h
index 35257c8..1496d33 100644
--- a/arch/powerpc/include/asm/qe.h
+++ b/include/soc/fsl/qe/qe.h
@@ -23,7 +23,7 @@
 #include <linux/of.h>
 #include <linux/of_address.h>
 #include <linux/types.h>
-#include <asm/immap_qe.h>
+#include <soc/fsl/qe/immap_qe.h>
 
 #define QE_NUM_OF_SNUM	256	/* There are 256 serial number in QE */
 #define QE_NUM_OF_BRGS	16
diff --git a/arch/powerpc/include/asm/ucc.h b/include/soc/fsl/qe/ucc.h
similarity index 96%
rename from arch/powerpc/include/asm/ucc.h
rename to include/soc/fsl/qe/ucc.h
index 6927ac2..894f14c 100644
--- a/arch/powerpc/include/asm/ucc.h
+++ b/include/soc/fsl/qe/ucc.h
@@ -15,8 +15,8 @@
 #ifndef __UCC_H__
 #define __UCC_H__
 
-#include <asm/immap_qe.h>
-#include <asm/qe.h>
+#include <soc/fsl/qe/immap_qe.h>
+#include <soc/fsl/qe/qe.h>
 
 #define STATISTICS
 
diff --git a/arch/powerpc/include/asm/ucc_fast.h b/include/soc/fsl/qe/ucc_fast.h
similarity index 98%
rename from arch/powerpc/include/asm/ucc_fast.h
rename to include/soc/fsl/qe/ucc_fast.h
index 72ea9ba..df8ea79 100644
--- a/arch/powerpc/include/asm/ucc_fast.h
+++ b/include/soc/fsl/qe/ucc_fast.h
@@ -16,10 +16,10 @@
 
 #include <linux/kernel.h>
 
-#include <asm/immap_qe.h>
-#include <asm/qe.h>
+#include <soc/fsl/qe/immap_qe.h>
+#include <soc/fsl/qe/qe.h>
 
-#include <asm/ucc.h>
+#include <soc/fsl/qe/ucc.h>
 
 /* Receive BD's status */
 #define R_E	0x80000000	/* buffer empty */
diff --git a/arch/powerpc/include/asm/ucc_slow.h b/include/soc/fsl/qe/ucc_slow.h
similarity index 99%
rename from arch/powerpc/include/asm/ucc_slow.h
rename to include/soc/fsl/qe/ucc_slow.h
index 233ef5f..6c0573a 100644
--- a/arch/powerpc/include/asm/ucc_slow.h
+++ b/include/soc/fsl/qe/ucc_slow.h
@@ -17,10 +17,10 @@
 
 #include <linux/kernel.h>
 
-#include <asm/immap_qe.h>
-#include <asm/qe.h>
+#include <soc/fsl/qe/immap_qe.h>
+#include <soc/fsl/qe/qe.h>
 
-#include <asm/ucc.h>
+#include <soc/fsl/qe/ucc.h>
 
 /* transmit BD's status */
 #define T_R	0x80000000	/* ready bit */
-- 
2.1.0.27.g96db324


^ permalink raw reply related	[flat|nested] 42+ messages in thread

* Re: [PATCH V7 1/3] genalloc:support memory-allocation with bytes-alignment to genalloc
  2015-08-31  8:58 [PATCH V7 1/3] genalloc:support memory-allocation with bytes-alignment to genalloc Zhao Qiang
  2015-08-31  8:58 ` [PATCH V7 2/3] qe_common: add qe_muram_ functions to manage muram Zhao Qiang
  2015-08-31  8:58 ` [PATCH V7 3/3] QE: Move QE from arch/powerpc to drivers/soc Zhao Qiang
@ 2015-09-02  0:30 ` Scott Wood
  2015-09-02  2:10     ` Zhao Qiang
  2 siblings, 1 reply; 42+ messages in thread
From: Scott Wood @ 2015-09-02  0:30 UTC (permalink / raw)
  To: Zhao Qiang; +Cc: linux-kernel, linuxppc-dev, lauraa, X.xie, benh, leoli, paulus

On Mon, 2015-08-31 at 16:58 +0800, Zhao Qiang wrote:
> 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 <qiang.zhao@freescale.com>
> ---
> 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.

This seems to be describing more than just the changes in this patch.  What 
does also handling cpm have to do with this patch?  Are you adding support 
for reserving a specific region in this patch?  I don't see it, and in any 
case it should go in a different patch.

> +/*
> + *  gen_pool data descriptor for gen_pool_first_fit_align.
> + */
> +struct genpool_data_align {
> +     int align;              /* alignment by bytes for starting address */
> +     unsigned long offset;   /* the offset of allocation start addr*/
> +};

The offset belongs on the caller side, not here.

-Scott


^ permalink raw reply	[flat|nested] 42+ messages in thread

* Re: [PATCH V7 2/3] qe_common: add qe_muram_ functions to manage muram
  2015-08-31  8:58 ` [PATCH V7 2/3] qe_common: add qe_muram_ functions to manage muram Zhao Qiang
@ 2015-09-02  0:34   ` Scott Wood
  2015-09-02  2:22       ` Zhao Qiang
  2015-09-06  6:37       ` Zhao Qiang
  0 siblings, 2 replies; 42+ messages in thread
From: Scott Wood @ 2015-09-02  0:34 UTC (permalink / raw)
  To: Zhao Qiang; +Cc: linux-kernel, linuxppc-dev, lauraa, X.xie, benh, leoli, paulus

On Mon, 2015-08-31 at 16:58 +0800, Zhao Qiang wrote:

> @@ -187,12 +190,25 @@ static inline int qe_alive_during_sleep(void)
>  }
>  
>  /* we actually use cpm_muram implementation, define this for convenience */
> -#define qe_muram_init cpm_muram_init
> -#define qe_muram_alloc cpm_muram_alloc
> -#define qe_muram_alloc_fixed cpm_muram_alloc_fixed
> -#define qe_muram_free cpm_muram_free
> -#define qe_muram_addr cpm_muram_addr
> -#define qe_muram_offset cpm_muram_offset
> +#define cpm_muram_init qe_muram_init
> +#define cpm_muram_alloc qe_muram_alloc
> +#define cpm_muram_alloc_fixed qe_muram_alloc_fixed
> +#define cpm_muram_free qe_muram_free
> +#define cpm_muram_addr qe_muram_addr
> +#define cpm_muram_offset qe_muram_offset

Why?  This is unnecessary churn.


> @@ -266,6 +282,27 @@ struct qe_bd {
>  #define BD_STATUS_MASK       0xffff0000
>  #define BD_LENGTH_MASK       0x0000ffff
>  
> +/* Buffer descriptor control/status used by serial
> + */
> +
> +#define BD_SC_READY  (0x8000)        /* Transmit is ready */
> +#define BD_SC_WRAP   (0x2000)        /* Last buffer descriptor */
> +#define BD_SC_INTRPT (0x1000)        /* Interrupt on change */
> +#define BD_SC_LAST   (0x0800)        /* Last buffer in frame */
> +#define BD_SC_TC     (0x0400)        /* Transmit CRC */
> +#define BD_SC_CM     (0x0200)        /* Continuous mode */
> +#define BD_SC_ID     (0x0100)        /* Rec'd too many idles */
> +#define BD_SC_P              (0x0100)        /* xmt preamble */
> +#define BD_SC_BR     (0x0020)        /* Break received */
> +#define BD_SC_FR     (0x0010)        /* Framing error */
> +#define BD_SC_PR     (0x0008)        /* Parity error */
> +#define BD_SC_NAK    (0x0004)        /* NAK - did not respond */
> +#define BD_SC_OV     (0x0002)        /* Overrun */
> +#define BD_SC_UN     (0x0002)        /* Underrun */
> +#define BD_SC_CD     (0x0001)        /* */
> +#define BD_SC_CL     (0x0001)        /* Collision */
> +

Why is this being copied rather than moved?


>  
> -int cpm_muram_init(void)
> -{
> -     struct device_node *np;
> -     struct resource r;
> -     u32 zero[OF_MAX_ADDR_CELLS] = {};
> -     resource_size_t max = 0;
> -     int i = 0;
> -     int ret = 0;
> -
> -     if (muram_pbase)
> -             return 0;
> -
> -     spin_lock_init(&cpm_muram_lock);
> -     /* initialize the info header */
> -     rh_init(&cpm_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");
> -                     ret = -ENODEV;
> -                     goto out;
> -             }
> -     }
> -
> -     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");
> -             ret = -ENODEV;
> -             goto out;
> -     }

Did you pass -M -C to git format-patch?

-Scott


^ permalink raw reply	[flat|nested] 42+ messages in thread

* RE: [PATCH V7 1/3] genalloc:support memory-allocation with bytes-alignment to genalloc
  2015-09-02  0:30 ` [PATCH V7 1/3] genalloc:support memory-allocation with bytes-alignment to genalloc Scott Wood
@ 2015-09-02  2:10     ` Zhao Qiang
  0 siblings, 0 replies; 42+ messages in thread
From: Zhao Qiang @ 2015-09-02  2:10 UTC (permalink / raw)
  To: Scott Wood
  Cc: linux-kernel, linuxppc-dev, lauraa, Xiaobo Xie, benh, Li Leo, paulus

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="utf-8", Size: 2716 bytes --]

On Wed, 2015-09-02 at 08:38AM +0800, Wood Scott-B07421 wrote:
> -----Original Message-----
> From: Wood Scott-B07421
> Sent: Wednesday, September 02, 2015 8:30 AM
> To: Zhao Qiang-B45475
> Cc: linux-kernel@vger.kernel.org; linuxppc-dev@lists.ozlabs.org;
> lauraa@codeaurora.org; Xie Xiaobo-R63061; benh@kernel.crashing.org; Li
> Yang-Leo-R58472; paulus@samba.org
> Subject: Re: [PATCH V7 1/3] genalloc:support memory-allocation with
> bytes-alignment to genalloc
> 
> On Mon, 2015-08-31 at 16:58 +0800, Zhao Qiang wrote:
> > 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 <qiang.zhao@freescale.com>
> > ---
> > 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.
> 
> This seems to be describing more than just the changes in this patch.
> What does also handling cpm have to do with this patch?  Are you adding
> support for reserving a specific region in this patch?  I don't see it,
> and in any case it should go in a different patch.

Yes, I added. The code below can support the function.
	offset_bit = (alignment->offset + (1UL << order) - 1) >> order;
      return bitmap_find_next_zero_area(map, size, start + offset_bit, nr,
                        align_mask);
CPM has an function cpm_muram_alloc_fixed, needing to allocate muram from a
Specific offset. So I add the code and add offset to struct data.
This patch is the first patch of this patch set, so I explain what changes about
Set v7 and why I add support for reserving a specific region in this patch.

If you really think a different patch needed, I can add a new patch to handle it.

> 
> > +/*
> > + *  gen_pool data descriptor for gen_pool_first_fit_align.
> > + */
> > +struct genpool_data_align {
> > +     int align;              /* alignment by bytes for starting
> address */
> > +     unsigned long offset;   /* the offset of allocation start addr*/
> > +};
> 
> The offset belongs on the caller side, not here.

So, how do I pass offset to gen_pool_alloc_data or pool->algo?

> 
> -Scott

ÿôèº{.nÇ+‰·Ÿ®‰­†+%ŠËÿ±éݶ\x17¥Šwÿº{.nÇ+‰·¥Š{±þG«éÿŠ{ayº\x1dʇڙë,j\a­¢f£¢·hšïêÿ‘êçz_è®\x03(­éšŽŠÝ¢j"ú\x1a¶^[m§ÿÿ¾\a«þG«éÿ¢¸?™¨è­Ú&£ø§~á¶iO•æ¬z·švØ^\x14\x04\x1a¶^[m§ÿÿÃ\fÿ¶ìÿ¢¸?–I¥

^ permalink raw reply	[flat|nested] 42+ messages in thread

* RE: [PATCH V7 1/3] genalloc:support memory-allocation with bytes-alignment to genalloc
@ 2015-09-02  2:10     ` Zhao Qiang
  0 siblings, 0 replies; 42+ messages in thread
From: Zhao Qiang @ 2015-09-02  2:10 UTC (permalink / raw)
  To: Scott Wood
  Cc: linux-kernel, linuxppc-dev, lauraa, Xiaobo Xie, benh, Li Leo, paulus

T24gV2VkLCAyMDE1LTA5LTAyIGF0IDA4OjM4QU0gKzA4MDAsIFdvb2QgU2NvdHQtQjA3NDIxIHdy
b3RlOg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBXb29kIFNjb3R0LUIw
NzQyMQ0KPiBTZW50OiBXZWRuZXNkYXksIFNlcHRlbWJlciAwMiwgMjAxNSA4OjMwIEFNDQo+IFRv
OiBaaGFvIFFpYW5nLUI0NTQ3NQ0KPiBDYzogbGludXgta2VybmVsQHZnZXIua2VybmVsLm9yZzsg
bGludXhwcGMtZGV2QGxpc3RzLm96bGFicy5vcmc7DQo+IGxhdXJhYUBjb2RlYXVyb3JhLm9yZzsg
WGllIFhpYW9iby1SNjMwNjE7IGJlbmhAa2VybmVsLmNyYXNoaW5nLm9yZzsgTGkNCj4gWWFuZy1M
ZW8tUjU4NDcyOyBwYXVsdXNAc2FtYmEub3JnDQo+IFN1YmplY3Q6IFJlOiBbUEFUQ0ggVjcgMS8z
XSBnZW5hbGxvYzpzdXBwb3J0IG1lbW9yeS1hbGxvY2F0aW9uIHdpdGgNCj4gYnl0ZXMtYWxpZ25t
ZW50IHRvIGdlbmFsbG9jDQo+IA0KPiBPbiBNb24sIDIwMTUtMDgtMzEgYXQgMTY6NTggKzA4MDAs
IFpoYW8gUWlhbmcgd3JvdGU6DQo+ID4gQnl0ZXMgYWxpZ25tZW50IGlzIHJlcXVpcmVkIHRvIG1h
bmFnZSBzb21lIHNwZWNpYWwgUkFNLCBzbyBhZGQNCj4gPiBnZW5fcG9vbF9maXJzdF9maXRfYWxp
Z24gdG8gZ2VuYWxsb2MsIG1lYW53aGlsZSBhZGQNCj4gPiBnZW5fcG9vbF9hbGxvY19kYXRhIHRv
IHBhc3MgZGF0YSB0byBnZW5fcG9vbF9maXJzdF9maXRfYWxpZ24obW9kaWZ5DQo+ID4gZ2VuX3Bv
b2xfYWxsb2MgYXMgYSB3cmFwcGVyKQ0KPiA+DQo+ID4gU2lnbmVkLW9mZi1ieTogWmhhbyBRaWFu
ZyA8cWlhbmcuemhhb0BmcmVlc2NhbGUuY29tPg0KPiA+IC0tLQ0KPiA+IENoYW5nZXMgZm9yIHY2
Og0KPiA+ICAgICAgIC0gcGF0Y2hlcyBzZXQgdjYgaW5jbHVkZSBhIG5ldyBwYXRjaCBiZWNhdXNl
IG9mIHVzaW5nDQo+ID4gICAgICAgLSBnZW5hbGxvYyB0byBtYW5hZ2UgUUUgTVVSQU0sIHBhdGNo
IDAwMDEgaXMgdGhlIG5ldw0KPiA+ICAgICAgIC0gcGF0Y2gsIGFkZGluZyBieXRlcyBhbGlnbm1l
bnQgZm9yIGFsbG9jYXRpb24gZm9yIHVzZS4NCj4gPiBDaGFuZ2VzIGZvciB2NzoNCj4gPiAgICAg
ICAtIGNwbSBtdXJhbSBhbHNvIG5lZWQgdG8gdXNlIGdlbmFsbG9jIHRvIG1hbmFnZSwgaXQgaGFz
DQo+ID4gICAgICAgICBhIGZ1bmN0aW9uIHRvIHJlc2VydmUgYSBzcGVjaWZpYyByZWdpb24gb2Yg
bXVyYW0sDQo+ID4gICAgICAgICBhZGQgb2Zmc2V0IHRvIGdlbnBvb2xfZGF0YSBmb3Igc3RhcnQg
YWRkciB0byBiZSBhbGxvY2F0ZWQuDQo+IA0KPiBUaGlzIHNlZW1zIHRvIGJlIGRlc2NyaWJpbmcg
bW9yZSB0aGFuIGp1c3QgdGhlIGNoYW5nZXMgaW4gdGhpcyBwYXRjaC4NCj4gV2hhdCBkb2VzIGFs
c28gaGFuZGxpbmcgY3BtIGhhdmUgdG8gZG8gd2l0aCB0aGlzIHBhdGNoPyAgQXJlIHlvdSBhZGRp
bmcNCj4gc3VwcG9ydCBmb3IgcmVzZXJ2aW5nIGEgc3BlY2lmaWMgcmVnaW9uIGluIHRoaXMgcGF0
Y2g/ICBJIGRvbid0IHNlZSBpdCwNCj4gYW5kIGluIGFueSBjYXNlIGl0IHNob3VsZCBnbyBpbiBh
IGRpZmZlcmVudCBwYXRjaC4NCg0KWWVzLCBJIGFkZGVkLiBUaGUgY29kZSBiZWxvdyBjYW4gc3Vw
cG9ydCB0aGUgZnVuY3Rpb24uDQoJb2Zmc2V0X2JpdCA9IChhbGlnbm1lbnQtPm9mZnNldCArICgx
VUwgPDwgb3JkZXIpIC0gMSkgPj4gb3JkZXI7DQogICAgICByZXR1cm4gYml0bWFwX2ZpbmRfbmV4
dF96ZXJvX2FyZWEobWFwLCBzaXplLCBzdGFydCArIG9mZnNldF9iaXQsIG5yLA0KICAgICAgICAg
ICAgICAgICAgICAgICAgYWxpZ25fbWFzayk7DQpDUE0gaGFzIGFuIGZ1bmN0aW9uIGNwbV9tdXJh
bV9hbGxvY19maXhlZCwgbmVlZGluZyB0byBhbGxvY2F0ZSBtdXJhbSBmcm9tIGENClNwZWNpZmlj
IG9mZnNldC4gU28gSSBhZGQgdGhlIGNvZGUgYW5kIGFkZCBvZmZzZXQgdG8gc3RydWN0IGRhdGEu
DQpUaGlzIHBhdGNoIGlzIHRoZSBmaXJzdCBwYXRjaCBvZiB0aGlzIHBhdGNoIHNldCwgc28gSSBl
eHBsYWluIHdoYXQgY2hhbmdlcyBhYm91dA0KU2V0IHY3IGFuZCB3aHkgSSBhZGQgc3VwcG9ydCBm
b3IgcmVzZXJ2aW5nIGEgc3BlY2lmaWMgcmVnaW9uIGluIHRoaXMgcGF0Y2guDQoNCklmIHlvdSBy
ZWFsbHkgdGhpbmsgYSBkaWZmZXJlbnQgcGF0Y2ggbmVlZGVkLCBJIGNhbiBhZGQgYSBuZXcgcGF0
Y2ggdG8gaGFuZGxlIGl0Lg0KDQo+IA0KPiA+ICsvKg0KPiA+ICsgKiAgZ2VuX3Bvb2wgZGF0YSBk
ZXNjcmlwdG9yIGZvciBnZW5fcG9vbF9maXJzdF9maXRfYWxpZ24uDQo+ID4gKyAqLw0KPiA+ICtz
dHJ1Y3QgZ2VucG9vbF9kYXRhX2FsaWduIHsNCj4gPiArICAgICBpbnQgYWxpZ247ICAgICAgICAg
ICAgICAvKiBhbGlnbm1lbnQgYnkgYnl0ZXMgZm9yIHN0YXJ0aW5nDQo+IGFkZHJlc3MgKi8NCj4g
PiArICAgICB1bnNpZ25lZCBsb25nIG9mZnNldDsgICAvKiB0aGUgb2Zmc2V0IG9mIGFsbG9jYXRp
b24gc3RhcnQgYWRkciovDQo+ID4gK307DQo+IA0KPiBUaGUgb2Zmc2V0IGJlbG9uZ3Mgb24gdGhl
IGNhbGxlciBzaWRlLCBub3QgaGVyZS4NCg0KU28sIGhvdyBkbyBJIHBhc3Mgb2Zmc2V0IHRvIGdl
bl9wb29sX2FsbG9jX2RhdGEgb3IgcG9vbC0+YWxnbz8NCg0KPiANCj4gLVNjb3R0DQoNCg==

^ permalink raw reply	[flat|nested] 42+ messages in thread

* Re: [PATCH V7 1/3] genalloc:support memory-allocation with bytes-alignment to genalloc
  2015-09-02  2:10     ` Zhao Qiang
  (?)
@ 2015-09-02  2:18     ` Scott Wood
  2015-09-02  2:29         ` Zhao Qiang
  2015-09-06  3:13         ` Zhao Qiang
  -1 siblings, 2 replies; 42+ messages in thread
From: Scott Wood @ 2015-09-02  2:18 UTC (permalink / raw)
  To: Zhao Qiang-B45475
  Cc: linux-kernel, linuxppc-dev, lauraa, Xie Xiaobo-R63061, benh,
	Li Yang-Leo-R58472, paulus

On Tue, 2015-09-01 at 21:10 -0500, Zhao Qiang-B45475 wrote:
> On Wed, 2015-09-02 at 08:38AM +0800, Wood Scott-B07421 wrote:
> > -----Original Message-----
> > From: Wood Scott-B07421
> > Sent: Wednesday, September 02, 2015 8:30 AM
> > To: Zhao Qiang-B45475
> > Cc: linux-kernel@vger.kernel.org; linuxppc-dev@lists.ozlabs.org;
> > lauraa@codeaurora.org; Xie Xiaobo-R63061; benh@kernel.crashing.org; Li
> > Yang-Leo-R58472; paulus@samba.org
> > Subject: Re: [PATCH V7 1/3] genalloc:support memory-allocation with
> > bytes-alignment to genalloc
> > 
> > On Mon, 2015-08-31 at 16:58 +0800, Zhao Qiang wrote:
> > > 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 <qiang.zhao@freescale.com>
> > > ---
> > > 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.
> > 
> > This seems to be describing more than just the changes in this patch.
> > What does also handling cpm have to do with this patch?  Are you adding
> > support for reserving a specific region in this patch?  I don't see it,
> > and in any case it should go in a different patch.
> 
> Yes, I added. The code below can support the function.
>       offset_bit = (alignment->offset + (1UL << order) - 1) >> order;
>       return bitmap_find_next_zero_area(map, size, start + offset_bit, nr,
>                         align_mask);
>
> CPM has an function cpm_muram_alloc_fixed, needing to allocate muram from a
> Specific offset. So I add the code and add offset to struct data.

I thought the offset was related to the previous discussion of checking for 
allocation failure.  Are you using it to implement alloc_fixed()?  If so, 
please don't.  Besides the awkward implementation (what does it logically 
have to do with gen_pool_first_fit_align?), it does not appear to be correct -
- what happens with multiple chunks?  What happens if part of the region the 
caller is trying to reserve is already taken?  Implement a proper function to 
reserve a fixed genalloc region.

> This patch is the first patch of this patch set, so I explain what changes 
> about
> Set v7 and why I add support for reserving a specific region in this patch.

If you want to provide commentary that covers the entire patchset, use a 
cover letter.

> > > +/*
> > > + *  gen_pool data descriptor for gen_pool_first_fit_align.
> > > + */
> > > +struct genpool_data_align {
> > > +     int align;              /* alignment by bytes for starting
> > address */
> > > +     unsigned long offset;   /* the offset of allocation start addr*/
> > > +};
> > 
> > The offset belongs on the caller side, not here.
> 
> So, how do I pass offset to gen_pool_alloc_data or pool->algo?

You don't.

-Scott



^ permalink raw reply	[flat|nested] 42+ messages in thread

* RE: [PATCH V7 2/3] qe_common: add qe_muram_ functions to manage muram
  2015-09-02  0:34   ` Scott Wood
@ 2015-09-02  2:22       ` Zhao Qiang
  2015-09-06  6:37       ` Zhao Qiang
  1 sibling, 0 replies; 42+ messages in thread
From: Zhao Qiang @ 2015-09-02  2:22 UTC (permalink / raw)
  To: Scott Wood
  Cc: linux-kernel, linuxppc-dev, lauraa, Xiaobo Xie, benh, Li Leo, paulus

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="utf-8", Size: 2005 bytes --]

On Wed, 2015-09-02 at 8:34AM +0800, Wood Scott-B07421 wrote:
> -----Original Message-----
> From: Wood Scott-B07421
> Sent: Wednesday, September 02, 2015 8:34 AM
> To: Zhao Qiang-B45475
> Cc: linux-kernel@vger.kernel.org; linuxppc-dev@lists.ozlabs.org;
> lauraa@codeaurora.org; Xie Xiaobo-R63061; benh@kernel.crashing.org; Li
> Yang-Leo-R58472; paulus@samba.org
> Subject: Re: [PATCH V7 2/3] qe_common: add qe_muram_ functions to manage
> muram
> 
> On Mon, 2015-08-31 at 16:58 +0800, Zhao Qiang wrote:
> 
> > -int cpm_muram_init(void)
> > -{
> > -     struct device_node *np;
> > -     struct resource r;
> > -     u32 zero[OF_MAX_ADDR_CELLS] = {};
> > -     resource_size_t max = 0;
> > -     int i = 0;
> > -     int ret = 0;
> > -
> > -     if (muram_pbase)
> > -             return 0;
> > -
> > -     spin_lock_init(&cpm_muram_lock);
> > -     /* initialize the info header */
> > -     rh_init(&cpm_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");
> > -                     ret = -ENODEV;
> > -                     goto out;
> > -             }
> > -     }
> > -
> > -     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");
> > -             ret = -ENODEV;
> > -             goto out;
> > -     }
> 
> Did you pass -M -C to git format-patch?


Yes!

> 
> -Scott
-Zhao
ÿôèº{.nÇ+‰·Ÿ®‰­†+%ŠËÿ±éݶ\x17¥Šwÿº{.nÇ+‰·¥Š{±þG«éÿŠ{ayº\x1dʇڙë,j\a­¢f£¢·hšïêÿ‘êçz_è®\x03(­éšŽŠÝ¢j"ú\x1a¶^[m§ÿÿ¾\a«þG«éÿ¢¸?™¨è­Ú&£ø§~á¶iO•æ¬z·švØ^\x14\x04\x1a¶^[m§ÿÿÃ\fÿ¶ìÿ¢¸?–I¥

^ permalink raw reply	[flat|nested] 42+ messages in thread

* RE: [PATCH V7 2/3] qe_common: add qe_muram_ functions to manage muram
@ 2015-09-02  2:22       ` Zhao Qiang
  0 siblings, 0 replies; 42+ messages in thread
From: Zhao Qiang @ 2015-09-02  2:22 UTC (permalink / raw)
  To: Scott Wood
  Cc: linux-kernel, linuxppc-dev, lauraa, Xiaobo Xie, benh, Li Leo, paulus

T24gV2VkLCAyMDE1LTA5LTAyIGF0IDg6MzRBTSArMDgwMCwgV29vZCBTY290dC1CMDc0MjEgd3Jv
dGU6DQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IFdvb2QgU2NvdHQtQjA3
NDIxDQo+IFNlbnQ6IFdlZG5lc2RheSwgU2VwdGVtYmVyIDAyLCAyMDE1IDg6MzQgQU0NCj4gVG86
IFpoYW8gUWlhbmctQjQ1NDc1DQo+IENjOiBsaW51eC1rZXJuZWxAdmdlci5rZXJuZWwub3JnOyBs
aW51eHBwYy1kZXZAbGlzdHMub3psYWJzLm9yZzsNCj4gbGF1cmFhQGNvZGVhdXJvcmEub3JnOyBY
aWUgWGlhb2JvLVI2MzA2MTsgYmVuaEBrZXJuZWwuY3Jhc2hpbmcub3JnOyBMaQ0KPiBZYW5nLUxl
by1SNTg0NzI7IHBhdWx1c0BzYW1iYS5vcmcNCj4gU3ViamVjdDogUmU6IFtQQVRDSCBWNyAyLzNd
IHFlX2NvbW1vbjogYWRkIHFlX211cmFtXyBmdW5jdGlvbnMgdG8gbWFuYWdlDQo+IG11cmFtDQo+
IA0KPiBPbiBNb24sIDIwMTUtMDgtMzEgYXQgMTY6NTggKzA4MDAsIFpoYW8gUWlhbmcgd3JvdGU6
DQo+IA0KPiA+IC1pbnQgY3BtX211cmFtX2luaXQodm9pZCkNCj4gPiAtew0KPiA+IC0gICAgIHN0
cnVjdCBkZXZpY2Vfbm9kZSAqbnA7DQo+ID4gLSAgICAgc3RydWN0IHJlc291cmNlIHI7DQo+ID4g
LSAgICAgdTMyIHplcm9bT0ZfTUFYX0FERFJfQ0VMTFNdID0ge307DQo+ID4gLSAgICAgcmVzb3Vy
Y2Vfc2l6ZV90IG1heCA9IDA7DQo+ID4gLSAgICAgaW50IGkgPSAwOw0KPiA+IC0gICAgIGludCBy
ZXQgPSAwOw0KPiA+IC0NCj4gPiAtICAgICBpZiAobXVyYW1fcGJhc2UpDQo+ID4gLSAgICAgICAg
ICAgICByZXR1cm4gMDsNCj4gPiAtDQo+ID4gLSAgICAgc3Bpbl9sb2NrX2luaXQoJmNwbV9tdXJh
bV9sb2NrKTsNCj4gPiAtICAgICAvKiBpbml0aWFsaXplIHRoZSBpbmZvIGhlYWRlciAqLw0KPiA+
IC0gICAgIHJoX2luaXQoJmNwbV9tdXJhbV9pbmZvLCAxLA0KPiA+IC0gICAgICAgICAgICAgc2l6
ZW9mKGNwbV9ib290X211cmFtX3JoX2Jsb2NrKSAvDQo+ID4gLSAgICAgICAgICAgICBzaXplb2Yo
Y3BtX2Jvb3RfbXVyYW1fcmhfYmxvY2tbMF0pLA0KPiA+IC0gICAgICAgICAgICAgY3BtX2Jvb3Rf
bXVyYW1fcmhfYmxvY2spOw0KPiA+IC0NCj4gPiAtICAgICBucCA9IG9mX2ZpbmRfY29tcGF0aWJs
ZV9ub2RlKE5VTEwsIE5VTEwsICJmc2wsY3BtLW11cmFtLWRhdGEiKTsNCj4gPiAtICAgICBpZiAo
IW5wKSB7DQo+ID4gLSAgICAgICAgICAgICAvKiB0cnkgbGVnYWN5IGJpbmRpbmdzICovDQo+ID4g
LSAgICAgICAgICAgICBucCA9IG9mX2ZpbmRfbm9kZV9ieV9uYW1lKE5VTEwsICJkYXRhLW9ubHki
KTsNCj4gPiAtICAgICAgICAgICAgIGlmICghbnApIHsNCj4gPiAtICAgICAgICAgICAgICAgICAg
ICAgcHJpbnRrKEtFUk5fRVJSICJDYW5ub3QgZmluZCBDUE0gbXVyYW0gZGF0YQ0KPiBub2RlIik7
DQo+ID4gLSAgICAgICAgICAgICAgICAgICAgIHJldCA9IC1FTk9ERVY7DQo+ID4gLSAgICAgICAg
ICAgICAgICAgICAgIGdvdG8gb3V0Ow0KPiA+IC0gICAgICAgICAgICAgfQ0KPiA+IC0gICAgIH0N
Cj4gPiAtDQo+ID4gLSAgICAgbXVyYW1fcGJhc2UgPSBvZl90cmFuc2xhdGVfYWRkcmVzcyhucCwg
emVybyk7DQo+ID4gLSAgICAgaWYgKG11cmFtX3BiYXNlID09IChwaHlzX2FkZHJfdClPRl9CQURf
QUREUikgew0KPiA+IC0gICAgICAgICAgICAgcHJpbnRrKEtFUk5fRVJSICJDYW5ub3QgdHJhbnNs
YXRlIHplcm8gdGhyb3VnaCBDUE0gbXVyYW0NCj4gbm9kZSIpOw0KPiA+IC0gICAgICAgICAgICAg
cmV0ID0gLUVOT0RFVjsNCj4gPiAtICAgICAgICAgICAgIGdvdG8gb3V0Ow0KPiA+IC0gICAgIH0N
Cj4gDQo+IERpZCB5b3UgcGFzcyAtTSAtQyB0byBnaXQgZm9ybWF0LXBhdGNoPw0KDQoNClllcyEN
Cg0KPiANCj4gLVNjb3R0DQotWmhhbw0K

^ permalink raw reply	[flat|nested] 42+ messages in thread

* RE: [PATCH V7 1/3] genalloc:support memory-allocation with bytes-alignment to genalloc
  2015-09-02  2:18     ` Scott Wood
@ 2015-09-02  2:29         ` Zhao Qiang
  2015-09-06  3:13         ` Zhao Qiang
  1 sibling, 0 replies; 42+ messages in thread
From: Zhao Qiang @ 2015-09-02  2:29 UTC (permalink / raw)
  To: Scott Wood
  Cc: linux-kernel, linuxppc-dev, lauraa, Xiaobo Xie, benh, Li Leo, paulus

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="utf-8", Size: 4235 bytes --]

On Wed, 2015-09-02 at 10:18AM -0500, Wood Scott-B07421 wrote:
> -----Original Message-----
> From: Wood Scott-B07421
> Sent: Wednesday, September 02, 2015 10:18 AM
> To: Zhao Qiang-B45475
> Cc: linux-kernel@vger.kernel.org; linuxppc-dev@lists.ozlabs.org;
> lauraa@codeaurora.org; Xie Xiaobo-R63061; benh@kernel.crashing.org; Li
> Yang-Leo-R58472; paulus@samba.org
> Subject: Re: [PATCH V7 1/3] genalloc:support memory-allocation with
> bytes-alignment to genalloc
> 
> On Tue, 2015-09-01 at 21:10 -0500, Zhao Qiang-B45475 wrote:
> > On Wed, 2015-09-02 at 08:38AM +0800, Wood Scott-B07421 wrote:
> > > -----Original Message-----
> > > From: Wood Scott-B07421
> > > Sent: Wednesday, September 02, 2015 8:30 AM
> > > To: Zhao Qiang-B45475
> > > Cc: linux-kernel@vger.kernel.org; linuxppc-dev@lists.ozlabs.org;
> > > lauraa@codeaurora.org; Xie Xiaobo-R63061; benh@kernel.crashing.org;
> > > Li Yang-Leo-R58472; paulus@samba.org
> > > Subject: Re: [PATCH V7 1/3] genalloc:support memory-allocation with
> > > bytes-alignment to genalloc
> > >
> > > On Mon, 2015-08-31 at 16:58 +0800, Zhao Qiang wrote:
> > > > 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 <qiang.zhao@freescale.com>
> > > > ---
> > > > 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.
> > >
> > > This seems to be describing more than just the changes in this patch.
> > > What does also handling cpm have to do with this patch?  Are you
> > > adding support for reserving a specific region in this patch?  I
> > > don't see it, and in any case it should go in a different patch.
> >
> > Yes, I added. The code below can support the function.
> >       offset_bit = (alignment->offset + (1UL << order) - 1) >> order;
> >       return bitmap_find_next_zero_area(map, size, start + offset_bit,
> nr,
> >                         align_mask);
> >
> > CPM has an function cpm_muram_alloc_fixed, needing to allocate muram
> > from a Specific offset. So I add the code and add offset to struct data.
> 
> I thought the offset was related to the previous discussion of checking
> for allocation failure.  Are you using it to implement alloc_fixed()?  If
> so, please don't.  Besides the awkward implementation (what does it
> logically have to do with gen_pool_first_fit_align?), it does not appear
> to be correct -
> - what happens with multiple chunks?  What happens if part of the region
> the caller is trying to reserve is already taken?  Implement a proper
> function to reserve a fixed genalloc region.

This offset is totally different with the workaround OFFSET!
This offset is the offset of the muram.
CPM need to allocate block from a specific offset due to hardware restriction.
So I must handle this offset in genalloc. 

> 
> > This patch is the first patch of this patch set, so I explain what
> > changes about Set v7 and why I add support for reserving a specific
> > region in this patch.
> 
> If you want to provide commentary that covers the entire patchset, use a
> cover letter.
> 
> > > > +/*
> > > > + *  gen_pool data descriptor for gen_pool_first_fit_align.
> > > > + */
> > > > +struct genpool_data_align {
> > > > +     int align;              /* alignment by bytes for starting
> > > address */
> > > > +     unsigned long offset;   /* the offset of allocation start
> addr*/
> > > > +};
> > >
> > > The offset belongs on the caller side, not here.
> >
> > So, how do I pass offset to gen_pool_alloc_data or pool->algo?
> 
> You don't.
> 
> -Scott
> 

ÿôèº{.nÇ+‰·Ÿ®‰­†+%ŠËÿ±éݶ\x17¥Šwÿº{.nÇ+‰·¥Š{±þG«éÿŠ{ayº\x1dʇڙë,j\a­¢f£¢·hšïêÿ‘êçz_è®\x03(­éšŽŠÝ¢j"ú\x1a¶^[m§ÿÿ¾\a«þG«éÿ¢¸?™¨è­Ú&£ø§~á¶iO•æ¬z·švØ^\x14\x04\x1a¶^[m§ÿÿÃ\fÿ¶ìÿ¢¸?–I¥

^ permalink raw reply	[flat|nested] 42+ messages in thread

* RE: [PATCH V7 1/3] genalloc:support memory-allocation with bytes-alignment to genalloc
@ 2015-09-02  2:29         ` Zhao Qiang
  0 siblings, 0 replies; 42+ messages in thread
From: Zhao Qiang @ 2015-09-02  2:29 UTC (permalink / raw)
  To: Scott Wood
  Cc: linux-kernel, linuxppc-dev, lauraa, Xiaobo Xie, benh, Li Leo, paulus

T24gV2VkLCAyMDE1LTA5LTAyIGF0IDEwOjE4QU0gLTA1MDAsIFdvb2QgU2NvdHQtQjA3NDIxIHdy
b3RlOg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBXb29kIFNjb3R0LUIw
NzQyMQ0KPiBTZW50OiBXZWRuZXNkYXksIFNlcHRlbWJlciAwMiwgMjAxNSAxMDoxOCBBTQ0KPiBU
bzogWmhhbyBRaWFuZy1CNDU0NzUNCj4gQ2M6IGxpbnV4LWtlcm5lbEB2Z2VyLmtlcm5lbC5vcmc7
IGxpbnV4cHBjLWRldkBsaXN0cy5vemxhYnMub3JnOw0KPiBsYXVyYWFAY29kZWF1cm9yYS5vcmc7
IFhpZSBYaWFvYm8tUjYzMDYxOyBiZW5oQGtlcm5lbC5jcmFzaGluZy5vcmc7IExpDQo+IFlhbmct
TGVvLVI1ODQ3MjsgcGF1bHVzQHNhbWJhLm9yZw0KPiBTdWJqZWN0OiBSZTogW1BBVENIIFY3IDEv
M10gZ2VuYWxsb2M6c3VwcG9ydCBtZW1vcnktYWxsb2NhdGlvbiB3aXRoDQo+IGJ5dGVzLWFsaWdu
bWVudCB0byBnZW5hbGxvYw0KPiANCj4gT24gVHVlLCAyMDE1LTA5LTAxIGF0IDIxOjEwIC0wNTAw
LCBaaGFvIFFpYW5nLUI0NTQ3NSB3cm90ZToNCj4gPiBPbiBXZWQsIDIwMTUtMDktMDIgYXQgMDg6
MzhBTSArMDgwMCwgV29vZCBTY290dC1CMDc0MjEgd3JvdGU6DQo+ID4gPiAtLS0tLU9yaWdpbmFs
IE1lc3NhZ2UtLS0tLQ0KPiA+ID4gRnJvbTogV29vZCBTY290dC1CMDc0MjENCj4gPiA+IFNlbnQ6
IFdlZG5lc2RheSwgU2VwdGVtYmVyIDAyLCAyMDE1IDg6MzAgQU0NCj4gPiA+IFRvOiBaaGFvIFFp
YW5nLUI0NTQ3NQ0KPiA+ID4gQ2M6IGxpbnV4LWtlcm5lbEB2Z2VyLmtlcm5lbC5vcmc7IGxpbnV4
cHBjLWRldkBsaXN0cy5vemxhYnMub3JnOw0KPiA+ID4gbGF1cmFhQGNvZGVhdXJvcmEub3JnOyBY
aWUgWGlhb2JvLVI2MzA2MTsgYmVuaEBrZXJuZWwuY3Jhc2hpbmcub3JnOw0KPiA+ID4gTGkgWWFu
Zy1MZW8tUjU4NDcyOyBwYXVsdXNAc2FtYmEub3JnDQo+ID4gPiBTdWJqZWN0OiBSZTogW1BBVENI
IFY3IDEvM10gZ2VuYWxsb2M6c3VwcG9ydCBtZW1vcnktYWxsb2NhdGlvbiB3aXRoDQo+ID4gPiBi
eXRlcy1hbGlnbm1lbnQgdG8gZ2VuYWxsb2MNCj4gPiA+DQo+ID4gPiBPbiBNb24sIDIwMTUtMDgt
MzEgYXQgMTY6NTggKzA4MDAsIFpoYW8gUWlhbmcgd3JvdGU6DQo+ID4gPiA+IEJ5dGVzIGFsaWdu
bWVudCBpcyByZXF1aXJlZCB0byBtYW5hZ2Ugc29tZSBzcGVjaWFsIFJBTSwgc28gYWRkDQo+ID4g
PiA+IGdlbl9wb29sX2ZpcnN0X2ZpdF9hbGlnbiB0byBnZW5hbGxvYywgbWVhbndoaWxlIGFkZA0K
PiA+ID4gPiBnZW5fcG9vbF9hbGxvY19kYXRhIHRvIHBhc3MgZGF0YSB0bw0KPiA+ID4gPiBnZW5f
cG9vbF9maXJzdF9maXRfYWxpZ24obW9kaWZ5IGdlbl9wb29sX2FsbG9jIGFzIGEgd3JhcHBlcikN
Cj4gPiA+ID4NCj4gPiA+ID4gU2lnbmVkLW9mZi1ieTogWmhhbyBRaWFuZyA8cWlhbmcuemhhb0Bm
cmVlc2NhbGUuY29tPg0KPiA+ID4gPiAtLS0NCj4gPiA+ID4gQ2hhbmdlcyBmb3IgdjY6DQo+ID4g
PiA+ICAgICAgIC0gcGF0Y2hlcyBzZXQgdjYgaW5jbHVkZSBhIG5ldyBwYXRjaCBiZWNhdXNlIG9m
IHVzaW5nDQo+ID4gPiA+ICAgICAgIC0gZ2VuYWxsb2MgdG8gbWFuYWdlIFFFIE1VUkFNLCBwYXRj
aCAwMDAxIGlzIHRoZSBuZXcNCj4gPiA+ID4gICAgICAgLSBwYXRjaCwgYWRkaW5nIGJ5dGVzIGFs
aWdubWVudCBmb3IgYWxsb2NhdGlvbiBmb3IgdXNlLg0KPiA+ID4gPiBDaGFuZ2VzIGZvciB2NzoN
Cj4gPiA+ID4gICAgICAgLSBjcG0gbXVyYW0gYWxzbyBuZWVkIHRvIHVzZSBnZW5hbGxvYyB0byBt
YW5hZ2UsIGl0IGhhcw0KPiA+ID4gPiAgICAgICAgIGEgZnVuY3Rpb24gdG8gcmVzZXJ2ZSBhIHNw
ZWNpZmljIHJlZ2lvbiBvZiBtdXJhbSwNCj4gPiA+ID4gICAgICAgICBhZGQgb2Zmc2V0IHRvIGdl
bnBvb2xfZGF0YSBmb3Igc3RhcnQgYWRkciB0byBiZSBhbGxvY2F0ZWQuDQo+ID4gPg0KPiA+ID4g
VGhpcyBzZWVtcyB0byBiZSBkZXNjcmliaW5nIG1vcmUgdGhhbiBqdXN0IHRoZSBjaGFuZ2VzIGlu
IHRoaXMgcGF0Y2guDQo+ID4gPiBXaGF0IGRvZXMgYWxzbyBoYW5kbGluZyBjcG0gaGF2ZSB0byBk
byB3aXRoIHRoaXMgcGF0Y2g/ICBBcmUgeW91DQo+ID4gPiBhZGRpbmcgc3VwcG9ydCBmb3IgcmVz
ZXJ2aW5nIGEgc3BlY2lmaWMgcmVnaW9uIGluIHRoaXMgcGF0Y2g/ICBJDQo+ID4gPiBkb24ndCBz
ZWUgaXQsIGFuZCBpbiBhbnkgY2FzZSBpdCBzaG91bGQgZ28gaW4gYSBkaWZmZXJlbnQgcGF0Y2gu
DQo+ID4NCj4gPiBZZXMsIEkgYWRkZWQuIFRoZSBjb2RlIGJlbG93IGNhbiBzdXBwb3J0IHRoZSBm
dW5jdGlvbi4NCj4gPiAgICAgICBvZmZzZXRfYml0ID0gKGFsaWdubWVudC0+b2Zmc2V0ICsgKDFV
TCA8PCBvcmRlcikgLSAxKSA+PiBvcmRlcjsNCj4gPiAgICAgICByZXR1cm4gYml0bWFwX2ZpbmRf
bmV4dF96ZXJvX2FyZWEobWFwLCBzaXplLCBzdGFydCArIG9mZnNldF9iaXQsDQo+IG5yLA0KPiA+
ICAgICAgICAgICAgICAgICAgICAgICAgIGFsaWduX21hc2spOw0KPiA+DQo+ID4gQ1BNIGhhcyBh
biBmdW5jdGlvbiBjcG1fbXVyYW1fYWxsb2NfZml4ZWQsIG5lZWRpbmcgdG8gYWxsb2NhdGUgbXVy
YW0NCj4gPiBmcm9tIGEgU3BlY2lmaWMgb2Zmc2V0LiBTbyBJIGFkZCB0aGUgY29kZSBhbmQgYWRk
IG9mZnNldCB0byBzdHJ1Y3QgZGF0YS4NCj4gDQo+IEkgdGhvdWdodCB0aGUgb2Zmc2V0IHdhcyBy
ZWxhdGVkIHRvIHRoZSBwcmV2aW91cyBkaXNjdXNzaW9uIG9mIGNoZWNraW5nDQo+IGZvciBhbGxv
Y2F0aW9uIGZhaWx1cmUuICBBcmUgeW91IHVzaW5nIGl0IHRvIGltcGxlbWVudCBhbGxvY19maXhl
ZCgpPyAgSWYNCj4gc28sIHBsZWFzZSBkb24ndC4gIEJlc2lkZXMgdGhlIGF3a3dhcmQgaW1wbGVt
ZW50YXRpb24gKHdoYXQgZG9lcyBpdA0KPiBsb2dpY2FsbHkgaGF2ZSB0byBkbyB3aXRoIGdlbl9w
b29sX2ZpcnN0X2ZpdF9hbGlnbj8pLCBpdCBkb2VzIG5vdCBhcHBlYXINCj4gdG8gYmUgY29ycmVj
dCAtDQo+IC0gd2hhdCBoYXBwZW5zIHdpdGggbXVsdGlwbGUgY2h1bmtzPyAgV2hhdCBoYXBwZW5z
IGlmIHBhcnQgb2YgdGhlIHJlZ2lvbg0KPiB0aGUgY2FsbGVyIGlzIHRyeWluZyB0byByZXNlcnZl
IGlzIGFscmVhZHkgdGFrZW4/ICBJbXBsZW1lbnQgYSBwcm9wZXINCj4gZnVuY3Rpb24gdG8gcmVz
ZXJ2ZSBhIGZpeGVkIGdlbmFsbG9jIHJlZ2lvbi4NCg0KVGhpcyBvZmZzZXQgaXMgdG90YWxseSBk
aWZmZXJlbnQgd2l0aCB0aGUgd29ya2Fyb3VuZCBPRkZTRVQhDQpUaGlzIG9mZnNldCBpcyB0aGUg
b2Zmc2V0IG9mIHRoZSBtdXJhbS4NCkNQTSBuZWVkIHRvIGFsbG9jYXRlIGJsb2NrIGZyb20gYSBz
cGVjaWZpYyBvZmZzZXQgZHVlIHRvIGhhcmR3YXJlIHJlc3RyaWN0aW9uLg0KU28gSSBtdXN0IGhh
bmRsZSB0aGlzIG9mZnNldCBpbiBnZW5hbGxvYy4gDQoNCj4gDQo+ID4gVGhpcyBwYXRjaCBpcyB0
aGUgZmlyc3QgcGF0Y2ggb2YgdGhpcyBwYXRjaCBzZXQsIHNvIEkgZXhwbGFpbiB3aGF0DQo+ID4g
Y2hhbmdlcyBhYm91dCBTZXQgdjcgYW5kIHdoeSBJIGFkZCBzdXBwb3J0IGZvciByZXNlcnZpbmcg
YSBzcGVjaWZpYw0KPiA+IHJlZ2lvbiBpbiB0aGlzIHBhdGNoLg0KPiANCj4gSWYgeW91IHdhbnQg
dG8gcHJvdmlkZSBjb21tZW50YXJ5IHRoYXQgY292ZXJzIHRoZSBlbnRpcmUgcGF0Y2hzZXQsIHVz
ZSBhDQo+IGNvdmVyIGxldHRlci4NCj4gDQo+ID4gPiA+ICsvKg0KPiA+ID4gPiArICogIGdlbl9w
b29sIGRhdGEgZGVzY3JpcHRvciBmb3IgZ2VuX3Bvb2xfZmlyc3RfZml0X2FsaWduLg0KPiA+ID4g
PiArICovDQo+ID4gPiA+ICtzdHJ1Y3QgZ2VucG9vbF9kYXRhX2FsaWduIHsNCj4gPiA+ID4gKyAg
ICAgaW50IGFsaWduOyAgICAgICAgICAgICAgLyogYWxpZ25tZW50IGJ5IGJ5dGVzIGZvciBzdGFy
dGluZw0KPiA+ID4gYWRkcmVzcyAqLw0KPiA+ID4gPiArICAgICB1bnNpZ25lZCBsb25nIG9mZnNl
dDsgICAvKiB0aGUgb2Zmc2V0IG9mIGFsbG9jYXRpb24gc3RhcnQNCj4gYWRkciovDQo+ID4gPiA+
ICt9Ow0KPiA+ID4NCj4gPiA+IFRoZSBvZmZzZXQgYmVsb25ncyBvbiB0aGUgY2FsbGVyIHNpZGUs
IG5vdCBoZXJlLg0KPiA+DQo+ID4gU28sIGhvdyBkbyBJIHBhc3Mgb2Zmc2V0IHRvIGdlbl9wb29s
X2FsbG9jX2RhdGEgb3IgcG9vbC0+YWxnbz8NCj4gDQo+IFlvdSBkb24ndC4NCj4gDQo+IC1TY290
dA0KPiANCg0K

^ permalink raw reply	[flat|nested] 42+ messages in thread

* Re: [PATCH V7 2/3] qe_common: add qe_muram_ functions to manage muram
  2015-09-02  2:22       ` Zhao Qiang
  (?)
@ 2015-09-02  2:30       ` Scott Wood
  2015-09-02  2:32           ` Zhao Qiang
  -1 siblings, 1 reply; 42+ messages in thread
From: Scott Wood @ 2015-09-02  2:30 UTC (permalink / raw)
  To: Zhao Qiang-B45475
  Cc: linux-kernel, linuxppc-dev, lauraa, Xie Xiaobo-R63061, benh,
	Li Yang-Leo-R58472, paulus

On Tue, 2015-09-01 at 21:22 -0500, Zhao Qiang-B45475 wrote:
> On Wed, 2015-09-02 at 8:34AM +0800, Wood Scott-B07421 wrote:
> > -----Original Message-----
> > From: Wood Scott-B07421
> > Sent: Wednesday, September 02, 2015 8:34 AM
> > To: Zhao Qiang-B45475
> > Cc: linux-kernel@vger.kernel.org; linuxppc-dev@lists.ozlabs.org;
> > lauraa@codeaurora.org; Xie Xiaobo-R63061; benh@kernel.crashing.org; Li
> > Yang-Leo-R58472; paulus@samba.org
> > Subject: Re: [PATCH V7 2/3] qe_common: add qe_muram_ functions to manage
> > muram
> > 
> > On Mon, 2015-08-31 at 16:58 +0800, Zhao Qiang wrote:
> > 
> > > -int cpm_muram_init(void)
> > > -{
> > > -     struct device_node *np;
> > > -     struct resource r;
> > > -     u32 zero[OF_MAX_ADDR_CELLS] = {};
> > > -     resource_size_t max = 0;
> > > -     int i = 0;
> > > -     int ret = 0;
> > > -
> > > -     if (muram_pbase)
> > > -             return 0;
> > > -
> > > -     spin_lock_init(&cpm_muram_lock);
> > > -     /* initialize the info header */
> > > -     rh_init(&cpm_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");
> > > -                     ret = -ENODEV;
> > > -                     goto out;
> > > -             }
> > > -     }
> > > -
> > > -     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");
> > > -             ret = -ENODEV;
> > > -             goto out;
> > > -     }
> > 
> > Did you pass -M -C to git format-patch?
> 
> 
> Yes!

Then maybe it's the qe/cpm rename churn, or similar, that prevented it from 
being identified as a move?

-Scott


^ permalink raw reply	[flat|nested] 42+ messages in thread

* RE: [PATCH V7 2/3] qe_common: add qe_muram_ functions to manage muram
  2015-09-02  2:30       ` Scott Wood
@ 2015-09-02  2:32           ` Zhao Qiang
  0 siblings, 0 replies; 42+ messages in thread
From: Zhao Qiang @ 2015-09-02  2:32 UTC (permalink / raw)
  To: Scott Wood
  Cc: linux-kernel, linuxppc-dev, lauraa, Xiaobo Xie, benh, Li Leo, paulus

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="utf-8", Size: 2854 bytes --]

On Wed, 2015-09-02 at 10:31AM, Wood Scott-B07421 wrote:
> -----Original Message-----
> From: Wood Scott-B07421
> Sent: Wednesday, September 02, 2015 10:31 AM
> To: Zhao Qiang-B45475
> Cc: linux-kernel@vger.kernel.org; linuxppc-dev@lists.ozlabs.org;
> lauraa@codeaurora.org; Xie Xiaobo-R63061; benh@kernel.crashing.org; Li
> Yang-Leo-R58472; paulus@samba.org
> Subject: Re: [PATCH V7 2/3] qe_common: add qe_muram_ functions to manage
> muram
> 
> On Tue, 2015-09-01 at 21:22 -0500, Zhao Qiang-B45475 wrote:
> > On Wed, 2015-09-02 at 8:34AM +0800, Wood Scott-B07421 wrote:
> > > -----Original Message-----
> > > From: Wood Scott-B07421
> > > Sent: Wednesday, September 02, 2015 8:34 AM
> > > To: Zhao Qiang-B45475
> > > Cc: linux-kernel@vger.kernel.org; linuxppc-dev@lists.ozlabs.org;
> > > lauraa@codeaurora.org; Xie Xiaobo-R63061; benh@kernel.crashing.org;
> > > Li Yang-Leo-R58472; paulus@samba.org
> > > Subject: Re: [PATCH V7 2/3] qe_common: add qe_muram_ functions to
> > > manage muram
> > >
> > > On Mon, 2015-08-31 at 16:58 +0800, Zhao Qiang wrote:
> > >
> > > > -int cpm_muram_init(void)
> > > > -{
> > > > -     struct device_node *np;
> > > > -     struct resource r;
> > > > -     u32 zero[OF_MAX_ADDR_CELLS] = {};
> > > > -     resource_size_t max = 0;
> > > > -     int i = 0;
> > > > -     int ret = 0;
> > > > -
> > > > -     if (muram_pbase)
> > > > -             return 0;
> > > > -
> > > > -     spin_lock_init(&cpm_muram_lock);
> > > > -     /* initialize the info header */
> > > > -     rh_init(&cpm_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");
> > > > -                     ret = -ENODEV;
> > > > -                     goto out;
> > > > -             }
> > > > -     }
> > > > -
> > > > -     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");
> > > > -             ret = -ENODEV;
> > > > -             goto out;
> > > > -     }
> > >
> > > Did you pass -M -C to git format-patch?
> >
> >
> > Yes!
> 
> Then maybe it's the qe/cpm rename churn, or similar, that prevented it
> from being identified as a move?

Maybe

> 
> -Scott
-Zhao

ÿôèº{.nÇ+‰·Ÿ®‰­†+%ŠËÿ±éݶ\x17¥Šwÿº{.nÇ+‰·¥Š{±þG«éÿŠ{ayº\x1dʇڙë,j\a­¢f£¢·hšïêÿ‘êçz_è®\x03(­éšŽŠÝ¢j"ú\x1a¶^[m§ÿÿ¾\a«þG«éÿ¢¸?™¨è­Ú&£ø§~á¶iO•æ¬z·švØ^\x14\x04\x1a¶^[m§ÿÿÃ\fÿ¶ìÿ¢¸?–I¥

^ permalink raw reply	[flat|nested] 42+ messages in thread

* RE: [PATCH V7 2/3] qe_common: add qe_muram_ functions to manage muram
@ 2015-09-02  2:32           ` Zhao Qiang
  0 siblings, 0 replies; 42+ messages in thread
From: Zhao Qiang @ 2015-09-02  2:32 UTC (permalink / raw)
  To: Scott Wood
  Cc: linux-kernel, linuxppc-dev, lauraa, Xiaobo Xie, benh, Li Leo, paulus

T24gV2VkLCAyMDE1LTA5LTAyIGF0IDEwOjMxQU0sIFdvb2QgU2NvdHQtQjA3NDIxIHdyb3RlOg0K
PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBXb29kIFNjb3R0LUIwNzQyMQ0K
PiBTZW50OiBXZWRuZXNkYXksIFNlcHRlbWJlciAwMiwgMjAxNSAxMDozMSBBTQ0KPiBUbzogWmhh
byBRaWFuZy1CNDU0NzUNCj4gQ2M6IGxpbnV4LWtlcm5lbEB2Z2VyLmtlcm5lbC5vcmc7IGxpbnV4
cHBjLWRldkBsaXN0cy5vemxhYnMub3JnOw0KPiBsYXVyYWFAY29kZWF1cm9yYS5vcmc7IFhpZSBY
aWFvYm8tUjYzMDYxOyBiZW5oQGtlcm5lbC5jcmFzaGluZy5vcmc7IExpDQo+IFlhbmctTGVvLVI1
ODQ3MjsgcGF1bHVzQHNhbWJhLm9yZw0KPiBTdWJqZWN0OiBSZTogW1BBVENIIFY3IDIvM10gcWVf
Y29tbW9uOiBhZGQgcWVfbXVyYW1fIGZ1bmN0aW9ucyB0byBtYW5hZ2UNCj4gbXVyYW0NCj4gDQo+
IE9uIFR1ZSwgMjAxNS0wOS0wMSBhdCAyMToyMiAtMDUwMCwgWmhhbyBRaWFuZy1CNDU0NzUgd3Jv
dGU6DQo+ID4gT24gV2VkLCAyMDE1LTA5LTAyIGF0IDg6MzRBTSArMDgwMCwgV29vZCBTY290dC1C
MDc0MjEgd3JvdGU6DQo+ID4gPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+ID4gRnJv
bTogV29vZCBTY290dC1CMDc0MjENCj4gPiA+IFNlbnQ6IFdlZG5lc2RheSwgU2VwdGVtYmVyIDAy
LCAyMDE1IDg6MzQgQU0NCj4gPiA+IFRvOiBaaGFvIFFpYW5nLUI0NTQ3NQ0KPiA+ID4gQ2M6IGxp
bnV4LWtlcm5lbEB2Z2VyLmtlcm5lbC5vcmc7IGxpbnV4cHBjLWRldkBsaXN0cy5vemxhYnMub3Jn
Ow0KPiA+ID4gbGF1cmFhQGNvZGVhdXJvcmEub3JnOyBYaWUgWGlhb2JvLVI2MzA2MTsgYmVuaEBr
ZXJuZWwuY3Jhc2hpbmcub3JnOw0KPiA+ID4gTGkgWWFuZy1MZW8tUjU4NDcyOyBwYXVsdXNAc2Ft
YmEub3JnDQo+ID4gPiBTdWJqZWN0OiBSZTogW1BBVENIIFY3IDIvM10gcWVfY29tbW9uOiBhZGQg
cWVfbXVyYW1fIGZ1bmN0aW9ucyB0bw0KPiA+ID4gbWFuYWdlIG11cmFtDQo+ID4gPg0KPiA+ID4g
T24gTW9uLCAyMDE1LTA4LTMxIGF0IDE2OjU4ICswODAwLCBaaGFvIFFpYW5nIHdyb3RlOg0KPiA+
ID4NCj4gPiA+ID4gLWludCBjcG1fbXVyYW1faW5pdCh2b2lkKQ0KPiA+ID4gPiAtew0KPiA+ID4g
PiAtICAgICBzdHJ1Y3QgZGV2aWNlX25vZGUgKm5wOw0KPiA+ID4gPiAtICAgICBzdHJ1Y3QgcmVz
b3VyY2UgcjsNCj4gPiA+ID4gLSAgICAgdTMyIHplcm9bT0ZfTUFYX0FERFJfQ0VMTFNdID0ge307
DQo+ID4gPiA+IC0gICAgIHJlc291cmNlX3NpemVfdCBtYXggPSAwOw0KPiA+ID4gPiAtICAgICBp
bnQgaSA9IDA7DQo+ID4gPiA+IC0gICAgIGludCByZXQgPSAwOw0KPiA+ID4gPiAtDQo+ID4gPiA+
IC0gICAgIGlmIChtdXJhbV9wYmFzZSkNCj4gPiA+ID4gLSAgICAgICAgICAgICByZXR1cm4gMDsN
Cj4gPiA+ID4gLQ0KPiA+ID4gPiAtICAgICBzcGluX2xvY2tfaW5pdCgmY3BtX211cmFtX2xvY2sp
Ow0KPiA+ID4gPiAtICAgICAvKiBpbml0aWFsaXplIHRoZSBpbmZvIGhlYWRlciAqLw0KPiA+ID4g
PiAtICAgICByaF9pbml0KCZjcG1fbXVyYW1faW5mbywgMSwNCj4gPiA+ID4gLSAgICAgICAgICAg
ICBzaXplb2YoY3BtX2Jvb3RfbXVyYW1fcmhfYmxvY2spIC8NCj4gPiA+ID4gLSAgICAgICAgICAg
ICBzaXplb2YoY3BtX2Jvb3RfbXVyYW1fcmhfYmxvY2tbMF0pLA0KPiA+ID4gPiAtICAgICAgICAg
ICAgIGNwbV9ib290X211cmFtX3JoX2Jsb2NrKTsNCj4gPiA+ID4gLQ0KPiA+ID4gPiAtICAgICBu
cCA9IG9mX2ZpbmRfY29tcGF0aWJsZV9ub2RlKE5VTEwsIE5VTEwsICJmc2wsY3BtLW11cmFtLQ0K
PiBkYXRhIik7DQo+ID4gPiA+IC0gICAgIGlmICghbnApIHsNCj4gPiA+ID4gLSAgICAgICAgICAg
ICAvKiB0cnkgbGVnYWN5IGJpbmRpbmdzICovDQo+ID4gPiA+IC0gICAgICAgICAgICAgbnAgPSBv
Zl9maW5kX25vZGVfYnlfbmFtZShOVUxMLCAiZGF0YS1vbmx5Iik7DQo+ID4gPiA+IC0gICAgICAg
ICAgICAgaWYgKCFucCkgew0KPiA+ID4gPiAtICAgICAgICAgICAgICAgICAgICAgcHJpbnRrKEtF
Uk5fRVJSICJDYW5ub3QgZmluZCBDUE0gbXVyYW0gZGF0YQ0KPiA+ID4gbm9kZSIpOw0KPiA+ID4g
PiAtICAgICAgICAgICAgICAgICAgICAgcmV0ID0gLUVOT0RFVjsNCj4gPiA+ID4gLSAgICAgICAg
ICAgICAgICAgICAgIGdvdG8gb3V0Ow0KPiA+ID4gPiAtICAgICAgICAgICAgIH0NCj4gPiA+ID4g
LSAgICAgfQ0KPiA+ID4gPiAtDQo+ID4gPiA+IC0gICAgIG11cmFtX3BiYXNlID0gb2ZfdHJhbnNs
YXRlX2FkZHJlc3MobnAsIHplcm8pOw0KPiA+ID4gPiAtICAgICBpZiAobXVyYW1fcGJhc2UgPT0g
KHBoeXNfYWRkcl90KU9GX0JBRF9BRERSKSB7DQo+ID4gPiA+IC0gICAgICAgICAgICAgcHJpbnRr
KEtFUk5fRVJSICJDYW5ub3QgdHJhbnNsYXRlIHplcm8gdGhyb3VnaCBDUE0NCj4gbXVyYW0NCj4g
PiA+IG5vZGUiKTsNCj4gPiA+ID4gLSAgICAgICAgICAgICByZXQgPSAtRU5PREVWOw0KPiA+ID4g
PiAtICAgICAgICAgICAgIGdvdG8gb3V0Ow0KPiA+ID4gPiAtICAgICB9DQo+ID4gPg0KPiA+ID4g
RGlkIHlvdSBwYXNzIC1NIC1DIHRvIGdpdCBmb3JtYXQtcGF0Y2g/DQo+ID4NCj4gPg0KPiA+IFll
cyENCj4gDQo+IFRoZW4gbWF5YmUgaXQncyB0aGUgcWUvY3BtIHJlbmFtZSBjaHVybiwgb3Igc2lt
aWxhciwgdGhhdCBwcmV2ZW50ZWQgaXQNCj4gZnJvbSBiZWluZyBpZGVudGlmaWVkIGFzIGEgbW92
ZT8NCg0KTWF5YmUNCg0KPiANCj4gLVNjb3R0DQotWmhhbw0KDQo=

^ permalink raw reply	[flat|nested] 42+ messages in thread

* Re: [PATCH V7 1/3] genalloc:support memory-allocation with bytes-alignment to genalloc
  2015-09-02  2:29         ` Zhao Qiang
  (?)
@ 2015-09-02  2:33         ` Scott Wood
  2015-09-02  3:05             ` Zhao Qiang
  -1 siblings, 1 reply; 42+ messages in thread
From: Scott Wood @ 2015-09-02  2:33 UTC (permalink / raw)
  To: Zhao Qiang-B45475
  Cc: linux-kernel, linuxppc-dev, lauraa, Xie Xiaobo-R63061, benh,
	Li Yang-Leo-R58472, paulus

On Tue, 2015-09-01 at 21:29 -0500, Zhao Qiang-B45475 wrote:
> On Wed, 2015-09-02 at 10:18AM -0500, Wood Scott-B07421 wrote:
> > -----Original Message-----
> > From: Wood Scott-B07421
> > Sent: Wednesday, September 02, 2015 10:18 AM
> > To: Zhao Qiang-B45475
> > Cc: linux-kernel@vger.kernel.org; linuxppc-dev@lists.ozlabs.org;
> > lauraa@codeaurora.org; Xie Xiaobo-R63061; benh@kernel.crashing.org; Li
> > Yang-Leo-R58472; paulus@samba.org
> > Subject: Re: [PATCH V7 1/3] genalloc:support memory-allocation with
> > bytes-alignment to genalloc
> > 
> > On Tue, 2015-09-01 at 21:10 -0500, Zhao Qiang-B45475 wrote:
> > > On Wed, 2015-09-02 at 08:38AM +0800, Wood Scott-B07421 wrote:
> > > > -----Original Message-----
> > > > From: Wood Scott-B07421
> > > > Sent: Wednesday, September 02, 2015 8:30 AM
> > > > To: Zhao Qiang-B45475
> > > > Cc: linux-kernel@vger.kernel.org; linuxppc-dev@lists.ozlabs.org;
> > > > lauraa@codeaurora.org; Xie Xiaobo-R63061; benh@kernel.crashing.org;
> > > > Li Yang-Leo-R58472; paulus@samba.org
> > > > Subject: Re: [PATCH V7 1/3] genalloc:support memory-allocation with
> > > > bytes-alignment to genalloc
> > > > 
> > > > On Mon, 2015-08-31 at 16:58 +0800, Zhao Qiang wrote:
> > > > > 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 <qiang.zhao@freescale.com>
> > > > > ---
> > > > > 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.
> > > > 
> > > > This seems to be describing more than just the changes in this patch.
> > > > What does also handling cpm have to do with this patch?  Are you
> > > > adding support for reserving a specific region in this patch?  I
> > > > don't see it, and in any case it should go in a different patch.
> > > 
> > > Yes, I added. The code below can support the function.
> > >       offset_bit = (alignment->offset + (1UL << order) - 1) >> order;
> > >       return bitmap_find_next_zero_area(map, size, start + offset_bit,
> > nr,
> > >                         align_mask);
> > > 
> > > CPM has an function cpm_muram_alloc_fixed, needing to allocate muram
> > > from a Specific offset. So I add the code and add offset to struct data.
> > 
> > I thought the offset was related to the previous discussion of checking
> > for allocation failure.  Are you using it to implement alloc_fixed()?  If
> > so, please don't.  Besides the awkward implementation (what does it
> > logically have to do with gen_pool_first_fit_align?), it does not appear
> > to be correct -
> > - what happens with multiple chunks?  What happens if part of the region
> > the caller is trying to reserve is already taken?  Implement a proper
> > function to reserve a fixed genalloc region.
> 
> This offset is totally different with the workaround OFFSET!

There's a reason why we write changelogs that describe what the patch is 
doing, and avoid combining logically distinct changes in the same patch.

> This offset is the offset of the muram.

The offset of the muram relative to what?  Or do you mean the offset into 
muram?

> CPM need to allocate block from a specific offset due to hardware 
> restriction.
> So I must handle this offset in genalloc. 

Again, if you need to be able to mark a specific range reserved, add a 
function that does that properly.  Don't try to hack it in the way you did.

-Scott


^ permalink raw reply	[flat|nested] 42+ messages in thread

* RE: [PATCH V7 1/3] genalloc:support memory-allocation with bytes-alignment to genalloc
  2015-09-02  2:33         ` Scott Wood
@ 2015-09-02  3:05             ` Zhao Qiang
  0 siblings, 0 replies; 42+ messages in thread
From: Zhao Qiang @ 2015-09-02  3:05 UTC (permalink / raw)
  To: Scott Wood
  Cc: linux-kernel, linuxppc-dev, lauraa, Xiaobo Xie, benh, Li Leo, paulus

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="utf-8", Size: 4929 bytes --]

On Wed, 2015-09-02 at 10:33AM -0500, Wood Scott-B07421 wrote:

> -----Original Message-----
> From: Wood Scott-B07421
> Sent: Wednesday, September 02, 2015 10:33 AM
> To: Zhao Qiang-B45475
> Cc: linux-kernel@vger.kernel.org; linuxppc-dev@lists.ozlabs.org;
> lauraa@codeaurora.org; Xie Xiaobo-R63061; benh@kernel.crashing.org; Li
> Yang-Leo-R58472; paulus@samba.org
> Subject: Re: [PATCH V7 1/3] genalloc:support memory-allocation with
> bytes-alignment to genalloc
> 
> On Tue, 2015-09-01 at 21:29 -0500, Zhao Qiang-B45475 wrote:
> > On Wed, 2015-09-02 at 10:18AM -0500, Wood Scott-B07421 wrote:
> > > -----Original Message-----
> > > From: Wood Scott-B07421
> > > Sent: Wednesday, September 02, 2015 10:18 AM
> > > To: Zhao Qiang-B45475
> > > Cc: linux-kernel@vger.kernel.org; linuxppc-dev@lists.ozlabs.org;
> > > lauraa@codeaurora.org; Xie Xiaobo-R63061; benh@kernel.crashing.org;
> > > Li Yang-Leo-R58472; paulus@samba.org
> > > Subject: Re: [PATCH V7 1/3] genalloc:support memory-allocation with
> > > bytes-alignment to genalloc
> > >
> > > On Tue, 2015-09-01 at 21:10 -0500, Zhao Qiang-B45475 wrote:
> > > > On Wed, 2015-09-02 at 08:38AM +0800, Wood Scott-B07421 wrote:
> > > > > -----Original Message-----
> > > > > From: Wood Scott-B07421
> > > > > Sent: Wednesday, September 02, 2015 8:30 AM
> > > > > To: Zhao Qiang-B45475
> > > > > Cc: linux-kernel@vger.kernel.org; linuxppc-dev@lists.ozlabs.org;
> > > > > lauraa@codeaurora.org; Xie Xiaobo-R63061;
> > > > > benh@kernel.crashing.org; Li Yang-Leo-R58472; paulus@samba.org
> > > > > Subject: Re: [PATCH V7 1/3] genalloc:support memory-allocation
> > > > > with bytes-alignment to genalloc
> > > > >
> > > > > On Mon, 2015-08-31 at 16:58 +0800, Zhao Qiang wrote:
> > > > > > 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 <qiang.zhao@freescale.com>
> > > > > > ---
> > > > > > 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.
> > > > >
> > > > > This seems to be describing more than just the changes in this
> patch.
> > > > > What does also handling cpm have to do with this patch?  Are you
> > > > > adding support for reserving a specific region in this patch?  I
> > > > > don't see it, and in any case it should go in a different patch.
> > > >
> > > > Yes, I added. The code below can support the function.
> > > >       offset_bit = (alignment->offset + (1UL << order) - 1) >>
> order;
> > > >       return bitmap_find_next_zero_area(map, size, start +
> > > > offset_bit,
> > > nr,
> > > >                         align_mask);
> > > >
> > > > CPM has an function cpm_muram_alloc_fixed, needing to allocate
> > > > muram from a Specific offset. So I add the code and add offset to
> struct data.
> > >
> > > I thought the offset was related to the previous discussion of
> > > checking for allocation failure.  Are you using it to implement
> > > alloc_fixed()?  If so, please don't.  Besides the awkward
> > > implementation (what does it logically have to do with
> > > gen_pool_first_fit_align?), it does not appear to be correct -
> > > - what happens with multiple chunks?  What happens if part of the
> > > region the caller is trying to reserve is already taken?  Implement
> > > a proper function to reserve a fixed genalloc region.
> >
> > This offset is totally different with the workaround OFFSET!
> 
> There's a reason why we write changelogs that describe what the patch is
> doing, and avoid combining logically distinct changes in the same patch.
> 
> > This offset is the offset of the muram.
> 
> The offset of the muram relative to what?  Or do you mean the offset into
> muram?

Yes, the offset into muram.

> 
> > CPM need to allocate block from a specific offset due to hardware
> > restriction.
> > So I must handle this offset in genalloc.
> 
> Again, if you need to be able to mark a specific range reserved, add a
> function that does that properly.  Don't try to hack it in the way you
> did.

Add a function? Do you mean add a new alloc function or new algo?
If you mean new algo, CPM use both align algo and new algo, set 
Different algos in different muram_alloc func? 

> 
> -Scott

ÿôèº{.nÇ+‰·Ÿ®‰­†+%ŠËÿ±éݶ\x17¥Šwÿº{.nÇ+‰·¥Š{±þG«éÿŠ{ayº\x1dʇڙë,j\a­¢f£¢·hšïêÿ‘êçz_è®\x03(­éšŽŠÝ¢j"ú\x1a¶^[m§ÿÿ¾\a«þG«éÿ¢¸?™¨è­Ú&£ø§~á¶iO•æ¬z·švØ^\x14\x04\x1a¶^[m§ÿÿÃ\fÿ¶ìÿ¢¸?–I¥

^ permalink raw reply	[flat|nested] 42+ messages in thread

* RE: [PATCH V7 1/3] genalloc:support memory-allocation with bytes-alignment to genalloc
@ 2015-09-02  3:05             ` Zhao Qiang
  0 siblings, 0 replies; 42+ messages in thread
From: Zhao Qiang @ 2015-09-02  3:05 UTC (permalink / raw)
  To: Scott Wood
  Cc: linux-kernel, linuxppc-dev, lauraa, Xiaobo Xie, benh, Li Leo, paulus

T24gV2VkLCAyMDE1LTA5LTAyIGF0IDEwOjMzQU0gLTA1MDAsIFdvb2QgU2NvdHQtQjA3NDIxIHdy
b3RlOg0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IFdvb2QgU2NvdHQt
QjA3NDIxDQo+IFNlbnQ6IFdlZG5lc2RheSwgU2VwdGVtYmVyIDAyLCAyMDE1IDEwOjMzIEFNDQo+
IFRvOiBaaGFvIFFpYW5nLUI0NTQ3NQ0KPiBDYzogbGludXgta2VybmVsQHZnZXIua2VybmVsLm9y
ZzsgbGludXhwcGMtZGV2QGxpc3RzLm96bGFicy5vcmc7DQo+IGxhdXJhYUBjb2RlYXVyb3JhLm9y
ZzsgWGllIFhpYW9iby1SNjMwNjE7IGJlbmhAa2VybmVsLmNyYXNoaW5nLm9yZzsgTGkNCj4gWWFu
Zy1MZW8tUjU4NDcyOyBwYXVsdXNAc2FtYmEub3JnDQo+IFN1YmplY3Q6IFJlOiBbUEFUQ0ggVjcg
MS8zXSBnZW5hbGxvYzpzdXBwb3J0IG1lbW9yeS1hbGxvY2F0aW9uIHdpdGgNCj4gYnl0ZXMtYWxp
Z25tZW50IHRvIGdlbmFsbG9jDQo+IA0KPiBPbiBUdWUsIDIwMTUtMDktMDEgYXQgMjE6MjkgLTA1
MDAsIFpoYW8gUWlhbmctQjQ1NDc1IHdyb3RlOg0KPiA+IE9uIFdlZCwgMjAxNS0wOS0wMiBhdCAx
MDoxOEFNIC0wNTAwLCBXb29kIFNjb3R0LUIwNzQyMSB3cm90ZToNCj4gPiA+IC0tLS0tT3JpZ2lu
YWwgTWVzc2FnZS0tLS0tDQo+ID4gPiBGcm9tOiBXb29kIFNjb3R0LUIwNzQyMQ0KPiA+ID4gU2Vu
dDogV2VkbmVzZGF5LCBTZXB0ZW1iZXIgMDIsIDIwMTUgMTA6MTggQU0NCj4gPiA+IFRvOiBaaGFv
IFFpYW5nLUI0NTQ3NQ0KPiA+ID4gQ2M6IGxpbnV4LWtlcm5lbEB2Z2VyLmtlcm5lbC5vcmc7IGxp
bnV4cHBjLWRldkBsaXN0cy5vemxhYnMub3JnOw0KPiA+ID4gbGF1cmFhQGNvZGVhdXJvcmEub3Jn
OyBYaWUgWGlhb2JvLVI2MzA2MTsgYmVuaEBrZXJuZWwuY3Jhc2hpbmcub3JnOw0KPiA+ID4gTGkg
WWFuZy1MZW8tUjU4NDcyOyBwYXVsdXNAc2FtYmEub3JnDQo+ID4gPiBTdWJqZWN0OiBSZTogW1BB
VENIIFY3IDEvM10gZ2VuYWxsb2M6c3VwcG9ydCBtZW1vcnktYWxsb2NhdGlvbiB3aXRoDQo+ID4g
PiBieXRlcy1hbGlnbm1lbnQgdG8gZ2VuYWxsb2MNCj4gPiA+DQo+ID4gPiBPbiBUdWUsIDIwMTUt
MDktMDEgYXQgMjE6MTAgLTA1MDAsIFpoYW8gUWlhbmctQjQ1NDc1IHdyb3RlOg0KPiA+ID4gPiBP
biBXZWQsIDIwMTUtMDktMDIgYXQgMDg6MzhBTSArMDgwMCwgV29vZCBTY290dC1CMDc0MjEgd3Jv
dGU6DQo+ID4gPiA+ID4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPiA+ID4gPiBGcm9t
OiBXb29kIFNjb3R0LUIwNzQyMQ0KPiA+ID4gPiA+IFNlbnQ6IFdlZG5lc2RheSwgU2VwdGVtYmVy
IDAyLCAyMDE1IDg6MzAgQU0NCj4gPiA+ID4gPiBUbzogWmhhbyBRaWFuZy1CNDU0NzUNCj4gPiA+
ID4gPiBDYzogbGludXgta2VybmVsQHZnZXIua2VybmVsLm9yZzsgbGludXhwcGMtZGV2QGxpc3Rz
Lm96bGFicy5vcmc7DQo+ID4gPiA+ID4gbGF1cmFhQGNvZGVhdXJvcmEub3JnOyBYaWUgWGlhb2Jv
LVI2MzA2MTsNCj4gPiA+ID4gPiBiZW5oQGtlcm5lbC5jcmFzaGluZy5vcmc7IExpIFlhbmctTGVv
LVI1ODQ3MjsgcGF1bHVzQHNhbWJhLm9yZw0KPiA+ID4gPiA+IFN1YmplY3Q6IFJlOiBbUEFUQ0gg
VjcgMS8zXSBnZW5hbGxvYzpzdXBwb3J0IG1lbW9yeS1hbGxvY2F0aW9uDQo+ID4gPiA+ID4gd2l0
aCBieXRlcy1hbGlnbm1lbnQgdG8gZ2VuYWxsb2MNCj4gPiA+ID4gPg0KPiA+ID4gPiA+IE9uIE1v
biwgMjAxNS0wOC0zMSBhdCAxNjo1OCArMDgwMCwgWmhhbyBRaWFuZyB3cm90ZToNCj4gPiA+ID4g
PiA+IEJ5dGVzIGFsaWdubWVudCBpcyByZXF1aXJlZCB0byBtYW5hZ2Ugc29tZSBzcGVjaWFsIFJB
TSwgc28gYWRkDQo+ID4gPiA+ID4gPiBnZW5fcG9vbF9maXJzdF9maXRfYWxpZ24gdG8gZ2VuYWxs
b2MsIG1lYW53aGlsZSBhZGQNCj4gPiA+ID4gPiA+IGdlbl9wb29sX2FsbG9jX2RhdGEgdG8gcGFz
cyBkYXRhIHRvDQo+ID4gPiA+ID4gPiBnZW5fcG9vbF9maXJzdF9maXRfYWxpZ24obW9kaWZ5IGdl
bl9wb29sX2FsbG9jIGFzIGEgd3JhcHBlcikNCj4gPiA+ID4gPiA+DQo+ID4gPiA+ID4gPiBTaWdu
ZWQtb2ZmLWJ5OiBaaGFvIFFpYW5nIDxxaWFuZy56aGFvQGZyZWVzY2FsZS5jb20+DQo+ID4gPiA+
ID4gPiAtLS0NCj4gPiA+ID4gPiA+IENoYW5nZXMgZm9yIHY2Og0KPiA+ID4gPiA+ID4gICAgICAg
LSBwYXRjaGVzIHNldCB2NiBpbmNsdWRlIGEgbmV3IHBhdGNoIGJlY2F1c2Ugb2YgdXNpbmcNCj4g
PiA+ID4gPiA+ICAgICAgIC0gZ2VuYWxsb2MgdG8gbWFuYWdlIFFFIE1VUkFNLCBwYXRjaCAwMDAx
IGlzIHRoZSBuZXcNCj4gPiA+ID4gPiA+ICAgICAgIC0gcGF0Y2gsIGFkZGluZyBieXRlcyBhbGln
bm1lbnQgZm9yIGFsbG9jYXRpb24gZm9yIHVzZS4NCj4gPiA+ID4gPiA+IENoYW5nZXMgZm9yIHY3
Og0KPiA+ID4gPiA+ID4gICAgICAgLSBjcG0gbXVyYW0gYWxzbyBuZWVkIHRvIHVzZSBnZW5hbGxv
YyB0byBtYW5hZ2UsIGl0IGhhcw0KPiA+ID4gPiA+ID4gICAgICAgICBhIGZ1bmN0aW9uIHRvIHJl
c2VydmUgYSBzcGVjaWZpYyByZWdpb24gb2YgbXVyYW0sDQo+ID4gPiA+ID4gPiAgICAgICAgIGFk
ZCBvZmZzZXQgdG8gZ2VucG9vbF9kYXRhIGZvciBzdGFydCBhZGRyIHRvIGJlDQo+IGFsbG9jYXRl
ZC4NCj4gPiA+ID4gPg0KPiA+ID4gPiA+IFRoaXMgc2VlbXMgdG8gYmUgZGVzY3JpYmluZyBtb3Jl
IHRoYW4ganVzdCB0aGUgY2hhbmdlcyBpbiB0aGlzDQo+IHBhdGNoLg0KPiA+ID4gPiA+IFdoYXQg
ZG9lcyBhbHNvIGhhbmRsaW5nIGNwbSBoYXZlIHRvIGRvIHdpdGggdGhpcyBwYXRjaD8gIEFyZSB5
b3UNCj4gPiA+ID4gPiBhZGRpbmcgc3VwcG9ydCBmb3IgcmVzZXJ2aW5nIGEgc3BlY2lmaWMgcmVn
aW9uIGluIHRoaXMgcGF0Y2g/ICBJDQo+ID4gPiA+ID4gZG9uJ3Qgc2VlIGl0LCBhbmQgaW4gYW55
IGNhc2UgaXQgc2hvdWxkIGdvIGluIGEgZGlmZmVyZW50IHBhdGNoLg0KPiA+ID4gPg0KPiA+ID4g
PiBZZXMsIEkgYWRkZWQuIFRoZSBjb2RlIGJlbG93IGNhbiBzdXBwb3J0IHRoZSBmdW5jdGlvbi4N
Cj4gPiA+ID4gICAgICAgb2Zmc2V0X2JpdCA9IChhbGlnbm1lbnQtPm9mZnNldCArICgxVUwgPDwg
b3JkZXIpIC0gMSkgPj4NCj4gb3JkZXI7DQo+ID4gPiA+ICAgICAgIHJldHVybiBiaXRtYXBfZmlu
ZF9uZXh0X3plcm9fYXJlYShtYXAsIHNpemUsIHN0YXJ0ICsNCj4gPiA+ID4gb2Zmc2V0X2JpdCwN
Cj4gPiA+IG5yLA0KPiA+ID4gPiAgICAgICAgICAgICAgICAgICAgICAgICBhbGlnbl9tYXNrKTsN
Cj4gPiA+ID4NCj4gPiA+ID4gQ1BNIGhhcyBhbiBmdW5jdGlvbiBjcG1fbXVyYW1fYWxsb2NfZml4
ZWQsIG5lZWRpbmcgdG8gYWxsb2NhdGUNCj4gPiA+ID4gbXVyYW0gZnJvbSBhIFNwZWNpZmljIG9m
ZnNldC4gU28gSSBhZGQgdGhlIGNvZGUgYW5kIGFkZCBvZmZzZXQgdG8NCj4gc3RydWN0IGRhdGEu
DQo+ID4gPg0KPiA+ID4gSSB0aG91Z2h0IHRoZSBvZmZzZXQgd2FzIHJlbGF0ZWQgdG8gdGhlIHBy
ZXZpb3VzIGRpc2N1c3Npb24gb2YNCj4gPiA+IGNoZWNraW5nIGZvciBhbGxvY2F0aW9uIGZhaWx1
cmUuICBBcmUgeW91IHVzaW5nIGl0IHRvIGltcGxlbWVudA0KPiA+ID4gYWxsb2NfZml4ZWQoKT8g
IElmIHNvLCBwbGVhc2UgZG9uJ3QuICBCZXNpZGVzIHRoZSBhd2t3YXJkDQo+ID4gPiBpbXBsZW1l
bnRhdGlvbiAod2hhdCBkb2VzIGl0IGxvZ2ljYWxseSBoYXZlIHRvIGRvIHdpdGgNCj4gPiA+IGdl
bl9wb29sX2ZpcnN0X2ZpdF9hbGlnbj8pLCBpdCBkb2VzIG5vdCBhcHBlYXIgdG8gYmUgY29ycmVj
dCAtDQo+ID4gPiAtIHdoYXQgaGFwcGVucyB3aXRoIG11bHRpcGxlIGNodW5rcz8gIFdoYXQgaGFw
cGVucyBpZiBwYXJ0IG9mIHRoZQ0KPiA+ID4gcmVnaW9uIHRoZSBjYWxsZXIgaXMgdHJ5aW5nIHRv
IHJlc2VydmUgaXMgYWxyZWFkeSB0YWtlbj8gIEltcGxlbWVudA0KPiA+ID4gYSBwcm9wZXIgZnVu
Y3Rpb24gdG8gcmVzZXJ2ZSBhIGZpeGVkIGdlbmFsbG9jIHJlZ2lvbi4NCj4gPg0KPiA+IFRoaXMg
b2Zmc2V0IGlzIHRvdGFsbHkgZGlmZmVyZW50IHdpdGggdGhlIHdvcmthcm91bmQgT0ZGU0VUIQ0K
PiANCj4gVGhlcmUncyBhIHJlYXNvbiB3aHkgd2Ugd3JpdGUgY2hhbmdlbG9ncyB0aGF0IGRlc2Ny
aWJlIHdoYXQgdGhlIHBhdGNoIGlzDQo+IGRvaW5nLCBhbmQgYXZvaWQgY29tYmluaW5nIGxvZ2lj
YWxseSBkaXN0aW5jdCBjaGFuZ2VzIGluIHRoZSBzYW1lIHBhdGNoLg0KPiANCj4gPiBUaGlzIG9m
ZnNldCBpcyB0aGUgb2Zmc2V0IG9mIHRoZSBtdXJhbS4NCj4gDQo+IFRoZSBvZmZzZXQgb2YgdGhl
IG11cmFtIHJlbGF0aXZlIHRvIHdoYXQ/ICBPciBkbyB5b3UgbWVhbiB0aGUgb2Zmc2V0IGludG8N
Cj4gbXVyYW0/DQoNClllcywgdGhlIG9mZnNldCBpbnRvIG11cmFtLg0KDQo+IA0KPiA+IENQTSBu
ZWVkIHRvIGFsbG9jYXRlIGJsb2NrIGZyb20gYSBzcGVjaWZpYyBvZmZzZXQgZHVlIHRvIGhhcmR3
YXJlDQo+ID4gcmVzdHJpY3Rpb24uDQo+ID4gU28gSSBtdXN0IGhhbmRsZSB0aGlzIG9mZnNldCBp
biBnZW5hbGxvYy4NCj4gDQo+IEFnYWluLCBpZiB5b3UgbmVlZCB0byBiZSBhYmxlIHRvIG1hcmsg
YSBzcGVjaWZpYyByYW5nZSByZXNlcnZlZCwgYWRkIGENCj4gZnVuY3Rpb24gdGhhdCBkb2VzIHRo
YXQgcHJvcGVybHkuICBEb24ndCB0cnkgdG8gaGFjayBpdCBpbiB0aGUgd2F5IHlvdQ0KPiBkaWQu
DQoNCkFkZCBhIGZ1bmN0aW9uPyBEbyB5b3UgbWVhbiBhZGQgYSBuZXcgYWxsb2MgZnVuY3Rpb24g
b3IgbmV3IGFsZ28/DQpJZiB5b3UgbWVhbiBuZXcgYWxnbywgQ1BNIHVzZSBib3RoIGFsaWduIGFs
Z28gYW5kIG5ldyBhbGdvLCBzZXQgDQpEaWZmZXJlbnQgYWxnb3MgaW4gZGlmZmVyZW50IG11cmFt
X2FsbG9jIGZ1bmM/IA0KDQo+IA0KPiAtU2NvdHQNCg0K

^ permalink raw reply	[flat|nested] 42+ messages in thread

* Re: [PATCH V7 1/3] genalloc:support memory-allocation with bytes-alignment to genalloc
  2015-09-02  3:05             ` Zhao Qiang
  (?)
@ 2015-09-02  3:08             ` Scott Wood
  2015-09-02  3:57                 ` Zhao Qiang
  -1 siblings, 1 reply; 42+ messages in thread
From: Scott Wood @ 2015-09-02  3:08 UTC (permalink / raw)
  To: Zhao Qiang-B45475
  Cc: linux-kernel, linuxppc-dev, lauraa, Xie Xiaobo-R63061, benh,
	Li Yang-Leo-R58472, paulus

On Tue, 2015-09-01 at 22:05 -0500, Zhao Qiang-B45475 wrote:
> On Wed, 2015-09-02 at 10:33AM -0500, Wood Scott-B07421 wrote:
> 
> > -----Original Message-----
> > From: Wood Scott-B07421
> > Sent: Wednesday, September 02, 2015 10:33 AM
> > To: Zhao Qiang-B45475
> > Cc: linux-kernel@vger.kernel.org; linuxppc-dev@lists.ozlabs.org;
> > lauraa@codeaurora.org; Xie Xiaobo-R63061; benh@kernel.crashing.org; Li
> > Yang-Leo-R58472; paulus@samba.org
> > Subject: Re: [PATCH V7 1/3] genalloc:support memory-allocation with
> > bytes-alignment to genalloc
> > 
> > On Tue, 2015-09-01 at 21:29 -0500, Zhao Qiang-B45475 wrote:
> > > On Wed, 2015-09-02 at 10:18AM -0500, Wood Scott-B07421 wrote:
> > > > -----Original Message-----
> > > > From: Wood Scott-B07421
> > > > Sent: Wednesday, September 02, 2015 10:18 AM
> > > > To: Zhao Qiang-B45475
> > > > Cc: linux-kernel@vger.kernel.org; linuxppc-dev@lists.ozlabs.org;
> > > > lauraa@codeaurora.org; Xie Xiaobo-R63061; benh@kernel.crashing.org;
> > > > Li Yang-Leo-R58472; paulus@samba.org
> > > > Subject: Re: [PATCH V7 1/3] genalloc:support memory-allocation with
> > > > bytes-alignment to genalloc
> > > > 
> > > > On Tue, 2015-09-01 at 21:10 -0500, Zhao Qiang-B45475 wrote:
> > > > > On Wed, 2015-09-02 at 08:38AM +0800, Wood Scott-B07421 wrote:
> > > > > > -----Original Message-----
> > > > > > From: Wood Scott-B07421
> > > > > > Sent: Wednesday, September 02, 2015 8:30 AM
> > > > > > To: Zhao Qiang-B45475
> > > > > > Cc: linux-kernel@vger.kernel.org; linuxppc-dev@lists.ozlabs.org;
> > > > > > lauraa@codeaurora.org; Xie Xiaobo-R63061;
> > > > > > benh@kernel.crashing.org; Li Yang-Leo-R58472; paulus@samba.org
> > > > > > Subject: Re: [PATCH V7 1/3] genalloc:support memory-allocation
> > > > > > with bytes-alignment to genalloc
> > > > > > 
> > > > > > On Mon, 2015-08-31 at 16:58 +0800, Zhao Qiang wrote:
> > > > > > > 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 <qiang.zhao@freescale.com>
> > > > > > > ---
> > > > > > > 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.
> > > > > > 
> > > > > > This seems to be describing more than just the changes in this
> > patch.
> > > > > > What does also handling cpm have to do with this patch?  Are you
> > > > > > adding support for reserving a specific region in this patch?  I
> > > > > > don't see it, and in any case it should go in a different patch.
> > > > > 
> > > > > Yes, I added. The code below can support the function.
> > > > >       offset_bit = (alignment->offset + (1UL << order) - 1) >>
> > order;
> > > > >       return bitmap_find_next_zero_area(map, size, start +
> > > > > offset_bit,
> > > > nr,
> > > > >                         align_mask);
> > > > > 
> > > > > CPM has an function cpm_muram_alloc_fixed, needing to allocate
> > > > > muram from a Specific offset. So I add the code and add offset to
> > struct data.
> > > > 
> > > > I thought the offset was related to the previous discussion of
> > > > checking for allocation failure.  Are you using it to implement
> > > > alloc_fixed()?  If so, please don't.  Besides the awkward
> > > > implementation (what does it logically have to do with
> > > > gen_pool_first_fit_align?), it does not appear to be correct -
> > > > - what happens with multiple chunks?  What happens if part of the
> > > > region the caller is trying to reserve is already taken?  Implement
> > > > a proper function to reserve a fixed genalloc region.
> > > 
> > > This offset is totally different with the workaround OFFSET!
> > 
> > There's a reason why we write changelogs that describe what the patch is
> > doing, and avoid combining logically distinct changes in the same patch.
> > 
> > > This offset is the offset of the muram.
> > 
> > The offset of the muram relative to what?  Or do you mean the offset into
> > muram?
> 
> Yes, the offset into muram.
> 
> > 
> > > CPM need to allocate block from a specific offset due to hardware
> > > restriction.
> > > So I must handle this offset in genalloc.
> > 
> > Again, if you need to be able to mark a specific range reserved, add a
> > function that does that properly.  Don't try to hack it in the way you
> > did.
> 
> Add a function? Do you mean add a new alloc function or new algo?
> If you mean new algo, CPM use both align algo and new algo, set 
> Different algos in different muram_alloc func? 

I was thinking that it was a sufficiently different operation that it 
warranted its own independent function, but I suppose you could do it as an 
algorithm that only accepts the requested range and returns failure for all 
other chunks (as well as if the range is unavailable).  It would not be 
related at all to the aligned-alloc algorithm.

-Scott



^ permalink raw reply	[flat|nested] 42+ messages in thread

* RE: [PATCH V7 1/3] genalloc:support memory-allocation with bytes-alignment to genalloc
  2015-09-02  3:08             ` Scott Wood
@ 2015-09-02  3:57                 ` Zhao Qiang
  0 siblings, 0 replies; 42+ messages in thread
From: Zhao Qiang @ 2015-09-02  3:57 UTC (permalink / raw)
  To: Scott Wood
  Cc: linux-kernel, linuxppc-dev, lauraa, Xiaobo Xie, benh, Li Leo, paulus

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="utf-8", Size: 6497 bytes --]


On Wed, 2015-09-02 at 10:33AM -0500, Wood Scott-B07421 wrote:
> -----Original Message-----
> From: Wood Scott-B07421
> Sent: Wednesday, September 02, 2015 11:09 AM
> To: Zhao Qiang-B45475
> Cc: linux-kernel@vger.kernel.org; linuxppc-dev@lists.ozlabs.org;
> lauraa@codeaurora.org; Xie Xiaobo-R63061; benh@kernel.crashing.org; Li
> Yang-Leo-R58472; paulus@samba.org
> Subject: Re: [PATCH V7 1/3] genalloc:support memory-allocation with
> bytes-alignment to genalloc
> 
> On Tue, 2015-09-01 at 22:05 -0500, Zhao Qiang-B45475 wrote:
> > On Wed, 2015-09-02 at 10:33AM -0500, Wood Scott-B07421 wrote:
> >
> > > -----Original Message-----
> > > From: Wood Scott-B07421
> > > Sent: Wednesday, September 02, 2015 10:33 AM
> > > To: Zhao Qiang-B45475
> > > Cc: linux-kernel@vger.kernel.org; linuxppc-dev@lists.ozlabs.org;
> > > lauraa@codeaurora.org; Xie Xiaobo-R63061; benh@kernel.crashing.org;
> > > Li Yang-Leo-R58472; paulus@samba.org
> > > Subject: Re: [PATCH V7 1/3] genalloc:support memory-allocation with
> > > bytes-alignment to genalloc
> > >
> > > On Tue, 2015-09-01 at 21:29 -0500, Zhao Qiang-B45475 wrote:
> > > > On Wed, 2015-09-02 at 10:18AM -0500, Wood Scott-B07421 wrote:
> > > > > -----Original Message-----
> > > > > From: Wood Scott-B07421
> > > > > Sent: Wednesday, September 02, 2015 10:18 AM
> > > > > To: Zhao Qiang-B45475
> > > > > Cc: linux-kernel@vger.kernel.org; linuxppc-dev@lists.ozlabs.org;
> > > > > lauraa@codeaurora.org; Xie Xiaobo-R63061;
> > > > > benh@kernel.crashing.org; Li Yang-Leo-R58472; paulus@samba.org
> > > > > Subject: Re: [PATCH V7 1/3] genalloc:support memory-allocation
> > > > > with bytes-alignment to genalloc
> > > > >
> > > > > On Tue, 2015-09-01 at 21:10 -0500, Zhao Qiang-B45475 wrote:
> > > > > > On Wed, 2015-09-02 at 08:38AM +0800, Wood Scott-B07421 wrote:
> > > > > > > -----Original Message-----
> > > > > > > From: Wood Scott-B07421
> > > > > > > Sent: Wednesday, September 02, 2015 8:30 AM
> > > > > > > To: Zhao Qiang-B45475
> > > > > > > Cc: linux-kernel@vger.kernel.org;
> > > > > > > linuxppc-dev@lists.ozlabs.org; lauraa@codeaurora.org; Xie
> > > > > > > Xiaobo-R63061; benh@kernel.crashing.org; Li Yang-Leo-R58472;
> > > > > > > paulus@samba.org
> > > > > > > Subject: Re: [PATCH V7 1/3] genalloc:support
> > > > > > > memory-allocation with bytes-alignment to genalloc
> > > > > > >
> > > > > > > On Mon, 2015-08-31 at 16:58 +0800, Zhao Qiang wrote:
> > > > > > > > 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 <qiang.zhao@freescale.com>
> > > > > > > > ---
> > > > > > > > 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.
> > > > > > >
> > > > > > > This seems to be describing more than just the changes in
> > > > > > > this
> > > patch.
> > > > > > > What does also handling cpm have to do with this patch?  Are
> > > > > > > you adding support for reserving a specific region in this
> > > > > > > patch?  I don't see it, and in any case it should go in a
> different patch.
> > > > > >
> > > > > > Yes, I added. The code below can support the function.
> > > > > >       offset_bit = (alignment->offset + (1UL << order) - 1) >>
> > > order;
> > > > > >       return bitmap_find_next_zero_area(map, size, start +
> > > > > > offset_bit,
> > > > > nr,
> > > > > >                         align_mask);
> > > > > >
> > > > > > CPM has an function cpm_muram_alloc_fixed, needing to allocate
> > > > > > muram from a Specific offset. So I add the code and add offset
> > > > > > to
> > > struct data.
> > > > >
> > > > > I thought the offset was related to the previous discussion of
> > > > > checking for allocation failure.  Are you using it to implement
> > > > > alloc_fixed()?  If so, please don't.  Besides the awkward
> > > > > implementation (what does it logically have to do with
> > > > > gen_pool_first_fit_align?), it does not appear to be correct -
> > > > > - what happens with multiple chunks?  What happens if part of
> > > > > the region the caller is trying to reserve is already taken?
> > > > > Implement a proper function to reserve a fixed genalloc region.
> > > >
> > > > This offset is totally different with the workaround OFFSET!
> > >
> > > There's a reason why we write changelogs that describe what the
> > > patch is doing, and avoid combining logically distinct changes in the
> same patch.
> > >
> > > > This offset is the offset of the muram.
> > >
> > > The offset of the muram relative to what?  Or do you mean the offset
> > > into muram?
> >
> > Yes, the offset into muram.
> >
> > >
> > > > CPM need to allocate block from a specific offset due to hardware
> > > > restriction.
> > > > So I must handle this offset in genalloc.
> > >
> > > Again, if you need to be able to mark a specific range reserved, add
> > > a function that does that properly.  Don't try to hack it in the way
> > > you did.
> >
> > Add a function? Do you mean add a new alloc function or new algo?
> > If you mean new algo, CPM use both align algo and new algo, set
> > Different algos in different muram_alloc func?
> 
> I was thinking that it was a sufficiently different operation that it
> warranted its own independent function, but I suppose you could do it as
> an algorithm that only accepts the requested range and returns failure
> for all other chunks (as well as if the range is unavailable).  It would
> not be related at all to the aligned-alloc algorithm.

If do so, I need set algo in different muram_alloc function, it is redundancy.
The algos has start para, but it set start_bit = 0 in gen_pool_alloc_data, can 
We pass a start addr para to gen_pool_alloc_data?

> 
> -Scott
> 

ÿôèº{.nÇ+‰·Ÿ®‰­†+%ŠËÿ±éݶ\x17¥Šwÿº{.nÇ+‰·¥Š{±þG«éÿŠ{ayº\x1dʇڙë,j\a­¢f£¢·hšïêÿ‘êçz_è®\x03(­éšŽŠÝ¢j"ú\x1a¶^[m§ÿÿ¾\a«þG«éÿ¢¸?™¨è­Ú&£ø§~á¶iO•æ¬z·švØ^\x14\x04\x1a¶^[m§ÿÿÃ\fÿ¶ìÿ¢¸?–I¥

^ permalink raw reply	[flat|nested] 42+ messages in thread

* RE: [PATCH V7 1/3] genalloc:support memory-allocation with bytes-alignment to genalloc
@ 2015-09-02  3:57                 ` Zhao Qiang
  0 siblings, 0 replies; 42+ messages in thread
From: Zhao Qiang @ 2015-09-02  3:57 UTC (permalink / raw)
  To: Scott Wood
  Cc: linux-kernel, linuxppc-dev, lauraa, Xiaobo Xie, benh, Li Leo, paulus

DQpPbiBXZWQsIDIwMTUtMDktMDIgYXQgMTA6MzNBTSAtMDUwMCwgV29vZCBTY290dC1CMDc0MjEg
d3JvdGU6DQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IFdvb2QgU2NvdHQt
QjA3NDIxDQo+IFNlbnQ6IFdlZG5lc2RheSwgU2VwdGVtYmVyIDAyLCAyMDE1IDExOjA5IEFNDQo+
IFRvOiBaaGFvIFFpYW5nLUI0NTQ3NQ0KPiBDYzogbGludXgta2VybmVsQHZnZXIua2VybmVsLm9y
ZzsgbGludXhwcGMtZGV2QGxpc3RzLm96bGFicy5vcmc7DQo+IGxhdXJhYUBjb2RlYXVyb3JhLm9y
ZzsgWGllIFhpYW9iby1SNjMwNjE7IGJlbmhAa2VybmVsLmNyYXNoaW5nLm9yZzsgTGkNCj4gWWFu
Zy1MZW8tUjU4NDcyOyBwYXVsdXNAc2FtYmEub3JnDQo+IFN1YmplY3Q6IFJlOiBbUEFUQ0ggVjcg
MS8zXSBnZW5hbGxvYzpzdXBwb3J0IG1lbW9yeS1hbGxvY2F0aW9uIHdpdGgNCj4gYnl0ZXMtYWxp
Z25tZW50IHRvIGdlbmFsbG9jDQo+IA0KPiBPbiBUdWUsIDIwMTUtMDktMDEgYXQgMjI6MDUgLTA1
MDAsIFpoYW8gUWlhbmctQjQ1NDc1IHdyb3RlOg0KPiA+IE9uIFdlZCwgMjAxNS0wOS0wMiBhdCAx
MDozM0FNIC0wNTAwLCBXb29kIFNjb3R0LUIwNzQyMSB3cm90ZToNCj4gPg0KPiA+ID4gLS0tLS1P
cmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPiA+IEZyb206IFdvb2QgU2NvdHQtQjA3NDIxDQo+ID4g
PiBTZW50OiBXZWRuZXNkYXksIFNlcHRlbWJlciAwMiwgMjAxNSAxMDozMyBBTQ0KPiA+ID4gVG86
IFpoYW8gUWlhbmctQjQ1NDc1DQo+ID4gPiBDYzogbGludXgta2VybmVsQHZnZXIua2VybmVsLm9y
ZzsgbGludXhwcGMtZGV2QGxpc3RzLm96bGFicy5vcmc7DQo+ID4gPiBsYXVyYWFAY29kZWF1cm9y
YS5vcmc7IFhpZSBYaWFvYm8tUjYzMDYxOyBiZW5oQGtlcm5lbC5jcmFzaGluZy5vcmc7DQo+ID4g
PiBMaSBZYW5nLUxlby1SNTg0NzI7IHBhdWx1c0BzYW1iYS5vcmcNCj4gPiA+IFN1YmplY3Q6IFJl
OiBbUEFUQ0ggVjcgMS8zXSBnZW5hbGxvYzpzdXBwb3J0IG1lbW9yeS1hbGxvY2F0aW9uIHdpdGgN
Cj4gPiA+IGJ5dGVzLWFsaWdubWVudCB0byBnZW5hbGxvYw0KPiA+ID4NCj4gPiA+IE9uIFR1ZSwg
MjAxNS0wOS0wMSBhdCAyMToyOSAtMDUwMCwgWmhhbyBRaWFuZy1CNDU0NzUgd3JvdGU6DQo+ID4g
PiA+IE9uIFdlZCwgMjAxNS0wOS0wMiBhdCAxMDoxOEFNIC0wNTAwLCBXb29kIFNjb3R0LUIwNzQy
MSB3cm90ZToNCj4gPiA+ID4gPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+ID4gPiA+
IEZyb206IFdvb2QgU2NvdHQtQjA3NDIxDQo+ID4gPiA+ID4gU2VudDogV2VkbmVzZGF5LCBTZXB0
ZW1iZXIgMDIsIDIwMTUgMTA6MTggQU0NCj4gPiA+ID4gPiBUbzogWmhhbyBRaWFuZy1CNDU0NzUN
Cj4gPiA+ID4gPiBDYzogbGludXgta2VybmVsQHZnZXIua2VybmVsLm9yZzsgbGludXhwcGMtZGV2
QGxpc3RzLm96bGFicy5vcmc7DQo+ID4gPiA+ID4gbGF1cmFhQGNvZGVhdXJvcmEub3JnOyBYaWUg
WGlhb2JvLVI2MzA2MTsNCj4gPiA+ID4gPiBiZW5oQGtlcm5lbC5jcmFzaGluZy5vcmc7IExpIFlh
bmctTGVvLVI1ODQ3MjsgcGF1bHVzQHNhbWJhLm9yZw0KPiA+ID4gPiA+IFN1YmplY3Q6IFJlOiBb
UEFUQ0ggVjcgMS8zXSBnZW5hbGxvYzpzdXBwb3J0IG1lbW9yeS1hbGxvY2F0aW9uDQo+ID4gPiA+
ID4gd2l0aCBieXRlcy1hbGlnbm1lbnQgdG8gZ2VuYWxsb2MNCj4gPiA+ID4gPg0KPiA+ID4gPiA+
IE9uIFR1ZSwgMjAxNS0wOS0wMSBhdCAyMToxMCAtMDUwMCwgWmhhbyBRaWFuZy1CNDU0NzUgd3Jv
dGU6DQo+ID4gPiA+ID4gPiBPbiBXZWQsIDIwMTUtMDktMDIgYXQgMDg6MzhBTSArMDgwMCwgV29v
ZCBTY290dC1CMDc0MjEgd3JvdGU6DQo+ID4gPiA+ID4gPiA+IC0tLS0tT3JpZ2luYWwgTWVzc2Fn
ZS0tLS0tDQo+ID4gPiA+ID4gPiA+IEZyb206IFdvb2QgU2NvdHQtQjA3NDIxDQo+ID4gPiA+ID4g
PiA+IFNlbnQ6IFdlZG5lc2RheSwgU2VwdGVtYmVyIDAyLCAyMDE1IDg6MzAgQU0NCj4gPiA+ID4g
PiA+ID4gVG86IFpoYW8gUWlhbmctQjQ1NDc1DQo+ID4gPiA+ID4gPiA+IENjOiBsaW51eC1rZXJu
ZWxAdmdlci5rZXJuZWwub3JnOw0KPiA+ID4gPiA+ID4gPiBsaW51eHBwYy1kZXZAbGlzdHMub3ps
YWJzLm9yZzsgbGF1cmFhQGNvZGVhdXJvcmEub3JnOyBYaWUNCj4gPiA+ID4gPiA+ID4gWGlhb2Jv
LVI2MzA2MTsgYmVuaEBrZXJuZWwuY3Jhc2hpbmcub3JnOyBMaSBZYW5nLUxlby1SNTg0NzI7DQo+
ID4gPiA+ID4gPiA+IHBhdWx1c0BzYW1iYS5vcmcNCj4gPiA+ID4gPiA+ID4gU3ViamVjdDogUmU6
IFtQQVRDSCBWNyAxLzNdIGdlbmFsbG9jOnN1cHBvcnQNCj4gPiA+ID4gPiA+ID4gbWVtb3J5LWFs
bG9jYXRpb24gd2l0aCBieXRlcy1hbGlnbm1lbnQgdG8gZ2VuYWxsb2MNCj4gPiA+ID4gPiA+ID4N
Cj4gPiA+ID4gPiA+ID4gT24gTW9uLCAyMDE1LTA4LTMxIGF0IDE2OjU4ICswODAwLCBaaGFvIFFp
YW5nIHdyb3RlOg0KPiA+ID4gPiA+ID4gPiA+IEJ5dGVzIGFsaWdubWVudCBpcyByZXF1aXJlZCB0
byBtYW5hZ2Ugc29tZSBzcGVjaWFsIFJBTSwgc28NCj4gPiA+ID4gPiA+ID4gPiBhZGQgZ2VuX3Bv
b2xfZmlyc3RfZml0X2FsaWduIHRvIGdlbmFsbG9jLCBtZWFud2hpbGUgYWRkDQo+ID4gPiA+ID4g
PiA+ID4gZ2VuX3Bvb2xfYWxsb2NfZGF0YSB0byBwYXNzIGRhdGEgdG8NCj4gPiA+ID4gPiA+ID4g
PiBnZW5fcG9vbF9maXJzdF9maXRfYWxpZ24obW9kaWZ5IGdlbl9wb29sX2FsbG9jIGFzIGENCj4g
PiA+ID4gPiA+ID4gPiB3cmFwcGVyKQ0KPiA+ID4gPiA+ID4gPiA+DQo+ID4gPiA+ID4gPiA+ID4g
U2lnbmVkLW9mZi1ieTogWmhhbyBRaWFuZyA8cWlhbmcuemhhb0BmcmVlc2NhbGUuY29tPg0KPiA+
ID4gPiA+ID4gPiA+IC0tLQ0KPiA+ID4gPiA+ID4gPiA+IENoYW5nZXMgZm9yIHY2Og0KPiA+ID4g
PiA+ID4gPiA+ICAgICAgIC0gcGF0Y2hlcyBzZXQgdjYgaW5jbHVkZSBhIG5ldyBwYXRjaCBiZWNh
dXNlIG9mIHVzaW5nDQo+ID4gPiA+ID4gPiA+ID4gICAgICAgLSBnZW5hbGxvYyB0byBtYW5hZ2Ug
UUUgTVVSQU0sIHBhdGNoIDAwMDEgaXMgdGhlIG5ldw0KPiA+ID4gPiA+ID4gPiA+ICAgICAgIC0g
cGF0Y2gsIGFkZGluZyBieXRlcyBhbGlnbm1lbnQgZm9yIGFsbG9jYXRpb24gZm9yDQo+IHVzZS4N
Cj4gPiA+ID4gPiA+ID4gPiBDaGFuZ2VzIGZvciB2NzoNCj4gPiA+ID4gPiA+ID4gPiAgICAgICAt
IGNwbSBtdXJhbSBhbHNvIG5lZWQgdG8gdXNlIGdlbmFsbG9jIHRvIG1hbmFnZSwgaXQNCj4gaGFz
DQo+ID4gPiA+ID4gPiA+ID4gICAgICAgICBhIGZ1bmN0aW9uIHRvIHJlc2VydmUgYSBzcGVjaWZp
YyByZWdpb24gb2YgbXVyYW0sDQo+ID4gPiA+ID4gPiA+ID4gICAgICAgICBhZGQgb2Zmc2V0IHRv
IGdlbnBvb2xfZGF0YSBmb3Igc3RhcnQgYWRkciB0byBiZQ0KPiA+ID4gYWxsb2NhdGVkLg0KPiA+
ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4gPiBUaGlzIHNlZW1zIHRvIGJlIGRlc2NyaWJpbmcgbW9y
ZSB0aGFuIGp1c3QgdGhlIGNoYW5nZXMgaW4NCj4gPiA+ID4gPiA+ID4gdGhpcw0KPiA+ID4gcGF0
Y2guDQo+ID4gPiA+ID4gPiA+IFdoYXQgZG9lcyBhbHNvIGhhbmRsaW5nIGNwbSBoYXZlIHRvIGRv
IHdpdGggdGhpcyBwYXRjaD8gIEFyZQ0KPiA+ID4gPiA+ID4gPiB5b3UgYWRkaW5nIHN1cHBvcnQg
Zm9yIHJlc2VydmluZyBhIHNwZWNpZmljIHJlZ2lvbiBpbiB0aGlzDQo+ID4gPiA+ID4gPiA+IHBh
dGNoPyAgSSBkb24ndCBzZWUgaXQsIGFuZCBpbiBhbnkgY2FzZSBpdCBzaG91bGQgZ28gaW4gYQ0K
PiBkaWZmZXJlbnQgcGF0Y2guDQo+ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4gWWVzLCBJIGFkZGVk
LiBUaGUgY29kZSBiZWxvdyBjYW4gc3VwcG9ydCB0aGUgZnVuY3Rpb24uDQo+ID4gPiA+ID4gPiAg
ICAgICBvZmZzZXRfYml0ID0gKGFsaWdubWVudC0+b2Zmc2V0ICsgKDFVTCA8PCBvcmRlcikgLSAx
KSA+Pg0KPiA+ID4gb3JkZXI7DQo+ID4gPiA+ID4gPiAgICAgICByZXR1cm4gYml0bWFwX2ZpbmRf
bmV4dF96ZXJvX2FyZWEobWFwLCBzaXplLCBzdGFydCArDQo+ID4gPiA+ID4gPiBvZmZzZXRfYml0
LA0KPiA+ID4gPiA+IG5yLA0KPiA+ID4gPiA+ID4gICAgICAgICAgICAgICAgICAgICAgICAgYWxp
Z25fbWFzayk7DQo+ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4gQ1BNIGhhcyBhbiBmdW5jdGlvbiBj
cG1fbXVyYW1fYWxsb2NfZml4ZWQsIG5lZWRpbmcgdG8gYWxsb2NhdGUNCj4gPiA+ID4gPiA+IG11
cmFtIGZyb20gYSBTcGVjaWZpYyBvZmZzZXQuIFNvIEkgYWRkIHRoZSBjb2RlIGFuZCBhZGQgb2Zm
c2V0DQo+ID4gPiA+ID4gPiB0bw0KPiA+ID4gc3RydWN0IGRhdGEuDQo+ID4gPiA+ID4NCj4gPiA+
ID4gPiBJIHRob3VnaHQgdGhlIG9mZnNldCB3YXMgcmVsYXRlZCB0byB0aGUgcHJldmlvdXMgZGlz
Y3Vzc2lvbiBvZg0KPiA+ID4gPiA+IGNoZWNraW5nIGZvciBhbGxvY2F0aW9uIGZhaWx1cmUuICBB
cmUgeW91IHVzaW5nIGl0IHRvIGltcGxlbWVudA0KPiA+ID4gPiA+IGFsbG9jX2ZpeGVkKCk/ICBJ
ZiBzbywgcGxlYXNlIGRvbid0LiAgQmVzaWRlcyB0aGUgYXdrd2FyZA0KPiA+ID4gPiA+IGltcGxl
bWVudGF0aW9uICh3aGF0IGRvZXMgaXQgbG9naWNhbGx5IGhhdmUgdG8gZG8gd2l0aA0KPiA+ID4g
PiA+IGdlbl9wb29sX2ZpcnN0X2ZpdF9hbGlnbj8pLCBpdCBkb2VzIG5vdCBhcHBlYXIgdG8gYmUg
Y29ycmVjdCAtDQo+ID4gPiA+ID4gLSB3aGF0IGhhcHBlbnMgd2l0aCBtdWx0aXBsZSBjaHVua3M/
ICBXaGF0IGhhcHBlbnMgaWYgcGFydCBvZg0KPiA+ID4gPiA+IHRoZSByZWdpb24gdGhlIGNhbGxl
ciBpcyB0cnlpbmcgdG8gcmVzZXJ2ZSBpcyBhbHJlYWR5IHRha2VuPw0KPiA+ID4gPiA+IEltcGxl
bWVudCBhIHByb3BlciBmdW5jdGlvbiB0byByZXNlcnZlIGEgZml4ZWQgZ2VuYWxsb2MgcmVnaW9u
Lg0KPiA+ID4gPg0KPiA+ID4gPiBUaGlzIG9mZnNldCBpcyB0b3RhbGx5IGRpZmZlcmVudCB3aXRo
IHRoZSB3b3JrYXJvdW5kIE9GRlNFVCENCj4gPiA+DQo+ID4gPiBUaGVyZSdzIGEgcmVhc29uIHdo
eSB3ZSB3cml0ZSBjaGFuZ2Vsb2dzIHRoYXQgZGVzY3JpYmUgd2hhdCB0aGUNCj4gPiA+IHBhdGNo
IGlzIGRvaW5nLCBhbmQgYXZvaWQgY29tYmluaW5nIGxvZ2ljYWxseSBkaXN0aW5jdCBjaGFuZ2Vz
IGluIHRoZQ0KPiBzYW1lIHBhdGNoLg0KPiA+ID4NCj4gPiA+ID4gVGhpcyBvZmZzZXQgaXMgdGhl
IG9mZnNldCBvZiB0aGUgbXVyYW0uDQo+ID4gPg0KPiA+ID4gVGhlIG9mZnNldCBvZiB0aGUgbXVy
YW0gcmVsYXRpdmUgdG8gd2hhdD8gIE9yIGRvIHlvdSBtZWFuIHRoZSBvZmZzZXQNCj4gPiA+IGlu
dG8gbXVyYW0/DQo+ID4NCj4gPiBZZXMsIHRoZSBvZmZzZXQgaW50byBtdXJhbS4NCj4gPg0KPiA+
ID4NCj4gPiA+ID4gQ1BNIG5lZWQgdG8gYWxsb2NhdGUgYmxvY2sgZnJvbSBhIHNwZWNpZmljIG9m
ZnNldCBkdWUgdG8gaGFyZHdhcmUNCj4gPiA+ID4gcmVzdHJpY3Rpb24uDQo+ID4gPiA+IFNvIEkg
bXVzdCBoYW5kbGUgdGhpcyBvZmZzZXQgaW4gZ2VuYWxsb2MuDQo+ID4gPg0KPiA+ID4gQWdhaW4s
IGlmIHlvdSBuZWVkIHRvIGJlIGFibGUgdG8gbWFyayBhIHNwZWNpZmljIHJhbmdlIHJlc2VydmVk
LCBhZGQNCj4gPiA+IGEgZnVuY3Rpb24gdGhhdCBkb2VzIHRoYXQgcHJvcGVybHkuICBEb24ndCB0
cnkgdG8gaGFjayBpdCBpbiB0aGUgd2F5DQo+ID4gPiB5b3UgZGlkLg0KPiA+DQo+ID4gQWRkIGEg
ZnVuY3Rpb24/IERvIHlvdSBtZWFuIGFkZCBhIG5ldyBhbGxvYyBmdW5jdGlvbiBvciBuZXcgYWxn
bz8NCj4gPiBJZiB5b3UgbWVhbiBuZXcgYWxnbywgQ1BNIHVzZSBib3RoIGFsaWduIGFsZ28gYW5k
IG5ldyBhbGdvLCBzZXQNCj4gPiBEaWZmZXJlbnQgYWxnb3MgaW4gZGlmZmVyZW50IG11cmFtX2Fs
bG9jIGZ1bmM/DQo+IA0KPiBJIHdhcyB0aGlua2luZyB0aGF0IGl0IHdhcyBhIHN1ZmZpY2llbnRs
eSBkaWZmZXJlbnQgb3BlcmF0aW9uIHRoYXQgaXQNCj4gd2FycmFudGVkIGl0cyBvd24gaW5kZXBl
bmRlbnQgZnVuY3Rpb24sIGJ1dCBJIHN1cHBvc2UgeW91IGNvdWxkIGRvIGl0IGFzDQo+IGFuIGFs
Z29yaXRobSB0aGF0IG9ubHkgYWNjZXB0cyB0aGUgcmVxdWVzdGVkIHJhbmdlIGFuZCByZXR1cm5z
IGZhaWx1cmUNCj4gZm9yIGFsbCBvdGhlciBjaHVua3MgKGFzIHdlbGwgYXMgaWYgdGhlIHJhbmdl
IGlzIHVuYXZhaWxhYmxlKS4gIEl0IHdvdWxkDQo+IG5vdCBiZSByZWxhdGVkIGF0IGFsbCB0byB0
aGUgYWxpZ25lZC1hbGxvYyBhbGdvcml0aG0uDQoNCklmIGRvIHNvLCBJIG5lZWQgc2V0IGFsZ28g
aW4gZGlmZmVyZW50IG11cmFtX2FsbG9jIGZ1bmN0aW9uLCBpdCBpcyByZWR1bmRhbmN5Lg0KVGhl
IGFsZ29zIGhhcyBzdGFydCBwYXJhLCBidXQgaXQgc2V0IHN0YXJ0X2JpdCA9IDAgaW4gZ2VuX3Bv
b2xfYWxsb2NfZGF0YSwgY2FuIA0KV2UgcGFzcyBhIHN0YXJ0IGFkZHIgcGFyYSB0byBnZW5fcG9v
bF9hbGxvY19kYXRhPw0KDQo+IA0KPiAtU2NvdHQNCj4gDQoNCg==

^ permalink raw reply	[flat|nested] 42+ messages in thread

* Re: [PATCH V7 1/3] genalloc:support memory-allocation with bytes-alignment to genalloc
  2015-09-02  3:57                 ` Zhao Qiang
  (?)
@ 2015-09-02  4:51                 ` Scott Wood
  -1 siblings, 0 replies; 42+ messages in thread
From: Scott Wood @ 2015-09-02  4:51 UTC (permalink / raw)
  To: Zhao Qiang-B45475
  Cc: linux-kernel, linuxppc-dev, lauraa, Xie Xiaobo-R63061, benh,
	Li Yang-Leo-R58472, paulus

On Tue, 2015-09-01 at 22:57 -0500, Zhao Qiang-B45475 wrote:
> On Wed, 2015-09-02 at 10:33AM -0500, Wood Scott-B07421 wrote:
> > -----Original Message-----
> > From: Wood Scott-B07421
> > Sent: Wednesday, September 02, 2015 11:09 AM
> > To: Zhao Qiang-B45475
> > Cc: linux-kernel@vger.kernel.org; linuxppc-dev@lists.ozlabs.org;
> > lauraa@codeaurora.org; Xie Xiaobo-R63061; benh@kernel.crashing.org; Li
> > Yang-Leo-R58472; paulus@samba.org
> > Subject: Re: [PATCH V7 1/3] genalloc:support memory-allocation with
> > bytes-alignment to genalloc
> > 
> > On Tue, 2015-09-01 at 22:05 -0500, Zhao Qiang-B45475 wrote:
> > > On Wed, 2015-09-02 at 10:33AM -0500, Wood Scott-B07421 wrote:
> > > 
> > > > -----Original Message-----
> > > > From: Wood Scott-B07421
> > > > Sent: Wednesday, September 02, 2015 10:33 AM
> > > > To: Zhao Qiang-B45475
> > > > Cc: linux-kernel@vger.kernel.org; linuxppc-dev@lists.ozlabs.org;
> > > > lauraa@codeaurora.org; Xie Xiaobo-R63061; benh@kernel.crashing.org;
> > > > Li Yang-Leo-R58472; paulus@samba.org
> > > > Subject: Re: [PATCH V7 1/3] genalloc:support memory-allocation with
> > > > bytes-alignment to genalloc
> > > > 
> > > > On Tue, 2015-09-01 at 21:29 -0500, Zhao Qiang-B45475 wrote:
> > > > > On Wed, 2015-09-02 at 10:18AM -0500, Wood Scott-B07421 wrote:
> > > > > > -----Original Message-----
> > > > > > From: Wood Scott-B07421
> > > > > > Sent: Wednesday, September 02, 2015 10:18 AM
> > > > > > To: Zhao Qiang-B45475
> > > > > > Cc: linux-kernel@vger.kernel.org; linuxppc-dev@lists.ozlabs.org;
> > > > > > lauraa@codeaurora.org; Xie Xiaobo-R63061;
> > > > > > benh@kernel.crashing.org; Li Yang-Leo-R58472; paulus@samba.org
> > > > > > Subject: Re: [PATCH V7 1/3] genalloc:support memory-allocation
> > > > > > with bytes-alignment to genalloc
> > > > > > 
> > > > > > On Tue, 2015-09-01 at 21:10 -0500, Zhao Qiang-B45475 wrote:
> > > > > > > On Wed, 2015-09-02 at 08:38AM +0800, Wood Scott-B07421 wrote:
> > > > > > > > -----Original Message-----
> > > > > > > > From: Wood Scott-B07421
> > > > > > > > Sent: Wednesday, September 02, 2015 8:30 AM
> > > > > > > > To: Zhao Qiang-B45475
> > > > > > > > Cc: linux-kernel@vger.kernel.org;
> > > > > > > > linuxppc-dev@lists.ozlabs.org; lauraa@codeaurora.org; Xie
> > > > > > > > Xiaobo-R63061; benh@kernel.crashing.org; Li Yang-Leo-R58472;
> > > > > > > > paulus@samba.org
> > > > > > > > Subject: Re: [PATCH V7 1/3] genalloc:support
> > > > > > > > memory-allocation with bytes-alignment to genalloc
> > > > > > > > 
> > > > > > > > On Mon, 2015-08-31 at 16:58 +0800, Zhao Qiang wrote:
> > > > > > > > > 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 <qiang.zhao@freescale.com>
> > > > > > > > > ---
> > > > > > > > > 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.
> > > > > > > > 
> > > > > > > > This seems to be describing more than just the changes in
> > > > > > > > this
> > > > patch.
> > > > > > > > What does also handling cpm have to do with this patch?  Are
> > > > > > > > you adding support for reserving a specific region in this
> > > > > > > > patch?  I don't see it, and in any case it should go in a
> > different patch.
> > > > > > > 
> > > > > > > Yes, I added. The code below can support the function.
> > > > > > >       offset_bit = (alignment->offset + (1UL << order) - 1) >>
> > > > order;
> > > > > > >       return bitmap_find_next_zero_area(map, size, start +
> > > > > > > offset_bit,
> > > > > > nr,
> > > > > > >                         align_mask);
> > > > > > > 
> > > > > > > CPM has an function cpm_muram_alloc_fixed, needing to allocate
> > > > > > > muram from a Specific offset. So I add the code and add offset
> > > > > > > to
> > > > struct data.
> > > > > > 
> > > > > > I thought the offset was related to the previous discussion of
> > > > > > checking for allocation failure.  Are you using it to implement
> > > > > > alloc_fixed()?  If so, please don't.  Besides the awkward
> > > > > > implementation (what does it logically have to do with
> > > > > > gen_pool_first_fit_align?), it does not appear to be correct -
> > > > > > - what happens with multiple chunks?  What happens if part of
> > > > > > the region the caller is trying to reserve is already taken?
> > > > > > Implement a proper function to reserve a fixed genalloc region.
> > > > > 
> > > > > This offset is totally different with the workaround OFFSET!
> > > > 
> > > > There's a reason why we write changelogs that describe what the
> > > > patch is doing, and avoid combining logically distinct changes in the
> > same patch.
> > > > 
> > > > > This offset is the offset of the muram.
> > > > 
> > > > The offset of the muram relative to what?  Or do you mean the offset
> > > > into muram?
> > > 
> > > Yes, the offset into muram.
> > > 
> > > > 
> > > > > CPM need to allocate block from a specific offset due to hardware
> > > > > restriction.
> > > > > So I must handle this offset in genalloc.
> > > > 
> > > > Again, if you need to be able to mark a specific range reserved, add
> > > > a function that does that properly.  Don't try to hack it in the way
> > > > you did.
> > > 
> > > Add a function? Do you mean add a new alloc function or new algo?
> > > If you mean new algo, CPM use both align algo and new algo, set
> > > Different algos in different muram_alloc func?
> > 
> > I was thinking that it was a sufficiently different operation that it
> > warranted its own independent function, but I suppose you could do it as
> > an algorithm that only accepts the requested range and returns failure
> > for all other chunks (as well as if the range is unavailable).  It would
> > not be related at all to the aligned-alloc algorithm.
> 
> If do so, I need set algo in different muram_alloc function, it is 
> redundancy.

If you do it as a separate top-level function there would be no algorithm.

Using an algorithm would be simpler to implement, but a bit more awkward in 
the caller due to the need to swap out the algorithm (unless we change 
gen_pool_alloc_data to gen_pool_alloc_algo_data or similar...).

> The algos has start para, but it set start_bit = 0 in gen_pool_alloc_data, 
> can We pass a start addr para to gen_pool_alloc_data?

No.  Again, setting that "start" variable is not equivalent to what you're 
trying to accomplish, even if it happens to work in your test case.

-Scott


^ permalink raw reply	[flat|nested] 42+ messages in thread

* RE: [PATCH V7 1/3] genalloc:support memory-allocation with bytes-alignment to genalloc
  2015-09-02  2:18     ` Scott Wood
@ 2015-09-06  3:13         ` Zhao Qiang
  2015-09-06  3:13         ` Zhao Qiang
  1 sibling, 0 replies; 42+ messages in thread
From: Zhao Qiang @ 2015-09-06  3:13 UTC (permalink / raw)
  To: Scott Wood
  Cc: linux-kernel, linuxppc-dev, lauraa, Xiaobo Xie, benh, Li Leo, paulus

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="utf-8", Size: 3780 bytes --]

On Wed, 2015-09-02 at 10:18AM +0800, Wood Scott-B07421 wrote:
> -----Original Message-----
> From: Wood Scott-B07421
> Sent: Wednesday, September 02, 2015 10:18 AM
> To: Zhao Qiang-B45475
> Cc: linux-kernel@vger.kernel.org; linuxppc-dev@lists.ozlabs.org;
> lauraa@codeaurora.org; Xie Xiaobo-R63061; benh@kernel.crashing.org; Li
> Yang-Leo-R58472; paulus@samba.org
> Subject: Re: [PATCH V7 1/3] genalloc:support memory-allocation with
> bytes-alignment to genalloc
> 
> On Tue, 2015-09-01 at 21:10 -0500, Zhao Qiang-B45475 wrote:
> > On Wed, 2015-09-02 at 08:38AM +0800, Wood Scott-B07421 wrote:
> > > -----Original Message-----
> > > From: Wood Scott-B07421
> > > Sent: Wednesday, September 02, 2015 8:30 AM
> > > To: Zhao Qiang-B45475
> > > Cc: linux-kernel@vger.kernel.org; linuxppc-dev@lists.ozlabs.org;
> > > lauraa@codeaurora.org; Xie Xiaobo-R63061; benh@kernel.crashing.org;
> > > Li Yang-Leo-R58472; paulus@samba.org
> > > Subject: Re: [PATCH V7 1/3] genalloc:support memory-allocation with
> > > bytes-alignment to genalloc
> > >
> > > On Mon, 2015-08-31 at 16:58 +0800, Zhao Qiang wrote:
> > > > 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 <qiang.zhao@freescale.com>
> > > > ---
> > > > 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.
> > >
> > > This seems to be describing more than just the changes in this patch.
> > > What does also handling cpm have to do with this patch?  Are you
> > > adding support for reserving a specific region in this patch?  I
> > > don't see it, and in any case it should go in a different patch.
> >
> > Yes, I added. The code below can support the function.
> >       offset_bit = (alignment->offset + (1UL << order) - 1) >> order;
> >       return bitmap_find_next_zero_area(map, size, start + offset_bit,
> nr,
> >                         align_mask);
> >
> > CPM has an function cpm_muram_alloc_fixed, needing to allocate muram
> > from a Specific offset. So I add the code and add offset to struct data.
> 
> I thought the offset was related to the previous discussion of checking
> for allocation failure.  Are you using it to implement alloc_fixed()?  If
> so, please don't.  Besides the awkward implementation (what does it
> logically have to do with gen_pool_first_fit_align?), it does not appear
> to be correct -
> - what happens with multiple chunks?  What happens if part of the region
> the caller is trying to reserve is already taken?  Implement a proper
> function to reserve a fixed genalloc region.
> 
The offset is which allocation block address need to be larger than, 
Not equal to, it really like the parameter start of the algo(the bitnumber
To start searching at).

> 
> > > > +/*
> > > > + *  gen_pool data descriptor for gen_pool_first_fit_align.
> > > > + */
> > > > +struct genpool_data_align {
> > > > +     int align;              /* alignment by bytes for starting
> > > address */
> > > > +     unsigned long offset;   /* the offset of allocation start
> addr*/
> > > > +};
> > >
> 
> -Scott
> 
-Zhao
ÿôèº{.nÇ+‰·Ÿ®‰­†+%ŠËÿ±éݶ\x17¥Šwÿº{.nÇ+‰·¥Š{±þG«éÿŠ{ayº\x1dʇڙë,j\a­¢f£¢·hšïêÿ‘êçz_è®\x03(­éšŽŠÝ¢j"ú\x1a¶^[m§ÿÿ¾\a«þG«éÿ¢¸?™¨è­Ú&£ø§~á¶iO•æ¬z·švØ^\x14\x04\x1a¶^[m§ÿÿÃ\fÿ¶ìÿ¢¸?–I¥

^ permalink raw reply	[flat|nested] 42+ messages in thread

* RE: [PATCH V7 1/3] genalloc:support memory-allocation with bytes-alignment to genalloc
@ 2015-09-06  3:13         ` Zhao Qiang
  0 siblings, 0 replies; 42+ messages in thread
From: Zhao Qiang @ 2015-09-06  3:13 UTC (permalink / raw)
  To: Scott Wood
  Cc: linux-kernel, linuxppc-dev, lauraa, Xiaobo Xie, benh, Li Leo, paulus

T24gV2VkLCAyMDE1LTA5LTAyIGF0IDEwOjE4QU0gKzA4MDAsIFdvb2QgU2NvdHQtQjA3NDIxIHdy
b3RlOg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBXb29kIFNjb3R0LUIw
NzQyMQ0KPiBTZW50OiBXZWRuZXNkYXksIFNlcHRlbWJlciAwMiwgMjAxNSAxMDoxOCBBTQ0KPiBU
bzogWmhhbyBRaWFuZy1CNDU0NzUNCj4gQ2M6IGxpbnV4LWtlcm5lbEB2Z2VyLmtlcm5lbC5vcmc7
IGxpbnV4cHBjLWRldkBsaXN0cy5vemxhYnMub3JnOw0KPiBsYXVyYWFAY29kZWF1cm9yYS5vcmc7
IFhpZSBYaWFvYm8tUjYzMDYxOyBiZW5oQGtlcm5lbC5jcmFzaGluZy5vcmc7IExpDQo+IFlhbmct
TGVvLVI1ODQ3MjsgcGF1bHVzQHNhbWJhLm9yZw0KPiBTdWJqZWN0OiBSZTogW1BBVENIIFY3IDEv
M10gZ2VuYWxsb2M6c3VwcG9ydCBtZW1vcnktYWxsb2NhdGlvbiB3aXRoDQo+IGJ5dGVzLWFsaWdu
bWVudCB0byBnZW5hbGxvYw0KPiANCj4gT24gVHVlLCAyMDE1LTA5LTAxIGF0IDIxOjEwIC0wNTAw
LCBaaGFvIFFpYW5nLUI0NTQ3NSB3cm90ZToNCj4gPiBPbiBXZWQsIDIwMTUtMDktMDIgYXQgMDg6
MzhBTSArMDgwMCwgV29vZCBTY290dC1CMDc0MjEgd3JvdGU6DQo+ID4gPiAtLS0tLU9yaWdpbmFs
IE1lc3NhZ2UtLS0tLQ0KPiA+ID4gRnJvbTogV29vZCBTY290dC1CMDc0MjENCj4gPiA+IFNlbnQ6
IFdlZG5lc2RheSwgU2VwdGVtYmVyIDAyLCAyMDE1IDg6MzAgQU0NCj4gPiA+IFRvOiBaaGFvIFFp
YW5nLUI0NTQ3NQ0KPiA+ID4gQ2M6IGxpbnV4LWtlcm5lbEB2Z2VyLmtlcm5lbC5vcmc7IGxpbnV4
cHBjLWRldkBsaXN0cy5vemxhYnMub3JnOw0KPiA+ID4gbGF1cmFhQGNvZGVhdXJvcmEub3JnOyBY
aWUgWGlhb2JvLVI2MzA2MTsgYmVuaEBrZXJuZWwuY3Jhc2hpbmcub3JnOw0KPiA+ID4gTGkgWWFu
Zy1MZW8tUjU4NDcyOyBwYXVsdXNAc2FtYmEub3JnDQo+ID4gPiBTdWJqZWN0OiBSZTogW1BBVENI
IFY3IDEvM10gZ2VuYWxsb2M6c3VwcG9ydCBtZW1vcnktYWxsb2NhdGlvbiB3aXRoDQo+ID4gPiBi
eXRlcy1hbGlnbm1lbnQgdG8gZ2VuYWxsb2MNCj4gPiA+DQo+ID4gPiBPbiBNb24sIDIwMTUtMDgt
MzEgYXQgMTY6NTggKzA4MDAsIFpoYW8gUWlhbmcgd3JvdGU6DQo+ID4gPiA+IEJ5dGVzIGFsaWdu
bWVudCBpcyByZXF1aXJlZCB0byBtYW5hZ2Ugc29tZSBzcGVjaWFsIFJBTSwgc28gYWRkDQo+ID4g
PiA+IGdlbl9wb29sX2ZpcnN0X2ZpdF9hbGlnbiB0byBnZW5hbGxvYywgbWVhbndoaWxlIGFkZA0K
PiA+ID4gPiBnZW5fcG9vbF9hbGxvY19kYXRhIHRvIHBhc3MgZGF0YSB0bw0KPiA+ID4gPiBnZW5f
cG9vbF9maXJzdF9maXRfYWxpZ24obW9kaWZ5IGdlbl9wb29sX2FsbG9jIGFzIGEgd3JhcHBlcikN
Cj4gPiA+ID4NCj4gPiA+ID4gU2lnbmVkLW9mZi1ieTogWmhhbyBRaWFuZyA8cWlhbmcuemhhb0Bm
cmVlc2NhbGUuY29tPg0KPiA+ID4gPiAtLS0NCj4gPiA+ID4gQ2hhbmdlcyBmb3IgdjY6DQo+ID4g
PiA+ICAgICAgIC0gcGF0Y2hlcyBzZXQgdjYgaW5jbHVkZSBhIG5ldyBwYXRjaCBiZWNhdXNlIG9m
IHVzaW5nDQo+ID4gPiA+ICAgICAgIC0gZ2VuYWxsb2MgdG8gbWFuYWdlIFFFIE1VUkFNLCBwYXRj
aCAwMDAxIGlzIHRoZSBuZXcNCj4gPiA+ID4gICAgICAgLSBwYXRjaCwgYWRkaW5nIGJ5dGVzIGFs
aWdubWVudCBmb3IgYWxsb2NhdGlvbiBmb3IgdXNlLg0KPiA+ID4gPiBDaGFuZ2VzIGZvciB2NzoN
Cj4gPiA+ID4gICAgICAgLSBjcG0gbXVyYW0gYWxzbyBuZWVkIHRvIHVzZSBnZW5hbGxvYyB0byBt
YW5hZ2UsIGl0IGhhcw0KPiA+ID4gPiAgICAgICAgIGEgZnVuY3Rpb24gdG8gcmVzZXJ2ZSBhIHNw
ZWNpZmljIHJlZ2lvbiBvZiBtdXJhbSwNCj4gPiA+ID4gICAgICAgICBhZGQgb2Zmc2V0IHRvIGdl
bnBvb2xfZGF0YSBmb3Igc3RhcnQgYWRkciB0byBiZSBhbGxvY2F0ZWQuDQo+ID4gPg0KPiA+ID4g
VGhpcyBzZWVtcyB0byBiZSBkZXNjcmliaW5nIG1vcmUgdGhhbiBqdXN0IHRoZSBjaGFuZ2VzIGlu
IHRoaXMgcGF0Y2guDQo+ID4gPiBXaGF0IGRvZXMgYWxzbyBoYW5kbGluZyBjcG0gaGF2ZSB0byBk
byB3aXRoIHRoaXMgcGF0Y2g/ICBBcmUgeW91DQo+ID4gPiBhZGRpbmcgc3VwcG9ydCBmb3IgcmVz
ZXJ2aW5nIGEgc3BlY2lmaWMgcmVnaW9uIGluIHRoaXMgcGF0Y2g/ICBJDQo+ID4gPiBkb24ndCBz
ZWUgaXQsIGFuZCBpbiBhbnkgY2FzZSBpdCBzaG91bGQgZ28gaW4gYSBkaWZmZXJlbnQgcGF0Y2gu
DQo+ID4NCj4gPiBZZXMsIEkgYWRkZWQuIFRoZSBjb2RlIGJlbG93IGNhbiBzdXBwb3J0IHRoZSBm
dW5jdGlvbi4NCj4gPiAgICAgICBvZmZzZXRfYml0ID0gKGFsaWdubWVudC0+b2Zmc2V0ICsgKDFV
TCA8PCBvcmRlcikgLSAxKSA+PiBvcmRlcjsNCj4gPiAgICAgICByZXR1cm4gYml0bWFwX2ZpbmRf
bmV4dF96ZXJvX2FyZWEobWFwLCBzaXplLCBzdGFydCArIG9mZnNldF9iaXQsDQo+IG5yLA0KPiA+
ICAgICAgICAgICAgICAgICAgICAgICAgIGFsaWduX21hc2spOw0KPiA+DQo+ID4gQ1BNIGhhcyBh
biBmdW5jdGlvbiBjcG1fbXVyYW1fYWxsb2NfZml4ZWQsIG5lZWRpbmcgdG8gYWxsb2NhdGUgbXVy
YW0NCj4gPiBmcm9tIGEgU3BlY2lmaWMgb2Zmc2V0LiBTbyBJIGFkZCB0aGUgY29kZSBhbmQgYWRk
IG9mZnNldCB0byBzdHJ1Y3QgZGF0YS4NCj4gDQo+IEkgdGhvdWdodCB0aGUgb2Zmc2V0IHdhcyBy
ZWxhdGVkIHRvIHRoZSBwcmV2aW91cyBkaXNjdXNzaW9uIG9mIGNoZWNraW5nDQo+IGZvciBhbGxv
Y2F0aW9uIGZhaWx1cmUuICBBcmUgeW91IHVzaW5nIGl0IHRvIGltcGxlbWVudCBhbGxvY19maXhl
ZCgpPyAgSWYNCj4gc28sIHBsZWFzZSBkb24ndC4gIEJlc2lkZXMgdGhlIGF3a3dhcmQgaW1wbGVt
ZW50YXRpb24gKHdoYXQgZG9lcyBpdA0KPiBsb2dpY2FsbHkgaGF2ZSB0byBkbyB3aXRoIGdlbl9w
b29sX2ZpcnN0X2ZpdF9hbGlnbj8pLCBpdCBkb2VzIG5vdCBhcHBlYXINCj4gdG8gYmUgY29ycmVj
dCAtDQo+IC0gd2hhdCBoYXBwZW5zIHdpdGggbXVsdGlwbGUgY2h1bmtzPyAgV2hhdCBoYXBwZW5z
IGlmIHBhcnQgb2YgdGhlIHJlZ2lvbg0KPiB0aGUgY2FsbGVyIGlzIHRyeWluZyB0byByZXNlcnZl
IGlzIGFscmVhZHkgdGFrZW4/ICBJbXBsZW1lbnQgYSBwcm9wZXINCj4gZnVuY3Rpb24gdG8gcmVz
ZXJ2ZSBhIGZpeGVkIGdlbmFsbG9jIHJlZ2lvbi4NCj4gDQpUaGUgb2Zmc2V0IGlzIHdoaWNoIGFs
bG9jYXRpb24gYmxvY2sgYWRkcmVzcyBuZWVkIHRvIGJlIGxhcmdlciB0aGFuLCANCk5vdCBlcXVh
bCB0bywgaXQgcmVhbGx5IGxpa2UgdGhlIHBhcmFtZXRlciBzdGFydCBvZiB0aGUgYWxnbyh0aGUg
Yml0bnVtYmVyDQpUbyBzdGFydCBzZWFyY2hpbmcgYXQpLg0KDQo+IA0KPiA+ID4gPiArLyoNCj4g
PiA+ID4gKyAqICBnZW5fcG9vbCBkYXRhIGRlc2NyaXB0b3IgZm9yIGdlbl9wb29sX2ZpcnN0X2Zp
dF9hbGlnbi4NCj4gPiA+ID4gKyAqLw0KPiA+ID4gPiArc3RydWN0IGdlbnBvb2xfZGF0YV9hbGln
biB7DQo+ID4gPiA+ICsgICAgIGludCBhbGlnbjsgICAgICAgICAgICAgIC8qIGFsaWdubWVudCBi
eSBieXRlcyBmb3Igc3RhcnRpbmcNCj4gPiA+IGFkZHJlc3MgKi8NCj4gPiA+ID4gKyAgICAgdW5z
aWduZWQgbG9uZyBvZmZzZXQ7ICAgLyogdGhlIG9mZnNldCBvZiBhbGxvY2F0aW9uIHN0YXJ0DQo+
IGFkZHIqLw0KPiA+ID4gPiArfTsNCj4gPiA+DQo+IA0KPiAtU2NvdHQNCj4gDQotWmhhbw0K

^ permalink raw reply	[flat|nested] 42+ messages in thread

* RE: [PATCH V7 2/3] qe_common: add qe_muram_ functions to manage muram
  2015-09-02  0:34   ` Scott Wood
@ 2015-09-06  6:37       ` Zhao Qiang
  2015-09-06  6:37       ` Zhao Qiang
  1 sibling, 0 replies; 42+ messages in thread
From: Zhao Qiang @ 2015-09-06  6:37 UTC (permalink / raw)
  To: Scott Wood
  Cc: linux-kernel, linuxppc-dev, lauraa, Xiaobo Xie, benh, Li Leo, paulus

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="utf-8", Size: 2880 bytes --]

On Mon, 2015-09-2 at 8:34 +0800, Wood Scott-B07421 wrote:
> -----Original Message-----
> From: Wood Scott-B07421
> Sent: Wednesday, September 02, 2015 8:34 AM
> To: Zhao Qiang-B45475
> Cc: linux-kernel@vger.kernel.org; linuxppc-dev@lists.ozlabs.org;
> lauraa@codeaurora.org; Xie Xiaobo-R63061; benh@kernel.crashing.org; Li
> Yang-Leo-R58472; paulus@samba.org
> Subject: Re: [PATCH V7 2/3] qe_common: add qe_muram_ functions to manage
> muram
> 
> On Mon, 2015-08-31 at 16:58 +0800, Zhao Qiang wrote:
> 
> > @@ -187,12 +190,25 @@ static inline int qe_alive_during_sleep(void)  }
> >
> >  /* we actually use cpm_muram implementation, define this for
> > convenience */ -#define qe_muram_init cpm_muram_init -#define
> > qe_muram_alloc cpm_muram_alloc -#define qe_muram_alloc_fixed
> > cpm_muram_alloc_fixed -#define qe_muram_free cpm_muram_free -#define
> > qe_muram_addr cpm_muram_addr -#define qe_muram_offset cpm_muram_offset
> > +#define cpm_muram_init qe_muram_init
> > +#define cpm_muram_alloc qe_muram_alloc #define cpm_muram_alloc_fixed
> > +qe_muram_alloc_fixed #define cpm_muram_free qe_muram_free #define
> > +cpm_muram_addr qe_muram_addr #define cpm_muram_offset qe_muram_offset
> 
> Why?  This is unnecessary churn.
> 
This is necessary. QE is on both ARM and PowerPC, its code is under public code.
But CPM is only on PowerPC and its code is under PowerPC.
So when build ARM, QE will not find cpm_muram_* function.
> 
> 
> >
> > -int cpm_muram_init(void)
> > -{
> > -     struct device_node *np;
> > -     struct resource r;
> > -     u32 zero[OF_MAX_ADDR_CELLS] = {};
> > -     resource_size_t max = 0;
> > -     int i = 0;
> > -     int ret = 0;
> > -
> > -     if (muram_pbase)
> > -             return 0;
> > -
> > -     spin_lock_init(&cpm_muram_lock);
> > -     /* initialize the info header */
> > -     rh_init(&cpm_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");
> > -                     ret = -ENODEV;
> > -                     goto out;
> > -             }
> > -     }
> > -
> > -     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");
> > -             ret = -ENODEV;
> > -             goto out;
> > -     }
> > 
> -Scott

ÿôèº{.nÇ+‰·Ÿ®‰­†+%ŠËÿ±éݶ\x17¥Šwÿº{.nÇ+‰·¥Š{±þG«éÿŠ{ayº\x1dʇڙë,j\a­¢f£¢·hšïêÿ‘êçz_è®\x03(­éšŽŠÝ¢j"ú\x1a¶^[m§ÿÿ¾\a«þG«éÿ¢¸?™¨è­Ú&£ø§~á¶iO•æ¬z·švØ^\x14\x04\x1a¶^[m§ÿÿÃ\fÿ¶ìÿ¢¸?–I¥

^ permalink raw reply	[flat|nested] 42+ messages in thread

* RE: [PATCH V7 2/3] qe_common: add qe_muram_ functions to manage muram
@ 2015-09-06  6:37       ` Zhao Qiang
  0 siblings, 0 replies; 42+ messages in thread
From: Zhao Qiang @ 2015-09-06  6:37 UTC (permalink / raw)
  To: Scott Wood
  Cc: linux-kernel, linuxppc-dev, lauraa, Xiaobo Xie, benh, Li Leo, paulus

T24gTW9uLCAyMDE1LTA5LTIgYXQgODozNCArMDgwMCwgV29vZCBTY290dC1CMDc0MjEgd3JvdGU6
DQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IFdvb2QgU2NvdHQtQjA3NDIx
DQo+IFNlbnQ6IFdlZG5lc2RheSwgU2VwdGVtYmVyIDAyLCAyMDE1IDg6MzQgQU0NCj4gVG86IFpo
YW8gUWlhbmctQjQ1NDc1DQo+IENjOiBsaW51eC1rZXJuZWxAdmdlci5rZXJuZWwub3JnOyBsaW51
eHBwYy1kZXZAbGlzdHMub3psYWJzLm9yZzsNCj4gbGF1cmFhQGNvZGVhdXJvcmEub3JnOyBYaWUg
WGlhb2JvLVI2MzA2MTsgYmVuaEBrZXJuZWwuY3Jhc2hpbmcub3JnOyBMaQ0KPiBZYW5nLUxlby1S
NTg0NzI7IHBhdWx1c0BzYW1iYS5vcmcNCj4gU3ViamVjdDogUmU6IFtQQVRDSCBWNyAyLzNdIHFl
X2NvbW1vbjogYWRkIHFlX211cmFtXyBmdW5jdGlvbnMgdG8gbWFuYWdlDQo+IG11cmFtDQo+IA0K
PiBPbiBNb24sIDIwMTUtMDgtMzEgYXQgMTY6NTggKzA4MDAsIFpoYW8gUWlhbmcgd3JvdGU6DQo+
IA0KPiA+IEBAIC0xODcsMTIgKzE5MCwyNSBAQCBzdGF0aWMgaW5saW5lIGludCBxZV9hbGl2ZV9k
dXJpbmdfc2xlZXAodm9pZCkgIH0NCj4gPg0KPiA+ICAvKiB3ZSBhY3R1YWxseSB1c2UgY3BtX211
cmFtIGltcGxlbWVudGF0aW9uLCBkZWZpbmUgdGhpcyBmb3INCj4gPiBjb252ZW5pZW5jZSAqLyAt
I2RlZmluZSBxZV9tdXJhbV9pbml0IGNwbV9tdXJhbV9pbml0IC0jZGVmaW5lDQo+ID4gcWVfbXVy
YW1fYWxsb2MgY3BtX211cmFtX2FsbG9jIC0jZGVmaW5lIHFlX211cmFtX2FsbG9jX2ZpeGVkDQo+
ID4gY3BtX211cmFtX2FsbG9jX2ZpeGVkIC0jZGVmaW5lIHFlX211cmFtX2ZyZWUgY3BtX211cmFt
X2ZyZWUgLSNkZWZpbmUNCj4gPiBxZV9tdXJhbV9hZGRyIGNwbV9tdXJhbV9hZGRyIC0jZGVmaW5l
IHFlX211cmFtX29mZnNldCBjcG1fbXVyYW1fb2Zmc2V0DQo+ID4gKyNkZWZpbmUgY3BtX211cmFt
X2luaXQgcWVfbXVyYW1faW5pdA0KPiA+ICsjZGVmaW5lIGNwbV9tdXJhbV9hbGxvYyBxZV9tdXJh
bV9hbGxvYyAjZGVmaW5lIGNwbV9tdXJhbV9hbGxvY19maXhlZA0KPiA+ICtxZV9tdXJhbV9hbGxv
Y19maXhlZCAjZGVmaW5lIGNwbV9tdXJhbV9mcmVlIHFlX211cmFtX2ZyZWUgI2RlZmluZQ0KPiA+
ICtjcG1fbXVyYW1fYWRkciBxZV9tdXJhbV9hZGRyICNkZWZpbmUgY3BtX211cmFtX29mZnNldCBx
ZV9tdXJhbV9vZmZzZXQNCj4gDQo+IFdoeT8gIFRoaXMgaXMgdW5uZWNlc3NhcnkgY2h1cm4uDQo+
IA0KVGhpcyBpcyBuZWNlc3NhcnkuIFFFIGlzIG9uIGJvdGggQVJNIGFuZCBQb3dlclBDLCBpdHMg
Y29kZSBpcyB1bmRlciBwdWJsaWMgY29kZS4NCkJ1dCBDUE0gaXMgb25seSBvbiBQb3dlclBDIGFu
ZCBpdHMgY29kZSBpcyB1bmRlciBQb3dlclBDLg0KU28gd2hlbiBidWlsZCBBUk0sIFFFIHdpbGwg
bm90IGZpbmQgY3BtX211cmFtXyogZnVuY3Rpb24uDQo+IA0KPiANCj4gPg0KPiA+IC1pbnQgY3Bt
X211cmFtX2luaXQodm9pZCkNCj4gPiAtew0KPiA+IC0gICAgIHN0cnVjdCBkZXZpY2Vfbm9kZSAq
bnA7DQo+ID4gLSAgICAgc3RydWN0IHJlc291cmNlIHI7DQo+ID4gLSAgICAgdTMyIHplcm9bT0Zf
TUFYX0FERFJfQ0VMTFNdID0ge307DQo+ID4gLSAgICAgcmVzb3VyY2Vfc2l6ZV90IG1heCA9IDA7
DQo+ID4gLSAgICAgaW50IGkgPSAwOw0KPiA+IC0gICAgIGludCByZXQgPSAwOw0KPiA+IC0NCj4g
PiAtICAgICBpZiAobXVyYW1fcGJhc2UpDQo+ID4gLSAgICAgICAgICAgICByZXR1cm4gMDsNCj4g
PiAtDQo+ID4gLSAgICAgc3Bpbl9sb2NrX2luaXQoJmNwbV9tdXJhbV9sb2NrKTsNCj4gPiAtICAg
ICAvKiBpbml0aWFsaXplIHRoZSBpbmZvIGhlYWRlciAqLw0KPiA+IC0gICAgIHJoX2luaXQoJmNw
bV9tdXJhbV9pbmZvLCAxLA0KPiA+IC0gICAgICAgICAgICAgc2l6ZW9mKGNwbV9ib290X211cmFt
X3JoX2Jsb2NrKSAvDQo+ID4gLSAgICAgICAgICAgICBzaXplb2YoY3BtX2Jvb3RfbXVyYW1fcmhf
YmxvY2tbMF0pLA0KPiA+IC0gICAgICAgICAgICAgY3BtX2Jvb3RfbXVyYW1fcmhfYmxvY2spOw0K
PiA+IC0NCj4gPiAtICAgICBucCA9IG9mX2ZpbmRfY29tcGF0aWJsZV9ub2RlKE5VTEwsIE5VTEws
ICJmc2wsY3BtLW11cmFtLWRhdGEiKTsNCj4gPiAtICAgICBpZiAoIW5wKSB7DQo+ID4gLSAgICAg
ICAgICAgICAvKiB0cnkgbGVnYWN5IGJpbmRpbmdzICovDQo+ID4gLSAgICAgICAgICAgICBucCA9
IG9mX2ZpbmRfbm9kZV9ieV9uYW1lKE5VTEwsICJkYXRhLW9ubHkiKTsNCj4gPiAtICAgICAgICAg
ICAgIGlmICghbnApIHsNCj4gPiAtICAgICAgICAgICAgICAgICAgICAgcHJpbnRrKEtFUk5fRVJS
ICJDYW5ub3QgZmluZCBDUE0gbXVyYW0gZGF0YQ0KPiBub2RlIik7DQo+ID4gLSAgICAgICAgICAg
ICAgICAgICAgIHJldCA9IC1FTk9ERVY7DQo+ID4gLSAgICAgICAgICAgICAgICAgICAgIGdvdG8g
b3V0Ow0KPiA+IC0gICAgICAgICAgICAgfQ0KPiA+IC0gICAgIH0NCj4gPiAtDQo+ID4gLSAgICAg
bXVyYW1fcGJhc2UgPSBvZl90cmFuc2xhdGVfYWRkcmVzcyhucCwgemVybyk7DQo+ID4gLSAgICAg
aWYgKG11cmFtX3BiYXNlID09IChwaHlzX2FkZHJfdClPRl9CQURfQUREUikgew0KPiA+IC0gICAg
ICAgICAgICAgcHJpbnRrKEtFUk5fRVJSICJDYW5ub3QgdHJhbnNsYXRlIHplcm8gdGhyb3VnaCBD
UE0gbXVyYW0NCj4gbm9kZSIpOw0KPiA+IC0gICAgICAgICAgICAgcmV0ID0gLUVOT0RFVjsNCj4g
PiAtICAgICAgICAgICAgIGdvdG8gb3V0Ow0KPiA+IC0gICAgIH0NCj4gPiANCj4gLVNjb3R0DQoN
Cg==

^ permalink raw reply	[flat|nested] 42+ messages in thread

* Re: [PATCH V7 1/3] genalloc:support memory-allocation with bytes-alignment to genalloc
  2015-09-06  3:13         ` Zhao Qiang
  (?)
@ 2015-09-09 16:37         ` Scott Wood
  2015-09-10  2:26             ` Zhao Qiang
  -1 siblings, 1 reply; 42+ messages in thread
From: Scott Wood @ 2015-09-09 16:37 UTC (permalink / raw)
  To: Zhao Qiang-B45475
  Cc: linux-kernel, linuxppc-dev, lauraa, Xie Xiaobo-R63061, benh,
	Li Yang-Leo-R58472, paulus

On Sat, 2015-09-05 at 22:13 -0500, Zhao Qiang-B45475 wrote:
> On Wed, 2015-09-02 at 10:18AM +0800, Wood Scott-B07421 wrote:
> > -----Original Message-----
> > From: Wood Scott-B07421
> > Sent: Wednesday, September 02, 2015 10:18 AM
> > To: Zhao Qiang-B45475
> > Cc: linux-kernel@vger.kernel.org; linuxppc-dev@lists.ozlabs.org;
> > lauraa@codeaurora.org; Xie Xiaobo-R63061; benh@kernel.crashing.org; Li
> > Yang-Leo-R58472; paulus@samba.org
> > Subject: Re: [PATCH V7 1/3] genalloc:support memory-allocation with
> > bytes-alignment to genalloc
> > 
> > On Tue, 2015-09-01 at 21:10 -0500, Zhao Qiang-B45475 wrote:
> > > On Wed, 2015-09-02 at 08:38AM +0800, Wood Scott-B07421 wrote:
> > > > -----Original Message-----
> > > > From: Wood Scott-B07421
> > > > Sent: Wednesday, September 02, 2015 8:30 AM
> > > > To: Zhao Qiang-B45475
> > > > Cc: linux-kernel@vger.kernel.org; linuxppc-dev@lists.ozlabs.org;
> > > > lauraa@codeaurora.org; Xie Xiaobo-R63061; benh@kernel.crashing.org;
> > > > Li Yang-Leo-R58472; paulus@samba.org
> > > > Subject: Re: [PATCH V7 1/3] genalloc:support memory-allocation with
> > > > bytes-alignment to genalloc
> > > > 
> > > > On Mon, 2015-08-31 at 16:58 +0800, Zhao Qiang wrote:
> > > > > 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 <qiang.zhao@freescale.com>
> > > > > ---
> > > > > 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.
> > > > 
> > > > This seems to be describing more than just the changes in this patch.
> > > > What does also handling cpm have to do with this patch?  Are you
> > > > adding support for reserving a specific region in this patch?  I
> > > > don't see it, and in any case it should go in a different patch.
> > > 
> > > Yes, I added. The code below can support the function.
> > >       offset_bit = (alignment->offset + (1UL << order) - 1) >> order;
> > >       return bitmap_find_next_zero_area(map, size, start + offset_bit,
> > nr,
> > >                         align_mask);
> > > 
> > > CPM has an function cpm_muram_alloc_fixed, needing to allocate muram
> > > from a Specific offset. So I add the code and add offset to struct data.
> > 
> > I thought the offset was related to the previous discussion of checking
> > for allocation failure.  Are you using it to implement alloc_fixed()?  If
> > so, please don't.  Besides the awkward implementation (what does it
> > logically have to do with gen_pool_first_fit_align?), it does not appear
> > to be correct -
> > - what happens with multiple chunks?  What happens if part of the region
> > the caller is trying to reserve is already taken?  Implement a proper
> > function to reserve a fixed genalloc region.
> > 
> The offset is which allocation block address need to be larger than, 
> Not equal to, it really like the parameter start of the algo(the bitnumber
> To start searching at).

cpm_muram_alloc_fixed() is not "search starting at this offset".  It is 
"reserve this exact range or fail".

-Scott


^ permalink raw reply	[flat|nested] 42+ messages in thread

* Re: [PATCH V7 2/3] qe_common: add qe_muram_ functions to manage muram
  2015-09-06  6:37       ` Zhao Qiang
  (?)
@ 2015-09-09 16:38       ` Scott Wood
  2015-09-10  2:34           ` Zhao Qiang
  -1 siblings, 1 reply; 42+ messages in thread
From: Scott Wood @ 2015-09-09 16:38 UTC (permalink / raw)
  To: Zhao Qiang-B45475
  Cc: linux-kernel, linuxppc-dev, lauraa, Xie Xiaobo-R63061, benh,
	Li Yang-Leo-R58472, paulus

On Sun, 2015-09-06 at 01:37 -0500, Zhao Qiang-B45475 wrote:
> On Mon, 2015-09-2 at 8:34 +0800, Wood Scott-B07421 wrote:
> > -----Original Message-----
> > From: Wood Scott-B07421
> > Sent: Wednesday, September 02, 2015 8:34 AM
> > To: Zhao Qiang-B45475
> > Cc: linux-kernel@vger.kernel.org; linuxppc-dev@lists.ozlabs.org;
> > lauraa@codeaurora.org; Xie Xiaobo-R63061; benh@kernel.crashing.org; Li
> > Yang-Leo-R58472; paulus@samba.org
> > Subject: Re: [PATCH V7 2/3] qe_common: add qe_muram_ functions to manage
> > muram
> > 
> > On Mon, 2015-08-31 at 16:58 +0800, Zhao Qiang wrote:
> > 
> > > @@ -187,12 +190,25 @@ static inline int qe_alive_during_sleep(void)  }
> > > 
> > >  /* we actually use cpm_muram implementation, define this for
> > > convenience */ -#define qe_muram_init cpm_muram_init -#define
> > > qe_muram_alloc cpm_muram_alloc -#define qe_muram_alloc_fixed
> > > cpm_muram_alloc_fixed -#define qe_muram_free cpm_muram_free -#define
> > > qe_muram_addr cpm_muram_addr -#define qe_muram_offset cpm_muram_offset
> > > +#define cpm_muram_init qe_muram_init
> > > +#define cpm_muram_alloc qe_muram_alloc #define cpm_muram_alloc_fixed
> > > +qe_muram_alloc_fixed #define cpm_muram_free qe_muram_free #define
> > > +cpm_muram_addr qe_muram_addr #define cpm_muram_offset qe_muram_offset
> > 
> > Why?  This is unnecessary churn.
> > 
> This is necessary. QE is on both ARM and PowerPC, its code is under public 
> code.
> But CPM is only on PowerPC and its code is under PowerPC.
> So when build ARM, QE will not find cpm_muram_* function.

If you move the cpm_muram functions to drivers/soc, then ARM will find them.  
There is no need to rename them.

-Scott


^ permalink raw reply	[flat|nested] 42+ messages in thread

* RE: [PATCH V7 1/3] genalloc:support memory-allocation with bytes-alignment to genalloc
  2015-09-09 16:37         ` Scott Wood
@ 2015-09-10  2:26             ` Zhao Qiang
  0 siblings, 0 replies; 42+ messages in thread
From: Zhao Qiang @ 2015-09-10  2:26 UTC (permalink / raw)
  To: Scott Wood
  Cc: linux-kernel, linuxppc-dev, lauraa, Xiaobo Xie, benh, Li Leo, paulus

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="utf-8", Size: 4569 bytes --]

On Wed, 2015-09-10 at 12:38AM -0500, Wood Scott-B07421 wrote:
> -----Original Message-----
> From: Wood Scott-B07421
> Sent: Thursday, September 10, 2015 12:38 AM
> To: Zhao Qiang-B45475
> Cc: linux-kernel@vger.kernel.org; linuxppc-dev@lists.ozlabs.org;
> lauraa@codeaurora.org; Xie Xiaobo-R63061; benh@kernel.crashing.org; Li
> Yang-Leo-R58472; paulus@samba.org
> Subject: Re: [PATCH V7 1/3] genalloc:support memory-allocation with
> bytes-alignment to genalloc
> 
> On Sat, 2015-09-05 at 22:13 -0500, Zhao Qiang-B45475 wrote:
> > On Wed, 2015-09-02 at 10:18AM +0800, Wood Scott-B07421 wrote:
> > > -----Original Message-----
> > > From: Wood Scott-B07421
> > > Sent: Wednesday, September 02, 2015 10:18 AM
> > > To: Zhao Qiang-B45475
> > > Cc: linux-kernel@vger.kernel.org; linuxppc-dev@lists.ozlabs.org;
> > > lauraa@codeaurora.org; Xie Xiaobo-R63061; benh@kernel.crashing.org;
> > > Li Yang-Leo-R58472; paulus@samba.org
> > > Subject: Re: [PATCH V7 1/3] genalloc:support memory-allocation with
> > > bytes-alignment to genalloc
> > >
> > > On Tue, 2015-09-01 at 21:10 -0500, Zhao Qiang-B45475 wrote:
> > > > On Wed, 2015-09-02 at 08:38AM +0800, Wood Scott-B07421 wrote:
> > > > > -----Original Message-----
> > > > > From: Wood Scott-B07421
> > > > > Sent: Wednesday, September 02, 2015 8:30 AM
> > > > > To: Zhao Qiang-B45475
> > > > > Cc: linux-kernel@vger.kernel.org; linuxppc-dev@lists.ozlabs.org;
> > > > > lauraa@codeaurora.org; Xie Xiaobo-R63061;
> > > > > benh@kernel.crashing.org; Li Yang-Leo-R58472; paulus@samba.org
> > > > > Subject: Re: [PATCH V7 1/3] genalloc:support memory-allocation
> > > > > with bytes-alignment to genalloc
> > > > >
> > > > > On Mon, 2015-08-31 at 16:58 +0800, Zhao Qiang wrote:
> > > > > > 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 <qiang.zhao@freescale.com>
> > > > > > ---
> > > > > > 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.
> > > > >
> > > > > This seems to be describing more than just the changes in this
> patch.
> > > > > What does also handling cpm have to do with this patch?  Are you
> > > > > adding support for reserving a specific region in this patch?  I
> > > > > don't see it, and in any case it should go in a different patch.
> > > >
> > > > Yes, I added. The code below can support the function.
> > > >       offset_bit = (alignment->offset + (1UL << order) - 1) >>
> order;
> > > >       return bitmap_find_next_zero_area(map, size, start +
> > > > offset_bit,
> > > nr,
> > > >                         align_mask);
> > > >
> > > > CPM has an function cpm_muram_alloc_fixed, needing to allocate
> > > > muram from a Specific offset. So I add the code and add offset to
> struct data.
> > >
> > > I thought the offset was related to the previous discussion of
> > > checking for allocation failure.  Are you using it to implement
> > > alloc_fixed()?  If so, please don't.  Besides the awkward
> > > implementation (what does it logically have to do with
> > > gen_pool_first_fit_align?), it does not appear to be correct -
> > > - what happens with multiple chunks?  What happens if part of the
> > > region the caller is trying to reserve is already taken?  Implement
> > > a proper function to reserve a fixed genalloc region.
> > >
> > The offset is which allocation block address need to be larger than,
> > Not equal to, it really like the parameter start of the algo(the
> > bitnumber To start searching at).
> 
> cpm_muram_alloc_fixed() is not "search starting at this offset".  It is
> "reserve this exact range or fail".

Yes, you are right! How about to add a new algo into genalloc to search 
At offset, then handle it in muram layer, if the address return from genalloc
Is not equal to offset, return negative number?

> 
> -Scott

ÿôèº{.nÇ+‰·Ÿ®‰­†+%ŠËÿ±éݶ\x17¥Šwÿº{.nÇ+‰·¥Š{±þG«éÿŠ{ayº\x1dʇڙë,j\a­¢f£¢·hšïêÿ‘êçz_è®\x03(­éšŽŠÝ¢j"ú\x1a¶^[m§ÿÿ¾\a«þG«éÿ¢¸?™¨è­Ú&£ø§~á¶iO•æ¬z·švØ^\x14\x04\x1a¶^[m§ÿÿÃ\fÿ¶ìÿ¢¸?–I¥

^ permalink raw reply	[flat|nested] 42+ messages in thread

* RE: [PATCH V7 1/3] genalloc:support memory-allocation with bytes-alignment to genalloc
@ 2015-09-10  2:26             ` Zhao Qiang
  0 siblings, 0 replies; 42+ messages in thread
From: Zhao Qiang @ 2015-09-10  2:26 UTC (permalink / raw)
  To: Scott Wood
  Cc: linux-kernel, linuxppc-dev, lauraa, Xiaobo Xie, benh, Li Leo, paulus

T24gV2VkLCAyMDE1LTA5LTEwIGF0IDEyOjM4QU0gLTA1MDAsIFdvb2QgU2NvdHQtQjA3NDIxIHdy
b3RlOg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBXb29kIFNjb3R0LUIw
NzQyMQ0KPiBTZW50OiBUaHVyc2RheSwgU2VwdGVtYmVyIDEwLCAyMDE1IDEyOjM4IEFNDQo+IFRv
OiBaaGFvIFFpYW5nLUI0NTQ3NQ0KPiBDYzogbGludXgta2VybmVsQHZnZXIua2VybmVsLm9yZzsg
bGludXhwcGMtZGV2QGxpc3RzLm96bGFicy5vcmc7DQo+IGxhdXJhYUBjb2RlYXVyb3JhLm9yZzsg
WGllIFhpYW9iby1SNjMwNjE7IGJlbmhAa2VybmVsLmNyYXNoaW5nLm9yZzsgTGkNCj4gWWFuZy1M
ZW8tUjU4NDcyOyBwYXVsdXNAc2FtYmEub3JnDQo+IFN1YmplY3Q6IFJlOiBbUEFUQ0ggVjcgMS8z
XSBnZW5hbGxvYzpzdXBwb3J0IG1lbW9yeS1hbGxvY2F0aW9uIHdpdGgNCj4gYnl0ZXMtYWxpZ25t
ZW50IHRvIGdlbmFsbG9jDQo+IA0KPiBPbiBTYXQsIDIwMTUtMDktMDUgYXQgMjI6MTMgLTA1MDAs
IFpoYW8gUWlhbmctQjQ1NDc1IHdyb3RlOg0KPiA+IE9uIFdlZCwgMjAxNS0wOS0wMiBhdCAxMDox
OEFNICswODAwLCBXb29kIFNjb3R0LUIwNzQyMSB3cm90ZToNCj4gPiA+IC0tLS0tT3JpZ2luYWwg
TWVzc2FnZS0tLS0tDQo+ID4gPiBGcm9tOiBXb29kIFNjb3R0LUIwNzQyMQ0KPiA+ID4gU2VudDog
V2VkbmVzZGF5LCBTZXB0ZW1iZXIgMDIsIDIwMTUgMTA6MTggQU0NCj4gPiA+IFRvOiBaaGFvIFFp
YW5nLUI0NTQ3NQ0KPiA+ID4gQ2M6IGxpbnV4LWtlcm5lbEB2Z2VyLmtlcm5lbC5vcmc7IGxpbnV4
cHBjLWRldkBsaXN0cy5vemxhYnMub3JnOw0KPiA+ID4gbGF1cmFhQGNvZGVhdXJvcmEub3JnOyBY
aWUgWGlhb2JvLVI2MzA2MTsgYmVuaEBrZXJuZWwuY3Jhc2hpbmcub3JnOw0KPiA+ID4gTGkgWWFu
Zy1MZW8tUjU4NDcyOyBwYXVsdXNAc2FtYmEub3JnDQo+ID4gPiBTdWJqZWN0OiBSZTogW1BBVENI
IFY3IDEvM10gZ2VuYWxsb2M6c3VwcG9ydCBtZW1vcnktYWxsb2NhdGlvbiB3aXRoDQo+ID4gPiBi
eXRlcy1hbGlnbm1lbnQgdG8gZ2VuYWxsb2MNCj4gPiA+DQo+ID4gPiBPbiBUdWUsIDIwMTUtMDkt
MDEgYXQgMjE6MTAgLTA1MDAsIFpoYW8gUWlhbmctQjQ1NDc1IHdyb3RlOg0KPiA+ID4gPiBPbiBX
ZWQsIDIwMTUtMDktMDIgYXQgMDg6MzhBTSArMDgwMCwgV29vZCBTY290dC1CMDc0MjEgd3JvdGU6
DQo+ID4gPiA+ID4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPiA+ID4gPiBGcm9tOiBX
b29kIFNjb3R0LUIwNzQyMQ0KPiA+ID4gPiA+IFNlbnQ6IFdlZG5lc2RheSwgU2VwdGVtYmVyIDAy
LCAyMDE1IDg6MzAgQU0NCj4gPiA+ID4gPiBUbzogWmhhbyBRaWFuZy1CNDU0NzUNCj4gPiA+ID4g
PiBDYzogbGludXgta2VybmVsQHZnZXIua2VybmVsLm9yZzsgbGludXhwcGMtZGV2QGxpc3RzLm96
bGFicy5vcmc7DQo+ID4gPiA+ID4gbGF1cmFhQGNvZGVhdXJvcmEub3JnOyBYaWUgWGlhb2JvLVI2
MzA2MTsNCj4gPiA+ID4gPiBiZW5oQGtlcm5lbC5jcmFzaGluZy5vcmc7IExpIFlhbmctTGVvLVI1
ODQ3MjsgcGF1bHVzQHNhbWJhLm9yZw0KPiA+ID4gPiA+IFN1YmplY3Q6IFJlOiBbUEFUQ0ggVjcg
MS8zXSBnZW5hbGxvYzpzdXBwb3J0IG1lbW9yeS1hbGxvY2F0aW9uDQo+ID4gPiA+ID4gd2l0aCBi
eXRlcy1hbGlnbm1lbnQgdG8gZ2VuYWxsb2MNCj4gPiA+ID4gPg0KPiA+ID4gPiA+IE9uIE1vbiwg
MjAxNS0wOC0zMSBhdCAxNjo1OCArMDgwMCwgWmhhbyBRaWFuZyB3cm90ZToNCj4gPiA+ID4gPiA+
IEJ5dGVzIGFsaWdubWVudCBpcyByZXF1aXJlZCB0byBtYW5hZ2Ugc29tZSBzcGVjaWFsIFJBTSwg
c28gYWRkDQo+ID4gPiA+ID4gPiBnZW5fcG9vbF9maXJzdF9maXRfYWxpZ24gdG8gZ2VuYWxsb2Ms
IG1lYW53aGlsZSBhZGQNCj4gPiA+ID4gPiA+IGdlbl9wb29sX2FsbG9jX2RhdGEgdG8gcGFzcyBk
YXRhIHRvDQo+ID4gPiA+ID4gPiBnZW5fcG9vbF9maXJzdF9maXRfYWxpZ24obW9kaWZ5IGdlbl9w
b29sX2FsbG9jIGFzIGEgd3JhcHBlcikNCj4gPiA+ID4gPiA+DQo+ID4gPiA+ID4gPiBTaWduZWQt
b2ZmLWJ5OiBaaGFvIFFpYW5nIDxxaWFuZy56aGFvQGZyZWVzY2FsZS5jb20+DQo+ID4gPiA+ID4g
PiAtLS0NCj4gPiA+ID4gPiA+IENoYW5nZXMgZm9yIHY2Og0KPiA+ID4gPiA+ID4gICAgICAgLSBw
YXRjaGVzIHNldCB2NiBpbmNsdWRlIGEgbmV3IHBhdGNoIGJlY2F1c2Ugb2YgdXNpbmcNCj4gPiA+
ID4gPiA+ICAgICAgIC0gZ2VuYWxsb2MgdG8gbWFuYWdlIFFFIE1VUkFNLCBwYXRjaCAwMDAxIGlz
IHRoZSBuZXcNCj4gPiA+ID4gPiA+ICAgICAgIC0gcGF0Y2gsIGFkZGluZyBieXRlcyBhbGlnbm1l
bnQgZm9yIGFsbG9jYXRpb24gZm9yIHVzZS4NCj4gPiA+ID4gPiA+IENoYW5nZXMgZm9yIHY3Og0K
PiA+ID4gPiA+ID4gICAgICAgLSBjcG0gbXVyYW0gYWxzbyBuZWVkIHRvIHVzZSBnZW5hbGxvYyB0
byBtYW5hZ2UsIGl0IGhhcw0KPiA+ID4gPiA+ID4gICAgICAgICBhIGZ1bmN0aW9uIHRvIHJlc2Vy
dmUgYSBzcGVjaWZpYyByZWdpb24gb2YgbXVyYW0sDQo+ID4gPiA+ID4gPiAgICAgICAgIGFkZCBv
ZmZzZXQgdG8gZ2VucG9vbF9kYXRhIGZvciBzdGFydCBhZGRyIHRvIGJlDQo+IGFsbG9jYXRlZC4N
Cj4gPiA+ID4gPg0KPiA+ID4gPiA+IFRoaXMgc2VlbXMgdG8gYmUgZGVzY3JpYmluZyBtb3JlIHRo
YW4ganVzdCB0aGUgY2hhbmdlcyBpbiB0aGlzDQo+IHBhdGNoLg0KPiA+ID4gPiA+IFdoYXQgZG9l
cyBhbHNvIGhhbmRsaW5nIGNwbSBoYXZlIHRvIGRvIHdpdGggdGhpcyBwYXRjaD8gIEFyZSB5b3UN
Cj4gPiA+ID4gPiBhZGRpbmcgc3VwcG9ydCBmb3IgcmVzZXJ2aW5nIGEgc3BlY2lmaWMgcmVnaW9u
IGluIHRoaXMgcGF0Y2g/ICBJDQo+ID4gPiA+ID4gZG9uJ3Qgc2VlIGl0LCBhbmQgaW4gYW55IGNh
c2UgaXQgc2hvdWxkIGdvIGluIGEgZGlmZmVyZW50IHBhdGNoLg0KPiA+ID4gPg0KPiA+ID4gPiBZ
ZXMsIEkgYWRkZWQuIFRoZSBjb2RlIGJlbG93IGNhbiBzdXBwb3J0IHRoZSBmdW5jdGlvbi4NCj4g
PiA+ID4gICAgICAgb2Zmc2V0X2JpdCA9IChhbGlnbm1lbnQtPm9mZnNldCArICgxVUwgPDwgb3Jk
ZXIpIC0gMSkgPj4NCj4gb3JkZXI7DQo+ID4gPiA+ICAgICAgIHJldHVybiBiaXRtYXBfZmluZF9u
ZXh0X3plcm9fYXJlYShtYXAsIHNpemUsIHN0YXJ0ICsNCj4gPiA+ID4gb2Zmc2V0X2JpdCwNCj4g
PiA+IG5yLA0KPiA+ID4gPiAgICAgICAgICAgICAgICAgICAgICAgICBhbGlnbl9tYXNrKTsNCj4g
PiA+ID4NCj4gPiA+ID4gQ1BNIGhhcyBhbiBmdW5jdGlvbiBjcG1fbXVyYW1fYWxsb2NfZml4ZWQs
IG5lZWRpbmcgdG8gYWxsb2NhdGUNCj4gPiA+ID4gbXVyYW0gZnJvbSBhIFNwZWNpZmljIG9mZnNl
dC4gU28gSSBhZGQgdGhlIGNvZGUgYW5kIGFkZCBvZmZzZXQgdG8NCj4gc3RydWN0IGRhdGEuDQo+
ID4gPg0KPiA+ID4gSSB0aG91Z2h0IHRoZSBvZmZzZXQgd2FzIHJlbGF0ZWQgdG8gdGhlIHByZXZp
b3VzIGRpc2N1c3Npb24gb2YNCj4gPiA+IGNoZWNraW5nIGZvciBhbGxvY2F0aW9uIGZhaWx1cmUu
ICBBcmUgeW91IHVzaW5nIGl0IHRvIGltcGxlbWVudA0KPiA+ID4gYWxsb2NfZml4ZWQoKT8gIElm
IHNvLCBwbGVhc2UgZG9uJ3QuICBCZXNpZGVzIHRoZSBhd2t3YXJkDQo+ID4gPiBpbXBsZW1lbnRh
dGlvbiAod2hhdCBkb2VzIGl0IGxvZ2ljYWxseSBoYXZlIHRvIGRvIHdpdGgNCj4gPiA+IGdlbl9w
b29sX2ZpcnN0X2ZpdF9hbGlnbj8pLCBpdCBkb2VzIG5vdCBhcHBlYXIgdG8gYmUgY29ycmVjdCAt
DQo+ID4gPiAtIHdoYXQgaGFwcGVucyB3aXRoIG11bHRpcGxlIGNodW5rcz8gIFdoYXQgaGFwcGVu
cyBpZiBwYXJ0IG9mIHRoZQ0KPiA+ID4gcmVnaW9uIHRoZSBjYWxsZXIgaXMgdHJ5aW5nIHRvIHJl
c2VydmUgaXMgYWxyZWFkeSB0YWtlbj8gIEltcGxlbWVudA0KPiA+ID4gYSBwcm9wZXIgZnVuY3Rp
b24gdG8gcmVzZXJ2ZSBhIGZpeGVkIGdlbmFsbG9jIHJlZ2lvbi4NCj4gPiA+DQo+ID4gVGhlIG9m
ZnNldCBpcyB3aGljaCBhbGxvY2F0aW9uIGJsb2NrIGFkZHJlc3MgbmVlZCB0byBiZSBsYXJnZXIg
dGhhbiwNCj4gPiBOb3QgZXF1YWwgdG8sIGl0IHJlYWxseSBsaWtlIHRoZSBwYXJhbWV0ZXIgc3Rh
cnQgb2YgdGhlIGFsZ28odGhlDQo+ID4gYml0bnVtYmVyIFRvIHN0YXJ0IHNlYXJjaGluZyBhdCku
DQo+IA0KPiBjcG1fbXVyYW1fYWxsb2NfZml4ZWQoKSBpcyBub3QgInNlYXJjaCBzdGFydGluZyBh
dCB0aGlzIG9mZnNldCIuICBJdCBpcw0KPiAicmVzZXJ2ZSB0aGlzIGV4YWN0IHJhbmdlIG9yIGZh
aWwiLg0KDQpZZXMsIHlvdSBhcmUgcmlnaHQhIEhvdyBhYm91dCB0byBhZGQgYSBuZXcgYWxnbyBp
bnRvIGdlbmFsbG9jIHRvIHNlYXJjaCANCkF0IG9mZnNldCwgdGhlbiBoYW5kbGUgaXQgaW4gbXVy
YW0gbGF5ZXIsIGlmIHRoZSBhZGRyZXNzIHJldHVybiBmcm9tIGdlbmFsbG9jDQpJcyBub3QgZXF1
YWwgdG8gb2Zmc2V0LCByZXR1cm4gbmVnYXRpdmUgbnVtYmVyPw0KDQo+IA0KPiAtU2NvdHQNCg0K

^ permalink raw reply	[flat|nested] 42+ messages in thread

* RE: [PATCH V7 2/3] qe_common: add qe_muram_ functions to manage muram
  2015-09-09 16:38       ` Scott Wood
@ 2015-09-10  2:34           ` Zhao Qiang
  0 siblings, 0 replies; 42+ messages in thread
From: Zhao Qiang @ 2015-09-10  2:34 UTC (permalink / raw)
  To: Scott Wood
  Cc: linux-kernel, linuxppc-dev, lauraa, Xiaobo Xie, benh, Li Leo, paulus

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="utf-8", Size: 2554 bytes --]

On Mon, 2015-09-10 at 12:39 -0500, Wood Scott-B07421 wrote:

> -----Original Message-----
> From: Wood Scott-B07421
> Sent: Thursday, September 10, 2015 12:39 AM
> To: Zhao Qiang-B45475
> Cc: linux-kernel@vger.kernel.org; linuxppc-dev@lists.ozlabs.org;
> lauraa@codeaurora.org; Xie Xiaobo-R63061; benh@kernel.crashing.org; Li
> Yang-Leo-R58472; paulus@samba.org
> Subject: Re: [PATCH V7 2/3] qe_common: add qe_muram_ functions to manage
> muram
> 
> On Sun, 2015-09-06 at 01:37 -0500, Zhao Qiang-B45475 wrote:
> > On Mon, 2015-09-2 at 8:34 +0800, Wood Scott-B07421 wrote:
> > > -----Original Message-----
> > > From: Wood Scott-B07421
> > > Sent: Wednesday, September 02, 2015 8:34 AM
> > > To: Zhao Qiang-B45475
> > > Cc: linux-kernel@vger.kernel.org; linuxppc-dev@lists.ozlabs.org;
> > > lauraa@codeaurora.org; Xie Xiaobo-R63061; benh@kernel.crashing.org;
> > > Li Yang-Leo-R58472; paulus@samba.org
> > > Subject: Re: [PATCH V7 2/3] qe_common: add qe_muram_ functions to
> > > manage muram
> > >
> > > On Mon, 2015-08-31 at 16:58 +0800, Zhao Qiang wrote:
> > >
> > > > @@ -187,12 +190,25 @@ static inline int
> > > > qe_alive_during_sleep(void)  }
> > > >
> > > >  /* we actually use cpm_muram implementation, define this for
> > > > convenience */ -#define qe_muram_init cpm_muram_init -#define
> > > > qe_muram_alloc cpm_muram_alloc -#define qe_muram_alloc_fixed
> > > > cpm_muram_alloc_fixed -#define qe_muram_free cpm_muram_free
> > > > -#define qe_muram_addr cpm_muram_addr -#define qe_muram_offset
> > > > cpm_muram_offset
> > > > +#define cpm_muram_init qe_muram_init #define cpm_muram_alloc
> > > > +qe_muram_alloc #define cpm_muram_alloc_fixed qe_muram_alloc_fixed
> > > > +#define cpm_muram_free qe_muram_free #define cpm_muram_addr
> > > > +qe_muram_addr #define cpm_muram_offset qe_muram_offset
> > >
> > > Why?  This is unnecessary churn.
> > >
> > This is necessary. QE is on both ARM and PowerPC, its code is under
> > public code.
> > But CPM is only on PowerPC and its code is under PowerPC.
> > So when build ARM, QE will not find cpm_muram_* function.
> 
> If you move the cpm_muram functions to drivers/soc, then ARM will find
> them.
> There is no need to rename them.

Yes, moving cpm_muram can handle this issue. However, cpm is not necessary
To move to public code, and a churn is simpler than moving cpm_muram.
Please consider my suggestion, Thank you!

> 
> -Scott

ÿôèº{.nÇ+‰·Ÿ®‰­†+%ŠËÿ±éݶ\x17¥Šwÿº{.nÇ+‰·¥Š{±þG«éÿŠ{ayº\x1dʇڙë,j\a­¢f£¢·hšïêÿ‘êçz_è®\x03(­éšŽŠÝ¢j"ú\x1a¶^[m§ÿÿ¾\a«þG«éÿ¢¸?™¨è­Ú&£ø§~á¶iO•æ¬z·švØ^\x14\x04\x1a¶^[m§ÿÿÃ\fÿ¶ìÿ¢¸?–I¥

^ permalink raw reply	[flat|nested] 42+ messages in thread

* RE: [PATCH V7 2/3] qe_common: add qe_muram_ functions to manage muram
@ 2015-09-10  2:34           ` Zhao Qiang
  0 siblings, 0 replies; 42+ messages in thread
From: Zhao Qiang @ 2015-09-10  2:34 UTC (permalink / raw)
  To: Scott Wood
  Cc: linux-kernel, linuxppc-dev, lauraa, Xiaobo Xie, benh, Li Leo, paulus

T24gTW9uLCAyMDE1LTA5LTEwIGF0IDEyOjM5IC0wNTAwLCBXb29kIFNjb3R0LUIwNzQyMSB3cm90
ZToNCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBXb29kIFNjb3R0LUIw
NzQyMQ0KPiBTZW50OiBUaHVyc2RheSwgU2VwdGVtYmVyIDEwLCAyMDE1IDEyOjM5IEFNDQo+IFRv
OiBaaGFvIFFpYW5nLUI0NTQ3NQ0KPiBDYzogbGludXgta2VybmVsQHZnZXIua2VybmVsLm9yZzsg
bGludXhwcGMtZGV2QGxpc3RzLm96bGFicy5vcmc7DQo+IGxhdXJhYUBjb2RlYXVyb3JhLm9yZzsg
WGllIFhpYW9iby1SNjMwNjE7IGJlbmhAa2VybmVsLmNyYXNoaW5nLm9yZzsgTGkNCj4gWWFuZy1M
ZW8tUjU4NDcyOyBwYXVsdXNAc2FtYmEub3JnDQo+IFN1YmplY3Q6IFJlOiBbUEFUQ0ggVjcgMi8z
XSBxZV9jb21tb246IGFkZCBxZV9tdXJhbV8gZnVuY3Rpb25zIHRvIG1hbmFnZQ0KPiBtdXJhbQ0K
PiANCj4gT24gU3VuLCAyMDE1LTA5LTA2IGF0IDAxOjM3IC0wNTAwLCBaaGFvIFFpYW5nLUI0NTQ3
NSB3cm90ZToNCj4gPiBPbiBNb24sIDIwMTUtMDktMiBhdCA4OjM0ICswODAwLCBXb29kIFNjb3R0
LUIwNzQyMSB3cm90ZToNCj4gPiA+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4gPiBG
cm9tOiBXb29kIFNjb3R0LUIwNzQyMQ0KPiA+ID4gU2VudDogV2VkbmVzZGF5LCBTZXB0ZW1iZXIg
MDIsIDIwMTUgODozNCBBTQ0KPiA+ID4gVG86IFpoYW8gUWlhbmctQjQ1NDc1DQo+ID4gPiBDYzog
bGludXgta2VybmVsQHZnZXIua2VybmVsLm9yZzsgbGludXhwcGMtZGV2QGxpc3RzLm96bGFicy5v
cmc7DQo+ID4gPiBsYXVyYWFAY29kZWF1cm9yYS5vcmc7IFhpZSBYaWFvYm8tUjYzMDYxOyBiZW5o
QGtlcm5lbC5jcmFzaGluZy5vcmc7DQo+ID4gPiBMaSBZYW5nLUxlby1SNTg0NzI7IHBhdWx1c0Bz
YW1iYS5vcmcNCj4gPiA+IFN1YmplY3Q6IFJlOiBbUEFUQ0ggVjcgMi8zXSBxZV9jb21tb246IGFk
ZCBxZV9tdXJhbV8gZnVuY3Rpb25zIHRvDQo+ID4gPiBtYW5hZ2UgbXVyYW0NCj4gPiA+DQo+ID4g
PiBPbiBNb24sIDIwMTUtMDgtMzEgYXQgMTY6NTggKzA4MDAsIFpoYW8gUWlhbmcgd3JvdGU6DQo+
ID4gPg0KPiA+ID4gPiBAQCAtMTg3LDEyICsxOTAsMjUgQEAgc3RhdGljIGlubGluZSBpbnQNCj4g
PiA+ID4gcWVfYWxpdmVfZHVyaW5nX3NsZWVwKHZvaWQpICB9DQo+ID4gPiA+DQo+ID4gPiA+ICAv
KiB3ZSBhY3R1YWxseSB1c2UgY3BtX211cmFtIGltcGxlbWVudGF0aW9uLCBkZWZpbmUgdGhpcyBm
b3INCj4gPiA+ID4gY29udmVuaWVuY2UgKi8gLSNkZWZpbmUgcWVfbXVyYW1faW5pdCBjcG1fbXVy
YW1faW5pdCAtI2RlZmluZQ0KPiA+ID4gPiBxZV9tdXJhbV9hbGxvYyBjcG1fbXVyYW1fYWxsb2Mg
LSNkZWZpbmUgcWVfbXVyYW1fYWxsb2NfZml4ZWQNCj4gPiA+ID4gY3BtX211cmFtX2FsbG9jX2Zp
eGVkIC0jZGVmaW5lIHFlX211cmFtX2ZyZWUgY3BtX211cmFtX2ZyZWUNCj4gPiA+ID4gLSNkZWZp
bmUgcWVfbXVyYW1fYWRkciBjcG1fbXVyYW1fYWRkciAtI2RlZmluZSBxZV9tdXJhbV9vZmZzZXQN
Cj4gPiA+ID4gY3BtX211cmFtX29mZnNldA0KPiA+ID4gPiArI2RlZmluZSBjcG1fbXVyYW1faW5p
dCBxZV9tdXJhbV9pbml0ICNkZWZpbmUgY3BtX211cmFtX2FsbG9jDQo+ID4gPiA+ICtxZV9tdXJh
bV9hbGxvYyAjZGVmaW5lIGNwbV9tdXJhbV9hbGxvY19maXhlZCBxZV9tdXJhbV9hbGxvY19maXhl
ZA0KPiA+ID4gPiArI2RlZmluZSBjcG1fbXVyYW1fZnJlZSBxZV9tdXJhbV9mcmVlICNkZWZpbmUg
Y3BtX211cmFtX2FkZHINCj4gPiA+ID4gK3FlX211cmFtX2FkZHIgI2RlZmluZSBjcG1fbXVyYW1f
b2Zmc2V0IHFlX211cmFtX29mZnNldA0KPiA+ID4NCj4gPiA+IFdoeT8gIFRoaXMgaXMgdW5uZWNl
c3NhcnkgY2h1cm4uDQo+ID4gPg0KPiA+IFRoaXMgaXMgbmVjZXNzYXJ5LiBRRSBpcyBvbiBib3Ro
IEFSTSBhbmQgUG93ZXJQQywgaXRzIGNvZGUgaXMgdW5kZXINCj4gPiBwdWJsaWMgY29kZS4NCj4g
PiBCdXQgQ1BNIGlzIG9ubHkgb24gUG93ZXJQQyBhbmQgaXRzIGNvZGUgaXMgdW5kZXIgUG93ZXJQ
Qy4NCj4gPiBTbyB3aGVuIGJ1aWxkIEFSTSwgUUUgd2lsbCBub3QgZmluZCBjcG1fbXVyYW1fKiBm
dW5jdGlvbi4NCj4gDQo+IElmIHlvdSBtb3ZlIHRoZSBjcG1fbXVyYW0gZnVuY3Rpb25zIHRvIGRy
aXZlcnMvc29jLCB0aGVuIEFSTSB3aWxsIGZpbmQNCj4gdGhlbS4NCj4gVGhlcmUgaXMgbm8gbmVl
ZCB0byByZW5hbWUgdGhlbS4NCg0KWWVzLCBtb3ZpbmcgY3BtX211cmFtIGNhbiBoYW5kbGUgdGhp
cyBpc3N1ZS4gSG93ZXZlciwgY3BtIGlzIG5vdCBuZWNlc3NhcnkNClRvIG1vdmUgdG8gcHVibGlj
IGNvZGUsIGFuZCBhIGNodXJuIGlzIHNpbXBsZXIgdGhhbiBtb3ZpbmcgY3BtX211cmFtLg0KUGxl
YXNlIGNvbnNpZGVyIG15IHN1Z2dlc3Rpb24sIFRoYW5rIHlvdSENCg0KPiANCj4gLVNjb3R0DQoN
Cg==

^ permalink raw reply	[flat|nested] 42+ messages in thread

* Re: [PATCH V7 1/3] genalloc:support memory-allocation with bytes-alignment to genalloc
  2015-09-10  2:26             ` Zhao Qiang
  (?)
@ 2015-09-10 22:07             ` Scott Wood
  2015-09-11  2:09                 ` Zhao Qiang
  -1 siblings, 1 reply; 42+ messages in thread
From: Scott Wood @ 2015-09-10 22:07 UTC (permalink / raw)
  To: Zhao Qiang-B45475
  Cc: linux-kernel, linuxppc-dev, lauraa, Xie Xiaobo-R63061, benh,
	Li Yang-Leo-R58472, paulus

On Wed, 2015-09-09 at 21:26 -0500, Zhao Qiang-B45475 wrote:
> On Wed, 2015-09-10 at 12:38AM -0500, Wood Scott-B07421 wrote:
> > -----Original Message-----
> > From: Wood Scott-B07421
> > Sent: Thursday, September 10, 2015 12:38 AM
> > To: Zhao Qiang-B45475
> > Cc: linux-kernel@vger.kernel.org; linuxppc-dev@lists.ozlabs.org;
> > lauraa@codeaurora.org; Xie Xiaobo-R63061; benh@kernel.crashing.org; Li
> > Yang-Leo-R58472; paulus@samba.org
> > Subject: Re: [PATCH V7 1/3] genalloc:support memory-allocation with
> > bytes-alignment to genalloc
> > 
> > On Sat, 2015-09-05 at 22:13 -0500, Zhao Qiang-B45475 wrote:
> > > On Wed, 2015-09-02 at 10:18AM +0800, Wood Scott-B07421 wrote:
> > > > -----Original Message-----
> > > > From: Wood Scott-B07421
> > > > Sent: Wednesday, September 02, 2015 10:18 AM
> > > > To: Zhao Qiang-B45475
> > > > Cc: linux-kernel@vger.kernel.org; linuxppc-dev@lists.ozlabs.org;
> > > > lauraa@codeaurora.org; Xie Xiaobo-R63061; benh@kernel.crashing.org;
> > > > Li Yang-Leo-R58472; paulus@samba.org
> > > > Subject: Re: [PATCH V7 1/3] genalloc:support memory-allocation with
> > > > bytes-alignment to genalloc
> > > > 
> > > > On Tue, 2015-09-01 at 21:10 -0500, Zhao Qiang-B45475 wrote:
> > > > > On Wed, 2015-09-02 at 08:38AM +0800, Wood Scott-B07421 wrote:
> > > > > > -----Original Message-----
> > > > > > From: Wood Scott-B07421
> > > > > > Sent: Wednesday, September 02, 2015 8:30 AM
> > > > > > To: Zhao Qiang-B45475
> > > > > > Cc: linux-kernel@vger.kernel.org; linuxppc-dev@lists.ozlabs.org;
> > > > > > lauraa@codeaurora.org; Xie Xiaobo-R63061;
> > > > > > benh@kernel.crashing.org; Li Yang-Leo-R58472; paulus@samba.org
> > > > > > Subject: Re: [PATCH V7 1/3] genalloc:support memory-allocation
> > > > > > with bytes-alignment to genalloc
> > > > > > 
> > > > > > On Mon, 2015-08-31 at 16:58 +0800, Zhao Qiang wrote:
> > > > > > > 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 <qiang.zhao@freescale.com>
> > > > > > > ---
> > > > > > > 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.
> > > > > > 
> > > > > > This seems to be describing more than just the changes in this
> > patch.
> > > > > > What does also handling cpm have to do with this patch?  Are you
> > > > > > adding support for reserving a specific region in this patch?  I
> > > > > > don't see it, and in any case it should go in a different patch.
> > > > > 
> > > > > Yes, I added. The code below can support the function.
> > > > >       offset_bit = (alignment->offset + (1UL << order) - 1) >>
> > order;
> > > > >       return bitmap_find_next_zero_area(map, size, start +
> > > > > offset_bit,
> > > > nr,
> > > > >                         align_mask);
> > > > > 
> > > > > CPM has an function cpm_muram_alloc_fixed, needing to allocate
> > > > > muram from a Specific offset. So I add the code and add offset to
> > struct data.
> > > > 
> > > > I thought the offset was related to the previous discussion of
> > > > checking for allocation failure.  Are you using it to implement
> > > > alloc_fixed()?  If so, please don't.  Besides the awkward
> > > > implementation (what does it logically have to do with
> > > > gen_pool_first_fit_align?), it does not appear to be correct -
> > > > - what happens with multiple chunks?  What happens if part of the
> > > > region the caller is trying to reserve is already taken?  Implement
> > > > a proper function to reserve a fixed genalloc region.
> > > > 
> > > The offset is which allocation block address need to be larger than,
> > > Not equal to, it really like the parameter start of the algo(the
> > > bitnumber To start searching at).
> > 
> > cpm_muram_alloc_fixed() is not "search starting at this offset".  It is
> > "reserve this exact range or fail".
> 
> Yes, you are right! How about to add a new algo into genalloc to search 
> At offset, then handle it in muram layer, if the address return from 
> genalloc
> Is not equal to offset, return negative number?

If you're adding a new algorithm, why not make it actually do what you want 
rather than adding something different and fixing it up in the caller?

-Scott


^ permalink raw reply	[flat|nested] 42+ messages in thread

* Re: [PATCH V7 2/3] qe_common: add qe_muram_ functions to manage muram
  2015-09-10  2:34           ` Zhao Qiang
  (?)
@ 2015-09-10 22:09           ` Scott Wood
  2015-09-11  1:59               ` Zhao Qiang
  -1 siblings, 1 reply; 42+ messages in thread
From: Scott Wood @ 2015-09-10 22:09 UTC (permalink / raw)
  To: Zhao Qiang-B45475
  Cc: linux-kernel, linuxppc-dev, lauraa, Xie Xiaobo-R63061, benh,
	Li Yang-Leo-R58472, paulus

On Wed, 2015-09-09 at 21:34 -0500, Zhao Qiang-B45475 wrote:
> On Mon, 2015-09-10 at 12:39 -0500, Wood Scott-B07421 wrote:
> 
> > -----Original Message-----
> > From: Wood Scott-B07421
> > Sent: Thursday, September 10, 2015 12:39 AM
> > To: Zhao Qiang-B45475
> > Cc: linux-kernel@vger.kernel.org; linuxppc-dev@lists.ozlabs.org;
> > lauraa@codeaurora.org; Xie Xiaobo-R63061; benh@kernel.crashing.org; Li
> > Yang-Leo-R58472; paulus@samba.org
> > Subject: Re: [PATCH V7 2/3] qe_common: add qe_muram_ functions to manage
> > muram
> > 
> > On Sun, 2015-09-06 at 01:37 -0500, Zhao Qiang-B45475 wrote:
> > > On Mon, 2015-09-2 at 8:34 +0800, Wood Scott-B07421 wrote:
> > > > -----Original Message-----
> > > > From: Wood Scott-B07421
> > > > Sent: Wednesday, September 02, 2015 8:34 AM
> > > > To: Zhao Qiang-B45475
> > > > Cc: linux-kernel@vger.kernel.org; linuxppc-dev@lists.ozlabs.org;
> > > > lauraa@codeaurora.org; Xie Xiaobo-R63061; benh@kernel.crashing.org;
> > > > Li Yang-Leo-R58472; paulus@samba.org
> > > > Subject: Re: [PATCH V7 2/3] qe_common: add qe_muram_ functions to
> > > > manage muram
> > > > 
> > > > On Mon, 2015-08-31 at 16:58 +0800, Zhao Qiang wrote:
> > > > 
> > > > > @@ -187,12 +190,25 @@ static inline int
> > > > > qe_alive_during_sleep(void)  }
> > > > > 
> > > > >  /* we actually use cpm_muram implementation, define this for
> > > > > convenience */ -#define qe_muram_init cpm_muram_init -#define
> > > > > qe_muram_alloc cpm_muram_alloc -#define qe_muram_alloc_fixed
> > > > > cpm_muram_alloc_fixed -#define qe_muram_free cpm_muram_free
> > > > > -#define qe_muram_addr cpm_muram_addr -#define qe_muram_offset
> > > > > cpm_muram_offset
> > > > > +#define cpm_muram_init qe_muram_init #define cpm_muram_alloc
> > > > > +qe_muram_alloc #define cpm_muram_alloc_fixed qe_muram_alloc_fixed
> > > > > +#define cpm_muram_free qe_muram_free #define cpm_muram_addr
> > > > > +qe_muram_addr #define cpm_muram_offset qe_muram_offset
> > > > 
> > > > Why?  This is unnecessary churn.
> > > > 
> > > This is necessary. QE is on both ARM and PowerPC, its code is under
> > > public code.
> > > But CPM is only on PowerPC and its code is under PowerPC.
> > > So when build ARM, QE will not find cpm_muram_* function.
> > 
> > If you move the cpm_muram functions to drivers/soc, then ARM will find
> > them.
> > There is no need to rename them.
> 
> Yes, moving cpm_muram can handle this issue. However, cpm is not necessary
> To move to public code, and a churn is simpler than moving cpm_muram.
> Please consider my suggestion, Thank you!

What do you mean by "public code"?  You're already moving cpm_muram.  I'm 
just asking that you not rename it while you do so.  If it absolutely must be 
renamed, do it in a different patch from the one that moves the code, though I
don't see why the rename is helpful.

-Scott



^ permalink raw reply	[flat|nested] 42+ messages in thread

* RE: [PATCH V7 2/3] qe_common: add qe_muram_ functions to manage muram
  2015-09-10 22:09           ` Scott Wood
@ 2015-09-11  1:59               ` Zhao Qiang
  0 siblings, 0 replies; 42+ messages in thread
From: Zhao Qiang @ 2015-09-11  1:59 UTC (permalink / raw)
  To: Scott Wood
  Cc: linux-kernel, linuxppc-dev, lauraa, Xiaobo Xie, benh, Li Leo, paulus

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="utf-8", Size: 4144 bytes --]

On Mon, 2015-09-11 at 06:09 -0500, Wood Scott-B07421 wrote:
> -----Original Message-----
> From: Wood Scott-B07421
> Sent: Friday, September 11, 2015 6:09 AM
> To: Zhao Qiang-B45475
> Cc: linux-kernel@vger.kernel.org; linuxppc-dev@lists.ozlabs.org;
> lauraa@codeaurora.org; Xie Xiaobo-R63061; benh@kernel.crashing.org; Li
> Yang-Leo-R58472; paulus@samba.org
> Subject: Re: [PATCH V7 2/3] qe_common: add qe_muram_ functions to manage
> muram
> 
> On Wed, 2015-09-09 at 21:34 -0500, Zhao Qiang-B45475 wrote:
> > On Mon, 2015-09-10 at 12:39 -0500, Wood Scott-B07421 wrote:
> >
> > > -----Original Message-----
> > > From: Wood Scott-B07421
> > > Sent: Thursday, September 10, 2015 12:39 AM
> > > To: Zhao Qiang-B45475
> > > Cc: linux-kernel@vger.kernel.org; linuxppc-dev@lists.ozlabs.org;
> > > lauraa@codeaurora.org; Xie Xiaobo-R63061; benh@kernel.crashing.org;
> > > Li Yang-Leo-R58472; paulus@samba.org
> > > Subject: Re: [PATCH V7 2/3] qe_common: add qe_muram_ functions to
> > > manage muram
> > >
> > > On Sun, 2015-09-06 at 01:37 -0500, Zhao Qiang-B45475 wrote:
> > > > On Mon, 2015-09-2 at 8:34 +0800, Wood Scott-B07421 wrote:
> > > > > -----Original Message-----
> > > > > From: Wood Scott-B07421
> > > > > Sent: Wednesday, September 02, 2015 8:34 AM
> > > > > To: Zhao Qiang-B45475
> > > > > Cc: linux-kernel@vger.kernel.org; linuxppc-dev@lists.ozlabs.org;
> > > > > lauraa@codeaurora.org; Xie Xiaobo-R63061;
> > > > > benh@kernel.crashing.org; Li Yang-Leo-R58472; paulus@samba.org
> > > > > Subject: Re: [PATCH V7 2/3] qe_common: add qe_muram_ functions
> > > > > to manage muram
> > > > >
> > > > > On Mon, 2015-08-31 at 16:58 +0800, Zhao Qiang wrote:
> > > > >
> > > > > > @@ -187,12 +190,25 @@ static inline int
> > > > > > qe_alive_during_sleep(void)  }
> > > > > >
> > > > > >  /* we actually use cpm_muram implementation, define this for
> > > > > > convenience */ -#define qe_muram_init cpm_muram_init -#define
> > > > > > qe_muram_alloc cpm_muram_alloc -#define qe_muram_alloc_fixed
> > > > > > cpm_muram_alloc_fixed -#define qe_muram_free cpm_muram_free
> > > > > > -#define qe_muram_addr cpm_muram_addr -#define qe_muram_offset
> > > > > > cpm_muram_offset
> > > > > > +#define cpm_muram_init qe_muram_init #define cpm_muram_alloc
> > > > > > +qe_muram_alloc #define cpm_muram_alloc_fixed
> > > > > > +qe_muram_alloc_fixed #define cpm_muram_free qe_muram_free
> > > > > > +#define cpm_muram_addr qe_muram_addr #define cpm_muram_offset
> > > > > > +qe_muram_offset
> > > > >
> > > > > Why?  This is unnecessary churn.
> > > > >
> > > > This is necessary. QE is on both ARM and PowerPC, its code is
> > > > under public code.
> > > > But CPM is only on PowerPC and its code is under PowerPC.
> > > > So when build ARM, QE will not find cpm_muram_* function.
> > >
> > > If you move the cpm_muram functions to drivers/soc, then ARM will
> > > find them.
> > > There is no need to rename them.
> >
> > Yes, moving cpm_muram can handle this issue. However, cpm is not
> > necessary To move to public code, and a churn is simpler than moving
> cpm_muram.
> > Please consider my suggestion, Thank you!
> 
> What do you mean by "public code"?  You're already moving cpm_muram.  I'm
> just asking that you not rename it while you do so.  If it absolutely
> must be renamed, do it in a different patch from the one that moves the
> code, though I don't see why the rename is helpful.

"Public code" is "driver/soc" here. I moved the qe_muram into driver/soc, not cpm_muram,
And the functions are named qe_muram_*, and removed cpm_muram_*, let cpm_muram
Use the same functions code with qe_muram, and define cpm_muram_* qe_muram_*. 

Previously, cpm/qe-muram functions are named cpm_muram_* because CPM is the predecessor
Of QE, and "define qe_muram_* cpm_muram_*". Now, because QE support both ARM and PowerPC,
move qe to driver/soc, and move the cpm/qe-muram functions to drver/soc too. So name the 
functions qe_muram_*, and "define cpm_muram_* qe_muram_*"

> 
> -Scott
> 

ÿôèº{.nÇ+‰·Ÿ®‰­†+%ŠËÿ±éݶ\x17¥Šwÿº{.nÇ+‰·¥Š{±þG«éÿŠ{ayº\x1dʇڙë,j\a­¢f£¢·hšïêÿ‘êçz_è®\x03(­éšŽŠÝ¢j"ú\x1a¶^[m§ÿÿ¾\a«þG«éÿ¢¸?™¨è­Ú&£ø§~á¶iO•æ¬z·švØ^\x14\x04\x1a¶^[m§ÿÿÃ\fÿ¶ìÿ¢¸?–I¥

^ permalink raw reply	[flat|nested] 42+ messages in thread

* RE: [PATCH V7 2/3] qe_common: add qe_muram_ functions to manage muram
@ 2015-09-11  1:59               ` Zhao Qiang
  0 siblings, 0 replies; 42+ messages in thread
From: Zhao Qiang @ 2015-09-11  1:59 UTC (permalink / raw)
  To: Scott Wood
  Cc: linux-kernel, linuxppc-dev, lauraa, Xiaobo Xie, benh, Li Leo, paulus

T24gTW9uLCAyMDE1LTA5LTExIGF0IDA2OjA5IC0wNTAwLCBXb29kIFNjb3R0LUIwNzQyMSB3cm90
ZToNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogV29vZCBTY290dC1CMDc0
MjENCj4gU2VudDogRnJpZGF5LCBTZXB0ZW1iZXIgMTEsIDIwMTUgNjowOSBBTQ0KPiBUbzogWmhh
byBRaWFuZy1CNDU0NzUNCj4gQ2M6IGxpbnV4LWtlcm5lbEB2Z2VyLmtlcm5lbC5vcmc7IGxpbnV4
cHBjLWRldkBsaXN0cy5vemxhYnMub3JnOw0KPiBsYXVyYWFAY29kZWF1cm9yYS5vcmc7IFhpZSBY
aWFvYm8tUjYzMDYxOyBiZW5oQGtlcm5lbC5jcmFzaGluZy5vcmc7IExpDQo+IFlhbmctTGVvLVI1
ODQ3MjsgcGF1bHVzQHNhbWJhLm9yZw0KPiBTdWJqZWN0OiBSZTogW1BBVENIIFY3IDIvM10gcWVf
Y29tbW9uOiBhZGQgcWVfbXVyYW1fIGZ1bmN0aW9ucyB0byBtYW5hZ2UNCj4gbXVyYW0NCj4gDQo+
IE9uIFdlZCwgMjAxNS0wOS0wOSBhdCAyMTozNCAtMDUwMCwgWmhhbyBRaWFuZy1CNDU0NzUgd3Jv
dGU6DQo+ID4gT24gTW9uLCAyMDE1LTA5LTEwIGF0IDEyOjM5IC0wNTAwLCBXb29kIFNjb3R0LUIw
NzQyMSB3cm90ZToNCj4gPg0KPiA+ID4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPiA+
IEZyb206IFdvb2QgU2NvdHQtQjA3NDIxDQo+ID4gPiBTZW50OiBUaHVyc2RheSwgU2VwdGVtYmVy
IDEwLCAyMDE1IDEyOjM5IEFNDQo+ID4gPiBUbzogWmhhbyBRaWFuZy1CNDU0NzUNCj4gPiA+IENj
OiBsaW51eC1rZXJuZWxAdmdlci5rZXJuZWwub3JnOyBsaW51eHBwYy1kZXZAbGlzdHMub3psYWJz
Lm9yZzsNCj4gPiA+IGxhdXJhYUBjb2RlYXVyb3JhLm9yZzsgWGllIFhpYW9iby1SNjMwNjE7IGJl
bmhAa2VybmVsLmNyYXNoaW5nLm9yZzsNCj4gPiA+IExpIFlhbmctTGVvLVI1ODQ3MjsgcGF1bHVz
QHNhbWJhLm9yZw0KPiA+ID4gU3ViamVjdDogUmU6IFtQQVRDSCBWNyAyLzNdIHFlX2NvbW1vbjog
YWRkIHFlX211cmFtXyBmdW5jdGlvbnMgdG8NCj4gPiA+IG1hbmFnZSBtdXJhbQ0KPiA+ID4NCj4g
PiA+IE9uIFN1biwgMjAxNS0wOS0wNiBhdCAwMTozNyAtMDUwMCwgWmhhbyBRaWFuZy1CNDU0NzUg
d3JvdGU6DQo+ID4gPiA+IE9uIE1vbiwgMjAxNS0wOS0yIGF0IDg6MzQgKzA4MDAsIFdvb2QgU2Nv
dHQtQjA3NDIxIHdyb3RlOg0KPiA+ID4gPiA+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+
ID4gPiA+ID4gRnJvbTogV29vZCBTY290dC1CMDc0MjENCj4gPiA+ID4gPiBTZW50OiBXZWRuZXNk
YXksIFNlcHRlbWJlciAwMiwgMjAxNSA4OjM0IEFNDQo+ID4gPiA+ID4gVG86IFpoYW8gUWlhbmct
QjQ1NDc1DQo+ID4gPiA+ID4gQ2M6IGxpbnV4LWtlcm5lbEB2Z2VyLmtlcm5lbC5vcmc7IGxpbnV4
cHBjLWRldkBsaXN0cy5vemxhYnMub3JnOw0KPiA+ID4gPiA+IGxhdXJhYUBjb2RlYXVyb3JhLm9y
ZzsgWGllIFhpYW9iby1SNjMwNjE7DQo+ID4gPiA+ID4gYmVuaEBrZXJuZWwuY3Jhc2hpbmcub3Jn
OyBMaSBZYW5nLUxlby1SNTg0NzI7IHBhdWx1c0BzYW1iYS5vcmcNCj4gPiA+ID4gPiBTdWJqZWN0
OiBSZTogW1BBVENIIFY3IDIvM10gcWVfY29tbW9uOiBhZGQgcWVfbXVyYW1fIGZ1bmN0aW9ucw0K
PiA+ID4gPiA+IHRvIG1hbmFnZSBtdXJhbQ0KPiA+ID4gPiA+DQo+ID4gPiA+ID4gT24gTW9uLCAy
MDE1LTA4LTMxIGF0IDE2OjU4ICswODAwLCBaaGFvIFFpYW5nIHdyb3RlOg0KPiA+ID4gPiA+DQo+
ID4gPiA+ID4gPiBAQCAtMTg3LDEyICsxOTAsMjUgQEAgc3RhdGljIGlubGluZSBpbnQNCj4gPiA+
ID4gPiA+IHFlX2FsaXZlX2R1cmluZ19zbGVlcCh2b2lkKSAgfQ0KPiA+ID4gPiA+ID4NCj4gPiA+
ID4gPiA+ICAvKiB3ZSBhY3R1YWxseSB1c2UgY3BtX211cmFtIGltcGxlbWVudGF0aW9uLCBkZWZp
bmUgdGhpcyBmb3INCj4gPiA+ID4gPiA+IGNvbnZlbmllbmNlICovIC0jZGVmaW5lIHFlX211cmFt
X2luaXQgY3BtX211cmFtX2luaXQgLSNkZWZpbmUNCj4gPiA+ID4gPiA+IHFlX211cmFtX2FsbG9j
IGNwbV9tdXJhbV9hbGxvYyAtI2RlZmluZSBxZV9tdXJhbV9hbGxvY19maXhlZA0KPiA+ID4gPiA+
ID4gY3BtX211cmFtX2FsbG9jX2ZpeGVkIC0jZGVmaW5lIHFlX211cmFtX2ZyZWUgY3BtX211cmFt
X2ZyZWUNCj4gPiA+ID4gPiA+IC0jZGVmaW5lIHFlX211cmFtX2FkZHIgY3BtX211cmFtX2FkZHIg
LSNkZWZpbmUgcWVfbXVyYW1fb2Zmc2V0DQo+ID4gPiA+ID4gPiBjcG1fbXVyYW1fb2Zmc2V0DQo+
ID4gPiA+ID4gPiArI2RlZmluZSBjcG1fbXVyYW1faW5pdCBxZV9tdXJhbV9pbml0ICNkZWZpbmUg
Y3BtX211cmFtX2FsbG9jDQo+ID4gPiA+ID4gPiArcWVfbXVyYW1fYWxsb2MgI2RlZmluZSBjcG1f
bXVyYW1fYWxsb2NfZml4ZWQNCj4gPiA+ID4gPiA+ICtxZV9tdXJhbV9hbGxvY19maXhlZCAjZGVm
aW5lIGNwbV9tdXJhbV9mcmVlIHFlX211cmFtX2ZyZWUNCj4gPiA+ID4gPiA+ICsjZGVmaW5lIGNw
bV9tdXJhbV9hZGRyIHFlX211cmFtX2FkZHIgI2RlZmluZSBjcG1fbXVyYW1fb2Zmc2V0DQo+ID4g
PiA+ID4gPiArcWVfbXVyYW1fb2Zmc2V0DQo+ID4gPiA+ID4NCj4gPiA+ID4gPiBXaHk/ICBUaGlz
IGlzIHVubmVjZXNzYXJ5IGNodXJuLg0KPiA+ID4gPiA+DQo+ID4gPiA+IFRoaXMgaXMgbmVjZXNz
YXJ5LiBRRSBpcyBvbiBib3RoIEFSTSBhbmQgUG93ZXJQQywgaXRzIGNvZGUgaXMNCj4gPiA+ID4g
dW5kZXIgcHVibGljIGNvZGUuDQo+ID4gPiA+IEJ1dCBDUE0gaXMgb25seSBvbiBQb3dlclBDIGFu
ZCBpdHMgY29kZSBpcyB1bmRlciBQb3dlclBDLg0KPiA+ID4gPiBTbyB3aGVuIGJ1aWxkIEFSTSwg
UUUgd2lsbCBub3QgZmluZCBjcG1fbXVyYW1fKiBmdW5jdGlvbi4NCj4gPiA+DQo+ID4gPiBJZiB5
b3UgbW92ZSB0aGUgY3BtX211cmFtIGZ1bmN0aW9ucyB0byBkcml2ZXJzL3NvYywgdGhlbiBBUk0g
d2lsbA0KPiA+ID4gZmluZCB0aGVtLg0KPiA+ID4gVGhlcmUgaXMgbm8gbmVlZCB0byByZW5hbWUg
dGhlbS4NCj4gPg0KPiA+IFllcywgbW92aW5nIGNwbV9tdXJhbSBjYW4gaGFuZGxlIHRoaXMgaXNz
dWUuIEhvd2V2ZXIsIGNwbSBpcyBub3QNCj4gPiBuZWNlc3NhcnkgVG8gbW92ZSB0byBwdWJsaWMg
Y29kZSwgYW5kIGEgY2h1cm4gaXMgc2ltcGxlciB0aGFuIG1vdmluZw0KPiBjcG1fbXVyYW0uDQo+
ID4gUGxlYXNlIGNvbnNpZGVyIG15IHN1Z2dlc3Rpb24sIFRoYW5rIHlvdSENCj4gDQo+IFdoYXQg
ZG8geW91IG1lYW4gYnkgInB1YmxpYyBjb2RlIj8gIFlvdSdyZSBhbHJlYWR5IG1vdmluZyBjcG1f
bXVyYW0uICBJJ20NCj4ganVzdCBhc2tpbmcgdGhhdCB5b3Ugbm90IHJlbmFtZSBpdCB3aGlsZSB5
b3UgZG8gc28uICBJZiBpdCBhYnNvbHV0ZWx5DQo+IG11c3QgYmUgcmVuYW1lZCwgZG8gaXQgaW4g
YSBkaWZmZXJlbnQgcGF0Y2ggZnJvbSB0aGUgb25lIHRoYXQgbW92ZXMgdGhlDQo+IGNvZGUsIHRo
b3VnaCBJIGRvbid0IHNlZSB3aHkgdGhlIHJlbmFtZSBpcyBoZWxwZnVsLg0KDQoiUHVibGljIGNv
ZGUiIGlzICJkcml2ZXIvc29jIiBoZXJlLiBJIG1vdmVkIHRoZSBxZV9tdXJhbSBpbnRvIGRyaXZl
ci9zb2MsIG5vdCBjcG1fbXVyYW0sDQpBbmQgdGhlIGZ1bmN0aW9ucyBhcmUgbmFtZWQgcWVfbXVy
YW1fKiwgYW5kIHJlbW92ZWQgY3BtX211cmFtXyosIGxldCBjcG1fbXVyYW0NClVzZSB0aGUgc2Ft
ZSBmdW5jdGlvbnMgY29kZSB3aXRoIHFlX211cmFtLCBhbmQgZGVmaW5lIGNwbV9tdXJhbV8qIHFl
X211cmFtXyouIA0KDQpQcmV2aW91c2x5LCBjcG0vcWUtbXVyYW0gZnVuY3Rpb25zIGFyZSBuYW1l
ZCBjcG1fbXVyYW1fKiBiZWNhdXNlIENQTSBpcyB0aGUgcHJlZGVjZXNzb3INCk9mIFFFLCBhbmQg
ImRlZmluZSBxZV9tdXJhbV8qIGNwbV9tdXJhbV8qIi4gTm93LCBiZWNhdXNlIFFFIHN1cHBvcnQg
Ym90aCBBUk0gYW5kIFBvd2VyUEMsDQptb3ZlIHFlIHRvIGRyaXZlci9zb2MsIGFuZCBtb3ZlIHRo
ZSBjcG0vcWUtbXVyYW0gZnVuY3Rpb25zIHRvIGRydmVyL3NvYyB0b28uIFNvIG5hbWUgdGhlIA0K
ZnVuY3Rpb25zIHFlX211cmFtXyosIGFuZCAiZGVmaW5lIGNwbV9tdXJhbV8qIHFlX211cmFtXyoi
DQoNCj4gDQo+IC1TY290dA0KPiANCg0K

^ permalink raw reply	[flat|nested] 42+ messages in thread

* Re: [PATCH V7 2/3] qe_common: add qe_muram_ functions to manage muram
  2015-09-11  1:59               ` Zhao Qiang
  (?)
@ 2015-09-11  2:05               ` Scott Wood
  -1 siblings, 0 replies; 42+ messages in thread
From: Scott Wood @ 2015-09-11  2:05 UTC (permalink / raw)
  To: Zhao Qiang-B45475
  Cc: linux-kernel, linuxppc-dev, lauraa, Xie Xiaobo-R63061, benh,
	Li Yang-Leo-R58472, paulus

On Thu, 2015-09-10 at 20:59 -0500, Zhao Qiang-B45475 wrote:
> On Mon, 2015-09-11 at 06:09 -0500, Wood Scott-B07421 wrote:
> > -----Original Message-----
> > From: Wood Scott-B07421
> > Sent: Friday, September 11, 2015 6:09 AM
> > To: Zhao Qiang-B45475
> > Cc: linux-kernel@vger.kernel.org; linuxppc-dev@lists.ozlabs.org;
> > lauraa@codeaurora.org; Xie Xiaobo-R63061; benh@kernel.crashing.org; Li
> > Yang-Leo-R58472; paulus@samba.org
> > Subject: Re: [PATCH V7 2/3] qe_common: add qe_muram_ functions to manage
> > muram
> > 
> > On Wed, 2015-09-09 at 21:34 -0500, Zhao Qiang-B45475 wrote:
> > > On Mon, 2015-09-10 at 12:39 -0500, Wood Scott-B07421 wrote:
> > > 
> > > > -----Original Message-----
> > > > From: Wood Scott-B07421
> > > > Sent: Thursday, September 10, 2015 12:39 AM
> > > > To: Zhao Qiang-B45475
> > > > Cc: linux-kernel@vger.kernel.org; linuxppc-dev@lists.ozlabs.org;
> > > > lauraa@codeaurora.org; Xie Xiaobo-R63061; benh@kernel.crashing.org;
> > > > Li Yang-Leo-R58472; paulus@samba.org
> > > > Subject: Re: [PATCH V7 2/3] qe_common: add qe_muram_ functions to
> > > > manage muram
> > > > 
> > > > On Sun, 2015-09-06 at 01:37 -0500, Zhao Qiang-B45475 wrote:
> > > > > On Mon, 2015-09-2 at 8:34 +0800, Wood Scott-B07421 wrote:
> > > > > > -----Original Message-----
> > > > > > From: Wood Scott-B07421
> > > > > > Sent: Wednesday, September 02, 2015 8:34 AM
> > > > > > To: Zhao Qiang-B45475
> > > > > > Cc: linux-kernel@vger.kernel.org; linuxppc-dev@lists.ozlabs.org;
> > > > > > lauraa@codeaurora.org; Xie Xiaobo-R63061;
> > > > > > benh@kernel.crashing.org; Li Yang-Leo-R58472; paulus@samba.org
> > > > > > Subject: Re: [PATCH V7 2/3] qe_common: add qe_muram_ functions
> > > > > > to manage muram
> > > > > > 
> > > > > > On Mon, 2015-08-31 at 16:58 +0800, Zhao Qiang wrote:
> > > > > > 
> > > > > > > @@ -187,12 +190,25 @@ static inline int
> > > > > > > qe_alive_during_sleep(void)  }
> > > > > > > 
> > > > > > >  /* we actually use cpm_muram implementation, define this for
> > > > > > > convenience */ -#define qe_muram_init cpm_muram_init -#define
> > > > > > > qe_muram_alloc cpm_muram_alloc -#define qe_muram_alloc_fixed
> > > > > > > cpm_muram_alloc_fixed -#define qe_muram_free cpm_muram_free
> > > > > > > -#define qe_muram_addr cpm_muram_addr -#define qe_muram_offset
> > > > > > > cpm_muram_offset
> > > > > > > +#define cpm_muram_init qe_muram_init #define cpm_muram_alloc
> > > > > > > +qe_muram_alloc #define cpm_muram_alloc_fixed
> > > > > > > +qe_muram_alloc_fixed #define cpm_muram_free qe_muram_free
> > > > > > > +#define cpm_muram_addr qe_muram_addr #define cpm_muram_offset
> > > > > > > +qe_muram_offset
> > > > > > 
> > > > > > Why?  This is unnecessary churn.
> > > > > > 
> > > > > This is necessary. QE is on both ARM and PowerPC, its code is
> > > > > under public code.
> > > > > But CPM is only on PowerPC and its code is under PowerPC.
> > > > > So when build ARM, QE will not find cpm_muram_* function.
> > > > 
> > > > If you move the cpm_muram functions to drivers/soc, then ARM will
> > > > find them.
> > > > There is no need to rename them.
> > > 
> > > Yes, moving cpm_muram can handle this issue. However, cpm is not
> > > necessary To move to public code, and a churn is simpler than moving
> > cpm_muram.
> > > Please consider my suggestion, Thank you!
> > 
> > What do you mean by "public code"?  You're already moving cpm_muram.  I'm
> > just asking that you not rename it while you do so.  If it absolutely
> > must be renamed, do it in a different patch from the one that moves the
> > code, though I don't see why the rename is helpful.
> 
> "Public code" is "driver/soc" here. I moved the qe_muram into driver/soc, 
> not cpm_muram,

They are the same thing.

> And the functions are named qe_muram_*, 

Only after you renamed them.  Before that they were just #defined aliases.

> and removed cpm_muram_*, let cpm_muram
> Use the same functions code with qe_muram, and define cpm_muram_* 
> qe_muram_*. 
> 
> Previously, cpm/qe-muram functions are named cpm_muram_* because CPM is the 
> predecessor
> Of QE,

Yes, and just because marketing decided they wanted to change the name when 
they came out with a new version doesn't mean we need to rename 
infrastructure that is common between them.  E.g. we still classify PPC QorIQ 
chips as "mpc85xx".

Again, if you really want to do the rename, at least do it in a separate 
patch from moving the code, so that git will detect the code movement and we 
can see if anything else changed during the move.

-Scott


^ permalink raw reply	[flat|nested] 42+ messages in thread

* RE: [PATCH V7 1/3] genalloc:support memory-allocation with bytes-alignment to genalloc
  2015-09-10 22:07             ` Scott Wood
@ 2015-09-11  2:09                 ` Zhao Qiang
  0 siblings, 0 replies; 42+ messages in thread
From: Zhao Qiang @ 2015-09-11  2:09 UTC (permalink / raw)
  To: Scott Wood
  Cc: linux-kernel, linuxppc-dev, lauraa, Xiaobo Xie, benh, Li Leo, paulus

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="utf-8", Size: 5748 bytes --]

On Fri, 2015-09-11 at 06:07AM -0500, Wood Scott-B07421 wrote:
> -----Original Message-----
> From: Wood Scott-B07421
> Sent: Friday, September 11, 2015 6:07 AM
> To: Zhao Qiang-B45475
> Cc: linux-kernel@vger.kernel.org; linuxppc-dev@lists.ozlabs.org;
> lauraa@codeaurora.org; Xie Xiaobo-R63061; benh@kernel.crashing.org; Li
> Yang-Leo-R58472; paulus@samba.org
> Subject: Re: [PATCH V7 1/3] genalloc:support memory-allocation with
> bytes-alignment to genalloc
> 
> On Wed, 2015-09-09 at 21:26 -0500, Zhao Qiang-B45475 wrote:
> > On Wed, 2015-09-10 at 12:38AM -0500, Wood Scott-B07421 wrote:
> > > -----Original Message-----
> > > From: Wood Scott-B07421
> > > Sent: Thursday, September 10, 2015 12:38 AM
> > > To: Zhao Qiang-B45475
> > > Cc: linux-kernel@vger.kernel.org; linuxppc-dev@lists.ozlabs.org;
> > > lauraa@codeaurora.org; Xie Xiaobo-R63061; benh@kernel.crashing.org;
> > > Li Yang-Leo-R58472; paulus@samba.org
> > > Subject: Re: [PATCH V7 1/3] genalloc:support memory-allocation with
> > > bytes-alignment to genalloc
> > >
> > > On Sat, 2015-09-05 at 22:13 -0500, Zhao Qiang-B45475 wrote:
> > > > On Wed, 2015-09-02 at 10:18AM +0800, Wood Scott-B07421 wrote:
> > > > > -----Original Message-----
> > > > > From: Wood Scott-B07421
> > > > > Sent: Wednesday, September 02, 2015 10:18 AM
> > > > > To: Zhao Qiang-B45475
> > > > > Cc: linux-kernel@vger.kernel.org; linuxppc-dev@lists.ozlabs.org;
> > > > > lauraa@codeaurora.org; Xie Xiaobo-R63061;
> > > > > benh@kernel.crashing.org; Li Yang-Leo-R58472; paulus@samba.org
> > > > > Subject: Re: [PATCH V7 1/3] genalloc:support memory-allocation
> > > > > with bytes-alignment to genalloc
> > > > >
> > > > > On Tue, 2015-09-01 at 21:10 -0500, Zhao Qiang-B45475 wrote:
> > > > > > On Wed, 2015-09-02 at 08:38AM +0800, Wood Scott-B07421 wrote:
> > > > > > > -----Original Message-----
> > > > > > > From: Wood Scott-B07421
> > > > > > > Sent: Wednesday, September 02, 2015 8:30 AM
> > > > > > > To: Zhao Qiang-B45475
> > > > > > > Cc: linux-kernel@vger.kernel.org;
> > > > > > > linuxppc-dev@lists.ozlabs.org; lauraa@codeaurora.org; Xie
> > > > > > > Xiaobo-R63061; benh@kernel.crashing.org; Li Yang-Leo-R58472;
> > > > > > > paulus@samba.org
> > > > > > > Subject: Re: [PATCH V7 1/3] genalloc:support
> > > > > > > memory-allocation with bytes-alignment to genalloc
> > > > > > >
> > > > > > > On Mon, 2015-08-31 at 16:58 +0800, Zhao Qiang wrote:
> > > > > > > > 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 <qiang.zhao@freescale.com>
> > > > > > > > ---
> > > > > > > > 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.
> > > > > > >
> > > > > > > This seems to be describing more than just the changes in
> > > > > > > this
> > > patch.
> > > > > > > What does also handling cpm have to do with this patch?  Are
> > > > > > > you adding support for reserving a specific region in this
> > > > > > > patch?  I don't see it, and in any case it should go in a
> different patch.
> > > > > >
> > > > > > Yes, I added. The code below can support the function.
> > > > > >       offset_bit = (alignment->offset + (1UL << order) - 1) >>
> > > order;
> > > > > >       return bitmap_find_next_zero_area(map, size, start +
> > > > > > offset_bit,
> > > > > nr,
> > > > > >                         align_mask);
> > > > > >
> > > > > > CPM has an function cpm_muram_alloc_fixed, needing to allocate
> > > > > > muram from a Specific offset. So I add the code and add offset
> > > > > > to
> > > struct data.
> > > > >
> > > > > I thought the offset was related to the previous discussion of
> > > > > checking for allocation failure.  Are you using it to implement
> > > > > alloc_fixed()?  If so, please don't.  Besides the awkward
> > > > > implementation (what does it logically have to do with
> > > > > gen_pool_first_fit_align?), it does not appear to be correct -
> > > > > - what happens with multiple chunks?  What happens if part of
> > > > > the region the caller is trying to reserve is already taken?
> > > > > Implement a proper function to reserve a fixed genalloc region.
> > > > >
> > > > The offset is which allocation block address need to be larger
> > > > than, Not equal to, it really like the parameter start of the
> > > > algo(the bitnumber To start searching at).
> > >
> > > cpm_muram_alloc_fixed() is not "search starting at this offset".  It
> > > is "reserve this exact range or fail".
> >
> > Yes, you are right! How about to add a new algo into genalloc to
> > search At offset, then handle it in muram layer, if the address return
> > from genalloc Is not equal to offset, return negative number?
> 
> If you're adding a new algorithm, why not make it actually do what you
> want rather than adding something different and fixing it up in the
> caller?

Because I'm not sure whether it is proper to add a "offset searching at" algo. 

> 
> -Scott

ÿôèº{.nÇ+‰·Ÿ®‰­†+%ŠËÿ±éݶ\x17¥Šwÿº{.nÇ+‰·¥Š{±þG«éÿŠ{ayº\x1dʇڙë,j\a­¢f£¢·hšïêÿ‘êçz_è®\x03(­éšŽŠÝ¢j"ú\x1a¶^[m§ÿÿ¾\a«þG«éÿ¢¸?™¨è­Ú&£ø§~á¶iO•æ¬z·švØ^\x14\x04\x1a¶^[m§ÿÿÃ\fÿ¶ìÿ¢¸?–I¥

^ permalink raw reply	[flat|nested] 42+ messages in thread

* RE: [PATCH V7 1/3] genalloc:support memory-allocation with bytes-alignment to genalloc
@ 2015-09-11  2:09                 ` Zhao Qiang
  0 siblings, 0 replies; 42+ messages in thread
From: Zhao Qiang @ 2015-09-11  2:09 UTC (permalink / raw)
  To: Scott Wood
  Cc: linux-kernel, linuxppc-dev, lauraa, Xiaobo Xie, benh, Li Leo, paulus

T24gRnJpLCAyMDE1LTA5LTExIGF0IDA2OjA3QU0gLTA1MDAsIFdvb2QgU2NvdHQtQjA3NDIxIHdy
b3RlOg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBXb29kIFNjb3R0LUIw
NzQyMQ0KPiBTZW50OiBGcmlkYXksIFNlcHRlbWJlciAxMSwgMjAxNSA2OjA3IEFNDQo+IFRvOiBa
aGFvIFFpYW5nLUI0NTQ3NQ0KPiBDYzogbGludXgta2VybmVsQHZnZXIua2VybmVsLm9yZzsgbGlu
dXhwcGMtZGV2QGxpc3RzLm96bGFicy5vcmc7DQo+IGxhdXJhYUBjb2RlYXVyb3JhLm9yZzsgWGll
IFhpYW9iby1SNjMwNjE7IGJlbmhAa2VybmVsLmNyYXNoaW5nLm9yZzsgTGkNCj4gWWFuZy1MZW8t
UjU4NDcyOyBwYXVsdXNAc2FtYmEub3JnDQo+IFN1YmplY3Q6IFJlOiBbUEFUQ0ggVjcgMS8zXSBn
ZW5hbGxvYzpzdXBwb3J0IG1lbW9yeS1hbGxvY2F0aW9uIHdpdGgNCj4gYnl0ZXMtYWxpZ25tZW50
IHRvIGdlbmFsbG9jDQo+IA0KPiBPbiBXZWQsIDIwMTUtMDktMDkgYXQgMjE6MjYgLTA1MDAsIFpo
YW8gUWlhbmctQjQ1NDc1IHdyb3RlOg0KPiA+IE9uIFdlZCwgMjAxNS0wOS0xMCBhdCAxMjozOEFN
IC0wNTAwLCBXb29kIFNjb3R0LUIwNzQyMSB3cm90ZToNCj4gPiA+IC0tLS0tT3JpZ2luYWwgTWVz
c2FnZS0tLS0tDQo+ID4gPiBGcm9tOiBXb29kIFNjb3R0LUIwNzQyMQ0KPiA+ID4gU2VudDogVGh1
cnNkYXksIFNlcHRlbWJlciAxMCwgMjAxNSAxMjozOCBBTQ0KPiA+ID4gVG86IFpoYW8gUWlhbmct
QjQ1NDc1DQo+ID4gPiBDYzogbGludXgta2VybmVsQHZnZXIua2VybmVsLm9yZzsgbGludXhwcGMt
ZGV2QGxpc3RzLm96bGFicy5vcmc7DQo+ID4gPiBsYXVyYWFAY29kZWF1cm9yYS5vcmc7IFhpZSBY
aWFvYm8tUjYzMDYxOyBiZW5oQGtlcm5lbC5jcmFzaGluZy5vcmc7DQo+ID4gPiBMaSBZYW5nLUxl
by1SNTg0NzI7IHBhdWx1c0BzYW1iYS5vcmcNCj4gPiA+IFN1YmplY3Q6IFJlOiBbUEFUQ0ggVjcg
MS8zXSBnZW5hbGxvYzpzdXBwb3J0IG1lbW9yeS1hbGxvY2F0aW9uIHdpdGgNCj4gPiA+IGJ5dGVz
LWFsaWdubWVudCB0byBnZW5hbGxvYw0KPiA+ID4NCj4gPiA+IE9uIFNhdCwgMjAxNS0wOS0wNSBh
dCAyMjoxMyAtMDUwMCwgWmhhbyBRaWFuZy1CNDU0NzUgd3JvdGU6DQo+ID4gPiA+IE9uIFdlZCwg
MjAxNS0wOS0wMiBhdCAxMDoxOEFNICswODAwLCBXb29kIFNjb3R0LUIwNzQyMSB3cm90ZToNCj4g
PiA+ID4gPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+ID4gPiA+IEZyb206IFdvb2Qg
U2NvdHQtQjA3NDIxDQo+ID4gPiA+ID4gU2VudDogV2VkbmVzZGF5LCBTZXB0ZW1iZXIgMDIsIDIw
MTUgMTA6MTggQU0NCj4gPiA+ID4gPiBUbzogWmhhbyBRaWFuZy1CNDU0NzUNCj4gPiA+ID4gPiBD
YzogbGludXgta2VybmVsQHZnZXIua2VybmVsLm9yZzsgbGludXhwcGMtZGV2QGxpc3RzLm96bGFi
cy5vcmc7DQo+ID4gPiA+ID4gbGF1cmFhQGNvZGVhdXJvcmEub3JnOyBYaWUgWGlhb2JvLVI2MzA2
MTsNCj4gPiA+ID4gPiBiZW5oQGtlcm5lbC5jcmFzaGluZy5vcmc7IExpIFlhbmctTGVvLVI1ODQ3
MjsgcGF1bHVzQHNhbWJhLm9yZw0KPiA+ID4gPiA+IFN1YmplY3Q6IFJlOiBbUEFUQ0ggVjcgMS8z
XSBnZW5hbGxvYzpzdXBwb3J0IG1lbW9yeS1hbGxvY2F0aW9uDQo+ID4gPiA+ID4gd2l0aCBieXRl
cy1hbGlnbm1lbnQgdG8gZ2VuYWxsb2MNCj4gPiA+ID4gPg0KPiA+ID4gPiA+IE9uIFR1ZSwgMjAx
NS0wOS0wMSBhdCAyMToxMCAtMDUwMCwgWmhhbyBRaWFuZy1CNDU0NzUgd3JvdGU6DQo+ID4gPiA+
ID4gPiBPbiBXZWQsIDIwMTUtMDktMDIgYXQgMDg6MzhBTSArMDgwMCwgV29vZCBTY290dC1CMDc0
MjEgd3JvdGU6DQo+ID4gPiA+ID4gPiA+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4g
PiA+ID4gPiA+IEZyb206IFdvb2QgU2NvdHQtQjA3NDIxDQo+ID4gPiA+ID4gPiA+IFNlbnQ6IFdl
ZG5lc2RheSwgU2VwdGVtYmVyIDAyLCAyMDE1IDg6MzAgQU0NCj4gPiA+ID4gPiA+ID4gVG86IFpo
YW8gUWlhbmctQjQ1NDc1DQo+ID4gPiA+ID4gPiA+IENjOiBsaW51eC1rZXJuZWxAdmdlci5rZXJu
ZWwub3JnOw0KPiA+ID4gPiA+ID4gPiBsaW51eHBwYy1kZXZAbGlzdHMub3psYWJzLm9yZzsgbGF1
cmFhQGNvZGVhdXJvcmEub3JnOyBYaWUNCj4gPiA+ID4gPiA+ID4gWGlhb2JvLVI2MzA2MTsgYmVu
aEBrZXJuZWwuY3Jhc2hpbmcub3JnOyBMaSBZYW5nLUxlby1SNTg0NzI7DQo+ID4gPiA+ID4gPiA+
IHBhdWx1c0BzYW1iYS5vcmcNCj4gPiA+ID4gPiA+ID4gU3ViamVjdDogUmU6IFtQQVRDSCBWNyAx
LzNdIGdlbmFsbG9jOnN1cHBvcnQNCj4gPiA+ID4gPiA+ID4gbWVtb3J5LWFsbG9jYXRpb24gd2l0
aCBieXRlcy1hbGlnbm1lbnQgdG8gZ2VuYWxsb2MNCj4gPiA+ID4gPiA+ID4NCj4gPiA+ID4gPiA+
ID4gT24gTW9uLCAyMDE1LTA4LTMxIGF0IDE2OjU4ICswODAwLCBaaGFvIFFpYW5nIHdyb3RlOg0K
PiA+ID4gPiA+ID4gPiA+IEJ5dGVzIGFsaWdubWVudCBpcyByZXF1aXJlZCB0byBtYW5hZ2Ugc29t
ZSBzcGVjaWFsIFJBTSwgc28NCj4gPiA+ID4gPiA+ID4gPiBhZGQgZ2VuX3Bvb2xfZmlyc3RfZml0
X2FsaWduIHRvIGdlbmFsbG9jLCBtZWFud2hpbGUgYWRkDQo+ID4gPiA+ID4gPiA+ID4gZ2VuX3Bv
b2xfYWxsb2NfZGF0YSB0byBwYXNzIGRhdGEgdG8NCj4gPiA+ID4gPiA+ID4gPiBnZW5fcG9vbF9m
aXJzdF9maXRfYWxpZ24obW9kaWZ5IGdlbl9wb29sX2FsbG9jIGFzIGENCj4gPiA+ID4gPiA+ID4g
PiB3cmFwcGVyKQ0KPiA+ID4gPiA+ID4gPiA+DQo+ID4gPiA+ID4gPiA+ID4gU2lnbmVkLW9mZi1i
eTogWmhhbyBRaWFuZyA8cWlhbmcuemhhb0BmcmVlc2NhbGUuY29tPg0KPiA+ID4gPiA+ID4gPiA+
IC0tLQ0KPiA+ID4gPiA+ID4gPiA+IENoYW5nZXMgZm9yIHY2Og0KPiA+ID4gPiA+ID4gPiA+ICAg
ICAgIC0gcGF0Y2hlcyBzZXQgdjYgaW5jbHVkZSBhIG5ldyBwYXRjaCBiZWNhdXNlIG9mIHVzaW5n
DQo+ID4gPiA+ID4gPiA+ID4gICAgICAgLSBnZW5hbGxvYyB0byBtYW5hZ2UgUUUgTVVSQU0sIHBh
dGNoIDAwMDEgaXMgdGhlIG5ldw0KPiA+ID4gPiA+ID4gPiA+ICAgICAgIC0gcGF0Y2gsIGFkZGlu
ZyBieXRlcyBhbGlnbm1lbnQgZm9yIGFsbG9jYXRpb24gZm9yDQo+IHVzZS4NCj4gPiA+ID4gPiA+
ID4gPiBDaGFuZ2VzIGZvciB2NzoNCj4gPiA+ID4gPiA+ID4gPiAgICAgICAtIGNwbSBtdXJhbSBh
bHNvIG5lZWQgdG8gdXNlIGdlbmFsbG9jIHRvIG1hbmFnZSwgaXQNCj4gaGFzDQo+ID4gPiA+ID4g
PiA+ID4gICAgICAgICBhIGZ1bmN0aW9uIHRvIHJlc2VydmUgYSBzcGVjaWZpYyByZWdpb24gb2Yg
bXVyYW0sDQo+ID4gPiA+ID4gPiA+ID4gICAgICAgICBhZGQgb2Zmc2V0IHRvIGdlbnBvb2xfZGF0
YSBmb3Igc3RhcnQgYWRkciB0byBiZQ0KPiA+ID4gYWxsb2NhdGVkLg0KPiA+ID4gPiA+ID4gPg0K
PiA+ID4gPiA+ID4gPiBUaGlzIHNlZW1zIHRvIGJlIGRlc2NyaWJpbmcgbW9yZSB0aGFuIGp1c3Qg
dGhlIGNoYW5nZXMgaW4NCj4gPiA+ID4gPiA+ID4gdGhpcw0KPiA+ID4gcGF0Y2guDQo+ID4gPiA+
ID4gPiA+IFdoYXQgZG9lcyBhbHNvIGhhbmRsaW5nIGNwbSBoYXZlIHRvIGRvIHdpdGggdGhpcyBw
YXRjaD8gIEFyZQ0KPiA+ID4gPiA+ID4gPiB5b3UgYWRkaW5nIHN1cHBvcnQgZm9yIHJlc2Vydmlu
ZyBhIHNwZWNpZmljIHJlZ2lvbiBpbiB0aGlzDQo+ID4gPiA+ID4gPiA+IHBhdGNoPyAgSSBkb24n
dCBzZWUgaXQsIGFuZCBpbiBhbnkgY2FzZSBpdCBzaG91bGQgZ28gaW4gYQ0KPiBkaWZmZXJlbnQg
cGF0Y2guDQo+ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4gWWVzLCBJIGFkZGVkLiBUaGUgY29kZSBi
ZWxvdyBjYW4gc3VwcG9ydCB0aGUgZnVuY3Rpb24uDQo+ID4gPiA+ID4gPiAgICAgICBvZmZzZXRf
Yml0ID0gKGFsaWdubWVudC0+b2Zmc2V0ICsgKDFVTCA8PCBvcmRlcikgLSAxKSA+Pg0KPiA+ID4g
b3JkZXI7DQo+ID4gPiA+ID4gPiAgICAgICByZXR1cm4gYml0bWFwX2ZpbmRfbmV4dF96ZXJvX2Fy
ZWEobWFwLCBzaXplLCBzdGFydCArDQo+ID4gPiA+ID4gPiBvZmZzZXRfYml0LA0KPiA+ID4gPiA+
IG5yLA0KPiA+ID4gPiA+ID4gICAgICAgICAgICAgICAgICAgICAgICAgYWxpZ25fbWFzayk7DQo+
ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4gQ1BNIGhhcyBhbiBmdW5jdGlvbiBjcG1fbXVyYW1fYWxs
b2NfZml4ZWQsIG5lZWRpbmcgdG8gYWxsb2NhdGUNCj4gPiA+ID4gPiA+IG11cmFtIGZyb20gYSBT
cGVjaWZpYyBvZmZzZXQuIFNvIEkgYWRkIHRoZSBjb2RlIGFuZCBhZGQgb2Zmc2V0DQo+ID4gPiA+
ID4gPiB0bw0KPiA+ID4gc3RydWN0IGRhdGEuDQo+ID4gPiA+ID4NCj4gPiA+ID4gPiBJIHRob3Vn
aHQgdGhlIG9mZnNldCB3YXMgcmVsYXRlZCB0byB0aGUgcHJldmlvdXMgZGlzY3Vzc2lvbiBvZg0K
PiA+ID4gPiA+IGNoZWNraW5nIGZvciBhbGxvY2F0aW9uIGZhaWx1cmUuICBBcmUgeW91IHVzaW5n
IGl0IHRvIGltcGxlbWVudA0KPiA+ID4gPiA+IGFsbG9jX2ZpeGVkKCk/ICBJZiBzbywgcGxlYXNl
IGRvbid0LiAgQmVzaWRlcyB0aGUgYXdrd2FyZA0KPiA+ID4gPiA+IGltcGxlbWVudGF0aW9uICh3
aGF0IGRvZXMgaXQgbG9naWNhbGx5IGhhdmUgdG8gZG8gd2l0aA0KPiA+ID4gPiA+IGdlbl9wb29s
X2ZpcnN0X2ZpdF9hbGlnbj8pLCBpdCBkb2VzIG5vdCBhcHBlYXIgdG8gYmUgY29ycmVjdCAtDQo+
ID4gPiA+ID4gLSB3aGF0IGhhcHBlbnMgd2l0aCBtdWx0aXBsZSBjaHVua3M/ICBXaGF0IGhhcHBl
bnMgaWYgcGFydCBvZg0KPiA+ID4gPiA+IHRoZSByZWdpb24gdGhlIGNhbGxlciBpcyB0cnlpbmcg
dG8gcmVzZXJ2ZSBpcyBhbHJlYWR5IHRha2VuPw0KPiA+ID4gPiA+IEltcGxlbWVudCBhIHByb3Bl
ciBmdW5jdGlvbiB0byByZXNlcnZlIGEgZml4ZWQgZ2VuYWxsb2MgcmVnaW9uLg0KPiA+ID4gPiA+
DQo+ID4gPiA+IFRoZSBvZmZzZXQgaXMgd2hpY2ggYWxsb2NhdGlvbiBibG9jayBhZGRyZXNzIG5l
ZWQgdG8gYmUgbGFyZ2VyDQo+ID4gPiA+IHRoYW4sIE5vdCBlcXVhbCB0bywgaXQgcmVhbGx5IGxp
a2UgdGhlIHBhcmFtZXRlciBzdGFydCBvZiB0aGUNCj4gPiA+ID4gYWxnbyh0aGUgYml0bnVtYmVy
IFRvIHN0YXJ0IHNlYXJjaGluZyBhdCkuDQo+ID4gPg0KPiA+ID4gY3BtX211cmFtX2FsbG9jX2Zp
eGVkKCkgaXMgbm90ICJzZWFyY2ggc3RhcnRpbmcgYXQgdGhpcyBvZmZzZXQiLiAgSXQNCj4gPiA+
IGlzICJyZXNlcnZlIHRoaXMgZXhhY3QgcmFuZ2Ugb3IgZmFpbCIuDQo+ID4NCj4gPiBZZXMsIHlv
dSBhcmUgcmlnaHQhIEhvdyBhYm91dCB0byBhZGQgYSBuZXcgYWxnbyBpbnRvIGdlbmFsbG9jIHRv
DQo+ID4gc2VhcmNoIEF0IG9mZnNldCwgdGhlbiBoYW5kbGUgaXQgaW4gbXVyYW0gbGF5ZXIsIGlm
IHRoZSBhZGRyZXNzIHJldHVybg0KPiA+IGZyb20gZ2VuYWxsb2MgSXMgbm90IGVxdWFsIHRvIG9m
ZnNldCwgcmV0dXJuIG5lZ2F0aXZlIG51bWJlcj8NCj4gDQo+IElmIHlvdSdyZSBhZGRpbmcgYSBu
ZXcgYWxnb3JpdGhtLCB3aHkgbm90IG1ha2UgaXQgYWN0dWFsbHkgZG8gd2hhdCB5b3UNCj4gd2Fu
dCByYXRoZXIgdGhhbiBhZGRpbmcgc29tZXRoaW5nIGRpZmZlcmVudCBhbmQgZml4aW5nIGl0IHVw
IGluIHRoZQ0KPiBjYWxsZXI/DQoNCkJlY2F1c2UgSSdtIG5vdCBzdXJlIHdoZXRoZXIgaXQgaXMg
cHJvcGVyIHRvIGFkZCBhICJvZmZzZXQgc2VhcmNoaW5nIGF0IiBhbGdvLiANCg0KPiANCj4gLVNj
b3R0DQoNCg==

^ permalink raw reply	[flat|nested] 42+ messages in thread

* Re: [PATCH V7 1/3] genalloc:support memory-allocation with bytes-alignment to genalloc
  2015-09-11  2:09                 ` Zhao Qiang
  (?)
@ 2015-09-11  2:15                 ` Scott Wood
  2015-09-11  2:25                     ` Zhao Qiang
  -1 siblings, 1 reply; 42+ messages in thread
From: Scott Wood @ 2015-09-11  2:15 UTC (permalink / raw)
  To: Zhao Qiang-B45475
  Cc: linux-kernel, linuxppc-dev, lauraa, Xie Xiaobo-R63061, benh,
	Li Yang-Leo-R58472, paulus

On Thu, 2015-09-10 at 21:09 -0500, Zhao Qiang-B45475 wrote:
> On Fri, 2015-09-11 at 06:07AM -0500, Wood Scott-B07421 wrote:
> > -----Original Message-----
> > From: Wood Scott-B07421
> > Sent: Friday, September 11, 2015 6:07 AM
> > To: Zhao Qiang-B45475
> > Cc: linux-kernel@vger.kernel.org; linuxppc-dev@lists.ozlabs.org;
> > lauraa@codeaurora.org; Xie Xiaobo-R63061; benh@kernel.crashing.org; Li
> > Yang-Leo-R58472; paulus@samba.org
> > Subject: Re: [PATCH V7 1/3] genalloc:support memory-allocation with
> > bytes-alignment to genalloc
> > 
> > On Wed, 2015-09-09 at 21:26 -0500, Zhao Qiang-B45475 wrote:
> > > On Wed, 2015-09-10 at 12:38AM -0500, Wood Scott-B07421 wrote:
> > > > -----Original Message-----
> > > > From: Wood Scott-B07421
> > > > Sent: Thursday, September 10, 2015 12:38 AM
> > > > To: Zhao Qiang-B45475
> > > > Cc: linux-kernel@vger.kernel.org; linuxppc-dev@lists.ozlabs.org;
> > > > lauraa@codeaurora.org; Xie Xiaobo-R63061; benh@kernel.crashing.org;
> > > > Li Yang-Leo-R58472; paulus@samba.org
> > > > Subject: Re: [PATCH V7 1/3] genalloc:support memory-allocation with
> > > > bytes-alignment to genalloc
> > > > 
> > > > On Sat, 2015-09-05 at 22:13 -0500, Zhao Qiang-B45475 wrote:
> > > > > On Wed, 2015-09-02 at 10:18AM +0800, Wood Scott-B07421 wrote:
> > > > > > -----Original Message-----
> > > > > > From: Wood Scott-B07421
> > > > > > Sent: Wednesday, September 02, 2015 10:18 AM
> > > > > > To: Zhao Qiang-B45475
> > > > > > Cc: linux-kernel@vger.kernel.org; linuxppc-dev@lists.ozlabs.org;
> > > > > > lauraa@codeaurora.org; Xie Xiaobo-R63061;
> > > > > > benh@kernel.crashing.org; Li Yang-Leo-R58472; paulus@samba.org
> > > > > > Subject: Re: [PATCH V7 1/3] genalloc:support memory-allocation
> > > > > > with bytes-alignment to genalloc
> > > > > > 
> > > > > > On Tue, 2015-09-01 at 21:10 -0500, Zhao Qiang-B45475 wrote:
> > > > > > > On Wed, 2015-09-02 at 08:38AM +0800, Wood Scott-B07421 wrote:
> > > > > > > > -----Original Message-----
> > > > > > > > From: Wood Scott-B07421
> > > > > > > > Sent: Wednesday, September 02, 2015 8:30 AM
> > > > > > > > To: Zhao Qiang-B45475
> > > > > > > > Cc: linux-kernel@vger.kernel.org;
> > > > > > > > linuxppc-dev@lists.ozlabs.org; lauraa@codeaurora.org; Xie
> > > > > > > > Xiaobo-R63061; benh@kernel.crashing.org; Li Yang-Leo-R58472;
> > > > > > > > paulus@samba.org
> > > > > > > > Subject: Re: [PATCH V7 1/3] genalloc:support
> > > > > > > > memory-allocation with bytes-alignment to genalloc
> > > > > > > > 
> > > > > > > > On Mon, 2015-08-31 at 16:58 +0800, Zhao Qiang wrote:
> > > > > > > > > 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 <qiang.zhao@freescale.com>
> > > > > > > > > ---
> > > > > > > > > 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.
> > > > > > > > 
> > > > > > > > This seems to be describing more than just the changes in
> > > > > > > > this
> > > > patch.
> > > > > > > > What does also handling cpm have to do with this patch?  Are
> > > > > > > > you adding support for reserving a specific region in this
> > > > > > > > patch?  I don't see it, and in any case it should go in a
> > different patch.
> > > > > > > 
> > > > > > > Yes, I added. The code below can support the function.
> > > > > > >       offset_bit = (alignment->offset + (1UL << order) - 1) >>
> > > > order;
> > > > > > >       return bitmap_find_next_zero_area(map, size, start +
> > > > > > > offset_bit,
> > > > > > nr,
> > > > > > >                         align_mask);
> > > > > > > 
> > > > > > > CPM has an function cpm_muram_alloc_fixed, needing to allocate
> > > > > > > muram from a Specific offset. So I add the code and add offset
> > > > > > > to
> > > > struct data.
> > > > > > 
> > > > > > I thought the offset was related to the previous discussion of
> > > > > > checking for allocation failure.  Are you using it to implement
> > > > > > alloc_fixed()?  If so, please don't.  Besides the awkward
> > > > > > implementation (what does it logically have to do with
> > > > > > gen_pool_first_fit_align?), it does not appear to be correct -
> > > > > > - what happens with multiple chunks?  What happens if part of
> > > > > > the region the caller is trying to reserve is already taken?
> > > > > > Implement a proper function to reserve a fixed genalloc region.
> > > > > > 
> > > > > The offset is which allocation block address need to be larger
> > > > > than, Not equal to, it really like the parameter start of the
> > > > > algo(the bitnumber To start searching at).
> > > > 
> > > > cpm_muram_alloc_fixed() is not "search starting at this offset".  It
> > > > is "reserve this exact range or fail".
> > > 
> > > Yes, you are right! How about to add a new algo into genalloc to
> > > search At offset, then handle it in muram layer, if the address return
> > > from genalloc Is not equal to offset, return negative number?
> > 
> > If you're adding a new algorithm, why not make it actually do what you
> > want rather than adding something different and fixing it up in the
> > caller?
> 
> Because I'm not sure whether it is proper to add a "offset searching at" 
> algo. 

Again, "offset searching at" is not what we want anyway.  What we want is 
"allocate this range or fail".  Why would it be improper to have such an 
algorithm?

-Scott


^ permalink raw reply	[flat|nested] 42+ messages in thread

* RE: [PATCH V7 1/3] genalloc:support memory-allocation with bytes-alignment to genalloc
  2015-09-11  2:15                 ` Scott Wood
@ 2015-09-11  2:25                     ` Zhao Qiang
  0 siblings, 0 replies; 42+ messages in thread
From: Zhao Qiang @ 2015-09-11  2:25 UTC (permalink / raw)
  To: Scott Wood
  Cc: linux-kernel, linuxppc-dev, lauraa, Xiaobo Xie, benh, Li Leo, paulus

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="utf-8", Size: 7139 bytes --]

On Fri, 2015-09-11 at 10:15AM -0500, Wood Scott-B07421 wrote:
> -----Original Message-----
> From: Wood Scott-B07421
> Sent: Friday, September 11, 2015 10:15 AM
> To: Zhao Qiang-B45475
> Cc: linux-kernel@vger.kernel.org; linuxppc-dev@lists.ozlabs.org;
> lauraa@codeaurora.org; Xie Xiaobo-R63061; benh@kernel.crashing.org; Li
> Yang-Leo-R58472; paulus@samba.org
> Subject: Re: [PATCH V7 1/3] genalloc:support memory-allocation with
> bytes-alignment to genalloc
> 
> On Thu, 2015-09-10 at 21:09 -0500, Zhao Qiang-B45475 wrote:
> > On Fri, 2015-09-11 at 06:07AM -0500, Wood Scott-B07421 wrote:
> > > -----Original Message-----
> > > From: Wood Scott-B07421
> > > Sent: Friday, September 11, 2015 6:07 AM
> > > To: Zhao Qiang-B45475
> > > Cc: linux-kernel@vger.kernel.org; linuxppc-dev@lists.ozlabs.org;
> > > lauraa@codeaurora.org; Xie Xiaobo-R63061; benh@kernel.crashing.org;
> > > Li Yang-Leo-R58472; paulus@samba.org
> > > Subject: Re: [PATCH V7 1/3] genalloc:support memory-allocation with
> > > bytes-alignment to genalloc
> > >
> > > On Wed, 2015-09-09 at 21:26 -0500, Zhao Qiang-B45475 wrote:
> > > > On Wed, 2015-09-10 at 12:38AM -0500, Wood Scott-B07421 wrote:
> > > > > -----Original Message-----
> > > > > From: Wood Scott-B07421
> > > > > Sent: Thursday, September 10, 2015 12:38 AM
> > > > > To: Zhao Qiang-B45475
> > > > > Cc: linux-kernel@vger.kernel.org; linuxppc-dev@lists.ozlabs.org;
> > > > > lauraa@codeaurora.org; Xie Xiaobo-R63061;
> > > > > benh@kernel.crashing.org; Li Yang-Leo-R58472; paulus@samba.org
> > > > > Subject: Re: [PATCH V7 1/3] genalloc:support memory-allocation
> > > > > with bytes-alignment to genalloc
> > > > >
> > > > > On Sat, 2015-09-05 at 22:13 -0500, Zhao Qiang-B45475 wrote:
> > > > > > On Wed, 2015-09-02 at 10:18AM +0800, Wood Scott-B07421 wrote:
> > > > > > > -----Original Message-----
> > > > > > > From: Wood Scott-B07421
> > > > > > > Sent: Wednesday, September 02, 2015 10:18 AM
> > > > > > > To: Zhao Qiang-B45475
> > > > > > > Cc: linux-kernel@vger.kernel.org;
> > > > > > > linuxppc-dev@lists.ozlabs.org; lauraa@codeaurora.org; Xie
> > > > > > > Xiaobo-R63061; benh@kernel.crashing.org; Li Yang-Leo-R58472;
> > > > > > > paulus@samba.org
> > > > > > > Subject: Re: [PATCH V7 1/3] genalloc:support
> > > > > > > memory-allocation with bytes-alignment to genalloc
> > > > > > >
> > > > > > > On Tue, 2015-09-01 at 21:10 -0500, Zhao Qiang-B45475 wrote:
> > > > > > > > On Wed, 2015-09-02 at 08:38AM +0800, Wood Scott-B07421
> wrote:
> > > > > > > > > -----Original Message-----
> > > > > > > > > From: Wood Scott-B07421
> > > > > > > > > Sent: Wednesday, September 02, 2015 8:30 AM
> > > > > > > > > To: Zhao Qiang-B45475
> > > > > > > > > Cc: linux-kernel@vger.kernel.org;
> > > > > > > > > linuxppc-dev@lists.ozlabs.org; lauraa@codeaurora.org;
> > > > > > > > > Xie Xiaobo-R63061; benh@kernel.crashing.org; Li
> > > > > > > > > Yang-Leo-R58472; paulus@samba.org
> > > > > > > > > Subject: Re: [PATCH V7 1/3] genalloc:support
> > > > > > > > > memory-allocation with bytes-alignment to genalloc
> > > > > > > > >
> > > > > > > > > On Mon, 2015-08-31 at 16:58 +0800, Zhao Qiang wrote:
> > > > > > > > > > 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 <qiang.zhao@freescale.com>
> > > > > > > > > > ---
> > > > > > > > > > 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.
> > > > > > > > >
> > > > > > > > > This seems to be describing more than just the changes
> > > > > > > > > in this
> > > > > patch.
> > > > > > > > > What does also handling cpm have to do with this patch?
> > > > > > > > > Are you adding support for reserving a specific region
> > > > > > > > > in this patch?  I don't see it, and in any case it
> > > > > > > > > should go in a
> > > different patch.
> > > > > > > >
> > > > > > > > Yes, I added. The code below can support the function.
> > > > > > > >       offset_bit = (alignment->offset + (1UL << order) -
> > > > > > > > 1) >>
> > > > > order;
> > > > > > > >       return bitmap_find_next_zero_area(map, size, start +
> > > > > > > > offset_bit,
> > > > > > > nr,
> > > > > > > >                         align_mask);
> > > > > > > >
> > > > > > > > CPM has an function cpm_muram_alloc_fixed, needing to
> > > > > > > > allocate muram from a Specific offset. So I add the code
> > > > > > > > and add offset to
> > > > > struct data.
> > > > > > >
> > > > > > > I thought the offset was related to the previous discussion
> > > > > > > of checking for allocation failure.  Are you using it to
> > > > > > > implement alloc_fixed()?  If so, please don't.  Besides the
> > > > > > > awkward implementation (what does it logically have to do
> > > > > > > with gen_pool_first_fit_align?), it does not appear to be
> > > > > > > correct -
> > > > > > > - what happens with multiple chunks?  What happens if part
> > > > > > > of the region the caller is trying to reserve is already
> taken?
> > > > > > > Implement a proper function to reserve a fixed genalloc
> region.
> > > > > > >
> > > > > > The offset is which allocation block address need to be larger
> > > > > > than, Not equal to, it really like the parameter start of the
> > > > > > algo(the bitnumber To start searching at).
> > > > >
> > > > > cpm_muram_alloc_fixed() is not "search starting at this offset".
> > > > > It is "reserve this exact range or fail".
> > > >
> > > > Yes, you are right! How about to add a new algo into genalloc to
> > > > search At offset, then handle it in muram layer, if the address
> > > > return from genalloc Is not equal to offset, return negative number?
> > >
> > > If you're adding a new algorithm, why not make it actually do what
> > > you want rather than adding something different and fixing it up in
> > > the caller?
> >
> > Because I'm not sure whether it is proper to add a "offset searching
> at"
> > algo.
> 
> Again, "offset searching at" is not what we want anyway.  What we want is
> "allocate this range or fail".  Why would it be improper to have such an
> algorithm?

Yes, I mean "allocate this range or fail", just type wrong.
I will push another version and modify it.

> 
> -Scott

ÿôèº{.nÇ+‰·Ÿ®‰­†+%ŠËÿ±éݶ\x17¥Šwÿº{.nÇ+‰·¥Š{±þG«éÿŠ{ayº\x1dʇڙë,j\a­¢f£¢·hšïêÿ‘êçz_è®\x03(­éšŽŠÝ¢j"ú\x1a¶^[m§ÿÿ¾\a«þG«éÿ¢¸?™¨è­Ú&£ø§~á¶iO•æ¬z·švØ^\x14\x04\x1a¶^[m§ÿÿÃ\fÿ¶ìÿ¢¸?–I¥

^ permalink raw reply	[flat|nested] 42+ messages in thread

* RE: [PATCH V7 1/3] genalloc:support memory-allocation with bytes-alignment to genalloc
@ 2015-09-11  2:25                     ` Zhao Qiang
  0 siblings, 0 replies; 42+ messages in thread
From: Zhao Qiang @ 2015-09-11  2:25 UTC (permalink / raw)
  To: Scott Wood
  Cc: linux-kernel, linuxppc-dev, lauraa, Xiaobo Xie, benh, Li Leo, paulus

T24gRnJpLCAyMDE1LTA5LTExIGF0IDEwOjE1QU0gLTA1MDAsIFdvb2QgU2NvdHQtQjA3NDIxIHdy
b3RlOg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBXb29kIFNjb3R0LUIw
NzQyMQ0KPiBTZW50OiBGcmlkYXksIFNlcHRlbWJlciAxMSwgMjAxNSAxMDoxNSBBTQ0KPiBUbzog
WmhhbyBRaWFuZy1CNDU0NzUNCj4gQ2M6IGxpbnV4LWtlcm5lbEB2Z2VyLmtlcm5lbC5vcmc7IGxp
bnV4cHBjLWRldkBsaXN0cy5vemxhYnMub3JnOw0KPiBsYXVyYWFAY29kZWF1cm9yYS5vcmc7IFhp
ZSBYaWFvYm8tUjYzMDYxOyBiZW5oQGtlcm5lbC5jcmFzaGluZy5vcmc7IExpDQo+IFlhbmctTGVv
LVI1ODQ3MjsgcGF1bHVzQHNhbWJhLm9yZw0KPiBTdWJqZWN0OiBSZTogW1BBVENIIFY3IDEvM10g
Z2VuYWxsb2M6c3VwcG9ydCBtZW1vcnktYWxsb2NhdGlvbiB3aXRoDQo+IGJ5dGVzLWFsaWdubWVu
dCB0byBnZW5hbGxvYw0KPiANCj4gT24gVGh1LCAyMDE1LTA5LTEwIGF0IDIxOjA5IC0wNTAwLCBa
aGFvIFFpYW5nLUI0NTQ3NSB3cm90ZToNCj4gPiBPbiBGcmksIDIwMTUtMDktMTEgYXQgMDY6MDdB
TSAtMDUwMCwgV29vZCBTY290dC1CMDc0MjEgd3JvdGU6DQo+ID4gPiAtLS0tLU9yaWdpbmFsIE1l
c3NhZ2UtLS0tLQ0KPiA+ID4gRnJvbTogV29vZCBTY290dC1CMDc0MjENCj4gPiA+IFNlbnQ6IEZy
aWRheSwgU2VwdGVtYmVyIDExLCAyMDE1IDY6MDcgQU0NCj4gPiA+IFRvOiBaaGFvIFFpYW5nLUI0
NTQ3NQ0KPiA+ID4gQ2M6IGxpbnV4LWtlcm5lbEB2Z2VyLmtlcm5lbC5vcmc7IGxpbnV4cHBjLWRl
dkBsaXN0cy5vemxhYnMub3JnOw0KPiA+ID4gbGF1cmFhQGNvZGVhdXJvcmEub3JnOyBYaWUgWGlh
b2JvLVI2MzA2MTsgYmVuaEBrZXJuZWwuY3Jhc2hpbmcub3JnOw0KPiA+ID4gTGkgWWFuZy1MZW8t
UjU4NDcyOyBwYXVsdXNAc2FtYmEub3JnDQo+ID4gPiBTdWJqZWN0OiBSZTogW1BBVENIIFY3IDEv
M10gZ2VuYWxsb2M6c3VwcG9ydCBtZW1vcnktYWxsb2NhdGlvbiB3aXRoDQo+ID4gPiBieXRlcy1h
bGlnbm1lbnQgdG8gZ2VuYWxsb2MNCj4gPiA+DQo+ID4gPiBPbiBXZWQsIDIwMTUtMDktMDkgYXQg
MjE6MjYgLTA1MDAsIFpoYW8gUWlhbmctQjQ1NDc1IHdyb3RlOg0KPiA+ID4gPiBPbiBXZWQsIDIw
MTUtMDktMTAgYXQgMTI6MzhBTSAtMDUwMCwgV29vZCBTY290dC1CMDc0MjEgd3JvdGU6DQo+ID4g
PiA+ID4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPiA+ID4gPiBGcm9tOiBXb29kIFNj
b3R0LUIwNzQyMQ0KPiA+ID4gPiA+IFNlbnQ6IFRodXJzZGF5LCBTZXB0ZW1iZXIgMTAsIDIwMTUg
MTI6MzggQU0NCj4gPiA+ID4gPiBUbzogWmhhbyBRaWFuZy1CNDU0NzUNCj4gPiA+ID4gPiBDYzog
bGludXgta2VybmVsQHZnZXIua2VybmVsLm9yZzsgbGludXhwcGMtZGV2QGxpc3RzLm96bGFicy5v
cmc7DQo+ID4gPiA+ID4gbGF1cmFhQGNvZGVhdXJvcmEub3JnOyBYaWUgWGlhb2JvLVI2MzA2MTsN
Cj4gPiA+ID4gPiBiZW5oQGtlcm5lbC5jcmFzaGluZy5vcmc7IExpIFlhbmctTGVvLVI1ODQ3Mjsg
cGF1bHVzQHNhbWJhLm9yZw0KPiA+ID4gPiA+IFN1YmplY3Q6IFJlOiBbUEFUQ0ggVjcgMS8zXSBn
ZW5hbGxvYzpzdXBwb3J0IG1lbW9yeS1hbGxvY2F0aW9uDQo+ID4gPiA+ID4gd2l0aCBieXRlcy1h
bGlnbm1lbnQgdG8gZ2VuYWxsb2MNCj4gPiA+ID4gPg0KPiA+ID4gPiA+IE9uIFNhdCwgMjAxNS0w
OS0wNSBhdCAyMjoxMyAtMDUwMCwgWmhhbyBRaWFuZy1CNDU0NzUgd3JvdGU6DQo+ID4gPiA+ID4g
PiBPbiBXZWQsIDIwMTUtMDktMDIgYXQgMTA6MThBTSArMDgwMCwgV29vZCBTY290dC1CMDc0MjEg
d3JvdGU6DQo+ID4gPiA+ID4gPiA+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4gPiA+
ID4gPiA+IEZyb206IFdvb2QgU2NvdHQtQjA3NDIxDQo+ID4gPiA+ID4gPiA+IFNlbnQ6IFdlZG5l
c2RheSwgU2VwdGVtYmVyIDAyLCAyMDE1IDEwOjE4IEFNDQo+ID4gPiA+ID4gPiA+IFRvOiBaaGFv
IFFpYW5nLUI0NTQ3NQ0KPiA+ID4gPiA+ID4gPiBDYzogbGludXgta2VybmVsQHZnZXIua2VybmVs
Lm9yZzsNCj4gPiA+ID4gPiA+ID4gbGludXhwcGMtZGV2QGxpc3RzLm96bGFicy5vcmc7IGxhdXJh
YUBjb2RlYXVyb3JhLm9yZzsgWGllDQo+ID4gPiA+ID4gPiA+IFhpYW9iby1SNjMwNjE7IGJlbmhA
a2VybmVsLmNyYXNoaW5nLm9yZzsgTGkgWWFuZy1MZW8tUjU4NDcyOw0KPiA+ID4gPiA+ID4gPiBw
YXVsdXNAc2FtYmEub3JnDQo+ID4gPiA+ID4gPiA+IFN1YmplY3Q6IFJlOiBbUEFUQ0ggVjcgMS8z
XSBnZW5hbGxvYzpzdXBwb3J0DQo+ID4gPiA+ID4gPiA+IG1lbW9yeS1hbGxvY2F0aW9uIHdpdGgg
Ynl0ZXMtYWxpZ25tZW50IHRvIGdlbmFsbG9jDQo+ID4gPiA+ID4gPiA+DQo+ID4gPiA+ID4gPiA+
IE9uIFR1ZSwgMjAxNS0wOS0wMSBhdCAyMToxMCAtMDUwMCwgWmhhbyBRaWFuZy1CNDU0NzUgd3Jv
dGU6DQo+ID4gPiA+ID4gPiA+ID4gT24gV2VkLCAyMDE1LTA5LTAyIGF0IDA4OjM4QU0gKzA4MDAs
IFdvb2QgU2NvdHQtQjA3NDIxDQo+IHdyb3RlOg0KPiA+ID4gPiA+ID4gPiA+ID4gLS0tLS1Pcmln
aW5hbCBNZXNzYWdlLS0tLS0NCj4gPiA+ID4gPiA+ID4gPiA+IEZyb206IFdvb2QgU2NvdHQtQjA3
NDIxDQo+ID4gPiA+ID4gPiA+ID4gPiBTZW50OiBXZWRuZXNkYXksIFNlcHRlbWJlciAwMiwgMjAx
NSA4OjMwIEFNDQo+ID4gPiA+ID4gPiA+ID4gPiBUbzogWmhhbyBRaWFuZy1CNDU0NzUNCj4gPiA+
ID4gPiA+ID4gPiA+IENjOiBsaW51eC1rZXJuZWxAdmdlci5rZXJuZWwub3JnOw0KPiA+ID4gPiA+
ID4gPiA+ID4gbGludXhwcGMtZGV2QGxpc3RzLm96bGFicy5vcmc7IGxhdXJhYUBjb2RlYXVyb3Jh
Lm9yZzsNCj4gPiA+ID4gPiA+ID4gPiA+IFhpZSBYaWFvYm8tUjYzMDYxOyBiZW5oQGtlcm5lbC5j
cmFzaGluZy5vcmc7IExpDQo+ID4gPiA+ID4gPiA+ID4gPiBZYW5nLUxlby1SNTg0NzI7IHBhdWx1
c0BzYW1iYS5vcmcNCj4gPiA+ID4gPiA+ID4gPiA+IFN1YmplY3Q6IFJlOiBbUEFUQ0ggVjcgMS8z
XSBnZW5hbGxvYzpzdXBwb3J0DQo+ID4gPiA+ID4gPiA+ID4gPiBtZW1vcnktYWxsb2NhdGlvbiB3
aXRoIGJ5dGVzLWFsaWdubWVudCB0byBnZW5hbGxvYw0KPiA+ID4gPiA+ID4gPiA+ID4NCj4gPiA+
ID4gPiA+ID4gPiA+IE9uIE1vbiwgMjAxNS0wOC0zMSBhdCAxNjo1OCArMDgwMCwgWmhhbyBRaWFu
ZyB3cm90ZToNCj4gPiA+ID4gPiA+ID4gPiA+ID4gQnl0ZXMgYWxpZ25tZW50IGlzIHJlcXVpcmVk
IHRvIG1hbmFnZSBzb21lIHNwZWNpYWwNCj4gPiA+ID4gPiA+ID4gPiA+ID4gUkFNLCBzbyBhZGQg
Z2VuX3Bvb2xfZmlyc3RfZml0X2FsaWduIHRvIGdlbmFsbG9jLA0KPiA+ID4gPiA+ID4gPiA+ID4g
PiBtZWFud2hpbGUgYWRkIGdlbl9wb29sX2FsbG9jX2RhdGEgdG8gcGFzcyBkYXRhIHRvDQo+ID4g
PiA+ID4gPiA+ID4gPiA+IGdlbl9wb29sX2ZpcnN0X2ZpdF9hbGlnbihtb2RpZnkgZ2VuX3Bvb2xf
YWxsb2MgYXMgYQ0KPiA+ID4gPiA+ID4gPiA+ID4gPiB3cmFwcGVyKQ0KPiA+ID4gPiA+ID4gPiA+
ID4gPg0KPiA+ID4gPiA+ID4gPiA+ID4gPiBTaWduZWQtb2ZmLWJ5OiBaaGFvIFFpYW5nIDxxaWFu
Zy56aGFvQGZyZWVzY2FsZS5jb20+DQo+ID4gPiA+ID4gPiA+ID4gPiA+IC0tLQ0KPiA+ID4gPiA+
ID4gPiA+ID4gPiBDaGFuZ2VzIGZvciB2NjoNCj4gPiA+ID4gPiA+ID4gPiA+ID4gICAgICAgLSBw
YXRjaGVzIHNldCB2NiBpbmNsdWRlIGEgbmV3IHBhdGNoIGJlY2F1c2Ugb2YNCj4gdXNpbmcNCj4g
PiA+ID4gPiA+ID4gPiA+ID4gICAgICAgLSBnZW5hbGxvYyB0byBtYW5hZ2UgUUUgTVVSQU0sIHBh
dGNoIDAwMDEgaXMgdGhlDQo+IG5ldw0KPiA+ID4gPiA+ID4gPiA+ID4gPiAgICAgICAtIHBhdGNo
LCBhZGRpbmcgYnl0ZXMgYWxpZ25tZW50IGZvciBhbGxvY2F0aW9uDQo+ID4gPiA+ID4gPiA+ID4g
PiA+IGZvcg0KPiA+ID4gdXNlLg0KPiA+ID4gPiA+ID4gPiA+ID4gPiBDaGFuZ2VzIGZvciB2NzoN
Cj4gPiA+ID4gPiA+ID4gPiA+ID4gICAgICAgLSBjcG0gbXVyYW0gYWxzbyBuZWVkIHRvIHVzZSBn
ZW5hbGxvYyB0byBtYW5hZ2UsDQo+ID4gPiA+ID4gPiA+ID4gPiA+IGl0DQo+ID4gPiBoYXMNCj4g
PiA+ID4gPiA+ID4gPiA+ID4gICAgICAgICBhIGZ1bmN0aW9uIHRvIHJlc2VydmUgYSBzcGVjaWZp
YyByZWdpb24gb2YNCj4gbXVyYW0sDQo+ID4gPiA+ID4gPiA+ID4gPiA+ICAgICAgICAgYWRkIG9m
ZnNldCB0byBnZW5wb29sX2RhdGEgZm9yIHN0YXJ0IGFkZHIgdG8NCj4gPiA+ID4gPiA+ID4gPiA+
ID4gYmUNCj4gPiA+ID4gPiBhbGxvY2F0ZWQuDQo+ID4gPiA+ID4gPiA+ID4gPg0KPiA+ID4gPiA+
ID4gPiA+ID4gVGhpcyBzZWVtcyB0byBiZSBkZXNjcmliaW5nIG1vcmUgdGhhbiBqdXN0IHRoZSBj
aGFuZ2VzDQo+ID4gPiA+ID4gPiA+ID4gPiBpbiB0aGlzDQo+ID4gPiA+ID4gcGF0Y2guDQo+ID4g
PiA+ID4gPiA+ID4gPiBXaGF0IGRvZXMgYWxzbyBoYW5kbGluZyBjcG0gaGF2ZSB0byBkbyB3aXRo
IHRoaXMgcGF0Y2g/DQo+ID4gPiA+ID4gPiA+ID4gPiBBcmUgeW91IGFkZGluZyBzdXBwb3J0IGZv
ciByZXNlcnZpbmcgYSBzcGVjaWZpYyByZWdpb24NCj4gPiA+ID4gPiA+ID4gPiA+IGluIHRoaXMg
cGF0Y2g/ICBJIGRvbid0IHNlZSBpdCwgYW5kIGluIGFueSBjYXNlIGl0DQo+ID4gPiA+ID4gPiA+
ID4gPiBzaG91bGQgZ28gaW4gYQ0KPiA+ID4gZGlmZmVyZW50IHBhdGNoLg0KPiA+ID4gPiA+ID4g
PiA+DQo+ID4gPiA+ID4gPiA+ID4gWWVzLCBJIGFkZGVkLiBUaGUgY29kZSBiZWxvdyBjYW4gc3Vw
cG9ydCB0aGUgZnVuY3Rpb24uDQo+ID4gPiA+ID4gPiA+ID4gICAgICAgb2Zmc2V0X2JpdCA9IChh
bGlnbm1lbnQtPm9mZnNldCArICgxVUwgPDwgb3JkZXIpIC0NCj4gPiA+ID4gPiA+ID4gPiAxKSA+
Pg0KPiA+ID4gPiA+IG9yZGVyOw0KPiA+ID4gPiA+ID4gPiA+ICAgICAgIHJldHVybiBiaXRtYXBf
ZmluZF9uZXh0X3plcm9fYXJlYShtYXAsIHNpemUsIHN0YXJ0ICsNCj4gPiA+ID4gPiA+ID4gPiBv
ZmZzZXRfYml0LA0KPiA+ID4gPiA+ID4gPiBuciwNCj4gPiA+ID4gPiA+ID4gPiAgICAgICAgICAg
ICAgICAgICAgICAgICBhbGlnbl9tYXNrKTsNCj4gPiA+ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4g
PiA+IENQTSBoYXMgYW4gZnVuY3Rpb24gY3BtX211cmFtX2FsbG9jX2ZpeGVkLCBuZWVkaW5nIHRv
DQo+ID4gPiA+ID4gPiA+ID4gYWxsb2NhdGUgbXVyYW0gZnJvbSBhIFNwZWNpZmljIG9mZnNldC4g
U28gSSBhZGQgdGhlIGNvZGUNCj4gPiA+ID4gPiA+ID4gPiBhbmQgYWRkIG9mZnNldCB0bw0KPiA+
ID4gPiA+IHN0cnVjdCBkYXRhLg0KPiA+ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4gPiBJIHRob3Vn
aHQgdGhlIG9mZnNldCB3YXMgcmVsYXRlZCB0byB0aGUgcHJldmlvdXMgZGlzY3Vzc2lvbg0KPiA+
ID4gPiA+ID4gPiBvZiBjaGVja2luZyBmb3IgYWxsb2NhdGlvbiBmYWlsdXJlLiAgQXJlIHlvdSB1
c2luZyBpdCB0bw0KPiA+ID4gPiA+ID4gPiBpbXBsZW1lbnQgYWxsb2NfZml4ZWQoKT8gIElmIHNv
LCBwbGVhc2UgZG9uJ3QuICBCZXNpZGVzIHRoZQ0KPiA+ID4gPiA+ID4gPiBhd2t3YXJkIGltcGxl
bWVudGF0aW9uICh3aGF0IGRvZXMgaXQgbG9naWNhbGx5IGhhdmUgdG8gZG8NCj4gPiA+ID4gPiA+
ID4gd2l0aCBnZW5fcG9vbF9maXJzdF9maXRfYWxpZ24/KSwgaXQgZG9lcyBub3QgYXBwZWFyIHRv
IGJlDQo+ID4gPiA+ID4gPiA+IGNvcnJlY3QgLQ0KPiA+ID4gPiA+ID4gPiAtIHdoYXQgaGFwcGVu
cyB3aXRoIG11bHRpcGxlIGNodW5rcz8gIFdoYXQgaGFwcGVucyBpZiBwYXJ0DQo+ID4gPiA+ID4g
PiA+IG9mIHRoZSByZWdpb24gdGhlIGNhbGxlciBpcyB0cnlpbmcgdG8gcmVzZXJ2ZSBpcyBhbHJl
YWR5DQo+IHRha2VuPw0KPiA+ID4gPiA+ID4gPiBJbXBsZW1lbnQgYSBwcm9wZXIgZnVuY3Rpb24g
dG8gcmVzZXJ2ZSBhIGZpeGVkIGdlbmFsbG9jDQo+IHJlZ2lvbi4NCj4gPiA+ID4gPiA+ID4NCj4g
PiA+ID4gPiA+IFRoZSBvZmZzZXQgaXMgd2hpY2ggYWxsb2NhdGlvbiBibG9jayBhZGRyZXNzIG5l
ZWQgdG8gYmUgbGFyZ2VyDQo+ID4gPiA+ID4gPiB0aGFuLCBOb3QgZXF1YWwgdG8sIGl0IHJlYWxs
eSBsaWtlIHRoZSBwYXJhbWV0ZXIgc3RhcnQgb2YgdGhlDQo+ID4gPiA+ID4gPiBhbGdvKHRoZSBi
aXRudW1iZXIgVG8gc3RhcnQgc2VhcmNoaW5nIGF0KS4NCj4gPiA+ID4gPg0KPiA+ID4gPiA+IGNw
bV9tdXJhbV9hbGxvY19maXhlZCgpIGlzIG5vdCAic2VhcmNoIHN0YXJ0aW5nIGF0IHRoaXMgb2Zm
c2V0Ii4NCj4gPiA+ID4gPiBJdCBpcyAicmVzZXJ2ZSB0aGlzIGV4YWN0IHJhbmdlIG9yIGZhaWwi
Lg0KPiA+ID4gPg0KPiA+ID4gPiBZZXMsIHlvdSBhcmUgcmlnaHQhIEhvdyBhYm91dCB0byBhZGQg
YSBuZXcgYWxnbyBpbnRvIGdlbmFsbG9jIHRvDQo+ID4gPiA+IHNlYXJjaCBBdCBvZmZzZXQsIHRo
ZW4gaGFuZGxlIGl0IGluIG11cmFtIGxheWVyLCBpZiB0aGUgYWRkcmVzcw0KPiA+ID4gPiByZXR1
cm4gZnJvbSBnZW5hbGxvYyBJcyBub3QgZXF1YWwgdG8gb2Zmc2V0LCByZXR1cm4gbmVnYXRpdmUg
bnVtYmVyPw0KPiA+ID4NCj4gPiA+IElmIHlvdSdyZSBhZGRpbmcgYSBuZXcgYWxnb3JpdGhtLCB3
aHkgbm90IG1ha2UgaXQgYWN0dWFsbHkgZG8gd2hhdA0KPiA+ID4geW91IHdhbnQgcmF0aGVyIHRo
YW4gYWRkaW5nIHNvbWV0aGluZyBkaWZmZXJlbnQgYW5kIGZpeGluZyBpdCB1cCBpbg0KPiA+ID4g
dGhlIGNhbGxlcj8NCj4gPg0KPiA+IEJlY2F1c2UgSSdtIG5vdCBzdXJlIHdoZXRoZXIgaXQgaXMg
cHJvcGVyIHRvIGFkZCBhICJvZmZzZXQgc2VhcmNoaW5nDQo+IGF0Ig0KPiA+IGFsZ28uDQo+IA0K
PiBBZ2FpbiwgIm9mZnNldCBzZWFyY2hpbmcgYXQiIGlzIG5vdCB3aGF0IHdlIHdhbnQgYW55d2F5
LiAgV2hhdCB3ZSB3YW50IGlzDQo+ICJhbGxvY2F0ZSB0aGlzIHJhbmdlIG9yIGZhaWwiLiAgV2h5
IHdvdWxkIGl0IGJlIGltcHJvcGVyIHRvIGhhdmUgc3VjaCBhbg0KPiBhbGdvcml0aG0/DQoNClll
cywgSSBtZWFuICJhbGxvY2F0ZSB0aGlzIHJhbmdlIG9yIGZhaWwiLCBqdXN0IHR5cGUgd3Jvbmcu
DQpJIHdpbGwgcHVzaCBhbm90aGVyIHZlcnNpb24gYW5kIG1vZGlmeSBpdC4NCg0KPiANCj4gLVNj
b3R0DQoNCg==

^ permalink raw reply	[flat|nested] 42+ messages in thread

end of thread, other threads:[~2015-09-11  2:25 UTC | newest]

Thread overview: 42+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-08-31  8:58 [PATCH V7 1/3] genalloc:support memory-allocation with bytes-alignment to genalloc Zhao Qiang
2015-08-31  8:58 ` [PATCH V7 2/3] qe_common: add qe_muram_ functions to manage muram Zhao Qiang
2015-09-02  0:34   ` Scott Wood
2015-09-02  2:22     ` Zhao Qiang
2015-09-02  2:22       ` Zhao Qiang
2015-09-02  2:30       ` Scott Wood
2015-09-02  2:32         ` Zhao Qiang
2015-09-02  2:32           ` Zhao Qiang
2015-09-06  6:37     ` Zhao Qiang
2015-09-06  6:37       ` Zhao Qiang
2015-09-09 16:38       ` Scott Wood
2015-09-10  2:34         ` Zhao Qiang
2015-09-10  2:34           ` Zhao Qiang
2015-09-10 22:09           ` Scott Wood
2015-09-11  1:59             ` Zhao Qiang
2015-09-11  1:59               ` Zhao Qiang
2015-09-11  2:05               ` Scott Wood
2015-08-31  8:58 ` [PATCH V7 3/3] QE: Move QE from arch/powerpc to drivers/soc Zhao Qiang
2015-09-02  0:30 ` [PATCH V7 1/3] genalloc:support memory-allocation with bytes-alignment to genalloc Scott Wood
2015-09-02  2:10   ` Zhao Qiang
2015-09-02  2:10     ` Zhao Qiang
2015-09-02  2:18     ` Scott Wood
2015-09-02  2:29       ` Zhao Qiang
2015-09-02  2:29         ` Zhao Qiang
2015-09-02  2:33         ` Scott Wood
2015-09-02  3:05           ` Zhao Qiang
2015-09-02  3:05             ` Zhao Qiang
2015-09-02  3:08             ` Scott Wood
2015-09-02  3:57               ` Zhao Qiang
2015-09-02  3:57                 ` Zhao Qiang
2015-09-02  4:51                 ` Scott Wood
2015-09-06  3:13       ` Zhao Qiang
2015-09-06  3:13         ` Zhao Qiang
2015-09-09 16:37         ` Scott Wood
2015-09-10  2:26           ` Zhao Qiang
2015-09-10  2:26             ` Zhao Qiang
2015-09-10 22:07             ` Scott Wood
2015-09-11  2:09               ` Zhao Qiang
2015-09-11  2:09                 ` Zhao Qiang
2015-09-11  2:15                 ` Scott Wood
2015-09-11  2:25                   ` Zhao Qiang
2015-09-11  2:25                     ` Zhao Qiang

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.