HACK: misc: Add dma-buf to physical address exporter

This is driver allows user-space to attach a DMA-BUF and
receive back its CPU physical address. This is a temporary
solution to allow CMEM like functionality from ION allocated
buffers. This is a hack and this will be removed when proper
solutions are implemented.

Signed-off-by: Andrew F. Davis <afd@ti.com>

HACK: dt-bindings: misc: Add ti,dma_buf_phys binding doc

Signed-off-by: Andrew F. Davis <afd@ti.com>

Merge branch 'connectivity-ti-linux-4.19.y' of git://git.ti.com/connectivity-integration-tree/connectivity-ti-linux-kernel into ti-linux-4.19.y

TI-Feature: connectivity
TI-Tree: git://git.ti.com/connectivity-integration-tree/connectivity-ti-linux-kernel.git
TI-Branch: connectivity-ti-linux-4.19.y

* 'connectivity-ti-linux-4.19.y' of git://git.ti.com/connectivity-integration-tree/connectivity-ti-linux-kernel:
  ARM: dts: am57xx-evm: Add wilink8 wlan support
  ARM: dts: dt-overlays: fixup dra71x-evm NAND support
  usb: dwc3: don't log probe deferrals; but do log other error codes
  arm64: dts: ti: k3-am654-pcie-usb2: Add USB host port
  PCI: endpoint: functions: use memcpy_fromio()/memcpy_toio()
  ARM: dts: am57xx-beagle-x15/am57xx-idk: Remove "gpios" for endpoint dt nodes
  ARM: dts: am571x-idk: Fix gpios property to have the correct gpio number
  ARM: dts: dra7: Add properties to enable PCIe x2 lane mode
  PCI: dra7xx: Enable x2 mode support for dra74x, dra76x and dra72x
  dt-bindings: PCI: dra7xx: Add properties to enable x2 lane in dra7
  dt-bindings: PCI: dra7xx: Add SoC specific compatible strings
  ARM: dts: beagle-x15-common: Model 5V0 regulator

Signed-off-by: Dan Murphy <dmurphy@ti.com>

ARM: dts: am57xx-evm: Add wilink8 wlan support

On am57xx-evm, MMC3 is used for connecting wilink8 module.
Add dt node for com_3v6 and vmmcwl_fixed requlators
connected to vmmc-supply and vqmmc-supply of MMC3 dt node.
Also add wlcore dt node as a sub-node of MMC3 dt node.

MMC3 has different IODelay values for ES1.1 and ES2.0.
In order to handle this, create am57xx-evm-reva3.dtso
which has IODelay values for ES2.0, keep ES1.1 IODelay
values in am57xx-evm.dtso and create am57xx-evm-common.dtso
to keep everything that is common to both revisions.

Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>

ARM: dts: dt-overlays: fixup dra71x-evm NAND support

commit c24bb977be0d ("ARM: dts: dt-overlays: Add Support for dra71-evm NAND")
left out the important part of adding a makefile target for building
device-tree blob with NAND overlay applied.

Fix it.

Reported-by: Denys Dmytriyenko <denys@ti.com>
Fixes: c24bb977be0d ("ARM: dts: dt-overlays: Add Support for dra71-evm NAND")
Signed-off-by: Sekhar Nori <nsekhar@ti.com>

usb: dwc3: don't log probe deferrals; but do log other error codes

commit 408d3ba006af57380fa48858b39f72fde6405031 upstream.

It's not very useful to repeat a bunch of probe deferral errors. And
it's also not very useful to log "failed" without telling the error
code.

Signed-off-by: Brian Norris <briannorris@chromium.org>
Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
Signed-off-by: Roger Quadros <rogerq@ti.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>

arm64: dts: ti: k3-am654-pcie-usb2: Add USB host port

This card has a USB 2.0 dual-role port. As the base board
already supports a 2.0 dual-role port we enable the
port on the SERDES card to be a host only port.

This will prevent user confusion as having 2 ports in
device mode often leads to confusion as to which port
is bound to the gadget function driver.

Signed-off-by: Roger Quadros <rogerq@ti.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>

PCI: endpoint: functions: use memcpy_fromio()/memcpy_toio()

Use the IO memcpy() functions when copying from/to IO memory.
These locations were found via sparse.

Signed-off-by: Wen Yang <wen.yang99@zte.com.cn>
Suggested-by: Kishon Vijay Abraham I <kishon@ti.com>
CC: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
CC: Bjorn Helgaas <bhelgaas@google.com>
CC: Gustavo Pimentel <gustavo.pimentel@synopsys.com>
CC: Niklas Cassel <niklas.cassel@axis.com>
CC: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
CC: Cyrille Pitchen <cyrille.pitchen@free-electrons.com>
CC: linux-pci@vger.kernel.org
CC: linux-kernel@vger.kernel.org
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>

ARM: dts: am57xx-beagle-x15/am57xx-idk: Remove "gpios" for endpoint dt nodes

PERST# line in the PCIE connector is driver by the host mode and not
EP mode. The gpios property here is used for driving the PERST# line.
Remove gpios property from all endpoint device tree nodes.

Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>

ARM: dts: am571x-idk: Fix gpios property to have the correct gpio number

