[SCSI] Remove scsi_wait_scan module

scsi_wait_scan was introduced with asynchronous host scanning as a hack
for distributions that weren't using proper udev based wait for root to
appear in their initramfs scripts.  In 2.6.30 Commit

c751085943362143f84346d274e0011419c84202
Author: Rafael J. Wysocki <rjw@sisk.pl>
Date:   Sun Apr 12 20:06:56 2009 +0200

    PM/Hibernate: Wait for SCSI devices scan to complete during resume

Actually broke scsi_wait_scan because it renders
scsi_complete_async_scans() a nop for modular SCSI if you include
scsi_scans.h (which this module does).

The lack of bug reports is sufficient proof that this module is no
longer used.

Cc: Jeff Mahoney <jeffm@suse.de>
Cc: Dave Jones <davej@redhat.com>
Cc: maximilian attems <max@stro.at>
Signed-off-by: James Bottomley <JBottomley@Parallels.com>

Conflicts:
	drivers/scsi/scsi_wait_scan.c
Remove PVR.
OMAP4: ion: remove hardcoded carveout sizes

These are no longer used as android-display is calculating the
carveout sizes.

Change-Id: I3dcaec56158da1a573cb8de9ec3761db94d1a698
Signed-off-by: Lajos Molnar <lajos@ti.com>
Singed-off-by: Dima Svetlov <svetlov@ti.com>

Conflicts:
	arch/arm/mach-omap2/include/mach/omap4_ion.h
omap: ion: define carveouts as per system memory configuration

Carveout address and sizes are hardcoded as per 1GB configuration.
512MB configuration will have reduced carveouts and needs
redifinition of carveouts. Static carveout parameters are made
dynamic and calclulated runtime as per system configuration.

Carveout address,size parameters,calculation are made more
easily readable and perceivable.
All carveout parameter initialization needs to happen at
the earliest possible, which is triggerd by board file.

Change-Id: I32bb9e04ef40f5d7d6f7548bba9ab5878bfcb56d
Signed-off-by: Devaraj Rangasamy <dev@ti.com>
sgx_omaplfb: Create omaplfb platform device file to permit device configuration

Change-Id: Ic790a0440d19d862d981a230470523409b25b9a3
Signed-off-by: Tony Lofthouse <a0741364@ti.com>
Signed-off-by: Gustavo Diaz Prado <a0273371@ti.com>
OMAP2: generic Android display configuration setup

Added android_display methods to allow runtime configuration of
Android display resources, such as:

- FB0's vram is dynamically calculated from the number of
  buffers SGX requires in VRAM (swap chain and/or composition
  buffers), and the FB0 display size.
- OMAP VRAM is calculated from FB0's vram need + any other
  specified FB's vram.  (If command line is used to specify
  FB vrams, omap vram must also be specified.)
- TILER1D area reserved for use as DSS MMU by DSSCOMP is
  calculated from default display size.  It can be overriden
  by board file.
- TILER2D carveout size is reduced by TILER1D area (if coallocated
  with TILER2D) and by the TILER2D SGX buffers (swapchain and/or
  composition buffers)
- nonsecure TILER2D carveout size is set to the backpages needed
  by TILER2D SGX buffers.

All of this is coordinated by omap_android_display_setup.  It
takes pointers to the DSS board info, FB platform data, and
optionally to the ION, SGX and DSSCOMP platform data.  It should
be called in board_reserve before omap_ion_init.

If SGX data is provided, it is set as the SGX platform data for
FB0.  Similarly, if DSSCOMP platform data is provided it is
also set.  This can be used to set a preferred tiler1d slot size.
If ION platform data is provided, it is updated with the required
tiler2d carveout sizes.

NOTE:

To maximize TILER2D space, the TILER1D area reserved for android
display is not aligned to 1MB, but is aligned to 32 pages as the
smallest 2D allocation needs a 32-page band.  We further reduce
TILER2D space by the container space lost by the SGX buffers,
which may be larger than the actual backpages bneeded for the
SGX buffers.

Therefore the sum of secure + nonsecure + 1D tiler space may
be smaller than the available container space.

Ported to latest SGX DDK by Dima Svetlov.

Change-Id: I5d8858c38efd842452994e3a3476463083d200d7
Signed-off-by: Lajos Molnar <lajos@ti.com>
Signed-off-by: Dima Svetlov <svetlov@ti.com>
OMAP2: correction in early params functions for android-display

Correction in early params functions in android-display.c

Change-Id: I2bef7e62cc96f75ef23690e29213c8e6d4d545ea
Signed-off-by: Muralidhar Dixit <murali.dixit@ti.com>
plat-omap: android-display: Set min number of vram buffers

Omapfb requires at least one vram buffer

