* [PATCH 0/5] drivers: uio: new driver uio_fsl_85xx_cache_sram @ 2020-04-15 12:33 Wang Wenhu 2020-04-15 12:33 ` [PATCH 1/5] powerpc: 85xx: make FSL_85XX_CACHE_SRAM configurable Wang Wenhu ` (4 more replies) 0 siblings, 5 replies; 46+ messages in thread From: Wang Wenhu @ 2020-04-15 12:33 UTC (permalink / raw) To: gregkh, linux-kernel, oss, christophe.leroy, linuxppc-dev Cc: kernel, Wang Wenhu This series add a new uio driver for freescale 85xx platforms to access the Cache-Sram form user level. This is extremely helpful for the user-space applications that require high performance memory accesses. It fixes the compile errors and warning of the hardware level drivers and implements the uio driver in uio_fsl_85xx_cache_sram.c. Wang Wenhu (5): powerpc: 85xx: make FSL_85XX_CACHE_SRAM configurable powerpc: sysdev: fix compile error for fsl_85xx_cache_sram powerpc: sysdev: fix compile warning for fsl_85xx_cache_sram powerpc: sysdev: fix compile error for fsl_85xx_l2ctlr drivers: uio: new driver for fsl_85xx_cache_sram arch/powerpc/platforms/85xx/Kconfig | 2 +- arch/powerpc/platforms/Kconfig.cputype | 5 +- arch/powerpc/sysdev/fsl_85xx_cache_sram.c | 3 +- arch/powerpc/sysdev/fsl_85xx_l2ctlr.c | 1 + drivers/uio/Kconfig | 8 + drivers/uio/Makefile | 1 + drivers/uio/uio_fsl_85xx_cache_sram.c | 195 ++++++++++++++++++++++ 7 files changed, 211 insertions(+), 4 deletions(-) create mode 100644 drivers/uio/uio_fsl_85xx_cache_sram.c -- 2.17.1 ^ permalink raw reply [flat|nested] 46+ messages in thread
* [PATCH 1/5] powerpc: 85xx: make FSL_85XX_CACHE_SRAM configurable 2020-04-15 12:33 [PATCH 0/5] drivers: uio: new driver uio_fsl_85xx_cache_sram Wang Wenhu @ 2020-04-15 12:33 ` Wang Wenhu 2020-04-16 0:58 ` kbuild test robot 2020-04-15 12:33 ` [PATCH 2/5] powerpc: sysdev: fix compile error for fsl_85xx_cache_sram Wang Wenhu ` (3 subsequent siblings) 4 siblings, 1 reply; 46+ messages in thread From: Wang Wenhu @ 2020-04-15 12:33 UTC (permalink / raw) To: gregkh, linux-kernel, oss, christophe.leroy, linuxppc-dev Cc: kernel, Wang Wenhu, Michael Ellerman Enable FSL_85XX_CACHE_SRAM selection. On e500 platforms, the cache could be configured and used as a piece of SRAM which is hignly friendly for some user level application performances. Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Christophe Leroy <christophe.leroy@c-s.fr> Cc: Scott Wood <oss@buserror.net> Cc: Michael Ellerman <mpe@ellerman.id.au> Cc: linuxppc-dev@lists.ozlabs.org Signed-off-by: Wang Wenhu <wenhu.wang@vivo.com> --- arch/powerpc/platforms/85xx/Kconfig | 2 +- arch/powerpc/platforms/Kconfig.cputype | 5 +++-- 2 files changed, 4 insertions(+), 3 deletions(-) diff --git a/arch/powerpc/platforms/85xx/Kconfig b/arch/powerpc/platforms/85xx/Kconfig index fa3d29dcb57e..6debb4f1b9cc 100644 --- a/arch/powerpc/platforms/85xx/Kconfig +++ b/arch/powerpc/platforms/85xx/Kconfig @@ -17,7 +17,7 @@ if FSL_SOC_BOOKE if PPC32 config FSL_85XX_CACHE_SRAM - bool + bool "Freescale 85xx Cache-Sram" select PPC_LIB_RHEAP help When selected, this option enables cache-sram support diff --git a/arch/powerpc/platforms/Kconfig.cputype b/arch/powerpc/platforms/Kconfig.cputype index 0c3c1902135c..1921e9a573e8 100644 --- a/arch/powerpc/platforms/Kconfig.cputype +++ b/arch/powerpc/platforms/Kconfig.cputype @@ -1,6 +1,6 @@ # SPDX-License-Identifier: GPL-2.0 config PPC32 - bool + bool "32-bit kernel" default y if !PPC64 select KASAN_VMALLOC if KASAN && MODULES @@ -15,6 +15,7 @@ config PPC_BOOK3S_32 bool menu "Processor support" + choice prompt "Processor Type" depends on PPC32 @@ -211,9 +212,9 @@ config PPC_BOOK3E depends on PPC_BOOK3E_64 config E500 + bool "e500 Support" select FSL_EMB_PERFMON select PPC_FSL_BOOK3E - bool config PPC_E500MC bool "e500mc Support" -- 2.17.1 ^ permalink raw reply related [flat|nested] 46+ messages in thread
* Re: [PATCH 1/5] powerpc: 85xx: make FSL_85XX_CACHE_SRAM configurable 2020-04-15 12:33 ` [PATCH 1/5] powerpc: 85xx: make FSL_85XX_CACHE_SRAM configurable Wang Wenhu @ 2020-04-16 0:58 ` kbuild test robot 0 siblings, 0 replies; 46+ messages in thread From: kbuild test robot @ 2020-04-16 0:58 UTC (permalink / raw) To: Wang Wenhu, gregkh, linux-kernel, oss, christophe.leroy, linuxppc-dev Cc: kbuild-all, kernel, Wang Wenhu [-- Attachment #1: Type: text/plain, Size: 21439 bytes --] Hi Wang, Thank you for the patch! Yet something to improve: [auto build test ERROR on powerpc/next] [also build test ERROR on char-misc/char-misc-testing staging/staging-testing v5.7-rc1 next-20200415] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system. BTW, we also suggest to use '--base' option to specify the base tree in git format-patch, please see https://stackoverflow.com/a/37406982] url: https://github.com/0day-ci/linux/commits/Wang-Wenhu/drivers-uio-new-driver-uio_fsl_85xx_cache_sram/20200416-040633 base: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git next config: powerpc-allyesconfig (attached as .config) compiler: powerpc64-linux-gcc (GCC) 9.3.0 reproduce: wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross # save the attached .config to linux build tree COMPILER_INSTALL_PATH=$HOME/0day GCC_VERSION=9.3.0 make.cross ARCH=powerpc If you fix the issue, kindly add following tag as appropriate Reported-by: kbuild test robot <lkp@intel.com> All error/warnings (new ones prefixed by >>): WARNING: unmet direct dependencies detected for ARCH_32BIT_OFF_T Depends on !64BIT Selected by - PPC && PPC32 In file included from include/linux/atomic-fallback.h:1185, from include/linux/atomic.h:74, from include/linux/debug_locks.h:6, from include/linux/lockdep.h:28, from include/linux/spinlock_types.h:18, from kernel/bounds.c:14: >> include/asm-generic/atomic64.h:14:3: error: conflicting types for 'atomic64_t' 14 | } atomic64_t; | ^~~~~~~~~~ In file included from include/linux/page-flags.h:9, from kernel/bounds.c:10: include/linux/types.h:178:3: note: previous declaration of 'atomic64_t' was here 178 | } atomic64_t; | ^~~~~~~~~~ In file included from include/linux/atomic-fallback.h:1185, from include/linux/atomic.h:74, from include/linux/debug_locks.h:6, from include/linux/lockdep.h:28, from include/linux/spinlock_types.h:18, from kernel/bounds.c:14: >> include/asm-generic/atomic64.h:18:12: error: conflicting types for 'atomic64_read' 18 | extern s64 atomic64_read(const atomic64_t | ^~~~~~~~~~~~~ In file included from include/linux/atomic.h:7, from include/linux/debug_locks.h:6, from include/linux/lockdep.h:28, from include/linux/spinlock_types.h:18, from kernel/bounds.c:14: arch/powerpc/include/asm/atomic.h:300:23: note: previous definition of 'atomic64_read' was here 300 | static __inline__ s64 atomic64_read(const atomic64_t | ^~~~~~~~~~~~~ In file included from include/linux/atomic-fallback.h:1185, from include/linux/atomic.h:74, from include/linux/debug_locks.h:6, from include/linux/lockdep.h:28, from include/linux/spinlock_types.h:18, from kernel/bounds.c:14: >> include/asm-generic/atomic64.h:19:13: error: conflicting types for 'atomic64_set' 19 | extern void atomic64_set(atomic64_t s64 i); | ^~~~~~~~~~~~ In file included from include/linux/atomic.h:7, from include/linux/debug_locks.h:6, from include/linux/lockdep.h:28, from include/linux/spinlock_types.h:18, from kernel/bounds.c:14: arch/powerpc/include/asm/atomic.h:309:24: note: previous definition of 'atomic64_set' was here 309 | static __inline__ void atomic64_set(atomic64_t s64 i) | ^~~~~~~~~~~~ In file included from include/linux/atomic-fallback.h:1185, from include/linux/atomic.h:74, from include/linux/debug_locks.h:6, from include/linux/lockdep.h:28, from include/linux/spinlock_types.h:18, from kernel/bounds.c:14: >> include/asm-generic/atomic64.h:32: warning: "ATOMIC64_OPS" redefined 32 | #define ATOMIC64_OPS(op) ATOMIC64_OP(op) ATOMIC64_OP_RETURN(op) ATOMIC64_FETCH_OP(op) | In file included from include/linux/atomic.h:7, from include/linux/debug_locks.h:6, from include/linux/lockdep.h:28, from include/linux/spinlock_types.h:18, from kernel/bounds.c:14: arch/powerpc/include/asm/atomic.h:380: note: this is the location of the previous definition 380 | #define ATOMIC64_OPS(op, asm_op) | In file included from include/linux/atomic-fallback.h:1185, from include/linux/atomic.h:74, from include/linux/debug_locks.h:6, from include/linux/lockdep.h:28, from include/linux/spinlock_types.h:18, from kernel/bounds.c:14: >> include/asm-generic/atomic64.h:24:14: error: conflicting types for 'atomic64_add' 24 | extern void atomic64_##op(s64 a, atomic64_t | ^~~~~~~~~ >> include/asm-generic/atomic64.h:32:26: note: in expansion of macro 'ATOMIC64_OP' 32 | #define ATOMIC64_OPS(op) ATOMIC64_OP(op) ATOMIC64_OP_RETURN(op) ATOMIC64_FETCH_OP(op) | ^~~~~~~~~~~ >> include/asm-generic/atomic64.h:34:1: note: in expansion of macro 'ATOMIC64_OPS' 34 | ATOMIC64_OPS(add) | ^~~~~~~~~~~~ In file included from include/linux/atomic.h:7, from include/linux/debug_locks.h:6, from include/linux/lockdep.h:28, from include/linux/spinlock_types.h:18, from kernel/bounds.c:14: arch/powerpc/include/asm/atomic.h:315:24: note: previous definition of 'atomic64_add' was here 315 | static __inline__ void atomic64_##op(s64 a, atomic64_t | ^~~~~~~~~ >> arch/powerpc/include/asm/atomic.h:366:2: note: in expansion of macro 'ATOMIC64_OP' 366 | ATOMIC64_OP(op, asm_op) | ^~~~~~~~~~~ >> arch/powerpc/include/asm/atomic.h:370:1: note: in expansion of macro 'ATOMIC64_OPS' 370 | ATOMIC64_OPS(add, add) | ^~~~~~~~~~~~ In file included from include/linux/atomic-fallback.h:1185, from include/linux/atomic.h:74, from include/linux/debug_locks.h:6, from include/linux/lockdep.h:28, from include/linux/spinlock_types.h:18, from kernel/bounds.c:14: >> include/asm-generic/atomic64.h:24:14: error: conflicting types for 'atomic64_sub' 24 | extern void atomic64_##op(s64 a, atomic64_t | ^~~~~~~~~ >> include/asm-generic/atomic64.h:32:26: note: in expansion of macro 'ATOMIC64_OP' 32 | #define ATOMIC64_OPS(op) ATOMIC64_OP(op) ATOMIC64_OP_RETURN(op) ATOMIC64_FETCH_OP(op) | ^~~~~~~~~~~ include/asm-generic/atomic64.h:35:1: note: in expansion of macro 'ATOMIC64_OPS' 35 | ATOMIC64_OPS(sub) | ^~~~~~~~~~~~ In file included from include/linux/atomic.h:7, from include/linux/debug_locks.h:6, from include/linux/lockdep.h:28, from include/linux/spinlock_types.h:18, from kernel/bounds.c:14: arch/powerpc/include/asm/atomic.h:315:24: note: previous definition of 'atomic64_sub' was here 315 | static __inline__ void atomic64_##op(s64 a, atomic64_t | ^~~~~~~~~ >> arch/powerpc/include/asm/atomic.h:366:2: note: in expansion of macro 'ATOMIC64_OP' 366 | ATOMIC64_OP(op, asm_op) | ^~~~~~~~~~~ arch/powerpc/include/asm/atomic.h:371:1: note: in expansion of macro 'ATOMIC64_OPS' 371 | ATOMIC64_OPS(sub, subf) | ^~~~~~~~~~~~ In file included from include/linux/atomic-fallback.h:1185, from include/linux/atomic.h:74, from include/linux/debug_locks.h:6, from include/linux/lockdep.h:28, from include/linux/spinlock_types.h:18, from kernel/bounds.c:14: >> include/asm-generic/atomic64.h:24:14: error: conflicting types for 'atomic64_and' 24 | extern void atomic64_##op(s64 a, atomic64_t | ^~~~~~~~~ include/asm-generic/atomic64.h:38:26: note: in expansion of macro 'ATOMIC64_OP' 38 | #define ATOMIC64_OPS(op) ATOMIC64_OP(op) ATOMIC64_FETCH_OP(op) | ^~~~~~~~~~~ include/asm-generic/atomic64.h:40:1: note: in expansion of macro 'ATOMIC64_OPS' 40 | ATOMIC64_OPS(and) | ^~~~~~~~~~~~ In file included from include/linux/atomic.h:7, from include/linux/debug_locks.h:6, from include/linux/lockdep.h:28, from include/linux/spinlock_types.h:18, from kernel/bounds.c:14: arch/powerpc/include/asm/atomic.h:315:24: note: previous definition of 'atomic64_and' was here 315 | static __inline__ void atomic64_##op(s64 a, atomic64_t | ^~~~~~~~~ arch/powerpc/include/asm/atomic.h:381:2: note: in expansion of macro 'ATOMIC64_OP' 381 | ATOMIC64_OP(op, asm_op) | ^~~~~~~~~~~ arch/powerpc/include/asm/atomic.h:384:1: note: in expansion of macro 'ATOMIC64_OPS' 384 | ATOMIC64_OPS(and, and) | ^~~~~~~~~~~~ In file included from include/linux/atomic-fallback.h:1185, from include/linux/atomic.h:74, from include/linux/debug_locks.h:6, from include/linux/lockdep.h:28, from include/linux/spinlock_types.h:18, from kernel/bounds.c:14: >> include/asm-generic/atomic64.h:24:14: error: conflicting types for 'atomic64_or' 24 | extern void atomic64_##op(s64 a, atomic64_t | ^~~~~~~~~ include/asm-generic/atomic64.h:38:26: note: in expansion of macro 'ATOMIC64_OP' 38 | #define ATOMIC64_OPS(op) ATOMIC64_OP(op) ATOMIC64_FETCH_OP(op) | ^~~~~~~~~~~ include/asm-generic/atomic64.h:41:1: note: in expansion of macro 'ATOMIC64_OPS' 41 | ATOMIC64_OPS(or) | ^~~~~~~~~~~~ In file included from include/linux/atomic.h:7, from include/linux/debug_locks.h:6, from include/linux/lockdep.h:28, from include/linux/spinlock_types.h:18, from kernel/bounds.c:14: arch/powerpc/include/asm/atomic.h:315:24: note: previous definition of 'atomic64_or' was here 315 | static __inline__ void atomic64_##op(s64 a, atomic64_t | ^~~~~~~~~ arch/powerpc/include/asm/atomic.h:381:2: note: in expansion of macro 'ATOMIC64_OP' 381 | ATOMIC64_OP(op, asm_op) | ^~~~~~~~~~~ arch/powerpc/include/asm/atomic.h:385:1: note: in expansion of macro 'ATOMIC64_OPS' 385 | ATOMIC64_OPS(or, or) | ^~~~~~~~~~~~ In file included from include/linux/atomic-fallback.h:1185, from include/linux/atomic.h:74, from include/linux/debug_locks.h:6, from include/linux/lockdep.h:28, from include/linux/spinlock_types.h:18, from kernel/bounds.c:14: >> include/asm-generic/atomic64.h:24:14: error: conflicting types for 'atomic64_xor' 24 | extern void atomic64_##op(s64 a, atomic64_t | ^~~~~~~~~ include/asm-generic/atomic64.h:38:26: note: in expansion of macro 'ATOMIC64_OP' 38 | #define ATOMIC64_OPS(op) ATOMIC64_OP(op) ATOMIC64_FETCH_OP(op) | ^~~~~~~~~~~ include/asm-generic/atomic64.h:42:1: note: in expansion of macro 'ATOMIC64_OPS' 42 | ATOMIC64_OPS(xor) | ^~~~~~~~~~~~ In file included from include/linux/atomic.h:7, from include/linux/debug_locks.h:6, from include/linux/lockdep.h:28, from include/linux/spinlock_types.h:18, from kernel/bounds.c:14: arch/powerpc/include/asm/atomic.h:315:24: note: previous definition of 'atomic64_xor' was here 315 | static __inline__ void atomic64_##op(s64 a, atomic64_t | ^~~~~~~~~ arch/powerpc/include/asm/atomic.h:381:2: note: in expansion of macro 'ATOMIC64_OP' 381 | ATOMIC64_OP(op, asm_op) | ^~~~~~~~~~~ arch/powerpc/include/asm/atomic.h:386:1: note: in expansion of macro 'ATOMIC64_OPS' 386 | ATOMIC64_OPS(xor, xor) | ^~~~~~~~~~~~ >> arch/powerpc/include/asm/atomic.h:485:34: error: conflicting types for 'atomic64_dec_if_positive' 485 | #define atomic64_dec_if_positive atomic64_dec_if_positive | ^~~~~~~~~~~~~~~~~~~~~~~~ >> include/asm-generic/atomic64.h:49:12: note: in expansion of macro 'atomic64_dec_if_positive' 49 | extern s64 atomic64_dec_if_positive(atomic64_t | ^~~~~~~~~~~~~~~~~~~~~~~~ arch/powerpc/include/asm/atomic.h:466:23: note: previous definition of 'atomic64_dec_if_positive' was here 466 | static __inline__ s64 atomic64_dec_if_positive(atomic64_t | ^~~~~~~~~~~~~~~~~~~~~~~~ In file included from arch/powerpc/include/asm/atomic.h:11, from include/linux/atomic.h:7, from include/linux/debug_locks.h:6, from include/linux/lockdep.h:28, from include/linux/spinlock_types.h:18, from kernel/bounds.c:14: >> arch/powerpc/include/asm/cmpxchg.h:482:4: error: expected identifier or '(' before '{' token 482 | ({ | ^ >> arch/powerpc/include/asm/atomic.h:487:36: note: in expansion of macro 'cmpxchg' 487 | #define atomic64_cmpxchg(v, o, n) (cmpxchg(&((v)->counter), (o), (n))) | ^~~~~~~ >> include/asm-generic/atomic64.h:51:12: note: in expansion of macro 'atomic64_cmpxchg' 51 | extern s64 atomic64_cmpxchg(atomic64_t s64 o, s64 n); | ^~~~~~~~~~~~~~~~ In file included from include/linux/debug_locks.h:6, from include/linux/lockdep.h:28, from include/linux/spinlock_types.h:18, from kernel/bounds.c:14: include/linux/atomic.h:66:2: error: expected identifier or '(' before '{' token 66 | ({ | ^ include/linux/atomic-fallback.h:27:2: note: in expansion of macro '__atomic_op_fence' 27 | __atomic_op_fence(xchg, __VA_ARGS__) | ^~~~~~~~~~~~~~~~~ arch/powerpc/include/asm/atomic.h:493:32: note: in expansion of macro 'xchg' 493 | #define atomic64_xchg(v, new) (xchg(&((v)->counter), new)) | ^~~~ include/asm-generic/atomic64.h:52:12: note: in expansion of macro 'atomic64_xchg' 52 | extern s64 atomic64_xchg(atomic64_t s64 new); | ^~~~~~~~~~~~~ In file included from include/linux/atomic.h:7, from include/linux/debug_locks.h:6, from include/linux/lockdep.h:28, from include/linux/spinlock_types.h:18, from kernel/bounds.c:14: arch/powerpc/include/asm/atomic.h:526:35: error: conflicting types for 'atomic64_fetch_add_unless' 526 | #define atomic64_fetch_add_unless atomic64_fetch_add_unless | ^~~~~~~~~~~~~~~~~~~~~~~~~ include/asm-generic/atomic64.h:53:12: note: in expansion of macro 'atomic64_fetch_add_unless' 53 | extern s64 atomic64_fetch_add_unless(atomic64_t s64 a, s64 u); | ^~~~~~~~~~~~~~~~~~~~~~~~~ arch/powerpc/include/asm/atomic.h:505:23: note: previous definition of 'atomic64_fetch_add_unless' was here 505 | static __inline__ s64 atomic64_fetch_add_unless(atomic64_t s64 a, s64 u) | ^~~~~~~~~~~~~~~~~~~~~~~~~ In file included from include/linux/atomic.h:74, from include/linux/debug_locks.h:6, from include/linux/lockdep.h:28, from include/linux/spinlock_types.h:18, from kernel/bounds.c:14: include/linux/atomic-fallback.h: In function 'atomic64_add_return_acquire': include/linux/atomic-fallback.h:1216:43: error: passing argument 2 of 'atomic64_add_return_relaxed' from incompatible pointer type 1216 | s64 ret = atomic64_add_return_relaxed(i, v); | ^ | | | atomic64_t Makefile arch block certs crypto drivers fs include init ipc kernel lib mm net scripts security sound source usr virt {aka struct <anonymous> In file included from include/linux/atomic.h:7, from include/linux/debug_locks.h:6, from include/linux/lockdep.h:28, from include/linux/spinlock_types.h:18, from kernel/bounds.c:14: arch/powerpc/include/asm/atomic.h:331:51: note: expected 'atomic64_t {aka 'struct <anonymous> but argument is of type 'atomic64_t {aka 'struct <anonymous> 331 | atomic64_##op##_return_relaxed(s64 a, atomic64_t | ~~~~~~~~~~~~^ arch/powerpc/include/asm/atomic.h:367:2: note: in expansion of macro 'ATOMIC64_OP_RETURN_RELAXED' 367 | ATOMIC64_OP_RETURN_RELAXED(op, asm_op) | ^~~~~~~~~~~~~~~~~~~~~~~~~~ arch/powerpc/include/asm/atomic.h:370:1: note: in expansion of macro 'ATOMIC64_OPS' 370 | ATOMIC64_OPS(add, add) | ^~~~~~~~~~~~ In file included from include/linux/atomic.h:74, from include/linux/debug_locks.h:6, from include/linux/lockdep.h:28, from include/linux/spinlock_types.h:18, from kernel/bounds.c:14: include/linux/atomic-fallback.h: In function 'atomic64_add_return_release': include/linux/atomic-fallback.h:1228:40: error: passing argument 2 of 'atomic64_add_return_relaxed' from incompatible pointer type 1228 | return atomic64_add_return_relaxed(i, v); | ^ | | | atomic64_t Makefile arch block certs crypto drivers fs include init ipc kernel lib mm net scripts security sound source usr virt {aka struct <anonymous> In file included from include/linux/atomic.h:7, from include/linux/debug_locks.h:6, from include/linux/lockdep.h:28, from include/linux/spinlock_types.h:18, from kernel/bounds.c:14: arch/powerpc/include/asm/atomic.h:331:51: note: expected 'atomic64_t {aka 'struct <anonymous> but argument is of type 'atomic64_t {aka 'struct <anonymous> 331 | atomic64_##op##_return_relaxed(s64 a, atomic64_t | ~~~~~~~~~~~~^ arch/powerpc/include/asm/atomic.h:367:2: note: in expansion of macro 'ATOMIC64_OP_RETURN_RELAXED' 367 | ATOMIC64_OP_RETURN_RELAXED(op, asm_op) | ^~~~~~~~~~~~~~~~~~~~~~~~~~ arch/powerpc/include/asm/atomic.h:370:1: note: in expansion of macro 'ATOMIC64_OPS' 370 | ATOMIC64_OPS(add, add) | ^~~~~~~~~~~~ In file included from include/linux/atomic.h:74, from include/linux/debug_locks.h:6, from include/linux/lockdep.h:28, from include/linux/spinlock_types.h:18, from kernel/bounds.c:14: include/linux/atomic-fallback.h: At top level: include/linux/atomic-fallback.h:1235:1: error: static declaration of 'atomic64_add_return' follows non-static declaration 1235 | atomic64_add_return(s64 i, atomic64_t | ^~~~~~~~~~~~~~~~~~~ In file included from include/linux/atomic-fallback.h:1185, from include/linux/atomic.h:74, from include/linux/debug_locks.h:6, from include/linux/lockdep.h:28, from include/linux/spinlock_types.h:18, from kernel/bounds.c:14: include/asm-generic/atomic64.h:27:12: note: previous declaration of 'atomic64_add_return' was here 27 | extern s64 atomic64_##op##_return(s64 a, atomic64_t | ^~~~~~~~~ include/asm-generic/atomic64.h:32:42: note: in expansion of macro 'ATOMIC64_OP_RETURN' 32 | #define ATOMIC64_OPS(op) ATOMIC64_OP(op) ATOMIC64_OP_RETURN(op) ATOMIC64_FETCH_OP(op) | ^~~~~~~~~~~~~~~~~~ include/asm-generic/atomic64.h:34:1: note: in expansion of macro 'ATOMIC64_OPS' 34 | ATOMIC64_OPS(add) vim +/atomic64_t +14 include/asm-generic/atomic64.h 09d4e0edd4614e7 Paul Mackerras 2009-06-12 11 09d4e0edd4614e7 Paul Mackerras 2009-06-12 12 typedef struct { 9255813d5841e15 Mark Rutland 2019-05-22 13 s64 counter; 09d4e0edd4614e7 Paul Mackerras 2009-06-12 @14 } atomic64_t; 09d4e0edd4614e7 Paul Mackerras 2009-06-12 15 09d4e0edd4614e7 Paul Mackerras 2009-06-12 16 #define ATOMIC64_INIT(i) { (i) } 09d4e0edd4614e7 Paul Mackerras 2009-06-12 17 9255813d5841e15 Mark Rutland 2019-05-22 @18 extern s64 atomic64_read(const atomic64_t *v); 9255813d5841e15 Mark Rutland 2019-05-22 @19 extern void atomic64_set(atomic64_t *v, s64 i); 560cb12a4080a48 Peter Zijlstra 2014-04-23 20 9d664c0aec3bfdb Peter Zijlstra 2017-06-09 21 #define atomic64_set_release(v, i) atomic64_set((v), (i)) 9d664c0aec3bfdb Peter Zijlstra 2017-06-09 22 560cb12a4080a48 Peter Zijlstra 2014-04-23 23 #define ATOMIC64_OP(op) \ 9255813d5841e15 Mark Rutland 2019-05-22 @24 extern void atomic64_##op(s64 a, atomic64_t *v); 560cb12a4080a48 Peter Zijlstra 2014-04-23 25 560cb12a4080a48 Peter Zijlstra 2014-04-23 26 #define ATOMIC64_OP_RETURN(op) \ 9255813d5841e15 Mark Rutland 2019-05-22 27 extern s64 atomic64_##op##_return(s64 a, atomic64_t *v); 560cb12a4080a48 Peter Zijlstra 2014-04-23 28 28aa2bda2211f43 Peter Zijlstra 2016-04-18 29 #define ATOMIC64_FETCH_OP(op) \ 9255813d5841e15 Mark Rutland 2019-05-22 30 extern s64 atomic64_fetch_##op(s64 a, atomic64_t *v); 28aa2bda2211f43 Peter Zijlstra 2016-04-18 31 28aa2bda2211f43 Peter Zijlstra 2016-04-18 @32 #define ATOMIC64_OPS(op) ATOMIC64_OP(op) ATOMIC64_OP_RETURN(op) ATOMIC64_FETCH_OP(op) 560cb12a4080a48 Peter Zijlstra 2014-04-23 33 560cb12a4080a48 Peter Zijlstra 2014-04-23 @34 ATOMIC64_OPS(add) 560cb12a4080a48 Peter Zijlstra 2014-04-23 35 ATOMIC64_OPS(sub) 560cb12a4080a48 Peter Zijlstra 2014-04-23 36 28aa2bda2211f43 Peter Zijlstra 2016-04-18 37 #undef ATOMIC64_OPS 28aa2bda2211f43 Peter Zijlstra 2016-04-18 38 #define ATOMIC64_OPS(op) ATOMIC64_OP(op) ATOMIC64_FETCH_OP(op) 28aa2bda2211f43 Peter Zijlstra 2016-04-18 39 28aa2bda2211f43 Peter Zijlstra 2016-04-18 40 ATOMIC64_OPS(and) 28aa2bda2211f43 Peter Zijlstra 2016-04-18 41 ATOMIC64_OPS(or) 28aa2bda2211f43 Peter Zijlstra 2016-04-18 42 ATOMIC64_OPS(xor) e6942b7de2dfe44 Peter Zijlstra 2014-04-23 43 560cb12a4080a48 Peter Zijlstra 2014-04-23 44 #undef ATOMIC64_OPS 28aa2bda2211f43 Peter Zijlstra 2016-04-18 45 #undef ATOMIC64_FETCH_OP 560cb12a4080a48 Peter Zijlstra 2014-04-23 46 #undef ATOMIC64_OP_RETURN 560cb12a4080a48 Peter Zijlstra 2014-04-23 47 #undef ATOMIC64_OP 560cb12a4080a48 Peter Zijlstra 2014-04-23 48 9255813d5841e15 Mark Rutland 2019-05-22 @49 extern s64 atomic64_dec_if_positive(atomic64_t *v); b3a2a05f9111de0 Mark Rutland 2018-06-21 50 #define atomic64_dec_if_positive atomic64_dec_if_positive 9255813d5841e15 Mark Rutland 2019-05-22 @51 extern s64 atomic64_cmpxchg(atomic64_t *v, s64 o, s64 n); 9255813d5841e15 Mark Rutland 2019-05-22 @52 extern s64 atomic64_xchg(atomic64_t *v, s64 new); 9255813d5841e15 Mark Rutland 2019-05-22 @53 extern s64 atomic64_fetch_add_unless(atomic64_t *v, s64 a, s64 u); 00b808ab79ead37 Mark Rutland 2018-06-21 54 #define atomic64_fetch_add_unless atomic64_fetch_add_unless 09d4e0edd4614e7 Paul Mackerras 2009-06-12 55 :::::: The code at line 14 was first introduced by commit :::::: 09d4e0edd4614e787393acc582ac701c6ec3565b lib: Provide generic atomic64_t implementation :::::: TO: Paul Mackerras <paulus@samba.org> :::::: CC: Benjamin Herrenschmidt <benh@kernel.crashing.org> --- 0-DAY CI Kernel Test Service, Intel Corporation https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org [-- Attachment #2: .config.gz --] [-- Type: application/gzip, Size: 68870 bytes --] ^ permalink raw reply [flat|nested] 46+ messages in thread
* [PATCH 2/5] powerpc: sysdev: fix compile error for fsl_85xx_cache_sram 2020-04-15 12:33 [PATCH 0/5] drivers: uio: new driver uio_fsl_85xx_cache_sram Wang Wenhu 2020-04-15 12:33 ` [PATCH 1/5] powerpc: 85xx: make FSL_85XX_CACHE_SRAM configurable Wang Wenhu @ 2020-04-15 12:33 ` Wang Wenhu 2020-04-15 12:33 ` [PATCH 3/5] powerpc: sysdev: fix compile warning " Wang Wenhu ` (2 subsequent siblings) 4 siblings, 0 replies; 46+ messages in thread From: Wang Wenhu @ 2020-04-15 12:33 UTC (permalink / raw) To: gregkh, linux-kernel, oss, christophe.leroy, linuxppc-dev Cc: kernel, Wang Wenhu, Michael Ellerman Include linux/io.h into fsl_85xx_cache_sram.c to fix the implicit-declaration compile error when building Cache-Sram. arch/powerpc/sysdev/fsl_85xx_cache_sram.c: In function ‘instantiate_cache_sram’: arch/powerpc/sysdev/fsl_85xx_cache_sram.c:97:26: error: implicit declaration of function ‘ioremap_coherent’; did you mean ‘bitmap_complement’? [-Werror=implicit-function-declaration] cache_sram->base_virt = ioremap_coherent(cache_sram->base_phys, ^~~~~~~~~~~~~~~~ bitmap_complement arch/powerpc/sysdev/fsl_85xx_cache_sram.c:97:24: error: assignment makes pointer from integer without a cast [-Werror=int-conversion] cache_sram->base_virt = ioremap_coherent(cache_sram->base_phys, ^ arch/powerpc/sysdev/fsl_85xx_cache_sram.c:123:2: error: implicit declaration of function ‘iounmap’; did you mean ‘roundup’? [-Werror=implicit-function-declaration] iounmap(cache_sram->base_virt); ^~~~~~~ roundup cc1: all warnings being treated as errors Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Christophe Leroy <christophe.leroy@c-s.fr> Cc: Scott Wood <oss@buserror.net> Cc: Michael Ellerman <mpe@ellerman.id.au> Cc: linuxppc-dev@lists.ozlabs.org Fixes: 6db92cc9d07d ("powerpc/85xx: add cache-sram support") Signed-off-by: Wang Wenhu <wenhu.wang@vivo.com> --- arch/powerpc/sysdev/fsl_85xx_cache_sram.c | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/powerpc/sysdev/fsl_85xx_cache_sram.c b/arch/powerpc/sysdev/fsl_85xx_cache_sram.c index f6c665dac725..be3aef4229d7 100644 --- a/arch/powerpc/sysdev/fsl_85xx_cache_sram.c +++ b/arch/powerpc/sysdev/fsl_85xx_cache_sram.c @@ -17,6 +17,7 @@ #include <linux/of_platform.h> #include <asm/pgtable.h> #include <asm/fsl_85xx_cache_sram.h> +#include <linux/io.h> #include "fsl_85xx_cache_ctlr.h" -- 2.17.1 ^ permalink raw reply related [flat|nested] 46+ messages in thread
* [PATCH 3/5] powerpc: sysdev: fix compile warning for fsl_85xx_cache_sram 2020-04-15 12:33 [PATCH 0/5] drivers: uio: new driver uio_fsl_85xx_cache_sram Wang Wenhu 2020-04-15 12:33 ` [PATCH 1/5] powerpc: 85xx: make FSL_85XX_CACHE_SRAM configurable Wang Wenhu 2020-04-15 12:33 ` [PATCH 2/5] powerpc: sysdev: fix compile error for fsl_85xx_cache_sram Wang Wenhu @ 2020-04-15 12:33 ` Wang Wenhu 2020-04-15 12:33 ` [PATCH 4/5] powerpc: sysdev: fix compile error for fsl_85xx_l2ctlr Wang Wenhu 2020-04-15 12:33 ` [PATCH 5/5] drivers: uio: new driver for fsl_85xx_cache_sram Wang Wenhu 4 siblings, 0 replies; 46+ messages in thread From: Wang Wenhu @ 2020-04-15 12:33 UTC (permalink / raw) To: gregkh, linux-kernel, oss, christophe.leroy, linuxppc-dev Cc: kernel, Wang Wenhu, Michael Ellerman Function instantiate_cache_sram should not be linked into the init section for its caller mpc85xx_l2ctlr_of_probe is none-__init. Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Christophe Leroy <christophe.leroy@c-s.fr> Cc: Scott Wood <oss@buserror.net> Cc: Michael Ellerman <mpe@ellerman.id.au> Cc: linuxppc-dev@lists.ozlabs.org Fixes: 6db92cc9d07d ("powerpc/85xx: add cache-sram support") Signed-off-by: Wang Wenhu <wenhu.wang@vivo.com> Warning information: MODPOST vmlinux.o WARNING: modpost: vmlinux.o(.text+0x1e540): Section mismatch in reference from the function mpc85xx_l2ctlr_of_probe() to the function .init.text:instantiate_cache_sram() The function mpc85xx_l2ctlr_of_probe() references the function __init instantiate_cache_sram(). This is often because mpc85xx_l2ctlr_of_probe lacks a __init annotation or the annotation of instantiate_cache_sram is wrong. --- arch/powerpc/sysdev/fsl_85xx_cache_sram.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/powerpc/sysdev/fsl_85xx_cache_sram.c b/arch/powerpc/sysdev/fsl_85xx_cache_sram.c index be3aef4229d7..3de5ac8382c0 100644 --- a/arch/powerpc/sysdev/fsl_85xx_cache_sram.c +++ b/arch/powerpc/sysdev/fsl_85xx_cache_sram.c @@ -68,7 +68,7 @@ void mpc85xx_cache_sram_free(void *ptr) } EXPORT_SYMBOL(mpc85xx_cache_sram_free); -int __init instantiate_cache_sram(struct platform_device *dev, +int instantiate_cache_sram(struct platform_device *dev, struct sram_parameters sram_params) { int ret = 0; -- 2.17.1 ^ permalink raw reply related [flat|nested] 46+ messages in thread
* [PATCH 4/5] powerpc: sysdev: fix compile error for fsl_85xx_l2ctlr 2020-04-15 12:33 [PATCH 0/5] drivers: uio: new driver uio_fsl_85xx_cache_sram Wang Wenhu ` (2 preceding siblings ...) 2020-04-15 12:33 ` [PATCH 3/5] powerpc: sysdev: fix compile warning " Wang Wenhu @ 2020-04-15 12:33 ` Wang Wenhu 2020-04-15 12:33 ` [PATCH 5/5] drivers: uio: new driver for fsl_85xx_cache_sram Wang Wenhu 4 siblings, 0 replies; 46+ messages in thread From: Wang Wenhu @ 2020-04-15 12:33 UTC (permalink / raw) To: gregkh, linux-kernel, oss, christophe.leroy, linuxppc-dev Cc: kernel, Wang Wenhu, Michael Ellerman Include "linux/of_address.h" to fix the compile error for mpc85xx_l2ctlr_of_probe() when compiling fsl_85xx_cache_sram.c. CC arch/powerpc/sysdev/fsl_85xx_l2ctlr.o arch/powerpc/sysdev/fsl_85xx_l2ctlr.c: In function ‘mpc85xx_l2ctlr_of_probe’: arch/powerpc/sysdev/fsl_85xx_l2ctlr.c:90:11: error: implicit declaration of function ‘of_iomap’; did you mean ‘pci_iomap’? [-Werror=implicit-function-declaration] l2ctlr = of_iomap(dev->dev.of_node, 0); ^~~~~~~~ pci_iomap arch/powerpc/sysdev/fsl_85xx_l2ctlr.c:90:9: error: assignment makes pointer from integer without a cast [-Werror=int-conversion] l2ctlr = of_iomap(dev->dev.of_node, 0); ^ cc1: all warnings being treated as errors scripts/Makefile.build:267: recipe for target 'arch/powerpc/sysdev/fsl_85xx_l2ctlr.o' failed make[2]: *** [arch/powerpc/sysdev/fsl_85xx_l2ctlr.o] Error 1 Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Christophe Leroy <christophe.leroy@c-s.fr> Cc: Scott Wood <oss@buserror.net> Cc: Michael Ellerman <mpe@ellerman.id.au> Cc: linuxppc-dev@lists.ozlabs.org Fixes: 6db92cc9d07d ("powerpc/85xx: add cache-sram support") Signed-off-by: Wang Wenhu <wenhu.wang@vivo.com> --- arch/powerpc/sysdev/fsl_85xx_l2ctlr.c | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/powerpc/sysdev/fsl_85xx_l2ctlr.c b/arch/powerpc/sysdev/fsl_85xx_l2ctlr.c index 2d0af0c517bb..7533572492f0 100644 --- a/arch/powerpc/sysdev/fsl_85xx_l2ctlr.c +++ b/arch/powerpc/sysdev/fsl_85xx_l2ctlr.c @@ -10,6 +10,7 @@ #include <linux/kernel.h> #include <linux/module.h> #include <linux/of_platform.h> +#include <linux/of_address.h> #include <asm/io.h> #include "fsl_85xx_cache_ctlr.h" -- 2.17.1 ^ permalink raw reply related [flat|nested] 46+ messages in thread
* [PATCH 5/5] drivers: uio: new driver for fsl_85xx_cache_sram 2020-04-15 12:33 [PATCH 0/5] drivers: uio: new driver uio_fsl_85xx_cache_sram Wang Wenhu ` (3 preceding siblings ...) 2020-04-15 12:33 ` [PATCH 4/5] powerpc: sysdev: fix compile error for fsl_85xx_l2ctlr Wang Wenhu @ 2020-04-15 12:33 ` Wang Wenhu 2020-04-15 12:49 ` Greg KH 4 siblings, 1 reply; 46+ messages in thread From: Wang Wenhu @ 2020-04-15 12:33 UTC (permalink / raw) To: gregkh, linux-kernel, oss, christophe.leroy, linuxppc-dev Cc: kernel, Wang Wenhu, Michael Ellerman A driver for freescale 85xx platforms to access the Cache-Sram form user level. This is extremely helpful for some user-space applications that require high performance memory accesses. Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Christophe Leroy <christophe.leroy@c-s.fr> Cc: Scott Wood <oss@buserror.net> Cc: Michael Ellerman <mpe@ellerman.id.au> Cc: linuxppc-dev@lists.ozlabs.org Signed-off-by: Wang Wenhu <wenhu.wang@vivo.com> --- drivers/uio/Kconfig | 8 ++ drivers/uio/Makefile | 1 + drivers/uio/uio_fsl_85xx_cache_sram.c | 195 ++++++++++++++++++++++++++ 3 files changed, 204 insertions(+) create mode 100644 drivers/uio/uio_fsl_85xx_cache_sram.c diff --git a/drivers/uio/Kconfig b/drivers/uio/Kconfig index 202ee81cfc2b..afd38ec13de0 100644 --- a/drivers/uio/Kconfig +++ b/drivers/uio/Kconfig @@ -105,6 +105,14 @@ config UIO_NETX To compile this driver as a module, choose M here; the module will be called uio_netx. +config UIO_FSL_85XX_CACHE_SRAM + tristate "Freescale 85xx Cache-Sram driver" + depends on FSL_85XX_CACHE_SRAM + help + Generic driver for accessing the Cache-Sram form user level. This + is extremely helpful for some user-space applications that require + high performance memory accesses. + config UIO_FSL_ELBC_GPCM tristate "eLBC/GPCM driver" depends on FSL_LBC diff --git a/drivers/uio/Makefile b/drivers/uio/Makefile index c285dd2a4539..be2056cffc21 100644 --- a/drivers/uio/Makefile +++ b/drivers/uio/Makefile @@ -10,4 +10,5 @@ obj-$(CONFIG_UIO_NETX) += uio_netx.o obj-$(CONFIG_UIO_PRUSS) += uio_pruss.o obj-$(CONFIG_UIO_MF624) += uio_mf624.o obj-$(CONFIG_UIO_FSL_ELBC_GPCM) += uio_fsl_elbc_gpcm.o +obj-$(CONFIG_UIO_FSL_85XX_CACHE_SRAM) += uio_fsl_85xx_cache_sram.o obj-$(CONFIG_UIO_HV_GENERIC) += uio_hv_generic.o diff --git a/drivers/uio/uio_fsl_85xx_cache_sram.c b/drivers/uio/uio_fsl_85xx_cache_sram.c new file mode 100644 index 000000000000..e11202dd5b93 --- /dev/null +++ b/drivers/uio/uio_fsl_85xx_cache_sram.c @@ -0,0 +1,195 @@ +// SPDX-License-Identifier: GPL-2.0 +/* + * Copyright (C) 2020 Vivo Communication Technology Co. Ltd. + * Copyright (C) 2020 Wang Wenhu <wenhu.wang@vivo.com> + * All rights reserved. + * + * This program is free software; you can redistribute it and/or modify it + * under the terms of the GNU General Public License version 2 as published + * by the Free Software Foundation. + */ + +#include <linux/platform_device.h> +#include <linux/uio_driver.h> +#include <linux/stringify.h> +#include <linux/module.h> +#include <linux/kernel.h> +#include <asm/fsl_85xx_cache_sram.h> + +#define DRIVER_VERSION "0.1.0" +#define DRIVER_NAME "uio_fsl_85xx_cache_sram" +#define UIO_NAME "uio_cache_sram" + +static const struct of_device_id uio_mpc85xx_l2ctlr_of_match[] = { + { .compatible = "uio,fsl,p2020-l2-cache-controller", }, + { .compatible = "uio,fsl,p2010-l2-cache-controller", }, + { .compatible = "uio,fsl,p1020-l2-cache-controller", }, + { .compatible = "uio,fsl,p1011-l2-cache-controller", }, + { .compatible = "uio,fsl,p1013-l2-cache-controller", }, + { .compatible = "uio,fsl,p1022-l2-cache-controller", }, + { .compatible = "uio,fsl,mpc8548-l2-cache-controller", }, + { .compatible = "uio,fsl,mpc8544-l2-cache-controller", }, + { .compatible = "uio,fsl,mpc8572-l2-cache-controller", }, + { .compatible = "uio,fsl,mpc8536-l2-cache-controller", }, + { .compatible = "uio,fsl,p1021-l2-cache-controller", }, + { .compatible = "uio,fsl,p1012-l2-cache-controller", }, + { .compatible = "uio,fsl,p1025-l2-cache-controller", }, + { .compatible = "uio,fsl,p1016-l2-cache-controller", }, + { .compatible = "uio,fsl,p1024-l2-cache-controller", }, + { .compatible = "uio,fsl,p1015-l2-cache-controller", }, + { .compatible = "uio,fsl,p1010-l2-cache-controller", }, + { .compatible = "uio,fsl,bsc9131-l2-cache-controller", }, + {}, +}; + +static void uio_info_free_internal(struct uio_info *info) +{ + struct uio_mem *uiomem = &info->mem[0]; + + while (uiomem < &info->mem[MAX_UIO_MAPS]) { + if (uiomem->size) { + mpc85xx_cache_sram_free(uiomem->internal_addr); + kfree(uiomem->name); + } + uiomem++; + } +} + +static int uio_fsl_85xx_cache_sram_probe(struct platform_device *pdev) +{ + struct device_node *parent = pdev->dev.of_node; + struct device_node *node = NULL; + struct uio_info *info; + struct uio_mem *uiomem; + const char *dt_name; + u32 mem_size; + u32 align; + void *virt; + phys_addr_t phys; + int ret = -ENODEV; + + /* alloc uio_info for one device */ + info = kzalloc(sizeof(*info), GFP_KERNEL); + if (!info) { + dev_err(&pdev->dev, "kzalloc uio_info failed\n"); + ret = -ENOMEM; + goto err_out; + } + + /* get optional uio name */ + if (of_property_read_string(parent, "uio_name", &dt_name)) + dt_name = UIO_NAME; + + info->name = kstrdup(dt_name, GFP_KERNEL); + if (!info->name) { + dev_err(&pdev->dev, "error kstrdup uio_name\n"); + ret = -ENOMEM; + goto err_info_free; + } + + uiomem = &info->mem[0]; + for_each_child_of_node(parent, node) { + if (!node) { + dev_err(&pdev->dev, "device's OF-node is NULL\n"); + continue; + } + + ret = of_property_read_u32(node, "cache-mem-size", &mem_size); + if (ret) { + dev_err(&pdev->dev, "missing cache-mem-size value\n"); + continue; + } + + if (mem_size == 0) { + dev_err(&pdev->dev, "cache-mem-size should not be 0\n"); + continue; + } + + align = 2; + while (align < mem_size) + align *= 2; + virt = mpc85xx_cache_sram_alloc(mem_size, &phys, align); + if (!virt) { + dev_err(&pdev->dev, "allocate 0x%x cache-mem failed\n", mem_size); + continue; + } + + uiomem->memtype = UIO_MEM_PHYS; + uiomem->addr = phys; + uiomem->size = mem_size; + uiomem->name = kstrdup(node->name, GFP_KERNEL);; + uiomem->internal_addr = virt; + ++uiomem; + + if (uiomem >= &info->mem[MAX_UIO_MAPS]) { + dev_warn(&pdev->dev, "device has more than " + __stringify(MAX_UIO_MAPS) + " I/O memory resources.\n"); + break; + } + } + + while (uiomem < &info->mem[MAX_UIO_MAPS]) { + uiomem->size = 0; + ++uiomem; + } + + if (info->mem[0].size == 0) { + dev_err(&pdev->dev, "error no valid uio-map configured\n"); + ret = -EINVAL; + goto err_name_free; + } + + info->version = DRIVER_VERSION; + + /* register UIO device */ + if (uio_register_device(&pdev->dev, info)) { + dev_err(&pdev->dev, "UIO registration failed\n"); + ret = -ENODEV; + goto err_unregister; + } + + platform_set_drvdata(pdev, info); + + return 0; +err_unregister: + uio_info_free_internal(info); +err_name_free: + kfree(info->name); +err_info_free: + kfree(info); +err_out: + return ret; +} + +static int uio_fsl_85xx_cache_sram_remove(struct platform_device *pdev) +{ + struct uio_info *info = platform_get_drvdata(pdev); + + uio_unregister_device(info); + + uio_info_free_internal(info); + + kfree(info->name); + + kfree(info); + + return 0; +} + +static struct platform_driver uio_fsl_85xx_cache_sram = { + .probe = uio_fsl_85xx_cache_sram_probe, + .remove = uio_fsl_85xx_cache_sram_remove, + .driver = { + .name = DRIVER_NAME, + .owner = THIS_MODULE, + .of_match_table = uio_mpc85xx_l2ctlr_of_match, + }, +}; + +module_platform_driver(uio_fsl_85xx_cache_sram); + +MODULE_AUTHOR("Wang Wenhu <wenhu.wang@vivo.com>"); +MODULE_DESCRIPTION("Freescale MPC85xx Cache-Sram UIO Platform Driver"); +MODULE_ALIAS("platform:" DRIVER_NAME); +MODULE_LICENSE("GPL v2"); -- 2.17.1 ^ permalink raw reply related [flat|nested] 46+ messages in thread
* Re: [PATCH 5/5] drivers: uio: new driver for fsl_85xx_cache_sram 2020-04-15 12:33 ` [PATCH 5/5] drivers: uio: new driver for fsl_85xx_cache_sram Wang Wenhu @ 2020-04-15 12:49 ` Greg KH 2020-04-15 14:07 ` [PATCH 5/5] drivers: uio: new driver for fsl_85xx_cache_sram>On Wed, Apr 15, 2020 at 05:33:46AM -0700, Wang Wenhu wrote: Wang Wenhu 2020-04-15 15:24 ` [PATCH v2,0/5] drivers: uio: new driver uio_fsl_85xx_cache_sram Wang Wenhu 0 siblings, 2 replies; 46+ messages in thread From: Greg KH @ 2020-04-15 12:49 UTC (permalink / raw) To: Wang Wenhu Cc: linux-kernel, oss, christophe.leroy, linuxppc-dev, kernel, Michael Ellerman On Wed, Apr 15, 2020 at 05:33:46AM -0700, Wang Wenhu wrote: > A driver for freescale 85xx platforms to access the Cache-Sram form > user level. This is extremely helpful for some user-space applications > that require high performance memory accesses. > > Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> > Cc: Christophe Leroy <christophe.leroy@c-s.fr> > Cc: Scott Wood <oss@buserror.net> > Cc: Michael Ellerman <mpe@ellerman.id.au> > Cc: linuxppc-dev@lists.ozlabs.org > Signed-off-by: Wang Wenhu <wenhu.wang@vivo.com> > --- > drivers/uio/Kconfig | 8 ++ > drivers/uio/Makefile | 1 + > drivers/uio/uio_fsl_85xx_cache_sram.c | 195 ++++++++++++++++++++++++++ > 3 files changed, 204 insertions(+) > create mode 100644 drivers/uio/uio_fsl_85xx_cache_sram.c > > diff --git a/drivers/uio/Kconfig b/drivers/uio/Kconfig > index 202ee81cfc2b..afd38ec13de0 100644 > --- a/drivers/uio/Kconfig > +++ b/drivers/uio/Kconfig > @@ -105,6 +105,14 @@ config UIO_NETX > To compile this driver as a module, choose M here; the module > will be called uio_netx. > > +config UIO_FSL_85XX_CACHE_SRAM > + tristate "Freescale 85xx Cache-Sram driver" > + depends on FSL_85XX_CACHE_SRAM > + help > + Generic driver for accessing the Cache-Sram form user level. This > + is extremely helpful for some user-space applications that require > + high performance memory accesses. > + > config UIO_FSL_ELBC_GPCM > tristate "eLBC/GPCM driver" > depends on FSL_LBC > diff --git a/drivers/uio/Makefile b/drivers/uio/Makefile > index c285dd2a4539..be2056cffc21 100644 > --- a/drivers/uio/Makefile > +++ b/drivers/uio/Makefile > @@ -10,4 +10,5 @@ obj-$(CONFIG_UIO_NETX) += uio_netx.o > obj-$(CONFIG_UIO_PRUSS) += uio_pruss.o > obj-$(CONFIG_UIO_MF624) += uio_mf624.o > obj-$(CONFIG_UIO_FSL_ELBC_GPCM) += uio_fsl_elbc_gpcm.o > +obj-$(CONFIG_UIO_FSL_85XX_CACHE_SRAM) += uio_fsl_85xx_cache_sram.o > obj-$(CONFIG_UIO_HV_GENERIC) += uio_hv_generic.o > diff --git a/drivers/uio/uio_fsl_85xx_cache_sram.c b/drivers/uio/uio_fsl_85xx_cache_sram.c > new file mode 100644 > index 000000000000..e11202dd5b93 > --- /dev/null > +++ b/drivers/uio/uio_fsl_85xx_cache_sram.c > @@ -0,0 +1,195 @@ > +// SPDX-License-Identifier: GPL-2.0 > +/* > + * Copyright (C) 2020 Vivo Communication Technology Co. Ltd. > + * Copyright (C) 2020 Wang Wenhu <wenhu.wang@vivo.com> > + * All rights reserved. > + * > + * This program is free software; you can redistribute it and/or modify it > + * under the terms of the GNU General Public License version 2 as published > + * by the Free Software Foundation. Nit, you don't need this sentance anymore now that you have the SPDX line above > + */ > + > +#include <linux/platform_device.h> > +#include <linux/uio_driver.h> > +#include <linux/stringify.h> > +#include <linux/module.h> > +#include <linux/kernel.h> > +#include <asm/fsl_85xx_cache_sram.h> > + > +#define DRIVER_VERSION "0.1.0" Don't do DRIVER_VERSIONs, they never work once the code is in the kernel tree. > +#define DRIVER_NAME "uio_fsl_85xx_cache_sram" KBUILD_MODNAME? > +#define UIO_NAME "uio_cache_sram" > + > +static const struct of_device_id uio_mpc85xx_l2ctlr_of_match[] = { > + { .compatible = "uio,fsl,p2020-l2-cache-controller", }, > + { .compatible = "uio,fsl,p2010-l2-cache-controller", }, > + { .compatible = "uio,fsl,p1020-l2-cache-controller", }, > + { .compatible = "uio,fsl,p1011-l2-cache-controller", }, > + { .compatible = "uio,fsl,p1013-l2-cache-controller", }, > + { .compatible = "uio,fsl,p1022-l2-cache-controller", }, > + { .compatible = "uio,fsl,mpc8548-l2-cache-controller", }, > + { .compatible = "uio,fsl,mpc8544-l2-cache-controller", }, > + { .compatible = "uio,fsl,mpc8572-l2-cache-controller", }, > + { .compatible = "uio,fsl,mpc8536-l2-cache-controller", }, > + { .compatible = "uio,fsl,p1021-l2-cache-controller", }, > + { .compatible = "uio,fsl,p1012-l2-cache-controller", }, > + { .compatible = "uio,fsl,p1025-l2-cache-controller", }, > + { .compatible = "uio,fsl,p1016-l2-cache-controller", }, > + { .compatible = "uio,fsl,p1024-l2-cache-controller", }, > + { .compatible = "uio,fsl,p1015-l2-cache-controller", }, > + { .compatible = "uio,fsl,p1010-l2-cache-controller", }, > + { .compatible = "uio,fsl,bsc9131-l2-cache-controller", }, > + {}, > +}; > + > +static void uio_info_free_internal(struct uio_info *info) > +{ > + struct uio_mem *uiomem = &info->mem[0]; > + > + while (uiomem < &info->mem[MAX_UIO_MAPS]) { > + if (uiomem->size) { > + mpc85xx_cache_sram_free(uiomem->internal_addr); > + kfree(uiomem->name); > + } > + uiomem++; > + } > +} > + > +static int uio_fsl_85xx_cache_sram_probe(struct platform_device *pdev) > +{ > + struct device_node *parent = pdev->dev.of_node; > + struct device_node *node = NULL; > + struct uio_info *info; > + struct uio_mem *uiomem; > + const char *dt_name; > + u32 mem_size; > + u32 align; > + void *virt; > + phys_addr_t phys; > + int ret = -ENODEV; > + > + /* alloc uio_info for one device */ > + info = kzalloc(sizeof(*info), GFP_KERNEL); > + if (!info) { > + dev_err(&pdev->dev, "kzalloc uio_info failed\n"); kzalloc already says this. > + ret = -ENOMEM; > + goto err_out; > + } > + > + /* get optional uio name */ > + if (of_property_read_string(parent, "uio_name", &dt_name)) > + dt_name = UIO_NAME; > + > + info->name = kstrdup(dt_name, GFP_KERNEL); > + if (!info->name) { > + dev_err(&pdev->dev, "error kstrdup uio_name\n"); kstrdup should have given you an error string already, right? > + ret = -ENOMEM; > + goto err_info_free; > + } > + > + uiomem = &info->mem[0]; > + for_each_child_of_node(parent, node) { > + if (!node) { > + dev_err(&pdev->dev, "device's OF-node is NULL\n"); How can this happen? > + continue; Why not error out? > + } > + > + ret = of_property_read_u32(node, "cache-mem-size", &mem_size); > + if (ret) { > + dev_err(&pdev->dev, "missing cache-mem-size value\n"); You don't exit? > + continue; > + } > + > + if (mem_size == 0) { > + dev_err(&pdev->dev, "cache-mem-size should not be 0\n"); Again, you don't exit? > + continue; > + } > + > + align = 2; > + while (align < mem_size) > + align *= 2; > + virt = mpc85xx_cache_sram_alloc(mem_size, &phys, align); > + if (!virt) { > + dev_err(&pdev->dev, "allocate 0x%x cache-mem failed\n", mem_size); You don't exit? > + continue; > + } > + > + uiomem->memtype = UIO_MEM_PHYS; > + uiomem->addr = phys; > + uiomem->size = mem_size; > + uiomem->name = kstrdup(node->name, GFP_KERNEL);; > + uiomem->internal_addr = virt; > + ++uiomem; > + > + if (uiomem >= &info->mem[MAX_UIO_MAPS]) { > + dev_warn(&pdev->dev, "device has more than " > + __stringify(MAX_UIO_MAPS) > + " I/O memory resources.\n"); What can someone do with that? thanks, greg k-h ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [PATCH 5/5] drivers: uio: new driver for fsl_85xx_cache_sram>On Wed, Apr 15, 2020 at 05:33:46AM -0700, Wang Wenhu wrote: 2020-04-15 12:49 ` Greg KH @ 2020-04-15 14:07 ` Wang Wenhu 2020-04-15 15:24 ` [PATCH v2,0/5] drivers: uio: new driver uio_fsl_85xx_cache_sram Wang Wenhu 1 sibling, 0 replies; 46+ messages in thread From: Wang Wenhu @ 2020-04-15 14:07 UTC (permalink / raw) To: gregkh Cc: christophe.leroy, kernel, linux-kernel, linuxppc-dev, mpe, oss, wenhu.wang Hi, Greg k-h! Thank you for you fast reply. All the comments will be addressed with v2 soon. Detailed explanations are just below specific comment. >> A driver for freescale 85xx platforms to access the Cache-Sram form >> user level. This is extremely helpful for some user-space applications >> that require high performance memory accesses. >> >> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> >> Cc: Christophe Leroy <christophe.leroy@c-s.fr> >> Cc: Scott Wood <oss@buserror.net> >> Cc: Michael Ellerman <mpe@ellerman.id.au> >> Cc: linuxppc-dev@lists.ozlabs.org >> Signed-off-by: Wang Wenhu <wenhu.wang@vivo.com> >> --- >> drivers/uio/Kconfig | 8 ++ >> drivers/uio/Makefile | 1 + >> drivers/uio/uio_fsl_85xx_cache_sram.c | 195 ++++++++++++++++++++++++++ >> 3 files changed, 204 insertions(+) >> create mode 100644 drivers/uio/uio_fsl_85xx_cache_sram.c >> >> diff --git a/drivers/uio/Kconfig b/drivers/uio/Kconfig >> index 202ee81cfc2b..afd38ec13de0 100644 >> --- a/drivers/uio/Kconfig >> +++ b/drivers/uio/Kconfig >> @@ -105,6 +105,14 @@ config UIO_NETX >> To compile this driver as a module, choose M here; the module >> will be called uio_netx. >> >> +config UIO_FSL_85XX_CACHE_SRAM >> + tristate "Freescale 85xx Cache-Sram driver" >> + depends on FSL_85XX_CACHE_SRAM >> + help >> + Generic driver for accessing the Cache-Sram form user level. This >> + is extremely helpful for some user-space applications that require >> + high performance memory accesses. >> + >> config UIO_FSL_ELBC_GPCM >> tristate "eLBC/GPCM driver" >> depends on FSL_LBC >> diff --git a/drivers/uio/Makefile b/drivers/uio/Makefile >> index c285dd2a4539..be2056cffc21 100644 >> --- a/drivers/uio/Makefile >> +++ b/drivers/uio/Makefile >> @@ -10,4 +10,5 @@ obj-$(CONFIG_UIO_NETX) += uio_netx.o >> obj-$(CONFIG_UIO_PRUSS) += uio_pruss.o >> obj-$(CONFIG_UIO_MF624) += uio_mf624.o >> obj-$(CONFIG_UIO_FSL_ELBC_GPCM) += uio_fsl_elbc_gpcm.o >> +obj-$(CONFIG_UIO_FSL_85XX_CACHE_SRAM) += uio_fsl_85xx_cache_sram.o >> obj-$(CONFIG_UIO_HV_GENERIC) += uio_hv_generic.o >> diff --git a/drivers/uio/uio_fsl_85xx_cache_sram.c b/drivers/uio/uio_fsl_85xx_cache_sram.c >> new file mode 100644 >> index 000000000000..e11202dd5b93 >> --- /dev/null >> +++ b/drivers/uio/uio_fsl_85xx_cache_sram.c >> @@ -0,0 +1,195 @@ >> +// SPDX-License-Identifier: GPL-2.0 >> +/* >> + * Copyright (C) 2020 Vivo Communication Technology Co. Ltd. >> + * Copyright (C) 2020 Wang Wenhu <wenhu.wang@vivo.com> >> + * All rights reserved. >> + * >> + * This program is free software; you can redistribute it and/or modify it >> + * under the terms of the GNU General Public License version 2 as published >> + * by the Free Software Foundation. > >Nit, you don't need this sentance anymore now that you have the SPDX >line above > Got, I will delete it with v2. >> + */ >> + >> +#include <linux/platform_device.h> >> +#include <linux/uio_driver.h> >> +#include <linux/stringify.h> >> +#include <linux/module.h> >> +#include <linux/kernel.h> >> +#include <asm/fsl_85xx_cache_sram.h> >> + >> +#define DRIVER_VERSION "0.1.0" > >Don't do DRIVER_VERSIONs, they never work once the code is in the kernel >tree. > >> +#define DRIVER_NAME "uio_fsl_85xx_cache_sram" > >KBUILD_MODNAME? Yes, and sorry for that I did not get what should have been done? > >> +#define UIO_NAME "uio_cache_sram" >> + >> +static const struct of_device_id uio_mpc85xx_l2ctlr_of_match[] = { >> + { .compatible = "uio,fsl,p2020-l2-cache-controller", }, >> + { .compatible = "uio,fsl,p2010-l2-cache-controller", }, >> + { .compatible = "uio,fsl,p1020-l2-cache-controller", }, >> + { .compatible = "uio,fsl,p1011-l2-cache-controller", }, >> + { .compatible = "uio,fsl,p1013-l2-cache-controller", }, >> + { .compatible = "uio,fsl,p1022-l2-cache-controller", }, >> + { .compatible = "uio,fsl,mpc8548-l2-cache-controller", }, >> + { .compatible = "uio,fsl,mpc8544-l2-cache-controller", }, >> + { .compatible = "uio,fsl,mpc8572-l2-cache-controller", }, >> + { .compatible = "uio,fsl,mpc8536-l2-cache-controller", }, >> + { .compatible = "uio,fsl,p1021-l2-cache-controller", }, >> + { .compatible = "uio,fsl,p1012-l2-cache-controller", }, >> + { .compatible = "uio,fsl,p1025-l2-cache-controller", }, >> + { .compatible = "uio,fsl,p1016-l2-cache-controller", }, >> + { .compatible = "uio,fsl,p1024-l2-cache-controller", }, >> + { .compatible = "uio,fsl,p1015-l2-cache-controller", }, >> + { .compatible = "uio,fsl,p1010-l2-cache-controller", }, >> + { .compatible = "uio,fsl,bsc9131-l2-cache-controller", }, >> + {}, >> +}; >> + >> +static void uio_info_free_internal(struct uio_info *info) >> +{ >> + struct uio_mem *uiomem = &info->mem[0]; >> + >> + while (uiomem < &info->mem[MAX_UIO_MAPS]) { >> + if (uiomem->size) { >> + mpc85xx_cache_sram_free(uiomem->internal_addr); >> + kfree(uiomem->name); >> + } >> + uiomem++; >> + } >> +} >> + >> +static int uio_fsl_85xx_cache_sram_probe(struct platform_device *pdev) >> +{ >> + struct device_node *parent = pdev->dev.of_node; >> + struct device_node *node = NULL; >> + struct uio_info *info; >> + struct uio_mem *uiomem; >> + const char *dt_name; >> + u32 mem_size; >> + u32 align; >> + void *virt; >> + phys_addr_t phys; >> + int ret = -ENODEV; >> + >> + /* alloc uio_info for one device */ >> + info = kzalloc(sizeof(*info), GFP_KERNEL); >> + if (!info) { >> + dev_err(&pdev->dev, "kzalloc uio_info failed\n"); > >kzalloc already says this. > Surely, I will delete with v2. >> + ret = -ENOMEM; >> + goto err_out; >> + } >> + >> + /* get optional uio name */ >> + if (of_property_read_string(parent, "uio_name", &dt_name)) >> + dt_name = UIO_NAME; >> + >> + info->name = kstrdup(dt_name, GFP_KERNEL); >> + if (!info->name) { >> + dev_err(&pdev->dev, "error kstrdup uio_name\n"); > >kstrdup should have given you an error string already, right? > Surely, I will delete with v2. >> + ret = -ENOMEM; >> + goto err_info_free; >> + } >> + >> + uiomem = &info->mem[0]; >> + for_each_child_of_node(parent, node) { >> + if (!node) { >> + dev_err(&pdev->dev, "device's OF-node is NULL\n"); > >How can this happen? > My fault, this would never happen. I will address it in v2. >> + continue; > >Why not error out? > >> + } >> + >> + ret = of_property_read_u32(node, "cache-mem-size", &mem_size); >> + if (ret) { >> + dev_err(&pdev->dev, "missing cache-mem-size value\n"); > >You don't exit? > >> + continue; >> + } >> + >> + if (mem_size == 0) { >> + dev_err(&pdev->dev, "cache-mem-size should not be 0\n"); > >Again, you don't exit? > >> + continue; >> + } >> + >> + align = 2; >> + while (align < mem_size) >> + align *= 2; >> + virt = mpc85xx_cache_sram_alloc(mem_size, &phys, align); >> + if (!virt) { >> + dev_err(&pdev->dev, "allocate 0x%x cache-mem failed\n", mem_size); > >You don't exit? > Actual all these situations should error out. For the continue branches, we got a situation that we accept all the possibly correct child node configurations, and it works. But it is not the common circumstance. I have tested all these situations and I will change all these to error out processes with v2. >> + continue; >> + } >> + >> + uiomem->memtype = UIO_MEM_PHYS; >> + uiomem->addr = phys; >> + uiomem->size = mem_size; >> + uiomem->name = kstrdup(node->name, GFP_KERNEL);; >> + uiomem->internal_addr = virt; >> + ++uiomem; >> + >> + if (uiomem >= &info->mem[MAX_UIO_MAPS]) { >> + dev_warn(&pdev->dev, "device has more than " >> + __stringify(MAX_UIO_MAPS) >> + " I/O memory resources.\n"); > >What can someone do with that? > Surely it should be more friendly. I will address it with v2. >thanks, > >greg k-h ^ permalink raw reply [flat|nested] 46+ messages in thread
* [PATCH v2,0/5] drivers: uio: new driver uio_fsl_85xx_cache_sram 2020-04-15 12:49 ` Greg KH 2020-04-15 14:07 ` [PATCH 5/5] drivers: uio: new driver for fsl_85xx_cache_sram>On Wed, Apr 15, 2020 at 05:33:46AM -0700, Wang Wenhu wrote: Wang Wenhu @ 2020-04-15 15:24 ` Wang Wenhu 2020-04-15 15:24 ` [PATCH v2,1/5] powerpc: 85xx: make FSL_85XX_CACHE_SRAM configurable Wang Wenhu ` (7 more replies) 1 sibling, 8 replies; 46+ messages in thread From: Wang Wenhu @ 2020-04-15 15:24 UTC (permalink / raw) To: gregkh, linux-kernel, oss, christophe.leroy, linuxppc-dev Cc: kernel, Wang Wenhu This series add a new uio driver for freescale 85xx platforms to access the Cache-Sram form user level. This is extremely helpful for the user-space applications that require high performance memory accesses. It fixes the compile errors and warning of the hardware level drivers and implements the uio driver in uio_fsl_85xx_cache_sram.c. Changes since v1: * Addressed comments of Greg K-H * Moved kfree(info->name) into uio_info_free_internal() Wang Wenhu (5): powerpc: 85xx: make FSL_85XX_CACHE_SRAM configurable powerpc: sysdev: fix compile error for fsl_85xx_cache_sram powerpc: sysdev: fix compile warning for fsl_85xx_cache_sram powerpc: sysdev: fix compile error for fsl_85xx_l2ctlr drivers: uio: new driver for fsl_85xx_cache_sram arch/powerpc/platforms/85xx/Kconfig | 2 +- arch/powerpc/platforms/Kconfig.cputype | 5 +- arch/powerpc/sysdev/fsl_85xx_cache_sram.c | 3 +- arch/powerpc/sysdev/fsl_85xx_l2ctlr.c | 1 + drivers/uio/Kconfig | 8 + drivers/uio/Makefile | 1 + drivers/uio/uio_fsl_85xx_cache_sram.c | 182 ++++++++++++++++++++++ 7 files changed, 198 insertions(+), 4 deletions(-) create mode 100644 drivers/uio/uio_fsl_85xx_cache_sram.c -- 2.17.1 ^ permalink raw reply [flat|nested] 46+ messages in thread
* [PATCH v2,1/5] powerpc: 85xx: make FSL_85XX_CACHE_SRAM configurable 2020-04-15 15:24 ` [PATCH v2,0/5] drivers: uio: new driver uio_fsl_85xx_cache_sram Wang Wenhu @ 2020-04-15 15:24 ` Wang Wenhu 2020-04-15 16:26 ` Christophe Leroy ` (2 more replies) 2020-04-15 15:24 ` [PATCH v2,2/5] powerpc: sysdev: fix compile error for fsl_85xx_cache_sram Wang Wenhu ` (6 subsequent siblings) 7 siblings, 3 replies; 46+ messages in thread From: Wang Wenhu @ 2020-04-15 15:24 UTC (permalink / raw) To: gregkh, linux-kernel, oss, christophe.leroy, linuxppc-dev Cc: kernel, Wang Wenhu, Michael Ellerman Enable FSL_85XX_CACHE_SRAM selection. On e500 platforms, the cache could be configured and used as a piece of SRAM which is hignly friendly for some user level application performances. Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Christophe Leroy <christophe.leroy@c-s.fr> Cc: Scott Wood <oss@buserror.net> Cc: Michael Ellerman <mpe@ellerman.id.au> Cc: linuxppc-dev@lists.ozlabs.org Signed-off-by: Wang Wenhu <wenhu.wang@vivo.com> --- Changes since v1: * None --- arch/powerpc/platforms/85xx/Kconfig | 2 +- arch/powerpc/platforms/Kconfig.cputype | 5 +++-- 2 files changed, 4 insertions(+), 3 deletions(-) diff --git a/arch/powerpc/platforms/85xx/Kconfig b/arch/powerpc/platforms/85xx/Kconfig index fa3d29dcb57e..6debb4f1b9cc 100644 --- a/arch/powerpc/platforms/85xx/Kconfig +++ b/arch/powerpc/platforms/85xx/Kconfig @@ -17,7 +17,7 @@ if FSL_SOC_BOOKE if PPC32 config FSL_85XX_CACHE_SRAM - bool + bool "Freescale 85xx Cache-Sram" select PPC_LIB_RHEAP help When selected, this option enables cache-sram support diff --git a/arch/powerpc/platforms/Kconfig.cputype b/arch/powerpc/platforms/Kconfig.cputype index 0c3c1902135c..1921e9a573e8 100644 --- a/arch/powerpc/platforms/Kconfig.cputype +++ b/arch/powerpc/platforms/Kconfig.cputype @@ -1,6 +1,6 @@ # SPDX-License-Identifier: GPL-2.0 config PPC32 - bool + bool "32-bit kernel" default y if !PPC64 select KASAN_VMALLOC if KASAN && MODULES @@ -15,6 +15,7 @@ config PPC_BOOK3S_32 bool menu "Processor support" + choice prompt "Processor Type" depends on PPC32 @@ -211,9 +212,9 @@ config PPC_BOOK3E depends on PPC_BOOK3E_64 config E500 + bool "e500 Support" select FSL_EMB_PERFMON select PPC_FSL_BOOK3E - bool config PPC_E500MC bool "e500mc Support" -- 2.17.1 ^ permalink raw reply related [flat|nested] 46+ messages in thread
* Re: [PATCH v2,1/5] powerpc: 85xx: make FSL_85XX_CACHE_SRAM configurable 2020-04-15 15:24 ` [PATCH v2,1/5] powerpc: 85xx: make FSL_85XX_CACHE_SRAM configurable Wang Wenhu @ 2020-04-15 16:26 ` Christophe Leroy 2020-04-15 16:29 ` Christophe Leroy 2020-04-15 18:53 ` Scott Wood 2 siblings, 0 replies; 46+ messages in thread From: Christophe Leroy @ 2020-04-15 16:26 UTC (permalink / raw) To: Wang Wenhu, gregkh, linux-kernel, oss, linuxppc-dev Cc: kernel, Michael Ellerman Le 15/04/2020 à 17:24, Wang Wenhu a écrit : > Enable FSL_85XX_CACHE_SRAM selection. On e500 platforms, the cache > could be configured and used as a piece of SRAM which is hignly > friendly for some user level application performances. > > Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> > Cc: Christophe Leroy <christophe.leroy@c-s.fr> > Cc: Scott Wood <oss@buserror.net> > Cc: Michael Ellerman <mpe@ellerman.id.au> > Cc: linuxppc-dev@lists.ozlabs.org > Signed-off-by: Wang Wenhu <wenhu.wang@vivo.com> > --- > Changes since v1: > * None > --- > arch/powerpc/platforms/85xx/Kconfig | 2 +- > arch/powerpc/platforms/Kconfig.cputype | 5 +++-- > 2 files changed, 4 insertions(+), 3 deletions(-) > > diff --git a/arch/powerpc/platforms/85xx/Kconfig b/arch/powerpc/platforms/85xx/Kconfig > index fa3d29dcb57e..6debb4f1b9cc 100644 > --- a/arch/powerpc/platforms/85xx/Kconfig > +++ b/arch/powerpc/platforms/85xx/Kconfig > @@ -17,7 +17,7 @@ if FSL_SOC_BOOKE > if PPC32 > > config FSL_85XX_CACHE_SRAM > - bool > + bool "Freescale 85xx Cache-Sram" > select PPC_LIB_RHEAP > help > When selected, this option enables cache-sram support > diff --git a/arch/powerpc/platforms/Kconfig.cputype b/arch/powerpc/platforms/Kconfig.cputype > index 0c3c1902135c..1921e9a573e8 100644 > --- a/arch/powerpc/platforms/Kconfig.cputype > +++ b/arch/powerpc/platforms/Kconfig.cputype > @@ -1,6 +1,6 @@ > # SPDX-License-Identifier: GPL-2.0 > config PPC32 > - bool > + bool "32-bit kernel" Why make that user selectable ? Either a kernel is 64-bit or it is 32-bit. So having PPC64 user selectable is all we need. And what is the link between this change and the description in the log ? > default y if !PPC64 > select KASAN_VMALLOC if KASAN && MODULES > > @@ -15,6 +15,7 @@ config PPC_BOOK3S_32 > bool > > menu "Processor support" > + Why adding this space ? > choice > prompt "Processor Type" > depends on PPC32 > @@ -211,9 +212,9 @@ config PPC_BOOK3E > depends on PPC_BOOK3E_64 > > config E500 > + bool "e500 Support" > select FSL_EMB_PERFMON > select PPC_FSL_BOOK3E > - bool Why make this user-selectable ? This is already selected by the processors requiring it, ie 8500, e5500 and e6500. Is there any other case where we need E500 ? And again, what's the link between this change and the description in the log ? > > config PPC_E500MC > bool "e500mc Support" > Christophe ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [PATCH v2,1/5] powerpc: 85xx: make FSL_85XX_CACHE_SRAM configurable 2020-04-15 15:24 ` [PATCH v2,1/5] powerpc: 85xx: make FSL_85XX_CACHE_SRAM configurable Wang Wenhu 2020-04-15 16:26 ` Christophe Leroy @ 2020-04-15 16:29 ` Christophe Leroy 2020-04-15 18:53 ` Scott Wood 2 siblings, 0 replies; 46+ messages in thread From: Christophe Leroy @ 2020-04-15 16:29 UTC (permalink / raw) To: Wang Wenhu, gregkh, linux-kernel, oss, linuxppc-dev Cc: kernel, Michael Ellerman Le 15/04/2020 à 17:24, Wang Wenhu a écrit : > Enable FSL_85XX_CACHE_SRAM selection. On e500 platforms, the cache > could be configured and used as a piece of SRAM which is hignly > friendly for some user level application performances. It looks like following patches are fixing errors generated by selecting FSL_85XX_CACHE_SRAM. So this patch should go after the patches which fixes the errors, ie it should be patch 4 in the series. Christophe ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [PATCH v2,1/5] powerpc: 85xx: make FSL_85XX_CACHE_SRAM configurable 2020-04-15 15:24 ` [PATCH v2,1/5] powerpc: 85xx: make FSL_85XX_CACHE_SRAM configurable Wang Wenhu 2020-04-15 16:26 ` Christophe Leroy 2020-04-15 16:29 ` Christophe Leroy @ 2020-04-15 18:53 ` Scott Wood 2020-04-16 4:11 ` Wang Wenhu 2 siblings, 1 reply; 46+ messages in thread From: Scott Wood @ 2020-04-15 18:53 UTC (permalink / raw) To: Wang Wenhu, gregkh, linux-kernel, christophe.leroy, linuxppc-dev Cc: kernel, Michael Ellerman On Wed, 2020-04-15 at 08:24 -0700, Wang Wenhu wrote: > Enable FSL_85XX_CACHE_SRAM selection. On e500 platforms, the cache > could be configured and used as a piece of SRAM which is hignly > friendly for some user level application performances. > > Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> > Cc: Christophe Leroy <christophe.leroy@c-s.fr> > Cc: Scott Wood <oss@buserror.net> > Cc: Michael Ellerman <mpe@ellerman.id.au> > Cc: linuxppc-dev@lists.ozlabs.org > Signed-off-by: Wang Wenhu <wenhu.wang@vivo.com> > --- > Changes since v1: > * None > --- > arch/powerpc/platforms/85xx/Kconfig | 2 +- > arch/powerpc/platforms/Kconfig.cputype | 5 +++-- > 2 files changed, 4 insertions(+), 3 deletions(-) > > diff --git a/arch/powerpc/platforms/85xx/Kconfig > b/arch/powerpc/platforms/85xx/Kconfig > index fa3d29dcb57e..6debb4f1b9cc 100644 > --- a/arch/powerpc/platforms/85xx/Kconfig > +++ b/arch/powerpc/platforms/85xx/Kconfig > @@ -17,7 +17,7 @@ if FSL_SOC_BOOKE > if PPC32 > > config FSL_85XX_CACHE_SRAM > - bool > + bool "Freescale 85xx Cache-Sram" > select PPC_LIB_RHEAP > help > When selected, this option enables cache-sram support NACK As discussed before, the driver that uses this API should "select" this symbol. -Scott ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [PATCH v2,1/5] powerpc: 85xx: make FSL_85XX_CACHE_SRAM configurable 2020-04-15 18:53 ` Scott Wood @ 2020-04-16 4:11 ` Wang Wenhu 0 siblings, 0 replies; 46+ messages in thread From: Wang Wenhu @ 2020-04-16 4:11 UTC (permalink / raw) To: oss, Wang Wenhu, gregkh Cc: christophe.leroy, kernel, linux-kernel, linuxppc-dev, mpe From: Scott Wood <oss@buserror.net> >> + bool "32-bit kernel" > >Why make that user selectable ? > >Either a kernel is 64-bit or it is 32-bit. So having PPC64 user >selectable is all we need. > >And what is the link between this change and the description in the log ? > >> default y if !PPC64 >> select KASAN_VMALLOC if KASAN && MODULES >> >> @@ -15,6 +15,7 @@ config PPC_BOOK3S_32 >> bool >> >> menu "Processor support" >> + > >Why adding this space ? > >> choice >> prompt "Processor Type" >> depends on PPC32 >> @@ -211,9 +212,9 @@ config PPC_BOOK3E >> depends on PPC_BOOK3E_64 >> >> config E500 >> + bool "e500 Support" >> select FSL_EMB_PERFMON >> select PPC_FSL_BOOK3E >> - bool > >Why make this user-selectable ? This is already selected by the >processors requiring it, ie 8500, e5500 and e6500. > >Is there any other case where we need E500 ? > >And again, what's the link between this change and the description in >the log ? > > >> >> config PPC_E500MC >> bool "e500mc Support" >> > >Christophe Hi, Scott, Christophe! I find that I did not get the point well of the defferences between configurability and selectability(maybe words I created) of Kconfig items. You are right that FSL_85XX_CACHE_SRAM should only be selected by a caller but never enable it seperately. Same answer for the comments from Christophe. I will drop this patch in v3. Thanks, Wenhu ^ permalink raw reply [flat|nested] 46+ messages in thread
* [PATCH v2,2/5] powerpc: sysdev: fix compile error for fsl_85xx_cache_sram 2020-04-15 15:24 ` [PATCH v2,0/5] drivers: uio: new driver uio_fsl_85xx_cache_sram Wang Wenhu 2020-04-15 15:24 ` [PATCH v2,1/5] powerpc: 85xx: make FSL_85XX_CACHE_SRAM configurable Wang Wenhu @ 2020-04-15 15:24 ` Wang Wenhu 2020-04-15 15:24 ` [PATCH v2,3/5] powerpc: sysdev: fix compile warning " Wang Wenhu ` (5 subsequent siblings) 7 siblings, 0 replies; 46+ messages in thread From: Wang Wenhu @ 2020-04-15 15:24 UTC (permalink / raw) To: gregkh, linux-kernel, oss, christophe.leroy, linuxppc-dev Cc: kernel, Wang Wenhu, Michael Ellerman Include linux/io.h into fsl_85xx_cache_sram.c to fix the implicit-declaration compile error when building Cache-Sram. arch/powerpc/sysdev/fsl_85xx_cache_sram.c: In function ‘instantiate_cache_sram’: arch/powerpc/sysdev/fsl_85xx_cache_sram.c:97:26: error: implicit declaration of function ‘ioremap_coherent’; did you mean ‘bitmap_complement’? [-Werror=implicit-function-declaration] cache_sram->base_virt = ioremap_coherent(cache_sram->base_phys, ^~~~~~~~~~~~~~~~ bitmap_complement arch/powerpc/sysdev/fsl_85xx_cache_sram.c:97:24: error: assignment makes pointer from integer without a cast [-Werror=int-conversion] cache_sram->base_virt = ioremap_coherent(cache_sram->base_phys, ^ arch/powerpc/sysdev/fsl_85xx_cache_sram.c:123:2: error: implicit declaration of function ‘iounmap’; did you mean ‘roundup’? [-Werror=implicit-function-declaration] iounmap(cache_sram->base_virt); ^~~~~~~ roundup cc1: all warnings being treated as errors Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Christophe Leroy <christophe.leroy@c-s.fr> Cc: Scott Wood <oss@buserror.net> Cc: Michael Ellerman <mpe@ellerman.id.au> Cc: linuxppc-dev@lists.ozlabs.org Fixes: 6db92cc9d07d ("powerpc/85xx: add cache-sram support") Signed-off-by: WANG Wenhu <wenhu.wang@vivo.com> --- Changes since v1: * None --- arch/powerpc/sysdev/fsl_85xx_cache_sram.c | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/powerpc/sysdev/fsl_85xx_cache_sram.c b/arch/powerpc/sysdev/fsl_85xx_cache_sram.c index f6c665dac725..be3aef4229d7 100644 --- a/arch/powerpc/sysdev/fsl_85xx_cache_sram.c +++ b/arch/powerpc/sysdev/fsl_85xx_cache_sram.c @@ -17,6 +17,7 @@ #include <linux/of_platform.h> #include <asm/pgtable.h> #include <asm/fsl_85xx_cache_sram.h> +#include <linux/io.h> #include "fsl_85xx_cache_ctlr.h" -- 2.17.1 ^ permalink raw reply related [flat|nested] 46+ messages in thread
* [PATCH v2,3/5] powerpc: sysdev: fix compile warning for fsl_85xx_cache_sram 2020-04-15 15:24 ` [PATCH v2,0/5] drivers: uio: new driver uio_fsl_85xx_cache_sram Wang Wenhu 2020-04-15 15:24 ` [PATCH v2,1/5] powerpc: 85xx: make FSL_85XX_CACHE_SRAM configurable Wang Wenhu 2020-04-15 15:24 ` [PATCH v2,2/5] powerpc: sysdev: fix compile error for fsl_85xx_cache_sram Wang Wenhu @ 2020-04-15 15:24 ` Wang Wenhu 2020-04-15 15:24 ` [PATCH v2,4/5] powerpc: sysdev: fix compile error for fsl_85xx_l2ctlr Wang Wenhu ` (4 subsequent siblings) 7 siblings, 0 replies; 46+ messages in thread From: Wang Wenhu @ 2020-04-15 15:24 UTC (permalink / raw) To: gregkh, linux-kernel, oss, christophe.leroy, linuxppc-dev Cc: kernel, Wang Wenhu, Michael Ellerman Function instantiate_cache_sram should not be linked into the init section for its caller mpc85xx_l2ctlr_of_probe is none-__init. Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Christophe Leroy <christophe.leroy@c-s.fr> Cc: Scott Wood <oss@buserror.net> Cc: Michael Ellerman <mpe@ellerman.id.au> Cc: linuxppc-dev@lists.ozlabs.org Fixes: 6db92cc9d07d ("powerpc/85xx: add cache-sram support") Signed-off-by: Wang Wenhu <wenhu.wang@vivo.com> Warning information: MODPOST vmlinux.o WARNING: modpost: vmlinux.o(.text+0x1e540): Section mismatch in reference from the function mpc85xx_l2ctlr_of_probe() to the function .init.text:instantiate_cache_sram() The function mpc85xx_l2ctlr_of_probe() references the function __init instantiate_cache_sram(). This is often because mpc85xx_l2ctlr_of_probe lacks a __init annotation or the annotation of instantiate_cache_sram is wrong. --- Changes since v1: * None --- arch/powerpc/sysdev/fsl_85xx_cache_sram.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/powerpc/sysdev/fsl_85xx_cache_sram.c b/arch/powerpc/sysdev/fsl_85xx_cache_sram.c index be3aef4229d7..3de5ac8382c0 100644 --- a/arch/powerpc/sysdev/fsl_85xx_cache_sram.c +++ b/arch/powerpc/sysdev/fsl_85xx_cache_sram.c @@ -68,7 +68,7 @@ void mpc85xx_cache_sram_free(void *ptr) } EXPORT_SYMBOL(mpc85xx_cache_sram_free); -int __init instantiate_cache_sram(struct platform_device *dev, +int instantiate_cache_sram(struct platform_device *dev, struct sram_parameters sram_params) { int ret = 0; -- 2.17.1 ^ permalink raw reply related [flat|nested] 46+ messages in thread
* [PATCH v2,4/5] powerpc: sysdev: fix compile error for fsl_85xx_l2ctlr 2020-04-15 15:24 ` [PATCH v2,0/5] drivers: uio: new driver uio_fsl_85xx_cache_sram Wang Wenhu ` (2 preceding siblings ...) 2020-04-15 15:24 ` [PATCH v2,3/5] powerpc: sysdev: fix compile warning " Wang Wenhu @ 2020-04-15 15:24 ` Wang Wenhu 2020-04-15 15:24 ` [PATCH v2,5/5] drivers: uio: new driver for fsl_85xx_cache_sram Wang Wenhu ` (3 subsequent siblings) 7 siblings, 0 replies; 46+ messages in thread From: Wang Wenhu @ 2020-04-15 15:24 UTC (permalink / raw) To: gregkh, linux-kernel, oss, christophe.leroy, linuxppc-dev Cc: kernel, Wang Wenhu, Michael Ellerman Include "linux/of_address.h" to fix the compile error for mpc85xx_l2ctlr_of_probe() when compiling fsl_85xx_cache_sram.c. CC arch/powerpc/sysdev/fsl_85xx_l2ctlr.o arch/powerpc/sysdev/fsl_85xx_l2ctlr.c: In function ‘mpc85xx_l2ctlr_of_probe’: arch/powerpc/sysdev/fsl_85xx_l2ctlr.c:90:11: error: implicit declaration of function ‘of_iomap’; did you mean ‘pci_iomap’? [-Werror=implicit-function-declaration] l2ctlr = of_iomap(dev->dev.of_node, 0); ^~~~~~~~ pci_iomap arch/powerpc/sysdev/fsl_85xx_l2ctlr.c:90:9: error: assignment makes pointer from integer without a cast [-Werror=int-conversion] l2ctlr = of_iomap(dev->dev.of_node, 0); ^ cc1: all warnings being treated as errors scripts/Makefile.build:267: recipe for target 'arch/powerpc/sysdev/fsl_85xx_l2ctlr.o' failed make[2]: *** [arch/powerpc/sysdev/fsl_85xx_l2ctlr.o] Error 1 Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Christophe Leroy <christophe.leroy@c-s.fr> Cc: Scott Wood <oss@buserror.net> Cc: Michael Ellerman <mpe@ellerman.id.au> Cc: linuxppc-dev@lists.ozlabs.org Fixes: 6db92cc9d07d ("powerpc/85xx: add cache-sram support") Signed-off-by: Wang Wenhu <wenhu.wang@vivo.com> --- Changes since v1: * None --- arch/powerpc/sysdev/fsl_85xx_l2ctlr.c | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/powerpc/sysdev/fsl_85xx_l2ctlr.c b/arch/powerpc/sysdev/fsl_85xx_l2ctlr.c index 2d0af0c517bb..7533572492f0 100644 --- a/arch/powerpc/sysdev/fsl_85xx_l2ctlr.c +++ b/arch/powerpc/sysdev/fsl_85xx_l2ctlr.c @@ -10,6 +10,7 @@ #include <linux/kernel.h> #include <linux/module.h> #include <linux/of_platform.h> +#include <linux/of_address.h> #include <asm/io.h> #include "fsl_85xx_cache_ctlr.h" -- 2.17.1 ^ permalink raw reply related [flat|nested] 46+ messages in thread
* [PATCH v2,5/5] drivers: uio: new driver for fsl_85xx_cache_sram 2020-04-15 15:24 ` [PATCH v2,0/5] drivers: uio: new driver uio_fsl_85xx_cache_sram Wang Wenhu ` (3 preceding siblings ...) 2020-04-15 15:24 ` [PATCH v2,4/5] powerpc: sysdev: fix compile error for fsl_85xx_l2ctlr Wang Wenhu @ 2020-04-15 15:24 ` Wang Wenhu 2020-04-15 16:52 ` Christophe Leroy 2020-04-15 19:26 ` Scott Wood 2020-04-16 7:29 ` [PATCH v3,0/4] drivers: uio: new driver uio_fsl_85xx_cache_sram Wang Wenhu ` (2 subsequent siblings) 7 siblings, 2 replies; 46+ messages in thread From: Wang Wenhu @ 2020-04-15 15:24 UTC (permalink / raw) To: gregkh, linux-kernel, oss, christophe.leroy, linuxppc-dev Cc: kernel, Wang Wenhu, Michael Ellerman A driver for freescale 85xx platforms to access the Cache-Sram form user level. This is extremely helpful for some user-space applications that require high performance memory accesses. Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Christophe Leroy <christophe.leroy@c-s.fr> Cc: Scott Wood <oss@buserror.net> Cc: Michael Ellerman <mpe@ellerman.id.au> Cc: linuxppc-dev@lists.ozlabs.org Signed-off-by: Wang Wenhu <wenhu.wang@vivo.com> --- Changes since v1: * Addressed comments of Greg K-H * Moved kfree(info->name) into uio_info_free_internal() --- drivers/uio/Kconfig | 8 ++ drivers/uio/Makefile | 1 + drivers/uio/uio_fsl_85xx_cache_sram.c | 182 ++++++++++++++++++++++++++ 3 files changed, 191 insertions(+) create mode 100644 drivers/uio/uio_fsl_85xx_cache_sram.c diff --git a/drivers/uio/Kconfig b/drivers/uio/Kconfig index 202ee81cfc2b..afd38ec13de0 100644 --- a/drivers/uio/Kconfig +++ b/drivers/uio/Kconfig @@ -105,6 +105,14 @@ config UIO_NETX To compile this driver as a module, choose M here; the module will be called uio_netx. +config UIO_FSL_85XX_CACHE_SRAM + tristate "Freescale 85xx Cache-Sram driver" + depends on FSL_85XX_CACHE_SRAM + help + Generic driver for accessing the Cache-Sram form user level. This + is extremely helpful for some user-space applications that require + high performance memory accesses. + config UIO_FSL_ELBC_GPCM tristate "eLBC/GPCM driver" depends on FSL_LBC diff --git a/drivers/uio/Makefile b/drivers/uio/Makefile index c285dd2a4539..be2056cffc21 100644 --- a/drivers/uio/Makefile +++ b/drivers/uio/Makefile @@ -10,4 +10,5 @@ obj-$(CONFIG_UIO_NETX) += uio_netx.o obj-$(CONFIG_UIO_PRUSS) += uio_pruss.o obj-$(CONFIG_UIO_MF624) += uio_mf624.o obj-$(CONFIG_UIO_FSL_ELBC_GPCM) += uio_fsl_elbc_gpcm.o +obj-$(CONFIG_UIO_FSL_85XX_CACHE_SRAM) += uio_fsl_85xx_cache_sram.o obj-$(CONFIG_UIO_HV_GENERIC) += uio_hv_generic.o diff --git a/drivers/uio/uio_fsl_85xx_cache_sram.c b/drivers/uio/uio_fsl_85xx_cache_sram.c new file mode 100644 index 000000000000..fb6903fdaddb --- /dev/null +++ b/drivers/uio/uio_fsl_85xx_cache_sram.c @@ -0,0 +1,182 @@ +// SPDX-License-Identifier: GPL-2.0 +/* + * Copyright (C) 2020 Vivo Communication Technology Co. Ltd. + * Copyright (C) 2020 Wang Wenhu <wenhu.wang@vivo.com> + * All rights reserved. + */ + +#include <linux/platform_device.h> +#include <linux/uio_driver.h> +#include <linux/stringify.h> +#include <linux/module.h> +#include <linux/kernel.h> +#include <asm/fsl_85xx_cache_sram.h> + +#define DRIVER_NAME "uio_fsl_85xx_cache_sram" +#define UIO_NAME "uio_cache_sram" + +static const struct of_device_id uio_mpc85xx_l2ctlr_of_match[] = { + { .compatible = "uio,fsl,p2020-l2-cache-controller", }, + { .compatible = "uio,fsl,p2010-l2-cache-controller", }, + { .compatible = "uio,fsl,p1020-l2-cache-controller", }, + { .compatible = "uio,fsl,p1011-l2-cache-controller", }, + { .compatible = "uio,fsl,p1013-l2-cache-controller", }, + { .compatible = "uio,fsl,p1022-l2-cache-controller", }, + { .compatible = "uio,fsl,mpc8548-l2-cache-controller", }, + { .compatible = "uio,fsl,mpc8544-l2-cache-controller", }, + { .compatible = "uio,fsl,mpc8572-l2-cache-controller", }, + { .compatible = "uio,fsl,mpc8536-l2-cache-controller", }, + { .compatible = "uio,fsl,p1021-l2-cache-controller", }, + { .compatible = "uio,fsl,p1012-l2-cache-controller", }, + { .compatible = "uio,fsl,p1025-l2-cache-controller", }, + { .compatible = "uio,fsl,p1016-l2-cache-controller", }, + { .compatible = "uio,fsl,p1024-l2-cache-controller", }, + { .compatible = "uio,fsl,p1015-l2-cache-controller", }, + { .compatible = "uio,fsl,p1010-l2-cache-controller", }, + { .compatible = "uio,fsl,bsc9131-l2-cache-controller", }, + {}, +}; + +static void uio_info_free_internal(struct uio_info *info) +{ + struct uio_mem *uiomem = &info->mem[0]; + + while (uiomem < &info->mem[MAX_UIO_MAPS]) { + if (uiomem->size) { + mpc85xx_cache_sram_free(uiomem->internal_addr); + kfree(uiomem->name); + } + uiomem++; + } + + kfree(info->name); +} + +static int uio_fsl_85xx_cache_sram_probe(struct platform_device *pdev) +{ + struct device_node *parent = pdev->dev.of_node; + struct device_node *node = NULL; + struct uio_info *info; + struct uio_mem *uiomem; + const char *dt_name; + u32 mem_size; + u32 align; + void *virt; + phys_addr_t phys; + int ret = -ENODEV; + + /* alloc uio_info for one device */ + info = kzalloc(sizeof(*info), GFP_KERNEL); + if (!info) { + ret = -ENOMEM; + goto err_out; + } + + /* get optional uio name */ + if (of_property_read_string(parent, "uio_name", &dt_name)) + dt_name = UIO_NAME; + + info->name = kstrdup(dt_name, GFP_KERNEL); + if (!info->name) { + ret = -ENOMEM; + goto err_info_free; + } + + uiomem = &info->mem[0]; + for_each_child_of_node(parent, node) { + ret = of_property_read_u32(node, "cache-mem-size", &mem_size); + if (ret) { + ret = -EINVAL; + goto err_info_free_internel; + } + + if (mem_size == 0) { + dev_err(&pdev->dev, "cache-mem-size should not be 0\n"); + ret = -EINVAL; + goto err_info_free_internel; + } + + align = 2; + while (align < mem_size) + align *= 2; + virt = mpc85xx_cache_sram_alloc(mem_size, &phys, align); + if (!virt) { + /* mpc85xx_cache_sram_alloc to define the cause */ + ret = -EINVAL; + goto err_info_free_internel; + } + + uiomem->memtype = UIO_MEM_PHYS; + uiomem->addr = phys; + uiomem->size = mem_size; + uiomem->name = kstrdup(node->name, GFP_KERNEL);; + uiomem->internal_addr = virt; + ++uiomem; + + if (uiomem >= &info->mem[MAX_UIO_MAPS]) { + dev_warn(&pdev->dev, "more than %d uio-maps for device.\n", + MAX_UIO_MAPS); + break; + } + } + + while (uiomem < &info->mem[MAX_UIO_MAPS]) { + uiomem->size = 0; + ++uiomem; + } + + if (info->mem[0].size == 0) { + dev_err(&pdev->dev, "error no valid uio-map configured\n"); + ret = -EINVAL; + goto err_info_free_internel; + } + + info->version = "0.1.0"; + + /* register uio device */ + if (uio_register_device(&pdev->dev, info)) { + dev_err(&pdev->dev, "uio registration failed\n"); + ret = -ENODEV; + goto err_info_free_internel; + } + + platform_set_drvdata(pdev, info); + + return 0; +err_info_free_internel: + uio_info_free_internal(info); +err_info_free: + kfree(info); +err_out: + return ret; +} + +static int uio_fsl_85xx_cache_sram_remove(struct platform_device *pdev) +{ + struct uio_info *info = platform_get_drvdata(pdev); + + uio_unregister_device(info); + + uio_info_free_internal(info); + + kfree(info); + + return 0; +} + +static struct platform_driver uio_fsl_85xx_cache_sram = { + .probe = uio_fsl_85xx_cache_sram_probe, + .remove = uio_fsl_85xx_cache_sram_remove, + .driver = { + .name = DRIVER_NAME, + .owner = THIS_MODULE, + .of_match_table = uio_mpc85xx_l2ctlr_of_match, + }, +}; + +module_platform_driver(uio_fsl_85xx_cache_sram); + +MODULE_AUTHOR("Wang Wenhu <wenhu.wang@vivo.com>"); +MODULE_DESCRIPTION("Freescale MPC85xx Cache-Sram UIO Platform Driver"); +MODULE_ALIAS("platform:" DRIVER_NAME); +MODULE_LICENSE("GPL v2"); -- 2.17.1 ^ permalink raw reply related [flat|nested] 46+ messages in thread
* Re: [PATCH v2,5/5] drivers: uio: new driver for fsl_85xx_cache_sram 2020-04-15 15:24 ` [PATCH v2,5/5] drivers: uio: new driver for fsl_85xx_cache_sram Wang Wenhu @ 2020-04-15 16:52 ` Christophe Leroy 2020-04-15 19:27 ` Scott Wood 2020-04-16 5:22 ` Wang Wenhu 2020-04-15 19:26 ` Scott Wood 1 sibling, 2 replies; 46+ messages in thread From: Christophe Leroy @ 2020-04-15 16:52 UTC (permalink / raw) To: Wang Wenhu, gregkh, linux-kernel, oss, linuxppc-dev Cc: kernel, Michael Ellerman Le 15/04/2020 à 17:24, Wang Wenhu a écrit : > A driver for freescale 85xx platforms to access the Cache-Sram form > user level. This is extremely helpful for some user-space applications > that require high performance memory accesses. > > Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> > Cc: Christophe Leroy <christophe.leroy@c-s.fr> > Cc: Scott Wood <oss@buserror.net> > Cc: Michael Ellerman <mpe@ellerman.id.au> > Cc: linuxppc-dev@lists.ozlabs.org > Signed-off-by: Wang Wenhu <wenhu.wang@vivo.com> > --- > Changes since v1: > * Addressed comments of Greg K-H > * Moved kfree(info->name) into uio_info_free_internal() > --- > drivers/uio/Kconfig | 8 ++ > drivers/uio/Makefile | 1 + > drivers/uio/uio_fsl_85xx_cache_sram.c | 182 ++++++++++++++++++++++++++ > 3 files changed, 191 insertions(+) > create mode 100644 drivers/uio/uio_fsl_85xx_cache_sram.c > > diff --git a/drivers/uio/Kconfig b/drivers/uio/Kconfig > index 202ee81cfc2b..afd38ec13de0 100644 > --- a/drivers/uio/Kconfig > +++ b/drivers/uio/Kconfig > @@ -105,6 +105,14 @@ config UIO_NETX > To compile this driver as a module, choose M here; the module > will be called uio_netx. > > +config UIO_FSL_85XX_CACHE_SRAM > + tristate "Freescale 85xx Cache-Sram driver" > + depends on FSL_85XX_CACHE_SRAM Is there any point having FSL_85XX_CACHE_SRAM without this ? Should it be the other way round, leave FSL_85XX_CACHE_SRAM unselectable by user, and this driver select FSL_85XX_CACHE_SRAM instead of depending on it ? > + help > + Generic driver for accessing the Cache-Sram form user level. This > + is extremely helpful for some user-space applications that require > + high performance memory accesses. > + > config UIO_FSL_ELBC_GPCM > tristate "eLBC/GPCM driver" > depends on FSL_LBC > diff --git a/drivers/uio/Makefile b/drivers/uio/Makefile > index c285dd2a4539..be2056cffc21 100644 > --- a/drivers/uio/Makefile > +++ b/drivers/uio/Makefile > @@ -10,4 +10,5 @@ obj-$(CONFIG_UIO_NETX) += uio_netx.o > obj-$(CONFIG_UIO_PRUSS) += uio_pruss.o > obj-$(CONFIG_UIO_MF624) += uio_mf624.o > obj-$(CONFIG_UIO_FSL_ELBC_GPCM) += uio_fsl_elbc_gpcm.o > +obj-$(CONFIG_UIO_FSL_85XX_CACHE_SRAM) += uio_fsl_85xx_cache_sram.o > obj-$(CONFIG_UIO_HV_GENERIC) += uio_hv_generic.o > diff --git a/drivers/uio/uio_fsl_85xx_cache_sram.c b/drivers/uio/uio_fsl_85xx_cache_sram.c > new file mode 100644 > index 000000000000..fb6903fdaddb > --- /dev/null > +++ b/drivers/uio/uio_fsl_85xx_cache_sram.c > @@ -0,0 +1,182 @@ > +// SPDX-License-Identifier: GPL-2.0 > +/* > + * Copyright (C) 2020 Vivo Communication Technology Co. Ltd. > + * Copyright (C) 2020 Wang Wenhu <wenhu.wang@vivo.com> > + * All rights reserved. > + */ > + > +#include <linux/platform_device.h> > +#include <linux/uio_driver.h> > +#include <linux/stringify.h> > +#include <linux/module.h> > +#include <linux/kernel.h> > +#include <asm/fsl_85xx_cache_sram.h> > + > +#define DRIVER_NAME "uio_fsl_85xx_cache_sram" > +#define UIO_NAME "uio_cache_sram" > + > +static const struct of_device_id uio_mpc85xx_l2ctlr_of_match[] = { > + { .compatible = "uio,fsl,p2020-l2-cache-controller", }, > + { .compatible = "uio,fsl,p2010-l2-cache-controller", }, > + { .compatible = "uio,fsl,p1020-l2-cache-controller", }, > + { .compatible = "uio,fsl,p1011-l2-cache-controller", }, > + { .compatible = "uio,fsl,p1013-l2-cache-controller", }, > + { .compatible = "uio,fsl,p1022-l2-cache-controller", }, > + { .compatible = "uio,fsl,mpc8548-l2-cache-controller", }, > + { .compatible = "uio,fsl,mpc8544-l2-cache-controller", }, > + { .compatible = "uio,fsl,mpc8572-l2-cache-controller", }, > + { .compatible = "uio,fsl,mpc8536-l2-cache-controller", }, > + { .compatible = "uio,fsl,p1021-l2-cache-controller", }, > + { .compatible = "uio,fsl,p1012-l2-cache-controller", }, > + { .compatible = "uio,fsl,p1025-l2-cache-controller", }, > + { .compatible = "uio,fsl,p1016-l2-cache-controller", }, > + { .compatible = "uio,fsl,p1024-l2-cache-controller", }, > + { .compatible = "uio,fsl,p1015-l2-cache-controller", }, > + { .compatible = "uio,fsl,p1010-l2-cache-controller", }, > + { .compatible = "uio,fsl,bsc9131-l2-cache-controller", }, > + {}, > +}; > + > +static void uio_info_free_internal(struct uio_info *info) > +{ > + struct uio_mem *uiomem = &info->mem[0]; > + > + while (uiomem < &info->mem[MAX_UIO_MAPS]) { > + if (uiomem->size) { > + mpc85xx_cache_sram_free(uiomem->internal_addr); > + kfree(uiomem->name); > + } > + uiomem++; > + } > + > + kfree(info->name); > +} > + > +static int uio_fsl_85xx_cache_sram_probe(struct platform_device *pdev) > +{ > + struct device_node *parent = pdev->dev.of_node; > + struct device_node *node = NULL; > + struct uio_info *info; > + struct uio_mem *uiomem; > + const char *dt_name; > + u32 mem_size; > + u32 align; Align is not used outside of the for loop, it should be declared in the loop block. > + void *virt; Same for virt > + phys_addr_t phys; Same for phys > + int ret = -ENODEV; It looks like this init value is unneeded, you should leave 'ret' uninitialised (unless I missed some way out and you get a warning). > + > + /* alloc uio_info for one device */ > + info = kzalloc(sizeof(*info), GFP_KERNEL); > + if (!info) { > + ret = -ENOMEM; > + goto err_out; Nothing special is done at err_out, you should instead do: if (!info) return -ENOMEM; > + } > + > + /* get optional uio name */ > + if (of_property_read_string(parent, "uio_name", &dt_name)) > + dt_name = UIO_NAME; > + > + info->name = kstrdup(dt_name, GFP_KERNEL); > + if (!info->name) { > + ret = -ENOMEM; > + goto err_info_free; > + } > + > + uiomem = &info->mem[0]; I'd prefer uiomem = info->mem; > + for_each_child_of_node(parent, node) { > + ret = of_property_read_u32(node, "cache-mem-size", &mem_size); > + if (ret) { > + ret = -EINVAL; > + goto err_info_free_internel; > + } > + > + if (mem_size == 0) { > + dev_err(&pdev->dev, "cache-mem-size should not be 0\n"); > + ret = -EINVAL; > + goto err_info_free_internel; > + } > + > + align = 2; > + while (align < mem_size) > + align *= 2; I think ilog2() or one of it friends should be used here, maybe roundup_pow_of_two() > + virt = mpc85xx_cache_sram_alloc(mem_size, &phys, align); > + if (!virt) { > + /* mpc85xx_cache_sram_alloc to define the cause */ > + ret = -EINVAL; Should it be -ENOMEM like any allocation failure ? > + goto err_info_free_internel; > + } > + > + uiomem->memtype = UIO_MEM_PHYS; > + uiomem->addr = phys; > + uiomem->size = mem_size; > + uiomem->name = kstrdup(node->name, GFP_KERNEL);; > + uiomem->internal_addr = virt; > + ++uiomem; Usually people use uiomem++; > + > + if (uiomem >= &info->mem[MAX_UIO_MAPS]) { I'd prefer if (uiomem - info->mem >= MAX_UIO_MAPS) { > + dev_warn(&pdev->dev, "more than %d uio-maps for device.\n", > + MAX_UIO_MAPS); > + break; > + } > + } > + > + while (uiomem < &info->mem[MAX_UIO_MAPS]) { I'd prefer while (uiomem - info->mem < MAX_UIO_MAPS) { > + uiomem->size = 0; > + ++uiomem; > + } > + > + if (info->mem[0].size == 0) { Is there any point in doing all the clearing loop above if it's to bail out here ? Wouldn't it be cleaner to do the test above the clearing loop, by just checking whether uiomem is still equal to info->mem ? > + dev_err(&pdev->dev, "error no valid uio-map configured\n"); > + ret = -EINVAL; > + goto err_info_free_internel; > + } > + > + info->version = "0.1.0"; Could you define some DRIVER_VERSION in the top of the file next to DRIVER_NAME instead of hard coding in the middle on a function ? > + > + /* register uio device */ > + if (uio_register_device(&pdev->dev, info)) { > + dev_err(&pdev->dev, "uio registration failed\n"); > + ret = -ENODEV; > + goto err_info_free_internel; > + } > + > + platform_set_drvdata(pdev, info); > + > + return 0; > +err_info_free_internel: Do you mean 'internal' instead of 'internel' ? > + uio_info_free_internal(info); > +err_info_free: > + kfree(info); > +err_out: > + return ret; > +} > + > +static int uio_fsl_85xx_cache_sram_remove(struct platform_device *pdev) > +{ > + struct uio_info *info = platform_get_drvdata(pdev); > + > + uio_unregister_device(info); > + > + uio_info_free_internal(info); > + > + kfree(info); > + > + return 0; > +} > + > +static struct platform_driver uio_fsl_85xx_cache_sram = { > + .probe = uio_fsl_85xx_cache_sram_probe, > + .remove = uio_fsl_85xx_cache_sram_remove, > + .driver = { > + .name = DRIVER_NAME, > + .owner = THIS_MODULE, > + .of_match_table = uio_mpc85xx_l2ctlr_of_match, > + }, > +}; > + > +module_platform_driver(uio_fsl_85xx_cache_sram); > + > +MODULE_AUTHOR("Wang Wenhu <wenhu.wang@vivo.com>"); > +MODULE_DESCRIPTION("Freescale MPC85xx Cache-Sram UIO Platform Driver"); > +MODULE_ALIAS("platform:" DRIVER_NAME); > +MODULE_LICENSE("GPL v2"); > Christophe ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [PATCH v2,5/5] drivers: uio: new driver for fsl_85xx_cache_sram 2020-04-15 16:52 ` Christophe Leroy @ 2020-04-15 19:27 ` Scott Wood 2020-04-16 6:30 ` Greg KH 2020-04-16 5:22 ` Wang Wenhu 1 sibling, 1 reply; 46+ messages in thread From: Scott Wood @ 2020-04-15 19:27 UTC (permalink / raw) To: Christophe Leroy, Wang Wenhu, gregkh, linux-kernel, linuxppc-dev Cc: kernel, Michael Ellerman On Wed, 2020-04-15 at 18:52 +0200, Christophe Leroy wrote: > > Le 15/04/2020 à 17:24, Wang Wenhu a écrit : > > + > > + if (uiomem >= &info->mem[MAX_UIO_MAPS]) { > > I'd prefer > if (uiomem - info->mem >= MAX_UIO_MAPS) { > > > + dev_warn(&pdev->dev, "more than %d uio-maps for > > device.\n", > > + MAX_UIO_MAPS); > > + break; > > + } > > + } > > + > > + while (uiomem < &info->mem[MAX_UIO_MAPS]) { > > I'd prefer > > while (uiomem - info->mem < MAX_UIO_MAPS) { > I wouldn't. You're turning a simple comparison into a division and a comparison (if the compiler doesn't optimize it back into the original form), and making it less clear in the process. Of course, working with array indices to begin with instead of incrementing a pointer would be more idiomatic. > > + uiomem->size = 0; > > + ++uiomem; > > + } > > + > > + if (info->mem[0].size == 0) { > > Is there any point in doing all the clearing loop above if it's to bail > out here ? > > Wouldn't it be cleaner to do the test above the clearing loop, by just > checking whether uiomem is still equal to info->mem ? There's no point doing the clearing at all, since the array was allocated with kzalloc(). > > + dev_err(&pdev->dev, "error no valid uio-map configured\n"); > > + ret = -EINVAL; > > + goto err_info_free_internel; > > + } > > + > > + info->version = "0.1.0"; > > Could you define some DRIVER_VERSION in the top of the file next to > DRIVER_NAME instead of hard coding in the middle on a function ? That's what v1 had, and Greg KH said to remove it. I'm guessing that he thought it was the common-but-pointless practice of having the driver print a version number that never gets updated, rather than something the UIO API (unfortunately, compared to a feature query interface) expects. That said, I'm not sure what the value is of making it a macro since it should only be used once, that use is self documenting, it isn't tunable, etc. Though if this isn't a macro, UIO_NAME also shouldn't be (and if it is made a macro again, it should be UIO_VERSION, not DRIVER_VERSION). Does this really need a three-part version scheme? What's wrong with a version of "1", to be changed to "2" in the hopefully-unlikely event that the userspace API changes? Assuming UIO is used for this at all, which doesn't seem like a great fit to me. -Scott ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [PATCH v2,5/5] drivers: uio: new driver for fsl_85xx_cache_sram 2020-04-15 19:27 ` Scott Wood @ 2020-04-16 6:30 ` Greg KH 2020-04-16 19:36 ` Scott Wood 0 siblings, 1 reply; 46+ messages in thread From: Greg KH @ 2020-04-16 6:30 UTC (permalink / raw) To: Scott Wood Cc: Christophe Leroy, Wang Wenhu, linux-kernel, linuxppc-dev, kernel, Michael Ellerman On Wed, Apr 15, 2020 at 02:27:51PM -0500, Scott Wood wrote: > > > + dev_err(&pdev->dev, "error no valid uio-map configured\n"); > > > + ret = -EINVAL; > > > + goto err_info_free_internel; > > > + } > > > + > > > + info->version = "0.1.0"; > > > > Could you define some DRIVER_VERSION in the top of the file next to > > DRIVER_NAME instead of hard coding in the middle on a function ? > > That's what v1 had, and Greg KH said to remove it. I'm guessing that he > thought it was the common-but-pointless practice of having the driver print a > version number that never gets updated, rather than something the UIO API > (unfortunately, compared to a feature query interface) expects. That said, > I'm not sure what the value is of making it a macro since it should only be > used once, that use is self documenting, it isn't tunable, etc. Though if > this isn't a macro, UIO_NAME also shouldn't be (and if it is made a macro > again, it should be UIO_VERSION, not DRIVER_VERSION). > > Does this really need a three-part version scheme? What's wrong with a > version of "1", to be changed to "2" in the hopefully-unlikely event that the > userspace API changes? Assuming UIO is used for this at all, which doesn't > seem like a great fit to me. No driver version numbers at all please, they do not make any sense when the driver is included in the kernel tree. greg k-h ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [PATCH v2,5/5] drivers: uio: new driver for fsl_85xx_cache_sram 2020-04-16 6:30 ` Greg KH @ 2020-04-16 19:36 ` Scott Wood 0 siblings, 0 replies; 46+ messages in thread From: Scott Wood @ 2020-04-16 19:36 UTC (permalink / raw) To: Greg KH Cc: Christophe Leroy, Wang Wenhu, linux-kernel, linuxppc-dev, kernel, Michael Ellerman On Thu, 2020-04-16 at 08:30 +0200, Greg KH wrote: > On Wed, Apr 15, 2020 at 02:27:51PM -0500, Scott Wood wrote: > > > > + dev_err(&pdev->dev, "error no valid uio-map > > > > configured\n"); > > > > + ret = -EINVAL; > > > > + goto err_info_free_internel; > > > > + } > > > > + > > > > + info->version = "0.1.0"; > > > > > > Could you define some DRIVER_VERSION in the top of the file next to > > > DRIVER_NAME instead of hard coding in the middle on a function ? > > > > That's what v1 had, and Greg KH said to remove it. I'm guessing that he > > thought it was the common-but-pointless practice of having the driver > > print a > > version number that never gets updated, rather than something the UIO API > > (unfortunately, compared to a feature query interface) expects. That > > said, > > I'm not sure what the value is of making it a macro since it should only > > be > > used once, that use is self documenting, it isn't tunable, etc. Though if > > this isn't a macro, UIO_NAME also shouldn't be (and if it is made a macro > > again, it should be UIO_VERSION, not DRIVER_VERSION). > > > > Does this really need a three-part version scheme? What's wrong with a > > version of "1", to be changed to "2" in the hopefully-unlikely event that > > the > > userspace API changes? Assuming UIO is used for this at all, which > > doesn't > > seem like a great fit to me. > > No driver version numbers at all please, they do not make any sense when > the driver is included in the kernel tree. Again, reporting a version string is part of the UIO API. It might not be a good API, but if it's left as NULL the registration will fail. -Scott ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [PATCH v2,5/5] drivers: uio: new driver for fsl_85xx_cache_sram 2020-04-15 16:52 ` Christophe Leroy 2020-04-15 19:27 ` Scott Wood @ 2020-04-16 5:22 ` Wang Wenhu 2020-04-16 6:02 ` Christophe Leroy 1 sibling, 1 reply; 46+ messages in thread From: Wang Wenhu @ 2020-04-16 5:22 UTC (permalink / raw) To: christophe.leroy Cc: gregkh, kernel, linux-kernel, linuxppc-dev, mpe, oss, wenhu.wang Yes, kzalloc() would clean the allocated areas and the init of remaining array elements are redundant. I will remove the block in v3. >> > + dev_err(&pdev->dev, "error no valid uio-map configured\n"); >> > + ret = -EINVAL; >> > + goto err_info_free_internel; >> > + } >> > + >> > + info->version = "0.1.0"; >> >> Could you define some DRIVER_VERSION in the top of the file next to >> DRIVER_NAME instead of hard coding in the middle on a function ? > >That's what v1 had, and Greg KH said to remove it. I'm guessing that he >thought it was the common-but-pointless practice of having the driver print a >version number that never gets updated, rather than something the UIO API >(unfortunately, compared to a feature query interface) expects. That said, >I'm not sure what the value is of making it a macro since it should only be >used once, that use is self documenting, it isn't tunable, etc. Though if >this isn't a macro, UIO_NAME also shouldn't be (and if it is made a macro >again, it should be UIO_VERSION, not DRIVER_VERSION). > >Does this really need a three-part version scheme? What's wrong with a >version of "1", to be changed to "2" in the hopefully-unlikely event that the >userspace API changes? Assuming UIO is used for this at all, which doesn't >seem like a great fit to me. > >-Scott > As Scott mentioned, the version define as necessity by uio core but actually useless for us here(and for many other type of devices I guess). So maybe the better way is to set it optionally, but this belong first to uio core. For the cache-sram uio driver, I will define an UIO_VERSION micro as a compromise fit all wonders, no confusing as Greg first mentioned. >> +static const struct of_device_id uio_mpc85xx_l2ctlr_of_match[] = { >> + { .compatible = "uio,fsl,p2020-l2-cache-controller", }, >> + { .compatible = "uio,fsl,p2010-l2-cache-controller", }, >> + { .compatible = "uio,fsl,p1020-l2-cache-controller", }, >> + { .compatible = "uio,fsl,p1011-l2-cache-controller", }, >> + { .compatible = "uio,fsl,p1013-l2-cache-controller", }, >> + { .compatible = "uio,fsl,p1022-l2-cache-controller", }, >> + { .compatible = "uio,fsl,mpc8548-l2-cache-controller", }, >> + { .compatible = "uio,fsl,mpc8544-l2-cache-controller", }, >> + { .compatible = "uio,fsl,mpc8572-l2-cache-controller", }, >> + { .compatible = "uio,fsl,mpc8536-l2-cache-controller", }, >> + { .compatible = "uio,fsl,p1021-l2-cache-controller", }, >> + { .compatible = "uio,fsl,p1012-l2-cache-controller", }, >> + { .compatible = "uio,fsl,p1025-l2-cache-controller", }, >> + { .compatible = "uio,fsl,p1016-l2-cache-controller", }, >> + { .compatible = "uio,fsl,p1024-l2-cache-controller", }, >> + { .compatible = "uio,fsl,p1015-l2-cache-controller", }, >> + { .compatible = "uio,fsl,p1010-l2-cache-controller", }, >> + { .compatible = "uio,fsl,bsc9131-l2-cache-controller", }, >> + {}, >> +}; > >NACK > >The device tree describes the hardware, not what driver you want to bind the >hardware to, or how you want to allocate the resources. And even if defining >nodes for sram allocation were the right way to go, why do you have a separate >compatible for each chip when you're just describing software configuration? > >Instead, have module parameters that take the sizes and alignments you'd like >to allocate and expose to userspace. Better still would be some sort of >dynamic allocation (e.g. open a fd, ioctl to set the requested size/alignment, >if it succeeds you can mmap it, and when the fd is closed the region is >freed). > >-Scott > Can not agree more. But what if I want to define more than one cache-sram uio devices? How about use the device tree for pseudo uio cache-sram driver? static const struct of_device_id uio_mpc85xx_l2ctlr_of_match[] = { { .compatible = "uio,cache-sram", }, {}, }; Thanks, Wenhu ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [PATCH v2,5/5] drivers: uio: new driver for fsl_85xx_cache_sram 2020-04-16 5:22 ` Wang Wenhu @ 2020-04-16 6:02 ` Christophe Leroy 0 siblings, 0 replies; 46+ messages in thread From: Christophe Leroy @ 2020-04-16 6:02 UTC (permalink / raw) To: Wang Wenhu; +Cc: gregkh, kernel, linux-kernel, linuxppc-dev, mpe, oss Le 16/04/2020 à 07:22, Wang Wenhu a écrit : > Yes, kzalloc() would clean the allocated areas and the init of remaining array > elements are redundant. I will remove the block in v3. > >>>> + dev_err(&pdev->dev, "error no valid uio-map configured\n"); >>>> + ret = -EINVAL; >>>> + goto err_info_free_internel; >>>> + } >>>> + >>>> + info->version = "0.1.0"; >>> >>> Could you define some DRIVER_VERSION in the top of the file next to >>> DRIVER_NAME instead of hard coding in the middle on a function ? >> >> That's what v1 had, and Greg KH said to remove it. I'm guessing that he >> thought it was the common-but-pointless practice of having the driver print a >> version number that never gets updated, rather than something the UIO API >> (unfortunately, compared to a feature query interface) expects. That said, >> I'm not sure what the value is of making it a macro since it should only be >> used once, that use is self documenting, it isn't tunable, etc. Though if >> this isn't a macro, UIO_NAME also shouldn't be (and if it is made a macro >> again, it should be UIO_VERSION, not DRIVER_VERSION). >> >> Does this really need a three-part version scheme? What's wrong with a >> version of "1", to be changed to "2" in the hopefully-unlikely event that the >> userspace API changes? Assuming UIO is used for this at all, which doesn't >> seem like a great fit to me. >> >> -Scott >> > > As Scott mentioned, the version define as necessity by uio core but actually > useless for us here(and for many other type of devices I guess). So maybe the better > way is to set it optionally, but this belong first to uio core. > > For the cache-sram uio driver, I will define an UIO_VERSION micro as a compromise > fit all wonders, no confusing as Greg first mentioned. Yes I like it. > >>> +static const struct of_device_id uio_mpc85xx_l2ctlr_of_match[] = { >>> + { .compatible = "uio,fsl,p2020-l2-cache-controller", }, >>> + { .compatible = "uio,fsl,p2010-l2-cache-controller", }, >>> + { .compatible = "uio,fsl,p1020-l2-cache-controller", }, >>> + { .compatible = "uio,fsl,p1011-l2-cache-controller", }, >>> + { .compatible = "uio,fsl,p1013-l2-cache-controller", }, >>> + { .compatible = "uio,fsl,p1022-l2-cache-controller", }, >>> + { .compatible = "uio,fsl,mpc8548-l2-cache-controller", }, >>> + { .compatible = "uio,fsl,mpc8544-l2-cache-controller", }, >>> + { .compatible = "uio,fsl,mpc8572-l2-cache-controller", }, >>> + { .compatible = "uio,fsl,mpc8536-l2-cache-controller", }, >>> + { .compatible = "uio,fsl,p1021-l2-cache-controller", }, >>> + { .compatible = "uio,fsl,p1012-l2-cache-controller", }, >>> + { .compatible = "uio,fsl,p1025-l2-cache-controller", }, >>> + { .compatible = "uio,fsl,p1016-l2-cache-controller", }, >>> + { .compatible = "uio,fsl,p1024-l2-cache-controller", }, >>> + { .compatible = "uio,fsl,p1015-l2-cache-controller", }, >>> + { .compatible = "uio,fsl,p1010-l2-cache-controller", }, >>> + { .compatible = "uio,fsl,bsc9131-l2-cache-controller", }, >>> + {}, >>> +}; >> >> NACK >> >> The device tree describes the hardware, not what driver you want to bind the >> hardware to, or how you want to allocate the resources. And even if defining >> nodes for sram allocation were the right way to go, why do you have a separate >> compatible for each chip when you're just describing software configuration? >> >> Instead, have module parameters that take the sizes and alignments you'd like >> to allocate and expose to userspace. Better still would be some sort of >> dynamic allocation (e.g. open a fd, ioctl to set the requested size/alignment, >> if it succeeds you can mmap it, and when the fd is closed the region is >> freed). >> >> -Scott >> > > Can not agree more. But what if I want to define more than one cache-sram uio devices? > How about use the device tree for pseudo uio cache-sram driver? > > static const struct of_device_id uio_mpc85xx_l2ctlr_of_match[] = { > { .compatible = "uio,cache-sram", }, > {}, > }; > You can still give it a name in line with your driver, ie: "uio,mpc85xx-cache-sram" After, it you have different behaviours depending on the compatible, then you have to add a .data field which will tell the driver which behaviour to implement. Christophe ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [PATCH v2,5/5] drivers: uio: new driver for fsl_85xx_cache_sram 2020-04-15 15:24 ` [PATCH v2,5/5] drivers: uio: new driver for fsl_85xx_cache_sram Wang Wenhu 2020-04-15 16:52 ` Christophe Leroy @ 2020-04-15 19:26 ` Scott Wood 2020-04-16 6:30 ` Greg KH 1 sibling, 1 reply; 46+ messages in thread From: Scott Wood @ 2020-04-15 19:26 UTC (permalink / raw) To: Wang Wenhu, gregkh, linux-kernel, christophe.leroy, linuxppc-dev Cc: kernel, Michael Ellerman On Wed, 2020-04-15 at 08:24 -0700, Wang Wenhu wrote: > +static const struct of_device_id uio_mpc85xx_l2ctlr_of_match[] = { > + { .compatible = "uio,fsl,p2020-l2-cache-controller", }, > + { .compatible = "uio,fsl,p2010-l2-cache-controller", }, > + { .compatible = "uio,fsl,p1020-l2-cache-controller", }, > + { .compatible = "uio,fsl,p1011-l2-cache-controller", }, > + { .compatible = "uio,fsl,p1013-l2-cache-controller", }, > + { .compatible = "uio,fsl,p1022-l2-cache-controller", }, > + { .compatible = "uio,fsl,mpc8548-l2-cache-controller", }, > + { .compatible = "uio,fsl,mpc8544-l2-cache-controller", }, > + { .compatible = "uio,fsl,mpc8572-l2-cache-controller", }, > + { .compatible = "uio,fsl,mpc8536-l2-cache-controller", }, > + { .compatible = "uio,fsl,p1021-l2-cache-controller", }, > + { .compatible = "uio,fsl,p1012-l2-cache-controller", }, > + { .compatible = "uio,fsl,p1025-l2-cache-controller", }, > + { .compatible = "uio,fsl,p1016-l2-cache-controller", }, > + { .compatible = "uio,fsl,p1024-l2-cache-controller", }, > + { .compatible = "uio,fsl,p1015-l2-cache-controller", }, > + { .compatible = "uio,fsl,p1010-l2-cache-controller", }, > + { .compatible = "uio,fsl,bsc9131-l2-cache-controller", }, > + {}, > +}; NACK The device tree describes the hardware, not what driver you want to bind the hardware to, or how you want to allocate the resources. And even if defining nodes for sram allocation were the right way to go, why do you have a separate compatible for each chip when you're just describing software configuration? Instead, have module parameters that take the sizes and alignments you'd like to allocate and expose to userspace. Better still would be some sort of dynamic allocation (e.g. open a fd, ioctl to set the requested size/alignment, if it succeeds you can mmap it, and when the fd is closed the region is freed). -Scott ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [PATCH v2,5/5] drivers: uio: new driver for fsl_85xx_cache_sram 2020-04-15 19:26 ` Scott Wood @ 2020-04-16 6:30 ` Greg KH 2020-04-16 19:40 ` Scott Wood 0 siblings, 1 reply; 46+ messages in thread From: Greg KH @ 2020-04-16 6:30 UTC (permalink / raw) To: Scott Wood Cc: Wang Wenhu, linux-kernel, christophe.leroy, linuxppc-dev, kernel, Michael Ellerman On Wed, Apr 15, 2020 at 02:26:55PM -0500, Scott Wood wrote: > Instead, have module parameters that take the sizes and alignments you'd like > to allocate and expose to userspace. Better still would be some sort of > dynamic allocation (e.g. open a fd, ioctl to set the requested size/alignment, > if it succeeds you can mmap it, and when the fd is closed the region is > freed). No module parameters please, this is not the 1990's. Use device tree, that is what it is there for. thanks, greg k-h ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [PATCH v2,5/5] drivers: uio: new driver for fsl_85xx_cache_sram 2020-04-16 6:30 ` Greg KH @ 2020-04-16 19:40 ` Scott Wood 0 siblings, 0 replies; 46+ messages in thread From: Scott Wood @ 2020-04-16 19:40 UTC (permalink / raw) To: Greg KH Cc: Wang Wenhu, linux-kernel, christophe.leroy, linuxppc-dev, kernel, Michael Ellerman On Thu, 2020-04-16 at 08:30 +0200, Greg KH wrote: > On Wed, Apr 15, 2020 at 02:26:55PM -0500, Scott Wood wrote: > > Instead, have module parameters that take the sizes and alignments you'd > > like > > to allocate and expose to userspace. Better still would be some sort of > > dynamic allocation (e.g. open a fd, ioctl to set the requested > > size/alignment, > > if it succeeds you can mmap it, and when the fd is closed the region is > > freed). > > No module parameters please, this is not the 1990's. > > Use device tree, that is what it is there for. Since when is the device tree for indicating desired allocations? This is not hardware description. If module parameters are unacceptable, then I'd suggest dynamic allocation as described above. -Scott ^ permalink raw reply [flat|nested] 46+ messages in thread
* [PATCH v3,0/4] drivers: uio: new driver uio_fsl_85xx_cache_sram 2020-04-15 15:24 ` [PATCH v2,0/5] drivers: uio: new driver uio_fsl_85xx_cache_sram Wang Wenhu ` (4 preceding siblings ...) 2020-04-15 15:24 ` [PATCH v2,5/5] drivers: uio: new driver for fsl_85xx_cache_sram Wang Wenhu @ 2020-04-16 7:29 ` Wang Wenhu 2020-04-16 7:29 ` [PATCH v3,1/4] powerpc: sysdev: fix compile error for fsl_85xx_l2ctlr Wang Wenhu ` (3 more replies) 2020-04-16 7:41 ` [PATCH v3,0/4] drivers: uio: new driver uio_fsl_85xx_cache_sram Wang Wenhu 2020-04-16 7:49 ` [PATCH v3,0/4] drivers: uio: new driver uio_fsl_85xx_cache_sram Wang Wenhu 7 siblings, 4 replies; 46+ messages in thread From: Wang Wenhu @ 2020-04-16 7:29 UTC (permalink / raw) To: gregkh, linux-kernel, oss, christophe.leroy, linuxppc-dev Cc: kernel, Wang Wenhu This series add a new uio driver for freescale 85xx platforms to access the Cache-Sram form user level. This is extremely helpful for the user-space applications that require high performance memory accesses. It fixes the compile errors and warning of the hardware level drivers and implements the uio driver in uio_fsl_85xx_cache_sram.c. Changes since v1: * Addressed comments from Greg K-H * Moved kfree(info->name) into uio_info_free_internal() Changes since v2: * Drop the patch that modifies Kconfigs of arch/powerpc/platforms and modified the sequence of patches: 01:dropped, 02->03, 03->02, 04->01, 05->04 * Addressed comments from Greg, Scott and Christophe * Use "uiomem->internal_addr" as if condition for sram memory free, and memset the uiomem entry * Modified of_match_table make the driver apart from Cache-Sram HW info which belong to the HW level driver fsl_85xx_cache_sram to match * Use roundup_pow_of_two for align calc(really learned a lot from Christophe) * Remove useless clear block of uiomem entries. * Use UIO_INFO_VER micro for info->version, and define it as "devicetree,pseudo", meaning this is pseudo device and probed from device tree configuration * Select FSL_85XX_CACHE_SRAM rather than depends on it Wang Wenhu (4): powerpc: sysdev: fix compile error for fsl_85xx_l2ctlr powerpc: sysdev: fix compile error for fsl_85xx_cache_sram powerpc: sysdev: fix compile warning for fsl_85xx_cache_sram drivers: uio: new driver for fsl_85xx_cache_sram arch/powerpc/sysdev/fsl_85xx_cache_sram.c | 3 +- arch/powerpc/sysdev/fsl_85xx_l2ctlr.c | 1 + drivers/uio/Kconfig | 9 ++ drivers/uio/Makefile | 1 + drivers/uio/uio_fsl_85xx_cache_sram.c | 158 ++++++++++++++++++++++ 5 files changed, 171 insertions(+), 1 deletion(-) create mode 100644 drivers/uio/uio_fsl_85xx_cache_sram.c -- 2.17.1 ^ permalink raw reply [flat|nested] 46+ messages in thread
* [PATCH v3,1/4] powerpc: sysdev: fix compile error for fsl_85xx_l2ctlr 2020-04-16 7:29 ` [PATCH v3,0/4] drivers: uio: new driver uio_fsl_85xx_cache_sram Wang Wenhu @ 2020-04-16 7:29 ` Wang Wenhu 2020-04-16 7:29 ` [PATCH v3,2/4] powerpc: sysdev: fix compile error for fsl_85xx_cache_sram Wang Wenhu ` (2 subsequent siblings) 3 siblings, 0 replies; 46+ messages in thread From: Wang Wenhu @ 2020-04-16 7:29 UTC (permalink / raw) To: gregkh, linux-kernel, oss, christophe.leroy, linuxppc-dev Cc: kernel, Wang Wenhu, Michael Ellerman Include "linux/of_address.h" to fix the compile error for mpc85xx_l2ctlr_of_probe() when compiling fsl_85xx_cache_sram.c. CC arch/powerpc/sysdev/fsl_85xx_l2ctlr.o arch/powerpc/sysdev/fsl_85xx_l2ctlr.c: In function ‘mpc85xx_l2ctlr_of_probe’: arch/powerpc/sysdev/fsl_85xx_l2ctlr.c:90:11: error: implicit declaration of function ‘of_iomap’; did you mean ‘pci_iomap’? [-Werror=implicit-function-declaration] l2ctlr = of_iomap(dev->dev.of_node, 0); ^~~~~~~~ pci_iomap arch/powerpc/sysdev/fsl_85xx_l2ctlr.c:90:9: error: assignment makes pointer from integer without a cast [-Werror=int-conversion] l2ctlr = of_iomap(dev->dev.of_node, 0); ^ cc1: all warnings being treated as errors scripts/Makefile.build:267: recipe for target 'arch/powerpc/sysdev/fsl_85xx_l2ctlr.o' failed make[2]: *** [arch/powerpc/sysdev/fsl_85xx_l2ctlr.o] Error 1 Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Christophe Leroy <christophe.leroy@c-s.fr> Cc: Scott Wood <oss@buserror.net> Cc: Michael Ellerman <mpe@ellerman.id.au> Cc: linuxppc-dev@lists.ozlabs.org Fixes: 6db92cc9d07d ("powerpc/85xx: add cache-sram support") Signed-off-by: Wang Wenhu <wenhu.wang@vivo.com> --- Changes since v1: * None Changes since v2: * None --- arch/powerpc/sysdev/fsl_85xx_l2ctlr.c | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/powerpc/sysdev/fsl_85xx_l2ctlr.c b/arch/powerpc/sysdev/fsl_85xx_l2ctlr.c index 2d0af0c517bb..7533572492f0 100644 --- a/arch/powerpc/sysdev/fsl_85xx_l2ctlr.c +++ b/arch/powerpc/sysdev/fsl_85xx_l2ctlr.c @@ -10,6 +10,7 @@ #include <linux/kernel.h> #include <linux/module.h> #include <linux/of_platform.h> +#include <linux/of_address.h> #include <asm/io.h> #include "fsl_85xx_cache_ctlr.h" -- 2.17.1 ^ permalink raw reply related [flat|nested] 46+ messages in thread
* [PATCH v3,2/4] powerpc: sysdev: fix compile error for fsl_85xx_cache_sram 2020-04-16 7:29 ` [PATCH v3,0/4] drivers: uio: new driver uio_fsl_85xx_cache_sram Wang Wenhu 2020-04-16 7:29 ` [PATCH v3,1/4] powerpc: sysdev: fix compile error for fsl_85xx_l2ctlr Wang Wenhu @ 2020-04-16 7:29 ` Wang Wenhu 2020-04-16 7:29 ` [PATCH v3,3/4] powerpc: sysdev: fix compile warning " Wang Wenhu 2020-04-16 7:29 ` [PATCH v3,4/4] drivers: uio: new driver " Wang Wenhu 3 siblings, 0 replies; 46+ messages in thread From: Wang Wenhu @ 2020-04-16 7:29 UTC (permalink / raw) To: gregkh, linux-kernel, oss, christophe.leroy, linuxppc-dev Cc: kernel, Wang Wenhu, Michael Ellerman Include linux/io.h into fsl_85xx_cache_sram.c to fix the implicit-declaration compile error when building Cache-Sram. arch/powerpc/sysdev/fsl_85xx_cache_sram.c: In function ‘instantiate_cache_sram’: arch/powerpc/sysdev/fsl_85xx_cache_sram.c:97:26: error: implicit declaration of function ‘ioremap_coherent’; did you mean ‘bitmap_complement’? [-Werror=implicit-function-declaration] cache_sram->base_virt = ioremap_coherent(cache_sram->base_phys, ^~~~~~~~~~~~~~~~ bitmap_complement arch/powerpc/sysdev/fsl_85xx_cache_sram.c:97:24: error: assignment makes pointer from integer without a cast [-Werror=int-conversion] cache_sram->base_virt = ioremap_coherent(cache_sram->base_phys, ^ arch/powerpc/sysdev/fsl_85xx_cache_sram.c:123:2: error: implicit declaration of function ‘iounmap’; did you mean ‘roundup’? [-Werror=implicit-function-declaration] iounmap(cache_sram->base_virt); ^~~~~~~ roundup cc1: all warnings being treated as errors Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Christophe Leroy <christophe.leroy@c-s.fr> Cc: Scott Wood <oss@buserror.net> Cc: Michael Ellerman <mpe@ellerman.id.au> Cc: linuxppc-dev@lists.ozlabs.org Fixes: 6db92cc9d07d ("powerpc/85xx: add cache-sram support") Signed-off-by: WANG Wenhu <wenhu.wang@vivo.com> --- Changes since v1: * None Changes since v2: * None --- arch/powerpc/sysdev/fsl_85xx_cache_sram.c | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/powerpc/sysdev/fsl_85xx_cache_sram.c b/arch/powerpc/sysdev/fsl_85xx_cache_sram.c index f6c665dac725..be3aef4229d7 100644 --- a/arch/powerpc/sysdev/fsl_85xx_cache_sram.c +++ b/arch/powerpc/sysdev/fsl_85xx_cache_sram.c @@ -17,6 +17,7 @@ #include <linux/of_platform.h> #include <asm/pgtable.h> #include <asm/fsl_85xx_cache_sram.h> +#include <linux/io.h> #include "fsl_85xx_cache_ctlr.h" -- 2.17.1 ^ permalink raw reply related [flat|nested] 46+ messages in thread
* [PATCH v3,3/4] powerpc: sysdev: fix compile warning for fsl_85xx_cache_sram 2020-04-16 7:29 ` [PATCH v3,0/4] drivers: uio: new driver uio_fsl_85xx_cache_sram Wang Wenhu 2020-04-16 7:29 ` [PATCH v3,1/4] powerpc: sysdev: fix compile error for fsl_85xx_l2ctlr Wang Wenhu 2020-04-16 7:29 ` [PATCH v3,2/4] powerpc: sysdev: fix compile error for fsl_85xx_cache_sram Wang Wenhu @ 2020-04-16 7:29 ` Wang Wenhu 2020-04-16 7:29 ` [PATCH v3,4/4] drivers: uio: new driver " Wang Wenhu 3 siblings, 0 replies; 46+ messages in thread From: Wang Wenhu @ 2020-04-16 7:29 UTC (permalink / raw) To: gregkh, linux-kernel, oss, christophe.leroy, linuxppc-dev Cc: kernel, Wang Wenhu, Michael Ellerman Function instantiate_cache_sram should not be linked into the init section for its caller mpc85xx_l2ctlr_of_probe is none-__init. Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Christophe Leroy <christophe.leroy@c-s.fr> Cc: Scott Wood <oss@buserror.net> Cc: Michael Ellerman <mpe@ellerman.id.au> Cc: linuxppc-dev@lists.ozlabs.org Fixes: 6db92cc9d07d ("powerpc/85xx: add cache-sram support") Signed-off-by: Wang Wenhu <wenhu.wang@vivo.com> Warning information: MODPOST vmlinux.o WARNING: modpost: vmlinux.o(.text+0x1e540): Section mismatch in reference from the function mpc85xx_l2ctlr_of_probe() to the function .init.text:instantiate_cache_sram() The function mpc85xx_l2ctlr_of_probe() references the function __init instantiate_cache_sram(). This is often because mpc85xx_l2ctlr_of_probe lacks a __init annotation or the annotation of instantiate_cache_sram is wrong. --- Changes since v1: * None Changes since v2: * None --- arch/powerpc/sysdev/fsl_85xx_cache_sram.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/powerpc/sysdev/fsl_85xx_cache_sram.c b/arch/powerpc/sysdev/fsl_85xx_cache_sram.c index be3aef4229d7..3de5ac8382c0 100644 --- a/arch/powerpc/sysdev/fsl_85xx_cache_sram.c +++ b/arch/powerpc/sysdev/fsl_85xx_cache_sram.c @@ -68,7 +68,7 @@ void mpc85xx_cache_sram_free(void *ptr) } EXPORT_SYMBOL(mpc85xx_cache_sram_free); -int __init instantiate_cache_sram(struct platform_device *dev, +int instantiate_cache_sram(struct platform_device *dev, struct sram_parameters sram_params) { int ret = 0; -- 2.17.1 ^ permalink raw reply related [flat|nested] 46+ messages in thread
* [PATCH v3,4/4] drivers: uio: new driver for fsl_85xx_cache_sram 2020-04-16 7:29 ` [PATCH v3,0/4] drivers: uio: new driver uio_fsl_85xx_cache_sram Wang Wenhu ` (2 preceding siblings ...) 2020-04-16 7:29 ` [PATCH v3,3/4] powerpc: sysdev: fix compile warning " Wang Wenhu @ 2020-04-16 7:29 ` Wang Wenhu 3 siblings, 0 replies; 46+ messages in thread From: Wang Wenhu @ 2020-04-16 7:29 UTC (permalink / raw) To: gregkh, linux-kernel, oss, christophe.leroy, linuxppc-dev Cc: kernel, Wang Wenhu, Michael Ellerman A driver for freescale 85xx platforms to access the Cache-Sram form user level. This is extremely helpful for some user-space applications that require high performance memory accesses. Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Christophe Leroy <christophe.leroy@c-s.fr> Cc: Scott Wood <oss@buserror.net> Cc: Michael Ellerman <mpe@ellerman.id.au> Cc: linuxppc-dev@lists.ozlabs.org Signed-off-by: Wang Wenhu <wenhu.wang@vivo.com> --- Changes since v1: * Addressed comments from Greg K-H * Moved kfree(info->name) into uio_info_free_internal() Changes since v2: * Addressed comments from Greg, Scott and Christophe * Use "uiomem->internal_addr" as if condition for sram memory free, and memset the uiomem entry * Modified of_match_table make the driver apart from Cache-Sram HW info which belong to the HW level driver fsl_85xx_cache_sram to match * Use roundup_pow_of_two for align calculation * Remove useless clear block of uiomem entries. * Use UIO_INFO_VER micro for info->version, and define it as "devicetree,pseudo", meaning this is pseudo device and probed from device tree configuration * Select FSL_85XX_CACHE_SRAM rather than depends on it --- drivers/uio/Kconfig | 9 ++ drivers/uio/Makefile | 1 + drivers/uio/uio_fsl_85xx_cache_sram.c | 158 ++++++++++++++++++++++++++ 3 files changed, 168 insertions(+) create mode 100644 drivers/uio/uio_fsl_85xx_cache_sram.c diff --git a/drivers/uio/Kconfig b/drivers/uio/Kconfig index 202ee81cfc2b..9c3b47461b71 100644 --- a/drivers/uio/Kconfig +++ b/drivers/uio/Kconfig @@ -105,6 +105,15 @@ config UIO_NETX To compile this driver as a module, choose M here; the module will be called uio_netx. +config UIO_FSL_85XX_CACHE_SRAM + tristate "Freescale 85xx Cache-Sram driver" + depends on FSL_SOC_BOOKE && PPC32 + select FSL_85XX_CACHE_SRAM + help + Generic driver for accessing the Cache-Sram form user level. This + is extremely helpful for some user-space applications that require + high performance memory accesses. + config UIO_FSL_ELBC_GPCM tristate "eLBC/GPCM driver" depends on FSL_LBC diff --git a/drivers/uio/Makefile b/drivers/uio/Makefile index c285dd2a4539..be2056cffc21 100644 --- a/drivers/uio/Makefile +++ b/drivers/uio/Makefile @@ -10,4 +10,5 @@ obj-$(CONFIG_UIO_NETX) += uio_netx.o obj-$(CONFIG_UIO_PRUSS) += uio_pruss.o obj-$(CONFIG_UIO_MF624) += uio_mf624.o obj-$(CONFIG_UIO_FSL_ELBC_GPCM) += uio_fsl_elbc_gpcm.o +obj-$(CONFIG_UIO_FSL_85XX_CACHE_SRAM) += uio_fsl_85xx_cache_sram.o obj-$(CONFIG_UIO_HV_GENERIC) += uio_hv_generic.o diff --git a/drivers/uio/uio_fsl_85xx_cache_sram.c b/drivers/uio/uio_fsl_85xx_cache_sram.c new file mode 100644 index 000000000000..8701df695307 --- /dev/null +++ b/drivers/uio/uio_fsl_85xx_cache_sram.c @@ -0,0 +1,158 @@ +// SPDX-License-Identifier: GPL-2.0 +/* + * Copyright (C) 2020 Vivo Communication Technology Co. Ltd. + * Copyright (C) 2020 Wang Wenhu <wenhu.wang@vivo.com> + * All rights reserved. + */ + +#include <linux/platform_device.h> +#include <linux/uio_driver.h> +#include <linux/stringify.h> +#include <linux/module.h> +#include <linux/kernel.h> +#include <asm/fsl_85xx_cache_sram.h> + +#define DRIVER_NAME "uio_fsl_85xx_cache_sram" +#define UIO_INFO_VER "devicetree,pseudo" +#define UIO_NAME "uio_cache_sram" + +static void uio_info_free_internal(struct uio_info *info) +{ + struct uio_mem *uiomem = info->mem; + + while (uiomem < &info->mem[MAX_UIO_MAPS]) { + if (uiomem->internal_addr) { + mpc85xx_cache_sram_free(uiomem->internal_addr); + kfree(uiomem->name); + memset(uiomem, 0, sizeof(*uiomem)); + } + uiomem++; + } + + kfree(info->name); +} + +static int uio_fsl_85xx_cache_sram_probe(struct platform_device *pdev) +{ + struct device_node *parent = pdev->dev.of_node; + struct device_node *node = NULL; + struct uio_info *info; + struct uio_mem *uiomem; + const char *dt_name; + u32 mem_size; + int ret; + + /* alloc uio_info for one device */ + info = kzalloc(sizeof(*info), GFP_KERNEL); + if (!info) + return -ENOMEM; + + /* get optional uio name */ + if (of_property_read_string(parent, "uio_name", &dt_name)) + dt_name = UIO_NAME; + + info->name = kstrdup(dt_name, GFP_KERNEL); + if (!info->name) { + ret = -ENOMEM; + goto err_info_free; + } + + uiomem = info->mem; + for_each_child_of_node(parent, node) { + void *virt; + phys_addr_t phys; + + ret = of_property_read_u32(node, "cache-mem-size", &mem_size); + if (ret) { + ret = -EINVAL; + goto err_info_free_internal; + } + + if (mem_size == 0) { + dev_err(&pdev->dev, "cache-mem-size should not be 0\n"); + ret = -EINVAL; + goto err_info_free_internal; + } + + virt = mpc85xx_cache_sram_alloc(mem_size, + &phys, + roundup_pow_of_two(mem_size)); + if (!virt) { + /* mpc85xx_cache_sram_alloc to define the real cause */ + ret = -ENOMEM; + goto err_info_free_internal; + } + + uiomem->memtype = UIO_MEM_PHYS; + uiomem->addr = phys; + uiomem->size = mem_size; + uiomem->name = kstrdup(node->name, GFP_KERNEL);; + uiomem->internal_addr = virt; + uiomem++; + + if (uiomem >= &info->mem[MAX_UIO_MAPS]) { + dev_warn(&pdev->dev, "more than %d uio-maps for device.\n", + MAX_UIO_MAPS); + break; + } + } + + if (uiomem == info->mem) { + dev_err(&pdev->dev, "error no valid uio-map configured\n"); + ret = -EINVAL; + goto err_info_free_internal; + } + + info->version = UIO_INFO_VER; + + /* register uio device */ + if (uio_register_device(&pdev->dev, info)) { + dev_err(&pdev->dev, "uio registration failed\n"); + ret = -ENODEV; + goto err_info_free_internal; + } + + platform_set_drvdata(pdev, info); + + return 0; +err_info_free_internal: + uio_info_free_internal(info); +err_info_free: + kfree(info); + return ret; +} + +static int uio_fsl_85xx_cache_sram_remove(struct platform_device *pdev) +{ + struct uio_info *info = platform_get_drvdata(pdev); + + uio_unregister_device(info); + + uio_info_free_internal(info); + + kfree(info); + + return 0; +} + +static const struct of_device_id uio_mpc85xx_l2ctlr_of_match[] = { + { .compatible = "uio,mpc85xx-cache-sram", }, + {}, +}; + +static struct platform_driver uio_fsl_85xx_cache_sram = { + .probe = uio_fsl_85xx_cache_sram_probe, + .remove = uio_fsl_85xx_cache_sram_remove, + .driver = { + .name = DRIVER_NAME, + .owner = THIS_MODULE, + .of_match_table = uio_mpc85xx_l2ctlr_of_match, + }, +}; + +module_platform_driver(uio_fsl_85xx_cache_sram); + +MODULE_AUTHOR("Wang Wenhu <wenhu.wang@vivo.com>"); +MODULE_DESCRIPTION("Freescale MPC85xx Cache-Sram UIO Platform Driver"); +MODULE_ALIAS("platform:" DRIVER_NAME); +MODULE_LICENSE("GPL v2"); -- 2.17.1 ^ permalink raw reply related [flat|nested] 46+ messages in thread
* [PATCH v3,0/4] drivers: uio: new driver uio_fsl_85xx_cache_sram 2020-04-15 15:24 ` [PATCH v2,0/5] drivers: uio: new driver uio_fsl_85xx_cache_sram Wang Wenhu ` (5 preceding siblings ...) 2020-04-16 7:29 ` [PATCH v3,0/4] drivers: uio: new driver uio_fsl_85xx_cache_sram Wang Wenhu @ 2020-04-16 7:41 ` Wang Wenhu 2020-04-16 7:41 ` [PATCH v3,1/4] powerpc: sysdev: fix compile error for fsl_85xx_l2ctlr Wang Wenhu ` (3 more replies) 2020-04-16 7:49 ` [PATCH v3,0/4] drivers: uio: new driver uio_fsl_85xx_cache_sram Wang Wenhu 7 siblings, 4 replies; 46+ messages in thread From: Wang Wenhu @ 2020-04-16 7:41 UTC (permalink / raw) To: gregkh, linux-kernel, oss, christophe.leroy, linuxppc-dev Cc: kernel, Wang Wenhu This series add a new uio driver for freescale 85xx platforms to access the Cache-Sram form user level. This is extremely helpful for the user-space applications that require high performance memory accesses. It fixes the compile errors and warning of the hardware level drivers and implements the uio driver in uio_fsl_85xx_cache_sram.c. Changes since v1: * Addressed comments from Greg K-H * Moved kfree(info->name) into uio_info_free_internal() Changes since v2: * Drop the patch that modifies Kconfigs of arch/powerpc/platforms and modified the sequence of patches: 01:dropped, 02->03, 03->02, 04->01, 05->04 * Addressed comments from Greg, Scott and Christophe * Use "uiomem->internal_addr" as if condition for sram memory free, and memset the uiomem entry * Modified of_match_table make the driver apart from Cache-Sram HW info which belong to the HW level driver fsl_85xx_cache_sram to match * Use roundup_pow_of_two for align calc(really learned a lot from Christophe) * Remove useless clear block of uiomem entries. * Use UIO_INFO_VER micro for info->version, and define it as "devicetree,pseudo", meaning this is pseudo device and probed from device tree configuration * Select FSL_85XX_CACHE_SRAM rather than depends on it Wang Wenhu (4): powerpc: sysdev: fix compile error for fsl_85xx_l2ctlr powerpc: sysdev: fix compile error for fsl_85xx_cache_sram powerpc: sysdev: fix compile warning for fsl_85xx_cache_sram drivers: uio: new driver for fsl_85xx_cache_sram arch/powerpc/sysdev/fsl_85xx_cache_sram.c | 3 +- arch/powerpc/sysdev/fsl_85xx_l2ctlr.c | 1 + drivers/uio/Kconfig | 9 ++ drivers/uio/Makefile | 1 + drivers/uio/uio_fsl_85xx_cache_sram.c | 158 ++++++++++++++++++++++ 5 files changed, 171 insertions(+), 1 deletion(-) create mode 100644 drivers/uio/uio_fsl_85xx_cache_sram.c -- 2.17.1 ^ permalink raw reply [flat|nested] 46+ messages in thread
* [PATCH v3,1/4] powerpc: sysdev: fix compile error for fsl_85xx_l2ctlr 2020-04-16 7:41 ` [PATCH v3,0/4] drivers: uio: new driver uio_fsl_85xx_cache_sram Wang Wenhu @ 2020-04-16 7:41 ` Wang Wenhu 2020-04-16 7:41 ` [PATCH v3,2/4] powerpc: sysdev: fix compile error for fsl_85xx_cache_sram Wang Wenhu ` (2 subsequent siblings) 3 siblings, 0 replies; 46+ messages in thread From: Wang Wenhu @ 2020-04-16 7:41 UTC (permalink / raw) To: gregkh, linux-kernel, oss, christophe.leroy, linuxppc-dev Cc: kernel, Wang Wenhu, Michael Ellerman Include "linux/of_address.h" to fix the compile error for mpc85xx_l2ctlr_of_probe() when compiling fsl_85xx_cache_sram.c. CC arch/powerpc/sysdev/fsl_85xx_l2ctlr.o arch/powerpc/sysdev/fsl_85xx_l2ctlr.c: In function ‘mpc85xx_l2ctlr_of_probe’: arch/powerpc/sysdev/fsl_85xx_l2ctlr.c:90:11: error: implicit declaration of function ‘of_iomap’; did you mean ‘pci_iomap’? [-Werror=implicit-function-declaration] l2ctlr = of_iomap(dev->dev.of_node, 0); ^~~~~~~~ pci_iomap arch/powerpc/sysdev/fsl_85xx_l2ctlr.c:90:9: error: assignment makes pointer from integer without a cast [-Werror=int-conversion] l2ctlr = of_iomap(dev->dev.of_node, 0); ^ cc1: all warnings being treated as errors scripts/Makefile.build:267: recipe for target 'arch/powerpc/sysdev/fsl_85xx_l2ctlr.o' failed make[2]: *** [arch/powerpc/sysdev/fsl_85xx_l2ctlr.o] Error 1 Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Christophe Leroy <christophe.leroy@c-s.fr> Cc: Scott Wood <oss@buserror.net> Cc: Michael Ellerman <mpe@ellerman.id.au> Cc: linuxppc-dev@lists.ozlabs.org Fixes: 6db92cc9d07d ("powerpc/85xx: add cache-sram support") Signed-off-by: Wang Wenhu <wenhu.wang@vivo.com> --- Changes since v1: * None Changes since v2: * None --- arch/powerpc/sysdev/fsl_85xx_l2ctlr.c | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/powerpc/sysdev/fsl_85xx_l2ctlr.c b/arch/powerpc/sysdev/fsl_85xx_l2ctlr.c index 2d0af0c517bb..7533572492f0 100644 --- a/arch/powerpc/sysdev/fsl_85xx_l2ctlr.c +++ b/arch/powerpc/sysdev/fsl_85xx_l2ctlr.c @@ -10,6 +10,7 @@ #include <linux/kernel.h> #include <linux/module.h> #include <linux/of_platform.h> +#include <linux/of_address.h> #include <asm/io.h> #include "fsl_85xx_cache_ctlr.h" -- 2.17.1 ^ permalink raw reply related [flat|nested] 46+ messages in thread
* [PATCH v3,2/4] powerpc: sysdev: fix compile error for fsl_85xx_cache_sram 2020-04-16 7:41 ` [PATCH v3,0/4] drivers: uio: new driver uio_fsl_85xx_cache_sram Wang Wenhu 2020-04-16 7:41 ` [PATCH v3,1/4] powerpc: sysdev: fix compile error for fsl_85xx_l2ctlr Wang Wenhu @ 2020-04-16 7:41 ` Wang Wenhu 2020-04-16 7:41 ` [PATCH v3,3/4] powerpc: sysdev: fix compile warning " Wang Wenhu 2020-04-16 7:41 ` [PATCH v3,4/4] drivers: uio: new driver " Wang Wenhu 3 siblings, 0 replies; 46+ messages in thread From: Wang Wenhu @ 2020-04-16 7:41 UTC (permalink / raw) To: gregkh, linux-kernel, oss, christophe.leroy, linuxppc-dev Cc: kernel, Wang Wenhu, Michael Ellerman Include linux/io.h into fsl_85xx_cache_sram.c to fix the implicit-declaration compile error when building Cache-Sram. arch/powerpc/sysdev/fsl_85xx_cache_sram.c: In function ‘instantiate_cache_sram’: arch/powerpc/sysdev/fsl_85xx_cache_sram.c:97:26: error: implicit declaration of function ‘ioremap_coherent’; did you mean ‘bitmap_complement’? [-Werror=implicit-function-declaration] cache_sram->base_virt = ioremap_coherent(cache_sram->base_phys, ^~~~~~~~~~~~~~~~ bitmap_complement arch/powerpc/sysdev/fsl_85xx_cache_sram.c:97:24: error: assignment makes pointer from integer without a cast [-Werror=int-conversion] cache_sram->base_virt = ioremap_coherent(cache_sram->base_phys, ^ arch/powerpc/sysdev/fsl_85xx_cache_sram.c:123:2: error: implicit declaration of function ‘iounmap’; did you mean ‘roundup’? [-Werror=implicit-function-declaration] iounmap(cache_sram->base_virt); ^~~~~~~ roundup cc1: all warnings being treated as errors Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Christophe Leroy <christophe.leroy@c-s.fr> Cc: Scott Wood <oss@buserror.net> Cc: Michael Ellerman <mpe@ellerman.id.au> Cc: linuxppc-dev@lists.ozlabs.org Fixes: 6db92cc9d07d ("powerpc/85xx: add cache-sram support") Signed-off-by: WANG Wenhu <wenhu.wang@vivo.com> --- Changes since v1: * None Changes since v2: * None --- arch/powerpc/sysdev/fsl_85xx_cache_sram.c | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/powerpc/sysdev/fsl_85xx_cache_sram.c b/arch/powerpc/sysdev/fsl_85xx_cache_sram.c index f6c665dac725..be3aef4229d7 100644 --- a/arch/powerpc/sysdev/fsl_85xx_cache_sram.c +++ b/arch/powerpc/sysdev/fsl_85xx_cache_sram.c @@ -17,6 +17,7 @@ #include <linux/of_platform.h> #include <asm/pgtable.h> #include <asm/fsl_85xx_cache_sram.h> +#include <linux/io.h> #include "fsl_85xx_cache_ctlr.h" -- 2.17.1 ^ permalink raw reply related [flat|nested] 46+ messages in thread
* [PATCH v3,3/4] powerpc: sysdev: fix compile warning for fsl_85xx_cache_sram 2020-04-16 7:41 ` [PATCH v3,0/4] drivers: uio: new driver uio_fsl_85xx_cache_sram Wang Wenhu 2020-04-16 7:41 ` [PATCH v3,1/4] powerpc: sysdev: fix compile error for fsl_85xx_l2ctlr Wang Wenhu 2020-04-16 7:41 ` [PATCH v3,2/4] powerpc: sysdev: fix compile error for fsl_85xx_cache_sram Wang Wenhu @ 2020-04-16 7:41 ` Wang Wenhu 2020-04-16 7:41 ` [PATCH v3,4/4] drivers: uio: new driver " Wang Wenhu 3 siblings, 0 replies; 46+ messages in thread From: Wang Wenhu @ 2020-04-16 7:41 UTC (permalink / raw) To: gregkh, linux-kernel, oss, christophe.leroy, linuxppc-dev Cc: kernel, Wang Wenhu, Michael Ellerman Function instantiate_cache_sram should not be linked into the init section for its caller mpc85xx_l2ctlr_of_probe is none-__init. Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Christophe Leroy <christophe.leroy@c-s.fr> Cc: Scott Wood <oss@buserror.net> Cc: Michael Ellerman <mpe@ellerman.id.au> Cc: linuxppc-dev@lists.ozlabs.org Fixes: 6db92cc9d07d ("powerpc/85xx: add cache-sram support") Signed-off-by: Wang Wenhu <wenhu.wang@vivo.com> Warning information: MODPOST vmlinux.o WARNING: modpost: vmlinux.o(.text+0x1e540): Section mismatch in reference from the function mpc85xx_l2ctlr_of_probe() to the function .init.text:instantiate_cache_sram() The function mpc85xx_l2ctlr_of_probe() references the function __init instantiate_cache_sram(). This is often because mpc85xx_l2ctlr_of_probe lacks a __init annotation or the annotation of instantiate_cache_sram is wrong. --- Changes since v1: * None Changes since v2: * None --- arch/powerpc/sysdev/fsl_85xx_cache_sram.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/powerpc/sysdev/fsl_85xx_cache_sram.c b/arch/powerpc/sysdev/fsl_85xx_cache_sram.c index be3aef4229d7..3de5ac8382c0 100644 --- a/arch/powerpc/sysdev/fsl_85xx_cache_sram.c +++ b/arch/powerpc/sysdev/fsl_85xx_cache_sram.c @@ -68,7 +68,7 @@ void mpc85xx_cache_sram_free(void *ptr) } EXPORT_SYMBOL(mpc85xx_cache_sram_free); -int __init instantiate_cache_sram(struct platform_device *dev, +int instantiate_cache_sram(struct platform_device *dev, struct sram_parameters sram_params) { int ret = 0; -- 2.17.1 ^ permalink raw reply related [flat|nested] 46+ messages in thread
* [PATCH v3,4/4] drivers: uio: new driver for fsl_85xx_cache_sram 2020-04-16 7:41 ` [PATCH v3,0/4] drivers: uio: new driver uio_fsl_85xx_cache_sram Wang Wenhu ` (2 preceding siblings ...) 2020-04-16 7:41 ` [PATCH v3,3/4] powerpc: sysdev: fix compile warning " Wang Wenhu @ 2020-04-16 7:41 ` Wang Wenhu 3 siblings, 0 replies; 46+ messages in thread From: Wang Wenhu @ 2020-04-16 7:41 UTC (permalink / raw) To: gregkh, linux-kernel, oss, christophe.leroy, linuxppc-dev Cc: kernel, Wang Wenhu, Michael Ellerman A driver for freescale 85xx platforms to access the Cache-Sram form user level. This is extremely helpful for some user-space applications that require high performance memory accesses. Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Christophe Leroy <christophe.leroy@c-s.fr> Cc: Scott Wood <oss@buserror.net> Cc: Michael Ellerman <mpe@ellerman.id.au> Cc: linuxppc-dev@lists.ozlabs.org Signed-off-by: Wang Wenhu <wenhu.wang@vivo.com> --- Changes since v1: * Addressed comments from Greg K-H * Moved kfree(info->name) into uio_info_free_internal() Changes since v2: * Addressed comments from Greg, Scott and Christophe * Use "uiomem->internal_addr" as if condition for sram memory free, and memset the uiomem entry * Modified of_match_table make the driver apart from Cache-Sram HW info which belong to the HW level driver fsl_85xx_cache_sram to match * Use roundup_pow_of_two for align calculation * Remove useless clear block of uiomem entries. * Use UIO_INFO_VER micro for info->version, and define it as "devicetree,pseudo", meaning this is pseudo device and probed from device tree configuration * Select FSL_85XX_CACHE_SRAM rather than depends on it --- drivers/uio/Kconfig | 9 ++ drivers/uio/Makefile | 1 + drivers/uio/uio_fsl_85xx_cache_sram.c | 158 ++++++++++++++++++++++++++ 3 files changed, 168 insertions(+) create mode 100644 drivers/uio/uio_fsl_85xx_cache_sram.c diff --git a/drivers/uio/Kconfig b/drivers/uio/Kconfig index 202ee81cfc2b..9c3b47461b71 100644 --- a/drivers/uio/Kconfig +++ b/drivers/uio/Kconfig @@ -105,6 +105,15 @@ config UIO_NETX To compile this driver as a module, choose M here; the module will be called uio_netx. +config UIO_FSL_85XX_CACHE_SRAM + tristate "Freescale 85xx Cache-Sram driver" + depends on FSL_SOC_BOOKE && PPC32 + select FSL_85XX_CACHE_SRAM + help + Generic driver for accessing the Cache-Sram form user level. This + is extremely helpful for some user-space applications that require + high performance memory accesses. + config UIO_FSL_ELBC_GPCM tristate "eLBC/GPCM driver" depends on FSL_LBC diff --git a/drivers/uio/Makefile b/drivers/uio/Makefile index c285dd2a4539..be2056cffc21 100644 --- a/drivers/uio/Makefile +++ b/drivers/uio/Makefile @@ -10,4 +10,5 @@ obj-$(CONFIG_UIO_NETX) += uio_netx.o obj-$(CONFIG_UIO_PRUSS) += uio_pruss.o obj-$(CONFIG_UIO_MF624) += uio_mf624.o obj-$(CONFIG_UIO_FSL_ELBC_GPCM) += uio_fsl_elbc_gpcm.o +obj-$(CONFIG_UIO_FSL_85XX_CACHE_SRAM) += uio_fsl_85xx_cache_sram.o obj-$(CONFIG_UIO_HV_GENERIC) += uio_hv_generic.o diff --git a/drivers/uio/uio_fsl_85xx_cache_sram.c b/drivers/uio/uio_fsl_85xx_cache_sram.c new file mode 100644 index 000000000000..8701df695307 --- /dev/null +++ b/drivers/uio/uio_fsl_85xx_cache_sram.c @@ -0,0 +1,158 @@ +// SPDX-License-Identifier: GPL-2.0 +/* + * Copyright (C) 2020 Vivo Communication Technology Co. Ltd. + * Copyright (C) 2020 Wang Wenhu <wenhu.wang@vivo.com> + * All rights reserved. + */ + +#include <linux/platform_device.h> +#include <linux/uio_driver.h> +#include <linux/stringify.h> +#include <linux/module.h> +#include <linux/kernel.h> +#include <asm/fsl_85xx_cache_sram.h> + +#define DRIVER_NAME "uio_fsl_85xx_cache_sram" +#define UIO_INFO_VER "devicetree,pseudo" +#define UIO_NAME "uio_cache_sram" + +static void uio_info_free_internal(struct uio_info *info) +{ + struct uio_mem *uiomem = info->mem; + + while (uiomem < &info->mem[MAX_UIO_MAPS]) { + if (uiomem->internal_addr) { + mpc85xx_cache_sram_free(uiomem->internal_addr); + kfree(uiomem->name); + memset(uiomem, 0, sizeof(*uiomem)); + } + uiomem++; + } + + kfree(info->name); +} + +static int uio_fsl_85xx_cache_sram_probe(struct platform_device *pdev) +{ + struct device_node *parent = pdev->dev.of_node; + struct device_node *node = NULL; + struct uio_info *info; + struct uio_mem *uiomem; + const char *dt_name; + u32 mem_size; + int ret; + + /* alloc uio_info for one device */ + info = kzalloc(sizeof(*info), GFP_KERNEL); + if (!info) + return -ENOMEM; + + /* get optional uio name */ + if (of_property_read_string(parent, "uio_name", &dt_name)) + dt_name = UIO_NAME; + + info->name = kstrdup(dt_name, GFP_KERNEL); + if (!info->name) { + ret = -ENOMEM; + goto err_info_free; + } + + uiomem = info->mem; + for_each_child_of_node(parent, node) { + void *virt; + phys_addr_t phys; + + ret = of_property_read_u32(node, "cache-mem-size", &mem_size); + if (ret) { + ret = -EINVAL; + goto err_info_free_internal; + } + + if (mem_size == 0) { + dev_err(&pdev->dev, "cache-mem-size should not be 0\n"); + ret = -EINVAL; + goto err_info_free_internal; + } + + virt = mpc85xx_cache_sram_alloc(mem_size, + &phys, + roundup_pow_of_two(mem_size)); + if (!virt) { + /* mpc85xx_cache_sram_alloc to define the real cause */ + ret = -ENOMEM; + goto err_info_free_internal; + } + + uiomem->memtype = UIO_MEM_PHYS; + uiomem->addr = phys; + uiomem->size = mem_size; + uiomem->name = kstrdup(node->name, GFP_KERNEL);; + uiomem->internal_addr = virt; + uiomem++; + + if (uiomem >= &info->mem[MAX_UIO_MAPS]) { + dev_warn(&pdev->dev, "more than %d uio-maps for device.\n", + MAX_UIO_MAPS); + break; + } + } + + if (uiomem == info->mem) { + dev_err(&pdev->dev, "error no valid uio-map configured\n"); + ret = -EINVAL; + goto err_info_free_internal; + } + + info->version = UIO_INFO_VER; + + /* register uio device */ + if (uio_register_device(&pdev->dev, info)) { + dev_err(&pdev->dev, "uio registration failed\n"); + ret = -ENODEV; + goto err_info_free_internal; + } + + platform_set_drvdata(pdev, info); + + return 0; +err_info_free_internal: + uio_info_free_internal(info); +err_info_free: + kfree(info); + return ret; +} + +static int uio_fsl_85xx_cache_sram_remove(struct platform_device *pdev) +{ + struct uio_info *info = platform_get_drvdata(pdev); + + uio_unregister_device(info); + + uio_info_free_internal(info); + + kfree(info); + + return 0; +} + +static const struct of_device_id uio_mpc85xx_l2ctlr_of_match[] = { + { .compatible = "uio,mpc85xx-cache-sram", }, + {}, +}; + +static struct platform_driver uio_fsl_85xx_cache_sram = { + .probe = uio_fsl_85xx_cache_sram_probe, + .remove = uio_fsl_85xx_cache_sram_remove, + .driver = { + .name = DRIVER_NAME, + .owner = THIS_MODULE, + .of_match_table = uio_mpc85xx_l2ctlr_of_match, + }, +}; + +module_platform_driver(uio_fsl_85xx_cache_sram); + +MODULE_AUTHOR("Wang Wenhu <wenhu.wang@vivo.com>"); +MODULE_DESCRIPTION("Freescale MPC85xx Cache-Sram UIO Platform Driver"); +MODULE_ALIAS("platform:" DRIVER_NAME); +MODULE_LICENSE("GPL v2"); -- 2.17.1 ^ permalink raw reply related [flat|nested] 46+ messages in thread
* [PATCH v3,0/4] drivers: uio: new driver uio_fsl_85xx_cache_sram 2020-04-15 15:24 ` [PATCH v2,0/5] drivers: uio: new driver uio_fsl_85xx_cache_sram Wang Wenhu ` (6 preceding siblings ...) 2020-04-16 7:41 ` [PATCH v3,0/4] drivers: uio: new driver uio_fsl_85xx_cache_sram Wang Wenhu @ 2020-04-16 7:49 ` Wang Wenhu 2020-04-16 7:49 ` [PATCH v3,1/4] powerpc: sysdev: fix compile error for fsl_85xx_l2ctlr Wang Wenhu ` (4 more replies) 7 siblings, 5 replies; 46+ messages in thread From: Wang Wenhu @ 2020-04-16 7:49 UTC (permalink / raw) To: gregkh, linux-kernel, oss, christophe.leroy, linuxppc-dev Cc: kernel, Wang Wenhu This series add a new uio driver for freescale 85xx platforms to access the Cache-Sram form user level. This is extremely helpful for the user-space applications that require high performance memory accesses. It fixes the compile errors and warning of the hardware level drivers and implements the uio driver in uio_fsl_85xx_cache_sram.c. Changes since v1: * Addressed comments from Greg K-H * Moved kfree(info->name) into uio_info_free_internal() Changes since v2: * Drop the patch that modifies Kconfigs of arch/powerpc/platforms and modified the sequence of patches: 01:dropped, 02->03, 03->02, 04->01, 05->04 * Addressed comments from Greg, Scott and Christophe * Use "uiomem->internal_addr" as if condition for sram memory free, and memset the uiomem entry * Modified of_match_table make the driver apart from Cache-Sram HW info which belong to the HW level driver fsl_85xx_cache_sram to match * Use roundup_pow_of_two for align calc(really learned a lot from Christophe) * Remove useless clear block of uiomem entries. * Use UIO_INFO_VER micro for info->version, and define it as "devicetree,pseudo", meaning this is pseudo device and probed from device tree configuration * Select FSL_85XX_CACHE_SRAM rather than depends on it Wang Wenhu (4): powerpc: sysdev: fix compile error for fsl_85xx_l2ctlr powerpc: sysdev: fix compile error for fsl_85xx_cache_sram powerpc: sysdev: fix compile warning for fsl_85xx_cache_sram drivers: uio: new driver for fsl_85xx_cache_sram arch/powerpc/sysdev/fsl_85xx_cache_sram.c | 3 +- arch/powerpc/sysdev/fsl_85xx_l2ctlr.c | 1 + drivers/uio/Kconfig | 9 ++ drivers/uio/Makefile | 1 + drivers/uio/uio_fsl_85xx_cache_sram.c | 158 ++++++++++++++++++++++ 5 files changed, 171 insertions(+), 1 deletion(-) create mode 100644 drivers/uio/uio_fsl_85xx_cache_sram.c -- 2.17.1 ^ permalink raw reply [flat|nested] 46+ messages in thread
* [PATCH v3,1/4] powerpc: sysdev: fix compile error for fsl_85xx_l2ctlr 2020-04-16 7:49 ` [PATCH v3,0/4] drivers: uio: new driver uio_fsl_85xx_cache_sram Wang Wenhu @ 2020-04-16 7:49 ` Wang Wenhu 2020-04-16 7:49 ` [PATCH v3,2/4] powerpc: sysdev: fix compile error for fsl_85xx_cache_sram Wang Wenhu ` (3 subsequent siblings) 4 siblings, 0 replies; 46+ messages in thread From: Wang Wenhu @ 2020-04-16 7:49 UTC (permalink / raw) To: gregkh, linux-kernel, oss, christophe.leroy, linuxppc-dev Cc: kernel, Wang Wenhu, Michael Ellerman Include "linux/of_address.h" to fix the compile error for mpc85xx_l2ctlr_of_probe() when compiling fsl_85xx_cache_sram.c. CC arch/powerpc/sysdev/fsl_85xx_l2ctlr.o arch/powerpc/sysdev/fsl_85xx_l2ctlr.c: In function ‘mpc85xx_l2ctlr_of_probe’: arch/powerpc/sysdev/fsl_85xx_l2ctlr.c:90:11: error: implicit declaration of function ‘of_iomap’; did you mean ‘pci_iomap’? [-Werror=implicit-function-declaration] l2ctlr = of_iomap(dev->dev.of_node, 0); ^~~~~~~~ pci_iomap arch/powerpc/sysdev/fsl_85xx_l2ctlr.c:90:9: error: assignment makes pointer from integer without a cast [-Werror=int-conversion] l2ctlr = of_iomap(dev->dev.of_node, 0); ^ cc1: all warnings being treated as errors scripts/Makefile.build:267: recipe for target 'arch/powerpc/sysdev/fsl_85xx_l2ctlr.o' failed make[2]: *** [arch/powerpc/sysdev/fsl_85xx_l2ctlr.o] Error 1 Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Christophe Leroy <christophe.leroy@c-s.fr> Cc: Scott Wood <oss@buserror.net> Cc: Michael Ellerman <mpe@ellerman.id.au> Cc: linuxppc-dev@lists.ozlabs.org Fixes: 6db92cc9d07d ("powerpc/85xx: add cache-sram support") Signed-off-by: Wang Wenhu <wenhu.wang@vivo.com> --- Changes since v1: * None Changes since v2: * None --- arch/powerpc/sysdev/fsl_85xx_l2ctlr.c | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/powerpc/sysdev/fsl_85xx_l2ctlr.c b/arch/powerpc/sysdev/fsl_85xx_l2ctlr.c index 2d0af0c517bb..7533572492f0 100644 --- a/arch/powerpc/sysdev/fsl_85xx_l2ctlr.c +++ b/arch/powerpc/sysdev/fsl_85xx_l2ctlr.c @@ -10,6 +10,7 @@ #include <linux/kernel.h> #include <linux/module.h> #include <linux/of_platform.h> +#include <linux/of_address.h> #include <asm/io.h> #include "fsl_85xx_cache_ctlr.h" -- 2.17.1 ^ permalink raw reply related [flat|nested] 46+ messages in thread
* [PATCH v3,2/4] powerpc: sysdev: fix compile error for fsl_85xx_cache_sram 2020-04-16 7:49 ` [PATCH v3,0/4] drivers: uio: new driver uio_fsl_85xx_cache_sram Wang Wenhu 2020-04-16 7:49 ` [PATCH v3,1/4] powerpc: sysdev: fix compile error for fsl_85xx_l2ctlr Wang Wenhu @ 2020-04-16 7:49 ` Wang Wenhu 2020-04-16 7:49 ` [PATCH v3,3/4] powerpc: sysdev: fix compile warning " Wang Wenhu ` (2 subsequent siblings) 4 siblings, 0 replies; 46+ messages in thread From: Wang Wenhu @ 2020-04-16 7:49 UTC (permalink / raw) To: gregkh, linux-kernel, oss, christophe.leroy, linuxppc-dev Cc: kernel, Wang Wenhu, Michael Ellerman Include linux/io.h into fsl_85xx_cache_sram.c to fix the implicit-declaration compile error when building Cache-Sram. arch/powerpc/sysdev/fsl_85xx_cache_sram.c: In function ‘instantiate_cache_sram’: arch/powerpc/sysdev/fsl_85xx_cache_sram.c:97:26: error: implicit declaration of function ‘ioremap_coherent’; did you mean ‘bitmap_complement’? [-Werror=implicit-function-declaration] cache_sram->base_virt = ioremap_coherent(cache_sram->base_phys, ^~~~~~~~~~~~~~~~ bitmap_complement arch/powerpc/sysdev/fsl_85xx_cache_sram.c:97:24: error: assignment makes pointer from integer without a cast [-Werror=int-conversion] cache_sram->base_virt = ioremap_coherent(cache_sram->base_phys, ^ arch/powerpc/sysdev/fsl_85xx_cache_sram.c:123:2: error: implicit declaration of function ‘iounmap’; did you mean ‘roundup’? [-Werror=implicit-function-declaration] iounmap(cache_sram->base_virt); ^~~~~~~ roundup cc1: all warnings being treated as errors Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Christophe Leroy <christophe.leroy@c-s.fr> Cc: Scott Wood <oss@buserror.net> Cc: Michael Ellerman <mpe@ellerman.id.au> Cc: linuxppc-dev@lists.ozlabs.org Fixes: 6db92cc9d07d ("powerpc/85xx: add cache-sram support") Signed-off-by: WANG Wenhu <wenhu.wang@vivo.com> --- Changes since v1: * None Changes since v2: * None --- arch/powerpc/sysdev/fsl_85xx_cache_sram.c | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/powerpc/sysdev/fsl_85xx_cache_sram.c b/arch/powerpc/sysdev/fsl_85xx_cache_sram.c index f6c665dac725..be3aef4229d7 100644 --- a/arch/powerpc/sysdev/fsl_85xx_cache_sram.c +++ b/arch/powerpc/sysdev/fsl_85xx_cache_sram.c @@ -17,6 +17,7 @@ #include <linux/of_platform.h> #include <asm/pgtable.h> #include <asm/fsl_85xx_cache_sram.h> +#include <linux/io.h> #include "fsl_85xx_cache_ctlr.h" -- 2.17.1 ^ permalink raw reply related [flat|nested] 46+ messages in thread
* [PATCH v3,3/4] powerpc: sysdev: fix compile warning for fsl_85xx_cache_sram 2020-04-16 7:49 ` [PATCH v3,0/4] drivers: uio: new driver uio_fsl_85xx_cache_sram Wang Wenhu 2020-04-16 7:49 ` [PATCH v3,1/4] powerpc: sysdev: fix compile error for fsl_85xx_l2ctlr Wang Wenhu 2020-04-16 7:49 ` [PATCH v3,2/4] powerpc: sysdev: fix compile error for fsl_85xx_cache_sram Wang Wenhu @ 2020-04-16 7:49 ` Wang Wenhu 2020-04-16 7:49 ` [PATCH v3,4/4] drivers: uio: new driver " Wang Wenhu 2020-04-16 9:29 ` Re:[PATCH v3,0/4] drivers: uio: new driver uio_fsl_85xx_cache_sram 王文虎 4 siblings, 0 replies; 46+ messages in thread From: Wang Wenhu @ 2020-04-16 7:49 UTC (permalink / raw) To: gregkh, linux-kernel, oss, christophe.leroy, linuxppc-dev Cc: kernel, Wang Wenhu, Michael Ellerman Function instantiate_cache_sram should not be linked into the init section for its caller mpc85xx_l2ctlr_of_probe is none-__init. Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Christophe Leroy <christophe.leroy@c-s.fr> Cc: Scott Wood <oss@buserror.net> Cc: Michael Ellerman <mpe@ellerman.id.au> Cc: linuxppc-dev@lists.ozlabs.org Fixes: 6db92cc9d07d ("powerpc/85xx: add cache-sram support") Signed-off-by: Wang Wenhu <wenhu.wang@vivo.com> Warning information: MODPOST vmlinux.o WARNING: modpost: vmlinux.o(.text+0x1e540): Section mismatch in reference from the function mpc85xx_l2ctlr_of_probe() to the function .init.text:instantiate_cache_sram() The function mpc85xx_l2ctlr_of_probe() references the function __init instantiate_cache_sram(). This is often because mpc85xx_l2ctlr_of_probe lacks a __init annotation or the annotation of instantiate_cache_sram is wrong. --- Changes since v1: * None Changes since v2: * None --- arch/powerpc/sysdev/fsl_85xx_cache_sram.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/powerpc/sysdev/fsl_85xx_cache_sram.c b/arch/powerpc/sysdev/fsl_85xx_cache_sram.c index be3aef4229d7..3de5ac8382c0 100644 --- a/arch/powerpc/sysdev/fsl_85xx_cache_sram.c +++ b/arch/powerpc/sysdev/fsl_85xx_cache_sram.c @@ -68,7 +68,7 @@ void mpc85xx_cache_sram_free(void *ptr) } EXPORT_SYMBOL(mpc85xx_cache_sram_free); -int __init instantiate_cache_sram(struct platform_device *dev, +int instantiate_cache_sram(struct platform_device *dev, struct sram_parameters sram_params) { int ret = 0; -- 2.17.1 ^ permalink raw reply related [flat|nested] 46+ messages in thread
* [PATCH v3,4/4] drivers: uio: new driver for fsl_85xx_cache_sram 2020-04-16 7:49 ` [PATCH v3,0/4] drivers: uio: new driver uio_fsl_85xx_cache_sram Wang Wenhu ` (2 preceding siblings ...) 2020-04-16 7:49 ` [PATCH v3,3/4] powerpc: sysdev: fix compile warning " Wang Wenhu @ 2020-04-16 7:49 ` Wang Wenhu 2020-04-16 9:29 ` Re:[PATCH v3,0/4] drivers: uio: new driver uio_fsl_85xx_cache_sram 王文虎 4 siblings, 0 replies; 46+ messages in thread From: Wang Wenhu @ 2020-04-16 7:49 UTC (permalink / raw) To: gregkh, linux-kernel, oss, christophe.leroy, linuxppc-dev Cc: kernel, Wang Wenhu, Michael Ellerman A driver for freescale 85xx platforms to access the Cache-Sram form user level. This is extremely helpful for some user-space applications that require high performance memory accesses. Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Christophe Leroy <christophe.leroy@c-s.fr> Cc: Scott Wood <oss@buserror.net> Cc: Michael Ellerman <mpe@ellerman.id.au> Cc: linuxppc-dev@lists.ozlabs.org Signed-off-by: Wang Wenhu <wenhu.wang@vivo.com> --- Changes since v1: * Addressed comments from Greg K-H * Moved kfree(info->name) into uio_info_free_internal() Changes since v2: * Addressed comments from Greg, Scott and Christophe * Use "uiomem->internal_addr" as if condition for sram memory free, and memset the uiomem entry * Modified of_match_table make the driver apart from Cache-Sram HW info which belong to the HW level driver fsl_85xx_cache_sram to match * Use roundup_pow_of_two for align calculation * Remove useless clear block of uiomem entries. * Use UIO_INFO_VER micro for info->version, and define it as "devicetree,pseudo", meaning this is pseudo device and probed from device tree configuration * Select FSL_85XX_CACHE_SRAM rather than depends on it --- drivers/uio/Kconfig | 9 ++ drivers/uio/Makefile | 1 + drivers/uio/uio_fsl_85xx_cache_sram.c | 158 ++++++++++++++++++++++++++ 3 files changed, 168 insertions(+) create mode 100644 drivers/uio/uio_fsl_85xx_cache_sram.c diff --git a/drivers/uio/Kconfig b/drivers/uio/Kconfig index 202ee81cfc2b..9c3b47461b71 100644 --- a/drivers/uio/Kconfig +++ b/drivers/uio/Kconfig @@ -105,6 +105,15 @@ config UIO_NETX To compile this driver as a module, choose M here; the module will be called uio_netx. +config UIO_FSL_85XX_CACHE_SRAM + tristate "Freescale 85xx Cache-Sram driver" + depends on FSL_SOC_BOOKE && PPC32 + select FSL_85XX_CACHE_SRAM + help + Generic driver for accessing the Cache-Sram form user level. This + is extremely helpful for some user-space applications that require + high performance memory accesses. + config UIO_FSL_ELBC_GPCM tristate "eLBC/GPCM driver" depends on FSL_LBC diff --git a/drivers/uio/Makefile b/drivers/uio/Makefile index c285dd2a4539..be2056cffc21 100644 --- a/drivers/uio/Makefile +++ b/drivers/uio/Makefile @@ -10,4 +10,5 @@ obj-$(CONFIG_UIO_NETX) += uio_netx.o obj-$(CONFIG_UIO_PRUSS) += uio_pruss.o obj-$(CONFIG_UIO_MF624) += uio_mf624.o obj-$(CONFIG_UIO_FSL_ELBC_GPCM) += uio_fsl_elbc_gpcm.o +obj-$(CONFIG_UIO_FSL_85XX_CACHE_SRAM) += uio_fsl_85xx_cache_sram.o obj-$(CONFIG_UIO_HV_GENERIC) += uio_hv_generic.o diff --git a/drivers/uio/uio_fsl_85xx_cache_sram.c b/drivers/uio/uio_fsl_85xx_cache_sram.c new file mode 100644 index 000000000000..8701df695307 --- /dev/null +++ b/drivers/uio/uio_fsl_85xx_cache_sram.c @@ -0,0 +1,158 @@ +// SPDX-License-Identifier: GPL-2.0 +/* + * Copyright (C) 2020 Vivo Communication Technology Co. Ltd. + * Copyright (C) 2020 Wang Wenhu <wenhu.wang@vivo.com> + * All rights reserved. + */ + +#include <linux/platform_device.h> +#include <linux/uio_driver.h> +#include <linux/stringify.h> +#include <linux/module.h> +#include <linux/kernel.h> +#include <asm/fsl_85xx_cache_sram.h> + +#define DRIVER_NAME "uio_fsl_85xx_cache_sram" +#define UIO_INFO_VER "devicetree,pseudo" +#define UIO_NAME "uio_cache_sram" + +static void uio_info_free_internal(struct uio_info *info) +{ + struct uio_mem *uiomem = info->mem; + + while (uiomem < &info->mem[MAX_UIO_MAPS]) { + if (uiomem->internal_addr) { + mpc85xx_cache_sram_free(uiomem->internal_addr); + kfree(uiomem->name); + memset(uiomem, 0, sizeof(*uiomem)); + } + uiomem++; + } + + kfree(info->name); +} + +static int uio_fsl_85xx_cache_sram_probe(struct platform_device *pdev) +{ + struct device_node *parent = pdev->dev.of_node; + struct device_node *node = NULL; + struct uio_info *info; + struct uio_mem *uiomem; + const char *dt_name; + u32 mem_size; + int ret; + + /* alloc uio_info for one device */ + info = kzalloc(sizeof(*info), GFP_KERNEL); + if (!info) + return -ENOMEM; + + /* get optional uio name */ + if (of_property_read_string(parent, "uio_name", &dt_name)) + dt_name = UIO_NAME; + + info->name = kstrdup(dt_name, GFP_KERNEL); + if (!info->name) { + ret = -ENOMEM; + goto err_info_free; + } + + uiomem = info->mem; + for_each_child_of_node(parent, node) { + void *virt; + phys_addr_t phys; + + ret = of_property_read_u32(node, "cache-mem-size", &mem_size); + if (ret) { + ret = -EINVAL; + goto err_info_free_internal; + } + + if (mem_size == 0) { + dev_err(&pdev->dev, "cache-mem-size should not be 0\n"); + ret = -EINVAL; + goto err_info_free_internal; + } + + virt = mpc85xx_cache_sram_alloc(mem_size, + &phys, + roundup_pow_of_two(mem_size)); + if (!virt) { + /* mpc85xx_cache_sram_alloc to define the real cause */ + ret = -ENOMEM; + goto err_info_free_internal; + } + + uiomem->memtype = UIO_MEM_PHYS; + uiomem->addr = phys; + uiomem->size = mem_size; + uiomem->name = kstrdup(node->name, GFP_KERNEL);; + uiomem->internal_addr = virt; + uiomem++; + + if (uiomem >= &info->mem[MAX_UIO_MAPS]) { + dev_warn(&pdev->dev, "more than %d uio-maps for device.\n", + MAX_UIO_MAPS); + break; + } + } + + if (uiomem == info->mem) { + dev_err(&pdev->dev, "error no valid uio-map configured\n"); + ret = -EINVAL; + goto err_info_free_internal; + } + + info->version = UIO_INFO_VER; + + /* register uio device */ + if (uio_register_device(&pdev->dev, info)) { + dev_err(&pdev->dev, "uio registration failed\n"); + ret = -ENODEV; + goto err_info_free_internal; + } + + platform_set_drvdata(pdev, info); + + return 0; +err_info_free_internal: + uio_info_free_internal(info); +err_info_free: + kfree(info); + return ret; +} + +static int uio_fsl_85xx_cache_sram_remove(struct platform_device *pdev) +{ + struct uio_info *info = platform_get_drvdata(pdev); + + uio_unregister_device(info); + + uio_info_free_internal(info); + + kfree(info); + + return 0; +} + +static const struct of_device_id uio_mpc85xx_l2ctlr_of_match[] = { + { .compatible = "uio,mpc85xx-cache-sram", }, + {}, +}; + +static struct platform_driver uio_fsl_85xx_cache_sram = { + .probe = uio_fsl_85xx_cache_sram_probe, + .remove = uio_fsl_85xx_cache_sram_remove, + .driver = { + .name = DRIVER_NAME, + .owner = THIS_MODULE, + .of_match_table = uio_mpc85xx_l2ctlr_of_match, + }, +}; + +module_platform_driver(uio_fsl_85xx_cache_sram); + +MODULE_AUTHOR("Wang Wenhu <wenhu.wang@vivo.com>"); +MODULE_DESCRIPTION("Freescale MPC85xx Cache-Sram UIO Platform Driver"); +MODULE_ALIAS("platform:" DRIVER_NAME); +MODULE_LICENSE("GPL v2"); -- 2.17.1 ^ permalink raw reply related [flat|nested] 46+ messages in thread
* Re:[PATCH v3,0/4] drivers: uio: new driver uio_fsl_85xx_cache_sram 2020-04-16 7:49 ` [PATCH v3,0/4] drivers: uio: new driver uio_fsl_85xx_cache_sram Wang Wenhu ` (3 preceding siblings ...) 2020-04-16 7:49 ` [PATCH v3,4/4] drivers: uio: new driver " Wang Wenhu @ 2020-04-16 9:29 ` 王文虎 2020-04-16 10:36 ` [PATCH " Christophe Leroy 4 siblings, 1 reply; 46+ messages in thread From: 王文虎 @ 2020-04-16 9:29 UTC (permalink / raw) To: Wang Wenhu Cc: gregkh, linux-kernel, oss, christophe.leroy, linuxppc-dev, kernel Hi, Seems there is something wrong with the server that multiple dumplications of the v3 patches were sent out, please ignore the rest and take this newest series as formal count. Thanks, Wenhu From: Wang Wenhu <wenhu.wang@vivo.com> Date: 2020-04-16 15:49:14 To: gregkh@linuxfoundation.org,linux-kernel@vger.kernel.org,oss@buserror.net,christophe.leroy@c-s.fr,linuxppc-dev@lists.ozlabs.org Cc: kernel@vivo.com,Wang Wenhu <wenhu.wang@vivo.com> Subject: [PATCH v3,0/4] drivers: uio: new driver uio_fsl_85xx_cache_sram>This series add a new uio driver for freescale 85xx platforms to >access the Cache-Sram form user level. This is extremely helpful >for the user-space applications that require high performance memory >accesses. > >It fixes the compile errors and warning of the hardware level drivers >and implements the uio driver in uio_fsl_85xx_cache_sram.c. > >Changes since v1: > * Addressed comments from Greg K-H > * Moved kfree(info->name) into uio_info_free_internal() > >Changes since v2: > * Drop the patch that modifies Kconfigs of arch/powerpc/platforms > and modified the sequence of patches: > 01:dropped, 02->03, 03->02, 04->01, 05->04 > * Addressed comments from Greg, Scott and Christophe > * Use "uiomem->internal_addr" as if condition for sram memory free, > and memset the uiomem entry > * Modified of_match_table make the driver apart from Cache-Sram HW info > which belong to the HW level driver fsl_85xx_cache_sram to match > * Use roundup_pow_of_two for align calc(really learned a lot from Christophe) > * Remove useless clear block of uiomem entries. > * Use UIO_INFO_VER micro for info->version, and define it as > "devicetree,pseudo", meaning this is pseudo device and probed from > device tree configuration > * Select FSL_85XX_CACHE_SRAM rather than depends on it > >Wang Wenhu (4): > powerpc: sysdev: fix compile error for fsl_85xx_l2ctlr > powerpc: sysdev: fix compile error for fsl_85xx_cache_sram > powerpc: sysdev: fix compile warning for fsl_85xx_cache_sram > drivers: uio: new driver for fsl_85xx_cache_sram > > arch/powerpc/sysdev/fsl_85xx_cache_sram.c | 3 +- > arch/powerpc/sysdev/fsl_85xx_l2ctlr.c | 1 + > drivers/uio/Kconfig | 9 ++ > drivers/uio/Makefile | 1 + > drivers/uio/uio_fsl_85xx_cache_sram.c | 158 ++++++++++++++++++++++ > 5 files changed, 171 insertions(+), 1 deletion(-) > create mode 100644 drivers/uio/uio_fsl_85xx_cache_sram.c > >-- >2.17.1 > ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [PATCH v3,0/4] drivers: uio: new driver uio_fsl_85xx_cache_sram 2020-04-16 9:29 ` Re:[PATCH v3,0/4] drivers: uio: new driver uio_fsl_85xx_cache_sram 王文虎 @ 2020-04-16 10:36 ` Christophe Leroy 2020-04-16 11:14 ` 王文虎 0 siblings, 1 reply; 46+ messages in thread From: Christophe Leroy @ 2020-04-16 10:36 UTC (permalink / raw) To: 王文虎; +Cc: gregkh, linux-kernel, oss, linuxppc-dev, kernel Le 16/04/2020 à 11:29, 王文虎 a écrit : > Hi, > Seems there is something wrong with the server that multiple dumplications > of the v3 patches were sent out, please ignore the rest and take this newest > series as formal count. Which series ? It seems you sent 3 times, at 9:29, 9:41 and 9:49 (Paris Time) From the series of 9:29, I received patches 0 to 3 From the series of 9:41, I received patches 0 to 3 From the series of 9:49, I received patches 0 and 4. Looks like powerpc patchwork (https://patchwork.ozlabs.org/project/linuxppc-dev/list/?submitter=78320) got: From the series of 9:29, I received patches 0 to 4 From the series of 9:41, I received patches 1 to 4 From the series of 9:49, I received patches 1 to 4 So this seems to be something wrong somewhere. Christophe > > Thanks, > Wenhu > > From: Wang Wenhu <wenhu.wang@vivo.com> > Date: 2020-04-16 15:49:14 > To: gregkh@linuxfoundation.org,linux-kernel@vger.kernel.org,oss@buserror.net,christophe.leroy@c-s.fr,linuxppc-dev@lists.ozlabs.org > Cc: kernel@vivo.com,Wang Wenhu <wenhu.wang@vivo.com> > Subject: [PATCH v3,0/4] drivers: uio: new driver uio_fsl_85xx_cache_sram>This series add a new uio driver for freescale 85xx platforms to >> access the Cache-Sram form user level. This is extremely helpful >> for the user-space applications that require high performance memory >> accesses. >> >> It fixes the compile errors and warning of the hardware level drivers >> and implements the uio driver in uio_fsl_85xx_cache_sram.c. >> >> Changes since v1: >> * Addressed comments from Greg K-H >> * Moved kfree(info->name) into uio_info_free_internal() >> >> Changes since v2: >> * Drop the patch that modifies Kconfigs of arch/powerpc/platforms >> and modified the sequence of patches: >> 01:dropped, 02->03, 03->02, 04->01, 05->04 >> * Addressed comments from Greg, Scott and Christophe >> * Use "uiomem->internal_addr" as if condition for sram memory free, >> and memset the uiomem entry >> * Modified of_match_table make the driver apart from Cache-Sram HW info >> which belong to the HW level driver fsl_85xx_cache_sram to match >> * Use roundup_pow_of_two for align calc(really learned a lot from Christophe) >> * Remove useless clear block of uiomem entries. >> * Use UIO_INFO_VER micro for info->version, and define it as >> "devicetree,pseudo", meaning this is pseudo device and probed from >> device tree configuration >> * Select FSL_85XX_CACHE_SRAM rather than depends on it >> >> Wang Wenhu (4): >> powerpc: sysdev: fix compile error for fsl_85xx_l2ctlr >> powerpc: sysdev: fix compile error for fsl_85xx_cache_sram >> powerpc: sysdev: fix compile warning for fsl_85xx_cache_sram >> drivers: uio: new driver for fsl_85xx_cache_sram >> >> arch/powerpc/sysdev/fsl_85xx_cache_sram.c | 3 +- >> arch/powerpc/sysdev/fsl_85xx_l2ctlr.c | 1 + >> drivers/uio/Kconfig | 9 ++ >> drivers/uio/Makefile | 1 + >> drivers/uio/uio_fsl_85xx_cache_sram.c | 158 ++++++++++++++++++++++ >> 5 files changed, 171 insertions(+), 1 deletion(-) >> create mode 100644 drivers/uio/uio_fsl_85xx_cache_sram.c >> >> -- >> 2.17.1 >> > > ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [PATCH v3,0/4] drivers: uio: new driver uio_fsl_85xx_cache_sram 2020-04-16 10:36 ` [PATCH " Christophe Leroy @ 2020-04-16 11:14 ` 王文虎 0 siblings, 0 replies; 46+ messages in thread From: 王文虎 @ 2020-04-16 11:14 UTC (permalink / raw) To: Christophe Leroy; +Cc: gregkh, linux-kernel, oss, linuxppc-dev, kernel Hi, From: Christophe Leroy <christophe.leroy@c-s.fr> Date: 2020-04-16 18:36:38 To:"王文虎" <wenhu.wang@vivo.com> cc: gregkh@linuxfoundation.org,linux-kernel@vger.kernel.org,oss@buserror.net,linuxppc-dev@lists.ozlabs.org,kernel@vivo.com Subject: Re: [PATCH v3,0/4] drivers: uio: new driver uio_fsl_85xx_cache_sram> > >Le 16/04/2020 à 11:29, 王文虎 a écrit : >> Hi, >> Seems there is something wrong with the server that multiple dumplications >> of the v3 patches were sent out, please ignore the rest and take this newest >> series as formal count. > >Which series ? > >It seems you sent 3 times, at 9:29, 9:41 and 9:49 (Paris Time) > > From the series of 9:29, I received patches 0 to 3 > From the series of 9:41, I received patches 0 to 3 > From the series of 9:49, I received patches 0 and 4. > >Looks like powerpc patchwork >(https://patchwork.ozlabs.org/project/linuxppc-dev/list/?submitter=78320) >got: > From the series of 9:29, I received patches 0 to 4 > From the series of 9:41, I received patches 1 to 4 > From the series of 9:49, I received patches 1 to 4 > >So this seems to be something wrong somewhere. > >Christophe > Hi Christophe, Sorry again, and I don't know which best fit you all. I guess a RESEND tag might help. So I will send another series with RESEND tag, please just drop all this three. Hope that relly won't trouble you yelling, and hope the mail server would work well. Thanks, Wenhu >> >> From: Wang Wenhu <wenhu.wang@vivo.com> >> Date: 2020-04-16 15:49:14 >> To: gregkh@linuxfoundation.org,linux-kernel@vger.kernel.org,oss@buserror.net,christophe.leroy@c-s.fr,linuxppc-dev@lists.ozlabs.org >> Cc: kernel@vivo.com,Wang Wenhu <wenhu.wang@vivo.com> >> Subject: [PATCH v3,0/4] drivers: uio: new driver uio_fsl_85xx_cache_sram>This series add a new uio driver for freescale 85xx platforms to >>> access the Cache-Sram form user level. This is extremely helpful >>> for the user-space applications that require high performance memory >>> accesses. >>> >>> It fixes the compile errors and warning of the hardware level drivers >>> and implements the uio driver in uio_fsl_85xx_cache_sram.c. >>> >>> Changes since v1: >>> * Addressed comments from Greg K-H >>> * Moved kfree(info->name) into uio_info_free_internal() >>> >>> Changes since v2: >>> * Drop the patch that modifies Kconfigs of arch/powerpc/platforms >>> and modified the sequence of patches: >>> 01:dropped, 02->03, 03->02, 04->01, 05->04 >>> * Addressed comments from Greg, Scott and Christophe >>> * Use "uiomem->internal_addr" as if condition for sram memory free, >>> and memset the uiomem entry >>> * Modified of_match_table make the driver apart from Cache-Sram HW info >>> which belong to the HW level driver fsl_85xx_cache_sram to match >>> * Use roundup_pow_of_two for align calc(really learned a lot from Christophe) >>> * Remove useless clear block of uiomem entries. >>> * Use UIO_INFO_VER micro for info->version, and define it as >>> "devicetree,pseudo", meaning this is pseudo device and probed from >>> device tree configuration >>> * Select FSL_85XX_CACHE_SRAM rather than depends on it >>> >>> Wang Wenhu (4): >>> powerpc: sysdev: fix compile error for fsl_85xx_l2ctlr >>> powerpc: sysdev: fix compile error for fsl_85xx_cache_sram >>> powerpc: sysdev: fix compile warning for fsl_85xx_cache_sram >>> drivers: uio: new driver for fsl_85xx_cache_sram >>> >>> arch/powerpc/sysdev/fsl_85xx_cache_sram.c | 3 +- >>> arch/powerpc/sysdev/fsl_85xx_l2ctlr.c | 1 + >>> drivers/uio/Kconfig | 9 ++ >>> drivers/uio/Makefile | 1 + >>> drivers/uio/uio_fsl_85xx_cache_sram.c | 158 ++++++++++++++++++++++ >>> 5 files changed, 171 insertions(+), 1 deletion(-) >>> create mode 100644 drivers/uio/uio_fsl_85xx_cache_sram.c >>> >>> -- >>> 2.17.1 >>> >> >> ^ permalink raw reply [flat|nested] 46+ messages in thread
end of thread, other threads:[~2020-04-16 19:42 UTC | newest] Thread overview: 46+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2020-04-15 12:33 [PATCH 0/5] drivers: uio: new driver uio_fsl_85xx_cache_sram Wang Wenhu 2020-04-15 12:33 ` [PATCH 1/5] powerpc: 85xx: make FSL_85XX_CACHE_SRAM configurable Wang Wenhu 2020-04-16 0:58 ` kbuild test robot 2020-04-15 12:33 ` [PATCH 2/5] powerpc: sysdev: fix compile error for fsl_85xx_cache_sram Wang Wenhu 2020-04-15 12:33 ` [PATCH 3/5] powerpc: sysdev: fix compile warning " Wang Wenhu 2020-04-15 12:33 ` [PATCH 4/5] powerpc: sysdev: fix compile error for fsl_85xx_l2ctlr Wang Wenhu 2020-04-15 12:33 ` [PATCH 5/5] drivers: uio: new driver for fsl_85xx_cache_sram Wang Wenhu 2020-04-15 12:49 ` Greg KH 2020-04-15 14:07 ` [PATCH 5/5] drivers: uio: new driver for fsl_85xx_cache_sram>On Wed, Apr 15, 2020 at 05:33:46AM -0700, Wang Wenhu wrote: Wang Wenhu 2020-04-15 15:24 ` [PATCH v2,0/5] drivers: uio: new driver uio_fsl_85xx_cache_sram Wang Wenhu 2020-04-15 15:24 ` [PATCH v2,1/5] powerpc: 85xx: make FSL_85XX_CACHE_SRAM configurable Wang Wenhu 2020-04-15 16:26 ` Christophe Leroy 2020-04-15 16:29 ` Christophe Leroy 2020-04-15 18:53 ` Scott Wood 2020-04-16 4:11 ` Wang Wenhu 2020-04-15 15:24 ` [PATCH v2,2/5] powerpc: sysdev: fix compile error for fsl_85xx_cache_sram Wang Wenhu 2020-04-15 15:24 ` [PATCH v2,3/5] powerpc: sysdev: fix compile warning " Wang Wenhu 2020-04-15 15:24 ` [PATCH v2,4/5] powerpc: sysdev: fix compile error for fsl_85xx_l2ctlr Wang Wenhu 2020-04-15 15:24 ` [PATCH v2,5/5] drivers: uio: new driver for fsl_85xx_cache_sram Wang Wenhu 2020-04-15 16:52 ` Christophe Leroy 2020-04-15 19:27 ` Scott Wood 2020-04-16 6:30 ` Greg KH 2020-04-16 19:36 ` Scott Wood 2020-04-16 5:22 ` Wang Wenhu 2020-04-16 6:02 ` Christophe Leroy 2020-04-15 19:26 ` Scott Wood 2020-04-16 6:30 ` Greg KH 2020-04-16 19:40 ` Scott Wood 2020-04-16 7:29 ` [PATCH v3,0/4] drivers: uio: new driver uio_fsl_85xx_cache_sram Wang Wenhu 2020-04-16 7:29 ` [PATCH v3,1/4] powerpc: sysdev: fix compile error for fsl_85xx_l2ctlr Wang Wenhu 2020-04-16 7:29 ` [PATCH v3,2/4] powerpc: sysdev: fix compile error for fsl_85xx_cache_sram Wang Wenhu 2020-04-16 7:29 ` [PATCH v3,3/4] powerpc: sysdev: fix compile warning " Wang Wenhu 2020-04-16 7:29 ` [PATCH v3,4/4] drivers: uio: new driver " Wang Wenhu 2020-04-16 7:41 ` [PATCH v3,0/4] drivers: uio: new driver uio_fsl_85xx_cache_sram Wang Wenhu 2020-04-16 7:41 ` [PATCH v3,1/4] powerpc: sysdev: fix compile error for fsl_85xx_l2ctlr Wang Wenhu 2020-04-16 7:41 ` [PATCH v3,2/4] powerpc: sysdev: fix compile error for fsl_85xx_cache_sram Wang Wenhu 2020-04-16 7:41 ` [PATCH v3,3/4] powerpc: sysdev: fix compile warning " Wang Wenhu 2020-04-16 7:41 ` [PATCH v3,4/4] drivers: uio: new driver " Wang Wenhu 2020-04-16 7:49 ` [PATCH v3,0/4] drivers: uio: new driver uio_fsl_85xx_cache_sram Wang Wenhu 2020-04-16 7:49 ` [PATCH v3,1/4] powerpc: sysdev: fix compile error for fsl_85xx_l2ctlr Wang Wenhu 2020-04-16 7:49 ` [PATCH v3,2/4] powerpc: sysdev: fix compile error for fsl_85xx_cache_sram Wang Wenhu 2020-04-16 7:49 ` [PATCH v3,3/4] powerpc: sysdev: fix compile warning " Wang Wenhu 2020-04-16 7:49 ` [PATCH v3,4/4] drivers: uio: new driver " Wang Wenhu 2020-04-16 9:29 ` Re:[PATCH v3,0/4] drivers: uio: new driver uio_fsl_85xx_cache_sram 王文虎 2020-04-16 10:36 ` [PATCH " Christophe Leroy 2020-04-16 11:14 ` 王文虎
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).