[U-Boot] [PATCH v3 2/7] soc: ti: k3: add navss ringacc driver

[Tom Rini <trini@konsulko.com>]

On Tue, Jan 29, 2019 at 11:27:24AM +0530, Vignesh R wrote:

> 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 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: Vignesh R <vigneshr@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>