c869c75c16b3d1ffcf64fb2fd63ba0c4a369071c |
|
12-Mar-2013 |
Suman Anna <s-anna@ti.com> |
mailbox/omap: move the OMAP mailbox framework to drivers The mailbox hardware (in OMAP) uses a queued mailbox interrupt mechanism that provides a communication channel between processors through a set of registers and their associated interrupt signals by sending and receiving messages. The OMAP mailbox framework/driver code is moved to be under drivers/mailbox, in preparation for adapting to a common mailbox driver framework. This allows the build for OMAP mailbox to be enabled (it was disabled during the multi-platform support). As part of the migration from plat and mach code: - Kconfig symbols have been renamed to build OMAP1 or OMAP2+ drivers. - mailbox.h under plat-omap/plat/include has been split into a public and private header files. The public header has only the API related functions and types. - The module name mailbox.ko from plat-omap is changed to omap-mailbox.ko - The module name mailbox_mach.ko from mach-omapX is changed as mailbox_omap1.ko for OMAP1 mailbox_omap2.ko for OMAP2+ Cc: Tony Lindgren <tony@atomide.com> [gregkh@linuxfoundation.org: ack for staging part] Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Omar Ramirez Luna <omar.ramirez@copitl.com> Signed-off-by: Suman Anna <s-anna@ti.com>
|
0fe763c570ad2701c830b9e4e53c65ad89c11c32 |
|
22-Dec-2012 |
Greg Kroah-Hartman <gregkh@linuxfoundation.org> |
Drivers: misc: remove __dev* attributes. CONFIG_HOTPLUG is going away as an option. As a result, the __dev* markings need to be removed. This change removes the use of __devinit, __devexit_p, __devinitdata, __devinitconst, and __devexit from these drivers. Based on patches originally written by Bill Pemberton, but redone by me in order to handle some of the coding style issues better, by hand. Cc: Bill Pemberton <wfp5p@virginia.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
2203747c97712975accc5e69bdaf1ad38a691635 |
|
24-Aug-2012 |
Arnd Bergmann <arnd@arndb.de> |
ARM: omap: move platform_data definitions Platform data for device drivers should be defined in include/linux/platform_data/*.h, not in the architecture and platform specific directories. This moves such data out of the omap include directories Signed-off-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Acked-by: Nicolas Pitre <nico@linaro.org> Acked-by: Tony Lindgren <tony@atomide.com> Cc: Kevin Hilman <khilman@ti.com> Cc: "Benoît Cousson" <b-cousson@ti.com> Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com> Cc: David Woodhouse <dwmw2@infradead.org> Cc: Kyungmin Park <kyungmin.park@samsung.com> Cc: Ohad Ben-Cohen <ohad@wizery.com> Cc: Grant Likely <grant.likely@secretlab.ca> Cc: Omar Ramirez Luna <omar.ramirez@ti.com> Cc: Tomi Valkeinen <tomi.valkeinen@ti.com> Cc: Florian Tobias Schandinat <FlorianSchandinat@gmx.de> Cc: Peter Ujfalusi <peter.ujfalusi@ti.com> Cc: Jarkko Nikula <jarkko.nikula@bitmer.com> Cc: Liam Girdwood <lrg@ti.com> Cc: Artem Bityutskiy <artem.bityutskiy@linux.intel.com> Cc: Jean Pihet <j-pihet@ti.com> Cc: J Keerthy <j-keerthy@ti.com> Cc: linux-omap@vger.kernel.org
|
4980f465d21400303b234bcc3d082916f19f11ff |
|
15-Aug-2012 |
Juan Gutierrez <jgutierrez@ti.com> |
remoteproc/omap: set bootaddr support Some remote processors (like OMAP4's DSP) require we explicitly set a boot address from which they'd start executing code when taken out of reset. Support for this is now being added to the omap-specific remoteproc driver through a set_bootaddr function in the platform data which, if needed, must be set according to the backend remote processor. For OMAP4's dsp we can use the following control function: .set_bootaddr = omap_ctrl_write_dsp_boot_addr Signed-off-by: Juan Gutierrez <jgutierrez@ti.com> Signed-off-by: Suman Anna <s-anna@ti.com> [ohad: slight changes to the commit log] Signed-off-by: Ohad Ben-Cohen <ohad@wizery.com>
|
160e7c840fe85836040c43e0058d5afced470c85 |
|
04-Jul-2012 |
Ohad Ben-Cohen <ohad@wizery.com> |
remoteproc: adopt the driver core's alloc/add/del/put naming To make remoteproc's API more intuitive for developers, we adopt the driver core's naming, i.e. alloc -> add -> del -> put. We'll also add register/unregister when their first user shows up. Otherwise - there's no functional change here. Suggested by Russell King <linux@arm.linux.org.uk>. Cc: Russell King <linux@arm.linux.org.uk> Cc: Fernando Guzman Lugo <fernando.lugo@ti.com> Cc: Sjur Brændeland <sjur.brandeland@stericsson.com> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Acked-by: Stephen Boyd <sboyd@codeaurora.org> Signed-off-by: Ohad Ben-Cohen <ohad@wizery.com>
|
c6b5a27628faf6657b741d828a1462d832d0dbc5 |
|
02-Jul-2012 |
Ohad Ben-Cohen <ohad@wizery.com> |
remoteproc: simplify unregister/free interfaces Simplify the unregister/free interfaces, and make them easier to understand and use, by moving to a symmetric and consistent alloc() -> register() -> unregister() -> free() flow. To create and register an rproc instance, one needed to invoke rproc_alloc() followed by rproc_register(). To unregister and free an rproc instance, one now needs to invoke rproc_unregister() followed by rproc_free(). Cc: Stephen Boyd <sboyd@codeaurora.org> Signed-off-by: Ohad Ben-Cohen <ohad@wizery.com>
|
b5ab5e24e960b9f780a4cc96815cfd4b0d412720 |
|
30-May-2012 |
Ohad Ben-Cohen <ohad@wizery.com> |
remoteproc: maintain a generic child device for each rproc For each registered rproc, maintain a generic remoteproc device whose parent is the low level platform-specific device (commonly a pdev, but it may certainly be any other type of device too). With this in hand, the resulting device hierarchy might then look like: omap-rproc.0 | - remoteproc0 <---- new ! | - virtio0 | - virtio1 | - rpmsg0 | - rpmsg1 | - rpmsg2 Where: - omap-rproc.0 is the low level device that's bound to the driver which invokes rproc_register() - remoteproc0 is the result of this patch, and will be added by the remoteproc framework when rproc_register() is invoked - virtio0 and virtio1 are vdevs that are registered by remoteproc when it realizes that they are supported by the firmware of the physical remote processor represented by omap-rproc.0 - rpmsg0, rpmsg1 and rpmsg2 are rpmsg devices that represent rpmsg channels, and are registerd by the rpmsg bus when it gets notified about their existence Technically, this patch: - changes 'struct rproc' to contain this generic remoteproc.x device - creates a new "remoteproc" type, to which this new generic remoteproc.x device belong to. - adds a super simple enumeration method for the indices of the remoteproc.x devices - updates all dev_* messaging to use the generic remoteproc.x device instead of the low level platform-specific device - updates all dma_* allocations to use the parent of remoteproc.x (where the platform-specific memory pools, most commonly CMA, are to be found) Adding this generic device has several merits: - we can now add remoteproc runtime PM support simply by hooking onto the new "remoteproc" type - all remoteproc log messages will now carry a common name prefix instead of having a platform-specific one - having a device as part of the rproc struct makes it possible to simplify refcounting (see subsequent patch) Thanks to Stephen Boyd <sboyd@codeaurora.org> for suggesting and discussing these ideas in one of the remoteproc review threads and to Fernando Guzman Lugo <fernando.lugo@ti.com> for trying them out with the (upcoming) runtime PM support for remoteproc. Cc: Fernando Guzman Lugo <fernando.lugo@ti.com> Reviewed-by: Stephen Boyd <sboyd@codeaurora.org> Signed-off-by: Ohad Ben-Cohen <ohad@wizery.com>
|
6b03976288538a94e072bbfcd12d69a20daea8aa |
|
21-May-2012 |
Ohad Ben-Cohen <ohad@wizery.com> |
remoteproc/omap: fix dev_err typo For some reason one of the dev_err invocations is using a wrong device so fix that. Signed-off-by: Ohad Ben-Cohen <ohad@wizery.com> Cc: stable@vger.kernel.org
|
55f34080d99be0ac75122a27e7b151c76a5b070d |
|
13-Feb-2012 |
Ohad Ben-Cohen <ohad@wizery.com> |
remoteproc/omap: remove the mbox_callback limitation Now that remoteproc supports any number of virtio devices, the previous sanity check in omap_rproc_mbox_callback doesn't make sense anymore. Remove that so we can start supporting multiple vdevs. Signed-off-by: Ohad Ben-Cohen <ohad@wizery.com> Cc: Brian Swetland <swetland@google.com> Cc: Iliyan Malchev <malchev@google.com> Cc: Arnd Bergmann <arnd@arndb.de> Cc: Grant Likely <grant.likely@secretlab.ca> Cc: Rusty Russell <rusty@rustcorp.com.au> Cc: Mark Grosen <mgrosen@ti.com> Cc: John Williams <john.williams@petalogix.com> Cc: Michal Simek <monstr@monstr.eu> Cc: Loic PALLARDY <loic.pallardy@stericsson.com> Cc: Ludovic BARRE <ludovic.barre@stericsson.com> Cc: Omar Ramirez Luna <omar.luna@linaro.org> Cc: Guzman Lugo Fernando <fernando.lugo@ti.com> Cc: Anna Suman <s-anna@ti.com> Cc: Clark Rob <rob@ti.com> Cc: Stephen Boyd <sboyd@codeaurora.org> Cc: Saravana Kannan <skannan@codeaurora.org> Cc: David Brown <davidb@codeaurora.org> Cc: Kieran Bingham <kieranbingham@gmail.com> Cc: Tony Lindgren <tony@atomide.com>
|
63d667bf53c444082b053d95ddc4d54f3dbe8f52 |
|
13-Dec-2011 |
Ohad Ben-Cohen <ohad@wizery.com> |
remoteproc/omap: utilize module_platform_driver Ditch some boilerplate code by employing the module_platform_driver helper. Signed-off-by: Ohad Ben-Cohen <ohad@wizery.com>
|
34ed5a33b1218efbe8b01e37738063800ccdcdcd |
|
20-Oct-2011 |
Ohad Ben-Cohen <ohad@wizery.com> |
remoteproc/omap: add a remoteproc driver for OMAP4 Add a remoteproc driver for OMAP4, so we can boot the dual-M3 and and DSP subsystems. Use the omap_device_* API to control the hardware state, and utilize the OMAP mailbox to interrupt the remote processor when a new message is pending (the mailbox payload is used to tell it which virtqueue was the message placed in). Conversely, when an inbound mailbox message arrives, tell the remoteproc core which virtqueue is triggered. Later we will also use the mailbox payload to signal omap-specific events like remote crashes (which will be used to trigger remoteproc recovery) and power management transitions. At that point we will also extend the remoteproc core to support this. Based on (but now quite far from) work done by Fernando Guzman Lugo <fernando.lugo@ti.com> and Hari Kanigeri <h-kanigeri2@ti.com>. Designed with Brian Swetland <swetland@google.com>. Signed-off-by: Ohad Ben-Cohen <ohad@wizery.com> Acked-by: Tony Lindgren <tony@atomide.com> Cc: Brian Swetland <swetland@google.com> Cc: Arnd Bergmann <arnd@arndb.de> Cc: Grant Likely <grant.likely@secretlab.ca> Cc: Russell King <linux@arm.linux.org.uk> Cc: Rusty Russell <rusty@rustcorp.com.au> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: Greg KH <greg@kroah.com> Cc: Stephen Boyd <sboyd@codeaurora.org>
|