- 09 10月, 2012 1 次提交
-
-
由 Paul Walmsley 提交于
Commit eb05f691 ("ARM: OMAP: hwmod: partially un-reset hwmods might not be properly enabled") added code to skip the IP block disable sequence if all of the block's hardreset lines weren't asserted. But this did not handle the case when no hardreset lines were associated with a module, which is the general case. In that situation, the IP block disable would be skipped. This is likely to cause PM regressions. So, modify _omap4_disable_module() and _am33xx_disable_module() to only bail out early if there are any hardreset lines asserted. And move the AM33xx test above the actual module disable code to ensure that the behavior is consistent. Reported-by: NArchit Taneja <a0393947@ti.com> Tested-by: Archit Taneja <a0393947@ti.com> # DSS Cc: Omar Ramirez Luna <omar.luna@linaro.org> Cc: Vaibhav Hiremath <hvaibhav@ti.com> Acked-by: NVaibhav Hiremath <hvaibhav@ti.com> Tested-by: Vaibhav Hiremath <hvaibhav@ti.com> # AM335x Signed-off-by: NPaul Walmsley <paul@pwsan.com>
-
- 24 9月, 2012 5 次提交
-
-
由 Paul Walmsley 提交于
The idle status of the IP blocks and clocks inside the EMU clockdomain isn't taken into account by the PRCM hardware when deciding whether the clockdomain is idle. Add a workaround flag in the clockdomain code, CLKDM_MISSING_IDLE_REPORTING, to deal with this problem, and add the code necessary to support it. If CLKDM_MISSING_IDLE_REPORTING is set on a clockdomain, the clockdomain will be forced active whenever an IP block inside that clockdomain is in use, even if the clockdomain supports hardware-supervised idle. When the kernel indicates that the last active IP block inside the clockdomain is no longer used, the clockdomain will be forced idle, or, if that mode is not supported in the hardware, it will be placed into hardware-supervised idle. This patch is an equal collaboration with Jon Hunter <jon-hunter@ti.com>. Ming Lei <ming.lei@canonical.com>, Will Deacon <will.deacon@arm.com>, Madhav Vij <mvij@ti.com>, Kevin Hilman <khilman@ti.com>, Benoît Cousson <b-cousson@ti.com>, and Santosh Shilimkar <santosh.shilimkar@ti.com> all made essential contributions to the understanding of EMU clockdomain power management on OMAP. Signed-off-by: NPaul Walmsley <paul@pwsan.com> Cc: Jon Hunter <jon-hunter@ti.com> Cc: Ming Lei <ming.lei@canonical.com> Cc: Will Deacon <will.deacon@arm.com> Cc: Madhav Vij <mvij@ti.com> Cc: Kevin Hilman <khilman@ti.com> Cc: Benoît Cousson <b-cousson@ti.com> Cc: Santosh Shilimkar <santosh.shilimkar@ti.com> Tested-by: NJon Hunter <jon-hunter@ti.com>
-
由 Omar Ramirez Luna 提交于
For a reset sequence to complete cleanly, a module needs its associated clocks to be enabled, otherwise the timeout check in prcm code can print a false failure (failed to hardreset) that occurs because the clocks aren't powered ON and the status bit checked can't transition without them. Signed-off-by: NOmar Ramirez Luna <omar.luna@linaro.org> Signed-off-by: NPaul Walmsley <paul@pwsan.com>
-
由 Omar Ramirez Luna 提交于
Some IP blocks might not be using/controlling more than one reset line, this check loosens the restriction to fully use hwmod framework for those drivers. E.g.: ipu has reset lines: mmu_cache, cpu0 and cpu1. - As of now cpu1 is not used and hence (with previous check) the IP block isn't fully enabled by hwmod code. - Usually ipu and dsp processors configure their mmu module first and then enable the processors, this involves: * Deasserting mmu reset line, and enabling the module. * Deasserting cpu0 reset line, and enabling the processor. The ones portrayed in this example are controlled through rproc_fw_boot in drivers/remoteproc/remoteproc_core.c While at it, prevent _omap4_module_disable if all the hardreset lines on an IP block are not under reset. This will allow the driver to: a. Deassert the reset line. b. Enable the hwmod through runtime PM default callbacks. c. Do its usecase. d. Disable hwmod through runtime PM. e. Assert the reset line. Signed-off-by: NOmar Ramirez Luna <omar.luna@linaro.org> [paul@pwsan.com: updated to apply] Signed-off-by: NPaul Walmsley <paul@pwsan.com>
-
由 Paul Walmsley 提交于
The decision was made a few months ago to allow struct omap_hwmod records and struct clk records to omit clockdomain information if the clockdomain is not software-controllable. See for example commit 868c157d ("ARM: OMAP2+: hwmod: remove prm_clkdm, cm_clkdm; allow hwmods to have no clockdomain"). So convert an existing pr_warning() to a pr_debug() (regarding missing clockdomains in clocks), and add a pr_debug() for missing hwmod clockdomains. It's still useful to enable these messages for debugging, since missing clockdomains can cause hard-to-debug problems with power management; see for example commit 6c4a057b ("ARM: OMAP4: clock data: Force a DPLL clkdm/pwrdm ON before a relock"). Signed-off-by: NPaul Walmsley <paul@pwsan.com> Cc: Benoît Cousson <b-cousson@ti.com>
-
由 Paul Walmsley 提交于
We're no longer requiring struct omap_hwmod records to contain a clockdomain. So we shouldn't return -EINVAL any more from _omap4_wait_target_disable() or _omap4_wait_target_ready() if there's no clockdomain defined, since that just gets passed back to the caller. This can result in pointless warnings under the relaxed data format. Signed-off-by: NPaul Walmsley <paul@pwsan.com> Cc: Benoît Cousson <b-cousson@ti.com>
-
- 23 9月, 2012 3 次提交
-
-
由 Rajendra Nayak 提交于
While we move to Common Clk Framework (CCF), direct deferencing of struct clk wouldn't be possible anymore. Hence get rid of all such instances in the current clock code and use macros/helpers similar to the ones that are provided by CCF. While here also concatenate some strings split across multiple lines which seem to be needed anyway. Signed-off-by: NRajendra Nayak <rnayak@ti.com> [paul@pwsan.com: simplified some compound expressions; reformatted some messages] Signed-off-by: NPaul Walmsley <paul@pwsan.com> Cc: Mike Turquette <mturquette@linaro.org>
-
由 Rajendra Nayak 提交于
Moving to Common clk framework for OMAP would mean we no longer use internal lookup mechanism like omap_clk_get_by_name(). get rid of all its usage mostly from hwmod and omap_device code. Moving to clk_get() also means the respective platforms need the clkdev tables updated with an entry for all clocks used by hwmod to have clock name same as the alias. Based on original changes from Mike Turquette. Signed-off-by: NRajendra Nayak <rnayak@ti.com> Cc: Russell King - ARM Linux <linux@arm.linux.org.uk> [paul@pwsan.com: removed IS_ERR_OR_NULL() conversion (rmk comment); restricted omap_96m_alwon_fck_3630 to OMAP36xx; added missing AM35xx clock aliases for emac_fck, emac_ick, vpfe_ick, vpfe_fck; added aliases rng_ick and several emulation clocks] Signed-off-by: NPaul Walmsley <paul@pwsan.com>
-
由 Rajendra Nayak 提交于
As part of Common Clk Framework (CCF) the clk_enable() operation was split into a clk_prepare() which could sleep, and a clk_enable() which should never sleep. Similarly the clk_disable() was split into clk_disable() and clk_unprepare(). This was needed to handle complex cases where in a clk gate/ungate would require a slow and a fast part to be implemented. None of the clocks below seem to be in the 'complex' clocks category and are just simple clocks which are enabled/disabled through simple register writes. Most of the instances also seem to be called in non-atomic context which means its safe to move all of those from using a clk_enable() to clk_prepare_enable() and clk_disable() to clk_disable_unprepare(). For some others, mainly the ones handled through the hwmod framework there is a possibility that they get called in either an atomic or a non-atomic context. The way these get handled below work only as long as clk_prepare is implemented as a no-op (which is the case today) since this gets called very early at boot while most subsystems are unavailable. Hence these are marked with a *HACK* comment, which says we need to re-visit these once we start doing something meaningful with clk_prepare/clk_unprepare like doing voltage scaling or something that involves i2c. This is in preparation of OMAP moving to CCF. Based on initial changes from Mike Turquette. Signed-off-by: NRajendra Nayak <rnayak@ti.com> Signed-off-by: NPaul Walmsley <paul@pwsan.com>
-
- 13 9月, 2012 1 次提交
-
-
由 Tony Lindgren 提交于
As the plat and mach includes need to disappear for single zImage work, we need to remove plat/hardware.h. Do this by splitting plat/hardware.h into omap1 and omap2+ specific files. The old plat/hardware.h already has omap1 only defines, so it gets moved to mach/hardware.h for omap1. For omap2+, we use the local soc.h that for now just includes the related SoC headers to keep this patch more readable. Note that the local soc.h still includes plat/cpu.h that can be dealt with in later patches. Let's also include plat/serial.h from common.h for all the board-*.c files. This allows making the include files local later on without patching these files again. Note that only minimal changes are done in this patch for the drivers/watchdog/omap_wdt.c driver to keep things compiling. Further patches are needed to eventually remove cpu_is_omap usage in the drivers. Also only minimal changes are done to sound/soc/omap/* to remove the unneeded includes and to define OMAP44XX_MCPDM_L3_BASE locally so there's no need to include omap44xx.h. While at it, also sort some of the includes in the standard way. Cc: linux-watchdog@vger.kernel.org Cc: alsa-devel@alsa-project.org Cc: Peter Ujfalusi <peter.ujfalusi@ti.com> Cc: Jarkko Nikula <jarkko.nikula@bitmer.com> Cc: Liam Girdwood <lrg@ti.com> Acked-by: NWim Van Sebroeck <wim@iguana.be> Acked-by: NMark Brown <broonie@opensource.wolfsonmicro.com> Signed-off-by: NTony Lindgren <tony@atomide.com>
-
- 12 9月, 2012 3 次提交
-
-
由 Paul Walmsley 提交于
Find and unwrap wrapped strings in the style: pr_debug("clockdomain: hardware cannot set/clear wake up of " "%s when %s wakes up\n", clkdm1->name, clkdm2->name); Keeping these strings contiguous seems to be the current Linux kernel policy. The offending lines were found with the following command: pcregrep -rnM '"\s*$\s*"' arch/arm/*omap* While here, some messages have been clarified, some pr_warning( ... calls have been converted to pr_warn( ..., and some printk(KERN_* ... have been converted to pr_*. Signed-off-by: NPaul Walmsley <paul@pwsan.com>
-
由 Paul Walmsley 提交于
Resolve the following warnings from smatch: arch/arm/mach-omap2/gpmc.c:282 gpmc_cs_set_timings() info: why not propagate 'div' from gpmc_cs_calc_divider() instead of -1? arch/arm/mach-omap2/serial.c:328 omap_serial_init_port() error: 'pdev' dereferencing possible ERR_PTR() arch/arm/mach-omap2/timer.c:213 omap2_gp_clockevent_init() Error invalid range 4096 to -1 arch/arm/mach-omap2/gpio.c:63 omap2_gpio_dev_init() warn: possible memory leak of 'pdata' arch/arm/mach-omap2/omap_hwmod.c:1478 _assert_hardreset() warn: assigning -22 to unsigned variable 'ret' arch/arm/mach-omap2/omap_hwmod.c:1487 _assert_hardreset() warn: 4294963201 is more than 255 (max '(ret)' can be) so this is always the same. arch/arm/mach-omap2/omap_hwmod.c:1545 _read_hardreset() warn: assigning -22 to unsigned variable 'ret' arch/arm/mach-omap2/omap_hwmod.c:1554 _read_hardreset() warn: 4294963201 is more than 255 (max '(ret)' can be) so this is always the same. arch/arm/mach-omap2/dpll3xxx.c:629 omap3_clkoutx2_recalc() error: we previously assumed 'pclk' could be null (see line 627) arch/arm/mach-omap2/board-n8x0.c:422 n8x0_mmc_late_init() Error invalid range 14 to 13 arch/arm/mach-omap1/leds-h2p2-debug.c:71 h2p2_dbg_leds_event() error: potentially derefencing uninitialized 'fpga'. arch/arm/plat-omap/mux.c:79 omap_cfg_reg() Error invalid range 4096 to -1 Thanks to Tony Lindgren <tony@atomide.com> for pointing out that BUG() can be disabled. The changes in the first version that removed the subsequent return() after BUG() states have been dropped. Signed-off-by: NPaul Walmsley <paul@pwsan.com> Cc: Tony Lindgren <tony@atomide.com>
-
由 Vaibhav Hiremath 提交于
AM33XX PRCM architecture is different that any OMAP family of devices, so it is required to have separate implementation to handle AM33XX module enable/disable, reset assert/deassert functionality. This patch adds wrapper api's in omap_hwmod framework to access prm/cm for AM33XX family of devices. Signed-off-by: NVaibhav Hiremath <hvaibhav@ti.com> Cc: Paul Walmsley <paul@pwsan.com> Cc: Kevin Hilman <khilman@ti.com> Cc: Tony Lindgren <tony@atomide.com> [paul@pwsan.com: fixed checkpatch messages] Signed-off-by: NPaul Walmsley <paul@pwsan.com>
-
- 08 9月, 2012 1 次提交
-
-
由 Vaibhav Hiremath 提交于
With the new devices (like, AM33XX and OMAP5) we now only support DT boot mode of operation and now it is the time to start killing slowly the dependency on hwmod, so with this patch, we are starting with device resources. The idea here is implemented considering to both boot modes - - DT boot mode OF framework will construct the resource structure (currently does for MEM & IRQ resource) and we should respect/use these resources, killing hwmod dependency. If pdev->num_resources > 0, we assume that MEM & IRQ resources have been allocated by OF layer already (through DTB). Once DMA resource is available from OF layer, we should kill filling any resources from hwmod. - Non-DT boot mode Here, pdev->num_resources = 0, and we should get all the resources from hwmod (following existing steps) Signed-off-by: NVaibhav Hiremath <hvaibhav@ti.com> Cc: Tony Lindgren <tony@atomide.com> Cc: Paul Walmsley <paul@pwsan.com> Cc: Kevin Hilman <khilman@ti.com> [b-cousson@ti.com: Fix some checkpatch CHECK issues] Signed-off-by: NBenoit Cousson <b-cousson@ti.com>
-
- 04 9月, 2012 1 次提交
-
-
由 Misael Lopez Cruz 提交于
Clock and module mode are explictly enable when hwmod is enabled. But if the hwmod doesn't get ready on time, clocks are disabled but module is left enabled. Signed-off-by: NMisael Lopez Cruz <misael.lopez@ti.com> Signed-off-by: NRajendra Nayak <rnayak@ti.com> Cc: Paul Walmsley <paul@pwsan.com> Cc: Benoit Cousson <b-cousson@ti.com> Signed-off-by: NPaul Walmsley <paul@pwsan.com>
-
- 09 7月, 2012 1 次提交
-
-
由 R Sricharan 提交于
OMAP5430 is Texas Instrument's SOC based on ARM Cortex-A15 SMP architecture. It's a dual core SOC with GIC used for interrupt handling and with an integrated L2 cache controller. OMAP5432 is another variant of OMAP5430, with a memory controller supporting DDR3 and SATA. Patch includes: - The machine specific headers and sources updates. - Platform header updates. - Minimum initialisation support for serial. - IO table init Signed-off-by: NR Sricharan <r.sricharan@ti.com> Signed-off-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
-
- 06 7月, 2012 2 次提交
-
-
由 Tony Lindgren 提交于
Commit ac5b0ea3 (Merge tag 'omap-devel-f-for-3.6'...) had a merge conflict that somehow got incorrecly resolved in a lossy way for commit bed9d1bb (ARM: OMAP2+: hwmod: add omap_hwmod_get_main_clk() API). Fix the issue by applying the missing pieces. Reported-by: NSantosh Shilimkar <santosh.shilimkar@ti.com> Signed-off-by: NTony Lindgren <tony@atomide.com>
-
由 Paul Walmsley 提交于
Kevin discovered that commit c8d82ff6 ("ARM: OMAP2/3: hwmod data: Add 32k-sync timer data to hwmod database") broke CORE idle on OMAP3. This prevents device low power states. The root cause is that the 32K sync timer IP block does not support smart-idle mode[1], and so the hwmod code keeps the IP block in no-idle mode while it is active. This in turn prevents the WKUP clockdomain from transitioning to idle. There is a hardcoded sleep dependency that prevents the CORE_L3 and CORE_CM clockdomains from transitioning to idle when the WKUP clockdomain is active[2], so the chip cannot enter any device low power states. It turns out that there is no need to take the 32k sync timer out of idle. The IP block itself probably does not have any native idle handling at all, due to its simplicity. Furthermore, the PRCM will never request target idle for this IP block while the kernel is running, due to the sleep dependency that prevents the WKUP clockdomain from idling while the CORE_L3 clockdomain is active. So we can safely leave the 32k sync timer in target-force-idle mode, even while we continue to access it. This workaround is implemented by defining a new clockdomain flag, CLKDM_ACTIVE_WITH_MPU, that indicates that the clockdomain is guaranteed to be active whenever the MPU is inactive. If an IP block's main functional clock exists inside this clockdomain, and the IP block does not support smart-idle modes, then the hwmod code will place the IP block into target force-idle mode even when enabled. The WKUP clockdomains on OMAP3/4 are marked with this flag. (On OMAP2xxx, no OCP header existed on the 32k sync timer.) Other clockdomains also should be marked with this flag, but those changes are deferred until a later merge window, to create a minimal fix. Another theoretically clean fix for this problem would be to implement PM runtime-based control for 32k sync timer accesses. These PM runtime calls would need to located in a custom clocksource, since the 32k sync timer is currently used as an MMIO clocksource. But in practice, there would be little benefit to doing so; and there would be some cost, due to the addition of unnecessary lines of code and the additional CPU overhead of the PM runtime and hwmod code - unnecessary in this case. Another possible fix would have been to modify the pm34xx.c code to force the IP block idle before entering WFI. But this would not have been an acceptable approach: we are trying to remove this type of centralized IP block idle control from the PM code. This patch is a collaboration between Kevin Hilman <khilman@ti.com> and Paul Walmsley <paul@pwsan.com>. Thanks to Vaibhav Hiremath <hvaibhav@ti.com> for providing comments on an earlier version of this patch. Thanks to Tero Kristo <t-kristo@ti.com> for identifying a bug in an earlier version of this patch. Thanks to Benoît Cousson <b-cousson@ti.com> for identifying some bugs in several versions of this patch and for implementation comments. References: 1. Table 16-96 "REG_32KSYNCNT_SYSCONFIG" of the OMAP34xx TRM Rev. ZU (SWPU223U), available from: http://www.ti.com/pdfs/wtbu/OMAP34x_ES3.1.x_PUBLIC_TRM_vzU.zip 2. Table 4-72 "Sleep Dependencies" of the OMAP34xx TRM Rev. ZU (SWPU223U) 3. ibid. Cc: Tony Lindgren <tony@atomide.com> Cc: Vaibhav Hiremath <hvaibhav@ti.com> Cc: Benoît Cousson <b-cousson@ti.com> Cc: Tero Kristo <t-kristo@ti.com> Tested-by: NKevin Hilman <khilman@ti.com> Signed-off-by: NPaul Walmsley <paul@pwsan.com> Signed-off-by: NKevin Hilman <khilman@ti.com>
-
- 04 7月, 2012 2 次提交
-
-
由 Kishon Vijay Abraham I 提交于
The DMADISABLE bit is a semi-automatic bit present in sysconfig register of some modules. When the DMA must perform read/write accesses, the DMADISABLE bit is cleared by the hardware. But when the DMA must stop for power management, software must set the DMADISABLE bit back to 1. In cases where the ROMCODE/BOOTLOADER uses dma, the hardware clears the DMADISABLE bit (but the romcode/bootloader might not set it back to 1). In order for the kernel to start in a clean state, it is necessary for the kernel to set DMADISABLE bit back to 1 (irrespective of whether it's been set to 1 in romcode or bootloader). During _reset of the (hwmod)device, the DMADISABLE bit is set so that it does not prevent idling of the system. (NOTE: having DMADISABLE to 0, prevents the system to idle) DMADISABLE bit is present in usbotgss module of omap5. Cc: Benoit Cousson <b-cousson@ti.com> Cc: Kevin Hilman <khilman@ti.com> Cc: Paul Walmsley <paul@pwsan.com> Signed-off-by: NKishon Vijay Abraham I <kishon@ti.com> [paul@pwsan.com: updated to apply; fixed checkpatch warnings] Signed-off-by: NPaul Walmsley <paul@pwsan.com>
-
由 Tarun Kanti DebBarma 提交于
Add an API to get main clock name associated with a given @oh. This will avoid the need to construct fclk names during early initialization in order to get fclk handle using clk_get(). Signed-off-by: NTarun Kanti DebBarma <tarun.kanti@ti.com> Cc: Benoit Cousson <b-cousson@ti.com> Cc: Paul Walmsley <paul@pwsan.com> Cc: Tony Lindgren <tony@atomide.com> Cc: Kevin Hilman <khilman@ti.com> Cc: Rajendra Nayak <rnayak@ti.com> Cc: Santosh Shilimkar <santosh.shilimkar@ti.com> Acked-by: NBenoit Cousson <b-cousson@ti.com> Signed-off-by: NPaul Walmsley <paul@pwsan.com>
-
- 22 6月, 2012 2 次提交
-
-
由 Vishwanath BS 提交于
IO Daisychain feature has to be triggered whenever there is a change in device's mux configuration (See section 3.9.4 in OMAP4 Public TRM vP). Now devices can idle independent of the powerdomain, there can be a window where device is idled and corresponding powerdomain can be ON/INACTIVE state. In such situations, since both module wake up is enabled at padlevel as well as io daisychain sequence is triggered, there will be 2 PRCM interrupts (Module async wake up via swakeup and IO Pad interrupt). But as PRCM Interrupt handler clears the Module Padlevel WKST bit in the first interrupt, module specific interrupt handler will not triggered for the second time Also look at detailed explanation given by Rajendra at http://www.spinics.net/lists/linux-serial/msg04480.htmlSigned-off-by: NVishwanath BS <vishwanath.bs@ti.com> Signed-off-by: NTero Kristo <t-kristo@ti.com> Reviewed-by: NRajendra Nayak <rnayak@ti.com> [paul@pwsan.com: remove dependency on pm.c & pm.h; add kerneldoc] Signed-off-by: NPaul Walmsley <paul@pwsan.com>
-
由 Djamil Elaidi 提交于
If an IP is configured in Smart-Standby-Wakeup, when disabling wakeup feature the IP will not go back to Smart-Standby, but will remain in Smart-Standby-Wakeup. Signed-off-by: NDjamil Elaidi <d-elaidi@ti.com> Signed-off-by: NPaul Walmsley <paul@pwsan.com>
-
- 20 6月, 2012 1 次提交
-
-
由 Paul Walmsley 提交于
Remove prm_clkdm and cm_clkdm and allow hwmods to have no clockdomain. Signed-off-by: NPaul Walmsley <paul@pwsan.com> Cc: Benoît Cousson <b-cousson@ti.com>
-
- 19 6月, 2012 6 次提交
-
-
由 Kevin Hilman 提交于
Rather than use runtime cpu_is* checking inside _init_clkdm, initialize SoC specific function pointer at init time. Signed-off-by: NKevin Hilman <khilman@ti.com> [paul@pwsan.com: convert to use soc_ops function pointers; remove second para from commit message since soc_ops function pointers are now set during hwmod layer init] Signed-off-by: NPaul Walmsley <paul@pwsan.com>
-
由 Kevin Hilman 提交于
Rather than using cpu_is* checking at runtime, initialize SoC specific function pointers for the various hard reset functions at init time. Signed-off-by: NKevin Hilman <khilman@ti.com> [paul@pwsan.com: convert to use soc_ops function pointers; add kerneldoc] Signed-off-by: NPaul Walmsley <paul@pwsan.com>
-
由 Kevin Hilman 提交于
Rather than using cpu_is* checking at runtime, initialize an SoC specific function pointer for wait_target_ready(). While here, downgrade the BUG() to a WARN_ON() so it gives a noisy warning instead of causing a kernel panic. Signed-off-by: NKevin Hilman <khilman@ti.com> [paul@pwsan.com: convert to use soc_ops function pointers; add kerneldoc; move soc_ops functions to their own section in the code; integrated the _wait_target_ready() function with the OMAP2/OMAP4 variants; renamed the wait_module_ready field to wait_target_ready] Signed-off-by: NPaul Walmsley <paul@pwsan.com>
-
由 Kevin Hilman 提交于
_omap4_wait_target_disable() is called only from inside _omap4_disable_module() which is already protected by SoC specific checks. Remove the cpu_is check here. Signed-off-by: NKevin Hilman <khilman@ti.com>
-
由 Kevin Hilman 提交于
The enable/disable module functions are specific to SoCs with OMAP4-class PRCM. Rather than use cpu_is* checks at runtime inside the enable/disable module functions, use cpu_is at init time to initialize function pointers only for SoCs that need them. NOTE: the cpu_is* check for _enable_module was different than the one for _disable_module, and this patch uses cpu_is_omap44xx() for both. Signed-off-by: NKevin Hilman <khilman@ti.com> [paul@pwsan.com: moved soc_ops function pointers to be per-kernel rather than per-hwmod since they do not vary by hwmod; added kerneldoc] Signed-off-by: NPaul Walmsley <paul@pwsan.com>
-
由 Kevin Hilman 提交于
_enable_module is specific to SoCs with PRCM interfaces similar to that of the OMAP4, so rename it to be consistent with the corresponding _omap4_disable_module. Signed-off-by: NKevin Hilman <khilman@ti.com> [paul@pwsan.com: tweaked commit message] Signed-off-by: NPaul Walmsley <paul@pwsan.com>
-
- 19 4月, 2012 11 次提交
-
-
由 Paul Walmsley 提交于
Now that the data has been converted to use interface registration, we can remove the (now unused) direct hwmod registration code. Signed-off-by: NPaul Walmsley <paul@pwsan.com> Cc: Benoît Cousson <b-cousson@ti.com>
-
由 Paul Walmsley 提交于
Add support for direct IP block interconnect ("link") registration to the hwmod code via a new function, omap_hwmod_register_links(). This will replace direct registration of hwmods, and a subsequent patch will remove omap_hwmod_register(). This change will allow a subsequent patch to remove the hwmod data link arrays. This will reduce the size of the hwmod static data and also make it easier to generate the data files. It will also make it possible to share some of the struct omap_hwmod records across multiple SoCs, since the link array pointers will be removed from the struct omap_hwmod. The downside is that boot time will increase. Minimizing boot time was the reason why the link arrays were originally introduced. Removing them will require extra computation during boot to allocate memory and associate IP blocks with their interconnects. However, since the current kernel development focus is on reducing the number of lines in arch/arm/mach-omap2/, boot time impact is now seemingly considered a lower priority. This patch contains additional complexity to reduce the number of memory allocations required for this change. This reduces the boot time impact: total hwmod link registration time was ~ 2655 microseconds with a simple allocation strategy, but is now ~ 549 microseconds[1] with the approach taken by this patch. 1. Measured on a BeagleBoard 35xx @ 500MHz MPU/333 MHz CORE, average of 7 samples. Total uncertainty is +/- 61 microseconds. Signed-off-by: NPaul Walmsley <paul@pwsan.com> Cc: Benoît Cousson <b-cousson@ti.com>
-
由 Paul Walmsley 提交于
An IP block's MPU interface port only needs to be found once. The result can be cached to speed further lookups. This patch consolidates these two steps into a single function. Signed-off-by: NPaul Walmsley <paul@pwsan.com> Cc: Benoît Cousson <b-cousson@ti.com>
-
由 Paul Walmsley 提交于
To reduce the number of lines of data in the OMAP portion of the Linux code base, subsequent patches will remove the lists of hwmod interconnect links from the static hwmod data. These lists will be built dynamically during boot. To ease this transition, this patch centralizes the way that interconnect links are iterated into a single function, _fetch_next_ocp_if(). Signed-off-by: NPaul Walmsley <paul@pwsan.com> Cc: Benoît Cousson <b-cousson@ti.com>
-
由 Paul Walmsley 提交于
Most IP blocks on the OMAP SoC have an interconnect link that is intended to be used by the MPU to communicate with the IP block. Several parts of the hwmod code need to be able to identify this link. Currently, this is open-coded. However, future patches will change the way that interconnect links are represented and will make identifying the link more complex. So to avoid code duplication, this patch centralizes the MPU port link identification code into a new function, _find_mpu_rt_port(). Signed-off-by: NPaul Walmsley <paul@pwsan.com> Cc: Benoît Cousson <b-cousson@ti.com>
-
由 Paul Walmsley 提交于
The timer integration code pokes around in hwmod data structures. Those data structures are about to change. Define a function, omap_hwmod_get_resource_byname(), for the timer integration code to use instead. The original patch has been changed to use struct resource by Tony's request, although the caller of this function should not be a driver._ Platform drivers should get their data through the regular platform_* functions; DT drivers through the appropriate of_* functions. This a function is only for use by OMAP core code in arch/arm/*omap*. Signed-off-by: NPaul Walmsley <paul@pwsan.com> Cc: Benoît Cousson <b-cousson@ti.com> Cc: Tony Lindgren <tony@atomide.com>
-
由 Paul Walmsley 提交于
A subsequent patch will need to know the struct omap_hwmod_addr_space record corresponding to the module's register target, used by the MPU. So, convert _find_mpu_rt_base() into _find_mpu_rt_addr_space(). Then modify its sole current user, _populate_mpu_rt_base(), to extract the MPU RT base address itself from the struct omap_hwmod_addr_space record. Signed-off-by: NPaul Walmsley <paul@pwsan.com> Cc: Benoît Cousson <b-cousson@ti.com>
-
由 Paul Walmsley 提交于
Change the way that hardreset lines are handled by the hwmod code. Hardreset lines are generally associated with initiator IP blocks. Prior to this change, the hwmod code expected to control hardreset lines itself, asserting them on shutdown and deasserting them upon enable. But driver authors inside TI have commented to us that their drivers require direct control over these lines. Unfortunately, these drivers haven't been posted publicly yet, so it's hard to determine exactly what is needed, a priori. This change attempts to set forth some reasonable semantics that should be an improvement over the current code. The semantics implemented by this patch are as follows: - If the hwmod is not marked with HWMOD_INIT_NO_RESET, then assert all associated hardreset lines during IP block setup. This is intended to place the IP blocks into a known state that will not interfere with other devices during kernel boot. - IP blocks with hardreset lines will not be automatically enabled or idled during setup. Instead, they will be left in the INITIALIZED state. - When the hwmod code is asked to enable, idle, or shutdown an IP block with asserted hardreset lines, the hwmod code will do nothing. The driver integration code must do the remaining work needed to control these IP blocks. Once this driver integration code is posted to the lists, hopefully we can consolidate it and move it inside the hwmod code. Custom reset functions for IP blocks with hardreset lines still should be supported and are strongly endorsed. It is intended that every subsystem with hardreset lines should have a custom reset function that can place their subsystem into quiescent idle with the hardreset lines deasserted. This reverts most of commit 5365efbe ("OMAP: hwmod: Add hardreset management support"). Later code reorganizations caused the sequencing of the code from this patch to be changed, anyway. Signed-off-by: NPaul Walmsley <paul@pwsan.com> Cc: Benoît Cousson <b-cousson@ti.com>
-
由 Paul Walmsley 提交于
Reorganize the code involved in resetting and configuring an IP block to make it easier to read and maintain. This involves improving documentation, splitting some large functions up into smaller ones to better conform with Documentation/CodingStyle, and removing some unnecessary code. Signed-off-by: NPaul Walmsley <paul@pwsan.com> Cc: Benoît Cousson <b-cousson@ti.com>
-
由 Paul Walmsley 提交于
Reorganize the code involved in initializing the internal data for each hwmod to make it easier to read and maintain. This involves improving documentation and removing some duplicated and unnecessary code. Signed-off-by: NPaul Walmsley <paul@pwsan.com> Cc: Benoît Cousson <b-cousson@ti.com>
-
由 Paul Walmsley 提交于
Revise the IP block reset process. This patch ensures that the OCP_SYSCONFIG registers are reloaded after a custom reset. Since OCP_SYSCONFIG bits are cleared during reset, they should be reprogrammed unless the IP block is being left in reset. (The only IP blocks that are left in reset are IP blocks with hardreset lines and no custom reset function.) If the IP block is left in reset, then it is inaccessible to the MPU, and an access to the OCP_SYSCONFIG register will cause an abort. This version incorporates comments from Omar Ramirez Luna <omar.ramirez@ti.com> to skip the OCP_SYSCONFIG access after asserting hardreset lines. This allows the MMU (IOMMU) IP block, which has both hardreset lines and an OCP_SYSCONFIG register. Also, ignore _ocp_softreset() errors if the IP block doesn't include a softreset bit. This is needed since a subsequent patch will start taking the return value of the _reset() function seriously. Signed-off-by: NPaul Walmsley <paul@pwsan.com> Cc: Benoît Cousson <b-cousson@ti.com> Cc: Omar Ramirez Luna <omar.ramirez@ti.com>
-