rpmsg/rpmsg.git
2 weeks agoMerged TI feature rpmsg into ti-linux-5.10.y rpmsg-ti-linux-5.10.y-next
LCPD Auto Merger [Tue, 27 Apr 2021 16:18:58 +0000 (11:18 -0500)]
Merged TI feature rpmsg into ti-linux-5.10.y

TI-Feature: rpmsg
TI-Branch: rpmsg-ti-linux-5.10.y-intg

* 'rpmsg-ti-linux-5.10.y-intg' of git://git.ti.com/rpmsg/rpmsg:
  arm64: dts: ti: am654: Add an overlay for SR1.0

Signed-off-by: LCPD Auto Merger <lcpd_integration@list.ti.com>
2 weeks agoarm64: dts: ti: am654: Add an overlay for SR1.0 rpmsg-ti-linux-5.10.y-intg
Suman Anna [Mon, 26 Apr 2021 23:36:39 +0000 (18:36 -0500)]
arm64: dts: ti: am654: Add an overlay for SR1.0

The AM65x family of SoCs has two Silicon Revisions - SR1.0 and SR2.0.
The current dtsi and dts files all define the nodes to represent and/or
use the AM65x SR2.0. Add a new overlay file 'k3-am654-sr1.dts' to specify
the delta differences between the two Silicon revisions. This overlay
should be applied on top of the actual AM65x board dts files.

The AM65x SR2.0 SoCs have a revised ICSSG IP that is based off the
subsequent IP revision used on J721E SoCs. The ICSSG IP on AM65x SR2.0
SoCs have two new custom auxiliary PRU cores called Transmit PRUs
(Tx_PRUs) in addition to the existing PRUs and RTUs, but these are
not present on AM65x SR1.0 SoCs. The Tx_PRU nodes are added and enabled
by default in the base k3-am65-main.dtsi file, but these are absent on
SR1.0, so mark them disabled specifically.

Signed-off-by: Suman Anna <s-anna@ti.com>
2 weeks agoMerged TI feature connectivity into ti-linux-5.10.y
LCPD Auto Merger [Tue, 27 Apr 2021 07:19:38 +0000 (02:19 -0500)]
Merged TI feature connectivity into ti-linux-5.10.y

TI-Feature: connectivity
TI-Branch: connectivity-ti-linux-5.10.y

* 'connectivity-ti-linux-5.10.y' of ssh://bitbucket.itg.ti.com/lcpdpublicdom/connectivity:
  ti_config_fragments/connectivity.cfg: enable pru soft uart driver
  arm: dts: add am335x-boneblack-pruswuart.dts
  serial: add pru soft uart (pru_swuart) driver
  dt-bindings: serial: add binding documentation for TI PRU software UART
  ARM: dts: am57xx-idk: Add prueth on ICSS
  net: ti: prueth_core: Add support for timestamping tx/rx packets using IEP
  HACK: net: ethernet: ti: icss-iep: Fix sync0 generation on a compare event
  net: ethernet: ti: prueth: Add IEP driver
  net: ti: prueth_core: move prueth_hostinit() to inside ndo_open()
  net: ti: prueth_core: use separate functions for fdb table handling
  net: ti: prueth_core: make tx irq use optional for Dual EMAC firmware
  net: ti: prueth_core: Add support for runtime mode change
  net: ti: prueth_core: Add support for RSTP switch
  net: ti: prueth: Update headers with switch related definitions
  net: ti: prueth_core: Add Broadcast, Multicast and Unicast storm prevention support
  net: prueth: Add TI PRUSS Ethernet driver
  dt-bindings: net: Add TI-PRUeth bindings
  net: ptp: introduce common defines for PTP message types

Signed-off-by: LCPD Auto Merger <lcpd_integration@list.ti.com>
2 weeks agoti_config_fragments/connectivity.cfg: enable pru soft uart driver
Bin Liu [Fri, 23 Apr 2021 15:50:46 +0000 (10:50 -0500)]
ti_config_fragments/connectivity.cfg: enable pru soft uart driver

enable CONFIG_SERIAL_PRU_SWUART

Signed-off-by: Bin Liu <b-liu@ti.com>
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
2 weeks agoarm: dts: add am335x-boneblack-pruswuart.dts
Bin Liu [Fri, 23 Apr 2021 15:50:45 +0000 (10:50 -0500)]
arm: dts: add am335x-boneblack-pruswuart.dts

This adds new dts file am335x-boneblack-pruswuart.dts to support PRU
software-based UART on Beaglebone Black.

The UART pins are on the expansion connector P8 and P9. Showing as an
example, the 3 ports on PRU0 do not define cts/rts pins to not use hw
flow control, while the 3 ports on PRU1 define cts/rts pins.

Signed-off-by: Bin Liu <b-liu@ti.com>
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
2 weeks agoserial: add pru soft uart (pru_swuart) driver
Bin Liu [Fri, 23 Apr 2021 15:50:44 +0000 (10:50 -0500)]
serial: add pru soft uart (pru_swuart) driver

This adds a new serial driver that supports the PRU software based UART.
With the current version of the PRU UART firmware (v1.0), up to three UART
ports are supported per PRU core. Each character is two bytes in the FIFO.
Hardware flow control is supported if CTS/RTS pins are defined, but
software flow control is not.

Signed-off-by: Bin Liu <b-liu@ti.com>
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
2 weeks agodt-bindings: serial: add binding documentation for TI PRU software UART
Bin Liu [Fri, 23 Apr 2021 15:50:43 +0000 (10:50 -0500)]
dt-bindings: serial: add binding documentation for TI PRU software UART

This adds dt bindings for PRU software based UART on TI SoCs.

Signed-off-by: Bin Liu <b-liu@ti.com>
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
2 weeks agoARM: dts: am57xx-idk: Add prueth on ICSS
Vignesh Raghavendra [Tue, 20 Apr 2021 07:47:33 +0000 (13:17 +0530)]
ARM: dts: am57xx-idk: Add prueth on ICSS

Add DT nodes for PRUSS ETH1 and PRUSS ETH2 which provide Dual EMAC and
Switch functionality over PRU with help of firmwares.

Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
2 weeks agonet: ti: prueth_core: Add support for timestamping tx/rx packets using IEP
Lokesh Vutla [Tue, 20 Apr 2021 07:47:32 +0000 (13:17 +0530)]
net: ti: prueth_core: Add support for timestamping tx/rx packets using IEP

IEP inside ICSS is used as PTP clock. Add support for initializing IEP
clock when prueth is enabled on ICSS. When PTP support is enabled, the
firmware timestamps the PTP packets that are going out via prueth ports.
The timestamp value is copied to a shared memory location. After
timestamping, a host IRQ is raised by the firmware as a notification to
read the timestamp. When PTP packets are received on ICSS ports,
firmware record the timestamps and appends the timestamp at
the next 32 byte block after the end

Add support to read the tx/rx timestamp and pass it to userspace.

Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Signed-off-by: Roger Quadros <rogerq@ti.com>
Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com>
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
2 weeks agoHACK: net: ethernet: ti: icss-iep: Fix sync0 generation on a compare event
Lokesh Vutla [Tue, 20 Apr 2021 07:47:31 +0000 (13:17 +0530)]
HACK: net: ethernet: ti: icss-iep: Fix sync0 generation on a compare event

