All definitions in arch/arm/mach-omap2/dma.h are removed so it can be
removed now.
Signed-off-by: NJarkko Nikula <jarkko.nikula@bitmer.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

Last remaining DMA channel definitions in arch/arm/mach-omap2/dma.h
are used only by omap_hwmod_2xxx_3xxx_ipblock_data.c and
omap_hwmod_3xxx_data.c. Remove them by using directly DMA channel number in
hwmod data and drop definitions with a following script:

egrep '#define [OMAP|AM35XX].*DMA' arch/arm/mach-omap2/dma.h | cut -f 1,3 \
	| while read i; do \
		DEF=`echo $i |cut -d ' ' -f 2`; \
		CH=`echo $i |cut -d ' ' -f 3`; \
		echo "removing" $DEF; \
		sed -i "s/${DEF}/${CH}/" arch/arm/mach-omap2/omap_hwmod_*.c; \
		sed -i "/${DEF}/d" arch/arm/mach-omap2/dma.h; \
	done
Signed-off-by: NJarkko Nikula <jarkko.nikula@bitmer.com>
Acked-by: NPaul Walmsley <paul@pwsan.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

Many DMA channel definitions in arch/arm/mach-omap2/dma.h have been moved or
redefined in drivers without removing them from dma.h. Remove those with a
script below:

egrep '#define OMAP.*DMA' arch/arm/mach-omap2/dma.h \
	|cut -f 1 |cut -d ' ' -f 1-2 | while read -r i; do \
		if [ `git grep -c "$i" |wc -l` -gt 1 ]; then \
			echo "removing" $i; \
			sed -i "/${i}/d" arch/arm/mach-omap2/dma.h; \
		fi; \
	done
Signed-off-by: NJarkko Nikula <jarkko.nikula@bitmer.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

These became unused after commit 660ffd6b
("ARM: OMAP2xxx: hwmod: Convert AES crypto devcie data to hwmod").
Signed-off-by: NJarkko Nikula <jarkko.nikula@bitmer.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

Now that there is a way to tell the powerdomain core about
missing voltage domain auto-scaling control in SoCs', get rid of the dummy
voltage domain data populated for AM33xx devices.
Acked-by: NNishanth Menon <nm@ti.com>
Acked-by: NVaibhav Hiremath <hvaibhav@ti.com>
Signed-off-by: NRajendra Nayak <rnayak@ti.com>
Acked-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
Tested-by: Afzal Mohammed <afzal@ti.com> # am335x evm
Signed-off-by: NKevin Hilman <khilman@linaro.org>

The powerdomain framework currently expects all powerdomains to be associated with
a corresponding voltagedomain. For some SoCs' (like the already existing AM33xx
family, or for the upcoming AM437x and DRA7 SoCs') which
do not have a Voltage controller/Voltage Processor (neither the SR I2C
bus to communicate with the PMIC) there is no need for a Powerdomain to have
a voltage domain association since there is no auto-scaling of voltages possible
using the voltage FSM.

Extend the arch operations to add an api which the powerdomain core can
then use to identify if a voltdm lookup and association for a powerdomain
is really needed.
Acked-by: NNishanth Menon <nm@ti.com>
Acked-by: NVaibhav Hiremath <hvaibhav@ti.com>
Signed-off-by: NRajendra Nayak <rnayak@ti.com>
Acked-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
Tested-by: Afzal Mohammed <afzal@ti.com> # am335x evm
Signed-off-by: NKevin Hilman <khilman@linaro.org>

Fix memory leaks in the error path.
Also, use platform_device_register_full() to allocate
the platform devices and set platform data.
Signed-off-by: NRoger Quadros <rogerq@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

We don't want to call omap_serial_early_init() for device
tree based booting as the ports are initialized based on
the .dts entries.
Reviewed-by: NKevin Hilman <khilman@linaro.org>
Signed-off-by: NTony Lindgren <tony@atomide.com>

Commit '3b9b1015' cleaned up the
data file to remove all irq and dma entries for all hwmods, which
are now populated by DT. But mcspi and mmc irq, dma entries were
retained since MMC, NFS boot was not working. Since it is root caused
to be an issue with only DMA entries [1], irq can be safely removed.

[1] http://www.mail-archive.com/linux-omap@vger.kernel.org/msg90115.htmlSigned-off-by: NSricharan R <r.sricharan@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

The itention was probably to make both pointers const but as it is now,
it is just const used twice.
Signed-off-by: NSebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: NTony Lindgren <tony@atomide.com>

