soc: ti: pruss: add helper functions to set GPI mode, MII_RT_event and XFR

The PRUSS CFG module is represented as a syscon node and is currently
managed by the PRUSS platform driver. Add easy accessor functions to set
GPI mode, MII_RT event enable/disable and XFR (XIN XOUT) enable/disable
to enable the PRUSS Ethernet usecase. These functions reuse the generic
pruss_regmap_update() API function.

Signed-off-by: Suman Anna <s-anna@ti.com>

soc: ti: pruss: add pruss_regmap_read()/update() API

Add two new generic API pruss_regmap_read() and pruss_regmap_update()
to the PRUSS platform driver to allow other drivers to read and program
respectively a register within one of the PRUSS sub-modules represented
by a syscon driver. The sub-modules include PRUSS CFG, IEP and MII_RT
at present. This interface provides a simple way for client drivers
without having them to include and parse these syscon nodes within
their respective device nodes. Various useful registers (mainly CFG
module) and macros for certain register bit-fields and their values
have also been added.

It is the responsibility of the client drivers to reconfigure or
reset a particular register upon any failures.

Signed-off-by: Suman Anna <s-anna@ti.com>

soc: ti: pruss: add pruss_{request,release}_mem_region() API

Add two new API - pruss_request_mem_region() & pruss_release_mem_region(),
to the PRUSS platform driver to allow client drivers to acquire and release
the common memory resources present within a PRU-ICSS subsystem. This
allows the client drivers to directly manipulate the respective memories,
as per their design contract with the associated firmware.

Signed-off-by: Andrew F. Davis <afd@ti.com>
[s-anna@ti.com: rename functions, add error checking, comments]
Signed-off-by: Suman Anna <s-anna@ti.com>

soc: ti: pruss: add pruss_get()/put() API

Add two new get and put API, pruss_get() and pruss_put(), to the
PRUSS platform driver to allow client drivers to request a handle
to a PRUSS device. This handle will be used by client drivers to
request various operations of the PRUSS platform driver through
additional API that will be added in the following patches.

The pruss_get() function returns the pruss handle corresponding
to a PRUSS device referenced by a PRU remoteproc instance. The
pruss_put() is the complimentary function to pruss_get().

Signed-off-by: Tero Kristo <t-kristo@ti.com>
[s-anna@ti.com: various fixups and cleanups]
Signed-off-by: Suman Anna <s-anna@ti.com>

remoteproc/pru: add pru_rproc_get_id() API to retrieve the PRU id

Export an API pru_rproc_get_id() to allow other PRUSS platform
drivers to clients to retrieve the PRU id from a remoteproc handle
associated with a PRU. The new function takes in a struct rproc
pointer as argument.

Signed-off-by: Suman Anna <s-anna@ti.com>

remoteproc/pru: add support for parsing pru interrupt mapping from DT

PRU interrupt mapping can now be parsed from devicetree also. The design
uses a single property "ti,pru-interrupt-map" in the PRU consumer nodes
to list all the interrupt mapping data associated with all the PRUs used
by the PRU consumer/application. This is an alternative configuration
method in addition to the legacy resource table config, and supercedes
any firmware provided intc configuration structure.

The design parses and configures the PRU INTC when a client driver
acquires a PRU core through pru_rproc_get(), and unconfigures the INTC
when it releases the PRU core through pru_rproc_put(). The design also
allows any referenced PRU cores with zero corresponding entries in the
"ti,pru-interrupt-map" property to fallback to use the interrupt mapping
data through the firmware intc vendor resource type, that is processed
during the loading/starting of the core through rproc_boot(). This
provides the maximum flexibility for PRU client drivers/applications.
If both are provided, the config in DT takes precedence. It is possible
that a client neither has the DT property nor uses the vendor resource
in its firmware, implying that particular PRU core doesn't use/need any
interrupts.

Signed-off-by: Tero Kristo <t-kristo@ti.com>
[rogerq@ti.com: refactor DT-parse logic into a separate function]
Signed-off-by: Roger Quadros <rogerq@ti.com>
[s-anna@ti.com: various fixes and cleanups, update patch description]
Signed-off-by: Suman Anna <s-anna@ti.com>

remoteproc/pru: configure firmware based on client setup

Client device node property firmware-name is now used to configure
firmware for the PRU instances. The default firmware is also
restored once releasing the PRU resource.

Signed-off-by: Tero Kristo <t-kristo@ti.com>
Signed-off-by: Suman Anna <s-anna@ti.com>

remoteproc/pru: Add pru_rproc_set_ctable() function

Some firmwares expect the OS drivers to configure the CTABLE
entries publishing dynamically allocated memory regions. For
example, the PRU Ethernet firmwares use the C28 and C30 entries
for retrieving the Shared RAM and System SRAM (OCMC) areas
allocated by the PRU Ethernet client driver.

Provide a way for users to do that through a new API,
pru_rproc_set_ctable(). The API returns 0 on success and
a negative value on error.

NOTE:
The programmable CTABLE entries are typically re-programmed by
the PRU firmwares when dealing with a certain block of memory
during block processing. This API provides an interface to the
PRU client drivers to publish a dynamically allocated memory
block with the PRU firmware using a CTABLE entry instead of a
negotiated address in shared memory. Additional synchronization
may be needed between the PRU client drivers and firmwares if
different addresses needs to be published at run-time reusing
the same CTABLE entry.

Signed-off-by: Roger Quadros <rogerq@ti.com>
Signed-off-by: Andrew F. Davis <afd@ti.com>
[s-anna@ti.com: add the NOTE: on patch description, minor cleanups]
Signed-off-by: Suman Anna <s-anna@ti.com>

remoteproc/pru: deny rproc sysfs ops for PRU client driven boots

The PRU remoteproc driver is not configured for 'auto-boot' by default,
and allows to be booted either by in-kernel PRU client drivers or by
userspace using the generic remoteproc sysfs interfaces. The sysfs
interfaces should not be permitted to change the remoteproc firmwares
or states when a PRU is being managed by an in-kernel client driver.
Use the newly introduced remoteproc generic 'deny_sysfs_ops' flag to
provide these restrictions by setting and clearing it appropriately
during the PRU acquire and release steps.

Signed-off-by: Suman Anna <s-anna@ti.com>

remoteproc/pru: add APIs to get and put the PRU cores

Add two new APIs, pru_rproc_get() and pru_rproc_put(), to the PRU
driver to allow client drivers to acquire and release the remoteproc
device associated with a PRU core. The PRU cores are treated as
resources with only one client owning it at a time.

The pru_rproc_get() function returns the rproc handle corresponding
to a PRU core identified by the device tree "prus" property under
the client node. The pru_rproc_put() is the complementary function
to pru_rproc_get().

Signed-off-by: Tero Kristo <t-kristo@ti.com>
[s-anna@ti.com: improve error checking, various fixes and cleanups]
Signed-off-by: Suman Anna <s-anna@ti.com>

dt-bindings: remoteproc: pru: Document application node bindings

Add documentation for the common properties that can be used by the
PRU consumer/application nodes and supported by the PRU remoteproc
driver. These are used to configure the PRU hardware for specific
user applications.

The application nodes themselves should define their own bindings.

Signed-off-by: Tero Kristo <t-kristo@ti.com>
[s-anna@ti.com: some binding updates]
Signed-off-by: Suman Anna <s-anna@ti.com>

ARM: dts: keystone-k2g: Add PRU system events for virtio

Two PRU system events "vring" and "kick" have been added to each
PRU node in each of the PRU-ICSS0 and PRU-ICSS1 remote processor
subsystems to enable the virtio/rpmsg communication between MPU
and that PRU core. The additions are done in the common base
keystone-k2g.dtsi file, and so are inherited by all 66AK2G boards.

The PRU system events is the preferred approach over using the
alternate IPCGR registers, as it eliminates an external MMR access
from the PRU-side, and keeps the interrupt generation internal to
the PRUSS. The difference from MPU would be minimal in using one
versus the other. Note that the 66AK2G SoCs do not have the OMAP
Mailbox IP, so there is no option of using mailboxes.

Signed-off-by: Suman Anna <s-anna@ti.com>

ARM: dts: DRA7: Add PRU system events for virtio

Two PRU system events "vring" and "kick" have been added to each
PRU node in each of the PRU-ICSS1 and PRU-ICSS2 remote processor
subsystems to enable the virtio/rpmsg communication between MPU
and that PRU core. The additions are done in the common base
dra7.dtsi file, and so are inherited by all the AM57xx boards.
Do note that PRUSS is not available/supported on the DRA7xx SoCs
SoCs and is only limited to the AM57xx SoCs.

The PRU system events is the preferred approach over using OMAP
mailboxes, as it eliminates an external peripheral access from
the PRU-side, and keeps the interrupt generation internal to the
PRUSS. The difference from MPU would be minimal in using one
versus the other.

Mailboxes can still be used if desired. Either approach would
require that an appropriate firmware image is loaded/booted on
the PRU.

Signed-off-by: Suman Anna <s-anna@ti.com>

ARM: dts: AM4372: Add PRU system events for virtio

Two PRU system events "vring" and "kick" have been added to each
PRU node in each of the PRU-ICSS0 and PRU-ICSS1 remote processor
subsystems to enable the virtio/rpmsg communication between MPU
and that PRU core. The additions are done in the base am4372.dtsi
file, and so are inherited by all the AM437x boards. Do note that
PRUSS is not available on all AM437x SoCs.

The PRU system events is the preferred approach over using OMAP
mailboxes, as it eliminates an external peripheral access from
the PRU-side, and keeps the interrupt generation internal to the
PRUSS. The difference from MPU would be minimal in using one
versus the other.

Mailboxes can still be used if desired. Either approach would
require that an appropriate firmware image is loaded/booted on
the PRU.

Signed-off-by: Suman Anna <s-anna@ti.com>

ARM: dts: AM33xx: Add PRU system events for virtio

Two PRU system events "vring" and "kick" have been added to each
of the PRU nodes in the PRU-ICSS remote processor subsystem to
enable the virtio/rpmsg communication between MPU and that PRU
core. The additions are done in the base am33xx.dtsi file, and
so are inherited by all the AM33xx boards. Do note that PRUSS
is not available on all AM335x SoCs.

The PRU system events is the preferred approach over using OMAP
mailboxes, as it eliminates an external peripheral access from
the PRU-side, and keeps the interrupt generation internal to the
PRUSS. The difference from MPU would be minimal in using one
versus the other.

Mailboxes can still be used if desired. Either approach would
require that an appropriate firmware image is loaded/booted on
the PRU.

Signed-off-by: Suman Anna <s-anna@ti.com>

remoteproc/pru: Add support for virtio rpmsg stack

The PRU remoteproc driver has been enhanced to support the optional
rpmsg stack using the virtio-ring based communication transport
between MPU and a PRU core. This provides support to any firmware
images supporting the virtio devices.

The virtio-ring signalling support is provided either through a OMAP
mailbox or through two PRU system events on OMAP-architecture based
SoCs - one event used in each direction for kicking from one processor
and receiving notification on the other processor. The virtio rpmsg
signalling is enabled only using using PRU system events for interrupts
on the Keystone-architecture based 66AK2G SoCs (it is possible to
implement using an alternate Keystone specific IPCGR registers as well).
The driver supports both signalling options, though the PRU events based
signalling is the recommended option as it avoids an external peripheral
access from the PRU side. It also provides a uniform solution across
both the OMAP, Keystone and Davinci architectures. The PRU events based
signalling takes precedence if both options are mentioned. Either of the
options would require the corresponding firmware support though. A build
dependency against MAILBOX is also added. Note that the OMAP Mailbox
IP is not present on 66AK2G and Davinci SoCs, so it is only selected
for OMAP-based SoCs.

