This allows us to pass dma request lines in platform data to
MMC driver the same way as we already do for omap2430 and later.
Signed-off-by: NTony Lindgren <tony@atomide.com>

This hardware exists only on 2430 and later omaps, so there's no
need to have it in plat-omap/devices.c.

Note that we don't have any users for exported omap_dsp_get_mempool_base(),
so we can make it static.
Signed-off-by: NTony Lindgren <tony@atomide.com>

This hardware exists on omap1 only and there's no need to keep it
in plat-omap/devices.c. No functional changes.
Signed-off-by: NTony Lindgren <tony@atomide.com>

The comments in omap1_init_devices() ask to keep the devices in
alphabetical order. Only omap_init_audio() is not following this,
so let's move it. No functional changes.
Signed-off-by: NTony Lindgren <tony@atomide.com>

The supply is connected to the DSS DO-D5 pins and is thus needed for
both serial and parallel display interfaces on the igep0030 as well as
the igep0020.

If the igep0030 module isn't connected to a display, no DSI or DPI
display will be specified in board code, and the DSS driver won't enable
to VPLL2 regulator anyway.
Signed-off-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Acked-by: NEnric Balletbo i Serra <eballetbo@gmail.com>
Tested-by: NEnric Balletbo i Serra <eballetbo@gmail.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

The INTC core is using a Kconfig option for TI816x which doesn't
exist.  Convert it to use TI81XX.

Cc: Hemant Pedanekar <hemantp@ti.com>
Signed-off-by: NKevin Hilman <khilman@ti.com>
Acked-by: NVaibhav Hiremath <hvaibhav@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

Each irq_chip for the main interrupt controller has offsets set for irq
masking registers, which added to respective base results in a pointer
to appropriate hardware register. However this is not correct for
INTC_CONTROL as there is only one INTC_CONTROL register. This does not
cause problems because generic ack code is never called, but remove
this assignment to avoid confusion.
Signed-off-by: NGrazvydas Ignotas <notasas@gmail.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

Signed-off-by: NChris Lalancette <clalancette@gmail.com>
Signed-off-by: NRoger Quadros <rogerq@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

Add statics to board-omap4-panda.c's internal functions and data
structures to remove sparse warnings:

arch/arm/mach-omap2/board-omap4panda.c:234:29: warning: symbol
'omap_panda_wlan_data' was not declared. Should it be static?
arch/arm/mach-omap2/board-omap4panda.c:441:24: warning: symbol
'omap4_panda_dvi_device' was not declared. Should it be static?
arch/arm/mach-omap2/board-omap4panda.c:451:12: warning: symbol
'omap4_panda_dvi_init' was not declared. Should it be static?
arch/arm/mach-omap2/board-omap4panda.c:512:13: warning: symbol
'omap4_panda_display_init' was not declared. Should it be static?
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

Looks like the register offsets are incorrect in the OMAP mailbox code
(arch/arm/mach-omap2/mailbox.c) for the OMAP4_MAILBOX_IRQ* macros. The
discrepancy is with p.224 of TI document SPRUGX9 and p3891 of SWPU231K.
Acked-by: NVaibhav Bedia <vaibhav.bedia@ti.com>
Signed-off-by: NHenry Chan <enli.chan@gmail.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

arch/arm/plat-omap/devices.c: In function 'omap_dsp_reserve_sdram_memblock':
arch/arm/plat-omap/devices.c:170: warning: format '%x' expects type 'unsigned int', but argument 3 has type 'phys_addr_t'
arch/arm/mach-omap2/dsp.c: In function 'omap_dsp_init':
arch/arm/mach-omap2/dsp.c:60: warning: format '%x' expects type 'unsigned int', but argument 3 has type 'phys_addr_t'
arch/arm/mach-omap2/dsp.c:60: warning: format '%x' expects type 'unsigned int', but argument 4 has type 'phys_addr_t'
Signed-off-by: NFelipe Contreras <felipe.contreras@gmail.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

Merge tag 'omap-devel-c-for-3.5' of git://git.kernel.org/pub/scm/linux/kernel/git/pjw/omap-pending into devel-hwmod-data

Some OMAP IP block data additions for 3.5, along with a
fix for a longstanding watchdog timer integration problem.

platform_device pdev can be NULL if CONFIG_MMC_OMAP_HS is not set.
Add check for NULL pointer. while at it move the duplicated functions
to omap4-common.c

Fixes the following boot crash seen with omap4sdp and omap4panda
when MMC is disabled.

Unable to handle kernel NULL pointer dereference at virtual address 0000008c
pgd = c0004000
[0000008c] *pgd=00000000
Internal error: Oops: 5 [#1] SMP ARM
Modules linked in:
CPU: 0    Not tainted  (3.4.0-rc1-05971-ga4dfa82 #4)
PC is at omap_4430sdp_init+0x184/0x410
LR is at device_add+0x1a0/0x664
Signed-off-by: NBalaji T K <balajitk@ti.com>
Reported-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

SX1 board requirese i2c, so select it in Kconfig, otherwise I have the
following build error:

arch/arm/mach-omap1/board-sx1.c: In function 'sx1_i2c_write_byte':
arch/arm/mach-omap1/board-sx1.c:58:2: error: implicit declaration of function 'i2c_get_adapter' [-Werror=implicit-function-declaration]
arch/arm/mach-omap1/board-sx1.c:58:7: warning: assignment makes pointer from integer without a cast [enabled by default]
arch/arm/mach-omap1/board-sx1.c:67:2: error: implicit declaration of function 'i2c_transfer' [-Werror=implicit-function-declaration]
arch/arm/mach-omap1/board-sx1.c:68:2: error: implicit declaration of function 'i2c_put_adapter' [-Werror=implicit-function-declaration]
arch/arm/mach-omap1/board-sx1.c: In function 'sx1_i2c_read_byte':
arch/arm/mach-omap1/board-sx1.c:82:7: warning: assignment makes pointer from integer without a cast [enabled by default]
cc1: some warnings being treated as errors
make[1]: *** [arch/arm/mach-omap1/board-sx1.o] Error 1
make: *** [arch/arm/mach-omap1] Error 2
make: *** Waiting for unfinished jobs....
Signed-off-by: NArtem Bityutskiy <artem.bityutskiy@linux.intel.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

Without runtime PM enabled, hwmod needs to leave all IP blocks in an
enabled state by default so any driver access to the HW will succeed.
This is accomplished by seting the postsetup_state to enabled for all
hwmods during init when runtime PM is disabled.

Currently, we have a special case for WDT in that its postsetup_state
is always set to disabled.  This is done so that the WDT is disabled
and the timer is disarmed at boot in case there is no WDT driver.
This also means that when runtime PM is disabled, if a WDT driver *is*
built in the kernel, the kernel will crash on the first access to the
WDT hardware.

We can't simply leave the WDT module enabled, because the timer is
armed by default after reset. That means that if there is no WDT
driver initialzed or loaded before the timer expires, the kernel will
reboot.

To fix this, a custom reset method is added to the watchdog class of
omap_hwmod.  This method will *always* disarm the timer after hwmod
reset.  The WDT timer then will only be rearmed when/if the driver is
loaded for the WDT.  With the timer disarmed by default, we no longer
need a special-case for the postsetup_state of WDT during init, so it
is removed.

Any platforms wishing to ensure the watchdog remains armed across the
entire boot boot can simply disable the reset-on-init feature of the
watchdog hwmod using omap_hwmod_no_setup_reset().

Tested on 3530/Overo, 4430/Panda.

NOTE: on 4430, the hwmod OCP reset does not seem to rearm the timer as
documented in the TRM (and what happens on OMAP3.)  I noticed this
because testing the HWMOD_INIT_NO_RESET feature with no driver loaded,
I expected a reboot part way through the boot, but did not see a
reboot.  Adding some debug to read the counter, I verified that right
after OCP softreset, the counter is not firing.  After writing the
magic start sequence, the timer starts counting.  This means that the
timer disarm sequence added here does not seem to be needed for 4430,
but is technically the correct way to ensure the timer is disarmed, so
it is left in for OMAP4.

Special thanks to Paul Walmsley for helping brainstorm ideas to fix
this problem.

Cc: Paul Walmsley <paul@pwsan.com>
Signed-off-by: NKevin Hilman <khilman@ti.com>
Cc: Santosh Shilimkar <santosh.shilimkar@ti.com>
Acked-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
[paul@pwsan.com: updated the omap2_wd_timer_reset() function in the
 wake of commit 3c55c1ba ("ARM:
 OMAP2+: hwmod: Revert "ARM: OMAP2+: hwmod: Make omap_hwmod_softreset
 wait for reset status""); added kerneldoc; rolled in warning fix from Kevin]
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

Add 32k-sync timer hwmod-data and add ocp_if details to
omap2 & 3 hwmod table.
Signed-off-by: NVaibhav Hiremath <hvaibhav@ti.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>
Reviewed-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
Cc: Benoit Cousson <b-cousson@ti.com>
Cc: Tony Lindgren <tony@atomide.com>
Cc: Paul Walmsley <paul@pwsan.com>
Cc: Kevin Hilman <khilman@ti.com>
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

Use 'common' as name for the common irq number in hwmod data for the McBSP
ports. The same name already in use for OMAP2430, and OMAP3.
Signed-off-by: NPeter Ujfalusi <peter.ujfalusi@ti.com>
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

Restore of context is not done for OMAP4. This patch
adds the OMAP_I2C_FLAG_RESET_REGS_POSTIDLE in the OMAP4
hwmod data which activates the restore for OMAP4.
Currently the OMAP4 does not hit device off still the
driver may have support for it.

Cc: Benoit Cousson <b-cousson@ti.com>
Cc: Paul Wamsley <paul@pwsan.com>
Reviewed-by: NKevin Hilman <khilman@ti.com>
Signed-off-by: NShubhrajyoti D <shubhrajyoti@ti.com>
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

Use 'common' as name for the common irq number in hwmod data for the McBSP
ports. The same name already in use for OMAP2430, and the OMAP4 hwmod data
will be using the same name.
Signed-off-by: NPeter Ujfalusi <peter.ujfalusi@ti.com>
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

Add the HDQ1W hwmod for all OMAP2xxx devices.

Assume that OMAP2xxx chips have the same HDQ idle handling bug
as OMAP3:

   http://www.spinics.net/lists/linux-omap/msg63576.html

and set the OCPIF_SWSUP_IDLE flag accordingly on the HDQ's OCP interface.
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

Add the HDQ1W hwmod for OMAP34xx, OMAP36xx, and AM3505/3517 devices.
According to the respective TRMs, it doesn't appear to be available for the
816x/814x or the AM335x.

The OCPIF_SWSUP_IDLE flag is added to work around an apparent hardware
bug: the hardware is not taking the CM_FCLKEN*_CORE.EN_HDQ bit into
account when considering whether to go idle:

    http://www.spinics.net/lists/linux-omap/msg63576.html

This causes HDQ transfers to fail or become corrupt.  Thanks to
NeilBrown for his help diagnosing and testing fixes for this problem.
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
Cc: NeilBrown <neilb@suse.de>
Tested-by: NNeilBrown <neilb@suse.de>

Much of the HDQ1W integration data is common between multiple generations
of OMAP SoCs, so rather than make several copies, we add it once into
files which are compiled for multiple SoCs.
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
Cc: NeilBrown <neilb@suse.de>
Tested-by: NNeilBrown <neilb@suse.de>

Implement a custom reset function for the HDQ1W IP block.  This is
because the HDQ1W IP block, like I2C, has an internal clock gating bit
that needs to be toggled after setting the SOFTRESET bit to allow the
reset to propagate.
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
Cc: NeilBrown <neilb@suse.de>
Cc: Avinash.H.M <avinashhm@ti.com>
Tested-by: NNeilBrown <neilb@suse.de>

Add MMC for 2420 so we can pass the DMA request lines the same
way as we already do on omap2430 and later.

Cc: Benoit Cousson <b-cousson@ti.com>
Cc: Paul Walmsley <paul@pwsan.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>
[paul@pwsan.com: updated to apply on top of the 3.5 hwmod cleanup;
 changed mmc hwmod name/class to "msdi" as documented in the 2420 TRM Rev X;
 added sysconfig register information; added 16 bit register width flag;
 added MSDI custom reset code]
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

Merge tag 'omap-devel-b-for-3.5' of git://git.kernel.org/pub/scm/linux/kernel/git/pjw/omap-pending into devel-prcm

Some OMAP PRCM updates for 3.5.  Includes some clock, clockdomain,
powerdomain, PRM, and CM changes.

Merge branches 'clock_am35xx_cleanup_3.5', 'prm_cm_devel_a_3.5', 'clock_devel_a_3.5' and 'pwrdm_clkdm_cleanup_3.5' into prcm_devel_a_3.5

Clean up clockdomains3xxx_data.c a bit by removing the superfluous
commas in gfx_sgx_3xxx_wkdeps[].
Signed-off-by: NMark A. Greer <mgreer@animalcreek.com>
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

With patch 'ARM: OMAP2+: powerdomain: Wait for powerdomain transition
in pwrdm_state_switch()', the pwrdm_clkdm_state_switch() API becomes
duplicate of pwrdm_state_switch().

Get rid off duplicate pwrdm_clkdm_state_switch() and update the
users of it with pwrdm_state_switch()
Signed-off-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
Cc: Rajendra Nayak <rnayak@ti.com>
Cc: Paul Walmsley <paul@pwsan.com>
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

Add the correct clockdomain for the HDQ functional clock.  This is needed
for the clock and hwmod PM code to work correctly.
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
Cc: NeilBrown <neilb@suse.de>

The current DPLL code enables and disables autoidle features
without checking whether the autoidle register is available.
Fix this by putting a check for the existence of the autoidle
register in the DPLL data.

With such a check in place, for DPLLs which do not support this
feature, simply skipping the autoidle_reg entry in the DPLL data
is sufficient.
Signed-off-by: NVaibhav Bedia <vaibhav.bedia@ti.com>
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

We do not use iclk anywhere in the dmtimer driver and so removing it.
Hence removing the timer iclk entries from OMAP4 clkdev table as well.
Signed-off-by: NTarun Kanti DebBarma <tarun.kanti@ti.com>
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

Instead of statically defining seperate arrays for every OMAP4+ archs,
have a generic init function to populate the arrays. This avoids the
need for creating new array for every arch added in the future that
reuses the prm and cm registers read/write code.

Cc: Paul Walmsley <paul@pwsan.com>
Signed-off-by: NR Sricharan <r.sricharan@ti.com>
Signed-off-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

Add missing idle_st bit for 32k-sync timer into the prcm-common
header file, required for hwmod data.
Signed-off-by: NVaibhav Hiremath <hvaibhav@ti.com>
Reviewed-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
Cc: Felipe Balbi <balbi@ti.com>
Cc: Benoit Cousson <b-cousson@ti.com>
Cc: Tony Lindgren <tony@atomide.com>
Cc: Paul Walmsley <paul@pwsan.com>
Cc: Kevin Hilman <khilman@ti.com>
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

The register bits for MPU_CLK_SRC and IVA2_CLK_SRC in CM_CLKSEL1_PLL
register are 3 bits wide.  Fix the MASK definition accordingly.
Signed-off-by: NRajendra Nayak <rnayak@ti.com>
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

To improve the clarity of the code, replace the CK_3517 flag used in
the clock data with CK_AM35XX.  The CK_3505 flag can also be
removed, since it is now unused.
Acked-by: NVaibhav Hiremath <hvaibhav@ti.com>
Signed-off-by: NKevin Hilman <khilman@ti.com>
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

The init for 3505/3517 specific clocks depends on the ordering of
cpu_is checks, is error prone and confusing (there are 2 separate
checks for cpu_is_omap3505()).

Remove the 3505-specific checking since CK_3505 flag is not used, and
treat all AM35x clocks the same.

This means that the SGX clock (the only AM35x clkdev not currently
flagged for 3505) will now be registered on 3505, but that is
harmless.  That can be cleaned up when the clkdev nodes are removed in
favor of them being registered by hwmod.
Acked-by: NVaibhav Hiremath <hvaibhav@ti.com>
Tested-by: NVaibhav Hiremath <hvaibhav@ti.com>
Signed-off-by: NKevin Hilman <khilman@ti.com>
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

The AM35x UART4 is common to all AM35x devices, so use CK_AM35XX instead
of (CK_3505 | CK_3517), which is equivalent.
Acked-by: NVaibhav Hiremath <hvaibhav@ti.com>
Tested-by: NVaibhav Hiremath <hvaibhav@ti.com>
Signed-off-by: NKevin Hilman <khilman@ti.com>
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

Pull x86 fixes form Peter Anvin

* 'x86-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
  intel_mid_powerbtn: mark irq as IRQF_NO_SUSPEND
  arch/x86/platform/geode/net5501.c: change active_low to 0 for LED driver
  x86, relocs: Remove an unused variable
  asm-generic: Use __BITS_PER_LONG in statfs.h
  x86/amd: Re-enable CPU topology extensions in case BIOS has disabled it