commit 41e5c46849b5 ("net: ethernet: ti: icss-iep: Add support for generating
perout/PPS signal for am57xx variant") introduced support for generating
PPS signal using the following method:
- Configure sync0 in single shot mode with 100ms as pulse length.
- This allows to generate a pulse on first compare event after
sync0 is enabled.
- Adjust CMP[1] register to next second boundary on every compare event.

With this setup only one pulse is created after enabling the pps as
sync0 is configured in single shot mode. In order to create a pulse on
every compare event, sync0 has to be disabled and enabled after the
pulse is completed. There are 2 ways to do it:
- Create a hrtimer task which gets scheduled after completed the pulse. With
  this there is a possibility that pulse can be missed, but in current
  situation there is not other better way. $patch is implementing this.
- Trigger an interrupt on falling edge of the pulse. But hardware does
  not support for this interrupt.

There are other ways on how sync0 can be configured. Below gives details
on why other approaches are not taken:
- Cyclic generation: Where cycle time & pulse length is configured upfront.
     Configuring cycle time upfront is a problem, as
     cycle time is in IEP clock cycles and cmp event is
     based on the IEP counter with compensation. This
     way cmp event and sync0 signal goes out of sync.
- Single shot mode: This is the current implementation.
- Cyclic with Ack mode: Where cycle time is configured upfront. Pulse
width is based on the Ack from software. In case
if this is used, ack should happen in cmp
interrupt handler. In this case, the interrupt
handling and ack is fast enough that most of the
times the pulse is not observed on the scope.
- Single shot with Ack mode: Where cycle length and pulse length is not
     fixed. Pulse gets started with first compare
     event. Pulse gets low with the ack from
     software. This will have the same problem
     as single shot mode and cyclic with ack
     mode.

After these experiments, the possible approach is to use Single shot
mode and re-enable sync after every pulse. This patch is using a hrtimer
task for re-enabling sync and that is why it is marked as HACK.

TODO: Explore if the task can be offloaded to firmware and then revert
this HACK

Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
2 weeks agonet: ethernet: ti: prueth: Add IEP driver
Roger Quadros [Tue, 20 Apr 2021 07:47:30 +0000 (13:17 +0530)]
net: ethernet: ti: prueth: Add IEP driver

Add a driver for Industrial Ethernet Peripheral (IEP) block of PRUSS to
support timestamping of ethernet packets and thus support PTP and PPS
for PRU ethernet ports.

Signed-off-by: Roger Quadros <rogerq@ti.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Signed-off-by: Murali Karicheri <m-karicheri2@ti.com>
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
2 weeks agonet: ti: prueth_core: move prueth_hostinit() to inside ndo_open()
Murali Karicheri [Tue, 20 Apr 2021 07:47:29 +0000 (13:17 +0530)]
net: ti: prueth_core: move prueth_hostinit() to inside ndo_open()

As preparatory patch to introduce support for additional Ethernet
types, move prueth_hostinit() to inside ndo_open() as prueth_hostinit()
is common across all Ethernet types and make sense to do it as part
of ndo_open() since driver needs to support run time changing of
Ethernet type. Currently Ethernet type is set inside
prueth_change_to_switch_mode() or prueth_change_to_emac_mode() and
prueth_hostinit() is invoked there. So move this to inside ndo_open().
Now that driver always do rproc_set_firmware() in ndo_open() based on
Ethernet type, remove the restore of firmware names to EMAC firmware
in prueth_sw_shutdown_prus().

For switch based firmwarem there are common resources to be
initialized when the first port is initialized which are done part
of prueth_hostinit(). So introduce a mutex to enter the critical
region inside ndo_open() for initialization and in ndo_stop()
when last port is down. Also set emac_configured at the end after
the port is enabled and use proper input to prueth_port_enable()
call.

Signed-off-by: Murali Karicheri <m-karicheri2@ti.com>
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
2 weeks agonet: ti: prueth_core: use separate functions for fdb table handling
Murali Karicheri [Tue, 20 Apr 2021 07:47:28 +0000 (13:17 +0530)]
net: ti: prueth_core: use separate functions for fdb table handling

Use functions to initialize the fdb table and to free the memory and
move the code to prueth_switch.c. While at it place the fdb init
function ahead of booting the PRUs as this memory is used by PRU.

Signed-off-by: Murali Karicheri <m-karicheri2@ti.com>
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
2 weeks agonet: ti: prueth_core: make tx irq use optional for Dual EMAC firmware
Murali Karicheri [Tue, 20 Apr 2021 07:47:27 +0000 (13:17 +0530)]
net: ti: prueth_core: make tx irq use optional for Dual EMAC firmware

Egress throughput with small size packet is better with
tx irq removed along with reduction in CPU usage. With DUT-DUT
test, a reduction in CPU usage of 7% is seen with iperf3 UDP
test using payload size of 76 bytes. 41% before change vs 34%
after the change on a RT kernel.

CPU usage measured using mpstat -P ALL 3 50 command. iperf
command used

Server
  iperf3 -s -i5

Client
  iperf3 -c <server IP> -u -b18M -l76 -i5 -t60&

DUT to PC test gives a higher throughput of 26-27 Mbits/sec
at this payload size of 76 bytes. client side command is
  iperf3 -c <server IP> -u -b30M -l76 -i5 -t60&

All tested on AM57x with ksoftirqd/0 & ksoftirqd/1 priority
raised as

chrt -f -p 40 9
chrt -f -p 40 20

With DUT to PC test, an improvement in effective throughput of
1.5Mbits/sec along with a reduction in CPU usage of ~1%. The
offered traffic is at 30Mbits/sec.

However with MTU size frames, a degradation in performance of about
7% seen based on testing with Tx IRQ removed. For industrial
networks, it is important to have higher performance at small size
packets since majority of the traffic is small sized. So make Tx IRQ
use in the driver optional for Dual EMAC firmware so that users can
add Tx IRQ entry in the DTS as needed if a specific application uses
predominantly MTU or near MTU sized frames and thus get the benefit
of higher throughput at that size.

Signed-off-by: Murali Karicheri <m-karicheri2@ti.com>
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
2 weeks agonet: ti: prueth_core: Add support for runtime mode change
Vignesh Raghavendra [Tue, 20 Apr 2021 07:47:26 +0000 (13:17 +0530)]
net: ti: prueth_core: Add support for runtime mode change

Add support to switch b/w Dual EMAC and Switch mode at runtime. Driver
will come up by default in Dual EMAC mode with Dual EMAC firmware
loaded. When user creates a bridge b/w two EMAC ports, then the driver
reloads PRUs with RSTP Switch firmware to support L2 forwarding offload
and RSTP.

Using Switch mode:

$ ifconfig eth2 up
$ ifconfig eth3 up
$ brctl addbr br0
$ brctl addif br0 eth2
$ brctl addif br0 eth3
$ brctl stp br0 on
$ mstpctl setforcevers br0 rstp
$ ifconfig br0 up
(Driver switches PRUs to RSTP firmware here)

Switching back to Dual EMAC:
$ ifconfig br0 down
$ brctl delbr br0
(Driver switches PRUs to Dual EMAC firmware here)

Note that RSTP switch is only supported on AM57xx platforms for now.

Signed-off-by: Murali Karicheri <m-karicheri2@ti.com>
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
2 weeks agonet: ti: prueth_core: Add support for RSTP switch
WingMan Kwok [Tue, 20 Apr 2021 07:47:25 +0000 (13:17 +0530)]
net: ti: prueth_core: Add support for RSTP switch

PRU based ethernet subsystem can operate in RSTP switch using a
different firmware (than Dual EMAC mode). RSTP switch support L2
forwarding offloading and RSTP state maintenance.

This patch adds switch support for PRUETH driver using switchdev
framework in order to support RSTP switch mode.

Driver supports:
- FDB (forwarding database) offload
- RSTP

Signed-off-by: WingMan Kwok <w-kwok2@ti.com>
[vigneshr@ti.com:
 - Move to new switchdev APIs
 - Use static RX/TX/Host queue sizes
 - Split switch related code to separate function
 - Rebase to v5.4]

Signed-off-by: Murali Karicheri <m-karicheri2@ti.com>
Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com>
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
2 weeks agonet: ti: prueth: Update headers with switch related definitions
Vignesh Raghavendra [Tue, 20 Apr 2021 07:47:24 +0000 (13:17 +0530)]
net: ti: prueth: Update headers with switch related definitions

Update the firmware headers with definitions required to support switch
firmware

Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
2 weeks agonet: ti: prueth_core: Add Broadcast, Multicast and Unicast storm prevention support
Vignesh Raghavendra [Tue, 20 Apr 2021 07:47:23 +0000 (13:17 +0530)]
net: ti: prueth_core: Add Broadcast, Multicast and Unicast storm prevention support

Prueth firmware on AM57xx, AM43xx and AM33xx supports credit based
broadcast, multicast and unicast storm prevention counter. There are
separate counters provided for each of them. Driver writes number of
packets allowed in a 100ms interval. When firmware encounters
packet of a given type, it decrements the value by 1 and when the
counter reaches 0, further packets are dropped.

So, add a way to set limit on number of broadcast, multicast and unicast
packets (L2 level) using the counters supported by firmware.
This is done by implementing offloading of tc-flower policer in
ndo_setup_tc() callback.

tc filter sets rate limit in terms of bits per second but firmware
supports limiting in terms of credits where each credit is equal to one
ethernet packet. Therefore, driver converts bits per second limit to
number of packets per second assuming minimum ethernet frame size for
each packet (Using min frame size allows much granular packets per
second setting)
There is a periodic hrtimer task that runs every 100ms refreshing
available credits. For simplicity credits are divided equally for each
100ms interval.

Based on https://lore.kernel.org/patchwork/patch/1217254/

Example for adding different filters:

Broadcast (dst mac is all 0xffs):
tc qdisc add dev eth2 clsact
tc filter add dev eth2 ingress flower skip_sw dst_mac ff:ff:ff:ff:ff:ff action police rate 10kbit burst 64k

Multicast (dst mac addr has first bit set, below is just an example):
tc qdisc add dev eth2 clsact
tc filter add dev eth2 ingress flower skip_sw dst_mac 01:00:00:00:00:00 action police rate 10kbit burst 64k

Unicast (dst mac addr where first bit is not set, below is just an example):
tc qdisc add dev eth2 clsact
tc filter add dev eth2 ingress flower skip_sw dst_mac 34:10:31:12:11:45 action police rate 10kbit burst 64k

Note that the unicast filter applies to all ingress traffic irrespective of
src mac. Also note that the dst_mac specified in above rule need not be
same as port's mac address. Any non multicast, non broadcast mac address will
end up setting the unicast filter.

Signed-off-by: Murali Karicheri <m-karicheri2@ti.com>
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
2 weeks agonet: prueth: Add TI PRUSS Ethernet driver
Roger Quadros [Tue, 20 Apr 2021 07:47:22 +0000 (13:17 +0530)]
net: prueth: Add TI PRUSS Ethernet driver

This driver brings dual-EMAC functionality on TI SoCs that support
Ethernet over PRUSS.

Signed-off-by: Roger Quadros <rogerq@ti.com>
Signed-off-by: Murali Karicheri <m-karicheri2@ti.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com>
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
2 weeks agoMerged TI feature rpmsg into ti-linux-5.10.y
LCPD Auto Merger [Fri, 23 Apr 2021 17:18:48 +0000 (12:18 -0500)]
Merged TI feature rpmsg into ti-linux-5.10.y

TI-Feature: rpmsg
TI-Branch: rpmsg-ti-linux-5.10.y-intg

* 'rpmsg-ti-linux-5.10.y-intg' of git://git.ti.com/rpmsg/rpmsg:
  dt-bindings: soc: ti: pruss: Add dma-coherent property
  remoteproc: pru: Fix missing cleanup paths in pru_handle_intrmap
  dt-bindings: irqchip: Add node name to PRUSS INTC
  arm64: dts: ti: k3-am65-mcu: Reserve some MCU SRAM for MCU R5F0

Signed-off-by: LCPD Auto Merger <lcpd_integration@list.ti.com>
2 weeks agoMerge branch 'rpmsg-ti-linux-5.10.y' of git://git.ti.com/rpmsg/rpmsg into rpmsg-ti...
Suman Anna [Fri, 23 Apr 2021 15:41:03 +0000 (10:41 -0500)]
Merge branch 'rpmsg-ti-linux-5.10.y' of git://git.ti.com/rpmsg/rpmsg into rpmsg-ti-linux-5.10.y-intg

Signed-off-by: Suman Anna <s-anna@ti.com>
2 weeks agoMerge branch 'rproc-linux-5.10.y' of git://git.ti.com/rpmsg/remoteproc into rpmsg... rpmsg-ti-linux-5.10.y
Suman Anna [Fri, 23 Apr 2021 15:32:24 +0000 (10:32 -0500)]
Merge branch 'rproc-linux-5.10.y' of git://git.ti.com/rpmsg/remoteproc into rpmsg-ti-linux-5.10.y

Pull in the updated remoteproc feature branch that includes few minor
fixes to the PRUSS and PRUSS INTC binding and the PRU remoteproc driver.
The merge also pulls in a change that reserves a portion of the MCU
SRAM for use by the MCU R5FSS Core0 on AM65x SoCs.

* 'rproc-linux-5.10.y' of git://git.ti.com/rpmsg/remoteproc:
  dt-bindings: soc: ti: pruss: Add dma-coherent property
  remoteproc: pru: Fix missing cleanup paths in pru_handle_intrmap
  dt-bindings: irqchip: Add node name to PRUSS INTC
  arm64: dts: ti: k3-am65-mcu: Reserve some MCU SRAM for MCU R5F0

Signed-off-by: Suman Anna <s-anna@ti.com>
2 weeks agodt-bindings: soc: ti: pruss: Add dma-coherent property
Suman Anna [Fri, 23 Apr 2021 14:10:57 +0000 (09:10 -0500)]
dt-bindings: soc: ti: pruss: Add dma-coherent property

Update the PRUSS schema file to include the dma-coherent property
that indicates the coherency of the IP. The PRUSS IPs on 66AK2G
SoCs do use this property.

Reported-by: kernel test robot <lkp@intel.com>
Signed-off-by: Suman Anna <s-anna@ti.com>
2 weeks agoremoteproc: pru: Fix missing cleanup paths in pru_handle_intrmap
Suman Anna [Thu, 22 Apr 2021 18:56:21 +0000 (13:56 -0500)]
remoteproc: pru: Fix missing cleanup paths in pru_handle_intrmap

The downstream commit 9f048e48f2c6 ("remoteproc: pru: Fix and cleanup
firmware interrupt mapping logic") did not reset the variables on all
the failure paths. Fix the gaps.

This patch syncs up the code logic to the equivalent revised version
of the above patch merged into mainline kernel in commit 880a66e026fb
("remoteproc: pru: Fix and cleanup firmware interrupt mapping logic").

Fixes: 9f048e48f2c6 ("remoteproc: pru: Fix and cleanup firmware interrupt mapping logic")
Signed-off-by: Suman Anna <s-anna@ti.com>
2 weeks agodt-bindings: irqchip: Add node name to PRUSS INTC
Suman Anna [Tue, 26 Jan 2021 16:32:51 +0000 (10:32 -0600)]
dt-bindings: irqchip: Add node name to PRUSS INTC

[ Upstream commit 5ab931402a1703358b8a0466c6c9333c560dea6d ]

The current PRUSS Interrupt Controller binding doesn't exactly specify
the convention for the node name. These interrupt-controllers will always
have a unit address. Update the binding with the '$nodename' using the
expected generic name, this shall ensure the interrupt-controller.yaml
is automatically applied to this binding.

Signed-off-by: Suman Anna <s-anna@ti.com>
Link: https://lore.kernel.org/r/20210126163251.29468-1-s-anna@ti.com
Signed-off-by: Rob Herring <robh@kernel.org>
[s-anna@ti.com: cherry-pick commit '5ab931402a17' from v5.12]

2 weeks agoarm64: dts: ti: k3-am65-mcu: Reserve some MCU SRAM for MCU R5F0
Suman Anna [Thu, 22 Apr 2021 19:12:50 +0000 (14:12 -0500)]
arm64: dts: ti: k3-am65-mcu: Reserve some MCU SRAM for MCU R5F0

Add a child SRAM node to reserve a portion of the MCU domain on-chip
SRAM memory for use by the MCU domain R5F Core0. A preliminary size
of 256 KB (half of the current SRAM) is reserved to begin with and
can be adjusted as per need.

This memory is also added to the R5F0 remoteproc node using the
sram property.

Signed-off-by: Suman Anna <s-anna@ti.com>
2 weeks agoMerged TI feature rpmsg into ti-linux-5.10.y
LCPD Auto Merger [Thu, 22 Apr 2021 15:18:07 +0000 (10:18 -0500)]
Merged TI feature rpmsg into ti-linux-5.10.y

TI-Feature: rpmsg
TI-Branch: rpmsg-ti-linux-5.10.y-intg

* 'rpmsg-ti-linux-5.10.y-intg' of git://git.ti.com/rpmsg/rpmsg:
  ti_config_fragments: rpmsg: Add keystone-dsp-mem and UIO modules
  remoteproc/keystone: add support for MPM userspace loader
  remoteproc: add infrastructure support for userspace driven loading
  TEMP: ARM: dts: keystone-k2g-ice: Add a memory carveout for MPM usecases
  TEMP: ARM: dts: keystone-k2g-evm: Add a memory carveout for MPM usecases
  TEMP: ARM: dts: keystone-k2e-evm: Add a memory carveout for MPM usecases
  TEMP: ARM: dts: keystone-k2l-evm: Add a memory carveout for MPM usecases
  TEMP: ARM: dts: keystone-k2hk-evm: Add a memory carveout for MPM usecases
  ARM: dts: keystone-k2g: Reserve SRAM for MPM
  ARM: dts: keystone-k2e: Reserve SRAM for MPM
  ARM: dts: keystone-k2l: Reserve SRAM for MPM
  ARM: dts: keystone-k2hk: Reserve SRAM for MPM
  TEMP: soc: ti: add the keystone_dsp_mem driver
  TEMP: dt-bindings: soc: ti: Add Keystone DSP Memory mapping binding

Signed-off-by: LCPD Auto Merger <lcpd_integration@list.ti.com>
2 weeks agoMerge branch 'rpmsg-ti-linux-5.10.y' of git://git.ti.com/rpmsg/rpmsg into rpmsg-ti...
Suman Anna [Thu, 22 Apr 2021 13:57:05 +0000 (08:57 -0500)]
Merge branch 'rpmsg-ti-linux-5.10.y' of git://git.ti.com/rpmsg/rpmsg into rpmsg-ti-linux-5.10.y-intg

Signed-off-by: Suman Anna <s-anna@ti.com>
2 weeks agoti_config_fragments: rpmsg: Add keystone-dsp-mem and UIO modules
Suman Anna [Wed, 21 Apr 2021 19:02:28 +0000 (14:02 -0500)]
ti_config_fragments: rpmsg: Add keystone-dsp-mem and UIO modules

Add the keystone-dsp-mem module and UIO core modules to the rpmsg
defconfig fragment to enable the user-land Multi Proc Manager (MPM)
based remoteproc usecases on Keystone platforms.

Signed-off-by: Suman Anna <s-anna@ti.com>
2 weeks agoMerge branch 'rproc-linux-5.10.y' of git://git.ti.com/rpmsg/remoteproc into rpmsg...
Suman Anna [Thu, 22 Apr 2021 13:45:38 +0000 (08:45 -0500)]
Merge branch 'rproc-linux-5.10.y' of git://git.ti.com/rpmsg/remoteproc into rpmsg-ti-linux-5.10.y

Pull in the updated remoteproc feature branch that enhances the
Keystone remoteproc driver to provide an userspace interface
for supporting a userland driven Multi Proc Manager (MPM) loader.
An additional temporary keystone_dsp_mem driver is also added
that provides an mmap interface for MultiCore Shared Memory (MSM)
and portions of DDR for exclusive usage for the DSPs.

Both the keystone remoteproc driver and keystone_dsp_mem driver
provide sysfs interfaces for presenting the DSP internal memory
regions and the DDR & SRAM regions respectively to userspace.
The keystone_dsp_mem driver uses the SRAM driver infrastructure,
and uses specific child nodes to reserve portions of the MSM
RAM for exposing them to userspace for the MPM stack on all
Keystone 2 SoCs.

The support relies on couple of enhancements to the remoteproc
core, mainly that provides the infrastructure support to allow
userspace driver loading and to deny any sysfs operations using
flags configured by a remoteproc driver (used during MPM mode
by Keystone remoteproc driver).

This support has been added to all the currently supported TI
platforms - K2H EVM, K2L EVM, K2E EVM, K2G GP EVM and K2G-ICE
boards.

* 'rproc-linux-5.10.y' of git://git.ti.com/rpmsg/remoteproc:
  remoteproc/keystone: add support for MPM userspace loader
  remoteproc: add infrastructure support for userspace driven loading
  TEMP: ARM: dts: keystone-k2g-ice: Add a memory carveout for MPM usecases
  TEMP: ARM: dts: keystone-k2g-evm: Add a memory carveout for MPM usecases
  TEMP: ARM: dts: keystone-k2e-evm: Add a memory carveout for MPM usecases
  TEMP: ARM: dts: keystone-k2l-evm: Add a memory carveout for MPM usecases
  TEMP: ARM: dts: keystone-k2hk-evm: Add a memory carveout for MPM usecases
  ARM: dts: keystone-k2g: Reserve SRAM for MPM
  ARM: dts: keystone-k2e: Reserve SRAM for MPM
  ARM: dts: keystone-k2l: Reserve SRAM for MPM
  ARM: dts: keystone-k2hk: Reserve SRAM for MPM
  TEMP: soc: ti: add the keystone_dsp_mem driver
  TEMP: dt-bindings: soc: ti: Add Keystone DSP Memory mapping binding

Signed-off-by: Suman Anna <s-anna@ti.com>
2 weeks agoremoteproc/keystone: add support for MPM userspace loader
Suman Anna [Wed, 21 Apr 2021 19:32:19 +0000 (14:32 -0500)]
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.

NOTE:
The remoteproc subsystem has gained a new character device functionality
recently in v5.9 kernel, but is not compatible with TI's existing
MPM userspace stack.

Signed-off-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Sam Nelson <samnelson@ti.com>
2 weeks agoremoteproc: add infrastructure support for userspace driven loading
Suman Anna [Wed, 21 Apr 2021 19:22:20 +0000 (14:22 -0500)]
remoteproc: add infrastructure support for userspace driven loading

The remoteproc infrastructure is enhanced to allow remoteproc drivers
to support userspace driven loading, with the actual boot triggered
through the kernel. This usecase is slightly different from the support
for remote processors that were already loaded and booted by bootloaders.
The support for the latter usecase is provided through RPROC_DETACHED
and new .attach() and detach() callbacks, while the userspace driven
load will usually have the remote processor firmwares loaded after
the userspace is up.

Support for the userspace loading feature is provided through a new field
in the rproc structure, 'skip_firmware_load'. This field is 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 loading any firmware segments using this state flag. The default
behavior is unchanged. The sysfs 'firmware' file shows the firmware as
"unknown" and checks are added to ensure the 'auto_boot' field is not
set when the driver is configured for 'skip_firmware_load'.

The actual interface and implementation details is left to the individual
remoteproc drivers. This design will be used by 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.

Signed-off-by: Suman Anna <s-anna@ti.com>
2 weeks agoTEMP: ARM: dts: keystone-k2g-ice: Add a memory carveout for MPM usecases
Suman Anna [Tue, 23 Jan 2018 17:39:09 +0000 (11:39 -0600)]
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>
2 weeks agoTEMP: ARM: dts: keystone-k2g-evm: Add a memory carveout for MPM usecases
Suman Anna [Tue, 23 Jan 2018 17:36:47 +0000 (11:36 -0600)]
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>
2 weeks agoTEMP: ARM: dts: keystone-k2e-evm: Add a memory carveout for MPM usecases
Suman Anna [Tue, 23 Jan 2018 17:36:02 +0000 (11:36 -0600)]
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>
2 weeks agoTEMP: ARM: dts: keystone-k2l-evm: Add a memory carveout for MPM usecases
Suman Anna [Tue, 23 Jan 2018 17:34:24 +0000 (11:34 -0600)]
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>
2 weeks agoTEMP: ARM: dts: keystone-k2hk-evm: Add a memory carveout for MPM usecases
Suman Anna [Tue, 23 Jan 2018 00:45:17 +0000 (18:45 -0600)]
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>
2 weeks agoARM: dts: keystone-k2g: Reserve SRAM for MPM
Suman Anna [Wed, 21 Apr 2021 20:33:40 +0000 (15:33 -0500)]
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>
2 weeks agoARM: dts: keystone-k2e: Reserve SRAM for MPM
Suman Anna [Wed, 21 Apr 2021 20:33:37 +0000 (15:33 -0500)]
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>
2 weeks agoARM: dts: keystone-k2l: Reserve SRAM for MPM
Suman Anna [Wed, 21 Apr 2021 20:33:33 +0000 (15:33 -0500)]
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>
2 weeks agoARM: dts: keystone-k2hk: Reserve SRAM for MPM
Suman Anna [Wed, 21 Apr 2021 20:33:29 +0000 (15:33 -0500)]
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>
2 weeks agoTEMP: soc: ti: add the keystone_dsp_mem driver
Suman Anna [Mon, 19 Apr 2021 20:32:13 +0000 (15:32 -0500)]
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>
2 weeks agoTEMP: dt-bindings: soc: ti: Add Keystone DSP Memory mapping binding
Suman Anna [Mon, 19 Apr 2021 18:11:33 +0000 (13:11 -0500)]
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>
3 weeks agoMerged TI feature connectivity into ti-linux-5.10.y
LCPD Auto Merger [Wed, 21 Apr 2021 06:18:06 +0000 (01:18 -0500)]
Merged TI feature connectivity into ti-linux-5.10.y

TI-Feature: connectivity
TI-Branch: connectivity-ti-linux-5.10.y

* 'connectivity-ti-linux-5.10.y' of ssh://bitbucket.itg.ti.com/lcpdpublicdom/connectivity:
  ti_config_fragments/connectivity.cfg: Enable CAN PHY transceiver driver
  arm64: dts: ti: k3-j721e-common-proc-board: Add support for mcu_mcan nodes
  arm64: dts: ti: k3-j721e: Add support for MCAN nodes
  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 transceiver as phy
  dt-bindings: net: can: Document transceiver implementation as phy
  phy: phy-can-transceiver: Add support for generic CAN transceiver driver
  dt-bindings: phy: Add binding for TI TCAN104x CAN transceivers
  phy: core: Reword the comment specifying the units of max_link_rate to be Mbps
  phy: Allow a NULL phy name for devm_phy_get()
  arm64: dts: ti: Add k3-am654-gp.dts overlay for audio support
  arm64: dts: ti: Add DT overlay for PCIe + USB2.0 SERDES personality card
  arm64: dts: ti: Add DT overlay for PCIe + USB3.0 SERDES personality card

Signed-off-by: LCPD Auto Merger <lcpd_integration@list.ti.com>
3 weeks agodt-bindings: net: Add TI-PRUeth bindings
Andrew F. Davis [Tue, 20 Apr 2021 07:47:21 +0000 (13:17 +0530)]
dt-bindings: net: Add TI-PRUeth bindings

Add DT binding information for TI's PRUSS Ethernet
device driver.

Signed-off-by: Andrew F. Davis <afd@ti.com>
Signed-off-by: Roger Quadros <rogerq@ti.com>
Signed-off-by: Murali Karicheri <m-karicheri2@ti.com>
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
3 weeks agonet: ptp: introduce common defines for PTP message types
Christian Eggers [Tue, 20 Apr 2021 07:47:20 +0000 (13:17 +0530)]
net: ptp: introduce common defines for PTP message types

commit 076d38b88c4146fd5506933d440b881741b6ab60 upstream.

Using PTP wide defines will obsolete different driver internal defines
and uses of magic numbers.

Cc: Kurt Kanzenbach <kurt@linutronix.de>
Signed-off-by: Christian Eggers <ceggers@arri.de>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
Reviewed-by: Vladimir Oltean <olteanv@gmail.com>
Reviewed-by: Richard Cochran <richardcochran@gmail.com>
3 weeks agoti_config_fragments/connectivity.cfg: Enable CAN PHY transceiver driver
Aswath Govindraju [Mon, 19 Apr 2021 06:23:45 +0000 (11:53 +0530)]
ti_config_fragments/connectivity.cfg: Enable CAN PHY transceiver driver

Enable CAN PHY transceiver driver as a module.-

Signed-off-by: Aswath Govindraju <a-govindraju@ti.com>
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
3 weeks agoarm64: dts: ti: k3-j721e-common-proc-board: Add support for mcu_mcan nodes
Faiz Abbas [Mon, 19 Apr 2021 06:23:44 +0000 (11:53 +0530)]
arm64: dts: ti: k3-j721e-common-proc-board: Add support for mcu_mcan nodes

Add two MCAN nodes present on the common processor board and set a
maximum data rate of 5 Mbps. Disable all other nodes for now.

Signed-off-by: Faiz Abbas <faiz_abbas@ti.com>
Signed-off-by: Aswath Govindraju <a-govindraju@ti.com>
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
3 weeks agoarm64: dts: ti: k3-j721e: Add support for MCAN nodes
Faiz Abbas [Mon, 19 Apr 2021 06:23:43 +0000 (11:53 +0530)]
arm64: dts: ti: k3-j721e: Add support for MCAN nodes

Add support for 14 MCAN controllers in main domain and 2 MCAN controllers
present in mcu domain. All the MCAN controllers support classic CAN
messages as well as CAN_FD messages.

Signed-off-by: Faiz Abbas <faiz_abbas@ti.com>
Signed-off-by: Aswath Govindraju <a-govindraju@ti.com>
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
3 weeks agoarm64: dts: k3-am654-idk: Add Support for MCAN
Faiz Abbas [Mon, 19 Apr 2021 06:23:42 +0000 (11:53 +0530)]
arm64: dts: k3-am654-idk: Add Support for MCAN

Add two MCAN nodes present on the idk board and set a maximum data rate
of 5 Mbps.

Signed-off-by: Faiz Abbas <faiz_abbas@ti.com>
Signed-off-by: Aswath Govindraju <a-govindraju@ti.com>
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
3 weeks agoarm64: dts: ti: k3-am65-mcu: Add Support for MCAN
Faiz Abbas [Mon, 19 Apr 2021 06:23:41 +0000 (11:53 +0530)]
arm64: dts: ti: k3-am65-mcu: Add Support for MCAN

Add Support for two MCAN controllers present on the am65x SOC. Both support
classic CAN messages as well as CAN-FD.

Signed-off-by: Faiz Abbas <faiz_abbas@ti.com>
Signed-off-by: Aswath Govindraju <a-govindraju@ti.com>
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
3 weeks agocan: m_can: Add support for transceiver as phy
Faiz Abbas [Mon, 19 Apr 2021 06:23:40 +0000 (11:53 +0530)]
can: m_can: Add support for transceiver as phy

Add support for implementing transceiver node as phy. The max_bitrate is
obtained by getting a phy attribute.

Signed-off-by: Faiz Abbas <faiz_abbas@ti.com>
Signed-off-by: Aswath Govindraju <a-govindraju@ti.com>
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
3 weeks agodt-bindings: net: can: Document transceiver implementation as phy
Faiz Abbas [Mon, 19 Apr 2021 06:23:39 +0000 (11:53 +0530)]
dt-bindings: net: can: Document transceiver implementation as phy

Some transceivers need a configuration step (for example, pulling the
standby or enable lines) for them to start sending messages. The
transceiver can be implemented as a phy with the configuration done in the
phy driver. The bit rate limitation can the be obtained by the driver using
the phy node.

Document the above implementation in the bosch mcan bindings

Signed-off-by: Faiz Abbas <faiz_abbas@ti.com>
Signed-off-by: Aswath Govindraju <a-govindraju@ti.com>
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
3 weeks agophy: phy-can-transceiver: Add support for generic CAN transceiver driver
Aswath Govindraju [Mon, 19 Apr 2021 06:23:38 +0000 (11:53 +0530)]
phy: phy-can-transceiver: Add support for generic CAN transceiver driver

The driver adds support for generic CAN transceivers. Currently
the modes supported by this driver are standby and normal modes for TI
TCAN1042 and TCAN1043 CAN transceivers.

The transceiver is modelled as a phy with pins controlled by gpios, to put
the transceiver in various device functional modes. It also gets the phy
attribute max_link_rate for the usage of CAN drivers.

Signed-off-by: Aswath Govindraju <a-govindraju@ti.com>
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
3 weeks agodt-bindings: phy: Add binding for TI TCAN104x CAN transceivers
Aswath Govindraju [Mon, 19 Apr 2021 06:23:37 +0000 (11:53 +0530)]
dt-bindings: phy: Add binding for TI TCAN104x CAN transceivers

Add binding documentation for TI TCAN104x CAN transceivers.

Signed-off-by: Aswath Govindraju <a-govindraju@ti.com>
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
Reviewed-by: Rob Herring <robh@kernel.org>
3 weeks agophy: core: Reword the comment specifying the units of max_link_rate to be Mbps
Aswath Govindraju [Mon, 19 Apr 2021 06:23:36 +0000 (11:53 +0530)]
phy: core: Reword the comment specifying the units of max_link_rate to be Mbps

In some subsystems (eg. CAN, SPI), the max link rate supported can be less
than 1 Mbps and if the unit for max_link_rate is Mbps then it can't be
used. Therefore, leave the decision of units to be used, to the producer
and consumer.

Signed-off-by: Aswath Govindraju <a-govindraju@ti.com>
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
3 weeks agophy: Allow a NULL phy name for devm_phy_get()
Rob Herring [Mon, 19 Apr 2021 06:23:35 +0000 (11:53 +0530)]
phy: Allow a NULL phy name for devm_phy_get()

For a single PHY, there's no reason to have a phy-names entry in DT.
The DT specific get functions allow for this already, but devm_phy_get()
WARNs in this case. Other subsystems also don't warn in their get
functions. Let's drop the WARN for DT case in devm_phy_get().

Signed-off-by: Rob Herring <robh@kernel.org>
[a-govindraju@ti.com: fixed some minor checkpatch checks]
Signed-off-by: Aswath Govindraju <a-govindraju@ti.com>
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
3 weeks agoarm64: dts: ti: Add k3-am654-gp.dts overlay for audio support
Peter Ujfalusi [Thu, 8 Apr 2021 10:39:56 +0000 (16:09 +0530)]
arm64: dts: ti: Add k3-am654-gp.dts overlay for audio support

The GP application board has:
ICSSG I2C0..3 connected to I2C EEPROMs
ICSSG UART0..3 headers with level shifters
ICSSG SPI0..3 connected to SPI Flash
McASP0 connected to tlv320aic3106 codec with Headset out and Line In jack

This patch adds support for the audio on the GP application board.

Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
[s-anna@ti.com: Makefile fixups, rename file and other cleanups for 5.10]
Signed-off-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
3 weeks agoarm64: dts: ti: Add DT overlay for PCIe + USB2.0 SERDES personality card
Roger Quadros [Thu, 15 Apr 2021 05:00:29 +0000 (10:30 +0530)]
arm64: dts: ti: Add DT overlay for PCIe + USB2.0 SERDES personality card

Enable both Serdes and PCIe dt nodes in order to get PCIe working in
the SERDES PCIe x2 personality card.

The daughter card also has a USB 2.0 dual-role port. As the base board
already supports a 2.0 dual-role port, 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.

Co-developed-by: Kishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: Roger Quadros <rogerq@ti.com>
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
[a-govindraju@ti.com: Makefile fixups, minor checkpatch fixes and rename file for 5.10]
Signed-off-by: Aswath Govindraju <a-govindraju@ti.com>
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
3 weeks agoarm64: dts: ti: Add DT overlay for PCIe + USB3.0 SERDES personality card
Kishon Vijay Abraham I [Thu, 15 Apr 2021 05:00:28 +0000 (10:30 +0530)]
arm64: dts: ti: Add DT overlay for PCIe + USB3.0 SERDES personality card

Add overlay for PCIe (uses the second instance of PCIe in AM654x) and
USB3.0 SERDES personality card

Co-developed-by: Roger Quadros <rogerq@ti.com>
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: Roger Quadros <rogerq@ti.com>
[a-govindraju@ti.com: Makefile fixups, add num-lanes and rename file to dts for 5.10]
Signed-off-by: Aswath Govindraju <a-govindraju@ti.com>
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
3 weeks agoMerged TI feature rpmsg into ti-linux-5.10.y
LCPD Auto Merger [Thu, 15 Apr 2021 00:36:20 +0000 (19:36 -0500)]
Merged TI feature rpmsg into ti-linux-5.10.y

TI-Feature: rpmsg
TI-Branch: rpmsg-ti-linux-5.10.y-intg

* 'rpmsg-ti-linux-5.10.y-intg' of git://git.ti.com/rpmsg/rpmsg:
  rpmsg: rpc: add the uapi rpmsg_rpc header

Signed-off-by: LCPD Auto Merger <lcpd_integration@list.ti.com>
3 weeks agoMerge branch 'rpmsg-ti-linux-5.10.y' of git://git.ti.com/rpmsg/rpmsg into rpmsg-ti...
Suman Anna [Wed, 14 Apr 2021 19:14:44 +0000 (14:14 -0500)]
Merge branch 'rpmsg-ti-linux-5.10.y' of git://git.ti.com/rpmsg/rpmsg into rpmsg-ti-linux-5.10.y-intg

Signed-off-by: Suman Anna <s-anna@ti.com>
3 weeks agoMerged TI feature rpmsg into ti-linux-5.10.y
LCPD Auto Merger [Wed, 14 Apr 2021 19:06:08 +0000 (14:06 -0500)]
Merged TI feature rpmsg into ti-linux-5.10.y

TI-Feature: rpmsg
TI-Branch: rpmsg-ti-linux-5.10.y-intg

* 'rpmsg-ti-linux-5.10.y-intg' of git://git.ti.com/rpmsg/rpmsg:
  ti_config_fragments: rpmsg: Enable rpmsg-proto module
  ARM: dts: da850: Add alias for DSP node
  remoteproc/davinci: Add a trace to print missing ids
  remoteproc/davinci: Switch a debug trace statement to use %pK
  net/rpmsg: add support for new rpmsg sockets
  rpmsg: core: add API to get MTU

Signed-off-by: LCPD Auto Merger <lcpd_integration@list.ti.com>
3 weeks agoMerge branch 'rpmsg-linux-5.10.y' of git://git.ti.com/rpmsg/rpmsg into rpmsg-ti-linux...
Suman Anna [Wed, 14 Apr 2021 18:15:55 +0000 (13:15 -0500)]
Merge branch 'rpmsg-linux-5.10.y' of git://git.ti.com/rpmsg/rpmsg into rpmsg-ti-linux-5.10.y

Pull in the base rpmsg tree that adds a uapi header for a new rpmsg
bus driver, rpmsg-rpc. This header will be used by MmRpc module in
IPC 3.x stack on OMAP4+ family of SoCs.

* 'rpmsg-linux-5.10.y' of git://git.ti.com/rpmsg/rpmsg:
  rpmsg: rpc: add the uapi rpmsg_rpc header

Signed-off-by: Suman Anna <s-anna@ti.com>
3 weeks agorpmsg: rpc: add the uapi rpmsg_rpc header rpmsg-linux-5.10.y
Suman Anna [Wed, 14 Apr 2021 16:42:21 +0000 (11:42 -0500)]
rpmsg: rpc: add the uapi rpmsg_rpc header

A new rpmsg client driver, rpmsg_rpc, will be introduced later that will
provide a framework for userspace applications to execute functions on
different remote processors.

The driver added in previous downstream TI kernels is not yet ready and
requires rework due to changes in dma-buf framework, to be ported and
be functional properly onto 5.10 kernel. Add and export the required
minimal uapi rpmsg_rpc.h header file for now to unblock the integration
of the TI IPC userspace components.

Signed-off-by: Suman Anna <s-anna@ti.com>
3 weeks agoMerge branch 'rpmsg-ti-linux-5.10.y' of git://git.ti.com/rpmsg/rpmsg into rpmsg-ti...
Suman Anna [Wed, 14 Apr 2021 14:20:20 +0000 (09:20 -0500)]
Merge branch 'rpmsg-ti-linux-5.10.y' of git://git.ti.com/rpmsg/rpmsg into rpmsg-ti-linux-5.10.y-intg

Signed-off-by: Suman Anna <s-anna@ti.com>
3 weeks agoMerged TI feature connectivity into ti-linux-5.10.y
LCPD Auto Merger [Wed, 14 Apr 2021 14:15:44 +0000 (09:15 -0500)]
Merged TI feature connectivity into ti-linux-5.10.y

TI-Feature: connectivity
TI-Branch: connectivity-ti-linux-5.10.y

* 'connectivity-ti-linux-5.10.y' of ssh://bitbucket.itg.ti.com/lcpdpublicdom/connectivity:
  arm64: dts: ti: k3-am64-main: Add ADC nodes
  arm64: dts: ti: k3-am65: Add support for UHS-I modes in MMCSD1 subsystem
  arm64: dts: ti: k3-j7200: Add support for higher speed modes and update delay select values for MMCSD subsystems

Signed-off-by: LCPD Auto Merger <lcpd_integration@list.ti.com>
3 weeks agoti_config_fragments: rpmsg: Enable rpmsg-proto module
Suman Anna [Tue, 13 Apr 2021 21:46:44 +0000 (16:46 -0500)]
ti_config_fragments: rpmsg: Enable rpmsg-proto module

Add support to build the rpmsg sockets driver "rpmsg-proto"
explicitly now for both v5 and v7 platforms. The dependent
REMOTEPROC is already enabled as built-in in the needed
defconfigs (multi_v7_defconfig and davinci_all_defconfig).
The other dependent RPMSG_VIRTIO module is also already
enabled.

These options enable the TI MessageQ IPC stack for various
v5 (OMAP-L138) and v7 (66AK2x, DRA7xx, AM57xx etc) platforms.

The driver won't be supported for v8 (AM65x, J721E, J7200,
AM64x) platforms, and rpmsg-char driver continues to be the
default driver to use with userspace on these SoC families.

Signed-off-by: Suman Anna <s-anna@ti.com>
3 weeks agoMerge branch 'rpmsg-linux-5.10.y' of git://git.ti.com/rpmsg/rpmsg into rpmsg-ti-linux...
Suman Anna [Wed, 14 Apr 2021 13:43:57 +0000 (08:43 -0500)]
Merge branch 'rpmsg-linux-5.10.y' of git://git.ti.com/rpmsg/rpmsg into rpmsg-ti-linux-5.10.y

Pull in the updated rpmsg base feature branch that adds a new
rpmsg bus driver, rpmsg-proto. The rpmsg-proto driver implements
a remote processor messaging socket interface, and supports the
MessageQ stack in the TI IPC product.

The merge also adds a new API to the rpmsg core to return the
maximum rpmsg transport payload size, that can be used by rpmsg
bus drivers when sending data over the virtio-rpmsg bus.

* 'rpmsg-linux-5.10.y' of git://git.ti.com/rpmsg/rpmsg:
  net/rpmsg: add support for new rpmsg sockets
  rpmsg: core: add API to get MTU

Signed-off-by: Suman Anna <s-anna@ti.com>
3 weeks agoMerge branch 'rproc-linux-5.10.y' of git://git.ti.com/rpmsg/remoteproc into rpmsg...
Suman Anna [Wed, 14 Apr 2021 13:42:30 +0000 (08:42 -0500)]
Merge branch 'rproc-linux-5.10.y' of git://git.ti.com/rpmsg/remoteproc into rpmsg-ti-linux-5.10.y

Pull in the updated remoteproc feature branch that includes few cleanups
and enhancements to the Davinci remoteproc driver needed to support the
TI MessageQ stack with the DSP core on the OMAP-L138 SoCs.

The remoteproc driver continues to support the legacy-mode devices on
non-DT platforms, and the DT-mode device is supported on the OMAP-L138
LCDK board.

* 'rproc-linux-5.10.y' of git://git.ti.com/rpmsg/remoteproc:
  ARM: dts: da850: Add alias for DSP node
  remoteproc/davinci: Add a trace to print missing ids
  remoteproc/davinci: Switch a debug trace statement to use %pK

Signed-off-by: Suman Anna <s-anna@ti.com>
4 weeks agoarm64: dts: ti: k3-am64-main: Add ADC nodes
Vignesh Raghavendra [Sat, 10 Apr 2021 11:27:51 +0000 (16:57 +0530)]
arm64: dts: ti: k3-am64-main: Add ADC nodes

commit fad4e18fe4dccacf68418da01e98c4b8fb590023 upstream.

AM64 SoC has a single ADC IP with 8 channels. Add DT node for the same.

Default usecase is to control ADC from non Linux core on the system on
AM642 GP EVM, therefore mark the node as reserved in k3-am642-evm.dts
file. ADC lines are not pinned out on AM642 SK board, therefore disable
the node in k3-am642-sk.dts file.

Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
Reviewed-by: Lokesh Vutla <lokeshvutla@ti.com>
Link: https://lore.kernel.org/r/20210318113443.20036-1-vigneshr@ti.com
4 weeks agoarm64: dts: ti: k3-am65: Add support for UHS-I modes in MMCSD1 subsystem
Aswath Govindraju [Wed, 7 Apr 2021 10:58:50 +0000 (16:28 +0530)]
arm64: dts: ti: k3-am65: Add support for UHS-I modes in MMCSD1 subsystem

UHS-I speed modes are supported in AM65 S.R. 2.0 SoC[1].

Add support by removing the no-1-8-v tag and including the voltage
regulator device tree nodes for power cycling.

[1] - https://www.ti.com/lit/ug/spruid7e/spruid7e.pdf, section 12.3.6.1.1

Signed-off-by: Aswath Govindraju <a-govindraju@ti.com>
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
4 weeks agoarm64: dts: ti: k3-j7200: Add support for higher speed modes and update delay select...
Aswath Govindraju [Mon, 29 Mar 2021 10:05:29 +0000 (15:35 +0530)]
arm64: dts: ti: k3-j7200: Add support for higher speed modes and update delay select values for MMCSD subsystems

The following speed modes are now supported in J7200 SoC,
- HS200 and HS400 modes at 1.8 V card voltage, in MMCSD0 subsystem [1].
- UHS-I speed modes in MMCSD1 subsystem [1].

Add support for UHS-I modes by adding voltage regulator device tree nodes
and corresponding pinmux details, to power cycle and voltage switch cards.
Set respective tags in sdhci0 and remove no-1-8-v tag from sdhci1
device tree nodes.

Also update the delay values for various speed modes supported, based on
the revised january 2021 J7200 datasheet[2].

[1] - section 12.3.6.1.1 MMCSD Features, in
      https://www.ti.com/lit/ug/spruiu1a/spruiu1a.pdf,
      (SPRUIU1A – JULY 2020 – REVISED JANUARY 2021)

[2] - https://www.ti.com/lit/ds/symlink/dra821u.pdf,
      (SPRSP57B – APRIL 2020 – REVISED JANUARY 2021)

Signed-off-by: Aswath Govindraju <a-govindraju@ti.com>
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
Reviewed-by: Kishon Vijay Abraham I <kishon@ti.com>
4 weeks agoARM: dts: da850: Add alias for DSP node
Suman Anna [Wed, 2 Jan 2019 21:13:43 +0000 (15:13 -0600)]
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>
4 weeks agoremoteproc/davinci: Add a trace to print missing ids
Suman Anna [Mon, 15 Jan 2018 18:41:31 +0000 (12:41 -0600)]
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>
4 weeks agoremoteproc/davinci: Switch a debug trace statement to use %pK
Suman Anna [Wed, 2 Jan 2019 21:34:37 +0000 (15:34 -0600)]
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>
4 weeks agonet/rpmsg: add support for new rpmsg sockets
Suman Anna [Tue, 13 Apr 2021 21:20:19 +0000 (16:20 -0500)]
net/rpmsg: add support for new rpmsg sockets

Add the support for a new socket address and protocol family -
remote-processor messaging sockets. This rpmsg protocol driver
provides the necessary support to expose a rpmsg communication
channel through the socket API to userspace under the AF_RPMSG
address family. The usage relies on leveraging the socket API's
connect() for Tx sockets and bind() for Rx sockets to exchange
messages to/from a remote processor. All message communication
is performed using the userspace created sockets, and even though
the probed rpmsg proto devices do create an embedded rpmsg endpoint
for receiving messages, they are not really designed to process
any such unexpected Rx messages.

This driver forms the kernel transport portion of the TI IPC
MessageQ stack. The MessageQ stack usage of the AF_RPMSG socket
interface is not really designed to handle multiple rpmsg-proto
devices published from the same remote processor, so a restriction
is imposed to allow only a single rpmsg device even though there
are no such restrictions imposed by the rpmsg bus infrastructure.
This can be scaled to make it more generic if needed but probably
will require some userspace interface adjustments.

This patch is based on some quite an old rpmsg socket support patch
from Ohad and some work by Rob Tivy. This has been updated rather
heavily to work with all the rpmsg framework changes in 4.9+ kernels.

Signed-off-by: Ohad Ben Cohen <ohad@wizery.com>
[s-anna@ti.com: adapted, improved and modified for latest kernel]
Signed-off-by: Suman Anna <s-anna@ti.com>
4 weeks agorpmsg: core: add API to get MTU
Arnaud Pouliquen [Tue, 13 Apr 2021 21:08:11 +0000 (16:08 -0500)]
rpmsg: core: add API to get MTU

Return the rpmsg buffer MTU for sending message, so rpmsg users
can split a long message in several sub rpmsg buffers.

Signed-off-by: Arnaud Pouliquen <arnaud.pouliquen@st.com>
Acked-by: Suman Anna <s-anna@ti.com>
Reviewed-by: Mathieu Poirier <mathieu.poirier@linaro.org>
[s-anna@ti.com: cherry-pick https://patchwork.kernel.org/project/linux-remoteproc/patch/20200324170407.16470-2-arnaud.pouliquen@st.com/]
[s-anna@ti.com: use EOPNOTSUPP to fix checkpatch warning]
Signed-off-by: Suman Anna <s-anna@ti.com>
4 weeks agoMerged TI feature rpmsg into ti-linux-5.10.y
LCPD Auto Merger [Tue, 13 Apr 2021 18:15:29 +0000 (13:15 -0500)]
Merged TI feature rpmsg into ti-linux-5.10.y

TI-Feature: rpmsg
TI-Branch: rpmsg-ti-linux-5.10.y-intg

* 'rpmsg-ti-linux-5.10.y-intg' of git://git.ti.com/rpmsg/rpmsg: (21 commits)
  remoteproc: k3-dsp: Add support for IPC-only mode for all K3 DSPs
  remoteproc: k3-dsp: Refactor mbox request code in start
  remoteproc: k3-r5: Add support for IPC-only mode for all R5Fs
  remoteproc: k3-r5: Refactor mbox request code in start
  remoteproc: Add support for detach-only during shutdown
  remoteproc: Introduce rproc_detach_device() wrapper
  remoteproc: Refactor function rproc_cdev_release()
  remoteproc: Properly deal with a detach request when attached
  remoteproc: Properly deal with a stop request when attached
  remoteproc: Properly deal with a start request when attached
  remoteproc: Properly deal with a kernel panic when attached
  remoteproc: Properly deal with the resource table when stopping
  remoteproc: Properly deal with the resource table when detaching
  remoteproc: Introduce function rproc_detach()
  remoteproc: Introduce function __rproc_detach()
  remoteproc: Add new detach() remoteproc operation
  remoteproc: Use prepare ops in rproc_attach
  remoteproc: Add new get_loaded_rsc_table() to rproc_ops
  remoteproc: Properly represent the attached state
  remoteproc: Add new RPROC_ATTACHED state
  ...

Signed-off-by: LCPD Auto Merger <lcpd_integration@list.ti.com>
4 weeks agoMerge branch 'rpmsg-ti-linux-5.10.y' of git://git.ti.com/rpmsg/rpmsg into rpmsg-ti...
Suman Anna [Tue, 13 Apr 2021 17:06:09 +0000 (12:06 -0500)]
Merge branch 'rpmsg-ti-linux-5.10.y' of git://git.ti.com/rpmsg/rpmsg into rpmsg-ti-linux-5.10.y-intg

Signed-off-by: Suman Anna <s-anna@ti.com>
4 weeks agoMerge branch 'rproc-linux-5.10.y' of git://git.ti.com/rpmsg/remoteproc into rpmsg...
Suman Anna [Tue, 13 Apr 2021 15:31:37 +0000 (10:31 -0500)]
Merge branch 'rproc-linux-5.10.y' of git://git.ti.com/rpmsg/remoteproc into rpmsg-ti-linux-5.10.y

Pull in the remoteproc topic branch that enhances the remoteproc subsystem
and the K3 R5F and DSP remoteproc drivers to add support for 'IPC-only' mode.
The 'IPC-only' mode has the drivers attach/establish just the IPC/rpmsg stack
while the remote processors themselves would have been booted by a bootloader.

All R5F remote processors on AM65x, J721E and J7200 and all C66x & C71x DSP
remote processors on J721E SoCs are supported in this new 'IPC-only' mode.
The MCU R5FSS on J721E & J7200 SoCs serves as the Device Manager firmware
and would have been booted by MCU R5 SPL, with all the others early booted
from A53/A72 U-Boot.

The IPC-only mode support has been re-done completely w.r.t 5.4 LTS kernel,
and relies on a whole bunch of enhancements to the remoteproc subsystem
(currently staged attach/detach support patches for v5.13 kernel). The
design relies on newly introduced RPROC_ATTACHED and RPROC_DETACHED state
flags; new .attach(), .detach() and .get_loaded_rsc_table() rproc ops;
and changes to remoteproc sysfs and cdev interfaces. The .start() and
.stop() callbacks are not invoked in IPC-only mode.

The following is a quick summary of changes to remoteproc sysfs files
in IPC-only mode:
 - 'state' file shows either 'attached' or 'detached' instead of 'running'
   and 'offline' respectively. 'offline' state is shown if the drivers
   support stopping the early-booted remoteprocs
 - 'state' file gains a new 'detach' command in addition to 'start' and
   'stop' to specifically detach an early-booted remoteproc
 - 'firmware' file shows the firmware name as 'unknown'. Actual firmware
   file is shown only in remoteproc mode

The K3 firmwares follow a design-by-contract approach and are expected
to have the resource tables placed specifically at the base of the DDR
firmware region (base of carveout referenced at the second array index
position in the remoteproc node's memory-region property). The K3 R5F
and DSP remoteproc devices cannot be stopped in 'IPC-only' mode and
will only be detached. The firmwares are also not reloaded to do a
resource table lookup.

* 'rproc-linux-5.10.y' of git://git.ti.com/rpmsg/remoteproc: (21 commits)
  remoteproc: k3-dsp: Add support for IPC-only mode for all K3 DSPs
  remoteproc: k3-dsp: Refactor mbox request code in start
  remoteproc: k3-r5: Add support for IPC-only mode for all R5Fs
  remoteproc: k3-r5: Refactor mbox request code in start
  remoteproc: Add support for detach-only during shutdown
  remoteproc: Introduce rproc_detach_device() wrapper
  remoteproc: Refactor function rproc_cdev_release()
  remoteproc: Properly deal with a detach request when attached
  remoteproc: Properly deal with a stop request when attached
  remoteproc: Properly deal with a start request when attached
  remoteproc: Properly deal with a kernel panic when attached
  remoteproc: Properly deal with the resource table when stopping
  remoteproc: Properly deal with the resource table when detaching
  remoteproc: Introduce function rproc_detach()
  remoteproc: Introduce function __rproc_detach()
  remoteproc: Add new detach() remoteproc operation
  remoteproc: Use prepare ops in rproc_attach
  remoteproc: Add new get_loaded_rsc_table() to rproc_ops
  remoteproc: Properly represent the attached state
  remoteproc: Add new RPROC_ATTACHED state
  ...

Signed-off-by: Suman Anna <s-anna@ti.com>
4 weeks agoremoteproc: k3-dsp: Add support for IPC-only mode for all K3 DSPs
Suman Anna [Sat, 10 Apr 2021 06:06:21 +0000 (01:06 -0500)]
remoteproc: k3-dsp: Add support for IPC-only mode for all K3 DSPs

Add support to the K3 DSP remoteproc driver to configure all the C66x
and C71x cores on J721E SoCs to be either in IPC-only mode or the
traditional remoteproc mode. The IPC-only mode expects that the remote
processors are already booted by the bootloader, and only perform the
minimum steps required to initialize and deinitialize the virtio IPC
transports. The remoteproc mode allows the kernel remoteproc driver to
do the regular load and boot and other device management operations for
a DSP.

The IPC-only mode for a DSP is detected and configured at driver probe
time by querying the System Firmware for the DSP power and reset state
and/or status and making sure that the DSP is indeed started by the
bootloaders, otherwise the device is configured for remoteproc mode.

Support for IPC-only mode is achieved through .attach(), .detach() and
.get_loaded_rsc_table() callback ops and various other flags in both
remoteproc core and the K3 DSP remoteproc driver. The resource table
follows a design-by-contract approach and is expected to be at the base
of the DDR firmware region reserved for each remoteproc, it is mostly
expected to contain only the virtio device and trace resource entries.

NOTE:
The driver cannot configure a DSP core for remoteproc mode by any
means without rebooting the kernel if that R5F core has been started
by a bootloader.

Signed-off-by: Suman Anna <s-anna@ti.com>
4 weeks agoremoteproc: k3-dsp: Refactor mbox request code in start
Suman Anna [Sat, 10 Apr 2021 04:22:28 +0000 (23:22 -0500)]
remoteproc: k3-dsp: Refactor mbox request code in start

Refactor out the mailbox request and associated ping logic code
from k3_dsp_rproc_start() function into its own separate function
so that it can be re-used in the soon to be added .attach() ops
callback.

Signed-off-by: Suman Anna <s-anna@ti.com>
4 weeks agoremoteproc: k3-r5: Add support for IPC-only mode for all R5Fs
Suman Anna [Sat, 10 Apr 2021 02:35:02 +0000 (21:35 -0500)]
remoteproc: k3-r5: Add support for IPC-only mode for all R5Fs

Add support to the K3 R5F remoteproc driver to configure all the R5F
cores to be either in IPC-only mode or the traditional remoteproc mode.
The IPC-only mode expects that the remote processors are already booted
by the bootloader, and only performs the minimum steps required to
initialize and deinitialize the virtio IPC transports. The remoteproc
mode allows the kernel remoteproc driver to do the regular load and
boot and other device management operations for a R5F core.

The IPC-only mode for a R5F core is detected and configured at driver
probe time by querying the System Firmware for the R5F power and reset
state and/or status and making sure that the R5F core is indeed started
by the bootloaders, otherwise the device is configured for remoteproc
mode.

Support for IPC-only mode is achieved through .attach(), .detach() and
.get_loaded_rsc_table() callback ops and various other flags in both
remoteproc core and the K3 R5F remoteproc driver. The resource table
follows a design-by-contract approach and is expected to be at the base
of the DDR firmware region reserved for each remoteproc, it is mostly
expected to contain only the virtio device and trace resource entries.

NOTE:
The driver cannot configure a R5F core for remoteproc mode by any
means without rebooting the kernel if that R5F core has been started
by a bootloader.

Signed-off-by: Suman Anna <s-anna@ti.com>
4 weeks agoremoteproc: k3-r5: Refactor mbox request code in start
Suman Anna [Wed, 7 Apr 2021 14:46:30 +0000 (09:46 -0500)]
remoteproc: k3-r5: Refactor mbox request code in start

Refactor out the mailbox request and associated ping logic code
from k3_r5_rproc_start() function into its own separate function
so that it can be re-used in the soon to be added .attach() ops
callback.

Signed-off-by: Suman Anna <s-anna@ti.com>
4 weeks agoremoteproc: Add support for detach-only during shutdown
Suman Anna [Fri, 9 Apr 2021 22:07:29 +0000 (17:07 -0500)]
remoteproc: Add support for detach-only during shutdown

The remoteproc core has support for both stopping and detaching a
remote processor that was attached to previously, through both the
remoteproc sysfs and cdev interfaces. The rproc_shutdown() though
unconditionally only uses the stop functionality at present. This
may not be the default desired functionality for all the remoteproc
platform drivers.

Introduce a new rproc state flag 'detach_on_shutdown' that individual
remoteproc drivers can set to only allow detach in rproc_shutdown()
that would have been invoked when the driver is uninstalled, so that
remote processor continues to run undisturbed even after the driver
removal.

Signed-off-by: Suman Anna <s-anna@ti.com>
4 weeks agoremoteproc: Introduce rproc_detach_device() wrapper
Suman Anna [Fri, 9 Apr 2021 14:23:48 +0000 (09:23 -0500)]
remoteproc: Introduce rproc_detach_device() wrapper

The .attach() rproc ops is invoked through the helper
rproc_attach_device(), but the .detach() ops is invoked
directly at present. Introduce a similar wrapper function
rproc_detach_device() for .detach() ops so that the code
is symmetric.

Signed-off-by: Suman Anna <s-anna@ti.com>
4 weeks agoremoteproc: Refactor function rproc_cdev_release()
Mathieu Poirier [Fri, 12 Mar 2021 16:24:53 +0000 (09:24 -0700)]
remoteproc: Refactor function rproc_cdev_release()

Refactor function rproc_cdev_release() to take into account the
current state of the remote processor when choosing the state to
transition to.

Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
Link: https://lore.kernel.org/r/20210312162453.1234145-18-mathieu.poirier@linaro.org
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
[s-anna@ti.com: cherry-pick linux-next commit '6e71d2b2a2b7' for v5.13]
Signed-off-by: Suman Anna <s-anna@ti.com>
4 weeks agoremoteproc: Properly deal with a detach request when attached
Mathieu Poirier [Fri, 12 Mar 2021 16:24:52 +0000 (09:24 -0700)]
remoteproc: Properly deal with a detach request when attached

This patch introduces the capability to detach a remote processor
that has been attached to by the remoteproc core.  For that to happen
a rproc::ops::detach() operation needs to be available.

Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
Reviewed-by: Arnaud Pouliquen <arnaud.pouliquen@st.com>
Link: https://lore.kernel.org/r/20210312162453.1234145-17-mathieu.poirier@linaro.org
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
[s-anna@ti.com: cherry-pick linux-next commit '5daaeb5f07ed' for v5.13]
Signed-off-by: Suman Anna <s-anna@ti.com>
4 weeks agoremoteproc: Properly deal with a stop request when attached
Mathieu Poirier [Fri, 12 Mar 2021 16:24:51 +0000 (09:24 -0700)]
remoteproc: Properly deal with a stop request when attached

Allow a remote processor that was started by another entity to be
switched off by the remoteproc core.  For that to happen a
rproc::ops::stop() operation needs to be available.

Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
Reviewed-by: Arnaud Pouliquen <arnaud.pouliquen@st.com>
Link: https://lore.kernel.org/r/20210312162453.1234145-16-mathieu.poirier@linaro.org
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
[s-anna@ti.com: cherry-pick linux-next commit 'd2008a968330' for v5.13]
Signed-off-by: Suman Anna <s-anna@ti.com>
4 weeks agoremoteproc: Properly deal with a start request when attached
Mathieu Poirier [Fri, 12 Mar 2021 16:24:50 +0000 (09:24 -0700)]
remoteproc: Properly deal with a start request when attached

This patch takes into account scenarios where a remote processor
has been attached to when receiving a "start" command from sysfs.

As with the case with the running state, the command can't be
carried out if the remote processor is already in operation.

Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
Reviewed-by: Arnaud Pouliquen <arnaud.pouliquen@st.com>
Link: https://lore.kernel.org/r/20210312162453.1234145-15-mathieu.poirier@linaro.org
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
[s-anna@ti.com: cherry-pick linux-next commit '83d4e6712c3b' for v5.13]
Signed-off-by: Suman Anna <s-anna@ti.com>
4 weeks agoremoteproc: Properly deal with a kernel panic when attached
Mathieu Poirier [Fri, 12 Mar 2021 16:24:49 +0000 (09:24 -0700)]
remoteproc: Properly deal with a kernel panic when attached

The panic handler operation of registered remote processors
should also be called when remote processors have been
attached to.

Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
Reviewed-by: Peng Fan <peng.fan@nxp.com>
Reviewed-by: Arnaud Pouliquen <arnaud.pouliquen@st.com>
Link: https://lore.kernel.org/r/20210312162453.1234145-14-mathieu.poirier@linaro.org
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
[s-anna@ti.com: cherry-pick linux-next commit '800dad0025ec' for v5.13]
Signed-off-by: Suman Anna <s-anna@ti.com>
4 weeks agoremoteproc: Properly deal with the resource table when stopping
Mathieu Poirier [Fri, 12 Mar 2021 16:24:48 +0000 (09:24 -0700)]
remoteproc: Properly deal with the resource table when stopping

When a remote processor that was attached to is stopped, special care
must be taken to make sure the shutdown process is similar to what
it would be had it been started by the remoteproc core.

This patch takes care of that by making a copy of the resource
table currently used by the remote processor.  From that point on
the copy is used, as if the remote processor had been started by
the remoteproc core.

Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
Reviewed-by: Arnaud Pouliquen <arnaud.pouliquen@st.com>
Reported-by: kernel test robot <lkp@intel.com>
Link: https://lore.kernel.org/r/20210312162453.1234145-13-mathieu.poirier@linaro.org
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
[s-anna@ti.com: cherry-pick linux-next commit '8088dd4d9316' for v5.13]
Signed-off-by: Suman Anna <s-anna@ti.com>
4 weeks agoremoteproc: Properly deal with the resource table when detaching
Mathieu Poirier [Fri, 12 Mar 2021 16:24:47 +0000 (09:24 -0700)]
remoteproc: Properly deal with the resource table when detaching

If it is possible to detach the remote processor, keep an untouched
copy of the resource table.  That way we can start from the same
resource table without having to worry about original values or what
elements the startup code has changed when re-attaching to the remote
processor.

Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
Reviewed-by: Arnaud Pouliquen <arnaud.pouliquen@st.com>
Link: https://lore.kernel.org/r/20210312162453.1234145-12-mathieu.poirier@linaro.org
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
[s-anna@ti.com: cherry-pick linux-next commit '9dc9507f1880' for v5.13]
Signed-off-by: Suman Anna <s-anna@ti.com>
4 weeks agoremoteproc: Introduce function rproc_detach()
Mathieu Poirier [Fri, 12 Mar 2021 16:24:46 +0000 (09:24 -0700)]
remoteproc: Introduce function rproc_detach()

Introduce function rproc_detach() to enable the remoteproc
core to release the resources associated with a remote processor
without stopping its operation.

Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
Reviewed-by: Arnaud Pouliquen <arnaud.pouliquen@st.com>
Link: https://lore.kernel.org/r/20210312162453.1234145-11-mathieu.poirier@linaro.org
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
[s-anna@ti.com: cherry-pick linux-next commit 'd3962a397885' for v5.13]
Signed-off-by: Suman Anna <s-anna@ti.com>
4 weeks agoremoteproc: Introduce function __rproc_detach()
Mathieu Poirier [Fri, 12 Mar 2021 16:24:45 +0000 (09:24 -0700)]
remoteproc: Introduce function __rproc_detach()

Introduce function __rproc_detach() to perform the same kind of
operation as rproc_stop(), but instead of switching off the
remote processor using rproc->ops->stop(), it uses
rproc->ops->detach().  That way it is possible for the core
to release the resources associated with a remote processor while
the latter is kept operating.

Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
Reviewed-by: Peng Fan <peng.fan@nxp.com>
Reviewed-by: Arnaud Pouliquen <arnaud.pouliquen@st.com>
Link: https://lore.kernel.org/r/20210312162453.1234145-10-mathieu.poirier@linaro.org
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
[s-anna@ti.com: cherry-pick linux-next commit '6070203fe433' for v5.13]
Signed-off-by: Suman Anna <s-anna@ti.com>
4 weeks agoremoteproc: Add new detach() remoteproc operation
Mathieu Poirier [Fri, 12 Mar 2021 16:24:44 +0000 (09:24 -0700)]
remoteproc: Add new detach() remoteproc operation

Add an new detach() operation in order to support scenarios where
the remoteproc core is going away but the remote processor is
kept operating.  This could be the case when the system is
rebooted or when the platform driver is removed.

Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
Reviewed-by: Peng Fan <peng.fan@nxp.com>
Reviewed-by: Arnaud Pouliquen <arnaud.pouliquen@st.com>
Link: https://lore.kernel.org/r/20210312162453.1234145-9-mathieu.poirier@linaro.org
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
[s-anna@ti.com: cherry-pick linux-next commit '7f3bd0c019cb' for v5.13]
Signed-off-by: Suman Anna <s-anna@ti.com>
4 weeks agoremoteproc: Use prepare ops in rproc_attach
Arnaud POULIQUEN [Fri, 12 Mar 2021 16:24:43 +0000 (09:24 -0700)]
remoteproc: Use prepare ops in rproc_attach

Some actions such as memory resources reallocation are needed when
trying to reattach a co-processor. Use the prepare() operation for
these actions.

This is a custom backport of just the remoteproc core pieces from
the commit 6e20a05104e5 ("remoteproc: stm32: Move memory parsing to
rproc_ops")

Co-developed-by: Mathieu Poirier <mathieu.poirier@linaro.org>
Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
Signed-off-by: Arnaud POULIQUEN <arnaud.pouliquen@foss.st.com>
Link: https://lore.kernel.org/r/20210312162453.1234145-8-mathieu.poirier@linaro.org
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
[s-anna@ti.com: custom cherry-pick linux-next commit '6e20a05104e5' for v5.13]
Signed-off-by: Suman Anna <s-anna@ti.com>
4 weeks agoremoteproc: Add new get_loaded_rsc_table() to rproc_ops
Mathieu Poirier [Fri, 12 Mar 2021 16:24:41 +0000 (09:24 -0700)]
remoteproc: Add new get_loaded_rsc_table() to rproc_ops

Add a new get_loaded_rsc_table() operation in order to support
scenarios where the remoteproc core has booted a remote processor
and detaches from it.  When re-attaching to the remote processor,
the core needs to know where the resource table has been placed
in memory.

Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
Reviewed-by: Arnaud Pouliquen <arnaud.pouliquen@st.com>
Link: https://lore.kernel.org/r/20210312162453.1234145-6-mathieu.poirier@linaro.org
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
[s-anna@ti.com: cherry-pick linux-next commit '1a631382be1d' for v5.13]
Signed-off-by: Suman Anna <s-anna@ti.com>
4 weeks agoremoteproc: Properly represent the attached state
Mathieu Poirier [Fri, 12 Mar 2021 16:24:40 +0000 (09:24 -0700)]
remoteproc: Properly represent the attached state

There is a need to know when a remote processor has been attached
to rather than booted by the remoteproc core.  In order to avoid
manipulating two variables, i.e rproc::autonomous and
rproc::state, get rid of the former and simply use the newly
introduced RPROC_ATTACHED state.

Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
Reviewed-by: Peng Fan <peng.fan@nxp.com>
Reviewed-by: Arnaud Pouliquen <arnaud.pouliquen@st.com>
Link: https://lore.kernel.org/r/20210312162453.1234145-5-mathieu.poirier@linaro.org
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
[s-anna@ti.com: cherry-pick linux-next commit '76f4c87587e2' for v5.13]
Signed-off-by: Suman Anna <s-anna@ti.com>