aboutsummaryrefslogtreecommitdiffstats
path: root/drivers/remoteproc
Commit message (Collapse)AuthorAgeFilesLines
* remoteproc: fix an off-by-one error in static-pool range checkSuman Anna2011-08-111-1/+1
| | | | | | | | | The comparison for checking the range of a carveout section against the remoteproc's static pool is incorrect, and has been fixed. Change-Id: I027c9ea89eb73fa783754ffb1a993663daefa32a Signed-off-by: Suman Anna <s-anna@ti.com> Signed-off-by: Iliyan Malchev <malchev@google.com>
* omap: rpres: reset device before shutdownFernando Guzman Lugo2011-08-051-1/+12
| | | | | | | | | | | rpres module manages devices that can be used by remote processors. There are some cases where the remote processor crashes and there are interruptions or any other pending actions that avoid clock going off or gated and keep the clock domain in transition state. So avoid those cases by reseting the devices which have softreset before shutdown. Change-Id: If260c621f2669805afc85485679c717fb3f628a0 Signed-off-by: Fernando Guzman Lugo <fernando.lugo@ti.com>
* remoteproc: block rproc_get after a crashFernando Guzman Lugo2011-08-051-0/+15
| | | | | | | | | | block calls to rproc_get when a crash until all the users have called to rproc_put, which releases the remote processor completely and a reset is made. That way we make sure new rproc_get starts with a clean remote processor initialization. Change-Id: Ie9be54480b2313128b86480bc6420bd946b75776 Signed-off-by: Fernando Guzman Lugo <fernando.lugo@ti.com>
* remoteproc: reset the memory pool and memory mapsSuman Anna2011-08-031-1/+17
| | | | | | | | | | | | | Reloading of the Ducati binary either during recovery or during modules reinstall requires that the prior memory pool and maps information be reset, to avoid running into out of pool memory and duplicate memory entry storage failures. These are reset therefore when the processor is being stopped. Change-Id: If9923eecf99863c5b529a96efc20481fe32ca549 Signed-off-by: Suman Anna <s-anna@ti.com> Signed-off-by: Iliyan Malchev <malchev@google.com>
* remoteproc: return -EIO instead of -EFAULT from fault ISRIliyan Malchev2011-08-021-2/+2
| | | | Signed-off-by: Iliyan Malchev <malchev@google.com>
* remoteproc: fix tracing with the new memory map changesSuman Anna2011-08-021-19/+41
| | | | | | | | | | | The remote processor tracing is non-functional with the new memory map changes, due to incorrect physical address. The rproc_da_to_pa information is not available until all the RSC_DEVMEM and RSC_CARVEOUT resources are handled, and as such the trace buffers cannot be setup until the very end. Change-Id: I728345b5ed138a0b6ab492d3724a2fa4eeab3a0b Signed-off-by: Suman Anna <s-anna@ti.com>
* omap: remoteproc: support reading memory maps from firmwareSuman Anna2011-07-281-1/+1
| | | | | | | | Remove support for static memory maps. Rely on the firmware specifying its own layout. Change-Id: I5b62a934ad9606aa1a4d3f776c1e8b2c5d3d4f2c Signed-off-by: Suman Anna <s-anna@ti.com>
* remoteproc: support reading memory maps from firmwareSuman Anna2011-07-281-32/+126
| | | | | | | | | | | | | | | | | | | | | | | | The remoteproc module has been adapted to load the remote processor completely based on the memory map from the firmware image. The following are the main changes: - pass a new memory pool in the platform data, replacing the previous memory maps, so that the firmware loading can use the pool data while processing the different image sections. - the new firmware image is expected to have the firmware section as the first section, so that the memory map data can be retrieved. - the resource table firmware section processing handles the allocation of memory for memory regions without physical addresses. The sections with pre-defined static addresses are also authenticated against the static pool range. - the previous memory maps data is completely removed from the platform data, but rather is localized now to remoteproc driver; the memory map is published during the resource table firmware section processing. Change-Id: I5b62a934ad9606aa1a4d3f776c1e8b2c5d3d4f2c Signed-off-by: Suman Anna <s-anna@ti.com>
* omap: remoteproc: allow loading of new resource_table with memmapG Anthony2011-07-281-8/+21
| | | | | | | | | | | | | | | | | | Updated the fw_resource types and structures to match the new BIOS-side resource table that includes the device memory map. The BIOS version stamp has been updated to reflect the new fw_resource structure, and an appropriate check has been added to detect mismatched versions. A new resource type, RSC_CARVEOUT is added to indicate the memory region is represented by a contiguous memory block. The RSC_SERVICE has been removed since the services are dynamically published, and there is no user for this resource. Change-Id: I28520baffaeb3aa76f9a7de4a7d16286157b08cd Signed-off-by: G Anthony <a0783926@ti.com> Signed-off-by: Suman Anna <s-anna@ti.com>
* OMAP4: PM: do omap_device_idle() for IVAHDGirish S Ghongdemath2011-07-211-1/+1
| | | | | | | | | | | | | | | | IVAHD doesn't transit to RET when suspend attempted during CAM usecase. When Calling on to *_shutdown messes up the IVA reset sequence. Letting remoteproc to do only device_idle. The observation is: - After the Video playback IVA reset sequence is properly done and IVA transit to RET as expected during suspend. - After CAM usecase, IVA doesn't seem to transit RET. Suspect is the assertion reset lines in shutdown messing up the h/w transition. However, this might need a REVISIT to see the ducati side reset sequence applied for Video Vs Cam usecase is the same. Change-Id: Id2021e4c1e41e358d0fcbdcff07bb80b08395b65 Signed-off-by: Girish S G <girishsg@it.com>
* OMAP4: PM: do omap_device_idle for ISS and fdifGirish S Ghongdemath2011-07-211-2/+2
| | | | | | | | | | | | | | | | | omap_device_shutdown should be called only when module is getting unloaded. Else there can be a chance when standby is getting asserted and forceidle is applied on the module causing interface to lock up on next access. ISS hang: device_shutdown was setting forceidle, this was unconditionally putting the interface to idle. The recommended setting is to call for device_idle which will set smartstdby/smartidle. This makes sure that all the submodules of ISS asserts Mstadby and once ISS acks back interface will be safe to idle. Do omap_device_idle for fdif as well. Change-Id: I94fee16ccc66c60de8c6060745aa1f92c0045dbc Signed-off-by: Girish S G <girishsg@ti.com>
* omap4: remoteproc: specific constraints apisMiguel Vadillo2011-07-201-0/+22
| | | | | | | | | | | | | | Omap4 specific implementation of constraints apis supporting: - Latency - Frequency - Bandwidth Change-Id: I7c001a54702156ed5e628867268279be3f2cc2ed Signed-off-by: Miguel Vadillo <vadillo@ti.com> Signed-off-by: Fernando Guzman Lugo <fernando.lugo@ti.com> Signed-off-by: Suman Anna <s-anna@ti.com>
* remoteproc: add constraints frameworkMiguel Vadillo2011-07-201-0/+56
| | | | | | | | | | | | | | | | | Add constraints api to remoteproc framework supporting: - Latency (Using pm_qos framework) - Frequency - Bandwidth Each of them should be provided by the specific architecture if supported. Change-Id: Icddd9a8ee3c6c781e1a30817a2db8716428089ad Signed-off-by: Miguel Vadillo <vadillo@ti.com> Signed-off-by: Fernando Guzman Lugo <fernando.lugo@ti.com> Signed-off-by: Suman Anna <s-anna@ti.com>
* omap: rpres: add fdif frequency functionMiguel Vadillo2011-07-201-2/+3
| | | | | | | Allow fdif to scale. Change-Id: Iab071570e317cfe082c71cc566001dc4107ebe5f Signed-off-by: Miguel Vadillo <vadillo@ti.com>
* omap: rpres: skip the creation of already created devicesMiguel Vadillo2011-07-202-12/+51
| | | | | | | | | | | | | | | | | | Some devices like: - iva - dsp - fdif are being created for pm purposes and create them again is not recommended. For these devices the pm framework is exporting api's to get them. If a resource is already created use the api to get the device and add the platform data and information needed for rpres to control such device. Change-Id: I6640883f911f4c21d204c20ded1ced104af5ed7c Signed-off-by: Miguel Vadillo <vadillo@ti.com>
* OMAP4: remoteproc: implement runtime PM autosuspendFernando Guzman Lugo2011-07-081-8/+167
| | | | | Signed-off-by: Fernando Guzman Lugo <fernando.lugo@ti.com> Signed-off-by: Iliyan Malchev <malchev@google.com>
* remoteproc: add runtime PM autosuspend supportFernando Guzman Lugo2011-07-082-3/+255
| | | | | | | | | | | | | | | | | | Going to suspend and resuming is a heavy task with much latency. For that reason remoteproc should go to suspend after some time of inactivity. However, the remoteproc driver cannot know by itself if activity is being performing on the remote processor (the driver is only in charge of turning it on/off). That is why remoteproc adds new APIs to be notified when the remote processor is used and then restart suspend timeout. Remote proc users need to use these new APIs. Besides, if they have issues when the remote processor goes to suspend without their knowledge, they need to register for suspend/resume notifications. Returning an error in the notification callback means they are using the remote processor and the autosuspend should be cancelled. Signed-off-by: Fernando Guzman Lugo <fernando.lugo@ti.com> Signed-off-by: Iliyan Malchev <malchev@google.com>
* OMAP: remoteproc: implement fatal error notificationsFernando Guzman Lugo2011-07-081-20/+58
| | | | | Signed-off-by: Fernando Guzman Lugo <fernando.lugo@ti.com> Signed-off-by: Iliyan Malchev <malchev@google.com>
* remoteproc: add fatal error notifications for rproc usersFernando Guzman Lugo2011-07-081-1/+84
| | | | | | | | | | | | Two new functions are added, so that rproc users can register/unregister for fatal error notifications. Once a fatal error is notified, the remote processor is not usable anymore, and the rproc handle should be released. This patch also includes MMU faults notifications. New fatal errors will be added in the future. Signed-off-by: Fernando Guzman Lugo <fernando.lugo@ti.com> Signed-off-by: Iliyan Malchev <malchev@google.com>
* omap: rpres: adding constraints APIMiguel Vadillo2011-06-302-2/+86
| | | | | | | | | | | | | | Adding PM constraints to rpres driver: - scale_dev: request a change in the opp of the device or the domain the device is part of. - set_lat: request a latency constraint on the device or the domain the device is part of. - set_bw: set the minimum bus troughput for this device. Change-Id: I711fc5c68d2cab812c399764f429d1ada37ced2b Signed-off-by: Miguel Vadillo <vadillo@ti.com> Signed-off-by: Fernando Guzman Lugo <fernando.lugo@ti.com>
* RPMSG: RESMGR: miscellaneous fixesFernando Guzman Lugo2011-06-231-0/+1
| | | | | | | | | | | | This patch changes: - Fixed memory leak in rprm_resource_free() - Fixed missing mutex_unlock in rprm_resource_alloc() in case of failure - Move RPMSG_RESMGR option above RPMSG samples in Kconfig (samples should go at the end - Chaged to "default y" option in Kconfig file for RPMSG_RESMGR Signed-off-by: Fernando Guzman Lugo <fernando.lugo@ti.com>
* OMAP: rpres: adding new framework rpresFernando Guzman Lugo2011-06-224-0/+297
| | | | | | | | | | | | | | | | | | | | | | | This new module create devices for resources than can be access by the moteprocessor in omap4. Note: sl2if has follow this sequence: - sl2if * A sequence is need to request them: > iva_hd > iva_seq0 > iva_seq1 > sl2if * A sequence is need to release them: > iva_seq1 > iva_seq0 > sl2if > iva_hd * Otherwise the PM transitions behavior is abnormal Signed-off-by: Fernando Guzman Lugo <fernando.lugo@ti.com> Signed-off-by: Miguel Vadillo <vadillo@ti.com>
* omap: remoteproc: remove the iommu clk temporary workaroundSuman Anna2011-06-141-5/+0
| | | | | | | | iommu module has been enhanced to use the hwmod framework, and does not use any clock api directly. This patch removes the relevant temporary workarounds in the remoteproc code. Signed-off-by: Suman Anna <s-anna@ti.com>
* remoteproc: add omap implementationGuzman Lugo, Fernando2011-06-143-0/+191
| | | | | | | | | | | | | | Add remoteproc implementation for OMAP4, to be able to load the remote dual M3 and DSP processors. Still needs some clean ups here. Based on code by Hari Kanigeri <h-kanigeri2@ti.com> Change-Id: I479553ed58d27ca771f9ce3c60608e8eaab89963 Signed-off-by: Guzman Lugo, Fernando <fernando.lugo@ti.com> [ohad@wizery.com: refactored and simplified, still wip] Signed-off-by: Ohad Ben-Cohen <ohad@wizery.com>
* drivers: add generic remoteproc frameworkOhad Ben-Cohen2011-06-143-0/+629
Some systems are equipped with slave heterogeneous remote processor devices, that are usually used to offload cpu-intensive computations (e.g. multimedia codec tasks). Introduce a generic remoteproc framework that allows drivers to start and stop those remote processor devices, load up their firmware (which might not necessarily be Linux-based), and in the future also manage their runtime PM status, recovery, and any other relevant configuration/states. Firmware loader is based on code by Mark Grosen <mgrosen@ti.com>. Change-Id: I7094eb8e0eb512b53a5333ff2dd70c756a775a7e Signed-off-by: Ohad Ben-Cohen <ohad@wizery.com>
generated by cgit v1.1 at 2025-01-24 14:43:36 +0000