Change-Id: I7d719856e3360314f8bccfba8fcbd3b518496b8b
Signed-off-by: Peter Nordström <nordstrom@ti.com>
Signed-off-by: Lajos Molnar <lajos@ti.com>
Signed-off-by: Dima Svetlov <svetlov@ti.com>
plat-omap: android-display: add 2 extra VRAM buffers for gc320

2 extra VRAM buffers are needed to gc320 composition

Change-Id: I5e02392f32a93c2eb12314151cd3a72b44fd4ae9
Signed-off-by: Dima Svetlov <svetlov@ti.com>
ION : ION buffers caching support (ION, TILER 1D buffers)

ION map is enhanced to map ion buffers as cached pages
This patch also adds IOCTLs in ION to flush and invalidate
the cached buffers
Note: TILER 2D buffers cant be mapped as cached regions to
MPU due to DMM limitation

Complete list of feature patchset (cross project dependencies)
  http://review.omapzoom.org/18390  kernel/omap
  http://review.omapzoom.org/18391  external/kernel-headers
  http://review.omapzoom.org/18392  bionic
  http://review.omapzoom.org/18393  hardware/ti/omap4xxx
  http://review.omapzoom.org/18394  hardware/ti/domx

Change-Id: I8c7c3f0375a4b3fae13f46a657d0c2eec703f72b
Signed-off-by: Kalpesh Patil <kalpeshpatil@ti.com>
Signed-off-by: Devaraj Rangasamy <dev@ti.com>

Conflicts:
	drivers/gpu/ion/omap/omap_tiler_heap.c
board-tuna: add android-display dependencies
tuna: Update defconfig.
tuna: remove duplicate call to set vram
android-display manages this now
rpmsg-omx: Use ion abstraction to get handle from PVR fd

PVRExportFDToIONHandles was being called directly by rpmsg-omx.
This is now abstracted by ion and drivers should use
omap_ion_fd_to_handles instead.

Change-Id: I2f750887a048eb3d9cd28cdc9c4b08eb3e83e31b
Signed-off-by: Hemant Hariyani <hemanthariyani@ti.com>
rpmsg: omx: implement separate register ioctl for sgx buffers

This implements a new register ioctl specifically meant for sgx
buffers. rpmsg_omx clients are expected to call register ioctl
for the specific buffer type (ion or sgx) before sending a buffer
to .write for mapping. The registration allows the rpmsg_omx
driver to hold a reference to the ion buffers making up the sgx
buffer, thereby preventing the buffer(s) to be freed up from
under the remote processor.

The individual imported ion handles are expected to be passed
into the .write call.

When a client no longer expects remote processor to use the buffer,
client should call unregister ioctl. A separate unregister ioctl
for pvr buffers is not created, and the same ion unregister ioctl
is expected to be used for all the ion handles a sgx buffer is
comprised of.

Change-Id: Ib36aab90136627899e98717aeb29bfa637ec09fd
Signed-off-by: Tyler Luu <tluu@ti.com>
Signed-off-by: Suman Anna <s-anna@ti.com>
rpmsg: omx: add ion system heap to omx ion client

Allow the rpmsg omx ion client to access buffers from
the ion system heap.

Change-Id: Ic2d6922cb5cb05ec96f807a36b77c124769f4ef2
Signed-off-by: Tyler Luu <tluu@ti.com>
Signed-off-by: David Schleef <ds@ti.com>
Signed-off-by: Suman Anna <s-anna@ti.com>
rpmsg: omx: add handling of ion system heap buffers

Conflicts:
	drivers/rpmsg/rpmsg_omx.c
rpmsg: omx: return correct handle count in 'OMX_IOCPVRREGISTER'

omap_ion_share_fd_to_buffers is always returning 2 in num_handles
even for fd's pointing to 1D memory. In order to return the correct
number of handles to rpmsg client in this ioctl call, 'break' out
of for loop instead of continuing.

Change-Id: Ic7fecc682895a63ad7b7f74b8824f0dc0eb57481
Signed-off-by: Emilian Peev <epeev@mm-sol.com>
Signed-off-by: Tyler Luu <tluu@ti.com>
omap: ion: defining a new Ion 1D heap for WFD HDCP

Conflicts:
	arch/arm/mach-omap2/board-bowser.c
	arch/arm/mach-omap2/board-omap4panda.c
	arch/arm/mach-omap2/omap4_ion.c
tuna: bluetooth: deassert BT_REG and BT_NRST during boot

BT_REG and BT_NRST should be deasserted during boot so that they
remain low and they are pulled high using the rfkill switch. Having
the BT_NRST gpio high would power on the chip even when BT was not
in use after boot and would need a power on and off cycle to disable
the chip.

2 Minute silence for all the power that has been lost since November 2011.

Change-Id: I3d4bcc35599bf58ab8fae81df650e4a3881b4bea