commit d23f3839fe97d8dce03d ("ARM: dts: DRA7: Add pcie1 dt node for
EP mode") while adding the dt node for EP mode for DRA7 platform,
added rc node for am571x-idk and populated gpios property with
"gpio3 23". However the GPIO_PCIE_SWRST line is actually connected
to "gpio5 18". Fix it here. (The patch adding "gpio3 23" was tested
with another am57x board in EP mode which doesn't rely on reset from
host).

Fixes: d23f3839fe97d8dce03d ("ARM: dts: DRA7: Add pcie1 dt node for
EP mode")
Cc: stable <stable@vger.kernel.org> # 4.14+
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>

ARM: dts: dra7: Add properties to enable PCIe x2 lane mode

ti,syscon-lane-sel and ti,syscon-lane-conf properties specific to enable
PCIe x2 lane mode are added here.

Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>

PCI: dra7xx: Enable x2 mode support for dra74x, dra76x and dra72x

dra74x/dra76x and dra72x have separate compatible strings. Add support
for these compatible strings in pci-dra7xx driver to perform syscon
configurations required to get x2 mode working.

Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>

dt-bindings: PCI: dra7xx: Add properties to enable x2 lane in dra7

Add syscon properties required for configuring PCIe in x2 lane mode.

Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>

dt-bindings: PCI: dra7xx: Add SoC specific compatible strings

Add new compatible strings for dra74x SoC (also used by dra76x) and
dra72x. This can be used to perform SoC specific configuration
(like configuring PCIe in x2 lane mode).

Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
Acked-by: Rob Herring <robh@kernel.org>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>

ARM: dts: beagle-x15-common: Model 5V0 regulator

On am57xx-beagle-x15, 5V0 is connected to P16, P17, P18 and P19
connectors. On am57xx-evm, 5V0 regulator is used to get 3V6 regulator
which is connected to the COMQ port. Model 5V0 regulator here in order
for it to be used in am57xx-evm to model 3V6 regulator.

Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>

Merge branch 'connectivity-ti-linux-4.19.y' of git://git.ti.com/connectivity-integration-tree/connectivity-ti-linux-kernel into ti-linux-4.19.y

TI-Feature: connectivity
TI-Tree: git://git.ti.com/connectivity-integration-tree/connectivity-ti-linux-kernel.git
TI-Branch: connectivity-ti-linux-4.19.y

* 'connectivity-ti-linux-4.19.y' of git://git.ti.com/connectivity-integration-tree/connectivity-ti-linux-kernel:
  arm64: dts: k3-am6: Enable PCIe GEN3 mode in RC mode
  PCI: keystone: Set DMA mask and coherent DMA mask
  misc: pci_endpoint_test: Use streaming DMA APIs for buffer allocation
  PCI: endpoint: functions/pci-epf-test: Use data_transfer API for tranferring data
  PCI: designware-ep: Populate epf_init and data_transfer callbacks to use DMA
  PCI: endpoint: Add callbacks for EPF initialization and data transfer
  PCI: endpoint: Add helpers to use dmaengine APIs for data transfers
  PCI: endpoint: Protect concurrent access to pci_epf_ops with mutex
  PCI: endpoint: Protect concurrent access to memory allocation with mutex
  PCI: endpoint: Replace spinlock with mutex
  PCI: endpoint: Use notification chain mechanism to notify EPC events to EPF
  ARM: dts: k2g-ice: Enable PCIe EP
  ARM: dts: keystone-k2g: Add node for PCI EP
  misc: pci_endpoint_test: Add support to test PCI EP in K2G
  PCI: keystone: Add support for PCIe EP in K2G
  PCI: dwc: designware: Add callbacks for configuring inbound and outbound ATU
  ARM: dts: keystone-k2g: Change #interrupt-cells of legacy-interrupt-controller to '2'
  arm64: dts: k3-am6: Change #interrupt-cells of legacy-interrupt-controller to '2'
  dt-bindings: PCI: Fix legacy-interrupt-controller #interrupt-cells to be '2'
  PCI: keystone: Fix error handling when "num-viewport" dt binding is not populated

Signed-off-by: LCPD Auto Merger <lcpd_integration@list.ti.com>

Merge branch 'audio_display-ti-linux-4.19.y' of git.ti.com:~jyrisarha/ti-linux-kernel/jyrisarhas-audio-video-linux-feature-tree into ti-linux-4.19.y

TI-Feature: audio-display
TI-Tree: git@git.ti.com:~jyrisarha/ti-linux-kernel/jyrisarhas-audio-video-linux-feature-tree.git
TI-Branch: audio_display-ti-linux-4.19.y

* 'audio_display-ti-linux-4.19.y' of git.ti.com:~jyrisarha/ti-linux-kernel/jyrisarhas-audio-video-linux-feature-tree:
  ARM: dts: keystone-k2g-evm-lcd: Fix non bidirectional graph connection

Signed-off-by: LCPD Auto Merger <lcpd_integration@list.ti.com>

ARM: dts: keystone-k2g-evm-lcd: Fix non bidirectional graph connection

While disabling sii9022 and connecting lcd node to dss instead is
enough to make lcd work, even the disabled sii9022 node with a port
node endpoint without backward link causes a dtb warning.

Delete sii9022 node completely to fix this. When sii9022 node goes, so
must sound1 and hdmi nodes that refer to it.

Signed-off-by: Jyri Sarha <jsarha@ti.com>

Merge branch 'rpmsg-ti-linux-4.19.y-intg' of git://git.ti.com/rpmsg/rpmsg into ti-linux-4.19.y

TI-Feature: rpmsg
TI-Tree: git://git.ti.com/rpmsg/rpmsg.git
TI-Branch: rpmsg-ti-linux-4.19.y-intg

* 'rpmsg-ti-linux-4.19.y-intg' of git://git.ti.com/rpmsg/rpmsg: (87 commits)
  remoteproc: Fix sysfs interface to stop a suspended processor
  remoteproc/omap: add support for runtime auto-suspend/resume
  remoteproc/omap: add support for system suspend/resume
  ARM: dts: dra7: Add standby info for IPU & DSPs
  ARM: dts: omap5: Add standby info for IPU and DSP
  ARM: dts: omap4: Add standby info for IPU and DSP
  dt-bindings: remoteproc: Update omap remoteproc binding for suspend
  ARM: dts: am571x-idk: Add CMA pools and enable IPUs & DSP1 rprocs
  ARM: dts: am572x-idk-common: Add CMA pools and enable IPU & DSP rprocs
  ARM: dts: beagle-x15-common: Add CMA pools and enable IPU & DSP rprocs
  ARM: dts: dra76-evm: Add CMA pools and enable IPU & DSP rprocs
  ARM: dts: dra71-evm: Add CMA pools and enable IPUs & DSP1 rprocs
  ARM: dts: dra72-evm-revc: Add CMA pools and enable IPUs & DSP1 rprocs
  ARM: dts: dra72-evm: Add CMA pools and enable IPUs & DSP1 rprocs
  ARM: dts: dra7-evm: Add CMA pools and enable IPU & DSP rprocs
  ARM: dts: dra7-ipu-dsp-common: Add timers to IPU and DSP nodes
  ARM: dts: dra7-ipu-dsp-common: Add mailboxes to IPU and DSP nodes
  ARM: dts: dra7-ipu-dsp-common: Move mailboxes into common files
  ARM: OMAP2+: Extend rproc pdata-quirks for DSP2 rproc on DRA74x
  ARM: OMAP2+: Extend rproc pdata-quirks for IPUs & DSP1 on DRA7
  ...

Signed-off-by: LCPD Auto Merger <lcpd_integration@list.ti.com>

Merge branch 'rpmsg-ti-linux-4.19.y' of git://git.ti.com/rpmsg/rpmsg into rpmsg-ti-linux-4.19.y-intg

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

Merge branch 'rproc-linux-4.19.y' of git://git.ti.com/rpmsg/remoteproc into rpmsg-ti-linux-4.19.y

Pull in the updated remoteproc feature branch that adds the support
for system suspend/resume and runtime auto-suspend/resume support on
the IPU and DSP remote processors on OMAP4, OMAP5 and DRA7 SoCs. The
feature branch merge also pulls in automatically the dependent OMAP
iommu feature branch with suspend/resume support. OMAP mailbox driver
already has the suspend/resume support in upstream 4.19 kernel.

* 'rproc-linux-4.19.y' of git://git.ti.com/rpmsg/remoteproc:
  remoteproc: Fix sysfs interface to stop a suspended processor
  remoteproc/omap: add support for runtime auto-suspend/resume
  remoteproc/omap: add support for system suspend/resume
  ARM: dts: dra7: Add standby info for IPU & DSPs
  ARM: dts: omap5: Add standby info for IPU and DSP
  ARM: dts: omap4: Add standby info for IPU and DSP
  dt-bindings: remoteproc: Update omap remoteproc binding for suspend
  iommu/omap: introduce new API for runtime suspend/resume control
  iommu/omap: Add system suspend/resume support
  iommu/omap: add logic to save/restore locked TLBs
  iommu/omap: streamline enable/disable through runtime pm callbacks
  ARM: OMAP2+: add pdata-quirks for OMAP3 ISP IOMMU
  ARM: OMAP2+: Add iommu pdata-quirks for DRA7 DSP EDMA MMUs
  ARM: OMAP2+: plug in device_enable/idle ops for IOMMUs
  iommu/omap: add pdata ops for omap_device_enable/idle

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

remoteproc: Fix sysfs interface to stop a suspended processor

Commit 2aefbef04149 ("remoteproc: Add a sysfs interface for
firmware and state") has added an interface to be able to stop
a remote processor, change the firmware and start the remote
processor using the new firmware through the sysfs files 'state'
and 'firmware'. Any firmware change requires the processor to be
in a stopped state. The logic in 'stop' checks for a valid state
(RPROC_RUNNING) before a processor can be stopped. A booted remote
processor though can also be in RPROC_SUSPENDED state if the driver
controlling the device supports runtime auto-suspend, and any
attempt to stop such a processor throws an error,
"write error: Invalid argument".

It should be possible to stop a processor that is in suspended
state using the sysfs entry, as this is a perfectly functional
scenario when either removing the module, or unbinding the device
from the driver. Fix the sysfs logic to permit the same.

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

remoteproc/omap: add support for runtime auto-suspend/resume

This patch enhances the PM support in the OMAP remoteproc driver to
support the runtime auto-suspend. A remoteproc may not be required to
be running all the time, and typically will need to be active only
during certain usecases. As such, to save power, it should be turned
off during potential long periods of inactivity between usecases.
This suspend and resume of the device is a relatively heavy process
in terms of latencies, so a remoteproc should be suspended only after
a certain period of prolonged inactivity. The OMAP remoteproc driver
leverages the runtime pm framework's auto_suspend feature to accomplish
this functionality. This feature is automatically enabled when a remote
processor has successfully booted. The 'autosuspend_delay_ms' for each
device dictates the inactivity period/time to wait for before
suspending the device.

The runtime auto-suspend design relies on marking the last busy time
on every communication (virtqueue kick) to and from the remote processor.
When there has been no activity for 'autosuspend_delay_ms' time, the
runtime PM framework invokes the driver's runtime pm suspend callback
to suspend the device. The remote processor will be woken up on the
initiation of the next communication message through the runtime pm
resume callback. The current auto-suspend design also allows a remote
processor to deny a auto-suspend attempt, if it wishes to, by sending a
NACK response to the initial suspend request message sent to the remote
processor as part of the suspend process. The auto-suspend request is
also only attempted if the remote processor is idled and in standby at
the time of inactivity timer expiry. This choice is made to avoid
unnecessary messaging, and the auto-suspend is simply rescheduled to
be attempted again after a further lapse of autosuspend_delay_ms.

The runtime pm callbacks functionality in this patch reuses most of the
core logic from the suspend/resume support code, and make use of an
additional auto_suspend flag to differentiate the logic in common code
from system suspend. The system suspend/resume sequences are also updated
to reflect the proper pm_runtime statuses, and also to really perform a
suspend/resume only if the remoteproc has not been auto-suspended at the
time of request. The remote processor is left in suspended state on a
system resume if it has been auto-suspended before, and will be woken up
only when a usecase needs to run. The other significant change in this
patch is to reset the remoteproc device's pm_domain so as to avoid
conflicts with the ordering sequences in the device pm_domain's runtime
callbacks and the reset management and clock management implemented
within the runtime callbacks in the driver.

The OMAP remoteproc driver currently uses a default value of 10 seconds
for all OMAP remoteprocs, and a different value can be chosen either by
choosing a positive value for the 'autosuspend_delay' in the device's
omap_rproc_fw_data in the driver match data or by updating the
'autosuspend_delay_ms' field at runtime through the sysfs interface.
    Eg: To use 25 seconds for IPU2 on DRA7xx,
      echo 25000 > /sys/bus/platform/devices/55020000.ipu/power/autosuspend_delay_ms

The runtime suspend feature can also be similarly enabled or disabled by
writing 'auto' or 'on' to the device's 'control' power field. The default
is enabled.
    Eg: To disable auto-suspend for IPU2 on DRA7xx SoC,
      echo on > /sys/bus/platform/devices/55020000.ipu/power/control

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

remoteproc/omap: add support for system suspend/resume

This patch adds the support for system suspend/resume to the
OMAP remoteproc driver so that the OMAP remoteproc devices can
be suspended/resumed during a system suspend/resume. The support
is added through the driver PM .suspend/.resume callbacks, and
requires appropriate support from the OS running on the remote
processors.

The IPU & DSP remote processors typically have their own private
modules like registers, internal memories, caches etc. The context
of these modules need to be saved and restored properly for a
suspend/resume to work. These are in general not accessible from
the MPU, so the remote processors themselves have to implement
the logic for the context save & restore of these modules.

The OMAP remoteproc driver initiates a suspend by sending a mailbox
message requesting the remote processor to save its context and
enter into an idle/standby state. The remote processor should
usually stop whatever processing it is doing to switch to a context
save mode. The OMAP remoteproc driver detects the completion of
the context save by checking the module standby status for the
remoteproc device. It also stops any resources used by the remote
processors like the timers. The timers need to be running only
when the processor is active and executing, and need to be stopped
otherwise to allow the timer driver to reach low-power states. The
IOMMUs are automatically suspended by the PM core during the late
suspend stage, after the remoteproc suspend process is completed by
putting the remote processor cores into reset. Thereafter, the Linux
kernel can put the domain into further lower power states as possible.

The resume sequence undoes the operations performed in the PM suspend
callback, by starting the timers and finally releasing the processors
from reset. This requires that the remote processor side OS be able to
distinguish a power-resume boot from a power-on/cold boot, restore the
context of its private modules saved during the suspend phase, and
resume executing code from where it was suspended. The IOMMUs would
have been resumed by the PM core during early resume, so they are
already enabled by the time remoteproc resume callback gets invoked.

The remote processors should save their context into System RAM (DDR),
as any internal memories are not guaranteed to retain context as it
depends on the lowest power domain that the remote processor device
is put into. The management of the DDR contents will be managed by
the Linux kernel.

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

ARM: dts: dra7: Add standby info for IPU & DSPs

Add the data for the "ti,rproc-standby-info" property for all
the DSP and IPU remoteproc processor nodes on DRA7xx family of
SoCs. This data is same for all DRA7 boards, and is required
by the OMAP remoteproc driver to implement suspend/resume for
the IPU & DSP remoteproc devices on DRA7 SoCs.

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

ARM: dts: omap5: Add standby info for IPU and DSP

Add the data for the "ti,rproc-standby-info" property for
the DSP and IPU remoteproc processor nodes, applicable to
all OMAP5 boards. This is required by the OMAP remoteproc
driver to implement suspend/resume for the OMAP5 remoteproc
devices.

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

ARM: dts: omap4: Add standby info for IPU and DSP

Add the data for the "ti,rproc-standby-info" property for
the DSP and IPU remoteproc processor nodes. This data is
common to all OMAP4 boards, and is required by the OMAP
remoteproc driver to implement suspend/resume for the OMAP4
remoteproc devices.

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

dt-bindings: remoteproc: Update omap remoteproc binding for suspend

The OMAP remoteproc binding has been updated to add an additional
property, "ti,rproc-standby-info". The property is used to define
the standby register address required by the OMAP remoteproc driver
to check that a remote proessor has entered standby and ready to
be suspended during a system suspend or a runtime auto-suspend of
the corresponding remoteproc device.

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

Merge branch 'iommu-linux-4.19.y' of git://git.ti.com/rpmsg/iommu into rproc-linux-4.19.y

Merge in the updated iommu feature branch into remoteproc tree to
pull in the suspend/resume support in the OMAP IOMMU driver. The
following are the main changes:
   - improvements in the OMAP iommu to perform the enabling &
     disabling of the IOMMU from within the runtime pm callbacks
   - system suspend/resume support through late dev_pm_ops
   - two new API that needs to be invoked from the OMAP remoteproc
     driver to runtime suspend/resume the IOMMU
   - locked TLB save & restore logic
   - add needed pdata quirks to all supported IOMMUs

Suspend/resume support in the OMAP mailbox driver is already supported
in baseline upstream kernel.

* 'iommu-linux-4.19.y' of git://git.ti.com/rpmsg/iommu:
  iommu/omap: introduce new API for runtime suspend/resume control
  iommu/omap: Add system suspend/resume support
  iommu/omap: add logic to save/restore locked TLBs
  iommu/omap: streamline enable/disable through runtime pm callbacks
  ARM: OMAP2+: add pdata-quirks for OMAP3 ISP IOMMU
  ARM: OMAP2+: Add iommu pdata-quirks for DRA7 DSP EDMA MMUs
  ARM: OMAP2+: plug in device_enable/idle ops for IOMMUs
  iommu/omap: add pdata ops for omap_device_enable/idle

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

Merge branch 'rproc-linux-4.19.y' of git://git.ti.com/rpmsg/remoteproc into rpmsg-ti-linux-4.19.y

Pull in the remoteproc feature branch supporting the boot of all DSP and
IPU remote processors on OMAP4, OMAP5 and various DRA7xx/AM57xx SoCs. The
feature branch also pulls in automatically the dependent iommu feature
tree with DRA7 support into the rpmsg-ti-linux-4.19.y RPMsg integration
branch. OMAP mailbox is fully upstream in vanilla 4.19 kernel for all
OMAP SoCs.

The merge also includes couple of fixes to the OMAP4, OMAP5 and DRA7
clock data files and the DMTimer nodes to be able to assign the correct
functional clocks for certain DMTimers and be able to set their parent
clocks.

The supported functional features in OMAP remoteproc include:
 - Device Tree based support for device-specific carveouts and CMA pools
 - Boot of device-tree based IPU and DSP remoteproc devices
 - Internal memory loading support on DSPs
 - BIOS Tick timer support using OMAP DMTimer clocksource code
 - Cleanup of legacy platform device based code

Supported platforms include OMAP4 Pandaboard, OMAP5 uEVM, DRA7 EVMs,
DRA76 EVM, both DRA72 rev.B and rev.C EVMs, DRA71 EVM, all AM57xx
BeagleBoard-X15 boards and their derivative boards, AM572x IDK, AM571x
IDK and AM574x IDK boards. The IVA and DSP remote processors will be
running at OPP_NOM clock frequencies by default, and at OPP_HIGH with
the appropriate U-Boot on boards/SoCs that can support them (DRA71 only
supports OPP_NOM).

* 'rproc-linux-4.19.y' of git://git.ti.com/rpmsg/remoteproc: (72 commits)
  ARM: dts: am571x-idk: Add CMA pools and enable IPUs & DSP1 rprocs
  ARM: dts: am572x-idk-common: Add CMA pools and enable IPU & DSP rprocs
  ARM: dts: beagle-x15-common: Add CMA pools and enable IPU & DSP rprocs
  ARM: dts: dra76-evm: Add CMA pools and enable IPU & DSP rprocs
  ARM: dts: dra71-evm: Add CMA pools and enable IPUs & DSP1 rprocs
  ARM: dts: dra72-evm-revc: Add CMA pools and enable IPUs & DSP1 rprocs
  ARM: dts: dra72-evm: Add CMA pools and enable IPUs & DSP1 rprocs
  ARM: dts: dra7-evm: Add CMA pools and enable IPU & DSP rprocs
  ARM: dts: dra7-ipu-dsp-common: Add timers to IPU and DSP nodes
  ARM: dts: dra7-ipu-dsp-common: Add mailboxes to IPU and DSP nodes
  ARM: dts: dra7-ipu-dsp-common: Move mailboxes into common files
  ARM: OMAP2+: Extend rproc pdata-quirks for DSP2 rproc on DRA74x
  ARM: OMAP2+: Extend rproc pdata-quirks for IPUs & DSP1 on DRA7
  ARM: DRA7: hwmod_data: add data for DSP2 processor
  ARM: DRA7: hwmod_data: add data for IPU and DSP1 rprocs
  ARM: dts: dra72x: Add aliases for rproc nodes
  ARM: dts: dra74x: Add aliases for rproc nodes
  ARM: dts: dra74x: Add DSP2 processor device node
  ARM: dts: dra7: Add common IPU and DSP nodes
  ARM: dts: omap5-uevm: Add system timers to DSP and IPU
  ...

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

Merge branch 'iommu-linux-4.19.y' of git://git.ti.com/rpmsg/iommu into rproc-linux-4.19.y

Merge in the updated iommu feature branch into remoteproc tree to
pull in the necessary support to fix the DRA7 IPU1 boot issue and
couple of DRA7 DSP idle issues with HW_AUTO setting. The DSP idle
status is achieved across all the DSPs and boards only with the
fix for errata i879.

* 'iommu-linux-4.19.y' of git://git.ti.com/rpmsg/iommu:
  ARM: OMAP2+: Add workaround for DRA7 DSP MStandby errata i879
  ARM: OMAP2+: Extend DRA7 IPU1 MMU pdata quirks to DSP MDMA MMUs
  ARM: OMAP2+: Use separate IOMMU pdata to fix DRA7 IPU1 boot
  iommu/omap: Fix boot issue on remoteprocs with AMMU/Unicache

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

ARM: dts: am571x-idk: Add CMA pools and enable IPUs & DSP1 rprocs

The CMA reserved memory nodes have been added for both the IPUs and the
DSP1 remoteproc devices on the AM571x IDK board. These nodes are assigned
to the respective rproc device nodes, and both the IPUs and the DSP1
remote processors are enabled for this board.

The current CMA pools and sizes are defined statically for each device.
The addresses chosen are the same as the respective processors on the
DRA72 EVM board to maintain firmware compatibility between the two boards.
The CMA pools and sizes are defined using 64-bit values to support LPAE.
The starting addresses are fixed to meet current dependencies on the
remote processor firmwares, and this will go away when the remote-side
code has been improved to gather this information runtime during its
initialization.

An associated pair of the rproc node and its CMA node can be disabled
later on if there is no use-case defined to use that remote processor.

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

ARM: dts: am572x-idk-common: Add CMA pools and enable IPU & DSP rprocs

The CMA reserved memory nodes have been added for all the IPU and DSP
remoteproc devices in the am572x-idk-common.dtsi file that is common to
both the AM572x and AM574x IDK boards. These nodes are assigned to the
respective rproc device nodes, and all the IPU and DSP remote processors
are enabled.

The current CMA pools and sizes are defined statically for each device.
The addresses chosen are the same as the respective processors on
the AM57xx EVM board to maintain firmware compatibility between the
two boards. The CMA pools and sizes are defined using 64-bit values
to support LPAE. The starting addresses are fixed to meet current
dependencies on the remote processor firmwares, and this will go
away when the remote-side code has been improved to gather this
information runtime during its initialization.

An associated pair of the rproc node and its CMA node can be disabled
later on if there is no use-case defined to use that remote processor.

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

ARM: dts: beagle-x15-common: Add CMA pools and enable IPU & DSP rprocs

The CMA reserved memory nodes have been added for all the IPU and DSP
remoteproc devices on all the AM57xx BeagleBoard-X15 boards. These nodes
are assigned to the respective rproc device nodes, and all the IPU and
DSP remote processors are enabled for all these boards.

The current CMA pools and sizes are defined statically for each device.
The addresses chosen are the same as the respective processors on the
DRA7 EVM board to maintain firmware compatibility between the two boards.
The CMA pools and sizes are defined using 64-bit values to support LPAE.
The starting addresses are fixed to meet current dependencies on the
remote processor firmwares, and this will go away when the remote-side
code has been improved to gather this information runtime during its
initialization.

An associated pair of the rproc node and its CMA node can be disabled
later on if there is no use-case defined to use that remote processor.

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

ARM: dts: dra76-evm: Add CMA pools and enable IPU & DSP rprocs

The CMA reserved memory nodes have been added for all the IPU and
the DSP remoteproc devices on the DRA76 EVM board, and assigned to
the respective rproc device nodes. These match the configuration
used on the DRA7 EVM board. Both the CMA nodes and the corresponding
rproc nodes are also enabled to enable these processors on the
DRA76 EVM board.

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

ARM: dts: dra71-evm: Add CMA pools and enable IPUs & DSP1 rprocs

The CMA reserved memory nodes have been added for both the IPUs and the
DSP1 remoteproc devices on DRA71 EVM board. These nodes are assigned to
the respective rproc device nodes, and both the IPUs and the DSP1 remote
processors are enabled for this board.

The current CMA pools and sizes are defined statically for each device.
The addresses chosen are the same as the respective processors on the
DRA72 EVM board to maintain firmware compatibility between the two boards.
The CMA pools and sizes are defined using 64-bit values to support LPAE.
The starting addresses are fixed to meet current dependencies on the
remote processor firmwares, and this will go away when the remote-side
code has been improved to gather this information runtime during its
initialization.

An associated pair of the rproc node and its CMA node can be disabled
later on if there is no use-case defined to use that remote processor.

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

ARM: dts: dra72-evm-revc: Add CMA pools and enable IPUs & DSP1 rprocs

The CMA reserved memory nodes have been added for both the IPUs and
the DSP1 remoteproc devices on the DRA72 EVM rev C board, and assigned
to the respective rproc device nodes. These match the configuration
used on the DRA72 EVM board. Both the CMA nodes and the corresponding
rproc nodes are also enabled to enable these processors on the
DRA72 EVM rev C board.

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

ARM: dts: dra72-evm: Add CMA pools and enable IPUs & DSP1 rprocs

The CMA reserved memory nodes have been added for both the IPUs and the
DSP1 remoteproc devices on DRA72 EVM board. These nodes are assigned to
the respective rproc device nodes, and both the IPUs and the DSP1 remote
processors are enabled for this board.

The current CMA pools and sizes are defined statically for each device.
The addresses chosen are the same as the respective processors on the
DRA7 EVM board to maintain firmware compatibility between the two boards.
The CMA pools and sizes are defined using 64-bit values to support LPAE.
The starting addresses are fixed to meet current dependencies on the
remote processor firmwares, and this will go away when the remote-side
code has been improved to gather this information runtime during its
initialization.

An associated pair of the rproc node and its CMA node can be disabled
later on if there is no use-case defined to use that remote processor.

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

ARM: dts: dra7-evm: Add CMA pools and enable IPU & DSP rprocs

The CMA reserved memory nodes have been added for all the IPU and DSP
remoteproc devices on DRA7 EVM board. These nodes are assigned to the
respective rproc device nodes, and all the IPU and DSP remote processors
are enabled for this board.

The current CMA pools and sizes are defined statically for each device.
The CMA pools and sizes are defined using 64-bit values to support LPAE.
The starting addresses are fixed to meet current dependencies on the
remote processor firmwares, and this will go away when the remote-side
code has been improved to gather this information runtime during its
initialization.

An associated pair of the rproc node and its CMA node can be disabled
later on if there is no use-case defined to use that remote processor.

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

ARM: dts: dra7-ipu-dsp-common: Add timers to IPU and DSP nodes

The BIOS System Tick timers have been added for all the IPU and
DSP remoteproc devices in the DRA7 SoC family. The data is added
to the two common dra7-ipu-dsp-common and dra74-ipu-dsp-common
dtsi files that are included by all the desired board files. The
following timers are chosen, as per the timers used on the current
firmware images:
        IPU2: GPTimer 3
        IPU1: GPTimer 11
        DSP1: GPTimer 5
        DSP2: GPTimer 6

The timers are optional, but are mandatory to support advanced device
management features such as power management and watchdog support.
The above are added to successfully boot and execute firmware images
configured with the respective timers, images that use internal
processor subsystem timers are not affected. The timers can be
changed or removed as per the system integration needs, if needed.

Each of the IPUs has two Cortex-M4 processors, and is currently
expected to be running in SMP-mode, so only a single timer suffices
to provide the BIOS tick timer. An additional timer should be added
for the second processor in IPU if it were to be run in non-SMP mode.
The timer value also needs to be unique from the ones used by other
processors so that they can be run simultaneously.

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

ARM: dts: dra7-ipu-dsp-common: Add mailboxes to IPU and DSP nodes

Add the required 'mboxes' property to all the IPU and DSP remote
processors (IPU1, IPU2, DSP1 and DSP2) in the two available common
dtsi files - dra7-ipu-dsp-common and dra74-ipu-dsp-common dtsi files.
The latter file is for platforms having DRA74x/DRA76x/AM572x/AM574x
SoCs which do have a DSP2 processor in addition to the other common
remote processors. The common data is added to the former file, and
the DSP2 only data is added to the latter file.

The mailboxes are required for running the Remote Processor Messaging
(RPMsg) stack between the host processor and each of the remote
processors. Each of the remote processors uses a single sub-mailbox
node, the IPUs are assumed to be running in SMP-mode. The chosen
sub-mailboxes match the values used in the current firmware images.
This can be changed, if needed, as per the system integration needs
after making appropriate changes on the firmware side as well.

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

ARM: dts: dra7-ipu-dsp-common: Move mailboxes into common files

The System Mailboxes 5 and 6 and their corresponding child sub-mailbox
(IPC 3.x) nodes are enabled in each of the DRA7xx and AM57xx board
dts files individually at present. These mailboxes enable the Remote
Processor Messaging (RPMsg) communication stack between the MPU host
processor and each of the IPU1, IPU2, DSP1 and DSP2 remote processors.

Move these nodes into two common dtsi files - dra7-ipu-dsp-common and
dra74-ipu-dsp-common files, which are then included in various board
dts files. These files can be used to add all the common configuration
properties (except memory data) required by remote processor nodes.
The memory pools and the remote processor nodes themselves are to be
enabled in the actual board dts files. The first file is to used by
platforms using DRA72x/DRA71x/AM571x/AM570x SoCs, and the second file
is to be used by platforms using DRA74x/DRA76x/AM572x/AM574x SoCs.
The second file includes the first file and contains additional data
only applicable for DSP2 remote processor.

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

ARM: OMAP2+: Extend rproc pdata-quirks for DSP2 rproc on DRA74x

The pdata quirks for the DSP2 remote processor device, present
usually on DRA74x SoCs, has been added. The DSP2 remote processor
is another identical instance as the DSP1 remote processor, and
the required quirks are identical to the rest of the remote
processors on DRA7xx.

The pdata quirks will be removed once the dependencies against
the arch/arm layers are resolved.

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

ARM: OMAP2+: Extend rproc pdata-quirks for IPUs & DSP1 on DRA7

The remote processors on DRA7xx requires similar device management
pdata-quirks (reset control, clocking, dmtimer API wrappers for
enabling both system and watchdog timers) as the IPU and DSP
processors on OMAP4/OMAP5. All these pdata ops are identical to
the ones used on OMAP4/OMAP5, so extend the existing rproc pdata
quirks to the most common remote processor subsystems on DRA7xx
family of SoCs - IPU1, IPU2 and DSP1.

The pdata quirks need to match the starting address in the auxdata
for the respective processors, as the same compatible string is used
for all the instances of the remote processor of the same type. The
pdata quirks will be removed once the dependencies against arch/arm
layers are resolved.

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

ARM: DRA7: hwmod_data: add data for DSP2 processor

The DRA7xx family of SoCs can have up to two identical DSP
processor subsystems, with most of them having a single DSP
processor subsystem. The second DSP is present only on DRA74x
variants currently. The relevant hwmod class and data structures
are added for this second DSP only for DRA74x SoC variants.
The hwmod data for this DSP2 is very similar to the data on
DSP1.

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

ARM: DRA7: hwmod_data: add data for IPU and DSP1 rprocs

The DRA7xx family of SoCs usually have two IPU and up to two DSP
remote processor subsystems. These subsystems are very similar to
the respective processor subsystems on OMAP4/OMAP5 in terms of clock
and reset integration. The relevant hwmod classes and data structures
are added for IPU1, IPU2 and DSP1 remoteproc devices, the most common
processors present on all DRA7xx SoCs.

Do note that these hwmod data structures do not have a .modulemode
field as the devices are managed together with their corresponding
MMUs. Each of the processor subsystem and its MMU are present within
the same clock domain and requires the domain be clocked and enabled
until the last entity is disabled. The module is disabled properly
during the omap_device_idle processing of the MMU hwmod while
disabling the MMU.

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

ARM: dts: dra72x: Add aliases for rproc nodes

Add aliases for all the 3 remote processor nodes common to
all DRA72x/DRA71x/AM571x/AM570x boards. The aliases uses the
stem "rproc", and are defined in the order of the most common
processors on the DRA72x family. The ids are same as DRA74x
except for the missing DSP2.

The aliases can be overridden, if needed, in the respective
derivative board dts files.

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

ARM: dts: dra74x: Add aliases for rproc nodes

Add aliases for all the IPU and DSP remoteproc processor
nodes common to all DRA74x/DRA76x/AM572x/AM574x boards.
The aliases uses the stem "rproc". The aliases are defined
in the order of the most common processors on the DRA74x
family.

The aliases can be overridden, if needed, in the respective
derivative board dts files.

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

ARM: dts: dra74x: Add DSP2 processor device node

The DRA7xx family of SoCs can contain upto two identical DSP
processor subsystems. The second DSP processor subsystem is
present only on the DRA74x/DRA76x variants. The processor
device DT node has therefore been added in disabled state for
this processor subsystem in the DRA74x specific DTS file.

NOTE:
1. The node does not have any mailboxes, timers or CMA region
   assigned, they should be added in the respective board dts
   files.
2. The node should also be enabled as per the individual product
   configuration in the corresponding board dts files.

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

ARM: dts: dra7: Add common IPU and DSP nodes

The DRA7xx family of SOCs have two IPUs and upto two DSP
processor subsystems in general. The IPU processor subsystem
contains dual-core ARM Cortex-M4 processors, while the DSP
processor subsystem is based on the TI's standard TMS320C66x
DSP CorePac core. The IPUs are very similar to those on OMAP5.

Two IPUs and one DSP processor subsystems is the most common
configuration. The processor device DT nodes have been added
for these processor subsystems, with the internal memories
added through 'reg' and 'reg-names' properties. The IPUs only
have an L2 RAM, whereas the DSPs have L1P, L1D and L2 RAM
memories.

NOTE:
1. The nodes do not have any mailboxes, timers or CMA regions
   assigned, they should be added in the respective board dts
   files.
2. The nodes haven been disabled by default and the enabling
   of these nodes is also left to the respective board dts
   files.

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

ARM: dts: omap5-uevm: Add system timers to DSP and IPU

The BIOS System Tick timers have been added for the IPU and DSP
remoteproc devices for the OMAP5 uEVM boards. The following timers
(same as the timers on OMAP4 Panda boards) are chosen:
        IPU : GPT3 (SMP-mode)
        DSP : GPT5

IPU has two Cortex-M4 processors, and is currently expected to be
running in SMP-mode, so only a single timer suffices to provide
the BIOS tick timer. An additional timer should be added for the
second processor in IPU if it were to be run in non-SMP mode. The
timer value also needs to be unique from the ones used by other
processors so that they can be run simultaneously.

The timers are optional, but are mandatory to support device
management features such as power management and watchdog support.
The above are added to successfully boot and execute firmware images
configured with the respective timers, images that use internal
processor subsystem timers are not affected. The timers can be
changed or removed as per the system integration needs, alongside
equivalent changes on the firmware side.

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

ARM: dts: omap5-uevm: Enable IPU & DSP CMA and rproc nodes

The IPU and DSP remote processor nodes and their associated
CMA pool nodes were previously disabled. The remote processor
nodes are enabled along with their corresponding CMA reserved
memory nodes for the OMAP5 uEVM board.

An associated pair of the rproc node and its CMA node can be
disabled later on if there is no use-case defined to use that
remote processor.

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

ARM: dts: omap5-uevm: Add CMA reserved memory nodes for rprocs

The CMA reserved memory nodes have been added for the IPU and DSP
remoteproc devices on OMAP5 uEVM board. The current CMA pools and
sizes are defined statically for each device. The starting addresses
are fixed to meet current dependencies on the remote processor
firmwares, and will go away when the remote-side code has been
improved to gather this information runtime during its initialization.

The nodes are assigned to the respective rproc device nodes, but are
disabled so that they are not created unnecessarily without enabling
the corresponding rproc devices.

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

ARM: OMAP2+: Extend OMAP4 IPU/DSP pdata-quirks to OMAP5

OMAP5 requires the same device management pdata-quirks as OMAP4
for the IPU and DSP processor subsystems, so extend the OMAP4 IPU
and DSP pdata quirks to OMAP5 as well.

The pdata quirks uses the appropriate starting addresses in the
auxdata as per the current DT node definitions to find the devices
to add the necessary quirks as platform data. The pdata quirks will
be removed once the reset dependencies against omap_device and
omap_hwmod layers are resolved.

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

ARM: OMAP5: hwmod_data: add data for IPU & DSP processors

OMAP5, like OMAP4, also has an IPU and a DSP processor subsystems.
The relevant hwmod classes and data structures are added for these
devices.

Do note that these hwmod data strucutures do not have a .modulemode
field as the devices are managed together with their corresponding
MMUs. Each of the processor subsystem and its MMU are present within
the same clock domain and requires the domain be clocked and enabled
until the last entity is disabled. The module is disabled properly
during the omap_device_idle processing of the MMU hwmod while
disabling the MMU.

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

ARM: dts: omap5: Add aliases for rproc nodes

Add aliases for the DSP and IPU remoteproc processor
nodes common to all OMAP5 boards. The aliases uses
the stem "rproc", and are identical to the values
chosen on OMAP4 boards.

The aliases can be overridden, if needed, in the
respective board files.

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

ARM: dts: omap5: Add DSP and IPU nodes

OMAP5, like OMAP4, also has two remote processor subsystems,
DSP and IPU. The IPU subsystem though has dual Cortex-M4
processors instead of the dual Cortex-M3 processors in OMAP4,
but otherwise has almost the same set of features. Add the
DT nodes for these two processor sub-systems for all OMAP5
SoCs.

The nodes have the 'iommus' and 'mboxes' properties added,
and are disabled for now. The IPU node has its L2 RAM memory
specified through the 'reg' and 'reg-names' properties. The
DSP node doesn't have these since it doesn't have any L2
RAM memories, but has an additional 'syscon-bootreg' property
instead as it has a specific boot register that needs to be
programmed for booting.

These nodes should be enabled as per the individual product
configuration in the corresponding board dts files.

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

ARM: OMAP4: hwmod_data: remove modulemode from IPU/DSP hwmods

The .modulemode field is removed from both the IPU and DSP processor
hwmods. This fixes a kernel crash during the shutdown sequence of any
of these remoteproc devices, either during a normal teardown or during
a recovery.

The DSP and IPU processor subsystems are represented by multiple hwmods
- one for each of the MMUs present within the subsystem, and one for
the processor cores. The processor subsystem is clocked from a single
clock source with separate reset lines for each of the processors and
the MMUs. This clock and reset information is represented in separate
hwmods to allow the management of these entities in different drivers
operating on the corresponding platform devices. This doesn't fit quite
well into the current omap_hwmod layer due to these inter-dependencies.

A remoteproc startup sequence involves enabling and programming of
the MMUs, loading of the firmware into RAM mapped by the MMUs, and
releasing the processors from reset. A shutdown sequence follows a
reverse pattern with the processors put into reset first followed by
the unmapping and disabling of the MMUs. Both the processors and the
MMUs are present within a single clock domain and requires the domain
be clocked and enabled until the last entity. The kernel crash is
caused during the unmapping phase of the MMUs, as the hwmod layer
disables the module during the omap_device_idle processing of the
processor hwmod. This issue is fixed by not defining a modulemode
for the IPU/DSP processors, which results in keeping the module in
an activated state. The module is disabled properly during the
omap_device_idle processing of the MMU hwmod while disabling the
MMU.

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

ARM: dts: omap4-panda-common:: Add system timers to DSP and IPU

The BIOS System Tick timers have been added for the IPU and DSP
remoteproc devices on all the OMAP4-based Panda boards. The
following DMTimers are chosen:
IPU : GPT3 (SMP-mode)
DSP : GPT5

IPU has two Cortex-M3 processors, and is currently expected to be
running in SMP-mode, so only a single timer suffices to provide
the BIOS tick timer. An additional timer should be added for the
second processor in IPU if it were to be run in non-SMP mode. The
timer value also needs to be unique from the ones used by other
processors so that they can be run simultaneously.

The timers are optional, but are mandatory to support device
management features such as power management and watchdog support.
The above are added to successfully boot and execute firmware images
configured with the respective timers, images that use internal
processor subsystem timers are not affected. The timers can be
changed or removed as per the system integration needs, alongside
equivalent changes on the firmware side.

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

ARM: dts: omap4-panda-common: Enable IPU & DSP CMA and rproc nodes

The IPU and DSP remote processor nodes and their associated
CMA pool nodes were previously disabled. The remote processor
nodes are enabled along with their corresponding CMA reserved
memory nodes for all the OMAP4-based Panda boards.

An associated pair of the rproc node and its CMA node can be
disabled later on if there is no use-case defined to use that
remote processor.

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

ARM: dts: omap4-panda-common: Add CMA reserved pools for rprocs

The CMA reserved memory nodes have been added for the IPU and DSP
remoteproc devices on all the OMAP4-based Panda boards. The current
CMA pools and sizes are defined statically for each device. The
starting addresses are fixed to meet current dependencies on the
remote processor firmwares, and will go away when the remote-side
code has been improved to gather this information runtime during
its initialization.

The nodes are assigned to the respective rproc device nodes, but are
disabled so that they are not created unnecessarily without enabling
the corresponding rproc devices.

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

ARM: OMAP2+: Add pdata-quirks for DSP and IPU remoteprocs

The OMAP remoteproc driver performs the device management (reset
control and clocking) for the remote processor sub-systems using
the omap_device API which are limited to only the mach-omap layer.
The OMAP mechanism of using pm_runtime API to achieve this is
insufficient as these devices have hard reset lines which are
managed separately. Use pdata quirks to manage the device reset
and clocking functionality through platform data ops, until the
reset portions are decoupled from omap_hwmod/omap_device into a
separate reset driver.

This patch adds the pdata quirks for both the DSP and IPU processor
subsystems on OMAP4, matching with the current DT node definitions
to find the devices to add platform data. The pdata quirks do not
use a starting address in the auxdata for the DSP device though as
it doesn't have any L2 RAM memory (and so no 'reg' value/address
for the device).

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

ARM: dts: omap4: Add aliases for rproc nodes

Add aliases for the DSP and IPU remoteproc processor
nodes common to all OMAP4 boards. The aliases uses
the stem "rproc".

The aliases can be overridden, if needed, in the
respective board files.

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

ARM: dts: omap4: Add IPU DT node

The DT node for the Dual-Cortex M3 IPU processor sub-system
has been added for OMAP4 SoCs. The L2RAM memory region
information has been added to the node through the 'reg'
and 'reg-names' properties. The node has the 'iommus' and
'mboxes' properties also added, and is disabled for now. It
should be enabled as per the individual product configuration
in the corresponding board dts files.

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

ARM: dts: omap4: Update the DSP node

The compatible property for the DSP node is updated to match
the OMAP remoteproc bindings. The node is moved from the soc
node to the ocp node, as this is better suited to use with
pdata-quirks.

The node is updated with the 'syscon-bootreg', 'iommus' and
'mboxes' properties. Note that the node does not have any
'reg' or 'reg-names' properties since it doesn't have any
L2 RAM memory, but only Unicaches.

The node is disabled for now, and should be enabled as per
the individual product configuration in the corresponding
board dts files.

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

remoteproc/omap: add a trace to print missing alias ids

The alias ids for OMAP 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 the alias id is not defined for a
remoteproc DT node.

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

remoteproc/omap: Request a timer(s) for remoteproc usage

The remote processors in OMAP4+ SoCs are equipped with internal
timers, like the internal SysTick timer in a Cortex M3/M4 NVIC or
the CTM timer within Unicache in IPU & DSP. However, these timers
are gated when the processor subsystem clock is gated, making
them rather difficult to use as OS tick sources. They will not
be able to wakeup the processor from any processor-sleep induced
clock-gating states.

This can be avoided by using an external timer as the tick source,
which can be controlled independently by the OMAP remoteproc
driver code, but still allowing the processor subsystem clock to
be auto-gated when the remoteproc cores are idle.

This patch adds the support for OMAP remote processors to request
timer(s) to be used by the remoteproc. The timers are enabled and
disabled in line with the enabling/disabling of the remoteproc.
The timer data is not mandatory if the advanced device management
features are not required.

The core timer functionality is provided by the OMAP DMTimer
clocksource driver, which does not export any API. The logic is
implemented through the timer device's platform data ops. The OMAP
remoteproc driver mainly requires ops to request/free a dmtimer,
and to start/stop a timer. The split ops helps in controlling the
timer state without having to request and release a timer everytime
it needs to use the timer.

NOTE: If the gptimer is already in use by the time IPU and/or
DSP are loaded, the processors will fail to boot.

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

remoteproc/omap: Check for undefined mailbox messages

Add some checks in the mailbox callback function to limit
any processing in the mailbox callback function to only
certain currently valid messages, and drop all the remaining
messages. A debug message is added to print any such invalid
messages when the appropriate trace control is enabled.

Signed-off-by: Subramaniam Chanderashekarapuram <subramaniam.ca@ti.com>
Signed-off-by: Suman Anna <s-anna@ti.com>

remoteproc/omap: Remove the omap_rproc_reserve_cma declaration

The omap_rproc_reserve_cma() function is not defined at the moment.
This prototype was to be used to define a function to declare a
remoteproc device-specific CMA pool.

The remoteproc devices will be defined through DT going forward. A
device specific CMA pool will be defined under the reserved-memory
node, and will be associated with the appropriate remoteproc device
node. This function prototype will no longer be needed and has
therefore been cleaned up.

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

remoteproc/omap: Remove the unused fields from platform data

The following fields: .name, .oh_name, .oh_name_opt, .mbox_name,
.firmware, .ops and .set_bootaddr, are removed from the platform data,
as these are no longer needed after the addition of DT support to the
OMAP remoteproc driver.

The .name field was used to give a name to the remoteproc, and this
is replaced with the device name. The .ops field was never used by
the OMAP remoteproc driver. The .mbox_name was used to define the
sub-mailbox node used for communication with the remote processor,
and is retrieved using the 'mboxes' property in the DT node. The
.firmware field is encoded directly in the OMAP remoteproc driver and
is retrieved using driver match data. The .set_bootaddr ops was used
for using a OMAP Control Module API to configure the boot address for
the processor, and is now implemented within the driver using a
syscon property.

The .oh_name field is used to define the primary hwmod for the processor
node, and is represented using the 'ti,hwmods' property in the DT node.
The .oh_name_opt field was primarily defined to identify the hwmod for
the second cpu in a dual Cortex-M3/M4 IPU processor sub-system. This
hwmod entry is no longer defined usually, but rather a single hwmod
representing both the processors in the IPU sub-system is defined.
A single firmware image (either in SMP-mode or a combined image for
non-SMP mode) is used, with both the resets released together always
as part of the device management. Any power management and recovery
aspects require that both the processors be managed as one entity due
to the presence of shared MMU and unicache within the IPU sub-system.

The OMAP remoteproc platform data structure is eventually expected
to be removed completely once the other dependencies with the
mach-omap layer are met.

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

remoteproc/omap: Add support for DRA7xx remote processors

DRA7xx/AM57xx SoCs have two IPU and up to two DSP processor subsystems
for offloading different computation algorithms. The IPU processor
subsystem contains dual-core ARM Cortex-M4 processors, and is very
similar to those on OMAP5. The DSP processor subsystem is based on
the TI's standard TMS320C66x DSP CorePac core.

Support has been added to the OMAP remoteproc driver through new
DRA7xx specific compatibles for properly probing and booting the
all the different processor subsystem instances on DRA7xx/AM57xx
SoCs - IPU1, IPU2, DSP1 & DSP2. A build dependency with SOC_DRA7XX
is added to enable the driver to be built in DRA7xx-only configuration.

The DSP boot address programming needed enhancement for DRA7xx as the
boot register fields are different on DRA7 compared to OMAP4 and OMAP5
SoCs. The register on DRA7xx contains additional fields within the
register and the boot address bit-field is right-shifted by 10 bits.
The internal memory parsing logic has also been updated to compute
the device addresses for the L2 RAM for DSP devices using relative
addressing logic, and to parse two additional RAMs at L1 level - L1P
and L1D. This allows the remoteproc driver to support loading into
these regions for a small subset of firmware images requiring as
such. The most common usage would be to use the L1 programmable
RAMs as L1 Caches.

The firmware lookup logic also has to be adjusted for DRA7xx as
there are (can be) more than one instance of both the IPU and DSP
remote processors for the first time in OMAP4+ SoCs.

The names for the firmware images are fixed for each processor and
are expected to be as follows:
IPU1: dra7-ipu1-fw.xem4
IPU2: dra7-ipu2-fw.xem4
DSP1: dra7-dsp1-fw.xe66
DSP2: dra7-dsp2-fw.xe66

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

remoteproc/omap: Initialize and assign reserved memory node

The reserved memory nodes are not assigned to platform devices by
default in the driver core to avoid the lookup for every platform
device and incur a penalty as the real users are expected to be
only a few devices.

OMAP remoteproc devices fall into the above category and the OMAP
remoteproc driver _requires_ specific CMA pools to be assigned
for each device at the moment to align on the location of the
vrings and vring buffers in the RTOS-side firmware images. So,
use the of_reserved_mem_device_init/release() API appropriately
to assign the corresponding reserved memory region to the OMAP
remoteproc device. Note that only one region per device is
allowed by the framework.

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

remoteproc/omap: Add the rproc ops .da_to_va() implementation

An implementation for the rproc ops .da_to_va() has been added
that provides the address translation between device addresses
to kernel virtual addresses for internal RAMs present on that
particular remote processor device. The implementation provides
the translations based on the addresses parsed and stored during
the probe.

This ops gets invoked by the exported rproc_da_to_va() function
and allows the remoteproc core's ELF loader to be able to load
program data directly into the internal memories.

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

remoteproc/omap: Add support to parse internal memories from DT

The OMAP remoteproc driver has been enhanced to parse and store
the kernel mappings for different internal RAM memories that may
be present within each remote processor IP subsystem. Different
devices have varying memories present on current SoCs. The current
support handles the L2RAM for all IPU devices on OMAP4+ SoCs. The
DSPs on OMAP4/OMAP5 only have Unicaches and do not have any L1 or
L2 RAM memories.

IPUs are expected to have the L2RAM at a fixed device address of
0x20000000, based on the current limitations on Attribute MMU
configurations.

NOTE:
The current logic doesn't handle the parsing of memories for DRA7
remoteproc devices, and will be added alongside the DRA7 support.

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

remoteproc/omap: Add a sanity check for DSP boot address alignment

The DSP remote processors on OMAP SoCs require a boot register to
be programmed with a boot address, and this boot address needs to
be on a 1KB boundary. The current code is simply masking the boot
address appropriately without performing any sanity checks before
releasing the resets. An unaligned boot address results in an
undefined execution behavior and can result in various bus errors
like MMU Faults or L3 NoC errors. Such errors are hard to debug and
can be easily avoided by adding a sanity check for the alignment
before booting a DSP remote processor.

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

remoteproc/omap: Add device tree support

OMAP4+ SoCs support device tree boot only. The OMAP remoteproc
driver is enhanced to support remoteproc devices created through
Device Tree, support for legacy platform devices has been
deprecated. The current DT support handles the IPU and DSP
processor subsystems on OMAP4 and OMAP5 SoCs.

The OMAP remoteproc driver relies on the omap_device, omap_hwmod
and control module layers for performing clock, reset and boot
vector management (DSP remoteprocs only) of the devices, but
some of these are limited only to the machine-specific layers
in arch/arm. The dependency against control module API for boot
vector management of the DSP remoteprocs has now been removed
with added logic to parse the boot register from the DT node
and program it appropriately directly within the driver.

The dependency on omap_device API for clock and reset control
remains though and is to be achieved through OMAP rproc specific
platform data ops, and the required implementations to boot and
shutdown have been added in the machine layer. These need to be
plugged in to the remoteproc devices through pdata quirks, for
properly booting the remote processors.

The OMAP remoteproc driver expects the firmware images to have
fixed names. This used to be defined through platform data
previously, and are now coded into the driver. The following
names are to be expected of the firmwares,
OMAP4 - IPU: omap4-ipu-fw.xem3
        DSP: omap4-dsp-fw.xe64T
OMAP5 - IPU: omap5-ipu-fw.xem4
        DSP: omap5-dsp-fw.xe64T

Cc: Tony Lindgren <tony@atomide.com>
Signed-off-by: Suman Anna <s-anna@ti.com>

dt-bindings: remoteproc: Add OMAP remoteproc bindings

Add the device tree bindings document for the IPU and DSP
remote processor devices on OMAP4+ SoCs.

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

remoteproc/omap: Switch to SPDX license identifiers

Use the appropriate SPDX license identifiers in various OMAP remoteproc
source files and drop the previous boilerplate license text.

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

ARM: dts: dra7: Fix functional clocks for DMTimer devices

The hwmod and clkctrl integration code is currently assigning the
clkctrl clock associated with MODULEMODE as the main functional
clock for nodes that have the ti,hwmods property. This is wrong
for devices that actually use mux or gate clocks as their main
clock and that are not yet converted to the ti-sysc node hierarchy.

The dmtimer clocksource driver cannot use this clock to configure
its parents. The dmtimer consumers got lucky so far due to the
default clock matching the requested parent clock, and a silent
successful return in the omap_dm_timer_set_source() function. Fix
this by adding the actual mux clocks to the DMTimer nodes with
the "fck" clock-name. These clocks are expected to remain even
after the nodes have moved under a ti,sysc parent node.

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

ARM: dts: omap5: Fix functional clocks for DMTimer devices

The hwmod and clkctrl integration code is currently assigning the
clkctrl clock associated with MODULEMODE as the main functional
clock for nodes that have the ti,hwmods property. This is wrong
for devices that actually use mux or gate clocks as their main
clock and that are not yet converted to the ti-sysc node hierarchy.

The dmtimer clocksource driver cannot use this clock to configure
its parents. The dmtimer consumers got lucky so far due to the
default clock matching the requested parent clock, and a silent
successful return in the omap_dm_timer_set_source() function. Fix
this by adding the actual mux clocks to the DMTimer nodes with
the "fck" clock-name. These clocks are expected to remain even
after the nodes have moved under a ti,sysc parent node.

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

ARM: dts: omap4: Fix functional clocks for ABE DMTimer devices

The hwmod and clkctrl integration code is currently assigning the
clkctrl clock associated with MODULEMODE as the main functional
clock for nodes that have the ti,hwmods property. This is wrong
for devices that actually use mux or gate clocks as their main
clock and that are not yet converted to the ti-sysc node hierarchy.

The dmtimer clocksource driver cannot use this clock to configure
its parents. All the DMTimer nodes except for those present in the
ABE domain have been converted to the new ti-sysc node hierarchy
style and do not face this issue. The dmtimer consumers got lucky
so far due to the default clock matching the requested parent clock,
and a silent successful return in the omap_dm_timer_set_source()
function. Fix the remaining DMTimer nodes in ABE domain by adding
the actual mux clocks to the DMTimer nodes with the "fck" clock-name.
These clocks are expected to remain even after the nodes have moved
under a ti,sysc parent node.

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

clocksource: timer-ti-dm: Drop bogus omap_dm_timer_of_set_source()

The function omap_dm_timer_of_set_source() was originally added in
commit 31a7448f4fa8a ("ARM: OMAP: dmtimer: Add clock source from DT"),
and is designed to set a clock source from DT using the clocks property
of a timer node. This is a bad design as typically the clocks property
is used to specify the functional clocks for a device, and not its
parents.

The commit 84badc5ec5fc ("ARM: dts: omap4: Move l4 child devices to
probe them with ti-sysc") adds a timer functional clock property to
almost all the timer nodes (except for GPTimers 5, 6, 7, 8 in ABE
domain) on OMAP4 SoCs and this results in an attempt to set the same
functional clock as its parent when a consumer driver attempts to
acquire any of these timers in the omap_dm_timer_prepare() function.
The resulting failure (-EINVAL) also prevents a fallback to the
omap_dm_timer_set_source() function. Fix this by simply dropping
this incorrect logic.

Any DT configuration of clock sources should be achieved using
assigned-clocks and assigned-clock-parents properties provided
by the Common Clock Framework.

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

clk: ti: dra7: Add back timer_sys_ck clock aliases

The commit a8202cd5174d ("clk: ti: dra7: drop unnecessary clock
aliases") has cleaned up all timer_sys_ck clock aliases and retained
only the timer_32k_ck clock alias. The OMAP clocksource timer driver
though still uses this clock alias when reconfiguring the parent
clock source for the timer functional clocks, so add these aliases
back for all the timers.

This is required by the OMAP remoteproc driver to successfully
acquire a timer and configure the source clock to be driven from
timer_sys_ck clock.

Fixes: a8202cd5174d ("clk: ti: dra7: drop unnecessary clock aliases")
Signed-off-by: Suman Anna <s-anna@ti.com>

clk: ti: omap5: Add back timer_sys_ck clock aliases

The commit d41e53040926 ("clk: ti: omap5: cleanup unnecessary clock
aliases") has cleaned up all timer_sys_ck clock aliases and retained
only the timer_32k_ck clock alias. The OMAP clocksource timer driver
though still uses this clock alias when reconfiguring the parent
clock source for the timer functional clocks, so add these aliases
back for all the timers.

This is required by the OMAP remoteproc driver to successfully
acquire a timer and configure the source clock to be driven from
timer_sys_ck clock.

Fixes: d41e53040926 ("clk: ti: omap5: cleanup unnecessary clock aliases")
Signed-off-by: Suman Anna <s-anna@ti.com>

clk: ti: omap4: Add back timer_sys_ck clock aliases

The commit 1c7de9f27a65 ("clk: ti: omap4: cleanup unnecessary clock
aliases") has cleaned up all timer_sys_ck clock aliases and retained
only the timer_32k_ck clock alias. The OMAP clocksource timer driver
though still uses this clock alias when reconfiguring the parent
clock source for the timer functional clocks, so add these aliases
back for all the timers.

This is required by the OMAP remoteproc driver to successfully
acquire a timer and configure the source clock to be driven from
timer_sys_ck clock.

Fixes: 1c7de9f27a65 ("clk: ti: omap4: cleanup unnecessary clock aliases")
Signed-off-by: Suman Anna <s-anna@ti.com>

Merge branch 'iommu-linux-4.19.y' of git://git.ti.com/rpmsg/iommu into rproc-linux-4.19.y

Pull in the iommu tree into the remoteproc tree, since this is a minimum
for bringing up the OMAP remote processors successfully. This iommu merge
pulls in couple of minor cleanups and the basic OMAP IOMMU driver support
for all the IPU and DSP MMUs present on DRA7xx/AM57xx SoC families. The
merge includes fixes to restore the functionality on OMAP4 and OMAP5 SoCs
due to the clkctrl changes, and also adds the clkctrl clocks and nodes for
DRA7 remote processors. The MMUs are enabled in the common base dra7 dts
files, so are supported on all applicable DRA7xx/AM57xx boards automatically.

The base support for IPU and DSP MMUs on OMAP4 and OMAP5 SoC families, and
the necessary DPLL clock configuration of the clocks required for various
remoteproc devices on OMAP4/OMAP5 and DRA7 SoCs are all upstream.

* 'iommu-linux-4.19.y' of git://git.ti.com/rpmsg/iommu:
  ARM: dts: dra74x: Enable DSP2 IOMMU nodes
  ARM: dts: dra7: Enable common IPU and DSP IOMMU nodes
  ARM: OMAP2+: Extend iommu pdata-quirks to DRA74x DSP2
  ARM: OMAP2+: Extend iommu pdata-quirks to DRA7 IPUs & DSP1
  ARM: DRA7: hwmod data: Add MMU data for DSPs
  ARM: DRA7: hwmod data: Add MMU data for IPUs
  ARM: dts: dra7: Add clkctrl nodes for IPU and DSP remote processors
  clk: ti: dra7: add clkctrl data for remote processor clocks
  dt-bindings: clk: add dra7 remotecore clkctrl definitions
  clk: ti: omap5: Drop idlest polling from IPU & DSP clkctrl clocks
  clk: ti: omap4: Drop idlest polling from IPU & DSP clkctrl clocks
  ARM: OMAP2+: hwmod_core: improve the support for clkctrl clocks
  iommu/omap: Use the correct type for SLAB_HWCACHE_ALIGN
  iommu/omap: Remove DEBUG_SEQ_FOPS_RO()

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

Merge branch 'audio_display-ti-linux-4.19.y' of git.ti.com:~jyrisarha/ti-linux-kernel/jyrisarhas-audio-video-linux-feature-tree into ti-linux-4.19.y

TI-Feature: audio-display
TI-Tree: git@git.ti.com:~jyrisarha/ti-linux-kernel/jyrisarhas-audio-video-linux-feature-tree.git
TI-Branch: audio_display-ti-linux-4.19.y

* 'audio_display-ti-linux-4.19.y' of git.ti.com:~jyrisarha/ti-linux-kernel/jyrisarhas-audio-video-linux-feature-tree:
  ti_config_fragments: audio_display.cfg: Update for dra7 LCD/HDMI support

Signed-off-by: LCPD Auto Merger <lcpd_integration@list.ti.com>

ti_config_fragments: audio_display.cfg: Update for dra7 LCD/HDMI support

Enable the following options:
CONFIG_DRM_TOSHIBA_TC358768 - dra7 family LCD support
CONFIG_DRM_PANEL_OSD_OSD101T2587_53TS - dra7 family LCD support
CONFIG_DRM_OMAP_DRA7EVM_ENCODER_TPD12S015 - dra74 HDMI support

CONFIG_SOUND, CONFIG_SND, CONFIG_SND_SOC and
CONFIG_SND_SOC_DAVINCI_MCASP - we need the GPIO for TPD

Disable CONFIG_DRM_PANEL_SAMSUNG_S6E63J0X03

Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
Signed-off-by: Jyri Sarha <jsarha@ti.com>

Merge branch 'connectivity-ti-linux-4.19.y' of git://git.ti.com/connectivity-integration-tree/connectivity-ti-linux-kernel into ti-linux-4.19.y

TI-Feature: connectivity
TI-Tree: git://git.ti.com/connectivity-integration-tree/connectivity-ti-linux-kernel.git
TI-Branch: connectivity-ti-linux-4.19.y

* 'connectivity-ti-linux-4.19.y' of git://git.ti.com/connectivity-integration-tree/connectivity-ti-linux-kernel: (39 commits)
  arm64: dts: k3-am654-idk: Add Support for MCAN
  arm64: dts: ti: k3-am65-mcu: Add Support for MCAN
  can: m_can: Add support for enabling transceiver through the STB line
  dt-bindings: net: can: m_can: Add Documentation for stb-gpios
  mmc: sdhci_am654: Add 48 bit DMA mask
  ti_config_fragments/connectivity.cfg: Enable ICSSG Ethernet driver
  arm64: dts: ti: Add overlay for AM65x IDK application board
  arm64: dts: ti: am654-base-board: add ICSSG2 Ethernet support
  arm64: dts: ti: k3-am65: add MSMC RAM ranges in interconnect nodes
  net: ti: icssg-prueth: Add ICSSG ethernet driver
  ARM: dts: dt-overlays: Add Support for dra71-evm NAND
  arm64: dts: ti: k3-am654-base-board: Add Support for SD card
  arm64: dts: ti: k3-am65-main: Enable support for sdhci1
  ti_config_fragments/connectivity.cfg: Enable PRU Ethernet driver
  ARM: dts: am335x-icev2: Add am335x-icev2-prueth.
  ARM: dts: keystone-k2g-ice: Add PRUSS Ethernet support
  ARM: dts: am437x-idk-evm: Add PRUSS1 Ethernet application node
  ARM: dts: ti: am57xx-idk: Add PRU Ethernet on ICSS1
  ARM: dts: am57xx-idk-common: Add PRUSS2 Ethernet application node
  net: prueth: Add TI PRUSS Ethernet driver
  ...

Signed-off-by: LCPD Auto Merger <lcpd_integration@list.ti.com>

arm64: dts: k3-am6: Enable PCIe GEN3 mode in RC mode

Set max-link-speed dt property to '3' in order to enable PCIe GEN3 mode
in RC mode. EP dt node already has max-link-speed set to '3'

Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>

PCI: keystone: Set DMA mask and coherent DMA mask

Set DMA mask and coherent DMA mask such to indicate the device
can address the entire address space (32-bit in the case of
K2G and 48-bit in the case of AM654.

Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>

misc: pci_endpoint_test: Use streaming DMA APIs for buffer allocation

Use streaming DMA APIs (dma_map_single/dma_unmap_single) for buffers
transmitted/received by the endpoint device instead of allocating
a coherent memory. Also add default_data to set the alignment to
4KB since dma_map_single might not return a 4KB aligned address.

Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>

PCI: endpoint: functions/pci-epf-test: Use data_transfer API for tranferring data

Use pci_epc_data_transfer() for tranferring data to the remote PCIe
RC and only on failure use memcpy. Using pci_epc_data_transfer()
will help to use DMA in the platform (either system or within PCIe
controller) to transfer data.

Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>

PCI: designware-ep: Populate epf_init and data_transfer callbacks to use DMA

Populate epf_init and data_transfer callbacks to use system DMA. This
callbacks will be modified when the DMA within the PCI controller is
used.

Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>

PCI: endpoint: Add callbacks for EPF initialization and data transfer

Add a callback to initialize EPF that is specific to EPC and a callback
to perfrom data transfer between EPC and remote PCIe RC. The endpoint
controller driver can use the dmaengine helper functions for data
transfer or have its own implementation of the internal DMA controller
present in PCIe EP.

Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>

PCI: endpoint: Add helpers to use dmaengine APIs for data transfers

The endpoint function drivers uses memcpy for data transfers. However
a platform can use system DMA or DMA within the PCIe controller for
these data transfers. Add helpers in pci-epf-core to use dmaengine
APIs to initialize DMA channel and for data transfers.

Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>

PCI: endpoint: Protect concurrent access to pci_epf_ops with mutex

Protect concurrent access to pci_epf_ops with mutex. The EPF mutex
added here will also be used to serialize data transfer of a EPF to
the remote RC.

Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>

PCI: endpoint: Protect concurrent access to memory allocation with mutex

pci-epc-mem uses bitmap to manage the PCI address region. This has to
be protected for concurrent access to avoid updating inconsistent state.
Use mutex to protect while updating bitmap.

Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>

PCI: endpoint: Replace spinlock with mutex

The pci_epc_ops is not intended to be invoked from interrupt context.
Hence replace spin_lock_irqsave and spin_unlock_irqrestore with
mutex_lock and mutex_unlock respectively.

Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>

PCI: endpoint: Use notification chain mechanism to notify EPC events to EPF

Use atomic_notifier_call_chain to notify EPC events like linkup to EPF
instead of using linkup ops in EPF driver. This is in preparation for
adding proper locking mechanism to EPF ops. This will also enable to
add more events (in addition to linkup) in the future.

Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>