diff options
author | 2012-09-23 17:28:20 -0600 | |
---|---|---|
committer | 2012-09-23 17:28:20 -0600 | |
commit | eb05f691290e99ee0bd1672317d6add789523c1e (patch) | |
tree | 1df79aa4c0faddd49c10afb81e4dc20bab2c5b7b /tools/perf/scripts/python/export-to-postgresql.py | |
parent | ARM: OMAP4: hwmod: flag hwmods/modules not supporting module level context status (diff) | |
download | linux-dev-eb05f691290e99ee0bd1672317d6add789523c1e.tar.xz linux-dev-eb05f691290e99ee0bd1672317d6add789523c1e.zip |
ARM: OMAP: hwmod: partially un-reset hwmods might not be properly enabled
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: Omar Ramirez Luna <omar.luna@linaro.org>
[paul@pwsan.com: updated to apply]
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Diffstat (limited to 'tools/perf/scripts/python/export-to-postgresql.py')
0 files changed, 0 insertions, 0 deletions