ARM: OMAP54XX: clock data: allow set rate on bandgap clock

This patch adds the clk_set_rate capability on bandgap clock.
This is required to bump up the BG clock.

Change-Id: Ica92d7f33ff918d0d9f26aad1de2ce82683dca80
Signed-off-by: Eduardo Valentin <eduardo.valentin@ti.com>
ARM: OMAP4+: SAR: enable l3_main_3 hwmod during save_sar_bank3

Some of the firewall registers are not accessible without the l3_main_3
clock being enabled.

Change-Id: I405c3d6a40c5c1b837959c56337f01cf21dbd6cf
Signed-off-by: Tero Kristo <t-kristo@ti.com>
Signed-off-by: Andrii.Tseglytskyi <andrii.tseglytskyi@ti.com>
Merge branch 'p-linux-omap-3.4' into p-android-omap-3.4

* p-linux-omap-3.4:
  ARM: OMAP4+: SAR: enable l3_main_3 hwmod during save_sar_bank3
  ARM: OMAP54XX: clock data: allow set rate on bandgap clock

Change-Id: Iac759dadbed701ddba6b5509d180f1cf14c6b685
Signed-off-by: Praneeth Bajjuri <praneeth@ti.com>
ARM: OMAP5: DPLL: Update children before scaling MPU up

Currently dividers of MPU-ABE and MPU-EMIF asynchronous
bridges are updated after MPU scaling.
This leaves a window with a wrong configuration during scale up.

So update dividers before scaling up.

Change-Id: I945966b1ca34e89ae75ce80b5b806a9c8f39350e
Signed-off-by: Taras Kondratiuk <taras@ti.com>
ARM: OMAP5: DPLL: Fix MPU DPLL rate check

omap5_mpu_dpll_set_rate() function skips setting
MPU DPLL rate if it is already the same.
But rate check is not correct if DCC is used.

For example we set MPU frequency to 1500MHz (DCC is used).
If we try to set 1500MHz again then configuration should be skipped.
But it is not skipped:

    rate = 1500;
    dpll_rate = 750;
    if (rate == dpll_rate/2) -> (1500 != 375)

Instead check should be changed to (rate/2 == dpll_rate)

Change-Id: I7e2115b2f1024915d9efcd35add56cc30a5feb0e
Signed-off-by: Taras Kondratiuk <taras@ti.com>
ARM: OMAP5: DPLL: Enable DCC after MPU DPLL is scaled.

Currently DCC is enabled before scaling DPLL frequency to rate/2.
In some cases for short period of time this will scale MPU
to higher frequency.

The patch enables DCC only after MPU DPLL is scaled.

mult_div1_reg rmw operation can't be interrupted by set_rate(),
because they both modify OMAP54XX_CM_CLKSEL_DPLL_MPU register.
So dd->mult_div1_reg should be read separately
inside of both if-else branches.

Change-Id: Ib42447b681153e500abb28e41a91850ebc0c3a19
Signed-off-by: Taras Kondratiuk <taras@ti.com>
ARM: OMAP5: hwmod data: add mmu device attributes for ipu and dsp

The MMU device attribute data is missing from the OMAP5 ES2 hwmod
data. This attribute data needs to be provided in order for the
proper initialization and creation of the iommu platform devices.
The lack of this data was causing a kernel null pointer data abort.

The hwmod class is also adjusted properly for the main ipu and dsp
hwmod devices to point to the omap54xx_hwmod_mmu_class. This is done
to have the OMAP iommu platform devices init properly as they are
based on 'mmu' class name.

Change-Id: I7542e68b2c8b2f75ad56f0efea5dca15e2503d3b
Signed-off-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Subramaniam Chanderashekarapuram <subramaniam.ca@ti.com>
ARM: OMAP5: hwmod data: remove omap54xx_ipu_sysc

The omap54xx_ipu_sysc structure is defined and used with the
omap54xx_ipu_hwmod_class. This class is used with the ipu
processor pseudo-hwmods, which are defined only for reset
purposes. The sysc structure need not be defined for these
hwmods and is therefore cleaned up. An equivalent sysc structure
is defined and used with the main ipu hwmod that also controls
the ipu mmu.