The dss_hdmi hwmod is used to create the HDMI audio device for OMAP4+
When we boot the kernel we can silently ignore the failure since the IP
does not exist on them.
Reported-by: NPaul Walmsley <paul@pwsan.com>
Signed-off-by: NPeter Ujfalusi <peter.ujfalusi@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

It means that the SoC does not have DMIC IP.
Reported-by: NPaul Walmsley <paul@pwsan.com>
Signed-off-by: NPeter Ujfalusi <peter.ujfalusi@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

It means that the SoC does not have McPDM IP.
Reported-by: NPaul Walmsley <paul@pwsan.com>
Signed-off-by: NPeter Ujfalusi <peter.ujfalusi@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

SDI driver gets currently the vdds_sdi regulator via omapdss device.
This is not correct, and we'll change the SDI driver to get the
regulator directly via omapdss_sdi.0 device.

This patch changes the rx51 board file to add vdds_dsi supply for
omapdss_sdi.0 device.

Note that the vdds_sdi supply for omapdss device is still left there, as
the current display driver uses it. When both the board files and the
display driver has been changed, we can remove the unused supply.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

DPI driver gets currently the vdds_dsi regulator via omapdss device.
This is not correct, and we'll change the DPI driver to get the
regulator directly via omapdss_dpi.0 device.

This patch changes the relevant board files to add vdds_dsi supply for
omapdss_dpi.0 device.

Note that the vdds_dsi supply for omapdss device is still left there, as
the current display driver uses it. When both the board files and the
display driver has been changed, we can remove the unused supply.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

board-cm-t35.c and board-ldp.c contain regulator supply entries for
vdds_dsi. However, the given device name is wrong.

This patch fixes the device name from omapdss_dsi1 to omapdss_dsi.0.

Note that as far as I know, DSI driver is not used on these boards, so
this should not have caused any problems. The DSI block can be used to
generate clock for DPI, though, but that's not enabled for omap3 boards
currently.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

Commit 3b9b1015 (ARM: OMAP4: hwmod data:
Clean up the data file) removes hwmod data for omap4, including DSS
data. DSS has not yet been converted to DT, so the hwmod data is still
needed.

This patch adds back the DSS parts of the hwmod data.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

- The IO resource information like dma request lines, irq number and
  ocp address space can be populated via dt blob. So such data is stripped
  from OMAP4 SOC hwmod data file.

- The devices which are still missing the device tree bindings,
  address space entries are not removed yet. When such devices add
  the dt bindings, respective address space data can be deleted.

- Also other unnecessary hwmods like firewalls are removed as a part of this.
  Since emif was getting registered only because of this firewalls links,
  the mpu->emif direct link is added now.

The above update, results in reduction of about ~1650 lines of code.
Signed-off-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
Signed-off-by: NSricharan R <r.sricharan@ti.com>
Acked-by: NBenoit Cousson <benoit.cousson@linaro.org>
Acked-by: NPaul Walmsley <paul@pwsan.com>
[tony@atomide.com: updated for omap44xx_usb_phy_and_pll_addrs, dropped
mcspi and mmc changes to avoid regressions on omap4sdp]
Signed-off-by: NTony Lindgren <tony@atomide.com>

AM33XX only supports DT boot mode and with addition of
extracting module resources like, irq, dma and address space
from DT block, so now we can remove duplicate information from
hwmod data file.

This patch cleanups-up/deletes,

     - All references to "omap_hwmod_irq_info" data.
     - All references to "omap_hwmod_dma_info" data.
     - References to "omap_hwmod_addr_space" of the modules
       for which DT node is available with required address
       space information.
     - For the modules where "sysc" field is not applicable,
       we don't need module address space, so remove them as well.
     - The hwmod like firewall etc which are not useful are also
       deleted.

This cleanup gets us around ~1100 LOC of negative diff.
Patch is boot tested on AM335x-EVM along with below modules -
	- Matrix-keypad
	- Volume up/down keys
	- Ethernet
	- RTC
	- WDT
Signed-off-by: NVaibhav Hiremath <hvaibhav@ti.com>
Signed-off-by: NSricharan R <r.sricharan@ti.com>
Signed-off-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
Acked-by: NPaul Walmsley <paul@pwsan.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

