RE: [RFC 0/6] Introducing OMAP Remote Processor module
-Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Ohad Ben-Cohen Sent: Friday, July 02, 2010 3:53 AM To: linux-omap@vger.kernel.org Cc: Kanigeri, Hari; Ben-cohen, Ohad Subject: [RFC 0/6] Introducing OMAP Remote Processor module From: Ohad Ben-Cohen oh...@ti.com This is a preliminary version of OMAP's remoteproc module, submitted for RFC purposes. The purpose of the remoteproc module is to decouple hw-specific code from generic IPC drivers (such as dspbridge and syslink), in order to eventually make those IPC drivers platform-independent. Currently the supported operations are starting and stopping the remote processor, but in the future additional functionality might be added. Both OMAP3 and OMAP4 are supported; OMAP3 supports the dsp remote processor, and OMAP4 supports ducati (tesla support is planned as well). The code was tested on both OMAP3 (using dspbridge) and OMAP4 (using syslink). The code is preliminary: we plan to add much more extensive hwmod support, ideally squashing as much hw-specific code as possible (including RST and PRCM manipulations). In addition, a rebase to recent code bases is needed. While dspbridge accesses remoteproc's interface via pdata pointers, syslink accesses it from user space, via character device interface, so both kernel and user space interfaces are supported. A few words on the char device interface: * Each remote processor is represented by a different character device: /dev/omap-rproc0, /dev/omap-rproc1, ... [sp] Concept of remote processor is not really tied to omap. Though the implementation is being done in context of OMAP, I would suggest removing the prefix omap- from the device name. * A rproc character device can only be opened by a single user (e.g. the syslink daemon) * The start/stop/get_state functionality is exposed via ioctl's * We plan to add automatic stop() invokation in case the user closes the device after starting a remote processor (for resource cleanup purposes. Thus the user will be required to hold the device open as long as it lives). Thanks, Hari Kanigeri (1): omap: introduce OMAP4 remoteproc module Ohad Ben-Cohen (5): omap: add iva2 hwmod support to omap3 omap: introduce OMAP3 remoteproc module omap: introduce common remoteproc module omap: add remoteproc device(s) omap: enable remoteproc building arch/arm/mach-omap2/Makefile |6 + arch/arm/mach-omap2/devices.c| 86 +++ arch/arm/mach-omap2/omap_hwmod_34xx.h| 23 ++ arch/arm/mach-omap2/remoteproc3xxx.c | 226 ++ arch/arm/mach-omap2/remoteproc44xx.c | 196 arch/arm/plat-omap/Kconfig |7 + arch/arm/plat-omap/Makefile |1 + arch/arm/plat-omap/include/plat/omap_hwmod.h |1 + arch/arm/plat-omap/include/plat/remoteproc.h | 75 ++ arch/arm/plat-omap/remoteproc.c | 316 ++ 10 files changed, 937 insertions(+), 0 deletions(-) create mode 100644 arch/arm/mach-omap2/remoteproc3xxx.c create mode 100644 arch/arm/mach-omap2/remoteproc44xx.c create mode 100644 arch/arm/plat-omap/include/plat/remoteproc.h create mode 100644 arch/arm/plat-omap/remoteproc.c -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 0/6] Introducing OMAP Remote Processor module
Hi Sanjeev, Thanks for your comments. As we plan to move remoteproc to hwmod, the code will be substantially changed. We will keep your comments in mind, and also keep in mind other TI platforms (like davinci). Thanks, Ohad. On Tue, Jul 27, 2010 at 3:27 PM, Premi, Sanjeev pr...@ti.com wrote: -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Ohad Ben-Cohen Sent: Friday, July 02, 2010 3:53 AM To: linux-omap@vger.kernel.org Cc: Kanigeri, Hari; Ben-cohen, Ohad Subject: [RFC 0/6] Introducing OMAP Remote Processor module From: Ohad Ben-Cohen oh...@ti.com This is a preliminary version of OMAP's remoteproc module, submitted for RFC purposes. The purpose of the remoteproc module is to decouple hw-specific code from generic IPC drivers (such as dspbridge and syslink), in order to eventually make those IPC drivers platform-independent. Currently the supported operations are starting and stopping the remote processor, but in the future additional functionality might be added. Both OMAP3 and OMAP4 are supported; OMAP3 supports the dsp remote processor, and OMAP4 supports ducati (tesla support is planned as well). The code was tested on both OMAP3 (using dspbridge) and OMAP4 (using syslink). The code is preliminary: we plan to add much more extensive hwmod support, ideally squashing as much hw-specific code as possible (including RST and PRCM manipulations). In addition, a rebase to recent code bases is needed. While dspbridge accesses remoteproc's interface via pdata pointers, syslink accesses it from user space, via character device interface, so both kernel and user space interfaces are supported. A few words on the char device interface: * Each remote processor is represented by a different character device: /dev/omap-rproc0, /dev/omap-rproc1, ... [sp] Concept of remote processor is not really tied to omap. Though the implementation is being done in context of OMAP, I would suggest removing the prefix omap- from the device name. * A rproc character device can only be opened by a single user (e.g. the syslink daemon) * The start/stop/get_state functionality is exposed via ioctl's * We plan to add automatic stop() invokation in case the user closes the device after starting a remote processor (for resource cleanup purposes. Thus the user will be required to hold the device open as long as it lives). Thanks, Hari Kanigeri (1): omap: introduce OMAP4 remoteproc module Ohad Ben-Cohen (5): omap: add iva2 hwmod support to omap3 omap: introduce OMAP3 remoteproc module omap: introduce common remoteproc module omap: add remoteproc device(s) omap: enable remoteproc building arch/arm/mach-omap2/Makefile | 6 + arch/arm/mach-omap2/devices.c | 86 +++ arch/arm/mach-omap2/omap_hwmod_34xx.h | 23 ++ arch/arm/mach-omap2/remoteproc3xxx.c | 226 ++ arch/arm/mach-omap2/remoteproc44xx.c | 196 arch/arm/plat-omap/Kconfig | 7 + arch/arm/plat-omap/Makefile | 1 + arch/arm/plat-omap/include/plat/omap_hwmod.h | 1 + arch/arm/plat-omap/include/plat/remoteproc.h | 75 ++ arch/arm/plat-omap/remoteproc.c | 316 ++ 10 files changed, 937 insertions(+), 0 deletions(-) create mode 100644 arch/arm/mach-omap2/remoteproc3xxx.c create mode 100644 arch/arm/mach-omap2/remoteproc44xx.c create mode 100644 arch/arm/plat-omap/include/plat/remoteproc.h create mode 100644 arch/arm/plat-omap/remoteproc.c -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC 0/6] Introducing OMAP Remote Processor module
From: Ohad Ben-Cohen oh...@ti.com This is a preliminary version of OMAP's remoteproc module, submitted for RFC purposes. The purpose of the remoteproc module is to decouple hw-specific code from generic IPC drivers (such as dspbridge and syslink), in order to eventually make those IPC drivers platform-independent. Currently the supported operations are starting and stopping the remote processor, but in the future additional functionality might be added. Both OMAP3 and OMAP4 are supported; OMAP3 supports the dsp remote processor, and OMAP4 supports ducati (tesla support is planned as well). The code was tested on both OMAP3 (using dspbridge) and OMAP4 (using syslink). The code is preliminary: we plan to add much more extensive hwmod support, ideally squashing as much hw-specific code as possible (including RST and PRCM manipulations). In addition, a rebase to recent code bases is needed. While dspbridge accesses remoteproc's interface via pdata pointers, syslink accesses it from user space, via character device interface, so both kernel and user space interfaces are supported. A few words on the char device interface: * Each remote processor is represented by a different character device: /dev/omap-rproc0, /dev/omap-rproc1, ... * A rproc character device can only be opened by a single user (e.g. the syslink daemon) * The start/stop/get_state functionality is exposed via ioctl's * We plan to add automatic stop() invokation in case the user closes the device after starting a remote processor (for resource cleanup purposes. Thus the user will be required to hold the device open as long as it lives). Thanks, Hari Kanigeri (1): omap: introduce OMAP4 remoteproc module Ohad Ben-Cohen (5): omap: add iva2 hwmod support to omap3 omap: introduce OMAP3 remoteproc module omap: introduce common remoteproc module omap: add remoteproc device(s) omap: enable remoteproc building arch/arm/mach-omap2/Makefile |6 + arch/arm/mach-omap2/devices.c| 86 +++ arch/arm/mach-omap2/omap_hwmod_34xx.h| 23 ++ arch/arm/mach-omap2/remoteproc3xxx.c | 226 ++ arch/arm/mach-omap2/remoteproc44xx.c | 196 arch/arm/plat-omap/Kconfig |7 + arch/arm/plat-omap/Makefile |1 + arch/arm/plat-omap/include/plat/omap_hwmod.h |1 + arch/arm/plat-omap/include/plat/remoteproc.h | 75 ++ arch/arm/plat-omap/remoteproc.c | 316 ++ 10 files changed, 937 insertions(+), 0 deletions(-) create mode 100644 arch/arm/mach-omap2/remoteproc3xxx.c create mode 100644 arch/arm/mach-omap2/remoteproc44xx.c create mode 100644 arch/arm/plat-omap/include/plat/remoteproc.h create mode 100644 arch/arm/plat-omap/remoteproc.c -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
