remoteproc: remove firmware.h dependencies from secure code

The remoteproc core code deals with requesting the firmware, and
there is no need for the remoteproc secure code to be dealing
with any firmware api or structures directly. It only needs the
firmware data pointer to be able to parse the necessary secure
sections.

Change-Id: I9ef6c64a806d49addd3819d91e0797bbb9f2701b
Signed-off-by: Suman Anna <s-anna@ti.com>
iommu/omap: fix an uninitialized variable compilation warning

Fixed the following compilation warning

drivers/iommu/omap-iommu.c: In function 'omap_iommu_attach_dev':
drivers/iommu/omap-iommu.c:985:6: warning: 'pm_constraint' may be used uninitialized in this function [-Wmaybe-uninitialized]
drivers/iommu/omap-iommu.c:940:6: note: 'pm_constraint' was declared here

Change-Id: I4f5daea2862ff47e8015fd8b9938fedc64393ae0
Signed-off-by: Suman Anna <s-anna@ti.com>
iommu: export an api to add domain data

Support has been added to add some domain data through
a new exported api, iommu_domain_add_iommudata. This data
will be added by the iommu users, and can be used by the
iommu driver implementations for various purposes.

The current usecase for one such usage is by the remoteproc
driver in OMAP to be able to send the secure mode parameters
to the OMAP iommu driver.

Change-Id: Ib4d1d53fbdb431904b486ae2f875fbaad5b4641e
Signed-off-by: Suman Anna <s-anna@ti.com>
iommu/omap: add support for secure mode

The omap iommu module has been enhanced to provide the support
for starting a remote processor in a mode suitable for running
secure applications.

The mode and ttbr value to be used in secure mode are configured
through the domain-specific iommu_data. The iommu_data needs to
be set before attaching the iommu device. In secure mode, all
iommu operations to program a PTE entry or TLB entry are blocked.
The TTB is configured to a pre-determined L1 table which is
firewalled, and the sanity of TTB is continuously checked in
the secure code.

Change-Id: I0149016502602cb3ce69486a49e6df8d1c5ca645
Signed-off-by: Suman Anna <s-anna@ti.com>
remoteproc: program the iommu after handling resources

The remoteproc driver currently maps the different processor
memories while processing the various entries in the resource
table. This logic has been reworked to facilitate the iommu
programming model for secure mode.

The resources need to be handled first to gather the memory
translation data that is required for parsing the iommu data
for the secure mode. The iommu can then be configured based
on the mode the remoteproc is being booted in.

Change-Id: I0ffd8ed6a6fadf0f9fb0492b2832d1ff3353936c
Signed-off-by: Suman Anna <s-anna@ti.com>
remoteproc: split the secure sections parsing and authentication

The functionality in the rproc_secure_boot code is split into
two separate functions, one for parsing the secure data sections,
and the other for performing the image validation and configuring
the hardware for secure mode.

This is done so as to retrieve the ttbr value earlier than the
authentication step for configuring the iommu driver properly.

Change-Id: I53d131d79e2230c1b479eb6bf39e182f35c65ffc
Signed-off-by: Suman Anna <s-anna@ti.com>
remoteproc: add functions to retrieve secure mode & ttbr value

Two functions, rproc_secure_get_mode & rproc_secure_get_ttb,
are added to retrieve the secure mode and ttbr value from the
remoteproc secure code. The ttbr value will be used in secure
mode, and is set based on the firmware image data. These functions
will be used by the remoteproc core driver code to program the
iommu for secure mode and normal mode appropriately.

Change-Id: Ibad6fba652a8c8d40346615ae5517130a624aacf
Signed-off-by: Suman Anna <s-anna@ti.com>
remoteproc: configure iommu for secure and normal modes

The remoteproc driver is adapted to retrieve and add the
appropriate mode and data information to the iommu domain,
as per its secure state. This information will be used by
the iommu driver during its init, and block any API that
might tend to program the L2MMU at runtime in secure mode.

Change-Id: I1887f3eb1616f9b74a9b95b3915bf66e02ee75d4
Signed-off-by: Suman Anna <s-anna@ti.com>
Merge branch 'p-linux-omap-3.4' into p-android-omap-3.4

* p-linux-omap-3.4:
  remoteproc: configure iommu for secure and normal modes
  remoteproc: add functions to retrieve secure mode & ttbr value
  remoteproc: split the secure sections parsing and authentication
  remoteproc: program the iommu after handling resources
  iommu/omap: add support for secure mode
  iommu: export an api to add domain data
  iommu/omap: fix an uninitialized variable compilation warning
  remoteproc: remove firmware.h dependencies from secure code

Change-Id: I0f56a2f32c7df6d21071a972db33c36d27096655
Signed-off-by: Praneeth Bajjuri <praneeth@ti.com>
Revert "sgx_omaplfb: cleanup static configuration"

This reverts commit a33f0a13e374e7d3aa94678ec7c818f190a4bab4.

The configuration of framebuffers was moved to board files and
The default configuration was removed from OmapLFB after it.
This brokes Blaze because Blaze has no specific configuration
for OMAPLFB driver.

This revert adds a default configuration for devices which
has no a specific configuration for OmapLFB in a board file.

