This avoids going through the list unnecessarily when
idling devices for runtime PM.
Based on an earlier patch by sricharan <r.sricharan@ti.com>.
Signed-off-by: sricharan <r.sricharan@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
Add a new clockdomain flag, CLKDM_NO_AUTODEPS, which, when marked on a
clockdomain, will prevent "autodeps" from being associated with the
clockdomain. ("Autodeps" are sleep dependencies and wakeup
dependencies from/to processor modules that are automatically added to
a clockdomain when it is in hardware-supervised idle mode. They are
deprecated -- a relic from the old CDP trees -- but are still in use
for OMAP3.)
Also, prevent the hwmod code from adding or removing initiator
dependencies for clockdomains with this flag set.
This patch should allow others to test which clockdomains actually
still need autodeps.
Thanks to Kevin Hilman <khilman@ti.com> for noting that the original
version should also modify the hwmod code.
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Kevin Hilman <khilman@ti.com>
Create a new API that forms a wrapper to _set_module_autoidle()
to modify the AUTOIDLE bit.
This API is intended to be used by drivers that requires direct
manipulation of the AUTOIDLE bits in SYSCONFIG register.
McBSP driver requires autoidle bit to be enabled/disabled while
using sidetone feature.
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Cc: Paul Walmsley <paul@pwsan.com>
Cc: Benoit Cousson <b-cousson@ti.com>
[paul@pwsan.com: restrict the hwmod states that the autoidle bit can be changed
in; changed function name; dropped "int" from "unsigned int long"]
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Some boards can't tolerate IP blocks being reset when they are initialized.
Michael Büsch cites a case with the Nokia N810:
http://www.spinics.net/lists/linux-omap/msg47277.html
To allow such boards to continue working normally, allow board file
maintainers to mark IP blocks to prevent them from being reset upon
init. This is done via a hwmod function, omap_hwmod_no_setup_reset().
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Michael Buesch <mb@bu3sch.de>
On OMAP2 and OMAP3 the reset ctrl shift doesn't match the
status bit, as it does on OMAP4, when handling the reset lines.
This patch adds a new member in the reset info structure, so now it
can be added as part of hwmod data, and checked accordingly for
OMAP2 or 3; otherwise, there could be cases when the shift masks
doesn't match both of the registers, and a successful reset might
throw an error message or vice versa.
Signed-off-by: Omar Ramirez Luna <omar.ramirez@ti.com>
[paul@pwsan.com: added a warning if st_shift used on OMAP4; renamed 'r'
variable; improved some documentation]
Signed-off-by: Paul Walmsley <paul@pwsan.com>
_init_clock always returns 0 and does
not propogate the error (in case of failure)
back to the caller, causing _init_clocks to
fail silently.
Signed-off-by: Rajendra Nayak <rnayak@ti.com>
Acked-by: Benoît Cousson <b-cousson@ti.com>
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Autoidle is a single bit, TIOCP_CFG[0], setting on OMAP1/2/3/4 platforms.
In _set_module_autoidle() I am seeing 0x3 value where the mask is computed.
This should be 0x1.
v2:
(1) Modified the subject.
(2) Modified the description with further specific information.
Baseline:
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
Tested Info:
Boot tested on OMAP 1/2/3/4.
Signed-off-by: Tarun Kanti DebBarma <tarun.kanti@ti.com>
Acked-by: Rajendra Nayak <rnayak@ti.com>
Acked-by: Benoit Cousson <b-cousson@ti.com>
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Add omap_hwmod_setup_one(), which is intended for use early in boot to
selectively setup the hwmods needed for system clocksources and
clockevents, and any other hwmod that is needed in early boot.
omap_hwmod_setup_all() can then be called later in the boot process.
The point is to minimize the amount of code that needs to be run
early.
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Benoît Cousson <b-cousson@ti.com>
Cc: Kevin Hilman <khilman@ti.com>
Cc: Santosh Shilimkar <santosh.shilimkar@ti.com>
Cc: Tony Lindgren <tony@atomide.com>
Previously, if a hwmod had already been set up, and the code attempted
to set up the hwmod again, an error would be returned. This is not
really useful behavior if we wish to allow the OMAP core code to setup
the hwmods needed for the Linux clocksources and clockevents before
the rest of the hwmods are setup. So, instead of generating errors,
just ignore the attempt to re-setup the hwmod.
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Benoît Cousson <b-cousson@ti.com>
Cc: Kevin Hilman <khilman@ti.com>
Move the code that looks for the MPU initiator hwmod to run during
the individual hwmod _register() function. (Previously, it ran after
all hwmods were registered in the omap_hwmod_late_init() function.)
This is done so code can late-initialize a few individual hwmods --
for example, for the system timer -- before the entire set of hwmods is
initialized later in boot via omap_hwmod_late_init().
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Benoît Cousson <b-cousson@ti.com>
Cc: Kevin Hilman <khilman@ti.com>
Rename omap_hwmod_init() to omap_hwmod_register(). Rename
omap_hwmod_late_init() to omap_hwmod_setup_all(). Also change all of
the callers to reflect the new names. While here, update some
copyrights.
Suggested by Tony Lindgren <tony@atomide.com>.
N.B. The comment in mach-omap2/serial.c may no longer be correct, given
recent changes in init order.
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Benoît Cousson <b-cousson@ti.com>
Cc: Kevin Hilman <khilman@ti.com>
Cc: Tony Lindgren <tony@atomide.com>
There's no longer any reason why we should prevent multiple
calls to omap_hwmod_init(). It is now simply used to register an
array of hwmods.
This should allow a subset of hwmods (e.g., hwmods
handling the system clocksource and clockevents) to be registered
earlier than the remaining mass of hwmods.
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Benoît Cousson <b-cousson@ti.com>
Cc: Kevin Hilman <khilman@ti.com>
Adds support for resource API to get address space info other than just MPU.
The drivers can now use platform_get_resource_byname() to get resource of
type 'IORESOURCE_MEM' by name.
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: Benoit Cousson <b-cousson@ti.com>
Acked-by: Paul Walmsley <paul@pwsan.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
Allow hwmod state changes to mux pads based on the state changes.
By default, only enable and disable the pads. In some rare cases
dynamic remuxing for the idles states is needed, this can be done
by passing the enable, idle, and off pads from board-*.c file along
with OMAP_DEVICE_PAD_REMUX flag.
Thanks to Paul Walmsley <paul@booyaka.com> for the comments on the
hwmod related changes.
Signed-off-by: Tony Lindgren <tony@atomide.com>
Implement OMAP PM layer omap_pm_get_dev_context_loss_count() API by
creating similar APIs at the omap_device and omap_hwmod levels. The
omap_hwmod level call is the layer with access to the powerdomain
core, so it is the place where the powerdomain is queried to get the
context loss count.
The new APIs return an unsigned value that can wrap as the
context-loss count grows. However, the wrapping is not important as
the role of this function is to determine context loss by checking for
any difference in subsequent calls to this function.
Note that these APIs at each level can return zero when no context
loss is detected, or on errors. This is to avoid returning error
codes which could potentially be mistaken for large context loss
counters.
NOTE: only works for devices which have been converted to use
omap_device/omap_hwmod.
Longer term, we could possibly remove this API from the OMAP PM layer,
and instead directly use the omap_device level API.
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
Signed-off-by: Paul Walmsley <paul@pwsan.com>
The new OMAP4 IPs introduced a new idle mode named smart-idle with wakeup.
This new idlemode replaces the enawakeup for the new IPs but seems to
coexist as well for some legacy IPs (UART, GPIO, MCSPI...)
Add the new SIDLE_SMART_WKUP flag to mark the IPs that support this
capability.
The omap_hwmod_44xx_data.c will have to be updated to add this new flag.
Enable this new mode when applicable in _enable_wakeup, _enable_sysc and
_idle_sysc.
Signed-off-by: Benoit Cousson <b-cousson@ti.com>
Tested-by: Sebastien Guiriec <s-guiriec@ti.com>
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Kevin Hilman <khilman@deeprootsystems.com>
Cc: Rajendra Nayak <rnayak@ti.com>
In cases where a module (hwmod) does not become accesible on enabling
the main clocks (can happen if there are external clocks needed
for the module to become accesible), make sure the clocks are not
left enabled.
This ensures that when the requisite external dependencies are met
a omap_hwmod_enable and omap_hwmod_idle/shutdown would rightly enable
and disable clocks using clk framework. Leaving the clocks enabled in
the error case causes additional usecounting at the clock framework
level leaving the clock enabled forever.
Signed-off-by: Rajendra Nayak <rnayak@ti.com>
Signed-off-by: Benoit Cousson <b-cousson@ti.com>
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Kevin Hilman <khilman@deeprootsystems.com>
The hwmod list will be built are init time and never
be modified at runtime. There is no need anymore to protect
the list from concurrent accesses using a mutex.
Signed-off-by: Benoit Cousson <b-cousson@ti.com>
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Kevin Hilman <khilman@deeprootsystems.com>
_register, _find_mpu_port_index and _find_mpu_rt_base are static APIs
that will be used only during the omap_hwmod initialization phase.
There is no need to keep them for runtime.
Signed-off-by: Benoit Cousson <b-cousson@ti.com>
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Kevin Hilman <khilman@deeprootsystems.com>
Do not allow omap_hwmod_register to be used outside the core
hwmod code. An omap_hwmod should be registered only at init time.
Remove the omap_hwmod_unregister that is not used today since the
hwmod list will be built once at init time and never be modified
at runtime.
Signed-off-by: Benoit Cousson <b-cousson@ti.com>
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Kevin Hilman <khilman@deeprootsystems.com>
In the omap_hwmod core, most of the SYSCONFIG register helper
functions do not directly write the register, but instead just modify
a value passed in.
This patch converts the _enable_wakeup() and _disable_wakeup() helper
functions to take a value argument and only modify it instead of
actually writing the register. This makes the wakeup helpers
consistent with the other helper functions and avoids unintentional
problems like the following.
This problem was found after discovering that GPIO wakeups were no
longer functional. The root cause was that the ENAWAKEUP bit of the
SYSCONFIG register was being unintentionaly overwritten, leaving
wakeups disabled after the following two commits were combined:
commit: 9980ce53c9
OMAP: hwmod: Enable module wakeup if in smartidle
commit: 78f26e872f
OMAP: hwmod: Set autoidle after smartidle during _sysc_enable
There resulting in code in _enable_sysc() was this:
/*
* XXX The clock framework should handle this, by
* calling into this code. But this must wait until the
* clock structures are tagged with omap_hwmod entries
*/
if ((oh->flags & HWMOD_SET_DEFAULT_CLOCKACT) &&
(sf & SYSC_HAS_CLOCKACTIVITY))
_set_clockactivity(oh, oh->class->sysc->clockact, &v);
_write_sysconfig(v, oh);
so here, 'v' has wakeups disabled.
/* If slave is in SMARTIDLE, also enable wakeup */
if ((sf & SYSC_HAS_SIDLEMODE) && !(oh->flags & HWMOD_SWSUP_SIDLE))
_enable_wakeup(oh);
Here wakeup is enabled in the SYSCONFIG register (but 'v' is not updated)
/*
* Set the autoidle bit only after setting the smartidle bit
* Setting this will not have any impact on the other modules.
*/
if (sf & SYSC_HAS_AUTOIDLE) {
idlemode = (oh->flags & HWMOD_NO_OCP_AUTOIDLE) ?
0 : 1;
_set_module_autoidle(oh, idlemode, &v);
_write_sysconfig(v, oh);
}
And here, SYSCONFIG is updated again using 'v', which does not have
wakeups enabled, resulting in ENAWAKEUP being cleared.
Special thanks to Benoit Cousson for pointing out that wakeups were
supposed to be automatically enabled when a hwmod is enabled, and thus
helping target the root cause of this problem.
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Benoit Cousson <b-cousson@ti.com>
Signed-off-by: Benoit Cousson <b-cousson@ti.com>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
The OMAP powerdomain code and data is all OMAP2+-specific. This seems
unlikely to change any time soon. Move plat-omap/include/plat/powerdomain.h
to mach-omap2/powerdomain.h. The primary point of doing this is to remove
the temptation for unrelated upper-layer code to access powerdomain code
and data directly.
As part of this process, remove the references to powerdomain data
from the GPIO "driver" and the OMAP PM no-op layer, both in plat-omap.
Change the DSPBridge code to point to the new location for the
powerdomain headers. The DSPBridge code should not be including the
powerdomain headers; these should be removed.
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Kevin Hilman <khilman@deeprootsystems.com>
Cc: Omar Ramirez Luna <omar.ramirez@ti.com>
Cc: Felipe Contreras <felipe.contreras@gmail.com>
Cc: Greg Kroah-Hartman <greg@kroah.com>
The OMAP clockdomain code and data is all OMAP2+-specific. This seems
unlikely to change any time soon. Move plat-omap/include/plat/clockdomain.h
to mach-omap2/clockdomain.h. The primary point of doing this is to remove
the temptation for unrelated upper-layer code to access clockdomain code
and data directly.
DSPBridge also uses the clockdomain headers for some reason, so,
modify it also. The DSPBridge code should not be including the
clockdomain headers; these should be removed.
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Kevin Hilman <khilman@deeprootsystems.com>
Cc: Omar Ramirez Luna <omar.ramirez@ti.com>
Cc: Felipe Contreras <felipe.contreras@gmail.com>
Cc: Greg Kroah-Hartman <greg@kroah.com>
Tested-by: Rajendra Nayak <rnayak@ti.com>
Tested-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
In preparation for adding OMAP4-specific PRCM accessor/mutator
functions, split the existing OMAP2/3 PRCM code into OMAP2/3-specific
files. Most of what was in mach-omap2/{cm,prm}.{c,h} has now been
moved into mach-omap2/{cm,prm}2xxx_3xxx.{c,h}, since it was
OMAP2xxx/3xxx-specific.
This process also requires the #includes in each of these files to be
changed to reference the new file name. As part of doing so, add some
comments into plat-omap/sram.c and plat-omap/mcbsp.c, which use
"sideways includes", to indicate that these users of the PRM/CM includes
should not be doing so.
Thanks to Felipe Contreras <felipe.contreras@gmail.com> for comments on this
patch.
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Jarkko Nikula <jhnikula@gmail.com>
Cc: Peter Ujfalusi <peter.ujfalusi@nokia.com>
Cc: Liam Girdwood <lrg@slimlogic.co.uk>
Cc: Omar Ramirez Luna <omar.ramirez@ti.com>
Acked-by: Omar Ramirez Luna <omar.ramirez@ti.com>
Cc: Felipe Contreras <felipe.contreras@gmail.com>
Acked-by: Felipe Contreras <felipe.contreras@gmail.com>
Cc: Greg Kroah-Hartman <greg@kroah.com>
Acked-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Reviewed-by: Kevin Hilman <khilman@deeprootsystems.com>
Tested-by: Kevin Hilman <khilman@deeprootsystems.com>
Tested-by: Rajendra Nayak <rnayak@ti.com>
Tested-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Split the existing cm44xx.h file into cm1_44xx.h and cm2_44xx.h files
so they match their underlying OMAP hardware modules. Add clockdomain
offset information.
Add header files for the MPU local PRCM, prcm_mpu44xx.h, and for the
SCRM, scrm44xx.h. SCRM register offsets still need to be added; TI
should do this.
Move the "_MOD" macros out of the prcm-common.h header file, into the
header file of the hardware module that they belong to. For example,
OMAP4430_PRM_*_MOD macros have been moved into the prm44xx.h header.
Adjust #includes of all files that used the old PRCM header file names
to point to the new filenames.
The autogeneration scripts have been updated accordingly.
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Benoît Cousson <b-cousson@ti.com>
Cc: Rajendra Nayak <rnayak@ti.com>
Reviewed-by: Kevin Hilman <khilman@deeprootsystems.com>
Tested-by: Kevin Hilman <khilman@deeprootsystems.com>
Tested-by: Rajendra Nayak <rnayak@ti.com>
Tested-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Do not skip the sysc programming in the hmwod framework based
on the cached value alone, since at times the module might have lost
context (due to the Powerdomain in which the module belongs
transitions to either Open Switch RET or OFF).
Identifying if a module has lost context requires atleast one
register read, and since a register read has more latency than
a write, it makes sense to do a blind write always.
Signed-off-by: Rajendra Nayak <rnayak@ti.com>
Acked-by: Kevin Hilman <khilman@deeprootsystems.com>
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Benoit Cousson <b-cousson@ti.com>
Cc: Santosh Shilimkar <santosh.shilimkar@ti.com>
Change the per-hwmod mutex to a spinlock. (The per-hwmod lock
serializes most post-initialization hwmod operations such as enable,
idle, and shutdown.) Spinlocks are needed, because in some cases,
hwmods must be enabled from timer interrupt disabled-context, such as
an ISR. The current use-case that is driving this is the OMAP GPIO
block ISR: it can trigger interrupts even with its clocks disabled,
but these clocks are needed for register accesses in the ISR to succeed.
This patch also effectively reverts commit
848240223c - this patch makes
_omap_hwmod_enable() and _omap_hwmod_init() static, renames them back
to _enable() and _idle(), and changes their callers to call the
spinlocking versions. Previously, since omap_hwmod_{enable,init}()
attempted to take mutexes, these functions could not be called while
the timer interrupt was disabled; but now that the functions use
spinlocks and save and restore the IRQ state, it is appropriate to
call them directly.
Kevin Hilman <khilman@deeprootsystems.com> originally proposed this
patch - thanks Kevin.
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Kevin Hilman <khilman@deeprootsystems.com>
Cc: Benoît Cousson <b-cousson@ti.com>
The standard omap_hwmod.c _reset() code relies on an IP block's
OCP_SYSCONFIG.SOFTRESET register bit to reset the IP block. This
works for most IP blocks on the chip, but unfortunately not all. For
example, initiator-only IP blocks often don't have any MPU-accessible
OCP-header registers, and therefore the MPU can't write to any
OCP_SYSCONFIG registers in that block. Other IP blocks, such as the
IVA and I2C, require a specialized reset sequence.
Since we need to be able to reset these IP blocks as well, allow
custom IP block reset functions to be passed into the hwmod code via a
per-hwmod-class reset function pointer, struct omap_hwmod_class.reset.
If .reset is non-null, then the hwmod _reset() code will call the custom
function instead of the standard OCP SOFTRESET-based code.
As part of this change, rename most of the existing _reset() function
code to _ocp_softreset(), to indicate more clearly that it does not work
for all cases.
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Benoît Cousson <b-cousson@ti.com>
Cc: Paul Hunt <hunt@ti.com>
Cc: Stanley Liu <stanley_liu@ti.com>
Allow board files and OMAP core code to control the state that some or
all of the hwmods end up in at the end of _setup() (called by
omap_hwmod_late_init() ). Reimplement the old skip_setup_idle code in
terms of this new postsetup state code.
There are two use-cases for this patch: the !CONFIG_PM_RUNTIME case,
in which all IP blocks should stay enabled after _setup() finishes;
and the MPU watchdog case, in which the watchdog IP block should enter
idle if watchdog coverage of kernel initialization is desired, and
should be disabled otherwise.
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Benoît Cousson <b-cousson@ti.com>
Cc: Kevin Hilman <khilman@deeprootsystems.com>
Cc: Charulatha Varadarajan <charu@ti.com>
Some OMAP IP blocks, such as the watchdog timers, cannot be completely
shut down via the standard hwmod shutdown mechanism. This patch
enables the hwmod data files to supply a pointer to a custom
pre-shutdown function via the struct omap_hwmod_class.pre_shutdown
function pointer. If the struct omap_hwmod_class.pre_shutdown
function pointer is non-null, the function will be executed before the
existing hwmod shutdown code runs.
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Benoît Cousson <b-cousson@ti.com>
Some modules which have 16bit registers can cause imprecise
aborts if a __raw_readl/writel is used to read/write 32 bits.
Add an additional flag to identify modules which have such
hard requirement, and handle it in the hwmod framework.
Signed-off-by: Rajendra Nayak <rnayak@ti.com>
Acked-by: Paul Walmsley <paul@pwsan.com>
Tested-by: Kevin Hilman <khilman@deeprootsystems.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
OMAP USBOTG module has a requirement to set the autoidle bit only after
setting smartidle bit. Modified the _sys_enable api to set the smartidle
first and then the autoidle bit. Setting this will not have any impact on the
other modules.
Signed-off-by: Hema HK <hemahk@ti.com>
Signed-off-by: Partha Basak <p-basak2@ti.com>
Cc: Felipe Balbi <balbi@ti.com>
Cc: Tony Lindgren <tony@atomide.com>
Cc: Kevin Hilman <khilman@deeprootsystems.com>
Acked-by: Benoit Cousson <b-cousson@ti.com>
Signed-off-by: Paul Walmsley <paul@pwsan.com>
This patch:
- adds more documentation to the hwmod code
- fixes some documentation typos elsewhere in the file
- changes the _sysc_*() function names to appear in (verb, noun) order,
to match the rest of the function names.
This patch should not result in any functional change.
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Kevin Hilman <khilman@deeprootsystems.com>
Cc: Benoît Cousson <b-cousson@ti.com>
If a module's OCP slave port is programmed to be in smartidle,
its also necessary that they have module level wakeup enabled.
Update _sysc_enable in hwmod framework to do this.
The thread "[PATCH 7/8] : Hwmod api changes" archived here:
http://www.mail-archive.com/linux-omap@vger.kernel.org/msg34212.html
has additional technical information on the rationale of this patch.
Sergei Shtylyov <sshtylyov@mvista.com> identified an indentation
problem with this patch - thanks, Sergei.
Signed-off-by: Rajendra Nayak <rnayak@ti.com>
Signed-off-by: Partha Basak <p-basak2@ti.com>
Signed-off-by: Benoît Cousson <b-cousson@ti.com>
[paul@pwsan.com: revised patch description]
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Kevin Hilman <khilman@deeprootsystems.com>
Cc: Sergei Shtylyov <sshtylyov@mvista.com>
Some modules (like GPIO, DSS...) require optionals clock to be enabled
in order to complete the sofreset properly.
Add a HWMOD_CONTROL_OPT_CLKS_IN_RESET flag to force all optional clocks
to be enabled before reset. Disabled them once the reset is done.
TODO:
For the moment it is very hard to understand from the HW spec, which
optional clock is needed and which one is not. So the current approach
will enable all the optional clocks.
Paul proposed a much finer approach that will allow to tag only the needed
clock in the optional clock table. This might be doable as soon as we have
a clear understanding of these dependencies.
Reported-by: Partha Basak <p-basak2@ti.com>
Signed-off-by: Benoit Cousson <b-cousson@ti.com>
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Kevin Hilman <khilman@deeprootsystems.com>
In OMAP3 a specific SYSSTATUS register was used to get the softreset status.
Starting in OMAP4, some IPs does not have SYSSTATUS register and instead
use the SYSC softreset bit to provide the status.
Other cases might exist:
- Some IPs like McBSP does have a softreset control but no reset status.
- Some IPs that represent subsystem, like the DSS, can contains
a reset status without softreset control. The status is the aggregation
of all the sub modules reset status.
- Add a new flag (SYSC_HAS_RESET_STATUS) to identify the new programming model
and replace the previous SYSS_MISSING, that was used to flag IP with
softreset control but without the SYSSTATUS register, with a specific
SYSS_HAS_RESET_STATUS flag.
- MCSPI and MMC contains both programming models, so the legacy one
will be prevented by removing the syss offset field that become useless.
Signed-off-by: Benoit Cousson <b-cousson@ti.com>
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Kevin Hilman <khilman@deeprootsystems.com>
Cc: Rajendra Nayak <rnayak@ti.com>
Expose an hardreset API from hwmod in order to assert / deassert all the
individual reset lines that belong to an hwmod. This API is needed by
some of the more complicated processor drivers, e.g., DSP/Bridge,
Syslink, etc.
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Benoît Cousson <b-cousson@ti.com>
Force the softreset of every IPs during the _setup phase.
IPs that cannot support softreset or that should not
be reset must set the HWMOD_INIT_NO_RESET flag in the
hwmod struct.
Signed-off-by: Benoit Cousson <b-cousson@ti.com>
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Tested-by: Kevin Hilman <khilman@deeprootsystems.com>
Most processor IPs does have a hardreset signal controlled by the PRM.
This is different of the softreset used for local IP reset from the
SYSCONFIG register.
The granularity can be much finer than orginal HWMOD, for ex, the IVA
hwmod contains 3 reset lines, the IPU 3 as well, the DSP 2...
Since this granularity is needed by the driver, we have to ensure
than one hwmod exist for each hardreset line.
- Store reset lines as hwmod resources that a driver can query by name like
an irq or sdma line.
- Add two functions for asserting / deasserting reset lines in hwmods
processor that require manual reset control.
- Add one functions to get the current reset state.
- If an hwmod contains only one line, an automatic assertion / de-assertion
is done.
-> de-assert the hardreset line only during enable from disable transition
-> assert the hardreset line only during shutdown
Note: The hwmods with hardreset line and HWMOD_INIT_NO_RESET flag must be
kept in INITIALIZED state.
They can be properly enabled only if the hardreset line is de-asserted
before.
For information here is the list of IPs with HW reset control
on an OMAP4430 device:
RM_DSP_RSTCTRL
1,1,'RST2','RW','1','DSP - MMU, cache and slave interface reset control'
0,0,'RST1','RW','1','DSP - DSP reset control'
RM_IVA_RSTCTRL
2,2,'RST3','RW','1','IVA logic and SL2 reset control'
1,1,'RST2','RW','1','IVA Sequencer2 reset control'
0,0,'RST1','RW','1','IVA sequencer1 reset control'
RM_IPU_RSTCTRL
2,2,'RST3','RW','1','IPU MMU and CACHE interface reset control.'
1,1,'RST2','RW','1','IPU Cortex M3 CPU2 reset control.'
0,0,'RST1','RW','1','IPU Cortex M3 CPU1 reset control.'
PRM_RSTCTRL
1,1,'RST_GLOBAL_COLD_SW','RW','0','Global COLD software reset control.'
0,0,'RST_GLOBAL_WARM_SW','RW','0','Global WARM software reset control.'
RM_CPU0_CPU0_RSTCTRL
RM_CPU1_CPU1_RSTCTRL
0,0,'RST','RW','0','Cortex A9 CPU0&1 warm local reset control'
Signed-off-by: Benoit Cousson <b-cousson@ti.com>
[paul@pwsan.com: made the hardreset functions static; moved the register
twiddling into prm*.c functions in previous patches; changed the
function names to conform with hwmod practice]
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Kevin Hilman <khilman@deeprootsystems.com>
Cc: Rajendra Nayak <rnayak@ti.com>
Currently omap_hwmod_mutex is being used to protect both the list
access/modification and concurrent access to hwmod functions. This
patch separates these two types of locking.
First, omap_hwmod_mutex is used only to protect access and
modification of omap_hwmod_list. Also cleaned up some comments
referring to this mutex that are no longer needed.
Then, for protecting concurrent access to hwmod functions, use a
per-hwmod mutex. This protects concurrent access to a single hwmod,
but would allow concurrent access to different hwmods.
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
[paul@pwsan.com: added structure documentation; changed mutex variable
name]
Signed-off-by: Paul Walmsley <paul@pwsan.com>
The reset function wrongly used the state flag as a bit mask and was trying
to re-enable after a reset.
hwmod is still enabled for the PRCM point of view after a softreset
so there is no need to re-enable.
Remove the state check from omap_hwmod_reset since the _reset
function is checking that as well and in addition can generate
a warning
Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
[b-cousson@ti.com: remove the wrong test, remove the re-enable]
Signed-off-by: Benoit Cousson <b-cousson@ti.com>
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Tested-by: Kevin Hilman <khilman@deeprootsystems.com>
Cc: Rajendra Nayak <rnayak@ti.com>
The disable function was disabling clocks and dependencies
from both enable and idle state. Since idle function is already
disabling both, an enable -> idle -> disable sequence will
try to disable twice the clocks and thus generate a
"Trying disable clock XXX with 0 usecount" warning.
Signed-off-by: Benoit Cousson <b-cousson@ti.com>
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Tested-by: Kevin Hilman <khilman@deeprootsystems.com>
The dma request line attribute was named dma channel, which leads
to confusion with the real dma channel definition.
Signed-off-by: Benoit Cousson <b-cousson@ti.com>
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Tested-by: Kevin Hilman <khilman@deeprootsystems.com>
Update some minor documentation issues and update copyright for
omap_device/omap_hwmod code.
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Kevin Hilman <khilman@deeprootsystems.com>
Cc: Benoît Cousson <b-cousson@ti.com>
Add omap_device_get_mpu_rt_va(). This is intended to be used by
device drivers (currently, via a struct platform_data function
pointer) to retrieve their corresponding device's virtual base address
that the MPU should use to access the device. This is needed because
the omap_hwmod code does its own ioremap(), in order to gain access to
the module's OCP_SYSCONFIG register.
Add omap_hwmod_get_mpu_rt_va(). omap_device_get_mpu_rt_va() calls this
function to do the real work.
While here, rename struct omap_hwmod._rt_va to struct
omap_hwmod._mpu_rt_va, to reinforce that it refers to the MPU's
register target virtual address base (as opposed to, for example, the
L3's).
In the future, this belongs as a function in an omap_bus, so it is not
necessary to call this through a platform_data function pointer.
The use-case for this function was originally presented by Santosh
Shilimkar <santosh.shilimkar@ti.com>.
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Santosh Shilimkar <santosh.shilimkar@ti.com>
