remoteproc: da8xx: don't select CMA on no-MMU

We can only use CMA on systems that have an MMU, because of
the requirement to use memory migration. NOMMU systems are
rather constrained to start with, but it seems reasonable
to assume that DMA allocations can still succeed in the
constrained case for remoteproc on NOMMU, so this patch
changes the da8xx implementation to not rely on CMA when
the MMU is disabled.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Ohad Ben-Cohen <ohad@wizery.com>
Cc: Robert Tivy <rtivy@ti.com>
[s-anna@ti.com: cherry-pick commit '8c09452' from 3.16]
Signed-off-by: Suman Anna <s-anna@ti.com>
remoteproc: use a flag to detect the presence of IOMMU

The remoteproc driver core currently relies on iommu_present() on
the bus the device is on, to perform MMU management. However, this
logic doesn't scale for multi-arch, especially for processors that
do not have an IOMMU. Replace this logic instead by using a h/w
capability flag for the presence of IOMMU in the rproc structure.

The individual platform implementations are required to set this
flag appropriately. The default setting is to not have an MMU.

The OMAP remoteproc driver is updated while at this, to maintain
the functionality with the IOMMU detection logic change in this
patch.

Cc: Sjur Brændeland <sjur.brandeland@stericsson.com>
Cc: Robert Tivy <rtivy@ti.com>
Signed-off-by: Suman Anna <s-anna@ti.com>
remoteproc: add support to handle internal memories

A remote processor may need to load certain firmware sections into
internal memories (eg: RAM at L1 or L2 levels) for performance or
other reasons. Introduce a new resource type (RSC_INTMEM) and add
an associated handler function to handle such memories. The handler
creates a kernel mapping for the resource's 'pa' (physical address).

Note that no iommu mapping is performed for this resource, as the
resource is primarily used to represent physical internal memories.
If the internal memory region can only be accessed through an iommu,
a devmem resource entry should be used instead.

Signed-off-by: Robert Tivy <rtivy@ti.com>
Signed-off-by: Suman Anna <s-anna@ti.com>
mailbox/omap: use devm_* interfaces

Use the various devm_ interfaces to simplify the cleanup in
probe and remove functions in OMAP2+ mailbox driver.

Signed-off-by: Suman Anna <s-anna@ti.com>
mailbox/omap: remove OMAP1 mailbox driver

There are no existing users for OMAP1 mailbox driver
in kernel. Commit ab6f775 "Removing dead OMAP_DSP"
has cleaned up all the dead code related to the only
possible user, including the creation of the mailbox
platform device.

Remove this stale driver so that the OMAP mailbox
driver can be simplified and streamlined better for
converting to mailbox framework.

Acked-by: Tony Lindgren <tony@atomide.com>
Acked-by: Aaro Koskinen <aaro.koskinen@iki.fi>
Signed-off-by: Suman Anna <s-anna@ti.com>
mailbox/omap: remove omap_mbox_type_t from mailbox ops

The type definition omap_mbox_type_t used for distinguishing
OMAP1 from OMAP2+ mailboxes is no longer needed after the
removal of OMAP1 mailbox driver, and has therefore been
cleaned up. This cleanup also eliminates the need for the
polling logic used for checking the transmit readiness.

Signed-off-by: Suman Anna <s-anna@ti.com>
mailbox/omap: simplify the fifo assignment by using macros

The OMAP mailbox IP has two different type of interrupt configuration
registers between OMAP4+ SoCs and OMAP2/3 SoCs. Simplify the current
interrupt configuration by using a single macro that translates the
two variants.

Signed-off-by: Suman Anna <s-anna@ti.com>
mailbox/omap: consolidate OMAP mailbox driver

There is no need for a separate common OMAP mailbox module
now that the OMAP1 mailbox driver has been removed. So,
consolidate the two individual OMAP mailbox modules into a
single driver. This streamlines the driver for converting
to mailbox framework.

The following are the main changes:
- collapse mailbox-omap2.c into omap-mailbox.c
- remove omap_mbox_ops and replace the ops calls with
  the equivalent functionality.
- simplify the sub-mailbox startup/shutdown functionality,
  the one-time operations are moved into probe, and the
  pm_runtime_get_sync and pm_runtime_put_sync can be invoked
  without using a configuration counter.
- move all definitions from private omap_mbox.h into the
  source code, and eliminate this internal header.
- rename some variables that used the omap2_mbox prefix with
  a generic omap_mbox prefix.

Signed-off-by: Suman Anna <s-anna@ti.com>
mailbox/omap: remove the private mailbox structure

The structure omap_mbox_priv is used previously to store arch
specific (OMAP1 vs OMAP2+) data, and is no longer required to be
maintained separately. Instead, absorb its elements into either
the sub-mailbox device structure, omap_mbox, or the individual
fifo descriptor structure, omap_mbox_fifo.

