[U-Boot] [PATCH v3 2/7] soc: ti: k3: add navss ringacc driver
Tom Rini
trini at konsulko.com
Fri Feb 1 15:32:30 UTC 2019
On Tue, Jan 29, 2019 at 11:27:24AM +0530, Vignesh R wrote:
> From: Grygorii Strashko <grygorii.strashko at 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 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 at ti.com>
> Signed-off-by: Vignesh R <vigneshr at ti.com>
> ---
> drivers/Kconfig | 2 +
> drivers/soc/Kconfig | 5 +
> drivers/soc/Makefile | 1 +
> drivers/soc/ti/Kconfig | 20 +
> drivers/soc/ti/Makefile | 5 +
> drivers/soc/ti/k3-navss-ringacc.c | 1096 +++++++++++++++++++++++
> include/linux/soc/ti/k3-navss-ringacc.h | 246 +++++
> 7 files changed, 1375 insertions(+)
> create mode 100644 drivers/soc/Kconfig
> create mode 100644 drivers/soc/ti/Kconfig
> create mode 100644 drivers/soc/ti/Makefile
> create mode 100644 drivers/soc/ti/k3-navss-ringacc.c
> create mode 100644 include/linux/soc/ti/k3-navss-ringacc.h
[snip]
> +#ifdef DEBUG
> +#define k3_nav_dbg(dev, arg...) dev_err(dev, arg)
> +static void dbg_writel(u32 v, void __iomem *reg)
> +{
> + pr_err("WRITEL(32): v(%08X)-->reg(%p)\n", v, reg);
> + writel(v, reg);
> +}
> +
> +static u32 dbg_readl(void __iomem *reg)
> +{
> + u32 v;
> +
> + v = readl(reg);
> + pr_err("READL(32): v(%08X)<--reg(%p)\n", v, reg);
> + return v;
> +}
> +#else
No more new debug macros / functions please. If it's worth having in
the driver now that it's being submitted it's worth using the right
level of pr_xxx directly, or not having at all. Thanks!
--
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20190201/7bc3d57b/attachment.sig>
More information about the U-Boot
mailing list