omap36xx_pwrdn_clk_enable_with_hsdiv_restore expects the parent hw of
the clock to be a clk_hw_omap. However, looking at cclock3xxx_data.c,
all concerned clock have parent defined as clk_divider.  Fix the
function to use clk_divider.  Tested with 3.9 on dm3730.
Signed-off-by: NJean-Philippe François <jp.francois@cynove.com>
Cc: NeilBrown <neilb@suse.de>
Cc: Mike Turquette <mturquette@linaro.org>
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

The UART2 hwmod structure is pointing to the EDMA channels of UART1,
which doesn't look right. This patch fixes this by making the UART2
hwmod structure to a new structure that lists the EDMA channels to be
used by the UART2.
Signed-off-by: NThomas Petazzoni <thomas.petazzoni@free-electrons.com>
Acked-by: NVaibhav Hiremath <hvaibhav@ti.com>
[paul@pwsan.com: updated to apply]
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

This is omap4+ only and no longer needed as omap4+ can be booted
using device tree.

Also remove the related pdata handling from the driver and the
now unneeded platform_data/omap_ocp2scp.h.

Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Olof Johansson <olof@lixom.net>
Reviewed-by: NKishon Vijay Abraham I <kishon@ti.com>
Acked-by: NFelipe Balbi <balbi@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

This is no longer needed as omap4 is now booted
using device tree.
Signed-off-by: NTony Lindgren <tony@atomide.com>

This is no longer needed as omap4 is now booted using
device tree.
Signed-off-by: NTony Lindgren <tony@atomide.com>

We can now boot with devicetree and muxing can be done
with pinctrl-single.c.
Signed-off-by: NTony Lindgren <tony@atomide.com>

We can now boot with device tree. If you don't want to update u-boot,
you can boot with appended DTB with the following instructions:

1. Make sure you have the appended DTB support in .config

   CONFIG_ARM_APPENDED_DTB=y
   CONFIG_ARM_ATAG_DTB_COMPAT=y
   CONFIG_ARM_ATAG_DTB_COMPAT_CMDLINE_EXTEND=y

2. Build the zImage

   $ ARCH=arm CROSS_COMPILE=... make zImage

3. Build the device tree blobs

   $ ARCH=arm CROSS_COMPILE=... make dtbs

4. Append the correct panda dtb to zImage

   Depending on your hardware it's omap4-panda.dtb, omap4-panda-a4.dtb
   or omap4-panda-es.dtb.

   $ cat arch/arm/boot/zImage arch/arm/boot/dts/omap4-panda-es.dtb > /tmp/appended

5. Use mkimage to produce the appended device tree uImage

   $ mkimage -A arm -O linux -T kernel -C none -a 0x80008000 -e 0x80008000 \
     -n "Linux" -d /tmp/appended /tmp/uImage

Signed-off-by: Tony Lindgren <tony@atomide.com

We can now boot with device tree. If you don't want to update u-boot,
you can boot with appended DTB with the following instructions:

1. Make sure you have the appended DTB support in .config

   CONFIG_ARM_APPENDED_DTB=y
   CONFIG_ARM_ATAG_DTB_COMPAT=y
   CONFIG_ARM_ATAG_DTB_COMPAT_CMDLINE_EXTEND=y

2. Build the zImage

   $ ARCH=arm CROSS_COMPILE=... make zImage

3. Build the device tree blobs

   $ ARCH=arm CROSS_COMPILE=... make dtbs

4. Append the dtb to zImage

   $ cat arch/arm/boot/zImage arch/arm/boot/dts/omap4-sdp.dtb > /tmp/appended

5. Use mkimage to produce the appended device tree uImage

   $ mkimage -A arm -O linux -T kernel -C none -a 0x80008000 -e 0x80008000 \
     -n "Linux" -d /tmp/appended /tmp/uImage
Signed-off-by: NTony Lindgren <tony@atomide.com>

Without WLAN we cannot switch omap4 to use device tree
only booting. This patch can be reverted when the
binding for wl12xx is added.

Cc: Benoit Cousson <b-cousson@ti.com>
Cc: Rajendra Nayak <rnayak@ti.com>
Cc: devicetree-discuss@lists.ozlabs.org
Tested-by: NLuciano Coelho <coelho@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

Commit a819c4f1 (ARM: OMAP3: PM: Only access IVA if one exists)
changed PM to not access IVA registers on omaps that don't have
them. Turns out we still need to idle iva2 as otherwise
iva2_pwrdm will stay on and block deeper idle states.

