On Tue, Feb 05, 2019 at 05:31:24PM +0530, Vignesh R wrote:
The UDMA-P is intended to perform similar (but significantly upgraded) functions as the packet-oriented DMA used on previous SoC devices. The UDMA-P module supports the transmission and reception of various packet types. The UDMA-P also supports acting as both a UTC and UDMA-C for its internal channels. Channels in the UDMA-P can be configured to be either Packet-Based or Third-Party channels on a channel by channel basis.
The initial driver supports:
- MEM_TO_MEM (TR mode)
- DEV_TO_MEM (Packet mode)
- MEM_TO_DEV (Packet mode)
Signed-off-by: Peter Ujfalusi peter.ujfalusi@ti.com Signed-off-by: Grygorii Strashko grygorii.strashko@ti.com Signed-off-by: Vignesh R vigneshr@ti.com
Please note that some of these comments apply to patch #2 as well, but I see a specific thing here
[snip]
+++ b/drivers/dma/ti/k3-udma-hwdef.h @@ -0,0 +1,184 @@ +/* SPDX-License-Identifier: GPL-2.0+ */ +/*
- Copyright (C) 2018 Texas Instruments Incorporated - http://www.ti.com
- This program is free software; you can redistribute it and/or modify
- it under the terms of the GNU General Public License version 2 as
- published by the Free Software Foundation.
You don't need/want both the SPDX tag and boilerplate.
[snip]
+/* Generic register access functions */ +static inline u32 udma_read(void __iomem *base, int reg) +{
- u32 v;
- v = __raw_readl(base + reg);
- pr_debug("READL(32): v(%08X)<--reg(%p)\n", v, base + reg);
- return v;
+}
+static inline void udma_write(void __iomem *base, int reg, u32 val) +{
- pr_debug("WRITEL(32): v(%08X)-->reg(%p)\n", val, base + reg);
- __raw_writel(val, base + reg);
+}
I wasn't clear enough, sorry. We should be using __raw_readl/writel and not wrapping them. If things are still in such a state that you need to dump every read/write, are things really usable? I assume this is just handy bring-up related work and it's time to drop it. Thanks!