Add MMC5 support on PANDA, which has the wl1271 device hardwired to.

The wl1271 is a 4-wire, 1.8V, embedded SDIO WLAN device with an
external IRQ line, and power-controlled by a GPIO-based fixed regulator.

Based on the patch for mmc3/wl1271 device support for zoom by Ohad
Ben-Cohen <ohad@wizery.com>
Signed-off-by: NPanduranga Mallireddy <panduranga_mallireddy@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

Add a fixed regulator vmmc device to enable power control
of the wl1271 wlan device.

Based on the patch for zoom by Ohad Ben-Cohen <ohad@wizery.com>
Signed-off-by: NPanduranga Mallireddy <panduranga_mallireddy@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

Power to the wl12xx wlan device is controlled by a fixed regulator.
Boards that have the wl12xx should select REGULATOR_FIXED_VOLTAGE.
Signed-off-by: NPanduranga Mallireddy <panduranga_mallireddy@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

Add board muxing to support the wlan wl1271 chip that is
hardwired to mmc5 (fifth mmc controller) on the PANDA.

Based on the wlan board muxing for zoom3 by Ohad Ben-Cohen
<ohadb@ti.com>
Signed-off-by: NPanduranga Mallireddy <panduranga_mallireddy@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

Signed-off-by: NBalaji T K <balajitk@ti.com>
Tested-by: NKishore Kadiyala <kishore.kadiyala@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

Fixed regulators in twl6030 do not have set_voltage hook.
Regulator core returns -22 if set_voltage is NULL and apply_uV is set
while applying the constraint to set voltage resulting in failure during probe
of these regulators.
Do not set apply_uV for fixed regulators which don't have set_voltage.

machine_constraints_voltage: VANA: failed to apply 2100000uV constraint
twl_reg twl_reg.43: can't register VANA, -22
twl_reg: probe of twl_reg.43 failed with error -22
machine_constraints_voltage: VCXIO: failed to apply 1800000uV constraint
twl_reg twl_reg.44: can't register VCXIO, -22
twl_reg: probe of twl_reg.44 failed with error -22
machine_constraints_voltage: VDAC: failed to apply 1800000uV constraint
twl_reg twl_reg.45: can't register VDAC, -22
twl_reg: probe of twl_reg.45 failed with error -22
Signed-off-by: NBalaji T K <balajitk@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

clean the regulator supply mapping data in the 3430sdp
board file (which is spread all over) by moving all
of them together.
Also use the REGULATOR_SUPPLY macro and remove instances
of mapping dev pointers at run time.
Additonally define all regulator_consumer_supply as
array's and use ARRAY_SIZE macro to define
num_consumer_supplies.
Signed-off-by: NRajendra Nayak <rnayak@ti.com>
Reviewed-by: NFelipe Balbi <balbi@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

On the OMAP3430SDP board, the ads7846 touchscreen controller
is powered by VAUX3 regulator (supplying 2.8v).
Fix this mapping in the board file, and hence prevent
the ads7846 driver init to fail with the below error..

ads7846 spi1.0: unable to get regulator: -19
Signed-off-by: NRajendra Nayak <rnayak@ti.com>
Reviewed-by: NFelipe Balbi <balbi@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

Set OMAP_PIN_OFF_WAKEUPENABLE to enable the wake-up
functionality from touchscreen controller.
Signed-off-by: NVaibhav Hiremath <hvaibhav@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

If you choose default output to DVI, the LCD backlight used to
stay on, since panel->disable function never gets called.

So, during init put backlight GPIO to off state and the driver
code will decide which output to enable.
Signed-off-by: NVaibhav Hiremath <hvaibhav@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

To support higher resolution (e.g 720P@60), on OMAP36x (AM/DM37x)
DSS data bus has been muxed with sys_boot pins.

DSS[18-23] => DSS[0-5]
sys_boot[0,1 3-5] => DSS[18-23]

EVM revision >=RevB adopt this mux changes, which is going to ship outside.
Signed-off-by: NVaibhav Hiremath <hvaibhav@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

Add vio regulator supply, needed for ads7846 touchscreen controller
driver.

Tested on OMAP3 (ES3.1 Si) RevG version of EVM.
Signed-off-by: NVaibhav Hiremath <hvaibhav@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

Since TWL GPIO's can go into sleep, and using normal
gpio_get/set_value() API will lead to kernel dump (WARN_ON()).
So replacing standard gpio_get/set_value() to
gpio_get/set_value_cansleep().
Signed-off-by: NVaibhav Hiremath <hvaibhav@ti.com>
Reviewed-by: NCharulatha V <charu@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

With addition of hwmod support to gpio, the ethernet controller
goes undetected for OMAP35xEVM. So explicitly assert the reset signal to
ethernet controller smsc911x -

	- GPIO7 (>=RevG version of EVM's)
	- GPIO64 (<=RevD version of EVM's)

Tested this patch on RevG version of EVM with ES3.1 Si.

This patch is based on intial version from Charulatha V, reference
to original discussion -
http://www.mail-archive.com/linux-omap@vger.kernel.org/msg35784.htmlSigned-off-by: NVaibhav Hiremath <hvaibhav@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

Adds platform initialization for working with the WLAN module attached to the evaluation module.
The patch includes MMC2 initialization, SDIO and control pins muxing and platform device registration
Signed-off-by: NEyal Reizer <eyalr@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

Cleans up all base address definitions for omap_mcspi
and adapts the device registration and driver to hwmod framework.
Changes involves:
1) Removing all base address macro defines.
2) Using omap-device layer to register device and utilizing data from
   hwmod data file for base address, dma channel number, Irq_number,
   device attribute(number of chipselect).
3) Appending base address with pdata reg_offset for omap4 boards.
   For omap4 all regs used in driver deviate with reg_offset_macros
   defined with an value of 0x100. So pass this offset through pdata
   and append the same to base address retrieved from hwmod data file
   and we are not mapping *_HL_* regs which are not used in driver.
Signed-off-by: NCharulatha V <charu@ti.com>
Signed-off-by: NGovindraj.R <govindraj.raja@ti.com>
Acked-by: NGrant Likely <grant.likely@secretlab.ca>
Reviewed-by: NPartha Basak <p-basak2@ti.com>
Reviewed-by: NKevin Hilman <khilman@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

Update omap3 hwmod data file with McSPI info.
Signed-off-by: NCharulatha V <charu@ti.com>
Signed-off-by: NGovindraj.R <govindraj.raja@ti.com>
Acked-by: NGrant Likely <grant.likely@secretlab.ca>
Reviewed-by: NKevin Hilman <khilman@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

Update the 2430 hwmod data file with McSPI info.
Signed-off-by: NCharulatha V <charu@ti.com>
Signed-off-by: NGovindraj.R <govindraj.raja@ti.com>
Acked-by: NGrant Likely <grant.likely@secretlab.ca>
Reviewed-by: NKevin Hilman <khilman@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

Update the omap2420 hwmod data with the McSPI info.
Add a device attribute structure which will be used
for passing number of chipselects from hwmod data.
Add revision macros to be passed from rev field from
hwmod.
Signed-off-by: NCharulatha V <charu@ti.com>
Signed-off-by: NGovindraj.R <govindraj.raja@ti.com>
Acked-by: NGrant Likely <grant.likely@secretlab.ca>
Reviewed-by: NKevin Hilman <khilman@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

Build and register an hwspinlock platform device.

Although only OMAP4 supports the hardware spinlock module (for now),
it is still safe to run this initcall on all omaps, because hwmod lookup
will simply fail on hwspinlock-less platforms.
Signed-off-by: NSimon Que <sque@ti.com>
Signed-off-by: NHari Kanigeri <h-kanigeri2@ti.com>
Signed-off-by: NOhad Ben-Cohen <ohad@wizery.com>
Cc: Benoit Cousson <b-cousson@ti.com>
Cc: Kevin Hilman <khilman@ti.com>
Cc: Paul Walmsley <paul@pwsan.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

OMAP4 hwmod data structures are populated with base address, L3 and L4
interface clocks, IRQs and sysconfig register details.

As per OMAP USBOTG specification, need to configure the USBOTG
to smart idle/standby or no idle/standby during data transfer and
force idle/standby when not in use to support retention and offmode.
By setting HWMOD_SWSUP_SIDLE and HWMOD_SWSUP_MSTANDBY flags,framework
will take care of configuring to no idle/standby when module is enabled
and force idle/standby when idled.
Signed-off-by: NCousson, Benoit <b-cousson@ti.com>
Signed-off-by: NHema HK <hemahk@ti.com>
Cc: Tony Lindgren <tony@atomide.com>
Cc: Kevin Hilman <khilman@deeprootsystems.com>
Cc: Paul Walmsley <paul@pwsan.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>
[b-cousson@ti.com: Fix position, opt_clk, and author]

Add more hwmod structures but keep them commented out for the moment
until the driver adaptation to hwmod / omap_device is done.
Signed-off-by: NBenoit Cousson <b-cousson@ti.com>
Cc: Paul Walmsley <paul@pwsan.com>
Cc: Kevin Hilman <khilman@ti.com>

Add mcbsp data including a revision member in hwmod_class in
order to provide mcbsp revision information in different omap.
Signed-off-by: NBenoit Cousson <b-cousson@ti.com>
Signed-off-by: NKishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: NCharulatha V <charu@ti.com>
[b-cousson@ti.com: Remove the mcbsp4 memory name, re-order
properly the structures]

Add HWMOD entries for the OMAP DMIC. The HWMOD entires define the system
resource requirements for the driver such as DMA addresses, channels,
and IRQ's. Placing this information in the HWMOD database allows for
more generic drivers to be written and having the specific implementation
details defined in HWMOD.
Signed-off-by: NBenoit Cousson <b-cousson@ti.com>
Signed-off-by: NDavid Lambert <dlambert@ti.com>
[b-cousson@ti.com: Change the wrong hwmod name,
add missing flag and re-order structures]

Mailbox hwmod data for omap4.
Signed-off-by: NBenoit Cousson <b-cousson@ti.com>
Signed-off-by: NOmar Ramirez Luna <omar.ramirez@ti.com>
[b-cousson@ti.com: Re-order the structures
and remove the irq line name]

Add dss, dispc, dsi1, dsi2, hdmi, rfbi and venc hwmods.
In OMAP4 there are severals IPs that can be reached by differents
interconnect paths depending of the access initiator (MPU vs. SDMA).
In the case of the DSS, both L3 direct path and L4 CFG path can be
used to access all the DSS IPs. The two ocp_ip already exists to support
the two address spaces.

      +------------+-- L3_MAIN --+ MPU
  IP  |            |
      +-- L4_CFG --+

L3 main address range is specified first, since it is used by default.
dss is also considered as an IP as dispc, rfbi, and named as dss_core.
Signed-off-by: NBenoit Cousson <b-cousson@ti.com>
Signed-off-by: NMayuresh Janorkar <mayur@ti.com>
Signed-off-by: NSenthilvadivu Guruswamy <svadivu@ti.com>
Signed-off-by: NSumit Semwal <sumit.semwal@ti.com>
[b-cousson@ti.com: Re-organize structures to match file
convention and remove irq entry from dss_hwmod]

Add the data for the 11 timers IPs.
OMAP4 contains two differents IP variants for the timers:
- 8 x regular timer (3, 4, 5, 6, 7, 8, 9 & 11)
- 3 x 1ms timer (1, 2 & 10)

The regular timers registers programming model was changed due to the
adaptation to the new IP interface. Unfortunately the 1ms version
still use the previous programming model. The driver will have
to take care of theses differences.

Please note that the capability and the partitioning is also
different depending of the instance.
- timer 1 is inside the wakeup domain
- timers 5, 6, 7 & 8 are inside in the ABE (audio backend)
- timers 2, 3, 4, 9, 10 & 11 are inside the PER power domain

The timer was previously named gptimerX or dmtimerX, it is
now simply named timerX.
Signed-off-by: NBenoit Cousson <b-cousson@ti.com>
Signed-off-by: NTarun Kanti DebBarma <tarun.kanti@ti.com>
[b-cousson@ti.com: Fix alignement in class attribute,
re-order flags and update the changelog]

Update omap4 hwmod file with McSPI info.
Signed-off-by: NBenoit Cousson <b-cousson@ti.com>
Signed-off-by: NCharulatha V <charu@ti.com>
Signed-off-by: NGovindraj.R <govindraj.raja@ti.com>
Acked-by: NGrant Likely <grant.likely@secretlab.ca>
Reviewed-by: NKevin Hilman <khilman@ti.com>

Add hwspinlock hwmod data for OMAP4 chip
Signed-off-by: NCousson, Benoit <b-cousson@ti.com>
Signed-off-by: NHari Kanigeri <h-kanigeri2@ti.com>
Signed-off-by: NOhad Ben-Cohen <ohad@wizery.com>
Cc: Paul Walmsley <paul@pwsan.com>
[b-cousson@ti.com: Move the data to keep the original
order and add missing SIDLE_SMART_WKUP flag]

Update to use init_early
Signed-off-by: NTony Lindgren <tony@atomide.com>

This patch adds support for low level debugging on TI816X boards. Currently the
support for UART3 console on TI816X EVM is added.
Signed-off-by: NHemant Pedanekar <hemantp@ti.com>
Reviewed-by: NKevin Hilman <khilman@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

This patch adds minimal support and build configuration for TI816X EVM.
Signed-off-by: NHemant Pedanekar <hemantp@ti.com>
Reviewed-by: NKevin Hilman <khilman@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

This patch updates the common machine specific source files with support for
TI816X.
Signed-off-by: NHemant Pedanekar <hemantp@ti.com>
Reviewed-by: NKevin Hilman <khilman@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

This patch updates the common platform files with TI816X support.

The approach taken in this patch is to add TI816X as part of OMAP3 variant where
the cpu class is considered as OMAP34XX and the type is TI816X. This means, both
cpu_is_omap34xx() and cpu_is_ti816x() checks return success on TI816X.

A kernel config option CONFIG_SOC_OMAPTI816X is added under OMAP3 to include
support for TI816X build.
Signed-off-by: NHemant Pedanekar <hemantp@ti.com>
Reviewed-by: NKevin Hilman <khilman@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

The secondary interrupt controller of the ColdFire 5249 code is not
setting the edge triggered flow handler. Set it.
Signed-off-by: NGreg Ungerer <gerg@uclinux.org>

The m68knommu arch does not define or use IRQ_FLG_LOCK in its irq
subsystem. Remove obsolete use of it.
Signed-off-by: NGreg Ungerer <gerg@uclinux.org>

Add missing linker section __modver to fix:

  LD      vmlinux
/usr/local/bin/../m68k-uclinux/bin/ld.real: error: no memory region specified for loadable section `__modver'
Signed-off-by: NGreg Ungerer <gerg@uclinux.org>

Compiling for 68360 targets gives:

  CC      arch/m68knommu/platform/68360/ints.o
arch/m68knommu/platform/68360/ints.c: In function ‘init_IRQ’:
arch/m68knommu/platform/68360/ints.c:135:16: error: ‘irq’ undeclared (first use in this function)
arch/m68knommu/platform/68360/ints.c:135:16: note: each undeclared identifier is reported only once for each function it appears in

Fix variable name used.
Signed-off-by: NGreg Ungerer <gerg@uclinux.org>

Add an m68k/coldfire optimized memmove() function for the m68knommu arch.
This is the same function as used by m68k. Simple speed tests show this
is faster once buffers are larger than 4 bytes, and significantly faster
on much larger buffers (4 times faster above about 100 bytes).

This also goes part of the way to fixing a regression caused by commit
ea61bc46 ("m68k/m68knommu: merge MMU and
non-MMU string.h"), which breaks non-coldfire non-mmu builds (which is
the 68x328 and 68360 families). They currently have no memmove() fucntion
defined, since there was none in the m68knommu/lib functions.
Signed-off-by: NGreg Ungerer <gerg@uclinux.org>

The m68k arch implements its own memcmp() function. It is not optimized
in any way (it is the most strait forward coding of memcmp you can get).
Remove it and use the kernels standard memcmp() implementation.

This also goes part of the way to fixing a regression caused by commit
ea61bc46 ("m68k/m68knommu: merge MMU and
non-MMU string.h"), which breaks non-coldfire non-mmu builds (which is
the 68x328 and 68360 families). They currently have no memcmp() function
defined, since there is none in the m68knommu/lib functions.
Signed-off-by: NGreg Ungerer <gerg@uclinux.org>
Acked-by: NGeert Uytterhoeven <geert@linux-m68k.org>