Message-Id: <20200424024554.30709-1-wenhu.wang@vivo.com>
Date:   Thu, 23 Apr 2020 19:45:49 -0700
From:   Wang Wenhu <wenhu.wang@...o.com>
To:     gregkh@...uxfoundation.org, arnd@...db.de,
        linux-kernel@...r.kernel.org, linuxppc-dev@...ts.ozlabs.org
Cc:     christophe.leroy@....fr, oss@...error.net, kernel@...o.com,
        robh@...nel.org, benh@...nel.crashing.org, paulus@...ba.org,
        Wang Wenhu <wenhu.wang@...o.com>
Subject: [PATCH v3,0/5] misc: generic user level sram dynamic access support

This series add a new misc module that act as an interface for user level
applications to access SRAM memory dynamically. Freescale 85xx Cache-SRAM
is exact an example.

This is extremely helpful for the user level applications that require
high performance memory accesses, such as some embedded networking devices
that need to process data in user space.

The series also fix the compile errors and warning of the freescale 85xx
Cache-SRAM driver, and implement a module to register the SRAM device to
sram_dynamic module, which enables its access for users in user space.

Changes since v1: addressed comments from Arnd
 * Changed the ioctl cmd definitions using _IO micros
 * Export interfaces for HW-SRAM drivers to register apis to available list
 * Modified allocation alignment to PAGE_SIZE
 * Use phys_addr_t as type of SRAM resource size and offset
 * Support compat_ioctl
 * Misc device name:sram
 * Use tristate for SRAM_UAPI
 * Use postcore_initcall

Changes since v2: addressed comments from Arnd, greg and Scott
 * Name the module with sram_dynamic in comparing with drivers/misc/sram.c

    I tried to tie the sram_dynamic with the abstractions in sram.c as
    Arnd suggested, and actually sram.c probes SRAM devices from devicetree
    and manages them with different partitions and create memory pools which
    are managed with genalloc functions.

    Here sram_dynamic acts only as a interface to user space. A SRAM memory
    pool is managed by the module that registers APIs to us, such as the
    backend hardware driver of Freescale 85xx Cache-SRAM.

 * Create one sram_device for each backend SRAM device(from Scott)
 * Allow only one block of SRAM memory allocated to a file descriptor(from Scott)
 * Add sysfs files for every allocated SRAM memory block
 * More documentations(As Greg commented)
 * Make uapi and non-uapi components apart(from Arnd and Greg)
 * Add a new module to register freescale 85xx Cache-SRAM APIs to the
   sram_dynamic module

Wang Wenhu (5):
  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
  misc: sram_dynamic for user level SRAM access
  powerpc: sysdev: support userspace access of fsl 85xx sram

 .../powerpc/include/asm/fsl_85xx_cache_sram.h |   4 +
 arch/powerpc/platforms/85xx/Kconfig           |  10 +
 arch/powerpc/sysdev/Makefile                  |   1 +
 arch/powerpc/sysdev/fsl_85xx_cache_ctlr.h     |   6 +
 arch/powerpc/sysdev/fsl_85xx_cache_sram.c     |  15 +-
 arch/powerpc/sysdev/fsl_85xx_l2ctlr.c         |   1 +
 arch/powerpc/sysdev/fsl_85xx_sram_uapi.c      |  39 ++
 drivers/misc/Kconfig                          |  11 +
 drivers/misc/Makefile                         |   1 +
 drivers/misc/sram_dynamic.c                   | 580 ++++++++++++++++++
 drivers/misc/sram_uapi.c                      | 351 +++++++++++
 include/linux/sram_dynamic.h                  |  23 +
 include/uapi/linux/sram.h                     |  11 +
 13 files changed, 1052 insertions(+), 1 deletion(-)
 create mode 100644 arch/powerpc/sysdev/fsl_85xx_sram_uapi.c
 create mode 100644 drivers/misc/sram_dynamic.c
 create mode 100644 drivers/misc/sram_uapi.c
 create mode 100644 include/linux/sram_dynamic.h
 create mode 100644 include/uapi/linux/sram.h

-- 
2.17.1

Powered by blists - more mailing lists