Signed-off-by: Suman Anna <s-anna@ti.com>

dt-bindings: remoteproc: pru: Update bindings for supporting rpmsg

Update the PRU remoteproc DT bindings to add the properties required
to support the optional virtio rpmsg stack using the virtio-ring based
communication transport between MPU and a PRU core.

Signed-off-by: Suman Anna <s-anna@ti.com>

ARM: dts: keystone-k2g: Add PRUSS GPIO controller nodes

Add the PRUSS GPIO controller nodes on the 66AK2G SoC. These can
be used to send interrupts to specific PRUSS subsystem instances
present on the SoC. Each PRUSS is capable of receiving an interrupt
each from two such nodes. The IP is identical to that of the
equivalent node for the DSP present on 66AK2G SoC.

Signed-off-by: Suman Anna <s-anna@ti.com>

ARM: dts: keystone-k2g: Add PRUSS MDIO controller nodes

The PRUSSs on 66AK2G SoCs contain an MDIO controller that can
be used to control external PHYs associated with the Industrial
Ethernet peripherals within each PRUSS. The MDIO module used
within the PRU-ICSS is an instance of the MDIO Controller used
in TI Davinci SoCs. The same bus frequency of 2.5 MHz is chosen
as the regular MDIO node.

The nodes are added to the common keystone-k2g dts file and are
disabled. These need to be enabled in the respective board files
supporting 66AK2G SoCs and where the ethernet is pinned out and
connected properly.

Signed-off-by: Suman Anna <s-anna@ti.com>

ARM: dts: keystone-k2g: Add the PRU-ICSS nodes

Add the DT nodes for the PRU-ICSS0 and PRU-ICSS1 processor subsystems
that are present on the 66AK2G SoC. The two PRU-ICSSs are identical
to each other. Each PRU-ICSS instance is represented by a pruss-soc-bus
node and a child PRUSS subsystem node. These nodes are enabled by
default.

The PRU-ICSSs on 66AK2G are very similar to the PRUSS on the AM57xx
SoCs except for larger Shared Data RAM and the lack of a PRU-ICSS
crossbar. There are also few other minor integration differences
w.r.t IPC mechansims that can be attributed to the architecture
differences between Keystone and OMAP families.

The PRUSS subsystem node contains the entire address space and the
various interrupts generated towards the main MPU. The various
sub-modules of the PRU-ICSS are represented as individual child
nodes (so platform devices themselves) of the PRUSS subsystem node.
These include the two PRU cores and the interrupt controller. The
Industrial Ethernet Peripheral (IEP), the Real Time Media Independent
Interface controller (MII_RT), and the CFG sub-module are represented
as syscon nodes. All the Data RAMs are represented within a child
node of its own named 'memories' without any compatible.

The DT nodes use all standard properties. The regs property in the
PRU nodes define the addresses for the Instruction RAM, the Debug
and Control sub-modules for that PRU core. The firmware for each
PRU core is defined through a 'firmware-name' property.

The default names for the firmware images for each PRU core are
defined as follows (these can be adjusted either in derivative
board dts files or through sysfs at runtime if required):
    PRU-ICSS0 PRU0 Core: k2g-pru0_0-fw
    PRU-ICSS0 PRU1 Core: k2g-pru0_1-fw
    PRU-ICSS1 PRU0 Core: k2g-pru1_0-fw
    PRU-ICSS1 PRU1 Core: k2g-pru1_1-fw

Signed-off-by: Suman Anna <s-anna@ti.com>

ARM: dts: am57xx-idk-common: Enable PRU-ICSS nodes

The two PRU-ICSS processor subsystem bus nodes and their corresponding
subsystem nodes were left in disabled state in the base dra7.dts file.
The PRU-ICSSs are supported on only the AM57xx SoCs, so enable these
nodes (both PRU-ICSS1 and PRU-ICSS2 instances) to support them on
all the AM571x, AM572x and AM574x IDK boards. The PRU nodes are
already enabled in the base dts file, and so become effective
automatically with the enabling of these PRU-ICSS nodes.

The corresponding PRU nodes can be disabled later on if there are
no use-cases defined to use a particular PRU core or the whole
PRU-ICSS subsystem itself if both its PRU cores are unused.

Signed-off-by: Suman Anna <s-anna@ti.com>

ARM: dts: beagle-x15-common: Enable PRU-ICSS nodes

The two PRU-ICSS processor subsystem bus nodes and their corresponding
subsystem nodes were left in disabled state in the base dra7.dts file.
The PRU-ICSSs are supported on only the AM57xx SoCs, so enable these
nodes ((both PRU-ICSS1 and PRU-ICSS2 instances) to support them on
all the BeagleBoard-X15 and AM57xx GP EVM boards. The PRU nodes are
already enabled in the base dts file, and so become effective
automatically with the enabling of these PRU-ICSS nodes.

The corresponding PRU nodes can be disabled later on if there are
no use-cases defined to use a particular PRU core or the whole
PRU-ICSS subsystem itself if both its PRU cores are unused.

Signed-off-by: Suman Anna <s-anna@ti.com>

ARM: DRA7: hwmod_data: Add PRU-ICSS data for AM57xx variants

The AM57xx family of SoCs have two PRU-ICSS remote processor
subsystems, each supporting two PRU processor cores. These
subsystems are not supported on the DRA7 family of SOCs. They
are very similar to the respective processor subsystems on
AM33xx/AM43xx SoCs except for a few differences. The relevant
hwmod classes and data structures have been added for the
PRU-ICSS1 and PRU-ICSS2 subsystems to enable support for
these on the AM57xx SoC variants.

Do note that these subsystems do not have a programmable module
reset line unlike those present in AM33xx/AM43xx. The modules
are reset just like any other IP with the SoC's global cold/warm
resets.

Signed-off-by: Suman Anna <s-anna@ti.com>

ARM: dts: DRA7: Add PRUSS MDIO controller nodes

The PRUSSs on AM57xx SoCs contain an MDIO controller that can
be used to control external PHYs associated with the Industrial
Ethernet peripherals within each PRUSS. The MDIO module used
within the PRU-ICSS is an instance of the MDIO Controller used
in TI Davinci SoCs. The same bus frequency of 1 MHz is chosen as
the regular MDIO node.

The nodes are added to the common DRA7 dts file and are disabled.
These need to be enabled in the respective board files supporting
AM57xx SoCs and where the ethernet is pinned out and connected
properly.

Signed-off-by: Andrew F. Davis <afd@ti.com>
[s-anna@ti.com: revise commit description]
Signed-off-by: Suman Anna <s-anna@ti.com>

ARM: dts: DRA7: Add the PRU-ICSS nodes

Add the DT nodes for the PRU-ICSS1 and PRU-ICSS2 processor subsystems
that are present on AM57xx family of SoCs. Each PRU-ICSS instance is
represented by a pruss-soc-bus node and a child PRUSS subsystem node.
The two PRU-ICSSs are identical to each other. They are not supported
on DRA7xx SoCs in general, so the nodes are added in disabled state
to the common dra7 DTS file. They should be enabled only in the AM57xx
related board files.

The PRU-ICSSs on AM57xx are very similar to the PRUSS in AM33xx and
AM437x except for variations in the RAM sizes and the number of
interrupts coming into the MPU INTC. The interrupt events into the
PRU-ICSS also requires programming of the corresponding crossbars
properly.

The PRUSS subsystem node contains the entire address space and the
various interrupts generated towards the main MPU. The various
sub-modules of the PRU-ICSS are represented as individual child
nodes (so platform devices themselves) of the PRUSS subsystem node.
These include the two PRU cores and the interrupt controller. The
Industrial Ethernet Peripheral (IEP), the Real Time Media Independent
Interface controller (MII_RT), and the CFG sub-module are represented
as syscon nodes. All the Data RAMs are represented within a child
node of its own named 'memories' without any compatible.

The DT nodes use all standard properties. The regs property in the
PRU nodes define the addresses for the Instruction RAM, the Debug
and Control sub-modules for that PRU core. The firmware for each
PRU core is defined through a 'firmware-name' property.

The default names for the firmware images for each PRU core are
defined as follows (these can be adjusted either in derivative
board dts files or through sysfs at runtime if required):
    PRU-ICSS1 PRU0 Core: am57xx-pru1_0-fw
    PRU-ICSS1 PRU1 Core: am57xx-pru1_1-fw
    PRU-ICSS2 PRU0 Core: am57xx-pru2_0-fw
    PRU-ICSS2 PRU1 Core: am57xx-pru2_1-fw

Signed-off-by: Suman Anna <s-anna@ti.com>

ARM: dts: am437x-idk: Enable PRU-ICSS nodes

The AM437x IDK board uses a AM437x SoC that supports two PRU-ICSS
instances. The PRU-ICSS processor bus nodes and subsystem nodes were
left in disabled state in the base am4372.dtsi file. All these nodes
(both PRU-ICSS1 and PRU-ICSS0 instances) have been enabled now. The
PRU nodes are already enabled in the base dts file, and so become
effective automatically with the enabling of these PRU-ICSS nodes.

The corresponding PRU nodes can be disabled later on if there are
no use-cases defined to use a particular PRU core or the whole
PRU-ICSS subsystem itself if both its PRU cores are unused.

Signed-off-by: Suman Anna <s-anna@ti.com>

ARM: dts: am437x-sk: Enable PRU-ICSS nodes

The AM437x SK EVM board uses a AM437x SoC that supports two PRU-ICSS
instances. The PRU-ICSS processor bus nodes and subsystem nodes were
left in disabled state in the base am4372.dtsi file. All these nodes
(both PRU-ICSS1 and PRU-ICSS0 instances) have been enabled now. The
PRU nodes are already enabled in the base dts file, and so become
effective automatically with the enabling of these PRU-ICSS nodes.

The corresponding PRU nodes can be disabled later on if there are
no use-cases defined to use a particular PRU core or the whole
PRU-ICSS subsystem itself if both its PRU cores are unused.

Signed-off-by: Suman Anna <s-anna@ti.com>

ARM: dts: am437x-gp-evm: Enable PRU-ICSS nodes

The AM437x GP EVM board uses a AM437x SoC that supports two PRU-ICSS
instances. The PRU-ICSS processor bus nodes and subsystem nodes were
left in disabled state in the base am4372.dtsi file. All these nodes
(both PRU-ICSS1 and PRU-ICSS0 instances) have been enabled now. The
PRU nodes are already enabled in the base dts file, and so become
effective automatically with the enabling of these PRU-ICSS nodes.

The corresponding PRU nodes can be disabled later on if there are
no use-cases defined to use a particular PRU core or the whole
PRU-ICSS subsystem itself if both its PRU cores are unused.

Signed-off-by: Suman Anna <s-anna@ti.com>

ARM: OMAP2+: extend pruss pdata-quirks to AM437x SoCs

The omap_device API is needed to perform the reset management for
any IP instances with PRCM RSTCTRL registers (hard reset lines).
This API is limited to the mach-omap2 layer, and cannot be exposed
to drivers layer directly.

AM437x requires the same functional reset management with PRUSS
as on AM33xx, so extend the AM33xx pruss pdata quirks to AM437x
as well. AM33xx relied on pdata quirks and platform data ops for
the PRUSS IP, to plumb the required omap_device API with the PRUSS
SoC bus driver ops to achieve the required reset functionality.
This was implemented in this fashion as there is no separate reset
driver at the moment.

Signed-off-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Keerthy <j-keerthy@ti.com>

ARM: dts: AM4372: Add PRUSS MDIO controller node

The PRU-ICSS1 instance on AM437x SoCs has a MDIO sub-module that
can be used to control external PHYs associated with the Industrial
Ethernet peripherals within the PRUSS. The MDIO module used within
this PRU-ICSS is an instance of the MDIO Controller used in TI
Davinci SoCs. The same bus frequency of 1 MHz is chosen as the
regular MDIO node. Note that there is no MDIO node added to the
smaller PRU-ICSS0 instance as the MDIO pins are not pinned out.

The node is added to the common am4372 dtsi file and is disabled.
This needs to be enabled in the respective board files using the
relevant AM437x SoCs supporting PRUSS and where the ethernet is
pinned out and connected properly.

Signed-off-by: Andrew F. Davis <afd@ti.com>
[s-anna@ti.com: fix reg address, add commit description]
Signed-off-by: Suman Anna <s-anna@ti.com>

ARM: dts: AM4372: Add the PRU-ICSS0 DT node

The AM437x SoC has a second smaller PRU-ICSS subsystem (PRUSS0)
in addition to the primary PRUSS1 instance. The PRUSS0 has less
DRAM per PRU, and no Shared DRAM among other minor differences.
The IEP and MII_RT modules even though present within the IP are
are not pinned out.

This PRUSS0 instance has a weird SoC integration. It shares the
same L3 OCP interconnect interface with PRUSS1, and also shares
its reset line and clocks. Any external accesses from PRUSS0
requires the PRUSS1's PRUSS_SYSCFG register to be programmed
properly. That said, it is its own IP instance (a cut-down version),
and so it has been added as an independent node (sibling node to
PRUSS1 node) and a child node of the PRUSS SoC bus node. This
allows the PRUSS0 instance to be enabled/disabled independently
of the PRUSS1 instance.

The nodes are added in disabled state as not every SoC in the
AM437x family has the PRU-ICSSs (AM4372 SoC lacks the support).
They need to be enabled in the respective board dts file based
on the SoC being used.

The default names for the firmware images for each PRU core are
defined as follows (these can be adjusted either in derivative
board dts files or through sysfs at runtime if required):
     PRU-ICSS0 PRU0 Core: am437x-pru0_0-fw
     PRU-ICSS0 PRU1 Core: am437x-pru0_1-fw

Signed-off-by: Suman Anna <s-anna@ti.com>

ARM: dts: AM4372: Add the PRU-ICSS1 DT node

Add the DT node for the PRU-ICSS1 instance on the AM437x family
of SoCs. Each PRU-ICSS instance is represented by the pruss-soc-bus
node and a child PRUSS subsystem node. The PRU-ICSS instances are
not supported on AM4372 SoC though in the AM437x family, so the
nodes are added in disabled state in the common am4372 dtsi file.
They should be enabled in only those derivative board files that
use a SoC containing PRU-ICSS.

The PRU-ICSS1 on AM437x is very similar to the PRUSS in AM33xx,
except for variations in the RAM sizes, bus addresses and the
number of interrupts coming into the MPU INTC (host interrupt
7 is routed to the other PRUSS instead of MPU).

The PRUSS subsystem node contains the entire address space and
the various interrupts generated towards the main MPU. The various
sub-modules of the PRU-ICSS are represented as individual child
nodes (so platform devices themselves) of the PRUSS subsystem node.
These include the two PRU cores and the interrupt controller. The
Industrial Ethernet Peripheral (IEP), the Real Time Media Independent
Interface controller (MII_RT), and the CFG sub-module are represented
as syscon nodes. All the Data RAMs are represented within a child node
of its own named 'memories' without any compatible.

The DT nodes use all standard properties. The regs property in the
PRU nodes define the addresses for the Instruction RAM, the Debug
and Control sub-modules for that PRU core. The firmware for each
PRU core is defined through a 'firmware-name' property.

The default names for the firmware images for each PRU core are
defined as follows (these can be adjusted either in derivative
board dts files or through sysfs at runtime if required):
     PRU-ICSS1 PRU0 Core: am437x-pru1_0-fw
     PRU-ICSS1 PRU1 Core: am437x-pru1_1-fw

Signed-off-by: Suman Anna <s-anna@ti.com>

ARM: dts: am335x-icev2: Enable PRU-ICSS nodes

The PRU-ICSS processor bus node and subsystem nodes were left in
disabled state in the base am33xx.dtsi file. PRU-ICSS is supported
on the AM335x ICEv2 board, so enable both these PRU-ICSS nodes. The
PRU nodes are already enabled in the base dts file, and so become
effective automatically with the enabling of these PRU-ICSS nodes.

The corresponding PRU nodes can be disabled later on if there are
no use-cases defined to use a particular PRU core or the whole
PRU-ICSS subsystem itself if both its PRU cores are unused.

Signed-off-by: Suman Anna <s-anna@ti.com>

ARM: dts: am335x-evmsk: Enable PRU-ICSS nodes

The PRU-ICSS processor bus node and subsystem nodes were left in
disabled state in the base am33xx.dtsi file. PRU-ICSS is supported
on the AM335x SK EVM board, so enable both these PRU-ICSS nodes. The
PRU nodes are already enabled in the base dts file, and so become
effective automatically with the enabling of these PRU-ICSS nodes.

The corresponding PRU nodes can be disabled later on if there are
no use-cases defined to use a particular PRU core or the whole
PRU-ICSS subsystem itself if both its PRU cores are unused.

Signed-off-by: Suman Anna <s-anna@ti.com>

ARM: dts: am335x-evm: Enable PRU-ICSS nodes

The PRU-ICSS processor bus node and subsystem nodes were left in
disabled state in the base am33xx.dtsi file. PRU-ICSS is supported
on the AM335x EVM, so enable both these PRU-ICSS nodes. The PRU
nodes are already enabled in the base dts file, and so become
effective automatically with the enabling of these PRU-ICSS nodes.

The corresponding PRU nodes can be disabled later on if there are
no use-cases defined to use a particular PRU core or the whole
PRU-ICSS subsystem itself if both its PRU cores are unused.

Signed-off-by: Suman Anna <s-anna@ti.com>

ARM: dts: am335x-bone-common: Enable PRU-ICSS nodes

The PRU-ICSS processor bus node and subsystem nodes were left in
disabled state in the base am33xx.dtsi file. Enable both these
PRU-ICSS nodes on all the AM335x beaglebone boards as they mostly
use a AM3358 or a AM3359 SoC which do contain the PRU-ICSS IP.
The PRU nodes are already enabled in the base dts file, and so
become effective automatically with the enabling of these PRU-ICSS
nodes.

The corresponding PRU nodes can be disabled later on if there are
no use-cases defined to use a particular PRU core or the whole
PRU-ICSS subsystem itself if both its PRU cores are unused.

Signed-off-by: Suman Anna <s-anna@ti.com>

ARM: OMAP2+: use pdata quirks for PRUSS reset lines on AM335x

The omap_device API is needed to perform the reset management for
any IP instances with PRCM RSTCTRL registers (hard reset lines).
This API is limited to the mach-omap2 layer, and cannot be exposed
to drivers layer directly. So use platform data ops and pdata quirks
for the PRUSS IP in AM335x SoCs to plumb the required omap_device
API. The PRUSS SoC bus driver can then use these pdata ops to
achieve the required reset functionality.

This is being implemented this way as there is no separate reset
driver at the moment.

Signed-off-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Keerthy <j-keerthy@ti.com>

ARM: dts: AM33xx: Add PRUSS MDIO controller node

The PRUSS on AM335x SoCs has a MDIO sub-module that can be used
to control external PHYs associated with the Industrial Ethernet
peripherals within the PRUSS. The MDIO module used within the
PRU-ICSS is an instance of the MDIO Controller used in TI Davinci
SoCs. The same bus frequency of 1 MHz is chosen as the regular
MDIO node.

The node is added to the common am33xx dts file and is disabled.
This needs to be enabled in the respective board files using the
relevant AM335x SoCs supporting PRUSS and where the ethernet is
pinned out and connected properly.

Signed-off-by: Suman Anna <s-anna@ti.com>

ARM: dts: AM33xx: Add the PRU-ICSS DT nodes

Add the DT nodes for the PRU-ICSS on AM33xx family of SoCs. The
AM33xx SoCs contain a single PRU-ICSS instance and is represented
by the pruss-soc-bus node and a child PRUSS node. PRU-ICSS is not
supported on AM3352 SoC though in the AM33xx family, so the nodes
are added in disabled state to the common am33xx dtsi file. They
should be enabled in only those derivative board files that use
a SoC containing PRU-ICSS.

The PRUSS subsystem node contains the entire address space and
the various interrupts generated towards the main MPU. The various
sub-modules of the PRU-ICSS are represented as individual child
nodes (so platform devices themselves) of the PRUSS subsystem node.
These include the two PRU cores and the interrupt controller. The
Industrial Ethernet Peripheral (IEP), the Real Time Media Independent
Interface controller (MII_RT), and the CFG sub-module are represented
as syscon nodes. All the Data RAMs are represented within a child
node of its own named 'memories' without any compatible.

The DT nodes use all standard properties. The regs property in
the PRU nodes define the addresses for the Instruction RAM, the
Debug and Control sub-modules for that PRU core. The firmware for
each PRU core is defined through a 'firmware-name' property.

The default names for the firmware images for each PRU core are
defined as follows (these can be adjusted either in derivative
board dts files or through sysfs at runtime if required):
     PRU-ICSS PRU0 Core: am335x-pru1_0-fw
     PRU-ICSS PRU1 Core: am335x-pru1_1-fw

Signed-off-by: Suman Anna <s-anna@ti.com>

soc: ti: pruss: Add support for PRU-ICSS subsystems on 66AK2G SoC

The 66AK2G SoC supports two PRU-ICSS instances, named PRUSS0 and PRUSS1,
each of which has two PRU processor cores. The two PRU-ICSS instances
are identical to each other with few minor SoC integration differences,
and are very similar to the PRU-ICSS1 of AM57xx/AM43xx. The Shared Data
RAM size is larger and the number of interrupts coming into MPU INTC
is like the instances on AM437x. There are also few other differences
attributing to integration in Keystone architecture (like no SYSCFG
register or PRCM handshake protocols). Other IP level differences
include different constant table, differences in system event interrupt
input sources etc. They also do not have a programmable module reset
line like those present on AM33xx/AM43xx SoCs. The modules are reset
just like any other IP with the SoC's global cold/warm resets.

The existing PRUSS platform drivers have been enhanced to support
these 66AK2G PRU-ICSS instances through new 66AK2G specific compatibles
for properly probing and booting all the different PRU cores in each
PRU-ICSS processor subsystem. The SoC-level integration differences
are dealt with using match data within the PRUSS INTC and PRUSS SoC
bus drivers. A build dependency with ARCH_KEYSTONE is added to enable
the driver to be built in K2G-only configuration. The initial names
for the firmware images for each PRU core are retrieved from DT nodes,
and can be adjusted through sysfs if required.

Signed-off-by: Andrew F. Davis <afd@ti.com>
Signed-off-by: Suman Anna <s-anna@ti.com>

soc: ti: pruss: Configure SYSCFG properly during probe/remove

The PRUSS CFG module's SYSCFG register is used for managing the
PRCM clock management settings at the PRU-ICSS subsystem level.

Add two helper functions pruss_{enable/disable}_module() that
programs this SYSCFG register during probe and remove. The
register is currently programmed for the default Smart-Idle
and Smart-Standby always during probe. The MStandby is enabled
during remove to undo the settings in probe to properly configure
the SYSCFG in the case that a firmware has disabled MStandby.
This is needed on SoCs like AM57xx that do not have a reset line
and so cannot reset the register properly.

Signed-off-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Roger Quadros <rogerq@ti.com>

soc: ti: pruss: Fix system suspend/MStandby config issues

The PRU-ICSS subsystem has a separate PRUSS_CFG module that contains
various configuration registers. This includes a control bit STANDBY_INIT
in PRUSS_CFG register to initiate a Standby sequence (when set) and
trigger a MStandby request to the SoC's PRCM module. This same bit is
also used to enable the OCP master ports (when cleared). The system
suspend/resume functionality on AM33xx/AM437x/AM57xx SoCs requires
all initiators to assert their MStandby signal properly inorder to
successfully enter suspend, and resume on a wakeup event.

Certain firmwares can enable the OCP master ports through the
STANDBY_INIT programming on the firmware side in order to access
peripherals or memories external to the PRUSS. This causes a hang
in the resume sequence on AM33xx/AM437x boards and requires a
board reset to come out of the hang.

This patch adds the preliminary System PM callbacks in the PRUSS SoC
bus driver, and fixes this system resume hang by setting the STANDBY_INIT
in the PM system suspend callback and resetting it back in the PM system
resume callback, if so configured. The clearing of the STANDBY_INIT
during resume requires an acknowledgment from PRCM and is done through
the monitoring of the PRUSS_SYSCFG.SUB_MWAIT bit.

NOTE:
1. This patch only adds the PM callbacks with code to fix the System
   Suspend/Resume hang issue on AM33xx/AM437x SoCs, but does not
   implement the full context save and restore required for the PRUSS
   drivers to work across system suspend/resume when the power domain
   is switched off (L4PER domain is switched OFF on AM335x/AM437x
   during system suspend/resume, so PRUSS modules do lose context).
2. The PRUSS driver functionality on AM57xx SoCs is not affected that
   much because the PER power domain to which the PRUSS IPs belong is
   not switched OFF during suspend/resume.

Signed-off-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Roger Quadros <rogerq@ti.com>

soc: ti: pruss: Add support for PRU-ICSS subsystems on AM57xx SoCs

The AM57xx family of SoCs supports two PRU-ICSS instances, each of
which has two PRU processor cores. The two PRU-ICSS instances are
identical to each other, and are very similar to the PRU-ICSS1 of
AM33xx/AM43xx except for a few minor differences like the RAM sizes
and the number of interrupts coming into the MPU INTC. They do
not have a programmable module reset line unlike those present on
AM33xx/AM43xx SoCs. The modules are reset just like any other IP
with the SoC's global cold/warm resets. Each PRU-ICSS's INTC is also
preceded by a Crossbar that enables multiple external events to be
routed to a specific number of input interrupt events. Any interrupt
event directed towards PRUSS needs this crossbar to be setup properly
on the firmware side.

The existing PRUSS platform drivers have been enhanced to support
these AM57xx PRU-ICSS instances through new AM57xx specific
compatibles for properly probing and booting all the different PRU
cores in each PRU-ICSS processor subsystem. The SoC-level integration
differences are dealt with using match data within the PRUSS SoC bus
driver. A build dependency with SOC_DRA7XX is also added to enable
the driver to be built in AM57xx-only configuration (there is no
separate Kconfig option for AM57xx vs DRA7xx). The initial names
for the firmware images for each PRU core are retrieved from DT
nodes, and can be adjusted through sysfs if required.

Signed-off-by: Suman Anna <s-anna@ti.com>

soc: ti: pruss: Add support for PRU-ICSS0 on AM437x SoCs

The AM437x SoCs have a second smaller PRU-ICSS subsystem (PRUSS0)
in addition to the primary PRUSS1 instance. The PRUSS0 is another
instantiation of the IP, but is not identical to PRUSS1. It is
essentially a cut-down version of the IP, with less DRAM per PRU,
no Shared DRAM etc. It also does not have direct access to L3 bus
regions, there is a single interface to L3 for both PRUSS0 and
PRUSS1, and it would have to go through the PRUSS1's interface.
The PRUSS_SYSCFG register is reserved on PRUSS0, so any external
access requires the programming the corresponding PRUSS_SYSCFG
register in PRUSS1. It does have its own dedicated I/O lines
though. Note that this instance does not support any PRU Ethernet
related usecases.

The PRUSS remoteproc drivers have been enhanced to support this
smaller PRUSS0 instance using instance-specific data. The adaptation
uses a newly introduced pruss_match_private_data structure and the
pruss_get_private_data() function to retrieve a PRUSS instance
specific data using a device-name based lookup logic. The reset
and the L3 external access are managed by the common PRUSS SoC bus
driver so that PRUSS1 and PRUSS0 can be independently supported.
The initial names for the firmware images for each PRU core are
retrieved from DT nodes, and can be adjusted through sysfs if
required.

Signed-off-by: Andrew F. Davis <afd@ti.com>
Signed-off-by: Suman Anna <s-anna@ti.com>

soc: ti: pruss: Add support for PRU-ICSS1 on AM437x SoCs

Enhance all the PRUSS platform drivers to support the PRU-ICSS1
sub-system on the AM437x family of SoCs. AM437x has two PRU-ICSS
instances, and support has been added only for the PRU-ICSS1 at
the moment. PRU-ICSS1 on AM437x is very similar to the PRU-ICSS
on AM33xx except for few minor differences - increased Instruction
RAM, increased Shared Data RAM2, and 1 less interrupt (PRUSS host
interrupt 7 which is redirected to the other PRUSS) towards the
MPU INTC.

The adaptation uses newly introduced compatibles in each driver
and relying on match data within the PRUSS INTC and PRUSS SoC bus
drivers to account for the SoC-level integration differences. The
initial names for the firmware images for each PRU core are
retrieved from DT nodes, and can be adjusted through sysfs if
required.

Signed-off-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Andrew F. Davis <afd@ti.com>

remoteproc/pru: Add pru-specific debugfs support

The remoteproc core creates certain standard debugfs entries,
that does not give a whole lot of useful information for the
PRUs. The PRU remoteproc driver is enhanced to add additional
debugfs entries for PRU. These will be auto-cleaned up when
the parent rproc debug directory is removed.

The enhanced debugfs support adds two new entries: 'regs' and
'single_step'. The 'regs' dumps out the useful CTRL sub-module
registers as well as each of the 32 GPREGs and CT_REGs registers.
The GPREGs and CT_REGs though are printed only when the PRU is
halted and accessible as per the IP design.

The 'single_step' utilizes the single-step execution of the PRU
cores. Writing a non-zero value performs a single step, and a
zero value restores the PRU to execute in the same mode as the
mode before the first single step. (note: if the PRU is halted
because of a halt instruction, then no change occurs).

Logic for setting the PC and jumping over a halt instruction shall
be added in the future.

Signed-off-by: Suman Anna <s-anna@ti.com>

remoteproc/pru: Add a PRU remoteproc driver

The Programmable Real-Time Unit Subsystem (PRUSS) consists of
dual 32-bit RISC cores (Programmable Real-Time Units, or PRUs)
for program execution. This patch adds a remoteproc platform
driver for managing the individual PRU RISC cores life cycle.

The PRU remoteproc driver uses the standard remoteproc core ELF
loader. However, the PRUs do not have a unified address space,
(has an Instruction RAM and a primary Data RAM at both 0x0) and
leverage an added .da_to_va ops to use the standard ELF loader.
This remoteproc driver does not have support for error recovery
and system suspend/resume features. Different compatibles are
used to allow providing scalability for instance-specific device
data if needed. The driver uses a default firmware-name retrieved
from device-tree, and the firmwares are expected to be present
in the standard Linux firmware search paths. They can also be
adjusted by userspace if required through the sysfs interface
provided by the remoteproc core.

The PRU remoteproc driver uses a client-driven boot methodology
- it does _not_ support auto-boot so that the PRU load and boot
is dictated by the corresponding client drivers for achieving
various usecases. This allows flexibility for the client drivers
or applications to set a firmware name (if needed) based on their
desired functionality and boot the PRU. The sysfs bind and unbind
attributes have also been suppressed so that the PRU devices cannot
be unbound and thereby shutdown a PRU from underneath a PRU client
driver.

The PRU interrupt configuration is handled within the PRUSS INTC
platform driver, and leverages the system events to interrupt
channels and host interrupts mapping configuration through a
PRU firmware resource table for now. This will be revisited and
enhanced in the future for a better interface. The mappings
are currently programmed during the booting/shutdown of the PRU.

The driver currently supports the AM335x SoC, and support for other
TI SoCs will be added in subsequent patches.

Signed-off-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Andrew F. Davis <afd@ti.com>

dt-bindings: remoteproc: Add binding doc for PRU Cores in the PRU-ICSS

The Programmable Real-Time Unit Subsystem (PRUSS) consists of dual
32-bit RISC cores (Programmable Real-Time Units, or PRUs) for program
execution. This patch adds the bindings for these PRU cores.

The binding currently covers the OMAP architecture SoCs - AM33xx,
AM437x and AM57xx; and a Keystone 2 architecture based 66AK2G SoC.
The Davinci based OMAPL138 SoCs and K3 architecture based AM65x SoCs
will be covered in a subsequent patch.

Signed-off-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Roger Quadros <rogerq@ti.com>

remoteproc: Extend rproc_da_to_va() API with a flags parameter

The rproc_da_to_va() API is currently used to perform any device
to kernel address translations to meet the different needs of the
remoteproc core/platform drivers (eg: loading). The function also
invokes the da_to_va ops, if present, to allow the remoteproc
platform drivers to provide address translation. However, not all
platform implementations have linear address spaces, and may need
an additional parameter to be able to perform proper translations.

The rproc_da_to_va() API and the rproc .da_to_va ops have therefore
been expanded to take in an additional flags field enabling some
remoteproc implementations (like the TI PRUSS remoteproc driver)
to use these flags. Also, define some semantics for this flags
argument as this can vary from one implementation to another. A
new flags type is encoded into the upper 16 bits along side the
actual value in the lower 16-bits for the flags argument, to
allow different individual implementations to have better
flexibility in interpreting the flags as per their needs.

Also, update the various remoteproc implementations that use the
.da_to_va() ops for the new signature.

Signed-off-by: Suman Anna <s-anna@ti.com>

remoteproc: move rproc_da_to_va declaration to remoteproc.h

The rproc_da_to_va() API is an exported function, so move its
declaration from the remoteproc local remoteproc_internal.h
to the public remoteproc.h file.

This will allow drivers outside of the remoteproc folder to be
able to use this API.

Signed-off-by: Suman Anna <s-anna@ti.com>

remoteproc: Add support to handle device specific resource types

The remoteproc framework handles a fixed set of resource table entries
today. To make it scalable across multiple platforms, it makes sense
for the framework to provide a way for the device specific implementation
to define and handle vendor specific resource types. These resource types
would be very specific to an implementation instance that it does not
make sense for the framework to handle it. There can be two types of
such resources depending on whether they need to be handled prior to
the loading of the firmware segments or after. A post-loading resource
type is typically needed because it references a loaded segment pointer
for conveying the resource information.

For instance, a remoteproc implementation might want timers information
embedded in the resource table so that the driver could parse the binary
and enable accordingly. Another example would be hwspinlocks that it
is using, to properly share system wide resources. A PRU post-loading
vendor resource handler for interrupts requires the PRU event - interrupt
channel information to be loaded into device memory.

This patch adds a function pointer to the list of rproc_ops for the
driver implementation to handle such custom vendor resources, and
reuses the same handler between pre-loading and post-loading resource
types, with the sub-types in the implementation handling the processing
of those resource types.

Signed-off-by: Suman Anna <s-anna@ti.com>

remoteproc: Fix unbalanced boot with sysfs for no auto-boot rprocs

The remoteproc core performs automatic boot and shutdown of a remote
processor during rproc_add() and rproc_del() for remote processors
supporting 'auto-boot'. The remoteproc devices not using 'auto-boot'
require either a remoteproc client driver or a userspace client to
use the sysfs 'state' variable to perform the boot and shutdown. The
in-kernel client drivers hold the corresponding remoteproc driver
module's reference count when they acquire a rproc handle through
the rproc_get_by_phandle() API, but there is no such support for
userspace applications performing the boot through sysfs interface.

The shutdown of a remoteproc upon removing a remoteproc platform
driver is automatic only with 'auto-boot' and this can cause a
remoteproc with no auto-boot to stay powered on and never freed
up if booted using the sysfs interface without a matching stop,
and when the remoteproc driver module is removed or unbound from
the device. This will result in a memory leak as well as the
corresponding remoteproc ida being never deallocated. Fix this
by holding a module reference count for the remoteproc's driver
during a sysfs 'start' and releasing it during the sysfs 'stop'
operation.

Signed-off-by: Suman Anna <s-anna@ti.com>

remoteproc: Add a rproc_set_firmware() API

A new API, rproc_set_firmware() is added to allow the remoteproc platform
drivers and remoteproc client drivers to be able to configure a custom
firmware name that is different from the default name used during
remoteproc registration. This function is being introduced to provide
a kernel-level equivalent of the current sysfs interface to remoteproc
client drivers, and can only change firmwares when the remoteproc is
offline. This allows some remoteproc drivers to choose different firmwares
at runtime based on the functionality the remote processor is providing.
The TI PRU Ethernet driver will be an example of such usage as it
requires to use different firmwares for different supported protocols.

Also, update the firmware_store() function used by the sysfs interface
to reuse this function to avoid code duplication.

Signed-off-by: Suman Anna <s-anna@ti.com>

remoteproc: Add missing kernel-doc comment for auto-boot

The commit ddf711872c9d ("remoteproc: Introduce auto-boot flag")
introduced the auto-boot flag but missed adding the corresponding
kernel-doc comment. Add the same.

Signed-off-by: Suman Anna <s-anna@ti.com>

clk: ti: am43xx: drop idlest polling from pruss clkctrl clock

The PRUSS modules on AM43xx SoCs have a hardreset line and are controlled
by a PRCM reset line. Any clkctrl enable/disable operations cannot be
checked for module enabled/disabled status independent of the reset
operation, and this causes some unwanted timeouts in the kernel and
unbalanced states for the PRUSS clocks. These details should be handled
by the driver integration code itself.

Add the CLKF_NO_IDLEST flag to the PRUSS clkctrl clock so that these
module status checks are skipped.

Signed-off-by: Tero Kristo <t-kristo@ti.com>
[s-anna@ti.com: revise patch description]
Signed-off-by: Suman Anna <s-anna@ti.com>

clk: ti: am33xx: drop idlest polling from pruss clkctrl clock

The PRUSS module on AM33xx SoCs has a hardreset line and is controlled
by a PRCM reset line. Any clkctrl enable/disable operations cannot be
checked for module enabled/disabled status independent of the reset
operation, and this causes some unwanted timeouts in the kernel and
unbalanced states for the PRUSS clocks. These details should be handled
by the driver integration code itself.

Add the CLKF_NO_IDLEST flag to the PRUSS clkctrl clock so that these
module status checks are skipped.

Signed-off-by: Tero Kristo <t-kristo@ti.com>
[s-anna@ti.com: revise patch description]
Signed-off-by: Suman Anna <s-anna@ti.com>

irqchip/irq-pruss-intc: Add API to trigger a PRU sysevent

The PRUSS INTC can generate an interrupt to various processor
subsystems on the SoC through a set of 64 possible PRU system
events. These system events can be used by PRU client drivers
or applications for event notifications/signalling between PRUs
and MPU or other processors. A new API, pruss_intc_trigger() is
provided to MPU-side PRU client drivers/applications to be able
to trigger an event/interrupt using IRQ numbers provided by the
PRUSS-INTC irqdomain chip.

Signed-off-by: Andrew F. Davis <afd@ti.com>
Signed-off-by: Suman Anna <s-anna@ti.com>

irqchip/irq-pruss-intc: Add a PRUSS irqchip driver for PRUSS interrupts

The Programmable Real-Time Unit Subsystem (PRUSS) contains an
interrupt controller (INTC) that can handle various system input
events and post interrupts back to the device-level initiators.
The INTC can support upto 64 input events with individual control
configuration and hardware prioritization. These events are mapped
onto 10 interrupt signals through two levels of many-to-one mapping
support. Different interrupt signals are routed to the individual
PRU cores or to the host CPU.

The PRUSS INTC platform driver manages this PRUSS interrupt
controller and implements an irqchip driver to provide a Linux
standard way for the PRU client users to enable/disable/ack/
re-trigger a PRUSS system event. The system events to interrupt
channels and host interrupts relies on the mapping configuration
provided through a firmware resource table for now. This will be
revisited and enhanced in the future for a better interface. The
mappings will currently be programmed during the boot/shutdown
of the PRU.

The PRUSS INTC module is reference counted during the interrupt
setup phase through the irqchip's irq_request_resources() and
irq_release_resources() ops. This restricts the module from being
removed as long as there are active interrupt users.

The driver currently supports the AM335x SoC, and support for other
TI SoCs will be added in subsequent patches.

Signed-off-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Andrew F. Davis <afd@ti.com>
Signed-off-by: Roger Quadros <rogerq@ti.com>

dt-bindings: irqchip: Add PRUSS interrupt controller bindings

The Programmable Real-Time Unit Subsystem (PRUSS) contains an
interrupt controller (INTC) that can handle various system input
events and post interrupts back to the device-level initiators.
The INTC can support upto 64 input events with individual control
configuration and hardware prioritization. These events are mapped
onto 10 interrupt signals through two levels of many-to-one mapping
support. Different interrupt signals are routed to the individual
PRU cores or to the host CPU.

Add the bindings document for this interrupt controller. The binding
currently covers the OMAP architecture SoCs - AM33xx, AM437x and AM57xx;
and a Keystone 2 architecture based 66AK2G SoC. The Davinci based
OMAPL138 SoCs and K3 architecture based AM65x SoCs will be covered
in a subsequent patch.

Signed-off-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Andrew F. Davis <afd@ti.com>
Signed-off-by: Roger Quadros <rogerq@ti.com>

soc: ti: pruss: Parse various syscon nodes and store their regmaps

The PRUSS device node currently uses three different syscon nodes for
CFG, IEP and MII_RT sub-modules. Parse these syscon nodes and store
their regmap handles to allow adding functions to program any register
within these sub-modules.

The MFD_SYSCON Kconfig option is also enabled whenever the PRUSS remoteproc
driver is enabled. The MFD_SYSCON is a boolean option, and the select
dependency option is chosen following the majority usage style within the
kernel, as well as to align with similar usage in couple of other
remoteproc drivers.

Signed-off-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Tero Kristo <t-kristo@ti.com>

soc: ti: pruss: Add a platform driver for PRUSS in TI SoCs

The PRUSS platform driver deals with the overall PRUSS and is
used for managing the subsystem level resources like various
memories. It is responsible for the creation and deletion of
the platform devices for the child PRU devices and other child
devices (Interrupt Controller or MDIO node or some syscon nodes)
so that they can be managed by specific platform drivers.

This design provides flexibility in representing the different
modules of PRUSS accordingly, and at the same time allowing the
PRUSS driver to add some instance specific configuration within
an SoC.

The driver currently supports the AM335x SoC, and support for
other TI SoCs will be added in subsequent patches.

Signed-off-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Andrew F. Davis <afd@ti.com>

soc: ti: pruss: Add pruss_soc_bus platform driver

The Programmable Real-Time Unit - Industrial Communication
Subsystem (PRU-ICSS) is present of various TI SoCs such as
AM335x or AM437x or the Keystone 66AK2G. Each SoC can have
one or more PRUSS instances that may or may not be identical.
For example, AM335x SoCs have a single PRUSS, while AM437x has
two PRUSS instances PRUSS1 and PRUSS0, with the PRUSS0 being
a cut-down version of the PRUSS1.

The PRUSS consists of dual 32-bit RISC cores called the
Programmable Real-Time Units (PRUs), some shared, data and
instruction memories, some internal peripheral modules, and
an interrupt controller. The programmable nature of the PRUs
provide flexibility to implement custom peripheral interfaces,
fast real-time responses, or specialized data handling.

The PRU-ICSS functionality is achieved through four different
modules, each implementing a platform driver addressing a
specific portion of the PRUSS. Some sub-modules of the PRU-ICSS
IP reuse some of the existing drivers (like davinci mdio driver
or the generic syscon driver). The pruss_soc_bus driver deals
with the SoC integration aspects of the PRUSS IP(s) and manages
the common clock, reset and interconnect configuration and
creates the child PRUSS devices. The second pruss driver is
responsible for the creation and deletion of various platform
devices for the child PRU device and other child devices. A third
driver manages the PRUSS interrupt controller and implements an
irqchip driver to provide a Linux standard way of interrupt
management to PRU clients. The fourth platform driver is a
remoteproc driver and performs the individual PRU RISC cores
management. This design provides flexibility in representing
the different modules of PRUSS accordingly.

The driver currently supports the AM335x SoC, and support for
other TI SoCs will be added in subsequent patches.

Signed-off-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Keerthy <j-keerthy@ti.com>
Signed-off-by: Roger Quadros <rogerq@ti.com>

soc: ti: pruss: Define platform data for PRUSS bus driver

The PRUSS can have a PRCM reset line associated with the IP on
some OMAP architecture based SoCs. The reset needs to be programmed
properly before accessing any of the internal registers in the PRUSS.
This functionality is achieved through the omap_device layer, which
is not exposed outside of mach-omap2 layer. Define a platform data
structure for PRUSS so that this API can be invoked through platform
data ops from the driver.

Signed-off-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Roger Quadros <rogerq@ti.com>

dt-bindings: soc: ti: Add TI PRUSS bindings

This patch adds the bindings for the Programmable Real-Time Unit
and Industrial Communication Subsystem (PRU-ICSS) present on various
TI SoCs. The IP is present on multiple TI SoC architecture families
including the OMAP architecture SoCs such as AM33xx, AM437x and
AM57xx; and on a Keystone 2 architecture based 66AK2G SoC. It is
also present on the Davinci based OMAPL138 SoCs and K3 architecture
based AM65x SoCs as well (not covered for now).

The IP has a number of sub-modules some of which have their own
devices. This binding covers only the top-level sub-system devices,
and some sub-modules like MDIO, MII_RT and IEP. The remaining
sub-modules bindings shall be defined in the respective driver
subsystem bindings folders. Couple of full examples have also
been added demonstrating the devices on AM335x and the unique
configuration on AM437x SoCs.

The binding status is also marked as unstable as the binding does
not cover all the sub-modules that are present within the PRU-ICSS.

Signed-off-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Roger Quadros <rogerq@ti.com>

remoteproc/keystone: add support for MPM userspace loader

The Keystone remoteproc driver performs the device management of
different DSP processor subsystems present on various Keystone 2
family of SoCs. The driver currently supports loading/booting using
the remoteproc core's 'auto-boot' feature and supports advanced
features like error recovery.

This patch enhances the Keystone remoteproc driver to add support
for a TI specific userspace based loading/booting mechanism called
the Multi Proc Manager (MPM) by exposing a character device interface
to userspace per device. A new module parameter 'use_rproc_core_loader'
is introduced to configure the driver for in-kernel auto-boot mode
or the MPM non auto-boot mode, with the default configured for MPM.
The standard platform driver's bind and unbind sysfs attributes are
suppressed for MPM-based stack so that the regular sysfs approach of
booting and shutting down a Keystone DSP remote processor does not
mess up the MPM-based state-machine by unbinding the device from the
driver even when it has open usage reference counts. The standard
remoteproc sysfs interfaces for changing 'state' and 'firmware'
conflict with the MPM state-machine and are denied using the
remoteproc generic 'deny_sysfs_ops' flag.  An exception notification
is also provided through an UIO device exposed by the keystone
remoteproc driver for now.

The MPM loading/booting mechanism uses the file operations exported
by the character device. The mmap interface is used for mapping device
memory into userspace for loading and the ioctl interfaces are used
for reset and remoteproc resource table configuration and triggering
the boot and shutdown of the DSPs.

The address and size of the various DSP internal RAM memories to
be used with the mmap interface are provided through two sysfs
files 'addr' and 'size' for each region, and are created under the
respective dspX misc device for each DSP remoteproc processor. These
files are created in their own directory for each region accessible
under the /sys/class/misc/dspX/ path, where X is the DSP number
(indexed from 0). The MPM also relies on another memory mapping
character device (/dev/dspmem) to support loading images into
external DDR memory and the Multicore Shared Memory (MSM). This
sysfs logic allows the userspace-based Multi Proc Manager (MPM)
stack to not rely on procfs-based DT parsing for looking up the
memories.

The MPM supports various kinds of firmware images - images with and
without resource tables, images that have a resource table but with
or without the virtio device resource entries. The loadable regions
include images just using internal DSP memories, or images using
portions of the MSM RAM and/or external DDR. The load/boot of images
with and without resource tables are supported using separate ioctl
operations. The KEYSTONE_RPROC_IOC_SET_STATE ioctl is used to boot
and shutdown remote processors for images with resource tables, and
the KEYSTONE_RPROC_IOC_DSP_RESET/BOOT ioctls for images without a
resource table. The boot address/entry point is published during the
corresponding ioctls that trigger a boot, and is stored in a local
variable in driver instance and later picked up by remoteproc core
driver through fw_ops.

This logic is created anew using an older code from Cyril Chemparathy
as a baseline.

Signed-off-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Sam Nelson <samnelson@ti.com>

remoteproc/keystone: Switch to SPDX license identifier

Use the appropriate SPDX license identifier in the keystone
remoteproc driver source file and drop the previous boilerplate
license text.

Signed-off-by: Suman Anna <s-anna@ti.com>

remoteproc: add infrastructure support to allow pre-loaded remoteprocs

The remoteproc infrastructure is enhanced to allow remoteproc drivers to
be able to connect to already loaded and/or booted remote processors. The
added infrastructure is designed to allow multiple different scenarios:
 - Support userspace driven loading, with the actual boot triggered
   through the kernel.
 - Support remote processors loaded and booted by bootloaders, with
   resource table either directly provided by the remoteproc driver or
   by remoteproc core by requesting the firmware and processing only
   the resource table.

Support for these features are provided through two new fields in the
rproc structure - 'skip_firmware_request' and 'skip_load'. These fields
are expected to be set to true as per the mode/need required by the
remoteproc drivers before a rproc_add() call. The remoteproc core skips
looking for firmware and/or loading any firmware segments using these two
state flags. The default behavior is unchanged.

The interface and implementation details for either of the above scenarios
is left to the individual remoteproc drivers. This design will be used
to achieve the following different usecases on TI SoCs:
 - Allow the TI Keystone remoteproc driver to support a userspace based
   loader. The remoteproc driver is expected to invoke rproc_boot() and
   rproc_shutdown() for triggering the boot and shutdown of the remote
   processor after the loading is completed and the resource table
   information is published to the remoteproc driver. The resource
   table is processed in-line during the rproc_boot() invocation.
 - Allow the K3 R5F remoteproc driver to be invoked in an IPC-only mode
   (No load, boot or error recovery functionality, but only establish
   IPC mechanism). The driver relies on still using the regular state
   machine flow for creating the virtio devices. The rproc .start() and
   .stop() ops are not bypassed, and the actual boot bypass is implemented
   within the driver.

Signed-off-by: Suman Anna <s-anna@ti.com>

TEMP: ARM: dts: keystone-k2g-ice: Add a memory carveout for MPM usecases

A reserved memory carveout node with the appropriate compatible property
is added on the K2G ICE board so that it can be reserved specifically to
be used by the Keystone Multi Proc Manager (MPM) stack for loading various
firmware images onto the DSPs directly from userspace.

A memory region of size 40 MB is currently reserved at address
0x81d000000 (aliased at 0x9d000000). The memory is chosen to be
adjacent to the DSP CMA memory pool so that the DSP Memory Protection
and Address Extension (MPAX) module can be configured efficiently.
This memory will not be mapped into the kernel space.

This address and size are aligned with the values used on the
K2G EVM board so that same firmwares can be run on both the K2G
boards. Note that these values are different from those used on
the other K2HK/K2L/K2E EVM boards.

Signed-off-by: Suman Anna <s-anna@ti.com>

TEMP: ARM: dts: keystone-k2g-evm: Add a memory carveout for MPM usecases

A reserved memory carveout node with the appropriate compatible property
is added on the K2G EVM board so that it can be reserved specifically to
be used by the Keystone Multi Proc Manager (MPM) stack for loading various
firmware images onto the DSPs directly from userspace.

A memory region of size 40 MB is currently reserved at address
0x81d000000 (aliased at 0x9d000000). The memory is chosen to be
adjacent to the DSP CMA memory pool so that the DSP Memory Protection
and Address Extension (MPAX) module can be configured efficiently.
This memory will not be mapped into the kernel space.

Note that this carveout is smaller and at a different address in
comparision to those used on K2HK/K2L/K2E EVMs. This is done to
align with the usage on K2G ICE board which has a smaller DDR memory
footprint, and thereby allow same firmwares to be run on both the
K2G boards.

Signed-off-by: Suman Anna <s-anna@ti.com>

TEMP: ARM: dts: keystone-k2e-evm: Add a memory carveout for MPM usecases

A reserved memory carveout node with the appropriate compatible property
is added on the K2E EVM board so that it can be reserved specifically to
be used by the Keystone Multi Proc Manager (MPM) stack for loading various
firmware images onto the DSPs directly from userspace.

A memory region of size 256 MB is currently reserved at address
0x820000000 (aliased at 0xa0000000). The memory is chosen to be
adjacent to the DSP CMA memory pool so that the DSP Memory Protection
and Address Extension (MPAX) module can be configured efficiently.
This memory will not be mapped into the kernel space.

Signed-off-by: Suman Anna <s-anna@ti.com>

TEMP: ARM: dts: keystone-k2l-evm: Add a memory carveout for MPM usecases

A reserved memory carveout node with the appropriate compatible property
is added on the K2L EVM board so that it can be reserved specifically to
be used by the Keystone Multi Proc Manager (MPM) stack for loading various
firmware images onto the DSPs directly from userspace.

A memory region of size 256 MB is currently reserved at address
0x820000000 (aliased at 0xa0000000). The memory is chosen to be
adjacent to the DSP CMA memory pool so that the DSP Memory Protection
and Address Extension (MPAX) module can be configured efficiently.
This memory will not be mapped into the kernel space.

Signed-off-by: Suman Anna <s-anna@ti.com>

TEMP: ARM: dts: keystone-k2hk-evm: Add a memory carveout for MPM usecases

A reserved memory carveout node with the appropriate compatible property
is added on the K2HK EVM board so that it can be reserved specifically to
be used by the Keystone Multi Proc Manager (MPM) stack for loading various
firmware images onto the DSPs directly from userspace.

A memory region of size 256 MB is currently reserved at address
0x820000000 (aliased at 0xa0000000). The memory is chosen to be
adjacent to the DSP CMA memory pool so that the DSP Memory Protection
and Address Extension (MPAX) module can be configured efficiently.
This memory will not be mapped into the kernel space.

Signed-off-by: Suman Anna <s-anna@ti.com>

ARM: dts: keystone-k2g: Reserve SRAM for MPM

Add a child SRAM node to reserve a portion of the Multicore Shared
Memory (MSM) RAM for use by the keystone-dsp-mem driver on 66AK2G
SoCs. This memory will be exposed to the userspace for meeting the
needs of the Multi Proc Manager (MPM) stack.

A preliminary size of 512 KB is reserved to begin with and can be
adjusted as per need.

Signed-off-by: Suman Anna <s-anna@ti.com>

ARM: dts: keystone-k2e: Reserve SRAM for MPM

Add a child SRAM node to reserve a portion of the Multicore Shared
Memory (MSM) RAM for use by the keystone-dsp-mem driver on 66AK2E
SoCs. This memory will be exposed to the userspace for meeting the
needs of the Multi Proc Manager (MPM) stack.

A preliminary size of 512 KB is reserved to begin with and can be
adjusted as per need.

Signed-off-by: Suman Anna <s-anna@ti.com>

ARM: dts: keystone-k2l: Reserve SRAM for MPM

Add a child SRAM node to reserve a portion of the Multicore Shared
Memory (MSM) RAM for use by the keystone-dsp-mem driver on 66AK2L
SoCs. This memory will be exposed to the userspace for meeting the
needs of the Multi Proc Manager (MPM) stack.

A preliminary size of 512 KB is reserved to begin with and can be
adjusted as per need.

Signed-off-by: Suman Anna <s-anna@ti.com>

ARM: dts: keystone-k2hk: Reserve SRAM for MPM

Add a child SRAM node to reserve a portion of the Multicore Shared
Memory (MSM) RAM for use by the keystone-dsp-mem driver on 66AK2H
SoCs. This memory will be exposed to the userspace for meeting the
needs of the Multi Proc Manager (MPM) stack.

A preliminary size of 512 KB is reserved to begin with and can be
adjusted as per need.

Signed-off-by: Suman Anna <s-anna@ti.com>

TEMP: soc: ti: add the keystone_dsp_mem driver

A very simple keystone_dsp_mem driver has been added for TI's Keystone 2
family of SoCs. This driver provides a user-space mapping interface for
some On-chip Multicore Shared Memory (MSM) SRAM Memory regions and/or
some portions of the platform board's DDR memory. This is done to enable
the Multi Proc Manager (MPM) based loader for loading different firmware
images into both DDR and On-chip SRAM in userspace for the various C66
DSP co-processors on the SoC.

The different MSM RAM regions to be exposed to userspace through this
driver need to be defined as 'reserved' child nodes under the parent
MSM RAM mmio-sram node with a specific compatible "ti,keystone-dsp-msm-ram"
property. Each of the DDR regions to be exposed should also be defined
using reserved-memory child nodes with the "no-map" property set and
using a specific compatible "ti,keystone-dsp-mpm-pool" property. Multiple
discrete regions of either SRAM and/or DDR can be exposed to userspace
by defining similar DTS nodes.

The keystone-dsp-mem driver provides sysfs entries to allow userspace
to read the address and size of supported DDR and Multicore Shared Memory
(MSM) RAM memories that are exposed to userspace. This sysfs logic provides
an agnostic way of presenting the supported memories irrespective of how
the driver acquires the memories. The 32-bit DDR alias addresses are used
while presenting the DDR regions through sysfs as per current MPM usage.
Each supported memory region is represented by its own directory, and are
created under the dspmem misc device. The directories can be accessed
under the /sys/class/misc/dspmem/ path.

The mapping interfaces are provided through a miscdevice and exposed
using the character device /dev/dspmem (matching the usage within MPM).
The mmap logic itself is based on a mechanism used within the UIO
framework.

Signed-off-by: Suman Anna <s-anna@ti.com>

TEMP: dt-bindings: soc: ti: Add Keystone DSP Memory mapping binding

Add the device tree binding document for the userspace memory mapping
driver on TI Keystone SoCs. This driver is used to expose either some
portions of the DDR and/or some portions of the On-chip RAM controlled
by the Multicore Shared Memory Controller (MSMC) to userspace for the
Multi Proc Manager (MPM) stack.

Signed-off-by: Suman Anna <s-anna@ti.com>

ARM: dts: da850: Add alias for DSP node

Add alias for the lone DSP remoteproc processor node present
on the OMAP-L13x/DA8xx SoCs. The alias uses the stem "rproc".
The alias is added to assign a fixed remoteproc id to the DSP
processor.

Signed-off-by: Suman Anna <s-anna@ti.com>

remoteproc/davinci: Add a trace to print missing ids

The remoteproc fixed ids for Davinci remoteprocs are required
by some rpmsg client drivers to identify a remote processor in
a fixed manner to userspace. Add a trace during probe to warn
developers if this unique id (alias id for DT devices and platform
device id for non-DT devices) is not defined for the DSP remoteproc
device.

Signed-off-by: Suman Anna <s-anna@ti.com>

remoteproc/davinci: Switch a debug trace statement to use %pK

Modify a debug trace statement to use %pK instead of %p for printing
the kernel virtual address for the mapped DSP internal memory regions.
The latter always prints a hashed address, and switching to %pK allows
the actual mapped address to be printed under proper conditions (by
writing a proper value to /proc/sys/kernel/kptr_restrict). The default
behavior is unchanged.

Signed-off-by: Suman Anna <s-anna@ti.com>

remoteproc/davinci: Use %zx for formating size_t

da8xx_rproc_mem size is of type size_t, so use %zx to format the debug
print of it to avoid a compile warning.

Acked-by: Suman Anna <s-anna@ti.com>
Reviewed-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
[s-anna@ti.com: cherry-pick commit '1e28dbbeced6' from v4.20]
Signed-off-by: Suman Anna <s-anna@ti.com>

remoteproc/wkup_m3: set deny_sysfs_ops flag

The Wakeup M3 remote processor is controlled by the wkup_m3_ipc
client driver, so set the newly introduced 'deny_sysfs_ops' flag
to not allow any overriding of the remoteproc firmware or state
from userspace.

Signed-off-by: Suman Anna <s-anna@ti.com>

remoteproc: introduce deny_sysfs_ops flag

The remoteproc framework provides sysfs interfaces for changing
the firmware name and for starting/stopping a remote processor
through the sysfs files 'state' and 'firmware'. These interfaces
are currently allowed irrespective of how the remoteprocs were
booted (like remoteproc self auto-boot, remoteproc client-driven
boot etc). These interfaces can adversely affect a remoteproc
and its clients especially when a remoteproc is being controlled
by a remoteproc client driver(s). Also, not all remoteproc
drivers may want to support the sysfs interfaces by default.

Add support to deny the sysfs state/firmware change by introducing
a state flag 'deny_sysfs_ops' that the individual remoteproc drivers
can set based on their usage needs. The default behavior is to
allow the sysfs operations as before.

Signed-off-by: Suman Anna <s-anna@ti.com>

rpmsg: add a description field

Add a new description field to the rpmsg bus infrastructure
that can be passed onto the rpmsg client drivers for additional
information. The current rpmsg bus client drivers need to have
a fixed id_table for proper matching, this new field can allow
flexibility for the client drivers (eg: like creating unique
cdevs).

The description field is published through an enhanced name
service announcement message structure. The name service
message processing logic is updated to maintain backward
compatibility with the previous message structure.

Based on an initial patch from Ohad Ben-Cohen.

Signed-off-by: Ohad Ben-Cohen <ohad@wizery.com>
[s-anna@ti.com: forward port, add sysfs documentation, fixup qcom drivers]
Signed-off-by: Suman Anna <s-anna@ti.com>
[t-kristo@ti.com: reworked to support both rpmsg with/without the desc field]
Signed-off-by: Tero Kristo <t-kristo@ti.com>

samples/rpmsg: Introduce a module parameter for message count

The current rpmsg_client_sample uses a fixed number of messages to
be sent to each instance. This is currently set at 100. Introduce
an optional module parameter 'count' so that the number of messages
to be exchanged can be made flexible.

Signed-off-by: Suman Anna <s-anna@ti.com>

remoteproc: add an api to do pa to da conversion

Added an api to provide memory translation from a
physical address to a device virtual address.
Since, carveouts and mappings are stored separately,
we need to traverse both lists.

Also stored the physical addresses for RSC_DEVMEM entries
to enable pa to da conversion for dev mem address spaces too.

Signed-off-by: Subramaniam Chanderashekarapuram <subramaniam.ca@ti.com>
Signed-off-by: Fernando Guzman Lugo <fernando.lugo@ti.com>
Signed-off-by: Suman Anna <s-anna@ti.com>

remoteproc: add api for retrieving a rproc unique id

A new api, rproc_get_id(), is added to allow remoteproc/rpmsg clients
to be able to retrieve a fixed unique id associated with a rproc
device. Each of the rprocs is given an ida index as well, but this
is dynamic depending on the order rproc_alloc is called (probe order),
and also depends on what remote processor devices are instantiated.
This unique id needs to be supported for both DT and non-DT devices.
The platform device id or the remoteproc alias id are therefore
chosen for non-DT and DT devices respectively, with the assumption
that the remoteproc devices are created with known platform device
ids or alias ids in DT.

Signed-off-by: Suman Anna <s-anna@ti.com>

remoteproc: add name in rproc_mem_entry struct

[ Upstream commit 3265230c5b05fe919291d09e266a8aedc85ebad0 ]

Add name field in struct rproc_mem_entry.
This new field will be used to match memory area
requested in resource table with pre-registered carveout.

Signed-off-by: Loic Pallardy <loic.pallardy@st.com>
Acked-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
[s-anna@ti.com: cherry-pick commit '3265230c5b05' from v4.20]
Signed-off-by: Suman Anna <s-anna@ti.com>

remoteproc: Check for NULL firmwares in sysfs interface

[ Upstream commit faeadbb64094757150a8c2a3175ca418dbdd472c ]

The remoteproc framework provides a sysfs file 'firmware'
for modifying the firmware image name from userspace. Add
an additional check to ensure NULL firmwares are errored
out right away, rather than getting a delayed error while
requesting a firmware during the start of a remoteproc
later on.

Tested-by: Arnaud Pouliquen <arnaud.pouliquen@st.com>
Signed-off-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
[s-anna@ti.com: cherry-pick commit 'faeadbb64094' from v4.20]

rpmsg: char: Migrate to iter versions of read and write

[ Upstream commit ccf45b18ce89f598c69a0c945ced1635013fc0b1 ]

In order to be able to use the aio interface for writing to a rpmsg_char
the write_iter function must be implemented, so migrate to iter version
for read and write functions.

Regular read and write uses the iter methods if present and is as such
unaffected.

Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
[s-anna@ti.com: cherry-pick commit 'ccf45b18ce89' from v4.20]
Signed-off-by: Suman Anna <s-anna@ti.com>

Linux 4.19

MAINTAINERS: Add an entry for the code of conduct

As I introduced these files, I'm willing to be the maintainer of them as
well.

Acked-by: Chris Mason <clm@fb.com>
Acked-by: Olof Johansson <olof@lixom.net>
Acked-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
Acked-by: Theodore Ts'o <tytso@mit.edu>
Acked-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Code of Conduct: Change the contact email address

The contact point for the kernel's Code of Conduct should now be the
Code of Conduct Committee, not the full TAB.  Change the email address
in the file to properly reflect this.

Acked-by: Chris Mason <clm@fb.com>
Acked-by: Olof Johansson <olof@lixom.net>
Acked-by: Theodore Ts'o <tytso@mit.edu>
Acked-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Code of Conduct Interpretation: Put in the proper URL for the committee

There was a blank <URL> reference for how to find the Code of Conduct
Committee.  Fix that up by pointing it to the correct kernel.org website
page location.

Acked-by: Chris Mason <clm@fb.com>
Acked-by: Olof Johansson <olof@lixom.net>
Acked-by: Theodore Ts'o <tytso@mit.edu>
Acked-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Code of Conduct: Provide links between the two documents

Create a link between the Code of Conduct and the Code of Conduct
Interpretation so that people can see that they are related.

Acked-by: Chris Mason <clm@fb.com>
Acked-by: Olof Johansson <olof@lixom.net>
Acked-by: Theodore Ts'o <tytso@mit.edu>
Acked-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Code of Conduct Interpretation: Properly reference the TAB correctly

We use the term "TAB" before defining it later in the document.  Fix
that up by defining it at the first location.

Reported-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Acked-by: Chris Mason <clm@fb.com>
Acked-by: Olof Johansson <olof@lixom.net>
Acked-by: Theodore Ts'o <tytso@mit.edu>
Acked-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Code of Conduct Interpretation: Add document explaining how the Code of Conduct is to be interpreted

The Contributor Covenant Code of Conduct is a general document meant to
provide a set of rules for almost any open source community.  Every
open-source community is unique and the Linux kernel is no exception.
Because of this, this document describes how we in the Linux kernel
community will interpret it.  We also do not expect this interpretation
to be static over time, and will adjust it as needed.

This document was created with the input and feedback of the TAB as well
as many current kernel maintainers.

Co-Developed-by: Thomas Gleixner <tglx@linutronix.de>
Co-Developed-by: Olof Johansson <olof@lixom.net>
Acked-by: Alex Deucher <alexander.deucher@amd.com>
Acked-by: Alexei Starovoitov <ast@kernel.org>
Acked-by: Amir Goldstein <amir73il@gmail.com>
Acked-by: Andrew Morton <akpm@linux-foundation.org>
Acked-by: Andy Lutomirski <luto@kernel.org>
Acked-by: Anna-Maria Gleixner <anna-maria@linutronix.de>
Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Acked-by: Boris Brezillon <boris.brezillon@bootlin.com>
Acked-by: Borislav Petkov <bp@kernel.org>
Acked-by: Chris Mason <clm@fb.com>
Acked-by: Christian Lütke-Stetzkamp <christian@lkamp.de>
Acked-by: Colin Ian King <colin.king@canonical.com>
Acked-by: Dan Carpenter <dan.carpenter@oracle.com>
Acked-by: Dan Williams <dan.j.williams@intel.com>
Acked-by: Daniel Borkmann <daniel@iogearbox.net>
Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Acked-by: Dave Airlie <airlied@redhat.com>
Acked-by: Dave Hansen <dave.hansen@linux.intel.com>
Acked-by: David Ahern <dsa@cumulusnetworks.com>
Acked-by: David Sterba <kdave@kernel.org>
Acked-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Acked-by: Dominik Brodowski <linux@dominikbrodowski.de>
Acked-by: Eric Dumazet <eric.dumazet@gmail.com>
Acked-by: Felipe Balbi <balbi@kernel.org>
Acked-by: Felix Kuehling <Felix.Kuehling@amd.com>
Acked-by: Florian Fainelli <f.fainelli@gmail.com>
Acked-by: Geert Uytterhoeven <geert@linux-m68k.org>
Acked-by: Grant Likely <grant.likely@secretlab.ca>
Acked-by: Gregory CLEMENT <gregory.clement@bootlin.com>
Acked-by: Guenter Roeck <linux@roeck-us.net>
Acked-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
Acked-by: Hans Verkuil <hverkuil@xs4all.nl>
Acked-by: Hans de Goede <j.w.r.degoede@gmail.com>
Acked-by: Harry Wentland <harry.wentland@amd.com>
Acked-by: Heiko Stuebner <heiko@sntech.de>
Acked-by: Ingo Molnar <mingo@kernel.org>
Acked-by: Jaegeuk Kim <jaegeuk@kernel.org>
Acked-by: James Smart <james.smart@broadcom.com>
Acked-by: James Smart <jsmart2021@gmail.com>
Acked-by: Jan Kara <jack@ucw.cz>
Acked-by: Jani Nikula <jani.nikula@intel.com>
Acked-by: Jason A. Donenfeld <Jason@zx2c4.com>
Acked-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Acked-by: Jens Axboe <axboe@kernel.dk>
Acked-by: Jessica Yu <jeyu@kernel.org>
Acked-by: Jia-Ju Bai <baijiaju1990@gmail.com>
Acked-by: Jiri Kosina <jikos@kernel.org>
Acked-by: Jiri Olsa <jolsa@redhat.com>
Acked-by: Joerg Roedel <joro@8bytes.org>
Acked-by: Johan Hovold <johan@kernel.org>
Acked-by: Johannes Thumshirn <jth@kernel.org>
Acked-by: Jonathan Corbet <corbet@lwn.net>
Acked-by: Julia Lawall <julia.lawall@lip6.fr>
Acked-by: Kees Cook <keescook@chromium.org>
Acked-by: Kirill Tkhai <ktkhai@virtuozzo.com>
Acked-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Acked-by: Lina Iyer <ilina@codeaurora.org>
Acked-by: Linus Torvalds <torvalds@linux-foundation.org>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Acked-by: Mark Brown <broonie@kernel.org>
Acked-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Acked-by: Masami Hiramatsu <mhiramat@kernel.org>
Acked-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Acked-by: Matias Bjørling <mb@lightnvm.io>
Acked-by: Mauro Carvalho Chehab <mchehab@kernel.org>
Acked-by: Maxime Ripard <maxime.ripard@bootlin.com>
Acked-by: Michael Ellerman <mpe@ellerman.id.au>
Acked-by: Mike Rapoport <rppt@linux.ibm.com>
Acked-by: Mimi Zohar <zohar@linux.ibm.com>
Acked-by: Miquel Raynal <miquel.raynal@bootlin.com>
Acked-by: Mishi Choudhary <mishi@linux.com>
Acked-by: Nikolay Borisov <n.borisov.lkml@gmail.com>
Acked-by: Oded Gabbay <oded.gabbay@gmail.com>
Acked-by: Palmer Dabbelt <palmer@dabbelt.com>
Acked-by: Paul E. McKenney <paulmck@linux.ibm.com>
Acked-by: Peter Zijlstra <peterz@infradead.org>
Acked-by: Rafael J. Wysocki <rafael@kernel.org>
Acked-by: Richard Weinberger <richard@nod.at>
Acked-by: Rik van Riel <riel@surriel.com>
Acked-by: Rob Clark <robdclark@gmail.com>
Acked-by: Rob Herring <robh@kernel.org>
Acked-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Acked-by: Sean Paul <sean@poorly.run>
Acked-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Acked-by: Sebastian Reichel <sre@kernel.org>
Acked-by: Sergio Paracuellos <sergio.paracuellos@gmail.com>
Acked-by: Shawn Guo <shawnguo@kernel.org>
Acked-by: Shuah Khan <shuah@kernel.org>
Acked-by: Simon Horman <horms@verge.net.au>
Acked-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
Acked-by: Stephen Hemminger <stephen@networkplumber.org>
Acked-by: Takashi Iwai <tiwai@kernel.org>
Acked-by: Tejun Heo <tj@kernel.org>
Acked-by: Theodore Ts'o <tytso@mit.edu>
Acked-by: Thierry Reding <thierry.reding@gmail.com>
Acked-by: Todd Poynor <toddpoynor@google.com>
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
Acked-by: Wei Yongjun <weiyongjun1@huawei.com>
Acked-by: YueHaibing <yuehaibing@huawei.com>
Reviewed-by: Steven Rostedt <rostedt@goodmis.org>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Olof Johansson <olof@lixom.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Code of conduct: Fix wording around maintainers enforcing the code of conduct

As it was originally worded, this paragraph requires maintainers to
enforce the code of conduct, or face potential repercussions.  It sends
the wrong message, when really we just want maintainers to be part of
the solution and not violate the code of conduct themselves.

Removing it doesn't limit our ability to enforce the code of conduct,
and we can still encourage maintainers to help maintain high standards
for the level of discourse in their subsystem.

Signed-off-by: Chris Mason <clm@fb.com>
Acked-by: Alex Deucher <alexander.deucher@amd.com>
Acked-by: Amir Goldstein <amir73il@gmail.com>
Acked-by: Andrew Morton <akpm@linux-foundation.org>
Acked-by: Anna-Maria Gleixner <anna-maria@linutronix.de>
Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Acked-by: Boris Brezillon <boris.brezillon@bootlin.com>
Acked-by: Borislav Petkov <bp@kernel.org>
Acked-by: Christian Lütke-Stetzkamp <christian@lkamp.de>
Acked-by: Christoph Hellwig <hch@lst.de>
Acked-by: Colin Ian King <colin.king@canonical.com>
Acked-by: Dan Carpenter <dan.carpenter@oracle.com>
Acked-by: Dan Williams <dan.j.williams@intel.com>
Acked-by: Daniel Borkmann <daniel@iogearbox.net>
Acked-by: Dave Airlie <airlied@redhat.com>
Acked-by: Dave Hansen <dave.hansen@linux.intel.com>
Acked-by: David Ahern <dsa@cumulusnetworks.com>
Acked-by: David Sterba <kdave@kernel.org>
Acked-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Acked-by: Dominik Brodowski <linux@dominikbrodowski.de>
Acked-by: Eric Dumazet <eric.dumazet@gmail.com>
Acked-by: Felipe Balbi <balbi@kernel.org>
Acked-by: Felix Kuehling <Felix.Kuehling@amd.com>
Acked-by: Florian Fainelli <f.fainelli@gmail.com>
Acked-by: Florian Westphal <fw@strlen.de>
Acked-by: Geert Uytterhoeven <geert@linux-m68k.org>
Acked-by: Grant Likely <grant.likely@secretlab.ca>
Acked-by: Gregory CLEMENT <gregory.clement@bootlin.com>
Acked-by: Guenter Roeck <linux@roeck-us.net>
Acked-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
Acked-by: Hans Verkuil <hverkuil@xs4all.nl>
Acked-by: Hans de Goede <j.w.r.degoede@gmail.com>
Acked-by: Harry Wentland <harry.wentland@amd.com>
Acked-by: Heiko Stuebner <heiko@sntech.de>
Acked-by: Ingo Molnar <mingo@kernel.org>
Acked-by: Jaegeuk Kim <jaegeuk@kernel.org>
Acked-by: James Smart <james.smart@broadcom.com>
Acked-by: James Smart <jsmart2021@gmail.com>
Acked-by: Jan Kara <jack@ucw.cz>
Acked-by: Jason A. Donenfeld <Jason@zx2c4.com>
Acked-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Acked-by: Jens Axboe <axboe@kernel.dk>
Acked-by: Jessica Yu <jeyu@kernel.org>
Acked-by: Jia-Ju Bai <baijiaju1990@gmail.com>
Acked-by: Jiri Kosina <jikos@kernel.org>
Acked-by: Jiri Olsa <jolsa@redhat.com>
Acked-by: Joerg Roedel <joro@8bytes.org>
Acked-by: Johan Hovold <johan@kernel.org>
Acked-by: Johannes Thumshirn <jth@kernel.org>
Acked-by: Jonathan Corbet <corbet@lwn.net>
Acked-by: Julia Lawall <julia.lawall@lip6.fr>
Acked-by: Kees Cook <keescook@chromium.org>
Acked-by: Kirill Tkhai <ktkhai@virtuozzo.com>
Acked-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Acked-by: Lina Iyer <ilina@codeaurora.org>
Acked-by: Linus Torvalds <torvalds@linux-foundation.org>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Acked-by: Mark Brown <broonie@kernel.org>
Acked-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Acked-by: Masami Hiramatsu <mhiramat@kernel.org>
Acked-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Acked-by: Matias Bjørling <mb@lightnvm.io>
Acked-by: Maxime Ripard <maxime.ripard@bootlin.com>
Acked-by: Michael Ellerman <mpe@ellerman.id.au>
Acked-by: Mike Rapoport <rppt@linux.ibm.com>
Acked-by: Mimi Zohar <zohar@linux.ibm.com>
Acked-by: Miquel Raynal <miquel.raynal@bootlin.com>
Acked-by: Nikolay Borisov <n.borisov.lkml@gmail.com>
Acked-by: Oded Gabbay <oded.gabbay@gmail.com>
Acked-by: Olof Johansson <olof@lixom.net>
Acked-by: Palmer Dabbelt <palmer@dabbelt.com>
Acked-by: Paul E. McKenney <paulmck@linux.ibm.com>
Acked-by: Peter Zijlstra <peterz@infradead.org>
Acked-by: Rafael J. Wysocki <rafael@kernel.org>
Acked-by: Richard Weinberger <richard@nod.at>
Acked-by: Rik van Riel <riel@surriel.com>
Acked-by: Rob Clark <robdclark@gmail.com>
Acked-by: Rob Herring <robh@kernel.org>
Acked-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Acked-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Acked-by: Sebastian Reichel <sre@kernel.org>
Acked-by: Sergio Paracuellos <sergio.paracuellos@gmail.com>
Acked-by: Shawn Guo <shawnguo@kernel.org>
Acked-by: Shuah Khan <shuah@kernel.org>
Acked-by: Simon Horman <horms@verge.net.au>
Acked-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
Acked-by: Stephen Hemminger <stephen@networkplumber.org>
Acked-by: Takashi Iwai <tiwai@kernel.org>
Acked-by: Tejun Heo <tj@kernel.org>
Acked-by: Theodore Ts'o <tytso@mit.edu>
Acked-by: Thierry Reding <thierry.reding@gmail.com>
Acked-by: Thomas Gleixner <tglx@linutronix.de>
Acked-by: Tim Bird <tim.bird@sony.com>
Acked-by: Todd Poynor <toddpoynor@google.com>
Acked-by: Trond Myklebust <trond.myklebust@hammerspace.com>
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
Acked-by: Wei Yongjun <weiyongjun1@huawei.com>
Acked-by: YueHaibing <yuehaibing@huawei.com>
Reviewed-by: Mauro Carvalho Chehab <mchehab@kernel.org>
Reviewed-by: Steven Rostedt <rostedt@goodmis.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Merge branch 'i2c/for-current' of git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux

Wolfram writes:
  "i2c for 4.19

   Another driver bugfix and MAINTAINERS addition from I2C."

* 'i2c/for-current' of git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux:
  i2c: rcar: cleanup DMA for all kinds of failure
  MAINTAINERS: Add entry for Broadcom STB I2C controller