dect
/
linux-2.6
Archived
13
0
Fork 0
Commit Graph

96 Commits

Author SHA1 Message Date
Paul Walmsley 5fb3d522ef ARM: OMAP2+: hwmod: add flag to prevent hwmod code from touching IP block during init
Add HWMOD_EXT_OPT_MAIN_CLK flag to indicate that this IP block is
dependent on an off-chip functional clock that is not guaranteed to be
present during initialization.  IP blocks marked with this flag are
left in the INITIALIZED state during kernel init.

This is a workaround for a hardware problem.  It should be possible to
guarantee that at least one clock source will be present and active
for any IP block's main functional clock.  This ensures that the hwmod
code can enable and reset the IP block.  Resetting the IP block during
kernel init prevents any bogus bootloader, ROM code, or previous OS
configuration from affecting the kernel.  Hopefully a clock
multiplexer can be added on future SoCs.

N.B., at some point in the future, it should be possible to query the
clock framework for this type of information.  Then this flag should
no longer be needed.

Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Benoît Cousson <b-cousson@ti.com>
2012-10-31 05:02:31 -06:00
Olof Johansson 54d69df584 Merge branch 'late/kirkwood' into late/soc
Merge in the late Kirkwood branch with the OMAP late branch for upstream
submission.

Final contents described in shared tag.

Fixup remove/change conflicts in arch/arm/mach-omap2/devices.c and
drivers/spi/spi-omap2-mcspi.c.

Signed-off-by: Olof Johansson <olof@lixom.net>
2012-10-04 20:17:25 -07:00
Tero Kristo 46b3af2789 ARM: OMAP4: hwmod: flag hwmods/modules not supporting module level context status
On OMAP4 most modules/hwmods support module level context status. On
OMAP3 and earlier, we relied on the power domain level context status.
Identify all modules that don't support 'context_offs' by adding a
flag bit, HWMOD_OMAP4_NO_CONTEXT_LOSS_BIT.  Rest have a valid
'context_offs' populated in .prcm structure already.

Signed-off-by: Tero Kristo <t-kristo@ti.com>
[paul@pwsan.com: add flag bit rather than overloading .context_offs;
 update changelog message]
Signed-off-by: Paul Walmsley <paul@pwsan.com>
2012-09-23 17:28:20 -06:00
Tero Kristo ce80979aed ARM: OMAP4: hwmod data: add support for lostcontext_mask
Currently hwmod only provides the offset for the context lose
register, and if we attempt to share the same register between two or
more hwmods, the resulting context loss counts get wrong. Thus, we
need a way to specify which bits are used for the context loss
information for each.  This is accomplished by adding a new field to
the omap4 prcm struct, 'lostcontext_mask', which specifies a bit-mask
to use for filtering the register.

Mark the affected hwmods appropriately.  'l4_abe' hwmod uses the
LOSTMEM_AESSMEM bit of RM_ABE_AESS_CONTEXT register, as l4_abe doesn't
have its own dedicated register for this purpose. This register is
shared with 'aess' hwmod, thus both hwmods must also specify which
bits of the register are used for them.

This patch only adds the hwmod data, but a future patch should add
code support such that only the specified bits are read and cleared by
the context lose counter update code. If a hwmod doesn't specify
'lostcontext_mask' (default behavior), the whole contents of the
context register should be used without any filtering.

Signed-off-by: Tero Kristo <t-kristo@ti.com>
[paul@pwsan.com: updated to apply after conversion to use flag bit for
 missing module context-loss register; combined data and code patches;
 dropped code change due to serial driver breakage]
Signed-off-by: Paul Walmsley <paul@pwsan.com>
2012-09-23 17:28:19 -06:00
Igor Grinberg c9e49024ed ARM: OMAP: hwmod code: remove unused hwmod function prototypes
Several hwmod function prototypes appear to not have an implementation
because the corresponding functions were removed or renamed.
Those prototypes are unneeded anymore - remove them.

Signed-off-by: Igor Grinberg <grinberg@compulab.co.il>
[paul@pwsan.com: tweaked subject]
Signed-off-by: Paul Walmsley <paul@pwsan.com>
2012-09-23 17:28:17 -06:00
Olof Johansson b612a85792 Merge branch 'next/soc' into next/multiplatform
* next/soc: (50 commits)
  ARM: OMAP: AM33xx hwmod: fixup SPI after platform_data move
  MAINTAINERS: add an entry for the BCM2835 ARM sub-architecture
  ARM: bcm2835: instantiate console UART
  ARM: bcm2835: add stub clock driver
  ARM: bcm2835: add system timer
  ARM: bcm2835: add interrupt controller driver
  ARM: add infra-structure for BCM2835 and Raspberry Pi
  ARM: tegra20: add CPU hotplug support
  ARM: tegra30: add CPU hotplug support
  ARM: tegra: clean up the common assembly macros into sleep.h
  ARM: tegra: replace the CPU CAR access code by tegra_cpu_car_ops
  ARM: tegra: introduce tegra_cpu_car_ops structures
  ARM: Tegra: Add smp_twd clock for Tegra20
  ARM: AM33XX: clock: Add dcan clock aliases for device-tree
  ARM: OMAP2+: dpll: Add missing soc_is_am33xx() check for common functions
  ARM: OMAP: omap_device: idle devices with no driver bound
  ARM: OMAP: omap_device: don't attempt late suspend if no driver bound
  ARM: OMAP: omap_device: keep track of driver bound status
  ARM: OMAP3+: hwmod: Add AM33XX HWMOD data
  ARM: OMAP2+: hwmod: Hook-up am33xx support in omap_hwmod framework
  ...

Change/remove conflict in arch/arm/mach-ux500/clock.c resolved.

Signed-off-by: Olof Johansson <olof@lixom.net>
2012-09-20 21:27:41 -07:00
Vaibhav Hiremath a2cfc509bc ARM: OMAP3+: hwmod: Add AM33XX HWMOD data
This patch adds HWMOD data for all the peripherals of
AM335X device and also hooks up to the existing OMAP framework.

hwmod data has been already been cleaned up for the recent
changes in clocktree, where all leaf nodes have been removed,
since with modulemode based control, both clock and hwmod
interface does same thing. This reduces the code size to large
extent and also avoids duplication of same control.
So instead of specifying module's leaf node as a main_clk,
now we are relying on parent clock of module's functional clock.

Signed-off-by: Vaibhav Hiremath <hvaibhav@ti.com>
Signed-off-by: Afzal Mohammed <afzal@ti.com>
Signed-off-by: Vaibhav Bedia <vaibhav.bedia@ti.com>
Cc: Paul Walmsley <paul@pwsan.com>
Cc: Benoit Cousson <b-cousson@ti.com>
Cc: Tony Lindgren <tony@atomide.com>
Cc: Kevin Hilman <khilman@ti.com>
Cc: Rajendra Nayak <rnayak@ti.com>
[paul@pwsan.com: removed period in hwmod device names; changed mmc2 main_clk
 to mmc_clk at Vaibhav's request; added trailing commas to structure
 records at Tony's request to deal with some rmk parsing issues; added
 OMAP_INTC_START to facilitate sparse-IRQ conversion]
