drivers/sandbox: Introduce a simplified remoteproc framework
Get series with b4
b4 am [email protected]Versions newest first · linked by author and title
- v3 Latest4 patches 0 repliesNew
- v24 patches 0 repliesSuperseded
- v10 of 3 patches 0 repliesSuperseded
Changes in v3 from the cover letter
- Minor comment updates from V2
- Review and tested tag picked up from V2
Patches in v3 No applies recorded yet
| # | Subject and files | Size | Replies | Applied |
|---|---|---|---|---|
| 1/4 | drivers: Introduce a simplified remoteproc frameworkcommon/ common/ common/ +9 more | +1074 | 3 replies | |
| 2/4 | remoteproc: Introduce a sandbox dummy driverdrivers/ drivers/ drivers/ | +348 | 3 replies | |
| 3/4 | sandbox: Introduce dummy remoteproc nodesarch/ configs/ | +15 | 3 replies | |
| 4/4 | test: Add basic tests for remoteproctest/ test/ | +68 | 2 replies |
Reviews trailers per patch
All 4 patches have a Reviewed-by or Acked-by.
| Patch | Simon Glass |
|---|---|
| 1/4 | R-b A-b A-b |
| 2/4 | R-b A-b A-b |
| 3/4 | R-b A-b A-b |
| 4/4 | R-b T-b A-b |
Trailers given in replies are filled; those carried in the patches from earlier versions are outlined with dashes.
Cover letter [U-Boot] [PATCH V3 0/4] drivers/sandbox: Introduce a simplified remoteproc framework
Many System on Chip(SoC) solutions are complex with multiple processors on the same die dedicated to either general purpose of specialized functions. Many examples do exist in today's SoCs from various vendors. Typical examples are micro controllers such as an ARM M3/M0 doing a offload of specific function such as event integration or power management or controlling camera etc.
Traditionally, the responsibility of loading up such a processor with a firmware and communication has been with a High Level Operating System(HLOS) such as Linux. However, there exists classes of products where Linux would need to expect services from such a processor or the delay of Linux and operating system being able to load up such a firmware is unacceptable.
The intent here is to introduce a simplified remoteproc framework which can then be used to provide basic services to these remote processors.
Special thanks to Simon in helping cleaning up the series to a much more better implementation.
The series is based on:
master fa43ce842c30 Merge git://git.denx.de/u-boot-fdt
Changes since V2:
- Minor comment updates from V2
- Review and tested tag picked up from V2
V2: http://marc.info/?l=u-boot&m=144073487701030&w=2
V1: http://lists.denx.de/pipermail/u-boot/2015-August/225085.html
Test Log: http://pastebin.ubuntu.com/12432507/
Nishanth Menon (4):
drivers: Introduce a simplified remoteproc framework
remoteproc: Introduce a sandbox dummy driver
sandbox: Introduce dummy remoteproc nodes
test: Add basic tests for remoteproc
arch/sandbox/dts/test.dts | 13 + common/Kconfig | 5 + common/Makefile | 1 + common/cmd_remoteproc.c | 281 ++++++++++++++ configs/sandbox_defconfig | 2 + doc/device-tree-bindings/remoteproc/remoteproc.txt | 14 + doc/driver-model/remoteproc-framework.txt | 168 +++++++++ drivers/Kconfig | 2 + drivers/Makefile | 1 + drivers/remoteproc/Kconfig | 24 ++ drivers/remoteproc/Makefile | 10 + drivers/remoteproc/rproc-uclass.c | 417 +++++++++++++++++++++ drivers/remoteproc/sandbox_testproc.c | 336 +++++++++++++++++ include/dm/uclass-id.h | 1 + include/remoteproc.h | 162 ++++++++ test/dm/Makefile | 1 + test/dm/remoteproc.c | 67 ++++ 17 files changed, 1505 insertions(+) create mode 100644 common/cmd_remoteproc.c create mode 100644 doc/device-tree-bindings/remoteproc/remoteproc.txt create mode 100644 doc/driver-model/remoteproc-framework.txt create mode 100644 drivers/remoteproc/Kconfig create mode 100644 drivers/remoteproc/Makefile create mode 100644 drivers/remoteproc/rproc-uclass.c create mode 100644 drivers/remoteproc/sandbox_testproc.c create mode 100644 include/remoteproc.h create mode 100644 test/dm/remoteproc.c
Signature · 1 line
2.1.4