aboutsummaryrefslogtreecommitdiffstats
path: root/arch/arm/plat-omap
Commit message (Collapse)AuthorAgeFilesLines
* [espresso] OMAP4: UART: add DEBUG_LL support for espressoZiyan2016-04-301-0/+3
|
* omap4: ion: add config option to force dynamic tiler allocationsLuden2016-04-301-0/+5
| | | | Change-Id: I35aa150bdeda21b063591cd18ef55f01a6171e8c
* OMAP: process tput request made before PM init.John Grossman2012-10-264-14/+79
| | | | | | | | | | | | | Because driver load order is uncertain, drivers could request bus throughput constraints before the PM subsystem had initialized. The constraints would be recorded, but would have no effect on the actual L3 clock. This change suppresses attempts to set L3 scaling before PM has initialized, and causes the PM subsystem to apply any pending bus throughput constraints immediately after it has initialized itself. Change-Id: If2a1f5315b8c1b084e4e4b3ce8e6844d92dd59b6 Signed-off-by: John Grossman <johngro@google.com> Signed-off-by: Ruslan Bilovol <ruslan.bilovol@ti.com>
* OMAP: McBSP: Fix rx_irq handling in omap_mcbsp_request.John Grossman2012-10-181-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Fix a logic error in omap_mcbsp_request in the TI McBSP libraries. Looks like this lib is trying to support a unit which has been around since OMAP1, but which has been evolving. In particular, the libraries are expecting there to be two different IRQs going into the GIC. One for TX and another for RX. This may have been true on older OMAPs, but on OMAP4, the TX and RX halves of each McBSP share a single IRQ routed to the GIC. The hwmod file for OMAP44xx attempts to signal this to the library by passing 0 for the RX IRQ. Someone has made some attempt in the lib to embrace the fact that there may only be one interrupt line by checking the rx_irq parameter and only attempting to request the IRQ if rx_irq >= 0. There is a problems with this. The hwmod file is passing 0 as the IRQ number. 0 is a legal IRQ number on OMAP 4; GIC IRQ IDs range from 0 to 127. The library code only registers for an rx_irq if one is passed to it by the hwmod definition, but it makes no attempt to embrace the fact that there is a shared IRQ line, not that there is a TX interrupt but no RX interrupt. As such, the IRQ handlers are split, and each assumes that if an interrupt fired, that it either signals a error, or if there is no error, then the TX (or RX) buffer must need service. IOW - the interrupt handlers are not fully decoding their IRQ status registers. To be correct, on systems with a shared IRQ, the handlers would both need to get called (right now, the RX handler is not called), and each handler would need to fully decoder their status, and not assume that because there was no (TX|RX) error, that the (TX|RX) buffers need service. This change fixes the initial issue by checking to see if the IRQ passed from hwmod is > 0 instead of >= 0. While 0 is a legal value for a system IRQ, it is not a legal value for any McBSP IRQ (and almost certainly never will be). I am not doing anything to fix the RX IRQ handler right now, mostly because I don't have a platform to test any changes on. It might be good to bring this to TI's attention, hopefully they can fix their shared IRQ issues themselves. Change-Id: I2f30a036595898f296f642df9a93a77caeec76a5 Signed-off-by: John Grossman <johngro@google.com> Signed-off-by: Ruslan Bilovol <ruslan.bilovol@ti.com>
* OMAP: mcbsp: Fix error checks of rx_irq.Mike J. Chen2012-10-181-2/+2
| | | | | | | | | | rx_irq is intialized via a call to platform_get_irq_byname(), which can return a negative error value. Also, zero is a valid irq. Fix checks that assumed non-zero values were the only valid rx_irq values. Change-Id: I6be171eefa5923021e4adccf71f21baad3383554 Signed-off-by: Mike J. Chen <mjchen@google.com> Signed-off-by: Ruslan Bilovol <ruslan.bilovol@ti.com>
* OMAP: DMA: Set thread reservation for high-priority channelsMisael Lopez Cruz2012-10-121-1/+1
| | | | | | | | | | | Reserve one thread for write and one for read for high-priority channels. This configuration helps latency critical synchronized transfers: memory-peripheral and/or peripheral-memory. Change-Id: Ib8ecf32db126937820b1da04b183568c44143d64 Signed-off-by: Misael Lopez Cruz <misael.lopez@ti.com> Signed-off-by: John Grossman <johngro@google.com> Signed-off-by: Ruslan Bilovol <ruslan.bilovol@ti.com>
* board: tablet: usb: coexisting both HSIC and PHY in single kernel binaryRuslan Bilovol2012-10-051-0/+1
| | | | | | | | | | | | | Added kernel command line parameter 'omap4_tablet_uses_hsic' that allows to have both HSIC and PHY in single kernel binary for Tablet2, this allows to enable HSIC changing only kernel command line Usage: pass 'omap4_tablet_uses_hsic' to kernel through command line in case of HSIC modifications on Tablet2. Do naot apss it in case of traditional PHY usage. Change-Id: I0c50a1af18a26b06ca3957b21c7fa707d870428b Signed-off-by: Ruslan Bilovol <ruslan.bilovol@ti.com>
* ehci: omap: add HSIC disconnect-reconnect functionalityRuslan Bilovol2012-10-051-0/+7
| | | | | | | | | | | Added HSIC disconnect-reconnect functionality using AUX pin. Disconnect or reconnect may be initiated by Device (using AUX pin) as well as by Host (through sysfs entries). Reimplemented .hub_status_data and .hub_control functions, implemented .disconnect and .reconnect ones. Change-Id: If697c06a4ef39ccaabb7c96dbcc0c597e7780515 Signed-off-by: Ruslan Bilovol <ruslan.bilovol@ti.com>
* ARM: OMAP4: Tablet: Add new board revisionVolodymyr Riazantsev2012-09-211-1/+3
| | | | | | | Adding new (2158-004) board revision for Tablet2. Change-Id: I9e3c914f8c79d8b29cd1ebb76509210ecccb33e2 Signed-off-by: Volodymyr Riazantsev <v.riazantsev@ti.com>
* OMAP4: USB: remove unused function twl6030_set_phy_clkRuslan Bilovol2012-09-121-1/+0
| | | | | | | | This function is redundant and not used anywhere. Remove it and change associated code accordingly Change-Id: I06ba222429cfe89a401b426a211d1752e646450a Signed-off-by: Ruslan Bilovol <ruslan.bilovol@ti.com>
* OMAP: clock: Add dummy round_rate and set_rate functionsTaras Kondratiuk2012-09-042-1/+16
| | | | | | | | | Add functions which are going to be used by dummy virtual clocks: long clk_dummy_round_rate(struct clk *clk, unsigned long rate) int clk_dummy_set_rate(struct clk *clk, unsigned long rate) Change-Id: I9bb1e886888a117548d62ef2edd9598bce2723e6 Signed-off-by: Taras Kondratiuk <taras@ti.com>
* ARM: OMAP: PM: Add more information on error pathRuslan Bilovol2012-08-291-1/+4
| | | | | | | | | | | Sometimes if some code tries to remove requested throughput, the message "Invalid Device Structure" is shown. This message is not informative because it's unknown for what device it was tried - so now added more information to that message. Change-Id: Id26bf385dafd4992c8c3487d9dc38935e0fcd777 Signed-off-by: Ruslan Bilovol <ruslan.bilovol@ti.com>
* omap: mailbox: process all messages before suspendShahid Akhtar2012-08-231-2/+2
| | | | | | | | | The mailbox for remote processors must wait for all messages from remote processors to be processed before unregistering block notifiers. Change-Id: I75ae76dacdb95582b5f075690c2c3ecaf99e5f65 Signed-off-by: Shahid Akhtar <sakhtar@ti.com>
* omap: increase default carveout size for DSP to 6MBSuman Anna2012-08-221-1/+1
| | | | | | | | | The default memory carveout size for DSP has been increased from 4MB to 6MB to accomodate adding new libraries to the DSP product base-images. Change-Id: I55b9e0550b93c1d41ecd2452f45b74bfc14bd9b1 Signed-off-by: Suman Anna <s-anna@ti.com>
* omap: rpres: add api to lookup max frequency for a remote deviceJuan Gutierrez2012-08-091-0/+2
| | | | | | | | | | | | | | | | A new public function, rpres_get_max_freq, is added to perform a lookup for the maximum supported frequency from the OPP table for a remote processor device. This API can be used by the remote resource layer in sharing this data to the remote processor application code for performing power related policy decisions. Change-Id: Idbea6884fa47b3bd1f000b6f696fbbcf7036a6ee Signed-off-by: Suman Anna <s-anna@ti.com> Signed-off-by: Juan Gutierrez <jgutierrez@ti.com> Signed-off-by: Paul Hunt <hunt@ti.com> Signed-off-by: Fernando Guzman Lugo <fernando.lugo@ti.com>
* OMAP4: Add platform data to support HDMI default displayMuralidhar Dixit2012-07-172-0/+10
| | | | | | | | | Adding new platform data to support HDMI default display feature. HDMI platform data is selected if HDMI is selected as default display in boot args. Change-Id: Ic5968c4b293e2a1edff61490b2deab2e4af6dbcb Signed-off-by: Muralidhar Dixit <murali.dixit@ti.com>
* OMAP2: correction in early params functions for android-displayMuralidhar Dixit2012-07-171-4/+4
| | | | | | | Correction in early params functions in android-display.c Change-Id: I2bef7e62cc96f75ef23690e29213c8e6d4d545ea Signed-off-by: Muralidhar Dixit <murali.dixit@ti.com>
* OMAP4: DPLL cascading: mute warnings during DPLL cascadingMike Turquette2012-06-181-0/+5
| | | | | | | | | | | | | | | | | | | | | | | | | 1) PM: mute warn from min_bus_tput constraint When the omap_device_set_rate function is called from omap_pm_set_min_bus_tput and fails, a warn is printed. This behavior is normal and expected in DPLL cascading mode, so the warn has been converted to pr_debug to minimize console noise. 2)clock: mute WARN when searching for fieldval This warn is hit every time when entering DPLL cascading. This is due to a workaround implemented in DPLL cascading code which must circumvent the clock framework to change l4_wkup_iclk's parent from SYS_CK to DPLL_ABE's LP output, and back again. During low power MP3 playback it is observed that this warn can disrupt playback by causing a rapid exit/re-entry of the DPLL cascading mode. [Andrii Tseglytskyi <andrii.tseglytskyi@ti.com>: Ported and adapted to p-android-omap-3.0] Change-Id: Id040a4710303845ebc9eeca81c1c06d49f922230 Signed-off-by: Mike Turquette <mturquette@ti.com> Signed-off-by: Andrii Tseglytskyi <andrii.tseglytskyi@ti.com>
* OMAP4: DPLL cascading: Recalibrate Baud Rates for UARTs when the DPLL freq ↵Ruchika Kharwar2012-06-181-0/+5
| | | | | | | | | | | | | | | changes This patch attached the callbacks to DPLL framework to recalib. the baud rates of all the UART's base on the functional clock chnages in the DPLL cascading Low Power mode. [Andrii Tseglytskyi <andrii.tseglytskyi@ti.com>: Ported and adapted to p-android-omap-3.0] Change-Id: If60b3287934f8d780b72b3aa68cbeccd52f99658 Signed-off-by: Ruchika Kharwar <ruchika@ti.com> Signed-off-by: Andrii Tseglytskyi <andrii.tseglytskyi@ti.com>
* omap: common: add kernel API to query RAM sizeDevaraj Rangasamy2012-06-162-0/+19
| | | | | | | | | | | | Add kernel api omap_total_ram_size() to query the exact size of physical ram available in system. Its derived from mem arguments passed to kernel via bootargs and is expected to be used by board files and drivers. Note: omap_init_ram_size() has to be invoked at the earliest during board init to update memory size. Change-Id: I8511fd66ba51343bc64a58db04994af930cbe709 Signed-off-by: Devaraj Rangasamy <dev@ti.com>
* omap: rpmsg: switch over vring memory to use dynamic pool for dspJesse Villarreal2012-06-151-2/+2
| | | | | | | | | | | | | | | | | | The carveout memory for DSP is being switched over to use the dynamically reserved memory pool. The memory addresses used to configure the vring memory is therefore being switched over to use the dynamic memory pool. The vring memory is allocated in the rpmsg layer, while the memory for other firmware sections is assigned by the remoteproc driver. The remoteproc driver adjusts for the utilization of this memory automatically through the presence of the vring carveout section as the first of the carveout sections in the resource table. Change-Id: I5156028450fc7aec813bf3ce9b328acf06059de1 Signed-off-by: Jesse Villarreal <jesse.villarreal@ti.com> Signed-off-by: Suman Anna <s-anna@ti.com>
* OMAP4470: gcx: Add device_scale, bandwith interface functions.Oleg Matcovschi2012-06-011-0/+4
| | | | | | | | Extend device platform data to support device scaling and querying L3 bandwidth. Change-Id: I7e926767ba727bacc0f13543425d43225f815ccd Signed-off-by: Oleg Matcovschi <oleg.matcovschi@ti.com>
* plat-omap: android-display: add 2 extra VRAM buffers for gc320Dima Svetlov2012-05-231-0/+8
| | | | | | | 2 extra VRAM buffers are needed to gc320 composition Change-Id: I5e02392f32a93c2eb12314151cd3a72b44fd4ae9 Signed-off-by: Dima Svetlov <svetlov@ti.com>
* Merge branch wuxga/p-android-omap-3.0-dev into p-android-omap-3.0-devDima Svetlov2012-05-184-0/+300
|\ | | | | | | | | Change-Id: I695b59aeccd2e5cb5a50c6fc734c5d54795f5615 Signed-off-by: Dima Svetlov <svetlov@ti.com>
| * OMAPDSS: DSSCOMP: Added support for back bufer copy for ext displaysSunita Nadampalli2012-05-171-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | In order to decouple the LCD FB and the ext display buffers, sDMA copy based solution is implemented in dsscomp. This patch adds the support for parsing ION handles for buffer addresses and copying FB into user provide buffers (for ext display cloning). Change-Id: I84cfa249e86b863aef9fd9685e1854649f25afc8 Signed-off-by: Sunita Nadampalli <sunitan@ti.com> Signed-off-by: Lajos Molnar <lajos@ti.com> Signed-off-by: Dima Svetlov <svetlov@ti.com>
| * plat-omap: android-display: Set min number of vram buffersPeter Nordström2012-05-171-2/+9
| | | | | | | | | | | | | | | | | | Omapfb requires at least one vram buffer Change-Id: I7d719856e3360314f8bccfba8fcbd3b518496b8b Signed-off-by: Peter Nordström <nordstrom@ti.com> Signed-off-by: Lajos Molnar <lajos@ti.com> Signed-off-by: Dima Svetlov <svetlov@ti.com>
| * OMAP2: generic Android display configuration setupLajos Molnar2012-05-153-0/+286
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Added android_display methods to allow runtime configuration of Android display resources, such as: - FB0's vram is dynamically calculated from the number of buffers SGX requires in VRAM (swap chain and/or composition buffers), and the FB0 display size. - OMAP VRAM is calculated from FB0's vram need + any other specified FB's vram. (If command line is used to specify FB vrams, omap vram must also be specified.) - TILER1D area reserved for use as DSS MMU by DSSCOMP is calculated from default display size. It can be overriden by board file. - TILER2D carveout size is reduced by TILER1D area (if coallocated with TILER2D) and by the TILER2D SGX buffers (swapchain and/or composition buffers) - nonsecure TILER2D carveout size is set to the backpages needed by TILER2D SGX buffers. All of this is coordinated by omap_android_display_setup. It takes pointers to the DSS board info, FB platform data, and optionally to the ION, SGX and DSSCOMP platform data. It should be called in board_reserve before omap_ion_init. If SGX data is provided, it is set as the SGX platform data for FB0. Similarly, if DSSCOMP platform data is provided it is also set. This can be used to set a preferred tiler1d slot size. If ION platform data is provided, it is updated with the required tiler2d carveout sizes. NOTE: To maximize TILER2D space, the TILER1D area reserved for android display is not aligned to 1MB, but is aligned to 32 pages as the smallest 2D allocation needs a 32-page band. We further reduce TILER2D space by the container space lost by the SGX buffers, which may be larger than the actual backpages bneeded for the SGX buffers. Therefore the sum of secure + nonsecure + 1D tiler space may be smaller than the available container space. Ported to latest SGX DDK by Dima Svetlov. Change-Id: I5d8858c38efd842452994e3a3476463083d200d7 Signed-off-by: Lajos Molnar <lajos@ti.com> Signed-off-by: Dima Svetlov <svetlov@ti.com>
| * OMAPDSS: DSSCOMP: Export dsscomp_set_platform_dataLajos Molnar2012-05-151-0/+4
| | | | | | | | | | | | | | | | | | This is used by android-display to set up default tiler1d slot size. Change-Id: Ic6fe49b9338d8ce41c2ac2b444d8ef018ee5fc7a Signed-off-by: Lajos Molnar <lajos@ti.com> Signed-off-by: Dima Svetlov <svetlov@ti.com>
* | omap: rpmsg: bump to max freq while booting remote processorMiguel Vadillo2012-05-172-1/+58
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Reduce the remote processor booting time by bumping to the max frequency. This is achieved by putting in constraints before the loading of the remote processor. The latter is known through the RPROC_PRELOAD notification. Once the remote processor has reached a certain point, it would send a message, RP_MSG_BOOTINIT_DONE via mailbox to notify the host that the remote processor has completed the basic boot and initization. The constraints are released upon receipt of this message. They are also released in case of an error during loading. NOTE: The current implementation used tput api for ipu since freq scale api is not supported directly yet. Change-Id: I1fe936087f00872756c7b532ee58d923e695ff28 Signed-off-by: Miguel Vadillo <vadillo@ti.com> Signed-off-by: Fernando Guzman Lugo <fernando.lugo@ti.com> Signed-off-by: Subramaniam C.A <subramaniam.ca@ti.com> Signed-off-by: Chandra Sekhar.Anagani <chandu@ti.com> Signed-off-by: Suman Anna <s-anna@ti.com>
* | remoteproc: fix obsolete comment about memory_mapsDavid Schleef2012-05-171-1/+0
| | | | | | | | | | | | | | | | | | | | memory_maps in remoteproc platform data has been replaced with memory_pool, but the comment still remained. It has been cleaned up. Change-Id: Iae78c0b8e8d4caccce2fc0248b89a9d18f8d7cca Signed-off-by: David Schleef <ds@ti.com> Signed-off-by: Suman Anna <s-anna@ti.com>
* | OMAP4: IRQ: Fix OMAP44XX_IRQ_CPUIDLE_POKE0 definitionGrygorii Strashko2012-05-151-1/+1
|/ | | | | | | | | | | According to OMAP4470 TRM the MA_IRQ_60 is busy for L3_STAT_ALARM_IRQ L3 NoC statistics collector alarm interrupt. The MA_IRQ_106 is reserved in all OMAP4 chips, so it's selected for using as OMAP44XX_IRQ_CPUIDLE_POKE0. Change-Id: Iba7f727035c71db009defe684a66fb8c58ee3f93 Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com>
* gc320: determine whether context was lost and reset gpuTony Lofthouse2012-05-101-0/+1
| | | | | | | | | If the context is lost this means BB2D_RST is asserted and we will need to take appropriate action. This assumes that resetting the GPU is the limit of this. There could be more. Change-Id: I71ec274e6dd46d0b22c0b1f708eaa3303bef824d Signed-off-by: Tony Lofthouse <a0741364@ti.com>
* ARM: OMAP4: USB: Update workaround for USB errata i719Jon Hunter2012-05-071-0/+3
| | | | | | | | | | | | | | | | | Due to USB errata i719 the USB host save-and-restore context can be corrupted if the device enters off mode more than two times without enabling the USB host controller in between. The corruption is occuring during the software save of the USB context which occurs on entry to every off mode attempt. To avoid this problem only save the USB context if the USB host controller has been enabled since the previous off mode attempt. We do not need to save the USB context on every entry to off mode if the USB controller has not been enabled. Change-Id: I67e07963679af6494ef289eb10db09c0162d6f00 Signed-off-by: Jon Hunter <jon-hunter@ti.com> Signed-off-by: Volodymyr Riazantsev <v.riazantsev@ti.com> Signed-off-by: Ruslan Bilovol <ruslan.bilovol@ti.com>
* gcx: use pm_runtime calls to obtain omap power resources.Tony Lofthouse2012-05-031-1/+0
| | | | | | | | | | | These are the proper PM apis to use for GC320. Remove explicit usage of the bb2d fclk. Remove idle wait check. Any handling of prcm wait states should be done in the hwmod if needed in the future. Change-Id: I16a53e98fa4c1efca512b7506e2fe9934e9b185f Signed-off-by: Tony Lofthouse <a0741364@ti.com>
* gcx: driver cleanup.David Sin2012-05-031-0/+1
| | | | | | | | | Remove unused flush pages function. Replace hardcoded irq value with proper method. Remove hardcoded 2d base address & direct allocation. Change-Id: I79c1089db935bfddc17e85f761113e3f709738b6 Signed-off-by: David Sin <davidsin@ti.com>
* omap: remoteproc: add a notification for loading errorMiguel Vadillo2012-05-031-0/+14
| | | | | | | | | | | | | | | | | | When calling rproc_get for the first time, the loading of the remoteproc image will be requested using a non-blocking request_firmware_no_wait, and the caller can continue before the actual loading is complete. The loader later can return an error due to a non-existing or wrong image and there should be a way to notify about this to users having a rproc handle. This functionality is added and is leveraged by rpmsg to release some resources it had already acquired since requesting a firmware load. Change-Id: I1d3523efbcfd613bca74d363084791ceaaaa9989 Signed-off-by: Miguel Vadillo <vadillo@ti.com>
* omap_gcx: enhance to provide omap operationsTony Lofthouse2012-04-201-0/+26
| | | | | | | | | | | In order to provide the gccore driver a function to check the state of the prcm, we will put a function pointer in the gcx platform device. The previous platform device entries were not used by the gccore driver. Change-Id: I7e3f1755261d99fe022964a2a26db6ba7f42092e Signed-off-by: Tony Lofthouse <a0741364@ti.com>
* omap: mailbox: add pm constraint field to mbox structureSubramaniam C.A2012-04-182-9/+11
| | | | | | | | | | By adding this field, the pm qos apis can be selectively applied only if the pm constraint is set to a +ve value. Change-Id: I3b6930e85f65f7354826813798dec76b25149370 Signed-off-by: Subramaniam C.A <subramaniam.ca@ti.com> Signed-off-by: Omar Ramirez Luna <omar.ramirez@ti.com> Signed-off-by: Suman Anna <s-anna@ti.com>
* omap: iommu: program constraints based on platform dataSubramaniam C.A2012-04-182-15/+19
| | | | | | | | | | | | | | | | | | | | IOMMU driver requests and releases constraints in iommu_get and iommu_put respectively. These constraints are actually needed only on OMAP4 and beyond for sub-systems that have an AMMU. The current driver code has these values hard-coded for all the chips. A new platform data field has been added now for the constraints values, and this allows the values to be programmed based on the OMAP chip and also allow a unique value if needed for each iommu instance. The logic in IOMMU driver code is adjusted to request the constraints only if the relevant platform data field is set. Change-Id: Iab18cbdde1d7fa7507dbff0b9512c8577b42fefd Signed-off-by: Subramaniam C.A <subramaniam.ca@ti.com> Signed-off-by: Suman Anna <s-anna@ti.com>
* sgx_omaplfb: Create omaplfb platform device file to permit device configurationTony Lofthouse2012-04-163-0/+153
| | | | | | Change-Id: Ic790a0440d19d862d981a230470523409b25b9a3 Signed-off-by: Tony Lofthouse <a0741364@ti.com> Signed-off-by: Gustavo Diaz Prado <a0273371@ti.com>
* omap: Adds access_process_vm to gpu platform dataRogelio Garcia2012-03-221-0/+2
| | | | | | | | This core API function is needed by modular PVR driver. Change-Id: I409bf934aa3c2566f468715e490c911b97b247bc Signed-off-by: Rogelio Garcia <rgarcia@ti.com> Signed-off-by: Atanas (Tony) Zlatinski <zlatinski@gmail.com>
* OMAP: clock: fix race in disable all clocksNishanth Menon2012-03-161-2/+3
| | | | | | | | | | | | | | | | | | | | | | | | clk_disable_unused is invoked when CONFIG_OMAP_RESET_CLOCKS=y. Since clk_disable_unused is called as lateinitcall, there can be more than a few workqueues executing off secondary CPU(s). The current code does the following: a) checks if clk is unused b) holds lock c) disables clk d) unlocks Between (a) and (b) being executed on CPU0, It is possible to have a driver executing on CPU1 which could do a get_sync->clk_get (and increase the use_count) of the clock which was just about to be disabled by clk_disable_unused. We ensure instead that the entire list traversal is protected by the lock allowing for parent child clock traversal which could be potentially be done by runtime operations to be safe as well. Change-Id: Iea5201233d89b8417576df4ed9026e1c05001596 Reported-by: Todd Poynor <toddpoynor@google.com> Signed-off-by: Nishanth Menon <nm@ti.com>
* OMAP4: ID: Add high IVA OPPs identificationTaras Kondratiuk2012-03-151-0/+4
| | | | | | | | Some 4460 and 4470 devices support IVA OPPNT and OPPSB. Add flags to identify this feature. Change-Id: I6e78d95ca07435c60aae36562a2d9b66fcd1baa4 Signed-off-by: Taras Kondratiuk <taras@ti.com>
* omap: Adding opp functions to gpu platform data.Rogelio Garcia2012-03-141-0/+3
| | | | | | | This is required for providing opp framework access to SGX kernel module. Change-Id: Ie968a6c51ac636b70909257be4c51430c4cc3d48 Signed-off-by: Rogelio Garcia <rgarcia@ti.com>
* omap: remoteproc: use device-specific dump-register opsJuan Gutierrez2012-03-141-0/+77
| | | | | | | | | | | | | | | The current omap register dump function is catering only to ARM cores. Introduce device-specific dump register functions so that the omap remoteproc code can call into them based on the processor type. This patch also adds a minimal support for dumping dsp registers in addition to moving the existing functionality for ARM cores to the device-specific function. Change-Id: Ic446695a6a5a1a4b1f600c1900f74c3e5932c158 Signed-off-by: Juan Gutierrez <jgutierrez@ti.com> Signed-off-by: Suman Anna <s-anna@ti.com>
* omap: rpmsg: add dsp as a virtio rproc deviceJuan Gutierrez2012-03-141-0/+18
| | | | | | | | | | | | | Add a dsp virtio rproc device to the omap_rpmsg_vproc array, so that the corresponding virtio device can be created and registered with the virtio bus. The device is included only if the dsp remote rproc is enabled. Change-Id: Ie33f9a8bee7b1a3c603fe8f33a44a4c8f01426e2 Signed-off-by: Juan Gutierrez <jgutierrez@ti.com> Signed-off-by: Suman Anna <s-anna@ti.com>
* omap: add dsp carveout for remoteproc functionalityJuan Gutierrez2012-03-145-9/+98
| | | | | | | | | | | | | | | | | | | | | | | remoteproc uses DDR carveout memories for the functionality of different rproc instances. New interfaces have been added to perform this carveout memory during board initialization for DSP. This patch reserves two types of carveout memory - one whose address is dynamic, and another that leverages a fixed static range. The dynamic pool will be used for allocating memory for firmware sections that have no physical memory allocated. The static pool will be used to validate the firmware sections with fixed physical addresses. This patch also assigns addresses for the Virtio vring buffers for DSP. This is previously not handled, and the buffers are currently assigned from the static pool associated with the dsp. The rpmsg bus initialization sequence is enhanced to process all the vprocs even if an earlier one in the list fails due to memory requirements. Change-Id: I0dec512b63904d3ffe0867ce00150b6c21a80805 Signed-off-by: Juan Gutierrez <jgutierrez@ti.com> Signed-off-by: Suman Anna <s-anna@ti.com>
* omap: add ipu and dsp as configurable remoteproc instancesJuan Gutierrez2012-03-144-3/+11
| | | | | | | | | | | | | | | | | OMAP4 and OMAP5 both support two remoteproc instances - ipu & dsp. The CONFIG_OMAP_REMOTE_PROC menuconfig option enabled support for all OMAP remoteproc instances, but there was no choice to enable/disable a specific remoteproc instance. This patch adds two additional dependent config options for finer control over these remoteproc instances. The option CONFIG_OMAP_REMOTE_PROC will continue to be the generic option for enabling remoteproc driver support for OMAP. Change-Id: I9688672e4c758b9e4f4c0fb4f83654ef7b3cf48f Signed-off-by: Juan Gutierrez <jgutierrez@ti.com> Signed-off-by: Suman Anna <s-anna@ti.com> Signed-off-by: Subramaniam C.A <subramaniam.ca@ti.com>
* omap: remoteproc: add support for a boot registerJuan Gutierrez2012-03-141-0/+2
| | | | | | | | | | | | | | | | | | | Some remote processors (like DSP) need to explicitly configure a boot address in a special register or memory location, and this is the address from which they start executing code when taken out of reset. Support for this infrastructure has been added to remoteproc code. The memory or register address where the boot address is to be stored is supplied through the boot_reg field of the platform data in the remoteproc. The omap_rproc_start function will fetch the boot address from the image, and write this address into the boot register, if provided, before taking the processor out of reset. Change-Id: I4efc5824791eda6e23e5d568f4568a3fe3d0014b Signed-off-by: Juan Gutierrez <jgutierrez@ti.com> Signed-off-by: Suman Anna <s-anna@ti.com>
* omap: iommu: apply latency constraint based on power domainJuan Gutierrez2012-03-141-4/+29
| | | | | | | | | | | | | When the iommu is taken out of reset, a latency constraint is set to avoid its power domain going to retention/off. The iommus for DSP and M3 reside in DSP and Core power domains respectively, and therefore the API for setting the constraints is different. This patch uses the appropriate API depending on the iommu (power domain) the latency constraint is being applied on. Change-Id: I3fa4485b3c405aa10c32a3fe0b7ac694d484ee21 Signed-off-by: Juan Gutierrez <jgutierrez@ti.com> Signed-off-by: Subramaniam C.A <subramaniam.ca@ti.com>
generated by cgit v1.1 at 2025-01-19 00:23:22 +0000