It seems that the only part of the reset that may not be needed
is the setting of the iva2 boot mode to idle. But as that register
seems to be there and is harmless if no iva2 is on the SoC, it's
probably safest to do the complete reset.
Acked-by: NMark A. Greer <mgreer@animalcreek.com>
Acked-by: NKevin Hilman <khilman@linaro.org>
Tested-by: NYegor Yefremov <yegorslists@googlemail.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

With the OMAP serial driver sysc cleanup patches in this series, we can
now remove the hwmod external apis for sysc fiddling.

While at this, also remove unused sysc auto idle api from hwmod code.
Tested-by: NVaibhav Bedia <vaibhav.bedia@ti.com>
Tested-by: NSourav Poddar <sourav.poddar@ti.com>
Signed-off-by: NRajendra nayak <rnayak@ti.com>
Signed-off-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
Reviewed-by: NKevin Hilman <khilman@linaro.org>
Tested-by: Kevin Hilman <khilman@linaro.org>  # OMAP4/Panda
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

UART IP idle handling now taken care by runtime pm backend(hwmod) indirectly
and OMAP serial driver is also cleaned up accordingly.

So remove the un-used slave idle platforms hooks now.
Tested-by: NVaibhav Bedia <vaibhav.bedia@ti.com>
Tested-by: NSourav Poddar <sourav.poddar@ti.com>
Signed-off-by: NRajendra nayak <rnayak@ti.com>
Signed-off-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
Reviewed-by: NKevin Hilman <khilman@linaro.org>
Tested-by: Kevin Hilman <khilman@linaro.org>  # OMAP4/Panda
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

OMAP UART IP needs software control for slave idle modes based on functional
state of the IP. i.e The IP slave idle settings should be set to 'noidle' when
being used and then put back to 'smart_idle' when unused. Currently this is
handled by the driver with function pointers implemented in platform code.
This however breaks in case of device tree because of missing idle handling
APIs.

Previous patches in this series added a flag HWMOD_SWSUP_SIDLE_ACTIVE which
takes care of the mentioned requirement. Hence add the flag for all UART IPs
to take advantage of feature supported by framework.

Subsequent patches removes the slave idle handling from driver code.
Tested-by: NVaibhav Bedia <vaibhav.bedia@ti.com>
Tested-by: NSourav Poddar <sourav.poddar@ti.com>
Signed-off-by: NRajendra Nayak <rnayak@ti.com>
Signed-off-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
Reviewed-by: NKevin Hilman <khilman@linaro.org>
Tested-by: Kevin Hilman <khilman@linaro.org>  # OMAP4/Panda
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

Some IPs (like UART) need the sidle mode to be controlled in SW only
while they are active. Once they go inactive, they need the IP to be
put back in HW control so they are also wakeup capable.

The flag HWMOD_SWSUP_SIDLE takes care of IPs which need the sidle
mode to be *always* controlled in SWSUP. We now have a need to control
IPs sidle mode in SWSUP only while its active.

So define a new flag 'HWMOD_SWSUP_SIDLE_ACT' to help the framework
know about these new IP requirements.
Tested-by: NVaibhav Bedia <vaibhav.bedia@ti.com>
Tested-by: NSourav Poddar <sourav.poddar@ti.com>
Signed-off-by: NRajendra Nayak <rnayak@ti.com>
Signed-off-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
Reviewed-by: NKevin Hilman <khilman@linaro.org>
Tested-by: Kevin Hilman <khilman@linaro.org>  # OMAP4/Panda
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

_enable_sysc() and _idle_sysc() handle the midle mode programming correctly
and program HWMOD_IDLEMODE_SMART or HWMOD_IDLEMODE_SMART_WKUP respectively
for supported IPs (The ones which support hardware controlled midle modes)

However the same programming logic is missing when it comes to sidle mode
programming. Here they seem to just set HWMOD_IDLEMODE_SMART (Again for the
ones which support hardware controlled sidle modes)

This problem was hidden due to the fact that a call to _enable_wakeup()
in those same functions would overwrite the idlemodes and program them
correctly (to HWMOD_IDLEMODE_SMART_WKUP in the supported cases)

So fix the sidlemode handling correctly in these functions and handle the
_enable_wakeup() for SIDLEMODE supported IPs same as the way its handled
for MIDLEMODE supported ones.
Tested-by: NVaibhav Bedia <vaibhav.bedia@ti.com>
Tested-by: NSourav Poddar <sourav.poddar@ti.com>
Signed-off-by: NRajendra Nayak <rnayak@ti.com>
Signed-off-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
Reviewed-by: NKevin Hilman <khilman@linaro.org>
Tested-by: Kevin Hilman <khilman@linaro.org>  # OMAP4/Panda
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

