- 03 10月, 2016 1 次提交
-
-
由 Bjorn Andersson 提交于
In order to be able to lock a rproc driver implementations only when used by a client, we must differ between the dereference operation of a client and the implementation itself. This patch brings no functional change. Signed-off-by: NBjorn Andersson <bjorn.andersson@linaro.org>
-
- 13 8月, 2016 2 次提交
-
-
由 Anna, Suman 提交于
The omap_mbox_msg_send() is the legacy API for sending a mailbox message. It has been replaced with the mbox_send_message() from the mailbox framework. Revise the failure trace to print a generic failure message instead of referencing the actual function name. Signed-off-by: NSuman Anna <s-anna@ti.com> Signed-off-by: NBjorn Andersson <bjorn.andersson@linaro.org>
-
由 Anna, Suman 提交于
This patch fixes some of the existing checkpatch warnings in OMAP remoteproc code. The fixes are to the following warnings: 1. WARNING: missing space after return type 2. WARNING: Unnecessary space after function pointer name 3. CHECK: Alignment should match open parenthesis Signed-off-by: NSuman Anna <s-anna@ti.com> Signed-off-by: NBjorn Andersson <bjorn.andersson@linaro.org>
-
- 12 3月, 2015 1 次提交
-
-
由 Suman Anna 提交于
The remoteproc framework currently relies on iommu_present() on the bus the device is on, to perform MMU management. However, this logic doesn't scale for multi-arch, especially for processors that do not have an IOMMU. Replace this logic instead by using a h/w capability flag for the presence of IOMMU in the rproc structure. This issue is seen on OMAP platforms when trying to add a remoteproc driver for a small Cortex M3 called the WkupM3 used for suspend / resume management on TI AM335/AM437x SoCs. This processor does not have an MMU. Same is the case with another processor subsystem PRU-ICSS on AM335/AM437x. All these are platform devices, and the current iommu_present check will not scale for the same kernel image to support OMAP4/OMAP5 and AM335/AM437x. The existing platform implementation drivers - OMAP remoteproc, STE Modem remoteproc and DA8xx remoteproc, are updated as well to properly configure the newly added rproc field. Cc: Robert Tivy <rtivy@ti.com> Cc: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: NSuman Anna <s-anna@ti.com> [small change in the commit title and in a single comment] Signed-off-by: NOhad Ben-Cohen <ohad@wizery.com>
-
- 27 11月, 2014 1 次提交
-
-
由 Suman Anna 提交于
The OMAP mailbox driver and its existing clients (remoteproc for OMAP4+) are adapted to use the generic mailbox framework. The main changes for the adaptation are: - The tasklet used for Tx is replaced with the state machine from the generic mailbox framework. The workqueue used for processing the received messages stays intact for minimizing the effects on the OMAP mailbox clients. - The existing exported client API, omap_mbox_get, omap_mbox_put and omap_mbox_send_msg are deleted, as the framework provides equivalent functionality. A OMAP-specific omap_mbox_request_channel is added though to support non-DT way of requesting mailboxes. - The OMAP mailbox driver is integrated with the mailbox framework through the proper implementations of mbox_chan_ops, except for .last_tx_done and .peek_data. The OMAP mailbox driver does not need these ops, as it is completely interrupt driven. - The OMAP mailbox driver uses a custom of_xlate controller ops that allows phandles for the pargs specifier instead of indexing to avoid any channel registration order dependencies. - The new framework does not support multiple clients operating on a single channel, so the reference counting logic is simplified. - The remoteproc driver (current client) is adapted to use the new API. The notifier callbacks used within this client is replaced with the regular callbacks from the newer framework. - The exported OMAP mailbox API are limited to omap_mbox_save_ctx, omap_mbox_restore_ctx, omap_mbox_enable_irq & omap_mbox_disable_irq, with the signature modified to take in the new mbox_chan handle instead of the OMAP specific omap_mbox handle. The first 2 will be removed when the OMAP mailbox driver is adapted to runtime_pm. The other exported API omap_mbox_request_channel will be removed once existing legacy users are converted to DT. Signed-off-by: NSuman Anna <s-anna@ti.com> Cc: Ohad Ben-Cohen <ohad@wizery.com> Signed-off-by: NJassi Brar <jaswinder.singh@linaro.org>
-
- 20 10月, 2014 1 次提交
-
-
由 Wolfram Sang 提交于
A platform_driver does not need to set an owner, it will be populated by the driver core. Signed-off-by: NWolfram Sang <wsa@the-dreams.de>
-
- 12 6月, 2013 1 次提交
-
-
由 Suman Anna 提交于
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: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NOmar Ramirez Luna <omar.ramirez@copitl.com> Signed-off-by: NSuman Anna <s-anna@ti.com>
-
- 04 1月, 2013 1 次提交
-
-
由 Greg Kroah-Hartman 提交于
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: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
- 19 9月, 2012 1 次提交
-
-
由 Arnd Bergmann 提交于
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: NArnd Bergmann <arnd@arndb.de> Acked-by: NMark Brown <broonie@opensource.wolfsonmicro.com> Acked-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Acked-by: NNicolas Pitre <nico@linaro.org> Acked-by: NTony 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
-
- 11 9月, 2012 1 次提交
-
-
由 Juan Gutierrez 提交于
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: NJuan Gutierrez <jgutierrez@ti.com> Signed-off-by: NSuman Anna <s-anna@ti.com> [ohad: slight changes to the commit log] Signed-off-by: NOhad Ben-Cohen <ohad@wizery.com>
-
- 06 7月, 2012 3 次提交
-
-
由 Ohad Ben-Cohen 提交于
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: NLinus Walleij <linus.walleij@linaro.org> Acked-by: NStephen Boyd <sboyd@codeaurora.org> Signed-off-by: NOhad Ben-Cohen <ohad@wizery.com>
-
由 Ohad Ben-Cohen 提交于
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: NOhad Ben-Cohen <ohad@wizery.com>
-
由 Ohad Ben-Cohen 提交于
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: NStephen Boyd <sboyd@codeaurora.org> Signed-off-by: NOhad Ben-Cohen <ohad@wizery.com>
-
- 17 6月, 2012 1 次提交
-
-
由 Ohad Ben-Cohen 提交于
For some reason one of the dev_err invocations is using a wrong device so fix that. Signed-off-by: NOhad Ben-Cohen <ohad@wizery.com> Cc: stable@vger.kernel.org
-
- 07 3月, 2012 1 次提交
-
-
由 Ohad Ben-Cohen 提交于
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: NOhad 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>
-
- 09 2月, 2012 2 次提交
-
-
由 Ohad Ben-Cohen 提交于
Ditch some boilerplate code by employing the module_platform_driver helper. Signed-off-by: NOhad Ben-Cohen <ohad@wizery.com>
-
由 Ohad Ben-Cohen 提交于
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: NOhad Ben-Cohen <ohad@wizery.com> Acked-by: NTony 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>
-