The newmsg_bit and notfull_bit used on Rx and Tx fifos respectively
are represented by the new intr_bit field in the fifo descriptor
structure. The interrupt configuration registers are also moved
into the fifo descriptor structure to allow the Rx and Tx fifos
to use different interrupt lines/users.

Signed-off-by: Suman Anna <s-anna@ti.com>
mailbox/omap: add a parent structure for every IP instance

A new structure, omap_mbox_device, is added to contain
the global variables pertinent to a mailbox h/w IP block.
This enables the support for having multiple instances of
the same h/w IP block in the SoC. This is in preparation
to support the DRA7 SoC, which is the first SoC in the OMAP
family to have multiple mailbox IP instances.

The changes include enhancements to the sub-mailbox registration
logic and mbox startup sequencing, removing the usage of single
global configuration variables for all h/w instances, and storing
the registered sub-mailboxes with the parent mailbox device
structure.

Signed-off-by: Suman Anna <s-anna@ti.com>
ARM: dts: OMAP2+: Add mailbox fifo and user information

The number of mailbox fifos and users (IP interrupts) are added
to the Mailbox DT nodes on OMAP2420, OMAP2430, OMAP3, and OMAP5
family of SoCs through the DT properties "ti,mbox-num-fifos" and
"ti,mbox-num-users" properties. This data represents the same data
that used to be represented in hwmod attribute data through the
.num_fifos and .num_users fields previously.

Acked-by: Pavel Machek <pavel@ucw.cz>
Signed-off-by: Suman Anna <s-anna@ti.com>
ARM: dts: OMAP4: Add mailbox node

The mailbox DT node data has been added for OMAP44xx
devices.

Signed-off-by: Suman Anna <s-anna@ti.com>
ARM: dts: AM33xx: Add mailbox node

The mailbox DT node data has been added for AM33xx device.
The mailbox IP in AM33xx is similar to the version found in
OMAP4+ devices.

Signed-off-by: Suman Anna <s-anna@ti.com>
ARM: dts: AM4372: Correct mailbox node data

The mailbox DT node for AM4372 is enabled and is corrected to
remove some properties that have crept in by mistake.

Fixes: 9e3269b (ARM: dts: AM4372: Add L2, EDMA, mailbox, MMC and SHAM nodes)
Cc: Lokesh Vutla <lokeshvutla@ti.com>
Signed-off-by: Suman Anna <s-anna@ti.com>
ARM: dts: DRA7: Add mailbox nodes

DRA7xx has 13 system mailboxes, and is present on both the
DRA72x and DRA74x family of SoCs. Add the DT nodes for all
these 13 mailboxes. Except for mailbox 1, all other mailboxes
do not have interrupts mapped into the MPU GIC by default.

All the mailboxes have been disabled and the interrupts
property information is left out intentionally for now,
because of the dependencies against the crossbar driver.
These mailboxes can be enabled when a usecase arises
and the crossbar driver dependencies are met.

NOTE: The mailbox 1 has different number of mailbox fifos
and IP interrupts compared to the remaining 12 mailboxes.

Signed-off-by: Suman Anna <s-anna@ti.com>
ARM: DRA7: hwmod_data: Add mailbox hwmod data

Add the hwmod data for the 13 instances of the system mailbox
IP in DRA7 SoC. The patch is needed for performing a soft-reset
while configuring the respective mailbox instance, otherwise is
a non-essential change for functionality. The modules are smart
idled on reset, and the IP module mode is hardware controlled.

Cc: Rajendra Nayak <rnayak@ti.com>
Cc: Paul Walmsley <paul@pwsan.com>
Signed-off-by: Suman Anna <s-anna@ti.com>
ARM: OMAP2+: Avoid mailbox legacy device creation for DT-boot

The legacy platform device for mailbox should not be created for
a DT boot, so adjust the platform device initialization logic
appropriately.

Signed-off-by: Suman Anna <s-anna@ti.com>
ARM: OMAP2: hwmod_data: Remove legacy mailbox data and addrs

OMAP2 devices are devicetree boot only, and the legacy mode
of mailbox device creation should no longer be used, so remove
the mailbox attribute data and the hwmod addr space used for
creating mailboxes in legacy mode.

Acked-by: Paul Walmsley <paul@pwsan.com>
Signed-off-by: Suman Anna <s-anna@ti.com>
ARM: OMAP4: hwmod_data: Remove legacy mailbox addrs

The legacy-style definition of the hwmod addr space is no longer
required after the addition of the OMAP4 mailbox DT node, so
clean up this data.

Cc: Paul Walmsley <paul@pwsan.com>
Cc: Benoît Cousson <bcousson@baylibre.com>
Signed-off-by: Suman Anna <s-anna@ti.com>
ARM: AM33xx: hwmod_data: Remove legacy mailbox addrs

The legacy-style definition of the hwmod addr space is no longer
required as AM33xx/AM43xx are DT-boot only, and the minimal mailbox
DT nodes have been added, so clean up this data.

Acked-by: Paul Walmsley <paul@pwsan.com>
Signed-off-by: Suman Anna <s-anna@ti.com>