Change-Id: I44d79c18e98efa2d398675dfc8ef91044a4c820a
Signed-off-by: Suman Anna <s-anna@ti.com>
ARM: OMAP54XX: cm1_54xx: consolidate so that just cm1_54xx.h needs inclusion

including the wrong cm1_54xx.h Vs cm1_54xx_es1.h in usage will wreak havoc
in code by the usage of ES2.0 macros in ES1.0 build and viceverca.

So ensure that cm1_54xx.h is the generic header that needs to be included
which will then include ES1.0 or ES2.0 macros as needed.

ES1.0 C data files have not been modified as they are meant to be built
solely for ES1.0. un-modified files are:
arch/arm/mach-omap2/clock54xx_es1_data.c
arch/arm/mach-omap2/clockdomains54xx_es1_data.c
arch/arm/mach-omap2/omap_hwmod_54xx_es1_data.c

Change-Id: I5394fc4d8e5adec42163e4ef6d35440ef49deb36
Signed-off-by: Nishanth Menon <nm@ti.com>
ARM: OMAP54XX: cm2_54xx: consolidate so that just cm2_54xx.h needs inclusion

including the wrong cm2_54xx.h Vs cm2_54xx_es1.h in usage will wreak havoc
in code by the usage of ES2.0 macros in ES1.0 build and viceverca.

So ensure that cm2_54xx.h is the generic header that needs to be included
which will then include ES1.0 or ES2.0 macros as needed.

ES1.0 C data files have not been modified as they are meant to be built
solely for ES1.0. un-modified files are:
arch/arm/mach-omap2/clock54xx_es1_data.c
arch/arm/mach-omap2/clockdomains54xx_es1_data.c
arch/arm/mach-omap2/omap_hwmod_54xx_es1_data.c

Change-Id: Ie39db7a2d0d94fec73145483cb27c9a454ea4cce
Signed-off-by: Nishanth Menon <nm@ti.com>
ARM: OMAP54XX: cm-regbits-54xx: consolidate so that just cm-regbits-54xx.h needs inclusion

including the wrong cm-regbits-54xx.h Vs cm-regbits-54xx_es1.h in usage
will wreak havoc in code by the usage of ES2.0 macros in ES1.0 build and
viceverca.

So ensure that cm-regbits-54xx.h is the generic header that needs to be included
which will then include ES1.0 or ES2.0 macros as needed.

ES1.0 C data files have not been modified as they are meant to be built
solely for ES1.0. un-modified files are:
arch/arm/mach-omap2/clock54xx_es1_data.c
arch/arm/mach-omap2/clockdomains54xx_es1_data.c

Change-Id: I63bc2a2c4070c9662643875ae14598f942c78183
Signed-off-by: Nishanth Menon <nm@ti.com>
ARM: OMAP54XX: prm54xx: consolidate so that just prm54xx.h needs inclusion

including the wrong prm54xx.h Vs prm54xx_es1.h in usage will wreak havoc
in code by the usage of ES2.0 macros in ES1.0 build and viceverca.

So ensure that prm54xx.h is the generic header that needs to be included
which will then include ES1.0 or ES2.0 macros as needed.

ES1.0 C data files have not been modified as they are meant to be built
solely for ES1.0. un-modified files are:
arch/arm/mach-omap2/clock54xx_es1_data.c
arch/arm/mach-omap2/clockdomains54xx_es1_data.c
arch/arm/mach-omap2/omap_hwmod_54xx_es1_data.c
arch/arm/mach-omap2/powerdomains54xx_es1_data.c

Change-Id: Iba46b8e069650b1f3b8f79a3e1d48b320b8b259e
Signed-off-by: Nishanth Menon <nm@ti.com>
ARM: OMAP54XX: prm-regbits-54xx: consolidate so that just prm-regbits-54xx.h needs inclusion

