author | Suman Anna <s-anna@ti.com> | |
Tue, 22 Jan 2019 23:57:01 +0000 (17:57 -0600) | ||
committer | Suman Anna <s-anna@ti.com> | |
Tue, 22 Jan 2019 23:57:06 +0000 (17:57 -0600) | ||
commit | dc3a77d7591ff28324077d90bc01641deb798481 | |
tree | 0c308a44f7ae84d21f53d3d77a02e719e854963f | tree | snapshot (tar.xz tar.gz zip) |
parent | 041e7acd6aa376b2d30ef16e1e897c122569dd06 | commit | diff |
TEMP: soc: ti: add the keystone_dsp_mem driver
A very simple keystone_dsp_mem driver has been added for TI's Keystone 2
family of SoCs. This driver provides a user-space mapping interface for
some On-chip Multicore Shared Memory (MSM) SRAM Memory regions and/or
some portions of the platform board's DDR memory. This is done to enable
the Multi Proc Manager (MPM) based loader for loading different firmware
images into both DDR and On-chip SRAM in userspace for the various C66
DSP co-processors on the SoC.
The different MSM RAM regions to be exposed to userspace through this
driver need to be defined as 'reserved' child nodes under the parent
MSM RAM mmio-sram node with a specific compatible "ti,keystone-dsp-msm-ram"
property. Each of the DDR regions to be exposed should also be defined
using reserved-memory child nodes with the "no-map" property set and
using a specific compatible "ti,keystone-dsp-mpm-pool" property. Multiple
discrete regions of either SRAM and/or DDR can be exposed to userspace
by defining similar DTS nodes.
The keystone-dsp-mem driver provides sysfs entries to allow userspace
to read the address and size of supported DDR and Multicore Shared Memory
(MSM) RAM memories that are exposed to userspace. This sysfs logic provides
an agnostic way of presenting the supported memories irrespective of how
the driver acquires the memories. The 32-bit DDR alias addresses are used
while presenting the DDR regions through sysfs as per current MPM usage.
Each supported memory region is represented by its own directory, and are
created under the dspmem misc device. The directories can be accessed
under the /sys/class/misc/dspmem/ path.
The mapping interfaces are provided through a miscdevice and exposed
using the character device /dev/dspmem (matching the usage within MPM).
The mmap logic itself is based on a mechanism used within the UIO
framework.
Signed-off-by: Suman Anna <s-anna@ti.com>
A very simple keystone_dsp_mem driver has been added for TI's Keystone 2
family of SoCs. This driver provides a user-space mapping interface for
some On-chip Multicore Shared Memory (MSM) SRAM Memory regions and/or
some portions of the platform board's DDR memory. This is done to enable
the Multi Proc Manager (MPM) based loader for loading different firmware
images into both DDR and On-chip SRAM in userspace for the various C66
DSP co-processors on the SoC.
The different MSM RAM regions to be exposed to userspace through this
driver need to be defined as 'reserved' child nodes under the parent
MSM RAM mmio-sram node with a specific compatible "ti,keystone-dsp-msm-ram"
property. Each of the DDR regions to be exposed should also be defined
using reserved-memory child nodes with the "no-map" property set and
using a specific compatible "ti,keystone-dsp-mpm-pool" property. Multiple
discrete regions of either SRAM and/or DDR can be exposed to userspace
by defining similar DTS nodes.
The keystone-dsp-mem driver provides sysfs entries to allow userspace
to read the address and size of supported DDR and Multicore Shared Memory
(MSM) RAM memories that are exposed to userspace. This sysfs logic provides
an agnostic way of presenting the supported memories irrespective of how
the driver acquires the memories. The 32-bit DDR alias addresses are used
while presenting the DDR regions through sysfs as per current MPM usage.
Each supported memory region is represented by its own directory, and are
created under the dspmem misc device. The directories can be accessed
under the /sys/class/misc/dspmem/ path.
The mapping interfaces are provided through a miscdevice and exposed
using the character device /dev/dspmem (matching the usage within MPM).
The mmap logic itself is based on a mechanism used within the UIO
framework.
Signed-off-by: Suman Anna <s-anna@ti.com>
drivers/soc/ti/Kconfig | diff | blob | history | |
drivers/soc/ti/Makefile | diff | blob | history | |
drivers/soc/ti/keystone_dsp_mem.c | [new file with mode: 0644] | blob |
include/uapi/linux/keystone_dsp_mem.h | [new file with mode: 0644] | blob |