It is required to enable respective clock-domain before
enabling any clock/module inside that clock-domain.

During common-clock migration, .clkdm_name field got missed
for "clkdiv32k_ick" clock, which leaves "clk_24mhz_clkdm"
unused; so it will be disabled even if childs of this clock-domain
is enabled, which keeps child modules in idle mode.

This fixes the kernel crash observed on AM335xEVM-SK platform,
where clkdiv32_ick clock is being used as a gpio debounce clock
and since clkdiv32k_ick is in idle mode it leads to below crash -

Crash Log:
==========
[    2.598347] Unhandled fault: external abort on non-linefetch (0x1028) at
0xfa1ac150
[    2.606434] Internal error: : 1028 [#1] SMP ARM
[    2.611207] Modules linked in:
[    2.614449] CPU: 0    Not tainted  (3.8.4-01382-g1f449cd-dirty #4)
[    2.620973] PC is at _set_gpio_debounce+0x60/0x104
[    2.626025] LR is at clk_enable+0x30/0x3c

Cc: stable@vger.kernel.org # v3.9
Signed-off-by: NVaibhav Hiremath <hvaibhav@ti.com>
Cc: Rajendra Nayak <rnayak@ti.com>
Acked-by: NPaul Walmsley <paul@pwsan.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

_enable_preprogram is marked as __init, but is called from _enable
which is not. Without this patch, the board oopses after init. Tested
on custom hardware and on beagle board xM. Otherwise we can get:

Unable to handle kernel paging request at virtual address 000b0012
pgd = cf968000
*pgd=8fb06831, *pte=00000000, *ppte=00000000
PREEMPT ARM
Modules linked in:
CPU: 0    Not tainted  (3.9.0 #2)
PC is at _enable_preprogram+0x1c/0x24
LR is at omap_hwmod_enable+0x34/0x60
   psr: 80000093
sp : cf95de08  ip : 00002de5  fp : bec33d4c
r10: 00000000  r9 : 00000002  r8 : b6dd2c78
r7 : 00000004  r6 : 00000000  r5 : a0000013  r4 : cf95c000
r3 : 00000000  r2 : b6dd2c7c  r1 : 00000000  r0 : 000b0012
Flags: Nzcv  IRQs off  FIQs on  Mode SVC_32  ISA ARM  Segment user
Control: 10c5387d  Table: 8f968019  DAC: 00000015
Process otpcmd (pid: 607, stack limit = 0xcf95c230)
Stack: (0xcf95de08 to 0xcf95e000)
de00:                   00000001 cf91f840 00000000 c001d6fc 00000002 cf91f840
de20: cf8f7e10 c001de54 cf8f7e10 c001de78 c001de68 c01d5e80 00000000 cf8f7e10
de40: cf8f7e10 c01d5f28 cf8f7e10 c0530d30 00000000 c01d6f28 00000000 c0088664
de60: b6ea1000 cfb05284 cf95c000 00000001 cf95c000 60000013 00000001 cf95dee4
de80: cf870050 c01d7308 cf870010 cf870050 00000001 c0278b14 c0526f28 00000000
dea0: cf870050 ffff8e18 00000001 cf95dee4 00000000 c0274f7c cf870050 00000001
dec0: cf95dee4 cf1d8484 000000e0 c0276464 00000008 cf9c0000 00000007 c0276980
dee0: cf9c0000 00000064 00000008 cf1d8404 cf1d8400 c01cc05c 0000270a cf1d8504
df00: 00000023 cf1d8484 00000007 c01cc670 00000bdd 00000001 00000000 cf449e60
df20: cf1dde70 cf1d8400 bec33d18 cf1d8504 c0246f00 00000003 cf95c000 00000000
df40: bec33d4c c01cd078 00000003 cf1d8504 00000081 c01cbcb8 bec33d18 00000003
df60: bec33d18 c00a9034 00002000 c00a9c68 cf92fe00 00000003 c0246f00 cf92fe00
df80: 00000000 c00a9cb0 00000003 00000000 00008e70 00000000 b6f17000 00000036
dfa0: c000e484 c000e300 00008e70 00000000 00000003 c0246f00 bec33d18 bec33d18
dfc0: 00008e70 00000000 b6f17000 00000036 00000000 00000000 b6f6d000 bec33d4c
dfe0: b6ea1bd0 bec33d0c 00008c9c b6ea1bdc 60000010 00000003 00000000 00000000
(_omap_device_enable_hwmods+0x20/0x34)
(omap_device_enable+0x3c/0x50)
(_od_runtime_resume+0x10/0x1c)
(__rpm_callback+0x54/0x98)
(rpm_callback+0x64/0x7c)
(rpm_resume+0x434/0x554)
(__pm_runtime_resume+0x48/0x74)
(omap_i2c_xfer+0x28/0xe8)
(__i2c_transfer+0x3c/0x78)
(i2c_transfer+0x6c/0xc0)
(i2c_master_send+0x38/0x48)
(sha204p_send_command+0x60/0x9c)
(sha204c_send_and_receive+0x5c/0x1e0)
(sha204m_read+0x94/0xa0)
(otp_do_read+0x50/0xa4)
(vfs_ioctl+0x24/0x40)
(do_vfs_ioctl+0x1b0/0x1c0)
(sys_ioctl+0x38/0x54)
(ret_fast_syscall+0x0/0x30)
Code: e1a08002 ea000009 e598003c e592c05c (e7904003)

Cc: stable@vger.kernel.org
Signed-off-by: NJean-Philippe Fran=C3=A7ois <jp.francois@cynove.com>
Acked-by: NKevin Hilman <khilman@linaro.org>
[tony@atomide.com: updated description with oops]
Signed-off-by: NTony Lindgren <tony@atomide.com>

Support for OMAP5 is added to the omap_dsp_ctrl_write_boot_addr()
to enable the DSP boot.
Signed-off-by: NSuman Anna <s-anna@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

Remove "no_idle_on_suspend" check, since respective
driver should be able to prevent idling of an
omap device whenever required.

Driver's can get same behavior by just returning -EBUSY
from their ->runtime_suspend only during suspend.

Cc: Santosh Shilimkar <santosh.shilimkar@ti.com>
Cc: Felipe Balbi <balbi@ti.com>
Cc: Rajendra nayak <rnayak@ti.com>
Cc: Grygorii Strashko <grygorii.strashko@ti.com>
Signed-off-by: NSourav Poddar <sourav.poddar@ti.com>
Reviewed-by: NFelipe Balbi <balbi@ti.com>
Signed-off-by: NKevin Hilman <khilman@linaro.org>

"no_console_suspend" is no longer handled in platform file,
Since the omap serial driver is now adapted to prevent
console UART idleing during suspend.

Cc: Santosh Shilimkar <santosh.shilimkar@ti.com>
Cc: Felipe Balbi <balbi@ti.com>
Cc: Rajendra nayak <rnayak@ti.com>
Signed-off-by: NSourav Poddar <sourav.poddar@ti.com>
Reviewed-by: NFelipe Balbi <balbi@ti.com>
Signed-off-by: NKevin Hilman <khilman@linaro.org>

Commit 6770b211 (ARM: OMAP2+: Export SoC information to userspace)
had some broken return value handling as noted by Russell King:

+       soc_dev = soc_device_register(soc_dev_attr);
+       if (IS_ERR_OR_NULL(soc_dev)) {
+               kfree(soc_dev_attr);
+               return;
+       }
+
+       parent = soc_device_to_device(soc_dev);
+       if (!IS_ERR_OR_NULL(parent))
+               device_create_file(parent, &omap_soc_attr);

This is nonsense.  For the first, IS_ERR() is sufficient.  For the second,
tell me what error checking is required in the return value of this
function:

struct device *soc_device_to_device(struct soc_device *soc_dev)
{
        return &soc_dev->dev;
}

when you've already determined that the passed soc_dev is a valid pointer.
If you read the comments against the prototype:

/**
 * soc_device_to_device - helper function to fetch struct device
 * @soc: Previously registered SoC device container
 */
struct device *soc_device_to_device(struct soc_device *soc);

if "soc" is valid, it means the "previously registered SoC device container"
must have succeeded and that can only happen if the struct device has been
registered.  Ergo, there will always be a valid struct device pointer for
any registered SoC device container.  Therefore, if soc_device_register()
succeeds, then the return value from soc_device_to_device() will always be
valid and no error checking of it is required.

Simples.  The rule as ever applies here: get to know the APIs your using
and don't fumble around in the dark hoping that you'll get this stuff
right.

Fix it as noted by Russell.
Reported-by: NRussell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: NTony Lindgren <tony@atomide.com>