staging: tidspbridge: dynamically allocate ibuf in dload_data

Dynamically allocate ibuf to silence the following warning:

drivers/staging/tidspbridge/dynload/cload.c:
    In function 'dload_data':
drivers/staging/tidspbridge/dynload/cload.c:1337:
    warning: the frame size of 1216 bytes is larger than 1024 bytes

Signed-off-by: Omar Ramirez Luna <omar.ramirez@copitl.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
staging: tidspbridge: dynamically allocate my_sym_buf in dload_symbols

Dynamically allocate my_sym_buf to silence the following warning:

drivers/staging/tidspbridge/dynload/cload.c:
    In function 'dload_symbols':
drivers/staging/tidspbridge/dynload/cload.c:890:
    warning: the frame size of 1040 bytes is larger than 1024 bytes

Signed-off-by: Omar Ramirez Luna <omar.ramirez@copitl.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
ARM: OMAP3: PM: fix I/O wakeup and I/O chain clock control detection

The way that we detect which OMAP3 chips support I/O wakeup and
software I/O chain clock control is broken.

Currently, I/O wakeup is marked as present for all OMAP3 SoCs other
than the AM3505/3517.  The TI81xx family of SoCs are at present
considered to be OMAP3 SoCs, but don't support I/O wakeup.  To resolve
this, convert the existing blacklist approach to an explicit,
whitelist support, in which only SoCs which are known to support I/O
wakeup are listed.  (At present, this only includes OMAP34xx,
OMAP3503, OMAP3515, OMAP3525, OMAP3530, and OMAP36xx.)

Also, the current code incorrectly detects the presence of a
software-controllable I/O chain clock on several chips that don't
support it.  This results in writes to reserved bitfields, unnecessary
delays, and console messages on kernels running on those chips:

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

Convert this test to a feature test with a chip-by-chip whitelist.

Thanks to Dave Hylands <dhylands@gmail.com> for reporting this problem
and doing some testing to help isolate the cause.  Thanks to Steve
Sakoman <sakoman@gmail.com> for catching a bug in the first version of
this patch.  Thanks to Russell King <linux@arm.linux.org.uk> for
comments.

Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Dave Hylands <dhylands@gmail.com>
Cc: Steve Sakoman <sakoman@gmail.com>
Tested-by: Steve Sakoman <sakoman@gmail.com>
Cc: Russell King - ARM Linux <linux@arm.linux.org.uk>
Signed-off-by: Kevin Hilman <khilman@ti.com>
ARM: OMAP3: PM: restrict erratum i443 handling to OMAP3430 only

Based on the documents that I have here, there doesn't appear to be an
equivalent to erratum i443 for OMAP3630, so restrict this one to OMAP34xx
chips.

Also, explicitly restrict this erratum to EMU and HS devices.

Signed-off-by: Paul Walmsley <paul@pwsan.com>
Signed-off-by: Kevin Hilman <khilman@ti.com>