Hi Santosh,

On 13/01/2020 23.28, santosh.shilimkar@oracle.com wrote:

On 12/23/19 3:38 AM, Peter Ujfalusi wrote:

quoted

Hi Santosh,

On 23/12/2019 13.04, Peter Ujfalusi wrote:

quoted

From: Grygorii Strashko <grygorii.strashko@ti.com>

The Ring Accelerator (RINGACC or RA) provides hardware acceleration to
enable straightforward passing of work between a producer and a
consumer.
There is one RINGACC module per NAVSS on TI AM65x SoCs.

The RINGACC converts constant-address read and write accesses to
equivalent
read or write accesses to a circular data structure in memory. The
RINGACC
eliminates the need for each DMA controller which needs to access ring
elements from having to know the current state of the ring (base
address,
current offset). The DMA controller performs a read or write access to a
specific address range (which maps to the source interface on the
RINGACC)
and the RINGACC replaces the address for the transaction with a new
address
which corresponds to the head or tail element of the ring (head for
reads,
tail for writes). Since the RINGACC maintains the state, multiple DMA
controllers or channels are allowed to coherently share the same
rings as
applicable. The RINGACC is able to place data which is destined towards
software into cached memory directly.

Supported ring modes:
- Ring Mode
- Messaging Mode
- Credentials Mode
- Queue Manager Mode

TI-SCI integration:

Texas Instrument's System Control Interface (TI-SCI) Message Protocol
now
has control over Ringacc module resources management (RM) and Rings
configuration.

The corresponding support of TI-SCI Ringacc module RM protocol
introduced as option through DT parameters:
- ti,sci: phandle on TI-SCI firmware controller DT node
- ti,sci-dev-id: TI-SCI device identifier as per TI-SCI firmware spec

if both parameters present - Ringacc driver will configure/free/reset
Rings
using TI-SCI Message Ringacc RM Protocol.

The Ringacc driver manages Rings allocation by itself now and requests
TI-SCI firmware to allocate and configure specific Rings only. It's done
this way because, Linux driver implements two stage Rings allocation and
configuration (allocate ring and configure ring) while TI-SCI Message
Protocol supports only one combined operation (allocate+configure).

Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com>
Signed-off-by: Peter Ujfalusi <redacted>
Reviewed-by: Tero Kristo <redacted>
Tested-by: Keerthy <j-keerthy@ti.com>

Can you please giver your Acked-by for the ringacc patches if they are
still OK from your point of view as you had offered to take them before
I got comments from Lokesh.

Sure. But you really need to split the series so that dma engine and
soc driver patches can be applied independently.

The ringacc is a build and runtime dependency for the DMA. I have hoped
that all of them can go via DMAengine (hence asking for your ACK on the
drivers/soc/ti/ patches) for 5.6.

Can you please do that?

This late in the merge window that would really mean that I will miss
another release for the KS3 DMA...
I can live with that if you can pick the ringacc for 5.6 and if Vinod
takes the DMAengine core changes as well.

That would leave only the DMA drivers for 5.7 and we can also queue up
changes for 5.7 which depends on the DMAengine API (ASoC changes, UART,
sa2ul, etc).

If they go independently and nothing makes it to 5.6 then 5.8 is the
realistic target for the DMA support for the KS3 family of devices...

Regards,
- Péter

Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel