The omap3pandora board file currently passes the reset gpio number to the
tpo-td043mtea1 panel driver via the reset_gpio field in omap_dss_device.

Platform related information should be passed via the panel driver's platform
data struct.

Add the reset gpio information to panel_tpo_td043_data so that it's passed to
the panel driver.
Signed-off-by: NArchit Taneja <archit@ti.com>
Cc: Tony Lindgren <tony@atomide.com>

The zoom board file currently requests gpios required by the nec-nl8048hl11-01
dpi panel, and provides dummy platform_enable/disable callbacks.

gpio request and configuration have been moved to the nec-nl8048hl11-01 panel
driver itself and shouldn't be done in the board files.

Remove the gpio requests and the platform callbacks from the board file. Add the
gpio information to panel_nec_nl8048_data so that it's passed to the panel
driver.
Signed-off-by: NArchit Taneja <archit@ti.com>
Cc: Tony Lindgren <tony@atomide.com>

The rx-51 board file currently requests gpios required by the acx565akm panel,
and provides platform_enable/disable callbacks to configure them.

These tasks have been moved to the acx565akm panel driver itself and shouldn't
be done in the board files.

Remove the gpio requests and the platform callbacks from the board file. Pass
the panel_acx565akm_data instance 'lcd_data' to omap_dss_device instead of
passing the gpio number in omap_dss_device's reset_gpio.

Add the gpio information to panel_acx565akm_data so that it's passed to the
panel driver.
Signed-off-by: NArchit Taneja <archit@ti.com>
Cc: Tony Lindgren <tony@atomide.com>

The omap3430sdp board file currently requests gpios required by the sharp_ls dpi
panel, and provides platform_enable/disable callbacks to configure them.

These tasks have been moved to the sharp_ls panel driver itself and shouldn't
be done in the board files.

Remove the gpio requests and the platform callbacks from the board file.
Add the gpio information to panel_sharp_ls037v7dw01_data so that it's
passed to the panel driver.

Out of sharp panel's configurable pins, all apart from resb_gpio are managed by
a CPLD on the display and set to a default value. Only the configurable pin is
passed to platform data.

The backlight GPIO doesn't go directly to the sharp panel, it is used to set up
a voltage supply which goes to the LED+ pin of the panel, hence it isn't passed
to panel as platform data, and configured in the board file itself. The
backlight used to previously toggle through the platform_enable/disable
callbacks, but now it is always on. This needs to be revisited.
Signed-off-by: NArchit Taneja <archit@ti.com>
Cc: Tony Lindgren <tony@atomide.com>

The omap3evm board file currently requests gpios required by the sharp_ls dpi
panel, and provides platform_enable/disable callbacks to configure them.

These tasks have been moved to the sharp_ls panel driver itself and shouldn't
be done in the board files.

Remove the gpio requests and the platform callbacks from the board file.
Add the gpio information to panel_sharp_ls037v7dw01_data so that it's passed
to the panel driver.

Note: The GPIOs OMAP3EVM_LCD_PANEL_ENVDD and OMAP3EVM_LCD_PANEL_BKLIGHT_GPIO
aren't directly connected to the sharp panel, hence they aren't passed to the
panel driver as platform data. These are set to a default value such that LCD
is enabled and backlight is on. These used to previously toggle through the
platform_enable/disable callbacks, but now these are always on. This needs to
be revisited.
Signed-off-by: NArchit Taneja <archit@ti.com>
Cc: Tony Lindgren <tony@atomide.com>

The overo board file currently requests gpios required by the lb035q02 panel,
and provides platform_enable/disable callbacks to configure them.

These tasks have been moved to the lb035q02 dpi panel driver itself and should
be removed from the board files.

The lb035q02 panel driver uses generic dpi panel's platform data struct
internally. Remove the gpio requests and the platform callbacks from the board
file. Add the gpio information to the generic dpi panel platform data struct so
that it's passed to the panel driver.
Signed-off-by: NArchit Taneja <archit@ti.com>
Cc: Tony Lindgren <tony@atomide.com>

The ldp board file currently requests gpios required to configure the NEC DPI
panel, and provides platform_enable/disable callbacks to configure them.

These tasks have been moved to the generic dpi panel driver itself and shouldn't
be done in the board files.

Remove the gpio requests and the platform callbacks from the board file.
Configure the gpio information in generic dpi panel's platform data so that it's
passed to the panel driver.
Signed-off-by: NArchit Taneja <archit@ti.com>
Cc: Tony Lindgren <tony@atomide.com>

The am3517 board file currently requests gpios required to configure the sharp
lq DPI panel, and provides platform_enable/disable callbacks to configure them.

These tasks have been moved to the generic dpi panel driver itself and shouldn't
be done in the board files.

Remove the gpio requests and the platform callbacks from the board file.
Add the gpio information to generic dpi panel's platform data so that it's
passed to the panel driver.

Note: It's not clear why the GPIOs were muxed as input signals in PULL down mode
in am3517_evm_display_init(). Also, only the LCD_PANEL_PWR was toggled in the
platform_enable/disable calls, the generic DPI panel driver will now toggle all
the three gpios on panel's disable/enable. We need to test if these changes to
see if they have any impact or not.
Signed-off-by: NArchit Taneja <archit@ti.com>
Cc: Tony Lindgren <tony@atomide.com>
Cc: Vaibhav Hiremath <hvaibhav@ti.com>

The cm-t35 board file currently requests gpios required to configure the tdo35s
panel, and provides platform_enable/disable callbacks to configure them.

These tasks have been moved to the generic dpi panel driver itself and shouldn't
be done in the board files.

Remove the gpio requests and the platform callbacks from the board file.
Add the gpio information to generic dpi panel's platform data so that it's
passed to the panel driver.

Note: Only BL enable gpio is handled in the panel driver. The LCD enable
GPIO is handled in the board file at init time, as there's a 50 ms delay
required when using the GPIO, and the panel driver doesn't know about
that.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
Cc: Tony Lindgren <tony@atomide.com>
Acked-by: NIgor Grinberg <grinberg@compulab.co.il>

The devkit8000 board file currently requests gpios required to configure the
innolux DPI panel, and provides platform_enable/disable callbacks to configure
them.

These tasks have been moved to the generic dpi panel driver itself and should
be removed from the board files.

Remove the gpio request and the platform callbacks from the board file.
Configure the gpio information in generic dpi panel's platform data so that it's
passed to the panel driver.
Signed-off-by: NArchit Taneja <archit@ti.com>
Cc: Tony Lindgren <tony@atomide.com>

The 2430sdp board file currently requests gpios required to configure the NEC
DPI panel, and provides platform_enable/disable callbacks to configure them.

These tasks have been moved to the generic dpi panel driver itself and shouldn't
be done in the board files.

Remove the gpio requests and the platform callbacks from the board file.
Add the gpio information to generic dpi panel's platform data so that it's
passed to the panel driver.
Signed-off-by: NArchit Taneja <archit@ti.com>
Cc: Tony Lindgren <tony@atomide.com>

Use pwm_leds driver for the keyboard light and pwm-backlight for the lcd
backlight control (instead of implementing the PWM driver part in the board
file).
Signed-off-by: NPeter Ujfalusi <peter.ujfalusi@ti.com>
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

Structs for platform data of omapdss panels are found in headers in the
'include/video/' path. Board files populate these structs with platform
specific values, and the panel driver uses these to configure the panel.

Currently, each panel has it's own header in the above path. Move all the
omapdss panel platform data structs to a single header omap-panel-data.h.
This is useful because:

- All other omapdss panel drivers will be modified to use platform data. This
  would lead to a lot of panel headers usable only by omapdss. A lot of these
  platform data structs are trivial, and don't really need a separate header.
- Platform data would be eventually removed, and platform information would be
  passed via device tree. Therefore, omapdss panel platform data structs are
  temporary, and will be easier to remove if they are all in the same header.
- All board files will have to include the same header to configure a panel's
  platform data, that makes the board files more consistent.
Signed-off-by: NArchit Taneja <archit@ti.com>

Commit 51482be9 (ARM: OMAP: USB: Add phy binding information) forgot to
add phy binding for RX-51, and as a result USB does not work anymore on
3.9-rc1. Add the missing binding.
Signed-off-by: NAaro Koskinen <aaro.koskinen@iki.fi>
Reviewed-by: NKishon Vijay Abraham I <kishon@ti.com>
Acked-by: NFelipe Balbi <balbi@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

Commit bbd707ac {ARM: omap2: use machine specific hook for late init}
accidentally added two declarations for omap4430_init_late().

Remove the duplicate declaration.

Cc: Shawn Guo <shawn.guo@linaro.org>
Signed-off-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
Reviewed-by: NFelipe Balbi <balbi@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

This is needed because the omap_mux_get_by_name()
function calls the _omap_mux_get_by_name subfunction
for each mux partition until needed mux is not found.
As a result, we get messages like
"Could not find signal XXX" for each partition
where this mux name does not exist.

This patch fixes wrong error message in
the _omap_mux_get_by_name() function moving it
to the omap_mux_get_by_name() one and as result
reduces noise in the kernel log.

My kernel log without this patch:
[...]
[    0.221801] omap_mux_init: Add partition: #2: wkup, flags: 3
[    0.222045] _omap_mux_get_by_name: Could not find signal fref_clk0_out.sys_drm_msecure
[    0.222137] _omap_mux_get_by_name: Could not find signal sys_nirq
[    0.222167] _omap_mux_get_by_name: Could not find signal sys_nirq
[    0.225006] _omap_mux_get_by_name: Could not find signal uart1_rx.uart1_rx
[    0.225006] _omap_mux_get_by_name: Could not find signal uart1_rx.uart1_rx
[    0.270111] _omap_mux_get_by_name: Could not find signal fref_clk4_out.fref_clk4_out
[    0.273406] twl: not initialized

[...]

My kernel log with this patch:
[...]
[    0.221771] omap_mux_init: Add partition: #2: wkup, flags: 3
[    0.222106] omap_mux_get_by_name: Could not find signal sys_nirq
[    0.224945] omap_mux_get_by_name: Could not find signal uart1_rx.uart1_rx
[    0.274536] twl: not initialized
[...]
Signed-off-by: NRuslan Bilovol <ruslan.bilovol@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

OMAP's debugfs interface creates one file
for each signal in the mux table, such file
provides a read method but didn't provide
read permission. Fix it.
Signed-off-by: NFelipe Balbi <balbi@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

We should not select drivers from kconfig as they should by default
be optional. Otherwise we'll be chasing broken dependencies forever:

warning: (MACH_OMAP_ZOOM2 && MACH_OMAP_ZOOM3 && MWAVE) selects SERIAL_8250
which has unmet direct dependencies (TTY && HAS_IOMEM && GENERIC_HARDIRQS)

Fix the issue by removing the selects for zoom and add them to
omap2plus_defconfig.
Reported-by: NRussell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: NTony Lindgren <tony@atomide.com>

The .init_late callback for OMAP3 has been missing for DT
builds, which causes a lot of late PM initializations to
be missed in turn.
Signed-off-by: NRajendra Nayak <rnayak@ti.com>
Acked-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

Commit 6797b4fe (ARM: OMAP2+: Prevent potential crash if GPMC probe fails)
added code to ensure that GPMC chip-selects could not be requested until the
device probe was successful. The chip-selects should have been
unreserved at the end of the probe function, but the code to unreserve
them appears to have ended up in the gpmc_calc_timings() function and
hence, this is causing problems requesting chip-selects. Fix this merge
error by unreserving the chip-selects at the end of the probe, but
before we call the gpmc child probe functions (for device-tree) which
request a chip-select.
Signed-off-by: NJon Hunter <jon-hunter@ti.com>
Tested-by: NEzequiel Garcia <ezequiel.garcia@free-electrons.com>
Tested-by: NPhilip Avinash <avinashphilip@ti.com>
Tested-by: NGrazvydas Ignotas <notasas@gmail.com>
[tony@atomide.com: updated description to add breaking commit id]
Signed-off-by: NTony Lindgren <tony@atomide.com>

The newly created omap_hwmod_reset.c is missing an
include of linux/errno.h in commit c02060d8 "ARM:
OMAP4+: AESS: enable internal auto-gating during
initial setup". It still works in omap2_defconfig,
but not in all other combinations.

Without this patch, building allmodconfig results in:

arch/arm/mach-omap2/omap_hwmod_reset.c: In function 'omap_hwmod_aess_preprogram':
arch/arm/mach-omap2/omap_hwmod_reset.c:47:11: error: 'EINVAL' undeclared (first use in this function)
arch/arm/mach-omap2/omap_hwmod_reset.c:47:11: note: each undeclared identifier is reported only once for each function it appears in
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
Acked-by: NTony Lindgren <tony@atomide.com>
Cc: Paul Walmsley <paul@pwsan.com>
Cc: Sebastien Guiriec <s-guiriec@ti.com>

Let's have a single platform data structure for the OMAP's High-Speed
USB host subsystem instead of having 3 separate ones i.e. one for
board data, one for USB Host (UHH) module and one for USB-TLL module.

This makes the code much simpler and avoids creating multiple copies of
platform data.
Signed-off-by: NRoger Quadros <rogerq@ti.com>
Reviewed-by: NFelipe Balbi <balbi@ti.com>

Use the future proof TWL_MODULE_PWM module id instead to aim the twl-core
cleanup planed for 3.9 kernel cycle.
Signed-off-by: NPeter Ujfalusi <peter.ujfalusi@ti.com>
Acked-by: NTony Lindgren <tony@atomide.com>
Signed-off-by: NSamuel Ortiz <sameo@linux.intel.com>

Commit c1d1cd59 ("ARM: OMAP2+:
omap_device: remove obsolete pm_lats and early_device code") missed a
few omap_device_build() calls that aren't included as part of the default
OMAP2+ Kconfig, omap2plus_defconfig.

Ideally, all devices that are present on the SoC should be created by
default, and only the corresponding device driver should be configured
or deconfigured in Kconfig.  This allows drivers to be built as
modules and loaded later, even if they weren't part of the original
kernel build.  Unfortunately, we're not quite there yet.

Thanks to Tony Lindgren for reporting this, found during his
randconfig tests.
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

Enable AESS data in hwmod in order to be able to probe
audio driver.
Signed-off-by: NSebastien Guiriec <s-guiriec@ti.com>
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

Add AESS memory bank data in hwmod in order to provide memory address
information to the driver.

This version also changes the AESS main clock to use a
non-CLKCTRL-based functional clock.  These are being removed from the
clock data, since they should be handled by the IP block integration
code.  Without this change, the kernel crashes during boot.  Thanks to
Tony Lindgren for reporting this during a test merge.
Signed-off-by: NSebastien Guiriec <s-guiriec@ti.com>
[paul@pwsan.com: updated to change the AESS main_clk]
Cc: Tony Lindgren <tony@atomide.com>
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

Enable the AESS auto-gating control bit during AESS hwmod setup.  This
fixes the following boot warning on OMAP4:

omap_hwmod: aess: _wait_target_disable failed

Without this patch, the AESS IP block does not indicate to the PRCM
that it is idle after it is reset.  This prevents some types of SoC
power management until something sets the auto-gating control bit.
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
Signed-off-by: NSebastien Guiriec <s-guiriec@ti.com>
Cc: Benoît Cousson <b-cousson@ti.com>
Cc: Péter Ujfalusi <peter.ujfalusi@ti.com>
Cc: Tony Lindgren <tony@atomide.com>

After setup/enable, some IP blocks need some additional setting to
indicate the PRCM that they are inactive until they are configured.
Some examples on OMAP4 include the AESS and FSUSB IP blocks.

To fix this cleanly, this patch adds another optional function
pointer, enable_preprogram, to the IP block's hwmod data.  The function
that is pointed to is called by the hwmod code immediately after the
IP block is reset.

This version of the patch includes a patch description fix from Felipe.
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
Signed-off-by: NSebastien Guiriec <s-guiriec@ti.com>
Cc: Benoît Cousson <b-cousson@ti.com>
Cc: Péter Ujfalusi <peter.ujfalusi@ti.com>
Cc: Felipe Balbi <balbi@ti.com>

Looks like there are few more places that I missed that can cause
compiler warnings. After grepping for omap initcall, all files
needing soc.h should now have it.
Reported-by: NRussell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: NTony Lindgren <tony@atomide.com>
Signed-off-by: NOlof Johansson <olof@lixom.net>

I needed this when compiling for pandaboard.

The reason this is needed is that we are now using
omap_initcalls to keep them multiplatform safe.
Signed-off-by: NAndré Hentschel <nerv@dawncrow.de>
[tony@atomide.com: updated comments]
Signed-off-by: NTony Lindgren <tony@atomide.com>
Signed-off-by: NOlof Johansson <olof@lixom.net>

dpll_usb needs the clkdm association so the clkdm can be
turned on before a relock. All other dplls for omap4 belong
to the ALWON (always on) domain.

The association was present as part of the older data file
(clock44xx_data.c) but looks like got accidently dropped with
the common clk convertion.

More details of the patch which fixed this up in the older
data file can be dound here..
http://www.spinics.net/lists/linux-omap/msg63076.html

Adding the .clkdm_name as part of the clk_hw_omap struct also
means a new .init needs to be part of the clk_ops for dpll_usb
to initialise the clkdm.
Signed-off-by: NRajendra Nayak <rnayak@ti.com>
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

Commit 1416408d {ARM: OMAP2+: PM: share some suspend-related functions
across OMAP2, 3, 4} moved suspend code to common place but now with
that change, for DT build on OMAP4, suspend hooks are not getting
registered which results in no suspend support.

The DT return condition is limited to PMIC and smartreflex
initialization and hence restrict it so that suspend ops gets
registered.

Cc: Paul Walmsley <paul@pwsan.com>
Cc: Kevin Hilman <khilman@deeprootsystems.com>
Signed-off-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
Reviewed-by: NFelipe Balbi <balbi@ti.com>
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

am33xx_cm_wait_module_ready() checks if register offset is NULL.

int am33xx_cm_wait_module_ready(u16 inst, s16 cdoffs, u16 clkctrl_offs)
{
	int i = 0;

	if (!clkctrl_offs)
		return 0;

In case of AM33xx, CLKCTRL register offset for different clock domains
are not uniformly placed. An example of this would be the RTC clock
domain with CLKCTRL offset at 0x00.
In such cases the module ready check is skipped which leads to a data
abort during boot-up when RTC registers is accessed.

Remove this check here to avoid checking module readiness for modules
with clkctrl register offset at 0x00.

Koen Kooi notes that this patch fixes a crash on boot with
CONFIG_RTC_DRV_OMAP=y with v3.8-rc5.
Signed-off-by: NHebbar Gururaja <gururaja.hebbar@ti.com>
Cc: Koen Kooi <koen@dominion.thruhere.net>
[paul@pwsan.com: noted Koen's test in the patch description]
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

struct omap_hwmod records belonging to wkup m3 domain is missing
HWMOD_NO_IDLEST flags; add them.

This patch is a prerequisite for a subsequent patch, 'ARM: OMAP2:
am33xx-hwmod: Fix "register offset NULL check" bug'.  That patch would
otherwise attempt to read from reserved bits.
Signed-off-by: NHebbar Gururaja <gururaja.hebbar@ti.com>
[paul@pwsan.com: add some more explanation in the patch description]
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

As part of PWM subsystem integration, PWM subsystem are sharing
resources like clock across submodules (ECAP, EQEP & EHRPWM). To handle
resource sharing & IP integration  rework on parent child relation
between PWMSS and ECAP, EQEP & EHRPWM child devices to support runtime PM.
Signed-off-by: NPhilip Avinash <avinashphilip@ti.com>
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

EQEP IP block integration data is not present in HWMOD data. Also
address ranges specified for EACP & EHRPWM are not correct & HWMOD
flags of ADDR_TYPE_RT are added to PWM subsystem register address
space. This patch:
1. Corrects register address mapping for ECAP & EHRPWM
2. Removes  HWMOD flags in PWM submodule register address space.
3. Adds EQEP HWMOD entries.
Signed-off-by: NPhilip Avinash <avinashphilip@ti.com>
[paul@pwsan.com: tweaked patch description]
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

WKUP-M3 has a reset status bit (RM_WKUP_STST.WKUP_M3_LRST)
Update the hardreset API to ensure that the reset line properly
deasserted.
Signed-off-by: NVaibhav Bedia <vaibhav.bedia@ti.com>
Acked-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
Acked-by: NPeter Korsgaard <jacmet@sunsite.dk>
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

WKUP-M3 has a reset status bit (RM_WKUP_STST.WKUP_M3_LRST)
Update the WKUP-M3 hwmod data to reflect the same.
Signed-off-by: NVaibhav Bedia <vaibhav.bedia@ti.com>
Acked-by: NPeter Korsgaard <jacmet@sunsite.dk>
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

The current HWMOD code expects the memory region with
the IP's SYSCONFIG register to be marked with ADDR_TYPE_RT
flag.

CPGMAC0 hwmod entry specifies two memory regions and marks
both with the flag ADDR_TYPE_RT although only the 2nd region
has the SYSCONFIG register. This leads to the HWMOD code
accessing the wrong memory address for idle and standby
operations. Fix this by removing the ADDR_TYPE_RT flag from
the 1st memory region in CPGMAC0 hwmod entry.
Signed-off-by: NVaibhav Bedia <vaibhav.bedia@ti.com>
Acked-by: NPeter Korsgaard <jacmet@sunsite.dk>
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

Third Party Transfer Controller (TPTC0) needs to be idled and
put to standby under SW control. Add the appropriate flags in
the TPTC0 hwmod entry.
Signed-off-by: NVaibhav Bedia <vaibhav.bedia@ti.com>
Acked-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
Acked-by: NPeter Korsgaard <jacmet@sunsite.dk>
Signed-off-by: NPaul Walmsley <paul@pwsan.com>