Change-Id: I8b5b0f0e21c3cafac43a528499c1cd156d5c3ef4
Signed-off-by: Artem Rudenko <artemrudenko@ti.com>
remoteproc: disable auto-suspend when entering secure mode

Secure module reads iommu ttbr register in order to make sure that the
iommu is using a firewalled MMU table. The clocks to iommu therefore
cannot be cut during secure play back. The remoteproc auto-suspend
is disabled for ipu processor when entering secure mode, and is
reenabled when switching back to normal mode.

Change-Id: I64b0b3acc7d9526b5b538104f7946d0e8ed0a537
Signed-off-by: Suman Anna <s-anna@ti.com>
remoteproc: add support to use a carveout memory pool

The remoteproc driver relies on device-specific CMA pool for
allocating memory for various firmware image sections. Support
has been added now to let the remoteproc driver choose to use a
carveout pool instead of the CMA pool.

This option is added to allow flexibility and robustness for
allocations within the remoteproc driver. The carveout memory
option is especially beneficial for improving the memory allocation
times and for avoiding any possible remoteproc failures due to
run-time failure of a CMA allocation. This option provides this
reliability at the expense of a static carveout.

The remoteproc driver is self-configured to use a carveout pool
or the CMA pool based on whether a carveout pool data is supplied
or not during the rproc registration. The carveout pool data will
need to be constructed during the remoteproc device creation.

NOTE: The current changes customize the carveout allocations
specifically for the OMAP firmware sections because of its
hardcoded adherence to the CMA assignments, specifically for
the vrings and vring data buffers.

Change-Id: I396314d4e484e3e9f33f4fbf9023764a4ab9684f
Signed-off-by: Angela Stegmaier <angelabaker@ti.com>
Signed-off-by: Suman Anna <s-anna@ti.com>
remoteproc: add .get & .set virtio config ops implementations

The virtio config ops functions for get and set are added through
rproc_virtio_get and rproc_virtio_set functions. These functions
are used in a non-standard way and are overloaded primarily to allow
the virtio rpmsg bus infrastructure to query the remoteproc driver
about it carveout pool configuration and to allocate/free the vring
buffers.

Change-Id: I6fbd6d1cb502b34f556469a5238b4b18128c2171
Signed-off-by: Suman Anna <s-anna@ti.com>
rpmsg: add support for allocating vring buffers from carveout

The current rpmsg code relies and uses the same CMA pool associated
with a rproc device. Support has been added to allocate the vring
buffers from a remoteproc's carveout pool. The virtio rpmsg bus
infrastructure does not have direct access to the remoteproc pool,
so it is extended using the virtio config ops. The remoteproc
carveout configuration is also retrieved to help with the proper
cleanup of the buffers.

The remoteproc carveout allocation returns both the physical address
and a virtual address. The virtual address is an ioremap'd address
and is not exactly the equivalent to the virtual address retrieved
from a dma_alloc_coherent call. Logic is adjusted to make the
underlying virtio publish a direct-mapped kernel address so that
the offsets are identical between the virtual and physical addresses.
This is essential for the remote processor to perform the address
translation properly using address masking.

Change-Id: I55848e9f5f3a4429f968285cddf3efa1feb6b47a
Signed-off-by: Suman Anna <s-anna@ti.com>
ARM: OMAP: remoteproc: add carveout memory pool configuration

The carveout memory pool data information is added to the OMAP
remoteproc platform data. A new configurable menuconfig option
has been added to help choose between the carveout pool or the
rproc device-specific CMA pool. The default option is left to
use the CMA pool.

The carveout memory for remoteproc will still be reserved at board
initialization time, but the allocation mechanism is dictated by
the configuration option. The option controls the configuration
choice for all the remote processors on the SoC, and cannot be
enabled differently for different processors.

Change-Id: Ic14734fbc3d64a9ee1ebf7c4933f588e76f9c8bc
Signed-off-by: Angela Stegmaier <angelabaker@ti.com>
Signed-off-by: Suman Anna <s-anna@ti.com>
Merge remote-tracking branch 'origin/p-linux-omap-3.4' into p-android-omap-3.4

* origin/p-linux-omap-3.4:
  ARM: OMAP: remoteproc: add carveout memory pool configuration
  rpmsg: add support for allocating vring buffers from carveout
  remoteproc: add .get & .set virtio config ops implementations
  remoteproc: add support to use a carveout memory pool
  remoteproc: disable auto-suspend when entering secure mode

Change-Id: Ia07133451df2bd55e3bfe33d5a6170062c0705a4
Signed-off-by: Praneeth Bajjuri <praneeth@ti.com>
ARM: android_omap_defconfig: enable rproc to use carveout

The remoteproc configuration to use carveout for memory
allocations is turned on by default in the android_omap
defconfig. This is being done to avoid any CMA allocation
failures during the reload of the remote processor specifically
for secure playback usecase (not seen during regular operation).

Change-Id: I154e8160c782f02ed83964218560957a14039b65
Signed-off-by: Suman Anna <s-anna@ti.com>
Merge remote-tracking branch 'omapzoom/p-android-omap-3.4' into p-android-omap-3.4