msm_sharedmem.txt 3.1 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116
  1. Introduction
  2. ============
  3. This is a new platform driver for newly introduced UIO devices
  4. to facilitate clients in Userspace.
  5. Hardware description
  6. ====================
  7. This driver does not implement any specific hardware driver.
  8. Software description
  9. ====================
  10. Design
  11. ======
  12. The goal of this driver is to ensure there is no security lapse in the
  13. Userspace clients' functionality. This new driver uses the existing
  14. UIO framework to facilitate the clients to be able to memory map their
  15. respective allotted shared memory address in the client's address space.
  16. |
  17. Userspace | Kernel space
  18. +--------------+ +---------------+ +---------------+
  19. | Client | | Shared | | shrdmem_uio |
  20. | <-------> Memory <-------> driver |
  21. +--------------+ +---------------+ +---------------+
  22. |
  23. |
  24. The shared memory (a transport buffer) address is unique for each
  25. individual client and is made available to the driver via device tree.
  26. For a given client the probe would be called once in the shrdmem_uio driver.
  27. This driver would parse the device tree and register a new UIO device with kernel
  28. available under /dev/uioX (where X would start from zero, being serially
  29. incremented for the next UIO device probed)
  30. The client in Userspace would be able to access the respective UIO device
  31. under the sysfs entry(/sys/class/uio/uioX) upon verifying the name and version
  32. of the device under this sysfs node. Once verified it could access the physical
  33. address under /sys/class/uio/uioX/maps/map0/addr
  34. The client would request for memory mapping which would be taken care of in the
  35. kernel space by the UIO framework. No explicit mmap() implementation required by
  36. the shrdmem_uio driver.
  37. Power Management
  38. ================
  39. Does not implement any power management.
  40. SMP/multi-core
  41. ==============
  42. The platform driver would be loaded/probed once per client.
  43. DTS files will be looked up for shared memory addresses and sizes for all the clients.
  44. The UIO char device will be created under /dev/uioX.
  45. This being one time activity for a given client it does not require SMP/multi-core safety.
  46. Security
  47. ========
  48. The devices (/dev/uioX) would have permission checks for restricted access
  49. Performance
  50. ===========
  51. None.
  52. Interface
  53. =========
  54. This driver does not export any APIs for kernel.
  55. Android user space can access the shared memory by mmaping it.
  56. Driver parameters
  57. =================
  58. None.
  59. Config options
  60. ==============
  61. None.
  62. Dependencies
  63. ============
  64. The only dependency is the kernel device tree files for the
  65. Userspace client details.
  66. User space utilities
  67. ====================
  68. This driver communicates with the following user space clients/utilities:
  69. Remote File System:
  70. - Based on Qualcomm Messaging Interface (QMI)
  71. - This service enables the modules on the MSM modem processor to
  72. read data from and write data to the embedded multimedia card (eMMC),
  73. which is solely controlled by the applications processor.
  74. Remote File System Access (QMI_RFSA):
  75. - Based on Qualcomm Messaging Interface (QMI)
  76. - This service provides access from the Hexagon processor to a High-Level
  77. Operating Sytem (HLOS) file system
  78. Other
  79. =====
  80. None.
  81. Known issues
  82. ============
  83. None.