including the wrong prm-regbits-54xx.h Vs prm-regbits-54xx_es1.h in usage
will wreak havoc in code by the usage of ES2.0 macros in ES1.0 build and
viceverca.

So ensure that prm-regbits-54xx.h is the generic header that needs to be
included which will then include ES1.0 or ES2.0 macros as needed.

ES1.0 C data files have not been modified as they are meant to be built
solely for ES1.0. un-modified files are:
arch/arm/mach-omap2/clock54xx_es1_data.c
arch/arm/mach-omap2/omap_hwmod_54xx_es1_data.c
arch/arm/mach-omap2/powerdomains54xx_es1_data.c

Change-Id: Id7a57ab426a645aadb001cda107b2cb8c74ab5b7
Signed-off-by: Nishanth Menon <nm@ti.com>
ARM: OMAP54XX: voltagedomains: use correct registers offsets

On OMAP5 ES2, OMAP54XX_PRM_DEVICE_INST register offset is
changed, comparing with OMAP5 ES1, so all voltagedomains
callbacks should be updated properly - now they use
only OMAP5 offsets.

Change-Id: I7d4b68764ba1f754e55c6a9e46522f53bde7bab0
Signed-off-by: Andrii.Tseglytskyi <andrii.tseglytskyi@ti.com>
ARM: OMAP54XX: SAR / PM: handle USB inst offset delta properly

OMAP5 ES2.0 has a different inst offset for USB, rest of the
register offsets and bit offsets have remained constant
so handle SAR appropriately.

Appropriate header guards are introduced to allow build with
assembly inclusion as well.

Change-Id: Ic4e17a60e0d236bc437cea503a80c73d763c7d7c
Signed-off-by: Nishanth Menon <nm@ti.com>
ARM: OMAP4+: SAR: remove duplicate header includes

Remove duplicated header includes which are included
couple of lines below.

Change-Id: I18125e481852503f10486fbdad387a923887153f
Signed-off-by: Nishanth Menon <nm@ti.com>
ARM: OMAP54XX: PRM: fix device instance handling for IO chain

OMAP5 ES2.0 and OMAP4 have different device instance offsets.

So to handle them properly, use a runtime detected instance offset
Other bit offsets and register offsets remained constant.

Creating a new function is not really worthwhile here as the logic
will be replicated without much benefit.

Change-Id: I3092be1ef581b33eb730c36de263944ce73a60af
Signed-off-by: Nishanth Menon <nm@ti.com>
ARM: OMAP54XX: PM: handle device instance offset in ES2.0 for non-EMIF I/O isolation

OMAP543x ES2.0 has a different PRM_DEVICE_INST offset
compared to ES1.0 OR OMAP4. ES1.0 Vs ES2.0 is compile defined,
However, we need to support OMAP4 Vs OMAP5 runtime, so handle
instance handling based on cpu.

The rest of the parameters are the same, so we leave them alone.

Change-Id: Ibbb99d1dbb055c11e4a598451f771e2d6b0918c2
Signed-off-by: Nishanth Menon <nm@ti.com>
ARM: OMAP54XX: PM: handle prcm_setup_regs device inst properly

OMAP5 ES2.0 and OMAP4 have different device instance offsets.

So to handle them properly, use a runtime detected instance offset
Other than the OMAP4 specific errata implementation, other
bit offsets and register offsets for clkctrl and pwrctrl have
remained constant. So do not touch the OMAP4 specific implementation.
the common usage is now will use runtime detection of instance offset.

Change-Id: Idd7d8d5ceb91cff7bbc9d9a13cafed0a34a54698
Signed-off-by: Nishanth Menon <nm@ti.com>
ARM: OMAP54XX: PM: use proper device instance for reset time programming

OMAP5 ES2.0 and OMAP4 have different device instance offsets.

So to handle them properly, use a runtime detected instance offset
Other bit offsets and register offsets remained constant.

Change-Id: I28911447d5a09a2151e1757e399bb5bed812c81c
Signed-off-by: Nishanth Menon <nm@ti.com>