linux-toradex.git/include/linux/soc/ti, branch v5.12-rc5

soc: ti: k3-ringacc: add AM64 DMA rings support.

2020-12-11T15:50:09+00:00

The DMAs in AM64 have built in rings compared to AM654/J721e/J7200 where a
separate and generic ringacc is used.

The ring SW interface is similar to ringacc with some major architectural
differences, like

They are part of the DMA (BCDMA or PKTDMA).

They are dual mode rings are modeled as pair of Rings objects which has
common configuration and memory buffer, but separate real-time control
register sets for each direction mem2dev (forward) and dev2mem (reverse).

The ringacc driver must be initialized for DMA rings use with
k3_ringacc_dmarings_init() as it is not an independent device as ringacc
is.

AM64 rings must be requested only using k3_ringacc_request_rings_pair(),
and forward ring must always be initialized/configured. After this any
other Ringacc APIs can be used without any callers changes.

Signed-off-by: Grygorii Strashko 
Signed-off-by: Peter Ujfalusi 
Link: https://lore.kernel.org/r/20201208090440.31792-17-peter.ujfalusi@ti.com
Signed-off-by: Vinod Koul

soc: ti: k3-ringacc: Use correct device for allocation in RING mode

2020-11-02T03:38:05+00:00

In RING mode the ringacc does not access the ring memory. In this access
mode the ringacc coherency does not have meaning.

If the ring is configured in RING mode, then the ringacc itself will not
access to the ring memory. Only the requester (user) of the ring is going
to read/write to the memory.
Extend the ring configuration parameters with a device pointer to be used
for DMA API when the ring is configured in RING mode.

Extending the ring configuration struct will allow per ring selection of
device to be used for allocation, thus allowing per ring coherency.

To avoid regression, fall back to use the ringacc dev in case the alloc_dev
is not provided.

Signed-off-by: Peter Ujfalusi 
Reviewed-by: Grygorii Strashko 
Signed-off-by: Santosh Shilimkar

firmware: ti_sci: rm: Remove unused config() from ti_sci_rm_ringacc_ops

2020-11-02T03:38:04+00:00

The ringacc driver has been converted to use the new set_cfg function to
configure the ring, the old config ops can be removed.

Signed-off-by: Peter Ujfalusi 
Reviewed-by: Grygorii Strashko 
Signed-off-by: Santosh Shilimkar

firmware: ti_sci: rm: Add new ops for ring configuration

2020-11-02T03:38:02+00:00

The sysfw ring configuration message has been extended to include virtid
and asel value for the ring.
Add the ASEL_VALID to TI_SCI_MSG_VALUE_RM_ALL_NO_ORDER as it is required
for DMA rings.

Instead of extending the current .config() ops - which would need same
patch change in the ringacc driver - add ti_sci_msg_rm_ring_cfg struct and
a new ops using it to configure the ring.

This will allow easy update path in case new members are added for the ring
configuration.

Signed-off-by: Peter Ujfalusi 
Reviewed-by: Grygorii Strashko 
Signed-off-by: Santosh Shilimkar

firmware: ti_sci: rm: Remove ring_get_config support

2020-11-02T03:38:02+00:00

The ring_get_cfg (0x1111 message) is not used and it is not supported by
sysfw for a long time.

Signed-off-by: Peter Ujfalusi 
Reviewed-by: Grygorii Strashko 
Signed-off-by: Santosh Shilimkar

firmware: ti_sci: rm: Add support for extended_ch_type for tx channel

2020-11-02T03:38:01+00:00

Sysfw added 'extended_ch_type' to the tx_ch_cfg_req message which should be
used when BCDMA block copy channels are configured:
extended_ch_type = 0 : the channel is split tx channel (tchan)
extended_ch_type = 1 : the channel is block copy channel (bchan)

Signed-off-by: Peter Ujfalusi 
Signed-off-by: Santosh Shilimkar

firmware: ti_sci: rm: Add support for second resource range

2020-11-02T03:37:59+00:00

Sysfw added support for a second range in the resource range API to be able
to describe complex allocations mainly for DMA channels.

Update the ti_sci part to consider the second range as well.

Signed-off-by: Peter Ujfalusi 
Signed-off-by: Santosh Shilimkar

firmware: ti_sci: Use struct ti_sci_resource_desc in get_range ops

2020-11-02T03:37:59+00:00

Use the ti_sci_resource_desc directly and update it's start and num members
directly instead of requiring individual parameters for them.

This will allow easy extension of the RM parameters without changing API.

Signed-off-by: Peter Ujfalusi 
Signed-off-by: Santosh Shilimkar

firmware: ti_sci: rm: Add support for tx_tdtype parameter for tx channel

2020-11-02T03:37:58+00:00

The system controller's resource manager have support for configuring the
TDTYPE of TCHAN_CFG register on j721e.
With this parameter the teardown completion can be controlled:
TDTYPE == 0: Return without waiting for peer to complete the teardown
TDTYPE == 1: Wait for peer to complete the teardown

Signed-off-by: Peter Ujfalusi 
Reviewed-by: Tero Kristo 
Tested-by: Keerthy 
Reviewed-by: Grygorii Strashko 
Signed-off-by: Santosh Shilimkar

firmware: ti_sci: Add support for getting resource with subtype

2020-08-16T21:00:22+00:00

With SYSFW ABI 3.0 changes, interrupts coming out of an interrupt
controller is identified by a type and it is consistent across SoCs.
Similarly global events for Interrupt aggregator. So add an API to get
resource range using a resource type.

Signed-off-by: Lokesh Vutla 
Signed-off-by: Marc Zyngier 
Acked-by: Nishanth Menon 
Link: https://lore.kernel.org/r/20200806074826.24607-4-lokeshvutla@ti.com