Signed-off-by: Paul Walmsley <paul@pwsan.com>
2012-09-11 17:18:58 -06:00
Vaibhav Hiremath b82b04e8eb ARM: OMAP: omap_device: Do not overwrite resources allocated by OF layer
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: Vaibhav 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: Benoit Cousson <b-cousson@ti.com>
2012-09-07 19:17:40 +02:00
Tony Lindgren 68c9a95e92 ARM: OMAP2+: Fix mismerge for omap_hwmod_get_main_clk() API
Commit ac5b0ea3d (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: Santosh Shilimkar <santosh.shilimkar@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
2012-07-06 00:58:43 -07:00
Tony Lindgren ac5b0ea3d0 Miscellaneous OMAP clock, hwmod, clockdomain, and powerdomain patches
for 3.6.  Mostly small infrastructure improvements, and preparation
 for OMAP5 and AM33xx code.
 -----BEGIN PGP SIGNATURE-----
 Version: GnuPG v1.4.12 (GNU/Linux)
 
 iQIcBAABAgAGBQJP9F5FAAoJEMePsQ0LvSpLocAP/00cPRZ+sOrZO6KYjoh84AwB
 mMfJd2QKhqwe19nBfPoGL3F+bClM5x9yIgX2pT2X46kJ25DqLcIDUnUeKydo/euF
 qON+8n2E2Z24iaiLnQvSLYyIJokTX+81l+RmddGYkT2Go8KT6U6XRcOnQ1J/kkIC
 Z9rkHkMtzL7wAtYUBcZktlEMw8PKzcLAayCSQsPQ4Q757JHONijtJFID24UyQQPQ
 azsuL4bxUJ5zhSeVjJRmCE7sFWbTgJ6vztMm/d1bc/TH4X7dFNKwhKIuZsMrAMBf
 fzf+lyB/UFX7CCt7oqQs8E3mX0E9B2ijq5WCal4SSLf7piLIIHxIpTT9LGAzO/of
 zYhRA3hY4o/HsaDmgsYxHZAPYGZoODosI93bYBVxBW2qZceYZ1j3nUfd0dY+AkCe
 Nm0L1TWeBhVG0oX3fP8bqTTxyiMCn4eDUUAUe002oJrsEFkeUb1+lAvTNoibXyns
 rQ9uQjbtR53V8nHT62sYcORxKdfUxGoDT3KFp2CHtKf/agjsuUe6JqP0Z3IkeYvT
 nmd+vUmO7D4delpbsT4OIt7vzmXCzTr6qB0hZIyXitFqQHlz9bBO4Fdow51CG+0V
 PNykHS9tfU7Ioe0bOMm9MhqjicbbxAJOc1Y4bBh8JGsNDsnfIAm9ZjHEjq7td/yz
 sZnZqUUrQHSB5EHBW5LU
 =sy5d
 -----END PGP SIGNATURE-----

Merge tag 'omap-devel-f-for-3.6' of git://git.kernel.org/pub/scm/linux/kernel/git/pjw/omap-pending into cleanup-part2

Miscellaneous OMAP clock, hwmod, clockdomain, and powerdomain patches
for 3.6.  Mostly small infrastructure improvements, and preparation
for OMAP5 and AM33xx code.

Conflicts:
	arch/arm/mach-omap2/omap_hwmod.c
	arch/arm/plat-omap/include/plat/omap_hwmod.h
2012-07-05 02:13:04 -07:00
Paul Walmsley 8cb8de5d87 Merge branches 'hwmod_am335x_support_3.6', 'clkdm_pwrdm_devel_a_3.6' and 'misc_devel_3.6' into omap_devel_f_3.6 2012-07-04 06:05:51 -06:00
Kishon Vijay Abraham I 6668546f3b ARM: OMAP2+: hwmod code: add support to set dmadisable in hwmod framework
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: Kishon Vijay Abraham I <kishon@ti.com>
[paul@pwsan.com: updated to apply; fixed checkpatch warnings]
Signed-off-by: Paul Walmsley <paul@pwsan.com>
2012-07-04 05:09:21 -06:00
Tarun Kanti DebBarma bed9d1bb4e ARM: OMAP2+: hwmod: add omap_hwmod_get_main_clk() API
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: Tarun 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: Benoit Cousson <b-cousson@ti.com>
Signed-off-by: Paul Walmsley <paul@pwsan.com>
2012-07-04 05:00:48 -06:00
Vaibhav Hiremath 768c69f5e9 ARM: OMAP3/4: omap_hwmod: Add rstst_offs field to struct omap_hwmod_omap4_prcm
In case of AM33XX device, XXX_RSTST register offset is not
consistent across PRM modules/instances,

PRM_XXX            RSTST
=========================
PRM_PER_MOD:       0x04
PRM_WKUP_MOD:      0x0C
PRM_MPU_MOD:       NA
PRM_DEVICE_MOD:    0x08

This means, we need to pass on XXX_RSTST register offset
information through omap_hwmod data, similar to XXX_RSTCTRL.

Currently, this field is only applicable and used for AM33XX
devices.

Signed-off-by: Vaibhav Hiremath <hvaibhav@ti.com>
Cc: Benoit Cousson <b-cousson@ti.com>
Cc: Tony Lindgren <tony@atomide.com>
Cc: Kevin Hilman <khilman@ti.com>
Cc: Paul Walmsley <paul@pwsan.com>
Cc: Rajendra Nayak <rnayak@ti.com>
Signed-off-by: Paul Walmsley <paul@pwsan.com>
2012-07-04 03:41:03 -06:00
Vaibhav Hiremath 248b3b3d84 ARM: OMAP2+: hwmod: Add new sysc_type3 into omap_hwmod required for am33xx
In case of AM33xx family of devices (like cpsw) have different sysc
bit field offsets defined,

sysc_type3:
|  3     2  |  1    0  |
| STDBYMODE | IDLEMODE |

So introduce new sysc_type3 in omap_hwmod common data.

Signed-off-by: Vaibhav Hiremath <hvaibhav@ti.com>
Signed-off-by: Vaibhav Bedia <vaibhav.bedia@ti.com>
Signed-off-by: Paul Walmsley <paul@pwsan.com>
2012-07-04 03:40:59 -06:00
Kevin Hilman 9ebfd28537 ARM: OMAP2+: hwmod: use init-time function ptrs for enable/disable module
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: Kevin 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: Paul Walmsley <paul@pwsan.com>
2012-06-18 12:12:23 -06:00
Paul Walmsley 42b9e38728 ARM: OMAP4: hwmod data: add some interconnect-related IP blocks
Add the SL2 interface IP block and interconnect data.  The SL2 is related
to the IVA-HD subsystem.

Add IP block and interconnect data for the C2C ("Chip-to-chip")
interconnect.  This can provide a direct system interconnect link to
other devices stacked on the OMAP package.

Add the ELM IP block and interconnect data.  The ELM can be used
to locate errors in NAND flash connected to the GPMC.


Signed-off-by: Paul Walmsley <paul@pwsan.com>
Signed-off-by: Benoît Cousson <b-cousson@ti.com>
2012-04-19 13:33:54 -06:00
Paul Walmsley 11cd4b94cb ARM: OMAP: hwmod: remove code support for direct hwmod registration
Now that the data has been converted to use interface registration, we
can remove the (now unused) direct hwmod registration code.

Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Benoît Cousson <b-cousson@ti.com>
2012-04-19 04:04:32 -06:00
Paul Walmsley 2221b5cddc ARM: OMAP2+: hwmod: add support for link registration
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: Paul Walmsley <paul@pwsan.com>
Cc: Benoît Cousson <b-cousson@ti.com>
2012-04-19 04:04:30 -06:00
Paul Walmsley 515237d6fe ARM: OMAP2+: hwmod: extend OCP_* register offsets from 16 to 32 bits
Extend the OCP_* register offsets in the struct
omap_hwmod_class_sysconfig to 32 bits.  This is required to add the
OMAP4+ GPU hwmod, which uses OCP_* register offsets larger than 16
bits.

Another possible solution may be to simply add a single 16 bit offset
field in this structure, and to add code to factor that offset into
all OCP_* register accesses.  This would save some memory, since
almost no modules need 32 bit offsets.

Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Benoît Cousson <b-cousson@ti.com>
2012-04-19 04:03:57 -06:00
Paul Walmsley 3d10f0d6d9 ARM: OMAP4: hwmod data: add OCP_USER_DSP; mark omap44xx_dsp__iva appropriately
One of the OMAP4 links was missing OCP_USER flags, since it was only
used by the DSP initiator, and we did not have an OCP_USER_DSP flag.
Future patches will switch the hwmod code and data to register
interfaces, rather than hwmods, and it will be mandatory for all
interfaces to have at least one user bit set.  This patch resolves the
issue by adding OCP_USER_DSP and marking the DSP-IVA interface
appropriately.

Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Benoît Cousson <b-cousson@ti.com>
2012-04-19 04:03:55 -06:00
Paul Walmsley 5e8370f1fa ARM: OMAP2+: hwmod: add omap_hwmod_get_resource_byname()
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: Paul Walmsley <paul@pwsan.com>
Cc: Benoît Cousson <b-cousson@ti.com>
Cc: Tony Lindgren <tony@atomide.com>
2012-04-19 04:03:11 -06:00
Fernando Guzman Lugo d99de7f552 ARM: OMAP2+: hwmod: add softreset delay field and OMAP4 data
Due to HW limitation, some IPs should not be accessed just after a
softreset. Since the current hwmod sequence is accessing the sysconfig
register just after the reset, it might lead to OCP bus error in
that case.

Add a new field in the sysconfig structure to specify a delay in usecs
needed after doing a softreset.

In the case of the ISS and FDIF modules, the L3 OCP port will be
disconnected upon a SW reset. That issue was confirmed with HW simulation
and an errata should be available soon. The HW recommendation to avoid
that is to wait for 100 OCP clk cycles, before accessing the IP.

Considering the worse case (OPP50), the L3 bus will run at 100 MHz,
so a 1 usec delay is needed. Add an x2 margin to be safe.

Acked-by: Benoit Cousson <b-cousson@ti.com>
Signed-off-by: Fernando Guzman Lugo <fernando.lugo@ti.com>
[paul@pwsan.com: dropped FDIF change for now since the hwmod data is not
 yet upstream; the FDIF change will need to be added later once the FDIF
 data is merged]
Signed-off-by: Paul Walmsley <paul@pwsan.com>
2012-04-13 05:08:03 -06:00
Vaibhav Hiremath 4ce107ccd7 ARM: OMAP2+: hwmod: Fix wrong SYSC_TYPE1_XXX_MASK bit definitions
In the SYSC_TYPE1_XXX_MASK configuration, SYSC_XXX_SHIFT macro
is used which is not defined anywhere in the kernel.
Until now the build was going through successfully, since it
is not being used anywhere in kernel.

This bug got introduced by the commit
358f0e630d ("OMAP3: hwmod: support
to specify the offset position of various SYSCONFIG register bits.")

Signed-off-by: Vaibhav Hiremath <hvaibhav@ti.com>
Acked-by: Benoit Cousson <b-cousson@ti.com>
Signed-off-by: Paul Walmsley <paul@pwsan.com>
2012-04-05 02:59:32 -06:00
Shweta Gulati cea6b94212 ARM: OMAP3+: SmartReflex: use voltage domain name in device attributes
To set sr ntarget values for all volt_domain,
volt_table is retrieved by doing a look_up of 'vdd_name'
field from omap_hwmod but voltage domain pointer does not
belong to omap_hwmod and is not used anywhere else.
As a part of voltage layer and SR Layer clean up volt
pointer is removed from omap_hwmod and added in dev
attributes of SR. The value of the field must match
the voltage domain names for the binding to be effective.

Tested on OMAP3630 SDP, OMAP3530 Beagleboard and
OMAP4430 SDP Board.

Signed-off-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Shweta Gulati <shweta.gulati@ti.com>
Acked by: Nishanth Menon <nm@ti.com>
Cc: Benoit Cousson <b-cousson@ti.com>
Cc: Paul Walmsley <paul@pwsan.com>
Signed-off-by: Jean Pihet <j-pihet@ti.com>
Reviewed-by: Kevin Hilman <khilman@ti.com>
Signed-off-by: Kevin Hilman <khilman@ti.com>
2012-03-05 11:29:25 -08:00
Tony Lindgren 9d297f5ee1 Merge branch 'tk_prm_chain_handler_devel_3.3' of git://git.pwsan.com/linux-2.6 into prcm
Conflicts:
	arch/arm/mach-omap2/Makefile
2011-12-16 14:00:23 -08:00
Rajendra Nayak aacf094128 ARM: OMAP2+: hwmod: Add a new flag to handle hwmods left enabled at init
An hwmod with a 'HWMOD_INIT_NO_IDLE' flag set, is left in
enabled state by the hwmod framework post the initial setup.
Once a real user of the device (a driver) tries to enable it
at a later point, the hwmod framework throws a WARN() about
the device being already in enabled state.

Fix this by introducing a new internal flag '_HWMOD_SKIP_ENABLE' to
identify such devices/hwmods. When the device/hwmod is requested to be
enabled (the first time) by its driver/user, nothing except the
mux-enable is needed. The mux data is board specific and is
unavailable during initial enable() of the device, done by the
framework as part of setup().

A good example of a such a device is an UART used as debug console.
The UART module needs to be kept enabled through the boot, until the
UART driver takes control of it, for debug prints to appear on
the console.

Acked-by: Kevin Hilman <khilman@ti.com>
Acked-by: Benoit Cousson <b-cousson@ti.com>
Signed-off-by: Rajendra Nayak <rnayak@ti.com>
[paul@pwsan.com: use a flag rather than a state; updated commit message;
 edited some documentation]
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
2011-12-16 13:59:55 -08:00
Tero Kristo abc2d54563 ARM: OMAP: hwmod: add support for selecting mpu_irq for each wakeup pad
By default all registered pads will trigger mpu_irqs[0]. Now there is
an API for selecting used mpu_irq on pad basis, which can be used to
trigger different irq handlers for different pads in the same hwmod.
Each pad that requires its interrupt to be re-routed this way must
have a separate call to omap_hwmod_pad_route_irq(hwmod, pad, irq).

Signed-off-by: Tero Kristo <t-kristo@ti.com>
Acked-by: Tony Lindgren <tony@atomide.com>
Tested-by: Kevin Hilman <khilman@ti.com>
Reviewed-by: Kevin Hilman <khilman@ti.com>
[paul@pwsan.com: moved fn to omap_hwmod.c; separated fn from mux scan_wakeups
 changes; added kerneldoc]
Signed-off-by: Paul Walmsley <paul@pwsan.com>
2011-12-16 14:36:59 -07:00
Tero Kristo 13a3fe52f7 ARM: OMAP2+: mux: add support for PAD wakeup interrupts
OMAP mux now parses active wakeup events from pad registers and calls
corresponding hwmod ISRs once a wakeup is detected. This is
accomplished by registering an interrupt handler for PRCM IO event,
which is raised every time the HW detects wakeups.

[paul@pwsan.com: This patch is a merge of Govindraj R's "ARM: OMAP2+:
hwmod: Add API to check IO PAD wakeup status" patch, Tero Kristo's
"ARM: OMAP2+: mux: add support for PAD wakeup interrupts" patch, and
part of Tero's "ARM: OMAP: mux: add support for selecting mpu_irq for
each wakeup pad" patch.]

Signed-off-by: Tero Kristo <t-kristo@ti.com>
Cc: Govindraj.R <govindraj.raja@ti.com>
Tested-by: Kevin Hilman <khilman@ti.com>
Reviewed-by: Kevin Hilman <khilman@ti.com>
Acked-by: Tony Lindgren <tony@atomide.com>
[paul@pwsan.com: reduced indentation level; renamed omap_hwmod function;
 improved function documentation; modified to iterate only through dynamic
 pads; modified to skip pads where idle mode doesn't enable wakeups; split
 patches]
Signed-off-by: Paul Walmsley <paul@pwsan.com>
2011-12-16 14:36:59 -07:00
Tomi Valkeinen fc01387302 ARM: OMAP: change get_context_loss_count ret value to int
get_context_loss_count functions return context loss count as u32, and
zero means an error. However, zero is also returned when context has
never been lost and could also be returned when the context loss count
has wrapped and goes to zero.

Change the functions to return an int, with negative value meaning an
error.

OMAP HSMMC code uses omap_pm_get_dev_context_loss_count(), but as the
hsmmc code handles the returned value as an int, with negative value
meaning an error, this patch actually fixes hsmmc code also.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Acked-by: Kevin Hilman <khilman@ti.com>
Acked-by: Paul Walmsley <paul@pwsan.com>
[tony@atomide.com: updated to fix a warning with recent dmtimer changes]
Signed-off-by: Tony Lindgren <tony@atomide.com>
2011-11-04 17:41:07 -07:00
Tony Lindgren 23618f7faa Merge branch 'for_3.2/voltage-cleanup' of git://gitorious.org/khilman/linux-omap-pm into voltage 2011-09-15 16:14:33 -07:00
Kevin Hilman fa17f20f68 OMAP2+: hwmod: remove unused voltagedomain pointer
The voltage domain pointer currently in struct omap_hwmod is not used
and does not belong here.  Instead, voltage domains will be associated
with powerdomains in forthcoming patches.

Acked-by: Paul Walmsley <paul@pwsan.com>
Signed-off-by: Kevin Hilman <khilman@ti.com>
2011-09-15 11:39:09 -07:00
Paul Walmsley d6504acd21 OMAP2+: hwmod: remove OMAP_CHIP*
At Tony's request, remove the OMAP_CHIP* flags from the hwmod data, and
replace it instead with chip family, variant, and ES level-specific lists
of hwmods to register.

Thanks to Gražvydas Ignotas <notasas@gmail.com> for finding a bug in the
AM3517/3505 support, and for other review comments.

Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Gražvydas Ignotas <notasas@gmail.com>
2011-09-14 17:23:19 -06:00
Benoit Cousson 03fdefe53a OMAP4: hwmod data: Add modulemode entry in omap_hwmod structure
Add a new field to provide the mode supported by the module.
The mode will control the way mandatory clocks are managed by the PRCM.

  0 : Module is temporarily disabled by SW. OCP access to module are stalled.
      Can be used to change timing parameter of GPMC module.
  1 : Module is managed automatically by HW according to clock domain
      transition. A clock domain sleep transition put module into idle.
      A wakeup domain transition put it back into function.
      If CLKTRCTRL=3, any OCP access to module is always granted.
      Module clocks may be gated according to the clock domain state.
  2 : Module is explicitly enabled. Interface clock (if not used for
      functions) may be gated according to the clock domain state.
      Functional clocks are guarantied to stay present. As long as
      in this configuration, power domain sleep transition cannot happen.

Some modules will have a modulemode initialized at 1 (HWCTRL) by default.
This is the case for interconnect and simple module like GPIO, WDT, MAILBOX.

Signed-off-by: Benoit Cousson <b-cousson@ti.com>
Cc: Paul Walmsley <paul@pwsan.com>
Cc: Rajendra Nayak <rnayak@ti.com>
Signed-off-by: Paul Walmsley <paul@pwsan.com>
2011-07-10 05:56:32 -06:00
Benoit Cousson 27bb00b58e OMAP4: hwmod data: Add PRM context register offset
Add a 'context_offs' entry in the prcm.omap4 structure to all
IPs when applicable.
The offset will be used to retrieve the per module context lost
information now available on OMAP4.

Signed-off-by: Benoit Cousson <b-cousson@ti.com>
Cc: Paul Walmsley <paul@pwsan.com>
Cc: Rajendra Nayak <rnayak@ti.com>
Signed-off-by: Paul Walmsley <paul@pwsan.com>
2011-07-10 05:56:32 -06:00
Benoit Cousson eaac329dfa OMAP4: hwmod: Replace RSTCTRL absolute address with offset macros
The RSTCTRL register was accessed using an absolute address.
The usage of hardcoded macros to calculate virtual address from physical
one should be avoided as much as possible.
The usage of an offset will allow future improvement like migration from
the current architecture code toward a module driver.

Update prm_xxx accessors, move definition to the proper header file and
update copyrights.
Change the s16 register offset parameter to u16.

Signed-off-by: Benoit Cousson <b-cousson@ti.com>
Cc: Paul Walmsley <paul@pwsan.com>
Cc: Rajendra Nayak <rnayak@ti.com>
[paul@pwsan.com: use '_prminst_' in function names that are part of the
 prminst44xx.c file]
Signed-off-by: Paul Walmsley <paul@pwsan.com>
2011-07-10 05:56:31 -06:00
Benoit Cousson d0f0631ddc OMAP4: hwmod: Replace CLKCTRL absolute address with offset macros
The CLKCTRL register was accessed using an absolute address.
The usage of hardcoded macros to calculate virtual address from physical
one should be avoided as much as possible.
The usage of a offset will allow future improvement like migration from
the current architecture code toward a module driver.

Update cm_xxx accessor, move definition to the proper header file and
update copyrights.

Signed-off-by: Benoit Cousson <b-cousson@ti.com>
Cc: Paul Walmsley <paul@pwsan.com>
Cc: Rajendra Nayak <rnayak@ti.com>
Cc: Todd Poynor <toddpoynor@google.com>
[paul@pwsan.com: renamed 'omap4_cm_' fns to 'omap4_cminst_'; removed empty
 fn prototype section from cm44xx.h; incorporated comments from Todd;
 documented some functions]
Signed-off-by: Paul Walmsley <paul@pwsan.com>
2011-07-10 05:56:30 -06:00
Benoit Cousson 6ae769973a OMAP2+: hwmod: Init clkdm field at boot time
At boot time, lookup the clkdm_name to get the clkdm
structure pointer for further usage.

Signed-off-by: Benoit Cousson <b-cousson@ti.com>
Cc: Paul Walmsley <paul@pwsan.com>
Cc: Rajendra Nayak <rnayak@ti.com>
Signed-off-by: Paul Walmsley <paul@pwsan.com>
2011-07-10 05:56:30 -06:00
Benoit Cousson a5322c6f3a OMAP4: hwmod data: Add clock domain attribute
In OMAP PRCM terminology, the clock domain is defined as a group of IPs
that share some clocks and most of the time an interface clock.
Every IP does belong to a clockdomain.
For the moment the clock domain attribute is affected to a clock node.
The issue with that approach, is that a clock might or not belong to a
clock domain. Moreover during module transition, it is up to a module
to handle properly the clock domain state and not to a clock node.

Create a clkdm_name attribute to provide this information per hwmod.

Populate this attribute for every OMAP4 hwmod entries.

Future cleanup series with remove that information from the OMAP4 clock
when it is relevant.

Signed-off-by: Benoit Cousson <b-cousson@ti.com>
Cc: Paul Walmsley <paul@pwsan.com>
Cc: Rajendra Nayak <rnayak@ti.com>
[paul@pwsan.com: fix the mpuss_clkdm name]
Signed-off-by: Paul Walmsley <paul@pwsan.com>
2011-07-10 05:56:29 -06:00
Avinash.H.M 6d3c55fd4f OMAP: hwmod: fix the i2c-reset timeout during bootup
The sequence of _ocp_softreset doesn't work for i2c. The i2c module has a
special sequence to reset the module. The sequence is
 - Disable the I2C.
 - Write to SOFTRESET bit.
 - Enable the I2C.
 - Poll on the RESETDONE bit.
The sequence is implemented as a function and the i2c_class is updated with
the correct 'reset' pointer.  omap_hwmod_softreset function is implemented
which triggers the softreset by writing into sysconfig register. On following
this sequence, i2c module resets properly and timeouts are not seen.

Cc: Rajendra Nayak <rnayak@ti.com>
Cc: Paul Walmsley <paul@pwsan.com>
Cc: Benoit Cousson <b-cousson@ti.com>
Cc: Kevin Hilman <khilman@ti.com>
Signed-off-by: Avinash.H.M <avinashhm@ti.com>
[paul@pwsan.com: combined this patch with a patch to remove
 HWMOD_INIT_NO_RESET from the 44xx hwmod flags; change register
 offset conditional code to use the IP block revision; minor code
 cleanup]
Signed-off-by: Paul Walmsley <paul@pwsan.com>
2011-07-10 05:27:16 -06:00
Paul Walmsley c402c0d9df Merge branches 'dmtimer_precleanup_3.1', 'hwmod_core_cleanup_a_3.1', 'combine_common_hwmod_3.1', 'omap4_hwmod_data_cleanup_a_3.1', 'clock_cleanup_a_3.1', 'prcm_cleanup_a_3.1', 'omap_pm_cleanup_3.1' and 'omap_device_cleanup_3.1' into prcm-cleanup-3.1 2011-07-09 20:24:07 -06:00
Paul Walmsley bc6149587b omap_hwmod: use a terminator record with omap_hwmod_dma_info arrays
Previously, struct omap_hwmod_dma_info arrays were unterminated; and
users of these arrays used the ARRAY_SIZE() macro to determine the
length of the array.  However, ARRAY_SIZE() only works when the array
is in the same scope as the macro user.

So far this hasn't been a problem.  However, to reduce duplicated
data, a subsequent patch will move common data to a separate, shared
file.  When this is done, ARRAY_SIZE() will no longer be usable.

This patch removes ARRAY_SIZE() usage for struct omap_hwmod_dma_info
arrays and uses a sentinel value (irq == -1) as the array terminator
instead.

Signed-off-by: Paul Walmsley <paul@pwsan.com>
2011-07-09 19:14:07 -06:00
Paul Walmsley 212738a449 omap_hwmod: use a terminator record with omap_hwmod_mpu_irqs arrays
Previously, struct omap_hwmod_mpu_irqs arrays were unterminated; and
users of these arrays used the ARRAY_SIZE() macro to determine the
length of the array.  However, ARRAY_SIZE() only works when the array
is in the same scope as the macro user.

So far this hasn't been a problem.  However, to reduce duplicated
data, a subsequent patch will move common data to a separate, shared
file.  When this is done, ARRAY_SIZE() will no longer be usable.

This patch removes ARRAY_SIZE() usage for struct omap_hwmod_mpu_irqs
arrays and uses a sentinel value (irq == -1) as the array terminator
instead.

Signed-off-by: Paul Walmsley <paul@pwsan.com>
2011-07-09 19:14:06 -06:00
Paul Walmsley 78183f3fdf omap_hwmod: use a null structure record to terminate omap_hwmod_addr_space arrays
Previously, struct omap_hwmod_addr_space arrays were unterminated; and
users of these arrays used the ARRAY_SIZE() macro to determine the
length of the array.  However, ARRAY_SIZE() only works when the array
is in the same scope as the macro user.

So far this hasn't been a problem.  However, to reduce duplicated
data, a subsequent patch will move common data to a separate, shared
file.  When this is done, ARRAY_SIZE() will no longer be usable.

This patch removes ARRAY_SIZE() usage for struct omap_hwmod_addr_space
arrays and uses a null structure member as the array terminator
instead.

Signed-off-by: Paul Walmsley <paul@pwsan.com>
2011-07-09 19:14:05 -06:00
Benoit Cousson 724019b013 OMAP2+: hwmod: Fix smart-standby + wakeup support
The commit 86009eb326 was adding
the wakeup support for new OMAP4 IPs. This support is incomplete for
busmaster IPs that need as well to use smart-standby with wakeup.

This new standbymode is suported on HSI and USB_HOST_FS for the moment.

Add the new MSTANDBY_SMART_WKUP flag to mark the IPs that support this
capability.

Enable this new mode when applicable in _enable_wakeup, _disable_wakeup,
_enable_sysc and _idle_sysc.

The omap_hwmod_44xx_data.c will have to be updated to add this new flag.

Signed-off-by: Benoit Cousson <b-cousson@ti.com>
Signed-off-by: Djamil Elaidi <d-elaidi@ti.com>
Signed-off-by: Paul Walmsley <paul@pwsan.com>
2011-07-09 19:13:35 -06:00
Tony Lindgren 029268e4c1 omap2+: Add separate list for dynamic pads to mux
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>
2011-03-11 11:32:25 -08:00
Paul Walmsley a08572ae52 Merge remote branch 'remotes/origin/voltage_split_2.6.39' into tmp-integration-2.6.39-20110310-024
Conflicts:
	arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
2011-03-10 22:43:32 -07:00
Paul Walmsley 2d403fe030 Merge remote branch 'remotes/origin/hwmod_a_2.6.39' into tmp-integration-2.6.39-20110310-024
Conflicts:
	arch/arm/mach-omap2/omap_hwmod_2430_data.c
	arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
	arch/arm/plat-omap/include/plat/omap_hwmod.h
2011-03-10 22:43:05 -07:00
Paul Walmsley 21ace5452c Merge remote branches 'remotes/origin/pwrdm_clkdm_b_2.6.39', 'remotes/origin/pwrdm_add_can_lose_context_fns_2.6.39', 'remotes/origin/omap_device_a_2.6.39', 'remotes/origin/mmc_a_2.6.39', 'remotes/origin/hwmod_b_2.6.39', 'remotes/origin/dmtimer_a_2.6.39', 'remotes/origin/pwrdm_clkdm_a_2.6.39', 'remotes/origin/clkdm_statdep_omap4_2.6.39', 'remotes/origin/clk_a_2.6.39', 'remotes/origin/clk_autoidle_a_2.6.39', 'remotes/origin/clk_autoidle_b_2.6.39', 'remotes/origin/clk_b_2.6.39', 'remotes/origin/clk_clkdm_a_2.6.39', 'remotes/origin/misc_a_2.6.39', 'remotes/origin/for_2.6.39/omap3_hwmod_data' and 'remotes/origin/wdtimer_a_2.6.39' into tmp-integration-2.6.39-20110310-024 2011-03-10 22:41:28 -07:00
Kishon Vijay Abraham I 9599217a06 OMAP2+: hwmod: add API to handle autoidle mode
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>
2011-03-10 03:50:08 -07:00