On Tue, Jan 29, 2019 at 11:27:24AM +0530, Vignesh R wrote: > From: Grygorii Strashko <grygorii.stras...@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.stras...@ti.com> > Signed-off-by: Vignesh R <vigne...@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
signature.asc
Description: PGP signature
_______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot