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>
On kernels that don't use the omap_device_enable() calls to enable
devices, leave all on-chip devices enabled in hwmod _setup().
Otherwise, accesses to those devices are likely to fail, crashing the
system. It's expected that kernels built without CONFIG_PM_RUNTIME
will be the primary use-case for this. This functionality is
controlled by adding an extra parameter to omap_hwmod_late_init().
This patch is based on the patch "OMAP: hwmod: don't auto-disable
hwmod when !CONFIG_PM_RUNTIME" by Kevin Hilman
<khilman@deeprootsystems.com>.
Cc: Kevin Hilman <khilman@deeprootsystems.com>
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Some hwmods may need to be idled/enabled in atomic context, so
non-locking versions of these functions are required.
Most users should not need these and usage of theses should be
controlled to understand why access is being done in atomic context.
For this reason, the non-locking functions are only exposed at the
hwmod level and not at the omap-device level.
The use-case that led to the need for the non-locking versions is
hwmods that are enabled/idled from within the core idle/suspend path.
Since interrupts are already disabled here, the mutex-based locking in
hwmod can sleep and will cause potential deadlocks.
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
Signed-off-by: Paul Walmsley <paul@pwsan.com>
As reported by Sergei, a couple of braces were missing after
the WARN removal patch.
[07/22] OMAP: hwmod: Replace WARN by pr_warning if clock lookup failed
https://patchwork.kernel.org/patch/100756/
Signed-off-by: Benoit Cousson <b-cousson@ti.com>
[paul@pwsan.com: fixed patch description per Anand's E-mail]
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Sergei Shtylyov <sshtylyov@mvista.com>
Cc: Anand Gadiyar <gadiyar@ti.com>
Add some missing credits for people who have contributed significant features
or fixes.
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Benoît Cousson <b-cousson@ti.com>
Cc: Tero Kristo <tero.kristo@nokia.com>
Cc: Kevin Hilman <khilman@deeprootsystems.com>
Cc: Thara Gopinath <thara@ti.com>
Most of the clock nodes belong to a clock domain, but it is perfectly valid
to have clock without clock domain.
Root clocks for example does not belong to any clock domain.
Keep the warning but reduce the verbosity.
Signed-off-by: Benoit Cousson <b-cousson@ti.com>
Signed-off-by: Paul Walmsley <paul@pwsan.com>
In the lastest OMAP4 hwmod data file, the _hwmod was removed
in order to save some memory space and because it does not
bring a lot.
The same cleanup will be have to done for other hwmods in
OMAP2 & 3 data files.
Signed-off-by: Benoit Cousson <b-cousson@ti.com>
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Rajendra Nayak <rnayak@ti.com>
During the _init_clocks phase, the iteration is stopped but the
status is still change from _HWMOD_STATE_REGISTERED to
_HWMOD_STATE_CLKS_INITED.
Since the _setup phase will be done nevertheless, it might be
better to keep initializing the others clocks nodes and just
keep the warning.
It is much easier to debug when a important number of clocks
name are wrong during the early debug phase of a new platform.
Signed-off-by: Benoit Cousson <b-cousson@ti.com>
Signed-off-by: Paul Walmsley <paul@pwsan.com>
The WARN is a little bit too verbose and is not providing
usefull information in that case.
Signed-off-by: Benoit Cousson <b-cousson@ti.com>
Signed-off-by: Paul Walmsley <paul@pwsan.com>
The previous clock API was returning a standard linux error code in
case of failure. This is not the case anymore with the new
omap_clk_get_by_name API. A NULL value means that the clock node
does not exist.
Replace all the IS_ERR check by a !clk check.
Signed-off-by: Benoit Cousson <b-cousson@ti.com>
Signed-off-by: Paul Walmsley <paul@pwsan.com>
The iteration is currently done on the omap_hwmod_ocp_if pointer
and not on the table pointer that reference them.
It worked most of the time because the structure are contiguous in
memory.
Signed-off-by: Benoit Cousson <b-cousson@ti.com>
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Some initiator modules in OMAP2 & 3 does not have IDLEST bit,
in that case we cannot detect the module readiness by
polling that bit and must exist the function immediately
assuming that the module is ready.
The previous flag was affected to the OCP interface. While it is
technically true that the idlest is related to the L4 slave
interface of the module, the PRCM status belong to the module.
Signed-off-by: Benoit Cousson <b-cousson@ti.com>
Signed-off-by: Paul Walmsley <paul@pwsan.com>
The return of the omap4_cm_wait_module_ready function is checked
in order to avoid accessing the sysconfig register if the module is
not in the correct state.
In that case the _setup will exit without trying to reset
using sysconfig.
For the moment a warning is printed. A proper management of fclk
and module reset will have to be done in order to init correctly
the problematic IPs listed below.
<4>omap_hwmod: ivahd: cannot be enabled (3)
<4>omap_hwmod: iss: cannot be enabled (3)
<4>omap_hwmod: tesla: cannot be enabled (3)
<4>omap_hwmod: sdma: cannot be enabled (3)
<4>omap_hwmod: sl2: cannot be enabled (3)
<4>omap_hwmod: sad2d: cannot be enabled (3)
<4>omap_hwmod: ducati: cannot be enabled (3)
Signed-off-by: Benoit Cousson <b-cousson@ti.com>
Signed-off-by: Paul Walmsley <paul@pwsan.com>
These files include linux/bootmem.h without using anything from this
file; remove the unnecessary include.
Acked-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
This patch adds check for presence of clockdomain structure in the API
omap_hwmod_get_pwrdm before trying to access the powerdomain structure.
This will prevent unnecessary crashing of the system in case of a
clock node with out an associated clockdomain.
Signed-off-by: Thara Gopinath <thara@ti.com>
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Add support for categorizing and iterating over hardware IP blocks by
the "class" of the IP block. The class is the type of the IP block:
e.g., "timer", "timer1ms", etc. Move the OCP_SYSCONFIG/SYSSTATUS data
from the struct omap_hwmod into the struct omap_hwmod_class, since
it's expected to stay consistent for each class. While here, fix some
comments.
The hwmod_class structures in this patch were designed and proposed by
Benoît Cousson <b-cousson@ti.com> and were refined in a discussion
between Thara Gopinath <thara@ti.com>, Kevin Hilman
<khilman@deeprootsystems.com>, and myself.
This patch uses WARN() lines that are longer than 80 characters, as
Kevin noted a broader lkml consensus to increase greppability by
keeping the messages all on one line.
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Signed-off-by: Benoît Cousson <b-cousson@ti.com>
Cc: Thara Gopinath <thara@ti.com>
Cc: Kevin Hilman <khilman@deeprootsystems.com>
The OMAP hwmod core code is intended to use SoC IP block description
structures that are autogenerated from TI's OMAP hardware database.
Currently the hwmod code uses clkdev device + connection addressing to
identify clocks. This causes problems in the hwmod autogeneration
process, since the TI hardware database doesn't use platform_device or
clkdev addressing; it uses a single clock signal name string, which
tends to bear some resemblance to what is used in the OMAP TRMs. This
patch converts the hwmod code and existing data to use omap_clk_get_by_name(),
introduced in the previous patch.
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Benoît Cousson <b-cousson@ti.com>
Cc: Kevin Hilman <khilman@deeprootsystems.com>
In OMAP3 Some modules like Smartreflex do not have the regular sysconfig
register.Instead clockactivity bits are part of another register at a
different bit position than the usual bit positions 8 and 9.
In OMAP4, a new scheme is available due to the new protocol
between the PRCM and the IPs. Depending of the scheme, the SYSCONFIG
bitfields position will be different.
The IP_REVISION register should be at offset 0x00.
It should contain a SCHEME field. From this we can determine whether
the IP follows legacy scheme or the new scheme.
31:30 SCHEME Used to distinguish between old scheme and current.
Read 0x0: Legacy protocol.
Read 0x1: New PRCM protocol defined for new OMAP4 IPs
For legacy IP
13:12 MIDLEMODE
11:8 CLOCKACTIVITY
6 EMUSOFT
5 EMUFREE
4:3 SIDLEMODE
2 ENAWAKEUP
1 SOFTRESET
0 AUTOIDLE
For new OMAP4 IP's, the bit position in SYSCONFIG is (for simple target):
5:4 STANDBYMODE (Ex MIDLEMODE)
3:2 IDLEMODE (Ex SIDLEMODE)
1 FREEEMU (Ex EMUFREE)
0 SOFTRESET
Unfortunately In OMAP4 also some IPs will not follow any of these
two schemes. This is the case at least for McASP, SmartReflex
and some security IPs.
This patch introduces a new field sysc_fields in omap_hwmod_sysconfig which
can be used by the hwmod structures to specify the offsets for the
sysconfig register of the IP.Also two static structures
omap_hwmod_sysc_type1 and omap_hwmod_sysc_type2 are defined
which can be used directly to populate the sysc_fields if the IP follows
legacy or new OMAP4 scheme. If the IP follows none of these two schemes
a new omap_hwmod_sysc_fields structure has to be defined and
passed as part of omap_hwmod_sysconfig.
Signed-off-by: Thara Gopinath <thara@ti.com>
Signed-off-by: Benoit Cousson <b-cousson@ti.com>
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Some HW blocks have errata which requires specific slave idle mode
under certain conditions.
This patch adds an hwmod API to allow setting slave idlemode
ensuring that any SYSCONFIG register updates go through hwmod.
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Move clockdomain wakeup dependency and sleep dependency data
structures from the powerdomain layer to the clockdomain layer, where
they belong. These dependencies were originally placed in the
powerdomain layer due to unclear documentation; however, it is clear
now that these dependencies are between clockdomains. For OMAP2/3,
this is not such a big problem, but for OMAP4 this needs to be fixed.
Thanks to Benoît Cousson <b-cousson@ti.com> for his advice on this
patch.
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Benoît Cousson <b-cousson@ti.com>
In the current implementation the sysconfig value is read into
_sysc_cache once and an actual update to the sysconfig register
happens only if the new value paased is differnt from the one in _sysc_cache.
_sysc_cache is updated only if _HWMOD_SYSCONFIG_LOADED is not set.
This can lead to the follwing issue if off mode is enabled in modules
which employs "always-retore" mechanism of context save and restore.
a. The module sets the sysconfig register through omap_device_enable.
Here _sysc_cache is updated with the value written to the sysconfig
register and left.
b. The power domain containig the module enters off mode and the
module context is lost.
c. The module in use becomes active and calls omap_device_enable to
enable itself. Here a read of sysconfig register does not happen
as _HWMOD_SYSCONFIG_LOADED flag is set. The value to be written
to the sysconfig register will be same as the one written in step a.
Since _sysc_cache reflects the previous written value an update
of the sysconfig register does not happen.
This means in modules which employs "always-restore" mechanism
after off , the sysconfig regsiters will never get updated.
This patch introduces a flag SYSC_NO_CACHE which if set ensures that the
sysconfig register is always read into _sysc_cache before an update is
attempted.
This flags need to be set only by modules which does not do a context save
but re-initializes the registers every time the module is accessed. This
includes modules like i2c, smartreflex etc.
Signed-off-by: Thara Gopinath <thara@ti.com>
[paul@pwsan.com: tweaked to apply on a different head, added flag comment]
Signed-off-by: Paul Walmsley <paul@pwsan.com>
WARN if a clock/hwmod is missing a clockdomain association since
resulting hwmod will not be able to correctly enable/disable clocks.
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Earlier, the hwmod code had considered the OCP_SYSCONFIG.CLOCKACTIVITY
bits to be incremental power saving bits, controlling internal IP
block clock gates. This was a misapprehension. The CLOCKACTIVITY
bits are used to indicate, in advance, which clocks will be cut when
the module acknowledges an idle request. This enables the IP block to
take whatever action is necessary to complete any in-progress work
before asserting its IdleAck.
In the current Linux-OMAP code, this implies that the clock framework
should be changing module CLOCKACTIVITY bits as module clocks are enabled
and disabled. We don't do that yet, but in the future, we should.
This must wait until the clock tree is annotated with omap_hwmod pointers
(or vice-versa). In the meantime, drop most of the hwmod code that
controls CLOCKACTIVITY bits to avoid confusion.
This patch has benefited from many illuminating discussions with (in
alphabetical order) Benoît Cousson <b-cousson@ti.com>, Rajendra Nayak
<rnayak@ti.com>, and Sebastien Sabatier <s-sabatier1@ti.com>.
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Rajendra Nayak <rnayak@ti.com>
Cc: Sebastien Sabatier <s-sabatier1@ti.com>
Cc: Benoît Cousson <b-cousson@ti.com>
Replace the existing u8 array of module MPU IRQ lines with a struct
that includes a name - similar to the existing struct
omap_hwmod_dma_info. Device drivers can then use
platform_get_resource_byname() to retrieve specific IRQs without nasty
dependencies on array ordering.
Thanks to Benoît Cousson <b-cousson@ti.com> and Kevin Hilman
<khilman@deeprootsystems.com> for feedback on this approach.
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Benoît Cousson <b-cousson@ti.com>
Cc: Kevin Hilman <khilman@deeprootsystems.com>
This patch fills in the OCP_SYSCONFIG.AUTOIDLE handling in the OMAP
hwmod code.
After this patch, the hwmod code will set the module AUTOIDLE bit
(generally <module>.OCP_SYSCONFIG.AUTOIDLE) to 1 by default upon
enable. If the hwmod flag HWMOD_NO_OCP_AUTOIDLE is set, AUTOIDLE will
be set to 0 upon enable. Upon module disable, AUTOIDLE will be set to
1.
Enabling module autoidle should save some power. The only reason to
not set the OCP_SYSCONFIG.AUTOIDLE bit is if there is a bug in the
module RTL, e.g., the MPUINTC block on OMAP3.
Comments from Kevin Hilman <khilman@deeprootsystems.com> inspired this patch,
and Kevin tested an earlier version of this patch.
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Tested-by: Kevin Hilman <khilman@deeprootsystems.com>
Reprogram the module's OCP_SYSCONFIG register after module reset (SOFTRESET
= 1). This may not be needed, but the definition of the reset performed by
the SOFTRESET bit is unclear.
Kevin Hilman <khilman@deeprootsystems.com> tested an earlier version of
this patch.
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Tested-by: Kevin Hilman <khilman@deeprootsystems.com>
Fix loop bailout off-by-one bugs reported by Juha Leppänen
<juha_motorsportcom@luukku.com>.
This second version incorporates comments from Russell King
<linux@arm.linux.org.uk>. A new macro, 'omap_test_timeout', has
been created, with cleaner code, and existing code has been converted
to use it.
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Juha Leppänen <juha_motorsportcom@luukku.com>
Cc: Russell King <linux@arm.linux.org.uk>
Move the remaining headers under plat-omap/include/mach
to plat-omap/include/plat. Also search and replace the
files using these headers to include using the right path.
This was done with:
#!/bin/bash
mach_dir_old="arch/arm/plat-omap/include/mach"
plat_dir_new="arch/arm/plat-omap/include/plat"
headers=$(cd $mach_dir_old && ls *.h)
omap_dirs="arch/arm/*omap*/ \
drivers/video/omap \
sound/soc/omap"
other_files="drivers/leds/leds-ams-delta.c \
drivers/mfd/menelaus.c \
drivers/mfd/twl4030-core.c \
drivers/mtd/nand/ams-delta.c"
for header in $headers; do
old="#include <mach\/$header"
new="#include <plat\/$header"
for dir in $omap_dirs; do
find $dir -type f -name \*.[chS] | \
xargs sed -i "s/$old/$new/"
done
find drivers/ -type f -name \*omap*.[chS] | \
xargs sed -i "s/$old/$new/"
for file in $other_files; do
sed -i "s/$old/$new/" $file
done
done
for header in $(ls $mach_dir_old/*.h); do
git mv $header $plat_dir_new/
done
Signed-off-by: Tony Lindgren <tony@atomide.com>
Connect the omap_hwmod code to the kernel boot. Create some basic
interconnect and device structures for OMAP2/3 chips.
Signed-off-by: Paul Walmsley <paul@pwsan.com>
OMAP SoCs can be considered a collection of hardware IP blocks
connected by various interconnects. The bus topology and device
integration data is somewhat more complex than platform_device can
encode. This patch creates code and structures to manage information
about OMAP on-chip devices ("hardware modules") and their integration
to the rest of the chip. Hardware module data is intended to be
generated dynamically from the TI hardware database for the OMAP4
chips and beyond, easing Linux support for new chip variants.
This code currently:
- resets and configures all hardware modules upon startup, reducing bootloader
dependencies;
- provides hooks for Linux driver model code to enable, idle, and shutdown
hardware modules (forthcoming patch);
- waits for hardware modules to leave idle once their clocks
are enabled and OCP_SYSCONFIG bits are set appropriately.
- provides a means to pass arbitrary IP block configuration data (e.g.,
FIFO size) to the device driver (via the dev_attr void pointer)
In the future this code is intended to:
- estimate interconnect bandwidth and latency characteristics to
ensure constraints are satisfied during DVFS
- provide *GRPSEL bit data to the powerdomain code
- handle pin/ball muxing for devices
- generate IO mapping information dynamically
- supply device firewall configuration data
- provide hardware module data to other on-chip coprocessor software
- allow the removal of the "disable unused clocks" code in the OMAP2/3
clock code
This patch represents a collaborative effort involving many people from TI,
Nokia, and the Linux-OMAP community.
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Benoit Cousson <b-cousson@ti.com>
Cc: Kevin Hilman <khilman@deeprootsystems.com>
Cc: Tony Lindgren <tony@atomide.com>
Cc: Rajendra Nayak <rnayak@ti.com>
Cc: Vikram Pandita <vikram.pandita@ti.com>
Cc: Sakari Poussa <sakari.poussa@nokia.com>
Cc: Anand Sawant <sawant@ti.com>
Cc: Santosh Shilimkar <santosh.shilimkar@ti.com>
Cc: Eric Thomas <ethomas@ti.com>
Cc: Richard Woodruff <r-woodruff2@ti.com>
